After the initial usage of JavaScriptMVC in my first view, I reviewed the code. One of the things I saw was my wrong usage of MVC. I’m not publishing that code, it was that bad. This had nothing to do with the implementation of JavaScriptMVC, but only with the usage of the framework.

What I had was an element controller, which takes care of reacting on changes of the input element, should update the model and get some info back from the model and can inform the view. This can be divided into 3 steps:
1. Controller gets event from view, e.g user has typed something in the input element.
2. Controller lets the model update itself with the data type by the user.
3. Controller gets event from model that everything is done

Identifying the above steps. I had no difficulty at all to implement a correct MVC pattern with JavaScriptMVC

Controller gets event from view

First we register a change event handler on the input element controller. This is done with the following snippet:

._dayinput is a class selector, the change the event. The function is executed when someone has changed the element. This gets us to the second step.

Controller lets the model update itself

Due to the registration of the view element on the controller, there is a change event fired and caught by the controller. This fires the next function.

Controller gets event from model that everything is done

It’s turns out the JavaScriptMVC framework uses ajax openhub to publish events about all sort of things. It also publishes create, update, destroy and error events.
Basically it works as follows. The model receives the data and changes the model. The model then fires an event, on which the controller is subscribed.
The events fired by the model are handled by the framework. If you want to react on those event you have to subscribe the controller to those events. See the code snippet for an example.

The implementation briefly describes how I implemented the MVC pattern with JavaScriptMVC. The framework itself is very powerful in doing this, I should have done more rtfm before coding.

We are doing a project with JavaScriptMVC as the framework for the front-end. The framework itself is a good framework for building web applications. One of our development principals is test driven development (TDD). By default JavaScriptMVC comes with the jQuery testing environment, nothing wrong with that, but we are more fond of Jasmine.

One of the things we also have in place is code coverage. So if you don’t want to disappoint your colleagues, you have to have your tests in place (not mentioning that its TDD and not TAD).

The testing of the model and the view are pretty straightforward, so we thought the controller should also be very easy to test. We opened the generated code and came across the following piece of code:

With this code we had some trouble:
1. Not testable, at least difficult to test
2. To much view in the controller code
3. Code duplication across the controllers.

So how do we solve those issues? This didn’t seem to hard, and if you think for a few minutes, it really is not that difficult.
The first thing we did is moving the code to a different method:

This is a solution only for the current controller, and the code is not that good.
Next step is to determine where to put the code so every controller can use this. The first thought was to patch the controller of JavaScriptMVC. We thought this was not correct, because when you update JavaScript MVC with a new version, you forget that you patched it. We decided to put it in the plugins directory. We created a directory “controllers” and put a file in it called “controller_extensions.js”. In this file we put the code code to extend the Controler class (a jmvc framewrok class) with the show method. And to make it more javascriptie the method expects an array with keys for id (id of the element), view (the name of the view to be show) en data (containing the data used by the view):

You can use the the show method in the load method as follows:

There is one drawback, and that is that you explicitly have to provide the directory the view file is in. This is because JavaScriptMVC determines the path of the view based on the controller. And now the controller is Controller in stead monthcontroller.

In our next blog we will show you how this made testing the load method way easier.

A quest for a full Ajax application (in 8 parts or so)

In my previous blog I came to the conclusion that we, developers, use too many development languages to get the job done. Having multiple languages causes overhead, mistakes and could force you to implement things more than once.

PART 2

Wouldn’t it be nice to have just one language in your development environment. Life would certainly be a lot easier. After some googling and some very nice (and concrete) suggestions of my colleagues, I came up with the following software stack, which is mainly based around javascript.

CouchDB for storage
http://couchdb.apache.org/

CouchDB is document based schema free database.  A document is basically a JSON object. Each document can have it’s own properties. So you can add or remove properties (of a single document) without update scripts to add or remove columns. CouchDB comes with a RESTful JSON api which integrates seamlessly with HTTP clients. Querying(map/reduce) and validation are done with javascript. An advantage is that these validation methods can also be reused in other javascript supporting layers.

The architecture of CouchDB allows for easy replication and scalability.

NodeJS
http://nodejs.org/

