JavaCampParis7

Encore une réussite ce JavaCampParis7 organisé par @LucBizeul, @PhilippeAntoine et Google FR. Nous nous sommes une fois de plus retrouvés dans les locaux de Google à Opéra entre une bonne cinquantaine de dévers de tout poil pour parler de pas mal de choses, mais finalement peu de Java. Journée difficile oblige, je n'ai pu participer qu'à une seule session : FP / Scala...

Comme à l'accoutumé, j'ai croisé mes anciens camarades de Vidal Software où l'utilisation de la programmation fonctionnelle dans des projets sérieux n'est pas une légende. En effet, @ugobourdon, @a_thieriot et @tonyskn nous ont fait part de leur retour d'expérience sur l'utilisation de Scala comme outil de développement du gestionnaire de mise à jour pour l'un de leur produit. Après une courte introduction sur les raisons expliquant en quoi Scala avait sa place chez Vidal, nous avons débattu sur les façons/raisons d'intégrer cette technologie en entreprise. En effet, nous constatons que bien souvent, les organisations ne perçoivent pas l'intérêt d'utiliser un nouveau langage de programmation et ont l'impression de subir un caprice de développeur.

Loin s'en faut, je pense que la mission d'un développeur est d'une part d'assurer sa veille technologique, mais aussi de corréler/axer cette veille technologique, suivant les besoins business de son entreprise : chose que certain d'entre nous ont trop tendance à occulter, j'ai l'impression.

Bref, j'arrête de digresser pour revenir au débat principalement animé par les gens de Vidal et Zenexity, où j'ai retenu deux informations intéressantes. La première par Ugo qui expliquait que l'utilisation des listes en Scala était un pur bonheur et que via cette API, il avait pu faire ses premières lignes de codes réellement fonctionnelle. La seconde par @mrspeaker qui m'a tendu un livre à lire pour vraiment se mettre à le programmation fonctionnelle, il s'agit de The Haskell School of Expression: Learning Functional Programming Through Multimedia Il m'a assuré que c'est un pro de programmation fonctionnelle qui lui a conseillé... et comme je vois de qui il parle, je ne peux que le croire :)

En résumé, encore une soirée passée auprès de gens bien capables, qui mettent les mains dans le cambouis, qui n'hésitent pas à venir parler de leur travail et à partager leurs expériences. Donc merci à ces barcampers et à la prochaine !

Paris Javascript Meetup #2

L'API Spore

J'ai continué mon immersion dans les mondes parallèles et vous propose un feedback rapide du très intéressant du Paris JS Meetup 2, qui s'est déroulé chez ISART Digital avec en maître de cérémonie Pierre-Loic. Intéressant à plus d'un titre, car non content d'y apprendre des choses passionnantes sur le vrai développement web, j'y ai rencontré des gens hors de la matrice Java/JavaEE, qui codent et qui le montrent. En outre et c'est là que l'on se rend compte de la richesse de ce type de soirée, je me suis trouvé à discuter aussi bien avec des développeurs iPhone, qu'avec des games designers ou encore des administrateurs systèmes fans de devops. La soirée s'est donc à peu près passée comme tout bon meetup qui se respecte, c'est à dire un enchaînement de quelques présentations, une pause pizzas, la suite des festivités et un dernier verre où l'on refait gentiment le monde.

Voici en bref, le contenu des différentes présentations :

Présentation HTML5 - Grégory PAUL

Grégory nous a présenté avec exemples à l'appui, des notions d'HTML5 sur :

• Les Webworker,
• Le WebGL,
• Les Websockets via un exemple de chat avec node.js,
• Le Webstorage,
• La Géolocalisation,
• ...

Présentation de Spore et Node-Spore - François de Metz

J'avais entendu parler de spore à l'OSDC FR 2010 cet été et j'avais trouvé l'idée relativement intéressante, car je n'avais pas réellement compris l'impact de cette API. En effet, le but de spore est de non seulement de décrire une API REST au travers d'une syntaxe JSon simple, mais aussi d'apporter du comportement dynamiquement au travers de middlewares dont le but est d'adapté une API cliente et ainsi de pouvoir gérer les différences de versions par exemple. Parmi les fonctionnalités énoncées par François, on retrouve :

