Blog Objet Direct

Whooosh … ça décoiffe, au sortir de cette conférence j’ai l’impression d’être dans une de ces boules à neige (qui colle bien avec l’image qu’on se fait du Danemark qui plus est ) : on vient de secouer plein de choses et il faut maintenant attendre que les flocons se posent. Dans ma tête… et surtout sur le marché : qui travaille avec Git chez son client ?
En effet la conférence (Java And Object Oriented) qui s’annonçait de développeur à développeur n’a pas (plus autant ?) les pieds sur terre, d’où son changement de nom en gotocon (je n’ai toujours pas compris ce nouveau nom d’ailleurs… faire fuir les développeurs ?), plus particulièrement au vu du contenu du premier jour de conférence où Java était… absent !

Par contre, sur le côté novateur (pour notre réalité bien sûr, pas pour Google, Twitter et cie)  de cette conférence, petite soeur du QCon, est très intéressant. On y retrouve tous les sujets les plus récents que l’on peut suivre sur twitter et la blogosphère. On change ici totalement de monde : on est dans l’univers des leaders de pensée, déconnectés de notre réalité quotidienne. Les sujets majeurs tournent autour des grands du web dont on peut/doit prendre des idées mais qui resteront difficilement vendables à court terme dans notre réalité.
Un point très appréciable néanmoins: malgré cette volonté de ne montrer que des sujets de pointe, on a quasi systématiquement un rappel assez complet de l’historique du sujet.

Pour ma part, le message que je retiendrai de cette conférence (que ce soit pour les sessions que j’ai pu suivre ou non) c’est que ces gens, en avance (où sommes nous en retard ?) sur leur temps se battent contre 2 mastodontes qui a leur sens entravent la productivité :

• Les méthodologies lourdes dont certaines applications de Scrum notamment quand la méthode est mal utilisée voire incomprise (le backlog semble être dans la ligne de mire des prochaines évolutions de l’agilité)

• Java qui n’a pas (réellement) évolué depuis 6 ans et qui peine à évoluer (cf. le plan « B »)

Des retours plus précis suivront ce billet d’introduction … à bientôt !

J’ai assisté ces derniers jours à la conférence Agile France 2010, 5ème édition de ce qui s’appelait « XP days » ces dernières années. Je vous livre ici mon ressenti sur ces deux jours de conférence que je considère comme un retour sur la situation de l’agilité en 2009. Pour situer un peu le contexte, j’y ai assisté en tant que Scrum Master/Développeur mais aussi dans une perspective future de coaching/accompagnement vers l’agilité.

La première chose marquante pour moi : sur plus de 60 présentations … à priori une seule a pour sujet principal Scrum et elle est annotée ‘Débutant’ ! Je me pose donc la question du pourquoi : est-ce que Scrum est déjà en cours d’abandon (les problèmes de certification lui ont certes causé du tort mais tout de même !) ? Devenu trop ‘mainstream’ pour qu’on ait encore des choses à dire dessus ? … Si vous avez des éléments de réponse, je suis preneur !

De même, les sessions sur la « vente » de l’agilité ont été plutôt rares (2 seulement) : l’agilité rentre dans les mœurs et il est devenu moins nécessaire de convaincre ?

En revanche le Lean s’est taillé la part du lion dans la catégorie ‘les bases des méthodologies’ pour une petite dizaine de présentations, associé à la bonne dizaine de sessions sur la transition de l’organisation vers l’agilité. C’est, il me semble, un point important à retenir : l’agilité commence à dépasser le cadre de l’équipe de développement pour s’installer dans les DSI en premier lieu et s’immisce doucement vers l’organisation de l’entreprise toute entière. Cela se fait principalement sur le constat suivant : les développements deviennent performants avec Scrum mais l’entreprise n’arrive pas à digérer cette performance, le lead time global peut difficilement changer si l’organisation n’est pas adaptée.

