Les furets sont au chtijug !

Tout ce qui est présenté est disponible sur GitHub, avec d’autres choses …

Donc, les furets font de l’assurance. Et ils ont fait d’abord différents sites au look … discutable.

En terme de code, actuellement, il y a 450K lignes de code, et un déploiement en prod par jour. Ca change pas mal des clients avec un déploiement par semestre …

DomainModel.stream()

A quoi ça sert

La classe Person, chez eux, est … grosse, et riche d’héritage. Normal pour un projet qui a 7 ans. Et évidement, ce modèle circule dans l’entreprise, du client Javascript à la base backoffice qui reprend les données sous des formats différents.

Evidement, comme c’est compliqué, ils ont cherché à simplifier tout ça, en utilisant globalement des domaines orientés colonne :

  • clé/valeur dans le client
  • modèle colonnes dans Cassandra
  • Vecteurs de données dans la base analytics

Du coup, utiliser un dictionnaire de clé partout devrait simplifier les choses.

Pour la suite, on va travailler sur un modèle simplifié.

Premier souci : comment ça se passe quand on a des relations 1-n ? A priori, « ca marche » … personnellement, je n’y crois pas trop, mais admettons.

Il y a aussi le souci des champs accessibles par plusieurs chemin, qui cette fois-ci sont dupliqués dans les données disponibles.

Et passons tout de suite au livecoding.

Manipulation simple du modèle

Donc, on a d’un côté notre modèle objet traditionnel, et de l’autre, grâce à un wrapper généré par l’outil des furets. Dans ce wrapper orienté clé/valeur, écrire des données se fait avec un simple

SampleModelWrapper.set(FieldId, value)

lire des données se fait simplement avec un

SampleModelWrapper.get(FieldId)

Et en terme d’implémentation, ça se fait facilement en générant des lambdas (évidement, avant Java8, ça aurait marché tout aussi bien avec des classes internes, mais bon, les lambdas sont à la mode). Et, en plus, l’inférence de type semble assez faible, puisque le type contenu dans le FieldId ne suffit pas à contraindre suffisament le type de sortie.

Manipulation avec des streams

Donc évidement, faire SampleModelWrapper#stream() retourne toutes les valeurs du modèle. Et on peut transformer les valeurs en map en traversant le même stream. Pratique, mais pas exceptionnel. Même si le speaker n’est pas de cet avis. Et en un sens, je le comprend, puisque le mapping est traditionnellement un problème compliqué : regardez Jackson/JAXB et autres qui galèrent pour bien faire les mêmes choses.

Petit bonus : on peut filtrer les éléments du wrapper selon différents tags, qui sont définis librement dans le wrapper. De cette manière, par exemple, on peut séparer les données du User et de l’Account du modèle d’exemple. Evidement, ça peut aussi servir à affiner l’accès à certaines interfaces selon les droits des utilisateurs.

A noter que le site des furets a environ 1000 clés dans les différents enums défnissant les modèles utilisés.

Introspection

Typiquement, quand on veut mettre les données dans une base Cassandra ou autre, il faut d’abord créer les colonnes typées associées, pour lesquelles on va naviguer le modèle, et pour chaque élément du modèle, on va créer une colonne dont le type sera obtenu grâce au FieldInfo correspondant à chaque champ.

Evidement, pour moi, il est assez curieux de voir des gens réinventer des notions analogues aux BeanInfo / PropertyDescriptor disponible dans le vieux monde des JavaBeans. Mais dans l’ensemble, ça fait le job assez (peut-être trop, en fait) simplement. Trop simplement, parce que par exemple, les annotations portées par le modèle initial ne sont pas transportées à travers le wrapper.

Conclusion partielle

Je comprend tout à fait l’intérêt de mapper un modèle de beans vers des séries de colonnes. En revanche, l’implémentation, certes joliment Java8, manque quand même de certains aspects clés : la gestion des collections fait vraiment peur, l’introspection est fichtrement limitée.

