99 Scala problems : les 22 premiers

Après quelques articles et tutoriels, ainsi que quelques tests sur les interactions avec Java, j’ai commencé mon apprentissage du Scala par les 99 Scala problems.

Avant de me lancer dans la résolution des problèmes en question, et en application des bonnes pratiques du TDD, j’ai écrit les signatures des méthodes, et les tests associés à ces 22 problèmes. Si vous voulez vous lancer, je vous épargne cette première étape : vous pouvez télécharger directement ce squelette.

Vous pourrez vérifier que les 22 tests échouent. Ces tests sont cependant rudimentaires, et les faire passer au vert ne garantira pas que vous avez la bonne solution (même si c’est encourageant).

D’autres personnes se sont lancées avant moi dans la résolution de ces problèmes. Comme il est toujours intéressant de comparer les différentes approches, en voici quelques unes (en plus des solutions du site original) :

Continuer la lecture

Publié dans Java | Marqué avec , , | Un commentaire

Mettre en place un workflow git

Si vous avez été à une ou deux présentations de git, vous avez sans doute déjà vu ce diagramme (ou un équivalent).

Après avoir un peu pratiqué git, ce genre de workflow devient naturel, et est particulièrement appréciable :

  • les fonctionnalités ont chacune leur branche dédiée : la lecture de son historique n’est donc pas gêné par le reste des développements
  • les livraisons peuvent être préparées sans empêcher les personnes qui travaillent sur les futures fonctionnalités de partager leur travail
  • etc.

Voila pour la théorie : sur le papier, ça laisse absolument rêveur ! Mais dans la pratique, tout ne fonctionne pas aussi bien, surtout au début. Et c’est là que commence mon retour d’expérience sur la mise en place de ce workflow.

Continuer la lecture

Publié dans Systèmes d'information | Marqué avec , , , , | 4 commentaires

Deuxième journée de What’s Next

Aujourd’hui, j’ai réussi à obtenir une connexion WIFI (reste à savoir pour combien de temps…). Je vais donc tenter de résumer cette deuxième journée de conférences en direct.

La journée commence de manière très conviviale, autour d’un café avec Nicolas de Loof, qui nous quittera précipitamment pour aller tester git rerere et mettre à jour sa présentation de ce soir. J’en profite pour faire la publicité des ateliers git attitude qui m’ont appris l’existence et l’utilisation de cette commande !

Keynote de Neal Gafter

Neal Gafter est une des figures emblématiques du langage Java, ayant contribué à son commencement. Il commence par nous présente un historique complet du langage, et des évènements survenus lors de son développement (problème des TCK et du projet Harmony, etc.). Au passage, quelques tests tirés de son livre Java Puzzlers (sur lesquels je me suis fait avoir : j’ai encore quelques révisions à faire…).

Nous passons maintenant à une partie qui m’intéresse : le cloud (encore !), mais à la sauce Microsoft :  Azure. La plate-forme de cloud tourne en environnement Windows, mais se veut ouverte à tous les langages de développement.

Avec la plate-forme Azure, on ne s’occupe pas des machines virtuelles : la plate-forme le gère pour nous, et fournit les VMs clés-en-main, en appliquant automatiquement les patchs de sécurité, etc. Le but est de permettre aux développeurs de se concentrer sur les applications. De même, la plupart des briques techniques sont gérées automatiquement : le load-balancing, l’ajout d’une base de données, etc.

Sur ces points, la description de cette plate-forme me rappelle fortement ce que j’ai pu voir de Cloud Foundry.

Apparemment, Azure est Java Ready : SDK Java, support de JDBC4 (et donc des frameworks de persistence comme Hibernate). Il y a également un Starter Kit permettant de configurer un projet Java sur le cloud.

RabbitMQ par Rob Harrop

Pas de WIFI pendant cette présentation, j’écris le compte-rendu à postériori. Rob était absolument impressionnant (je le soupçonne d’être en fait Chuck Norris déguisé) : démonstration live sans aucun « effet démo » sur 4 langages différents (Java, Erlang, Ruby, Python) pour montrer l’inter-opérabilité de la plate-forme. Ca donne vraiment envie de l’essayer !

A suivi une phase de questions-réponses assez pointues sur la scalabilité, la résistance à la panne, les différences d’approche par rapport à d’autres technologies de messagerie, etc.

Pause déjeuner

