Web application development workflow with Node.js

Context

The aim of the article is to describe a good workflow to use when developing web applications. I always read advice on good workflow practices but they are never aggregated together, that’s why I do it right now.

UI Driven Development

We are going to follow a Behavior Driven Development style. Moreover we are making a web application, so we decide to focus on user: we will start by writing code for the UI. Then for UI and backend, we will write our specs/tests first.

Technos

As technology we are going to use :

• Node.js and its framework Expess.JS because of their popularity and to get more familiar with it.
• The language is Coffeescript for its readability.
• Backbone is the UI framework.
• Mongoose is the ODM.
• Git is the version control system.
• Jasmine is the BDD framework for UI and Vows is the BDD Framework for backend.

Use case

The application on which I will apply the workflow is Ponyo, a simple app that actually does nothing apart of allowing to create and browse “categories”. To illustrate the workflow we are going to add a new feature : allow category deletion.

Category list

Category display

Workflow

Here are all steps we need to do proper developments. Of course most of the time pressure push us to do shortcuts, but it is good to keep the good way in mind. Moreover this complete workflow could help to think about what could be optimized/automatized:

1. Make a branch
2. Write UI specs + commit
3. Write UI specs code + commit
4. Write UI code + commit
5. Write backend resource specs + commit
6. Write backend resource tests + commit
7. Write backend resource code + commit
8. Run all tests
9. Test your app manually
10. Rebase branch
11. Merge branch + push
12. Refactor if needed

Details

1. Make a branch

First of all, don’t bother other programmers right now with our commits, so let’s create a branch called feature-delete-category.

With Git

    git branch feature-delete-category
    git checkout feature-delete-category

2. Write UI Specs

