I’ve just come across dash.
(free in mac app store :  http://itunes.apple.com/us/app/dash-docs-snippets/id458034879?mt=12)
And I thought you might like it.

It’s a snippet manager and an API documentation browser for Mac Os X.
Access to documentation is really fast (a nice improvement from integrated documentation browser inside XCode.)
As I use different languages (ruby, Objective-C, javascript), I find this unified interface handy.

Snippets can be created and shared (via a dropbox folder) inside a team.
(They will appear as search results)

Here is what it looks like :

iPhone/iPod Touch: application executable is missing a required architecture. At least one of the following architecture(s) must be present: armv6

As it doesn’t seem to be an isolated issue trivial to solve, I’d like to share how to we managed to fix it. We found the good hint in a comment of this post. On the setting Project -> Build Settings -> Architectures -> Release, we selected “Other…” and we removed $(ARCHS_STANDARD_32_BIT), and we added two values: first “armv6” and second “armv7“. The project settings were like this:

Making the changes at project level propagates the value in the corresponding target:

I hope this can help other people facing the same issue.

Did it work for you? Did you find another solution? Do please share it in the comments. Thanks!

Et je n’ai parlé de la mêlée de rugby (Aller les bleus!), le SCRUM, comme métaphore à une méthode agile du même nom… Oups! Je viens de le faire

Et pour ceux que cela intéresse, je vous invite fortement à faire un tour sur le post d’Alexandre Boutin, afin de le harceler jusqu’à ce qu’il crée la mailing list Agile Games

Qui a dit Pénicilline ?!…

J’ai déjà abordé ce sujet dans un précédant post : Apprendre en s’amusant

Mais après ce double coup de fraicheur, Agile Tour Toulouse (@agiletoulouse / #att11) puis Innovation Games par Claude Aubry et Alexandre Boutin, ainsi que la discussion avec Olivier Azeau, je tenais à partager de nouvelles ressources (au sens large) à propos de l’apprentissage (un pilier de notre métier) et du jeu comme forme d’apprentissage.

Avant tout, je tenais à vous sensibiliser au fait que “le jeu c’est sérieux”. Je regrette que le jeu soit mal considéré par chez nous, et donc sous exploité. Il serait interessant de se demander pourquoi…

Avant même de parler d’Innovation Game, il est regrettable que le jeu soit encore une forme innovante d’apprentissage. En effet, le jeu est une forme d’expérimentation ludique qui a comme heureux effet de bord un apprentissage par l’empirisme… Comment peut on le délaisser comme outil de formation ?…

Pour pousser un peu plus, le sport est pour moi une évolution du jeu. Et si on se focalise sur les sports collectifs, ils apportent cette dimension supplémentaire d’esprit d’équipe, et donc de Team Building. Et quand on pense que certains sélectionneurs d’équipes nationales sont chèrement payés pour venir exposer leurs principes à de grands managers…

Et je n’ai parlé de la mêlée de rugby (Aller les bleus!), le SCRUM, comme métaphore d’une méthode agile du même nom… Oups! Je viens de le faire

J’espère vous avoir un peu convaincu de l’intérêt du jeu dans l’apprentissage. Dans tous les cas, voici quelques ressources qui vont dans ce sens…

APPRENTISSAGE

Tout d’abord, quelques livres autour de l’apprentissage :

• “ Apprenticeship Patterns ” chez O’Reilly (Merci à Olivier Azeau / @oaz pour son excellent atelier sur le sujet, et notre discussion qui a suivi), dont le titre complet se termine par “Guidance for the Aspiring Software Craftsman“
• ” Pragmatic Thinking & Learning “, chez The Pragmatic Programmers (pragprog.com) avec la fiche de lecture de stéphane
• “ The Pragmatic Programmer: From Journeyman to Master “ (orienté développeur)
• “ The Passionate Programmer “, encore chez The Pragmatic Programmers (dont le titre complet se termine par “Creating a Remarkable Career in Software Development“)

Ces titres couvrent large, mais l’idée était de donner des pointeurs.

TOOLKITS

Quelques kits regroupant cette fois des conseils, parfois sous forme de retours d’expérience :

• “ Agile in a Flash: Speed-Learning Agile Software Development “ toujours chez The Pragmatic Programmers
• ” Xebia Essentials ” de Xebia.fr (merci Christophe Deniaud pour le tuyau !)
• “ Partageons ce qui nous départage ” d’Octo

L’idée ici est de mettre l’emphase sur des formats un peu différents, notamment des cartes : plus agréables et faciles à “emmener”.

JEUX

Passons maintenant au meilleur moment du post, les jeux !

• Les Innovation Games : la formation dispensée par Claude et Alexandre repose sur le livre éponyme de Luke Hohmann sous titré “Creating Breakthrough Products Through Collaborative Play”. Vous trouverez sur le site certains des jeux recensés dans le livre.
• Vous pourrez également trouvez d’autres ressources dans le livre ” Gamestorming “
• Evidemment l’Alchimiste Agile, créé par votre serviteur avec François Bachmann, sur la technique au combien précieuse de la rétrospective
• La liste d’Alexandre Boutin sur l’avant dernière page de sa Keynote à l’Agile Tour Toulouse 2011.
• Le tout récent groupe Agiles Games France lancé il y a quelques jours par Alexandre (le récidiviste
• Le site Agile Fun » Agile games and techniques, time to share some recense plus d’une vingtaine de jeux agiles.
• Lean Simulations: Huge List of Free Lean Games! liste quant à lui plus de 30 jeux autour des simulations Lean ainsi qu’un article “Lean Simulations: Seven Benefits of Teaching Lean with Simulations” dont le titre laisse présumer de son intérêt
• Coach Tools « The Agile Coach Toolkit se restreint plus précisément aux jeux créés par Pascal et Portia (que je crois reconnaitre dans le logo du site
• Le groupe Google Agile Games initié par Yves Hanouille
• Simulations & Games se concentre sur XP : cool !
• Et enfin une liste sacrément longue de plus de 300 jeux pour la formation, indiquée par Fabrice ROBERT : Training Games (une bière au premier qui les a tous joués
• Sans oublier mon précédant post Apprendre en s’amusant qui parlait déjà de : Agile Games  initié par Yves Hanouille,

Et pour “la théorie”, je vous invite à creuser la notion de “Serious Games”, par exemple avec le site Serious Games.

CONCLUSION

Quelques remarques sur ce post :

• Je n’ai pas lu toutes ces ressources, vos retours sont donc les bienvenus
• Je n’ai pas la prétention de le prétendre exhaustif, vos compléments sont donc les bienvenus

Enfin, une petite conclusion…

Une autre formidable source d’apprentissage… Et d’innovation… également dénigrée dans notre culture (à se demander comment on fait par chez nous;) est l’erreur !

Qui a dit Pénicilline ?!…

Patrice Lagisquet (directeur du rugby du Biarritz Olympique Pays Basque, Joueur en équipe de France de rugby de 1983 à 1991) l’a formidablement dit en clôture de l’Agile Tour Toulouse 2011 :

“[dans le sport (collectif)] les génies ont cette force mentale qui leur permet de tenter des choses, et d’assumer si c’est une connerie”

Jean-Claude Bivert, CEO des montres Hublot, a soutenu plus longuement ce principe au cours de sa session à Lift 2011. comme j’en ai déjà parlé dans le post “Lift11 : Faites des erreurs pour créer !”

Enfin, François Beauregard, dans sa tribune à l’ESM de Genève “Apprendre pour la performance et le bien-être” sur la pensée systémique, prédit que l’avenir est aux sociétés apprenantes, donc aux individus apprenants… Comment oser se priver d’une opportunité d’apprendre en s’interdisant de faire des erreurs ?

Tolérer, voire assumer, voire encore prôner le droit à l’erreur, implique par contre en parallèle de mettre en place des mécanismes qui permettent de :

1. Détecter efficacement l’erreur
2. Corriger rapidement l’erreur
3. Apprendre de cette erreur

Mais je pense que cela pourrait faire le sujet d’un autre poste !…

Je résumerais seulement cela ainsi :

L’erreur est humaine. La récidive est criminelle

… Magnifions notre condition humaine, mais combattons le crime.

Batman

Autre application que j’utilise beaucoup et souffrant le portage, Keynote (équivalent de Powerpoint, mais terrifroyablement plus génial, évidemment : au début de cette année j’avais une présentation dans le cadre d’une mission, et il s’est avéré que la visualisation sur iPad de cette présentation faite sur mon Mac n’était pas envisageable (rendu horrible sur certains slides). Dommage car ça en aurait mis plein la vue d’arriver avec mon iPad et le brancher au videoproj Et pour le coup, je ne me serais pas vu préparer la présentation sur l’iPad : l’insertion d’images par exemple aurait été un peu laborieuse…

Le seul cas où j’utilise mon iPad plutôt que mon MacAir, est les conférences sur au moins une journée, ou l’iPad est le seul à tenir la route en terme d’autonomie pour la prise de note. Sinon, pour rien au monde je n’échangerais mon MacAir contre un (autre iPad… Alors que j’échangerais bien volontiers mon iPad contre un MacAir 11 pouces… Sachant que j’ai un iPhone comme compagnon idéal du MacAir !!!

- les jeux (sur iPad)… Mais avec Chrome qui porte Hungry Birds sur tout ordinateur pouvant supporter Chrome, on ne va pas dans le sens de l’iPad

- enfin, tout ce qui touche à l’écran tactile…. Mais comme l’a fait remarqué st. : avec OS X Lion, les Mac sont prêts à recevoir des écrans tactiles… Ça plus les MacAir 11 pouces… Pourquoi acheter un iPad dans l’avenir ?… Si ce n’est pour plaisir à Madame et aux Schtroumpfs… Afin de s’accorder un peu de répit le temps de mettre une bonne mine au p’tit frère à Modern Warfar 2 sur PS3 )

PS: l’écriture de cette article ne m’a couté que 5% d’autonomie sur mon IPad

Je reviens d’un voyage *très itinérant* à l’étranger…

J’ai donc pris mon iPad et mon MacBook Air sur moi, mais je ne peux les utiliser que partiellement… Ce qui m’a permis de mieux cerner

les différences entre utiliser un iPad et utiliser un MacBook (Air)

et d’amorcer une réponse à cette même question que m’avait posée un collègue en début d’année alors qu’il hésitait à acheter l’un des deux…

Par contre j’oppose ici deux frères, l’iPad et le MacBook : je ne sais pas ce que cela donnerait dans les détails avec un cousin, à savoir l’iPad face à un PC portable…

Les plus d’un MacBook

Toutes les applications comme sur un ordinateur de bureau. J’ai entièrement développé une application iOS sur mon MacAir (xcode, Photoshop, Git…).

En particulier Dropbox, qui est devenu pour moi un outil central. Sur mon McAir, j’ai instantanément accès à l’intégralité de mon répertoire Dropbox, sans avoir eu besoin au préalable de marquer les documents importants comme Favoris, afin d’être certain de les avoir sur mon iPad.

Autre application que j’utilise beaucoup et souffrant le portage, Keynote (équivalent de Powerpoint, mais terrifroyablement plus génial, évidemment : au début de cette année j’avais une présentation dans le cadre d’une mission, et il s’est avéré que la visualisation sur iPad de cette présentation faite sur mon Mac n’était pas envisageable (rendu horrible sur certains slides). Dommage car ça en aurait mis plein la vue d’arriver avec mon iPad et le brancher au videoproj Et pour le coup, je ne me serais pas vu préparer la présentation sur l’iPad : l’insertion d’images par exemple aurait été un peu laborieuse…

Enregistrer aisément des documents, notamment des pièces jointes… Pourquoi ?… Disons que je souhaite les manipuler ou les partager… Dans le monde iPad cela signifie qu’il faut une intégration entre l’application qui met à disposition le document (par exemple Mails) et celle avec laquelle je souhaite le manipuler (par exemple Dropbox ou Bookman) : cela existe mais ce n’est pas aisé ou systématique. Au passage, il est vrai : finalement, pourquoi vouloir faire cette manipulation de “enregistrer sur le disque”… Mais j’y reviens en fin de conclusion…

L’historique de mes mails : je ne suis pas encore très performant quand à la gestion de mes mails, du coup je garde l’intégralité de mes 20’000 mails, soit plus d’1 Go, sur mon MacAir. Sur mon iPad, j’ai par défaut accès aux 50 derniers : pas plus tard que ce matin cela vient de me faire défaut pour la 2D fois en 2 jours ;(

Et si j’écris un mail, je peux aisément insérer une pièce jointe, voire plusieurs : je n’ai pas encore trouvé comment insérer facilement plusieurs photos à un mail depuis Mails sur iPad.

L’accès à certains sites web…

Je ne parle évidemment pas du flash : pour rappel, votre iPad est incapable de lire du flash… Flash est pourtant une réalité…. Mais Apple à le pouvoir de   changer la réalité… Et en fait sa raison d’être !

Mais je parle de certains sites, je pense par exemple à des sites de gestion de projet, avec des formulaires, qui ne passent pas très bien sur iPad… Mais cela semble être en train de s’améliorer.

Enfin, en voyage par exemple, le MacBook se pose comme une extension bien pratique de votre lecteur mp3 (pas seulement iPod), votre appareil photo…

Les plus de l’iPad

Sa taille… En était un, avant la sortie des Mac Air 11 pouces !

Mais son prix en reste un : si un iPad peut sembler couter une belle somme d’argent, il reste moins cher qu’un MacBook… Même si je viens de vous expliquer qu’il offre moins de possibilités.

Son autonomie… Là, je dis respect !

Ce qui en fait un (gros) iPhone :

• Sa puce 3G (si c’est un modèle avec puce)
• Le GPS
• L’écran tactile… J’y reviens en conclusion…
• L’acceleromètre
• Le clavier virtuel (est-ce un atout ?… Oui dans la mesure ou il est entièrement parametrable, y compris selon la langue… Mais si il était aussi pratique, pourquoi y aurait il des claviers physiques dédies comme périphériques ?!…)

Ma conclusion est double.

Le seul cas où j’utilise mon iPad plutôt que mon MacAir, est les conférences sur au moins une journée, ou l’iPad est le seul à tenir la route en terme d’autonomie pour la prise de note. Sinon, pour rien au monde je n’échangerais mon MacAir contre un (autre iPad… Alors que j’échangerais bien volontiers mon iPad contre un MacAir 11 pouces… Sachant que j’ai un iPhone comme compagnon idéal du MacAir !!!

Il y a trois choses qui je pense pourraient me faire changer d’avis :

• Les jeux (sur iPad)… Mais avec Chrome qui porte Hungry Birds sur tout ordinateur pouvant supporter Chrome, on ne va pas dans le sens de l’iPad
• Les “lecteurs évolués de contenu”, je pense par exemple à l’application iPad de The Economist, qui permet de lire les articles via un “conteneur” vraiment bien au delà d’un Acrobat Reader.
• Enfin, tout ce qui touche à l’écran tactile…. Mais comme l’a fait remarqué st. : avec OS X Lion, les Mac sont prêts à recevoir des écrans tactiles… Ça plus les MacAir 11 pouces… Pourquoi acheter un iPad dans l’avenir ?… Si ce n’est pour plaisir à Madame et aux Schtroumpfs… Afin de s’accorder un peu de répit le temps de mettre une bonne mine au p’tit frère à Modern Warfar 2 sur PS3 )

Peut être que la réponse est là : non pas qu’il faille acheter une PS3, mais “c’est pour Madame”… Je veux dire par là une Personae bien particulière, avec une utilisation bien précise, et j’ai envie de dire “réduite”, d’un ordinateur… Essentiellement du web (en excluant certains sites), du mail (sans trop jouer avec les pièces jointes), de la visioconf en famille (avec Skype ou FaceTime), et des jeux (pour elle seule ou avec son p’tit bout).

Enfin, avec le recule, l’écriture de cet article aura eu l’intérêt de me faire poser à chaque fois la question : “Mais pourquoi tu veux faire cela ? Et si tu en as vraiment besoin, pourquoi le fais tu ainsi ?”… Ce qui est globalement une bonne démarche, permettant parfois de tordre le coup à des habitudes antédiluviennes, et aberrantes de nos jours.

PS: l’écriture de cette article ne m’a couté que 5% d’autonomie sur mon IPad

PS2: Après avoir écrit ce post, je suis tombé sur 2 autres articles traitant du sujet

• IPad et/ou MacBook ?
• iPad ou MacBook ?

Mon safari photo a duré environ 30 minutes et j’ai du croisé un maximum de 10 personnes (voir en fin de post pour toutes les photos et vidéos) !…

Personne pour troubler le calme du Rhône

Depuis le quartier des banques en plein centre ville…

Le si actif quartier des banques

En passant par la très commerçante Rue de la Confédération

La très commerçante Rue Confédération

Jusque dans la vieille ville au pied de la cathédrale…

La tellement touristique vieille ville

… Sans oublie la Librairie Jullien, entre le bureau et la populaire Place de la Clémence !

A l'angle du bureau

Nous sommes en effet le 1er août, jour férié en Suisse : c’est la fête nationale.

Fête nationale Suisse

Assez déconcertant pour l’habitué de la ligne 13 de métro et la Gare St. Lazare aux heures de pointe à Paris…

Genève vraiment déserte !

Une experience somme toute déroutante…

… Toutes les photos sur Picasa et les vidéos sur Viméo (en cours d’upload : 4 au total) pour vous en convaincre !

Si vous souhaitez rencontrer des orateurs étrangers et francophones (Suisse, Quebec, France…), si l’agilité vous intéresse, quelque soit votre expérience, n’hésitez pas à jeter un oeil sur le programme :

http://xpday.agile-swiss.org/index.php?page=le-programme-2011

Et si vous êtes convaincus, poursuivez par le formulaire d’inscription : http://xpday.agile-swiss.org/index.php?page=les-inscriptions-2011

Et si vous êtes vraiment conquis, faites passer le mot, notamment sur Twitter via la mention @xpdaych

A très bientôt !

Il s’agit du retour d’une tranche de vie, que je pourrais résumer ainsi :

Ce que j’attend de mon gestionnaire de versions c’est qu’il soit comme une boite à bijoux, et non pas un labyrinthe dissimulant le Minotaure…

J’avais déjà fait 2 posts sur Git :

• J’étais cons-Git car je suis pro-agile… (1/2)
• J’étais cons-Git car je suis pro-agile… (2/2)

… D’ailleurs merci pour vos retours !

Ce matin, je suis en train de travailler sur un de nos projets iPhone : les sources sont sur Git, pour faire plaisir à Stephane (;o) et aussi pour me forcer à rentrer dedans…

Il est 11h17 : je change un champ depuis le studio studio graphique (“je mets l’attribut Tag à 0 dans InterfaceBuilder”) et je relance l’application. Là j’ai une erreur de compile me disant que les tag ne sont pas cohérents… Oups, j’ai glissé : du coup j’ouvre le fichier en question (le .xib)… Mais plus moyen de l’ouvrir : cela fait planter mon IDE (XCode) !

Ouaouh !… Trop malin que je suis, je décide d’ouvrir le fichier incriminé en mode texte (“Y en a la d’ans !”)… Et je tombe sur un fichier XML de 836 lignes contenant principalement des ID et autres nombres ésotériques… Et là, perdu au milieu de ce bruit, il y a le nombre qui me pose problème ;(

Décidément trop malin que je suis, j’ai alors l’idée de génie : “No problemo ! Je vais utiliser un outil trop puissant, *ET FAIT POUR CELA* : mon gestionnaire de versions !”

En effet, à quoi sert un gestionnaire de versions ?!… Quelle est la vocation première du gestionnaire de versions ?!… Pouvoir faire un diff ! Sinon la méthode qu’on utilisait avant les années 2000 suffisait largement : faire un ZIP à chaque version, le mettre dans un coin et en cas de problème je le ressorts !
“Mais non, le gestionnaire de version sert aussi à travailler en équipe, faire des merges, voire résoudre des conflits !”
… Ok, et tu fais quoi quand tu résous un conflit ?… Tu fais un diff !
CQFD.

Je cherche donc à faire un diff avec Git… Et c’est là que les problèmes commencent…

Je me rappelle d’une commande “git diff” que je m’empresse de taper dans mon terminal, me croyant vraiment trop malin (bien que ma confiance en moi ait quelque peu commencé à s’ébranler…). Et là mon terminal crache le diff d’un fichier XML de 836 lignes, tout en monochrome… Mais il a la gentillesse de me mettre des p’tits “+” en début de ligne pour attirer mon attention sur certaines parties… Trop cool

N’ayant pas été le meilleur copain de Néo à l’école, je n’ai pas appris à lire la Matrice… Je décide donc, dans un ultime sursaut d’ingéniosité, de me trouver un client pour MacOS… L’Internet Mondial, et Google son meilleur ami, semblent me conseiller GitX… Connaissant SvnX, je suis perplexe mais me sens obligé…

J’installe donc le GitX puis le lance… Et là, pas d’entrée de menu “Repositories” ou “Working copy”… Ni même d’entrée “diff”… Pas même l’aide semble avoir entendu parlé du key word “diff”… Alors que la démonstration scientifique rigoureuse ci-dessus à clairement démontré que c’était la vocation première d’un gestionnaire de version… Quand bien même que je vous accorderais dans un délire passagé que ce n’est pas la première, j’espère que vous aurez la politesse de m’accorder en retour que cela reste une fonctionnalité importante !

Le seul menu qui semble faire quelque chose est le menu “File > Open”… Il veut peut être que j’ouvre ma working copy ?!… Essayons… Ah oui, c’était bien cela… La fenêtre du bas semble être l’arborescence des fichiers… Je retrouve le fichier concerné… Toujours pas de commande “diff” à l’horizon… Que me dit le menu contextuel du bouton droit ?… Seule chose interessante le “Show history of file”… Ok, essayons : je brûle peut-être ?!… Ok, maintenant comment je fais pour faire le diff avec l’une des deux versions commitées et celle en locale ?!… Mais c’est un enfer… Les noms d’oiseaux commencent à fuser…

Bon, retour à mon meilleur ami, l’Internet Mondial : “how to view diff with gitx”… Et là, devinez quoi ?!… La première réponse est de nouveau une ligne de commande …

git diff v0.5 v0.6 | gitx

C’est pas trop fort d’utiliser une ligne de commande pour lancer un client qui a pour vocation de s’affranchir de la ligne de commande )
Suis trop enervé pour resister…

Je copie cela dans mon shell… Et j’en arrive à me demander : ok, par quoi je remplace v0.5 et v0.6 ???… Mais quelle est la version de mes fichiers ?… Comment la trouver dans mon client GitX ?…

25 minutes se sont écoulées… Il est l’heure d’aller manger avec Stéphane, laissant cette bataille à la machine !

Quoi ressortir de positif à celà ?

Quelles conclusions en tirer ?…

Je reste persuadé que la principale vocation d’un gestionnaire de versions est de répondre présent quand on a un soucis avec nos sources : Pouvoir faire simplement un diff entre deux versions… Git ne serait donc pas un gestionnaire de versions ?…

En tant qu’agiliste, je m’efforce de faire des logiciels qui répondent au besoin du client, et pour cela le logiciel doit s’adapter à lui, et non pas l’inverse… Ici c’est le contraire : ce n’est pas Git qui se plie à moi, mais c’est moi qui suit plié par Git… Il fait même de l’origami avec mes nerfs ! Si je n’apprend pas les arcanes de Git je n’ai aucune chance de pouvoir l’utiliser simplement pour les cas nominaux d’utilisation…

Je veux bien faire l’effort d’apprendre Git maintenant, mais il faudra que je refasse la même chose dans 5 ans avec son successeur, et rien que d’y penser, j’ai des frissons dans le dos en me demandant ce que la communauté va bien pouvoir nous pondre !…

Cela fini de me convaincre sur les outils en ligne de commande. Mon avis, maintenant bien tranché, sur ceux qui ne jurent que par les outils en ligne de commande, est le suivant :

• Soit se sont de pur geek – techos, et ce n’est pas péjoratif car je me revendique moi même de cette catégorie, mais pas sur ce que je considère être de la tuyauterie, de l’administratif, de la logistique.
• Soit ils n’ont pas confiance en l’outil graphique, et cela se comprend
• Soit l’outil ne répond pas assez vite, et là je comprends aussi…

Mais je ne suis pas payé par mon client pour passer du temps à maitriser mon environnement de développement en ligne de commande. Il me paye pour lui apporter de la valeur ajouté. Aussi, le gestionnaire de versions est fondamental dans mon métier, mais je ne devrais pas avoir à subir un apprentissage couteux pour mettre en oeuvre les cas d’utilisation standards. Clic-droit sur le bon fichier et diff : à lui de gérer le fait qu’on soit passé de CVS, à SVN, à Git puis à VCS2020…

D’où ma métaphore d’introduction :

Ce que j’attends de mon gestionnaire de versions c’est qu’il soit comme une boite à bijoux, et non pas un labyrinthe dissimulant le Minotaure…

Mes bijoux, ce qui fait ma valeur et pour quoi je suis payé, se sont mes sources. Pour les déposer, je cherche une boite à bijoux pratique, intuitive, qui me permette de ne pas perdre mes bijoux et de les retrouver facilement.
Je ne veux pas un labyrinthe qui m’oblige à connaitre par coeur le plan du labyrinthe pour retrouver mes bijoux.

C’est marrant que cela m’arrive ce matin, le jour même où je vais au Mardi Gras Hortis consacré à Git : je serais peut être plus détendu ce soir au retour

En tout cas, le fait de vous en avoir parlé dans ce post cathartique me détend : je vais pouvoir retourner faire mon diff

Comme je vous le disais en introduction de la première partie de mon article (“J’étais cons-Git car je suis pro-agile… (1/2)“), j’ai commencé il y a plus d’un an maintnant un article en deux partie sur mon irritation envers ceux qui me semblaient aveuglèment pro-git.

Voici donc la seconde partie de cet article.

Encore une fois j’en appelle à votre clémence : cela remonte à plus d’un an… N’hésitez pas à me faire part de vos remarques.

A la suite de ma première réflexion (“J’étais cons-Git car je suis pro-agile… (1/2)“), Stephane a eu la bonne idée de m’aiguiller vers cet article de Schott Chacon : “Why You Should Switch from Subversion to Git“. Cela m’a permis d’affiner mon idée sur les conseils même d’un des auteurs du livre et acteur de Github.

J’en ai profité pour préciser le titre du post !

Je constate une montée en puissance de Git sur Subversion (migrations des repositories) dans les projets Open Source… Comme Subversion l’a fait il y a quelques années avec CVS…

Je suis critique non pas par obsession ou fétichisme envers SVN, mais je cherche à comprendre l’intérêt avant d’y passer éventuellement. De plus, je tiens à dire explicitement que j’aborde Git sous un angle d’équipe XP, avec les principes qui guide le fonctionnement d’une telle équipe…

Git : anti-XP ?

1) Tout est local donc super rapide…

Ok, cela est un argument recevable dans un environnement XP qui doit être optimisé. Mais si je rajoute les étapes de synchronisation entre le repo local et le repo distant, je pense que l’on ré-quilibre les durées.

2) Des repo partout si ca coupe.

La redondance du serveur est une problématique qu’il ne faut pas résoudre en faisant des copies sur chaque poste !… Et de toute facon, si ça plante laquelle on prend ? Lequel a synchronisé son repo local en dernier ?
Si le serveur plante avec Subversion, la copie locale permet de continuer à travailler : ce qui est impossible est la synchronisation avec le repo distant, ce qui correspond à un commit (précédé d’un update/merge). Ce qui arrive toute les 2 heures environ pour les équipes extrêmement XP, et tous les quelques jours pour la majorité des équipes. Bref, cela laisse le temps de remonter le serveur.

3) Un workflow “incroyable”.

Là, pour le coup, je suis d’accord ! C’est incroyable. C’est le seul point sur lequel j’avais encore un doute, mais il a fini de me convaincre.
Il cite deux exemples de workflow qui font la force de Git… Deux exemples qui ne correspondent absolument pas au fonctionnement d’une équipe XP.
Le premier est celui de l’écriture de son livre (avec les 34 merges) : si j’ai bien compris, lui, “responsable de la branche main”, du contenu du livre, pioche et intègre selon son bon vouloir les ajouts, remarques, modifications et autres corrections des autres contributeurs, sous la forme de merge de branche. Ce fonctionnement décisionnel est l’inverse de celui d’une équipe de développement, et pas seulement XP : ce n’est pas un responsable du tronc qui décide de l’intégration, mais bien le réalisateur de la correction/évolution, de la branche, qui décide ou non d’intégrer quand il a fini.
Quand au second exemple avec un QA guru master qui a les pleins pouvoir d’intégration… Le schema pourrait figurer sans aucune honte dans une brochure IBM… Le prochain stade est la création d’un rôle d’administrateur/expert workflow Git facturer très cher la journée pour administrer le workflow chez le client… A mais je suis bête, cela existe déjà… Si si : ClearCase !
Il dit qu’on peut imaginer tous les workflow possibles. Ok, voici le mien, voici mon besoin : un repository dont je récupère le contenu, je fais ma micro-tâche, je la teste, si c’est ok je l’injecte dans le repo pour que tout le monde en bénificie dés maintenant… Ah mais cela existe aussi : SVN ;o)

4) Le déploiement sur Heroku.

Là, pour le coup, je suis vraiment intrigué. Cette fonctionnalité semble vraiment très séduisante sur le papier, car c’est un manque récurant chez de nombreux client pour lesquels j’ai travaillé : le déploiement des livrables dans l’environnement de production.
Le fait de pouvoir faire un ‘push’ sur un repo distant heroku (“repo de production”) pour délivrer.
Je vais creuser cette fonctionnalité avec intérêt.

5) Lightweight Branches: Frictionless Context Switching

Wouaouh ! J’ai l’impression qu’on mélange plusieurs choses…
a- le temps d’exécution : c’est bon, on a compris que c’est en local et que c’est plus rapide, mais on ne va pas tout le temps y revenir. Et puis quand on merge, le plus comsommateur en temps n’est vraiment pas la durée des traitements de l’outil, mais bien le temps qu’on passe à vérifier la cohérence du merge.
b- pourquoi autant de branches dans tous les sens ??? Je ne cache que d’experience j’ai développé une allergie vicérale aux branches et aux merges… Mais, cette peur mise de côté, je ne vois pas de raison objective pour un développeur de créer volontairement des branches à foison ! Un développeur qui travaille sur une tâche, va réaliser sa tâche, éventuellement dans une nouvelle branche. Admettons qu’il ait besoin de faire un refactoring en cours de tâche : il crée éventuellement une seconde branche, et c’est tout ! il va alors terminer son refactoring et merger sa 2nde branche avant de revenir à sa première branche : là, il va certainement commencer par synchroniser cette 1ere branche, car je pense qu’il a besoin de son refactoring pour continuer ?!… Puis il continue sur cette première et unique branche. Encore une fois, l’exemple qu’il donne avec son livre et les 34 merge (donc 34 branches) n’est pas celui d’une équipe de développement.

6) staging area

Là, je pense avoir mal compris… D’après l’auteur, Git permettrait de faire des commit “sémantiques”, par lot, mais pas SVN ?!… Dans SVN, il ne serait pas possible de faire des commits par groupe de fichiers choisis ?!… Biensûre que si ! Et là encore, cela est un “bad smell”. Les fois (trop nombreuses hélas) où j’ai du faire cela (commiter une partie seulement des fichiers que j’avais modifiés pour faire ressortir le fait que ces fichiers étaient liés), correspond à des fois où il s’est passé du temps, braucoup trop de temps (plus d’une journée), entre mes 2 commits successifs. De plus, si on considère que l’on ne doit commiter qu’une configuration testée, la configuration qui correspond au repo avec les quelques fichiers commités n’as pas été testée sur le poste du développeur (puisque d’autre fichiers modifiés y sont aussi). Au final, comment peut on faire un commit en toute tranquilité autrement qu’en recherchant tous les fichiers modifiés sur le poste et de les commiter d’un seul bloc ? La bonne pratique consiste donc à mettre en place des mécanismes qui favorisent le fait qu’on ait peu de fichiers à commiter à chaque fois !

7) stage parts of files