Cela dit, ça doit clairement bien limiter la complexité de la sérialisation, de la création d’interface graphique, ou même de persistence (non relationnelle, évidement, parce que sinon, c’est évidement merdique).

Il y a en fait là-dedans une idée très intéressante qui a sans doute un rapport certain avec le NoSQL. je m’explique. Lorsqu’on codait il y a dix/quinze ans avec une base de données relationnelle, avoir du code proprement décomposé était une bonne idée. Maintenant que la plupart des outils de stockage sont dénormalisés, à typage faible, bref, merdiques en terme de support des liens sémantiques, avoir un modèle riche est presque une gêne. Et c’est dans ce cadre que ce système de wrapper de modèle présente un intérêt.

Continuous delivery

Bon, si vous ne savez pas ce qu’est le continous delivery, c’est assez simple : c’est l’idée de pouvoir envoyer du code en prod au plus tôt. Et actuellement, les furets font plusieurs mises en prod par jour.

Historique

D’une façon amusante, en 2012, ils faisaient une MEP par mois, parce que leurs sprints SCRUM duraient un mois. Les tests étaient joués en fin de sprint et pouvaient entraîner des retards de MEP du fait de tests à corriger. Pas très pratique …

En 2013, ils ont tenté d’accélérer les choses avec des sprints « bonus » d’une semaine. Le premier impact est que le temps de build est passé de 15 mn à 3 mn.

En 2014/15, passage à Kanban avec une release chaque jour : les fonctionnalités sont marquées finies dans Kanban quand elles sont en prod. L’impact, évidement, c’est que la release est passée d’une journée entière à 2/3 heures. L’autre impact, c’est que les tests ont tous été automatisés. Histoire de se rassurer, les fonctionnalités passent quand même dans un environnement de staging pendant une journée pour vérifier que tout va bien.

Pour le futur, l’objectif est de livrer encore plus vite : les fonctionnalités devraient apparaître presque une par une en prod.

Curieusement, les MEP apportent toujours autant de code, voire même plus, parce qu’il y a beaucoup plus de fonctionnalités dedans.

Quelques aspects techniques

En-dehors des classiques environnements, il y a quelques points notables.

Les tests sont joués en parallèle sur un grid selenium, qui tourne sur une machine avec un RAMFS (128 Go de RAM chez OVH pour 300 €/mois).

Ils développé Zeno qui va sur une URL pour faire une capture d’écran. Et qui fait la différence entre la prod et la préprod. De cette façon, on peut vérifier que les différences visibles sont bien liées aux fonctionnalités développées (et pas à des bugs, par exemple). Cet outil pourrait par exemple être utilisé pour faire de la veille concurrentielle.

Evidement, le développement se fait en mode blue/green. Avec un double cluster.

Continuous delivery en détail

Il y a en gros 3 modèles de développement

  • trunk based : tout ce qui est dans le trunk part en prod. Ca implique le feature flipping qui est du code en trop.
  • feature branching : tout les dévs sont fait dans des branches, qui sont réintégrées dans le trunk au moment de la MEP. Ca pose évidement des problèmes d’intégration continue.
  • Et pour finir, le modèle github où le code est développé dans des branches, et réintégré dans le trunk via des pull requests, qui passeront dans l’intégration continue.

La grande astuce des furets pour simplifier tout ça est de tester les merge rapidement. Grâce à ce qu’ils appellent le continuous merge : lorsqu’un développeur a fini un développement, il est poussé sur un repository qui contient toutes les nouvelles features branches, et qui tente de les merger et de déployer le code sur l’environnement de staging.

git octopus

Chez eux, les branches en cours de dev s’appellent studies/ et celles qui sont finies s’appellent features/. Pour merger tout ça, ils ont un script appelé git octopus disponible sur github. Le truc magique, c’est qu’il peut détecter les conflits entre les branches à merger avant le merge final.

Pour résoudre les problèmes qui arrivent … ben là, essentiellement, c’est du git-fu (et vous savez ce que j’en pense). En fait, c’est pas vrai : tout ce qui est dit est également valable avec Subversion … et j’ai bien l’impression que c’est ce que gigomerge (mince, j’aurais bien mis le lien, mais je ne le retrouve plus) permet d’une certaine façon.