Tirage au sort de l’iPad 2 : encore perdu… Je ne perds pas espoir d’en gagner un prochainement.

Comme hier, au Mc Donald’s d’en face, mais sans passer par la case sandwichs.

Le découplage de services par Theo Schlossnagle

Un contributeur à presque 20 projets OpenSource, ça force le respect…

Début de conférence sur les chapeaux de roue : on met les pieds dans le plat avec les raisons du choix d’une architecture NoSQL ou Cloud.

Très bonne démonstration du fait qu’on n’a pas besoin de milliers de machines pour scaler, mais de repenser son modèle dans la majorité des cas.

Le découplage d’une application en systèmes élémentaires indépendants donne de la flexibilité, mais est une opération très complexe. Elle nécessite des systèmes de files (ActiveMQ, RabbitMQ, etc.).

Pour bien concevoir un système, on doit faire la part des choses entre ce que l’on veut (un résultat instantané), et ce que l’on peut obtenir (calcul trop long pour permettre un résultat instantané). Dans ce cas, il faut découpler ce calcul dans un système asynchrone.

Conseils pour parvenir à ses fins :

  • Programmation défensive (timeouts, points de vérification, etc.)
  • Mise en place de monitoring (vitesse de traitement, taille des files d’attente, nombre de connexions concurrentes, etc.)

Si une application doit tomber en erreur, il faut qu’elle tombe en erreur rapidement (timeouts, etc.) !

Résumé final : excellente conférence pleine de très bons conseils d’architecture !

Tirage au sort des gagnants de places VIP pour Rolland Garros

Félicitations Alexandre !

Architecturer l’expérience utilisateur, par Michaël Chaize

Conférence en français (ça mérite d’être souligné).

L’architecture est impactée par l’expérience utilisateur qu’on veut donner à ses clients

Flex est devenu Open Source en 2007, et peut être codé en ActionScript 3 ou en MXML. Il génère ensuite un fichier Flash. Flex est utilisé à 90% pour des applications internes [Mode mauvaise langue]par honte de les exposer au public[/Mode mauvaise langue].

Depuis 2007, la fondation OpenScreen a permis de travailler avec les acteurs du marché mobile pour optimiser le player Flash sur les terminaux, à l’exception d’un acteur du marché qui a refusé. On se demande bien lequel

Flex 4.5 semble effectivement assez adapté au développement mobile :

  • prise en compte des différentes résolutions d’écran
  • développement unique pour Android 2.2 et 2.3, Blackberry Playbook, et les tablettes Apple (moyennant une conversion de code)

Présentation intéressante, et qui donne envie. Mais malheureusement, je n’ai pas vraiment le temps en ce moment de faire du développement mobile (trop d’autres choses dans ma todo-list d’études).

Conférence Akka par Jonas Bonér (CTO de TypeSafe)

Il est difficile de construire des systèmes gérant correctement la concurrence et la scalabilité. Akka (et Scala) a été créé pour tenter de proposer des solutions à cette problématique.

Les trois briques principales de Akka :

  • Tolérance à la panne (supervision)
  • Scalabilité (système des Actors et clustering)
  • Concurrence (Actors, STM, Agents, Dataflow)

Plus tout un ensemble de modules add-on (JPA, etc.)

Qu’est ce qu’un acteur ? un acteur ressemble à un objet : c’est un état, et un comportement. Un acteur est indépendant, isolé, et ne partage pas son état : il n’y a donc pas de mécanisme de lock à implémenter pour gérer la concurrence. Les acteurs communiquent par un système de messages. Les acteurs sont indépendants des threads (à ceci près qu’un acteur est MonoThread) : la seule limitation du nombre d’acteurs est la mémoire.

L’envoi d’un message à un acteur n’attend aucun retour. Le traitement du message est asynchrone. On peut cependant attendre un résultat futur (associé à un timeout) :

1
2
3
4
5
actor ! message
 
val future = actor !!! message
future.await
val result = future.result

Le comportement des acteurs est complètement déterministe.

Travailler avec des acteurs distribués sur plusieurs machines est presque transparent pour le code. Le runtime fournit un mécanisme de clustering (gérant le failover) pour les acteurs, avec plusieurs stratégies de choix du serveur d’exécution (CPU utilisé, mémoire utilisée, etc.).

Elastic Search, par Shay Banon