Je me suis effectivement retrouvé sur des projets où après avoir fait un CTRL+SHIFT+F dans mon IDE préféré pour reformater automatiquement le code, 96% du fichier était considéré comme modifié, alors que je n’avais modifié que deux lignes. Cela m’est vraiment arrivé dans ces proportions ! Dans ce cas, ma technique est de commiter une première fois le fichier avec aucune modification sauf le reformatage, et un message de commit dans ce sens. Puis dans un 2nd commit, il n’y avait cette fois que les 2 lignes modifiées. Mais là encore, c’est un bad smell XP. En XP, une des pratiques est la propriété collective du code. Hors, comment peut on se promener partout dans le code comme si c’était le nôtre alors que chacun à sa propre façon d’écrire le code et de le formater ? La bonne pratique consiste à mettre en place consensuellement des conventions de codage.

craft your commits

Là, je n’ai as encore compris, sans ironie aucune.

9) Not Just for Teams of Coders

Alors là, je veux bien parier une bière ;o) Moi qui suis technicien depuis 10 ans, il m’a fallu plusieurs heures de lecture, d’utilisation, de réaction à des posts de blog pour sentir la philosophie de la gestion de version décentralisée, et l’auteur voudrait me faire croire que des non codeurs accèptent aiséement le schmilblicks et rentrent facilement dedans ?!… Mon estime de moi en prend un sacré coup

