Le voilà enfin,  le nouveau langage web  révolutionnaire, la fin des problèmes de compatibilité entre les navigateurs, la solution à tous nos soucis de développeur web. Bon, ce que je viens d’écrire est peut-être un peu trop optimiste… Certes, HTML 5 a pour objectif de standardiser les technologies du web mais il ne faut pas rêver,  ce ne sera pas, ou plutôt,  cela ne semble pas être la solution miracle.

<Intro>

Si vous ne le savez pas encore, HTML 5, comme le présuppose son nom, est la nouvelle version de HTML après HTML 4.1. Cette évolution de l’HyperText Markup Language se veut être à la fois un regroupement de bonnes pratiques observées depuis plusieurs années sur la toile et dans les entreprises mais aussi un regroupement de nouvelles fonctionnalités qui faisaient défaut. Initiées au départ, par les trois géants du web que sont Apple, Google et Mozilla au sein du Web Hypertext Application Technology Working Group (WHATWG), ces spécifications ont été ensuite reprises par le W3C pour être normalisées.

HTML 5 a aussi pour ambition de simplifier son utilisation qui s’est complexifiée avec le temps. Prenons pour exemple, la déclaration de certaines balises qui a été réduite au strict minimum. La déclaration du doctype devient très simple. La déclaration des scripts JS inline devient implicite.

L’implémentation de nombreux types de validations client comme la validation d’une chaine de caractères (email, code postal, numéro de téléphone…) est facilitée par l’utilisation d’attributs natifs.

La réalisation d’effets graphiques simples tels que, les coins arrondis, les ombres (de texte ou de boite) ou les dégradés de couleur deviennent natifs en CSS 3 (avec malheureusement encore quelques variations entre les différents navigateurs…).

<ASP.NET MVC>

The right way for HTML 5 !

HTML 5 arrive avec son lot de bonnes nouvelles et nous devons, en tant que modestes développeurs ASP.NET, être prêts à l’accueillir. Pour celles et ceux qui n’auraient pas encore mis leur nez dans l’implémentation du pattern MVC en ASP.NET, c’est le moment.

A mon sens, pour faire du HTML 5, il faut oublier les contrôles ASP.NET standards, produisant du code HTML plus que perfectible. Il faut désormais se tourner vers ASP.NET MVC qui permet d’avoir la maitrise totale du code HTML final. Fini les gros Datagrid très pratiques générant un code HTML lourd. Le développeur revient aux fondamentaux du développement web et doit recoder son beau tableau à la main mais avec beaucoup plus d’API qu’avant, simplifiant ainsi son implémentation. Le résultat est un code HTML plus propre, plus léger pour transiter sur les réseaux et facilement maintenable pour les éventuels intégrateurs. Le passage à HTML 5 se fait alors naturellement.

Des frameworks déjà disponibles, fournissent des méthodes évitant aux développeurs de réinventer la roue. Ils permettent notamment de simplifier l’accès aux éléments des pages, la gestion des évènements, la communication avec le serveur…

<Limitations>

HTML 5 en ASP.NET est donc bien possible mais jusqu’où ? Il est aisé de dire « Mon application est en HTML 5 » en ajoutant simplement le doctype qui correspond, mais l’est-elle vraiment ?

Les principaux acteurs du web se sont incontestablement associés pour définir les standards de cette nouvelle mouture mais, malheureusement, ils ne s’accordent toujours pas sur l’ensemble des aspects de la spécification. L’exemple frappant reste celui de la prise en compte des formats vidéo. Chacun voudrait que son standard vidéo soit celui retenu dans la spécification et cela donne un grand n’importe quoi. Pour le moment, pas de réel changement par rapport à la version précédente d’HTML, le format vidéo supporté dépend du navigateur. Pour être cross navigateur, il faudra prévoir une version de la vidéo pour chaque format existant. Quel dommage pour une spécification qui se veut être une standardisation ?!

Certaines implémentations de HTML 5 ne sont pas encore disponibles pour toutes les plateformes. En effet, parmi les évolutions apportées par cette nouvelle version du langage, l’implémentation des flux duplex via les web sockets n’est pas entièrement prise en charge par la plateforme .NET. Si la partie cliente dépend uniquement du navigateur, la partie serveur a aussi un rôle à jouer.  Or, le serveur IIS ne supporte pas encore le protocole web sockets. Pour le moment, seuls quelques serveurs d’application les supportent, tels que Jetty et Node JS (le serveur en Javascript). Il n’est donc pas possible d’utiliser cette évolution avec une plateforme full .NET. Il faudra attendre la plateforme Windows 8 avec IIS 8 et ASP.NET 4.5.

