Blog myBlog = BlogFactory.getWordPressBlog();
Systèmes d’information
Allons un peu plus loin avec Git-SVN
12/10/10
Il y a très peu de temps, j’expliquais comment utiliser Git avec SVN dans Eclipse. C’est maintenant quelque chose que j’utilise au quotidien, que ce soit avec Eclipse ou IntelliJ IDEA, mon nouveau choucou. Dans un cas comme dans l’autre, on ne coupera pas à l’utilisation des « external tools » pour la configuration des commandes « git svn rebase/dcommit/etc. »
Après plusieurs semaines d’utilisation, j’ai voulu étendre cette utilisation à d’autres commandes, afin de voir si on pouvait pousser plus loin les interactions entre Git et SVN.
La suite >
Session de rentrée Git-Attitude
20/09/10
Il est temps de faire un petit retour sur ce samedi, passé à la session de rentrée Git-Attitude. Ce fût une excellente journée, très dynamique et instructive. Cette formation intensive m’a permis de progresser bien plus vite que par une auto-formation… et pour un prix dérisoire, petit-déjeuner et déjeuner compris : nous avons donc eu le Git et le couvert (oui, elle était facile, mais je n’ai pas pu résister !).
Présentation des acteurs
Nous nous sommes retrouvés à 9 participants (dont Rik, Gabriel, Rudy, Bob, etc.) dans les locaux parisiens de Clever Age, plus notre formateur. Par un mystérieux hazard, j’ai découvert aujourd’hui que nous travaillons à quelques centaines de mètres, les locaux de Ciblo étant situés boulevard Bessières.
Premier point positif et remarquable : nous étions environ moitié MAC, moitié Linux (l’utilisation de Git étant, il est vrai, beaucoup plus pénible surWindows…). Le deuxième suit aussitôt : nous avions tous une connexion internet sans restrictions. Ca met de bonne humeur pour commencer la journée. Note :Le café et les viennoiseries du matin étant bien entamées, nous pouvons entamer la journée en douceur…
Les bases
Nous commençons par vérifier notre installation de Git (et sa customisation), et nous sur une présentation générale :
- Petit historique rapide des gestionnaires de configuration
- Comparaison de l’approche centralisée avec l’approche décentralisée, et des différents acteurs de chaque catégorie
- Immédiatement après (évangitlisation oblige), les avantages du décentralisé : travail en mode offline, commits plus atomiques, suppression du « single point of failure« , etc.
- Point sur le vocabulaire : commit et checkout sont des opérations locales. Les opérations distantes s’appellent push, pull, fetch.
- Présentation des quatre « zones » de travail sous Git : les « Untracked » (fichiers non encore gérés sous Git) « Working Tree » (espace de travail), « Index » (snapshot des fichiers prêts à être commités), « HEAD » (position du dernier commit)
- Toutes les références (branche, tag, etc.) sont des hachages SHA
Premiers travaux pratiques
- Création d’un premier dépôt, ajout d’un fichier à l’index (add), commit… Nous voyons tout de suite une première possibilité de Git, l’amendement (–amend) un commit (en cas d’oubli de fichier dans un commit)
- Nous voyons aussi quelques commandes de suivi : diff, status et log : ces quelques méthodes sont déjà impressionantes par le nombre de possibilités (différence entre l’espace de travail et l’index, entre l’index et le HEAD, entre l’espace de travail et le HEAD, etc.)
- Premier « Whaou » du jour : l’ajout interactif (add -i) : on peut mettre dans l’index des portions de fichier, et garder le reste des modifications pour un commit ultérieur.
- Encore plus fort, le retour en arrière en cas d’erreur avec Dick Rivers git reset.
Cette fonction reset est impressionnante. Si nous avons oublié de créer une branche depuis 2 commits, elle permet de corriger ça en 3 commandes :
1 2 3 | git branch ma_nouvelle_branche git reset --hard HEAD~2 # master revient deux commits en arrière git checkout ma_nouvelle_branche # Ni vu ni connu |
Après cette entrée en matière plutôt efficace, nous allons déjeuner, et discuter de choses et d’autres… mais en particulier du Paris Web.
Les branches
De retour, nous abordons un sujet assez inconnu sous Subversion (tant il est difficile de faire des fusions) : les branches. Sous, Git une branche n’est qu’une référence vers l’arbre d’origine (un SHA). C’est-à-dire quelques octets et quelques milli-secondes.
Une fois ces branches créées, elles sont aussi faciles à fusionner, avec une résolution automatique de grand nombres de cas. En particulier si des modifications concurrentes sur un fichier concernent des parties différentes, Git les fusionnera. Ca peut paraître simple… mais Subversion en est incapable.
Et comme c’est simple et que ça marche, on peut mettre en place de véritables stratégies et workflows de développement.
En cas d’urgence, on peut changer de branche sans perdre son travail avec la boite à idée « stash« .
Nous abordons ensuite plus en détail les différentes possibilités de fusion :
- résolution d’un conflit (oui, il arrive qu’on ne puisse y échapper…)
- fusion simultanée de plus de 2 branches (trois, dans notre cas) : et ça marche !
Rebase
(Encore) une fonctionnalité impressionnante de Git. « Rebase » permet :
- de modifier le point de départ d’une branche
- de diviser une branche et deux branches distinctes (dans le cas où elle contient deux parties n’ayant finalement pas de rapport)
- de réécrire l’historique en mode interactif (par exemple pour fusionner plusieurs commits successifs en un seul)
Dépôts distants
Travailler en local, c’est bien… mais à un moment, il faut partager son travail. Nous voyons donc comment se connecter à un dépôt distant, et comment interagir avec celui-ci : push, pull, fetch, etc.
Au passage, nous découvrons des nouveautés (simplification de la syntaxe des commandes) de la version 1.7 et effectuons nos travaux pratiques avec des clés SSH et Gitosis.
Une journée bien remplie…
Pour finir, nous voyons la fonction « tag« . La journée se terminera là-dessus : avec tout ça, nous n’aurons finalement pas eu le temps d’aborder les submodules (mais on pourra facilement trouver en ligne des informations sur ces derniers).
Il nous reste à passer un dernier quizz, et à rentrer chez nous méditer tout ça…
Maintenant, si vous êtes en manque d’imagination pour les nombreux commits que vous allez faire sous Git, allez donc lire What the commit…
Soirée ParisJUG de rentrée
16/09/10
Ce 10 septembre s’est tenu le Jug Summer Camp auquel je n’ai pas pu aller (comité de pilotage prévu depuis longue date). Heureusement, les conférenciers et participants n’ont pas été avares en compte-rendus : sur le touilleur-express, les JDuchess France, etc.
Alors, afin de ne pas rater deux fois de suite une conférence JUG, j’avais pointé sur mon calendrier le jour d’ouverture es inscriptions à la soirée Paris JUG de ce mardi. Bien m’en a pris car toutes les places sont parties en moins d’une demi-journée…
Cette soirée consacrée au NoSQL fût très intéressante, et particulièrement sympa. A la pause, j’y ai en particulier fait la connaissance « IRL » de deux connaissances Twitter : Audrey Neveu (des Duchess) et Cyrille Deruel (auteur du blog « Bouzin agile« ). Finalement, la barbe c’est pratique pour être reconnaissable. Mon seul regret, c’est le réveil à 5h le lendemain qui m’a empêché de participer à la troisième mi-temps pour espérer avoir un peu de sommeil.
Mais revenons au thème principal. Un résumé très complet de la soirée (y compris les intermèdes SWPA et ALM) est déjà disponible chez Le touilleur. Je ne vais donc pas paraphraser, et me contenter de compléter par quelques éléments qui m’ont marqué.
En particulier, j’ai été très intéressé par la présentation des bases « graph » (et Neo4J), et j’ai regretté qu’elle passe rapidement sur ce sujet. Le cas d’utilisation qui a été cité est celui des réseaux sociaux professionnels (Viadeo, LinkedIn, etc.), qui établissent des « chemins » et des « distances » entre nos relations (au 1er, 2ème, 3ème degré, etc.).
M’intéressant par ailleurs au web sémantique (qui m’avait attiré à la soirée de mon premier Paris JUG l’année dernière), j’ai pensé que ce type de base aurait un grand intérêt pour la persistance d’informations sémantiques. Après la soirée, une petite recherche m’a rassuré : je ne suis pas le premier à avoir pensé à cette utilisation. Et Michael Figuière, un des conférenciers de mardi, cite cette utilisation dans un de ses billets axé sur Neo4J. Il existe même une extension dédiée à l’utilisation de Neo4J pour le stockage de RDF.
Cette extrapolation de la conférence m’a sérieusement donné envie de me remettre au web sémantique… Une ligne de plus dans ma TODO-List des choses à étudier. Je ne suis malheureusement plus à une ligne prêt dans cette liste… #TropDeSujetsIntéressants comme on dit. Et une autre de ces technologies que j’aimerais étudier, c’est Play! Framework : il va donc falloir que je veille à ne pas manquer le prochain Paris JUG !
De SVN à Git sous Eclipse
31/08/10
Il y a maintenant quelques semaines, j’ai été frappé par le virus Git. Dans la foulée, j’ai migré la gestion de configuration de mes composants pour Talend Open Studio sous GitHub. Et depuis, pour mieux maitriser cet environnement, j’ai pris ProGit comme livre de chevet.
Plus récemment encore, j’ai décidé de passer également sous Git mon environnement de travail professionnel pour le développement Java. Mais cette fois, ce n’est plus aussi simple, car on ne peut pas remplacer comme ça le serveur SVN central utilisé par les différentes équipes de développement.
Mais Git et Subversion peuvent être utilisés ensemble. On travaille sous Git en local, profitant ainsi de tous ses avantages (passage rapide d’une branche à l’autre, pour bien découpler les différents travaux, etc.), et on synchronise ce travail sous Git avec le serveur SVN.
Ce mode de travail et ses avantages ont très bien été expliqués dans le dernier article de Nicolas de Loof. En particulier, ce qui m’intéresse, c’est la rapidité de mise en oeuvre sans avoir à faire évoluer la plate-forme de développement d’un iota.
Cet article expliquant tout ce qu’il y a à savoir pour débuter avec Git et SVN, je ne recommencerai pas. Je vais donc aborder l’étape suivante : l’intégration de cette nouvelle méthode de travail dans mon environnement de développement.
Découverte de Git et de GitHub
24/08/10
Après avoir utilisé pendant quelques années Subversion, qui me satisfaisait pour la gestion des sources de mes projets personnels (composants Talend, entre autres…), j’ai décidé par curiosité de tester Git, à cause des différents articles que j’ai pu lire récemment à ce sujet, dont la quasi-totalité vente les mérites.
Lorsque l’on a l’habitude d’un gestionnaire de configuration centralisé comme Subversion, la prise en main est rude… Les concepts ne sont pas les mêmes, et lorsqu’on essaye d’appliquer ceux dont on a l’habitude, on se retrouve face à quelques problèmes : mon premier réflexe a par exemple été de chercher comment lancer le « serveur Git » avant utilisation. #FAIL, comme on dirait sur Twitter…
Heureusement, vu la popularité croissante de ce système, je n’ai eu aucun mal à trouver des tutoriels qui m’ont ré-aiguillé sur la bonne voie. Je me suis ainsi rapidement mis à « la philosophie » de Git. Effectivement, j’approuve ce que j’ai pu lire : une fois qu’on l’a essayé, on a du mal à s’en passer. Je vais y revenir… Mais avant ça, voici ma liste de remerciements et des liens qui m’ont aidé à découvrir Git :
- le site officiel, pour commencer, qui propose le programme (évidemment), mais aussi un tutoriel de mise en place, le manuel ainsi que le Git Community Book.
- ProGit, ou Git Magic, deux autres ouvrages de référence disponibles en ligne
- Understand Git conceptually pour bien comprendre les concepts de Git
- Why Git is better than X, dont le titre en dit long sur le contenu : un plaidoyer sur les avantages de Git par rapport aux autres gestionnaires de configuration
- Git attitude, fournissant à ce jour deux articles très intéressants en français sur l’installation de Gitosis (même si je ne l’utilise pas) et sur l’installation de Git avec un « prompt » gérant l’auto-complétion des commandes Git.
- Le pense-bête de Nicolas de Loof sur l’utilisation de Git avec un repository central SVN, ainsi que son article sur le refactoring d’un projet SVN sous Eclipse en utilisant Git
Avec toutes ces lectures, j’ai pu me mettre correctement à Git. Les liens ci-dessus contenant toute la littérature nécessaire pour prendre un bon départ, je vous épargnerai un n-ième tutoriel qui se contenterait de recopier ce qui existe déjà…
Le premier projet personnel qui est passé de SVN à Git, ce sont les composants Talend que je développe. Chaque composant étant dans un répertoire distinct, et constitué d’une quinzaine de fichiers maximum, j’ai jugé plus simple de les regrouper dans un unique projet.
Et c’est là que les mécanismes de Git vont m’aider. Car souvent, j’ai des idées d’amélioration (ou de création) pour plusieurs composants n’ayant rien à voir : finition du bcFileOutputOOSpreadsheet, possibilité de logs conditionnelles dans tLog4J, etc.
Il existe sur SVN un mécanisme de branches, mais passer d’une branche à l’autre et effectuer des fusions de branches une fois le travail terminé n’est pas aisé :
- temps de switch relativement longs (surtout lorsque le projet a une taille conséquente). En développement Java sous Eclipse, quand je travaillais sur plusieurs évolutions fonctionnelles (branches) différentes, j’en suis venu à cloner mon projet en associant chaque projet à une branche différente pour pouvoir changer de branche en un temps acceptable.
- de très fréquents « faux » dans les conflits remontés par SVN lors des fusions (principalement en cas de suppression, de renommage ou de déplacement d’un fichier). La gestion manuelle de ces conflits sous SVN est plus que pénible.
De ce fait, j’utilisais peu ce système, et la plupart de mes commits étaient effectués dans le trunk.
Dans Git, le mécanisme de branche est beaucoup mieux géré, et est donc au coeur du système. Le réflexe à avoir sous Git, c’est « une nouvelle idée = création d’une nouvelle branche ». Si cette idée aboutit, elle sera fusionnée dans la branche principale (master). Sinon, elle sera simplement supprimée. Voici pourquoi ça marche :
- le repository Git, étant local, créer ou changer de branche est une opération très rapide, et on n’a plus besoin de cloner son projet. La « stash » (boite à idées), permet de garder en mémoire le travail en cours sur une branche avant d’en changer, sans pour autant devoir effectuer un commit
- la fonctionnalité de fusion des branches fonctionne beaucoup mieux que sous SVN. Quand le travail sur une branche est terminé, on la fusionne dans le « master » (équivalent du « trunk »). Et les mécanismes utilisés par Git, avec ses différentes stratégies de fusion, font que ça marche vraiment bien.
Après un changement dans mes habitudes de travail, je m’y retrouve donc beaucoup plus facilement avec Git, avec une branche par évolution de composant.
Dernière étape : sauvegarder mon travail, voire synchroniser mon travail entre mes différents postes de développement. Pour cela, SVN tournait sur un serveur distant et gérait très bien ce double aspect sauvegarde/synchronisation. Jusqu’ici, Git est uniquement installé sur une de mes machines de développement.
Plusieurs solutions sont possibles :
- installer git sur un serveur distant, avec un repository « bare » (cf. les nombreux tutoriels sur le travail collaboratif avec GIt que l’on trouve en ligne) et y accéder directement par le protocole Git+SSH.
- installer Gitosis (cf. tutoriel sur Git-attitude), offrant une gestion plus fine des droits sur plusieurs projets. Cette solution a beaucoup d’intérêt dans le cadre de « l’urbanisation de Git » dans le système d’informations d’une entreprise
- utiliser un hébergeur dédié, comme GitHub.
L’utilisation de GitHub est gratuite pour les projets Open Source, et payante pour les autres. Mes composants étant justement publiés en Open Source, j’ai opté pour cette dernière solution, beaucoup plus rapide à mettre en place (un formulaire de création de compte à remplir).
Outre le repository Git, la plate-forme GitHub, propose, comme SourceForge, un ensemble d’outils de suivi de projet : un historique du projet, des pages WIKI de documentation, un bugtracker…
J’ai apprécié cet aspect « Tout en un », qui manque (encore) à Talend Exchange. J’ai donc décidé de me servir de cette base pour créer le site du projet de mes composants Talend. Par rapport à Exchange, il ne contient que les composants encore vivants (dont les fonctionnalités n’ont pas été intégrées à la version de base du produit). Si vous avez des remarques (bugs) sur mes composants, ou envie de contribuer à ce projet, c’est maintenant par là-bas que ça se passe…
Il ne me reste plus qu’à éditer les liens des composants sur Exchange pour indiquer la nouvelle adresse du support…
Google Apps Marketplace
14/03/10
J’ai déjà eu l’occasion de parler des Google Apps lors de la panne générale de Google.
Depuis cette époque, j’utilise toujours Google (et les Google Apps) :
- personnellement, pour gérer mon domaine courtine.org
- à titre professionnel, AlcionGroup ayant franchi le pas de la gestion des mails par Google
Dans les deux cas, j’en suis tout à fait satisfait, et cette gestion infogérée n’a pas à rougir face à d’autres solutions professionnelles (synchronisation avec les terminaux mobiles des contacts et des calendriers, gestion de mailing-lists, etc.). Un certain nombre d’entreprises de tailles variées a d’ailleurs déjà franchi le pas.
Il y a maintenant quelques jours, le Google Apps Marketplace a été lancé. Il fonctionne exactement comme Apple AppStore ou Blackberry App World, à cette différence près qu’on y trouve des applications fonctionnant en interaction avec les Google Apps.
On trouve ainsi des applications ERP comme myERP.com, des logiciels de gestion de projet, etc.
Toutes ces applications (comme les Google Apps), gardent les données sur les serveurs de leurs éditeurs respectifs (en “Cloud Computing”). C’est certainement ce qui sera le plus grand frein au développement de ces solutions, car on perd la maîtrise de ses données (avec donc, le risque d’éventuelles fuites d’informations).
Cette solution est à mon avis néanmoins très intéressantes pour les consultants indépendants, TPE ou PME : elles sont peu coûteuses par rapport à un investissement dans des logiciels dédiés, permettent de bénéficier d’un système d’information de qualité dont on n’a pas à se préoccuper (risque d’incendie, de vol, de crash de disque dur, etc.).
Du point de vue des développeurs, le mode de facturation de Google est très similaire à celui d’Apple : un ticket d’entrée à 100$, auquel il faut ajouter 20% des revenus si on développe des applications payantes (le mode de paiement étant assez libre : par application, par abonnement, par utilisateur, etc.). A noter qu’il est possible (pour les philanthropes) de développer des applications gratuites.
Sortie de Quotero 1.0
9/03/09
Jeudi dernier, j’ai assisté à mon deuxième OpenDay, sur la sortie de Quotero 1.0 à la Cantine. Pour mémoire, le premier OpenDay auquel j’ai assisté concernait la sortie de la plateforme décisionnelle Open Souce Spago BI 2.0 : j’avais fait un rapide compte-rendu de cette conférence sur le blog technique d’Alcion Group.
Voici donc le compte-rendu de la conférence sur Quotero.
Est-on trop dépendant de Google ?
28/02/09
Il y a environ 4 mois, sur le blog technique d’Alcion Group, j’avais publié un billet pour venter les mérites des Google Apps, et en particulier de leur taux de disponibilité supérieur à 99,9%.
Pour mémoire, il s’agit d’un ensemble d’applications permettant aux particuliers (gratuitement) et aux PME (pour un coût “dérisoire” de 40€ par personne et par an) de délocaliser une partie de leur système d’information (comptes mails, agendas partagés, etc.) sur les serveurs de Google.
