Category Archives: code

Super Easy SPA with Durandal

I have not been very active from almost one and half year on this blog. There has been lot of learning, unlearning had happened in this duration. By the way, to revive my blog, I have invited my good friend Akhlesh Tiwari to share his overall JavaScript expertise with all of us. He happily agreed and here is the first article on his favorite subject i.e. Single Page Applications. Please do encourage the new author and share your feedback so that we all can improve.

Durandal is open source JavaScript library for SPA. Durandal is built on libs like jQuery, Knockout and RequireJS. So if you are already familiar with these libraries then very easily you can start making amazing single page apps.

Durandal is technology agnostic SPA framework so you can use it with any backend technology or make pure html/JavaScript app. To get start with Durandal all you need to get JavaScript libraries and modules and follow folder structure. So for this tutorial we take MVC4 as backend.

Get Start with Durandal in .Net

In .net we can download Durandal template from  VSIX file . Durandal is also available through nuget or you can install Durandal starter kit with this command Install-Package Durandal.StarterKit .but I will use manual setup for Durandal for better understanding of the framework. For manual setup just download all startup files. Startup project has basic examples in Durandal and navigation setup that can be modified as per requirement. After downloading startup project, we will go step by step to create Durandal app.

Step-1 Create MVC Project

First we will create mvc4 internet application in visual studio named as DurandalApp.

New Project

You can also take empty MVC project but then you have to write your own controller and starting cshtml page.

Step-2 Folder Structure

Durandal follows the folder structure to create application so here is application organization:-

Durandal Folder Structure

I recommend creating “App” folder with in project as shown above. Durandal applications are built as a collection of AMD modules. In fact, Durandal itself is just a set of modules. Here is what each folder used for:-

“viewmodels folder”- contains application-specific code (js file)

“views folders” contains the application-specific views(html).

“main.js” contains all of the JavaScript startup code for your app including the route configuration, module configuration etc. your app execution always starts with main which is referenced by the RequireJS script tag in the index.html file (.cshtml for .NET).

After setting up this folder structure, copy Durandal library under Script folder of your MVC project (You can keep Durandal library anywhere as per requirement, I keep it in Script folder because it just like a 3rd party JavaScript library). Durandal library has all core modules.

Durandal library folder structure

Durandal Lib Folder Structure

We also need RequireJS and knockout js(Jquery is optional) so I have added two more folders under lib folder. These folders have respective js library.

Step-3 Index.cshtml

A Durandal app is a Single Page App. When you navigate between pages, you are not navigating to new pages on the server. Instead, you are loading new virtual pages into the one-and-only-one server-side view(index.cshtml). For this sample I have created MVC HomeController.