Présentation très originale, qui s’est déroulée sans aucun slide, mais juste avec une console, et l’outil cURL, qui servait à attaquer l’API REST d’Elastic Search. Pour résumer, Elastic Search est un outil construit autour de Lucene avec les grandes fonctionnalités suivantes :

  • Fonctionnement en cluster (avec une gestion très simple de l’ajout d’un serveur au cluster)
  • API d’accès entièrement construite en REST, avec des données JSON

L’ensemble de la présentation consistait à nous montrer des fonctionnalités de plus en plus complexes :

  • utilisation d’un noeud, puis d’un cluster de noeuds
  • création d’index simples, puis complexes (en imposant un format de mapping)
  • recherches simples, puis complexes (filtrage, etc.)

Je n’ai encore jamais eu l’occasion de travailler sur une problématique d’indexation de documents (à l’exception d’une mise en place d’une GED Alfresco, mais où l’indexation est déjà gérée). Mais si ça devait arriver, l’API d’Elastic Search en fait un produit qui a l’air particulièrement intéressant.

L’avenir de l’intégration continue par Kohsuke Kawaguchi

La présentation commence par un bilan : la puissance des machines de développement augmente de manière exponentielle. Or, les compétences des développeurs ne suivent pas cette même évolution. Par rapport à la puissance des machines, le développeur est donc une denrée précieuse : il faut donc veiller à ce que l’outillage exploite eu mieux cette puissance machine pour permettre aux développeurs de gagner du temps.

Pour cela, plusieurs pistes :

  • utiliser au mieux les gestionnaires de configuration distribués (git par exemple)
  • faire exécuter les tests sur le serveur d’intégration continue au lieu de les exécuter sur les machines des développeurs
  • etc.

Epilogue

Voilà deux journées très intéressantes, sans aucun bémol majeur : c’est donc une grande réussite pour Zenika (dont je remercie toute l’équipe au passage), qui nous a d’ors et déjà invités à revenir l’année prochaine.

La soirée s’est achevée pour moi par plus d’une heure de discussions techniques passionnées sur les quais du métro avec Alexandre (rencontré hier par l’intermédiaire d’Antoine).

Félicitation à Nicolas qui a le courage de rempiler pour la soirée Jenkins… J’aurai une pensée émue pour sa présentation de ce soir (et j’en suis quitte pour un prochain article sur git, sauf si Sébastien me devance).

[Mise à jour : quelques autres compte-rendus]

[Et ça continue…]

Publié dans Java | Marqué avec , , | Laisser un commentaire

Première journée à la What’s Next

Je vais certainement manquer de temps pour résumer l’ensemble de cette journée… d’autant plus qu’on repart dès demain pour une deuxième journée de conférences toute aussi intéressante que la première.

Une logistique perfectible

Commençons par le sujet qui fâche… la logistique ! A la décharge de Zenika, c’est la première édition de la What’s Next. Et gérer la logistique pour une conférence de plus de 600 participants, ce n’est pas une mince affaire. Voici donc quelques points perfectibles :

  • Le Grand Rex n’a visiblement pas l’habitude de recevoir en même temps 500 geeks, tous équipés de leur {smartphone/tablette/ ordinateur portable} (rayer les mentions inutiles). Les 3 réseaux WIFI disponibles ont rapidement été saturés, et n’attribuaient plus d’adresse IP. Heureusement qu’il restait la 3G d’urgence pour couvrir l’évènement via Twitter (le hashtag officiel wsnparis ayant bien servi).
  • Un seul point de ravitaillement en café pour les mêmes 500 geeks, c’est l’embouteillage assuré à chaque pause (encore qu’il faille relativiser : la distribution restait suffisamment fluide, et que j’ai toujours pu avoir mon café).
  • Le déjeuner a convaincu une bonne partie des participants de se retrouver au Mc Donald’s d’en face. Cependant, vu le rapport entre le prix d’entrée et la qualité des conférenciers présents, je ne regrette pas le déjeuner un peu léger. J’aime autant que la conférence reste à prix abordable, quitte à devoir sacrifier sur la nourriture.

Le choix du Grand Rex a pourtant un certains nombres d’avantages indéniables :

  • bien placé, au centre de Paris
  • des sièges bien plus confortables que dans la majorité des salles de conférences

Une ambiance géniale et des rencontres très sympatiques