<Applications>

Pour résumer, HTML 5 est déjà là. Plus ou moins terminé, plus ou moins standard entre les navigateurs et les plateformes. Mais attention, si certaines fonctionnalités sont déjà présentes, la spécification n’étant pas finalisée, celles-ci peuvent être modifiées !

Donc, pour savoir dans quels cas il faut se lancer dans l’aventure HTML 5 et dans quels cas il vaut mieux l’éviter, il faut se poser les bonnes questions. Il faut commencer par identifier le type de l’application concernée et les utilisateurs finaux de cette application.

Si l’application est un site grand public, on veillera à bien étudier les nouvelles fonctionnalités que l’on souhaite utiliser sur le site. Cette fonction est-elle implémentée sur tous les navigateurs ? Y a-t-il un risque que l’implémentation change avant la fin de l’élaboration des spécifications ? (Et bien sûr, cette fonctionnalité est-elle bien adaptée à tous les visiteurs ?)

Si l’application est une application intranet, le scope des utilisateurs finaux est plus réduit et le nombre de navigateurs utilisés est souvent limité. On peut donc choisir d’utiliser telles ou telles nouvelles fonctionnalités du langage en ciblant les navigateurs. En entreprise, il est aussi possible de les imposer ce qui réduit encore l’éventail des navigateurs clients.

<Conclusion>

Au final, HTML 5 apporte un réel plus dans l’implémentation des applications web mais il faut prendre garde car les spécifications ne sont pas encore terminées. La version finale est prévue pour cette année mais rien ne dit que cette version sera conforme à ce qui est déjà écrit.  En attendant, tous les grands acteurs du web s’y préparent et Microsoft sera évidemment au rendez-vous.

ASP.NET MVC est la mise en œuvre apportée par Microsoft du design pattern MVC. Un projet Web MVC est caractérisé par le faible couplage entre les pages de rendu HTML, les données et les différentes interactions entre ces deux couches qui va se faire dans le contrôleur.

Cette année une session au Techdays 2012 a été consacrée sur les bonnes pratiques à utiliser dans un projet ASP.NET MVC et sur les pièges à éviter. Cette session a été  animée par Rui Carvalho architecte senior.net Net, Asp.Net, MVC, Sql Server et Julien Corioland formateur et consultant .net qui travaille principalement sur les technologies Silverlight et Silverlight pour Windows Phone mais également sur ASP.NET MVC / Windows Azure.

Durant la sessions, les animateurs ont abordé les points suivants:

• Rappel sur le design pattern MVC
• Bonnes pratiques
• Exemple de structuration/architecture d’un projet MVC

Rappel sur le design pattern MVC

Le modèle MVC est constitué des éléments suivants :

Modèle : représente la couche métier d’une application.

Vue : constitue les éléments d’interface utilisateurs : pages web, contrôles Web…

Contrôleur : permet de piloter l’application, il interprète les actions à réaliser et ordonne leur exécution (lecture, traitement de données et mises à jour).

Ci-dessous un schéma détaillant la relation entre les différentes couches :

Bonnes pratiques

Pourquoi choisir ASP.NET MVC?

Un projet  Web développé avec ASP.NET  MVC  a pour avantage d’être bien structuré en  proposant une architecture qui fait une séparation nette entre la couche du rendu  HTML et celle des données. Une telle architecture permet une meilleure testabilité de l’application et la rend extensible plus facilement. En effet, lors de la création d’une application ASP.NET MVC  un projet de test est généré automatiquement.

ASP.NET MVC met l’accent sur le référencement naturel,  une problématique non négligeable dans le monde du Web. Un site bien référencé par les moteurs de recherche améliore sa visibilité sur la toile et réduit ses coûts publicitaires. ASP.NET MVC, offre par son système de routage un mécanisme pour la génération d’url  décorées.

De plus, Microsoft met  à notre disposition un ensemble d’outils et moyens  pour améliorer la productivité d’un projet MVC notamment avec NuGet ,le scaffolding / Template T4 pour la génération de code et Razor le nouveau moteur de vue.