Pour faciliter la gestion des conflits, ils ont également créé un outil de gestion des conflits … qui en fait se contente de créer un workflow d’escalade des exceptions.

Conclusion

Deux présentations très intéressantes, faites par des gens qui se soucient manifestement beaucoup de ce qu’ils livrent, et de la façon dont ils le livrent. Il y a là-dedans des choses vraiment très intéressantes (git octopus, conceptuellement, est très bien, et cette histoire de repository définissant le niveau de maturité d’une feature est également très chouette) D’autres sont en revanche plus discutable (la résolution de conflit me paraît plus de l’ordre de l’astuce que de la solution vraiment propre).

Mais surtout, ce qui apparaît, c’est que, contrairement à bien des boîtes, ils ont l’ambition de se voir comme une boîte de développement logiciel, ce qui implique de produire de la qualité et de la visibilité. C’est sans doute ce qui leur permet de recruter des pointures, puisque nos deux intervenants paraissaient particulièrement compétents.

Je déteste encore git

J’ai déja écrit que je détestais git ? OUI.

Mais, en un sens, ce que je déteste au moins autant, c’est de me faire prendre pour un con.

Tiens, par exemple, quand j’écris un peu énervé

C’est quand même un peu vexant de se voir répondre

Me dire ça, à moi … Me dire que la meilleure façon d’utiliser cet outil difficilement compréhensible, c’est passer par nodejs et chromium … mon dieu.

Et puis, surtout, mon problème n’a rien à voir avec git en tant que tel, mais plus avec la façon foireuse de git d’utiliser la configuration système. Regardez un peu la question StackOverflow que j’ai posé à ce sujet … c’est assez merdique.

Cela dit, quelque chose m’a un peu intrigué. Ce tweet, en particulier.

Là, vous voyez, il y a un problème : le bon outil est ergonomique. Et quand je vois le nombre de personnes qui galèrent pour l’utiliser, sans même parler de l’utiliser correctement, je me demande si, réellement, il y a eu un gain si net par rapport à Subversion. Bon, pour le noyau Linux, clairement, ça doit être indispensable.

Mais ai-je besoin du même genre d’outil pour un projet qui ne va être partagé qu’entre quelques machines de développement et un serveur d’entreprise ?

Ai-je besoin d’un outil développé essentiellement pour des gens qui considèrent que l’ergonomie de la ligne de commande de Linux est un must insurpassable ?

Ai-je besoin d’un outil dont la l’intégration avec Linux est tellement poussée que le moindre problème dans la configuration réseau doit se résoudre dans les fichiers de configuration ssh du compte utilisé ?

Bref, encore une fois, je suis perplexe devant la faculté du monde du développement à adopter un outil inergonomique, rempli de fonctionnalités inutiles, et totalement inopérable pour peu que cet outil permette de démontrer une forme tordue de supériorité intellectuelle.

Et là, je me rends compte qu’en un sens, le Python ou plutôt sa communauté a peut-être changé ma perception de ce genre de choses …

Je déteste git

Je dois me rendre à l’évidence, je déteste git.

Notez que ça n’a pas grand chose à voir avec le fait que je ne soie pas spécialement fan de l’état d’esprit linuxien où la ligne de commande est reine, mais je dois bien avouer que ça n’aide pas.

git

Vous croyez sérieusement que j’aurais pu échapper à cette citation ?

Parce que c’est vrai que, apparemment, tous les gitters le disent, git sans la ligne de commande, c’est moins facile. Et c’est vrai que, quelquesoit le client graphique, c’est quand même loin d’être fameux : que ce soit EGit, TortoiseGit, SourceTree, dans tous les cas, les applications graphiques semblent s’écrouler dès qu’on travaille à plusieurs sur le même repository. Plus exactement, ces applications ne font pas mieux que la ligne de commande : elles ne protègent pas l’utilisateur.

