Tot nog toe was het probleem alleen: hoe maak ik mijn prototype beschikbaar voor mijn klanten? Systeembeheerders worden niet echt vrolijk als ze de webserver moeten inrichten voor rails applicaties.

Maar….. dan is er Heroku, een “Platform as a Service” speciaal voor rails applicaties. Hoe bruikbaar is dat?

Met “Platform as a service” heb ik altijd de angst dat je in je code al rekening moet houden met platform. Oftewel, als je voor een bepaalde PaaS kiest, dat zit je eraan vast. Maar Heroku is een verrassend elegante implementatie. Binnen 15 minuten had ik me geregistreerd, SSH keys aangemaakt, mijn applicatie neergezet en de database geconfigureerd. En bovenal, code aanpassingen waren niet nodig.

Zo doe je dat:
Stap 1. Maak een Rails applicatie.

Stap 2. Maak een GIT repository aan. Vanzelfsprekend is het nog handiger om dat te doen tijdens het ontwikkelen van de rails applicatie, maar anders gaat dat met drie kreten in een terminal window.
git init
git add .
git commit -m initial

Verder heb je nog een GitHub account en SSH keys nodig. Als je dat nog niet hebt dan staat hier beschreven hoe dat moet: http://help.github.com/mac-key-setup/ (Windows en Linux beschijvingen zijn er natuurlijk ook).

Stap 3. Zet alles op Heroku.
Eerst als nieuwe klant registreren bij Heroku. Dan een gem installeren:

>sudo gem install heroku


De SSH key bij heroku bekend maken:

>heroku keys:add


Create een omgeving in Heroku: >

> heroku create
Creating furious-sword-84.... done
Created http://furious-sword-84.heroku.com/ | git@heroku.com:furious-sword-84.git
Git remote heroku added


Heroku bedenkt prachtige krijgshaftige namen voor de applicatie, zoals hier “furious-sword-84″, de naam kan je natuurlijk aanpassen. Ik heb de naam laten staan en op http://furious-sword-84.heroku.com kan je nu mijn InsultMe applicatie vinden. InsultMe heeft overigens geen enkele serieuze bedoeling, het is slechts mijn versie van HelloWorld.

Nu de sources overbrengen naar Heroku:

>git push heroku master


De database tabellen aanmaken:

> heroku rake db:migrate


En nog wat initiele vulling voor de tabellen door middel van fixtures:

> heroku rake db:fixtures:load


Of de locale database overzetten naar de Heroku database:

> heroku db:push


Een database terughalen kan natuurlijk ook:

> heroku db:pull


That’s all!

Bekende key-factoren voor succesvolle “as a Service” producten zijn “eenvoud”, “prijs” met in ieder geval een gratis instapniveau en “Kwaliteit”. Heroku voldoet ruimschoots aan de “eenvoud” factor. Voor de “free” versie mag de database 5MB groot worden (dat zou wat meer mogen zijn) en krijg je de beschikking over 1 Dyno. De performance van die ene Dyno lijkt overeen te komen met de applicatie draaien onder WEBrick op mijn MacBook (ja, ook als ik het gebruik met een serieuzere applicatie dan InsultMe). Voor grotere applicaties is het eenvoudig om wat op-te-schalen. Ik heb me nooit verdiept in PaaS-pricing, maar de kosten hiervoor lijken me reëel en komen in de buurt van de MS-Azure prijzen (ik hoor het graag als dit niet zo is).
En over “Kwaliteit”: het moet werken, gewoon altijd. Ik heb nog niet meegemaakt dat mijn applicaties niet te benaderen waren. Ook hiervoor ben ik benieuwd naar ervaringen van anderen.

User stories gained popularity after realizing that developers had to start working with users throughout the project to understand their needs. It certainly works better than letting a developer discuss the needs with a user, which tends to end after a few minutes in a “Yes, I get it! No worries, know what you need”, followed by a near endless code-and-fix cycles.

So user stories are great, but who writes them? Hmmm, users probably. After all it’s their story. Question is “can users write user stories”? The answer is simple: it depends….

Certainly some users can write user stories. Sysadmins can, helpdesk and application support too. But the “real” users, can they write user stories? I don’t know about that. When you leave the writing of user stories in the hands of the users that can write user stories you may end up with “unbalanced systems” like the ones in the famous what-if-airplanes picture. After all, you don’t build a system just to do application support or system admin (unless that is your business). You build systems to increase “business value” or whatever greater purpose and for that you need the “real” users.

As stated before: “any user and developer should be able to read a user story and immediately understand it”. If it is that simple, it cannot be too hard to learn how to write a user story.

A user story consists of two parts:

-Just a few lines of text that describe the problem;

-A Test that serves as an example and that can be used to determine when a story is complete.

A simple template for this can be found here: cukes.info

All very simple, and I bet it is possible to make a training course with exercises were the stories and their tests just drip of the table….

Unfortunately, most systems we build nowadays are not that simple. Recently I explained user stories to a group of barristers who were asked to describe their new system. After the theoretical part it was time for some their first user story. Not some lab example a real life one.

Barrister: how do we start?

Me: just go over the things you do during the day and see where your new system system comes in

Barrister: I visit people with a legal document, hand it over, explain the implications and sometimes I give them advice or propose a solution. Then I make notes on their file. That’s it.

Me: Hmmm, that is too simple, there must be more…..

The discussion continued for quite some time and finally we found that the user story was about efficiency. In the morning they receive a pile of documents for that day, they order them by address, program their navigation system and they make their visits.

Or the cukes.info template:

In order to make as many visits as possible during a day

As a barrister

I want to receive an daily workload optimized for traveling time and in such a way that I spend the least possible time in programming my navigation system.

Barrister: not in a million years I would have come up with this user story! And how do I write a test for this? Is the navigation system part of the whole system? And what if there are traffic jams or rush hours should that be in there too? And what about different makes of navigation systems?

My conclusion: help your users in writing user stories and certainly help them in writing test scenario’s.