10) In closing

“a number of really good free resources online to help you learn and use Git” : c’est pas bon signe si il y a besoin d’un aussi grand nombre de ressources pour utiliser Git ;o)
“you have to use a typewriter instead of a computer”… Là je suis d’accord !… Et XP prône l’utilisation de la fiche cartonnée (SVN ?) ;o)

11) Essayer une idée chez soi le week end

En quoi svn avec ses traditionnelles copies de travail locales freinent ce papillonage ??? Effectivement, ces copies locales ne permettent pas de travailler durablement coupé du repo distant. Par contre je ne suis pas sure qu’il y ait beaucoup d’environnements de développements qui permettent d’être coupé de cet environnement, de travailler chez soi (serveur d’application, base de données, gestionnaire de bug…). Remarque je ne suis pas sure que cela soit une bonne chose en soi. Par contre, là encore je crie au bad smell. Si c’est occasionnel de travailler chez soi le week end (une fois par millenaire), le développeur n’a peut être pas besoin d’être branché au repo distant. Et dans le cas contraire, cela n’est pas compatible avec le binômage et les autres mécanismes de propriété collective du code, et de connaissance diffuse dans l’équipe (réunions de conception improvisées…).
Je pourrais par contre voir un intérêt de travail à distance dans le cadre d’une session chez le client, par exemple une phase de prototypage ou d’écriture de tests d’acceptation avec lui en Cucumber… Mais en XP le client est sur site (en tout cas on essaye ;o)