Parce que franchement, avec git, se tirer une balle dans le pied et se retrouver avec un repository inutilisable, c’est facile. Par exemple, hier encore, après un pull, j’avais des conflits que git n’arrivait pas à résoudre, et que je n’arrivais pas non plus à résoudre ni en stashant, ni en tentant les résolutions manuelles. Du coup, j’ai dû utiliser cette méthode de Subversionniste débutant : copier mon code en dehors de mon repository, faire un gros hard-reset, et remettre doucement le code à sa place.

Et en fait, une partie de ma frustration tient également à ça : je ne crois pas que Git résolve des problèmes qu’on se pose vraiment, ou des problèmes que Subversion ne puisse pas résoudre.

Parce qu’en vrai, le problème que Git résout le mieux est celui de l’arborescence d’autorité propre au noyau Linux. Vous savez, le fait que Linus Torvalds est le maître absolu, qui délègue son autorité à une arborescence de « mignons » qui s’y connaissent de moins en moins. je connais un seul projet dans lequel ce mode de fonctionnement puisse avoir un sens. Et encore, je pense que le problème vient plus de la multiplication des serveurs que d’autre chose.

D’ailleurs, Git résout également très bien un autre problème, qui intéresse énormément les présentateurs de conférence, mais pas du tout les développeurs « de bureau ». C’est évidement le problème de l’historique « offline » : avec Subversion, je n’ai pas connaissance d’un moyen d’avoir cet historique (et comme toutes les réponses Stackoverflow à cette question recommandent soit SVK – qui est abandonné, soit gitsvn, soit hgsvn, j’ai bien l’impression que c’est une vraie limite). Alors qu’avec Git, c’est natif. Du coup, pour le mec qui code principalement dans le train, c’est clairement avantageux. Et comme le mec code dans le train pour venir me raconter des trucs au chtijug, c’est évident qu’il sera content de me parler de Git.

En revanche, il y a des trucs où Subversion est loin d’être aussi mauvais que ce qu’on croit : les merges, par exemple. Ou, depuis la 1.8, le maintien de l’historique des branches après leur réintégration. Ou même (avec Eclipse du moins) la clarté de l’interface que je n’ai pas encore retrouvé dans les clients Git.

Tout ça pour dire quoi ? A part

Eh bien par exemple que j’aimerais bien me débarasser de cette horreur. Ou, si ça n’est pas possible, trouver une interface humaine à ce bazar. Typiquement, je trouve que la git cheat sheet de NDP software est très bien. Et si je devias me lancer demain dans un client Swing/JavaFX pour Git, clairement, je m’appuierai dessus pour la présentation, plutôt que de me content de présenter l’historique des branches.

En fait, à bien y réfléchir, je ferais un truc dual : d’une part, pour synchroniser mon espace de travail aveec l’index et la branche en cours, une vue façon SVN sync dans Eclipse.

Et pour gérer mes push/pull/…. Une autre vue plus proche de ce graphe, mais matérialisant bien comment une branche passe de mon local à un ou plusieurs distants.

Ah, et je gèrerai sans doute très différement le problème des merges, pour garantir à l’utilisateur qu’il fait bien ce qu’il croit.

Le révisionisme dans Git, et un thermomètre en polymère.

Oui, j’y étais.

Hier soir, j’ai été assister à une chouette session du chtijug sur trois sujets, traités assez rapidement …

Avoir de beaux historiques dans git

Cyril et Hubert nous on fait un duo à base de pierre-feuille-papier-ciseaux-lézard-spock sur le thème des historiques dans git. C’est apparement une session qu’ils avaient déja présentée à Devoxx, puisqu’ils sont déja sur Parleys. Et tant mieux, parce qu’on a eu droit du coup à une présentation bien rôdée.