Comme d’habitude, la journée a été très riche en rencontres. Outre les personnes déjà croisées au Paris JUG (ou autres évènements), j’ai pu faire la connaissance aujourd’hui de David Gageot, Nicolas de Loof, Arnaud Héritier, Florian Boulay, ainsi qu’un bon nombre d’autres personnes…

L’ambiance générale de l’évènement était très agréable : très détendue, très geek (sur l’ensemble des participants, on n’a pu dénombrer que quelques cravates). Sur ce sujet, la palme revient d’ailleurs certainement à Jevgeni Kabanov.

Enfin, la fin de journée sur une discussion autour d’une bière était une super-idée pour permettre un debriefing et des débats passionnés dans une bonne ambiance, même si j’ai dû m’absenter assez rapidement, étant attendu.

De très bonnes conférences

Les conférences étaient très bonnes. Parmi celles-ci, j’ai particulièrement apprécié :

  • La keynote d’Adrian Colyer, où il était question surtout question de cloud, de cloud… et de cloud ! Cette conférence m’a donné envie de me repencher sur Cloud Foundry, après quelques premiers tests. Au passage, on notera l’apparition d’un nouveau buzzword qui devrait faire fureur dans les prochaines : le microcloud (j’aurai peut-être l’occasion de revenir sur ce concept dans un prochain article).
  • La présentation du projet Eclipse Orion, par Boris Bokowski. Elle ne m’a pas convaincu d’abandonner IntelliJ IDEA, mais la démonstration des possibilités d’édition était impressionnante : on ne se croirait pas dans une application web ! Parmi mes appréhension, je me pose en particulier la question suivante : l’IDE web est-il résistant à la perte de la connexion réseau et permet-il de travailler offline ?
  • La présentation de Clojure par Howard Lewis Ship était intéressante : elle rappelait bien les différents paradigmes de la programmation fonctionnelle. Cependant, le langage lui-même ne m’a pas du tout convaincu : les exemples de code étaient particulièrement difficiles à relire, et me rappelaient la syntaxe sur-parenthésée du LISP. Sur les langages fonctionnels, je vais donc certainement continuer de faire l’impasse sur Clojure, et poursuivre ma découverte de Scala.
  • La présentation de Jevgeni Kabanov sur la gestion de la mémoire en Java était passionnante. En particulier, la modélisation du CPU et de la gestion mémoire par du code Java était impressionnante ! En résumé, un excellent cours de culture générale sur la gestion de la mémoire en Java. Pour revoir cette conférence (éventuellement au ralenti), c’est dans l’ordre ici, ici, et ici.
  • Enfin, la présentation des Web Sockets parBrad Drysdale m’a là encore donné envie d’étudier cette API de plus près. Par chance, je me souviens avoir lu rapidement un article parlant des Web Sockets et de Play Framework.

Après cette conférence, je sens que je vais avoir un programme d’étude chargé ces prochains week-ends… Vivement demain pour la suite !

[Mise à jour] Pour un résumé beaucoup plus détaillé de cette première journée, conférence par conférence (et avec des photos), foncez chez Nicolas.

Publié dans Java | Marqué avec , , | 3 commentaires

Premiers pas en Scala

Cela fait maintenant pas mal de temps que j’entends parler de Scala, mais je n’avais jamais pris le temps m’y attarder. Il y a maintenant deux semaines, l’annonce du lancement de Typesafe (on pourra lire l’article de Nicolas pour plus d’informations) m’a donné envie de regarder de plus près ce langage.

En attendant mon prochain passage par la FNAC pour trouver un bon livre sur la question, j’ai été glaner quelques informations pour débuter :

J’ai eu la chance d’avoir des cours de Caml Light en prépa et de Lisp en école d’ingénieurs : la programmation fonctionnelle ne m’est donc pas inconnue, ce qui m’a grandement facilité l’entrée en matière (même si j’ai rapidement dû me mettre à niveau avec les Case Class et autres concepts que je n’avais encore jamais rencontré).

Les cours de prépa que j’ai pu avoir sur la question étaient excellents. Même s’ils concernent le langage Caml, ils fournissent des exemples originaux dans lesquels la programmation fonctionnelle permet de s’en sortir bien plus facilement qu’en programmation procédurale. Je propose donc aux curieux d’aller les consulter sur le site de notre enseignant.
Continuer la lecture

Publié dans Java | Marqué avec , , | 4 commentaires