XP aussi est beaucoup ressorti, j’interpréterais cela de différentes façons : en premier lieu, la conférence s’est appelée XP Days pendant 4 ans, même si elle n’était pas exclusivement destinée à XP. Et puis c’est tout de même sur ces pratiques (plus que sur toute autre méthodologie … tiens, un élément de réponse :-) ) que les principes de l’agilité dans le monde du développement logiciel DOIVENT se reposer. L’accent a été mis sur les tests automatisés (10% des sessions) avec notamment le TDD qui commence à percer tout doucement. Et bien que ces pratiques soient globalement comprises elles restent toujours très peu mises en place.

Le dernier point que j’ai pu ressentir, certainement le plus important (pour moi étant donné mon profil mais aussi pour la réussite sur le long terme de projets de développement), c’est l’accent mis sur l’équipe, ses interactions et l’amélioration de la communication, le tout à la limite du développement personnel. Mais aussi un retour qui émerge : l’agilité à plein régime c’est exténuant et tout le monde ne supporte pas la transparence et le courage requis ! Le tout couronné d’une keynote d’Esther Derby sur l’alchimie équipe/management où comment se faire confiance réciproquement.

Ce fut une expérience instructive qui m’a permis de prendre un peu de recul et d’entrevoir de nombreux pans de l’agilité, et tout cela dans un environnement propice aux échanges dans un coin de verdure en bordure du bois de Vincennes. Un grand merci aux organisateurs !

Un article qui décrit le programme ‘Hello World’ sur 8 pages ça vous intéresse ?

Effectivement, présenté comme ça, ça rebute ! J’ai pensé abandonner la lecture à l’introduction qui décrit la palpitante vie d’HW (il est décliné dans 199 langages ici). Mais passé la première page, l’auteur utilise cet unique axe pour décrire de façon plutôt convaincante les fonctionnalités de base apportées par Groovy : gestion des variables, boucles, closures…

Si vous ne connaissez pas encore ce langage, voici donc une lecture rapide pour débuter.

Bonne lecture !

Tout d’abord, les différentes annonces qui ont eu lieu durant la soirée hier :

• Alexandre Bertails nous présente rapidement son nouveau job au W3C ainsi que le fonctionnement de l’organisme avec un rapide retour sur ce qu’est le web et l’importance du consortium.

• Developpez.com est un JUG … qui n’envoie pas de représentant, ils font donc profiter de leur place à Jazoon’10 à un volontaire qui a été tiré au sort.

• Une boutade dans la semaine, deux offres d’emplois supplémentaires sur son site d’ « Offres d’emplois pour passionnés », et Nicolas Martignole se voit en « obligation » d’offrir le buffet. Merci à lui !
• L’ISEP prête la salle de 200 personnes gratuitement, Antonio les remercie et demande des volontaires afin de pouvoir leur rendre service en retour en proposant des cours à leurs étudiants.

Entrons dans le vif du sujet ! La première partie de soirée est orientée « Share » avec un retour d’expérience sur le passage d’un CVCS (Gestionnaire de sources centralisé) à un DVCS (Gestionnaire de sources distribué) suivi d’une présentation du DVCS qui monte : Git. La seconde partie de soirée nous fourni une présentation de Maven 3 et de Deploy It.

DVCS

La présentation du sujet a été faite par Sébastien Douche qui nous fait donc ici un retour d’expérience sur un ton décalé et des slides épurées … très agréable.

Arrivé il y a 2 ans dans son entreprise actuelle, il fait le constat de la (classique) sous utilisation de SVN et après analyse du problème, migre vers un DVCS. Son crédo : les tests automatisés et l’outil de versionning sont les 2 filets de sécurité indispensables à un développement logiciel.

Le problème :

Après avoir tenté une évangélisation des bonnes pratiques SVN, il constate tout de même une dégradation régulière de la qualité, impliquant une démotivation (il parle de souffrance) des développeurs allant se poser la question ultime : a-t-on fait le boulot qui nous a été demandé ?

Le problème ne se situe pas au niveau du travail effectué… mais vient plutôt du fait qu’il n’est pas bien partagé ! Notamment avec un phénomène de « micro-merge » : pour exagérer, les développeurs font des commit de chaque ligne de code modifiée pour éviter d’avoir un trop gros merge à faire par la suite ! Ce qui implique une version constamment instable sur le serveur d’intégration et des difficultés à savoir où l’on en est dans le projet.