Bonnes pratiques

Démarrer un projet web ASP.NET MVC est une tâche assez simple néanmoins le démarrer correctement en est une autre.  Durant la session, une liste de recommandation a été fournie lors de la mise en place et développement d’une application web MVC :

• Eviter de laisser la route par défaut au niveau du fichier global.asax et ajouter des contraintes au niveau des routes en utilisant les expressions régulières, des valeurs spécifiques afin de maîtriser les points d’accès  au site web.
• Respecter le design pattern MVC en gardant une séparation nette entre le modèle de données et la vue. Une solution proposée serait de créer un projet à part pour la couche Business et accès aux données.
• Favoriser l’utilisation des vues typées
• Favoriser l’utilisation des « Data Annotation » qui permettront  de gérer d’une façon déclarative un ensemble d’action comme la validation de données, …
• Utiliser la validation des données et créer aussi ses propres validateurs
• Favoriser l’utilisation des filtres qui va permettre le rajout d’une façon déclarative d’une fonctionnalité transverse à l’application comme par exemple l’authentification. Il existe 3 types de filtres : Autorisation Filter, Exception Filter,   Action et Result Filter. A noter qu’il est possible de définir ses propres filtres.
• Créer ses propres « HTML Helpers » pour factoriser le code.

Exemple de structuration/architecture d’un projet MVC

La deuxième partie de la session était consacrée à la présentation d’un exemple sur une architecture  « type » dans un projet. Bien sûr, il ne faut pas appliquer à la lettre ce qui est proposé sachant que la définition de l’architecture d’un projet dépend de plusieurs facteurs lié au projet lui-même. Je citerai ci-dessous les quelques points que j’ai pu noter :

• Privilégier le design pattern SOLID
• Utilisation d’un projet  Bootstrapper pour la gestion de la partie configuration d’une application
• Séparation complète entre le code de l’interface utilisateur  (Vue) et le code fonctionnel en créant deux projets distincts
• Découplage fonctionnel en favorisant l’utilisation des areas

Conclusion

J’ai trouvé cette session intéressante même si la deuxième partie de la session consacrée à l’architecture était relativement courte et pas assez détaillée. Néanmoins, cette session m’a donné une idée globale sur les points à retenir lors du développement d’une application MVC notamment comment profiter des data Annotation pour gérer tous les contrôles transverses sur une fonctionnalité(validation des données , autorisations, authentification…) sans pour autant polluer le code métier.

Avec ASP.NET MVC  nous retrouvons les fondamentaux du développements web. Nos vues sont plus simples et libérées des contrôles serveurs où la logique métier et l’affichage peuvent se mêler. Nous avons ainsi une séparation nette entre la vue, chargée uniquement de l’affichage, le modèle, responsable de la manipulation et traitement de données et le contrôleur, qui gère les interactions entre la vue et le modèle. La question qui reste c’est quand privilégier l’utilisation d’une application ASP.NET MVC à une application .NET WebForm ?

Liens Utiles:

• Exemple structuration/architecture projet à télécharger: SampArch
• NuGet: http://nuget.codeplex.com/

J’ai eu la chance de me rendre à la dernière édition des Techdays,  où j’ai pu découvrir les nouveautés prévues pour la prochaine version de Visual Studio.

Cette session fut animée par deux consultants d’Infinite Square (anciennement Access IT), Etienne Margraff et Florent Santin.

Après un bref historique de la gamme Visual Studio et notamment sur les différents profils de personnes venues enrichir l’équipe de produit (développeurs, chefs de projets, testeurs et utilisateurs désormais) nos deux MVP ont présenté dans un premier temps les nouveautés concernant la partie développement pour ensuite conclure sur les spécificités de la partie ALM (Application Lifecycle Management) et donc de Team Foundation Server 2011.

Visual Studio 2011

Voici une liste non exhaustive de ces nouveautés.

Metro Style Application

• Templates de projet pour Windows 8 pour les applications de types “Metro Style” (XAML & HTML5/JavaScript),
• Intégration du moteur de design de la nouvelle version de Blend pour les applications de types XAML et HTML 5.

Productivité

