Voici mon billet consacré à Devoxx 2010. Les meetings étant aussi riches en contenu qu'en rencontres, je ne parlerai que des faits et sessions qui m'ont le plus marqué.
La keynote
“Welcome to Devoxx 2010” ! Cette phrase longuement attendue par la communauté Java depuis quelques semaines a raisonné comme un go-ahead de soulagement pour les 3000 personnes ayant bravé le climat Belge. Toujours organisée dans l’immense salle 8 du Metropolis d’Anvers, cette keynote divisée en trois parties, nous a appris que Devoxx 2010 a battu son record de visiteurs, qui avoisine les 3000 personnes, qu’il y a un wifi fiable (ce que je confirme), que la plateforme Parleys propose le visionnage du contenu des sessions Devoxx à un prix vraiment intéressant et dans des conditions (variété de clients) agréables. Brèf, une bonne entrée pour Stephan Janssen, l'organisateur de la conférence. A suivie ensuite, l'intervention de Mark Reinhold sur Java SE The Road Ahead. Rien de bien nouveau dans la suite des évènements pour notre langage "favori", je vous encourage donc à lire l'article qui résume les futures fonctionnalités annoncées sur le site de l'openjdk. Néanmoins, un point intéressant à noter est que la langage va devoir de plus en plus se prêter au jeu de la programmation concurrente, grâce notamment aux architectures 128 processeurs. Il va falloir donc trouver d'autre moyens/pratiques de développement pour permettre aux développeurs de coder des applications simplement et c'est là que rentrera en jeu le projet lambda, dont les spécifications (mode raw) sont disponibles dans ce document.Enterprise IT vs. WWW
Stephan Stilkov a encore prouvé qu'il maitrisait sont sujet, c'est à dire REST. Même s'il n'est pas très difficile de mettre en lumière les avantages et inconvénients entre une architrecture SOAP et REST, il a su trouver les mots et les exemples justes pour inciter les gens a passer à la vitesse supérieure, j'ai cité REST. Il a comme à son habitude introduit son propos avec des phrases chocs des grands noms du développement, qui critiquent sans retenus les WS. Le parallèle SOA/WS a fait mouche et le schéma montrait bien que les WS sont plus basés sur une architecture "technique" qu'une architecture logicielle. En effet, REST est avant un style de programmation et de pensée, qui est naturel au développement WEB. Il a donc prêché des convertis mais une piqure de rappel ne fait pas de mal de temps en temps.The Next Big JVM Language
J'ai particulièrement bien aimé cette présentation juste et précise de Stephen Colebourne. Il a dressé un panorama assez clair des différents challengers au langage Java, sans pour autant oublier de rappeler, que la JVM est avant tout une plateforme populaire, neutre, sure et auto-gérée. Ses critères de sélections allaient du but du langage, au facteur humain de d'adoption, de compréhension, aux leçons retenues des ses héritiers... Le premier a être passé sur le gril a été Clojure. Pour l'auteur, bien que Clojure soit pleinement fonctionnel, ait une approche intelligente et dispose d'une STM, il a néanmoins les principaux défauts d'être trop loin de Java et d'avoir une syntaxe a des années lumières de C/Java. Le second langage a avoir été passé en revu a été Groovy. Encore une fois, ce langage ne sera pas le NBJL. En effet, l'auteur lui trouve comme d'autre l'avantage et l'inconvenient d'être dynamique. Je vous laisse deviner pourquoi. En outre, l'auteur pense que ce langage est plus un complément à Java, qu'un remplaçant. Le troisième langage a avoir été décortiqué a été Scala. Ce langage a retenu l'attention de Stephen car il possède la caractéristique d'être aussi OO que fonctionnel, d'être massivement statiquement typé, d'être scallable par sa nature, d'être minimaliste au sens ou tout est librairie et que sa syntaxe est compréhensible des "humains". Le quatrième et dernier langage a avoir été passé en revue a été Phantom. Ce langage a également retenu l'attention du speaker pour les raisons suivantes : statiquement typé mais avec une pointe de dynamique, OO mais avec une pointe de fonctionnel, les variables ne peuvent être nulles, il est immutable, basé sur des modules et sa syntaxe est similaire à Java. Et le constat dans tout cela ? Et bien quand Scala est trop complexe, Fantom est fermé, quand Scala a un système de typage trop excessif, le typage de Phantom n'est pas assez puissant... Bref, pour conclure il semble qu'un bon NBJL est avant tout un langage que l'on maitrise et qui répond à une problématique donnée au bon moment. Et si Java X était le NBJL ?Building JavaFX Applications with Alternative Languages
J'avoue avoir été un peu déçu par cette présentation qui relevait plus du pari qu'autre chose, il faut l'avouer. Bien que Stephen Chin semblait connaître son affaire et que j'ai vu ce que j'attendais, c'est à dire voir du Clojure afficher de l'UI, j'ai trouvé la présentation un peu légère et peu dynamique. Néanmoins, il faut noter que la plupart des gros langages de la JVM actuelle comme JRuby, Clojure, Jython et Phantom peuvent utiliser JavaFX pour leur UI. Les exemples étaient simplistes mais avaient le méritent de fonctionner. J'ai pu noter toutefois que JavaFX Script APIs a été porté en Java et que l'on pourra donc s'affranchir du langage de script, qui a tant déplu aux développeurs, que les performances globales ont été améliorées, le support des animations CSS... En outre, j'ai noté un projet intéressant appelé Visage qui est un DSL permettant de décrire les UI dans JavaFX. A suivre... Comparing JVM Web Frameworks
Ça fait tout drôle de le voir en vrai le Matt Raible. Fidèle à l'image que j'avais du personnage, la présentation a été aussi claire qu'utile. En effet, la recette miracle pour choisir le web framework de demain est simple : tout d'abord établir une pré-liste des candidats potentiels, créer un prototype à l'identique pour chacun d'entre eux, faire une matrice résumant les critères importants, faire une présentation qui résume le tout et permettre de s'approprier les documents, les applications d'exemples et recommandations (conclusions). Vient ensuite l'identification du type d'application cible : l'application à grand trafic et donc scalable, l'application à destination de l'intranet et donc avec peu d'utilisateurs, le produit maison qui doit tenir la route pour 5-10 ans, autre... Dans la foulée, n'oubliez pas d'établir une vingtaine de points de comparaisons comme par exemple : la perception des développeur du framework, la courbe d'apprentissage, les jobs offerts cette techno, la validation la qualité de la documentation... Reste que vous pourrez retrouver tous ces points sur la slide de résumé disponible à l'URL suivante et vous laissez la surprise du grand vainqueur...JVM Web Framework Matrix
Defective Java: Mistakes that matter
William Pugh étant à la fois professeur et ingénieur dans l'industrie, c'est avec la bienveillance du professeur et l'assurance du senior, qui l'a partagé son expérience en terme de qualité logicielle et productivité. Il a pris un malin plaisir a dresser un panorama des erreur les plus ou moins grossières, qui lui a été amené à rencontrer durant ses audits de code. Certaines vérités étant toujours bonnes à dire et à rappeler, voici un petit résumé des choses à faire ou ne pas faire : faites des tests ! Des tests unitaires, de non régressions, d'intégration, qu'importe, tester ! Un code ne peut anticiper une action non prévu, donc essayez de prévoir un maximum de cas, ne pas laisser le doute planer ou la place à l'improvisation. Si vous ne pouvez pas prévoir une erreur, tachez d'avoir les mécanismes de détections et de logging, la runtime est votre amie, car si une erreur inattendue arrive, nous devons le savoir, est-ce que mon code est facile à comprendre, à modifier ? Lancer une runtime est une façon raisonnable de planter gracieusement et s'assurer l'erreur est remontée, avec un peu de travail, nos sont souvent plus clairs et pratiques... Après ces quelques recommandations, William Pugh a enchainé avec un panorama du bestiaire des plus gros fails qu'il a rencontré sur Eclipse et chez Google au travers d'une analyse Findbugs. Ce fût instructif et rassurant de voir que même chez les grands, des erreurs de la sorte peuvent arriver. La réalité dans tout cela, c'est qu'il n'y a pas d'arme magique à l'éradication d'un bug, qu'il faut tester, utiliser des outils d'analyse de code, qu'il faut être pragmatique dans l'écriture de son code, éradiquer le code mort où bien souvent le bug se réfugie... Toute une histoire.Java Puzzlers - Scraping the Bottom of the Barrel
A suivre...
Commentaires