namespace DurandalApp.Controllers{

public class HomeController : Controller{

public ActionResult Index(){

return View();




So it is just typical MVC code. I created the following server-side MVC view. This is the one-and-only server-side view used by the application.


<div id=”applicationHost”>



Sample App Durandal





<script type=”text/javascript” src=”../Scripts/lib/require/require.js” data-main=”/App/main”></script>

The “applicationHost” is where your app’s views will live. Below that is the script tag that references RequireJS. It points to our application’s entry point, declared in the data-main attribute. At runtime, this resolves to the main.js file.

In layout.cshtml we will setup css and js libraries. @RenderBody() has nothing just renders the cshtml view.

<!DOCTYPE html>

<html lang=”en”>


<link rel=”stylesheet” href=”Content/bootstrap/css/bootstrap.css” />

<link rel=”stylesheet” href=”Content/bootstrap/css/bootstrap-responsive.css” />

<link rel=”stylesheet” href=”Content/font-awesome/css/font-awesome.css” />

<link rel=”stylesheet” href=”Scripts/lib/durandal/css/durandal.css” />

<link rel=”stylesheet” href=”Content/site.css” />






You can see that I have put all style sheets under content folder and JavaScript under Scripts folder. In Durandal app durandal.css is used to render message box and dialog box and other css are optional.

Step-4 main.js

In 4th step we will see entry point of app that is main.js. It is the first code that get executed and where you can configure Durandal setting and tells to start the application.



paths: {

‘text’: ‘../Scripts/lib/require/text’,

‘durandal’: ‘../Scripts/lib/durandal/js’,

‘plugins’: ‘../Scripts/lib/durandal/js/plugins’,

‘transitions’: ‘../Scripts/lib/durandal/js/transitions’,

‘knockout’: ‘../Scripts/lib/knockout/knockout-2.3.0’,

‘bootstrap’: ‘../Scripts/lib/bootstrap/js/bootstrap’,

‘jquery’: ‘../Scripts/lib/jquery/jquery-1.9.1’



define([‘durandal/system’, ‘durandal/app’, ‘durandal/viewLocator’], function (system, app, viewLocator) {


app.title = ‘Durandal Starter Kit’;


router: true,

dialog: true,

widget: true


app.start().then(function () {


app.setRoot(‘viewmodels/shell’, ‘entrance’);



This code shows main functionality but it can be different according to application. Here is the list of main task in main.js:-

  1. RequireJs: – Configuration:- first few lines of main js used for configuring the durandal module path.
  2. Debugging: – Durandal have debugging functionality which can be used by turning on the debugging.
  3. Title: – You can set your application title.
  4. ConfigurePlugins: – here you can tell which plugin will available to your app.
  5. app.start():- this is actually used to kick off the application and it returns a promise which resolved when DOM is ready and framework is prepared for configuration.
  6. UseConvention: – here we set up our viewLocator with basic conventions.
  7. app.setRoot():- This is what actually causes the DOM to be composed with your application. It points to your main view model (or view). When this is called, Durandal’s composition infrastructure is invoked causing RequireJS to require your root view model, use the viewLocator to locate its view, data-bind them together and inject them into the applicationHost element. Additionally, the ‘entrance’ transition animation is used to animate the app in.

Step-5 Shell

shell is just like master page of durandal app where put all static content which you want to remain constant throughout the durandal app. So this is great place to have navigation, header and footer etc.  So first we will create the shell.js in App/viewmodel and shell.html in App/views.


define([‘plugins/router’, ‘durandal/app’], function (router, app) {

return {

router: router,

activate: function () {[

{ route: ”, title: ‘home’, moduleId: ‘viewmodels/home’, nav: true },


return router.activate();








<ul data-bind=”foreach: router.navigationModel”>

<li data-bind=”css: { active: isActive }”>

<a data-bind=”attr: { href: hash }, html: title”></a>





<div data-bind=”router: { transition:’entrance’ }”></div>


When you call setRoot, Durandal requires both the module and the html and uses Knockout to data-bind them together. It then injects them into the DOM’s applicationHost. As we see in shell.js, router plugin is used for registering the route.then we have used router’s navigationModel to dynamically generate or link in shell.html.

Here in shell.html knockout is used for view composition i.e. router keep track of current route and when route is changed new view is composed according to new route. Here is how exactly it happens?

  1. A route is triggered and the router finds the corresponding module and sets it as active.
  2. The router binding detects that the active module has changed. It examines the value and uses that to find the appropriate view (using the viewLocator).
  3. The module and the located view are data-bound together.
  4. The bound view is inserted into the DOM at the location of the router binding.
  5. If the router binding specifies an animation, it is used to smoothly show the new view.

Step-5 View and Viewmodels (Final Step)

Each page in application is comprised of view and viewmodel. Once you’ve setup the application as described above you can extend the application by adding new view in views folder and viewmodel in viewmodels folder. Then you just register with router in shell.js and when you go to that route, router will locate viewmodel and compose the view(insert the view in DOM). For example I am taking new page home.html.

So first create test.html under views folder and with the same name create js file under viewmodels folder.


define(function (require) {

var app = require(‘durandal/app’);

return {

displayName: ‘home Page’,

showMessage: function () {

app.showMessage(‘This is my first home page!’);






<h2 data-bind=”html: displayName”></h2>

<button data-bind=”click: showMessage”>Click Me</button>


Finally, go to the shell.js module and add update the router’s mappings whenever you add new page. In our application we have already added router mapping for home page.

define([‘plugins/router’, ‘durandal/app’], function (router, app) {

return {

router: router,

activate: function () {[

{ route: ”, title: ‘home’, moduleId: ‘viewmodels/home’, nav: true }


return router.activate();




Note-when you add new page, for registering your route, update the route mapping under shell.js. route property will have different value according to route.

e.g. If you add two new page like about and contact then will have :-[

{ route: ”, title: ‘home’, moduleId: ‘viewmodels/home’, nav: true },

{ route: ‘about’, title: ‘about’, moduleId: ‘viewmodels/about’, nav: true },

{ route: ‘contact’, title: ‘contact’, moduleId: ‘viewmodels/contact’, nav: true }


Now, run the application (make sure your browser isn’t caching resources) and you should see a new navigation option called ‘test’. Click on it and you will navigate to your new page. It’s that simple. I hope you like this blog post and will now start your journey of SPA-Single Page Applications.

Programmer’s Bad Habits II

Continuing part I of this series, here are some more things to add to bad habits or common fallacies and traps of programmers that are holding them from performing well.

1. Carry over the dead code/experiments/comments with you.

Go to any system/project’s codebase that is more than a year old and you will get to know what this means. You see the comment that says “Sales Invoice in next five lines” and more than 20 lines of code that is commented out and another 10 lines code that are currently working as you debug…and nobody can explain what that old commented code does but they don’t dare to clean that up.

2. I can’t fix another programmer’s code, rather I will rewrite it.

Ah! This is a classic and I admit that I had been also got hold of it in my early carrier. One programmer never says good things about another programmer’s code. I think this is in our gene and sometimes even if I think of this ,I think programmers in somewhere deep down their minds wanted a perfect world and each one has their own version J of it. Anyway, what all I can suggest is they can read martin fowler’s classic ‘refactoring’ book and this notion will go away.

3. The world can be written only with “if-else” and “for” loops and method reuse.

Junior junkie who can code for days and night and fresh from colleges or worse spent one or two years in some company can write entire systems in if-else and for loops and some procedure reuse. I think some or the other way this has a root cause of “failing to unlearn what we had learned first”. Most of these guys had learned C language as their first programming language and may found they were good at it or they presume that they are good at it. Biggest mistake our schools and some local book authors has did is they are teaching procedural and object oriented programming language the same way.

These authors had not thought over the object oriented principles, rather their focus is teaching upon the tooling of object orientation like inheritance and polymorphism and unfortunately this is the case in India which has got some credibility in IT.

4. Testing is inferior to programming. It is not what true programmer’s do. Testing is THEIR (Test Engineer’s) JOB.

I spent my early years of career in small start-ups where we don’t have luxury of appointing a separate test engineer. Whatever we write, we have to make sure that we are doing it correctly and the result of it is though I have got respect for the test engineers since I realized that say after testing for basic flows and validation errors it is very difficult to think of something different that can break the system. In regard of this thought I had learned some testing basics from various websites and still those are very handy even as a programmer.

Nowadays, While working with midsized firm and continually reading about TDD all I am realizing is, programmers had a misconception that they can write a code that had errors and they can just give it to test engineer to clear even basic things like spelling mistakes.

It is shameful that people do not want to test their own code and worst of all rely on some other individual for correcting their own mistakes.

The notion of TDD is good but their also our cleaver programmer (as well as some lousy test engineers) friends tell us the list of excuses like schedule, how can I write the test when there is no development etc.

5. Code review means somebody should check their code line by line for all aspects and point out the mistakes that they had made.

Yes, it is insane but I had seen some managers and some programmers have such ridiculous expectations from code reviews. First thing is programmer should be responsible for the code he/she is writing and not the other fellow who is helping it out to make that code better.

Code reviews should be conducted on sample basis and with the help of some tools likes of static code analysis etc. Checking the mere code conventions should not be the only intent of review. It would be more beneficial that code reviewer should do some firsthand refactoring and in that process programmer would learn things and two about the code as well as this leads to better design.

6. Creating a build means compiling the code.

For the people who have not been in the agile/product development have this misconception that compiling the code is the thing that makes the build process.

These people are missing so many steps that makes build process. I even really doubt that these people consider build as a process.

Many times project requires code signing ,obfuscation of code, replacing connection strings from test environment to production environment ,building for various platforms likes of Windows,*nix or 32 bit,64 bit as well as routine tasks as zipping the release, pushing the release over ftp, emailing about the release to stakeholders etc.

The people ignorant about the build process should really search for the continuous integration and trivial toolset of it which includes brilliant TFS, cruise control, Hudson, rake, NAnt etc.

These fallacies and traps are costing our customers millions and we should recognize it. In my opinion the root cause of these is the way SME’s hiring the resources, further on lack of training and setting the culture to sub standards.

The more I go deeper, I think the waterfall thinking model is still lurking people to write bad code and managers had their fear to adopt the bottom up management approach and what we need is agile mindset and learning organization.

“Learning is not child’s play; we cannot learn without pain.”
– Aristotle

Share this post :

Programmer’s Bad Habits

“Good habits are formed; bad habits we fall into.”

There are much literature that has been written on habits or misconceptions that gets acquired by human beings and how it become hard to leave, especially if those habits or concepts are considered as bad. Bad habits as we all know, seems easy and “quick” solutions that are acquired, mostly unconsciously. But good habits are hard to acquire but gives long lasting benefits to us.

As a developers/programmers or architects, we also acquire habits/misconceptions in our work that consciously or unconsciously imposed seems “quick and easy” solutions to our programming problems. I wanted to throw some light on such bad habits of us-developers…I had also gone through some of these bad habits but thankfully dropped them in my journey to become good dev. Some people may also term them as “anti patterns”, but I am not very comfortable about the word ‘anti-pattern” ;maybe I explain my reasons of terminology in some other post, but now let’s focus on these bad habits or misconceptions.

1. Ignore the warnings, while compilation since they are not causing any problems.

I had seen this many times and I hate this. Some colleague of mine calls me up says that s/he couldn’t find the bug in their program and even after spending a couple of hours and tried all the things s/he can do…

First thing I would try is, I rebuild codebase and see if they had any compilation errors or warnings…and here we go..many warnings yelling for attention!! When questioned about the warnings, the usual answer I hear is “oh! They are not causing any problem so we just ignored them”…and when I see the warnings..Most of the unfound reasons of the bugs are lying in warnings that are in front of the programmers but they can’t see it.

I am not suggesting that you convert all those warning messages into error messages, but warnings are generally-the sign of future or runtime error places and signaling towards inefficiencies in code ;so treat them like errors and work on those.

2. If code is compiling, it is working code.

If you give some junior any requirement and say them that “ok, you need to code this feature/use case etc.” and just watch them. They just start writing the code at the blink of the eye and eager to show their worthiness. But the unfortunate part is next, and that is when they say I am done with the feature/s after their code is getting compiled. Hey Guys! Wake up… writing a compiling code is just a first step and hell…you are not done…Your code has not even passed those unit tests and how you dare to say that your are done.

3. Code once written and running should never be touched.

I generally deal with legacy not in C/C++ terms but have reengineered systems those are in VB 6, .NET 1.1, and likes.

In my opinion, legacy should be termed as “system with inefficiencies even it’s written with latest and greatest likes of .Net 3.5.” Unfortunately that is not the de-facto definition.

Most of the developers and even sometimes project managers have this nausea that if the code has written and that is running that should never be touched.

They say, hey! That is running and as per specifications, why you want to change it or make it better [they see as, this idiot is fooling us by wasting hours on thing that is already done!!] What they miss out is; it is like rusting of the iron. If the code can be improved even a bit by any means, it should be done. It is like you see a piece of rusting iron in your vehicle and still you do not do anything and run your vehicle until any accident occurs.

Damn, that kind of code can carry any characteristic like rigid to requirement changes , fragile like showing strange behavior like fixing bug in one part of code throws the strange error in some other part of the code which is not even related with first. So, the point here is ,we need to remove the inefficiencies.

4. New features can only be floated out by writing tons of new code.

This is really hard to realize that we had picked up such misconception and even harder to come out of this!!

For example, during one re-engineering project, I realized that our architecture is giving ability to product that the client can sell different modules/subsystems to the end users as on need basis and we communicated this to product owner and he liked that idea and which in turn given the product the new revenue stream.We have delivered a feature that is making a strong business sense for product owner without adding extra code!!

All this becomes possible not because we have added some more code for such business feature but cleverly re-architecting the system.

Oh! This post is somewhat getting bigger,I am sorry to break the continuum but just like ‘short methods’ is a good idiom to follow in code, I am keeping this post small and write it in chunks as a true agile developer 🙂

Till then Happy Thinking!

Hope to see you next time…


Share this post :