Je suis un fan des travaux de Simon Wardley à propos du cycle d’évolution des activités: d’une innovation émergent des projets spécifiques qui peuvent devenir des “produits” eux mêmes commodifiés par des services ou des projets open source. Ces commodités pouvant servir de base à de nouvelles innovations auparavant inimaginables… La boucle est bouclée.
Se servir de la technologie comme levier pour innover est l’une des choses qui me motive chaque jour dans mon métier. Nous (les informaticiens) vivons une époque formidable, j’ai aujourd’hui la chance de pouvoir pousser tout ça un peu plus loin à un nouveau poste…
Je rejoins le Groupe Sfeir en tant que Directeur Technique.
A Web Developers’ View of Play Framework 2.0: With Play, the Back button just works […] Play doesn’t fight HTTP or the browser […] As a Java EE developer, PHP and Rails developers have been laughing at us for years
La tête dans les nuages Les mains dans le cambouis Les pieds sur la prod
La tête dans les nuages
Pas parce qu’il s’intéresse au cloud, mais parce qu’il doit prendre de la hauteur et du recul pour analyser, synthétiser et savoir restituer des vues adaptés à chacun des acteurs d’un projet. Il est le garant d’une vision partagée et cohérente des objectifs métiers stratégiques jusqu’aux déploiement des composants logiques sur des serveurs physiques ou virtuels.
Les mains dans le cambouis
L’architecte qui ne code plus (pire n’a jamais codé) a vite fait de s’envoler dans les nuages et de perdre le contact avec la réalité. De la vue aérienne d’un projet il doit pouvoir zoomer sur un composant logique, sa conception et la ligne de code. Seul un astro-architecte qui ne quitte jamais les stratosphères de sa cellule architecture et méthode peut retenir des technologies comme EJB1/2 ou JSF, qui en pratique sont inutilisables. Une technologie ou une architecture peut avoir toutes les qualités que l’on voudra, si elle n’est pas comprise et adopté par les développeurs ça n’ira pas loin.
Les pieds sur la prod
Tan qu’il n’est pas entre les mains des utilisateurs un projet informatique ne produit aucune valeur. Et le passage obligé pour atteindre les utilisateurs c’est la prod. Vous suivez à la lettre les recommandations du site 12factors ? Super votre application est prête à être déployé dans le cloud. Dommage, ce qu’attend votre prod c’est un ear pour déployer sur webFear ! Pour que le succès d’une application soit complet travailler en étroite collaboration avec les gens de la prod (Devops) et aussi important que de leur faire avec le métier (les méthodes agiles)
Et chez vous il fait quoi l’architecte (logiciel bien sûr) ?
Lors du code retreat de ce week-end la 3eme itération avec piwai m’a permis de trouver une illustration simple et concrète de ce précepte. (PRO tip: le pair programming est un moyen pour fabriquer des développeurs 10 fois plus productif à partir de deux développeurs normaux)
Le kata classique d’une code retreat est le game of life, la spec tien en 4 règles:
Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Chaque itération dure 45min, en pratique il est difficile de finir dans ce temps, ce qui tombe bien car le but d’un kata n’est pas de finir mais d’expérimenter librement. Dans une approche TDD naïve on va commencer par implémenter un test permettant de valider la première règle, puis implémenter le code permettant qui permet de faire passer le test.
Mais TDD ne veut pas pire pas de conception, bien au contraire, la première question à se poser est qu’est qu’on doit tester?
Dans le cas du game of life on réalise très vite qu’on à besoin de stocker l’état des cellules dans 2 structures, une pour la génération actuelle, une autre pour la suivante. Si l’on démarre toujours la génération suivante par une structure vide que l’on va remplir en parcourant la structure actuelle il n’est pas nécessaire d’identifier les cellules à tuer: elles sont déjà toutes mortes dans la prochaine génération. Ce qui permet de ne pas se soucier de 2 règles sur 4.
Ainsi
Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Devient
All cell are dead in the next generation
Any live cell with two or three live neighbours lives on to the next generation.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
La complexité du problème a été divisée par deux…
En partant sur ces bases on a pu finir de manière relativement élégante en 30 min.
Le premier est bien référencé, correctement documenté et facile à mettre en oeuvre. Il fonctionne sur le serveur svn (très lent) ou à distance (très très très lent)
Mais globalement il ne marche pas dès que le repo svn est un peu complexe. (dans mon cas + 13000 révisions et déjà une migration depuis cvs!)
Le second ne sort pas en premier sur google, vous devrez compiler les sources, et la doc est bien cachée (en fait il n’y a que des exemples). Il ne fonctionne que sur le serveur svn.
Mais il est très rapide (moins de 5 min pour mon repo avec 13000 révisions) et permet simplement de définir des règles pour configurer la conversion des branches et tags. On peut même transformer un repo svn en n repo git en une seule passe.
Voici donc une mini doc pour utiliser le bon svn2git
Installer et compiler (sous ubuntu)
sudo apt-get install libsvn-dev libqt4-dev
git clone git://gitorious.org/svn2git/svn2git.git
cd svn2git
qmake
make
Vous devrier avoir un éxécutable: svn-all-fast-export
Créer un fichier auteurs
Git identifie les utilisateurs par leur email, svn par un identifiant, il faut donc créer un fichier de correspondance entre id svn et email, soit à la main soit de manière automatique
#!/usr/bin/env bash
authors=$(svn log -q | grep -e '^r' | awk 'BEGIN { FS = "|" } ; { print $2 }' | sort | uniq)
for author in ${authors}; do
echo "${author} = NAME ";
done
Créer un fichiers rules
svn2git permet de décrire dans un fichier rules la manière dont on va mapper la structure de répertoire de svn dans des repos et branches git. Pour bien faire les choses il faut connaitre la structure des répertoires svn et leur évolution depuis le début. svneverever vous sera bien utile.