We are doing UI Driven Development, so first write client side code specs. Then, check with your browser (here the URL is http://localhost:3000/tests/) that the Jasmine entries fail.

With Jasmine

describe 'Category deletion', ->
  it 'When I display newly created category', ->
      expect(false).toBeTruthy()
  it 'And I click on delete category button from a category page', ->
      expect(false).toBeTruthy()
  it 'Then it brings me back to category list', ->
      expect(false).toBeTruthy()
  it 'And deleted activity is no more in the list', ->
      expect(false).toBeTruthy()

With Git, commit

    git commit tests/categories.coffee -m "Add specs for category deletion."

3. Write UI specs code

Now that you know what you want to do, you can write corresponding tests and checks that they fail.

With Jasmine

describe 'Category deletion', ->
it 'When I display newly created category', ->
    runs ->
      $("#category-jasmine").click()
    waits(500) # Waits to be sure that everything is done before testing
it 'And I click on delete category button from a category page', ->
    runs ->
      $("#delete-category-button").click()
    waits(500) # Waits to be sure that everything is done before testing
it 'Then it brings me back to category list', ->
    runs ->
      expect($("#category-list").length).not.toEqual 0
it 'And deleted activity is no more in the list', ->
    runs ->
      expect($("#category-jamsine").length).toEqual 0

With Git, commit

    git commit tests/categories.coffee -m "Add tests for category deletion."

4. Write UI code

Now we are going to write the UI code, it is needed to know what we expect from server. We add a button to the template displaying a category, then we code the button behavior. After that we check that our tests still fail (backend does not support request for deletion).  Finally we commit.

Modify the template with Eco

<p>
  <a id="delete-category-button" href="#home">
    Delete category<br />
  </a>
</p>

Write behavior with Backbone

categoryViewTemplate = require('../templates/category_view')
Category = require('../models/category').Category

class exports.CategoryView extends Backbone.View
  id: 'category-view'

  constructor: ->
    super()

 render: (category) ->
   $("#nav-content").html null
   $.get "/categories/#{category}/", (data) =>
     $("#nav-content").html categoryViewTemplate(category: data)
     @model = new Category data
     @deleteButton = $("#delete-category-button")
     @deleteButton.click(@onDeleteButtonClicked)

 onDeleteButtonClicked : (event) =>
   event.preventDefault()
   @model.destroy
     success: ->
       app.routers.main.navigate("home", true)
     error: ->
       alert "An error occured, category was probably not deleted."
       app.routers.main.navigate("home", true)

With Git, commit

    git commit public/ -m "Add deletion button to UI"

5. Write backend resources specs

Now we know that we need  a resource to delete category, so let’s write our category deletion resource specs and commit.

With Vows

.addBatch
  'DELETE /categories/category-02/':
    topic: () ->
      apiTest.del 'categories/category-02/', @callback

    'response should be with a 200 OK': (error, response, body) ->
      assert.ok false
    'GET /categories/category-02/':
      topic: () ->
        apiTest.get 'categories/category-02/', @callback
      'response should be with a 404 Not Found': (error, response, body) ->
        assert.ok false
    'DELETE /categories/category-02/':
      topic: () ->
        apiTest.del 'categories/category-02/', @callback
      'response should be with a 404 Not Found': (error, response, body) ->
        assert.ok false

With Git

 git commit test/ -m "Add backend resources specs"

6. Write backend resource tests

Now we write our test code, we just check that returned HTTP code are expected ones and that once category is deleted, it cannot be reached anymore. We commit.

With Vows

.addBatch
  'DELETE /categories/category-02/':
    topic: () ->
      apiTest.del 'categories/category-02/', @callback

    'response should be with a 200 OK': assertStatus 200
    'GET /categories/category-02/':
      topic: () ->
        apiTest.get 'categories/category-02/', @callback
      'response should be with a 404 Not Found': assertStatus 404
    'DELETE /categories/category-02/':
      topic: () ->
        apiTest.del 'categories/category-02/', @callback
      'response should be with a 404 Not Found': assertStatus 404

With Git

 git commit test/ -m "Add backend resources specs code"

7. Write backend resource code

Now we write code : we add a new route that will link to a new resource dedicated to category deletion. We commit.

With Express

  app.del "/categories/:category/", routers.deleteCategory

With Express and Mongoose

exports.deleteCategory = (req, res) ->
  categoryProvider = new CategoryProvider

  categoryProvider.getCategory req.params.category, (err, docs) ->
    if err
      console.error(err.stack)
      res.json 'An error occured', 500
    else if docs.length > 0
      docs[0].remove (err) ->
        if err
          console.error(err.stack)
          res.json 'An error occured', 500
        else
          return res.json  success: true
    else
      res.json 'I dont have that', 404

With Git

 git commit test/ -m "Add category deletion resource"

8. Run all tests

We run our backend tests and our UI tests through browser and we are glad to see they all work.

With Vows

vows --spec test/resources.coffee

9. Test your app manually

Once you launch all your tests, test your application as a normal user. BDD is great but it will never replace a manual test, we often miss something that is not revealed by our tests.

Category deletion is possible

10. Rebase branch

We want to add our commits like we did them from last version of master branch, so we use rebase command.

With Git

git rebase master

11. Merge branch

Then we can merge our features to the master trunk. A push to master branch will validate that work is done !

With Git

git checkout master
git merge feature-delete-category
git push
git branch -d feature-delete-category

12. Refactor if needed

UI Driven development has the nice advantage to not let you develop unuseful resources but it does not let you think as good as possible the way to develop your backend. So you will probably need some refactoring. Fortunately, with your tests refactoring will be easier and safer. Moreover patterns you see when you develop UI first push you to think about refactoring that match better to your needs.

NB: Feel free to comment and criticize this article so I could improve it and correct what is wrong.

The Lean Startup, revue de livre

Voilà un livre que j’étais très enthousiaste de recevoir. En effet, en ce moment que ce soit en bien ou en mal, on entend parler de la méthode Lean un peu partout. Dans le monde des startups informatiques ce thème revient même très souvent. Mais qu’a cette méthode de particulier ? Elle repose sur les principes suivant : il faut éliminer toute action inutile, chaque réalisation doit prouver son efficacité et permettre de progresser vers le succès (validation par l’apprentissage) et il faut se poser régulièrement la question de changer d’orientation ou de persévérer. Voilà en très résumé ce que raconte ce livre de 300 pages. Oui 300 pages pour expliquer ça c’est un peu beaucoup, l’auteur aurait pu faire plus concis. Heureusement il n’y a pas que du blabla, Eric Ries, l’auteur, nous expose beaucoup d’exemples concrets (expérience personnelle ou cas rencontrés en tant que consultant). Ce qui a tout de même pour avantage de rendre le livre assez convaincant.

Revenons à la méthode Lean. Pour que les choses soient claires, Eric Ries, ne recherche que la croissance maximum. On est donc pas dans le “Why grow ?” de 37signals. Pour cela il faut commencer de petit avec un produit minimum (MVP, Minimum Viable Product) afin d’avoir au plus vite des retours utilisateurs . On commence ainsi au plus tôt l’apprentissage. Comme pour lui les utilisateurs ne savent pas toujours ce qu’ils veulent, il ne va pas se contenter de leur poser des question, il va aussi analyser leurs réactions. En créant des indicateurs pertinents (évolution du taux de conversion par exemple) et en mettant de côté les indicateurs vantards (nombre de visites par exemple pour un site de produit payant) il va valider ou non l’ajout d’une feature, la modification d’un design, etc… Il conduit clairement des expérimentations pour définir la marche à suivre et n’hésite pas à revenir en arrière si ça n’a pas fonctionné. Pour que cela soit possible, il préconise de n’avancer que par petits pas et de travailler en petite équipe. Ainsi le retour en arrière est moins douloureux s’il doit avoir lieu. Après ça il continue sa progression jusqu’à ce que ça commence à coincer (croissance ralentie). Là il se pose la question, doit on continuer à améliorer l’existant ou doit on changer de positionnement ? Là il compte plus ou moins sur son instinct et ses résultats précédents pour faire son choix, puis il recommence le cycle.

NB : Pour les logiciels cloud, il prône la méthode du déploiement continu. Chaque modification passe en production rapidement. Il ne juge pas ça risqué car si un bug est mis en prod (malgré les tests automatiques) il sera facilement identifiable et corrigé rapidement car on peut relivrer tout de suite après.

Le concept n’est pas idiot même si je trouve ça gênant de prendre ses utilisateurs pour des rats de laboratoires. Autre point qui me pose problème, c’est qu’il prétend que c’est comme cela qu’on obtient de l’innovation. Alors que pour ma part, je ne trouve pas ce concept vraiment compatible avec l’innovation. Innover c’est parfois changer les habitudes et je ne suis pas sûr que les réalisations impliquant du changement soient “validées” par sa méthode. A l’inverse le bon côté de ce qu’il propose est que ça permet de diminuer les risques d’échec puisqu’on est sûr de développer ce que les gens veulent.

Ce livre présente aussi quelques trucs et astuces, comme la technique des 5 pourquoi. C’est un principe qui vient de Toyota (oui j’oubliais la plupart des principes Lean prennent leur source dans les manufactures Toyota qui avait pour principe de faire des voitures d’un seul coup et non par étapes. Cela leur permettait de mieux gérer leur stock de pièces et de se rendre compte plus vite s’il y avait un problème dans la chaine de production). Les 5 pourquoi qui consiste à analyser les problèmes en profondeur plutôt que de les attribuer à leur cause direct. Pour cela on réunit toutes les personnes impliquées depuis le début jusqu’à la fin de la chaine, management compris et on se pose 5 fois la question pourquoi. Ex : Jhon déploie une feature buggé. Pourquoi la feature est buggée ? parce que Jhon l’a déployée. Pourquoi Jhon a pu déployer une feature buggée ? parcequ’il n’avait pas fait les bons tests. Pourquoi n’a-t-il pas fait les bons tests ? Parcequ’il n’avait pas les bons outils, etc…

En résumé, c’est un livre très intéressant à lire (ok un peu chiant par moment) qui propose une méthode qui se tient avec comme bémol le côté expérimentation sur les utilisateurs.

Je me permettrai aussi une remarque : le principe de travailler avec des petites tâches et en permanence peut être assez épuisant pour les employés. En effet il n’y a plus jamais de pause comme on peut en trouver à la fin des projets ni même d’objectif conséquent à atteindre. A mon avis, il faut donc penser à aménager l’organisation du travail en conséquence : congés forcés, pas d’heures sup et petites victoires régulières me semblent obligatoires pour éviter manque de créativité, burnout ou lassement prématuré.

Start Small, Stay Small

Start Small, Stay Small,  un titre qui s’annonce bien, qui fleure bon le 37signals. Ca se confirme avec la couverture toute noire et son titre en blanc : on croirait presqu’un remake de Getting Real. Alors oui il y a des similitudes : notamment sur l’objectif qui est de vous apprendre à monter un business en vous passant d’investisseur, de “bootstrapper”. Par contre le but ici n’est pas de monter une boite conséquente, ni même d’embaucher quelqu’un (en fait rien n’empêche de le faire mais là le bouquin n’offre plus de conseils pour cela). L’idée cette fois consiste à monter une ou plusieurs micro entreprises vendeuses de logiciels et d’en gagner sa vie.

Là ou c’est intéressant c’est que l’auteur fournit plein de trucs pratiques pour arriver à ses fins. Un exemple : il fait de la publicité pour un produit qui n’existe pas. La pub renvoie sur une page de lancement où on peut laisser son mail. En fonction du nombre de gens qui laisse leur adresse et du nombre de visites, il en déduit si le logiciel en vaut la peine.

Là ou c’est trompeur c’est que ce guide pour développeur parle essentiellement de marketing. L’auteur juge qu’il n’a rien à apprendre à ses lecteurs dans le domaine du développement, donc il ne se concentre pratiquement que sur les moyens de ramener des visiteurs. Ca se tient. Il en résulte de bons tuyaux, il est assez convaincant sur la nécessité des newsletters par exemple mais à un moment ça devient exagéré. Par exemple, avec son blog et sa newsletter, il va cumuler des petites techniques pour attirer du monde : envoyer des contenus réguliers, faire intervenir des experts… Présenter comme il le présente ça donne l’impression qu’il essaye de gratter partout, alors qu’en prenant un peu de recul, il fait juste quelquechose de naturel : apporter des informations autour de son produit afin que ses utilisateurs puissent réagir et apprendre des nouvelles choses, un peu le “Build an audience” de Rework. C’est un peu dommage que ce soit fait dans cet état d’esprit.

Là ou c’est dérangeant c’est que pour couronner le tout, l’auteur fait l’éloge des Virtual Assistants ou VA. C’est quoi ? me direz vous. Un VA est simplement un type, qui n’a rien de virtuel au passage, à l’autre bout de la planète qui accepte de faire des tâches ingrates pour pas cher, comme saisir un listing par exemple. D’un point de vue totalement pragmatique c’est assez intelligent : pour peu d’argent on économise de nombreuses heures de travail. Mais éthiquement, on est à peu près à 20 000 lieux sous les mers.

Bref ce livre comporte pleins d’astuces utiles, mais son obsession marketale en fond un tout assez triste. A manipuler avec précaution.

Laos semaine 3 : Luang Prabang, Vang Vieng, Vientiane

Après 6h de bateau, j’arrive à Luang Prabang. C’est la ville la plus touristique du Laos, elle fait partie du patrimoine mondial de l’Unesco. Effectivement l’endroit est superbe. J’ai décidé d’y rester 6 jours car j’en ai un peu marre de courir partout.

Il y a beaucoup de marchés à Luang Prabang, notamment pour la nourriture. C’est l’occasion pour moi de vous parler de leurs bananes. Ici les bananes sont toutes petites. On en voit partout dans le pays, on finit par vraiment les associer au Laos. En plus elles sont très pratiques pour grignoter lorsqu’on marche.

Le coucher de soleil sur le Mekong, on ne s’en lasse pas. Plaisir quotidien auquel je ne savais dérogé.

Le Laos a de très belles cascades, ici celle de Tad Sae. Evidemment l’endroit est blindé de touristes. Mais une fois quelques mètres parcourus, on se retrouve seul pris entre l’eau turquoise et la jungle.

La belle rue où se situait ma guesthouse.

Le pays est très jeune, il y a des enfants partout. Ils sont assez suprenants de par leur calme, je n’en ai jamais vu un faire une colère. Certains travaillent et ont des allures d’adultes. Fréquemment, quand ils voient un falang (un étranger) ils accourent en criant Sabaidee (bonjour). Ils veulent souvent jouer et parfois réclament de l’argent. Pas facile de savoir quel comportement adopté. Pour ma part je passais mon chemin en les saluant.

Luang Prabang c’est aussi la ville des temples. Il y en a un paquet. A l’intérieur : un bouda géant et des offrandes.

Le marché des artisans est composé de stands comme celui ci. On en voit à perte de vue. Ils se ressemblent tous. et n’arrivent que le soir quand la nuit tombe. Mes pulsions consommatrices prennent le dessus : j’ai envie de tout acheter.

Les moines et leurs tuniques oranges. Ici nous sommes à Vang Vieng, j’ai pris le chemin du retour, mon avion est prévu deux jours plus tard.

Après Vang Vieng retour à Vientiane où mon dernier repas sera un Hot Pot, espèce de soupe de nouilles en forme de fondue. C’est très bon. Je me suis bien adapté au rythme laotien et n’ai plus vraiment envie de rentrer en France, malheureusement tout a une fin.

Laos semaine 2 : Phonsavan, Sam Neua, Vieng Xai, Nong Khiaw

Durant cette semaine j’ai beaucoup pris le bus, c’est un très bon moyen de transport pour voyager : on découvre le paysage et on côtoie les laotiens tout du long. Pas plus de trois touristes par bus dans ce coin du pays : direction le nord est avec pour objectif Vieng Xai.

C’est la première équipe qui m’accompagnera dans mon voyage, trois d’entre eux vomiront, nous serons même obliger de nous arrêter près d’une source pour laver le bus. Nous sommes dans un mini-van, les fauteuils sont en cuir, c’est du grand luxe. Par contre on y rentre le maximum de personne, nous étions 12.

La plaine des jarres ou l’Ile de Pâques du Laos, personne ne sait pourquoi ces jarres sont là.  On suppose simplement que ce sont des tombes mais on a trouvé aucune explication sur leur provenance, elles pèsent des tonnes et à cette époque les hommes n’était pas censés connaître de techniques pour les déplacer ni même les fabriquer. Cette visite est l’occasion pour moi de parler avec un laotien (mon guide) qui parle anglais et qui est récolte le riz le week-end. J’en apprends donc un peu plus sur la culture du riz. Ici l’agriculture bio règne en maitre,  ils n’ont pas encore de machines et se méfient des pesticides qui rendent le sol incultivable en à peine 3 ans.

C’est dans ces marmites qu’on fait cuire les nouilles. Là bas la soupe de nouilles, le phô, est le plat le plus courant. On en mange à n’importe quelle heure, même au petit déjeuner. C’est souvent assez bon même si la viande laisser à désirer. Les agréments, herbes et piments, sont servis à côté. J’en ai tellement mangé que j’ai oublié d’en prendre en photo, snif.

Mémorial de la guerre du Vietnam. Plus loin il y avait un mémorial de la guerre du Laos. Il faut savoir qu’ici les américains ont vidé l’équivalent d’un bombardier toutes les 8 minutes pendant 9 ans. Et en plus ils appelaient ça la guerre secrète.

Au Laos, il est courant de voir des animaux sur la route : coqs, boeufs, chiens, etc. Les bus s’arrêtent toujours pour les laisser passer (tout en klaxonnant pour qu’ils pressent le pas).

Après beaucoup d’heures de bus, arrivée à Sam Neau. Ville assez triste mais pourvu d’un marché de nourriture assez intéressant. Ici on diffuse les messages de propagande au haut parleur. On est proche du Vietnam, mais on est pas très habitués à recevoir les touristes. Personne ne parle anglais et tout est écrit en Lao. Le matin il fait froid. L’endroit n’est pas plaisant mais je suis content d’être dans une ville authentique.

Non loin de Sam Neua, se trouve une petite ville nommée Vieng Xai. Ici il existe de nombreuses grottes aménagées dans lesquels les gens vivaient durant la guerre. Mais surtout l’endroit est magnifique, une fois le soleil venu. Malheureusement il n’arrive que tard dans l’après midi. Jusque là le ciel est gris et il fait très froid. Ici on ne comprend vraiment pas l’anglais. J’aurais aimé rester plusieurs jours mais je me rends compte que j’ai atteint ma limite. Je ne suis pas à l’aise car je n’arrive pas à me faire comprendre, le climat est trop rigoureux. Je décide de m’enfuir dès le lendemain.

J’ai un peu de regret avec le recul, j’aurais mieux fait d’acheter des vêtements sur place. L’endroit est vraiment agréable. Tant pis, j’ai quand même trouvé là bas trois touristes avec qui je passe la soirée. Nous dînons avec une vue sur un des lacs artificiels qui entourent la ville.

Je reviens à Sam Neua pour y rester une journée supplémentaire. Je ne ferai pas de photos ce jour là, j’ai besoin d’une pause, marre de trimbaler mon matériel partout. Le lendemain je prends le bus le plus fun de mon voyage. Tant mieux car j’en ai pour 12h. Le conducteur va très vite, il évite très bien les animaux, rend service à des tas de gens sur la route, met de la musique lao à fond durant le trajet. C’est vraiment folklorique. Il est aussi très sympa avec nous. Le voyage passe à toute vitesse. Il me laisse à Nong Khiaw, qui est située près d’une rivière encaissée entre deux montagnes, c’est superbe. Je reporte mes photos au lendemain, grave erreur, au matin nous sommes dans la brume et on ne voit plus rien des montagnes. Dommage, je prends mon bateau à 11h pour Luang Prabang où une semaine facile au milieu des touristes m’attend.