Soyons agile : revenons un peu au besoin !

Qu’est ce que je demande à mon gestionnaire de version ?

Centraliser une version cohérente de l’ensemble de mes fichiers
…
Avec le recul, cet engouement pour Git, au lieu de faire penser à celui de Subversion à l’époque, me fait plutôt penser à celui pour J2EE et les EJB…

Au final, toutes ces nouvelles fonctionnalités, branching facilité (dans tous les sens ?), staging area (commit au bon vouloir… au hasard ?), stage parts of files (je code comme je veux !), la notion même de décentralisation (peu/pas compatible avec le binômage et la connaissance diffuse dans l’équipe) semble être la porte ouverte à des pratiques anti-XP voire destructrices sur un projet XP. S’ajoute à cela le temps de compréhension de la notion de décentralisation et le temps que l’on passe à merger et synchroniser. Je suis définitivement convaincu qu’il n’y a aucun intérêt et aucune raison à brancher et merger à foison, ce qui est l’argument de vente no de Git.

Sinon ok, on peut utiliser Git, mais alors de la même manière que SVN ;o)

Au final, la critique de cet article m’a fait passé du stade de curieux interrogatif à celui de réfractaire effrayé pour ce qui est de l’utilisation de Git dans une équipe XP (donc centralisée). La seule interrogation ouverte, est l’utilisation dans le cadre du pull sur un repo de production pour déployer les livrables en environnement de production : à creuser.
Je me pose la question uniquement du repo qui contient tous les documents de la société (si on ne souhaite pas de GED) : brochures et propositions commerciales, CV des collaborateurs, originaux des cartes de visite, du logo… Dans ce cadre, les éditeurs/commiteurs d’un même fichier ne sont pas légion et surtout la plupart de ces fichiers sont au format binaire : quid des branches et des merges ?
Par contre, je suis définitivement convaincu de l’intérêt de la gestion de version décentralisée pour le versioning de mes fichiers personnels afin de pouvoir facilement les editer en déplacement. Mais là on est plus dans un environnement d’équipe, mais bien individuel, et donc peu voir aucun intérêt pour les branches et les merges. Et là, je préfère utiliser SVK, car en tant qu’extension de SVN, il peut être branché sur n’importe quel repository SVN existant.

