Category Archives: architecture

Des tweets et des plus n°14 – Agile subway map

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 pratique “Définition de prêt pour une story”: Une story non prête n’est pas acceptée dans un sprint qui commence

On Naming:  The challenge is that the coder is holding two conversations at once, one with the compiler/interpreter and one with the future maintainer

It’s About The Hashbangs: Directly addressable content is what makes web apps better than desktop apps. It’s certainly not the UIs.

 

L’architecte

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) ?

Le meilleur code

est celui dont on peut se passer

J’aime bien cette citation

“Le meilleur code est celui dont on peut se passer.”
Le type qui va maintenir votre code

C’est la clé d’une réalité difficile à accepter et encore plus à prouver : un bon développeur peut être 100 fois plus productif qu’un mauvais.

Dans l’évolution d’un programmer python:

  • Le débutant écrit une implémentation naïve,
  • Celui qui connait le langage résout le problème en une ligne simple,
  • L’expert utilise tout simplement une librairie déjà existante.

Mais il manque un type de développeur: celui qui trouve la solution pour ne pas avoir à écrire ce code.

Illustration avec le Kata du game of life

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:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. 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

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Devient
  1. All cell are dead in the next generation
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. 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.

De svn à git

Comment migrer un repo svn vers git ? En utilisant svn2git bien sûr!

Mais attention il y a une grosse feinte, le conseil qui suit peut faire gagner des journées entières.

Il y a svn2git et svn2git

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.

Go

Plus qu’à lancer la commande suivante:
./svn-all-fast-export --identity-map authors  --rules rules --stats pathToYourSvnRepo
En cas d’erreur il est possible de mettre à jour le fichier rules et de repartir de là où on en était.
Bon Git !

Let’s GIT it started

“Pour apprendre  il faut pratiquer, pour comprendre il faut expliquer” ça ne doit pas être la citation exacte mais l’idée est là et s’applique parfaitement à GIT. Il n’y a qu’à voir le nombre de blog de geek qui éprouve l’envie irrésistible de faire un billet sur ce sujet. Je n’échappe pas à la règle, après quelques mois de pratique de ce DVCS.

Même si certain recommande de tout oublier de svn avant de se mettre à git je préfère pour ma part démarrer par une comparaison des concepts

Les concepts de SVN

Un repository svn ne gère que 3 types d’objets:

  • répertoire
  • fichier (ou plutôt la différence d’une version à une autre)
  • revision

Les revisions sont numérotées de 1 à n, elles se suivent de manière linéaire. Chaque révision pointe vers un arbre décrivant l’état du projet. Les branches et les tags n’existent pas dans un repository svn. Ce ne sont que des répertoires désignés comme branche ou tag uniquement PAR CONVENTION.

Voir  bubble up method pour approfondir

Les concepts de GIT

Un repository git gère 4 types d’objets

  • tree (répertoire en svn)
  • blob (fichier en svn)
  • commit (revision en svn)
  • tags

Et en plus des références qui sont utilisées pour désigner les branches On distingue les références des objets car ceux-ci sont immuables alors que les références sont volatiles (i.e.: HEAD est une référence qui peut pointer sur n’importe quel commit alors qu’un objet sera toujours identifié par le hash SHA-1 de son contenu).

Le stockage de cette structure est si bien optimisé que tout l’historique d’un gros et vieux projet ne prend pas plus de place qu’un seul checkout svn.

Mais surtout cet historique n’est pas linéaire comme celui de svn. Les commit sont stockés dans une structure en graphe (un  DAG pour être précis). Un commit peut avoir un ou plusieurs parents (commit avec plusieurs parents == commit de merge). Cette structure en graphe reflète de manière fidèle la notion de branche.

Voir  getting git pour appronfondir

Workflow de SVN

Svn est extrêmement simple, il y a le repository central et des checkouts partiels en local. Les seules commandes à connaitre pour débuter sont les suivantes:

# copier une révision du projet en local
svn checkout http://monprojet/trunk
# génèrer une nouvelle révision sur le serveur dont l'identifiant sera incrémenté de 1 par rapport à la revision précédente
# Par exemple: touch newFile.txt
svn commit
# mettre à jour son projet en local
svn update