• Intégration des Productivity Power Tools,
• Amélioration de l’Explorateur de solution avec une barre permettant de lancer une recherche (Classe, Méthode, Propriété, Attribut, etc.),
• Code Clones Analysis: fonctionnalité permettant de retrouver de manière sémantique des portions de codes identiques afin de faciliter le refactoring.

Développement Web

Cette partie a été le plus mis en avant notamment avec l’arrivée d’HTML 5. Ainsi VS 2011 fournit un ensemble de fonctionnalités destinées à faciliter le développement Web comme:

• l’ajout de snippets HTML 5 / CSS 3,
• une meilleure indentation, mise à jour automatique de la balise fermante lors de l’édition de la balise ouvrante, outlining.
• l’explorateur de DOM,
• la console JavaScript,
• l‘amélioration de l’inteliSence JavaScript.

Autres

• Ajout de snippets et des tests unitaires pour le C++,
• Refonte du moteur de tests unitaires, plus performant et multi-Framework,
• Editeur de modules 3D.

Team foundation Server 2011

Ces dernières années, Microsoft a également fait fortement évoluer sa solution ALM avec notamment la version 2010 de Team Foundation Server qui a permis d’imposer un certain nombre de fonctionnalités innovantes. Il continue ainsi sur cette lancée dans cette version 2011.

Nouvelle interface Web

L’interface et l’ergonomie du portail Web ont été totalement revues. Mais ce n’est pas tout car la notion d’équipe a fait son apparition. Désormais, un groupe de personnes travaillant sur un objectif commun peut bénéficier d’un espace permettant de gérer les dates d’indisponibilités des membres, les dates de début et de fin des itérations, son backlog ou encore de visualiser son tableau de tâches sous forme de post-it.

Nouveau Team Explorer

La partie Team Explorer qui n’avait pas beaucoup changé ces derniers temps fait également peau neuve.  La démonstration nous a laissé entrevoir un Team Explorer 2011 plus intuitif avec une interface plus épurée et accessible. Une nouvelle partie fait son apparition “My Work” permettant ainsi au développeur de visualiser directement les Work item le concernant. Une dernière modification est l’ajout d’une interface donnant la possibilité de demander à un autre développeur de revoir, de commenter et de valider une section de codes.

Tests

La partie Tests exploratoire introduite dans la version 2010 avec Test Manager  a aussi été amélioré afin d’être plus performante. Cet aspect a d’ailleurs fait l’objet d’une démonstration assez sympathique avec la mise en évidence des intéractions entre le testeur et le développeur.  Lors de la démonstration, le testeur crée une fiche d’incident suite à l’apparition d’un bug. Cette fiche est après transmise  au développeur avec toutes les informations nécessaires (commentaires, screen shots, context mémoire, intellitrace, ect.)

FeedBack

Avec cette nouvelle version, les utilisateurs sont maintenant intégrés dans la boucle avec Feedback Manager 2011 qui est un Test Manager « light » permettant de gérer les demandes de feedback et les retours des utilisateurs.

Team Foundation Service

Enfin comme vous avez pu le remarquer la tendance en ce moment est au Cloud et TFS n’y coupe pas avec Team Foundation Service qui est une version basic de TFS (gestion de source,  Work items,  Build, mais pas de portail web et de rapports) hébergée dans Azure.

Conclusion

Avec cette nouvelle version Microsoft permet aux développeurs de se munir des outils nécessaires à la création d’applications pour Windows 8. Mais ils ne sont pas arrêtés là en fournissant aussi une amélioration de l’expérience, de la productivité, ainsi qu’une solution complète permettant de gérer tous les aspects du cycle de vie d’une application.

Voici la suite de nos aventures à la Devoxx 2011!

Ça y est, les partenaires ont envahi tout le rez-de-chaussée qui abritait le petit déjeuner gargantuesque du premier jour. Il y aura donc moins à manger… mais à la clé moults goodies, concours et autres t-shirts aux couleurs des sponsors de l’évènement. Et je dois dire que nous sommes revenus chargés de cette journée ! (dont un superbe mug HTML5 du plus bel effet, photo!)

Rangeons nos mugs, nos nouveaux vêtements trop voyant pour être vraiment portés… et entrons dans le vif du sujet :

University : « The Well-Grounded Java Developer – intro to Java 7″.

(lien résumé officiel Devoxx, speakers : Martijn Verburg et Ben Evans)