PlayFramework et CloudFoundry RELOADED

L’informatique bouge décidément très vite !… A peine quelques jours et mon précédent article est déjà obsolète. Voici donc sa mise à jour.

Problèmes de fixtures

Revenons tout d’abord aux problèmes que j’ai rencontré avec la classe Fixtures, qui provoquaient deux erreurs lors du déploiement de l’application sous forme de WAR. Il s’agissait d’un bug spécifique à la version 1.2 de PlayFramework. Or avant même que j’aie le temps de le temps de dire ouf, la version 1.2.1 était publiée (une journée après mon article), corrigeant le bug en question !

J’ai depuis revérifié mon exemple : plus aucun problème de ce côté. Il est donc possible de déployer l’application YABE sur Cloud Foundry sans avoir à modifier la moindre ligne de code.

1
2
3
4
5
6
cd $PLAY_HOME/samples-and-tests
play war yabe -o yabe_war
cd yabe_war
jar -cvf yabe.war *
rm -rf WEB-INF
vmc push

Ca marche !

Utilisation du service MySQL de CloudFoundry

De ce côté là aussi, les choses ont bougé. Je me suis attelé à la tâche en créant un plugin dédié, dont le code (et les binaires) est disponible sur GitHub. Bon, je n’ai pas beaucoup de mérite : le plus gros du travail a été fait par SpringSource, avec le cloudfoundry-runtime.

Ca a été pour moi l’occasion de me familiariser vraiment avec une des nouvelles fonctionnalités de PlayFramework : la gestion des dépendances Maven. Voici à titre d’exemple le fichier dependencies.yml du plugin :

self: play -> cloudfoundry 0.1
require:
    - play
    - org.cloudfoundry -> cloudfoundry-runtime 0.6.0:
        exclude:
            - org.springframework -> *
            - org.springframework.amqp -> *
            - org.springframework.data -> *
            - org.apache.tomcat -> *
            - commons-dbcp -> *
repositories:
    - spring_milestone:
        type: iBiblio
        root: http://maven.springframework.org/milestone
        contains:
            - org.cloudfoundry -> *

Cette librairie effectue le travail de lecture et de parsing des variables d’environnement. Il suffisait donc ensuite de se servir des résultats de se parsing pour configurer la connexion à la base de données.

Cette fois, c’est le PlayFramework lui-même qui va nous simplifier la tâche. Les plugins peuvent surcharger la méthode onApplicationStart(), qui s’exécute comme son nom l’indique au démarrage de l’application.

1
2
3
4
5
6
7
8
9
10
11
public class CloudFoundryDBPlugin extends PlayPlugin {
    @Override
    public void onApplicationStart() {
        Properties p = Play.configuration;
        MysqlServiceInfo mysqlServiceInfo = getInfoFromCloudFoundryRuntimeLib();
        p.put("db.driver", "com.mysql.jdbc.Driver");
        p.put("db.url", mysqlServiceInfo.getUrl());
        p.put("db.user", mysqlServiceInfo.getUserName());
        p.put("db.pass", mysqlServiceInfo.getPassword());
    }
}

Et c’est tout. Pour utiliser ce plugin, il suffit d’ajouter le module correspondant dans l’application PlayFramework que l’on veut déployer sur Cloud Foundry, soit dans application.conf :

1
2
3
# Replace ce memory db by the cloudfoundry MySQL service
# db=mem
module.cloudfoundry=${play.path}/modules/cloudfoundry

Encore une fois, c’est tout : la magie de PlayFramework se charge du reste !

Il n’y a plus qu’à régénérer le WAR et mettre à jour l’application : ça marche, comme en témoigne l’application mise à jour http://yabe.cloudfoundry.com/

Et maintenant…

Le plugin ne gère pour l’instant que la configuration automatique d’un service MySQL de Cloud Foundry. Mais si des spécialistes de Redis, MongoDB veulent donner un coup de main pour gérer ces bases, les merge request de GitHub sont là pour ça.

 

Publié dans Java, Systèmes d'information | Marqué avec , , , | 3 commentaires

Application Play Framework sur Cloud Foundry

Il y a quelques semaines, j’ai obtenu un accès à la béta de Cloud Foundry. Pour ceux qui n’ont pas suivi l’actualité, il s’agit d’un PaaS (Platform as a Service) Open Source de VMWare, permettant d’exécuter en cloud des applications Java (WAR, Spring, ROO), Rails, ou Node.js (pour l’instant, mais d’autres pourraient bientôt venir enrichir cette liste).

