The Agile Inception Deck

Traduction libre de votre serviteur de l’article The Agile Inception Deck par Jonathan Rasmusson

Un domaine dans lequel les méthodes agiles font l’impasse est le lancement de projet. Ci-dessous vous trouverez une méthode simplifiée que vous pouvez utiliser pour combler ce manque et faire pointer vos projets dans la bonne direction longtemps avant que la première ligne de code ne soit écrite.

10 questions à poser au début de votre prochain projet

Ça démarre plein d’espoir, le projet débute, vous et votre équipe êtes sur la même longueur d’onde. Ou c’est ce qu’il semblait. Alors vous commencez à construire et vous réalisez que vous aviez tous quelque chose de différent en tête. Ça vous est déjà arrivé ?

Combien de projets ont commencé comme ça : vous et votre équipe êtes persuadés au début du projet que vous pensez tous à la même chose ?

Et quand vous commencez à construire quelque chose, vous réalisez que vous pensiez à quelque chose de complètement différent.

Cela arrive constamment dans les projets : penser qu’il y a un consensus alors qu’il n’en existe aucun.

Bien que les bonnes équipes puissent surmonter ces divergences et s’adapter au fur et à mesure, c’est une forme de gâchis qui peut ralentir ou tuer les imprudents avant même d’avoir passer la porte.

Pour étouffer ce problème dans l’œuf, quand j’étais à ThoughtWorks nous avons créé un outils léger de lancement de projet appelé « The Agile Inception Deck : 10 questions et exercices que vous seriez fous de ne pas poser et entreprendre avant de commencer votre projet. »

Ces questions ont deux objectifs : alignement et réglages des attentes.

L’alignement c’est être sûr que vous et tous les autres sont sur la même longueur d’onde du pourquoi on est là, qu’est ce qu’on essaye de faire et comment on va y arriver. La base.

D’un autre coté, le réglage des attentes c’est communiquer clairement avec votre équipe et les parties concernées de ce qu’il va falloir pour faire de ce projet un succès. Vous définissez les règles d’engagement.

Oui on peut construire ça pour vous. Non ça ne devrait pas être trop compliqué. Voilà ce que ça va nécessiter …

Vous devez avoir cette conversation tôt et faire en sorte que vos clients sachent ce dont vous avez besoin pour les servir le mieux possible. Ne présumez de rien, soyez explicite et posez des questions.

Comment être sur de ce que veulent vos clients ? Un bon moyen de commencer et de leur demander :

1. Pourquoi est-on là ?

Vous ne pourrez pas construire un super produit si au départ vous ne savez pas pourquoi vous le construisez. Demandez « pourquoi » donnera à vous-même et votre équipe le contexte nécessaire pour prendre toutes les décisions pertinentes pendant l’exécution.

Par exemple, disons que vous avez été embauché par une entreprise de construction pour créer un système de gestion de fermeture de routes, en fonction des dates, sur un chantier de construction.

Une question évidente qui vous aidera vous et l’équipe à construire une solution est « Pourquoi ? ». Pourquoi, en premier lieu, la société va dépenser du capital sur ce projet ?

Est ce pour la sécurité ? Une exigence réglementaire ? Pour réguler efficacement les mouvements de matériels sur le site de construction ?

Connaître et comprendre l’exigence première derrière votre projet vous aidera à trouver le bon équilibre dans les décisions de compromis qui se présenteront inévitablement pendant le développement.
Vous ne pourrez pas le faire sans savoir « pourquoi ? ».

2. Créer le pitch de l’ascenseur

Les projets peuvent représenter beaucoup de choses pour plein de gens. Cet exercice est fait pour s’assurer du contraire.

Un bon pitch d’ascenseur explique aux gens ce que votre produit est, pour qui il est et pourquoi, dans le temps nécessaire à une balade en ascenseur.

En faire un bon peut être plus difficile que vous ne le pensez. Mais une fois que vous l’aurez, vous vous sentirez mieux. Vous pourrez rapidement faire passer un concept bien abstrait (c’est comme ça que tous les projets débutent) en quelque chose de concis, réel et concret.

3. Dessiner la version boite

Bien réfléchir à votre produit du point de vue de votre client est toujours cool. Non seulement construire la version boite de votre produit vous place dans la tête de votre client mais c’est aussi un bon exercice de cohésion d’équipe et ça vous donne la permission de dessiner et colorier à votre boulot !

