Blog d'un ingénieur informaticien parmi d'autres...
Blog myBlog = BlogFactory.getWordPressBlog();
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.
Libérons (un peu) les développeurs
29/08/10
Il y a peu, j'ai posé sur Twitter la question :
Sondage express : pour ou contre le commit des fichiers propres à l'IDE dans le gestionnaire de sources ?
Un petit échange s'en est suivi avec @pierre_fauvel, qui pense que c'est en effet une bonne pratique. Pour ma part, je suis plus mitigé sur cette question… 140 caractères, c'est un peu court pour argumenter : je pensais donc publier un billet pour étayer mon avis sur la question. M. Fauvel a eu la même idée, et m'a devancé.
Avant de lire ce qui suit, je vous renvoie donc a son très intéressant billet sur la question.
Oui, il faut partager les bonnes pratiques
Je suis bien évidemment d'accord : il doit y avoir de la communication dans une équipe, ainsi qu'un partage des bonnes pratiques : c'est une évidence !
Il me vient tout de suite à l'esprit plusieurs applications concrètes incontournables de ce principe. En particulier pour tout ce qui concerne l'outillage du projet :
- l'outil de gestion de configuration : c'est la base du travail collaboratif. Il est donc inconcevable qu'un développeur n'utilise pas le même système que les autres
- la gestion du build : la manière de construise le projet doit être la même pour chaque développeur (Ant, Maven, Gradle, Ivy, ou autre), afin d'assurer la reproductibilité de celui-ci. C'est pour cela que nous mettons les fichiers de configuration du build (les pom.xml, profiles.xml, etc. de Maven dans notre cas) sont mis en gestion de configuration.
- les outils d'intégration continue ainsi que les résultats associés (tests en échec, métriques de qualité Sonar, etc.)
- les règles de qualité de code à mettre en place (PMD, CheckStyle, FindBugs). En particulier pour celles-ci, il est important que tous les développeurs soient convaincus de leur utilité, et soient d'accord sur les limites à appliquer et leurs raisons : pourquoi limiter une méthode à 30 lignes de code plutôt que 20 ou 40 ?…
Mais il faut aussi laisser une marge de liberté aux développeurs…
Les points précédents étant acquis, il ne faut pas non plus trop vouloir trop contrôler. En particulier, je ne suis pas partisan d'avoir un environnement de développement unique, configuré de la même manière pour tous les développeurs, et dont la configuration serait mise en gestion de configuration.
En effet, même s'il faut partager les bonnes pratiques, il me semble que certaines pratiques ne peuvent justement pas être hiérarchisées. Dans ce cas, pourquoi en imposer une plutôt qu'une autre ?
Prenons un exemple concret : l'utilisation de SVN avec Eclipse. On peut utiliser Subclipse ou Subversive. Les deux ont des fonctionnalités similaires, et le choix est donc affaire de préférence plus que de "bonne pratique". On pourrait effectivement choisir d'en imposer un arbitrairement, afin d'uniformiser les environnements de développement, mais j'avoue que je n'en vois pas l'intérêt : le choix n'impacte en rien la productivité, et je préfère donc laisser la liberté à chacun de choisir celui qu'il préfère.
Les développeurs ont souvent leurs propres habitudes, et leurs outils préférés. Et bien souvent, il existe des outils concurrents dont il est difficile de dire lequel est meilleurs que l'autre :
- vi, kate, emacs, etc. pour l'édition de fichiers sur les systèmes Unix
- Notepad++, PSPad, etc. pour faire la même chose sous Windows
- 7Zip ou PeaZip pour la gestion des archives sous Windows
- etc.
Plutôt que d'imposer un outil unique, je préfère laisser le choix aux développeurs d'utiliser celui qu'ils préfèrent. Ainsi, chacun sera efficace (en utilisant l'outil avec lequel il est à l'aise), et cela ne pénalise à mon avis pas le travail de l'ensemble de l'équipe.
Si je fais ce choix, c'est aussi pour une question de moral : un développeur n'est pas un enfant, et n'aime donc généralement pas qu'on le prenne pour tel. J'ai tendance à penser que chacun est à même de décider quels outils lui conviennent le mieux, et appréciera de pouvoir les utiliser : il en sera non seulement plus efficace, mais aussi plus motivé qu'on lui fasse confiance.
Tout ceci n'étant bien sûr vrai que dans la mesure où ces choix personnels ne sont pas gênants pour le travail de l'équipe. Bien sûr, nous discutons souvent de ces choix, et parfois, nous convainquons nos collègues qu'un logiciel est vraiment meilleurs qu'un autre. C'est ainsi que sur la recommandation de Damien, j'ai adopté yEd pour l'édition de diagrammes.
Quelques exemples
Un de mes collaborateurs a préféré travailler sous Ubuntu plutôt que sous Windows. Cet OS répond à ses besoins, et est parfaitement compatible avec le travail du reste de l'équipe (SVN, serveurs de test, etc.). Sa licence Windows a été installée sur une machine virtuelle lorsqu'il en a besoin occasionnellement.
Mon nouveau dada, c'est Git. J'en ai fait la présentation aux équipes de développement, mais avant de le déployer à grande échelle, je préfère le tester : je l'ai donc installé localement, en le connectant au SVN de l'équipe. Mon environnement est donc "personnalisé", mais cela n'impacte pas le travail de l'équipe. Si je suis convaincu, je proposerai aux autres cette solution, en leur présentant ses avantages, mais en laissant libres ceux qui préfèrent garder leurs habitudes de travailler directement avec Subversion. Et il y a des arguments pour chacune, comme par exemple le plugin EGit pour Eclipse qui n'est pas encore du tout au niveau de ceux qui existent pour SVN (mais là, j'anticipe sur un prochain article…).
Nous travaillons tous sous Eclipse. Je n'ai jamais eu l'occasion de travailler avec des IDE mixtes. Mais dans la mesure où d'autres IDE (Netbeans par exemple), permettent de travailler avec Maven, SVN, etc., je ne pense pas que cela soit impossible ou nuisible. Ainsi, si un collaborateur préférait par habitude utiliser un autre IDE, je n'y verrais pas d'inconvénient (mais là, je suis peut-être un grand optimiste).
Conclusion
Afin de laisser cette marge de manoeuvre aux développeurs, il faut y mettre quelques moyens. Deux d'entre eux me viennent à l'esprit :
- chaque développeur est administrateur local de sa machine
- maintien de manière collaborative (wiki, par exemple) d'une liste de "logiciels recommandés" par catégorie : édition de texte, etc., voire d'un centre de téléchargement interne, pour accélérer la vitesse d'accès et uniformiser les versions des logiciels (lorsque c'est pertinent)
- chacun a un accès à Internet peu restreint, permettant au moins l'accès au téléchargement de logiciels (libres) de son choix, mais aussi à la veille technologique, aux forums de discussion techniques, etc. (personnellement, je préconise même l'absence totale de blocage, sauf en cas d'abus manifestes).
A mon sens, cette souplesse ne va pas à l'encontre d'un développement structuré, tant qu'elle respecte la plate-forme de développement commune et les spécificités du projet. Elle permet aux membres de l'équipe de tester plusieurs outils, et d'échanger sur leurs expériences avec ceux-ci.
Cette diversité permet de multiplier les tests comparatifs, de communiquer et de capitaliser sur les résultats de ces tests :
- si un outil a clairement l'avantage sur ses concurrents, il sera naturellement adopté par l'ensemble de l'équipe
- si les outils ne peuvent être départagés, il n'est pas la peine de choisir
Mais revenons au sujet initial. Pour les raisons évoquées ci-dessus, je ne mets pas les fichiers propres à l'IDE sous gestion de configuration. Je ne considère pas la configuration de l'environnement de développement comme étant une "partie intégrante du projet". Ceci dit, une "configuration type du projet" est tout de même accessible pour ceux qui la veulent : elle n'est pas sous SVN pour éviter à ceux qui ont une configuration personnalisée d'écraser par erreur lors d'un commit celle par défaut.
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…
Flattr : un système économique bien pensé
19/08/10
J'ai découvert hier la nouveauté du moment : Flattr. L'idée est simple, mais il fallait l'avoir : c'est un système qui permet aux internautes de récompenser les sites que l'on trouve intéressants.
Il y a 10 ans, Paypal (racheté en 2002 par Ebay) a considérablement simplifié les paiements sur le web, en demandant un login/mot de passe plutôt qu'un numéro complet de carte bleu. Cependant, ce système reste lourd pour effectuer un micro-don aux sites qui nous intéressent.
Le concept de Flattr, c'est donc d'aller encore plus loin que Paypal dans la simplification du paiement, mais en se concentrant sur les micro-paiements. Je m'y suis inscrit pour voir son fonctionnement :
- Tout d'abord, on charge son compte Flattr, avec la somme d'argent que l'on veut.
- Ensuite, on choisit quelle somme on veut attribuer tous les mois (de 2 à 100 euros) aux sites qui nous plaisent.
- Tant qu'on est loggué, on peut sans avoir besoin de se ré-identifier, "flattrer" ces sites d'un simple clic, via un bouton (souvent similaire à ceux de Twitter).
- A la fin du mois, Flattr divise la somme allouée mensuellement entre les sites "flattrés" (en prélevant sa dîme au passage, je vais y revenir…). Si aucun site n'a été "flattré" dans le mois, l'argent est tout de même prélevé pour être réparti entre des organismes de charité.
La plupart des réseaux sociaux destinés au grand public (Twitter, Facebook, etc.) sont gratuits pour l'utilisateur final, et financés par la publicité (et la revente des informations commerciales que ces sociétés peuvent extraire de l'utilisation des systèmes). Voir ici par exemple pour plus d'information sur le modèle économique des réseaux sociaux. Les réseaux sociaux professionnels (LinkedIn, Viadeo, etc.) ne s'adressant pas au même public, ils peuvent se permettre d'avoir des fonctionnalités avancées payantes (recherche de profils par mots-clés pour les recruteurs, etc.).
Le génie de Flattr, c'est de s'adresser au grand public… tout en étant payant (même si c'est de façon déguisée). Pour cela, le système joue sur la sensibilité des gens en les incitant à "soutenir les personnes qu'elles aiment" (traduction de la page d'accueil), et en communiquant sur le soutien aux organismes de charité.
On aurait pu imaginer un système avec deux typologies d'utilisateurs :
- Les mécènes (soutenant gratuitement les auteurs, artistes, etc.) du web
- Les auteurs, artistes, etc. en question, utilisant Flattr pour se faire micro-rémunérer par leurs fans
En réalité, pour faire partie de la deuxième catégorie, il est obligatoire de faire partie de la première : "il faut donner pour recevoir". Avant d'avoir le droit de mettre un bouton "Flattr" sur son site, il faut donc alimenter son compte et dépenser au moins 2€ par mois. Si le solde du compte arrive à 0, celui-ci est désactivé et on ne peut plus recevoir jusqu'au réapprovisionnement de celui-ci.
Quand je disais que Flattr était "payant", c'est parce qu'il prélève 10% de toutes les sommes qui transitent par son biais. Chaque utilisateur étant tenu de contribuer au moins à hauteur de 2€ par mois, cela fait donc à Flattr une rente de micro-paiement minimale de 20 centimes par utilisateur et par mois. Sur la masse, cela peut représenter une somme non négligeable.
Pour un mécène qui se contente de donner, ce prélèvement est invisible : il s'applique sur les sommes perçues, au niveau des utilisateurs qui reçoivent de l'argent. Pas de quoi crier au scandale sur cette pratique, la plupart des systèmes de paiement (Paypal, etc.) se financent avec ce mode de prélèvement. On remarquera cependant que 10% de prélèvements, c'est astronomique par rapports aux taux pratiqués par Paypal.
Note : lorsqu'on recharge son compte Flattr, on le fait par Paypal (ou un système équivalent). Flattr doit donc s'acquitter auprès de ces systèmes d'un pourcentage du rechargement. Cependant, ces sommes sont re-facturées en amont, sur les utilisateurs. Ainsi, si je paye 30€ (via Paypal) pour recharger mon compte, il ne sera crédité que de 28,50€. Les 10% prélevés par Flattr ne servent donc pas à payer ces frais.
A ces 10% de prélèvement obligatoire s'ajoutent les revenus qui peuvent être générés par la revente des informations récoltées par le système sur les habitudes des consommateurs utilisateurs.
Il s'agit plus d'une constatation que d'une critique : il faut bien que cette société gagne de l'argent (comme les autres), et c'est un modèle économique comme un autre. J'aurais même tendance à admirer la prouesse qui consiste à rendre "micro-payant" un système destiné au grand public.
Mon seul "malaise" concerne juste le manque de transparence dans la communication de Flattr sur ce prélèvement "destiné uniquement à couvrir les frais de fonctionnement" : je ne peux m'empêcher de penser à toutes les arnaques en ligne jouant sur la sensibilité des utilisateurs.
Mais bon… Ne crions pas au loup trop vite, d'autant plus que l'idée de base (faciliter par micro-paiement et par un système facile à mettre en place le soutien aux auteurs, artistes, etc. qui consacrent un temps précieux à enrichir la base de connaissances du web) me plaît ! D'ailleurs, vous aurez remarqué que je me suis inscrit (et que j'ai donc accepté l'ensemble des conditions d'utilisation, incluant de payer ma dîme), et que le bouton "Flattr" est apparu sur les billets de ce blog (l'installation d'un simple plugin WordPress aura suffit).
Et puis, si de vrais mécènes s'inscrivent dans l'unique but de financer les autres, tout le monde pourrait être gagnant (on peut toujours rêver) :
- les éditeurs de contenu récupérant plus d'argent qu'ils n'en dépensent dans ce système
- Flattr gagnant de l'argent par ses prélèvements
De manière purement théorique et simpliste, pour que chaque éditeur gagne au moins autant qu'il dépense, en supposant la répartition des "flattrs" est homogène (hypothèse on ne peut plus fausse), il faut qu'un minimum de 11% des sommes "flattrées" le soient par des purs mécènes. J'avoue que je ne sais absolument pas quelle est la proportion mécènes/utilisateurs… et je ne suis pas sûr que Flattr communique un jour les chiffres à ce sujet.
Note : si le "Flattr ID" numérique qui m'a été attribué est un entier auto-incrémenté, nous sommes depuis mon inscription plus de 33000 utilisateurs du système.
Mais je ne me fait pas d'illusions : dans tous les cas, je serai plus mécène que millionnaire avec ce système. Le compteur de tweets de mes billets flirte avec le 0 (quand tweeter est un clic gratuit), alors un Flattr payant, je n'en parle même pas…
Note de conclusion pour moi-même : si je veux plus de tweets (et "flattrs"), il faudrait peut-être que je songe à écrire des billets intéressants… En attendant, je vais commencer par essayer de trouver des contenus intéressants à Flattrer. J'en ai déjà trouvé un sans difficultés. Pour les autres, le site Flattr offre un moteur de recherche intéressant permettant de trouver chaque mois du contenu à flattrer (par type d'oeuvre, par popularité, flattrement parlant, par tags, etc.).
[Edit] Mise à jour le 23 août 2010 : pas de changement majeur dans le fond, mais quelques précisions oubliées dans la première version de l'article, comme l'existence d'un moteur de recherche.[/edit]
Veille Technologique 2.0
18/08/10
Depuis 2006, début de ma vie professionnelle, je fais de la veille technologique.
Ca a commencé par la lecture des blogs techniques et sites d'information (dont certains sont dans ma liste de liens), généralistes et spécialisés dans le domaine du Java/J2EE. Avec le temps et l'ajout à ma liste de nouvelles sources d'information toutes plus intéressantes les unes que les autres, la lecture quotidienne de chacun de ces sites s'est avérée chronophage. Je suis donc naturellement passé à l'agrégation de flux RSS, avec Google Reader.
Dans le même genre, j'ai essayé NetVibes. Entre les deux, c'est affaire de goût : il est moins sobre que Google Reader, mais offre des fonctionnalités intéressantes : sur chaque "Tableau de bord" (correspondant à un centre d'intérêt), les informations sont affichées par source (présentation que j'apprécie), et des widgets sont disponibles (réseaux sociaux, etc.).
Mais ce n'est que récemment que je suis passé à une "veille 2.0", lorsque je me suis mis à utiliser Twitter comme source d'information. Mea culpa pour ce retard, que je vais tenter de justifier. En utilisant Facebook, je m'étais dit (avis que je partage toujours avec moi-même) que cet outil est purement ludique (encore que je goûte assez peu à la joie des "pokes"), et absolument pas adapté à une utilisation professionnelle. Cet avis m'est d'ailleurs confirmé par le fait que très peu d'entreprises ont un compte ou un groupe Facebook qu'elles animent. A l'époque, en regardant Twitter de très loin, j'ai cru qu'il s'agissait d'un Facebook réduit à sa seule fonctionnalité "Ecrire sur le mur" : je me suis donc dit que ça n'avait aucun intérêt, et j'ai passé mon chemin.
Ce qui m'a mis la puce à l'oreille sur mon erreur, c'est que les personnes et sociétés que je suivais dans ma veille avaient pour la plupart un compte Twitter. J'y suis donc retourné et j'y ai regardé d'un peu plus près. Si effectivement, Twitter a des allures de "mur Facebook", son fonctionnement n'est pas le même, et c'est ce qui fait toute la différence :
- contrairement à la relation d'amitié sur Facebook qui est obligatoirement réciproque, sur Twitter, le fait de suivre quelqu'un sur Twitter n'implique pas la réciprocité.
- la possibilité de faire suivre aux personnes qui nous suivent les tweets qu'on a lus et qui nous paraissent intéressants (propagation d'informations).
Ces deux fonctionnalités font de Twitter un outil tout à fait adapté à la veille. Après plusieurs mois d'utilisation, je remarque que Twitter est le moyen le plus rapide par lequel je me tiens informé des dernières nouvelles du monde informatique (et plus spécifiquement Java). Pour compléter, je vous renvoie à cette analyse plus complète de Nicolas Martignole, ainsi qu'à un guide des us et coutumes de Twitter pour les débutants qui m'a été bien utile pour comprendre les tweets quand je m'y suis mis.
En rédigeant cet article sur les réseaux sociaux, il m'est revenu à l'esprit une question rencontrée lors d'un devoir en école d'ingénieurs, que je vous retransmets en guise de conclusion :
On suppose qu'on dispose d'une relation d'amitié réciproque (au sens mathématique : "A est ami avec B => B est ami avec a").
Dans une foule de n personnes (n>=2), démontrer qu'au moins deux personnes ont le même nombre d'amis
Mise à jour de mon environnement de développement
16/08/10
Comme à chaque sortie de version d'Eclipse, j'attendais pour Helios la disponibilité du plugin pour l'utilisation des serveurs Glassfish.
Le rachat de Sun par Oracle aura eu cet effet positif : le plugin n'a pas mis longtemps à sortir. Et Oracle a même fait mieux que ça : il a rafraîchi son IDE "Oracle Enterprise Pack for Eclipse" (OEPE de son petit nom), qui jusqu'à maintenant était toujours basé sur une (quand ce n'était deux) version de retard d'Eclipse. Je l'ai téléchargé et testé et je dois avouer qu'il m'a convaincu :
- il est basé sur la dernière version stable d'Eclipse, Helios
- il apporte d'un seul coup le support des deux serveurs d'Oracle, Weblogic et Glassfish
- il intègre un certain nombre d'outils dédiés au développement J2EE, comme le Oracle JSP Validator, ou encore la prévisualisation de ces mêmes pages JSP
Je l'ai donc adopté, et jusqu'à maintenant, je n'ai pas été déçu. C'est une petite surcouche à Eclipse, agréable sans pour autant être trop lourde. Je m'en suis donc servi comme base pour une réinstallation propre de mon environnement de développement habituel. Je vais donc profiter de celle-ci pour écrire un petit tutoriel (un de plus, par rapport à tous ceux que vous trouverez déjà grâce à Google) de mise en place de cet environnement.
La suite >
Nouvelle option multi-compte de Google
10/08/10
Il y a quelques jours, j'ai appris l'existence d'une nouvelle option de Google permettant de se connecter simultanément à plusieurs comptes GMail. Je n'ai qu'un seul compte GMail… mais plusieurs autres comptes mails sur les Google Apps, gérant les mails de mon domaine.
Cette fonctionnalité m'intéressant donc beaucoup pour passer d'un compte à un autre, je me suis dit que ça ne coûtait rien d'essayer. Mais sans manuel, il m'a fallu au moins 5 minutes pour comprendre comment activer l'option en question… A moins de disposer d'un doctorat spécialisé en technologies Google, trouver l'option magique relève vraiment du casse-tête.
Pour ceux que l'expérience intéresse et qui comme moi, ne connaissent pas les menus GMail par coeur, voici comment procéder :
- Tout d'abord, inutile de chercher l'option sur les comptes Google Apps : elle n'existe pour le moment que sur les comptes GMail (ce qui n'augure rien de bon sur ma velléité de passer rapidement d'un compte GApps à un autre…).
- Sur les comptes GMail maintenant, il faut savoir que l'option n'est disponible que si votre interface est en anglais (il faut savoir que beaucoup d'options de Google sont d'abord rendues disponibles dans l'interface anglaise, comme c'était le cas il y a quelques temps pour les plugins GMail Labs).
- La première chose à faire est donc de se rendre dans les paramètres (lien en haut à droite de la fenêtre), et dans l'onglet Général, de changer la langue d'affichage de GMail pour passer en anglais (US ou UK).
- On valide en bas de la page. On revient ensuite dans les paramètres (devenus les Settings si le changement de langue s'est bien passé) et on passe alors au troisième onglet, Accounts and Import.
- En bas de cette page de paramètres, c'est le lien Google Account Settings qui permettra finalement d'accéder à la page où normalement, l'option Multiple sign-in est apparue !
Ouf !… Il ne reste plus qu'à l'activer. En haut à droite, le nom du compte devient alors un lien permettant d'enregistrer les autres comptes auxquels on veut se connecter. Pour moi, c'est raté : l'option ne fonctionne pour l'instant qu'avec les comptes GMail… Comme je n'en ai qu'un, je n'en ai pas l'utilité pour l'instant : il ne me reste donc plus qu'à remettre mon compte en ordre en désactivant l'option, en remettant l'interface en français… et à attendre que l'option soit étendue aux comptes Google Apps !
En attendant, j'espère que ce petit billet permettra à ceux qui veulent activer l'option de le faire plus rapidement…
Pour ceux qui ont eu le courage de lire ce billet jusqu'au bout, voici maintenant le raccourci ! Une fois connecté à son compte GMail, la page de gestion du compte (où on peut activer la fameuse option) est disponible à l'adresse https://www.google.com/accounts/ManageAccount?service=mail&hl=en : beaucoup plus simple que la liste des manipulations ci-dessus, mais il faut le savoir !
MAC : un an après…
7/08/10
Cela fait maintenant presque un an que j'utilise mon MacBook Pro (13 pouces). Peu de temps après son acquisition, j'avais dressé un premier bilan, à chaud. Le temps des vacances est propice à un second bilan mis à jour, mais avec une année supplémentaire de recul.
Le matériel
Du point de vue matériel, je n'ai toujours rien à redire. Et ce jusqu'à la batterie, qui après une utilisation preque quotidienne, garde une autonomie irréprochable : supérieure à 5 heures pour une utilisation bureautique, et largement suffisante pour regarder un film sur batterie lors d'un déplacement en train.
N'ayant rencontré aucun problème avec le matériel, je n'ai aucun commentaire à faire sur le SAV (je n'allais pas les contacter juste pour le plaisir).
Le poids et la taille (13 pouces) de la machine en font un outil idéal pour les déplacements. Le MAC est donc maintenant la machine qui m'accompagne partout, que ce soit en déplacement professionnel ou en vacances.
Le système d'exploitation
Passons maintenant au système, Snow Leopard. Afin de garder la possibilité de choisir mon environnement de travail, j'ai installé Windows 7 grâce à Boot Camp, ainsi qu'un Ubuntu 10.04 sur Virtual Box.
Les réserves que j'avais sur l'utilisabilité de Snow Leopard ont majoritairement disparues au fur et à mesure que je me suis habitué au système, même si je continue de trouver peu pratique pour développer le clavier MAC (ALT+SHIFT+'(' pour un crochet ouvrant, ALT+SHIFT+L pour un "pipe", etc.). Pour le développement, ça donne vraiment envie de se remettre au QWERTY, beaucoup mieux agencé :
Clavier MAC QWERTY
Malgré ce défaut, c'est tout de même sous Snow Leopard que je passe 70% de mon temps, ce système répondant à la majorité de mes besoins (et travailler sur un système à base d'Unix a vraiment du bon, même s'il existe Cygwin sur Windows). Le reste de l'utilisation se divise entre Windows 7 et Ubuntu. Bien que j'ai progressé dans la maîtrise de Snow Leopard, je ne suis pas encore un "power user" de ce système. De là où j'en suis, j'apprécie autant Windows 7 que Snow Leopard, qui ont chacun leurs avantages. Au passage, Steve aurait de sérieuses améliorations à apporter au Finder… La gestion des fichiers sous MAC est vraiment laborieuse.
Les logiciels
C'est à mon avis le gros point noir du MAC, par rapport à Windows. Aucun de ces deux systèmes n'est naturellement proche du monde Open Source… mais comme la communauté Windows est beaucoup plus importante, on trouve en général dans tous les domaines un (ou plusieurs) logiciels Open Source (ou au moins gratuits) qui répondent à nos besoins.
Sous MAC, le nombre de logiciels gratuits disponibles est beaucoup moins important, et il s'agit souvent de logiciels qui sont également disponibles sur les autres systèmes d'exploitation (FileZilla pour les transferts FTP, yEd pour l'édition de diagrammes, etc.).
Il existe quelques logiciels gratuits vraiment dédiés aux MAC (Adium comme client MSN, Tweetie comme client Twitter, etc.) mais ils sont loin de couvrir l'ensemble des besoins. Il existe certes d'excellents logiciels pour les autres besoins… mais ils sont loin d'être abordables quand on n'en a qu'une utilisation occasionnelle (Omnigraffe pour l'édition de diagrammes, par exemple).
Jusque là, rien de bien méchant. Les logiciels dont j'ai l'habitude fonctionnant aussi bien sur MAC que sur Windows. Là où le bât blesse, c'est que pour certaines fonctionnalités, il n'existe rien de convainquant sur MAC parmi les logiciels gratuits. Je pense en particulier à deux fonctionnalités pourtant basiques, pour lesquelles je n'ai pas trouvé mon bonheur :
- l'édition de texte : je n'ai pas encore trouvé sur MAC l'équivalent de PsPad ou de Notepad++. Il y a bien JEdit ou TextWrangler, mais aucun de ces logiciels n'a les fonctionnalités avancées que l'on peut trouver sur les logiciels existants sous Windows.
- la compression/décompression : il y a bien des logiciels comme Stuffit, mais il y a quelques temps, j'ai eu besoin de faire une compression avec mot de passe, ce qui nécessite une version payante de Stuffit (ou des autres gestionnaires d'archives sous MAC). J'ai donc dû lancer la compression en ligne de commande. A ce jour, comme pour l'édition de textes, je n'ai toujours pas trouvé d'équivalent gratuit de 7-Zip ou de PeaZip sous MAC.
Conclusion
En conclusion, cet ordinateur est une bonne machine, le système est agréable à utiliser, et on peut considérer que j'ai définitivement "switché" (sur cette machine du moins… sur mon PC fixe, je reste sur Windows 7). Cependant, il souffre à mon goût d'une logithèque gratuite beaucoup trop réduite. Pour bon nombre de choses, il faut soit se rabattre sur des logiciels qu'on utilise déjà sous Windows lorsqu'ils existent (et le Mac n'a donc pas de valeur ajoutée par rapport à Windows), soit passer à la caisse.
Nouvelles fonctions d'agrégation pour Talend Open Studio
6/08/10
Spécifications
Récemment, j'ai été confronté à la problématique suivante, en apparence assez simple : un fichier contenant une liste d'opérations bancaires. Chacune de ces opérations correspond (entre autres) à un client et à un statut booléen (opération approuvée ou rejetée). Pour simplifier, on supposera qu'une opération n'est constituée que de ces deux attributs.
Le but était de trier les clients en deux catégories : ceux dont toutes les opérations ont été approuvées, et ceux ayant eu au moins une opération rejetée (l'équivalent sur le fichier d'un "GROUP BY" SQL).
Analyse
Pour réaliser cette opération, j'ai évidemment sorti mon ETL préféré, Talend Open Studio et son composant tAggregateRow. Mais là, petite surprise : il n'existe pas de fonction d'agrégation "booléenne" (et logique, ou logique, etc.). Et comme il n'existe pas de relation d'ordre sur les booléens, impossible d'utiliser directement les fonctions MIN ou MAX.
Contournement
Dans un premier temps, la solution de contournement n'a pas été difficile à trouver (il en existe d'ailleurs un certain nombre) : convertir les "true" en "1" et les "false" en "0". Avec cette transformation, la fonction booléenne "ET" est représentée par la fonction mathématique "MIN" et la fonction booléenne "OU" par "MAX" dans l'agrégation. Après cette agrégation, il suffit de faire la transformation inverse pour revenir à des booléens. En plus de la lecture du fichier et de l'écriture de la sortie, il suffit donc de 3 composants pour réaliser le traitement souhaité.
Amélioration du composant
Je suis maintenant en vacances, et j'ai donc le temps de reprendre ce problème à tête reposée. Deux composant pour faire deux transformations inverses, cela ne me satisfaisait pas. Je me suis donc penché sur l'étude du composant tAggregateRow, pour voir comment étendre ses fonctionnalités aux agrégations de champs booléens.
Je comptais en profiter de ce cas d'utilisation pour commencer un tutoriel sur le développement et l'amélioration de composants, mais je suis revenu sur cette idée : le composant tAggregateRow n'est pas des plus simples (il est en particulier constitué de deux sous-composants techniques tAggregateIn et tAggregateOut), et n'est donc à mon avis pas un bon exemple pour aborder les généralités du développement de composants, mais ce n'est que partie remise.
Je passe donc directement à la conclusion : depuis le 29 juillet 2010, vous trouverez sur Talend Exchange le composant bcAggregateRow, permettant d'agréger des champs booléens avec les fonctions booléennes "ET", "OU", et "OU EXCLUSIF".
Mésaventures avec Mio
28/07/10
Si vous n'avez pas encore deviné à partir du titre de cet article, je vous déconseille fortement d'acheter vos GPS chez Mio.
Voici donc mon expérience monologue (n'ayant jamais obtenu de réponse aux multiples mails envoyés) avec leur service clientèle :
Tout a commencé au début de l'année 2009. Sur Cdiscount, le modèle Mio Moov 580, datant de 2008 était en promotion (liquidation des stocks, la gamme suivante étant apparue). Ce modèle avait eu une bonne critique, et l'offre précisait deux choses qui m'ont convaincu d'acheter :
- possibilité de mettre gratuitement à jour les cartes dans les 30 jours suivant l'achat
- abonnement de 3 ans offert à la mise à jour des radars
Je n'avais pas relevé à l'époque, mais voici comment les choses s'étaient passées : après avoir demandé la mise à jour des cartes, je reçois un fichier de cartes, ainsi qu'un code d'activation associé. Au moment de saisir celui-ci, j'obtiens un message d'erreur, que je n'ai plus exactement en tête, mais qui en substance était "Code d'activation incorrect". Naturellement, je contacte le service client (par mail, le téléphone étant surtaxé). Je n'ai jamais eu de réponse…
Je me suis donc retrouvé avec un appareil certes fonctionnel, mais avec des cartes de 2008, et sans la mise à jour offerte. Si j'en crois ce qu'on peut lire sur internet, je ne suis pas un cas isolé.
Ca, c'était il y a maintenant plus d'un an. Nous pouvons maintenant passer à l'acte 2 : avant de partir en vacances cet été, j'ai décidé de remettre ce problème sur le tapis. Et plutôt que d'acheter un nouveau GPS, j'ai décidé de mettre à jour ce Moov 580, qui n'est pas si vieux que ça et qui me donne satisfaction, à l'exception des cartes obsolètes et des erreurs de navigation qui en découlent…
Etape obligatoire pour la mise à jour du GPS : passer à la caisse ! Les cartes d'Europe coûtent la bagatelle de 50€ (pour la version à télécharger). Notons que le système de mise à jour est contre-intuitif, et le PDF fournit avec l'explication pas à pas n'est vraiment pas de trop pour réussir.
Au passage, j'ai changé d'ordinateur depuis l'achat de ce GPS (et je n'avais pas pris la peine de réinstaller "MioMore Desktop", le logiciel de gestion du GPS). Impossible de le télécharger sur le site de Mio, celui-ci ne proposant qu'une mise à jour : il m'a donc fallu faire des excavations pour remettre la main sur le CD original du produit avant de pouvoir procéder à la mise à jour des cartes…
Je finis tout de même par réussir ma mise à jour, et suis donc satisfait. J'aurais pu le demeurer si je n'avais fait quelques vérifications d'usage… Le fichier de mise à jour étant une ISO du DVD de mise à jour, je l'explore par curiosité avec mon 7Zip favori. Et là, quelque chose attire mon attention : dans le répertoire "Maps", les fichiers sont horodatés de 2009. Quelques vérifications plus tard, je m'aperçois que la mise à jour que je viens juste d'acheter… contient des cartes vieilles de presque un an et demi !
Comme il y a un an, je contacte le service client… et comme il y a un an, pas de réponse !
Vu la politique de ce service clientèle, je vous suggère donc vivement de passer votre chemin et d'aller voir du côté de la concurrence, et ce quelle que soit la qualité de leurs produits. J'envisage pour ma part d'aller voir du côté de Coyote.
S'il y a des suites à ces mésaventures (un service client qui se réveillerait…), je ne manquerai pas de mettre cet article à jour.