Une première solution pointe le bout de son nez : si on faisait des branches SVN ? Hum … Attendez, je crois qu’on tente de nous expliquer comment éviter ça :-)

L’impact du DVCS :

En règle générale, les outils de versionning centralisés sont utilisés principalement pour faire du suivi d’historique … et non leur boulot. On souhaite donc : un environnement constamment stable afin de connaitre l’état du projet tout le temps !

Pour cela, on va isoler le travail des développeurs en repensant notre façon de travailler, via une analyse des besoins réels, 3 workflows sont identifiés :

• La méthode de l’organisation (donc la gestion du repository central), avec une façon de faire par organisation. En général, le workflow le plus connu puisque c’est celui qui est visé par SVN et consorts. L’idée ici, c’est que la méthode de l’organisation ne soit pas impactée par les deux workflows suivants. Le but à atteindre serait, par exemple, d’avoir un seul commit par fonctionnalité.
• Puis le workflow inter-personnel, nouveau donc, qui doit être mis en place justement pour éviter d’impacter le repository central : nouveau dépôt de développement, dépôt temporaire, échange de patchs (très utilisé dans le monde de l’open source), branche spécifique, … Il permet aux développeurs de travailler entre eux.
• Et finalement le workflow personnel, ici aussi à bien séparer des deux autres et chacun pourra travailler à sa façon.

L’important, donc, est que ces workflows soient déconnectés les uns des autres.

Une fois la mise en place effectuée, le constat est le suivant : le développeur est concentré sur SON travail et non sur celui du voisin par peur des impacts qu’il pourrait-y avoir sur le sien. Avec cette fois un commit par fonctionnalité sur le repository central, plus de souplesse avec notamment la possibilité de faire de la revue de code et/ou une démonstration pour une et une seule fonctionnalité !

Il est à noter que ces nouveaux outils sont orientés contenu et non changement. Je pense que tout le monde s’accorde pour dire que SVN ne sais pas gérer le renommage de fichiers par exemple ! On voit donc disparaitre les dossiers ‘.svn’ et l’on gagne énormément en place et en vitesse.

En bonus, des repository sont accessibles en ligne. Un outil de binding permet une transition douce en intercalant le DVCS entre le développeur et son SVN.

Conclusion

Je crois que sa conclusion était plutôt claire :

Libérez-vous : utilisez un DVCS

Git, la gestion de configuration qui vous veut du bien

Présentée par David Gageot, très proche et complémentaire de la session précédente. On part sur le même ton puisque qu’il commence par reprendre la conclusion de Sébastien Il insiste notamment sur le fait qu’un outil est fait pour ouvrir des possibilités … et non en fermer !

Git est donc un DVCS, le plus connu avec Mercurial. Pour faire court :

• Pas besoin de serveur !
• Chaque utilisateur a tout l’historique en détail
• Fonctionne en déconnecté

Mais pour l’utiliser à pleine puissance, il faut oublier comment SVN fonctionne !!!

En général, on ne fait pas de merge avec ce type d’outils.

Démo

Il nous fait ensuite une démo rapide d’une fonctionnalité majeure : bisect.

L’idée est de retrouver quel commit a cassé le build. Avez-vous déjà tenté le coup avec SVN ?

L’idée ici est de donner à cette commande un commit qui ne cassait pas le build ou les tests, celui qui ne fonctionne plus et le test à effectuer (manuel ou automatique). Et par dichotomie, elle va retrouver la version qui a cassé le build.

On peut pousser plus loin :de ce fait, il est possible de jouer un nouveau cas de test (qui devrait passer mais ne passe finalement pas), sur des anciens commit !

Et si on jetait les serveurs d’intégration continue ?

En effet, il est tout a fait envisageable (d’autant plus que c’est ce que David a mis en place dans son entreprise) d’écrire un script qui fait un « private build » avant de faire le commit réel seulement si ce build réussi. Cela est rendu possible par les performances de Git et il est tout à fait possible de travailler en même temps que ce script fonctionne.