• La possibilité de rajouter des informations d'authentification à la volée,
• La possibilité de réparer une API cassée,
• La possibilité de mettre en cache les réponses,
• Le middleware connect permettant de rajouter OAuth sur l'appel d'une API Twitter par exemple,
• ...

Présentation sur les jeux en HTML5 - Pierre-Loic Doulcet

Encore une présentation aussi intéressante que technique avec un petit côté vintage, car Pierre-Loic nous a gentillement rappelé que sans la game-loop, point de salut ! Voici une énumération un peu sommaire du cookbook concocté par le speaker :

• Un rappel sur ce qu'est une game-loop,
• Eviter de redessiner tout l'écran afin de gagner en traitement,
• Utiliser setTimeOut plutôt que setIntervale,
• Utiliser le Webstorage locale,
• Utiliser YUI Compressor et Closure pour optimiser le transfert,
• Utiliser un setTimeOut et dynamique en fonction du temps déjà passé dans la game-loop,
• Utiliser les Webworker pour l'IA,
• La balise Audio est juste super limitée !

A noter que Pierre-Loic organise en 2011 le Html Game Jam, soit 48h pour coder un jeu en HTML5 de manière collaborative.

Présentation de La balise video HTML5 et Javascript - Clément Hallet

Cette présentation nous a montré comme améliorer le comportement d'une balise HTML5 en Javascript. Le cas d'école a été la balise vidéo où Clément a pris un malin plaisir à modifier ses attributs par le DOM avec Mooplay. Un exemple intéressant a été l'ajout par incrustation d'une traduction sur l'image en cours de lecture. Un projet à suivre...

...

Devoxx 2010

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...

Releaser avec Maven sur github

Le but de l'exercice est de releaser un projet Maven simple en utilisant le maven-release-plugin via Cygwin sur la plateforme github. En effet, la procédure serait aussi simple que sur Subversion, à la condition d'avoir ses settings et ses POM au carré, ce que nous allons voir de suite.

Pour mener à bien l'opération, les pré-requis sont les suivants :

• Avoir un environnement de développement sous Cygwin, le mien étant Windows XP SP3 / Cygwin 2.712, / java 1.6.0_17 / git 1.7.1 avec une auto-complétion des commandes git bien pratique,
  
• Avoir une configuration Maven opérationnelle dans le sens où vous avez accès aux maximums de repositories publics et une plateforme d'hébergement/déploiement pour vos archives. La mienne étant Maven 2.2.1 / Nexus™ Open Source Edition 1.7.1. J'avoue avoir de la chance, car j'utilise pour mes tests, ma plateforme d'entreprise (chez Vidal) configurée aux petits oignons par mon collègue Thierry que je salue au passage (@tnehr),
  
• Avoir un compte chez github (même gratuit) pour héberger ses sources.
  

1. Créer son projet Maven

Pour effectuer notre opération vous devez disposer d'un projet Maven simple. Nous allons en générer un à partir de la commande Maven suivante :

mvn archetype:generate

Choisissez de préférence l'archétype maven-archetype-quickstart, qui nous offrira un projet simple (code + tests) à tester.

2. Créer et ajouter son projet sous github

Pour le créer, rien de plus simple, tout se fait au travers de la console d'administration github. Donc, nous allons créer un projet "bar" via la commande :

Create a New Repository

Github vous indiquant comment importer le projet, je passe rapidement sur cette étape, mais voici tout de même pour informations, mes commandes git :

- git init
- git add *
- git commit -m 'Push bar example project'
- git remote add origin git@github.com:ulrich/bar.git
- git push origin master

3. Préparer ses POM

Cette étape est importante, car elle permet de "déployer" dans l'origine, un tag sous github. Pour ce faire, nous allons ajouter dans notre POM, la balise SCM comme indiqué ci-dessous :

<scm>
<connection>scm:git:ssh://git@github.com/ulrich/bar.git</connection>
<url>git:ssh://git@github.com/ulrich/bar.git</url>
</scm>