Enfin, je n’ose émettre aucune critique quand à l’utilisation de Git dans une équipe de développement “traditionnelle” (non XP), ou sur un projet open source et/ou une équipe décentralisée.

Au départ il devait s’agir que de la présentation d’iStoriz, mais au fil des mails avec Seb, il a été envisagé que je présente succinctement l’agilité (sachant que iStoriz manipule le concept de User Stories).

Et puis, étant donné que je viens de terminer ma mission de Scrum Master de l’équipe de développement iPhone de ViaMichelin.fr, s’est posé la question de faire quelques slides sur la mise en oeuvre de l’agilité dans un contexte de développement iOS.

Nous étions 9, mais j’ai apprécié de voir de nouvelles têtes. Je devais parler trois quarts d’heure, la session a finalement durée deux heures.

Comme je l’avais proposé à Sebastien, j’ai fait un ROTI en fin de session pour éveluation le niveau de satisfaction des participants…

Pour rappel, le ROTI consiste à demander aux participants, en fin de session, tous en même temps, de noter sur 5 (en levant une main avec le bon nombre de doigts) un élément de la session. A la question “Qu’avez-vous pensé de ma prestation”, j’ai eu les notes suivantes :

• 1 note de 3 sur 5
• 5 notes de 4 et
• 2 notes de 5

