Yearly Archives: 2011

Des tweets et des plus n°7 – Waterfall & Astérix

Programme de terminale: l’interopérabilité , persistance de l’information  et droit à l’oubli, Non-rivalité de l’information, Supranationalité des réseaux

Up and Down the  ladder of abstraction: the most powerful way to gain insight into a system is by moving between levels of abstraction

The Tao of Programming:  the fundamental problem of programming is dealing with the complexity that arises from interactions between state and behavior

Application d’entreprise: les caractéristiques d’un logiciel d’entreprise sont entièrement définies par la structure des grandes organisations qui les acquièrent, et en particulier par leur processus d’achat

Des tweets et des plus n°6 – Dennis Ritchie

Mon premier vrai livre de programmation !

Simple isn’t it? the general population has talked so much about Steve Jobs’ death and comparatively so little about Dennis Ritchie’s: Steve’s influence was at a layer that most people could see, while Dennis’ was much deeper

The O/R Impedance Mismatch: Why does this impedance mismatch exist?  The object-oriented paradigm is based on proven software engineering principles.   The relational paradigm, however, is based on proven mathematical principles.  Because the underlying paradigms are different the two technologies do not work together seamlessly.  The impedance mismatch becomes apparent when you look at the preferred approach to access: With the object paradigm you traverse objects via their relationships whereas with the relational paradigm you join the data rows of tables.  This fundamental difference results in a non-ideal combination of object and relational technologies, although when have you ever used two different things together without a few hitches?

Events as storage mechanism :  All events should be represented as verbs in the pas t tense such as CustomerRelocated, CargoShipped, or InventoryLossageRecorded. For those who speak French, it should be in Passé Composé, they are things that have completed in the past.

Un bon email est un email détruit: si après avoir lu et traité un email vous devez le garder, pire l’archiver, c’est suspect! Un email doit pouvoir être détruit

 

Des tweets et des plus n°5 – slide to unlock

La SSII m’a tuée: Comment cela Lucius, vous refusez la sodomie? », une pratique pourtant incontournable dans l’univers de la prestation de services.

One of the Best Bits of Programming Advice I ever Got: “Don’t make objects that end with ‘er’.”

Ram is cheap: Algorithms are for people who don’t know how to buy RAM.

LinkedIn engineering leader: best leaders […] know that if you hire the right people and put those people in the right positions, they will figure out the right technology and process to get the job done

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