Vous n’avez pas besoin de produire quelque chose de complexe ou de très élaboré, demandez vous simplement :

  1. Quelles sont les trois raisons les plus importantes qui font que les gens vont acheter ce produit ?
  2. S’il y a un slogan qui va capturer l’esprit du produit, ce serait lequel ?

4. Créer la liste NON

Dire oui c’est facile, c’est dire non qui est difficile. La liste des «NONs» commence à dessiner des limites, à cadrer et à définir ce que l’on ne va pas faire dans le projet.

Dire ce que vous n’allez pas faire est efficace. Cela va éliminer beaucoup de temps perdu en focalisant l’équipe sur ce qui est IN et en ignorant tout ce qui est OUT. C’est de la colonne IN que les scénarios utilisateurs de haut niveau vont découler.

Il n’est pas rare non plus que beaucoup de chose qui pourrait être dans le cadre de la colonne IN n’y soit pas (souvent à cause du temps et du budget). Il vaut mieux résoudre ces questions maintenant que de les laisser pour plus tard.

C’est vraiment de l’estimation des « essentiels ». Ce que vous représentez là c’est « si on implémente ces parties dans le projet, ce sera bon ».

5. Rencontrer vos voisins

Une fois, j’ai presque failli perdre un projet car je n’avais pas apprécier que la communauté d’un projet est toujours plus large qu’on ne le pense. Il est facile d’imaginer que tout tourne autour de vous et du noyau de l’équipe mais la réalité est que la plupart des projets nécessite plus que l’équipe de base pour être un succès (surtout dans les grandes entreprises).

Cet exercice consiste à vous projeter, vous et l’équipe, bien en avant dans le temps et pour rencontrer et établir des relations bien avant que le projet en ait besoin réellement. Non seulement c’est de la courtoisie mais cela leur laisse le temps de se préparer à votre arrivée et d’être là quand vous aurez besoin d’eux.

6. Montrer la solution

Vous choisissez votre architecture quand vous choisissez votre équipe donc il vaut mieux être sur que tout le monde est à la page avec votre solution avant de commencer.

Cet exercice consiste à faire passer les grandes lignes. Si vous comptez utiliser certains outils ou certaines architectures pour faire ce projet, il vaut mieux le faire savoir maintenant. C’est très énervant de se rendre compte plus tard qu’on est plus dans les limites d’un standard de l’entreprise par exemple.

C’est aussi une opportunité pour mettre les choses au clair si vous n’avez pas toutes les réponses (et c’est OK aussi !). Faites le leur savoir.

7. Demander ce qui pourrait nous empêcher de dormir

Il y a des milliers de choses qui peuvent mal tourner sur nos projets. Certaines sont gérables, d’autres non. Cet exercice aide à identifier les risques qui méritent qu’on s’en préoccupe et ceux dont on n’a pas besoin de se soucier.

Par exemple, on ne peut pas faire grand chose pour prévenir un crac de l’économie ou que votre contact client soit promu vice directeur informatique. Donc pas la peine de s’en soucier.

Avoir une équipe avec des membres permanents à temps plein, ça par contre vous pouvez travailler dessus et ça vaut le coup de se battre pour.

C’est votre chance de limiter l’emballement avant le début du projet et de vous battre pour ce qui va être nécessaire pour transformer ce projet en succès. Vous n’obtiendrez peut être pas tout mais ça fait jamais de mal de le demander.

8. Évaluer la taille

Cet exercice doit répondre à la question de la taille. On ne pourra pas dire exactement combien de jours cela va prendre pour mener à bien ce projet mais on peut dire si c’est un projet de 3, 6 ou 9 mois.

Cet exercice consiste à estimer et planifier des scénarios clients de haut niveau. La liste des «NONs» vous aidera bien ici. Vous devrez arriver à quelques grosses estimations pour que votre donneur d’ordres se fasse une idée de la taille du projet et ce que ça représente.

Le but de l’exercice n’est pas la précision des estimations mais de déterminer si ce projet est tout simplement faisable avec les ressources qu’on vous donne.

9. Soyez clair sur ce qui va compter

Tous les projets ont des leviers comme la durée, le budget, le cadre ou la qualité. Il vaut mieux savoir lequel est le plus important et sur lesquels ont peut jouer.

Pour certains projets, tout ce qui compte c’est le budget, pour d’autres, c’est la date de livraison.

Il faut mener cette conversation pour savoir quand la pression va monter si vous serez flexible sur la couverture fonctionnelle (de préférences) ou si vous avez une marge de manœuvre sur la date.