The goal of NodeJS is to provide an easy way to build scalable network programs. NodeJS is based on googles V8 javascript engine. The core principal of NodeJS is to do all I/O non blocking, so more calls can be served with fewer threads. This way the through put isn’t limited by the number of threads allowed to spawn, but by the resources of the computer(CPU, memory, disk or network I/O).

In combination with Express(http://expressjs.com/) this makes our server-side application tier. This server layer probably won’t become that big since we are trying to push as much as we can to the client machine.

jQuery
http://jquery.com/

I think jQuery is pretty well known. So I’m won’t dig in to deep on what it does. More interesting is that I also took a look at Closure(http://code.google.com/closure/). Compared to jQuery, Closure is more of Javascript SDK with AWT. Unfortunately you have to move the earth to add some simple behavior to your page. The nice fluent interface of jQuery simply blows Closure away in that area. Closure did help me to realize that TDD is more necessary than ever.

Jasmine
http://github.com/pivotal/jasmine#readme

Jasmine is very nice test framework for javascript. It has build in support for asserts and mocking and it is easily extensible. Jasmine test are written in a BDD style(Behaviour driven).

Javascript

As you may have noticed they al bear one thing in common…javascript. This certainly helps reducing the software stack.

Prefetching static noise

Another choice which might not be so obvious, is to render the html from at the client side with the javascript. This means we don’t require a template engine to render the html. And the back-end only needs to send data after the initial load and thus minimizing network bandwidth.

My brave new world

I think some small notes are required on the build file.  CouchApp loads your application in to CouchDB by convention. With my current understanding an experience of CouchDB and CouchApp this should be enough for “building” your database.

So what other build files are required javascript doesn’t compile and jasmine has a test runner. So I guess we only need some scripts(shell or other) to tie it together.

The first five rows are all javascript, JSON, a subset of javascript, or javascript enabled. This is a huge reduction of the language stack.

Will it blend?

It all looks nice on paper, but will it work well together. There is only one way to find out. Put it to the test by making a nice application. I will blog on each part and present my final conclusions by building a sample application.  The next blog will handle writing a plain javascript loader. which prefetches all the static data of the application.

By the way: As it happens a other colleague of mine Jeroen van Menen took a look at iPhone apps. He came up with jQTouch and PhoneGap. jQTouch is a javascript/css3 based library and PhoneGap compiles a iPhone application out of “your web site/application”.  This would blend perfectly with  the suggested stack.

A quest for a full Ajax application (in 8 parts or so)

PART 1

Here I’am a software developer with mainly server-side development skills. I did my share of Java, C# and a bit of Ruby. All very nice software development environments, but they all fail in scalability(cpu and bandwidth) and ceremony(development overhead). Ruby does it slightly better considering development overhead, but still the stack seems off. Did you ever count all the different program languages you use when writing a web application.

You might even throw in some testing stuff like Fitness or cucumber. This is quite a big stack, isn’t it. Why is this an issue?
Well first of all did you ever used a < in your code or ever wondered about the numerous ways to escape a character in a string? Pretty often a different language on your software stack is bugging you.

And second and probably more important. As a software engineer I like to solve my problems only once.
If I would like to validate my objects I’d write some validation in my business tier. I would be nice to have the same validation also available in the web front-end(and all other types of front-end). If I’m lucky I can generate some javascript and use that, but if it get’s to complex I have to do some custom plumbing. You could use the validation in you business tier on the server, but this would mean some form of lousy validation on form post backs or continuously wacking your server with stupid validation requests, making sure you abuse CPU, bandwidth, memory and the patience of your users. Most of my application do all the easy validations with javascript on the front-end and the complex stuff on the server, It might be practical, but in the end it is a half hearted solution.

If you also would like to ensure the integrity of your data storage, because your users/admins keep poking around in the database. You would probably end up writing some sort of stored procedure, trigger or other hook to make the database validation dance the way you desire. Personally I end up with a disclosure clause in the contract stating

“Thou shall not temper with the database”

I feel ashamed for being a software engineer…. We should be able to do better than this. This is my first goal keeping applications DRY(Don’t Repeat Yourself) and simple by finding a language/software stack better fit for writing web applications.

The next blog will give a first glance of the new software stack

Op dinsdag 9 en woensdag 10 maart vond de eerste workshop Test-Driven Development plaats in ons cursus lokaal in De Meern.

Dag 1

Na een uurtje introductie en theorie was het tijd om aan de slag te gaan, het is immers een workshop en TDD leer je alleen maar door het ook daadwerkelijk te doen. Elke cursist had dan ook een computer tot zijn beschikking met daarop geïnstalleerd Visual Studio 2008 en Resharper. Hiervan werd gretig gebruik gemaakt om mij te volgen terwijl ik de eerste test schreef voor wat na twee dagen zou uitmonden in een eenvoudig cursus registratie systeem.

Vooral het feit dat ik Test-First werkte, eerst een test schrijven en dan pas de daadwerkelijke implementatie, was voor de cursisten toch wel een redelijke “mind-shift”. De cursisten kregen dan ook ruimschoots de tijd om daar middels diverse oefeningen ervaring mee op te doen. Nadat de cursisten de ochtend hadden besteed aan het (uit)bouwen van de business logica laag van ons registratie systeem, werd het aan het begin van de middag tijd om aandacht te besteden aan diverse design/test patterns. Maar eerst even lunchen en een frisse neus halen.

Patterns die ’s middag aan de orde kwamen waren o.a. dependency injection, inheritance en het gebruik van factories. Deze patterns hebben we vervolgens toegepast bij het testbaar houden van onze business logica en de provider laag (later op de middag). Aan het eind van dag 1 hadden we volledig Test-Driven de business logica laag gecreëerd en een deel van de provider (database) laag.

Dag 2

Vandaag begonnen de cursisten met een oefening in het onderkennen van testgevallen voor nieuwe eisen aan onze business logica. Vervolgens gingen de zij middels pair programming aan de slag met het coderen van de tests en het schrijven van de implementatie om deze tests te laten slagen. Weer een stukje oefening in 1 van de meest belangrijke TDD mantra’s “Red, Green, Refactor”. Het tweede deel van de ochtend werd vervolgens besteed aan het verder uitwerken van de provider en database laag. En prima gelegenheid om te laten zien en te ontdekken hoe interfaces, factories, mocks en stubs kunnen helpen voorkomen dat tests afhankelijk worden van de data in je database.

Na de lunch was het tijd voor de laatste laag in onze applicatie, het user interface. Hierbij begonnen we met een redelijk ontestbare web pagina (met code behind) implementatie. Middels WatiN borgden we het gedrag waarna we stapje voor stapje de code “achter het scherm” konden gaan aanpassen conform het MVP pattern. Door het toepassen van dit pattern werd onze user interface code ook testbaar middels unit tests, wat ons in staat stelde gecontroleerd aanpassingen te kunnen doorvoeren aan de UI logica. Met deze laatste stap ronde we de implementatie van ons cursus registratie systeem af.

In het tweede deel van de middag zijn we nog kort ingegaan op functioneel testen. Ook hebben we gesproken hoe al dit nou te borgen in je ontwikkel process. Continues integration is hierbij toch wel de spil waar alles om draait. En natuurlijk die ene vraag: Ga je dit morgen toepassen in je werkzaamheden en…. waarom niet.

Gezien de enthousisate reacties van de cursisten en het plezier dat ik ook zelf heb beleefd aan het delen van mijn kennis, krijgt deze workshop van mij het stempel: Zeer geslaagd!

Jeroen van Menen
Trainer TDD workshop

Agile is “hot”. Agile projecten beloven sneller software te leveren, die na elke iteratie onmiddellijk in productie kan. Daarnaast zou de software beter moeten zijn. Dus sneller en beter, … daar moeten de klanten toch wel tevreden mee zijn? Business managers zijn tegenwoordig ook meer “aware” en vragen soms letterlijk aan hun ICT-afdeling om een meer “agile” aanpak. Toch lossen agile projecten in de praktijk vaak deze beloftes niet in.

Het één op één toepassen van de “regels” van bijvoorbeeld Scrum blijkt vaak onvoldoende. Het goed begrijpen van de principes van agile software development kan al een hoop ellende voorkomen. Theoretische kennis (opgedaan in een eenmalige cursus al dan niet met certificering) en het dogmatisch toepassen van de agile procedures en “regeltjes” alleen is onvoldoende garantie voor succes. Elk project kan weliswaar putten uit dezelfde pot met agile methoden, technieken en tools, maar wat als de ingezette set in de context van een specifiek project onvoldoende blijken te werken?

De agilisten onder ons zullen zeggen: “Daar hebben we toch de retrospective voor?” Inderdaad, maar het is dan wel de kunst om de werkwijze zodanig aan te passen, dat het wel gaat werken voor het project. Hiervoor is het nodig om echte agile ervaring in het project in te brengen, zeker als agile nieuw is.

Het is ook zeer belangrijk om de discipline vast te houden. Wat we in de praktijk regelmatig tegenkomen, is dat van principiële keuzes, zoals een gezamenlijke sprint planning, TDD (test driven development), refactoring of pairing gedurende het project wordt afgestapt. Meestal wordt dit ingegeven door een korte termijn doelstelling van de project manager: tijdswinst. Wat daarmee vaak wordt opgeofferd is kwaliteit en dus ook … tijd. Immers de op korte termijn “gewonnen” tijd wordt later in veelvoud weer ingeleverd door meer bug fixing, testwerk, etcetera.

Verder is het belangrijk om de juiste focus te houden op het doel: het opleveren van werkende en voor de klant waardevolle software. Het proces is hieraan ondergeschikt en slechts een middel om op effectieve wijze de software op te leveren. Wat we vaak tegenkomen is het halsstarrig vasthouden aan templates en werkafspraken, terwijl die voor het betreffende team onvoldoende blijken te werken. Een goede agile coach zal hier en daar het team moeten masseren. Uiteindelijk gaat het om het handhaven van de agile principes en is de invulling – het proces – flexibel. Stand-up meetings en retrospectives zijn hierbij uitermate geschikte momenten om het proces met het gehele team tegen het licht te houden.

Dit drieluik van whitepapers gaat in om het aspect kwaliteit binnen agile sofware development. Hoe kunnen we ervoor zorgen dat de sofware, die een agile project elke iteratie opnieuw oplevert, inderdaad van hoge kwaliteit is. Immers, pas dan heeft de business lead (product owner in Scrum terminologie) werkelijk de keuze om na elke iteratie in productie te gaan met de opgeleverde software.

Een simpele, algemene definitie van kwaliteit is “de mate waarin het geleverde aan de verwachtingen van de klant voldoet”. Volgens ISO 8402 is kwaliteit: het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgestelde of vanzelfsprekende behoeften. De auteur Joseph Juran beschrijft kwaliteit als “fitness for use” en Prince2 hanteert de definitie “fitness for purpose” of “conforms to requirements”.

“Fitness for purpose” kan worden gesplitst in:

• “Building the right thing”
• “Building the thing right”

In de eerste plaats moet je de juiste requirements ontwikkelen (“building the right thing”), en deze moet je op de juiste wijze implementeren (“buidling the thing right”).

Binnen Linkit projects is “fitness for purpose” alleen niet voldoende. Het is mooi, dat de software nu precies doet wat de klant ervan verwacht. Maar wat als de verwachtingen van de klant wijzigen, bijvoorbeeld als gevolg van veranderingen in markt? Iedereen kent de uitspraak “resultaten behaald in het verleden bieden geen garantie voor de toekomst”. Met kwaliteit is dit net zo: “kwaliteit in het heden is geen garantie voor kwaliteit in de toekomst”. Om software van blijvende waarde te laten zijn voor de klant, dient de software mee te kunnen bewegen met de eisen en wensen van de klant. En dan wel in het tempo van de klant! Dit houdt in, dat we naast “fitness for use” ook “fitness for change” als een belangrijke peiler van kwaliteit zien.

In de eerste whitepaper gaan we verder in op het kwaliteitsaspect “building the right thing”: White paper – Kwaliteit in Agile – Building the right thing

De volgende twee whitepapers zullen ingaan op respectievelijk “building the thing right” en “fitness for change”.