Monthly Archives: May 2014

Offline web applications with HTML5

The Rapid Apps team builds its apps using HTML5 as we believe this is the quickest way for us to create and release apps that can be used on any device without the need for lots of bespoking for each of the platforms that are out there. One of the key things needed with an app is the ability for it to work offline using  a manifest. Here’s how we do that.

When working with an HTML5 web app that you want to run offline you will need to rebuild the manifest (over and over and over) whenever you make changes to the code so that your browser knows it has changed and you can test/use it. This is a pain, so we have created this nice little console app that you can run in the background and it will keep the file up to date for you.

Download the manifest generator

How do I make a web app cachable I hear you ask?

To make a web app cachable, you first need to tweak the markup.

In the <html> element you need to add a manifest attribute that points to your appcache file.

e.g.

<html manifest=”fymp.appcache” xmlns=”http://www.w3.org/1999/xhtml”>

The appcache file needs to be served by IIS as type text/cache-manifest, so you’ll need to tweak your web.config file. In system.webServer add a staticContent element and then a mimemap for the file extension. ALWAYS remember to put a remove element in first incase the server hosting your app is already configured to serve appcache files, otherwise it will fail miserably as you can’t have the same mimeMap twice.

e.g.

<system.webServer>
    <staticContent>  
      <remove fileExtension=”.appcache”/>
      <mimeMap fileExtension=”.appcache” mimeType=”text/cache-manifest” />
    </staticContent>
</system.webServer>

The appcache file should be called {application name}.appcache and live in the root folder, where the index.html page is kept. In addition to this, you also need to create a file called AppCacheExclude.txt which lists out the files/folders you don’t want to put in the cache (e.g. any visual studio files, web.configs and the like). An example of the contents of an AppCacheExclude.txt file is shown below.

AppCacheExclude.txt
mycache.appcache
MyApp.csproj
MyApp.csproj.user
MyApp.sln
MyApp.v12.suo
Web.config
bin\*
obj\*
Properties\*
.svn\*

Using a * means all files/folders in the folder specified. You must include this or it will fall over and die on you horribly. It is also, obviously, crucial you don’t cache the exclude or the appcache file.

With all the above done, simply run the console app, tell it where to monitor and off you go. When you are done coding the manifest file can be checked back in to source control so CI tools can pick them up, deploy them, and then all the consumers of your app will seamlessly receive the changes!

If you are really interested (and I know you are) you can get the source code here

Speeding up new projects

We wouldn’t be the Parliamentary Rapid Apps Team if speed wasn’t important to us, and to our customers. As you can imagine, we are constantly picking up new projects and aiming to get a working product to our clients as quickly as we can, and one of the best ways to speed up that process is to speed up the time it takes to kick the project off.

Whenever we start a new project, someone has to go through the same steps just to get to a point where we can start coding for real:

  1. Create a new code repository for the project
  2. Create the shell of a project in Visual Studio
  3. Import useful features and 3rd party tools into the project
  4. Create TeamCity projects and builds for the project so it can have continuous integration and build monitoring, and be one-click deployed to the QA environment

Each time we do this, there is also potential for steps to be missed, copy and paste errors to occur or naming conventions to be ignored. And just as importantly, it takes time!

So simple a computer could do it

The solution to this problem is to automate this process as much as possible to cut down on manual mistakes, save time and make the most of our reusable code. So we have created MEGABuild™, which consists of two main components.

Templates

The first step was to identify which type of projects we create the most often (.NET MVC and .NET WebAPI) and what components and code we used in those projects repeatedly. We then created a Visual Studio solution for each type of project, which can be used as the perfect starting point for any new project. Our MVC solution template, for example, includes JQuery, Bootstrap, log4net, our custom stylesheets, a simple view layout and our basic configuration and automated build settings. Each solution is built with a number of keywords in it that can be replaced automatically when we use it to create a new project.

MEGABuild™

The final piece of the puzzle is a simple-to-use wizard that allows us to enter key information about a new project (such as its name and what namespace we should use) and then works away for a few minutes doing all the steps we would normally have to do manually. As a brief overview, it does the following:

  1. Checks out the latest version of the Solution template
  2. Creates the SVN repository for the new project
  3. Copies the solution template into the repo, and renames the keywords with the new project settings using powershell scripts
  4. Updates the ignore list for the new repo
  5. Commits the new solution to the repo
  6. Creates a new project and subproject in TeamCity
  7. Creates automated builds in TeamCity based on the build templates we have previously defined
  8. Finally, shows the user where they can find all this new stuff!

 

When the wizard has finished, you can simply checkout your new project from the repository and start coding!

Even more mega

We hope in the next couple of sprints to make MEGABuild™ to do even more for us. It can automatically enter DNS entries for our internal environments, and add details about the projects it creates to our other tools, such as our build monitor and our release management tool.