Ils nous y ont donc parlé de l’intérêt d’avoir un historique git beau et propre, sans commits avec des messages comme (je regarde dans mon projet …)

  • « WTF ? was lacking ? » (ça c’est moi)
  • «  » (oui, rien, ça arrive bien trop souvent)
  • « modif Nicolas afin de prendre en compte les interfaces héritées » (ça c’est quand je commite depuis le poste d’un collègue)
  • « PB-0005104,PB-0004951,PB-0005108,PB-0005006,PB-0004981,PB-0005173,PB-0005112 ,PB-0005037,PB-0005012,PB-0005164,PB-0005143,PB-0005010,PB-0004995,PB-0004955,PB-0004956 » (le pire message du monde : pleind e bugs résolus sur plein de fichiers différents)

Et donc, pour éviter ça, Hubert nous propose d’adopter le format Angular/Karma/…

Le format proposé n’est pas idiot, même si la description n’inclue que de façon très sommaire les liens vers les bugtracker (github issues en particulier a déja des outils bien pratiques, qu’il aurait été bon de mentionner).

Je passe par contre sur les lignes de commandes insupportables de git (surtout que SourceTree fournit le même workflow sans en passer par vi).

Cela dit, une question n’est pas posée : dans quel mesure ce travail est-il réellement utile par rapport à la mise en lien avec un bugtracker ? Autrement dit, quelle est la valeur ajoutée de ce travail d’esthétique de l’historique ?

Tiens, et une autre qui em vient comme ça : dans quelle mesure on essaye de faire de git une espèce d’ALM du pauvre quand des outils comme Tuleap existent ?

Un thermomètre dans ton web

Très chouette démonstration liant de l’Arduino, du Java8 et du Simple HTTP Server. Tout le code est sur Github, mais honnêtement, le code, là-dedans, c’est pas grand chose. Je cite :

Et encore, il manque le slide avec la tronche du chimpanzé …. et le fameux étalonage du thermomètre (qui m’a en fait très peu surpris, puisque comme l’a justement dit Mathieu, c’est réellement la façon professionnelle d’étalonner).

Une session à voir pour le style

Des superhéros polymérisés

Peut-être la session la plus proche de ce que je fais en ce moment avec Ractive. Il s’agissait en gros de produire un web-component avec polymer pour afficher de jolies fiches de super-héros.

Bon, par contre, il n’y a pas plus de version internet que pour le thermomètre, puisqu’il s’agissait là aussi de pur livecoding (ou plutôt, live-template-using, puisque Julien avait préparé des templates par dizaines pour que le ryhtme de la démo soit tenu, une très bonne idée).

Je retiens deux ou trois choses

  • Polymer est vraiment très très proche de Ractive : des templates utilisant Mustache, du two-way binding facile avec le modèle, et une grande simplicité du code
  • Le modèle des composants déja existants dans Flex est loin d’être mort. Thibaud parlait de JSF, mais ça remonte en fait bien plus loin … je dirais … Motif (quoi que je n’arrive pas à me souvenir si les composants étaient définis de façon duale par une construction statique + du code pour les événements).
  • Apparement, la spec derrière Polymer évolue encore assez régulièrement (la petite anecdote de Romain sur les trois réécritures de leur projet depuis Devoxx 2014 – donc 6 mois – m’a fait un peu flipper). Donc c’est pas encore complètement prêt à l’usage. C’est en revanche clairement la directionv ers laquelle converge le web.

Je suis un people

Et c’est qui la tête d’oeuf au premier rang ?

Ben ouais.

Bon, par contre, je pense que je tenterai l’after la prochaine fois, parce que le chtijug, c’est aussi ça

J’ai quand même du mal avec Git

Parce que bon, github, c’est vraiment un truc bien pensé, mais je comprend même pas comment ils ont pu construire un buisness aussi florissant sur une technologie aussi poussiéreusement foireuse.

Un exemple ?

J’ai passé deux heures à pester, mais alors vraiment pester, du genre

ou

Tout ça à cause d’une malencontreuse option « autoCRLF » qui ne fait pas du tout, mais alors pas du tout ce que je croyais. Pour mémoire, j’avais déja ajouté un fichier µ.gitattributes dans mes différents projets GitHub grâce aux contributions d’antoine_sd sur agorava-stackoverflow. Lui utilise en effet un Mac, et du coup, ces problèmes angoissants de fin de ligne (que je pensais voir réglés depuis Subversion au moins) étaient déja apparus.