A vérifier, mais dans le cadre de nos projets avec plusieurs sous-modules, nous avons ajouté systématiquement la balise SCM dans les POM des modules (sachant qu'elle est identique).

Un dernier ajustement concerne la connexion sous github. En effet, lors du déploiement, le plugin aura besoin de commiter, mais surtout de pusher ses modifications effectuées dans le POM. Si vous avez généré une clé SSH avec une passphrase, vous aurez besoin de taper les commandes suivantes, afin d'ajouter votre clé à votre session en cours et ainsi, éviter de bloquer le déploiement.

- ssh-agent /bin/bash
- ssh-add ~/.ssh/id_rsa

4. Exécuter le plugin

Nous voilà en phase finale de procédure, le but étant bien entendu d'utiliser le maven-release-plugin, qui au travers de deux actions/phases consécutives : de faire un tag git avec la version souhaitée, de déployer nos archives JAR et de monter de version notre projet. Nous devrons donc exécuter les commandes suivantes :

- mvn release:prepare
- mvn release:perform -Dgoals=deploy

Voilà ! Il est intéressant de noter les étapes et les commandes par lesquelles, le plugin a exécuté son tag et sa montée de version.

Nous voilà donc avec un tag git fraîchement crée dans github :







N'hésitez pas à me remonter les points, qui peuvent vous sembler obscurs ou incorrects.

Retour sur Rework

Je me suis pour une fois sorti la tête des ouvrages techniques, de mon GoogleReader/programming/languages et autres joyeusetés de ce genre, pour me plonger dans le livre à la mode, Rework. Ce livre co-écrit par Jason Fried et David Heinemeier Hansson est un cookbook destiné aussi bien aux boss, qu'à leurs employés, désirant comprendre et décrypter les clés de la réussite de cette entreprise : 37signals, qui est au passage la boite qui a crée le website Basecamp et le framework ROR. L'ensemble repose sur un enchainement intéressant de chapitres courts mais percutants, avec des illustrations assez plaisantes. Tout est écrit en noir & blanc dans un anglais assez compréhensif, qui permet de le terminer en un clin d'œil, si vous n'avez pas fait comme moi et pris des notes quasiment à chaque chapitre.

Je ne vais pas coucher toutes mes notes sur cette page, mais vous en énumérez les premiers points qui m'ont le plus marqué, car ce livre a été pour moi et sera je l'espère pour vous, un vrai catalyseur pour créer/agir/entreprendre/réaliser/coder/intégrer/... A noter, que ces énumérations sont le fruit de mon interprétation et peuvent avoir un autre sens pour vous.

Les erreurs ne sont pas une étape nécessaire vers la réussite, car comment peut-on apprendre d'une action ratée, elle nous apprend à éviter les pièges mais pas à réussir. Et au contraire, le succès engendre le succès,

Faire un business plan impose bien souvent un cadre trop rigide à entrepreneuriat, car la réussite passe parfois par l'improvisation,

Maîtriser sa croissance, ce n'est pas en ajoutant des salariés que l'on aura une meilleur rendement. Les grandes écoles l'on compris et préfère avoir un ratio élève / professeur raisonnable, gage de la qualité de l'enseignement. Paradoxalement, les petites entreprises veulent grandir et les grandes devenir plus modulaires pour être plus agiles, ce qui est intrinsèquement la qualité d'une petite structure,

Le vrai héros n'est pas la personne qui passe sa vie au travail, mais la personne qui sait accomplir sont travail en temps et en heure et mener une vie personnelle, lui permettant de s'épanouir,

Un entrepreneur est juste une personne qui veut faire ce qu'elle aime, au moment ou elle souhaite le faire et de la manière qu'elle le souhaite. La meilleur façon de concevoir un produit est de le concevoir pour soit,

Il ne faut pas s'abriter derrière l'excuse du temps pour ne pas entreprendre, car tout le monde peut trouver du temps et de plusieurs manières comme : partir une heure plus tôt du travail une fois dans la semaine, se coucher une heure plus tard...,

Un bon business a une idée directrice à laquelle on doit rester fidèle. Cela permet de mieux maîtriser son travail, de ne pas partir dans tous les sens et d'être cohérents aux yeux des clients,

La startup n'est pas le format idéal pour entreprendre. En effet, elle déconnecte de la réalité et place les gens dans une bulle et le marché, le business, les concurrents sont parti de réalité,

Rester léger. Eviter les process trop long, compliqués, les meetings trop nombreux... Etre léger permet le changement, force à se focaliser sur le produit,

...

Comme vous pouvez le voir, ce livre regorge de bons conseils et toutes les énumérer reviendraient à plagier les auteurs, c'est pour cela que je vous encourage à acheter ce livre et vous lancer comme moi, dans des projets qui vous donneront envie de partager et d'apprendre, bonne lecture.

Groovy Grails User Group #2

Encore une bien sympathique rencontre au Groovy Grails User Group hier soir avec les organisateurs et les gugers. Cette rencontre était basée sur l’étude du pourquoi et comment migrer une application web Java standard vers Grails par Stéphane Maldini, qui est au passage commiter sur iceScrum.

J’ai bien aimé la façon dont Stéphane a amené la chose et exprimé le besoin en tant que développeur, de passer à d’autres outils aussi facile d’accès, qu’instinctifs et toujours dans l’esprit de vouloir voir autre chose.

Je ne vais pas passer au crible les différents slides exposés par Stéphane car mon iPhone m’ayant joué des tours, j’ai perdu la moitié de mes notes. Néanmoins, j’ai été un peu étonné par un ou deux argument exposé.

Le premier était que Grails favorise les tests. Je bloque sur ce point et ce, malgré les arguments exposés. En effet, je ne peux comprendre en quoi Grails permet ou facilite l’écriture de tests unitaires. L’idée de Stéphane était que le couple Groovy/Grails permettant un développement plus rapide du code et générant des squelettes de tests, il offre la possibilité au développeur d’utiliser son surplus de temps à l’écriture des tests (sic) !

Le second est qu’il faut abandonner Maven au détriment d’IVY. Cet argument a provoqué une levée de bouclier dans l’assemblée, car bien évidemment, il remet en cause une migration déjà couteuse du SI. Le ressenti de Stéphane vis-à-vis de Maven provenait à priori sur l’aspect normé de Maven, qui impose sa structure de projet. Je pense personnellement, qui faut garder Maven pour les raisons suivantes :

• La majorité des SI aujourd’hui travail sous Maven,
• Le mapping du file system Maven sur Grails, n’est pas très couteux,
• Modulo un bon tunning des POM projets et des plugins, on garde la possibilité d'utiliser un maximum de plugin et reporting sur son projet.

A l’issue de la présentation, des questions/réponses ont fusé, dont la mienne portant sur un comparatif Playframework vs Grails. La réponse a été mon cinglante que je ne le pensais, car il semble que Play! soit un bon challenger à Grails, mais sans la multitude de plugins offerts par Grails.

Dommage, que je n’ai pu aller à la troisième mi-temps pour discuter et partager avec les gugers, mais j’espère rectifier le tir à la troisième rencontre !

I am back

Après un long silence du en partie à des petits soucis personnels, qui sont à ce jour "fixés". J'ai décidé de reprendre la maintenance de ce blog et m'appuiera sur celui-ci pour :

1) Partager mon travail personnel sur divers projets que je lance cette année comme :

• L'étude (retour aux sources) de la programmation fonctionnelle (particulièrement de Clojure),
• L'étude de solution NoSQL,
• L'étude du framework Play!,
• L'étude de JEE6,
• L'étude du SCM Git,
  
• Le développement d'une seconde application Java sous Google App Engine,
• L'étude de protocole de type Comet et framework comme Atmosphere.
  

2) Partager mes impressions sur des meeting auxquels je participe assez régulièrement comme les BarCamp, JUG, NoSQL User Group, Devoxx...

3) Partager le fruit de mon travail concernant le passage de ceinture sur Java black Belt et de la SCJP.

A bientôt,