Conclusion

Il y a énormément de nouveauté dans Git qu’il n’est pas possible de présenter dans le cadre du Paris JUG. Il nous conseille donc le livre Pro Git.

Il répète Sébastien en confirmant qu’il est possible de passer à Git en une commande : Git va importer le contenu du SVN et agir comme passerelle bidirectionnelle.

Maven 3

2 commiters Maven, Nicolas De Loof et Arnaud Héritier nous présentent Maven 3. La présentation est dynamique mais je reste sur ma faim quand aux nouveautés du produit : elles sont quasiment inexistantes … pour l’instant.

Le contenu :

En effet, le gros sujet, de cette version était une remise à plat des bases avec une refonte du produit (Passage à Java 5) et l’écriture d’une batterie de tests à priori impressionnante. L’écriture de plugins en revanche devrait être simplifiée grâce aux nouvelles API.

Un build plan est mis en place : les plugins pourront savoir ce qu’il s’est passé auparavant dans le buid et donc travailler en conséquence. Notamment le plugin Eclipse pourra laisser Eclipse faire sont boulot (compilation incrémentale) et en tirer bénéfice.

Les pom pourront être écrits dans d’autres langages (groovy, python, …) et les profils ont été revus.

Le résultat :

Une version 100% compatible avec les pom existants via un simple changement de MAVEN_HOME. Les impacts possibles se situent au niveau du plugin site qui n’est pas ou pas bien supporté et éventuellement dans les descripteurs de projet qui sont plus contrôlés.

Le gain que l’on peut avoir aujourd’hui en migrant se situe principalement sur les performances et de meilleurs logs.

Le futur :

• Ajout de la possibilité d’injecter de la configuration dans le pom (mix-in) afin de dépasser les limitations de l’héritage simple.
• Exclusions globales rendues possibles.
• Build parallèle sur multi-coeur
• Ajout d’une console (Maven Shell)

Conclusion :

Il y a peu de risques de régressions, et le passage de Maven 2 à Maven 3 devrait faire gagner du temps. Pour les développeurs Maven et/ou de plugins, le coût d’entrée est maintenant beaucoup plus bas étant donné la refonte. De ce fait la communauté revit et le produit se professionnalise.

Deploy It

La soirée se finit avec la présentation d’un outil d’automatisation des déploiements Java, réalisé par la société XebiaLabs. La présentation de l’outil est faite par Guillaume Bodet et Benoit Maussaud.

Le produit ne se contente pas d’une simple copie de WAR/EAR mais gère aussi :

• Binaire
• Ressources (datasource, securité, …)
• Fichiers de conf
• Base de données
• Réécriture apache
• Fichiers statiques (HTML, images, …)
• Batchs
• …

Je dois avouer que je me suis arrêté là dans la présentation, l’outil n’étant pas open source et ayant l’air plutôt complexe pour une problématique ne me concernant pas …

Ce billet présente mon retour sur la demi journée de séminaire que j’ai pu suivre mardi chez nos confrères de Valtech Training animé par Olivier Penhoat.

Le marché du smartphone.

Android arrive sur un marché difficile étant donné la place prépondérante des OS historiques. Là où l’iPhone a percé avec insolence, révolutionnant les standards, Android peine à démarrer.

Dans un premier temps, n’oublions pas que l’on parle de deux sujets différents : d’un côté il y a toute une stratégie marketing avec un OS destiné à un objet unique, et de l’autre un OS disponible sur de multiples plateformes intégrant chacune des périphériques différents qu’il faut pouvoir orchestrer de façon identique.

De plus, cet OS n’est pas destiné spécifiquement aux smartphones comme on aurait tendance à le penser en premier lieu mais à une multitude d’appareils mobiles (tablettes, GPS, ordinateur de bord automobile, …).

Contrairement à ce que l’on peut penser à première vue, il semblerait que le marché à venir concerne ces divers appareils encore plus que les smartphones !

Google nous propose donc ici un système qui se veut ouvert :