Prise en main

La prise en main de l’outil de déploiement VMC via le tutoriel est extrêmement simple. On y apprend à créer et déployer une application sur le cloud en quelques commandes.

Deuxième chose à laquelle je m’intéresse, les systèmes de persistance. On a le choix entre trois systèmes, SQL (MySQL) ou NoSQL : MongoDB (base orientée documents) et Redis (base clé-valeur). Cette liberté de choix est très appréciable, et permet de répondre aux différents types de besoins que l’on peut avoir. Et là encore, on peut penser que d’autres systèmes viendront prochainement enrichir cette liste.

Côté Java, encore de bonnes surprises : contrairement au Google App Engine (par exemple), il n’y a aucune restriction sur l’utilisation de l’API : l’application est exécutée sur un serveur Tomcat. Il est donc possible de développer une application web Java complètement standard, et ensuite de la déployer sur Cloud Foundry au lieu d’un serveur d’application classique.

J’ai fait le test (avec une application simple) et ça fonctionne !

Avec Spring et l’outil de développement Spring Tool Suite, la gestion de la persistence MySQL est très simple, comme expliqué sur le blog officiel.
Continuer la lecture

Publié dans Java, Systèmes d'information | Marqué avec , , , , , , | 3 commentaires

Gérer AUTREMENT un projet Maven avec Git

Comme vous avez été nombreux à apprécier mon article sur Maven et git, en voici la suite ! Il s’agit d’une solution alternative permettant de répondre à la même problématique, basée sur les subtree.

Rappel : mon but était de séparer la gestion de configuration de plusieurs modules Maven d’un même projet, tout en conservant un dépôt pour maintenir le projet (pom racine du projet, etc.).

La problématique étant la même, nous allons nous baser sur le même exemple : un projet créé à partir de l’archetype appfuse-modular-jsf. Pour sa mise en place de ce projet, je vous renvoie donc aux étapes Créer le projet de démonstration et Mise en place des dépôts distants.

Revenons à notre espace de travail

Maintenant que nous avons nos dépôts distants, la première chose à faire pour mettre en place les subtrees est de supprimer les répertoires des deux modules dans l’espace de travail. En effet, avec cette méthode, les modules n’ont pas de dépôt git locaux dédiés.

Déclarons ensuite les dépôts distants de notre espace de travail :

1
2
3
git remote add origin $BARE_REPOS/demo.git # S'il n'existe pas déjà
git remote add core $BARE_REPOS/demo-core.git
git remote add webapp $BARE_REPOS/demo-webapp.git

A ce stade, les habitués de git qui ne sont pas trop endormis doivent crier « KEUOUA ??? ». Effectivement, les démos distants sont normalement des clones du dépôt local. Or nous venons de déclarer trois dépôts distants qui n’ont pas un seul commit en commun.

Ce n’est pas une erreur, et c’est le mode de fonctionnement des subtrees. Contrairement aux submodules pour lesquels on avait trois dépôts locaux, avec les subtree, on a un unique dépôt local : le lien entre cet unique dépôt et les dépôts distants passe donc par les « remotes » du dépôt local.

Des branches locales pour travailler sur les modules

Nous allons maintenant créer des branches locales associées aux branches distantes afin de pouvoir travailler sur nos modules.

1
2
3
4
git fetch core
git fetch webapp
git branch localcore --track core/master
git branch localwebapp --track webapp/master

Il est maintenant possible de travailler sur les modules localcore et localwebapp dans leurs branches locales respectives. Le tracking étant défini, les push seront effectués vers les dépôts respectifs des deux modules.

Et l’arborescence globale de notre projet ?

Depuis notre unique dépôt local, nous avons vu comment travailler séparément sur nos différents modules. Mais à ce stade, nous n’avons pas reconstitué l’arborescence de notre projet Maven. C’est à ce stade qu’interviennent les subtrees.

On rebascule dans la branche master de notre projet, et on exécute :

git read-tree --prefix=core/ -u localcore
git read-tree --prefix=webapp/ -u localwebapp

Après cette étape, on n’oublie pas de commiter l’ensemble et nous avons récupéré l’arborescence globale de notre projet.