La session débute sous de bons auspices avec deux speakers motivés mais avec cette impression de parler en mâchant un chewin-gum (un accent bien américain donc). Ça commence par une question à l’assemblée de javaistes, pour savoir lesquels utilisent Java 4, puis 5, puis 6 (de plus en plus de bras se lèvent!)… et enfin 7 – et là tous les bras retombent. En effet, depuis juillet dernier la nouvelle mouture de notre langage préféré est arrivée « dans les bacs », mais elle n’a pas encore été adoptée par la communauté.

Introduction to Java 7

Le premier tiers de la présentation est donc dédié au passage en revue des nouveautés « alléchantes » amenées avec Java7.

Nous avons des nouveautés côté langage, le Project Coin :

• les nouveaux switch acceptant les string,
• les try-with-resources avec fermeture automatique des ressources,
• l’opérateur diamant <> qui allège l’utilisation des generics grâce à la déduction de type,
• le multi-catch permettant d’éviter la duplication de code (et bytecode), ainsi qu’un rethrow plus précis (le compilateur analyse les exceptions possible dans un catch)
• une nouvelle syntaxe pour l’écriture des nombres (séparation des milliers par des « _ »)

On ajoute à cela du côté des librairies :

• NIO.2 : une amélioration de la gestion des entrées/sorties (simplifiée!) avec possibilités de lecture asynchrone
• de nouvelles possibilités de réflexion (plus simple et optimisée) avec notamment la nouvelle instruction invokedynamic, sensée être aussi rapide que l’invocation statique classique en Java (il y aurait une amélioration de performance x10 pour les langages dynamiques tournant dans la JVM!)

et aussi :

• un nouveau look&feel pour Swing (Nimbus)
• JDBC amélioré
• nouvelles classes Helper (nouvelle classe Objects)
• meilleur support d’Unicode, et j’en passe…

Pour conclure ce chapitre, les speakers nous assurent que Java7 va nous aider à faire encore mieux notre métier. Les bonnes pratiques fusèrent durant la présentation, et nos orateurs insistent sur une statistique : une ligne de code couterait 32$ par an de maintenance ! Oui, tout de même!
Quelques morceaux de bravoure également dans cette présentation orientée « méthodologie » avec la mise en avant du côté social du développeur, voyez plutôt :

« Developers who communicate the best are the most influent on their projects. »

Polyglot and functional programming

Dans le monde Java, certaines âmes averties se posent ce genre de questions :

« Pourquoi le langage Java évolue-t-il si lentement ? »
Mais aussi :
« Pourquoi tant de langages de la JVM semblent beaucoup plus avancés que Java ? »

D’après nos deux compères américains, ces langages seraient tout simplement plus spécifiques que Java, souvent dédiés à répondre à des problématiques plus précises. Ils seraient comparables à des fenêtres sur l’avenir de Java. En quelque sorte des laboratoires desquels sortiront des nouveautés matures et non pas des changements par « effets de mode » polluant alors au fur et à mesure le langage.

« There are some features in Scala which everyone now regrets. »

Mais pourtant, parfois des nouveautés sont adoptées pour aider le programmeur, mais trahissent le plus souvent un problème de conception (exemple des nouveaux switch).
Il faut bien faire un peu de social aussi dans le monde de Java !

L’objet de cette partie est donc de nous sensibiliser à l’existence de plus de 200 autres langages fonctionnant dans la JVM :

• les ré-implémentations de langages : JRuby, Jython,
• ceux qui sont désigné comme des « Java-killers » : Fantom, Ceylon, Xtend, Scala
• les dynamiques : Groovy, Rhino, Clojure,
• les académiques : loke,  Steph…

Et on nous donne les clés du choix d’apprentissage d’un nouveau langage (simplicité, intégration avec IDE, employabilité, interopérabilité avec Java, tests…)

Vient ensuite le cas de la programmation fonctionnelle dans une approche centrée sur Java.
« Qu’aurions-nous besoin et que manque-t-il donc à ce sujet dans cette 7ème version de Java ? »
Avec de nombreux exemples à l’appui, on voit qu’effectivement, nous aimerions de temps à autre pouvoir passer des méthodes comme paramètres d’autres méthodes ! Les exemples des design patterns Map et Filter sont tout à fait éloquent (et je me rends alors compte, qu’en Flex/AS3 j’exploite justement beaucoup cette possibilité…)