L’autre sujet à discuter est : qu’est ce qui fait que ce projet sera LE projet ? La facilité d’utilisation, la simplicité, la rapidité, la flexibilité, la sécurité, etc. ? Mettez ça sur papier pour être certain que tout le monde le garde à l’esprit avant de commencer. Ces aspirations de haut niveau peuvent vous servir de lanterne quand le ciel s’assombrit.

10. Montrer ce que ça va prendre

Cet exercice est à propos des deux questions qui occupent l’esprit de tous les clients : combien de temps ça va prendre et combien ça va couter ?

Si le projet est en pré-vente, votre budget est peut être déjà fixé. Dans ce cas, le calcul va être simple pour voir si le projet est faisable avec les ressources qui vous ont été attribuées.

C’est encore une opportunité pour expliquer quel type d’équipe vous devez monter pour sortir ce projet. Vous pouvez appuyer vos attentes sur la taille de l’équipe et l’éventail des compétences nécessaires à la réalisation.

Mettre tout le monde dans le même bus

Travailler sur un Agile Inception Deck pour votre projet n’est pas magique. C’est simplement une façon de mettre les bonnes personnes dans une pièce, leur poser les vraies questions et partager les résultats avec vos clients et toute l’équipe.

Ça peut prendre un jour ou deux, jusqu’à deux semaines pour le compléter et ça assure normalement trois à six mois de planning. C’est un outil inestimable pour poser les attentes du projet et rappeler aux gens en quoi consiste votre équipe et ce projet.

Donc avant de commencer votre prochain projet agile, soyez sûr d’avoir poser les vraies questions et que tout le monde est sur la même ligne. Vous ressemblerez à un pro et vous aurez préparé votre succès longtemps avant qu’une ligne de code ne soit écrite.

[Voir le post original pour un lien vers une présentation de support vide et le lien vers le livre sur Amazon]

Le traducteur remercie Mizu no kokoro pour sa lecture attentive et ses suggestions.

 

Le client Linux de hubiC est sorti en bêta !