• Applications (internes et tierces) toutes logées à la même enseigne (accès à toutes les ressources)
• Personnalisation poussée du bureau
• Applications modérées à postériori
• Pas d’IDE/OS imposé pour les développements
• Développement sur des standards du marché (Java/XML)

Comment cela se présente-t-il ?

Le système

L’architecture est basée sur un noyau Linux récent, agrémenté des divers drivers fournis par les constructeurs. Ensuite il y a une couche de libraires dont le « runtime Android » contenant une VM optimisée (Dalvik), puis une couche identifiée comme le SDK Android permettant un accès via le langage Java aux développeurs.

Attention néanmoins, la VM Dalvik est assez spécifique :

• Bytecode propriétaire
• Fonctionne sur un registre et non une pile pour optimiser la mémoire.
• Une instance de VM par processus.

L’outillage

Il est plutôt complet, on note entre autres :

• Android Debug Bridge : envoi de commandes sur l’appareil (ou son émulation).
• Un émulateur (permettant de simuler les différentes versions, matériels) avec déploiement à chaud.
• Dalvik Debug Monitor Service : affiche notamment les logs de la VM.
• Android Development Tools : plugin pour IDE au choix permettant de gérer une structure de projet Android et de mettre en place les IHM visuellement.

Composition d’une application

Le fichier manifest

Il sert de contrat pour l’application. Toutes les ressources que l’application va utiliser doivent y être déclarées : géolocalisation précise ou non, accéléromètre, appels, …

Une orchestration via des « intentions »

Les intentions sont très similaire à REST, il s’agit d’une ressource identifiée par son URI liée à une action simple (MAIN retourne à l’accueil, PICK sélectionne la ressource, EDIT …).

4 composants proposés comme cadre :

• Les activités : le cœur de l’application, en général une activité est fortement liée à un écran.
• Les fournisseurs de contenu : le nom est plutôt explicite, il va géré les accès aux différents contenus pour  donner un accès simplifié à l’application.
• Les services : ce sont les processus lancés en tâche de fond, tournant même quand l’application n’a plus la main.
• Les récepteurs d’intention : prennent en compte des évènements extérieurs (appel entrant).

Limites

La fragmentation

La première limitation vient de l’objectif même d’Android : la multiplication des appareils sur lesquels il est amené à fonctionner et donc des configurations différentes à gérer par le développeur, notamment les tailles d’écran, présence d’accéléromètre, …

On appelle cela la fragmentation et elle se multiplie encore avec les différentes versions d’Android proposées par les constructeurs : v1.5 : 30%, v1.6 : 54%, v2.0.1 : 15% …

Il faudra donc composer avec toutes ces configurations !

Android Market

La place de marché pour les applications Android, mis en place par Google souffre de nombreuses lacunes mettant un frein à son développement :

• Mauvaise gestion des commentaires
• Achat uniquement via le système de paiement Google (Checkout)

Conclusion

Olivier nous a fait une démonstration rapide et efficace de la mise en place d’une application Android. Le résultat est flagrant, il parvient très rapidement à afficher une carte Google Maps avec notre dernière position géographique donnée par le GPS …

Pendant la session, il nous a confirmé plusieurs fois que le développement était très simple malgré la fragmentation, qui est plutôt bien gérée par le SDK, pour faire des choses simples. Le pendant de ce système ouvert reste sa complexité quant on veut faire des choses qui sortent du cadre.

De plus, il ne faut pas oublier que l’on déploie une application sur un mobile et non un serveur d’application ! Il faudra donc, même si l’on travaille en Java, repenser notre façon de développer afin d’optimiser certaines structures de code.

Tout d’abord, une bonne adresse à noter : si vous ratez les rendez-vous du JUG Parisien, vous pouvez désormais les rejouer à cette adresse http://beta.parleys.com/#st=4&id=56644.

JSF 2.0

La présentation JSF2 faite par Damien Gouyette et François Petitit a détaillé, non pas uniquement les nouveautés JSF2, mais une présentation complète du framework en marquant les nouveautés 2.0.

La présentation est intéressante même pour un débutant JSF. Je ne détaillerai ici que les nouveautés de la mouture 2009 du framework d’IHM de la spec JEE.