Par chance nous apprenons que justement, Java 8 va nous apporter cette programmation fonctionnelle… en empruntant la syntaxe à celle de Scala ! La boucle est bouclée.

Modern Java Concurrency

Je dois avouer que le dernier chapitre sur la concurrence était quelque peu barbant pour terminer la matinée !

On nous a servi une fois de plus le discours sur la puissance des processeurs qui plafonne, sur la loi de Moore, et sur la nécessité qu’ont eu les fondeurs de puces de passer à du multicore… Le problème que cela pose donc : pour tirer profit de ce dernier retranchement devant la fin de l’amélioration de la puissance de nos machine, il faut que nos logiciels apprennent à gérer la concurrence.

Et le problème glisse donc tranquillement sur nos petites épaules de développeurs : NOUS allons devoir apprendre à gérer la concurrence !

Je ne détaillerai pas davantage la présentation qui fut une successions de nombreux exemples pratiques, pour s’achever sur la présentation de la nouvelle API Fork/Join de Java7 pour optimiser les calculs en tirant profit des machines multi-cœurs.

University : « The Groovy Ecosystem ».

(lien résumé officiel Devoxx, speakers :Andres Almiray)

Le speaker nous propose un tour d’horizon des projets Groovy les plus connus, et s’attarde notamment sur Grails, Griffon et Gradle.

Grails, le framework de développement rapide d’application Web basé sur Groovy.

Après les éloges de son très bon support par les IDE « communs » (comprenez Eclipse, Netbeans et IntellJ IDEA), nous avons droit au couplet sur sa facilité de mise en œuvre, son extensibilité avec plus de 600 plugins, etc…

Vient ensuite la partie croustillante de l’université : la démonstration !

Il s’agit donc, sans grande surprise, de la fabrication de toutes pièces d’une petite application CRUD. En quelque lignes de commande, on crée l’application, le modèle, les contrôleurs, les contraintes de validations pour les champs de notre interface, le multilinguisme avec la traduction française toute faite, etc… et tout cela codé en Groovy.

Le code est très succinct, car tout fonctionne sur base de templates, qu’on surchargera pour changer les comportements par défaut. Il est d’ailleurs aussi possible d’afficher le code final généré et de le modifier à loisir.

Griffon, le « penchant application lourde » de Grails.

On passe ensuite sur la rapide présentation de Griffon, et surtout la démonstration qui nous intéresse.

Une commande pour créer une structure d’application Swing, avec des modèles, contrôleurs et vues à adapter à nos besoins. Il semble que le langage soit particulièrement adapté à l’écriture d’interfaces Swing par sa clarté et sa puissance.

Gradle, un outil de build de nouvelle génération écrit en Groovy.

On nous le présente comme l’alternative attendue à Ant et Maven. A la fois puissant, puisque ses scripts sont écrits en Groovy, ce qui lui permet de profiter de ses nombreuses APIs. Il est aussi compatible avec ses concurrents, et peut par exemple utiliser les repositories et artefacts maven, tout en s’intégrant parait-il facilement dans les usines logicielles déjà en place.

Le produit est jeune cependant, et même si on nous promet que « l’essayer c’est l’adopter », cela fait un système de build de plus à apprendre à maitriser…
L’avenir nous dira si son adoption est réussie. A tester !

D’autres projets :

L’université se termine sur un passage en revue de différents autres projets de l’écosystème Groovy :

• Gaelyk (pour le déploiement de nos applications Groovy dans le cloud)
• Gant (pour faire de l’Ant en Groovy… sans xml!)
• EasyB (pour faire de la BDD dans nos projets java)
• Spock Framework (pour faire des tests unitaires et fonctionnels de manière plus intuitive et efficace)
• Gpars (pour la concurrence)
• Codenarc…

Et voilà que s’achève une session à la fois intéressante et dense en informations, animée par un très bon speaker!

Tools in action : « Pimp your ALM, with task-based development ».

(lien résumé officiel Devoxx, speakers : Michael Hüttermann)

Nous avons droit à une présentation des différents outils de travail d’un développeur sur un projet agile « orienté taches ».

On fait une passe rapide sur l’IDE Eclipse et le plugin Mylyn permettant de visualiser les taches créées par le métier/la recette, et sur la manière dont les commits référencent les tickets.
Ensuite on se tourne vers l’intégration continue de l’outil Jenkins et son fonctionnement avec :