La structure et le workflow simplistes de svn font qu’une bonne pratique est d’utiliser le moins de branches possible, tout simplement car les merges sont longs et risqués.

Workflow de GIT

GIT est un DVCS, donc distribué: il peut y avoir plusieurs repository égaux entre eux. Mais de manière pratique on désigne souvent par convention un repository comme central. On a donc

  • un repository central
  • des repositories locaux (contient les mêmes infos que le central)
  • des workspace locaux (contient un checkout d’un commit du repo local)
  • des  index (contient les prochaines modifications à commiter)
  • des  stash

Une utilisation classique de git est donc la suivante

#dupliquer un repository en local
git clone
#Création d'un branche (MonDevAmoi = nom de ma nouvelle branche, créée à partir de la branche nommée BrancheDeReference)
git checkout -b MonDevAmoi BrancheDeReference
#Ajout des modifications dans l'index
git add ...
#commit de l'index dans le repo local
git commit ...
#récupération d'éventuelles modifications sur le repository central
git fetch
#merge de ces modifications avec notre branche
git merge
#Partage des modifications locales avec le repository central
git push

Avantages de git

Après cette présentation on se rend surtout compte que git est plus complexe. Quels avantages apporte cette complexité?

Rapidité

Toutes les opérations se font en local, git est plus rapide de plusieurs ordres de grandeur.

Merges rapide et facile

La structure de données de git a été pensée pour répondre à ce besoin, git est bien plus intelligent que svn sur ce point. Il devient possible de faire des  feature branch et d’envisager des  workflows évolués

Un historique propre

C’est tout de même la fonctionnalité principale d’un système de gestion de code: conserver l’historique. Conserver l’historique c’est bien, avoir un historique propre et utile c’est mieux. Combien de repository svn sont pollués par des commits du type “oups erreur lors du merge” ou “oublié de commiter un fichier” ?

Git ne résout pas ce problème de manière magique mais il donne les outils pour améliorer la situation

  • L’index:

L’index est l’espace où l’on ajoute les modifications que l’on va commiter, il formalise une bonne pratique qui consiste à préparer et valider un commit avant de le faire réellement.

  • La modification d’un commit:

Mais même avec l’index, il reste difficile de faire des commits “parfait”. Un fois un commit créé il est impossible de le modifier (signé avec un SHA-1) par contre il est tout à fait possible de le supprimer pour le remplacer par un autre tant que l’on a pas “pusher” ses commit vers un repo distant. C’est le  git commit amend qui permet de modifier un commit existant.

  • La revision de l’historique:

Et si ce n’est pas suffisant  git squash et rebase permettent de manipuler l’historique lorsque l’on merge des branches.

Par exemple une feature branch qui contient des dizaines de commit peut se transformer en un seul commit lorsqu’on la merge dans la branche principale.

GitHub

Il faut l’essayer pour comprendre. La fonction phare de github est la pull request qui exploite à merveille les capacités de merge de git. La pull request est aussi le moment idéal pour faire un code review.

Inconvénients de git

La courbe d’apprentissage: il faut investir en formation pour bénéficier pleinement de git.

L’outillage, par encore aussi mature que ce qui est disponible pour svn mais ça viendra, pour l’heure la ligne de commande est ton amie.

Git Flow VS pull request

Git permet de mettre en oeuvre de nombreux modèles de développement. Deux en particulier ont émergé:  Git Flow et  github pull request. Le premier est plus orienté workflow d’entreprise aux release régulières mais espacées, le deuxième est adapté aux projets open source, de nombreux contributeurs et un nombre restreint de “committers” qui valident les développements.

Mais rien n’empêche d’utiliser les deux: On peut très bien pusher vers github les features branchs de git flow. Et faire une pull request sur celle-ci pour les merger sur develop.

C’est la grande force de git on peut imaginer et mettre en oeuvre toute sorte de workflow, un autre exemple pour la route.

Pour aller plus loin

 

UPDATE: Think like (a) git est de loin le meilleur tuto sur git

Je maintien une liste de délicieux liens à propos de git mais la meilleure façon de se documenter sur Git est probablement de googler Scott Shacon, employé de github c’est l’évangéliste n°1 de git il a entre autre commis:

Mais si vous en avez assez de la théorie voici pour la pratique