Microsoft Certifications: Web development path

Microsoft Corporation offers a rich set of possibilities when it comes to education of new and existing software developers. Taking certification exams and certifying your knowledge is one of the best ways to build a solid knowledge base, improve your skills, and get ahead with your career in software development. In this post I will describe what it takes to follow Microsoft Certifications: Web development path.

In this wide range of certifications, where does one start from? Well, it depends on your current skills and work experience. If you are new to software development with less then one year of work experience or so, then my suggestion is you start with Microsoft Technology Associate (MTA) certifications.

You may start with  following MTA exams:

Software Development Fundamentals (Exam: 98-361)
Web Development Fundamentals (Exam: 98-363).
.NET Fundamentals (Exam: 98-372)
HTML5 App Development Fundamentals (Exam: 98-375)

For the complete list of MTA certifications please see MTA Certifications web page.

MTA certications are optional and are useful only if you do not have work experience developing these solutions.

What after that? The next part of the path is of professional certifications. The web development path leads to Microsoft Certified Solutions Developer: Web applications (MCSD). This title is awarded to anyone who passes these exams:

Programming in HTML5 with JavaScript and CSS3 (Exam: 70-480)
Developing ASP.NET MVC Web Applications (Exam: 70-486)
Developing Microsoft Azure and Web Services (Exam: 70-487)

When you complete all of these exams, you will get the title of MCSD: Web Applications which will certify your knowledge in the field of developing web applications using HTML5, CSS3, JavaScript, and ASP.NET MVC.

Offline availability with AppCache

Offline availability of your web application will give a little extra comfort to your users. If using Local storage an appropriate choice to enable web applications to work offline with dynamic data (see my post on Local storage), Application cache (hereafter AppCache) is a good choice for making the static content of the web application available offline.

About AppCache

AppCache enables developers to specify a set of files which need to be cached by the browser. While cached, the requested resources will be served from the disk and this will make your web application available even when users are offline.

Caching static content has several benefits which you may like to leverage, including:

  • Better site performance, as static content will be served from the disk and not requested from the server
  • Better server performance, as less resources will be served and bandwidth will be preserved
  • Users will have the possibility to access your contents while offline, leading to better user experience and satisfaction
  • Mobile users can use the web app even when they are out of internet coverage
  • Mobile user can bookmark/pin the web application to their phone and use it later as a mobile app (offline)

The cache size limit may vary between browsers, but a cache size of 5MB can be expected from modern browsers, and with users permission, the size can be increased if needed.

How do we tell the browser to cache our site, and most importantly, which files to cache. We can do this using a special file called Manifest file. We tie manifest file to the html root element using manifest attribute. e.g.

<html manifest="webapp.appcache">

It is recommended that the extension of the file is .appcache.

Manifest file structure

Manifest file is a simple text file which should be served with “text/cache-manifest” content type. The very first line of the file should be:

CACHE-MANIFEST

and after that files to be cached are listed one per line.

index.html
css/main.css
css/theme.css
js/lib.js

Folders and wildcard specifiers are also permitted.

The common practice is to follow this structure:

CACHE MANIFEST
#23.10.2014 v1.0.10
/file1.html
/file2.jpg

NETWORK:
posts.php

FALLBACK:
offline.html

On the first line we have put the mandatory declaration of “CACHE MANIFEST”. Then on the second line we put date and version as comment. After version, we start declaring files/folders which are to be cached. The “NETWORK” section shows which files should not be cached as they change frequently, and last, with “FALLBACK” we specify what should be used when a resource is unreachable.

The comment part with version number has a significant importance here. The browser will not ask for the cached files unless one of these two is true:

  • The cache is deleted
  • The manifest file has changed

We best note the change of the manifest file by putting a version number in it. Whenever we do a change in any of the cached files, we simply increment the version number to advise the browsers to re-cache the files.

Specifying the manifest file will make the browsers cache the content specified and make the static content of your web app available offline.

 

HTML5 Local Storage API

It has started to become a common requirement for Web applications to have some support for offline usage. HTML 5 local storage (hereafter local storage) is one of the options to consider when you need to support offline use of your web application. But what is local storage, and when should you consider it. Let’s go through what you need to know before you start using local storage.

What is HTML5 Local storage API?

Local storage is a storage of key-value pairs (KVP) which you can store and access using a JavaScript API. It is supported by most of major browsers (even IE8 does support it :)). The KVPs are string values of information used to store in the storage of the browser

e.g.  “CMS” => “WordPress”

Local storage has several advantages over Cookies and can be a good substitute for them. Cookies have the size limitation of 4KB, on the other side, the usual supported size for Local storage is 5MB. Also, cookies are sent to the server with every request, overloading the bandwidth, whilst, Local storage is not sent to the server any request, instead, only the required value is send.

Local storage is a persisted storage and have no expiration time. The data persisted will stay until cleared. There is another variant of browser storage which is temporary, and that is Session storage. Session storage is used only for the session, and when session expires or is destroyed, so is the session storage.

Storing and reading from Local storage

Before starting to use the Local storage, it is advisable you always test first if it is supported by the browser, and you do it with a simple check like this:

if (window['localStorage'] !== null) {
//your code here
}

Storing values to Local storage is done using setItem() function. This method accepts two parameters, the first one is the key, and second parameter is the value. e.g.

localStorage.setItem("cms", "WordPress");

If we open chrome developers tool in resources tab, we can see the values in local storage, and there is our “cms” key with value set to “WordPress”

Local storage in chrome developer tools

 

Reading the stored value is done using getItem() function and supplying the key as a parameter. e.g.

var cmsValue = localStorage.getItem("cms");

Other functions

There are several other useful functions which you can use with Local storage. If you want to get the total number of keys stored you can use localStorage.length property, or if you want to remove one item from the storage you can do this by calling removeItem function. e.g.

var numberOfItems = localStorage.length;

localStorage.removeItem("cms");

It is also possible that you clear the whole list of items stored by calling function clear e.g.

localStorage.clear();

Events

In some more advanced scenarios, you may want to track changes in local storage, that is where events come in. Events are out of scope of this post, however, it is good to remember that they are there should you have such a requirement.

References

If you want to get in details, the specification of the local storage can be found in this link: Web Storage specification