soit une moyenne de 4,1 sur 5

Ensuite on demande aux participants de donner des ” + ” (des choses à conserver) et des ” – ” (des choses à améliorer ou supprimer). Voici leurs remarques :

• Les ” plus ”
  • Je n’ai pas décroché en 2h !
  • J’ai appris des choses
  • Session vivante
  • Bon orateur, à l’aise, interessé par le sujet
  • Charisme et elocution
  • De bons slides
  • J’ai une sympathie pour cette méthode, donc pour la présentation
  • Session participative
  • Bien synthéstisée
  • La vue iOS d’un développeur JEE…
• Les ” moins ”
  • … La vue iOS d’un développeur JEE
  • Je ne me sens pas trop concernée dans l’imédiat
  • Manque de conseils concrets à appliquer (lié à la taille de ma structure)
  • Je ne suis pas expert en agilité, je ne suis donc pas apte à mettre 5/5
  • L’orateur n’était pas habillé assez court
  • La partie iOS était trop courte
  • Plus de questions posées que de réponses apportées
  • Manquait une partie technique sur les tests et l’intégration continue
  • Je connaissais la théorie (agilité) : j’ai eu beaucoup de réponses à mes questions

Ma conclusion sur cette session…

Tout d’abord le fait que des “opportunistes” (de plus en plus ?) semblent pointer le bout de leur nez dans l’écosystème du développement iOS : vu la pénurie actuelle de développeurs iOS, il y a fort à parier que ces personnes vont très bientôt se retrouver dans les équipes de développement iOS et qu’il faudra composer avec eux.

