1. Finding a job as a developer

With Newebe and my last job, now I can tell that I have a decent portfolio. So, finding a job in an exciting company is a possibility. I can say I like to deal with technical problematics, so working on another project is a nice path. But It requires to come back in recruitment process, something I don’t like at all. Moreover it is a little bit the lottery and I am not sure to find people that trust the same principles as me.

2. Finding a job as a project manager

I have both an experience as a business analyst and developer and I work since 6 years. So it could have been a good idea to look for a promotion as a project manager. It would be a good carrier choice. On the opposite, being hired would be harder.

3. Finding a job in another field

With BeBurlesque, I met a lot of people from other fields : event organization, fashion, edition, press relation… To get hired in one of those would be really harder but not impossible. They have some interests and could offer a great new experience. Unfortunately they require a lot of energy and a lot of communication skills and I’m not sure that I feel enough passion to struggle to get in one of them.

4. Travelling

Toughest choice from far. I really enjoyed my trip in Laos and met a lot of travellers who explained me how they can travel for so long without having a lot of money. I have enough cash now to travel for several months very comfortably. By the way, when I was in Laos my health improved a lot : no more back problems, no more insomnia, no more skin problems, a better physic condition and overall, my moral rose from under the ground to the sky.
I could also do some coding stuff while traveling, so Newebe could be improved during that time and my dev skills stay up to date.
The bad part is that when I will come back, things won’t be easy. Whatever solution 1 would still be available.

5. Start a new company

This is also a good opportunity. First I am available. Second I have enough cash to not be paid during several months. Thanks to our unemployment insurance, I will have additional funds. This added to my own funds gives me the equivalent of 1 year and a half of a decent salary to survive until this company earned enough money to pay me.
The other good part is that I met two partners who wants to make something about self hosting through a startup. If you read this blog, you know how far I am concerned by the subject.
I am also still young (29) and have no children. So, if it fails I still could go to choice 1 or maybe choice 4.

As you understand I have a big opportunity to build something new about web and self-hosting. My last startup experience was hard emotionally, but I have very good memories too. So I think I want to have a litte more. And because when things sounds good, they should be listened, I will try this path, hoping it is the best one.

2011 from hey_rabbit on Vimeo.

> new Date(2012, 01, 03, 0, 0, 0, 0)
Thu, 02 Feb 2012 23:00:00 GMT

I finally find one solution, that I share here, hoping it will save time to people in the same case as me. To avoid this, the timezone must not be set on the date you work on but on the node process. In your “main” just add this at the beginning :

process.env.TZ = 'UTC'

Now you can use date like in any other programming environment.

Edit : Apparently it’s not a Node bug, it’s the way javascript works…

User features

• Send pictures to your contacts
• Synchronize with your contacts to get all their pictures since last month.
• Time zones are now handled properly, you can interact with people from all over the world without time problem.
• Better rendering for code snippet in micropost application.
• Display embedded youtube video in the preview column when post contains youtube links.
• Display a clear message when profile URL is not set correctly.
• Do not allow password shorter than 4 characters.
• When an object is selected (micropost, picture, activity…) its background changes.

Under the hood

• Now all backend modules have their BDD specifications.
• Refactoring : most of the communications with contacts are extracted in a special client, and activities are managed by the base handler.
• Improved logging.
• Add utils to manage date, file upload, and to make testing easier.
• Add pytz to dependecies.

https://github.com/downloads/gelnior/newebe/newebe-0.4.0.zip

https://github.com/gelnior/newebe

next version

For the next version, I will focus on the installation script. To be able to install Newebe with one command could really make adoption easier. Then I will work a little bit on security and try to allow user to mix pictures, posts and notes. But before that, I’m going to have a break. So don’t be surprised if the repo don’t move for the next weeks.

Picture application screenshot

Another good improvement is refactoring. I did a lot of “behind the scene” work. Server code is cleaner with better logic separation and has better test coverage. Client side had some improvements such as some minor features and debugs but no deep refactoring and testing.

What is a lot more interesting than features, is that… The community grows ! We have now 10 watchers on Github (champagne!). Robin, a great canadian software engineer, help us by testing and providing  security advice on Newebe. Moreover a small company use it in a private network as a communication tool. Another cool fact : my post about the “first year of free software” had many good feedbacks when I posted it on Linuxfr two months ago.

I expect to make a new version of Newebe for the end of the month. Things go slowly but they go !

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.

git branch -d

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é.

]]> http://gelnior.wordpress.com/2011/12/15/the-lean-startup-revue-de-livre/feed/ 0 Gelnior book_book http://gelnior.wordpress.com/2011/12/13/start-small-stay-small/ http://gelnior.wordpress.com/2011/12/13/start-small-stay-small/#comments Tue, 13 Dec 2011 10:30:28 +0000 Gelnior http://gelnior.wordpress.com/?p=1121 ]]> 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.

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.

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.