Mettre à jour le projet lorsque les modules évoluent

Notre module core a maintenant évolué dans sa branche. Ces modifications ne sont pas automatiquement reportées dans la branche master de notre projet.

Pour récupérer ces mises à jour, il suffit d’utiliser la commande :

1
git merge -s subtree localcore

Cette opération aura pour effet de fusionner dans la branche master les modules (ainsi que leurs historiques respectifs).

On peut juger que ces historiques sont « parasites » à ce niveau : on les a déjà dans la branche du module. On préfèrera dans ce cas la commande :

1
git merge -s subtree --squash --no-commit localcore

Cela aura pour effet d’agréger tous les commits en un seul et de préparer le message de commit (qui concatène les messages de tous les commits agrégés). Il ne reste plus qu’à corriger ce message et à valider le commit.

Submodules ou Subtrees ?

Nous avons donc deux méthodes permettant de traiter la même problématique. Il ne reste plus qu’à en choisir une. Les deux approches ont leurs avantages et leurs inconvénients.

Les subtrees sont plus faciles à manipuler : ils nécessitent moins d’opérations, et il est plus difficile de faire une erreur qu’avec les submodules (oubli d’un push par exemple).

Les submodules sont plus complexes à utiliser, mais plus structurés (il s’agit là d’un avis subjectif de ma part) : chaque dépôt distant est associé à un dépôt local.

Personnellement, ce sont les submodules que je préfère.

Publié dans Systèmes d'information | Marqué avec , , , , , , | Un commentaire

Premier retour sur le ScrumDay

Aujourd’hui, j’étais au Scrum Day, dans le centre de conférences de Microsoft à Issy-les-Moulineaux.

La journée était très agréable, le déjeuner bon et assez copieux, et les conférences intéressantes. J’ai par ailleurs pu faire la connaissance de Guillaume Lours, Antoine Sabot-Durand, et Nathaniel Richand (dont la conférence sur les tests en environnement Java était très intéressante).

Pour appliquer un des grands principes de l’agilité, il faudra uniquement penser à noter quelques points dans la rétrospective de l’évènement (que je n’ai pas été le seul à noter, si j’en crois les retours sur Twitter :

  • il manquait la possibilité  de pouvoir se désaltérer entre les conférences (à l’exception du déjeuner et de la pause café de l’après-midi)
  • certaines salles de conférence, parmi les plus intéressantes étaient dans des salles ridiculement petites. Je pense surtout à la salle Corail, qui était généralement pleine plus d’un quart d’heure avant les conférences… J’ai ainsi manqué les conférences de Bertrand Pinel (sur « l’agilité en mode forfait »), et d’Alex Boutin. J’espère que des comptes-rendus de ces conférences (entre autres) fleurirons prochainement

Continuer la lecture

Publié dans Méthodes | 3 commentaires

Partager un projet Talend Open Studio avec git

Récemment, OCTO a publié deux bons billets sur les implémentations de services REST et sur leur testabilité. Je vais donc laisser ce sujet de côté pour le moment et différer le billet que je comptais écrire sur le sujet.

Depuis déjà pas mal de temps, je m’intéresse aux « forges logicielles », en particulier autour de des technologies Java. Dans ce cadre, j’ai testé plusieurs outils de suivi d’anomalies/évolutions : Mantis, JIRA, Redmine, etc.

D’après ce que j’ai pu voir, de nombreux clients utilisent Mantis pour le suivi des anomalies. Dans la forge mise en place en interne, nous utilisons plutôt Redmine (la suite des produits Altassian est également excellente, mais nécessite d’avoir le budget), en particulier pour son excellente intégration avec git :

  • possibilité de lier des commits aux fiches Redmine
  • pilotage automatique de la résolution et du « time-tracking » des fiches en extrayant automatiquement ces informations des commits git
  • visualisation dans l’interface Redmine des diffs
  • calcul et affichage de statistiques sur le dépôt du projet

Afin de pouvoir utiliser simultanément ces différents produits (Mantis du client et Redmine ou JIRA interne), j’ai pensé créer un projet Open Source permettant de synchroniser les données entre ces différents produits, en utilisant Talend Open Studio. Pour cela, il fallait donc réussir à partager ce projet en utilisant git (afin de le rendre accessible sur GitHub).

Continuer la lecture

Publié dans Talend | Marqué avec , , , | 7 commentaires