Le client Linux de hubiC est sorti en bêta (cf. cette adresse : https://forums.hubic.com/showthread.php?272-hubiC-for-Linux-beta-is-out-!).
Enfin ! Pffffiuuuuu on l’aura attendu celui là …

Je suis en train de refaire toute mon architecture de sauvegarde donc je vais pouvoir tester ce service au bon moment !

Un avertissement, le répertoire synchronisé (unique, actuellement ?) est sauvegardé tel quel vers hubiC donc si vous envisagez plusieurs répertoires différents, je vous conseille de créer un répertoire hubiC et de créer des liens dedans. (cf. ce post sur les limitations actuelles https://forums.hubic.com/showthread.php?270-beta-Linux-ligne-de-commande)

Allez en cadeau, première mondiale tout ça tout ça, le source du premier client léger disponible :

#! /bin/bash
while true
do
	output=$(hubic status)
	printf "\ec"
	echo "$output"
	sleep 1
done

Ok… Je sors…

Bonne sauvegarde et n’oubliez pas que c’est une bétâ !

Les commentaires dans le code

« [comments] It is a “back channel” of communication between the author of the program and all of its future readers to convey information about the program. »
Prologue de How to Design Programs.

Les commentaires ne sont pas là pour passer des tests de bonnes conduites et souffler de désespoir sur la redondance avec la définition de votre fonction (vous êtes dans l’erreur, C3 du Clean Code), ils sont là pour communiquer avec vous dans le futur ou encore plus important avec un autre codeur dans le futur, ils sont là pour faire gagner du temps … mais dans quelques mois.

 

Mon système de sauvegarde en juillet 2012

On s’étonne souvent de mon système de sauvegarde, des redondances ou de sa complexité. Toutes ces personnes n’ont pas perdu les deux derniers mois de développement d’un projet de deux ans à rendre trois semaines plus tard (~1997) ou plusieurs années de photos (~2002).

Enfin pas encore.

Données

Découpage et rangement de mes données à sauvegarder :

  • agile
    données qui changent souvent (programmation, configuration, etc.) ou en cours d’écriture (documentation, etc.) et qui ne sont pas privées (je publie mon code) ou très peu.
  • confidentiel
    généalogie, photos, sauvegardes de services externes, de téléphone, etc.
  • dormante
    données qui changent très peu (fond d’écran, ebooks, etc.) et n’ont pas de  caractère privés. Il est possible de trouver un rapport avec un pseudo et/ou une activité (screenshot de jeu par exemple)
  • jetable
    données que je garde mais que je peux «perdre» et qui n’ont aucun caractère privé
  • privee
    données privées (comptabilité, scan de document administratif, etc.). Dans un container truecrypt.
Tableau récapitulatif :
Chemin Importance Confidentialité Taille (en Go) Fréquence de sauvegarde
agile *** ** 1 «temps réel»
confidentiel *** *** 45 toutes les heures
dormante ** * 20 toutes les nuits
jetable * * 20 toutes les nuits
privée *** *** 1 «temps réel»

Outils

  • TrueCrypt pour créer les containers
  • SSH Filesystem pour monter un système de fichier distant au travers d’un tunnel SSH
  • rsync pour faire de la synchro incrémentale
  • BackupPC pour la sauvegarde locale (serveur et interne)
  • FileZilla pour la sauvegarde vers le NAS local

Cf. Sauvegarde avec rsync dans un container Truecrypt distant monté par ssh avec sshfs pour articuler ces outils entre eux.

Matériels de sauvegarde

Services

  • SpiderOak sauvegarde, synchronisation et partage en ligne (100Go pour 100$/an), chiffrement à la source, multi-plateforme, python.
  • Crashplan sauvegarde en ligne (illimité pour 50$/an) et entre amis, parents, etc. (je te laisse 100Go chez moi, héberge moi mes 80Go). Gratuit pour la version sans sauvegarde paramétrée (priorité, filtre, etc.)
  • hubiC sauvegarde et partage (synchronisation prévue) en ligne (100Go pour 12€/an), multi-plateforme, service et hébergement en France par OVH.
Plus utilisé :

Organisation

Données envoyés :

  • Totale chez CrashPlan (automatique).
  • Totale chez SpiderOak (automatique).
  • Totale en interne (disque différent) par BackupPC (automatique).
  • Données importantes (*** sur le tableau) sur un NAS hébergé par SSHFS (manuel / automatique).
  • Données multimédia en local sur un NAS (manuel).
  • Données multimédia chez hubiC (manuel).
  • En fonction de l’utilisation d’internet, de la place dispo, etc. telles ou telles parties chez telles ou telles personnes par CrashPlan (automatique).

Données reçues (en interne est le petit nom de /backup, mignon petit disque dur de 500Go) :

  • Le serveur local en interne par BackupPC.
  • Autres PC du LAN en interne par CrashPlan.
  • Personnes qui hébergent mes donnée par CrashPlan en interne par CrashPlan.

Conclusion

« (Only wimps use tape backup: _real_ men just upload their important stuff 
on ftp, and let the rest of the world mirror it ;) » (source) – Linus Torvalds

Oui. Mais on est pas tous Linus :)

Ma configuration internet de juillet 2012

Navigateur

Enfer et damnation, après avoir conquis mes PCs persos et pro, Chrome (Chromium sur les PCs) est maintenant mon navigateur sur Android :(

CHROMIUM (NON, PAS CHROME)

Navigateur principal : Chromium.

Je surveille https://chromium-build.appspot.com/p/chromium/console puis je télécharge la version qui me semble la plus appropriée sur http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html

Modules complémentaires :

gTranslate est remplacé par le !Bang « !tr » de DuckDuckGo.

FIREFOX

Navigateur complémentaire : Firefox installé avec les .tar.gz dans un répertoire /opt pour ne pas attendre l’empaquetage de ma distribution.

Sans modules complémentaires on a pas un vrai Firefox donc dans l’ordre d’urgence d’installation :

  • NoScript pour bloquer les scripts
  • Adblock Plus pour bloquer les pubs
  • Lazarus pour sauvegarder les formulaires et ne plus perdre vos textes toujours au pire moment (avec un F5 malencontreux par exemple …)
  • gTranslate pour avoir rapidement, sans 15000 options et fenêtres, la traduction d’un mot
  • Linky pour pouvoir faire clic droit, Open Selected Links in tabs
Modules supprimés
  • Fast Dial avec des raccourcis en 10×6. L’auteur met vraiment trop de temps entre les mises à jour Firefox et les mises à jour de son module.
  • FlashGot pour pouvoir faire clic droit, « Télécharger la sélection avec FlashGot ». Plus besoin puisque JDownloader surveille le presse papiers donc à la place je fais juste un Ctrl+C.

Services

MAIL

Ayé, la transition à commencée :
Mail courant désormais chez GMX Caramail. Oui, ça fait bizarre d’écrire Caramail :)
Mail perso géré par Sud-Ouest.org
Google Mail récupéré par GMX.

Calendrier

Ayé aussi, je suis entièrement sous ownCloud.
Pour l’utilisation par le téléphone :

J’ai perdu le partage mais il est présent dans la nouvelle version, je n’ai juste pas encore mis à jour.

TODO

Toodledo car j’ai erré dans la jungle de GTD pendant des années (preuve sur linuxfr.org d’il y a 4 ans, si si 4 ans …) et j’en ai essayé des kilos. J’utilise donc Toodledo comme système et Evernote pour les références (cf. ci dessous).
En complément : Ultimate To-Do List sur mon téléphone avec les widget 1×4 qui affiche seulement les TODO rapide/temporaire (configuré dans New task) et 4×4 pour l’agenda à venir.

Nouveau venu pour certains usages très précis : WorkFlowy.
Des raccourcis clavier à gogo, un partage nickel, excellent.

NOTES ET MARQUES PAGES

Evernote avec mes conseils et rêgles.
Toujours tout ce que j’ai cité dans le post précédent mais ils ont corrigé l’édition du carnet ne vous oblige pas aller dans ce carnet.

Sinon :

  • Memonic… Contrairement aux post précédent, j’évite. Passé payant et impossible d’importer mes notes Evernote. Plusieurs relances. Toujours aussi rapide et cordial dans les échanges mais le service n’est pas là.
  • Springpad je connais des inconditionnels mais je ne supporte pas leur interface
  • Suppression de Diigo car trop de problème de mise à jour des tags
  • Peut être une migration vers Semantic Scuttle le jour où les imports fournis fonctionneront mais c’est limité aux marque-pages

DOCUMENT

Google docs malgré l’installation d’Owncloud.

Mais j’utilise de plus en plus des documents « lourds » (type LibreOffice) mais sur des disques réseaux partagés (type DropBox, Ubuntu One, hubiC, etc.)

LECTEUR RSS

RSS Lounge découvert grâce à Dada. Avec ces 2 hacks : 63 et 81 (de moi !), c’est parfait … et rapide !

J’ai eu plusieurs brefs passages par Tiny Tiny RSS mais c’est vraiment trop lent.

PHOTOS

Google Picasa à cause … du client lourd Picasa pour la gestion des visages, le partage gratuit, la synchronisation des répertoires, la gestion des tags et du client Android pour Google+.

J’envisage Piwigo plus tard.

Comprendre le processus Git

Traduction libre de votre serviteur de l’article Understanding the Git Workflow par Benjamin Sandofsky

Comprendre le processus Git

Si vous ne comprenez pas ce qui a poussé au design actuel de Git, vous allez souffrir en l’utilisant. Avec toutes ses options, vous arriverez à forcer Git à agir comme vous pensez qu’il doit agir au lieu de le laisser agir comme il le souhaite. C’est comme utiliser un tournevis à la place d’un marteau, vous arriverez au résultat souhaité sauf que cela sera mal fait, ça prendra du temps et ça abîmera le tournevis.

Regardez comment le processus classique de Git peut s’écrouler.

Créer une branche depuis Master, coder, fusionner la branche dans Master quand vous avez fini.

La plupart du temps vous obtiendrez le comportement attendu car Master n’aura pas changé depuis la création de la branche. Plus tard, vous allez fusionner la branche dans Master mais Master n’aura pas divergé. Au lieu de créer un commit de fusion, Git va simplement faire pointer Master sur le dernier commit de la branche (ce qu’on appelle un «fast forward», une avance rapide, cf. ce diagramme).

Malheureusement, votre branche contenait des commits d’étapes, des commits qui permettent de sauvegarder votre progression mais qui fixent un code non stabilisé. Maintenant ces commits sont confondus avec les commits stables de la branche Master. Vous pouvez facilement provoquer une pagaille en revenant en arrière.

Donc vous vous créez une nouvelle règle : «Quand je fusionne une branche, j’utilise l’option –no-ff pour forcer un nouveau commit.». Affaire résolue, on continue.

Et puis un beau jour vous découvrez un bug critique en production et vous avez besoin de revenir en arrière pour trouver quand il a été introduit. Vous utilisez bisect mais vous arrivez toujours sur des commits d’étapes. Vous abandonnez et vous finissez par chercher «à la main».

Vous arrivez à localiser le bug dans un fichier et vous utilisez blame pour voir comment il a évolué dans les dernières 48 heures. Vous savez que c’est impossible pourtant blame vous rapporte que le fichier n’a pas été modifié depuis des semaines. Il se trouve que blame rapporte les changements à la date du commit initial et pas à la fusion. Vos changements ont été fusionnés aujourd’hui mais votre premier commit d’étapes a modifié ce fichier il y a des semaines.

Entre le plâtre no-ff, bisect inutilisable et blame incompréhensible, nous avons tous les symptômes d’un tournevis utilisé comme un marteau.

Repenser le contrôle de révision

Le contrôle des révisions existe pour deux raisons.

La première est d’aider l’acte d’écrire du code. Vous avez besoin de synchroniser des changements avec vos collègues et de régulièrement sauvegarder votre travail. Non, envoyer des zips de vos fichiers ne tient pas la montée en charge.

La seconde est le management de configuration. Cela inclut le management en parallèle de plusieurs axes de développement comme travailler sur la prochaine version majeure tout en appliquant des corrections de bug sur la version existante en production. Le management de configuration est aussi utilisé pour comprendre exactement quand quelque chose a changé, ce qui en fait un outil de débogage qui n’a pas de prix.

Traditionnellement ces deux raisons sont en conflit.

Quand on maquette une fonctionnalité, on fait des commits d’étapes réguliers et souvent ces commits empêchent la compilation. Alors que dans un monde parfait, chaque changement dans votre historique de révision est succinct et stable. Il n’y a pas de bruit créé par des commits d’étapes. Il n’y a pas de commit géant de 10 000 lignes. Un historique propre facilite l’annulation de changement ou l’opération de cherry-pick entre les branches. Un historique propre facilite également l’analyse, l’inspection à posteriori. Cependant, maintenir un historique propre signifie attendre que le code soit parfait avant de l’enregistrer.

Donc quelle approche choisir ? Commit régulier ou historique propre ?

Si vous vous êtes à la veille de lancer votre mini startup, un historique propre ne va pas être un avantage décisif. Vous pouvez commiter à tout va et déployer quand bon vous chante.

Mais en conséquence d’une augmentation du nombre des modifications, que ce soit du à l’élargissement de l’équipe de développement ou à la taille de votre base d’utilisateurs, vous allez avoir besoin d’outils et de techniques pour maintenir les choses sous contrôle. Cela inclut les tests automatiques, les revues de code … et un historique propre.

Les branches de fonctionnalités peuvent sembler une solution équilibrée. Elles résolvent les problèmes de base du développement parallèle. Vous pensez à l’intégration au moment le moins opportun, quand vous écrivez du code, mais ça vous rattrapera. Quand le projet aura assez grossi, le simple processus branche/commit/fusion va s’effondrer. Finis les rafistolages, vous aurez besoin d’un historique de révision propre.

Git est révolutionnaire car il vous donne le meilleur des deux mondes. Vous pouvez maquetter une solution avec des commits réguliers mais également délivrer un historique propre lorsque vous avez fini. Et si c’est bien votre but, les choix par défaut de Git prennent alors tous leurs sens.

Le processus

Penser aux branches en les divisant en deux catégories : publique et privée.

Les branches publiques représentent l’autorité historique du projet. Dans une branche publique, chaque commit doit être succinct, atomique et un message de commit correctement rédigé. Une branche publique doit être la plus linéaire possible et non modifiable. Master et les branches de releases sont des branches publiques.

Une branche privée est personnelle. C’est votre brouillon quand vous travaillez sur un problème.

Il est plus sûr de garder locale une branche privée. Si vous avez besoin de la faire remonter sur dépôt, pour synchroniser vos ordinateurs professionnel et personnel par exemple, prévenez vos collègues que cette branche est privée et qu’ils n’ont pas besoin de travailler dessus.

Vous ne devriez jamais fusionner une branche privée directement dans une branche publique avec un merge de base. Vous devez d’abord nettoyer votre branche avec des outils comme reset, rebase, squash merges, et l’amendement de commit.

Mettez vous dans la peau d’un écrivain et prenez chaque commit comme le chapitre d’un livre. Les écrivains ne publient pas leurs premiers brouillons, Michael Crichton a dit «Les grands livres ne sont pas écris, ils sont réécris.».

Si vous venez d’autres systèmes, modifier l’historique peut vous sembler tabou. Vous avez été conditionnés pour considérer que les commits sont écris dans le marbre mais avec cette logique nous devrions désactiver la fonction «Annuler» dans nos éditeurs de textes.

Les gens pragmatiques prennent soin des changements jusqu’à ce que les changements ne soient que du bruit. Pour la gestion des configurations, nous prenons soin des changements importants. Les commits d’étapes ne sont que des brouillons sauvegardés dans le nuage.

Si vous traitez votre historique public comme une lady, les fusions avec avances rapides sont non seulement plus sûres mais nécessaires. Elles conservent l’historique linéaire et sont simples à suivre.

Le seul argument restant pour –no-ff c’est «la documentation». On peut utiliser les commits de fusion pour représenter la dernière version déployée du code en production. C’est un antipattern, utilisez les tags.

Lignes directrices et exemples

J’utilise trois approches de base en fonction de la taille de mes changements, du temps consacré à ce travail et de l’état de divergence de la branche

Travail à courte durée de vie

Dans la majorité des cas, mon nettoyage consiste seulement à une fusion avec squash.

Imaginons que je crée une branche de fonctionnalité et une série de commits d’étapes pendant la prochaine heure :

<code>git checkout -b branche_privee_fonctionnalite
touch file1.txt
git add file1.txt
git commit -am "WIP"</code>

Quand j’ai fini, au lieu d’un merge de base, j’utilise :

<code>git checkout master
git merge --squash branche_privee_fonctionnalite
git commit -v </code>

Et je prends une minute pour écrire un message de commit détaillé.

Travail plus conséquent

Parfois une fonctionnalité s’étale sur un projet de plusieurs jours avec des douzaines de petits commits.

Si je décide que ma modification doit être séparée en plusieurs modifications plus petites, squash est un peu trop bourrin (comme métrique, je me demande toujours «Est ce que ce code serait facile à faire valider ?»)

Si mes commits d’étapes suivent une progression logique, j’utilise le mode interactif de rebase. C’est très puissant, vous pouvez l’utiliser pour éditer un vieux commit, les séparés, changer l’ordre et dans ce cas utiliser squash sur quelques uns.

Sur ma branche de fonctionnalité :

<code>git rebase --interactive master</code>

Cela ouvre un éditeur avec une liste des commits. Sur chaque ligne, on retrouve l’opération à effectuer, le SHA1 du commit et le message de commit actuel. Une légende de la liste des commandes possibles est affichée.

Par défaut, chaque commit utilise «pick» qui ne modifie pas le commit.

<code>pick ccd6e62 Travail sur le bouton retour
pick 1c83feb Résolutions de bogues
pick f9d0c33 Début du travail sur la barre d'outils</code>

Je change l’opération en «squash» ce qui va fusionner le deuxième commit dans le premier.

<code>pick ccd6e62 Travail sur le bouton retour
squash 1c83feb Résolutions de bogues
pick f9d0c33 Début du travail sur la barre d'outils</code>

Quand je sauvegarde et ferme l’éditeur, un nouvel éditeur va s’afficher pour écrire le message de commit des commits fusionnés.
Et c’est fini.

Travail sur une branche en faillite

Peut être que ma branche de fonctionnalité existe depuis très longtemps et que j’ai du fusionner plusieurs branches dans ma branche de fonctionnalité pour la garder à jour tout en travaillant dessus. L’historique est en vrille. Le plus simple est de récupérer les différences brutes et de créer une nouvelle branche.

<code>git checkout master
git checkout -b branche_propre
git merge --squash branche_privee_fonctionnalite
git reset</code>

J’ai maintenant un répertoire de travail avec toutes mes modifications sans traîner les valises de ma branche précédente. Je peux alors ajouter manuellement mes modifications et faire mes commits

Résumé

Si vous vous battez avec les choix par défaut de Git, demandez vous « pourquoi ? ».

Traiter l’historique public comme immuable, atomique et facile à suivre. Traiter l’historique privé comme jetable et malléable.

Le processus prévu est :

  1. Créer un branche privée depuis une branche publique.
  2. Commiter régulièrement sur cette branche privée.
  3. Une fois que votre code est parfait, nettoyer son historique.
  4. Fusionner cette branche nettoyée vers la branche publique.

L’auteur remercie particulièrement @joshaber et @jbarnette pour leurs retours sur les premiers brouillons.
Le traducteur remercie Mizu no kokoro pour sa lecture attentive d’un texte « totalement incompréhensible mais tellement poétique, hermétique et ésotérique ».

Appliquer un format de code en masse avec Eclipse

Vous venez de vous mettre d’accord avec tout le monde sur un format de code dérivé de la convention de code Java avec quelques ajustements (taille de ligne à 160, on à des 24 pouces quand même, et « space only » pour les tabulations), maintenant faut appliquer ça partout !

Vous avez également configurer le « Save actions » avec « Format source code », parfait.
Ou pas.
Si vous attendez de passer dans le code pour reformatter, vous risquez de perdre la prochaine modification dans un énorme commit à cause d’un fichier entièrement reformaté, il faut donc faire un traitement de masse.

Attention à bien choisir le moment car
vous risquez de perdre la comparaison de code pour tout le code précédent !

J’ai trouvé la solution dans http://blogs.operationaldynamics.com/andrew/software/java-gnome/eclipse-code-format-from-command-line et http://www.peterfriese.de/formatting-your-code-using-the-eclipse-code-formatter/ par contre je préfère sauter l’étape d’enregistrer le formatage à un projet et utiliser le formattage affecter au workspace, ma ligne de commande ressemble donc plutôt à ça :

<path-to-eclipse>\eclipse.exe
-nosplash
-verbose
-application org.eclipse.jdt.core.JavaCodeFormatter
-config <path-to-workspace>\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.core.prefs
<path-to-your-source-files>\src\

Script de mise à jour de RetroShare par les sources (svn)

À placer dans un compile_retroshare.sh (par exemple).
Configuration avec RetroShare installé dans «/opt» :

#!/bin/bash
cd /opt/retroshare
svn update
cd /opt/retroshare/libbitdht/src
qmake
make clean
make
cd /opt/retroshare/libretroshare/src
qmake
make clean
make
cd /opt/retroshare/retroshare-gui/src
qmake
make clean
make

Oui, s’il n’y a pas eu de changement, les

make clean

font perdre un peu de temps mais ils m’ont débloqué, surtout pour retroshare-ui, un paquet de fois donc maintenant ils sont permanents.

Source : http://doc.ubuntu-fr.org/retroshare#depuis_la_source

Genesi Efika MX

Genesi Efika MX SmarttopÇa fait plusieurs mois que je réorganise ma présence web, quel service j’utilise ou pas, à qui je donne mes données ou pas et j’ai décidé de rapatrier certaines données @Home comme au bon vieux temps.
Après des tas de lectures, tests, avis, trolls, etc., mon choix s’est porté sur un Genesi Efika MX  Smarttop (ARM et consommation 5W).

Et bien ça y est, je l’ai reçu !
Commandé sur http://www.genesi-europe.com/store/eu/, livraison en une semaine par DHL, la bête vient d’Allemagne.

Headless

Sortie HDMI uniquement. Aïe, j’avais pas vu ce point. Je boot, pas d’accés distant, je branche un écran et … c’était bloqué à l’install d’Ubuntu … Je finis l’installation et ça rame un peu. Allez on vire tout, c’est pour faire un serveur de toute façon. Est ce que je vire la couche X … Est ce que je shoot juste le lancement du service… Je me balade sur le forum officiel : http://www.powerdeveloper.org/forums/ et j’ai trouvé mon bonheur sur http://www.powerdeveloper.org/forums/viewtopic.php?t=1975.

J’ai suivi le README sauf pour la création de la carte SD, j’ai utilisé

xz -dc maverickheadless.img.xz | dd of=/dev/sde

plutôt que

xzcat maverickheadless.img.xz | dd bs=1M of=/dev/sde

Tout se passe comme prévu, réinstall, reboot, etc.

apt-get update
apt-get upgrade
reboot

Et voilà !

SSH

Ajout de la clé avec ssh-copy-id (http://doc.ubuntu-fr.org/ssh#authentification_par_un_systeme_de_cles_publiqueprivee).

On vire l’authentification par mot de passe, on limite les utilisateurs et les tentatives.

SSH ne sera pas accessible de l’extérieur mais retenez toujours : « On ferme tout et on ouvre le strict nécessaire ».

GIT

J’aime bien suivre ce que je modifie donc j’utilise un gestionnaire de source pour suivre tout les changements de /etc. (update : attention à cette opération, cf. le lien d’Etienne Millon dans le premier commentaire)

On installe Git avec

apt-get install git

et on sauvegarde /etc avec

cd /etc
git init
git add *
git -a -m "Add: Import initial."

À chaque modification, upgrade, ne pas oublier de commiter.

Munin

Pour surveiller ce qui se passe un peu sur le serveur, j’adore munin.

apt-get install munin-node smartmontools lm-sensors ethtool

Pour les problèmes de locale, installer le pack fr

apt-get install language-pack-fr

Préciser quel hôte à le droit de consulter les données avec le «allow» de /etc/munin/munin-node.conf

La suite ?

La suite bientôt avec nginx, owncloud, seeks, etc.