• Jira (aidé du plugin Greenhopper) pour visualiser les tickets,
• Fisheye pour afficher les différentes versions de code et les deltas par révision,
• Artifactory comme repository de nos constructions,
• et enfin Sonar pour visualiser les métriques concernant la qualité de notre code…

En conclusion, pas une seule nouveauté croustillante ni aucune information récoltée pour un développeur sous Eclipse avec un minimum d’expérience.

Tel un « pitch » pour son livre – dans lequel, j’espère, il aura plus de choses à dire – notre speaker s’efforça de survoler d’un peu trop haut, le sujet. En insistant évidemment sur son l’excellence de son livre au passage. Le moins que l’on puisse dire, c’est qu’il avait vraiment envie de le vendre, son livre. J’ajouterais que la présentation était très courte, encore plus que le format prévu, pourtant de 30 minutes. Et finalement c’était peut être un moindre mal vu l’ennui engendré par ce « Tools in Action ».

Tools in action : « Jenkins: From Continuous Integration to Continuous Delivery ».

(lien résumé officiel Devoxx, speakers : John Smart)

Cette session aborde le problème du branching multiple de projet, et des problèmes du cycle de vie des branches tout au long d’un projet.

On commence par nous montrer les possibilité de Jenkins, notamment son intégration avec CloudBees pour le déploiement dans le cloud en cas de succès des constructions. Encore une fois Git est à l’honneur, avec sa simplicité d’utilisation et le merge de branches.
Idéalement dans le processus de livraison, nous devrions à un moment donné choisir les fonctionnalités (comprendre « branches » à pousser sur le « trunk ») pour confectionner le livrable.

Grâce à l’option de merge avant build de Jenkins, on peut construire la branche en validant son bon fonctionnement sur le trunk, avant de valider le build et s’assurer ainsi que notre branche est fiable avant de la pousser dans la livraison.

« Continuous Delivery is impossible without Continuous Quality ».

L’idée est de s’assurer constamment de la qualité de l’intégration à l’aide de Smoke Tests (on nous fait une démonstration avec thucydides dont je n’avais jamais entendu parler).

Jenkins, parmi sa panoplie d’outils, nous offre une vue synthétique de nos derniers builds, la Build Pipeline. Nous voyons immédiatement, par exemple, si un smoke test n’a pas fonctionné, stoppant ainsi le workflow de livraison. Nous avons aussi la possibilité de lancer des builds à partir de cette vue, pour par exemple pousser en production une (précédente) version spécifique.

Session de fin des 2 University Days : « The Fireside chat ».

(Intervenants : Tim Bray, Cameron Purdy, Mark Reinhold et Henrik Ståhl)

Pour conclure ces 2 premiers jours à la Devoxx 2011, une discussion est amorcée entre 4 personnes influentes du monde Java autour d’une table (mise en situation : imaginez un bar) et qui échangent sur divers sujets d’actualité.

A n’en pas douter, le discours n’est pas préparé, ça commence d’ailleurs plutôt mollement (discussion au sujet de la bouteille de vin posé à leur table…). Le dialogue se met en place doucement et ils parleront durant près d’une heure avant que le « médiateur » ne les arrête.

Et de quoi ont-ils parlé ? De Java tout d’abord, l’évolution du langage et des langages de la JVM.
De l’avenir d’HTML5 dans le web actuel.
Des smartphones et plus spécifiquement des nouvelles tendances et besoins amenés avec l’invention des iPhones et iPads.
De l’imprévisibilité de ces succès technologiques.
De nos habitudes en tant qu’utilisateurs de nouvelles technologies.
Finalement ils reparleront du web en général, et ils ne pourront s’empêcher de revenir à nouveau sur le sujet des smartphones.

Bonne ambiance et applaudissements vigoureux garantis !

Voilà donc terminées nos deux intenses journées, et je retiendrai la blague de Mark Reinhold :

« What’s the difference between Maven and Ant ? The creator of Ant has apologized ! »

Il n’a peut être pas encore testé Gradle !

Voilà, ce millésime 2011 de la Devoxx c’est vraiment fini, et cette année la JOP y était ! Nul doute que l’année prochaine, d’autres ambassadeurs de Novédia auront tout intérêt à y retourner!