Une bonne remarque qu’a faite Eric : Apple a fédérer de nombreux développeurs avec son programme développeur iOS (les chiffres de 80’000 nouveaux adhérents par mois et la barre du million à la fin de l’année ont été lancés – à vérifier, sous toute réserve). Et avec l’arrivée de Lion (Mac OS X.7) et son “Back to Mac”, la récupération de cette manne de développeurs pour les développements Mac desktop cette fois est en route…

Le manque de maturité de la plate-forme de développement iOS pour des problématiques d’équipe : tests fonctionnels, intégration, déploiement automatisé…

A ce propos, il a été dis que ces développeurs JEE qui se mettent à l’iOS (et auxquels on m’apparente) cherchent à tous pris à injecter de la “rationnalisation” (ou de l’agilité)… bref, un peu de processus, dans un monde qui n’en n’a pas… Peut-être parceque il n’en n’a pas besoin. Pour éviter tout mal entendu, mon point de vu est le suivant : je ne pousse pas à faire de l’agilité à tout pris. Faire de l’agilité, voire de l’XP, implique un “surcoût à l’achat” (c’est un investissement, un peu comme ceux qui peuvent se payer une maison en pierre plutôt qu’en préfabriqué…). Si vous êtes certain que vous pouvez faire seul votre application, en quelques jours seulement, et qu’il n’y aura pas de maintenance évolutive : foncez, et oubliez l’agilité ! Par contre, si vous devez bosser à plusieurs pour tenir une première échéance serrée, et qu’il y a d’autres livraisons ensuite, peut-être avec d’autres développeurs… Là, ça vaut peut être le coup de se poser des questions sur une bonne façon de procéder ?!… Cette problématique du processus est liée à la taille du projet / de l’équipe et non pas à la techno (Java ou iOS).

Au final, j’ai pris sur moi de comparer le monde iOS maintenant à celui du développement PHP il y a 10 ans : on part de mercenaires opérant seuls et on arrive une plate-forme devant encaisser des développements en équipe plus ambitieux… Le monde iOS semble avoir atteint l’âge de la puberté : comment va s’opérer le passage à l’âge adulte ???…

Merci aux participants pour cette enrichissante session.

Télécharger les slides au format PDF

Une des gue-guerres internes au royaume inagua, est la confrontation fratricide entre Stephane GIT et Jacques SUBVERSION…

J’avais donc écrit il y a un peu plus d’un an maintenant un draft de pamphlet à l’encontre de Git, et m’étais promis de le publier avant que je change d’avis…

Or, comme je sens que je suis en train de changer d’avis, il est urgent que je publie ce premier article !…

… Merci Bobo pour tes arguments qui me permettent d’évoluer !