Bon, et ce matin, en bonus, j’ai des problèmes de release liés apparement à des bugs … curieux … dans le plugin maven-javadoc-plugin qui font que la génération du site lors de la release fait tout planter. Bref, la joie.

Fork me I’m famous !

J'entends régulièrement parler de Git/GitHub/Mercurial/toussa depuis maintenant environ quatre ou cinq ans.
Depuis toutes ces années, j'en retiens une impression de complexité, sans doute dûe à des à-prioris antérieurs. Cela dit, ces derniers temps, ça a changé.
D'abord, grâce à EGit, le plugin pour Eclipse. Parce que je ne sais pas si vous savez, mais moi, je suis PC, et Eclipse, c'est mon idée … Mais qu'est-ce que je raconte, moi ? Bon, il se trouve en fait plutôt que j'utilise Eclipse depuis … environ … 9 ans. Et depuis toutes ces années, s'il a bien une fonctionnalité qui fait la différence, c'est sa gestion du travail en Eclipse … pardon, en équipe (c'est le soir, j'en ai marre). Tiens, par exemple, vous saviez, vous, qu'Eclipse est sans doute l'un des meilleurs clients Subversion (comble du luxe, en fait, c'est un double client Subversion basé sur deux librairies bas-niveau totalement interchangeables – et si vous voulez tout savoir, j'ai du écrire un bon paquet de code avec SVNKit, et même si c'est assez curieux, ça fonctionne finalement très bien) ? Tout ça pour dire quoi ? Eh bien simplement que EGit est au niveau de Subclipse. C'est un plugin qui s'intègre très bien dans Eclipse et permet de faire la plupart des opérations sans y penser : pas de problème pour faire des push/pull, pas non plus de soucis pour créer des branches, commiter, … Bref, EGit, c'est l'anti-ligne de commande et ça c'est bien !
Seulement, avoir le client, c'est bien, il faut aussi avoir le projet sur lequel travailler … Et il se trouve que, récemment, j'ai dû utiliser plusieurs projets hébergés sur GitHub pour lesquels existaient certains bugs qui m'affectaient particulièrement et qui étaient assez faciles à corriger.
Prenant donc mon meilleur clavier, j'ai entré un bug dans le bugtracker de l'un de ces projets, forké la branche master sur mon compte GitHub, récupéré cette branche sur ma machine, implémenté la feature, commité, pushé, fait la pull request … (dit comme ça, c'est long, et je dois dire que j'ai été impressionné … pas par la complexité, mais par le fait que, justement, avec EGit, c'est aussi facile que du Subversion). Et voilà ! Mon commit a été intégré !
Bon, je sais, pour vous, tout ça, c'est rien. Mais pour moi le monde de Git et de GitHub est longtemps resté très mystérieux. Avec cette expérience, les choses se clarifient notoirement. Et d'autres bugs vont bientôt être corrigés !

hg-git, c’est pas gagné ou c’est moi ?

Depuis quelques temps, j’ai une petite idée, à la gource, qui me trotte dans la tête. j’en avais déjà parlé, essentiellement pour en profiter pour me plaindre de l’aspect DIYde GitHub. Hier, après une journée de merge, j’ai replongé. Profitant du fait que j’avais précédemment installé hg-git, j’ai cloné (enfin, forké) chez moi le dépôt de l’auteur de gexf4j. J’en ai alors profité pour corriger tous les bugs dans les tests unitaires, avant de commiter dans mon dépôt local et de pousser ces modifications dans mon dépôt GitHub.
Et c’est là que ça chie.
Parce que, quand je pousse, hg-git me dit
E:\java-ext\gexf4j\gexf4j-core>hg push git+ssh://git@github.com:Riduidel/gexf4j-core.git
pushing to git+ssh://git@github.com:Riduidel/gexf4j-core.git
importing Hg objects into Git
creating and sending data
default::refs/heads/version0-2 => GIT:61a30e14
default::.have => GIT:b7c0f5d2
default::refs/heads/dynFloat => GIT:b7c0f5d2
default::refs/heads/v2 => GIT:76262214
default::refs/heads/v3 => GIT:cb2f4173
default::refs/heads/master => GIT:8f769e5a

Seulement, quand je regarde dans l’interface web, je ne vois pas mon commit. Bizarre, non ?

Alors si un quelconque professionnel de GitHub passe par là, j’aimerais bien qu’il m’explique comment rendre
visible mon commit dans mon dépôt chez GitHub (sans même parler de proposer de réintégrer les changements dans le dépôt principal) …

Pourquoi j’ai un à-priori contre git

Le titre semble provocateur, pourtant il reflété très exactement mon état d'esprit. Oui, j'ai un authentique à-priori contre git.
Quel est cet à-priori ? Facile, j'ai envie de penser que git est une espèce de truc typiquement linuxien : très puissant, mais vraiment pas pensé pour être utilisé. Plus pensé pour être bidouillé, en fait.
Mais revenons au début.
La mode de ces dernières années, en ce qui concerne la gestion de sources, est de diaboliser Subversion (trop nul pour gérer les branches, typiquement) pour pouvoir lui préférer des outils distribués. Parmi ces outils, on trouve évidement Mercurial, Git, mais aussi Darcs, Arch, Bazaar et quelques autres qui tentent de se faire une place au soleil. De tous, c'est évidement git qui s'est fait le plus vite une place au soleil. D'abord par sa naissance : la légende veut qu'il soit sorti habillé de pied en cape de la tête de Linus Torvalds, à la façon d'Athena. Et ça, pour n'importe quel linuxien, c'est un signe de perfection. Ensuite, comme Linus Torvalds a un peu d'influence, il a fait en sorte que git soit utilisé pour le noyau Linux, ce qui a immédiatement permis son utilisation dans le cercle des alpha-geeks (parce que n'en déplaise aux grognons, les mainteneurs du noyau Linux sont clairement des alpha-geeks, au même titre que, je sais pas, moi, les Java Champions, ou les leaders de JUG, voire les multiclassés champions/JUG leaders/pubs vivantes pour L'Oracle ;-)). Du coup, très vite, git est apparu comme le DVCS à utiliser (bien plus que darcs, par exemple, pourtant bien plus ancien – à peu prés 2002, fondé – d'après un ancien collègue qui doit se retourner dans sa tombe devant la trahison de Linus – sur une théorie du patch complètement conceptuelle), et s'est répandu dans toutes les sphères où le buzz fonctionne … typiquement, la sphère du Ruby on Rails. Et c'est comme ça qu'on a vu apparaitre le plus gros argument commercial en faveur de git : GitHub.
Pourtant, git n'est pas exempt de problèmes, le moindre n'étant pas sa ligne de commande, réputée "délicate" à manipuler. Et personnellement, si il y a bien un truc qui me rend fou, c'est les softs en ligne de commande où c'est le quatrième argument qui compte.
Le pire, en fait, c'est de se dire que l'alternative "compatible" existe … ben oui, avec mercurial, vous avez aussi un client de gestion de sources puissant, mais à la ligne de commande beaucoup plus compréhensible, d'après ce que j'en vois. Surtout que, contrairement à git, mercurial n'est pas un monolithe, mais une application extensible. Et franchement, vous en utilisez encore beaucoup, vous les geeks, des applications sans plugins ? Le must étant évidement qu'on trouve, parmi ces extensions, Hg-git qui permet de se connecter à un repository git avec mercurial. Notez bien sûr que le contraire n'est pas vrai. Du coup, git, utilisé pour le développement le plus visiblement open-source, apparaît comme une solution un peu plus fermée que son concurrent le plus direct …
Bon, après, mercurial ou git, j'ai l'impression que c'est plus une question de goûts personnels qu'autre chose …