On note que JSF2 est bien entendu, complètement inclus dans JEE6 (dont Antonio Goncalves rappelle qu’il fera une présentation au Paris JUG de décembre) et est compatible JEE5.

Voici donc les nouveautés :

• Une déclaration des managed beans de la sorte :

@ManagedBean

@SessionScoped

public class MonBean {

…

}

La convention dit que ce bean sera accessible dans la vue par son nom de classe ; première lettre en minuscule : ‘monBean’

• Validation des vues via les annotations Hibernate Validator (ce qui permet une vérification centralisée des contraintes)
• Un nouveau scope, le ‘view scope’ ayant une durée de vie égale à la durée de vie de la vue. Scope qui s’intercale donc entre request et session
• Un des principaux apports de cette nouvelle version est le support natif d’AJAX. On ajoute le support Ajax à un composant JSF en insérant le tag <f:ajax>

<h:inputText ….>

<f:ajax render= »autreChamp » />

</h:inputText>

• Les Jsp sont abandonnées (mais restent compatibles) au profit des Facelets XHTML. Les Facelets apportent notamment le concept de « templating », permettant de réutiliser aisément des sections de la vue.
• EZComp permet de créer facilement des composants uniquement via les Facelets (plus de Java nécessaire pour des composants simples) en leur déclarant une interface puis un contenu créé de façon similaire à celui des vues qui sont, elles aussi, des Facelets.

Un exemple des plus classiques : ici on a créé un composant qui prend un attribut ‘value’ :

<!DOCTYPE html PUBLIC « -//W3C//DTD XHTML 1.0 Transitional//EN »

« http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd »>

<html xmlns=« http://www.w3.org/1999/xhtml »

xmlns:h=« http://java.sun.com/jsf/html »

xmlns:ezcomp=« http://java.sun.com/jsf/composite »>

<body>

<ezcomp:interface>

<ezcomp:attribute name=« value » required=« true »/>

</ezcomp:interface>

<ezcomp:implementation>

<!– Les mots clés cc.attrs sont réservés par JSF2 pour accéder aux attributs/paramètres passés au composant –>

<h:outputText value=« Hello #{cc.attrs.value} » />

</ezcomp:implementation>

</body>
</html>

Ce composant est déclaré dans ‘WEB-INF/resources/’ puis utilisé tout simplement :

<ez:mycomp value= »world » />

Je vous laisse deviner le résultat …

• Un autre apport non négligeable est la gestion de profils d’environnement : « prod », « testUnit » …
• La gestion des ressources statiques est améliorée : on n’a plus besoin de gérer ces ressources dans le WEB-INF de son projet. Elles peuvent être apportées par un jar.

On note donc une évolution de la spec, reprenant de bonnes idées. On retrouve notamment de nombreux concepts apparus dans des frameworks et librairies JEE comme Seam ou ajax4jsf.

Servlet 3.0

Mon retour sera beaucoup plus rapide sur ce sujet qui nous touche quotidiennement … mais de loin puisque les frameworks que nous utilisons nous font travailler à un plus haut niveau.

La présentation de l’API par Rémy Maucherat concernait donc plus particulièrement les personnes développant ces frameworks. Néanmoins un tour d’horizon permet d’apercevoir quelques impacts sur notre façon de travailler avec ces frameworks :

• Actuellement, lors de l’ajout d’un framework il est nécessaire de configurer le fameux fichier web.xml afin de notifier le conteneur de servlet de la présence de ce framework.Cela sera remplacé par des web-fragments vivant à l’intérieur des jars des frameworks et donc intégrés au web.xml par le conteneur à l’initialisation.
• Le deuxième point marquant est la gestion de l’exécution asynchrone des Servlets. Actuellement on réserve un processus pour traiter une requête et la gestion asynchrone devait être gérée par ailleurs.
  Servlet 3.0 permet de rendre un traitement asynchrone et donc de libérer des ressources tout en ayant des requêtes longues. En travaillant sur ce point les frameworks devraient gagner en performance.

Fortement lié au contenu de ce post, un post précédent traitait des nouveautés JEE6.