Remarque : Etant donné que j’ai virament du mal avec cette philosophie Git (comme vous allez pouvoir le lire , je me suis fait un aide mémoire des principales commandes sur mon wiki. Le fait même qu’on ait besoin de ce genre d’aide mémoire signifie soit que je suis atteint de déficience mentale, soit que cet outil est d’une complexité nuisible… J’aime à croire que la première hypothèse n’est pas la bonne

Le 09/09/09, quelque part au bord de la Méditerranée…

Depuis que j’ai découvert Git, je suis resté dubitatif sur l’intérêt des Gestionnaires de Version Distribués (GVD). C’est pour cette raison que j’ai décidé de l’utiliser pour gérer un projet personnel pendant plus d’un mois.

Au final, je n’étais toujours pas convaincu. Je n’y ai pas trouvé d’intérêt, mais par contre des aspects bloquants.

• Par exemple, je n’ai pas trouvé comment obtenir du repository qu’une partie du projet sur lequel je travaillais. Si j’ai une partie serveur et une partie IHM, ou une partie Rails et une partie Flex, je n’ai pas besoin de récupérer l’intégralité du projet pour travailler.
• Autre problème : j’ai par mégarde mis sous gestion de version le fichier de log des développement qui existe lorsque l’on développe en Rails. Ce fichier grossit rapidement. A la fin, il m’était impossible d’obtenir une copie locale sur un nouvel environnement, car la recopie échouait en raison du fichier trop volumineux ! J’ai commencé à partir sur une mise à jour de mon environnement de développement sous Mac OSX… Voire à une recompilation de mon client Git… Bref, des considérations bien loin de mon projet.

Je veux bien reconnaître que ces problèmes puissent être du à ma méconnaissance du logiciel, Git, et aussi de la philosophie, la gestion de version décentralisée.

Mais je pense que la principale raison au fait que je sois réfractaire, tient au fait que je ne vois aucune limitation actuelle, aucune lacune, imputables à mon chouchou : Subversion (SVN pour les intimes).

En effet, SVN a de tout temps répondu à mes attentes, sur des projets “tout-seul” comme des projets à plusieurs développeurs pendant plusieurs années.

La seule situation, selon moi, où SVN était en défaut est celle qui m’a poussé à persévérer dans mon utilisation des GVD. J’ai souvent eu des temps de transport assez long pour aller travailler. Ce temps était propice à travailler. Or, impossible de pouvoir faire un commit dans le train : je n’avais pas l’Internet Mondial ! J’en étais arrivé au point de m’installer un serveur SVN sur mon portable, mais la synchronisation n’était pas aisée quand les véritables repositories étaient multiples (projets différents). Lorsque j’ai entendu parlé des GVD, j’y ai vu la lumière !
Etant donné que je maîtrise et apprécie SVN pour mes besoins quotidiens, j’ai donc persévéré sur une extension à SVN qui en fait un GVD : SVK.

Le premier, voire principal, intérêt de SVK est justement que c’est une extension à SVN. Vous pouvez donc installer SVK sur votre portable et vous “brancher” sur un repository SVN quelconque : vous pourrez travailler à votre rythme avec SVK sur le projet, alors que les autres continuent de travailler avec Subversion sans même avoir entendu parlé de GVD !
Le principe de SVK est de créer un miroir du repository central/distant sur votre poste, miroir qui sera pour vous le “nouveau” repository de référence. Vous pouvez donc travailler avec ce miroir sans contrainte (en déplacement par exemple). Et lorsque que votre connexion internet préférée redevient accessible, vous synchronisez alors votre miroir au repository distant. Seule ombre au tableau, le “merge” peut s’avérer “conflictuel” si vous êtes parti longtemps ou si vous êtes nombreux sur le projet.
Donc, SVK en particulier, et les GVD en général, répondent parfaitement au besoin du geek solitaire que je suis, qui souhaite versionner ses projets et ses documents.
Mais devant cet engouement croissant pour Git notamment, je ne peux m’empêcher de m’interroger sur l’intérêt de ces outils sur des projets professionnels traditionnels où l’équipe est regroupée.

Quel est l’intérêt d’avoir un miroir sur son poste ?

Le principal argument que j’ai entendu est “si tu n’as plus de réseau !”. La copie locale d’un SVN traditionnel, permet quand même de travailler librement… Jusqu’au prochain commit ou update il est vrai. Mais c’est déjà une étape par rapport aux vues dynamiques sous Clear Case, où la copie de travail est un disque monté, les sources étant distantes… Soit disant pour protéger le développeur d’un crash de sa machine. En 2 ans d’utilisation, ma machine n’a pas crashé, par contre le serveur Clear Case lui oui, et par deux fois, paralysant tout le plateau immédiatement ! Mais cela sera certainement l’objet d’un autre post ;o) Un miroir local permet donc de se prémunir d’une coupure réseau, mais au prix de quel complexité supplémentaire (synchronisation du miroir) !… Et puis, si le réseau tombe, de nos jours, je ne connais pas beaucoup de développeurs qui peut encore continuer à travailler (besoin d’internet, d’un serveur d’application, d’un serveur de librairie (Maven), du gestionnaire de bug, du mail…).

L’autre intérêt que j’y vois éventuellement, est lors d’un développement en parallèle. Le seul type de cas qui me vient à l’esprit est ceux que j’ai rencontrés : un refactoring. Je suis en train de réaliser ma tâche, et je me rend compte qu’il faut que je fasse un refactoring pour cela. Je pars donc sur une autre branche, une autre copie locale, réalise mon refactoring, commit ma seconde branche, puis revient sur ma première copie locale que je synchronise avant de continuer (pour récupérer le refactoring). Mais cela peut se faire avec SVN : SVN n’empêche en rien d’avoir plusieurs copies de travail sur son poste. SVK et les GVD facilitent peut être le merge des branches.

Quel est le danger d’avoir un miroir sur son poste ?

Je ne vois donc pas vraiment d’intérêt inestimable dans les GVD, par contre j’y vois un risque majeur. Autre argument que j’ai entendu : “avec Git, je commit le soir avant de partir sur mon miroir sans polluer les autres”. Argh ! L’eXtrême Programmeur que je suis ne peut s’empêcher de grincer des dents à l’entente de ces mots ! Un des points sur lequel on discute en XP est que chaque soir, avant de partir, soit tu commites sur le référentiel distant car tous tes tests sont ok, soit tu jettes ton code. Cela peut faire hurler, mais cette pratique ne vient pas seule. Il est liée au fait que l’on est censé commiter plusieurs fois par jour, voire de l’ordre de l’heure. Cela force à découper son travail en micro-itération, et donc à limiter l’effet tunnel même sur l’ordre de grandeur de la journée. Je vous rassure, au risque de faire hurler mon premier coach XP, je ne l’ai pas toujours (souvent ;o) fait. Et c’est pour cela que je monte inagua, pour me donner les moyens de le faire et voir si cela fonctionne avec du sens.

Donc, si l’on permet aux développeurs de faire des commits n’importe quand, cela risque de perturber cette habitude au commit propre et fréquent.

Donc, si les intérêts sont minimes, mais les risques possibles, pourquoi rajouter une couche, de la complexité, la synchronisation, à des outils qui répondent déjà à notre besoin ?

Je parle bien ici des projets traditionnels, avec une équipe regroupée et des besoins provenant d’un même pôle. Je ne parle pas des projets Open Source par exemple.
Je n’adresse pas non plus ici la dimension au delà de Git : Github. Ce site sort en effet du simple cadre de la GVD. N’ayant pas d’expérience ni de recule sur Github, je reste curieux sur le sujet.

J’espère vous avoir transmis mon sentiment que le gestionnaire de version est suffisamment structurant dans la façon de travailler qu’il faut le manier avec précaution. Son utilisation est directement liée à votre méthode de développement : une aiguille peut soit vous servir à recoudre les chaussettes en laine préférées de votre grand mère, soit à faire du vaudou sur le totem de votre supérieur despotique…

En relisant cet article avant de le publier, je me rend compte que j’ai une vision différente sur certains aspects : de l’eau à coulé sous les ponts depuis, tant mon esprit que les outils ont évolués. Mais je publie quand même cet article tant pour voir le cheminement de mes pensées que pour appeler à la discussion…