Keynote 1 : L’histoire des écritures
par Clarisse Herrenschmidt
Clarisse Herrenschmidt, chercheuse au CNRS est linguiste, philologue, anthropologue et sémiologue nous présente lors cette première keynote une partie de ses réflexions sur le passé, le présent et l’avenir des langues. Comment les langues sont nées ? Comment se sont-elles construites? Comment ont-elles évolué ? Et surtout, comment vont-elles évoluer ? Pour elle, tout commence à partir de l’invention des monnaies sur la base des calculi et leur représentation de la valeur/des biens. Ces calculis et les langues évoluent jusqu’à contenir des symboles puis des symboles mathématiques puis des nombres… jusqu’à ce que cette monnaie en cours de naissance soit basée sur le poids des métaux (les electrums) puis de la monnaie frappée et des lettres de change. En parallèle, elle nous explique l’évolution du langage mathématique dont l’évolution se décorrèle de celles des monnaies quand Dixon coupe le lien entre le dollar et l’or. Ce qui est intéressant à comprendre (pour nous informaticiens) est dans la partie sur l’évolution des langues, elle ressemble fortement à l’évolution des langages informatiques et comment ils se créées, vivent, s’adaptent, disparaissent et permettent à des langages plus évoluées de prendre la place.
Keynote 2 : Object and Functions, conflict without a cause
Par Martin Odersky
Le père du langage Scala nous présente à travers de sa keynote pourquoi il a créé Scala et quels en sont les enjeux. Clairement, Scala se veut le langage qui unira programmation impérative, objet et fonctionnelle. Les avantages de la programmation fonctionnelle sont nombreux et clairement indiqués dans les problématiques applicatives de notre époque. Scala est un langage récent, à typage statique, qui compile vers du bytecode Java et qui tourne sur la JVM. Scala permet d’écrire facilement des applications optimisées pour les problématiques de scalabilité, de réactivité et de distributivité ! Il permet aussi de réaliser facilement des traitements sur les collections avec son API très riche. Scala permet facilement d’éviter les problèmes de muabilité et de non déterminisme.
Elastifiez votre application : du SQL au NoSQL en moins d’une heure
Par Tug Dual Graal @tgrall (technical advocat chez CouchBase et David Pilato @dadoonet (technical advocat chez Elastic Search)
Ils dressent le constat que lorsqu’une bdd relationnelle devient trop lourde et des problématiques de scalabilité se posent. De plus, les recherches full text sont très complexes à mettre en oeuvre avec ces bdds.
Devant nous, ils écrivent une application web avec AngularJS qui va interroger des services REST Spring, qui récupèrent les données dans une base noSQL CouchBase. Sur cette application, ils connectent un noeud Elastic Search qui va indexer les données et permettre des recherche full text depuis notre nouvelle application. Enfin, ils réalisent devant nous des insertions de grands volumes de données qu’ils vont ensuite analyser avec le plugin Kibana d’Elastic Search. Ce plugin permet d’analyser les données de notre Elastic search et de réaliser des statistiques de manière dynamique sur ces données.
Comparing JVM Web Frameworks
par Matt Raible
Matt Raible a mis à jour sa célèbre conférence de comparaison des Frameworks Web et c’est une ballade à travers cette comparaison qu’il nous propose. Dans un premier temps, nous parcourons rapidement l’histoire des web frameworks, nous en venons au constat qu’une multitude existe mais que le problème n’est pas le nombre mais de poser les bons critères de choix.
Matt expose sa méthode de choix :
- Définir ses priorités,
- Pondérer chacun de ses objectifs,
- Évaluer et sélectionner des candidats puis réaliser des POCs.
Les critères de sélection de Matt pour choisir sont :
- Quelle la taille de la communauté ?
- Quel est le niveau du support ?
- Ce framework respecte-t-il l’architecture REST ?
- Ce framework permettra-t-il à mon application d’être utilisable sur Mobile ?
- Quel est le niveau de performance ?
- Quelle est la vitesse de rendu des pages ?
Les frameworks étudiés sont :
- FullStack : Rails, Grails, Play!, Lift, Spring Roo, Seam,
- SOFEA*1 – JavaScript MVC : Backbone.js, Batman.js, JavaScript MVC, Ember.js, Sprout Core, Knockout.js, AngularJS,
- SOFEA*1 – API : RESTEasy, Jersey, CXF, vert.x, Dropwizard,
- Pure web – GWT : SmartGWT, GXT, Vaadin, Errai,
- Pure web – Apache : Wicket, Struts, Spring, Tapestry, Click,
- Pure web – JSF : Mojarra, MyFaces, Tomahawk, IceFaces, RichFaces, PrimeFaces.
*1 : SOFEA : Service Oriented Front End Architecture
Chaque framework est noté selon les critères précédents mais Matt rajoute quelques autres points à prendre en compte.
- FullStack : Choisir par connaissance du langage,
- SOFEA : Choisir en fonction des APIs disponibles et à consommer,
De plus, il ne garde que ceux : qui ont eut une release en 2012, et dont le développement n’est pas arrêté, 1 livre sur Amazon, 10 jobs sur dice.com et plus de 250 questions sur stackoverflow. Pour tous, il conseille de regarder aussi sur quelques sites, la facilité à trouver des développeurs et le nombre d’offres de jobs puis d’en faire le rapport (Le framework est-il connu ? Est-il facile de trouver un développeur ?) Enfin, il ajoute notamment le fait (presque logique) que la solution retenue doit s’intégrer facilement au patrimoine applicatif de la société.
Quelques conclusions :
- Grails est le framework full stack le plus demandé sur dice.com
- SpringMVC est le pure web framework le plus demandé sur dice.com
- Backbone.js est le js web framework le plus demandé sur dice.com
- Grails est le framework full stack le plus connu sur linkedin.com
- SpringMVC est le pure web framework le plus demandé sur linkedin.com
- Backbone.js est le js web framework le plus demandé sur linkedin.com
- Grails (puis Playframework) est le framework full stack le plus demandé sur google trends
- SpringMVC est le pure web framework le plus demandé sur google trends.
- AngularJS (puis Backbone.js) est le js web framework le plus demandé sur google trends.
- Grails (puis Playframework) est le framework full stack le plus demandé sur google trends.
- SpringMVC est le pure web framework le plus demandé sur google trends.
- AngularJS (puis Backbone.js) est le js web framework le plus demandé sur google trends.
- Playframework est le framework full stack dont la mailing list est la plus active.
- AngularJS est le js web framework dont la mailing list est la plus active.
- Grails (puis Playframework) est le framework full stack le plus actif sur stackoverflow.
- SpringMVC est le pure web framework le plus actif sur stackoverflow.
- Backbone.js (puis AngularJS) est le js web framework le plus actif sur stackoverflow.
Architecting for continuous delivery
par axel fontaine (@axelfontaine)
L’objectif d’Axel Fontaine est de nous présenter les bonnes pratiques à observer dans une usine logicielle pour déployer de manière automatisée, en sécurité, et continue plusieurs fois par jour en production. Axel nous explique que c’est déjà la réalité pour certains sites :
- facebook,
- flickr,
- etsy,
- stackoverflow.
Pour lui, les pré requis pour arriver à cela sont :
- Les processus projets adéquats niveau développement
- Les outils de builds de l’entreprise : sont-ils automatisés ?
- Le versionnement des sources et livrables : sont-ils industrialisables ?
- Les tests : sont-ils unitaires, intégrations, fonctionnels, et automatisés ?
Premièrement, nous ne déployons jamais des versions dites SNAPSHOTs (id est de développement) des applications, nous déployons uniquement nos RELEASEs. Puis, il faut arriver à réaliser des cycles très courts de développement/livraison où les RELEASEs ne sont plus associées à des efforts lourds. La RELEASE ne doit rien coûter. Enfin, pour assurer une disponibilité continue des applications en production, il faut pouvoir livrer les RELEASEs avec la technique “BLUE/GREEN DEPLOYEMENTS” (technique visant à livrer sur un serveur à la fois)
Pour en savoir plus, le livre “Continuous Delivery” de David Farley et Jez Humble
Son site axelfontaine.com
Play VS. Grails Smackdown
par James Ward (@_JamesWard) et Matt Raible(@mraible)
James Ward et Matt Raible nous font un show pour cette conférence ! Ils ont décidé de comparer Play 2 et Grails 2 qui sont tous les deux parmi les frameworks Web tournant sur la jvm les plus populaires ! Ils ont développé tous les deux la même application en cinq semaines. Les critères de comparaison sont :
- les templates,
- les formulaires,
- la pagination,
- l’authentification,
- l’écriture des jobs,
- les flux rss,
- l’envoi d’email,
- les tests unitaires,
- les tests d’intégration,
- les tests fonctionnels,
- les tests de montée en charge,
- les performances,
- la recherche,
- l’upload de photos,
James souligne que les éléments les mieux de Play sont : la simplicité, la gestion des urls, le rechargement automatique des classes, le stateless, le support java/scala, les tests, ebean, le déploiement instantané sur heroku, le nio serveur.
Matt explique que les meilleurs éléments de Grails sont : poussé par Spring, basé sur Groovy, la documentation, les urls propres, le GORM, l’intégration à intellij, le zero turnaround, les tests, l’optimiseur de ressources, et le déploiement instantané sur heroku.
Puis, la suite de la conférence est un échange entre Matt et James afin de citer selon eux sur chaque critère pourquoi telle ou telle framework est mieux. Globalement, les deux frameworks se valent sur la plupart des points toutefois niveau performance Playframework se détache et prend la tête.
Faciliter le développement d’applications Web hors-ligne en JAVA avec GWT
Par Arnaud Tournier
Présentation très intéressante proposée par Arnaud Tournier (Palo IT) qui présente les possibilités dont dispose GWT pour mettre en oeuvre une application web en mode déconnecté à travers quatres thématiques principales :
- Le cache d’application
- Stockage de données locale
- SGBD locales
- Synchronisation d’application
Le cache d’application
La mise en oeuvre d’un cache d’application sous GWT est relativement simple. Tout d’abord dans le html container, il faut déclarer dans la balise ‘html’ l’attribut ‘manifest’ en indiquant le chemin du manifeste de ressources. Ce dernier doit contenir la liste des ressources à cacher. Via la couche JSNI (Javascript Native Interface), il est possible de créer un Linker pour lister automatiquement les ressources à cacher. Toujours via JSNI L’application GWT peut ensuite communiquer avec le gestionnaire de cache (window.applicationCache) pour détecter une mise à jour des ressources.
Stockage de données locale
Après avoir survolé WebSQL et IndexedDB en raison de leur couverture incomplète par les navigateurs actuels, la présentation s’est focalisé sur LocaleStorage disponible lui sur l’ensemble des navigateurs et pris en charge nativement par GWT. la fonctionnalité reste cependant limitée, avec 5M de stockage autorisé en moyenne (jusqu’a 10 pour certains) et une manipulation archaïque (clés, valeurs texte). Un absent de taille a pour le coup été oublié avec l’api HTML5 FileSystem !
SGBD locale
La présentation s’est ensuite focalisé sur les moyens disponibles à une application en mode déconnecté de manipuler les données.
ERRAI de JBoss est à surveiller car très prometteur mais encore incomplet , mais le choix qui s’impose est SQL.js largement supporté et là encore accessible depuis GWT en JSNI ($wnd.SQL) avec une API disponible pour les actions habituelles de SGBD. A noter également que les performances qui sont vraiment très bonnes (immédiat pour une recherche sur plusieurs milliers d’enregistrements).
Synchronisation
La complexité de la mise en œuvre d’une synchronisation de l’application cliente avec le navigateur depends des actions que l’on autorisera à l’utilisateur :
– Lecture seule : synchronisation triviale
– Lecture / ajout : gestion des nouveaux enregistrements nécessaires, une astuce proposée etant d’utiliser des id négatifs pour les enregistrements locaux
– Modification / suppression : plusieurs stratégies sont possibles (source wins, destination wins, specified replica winws, merge, etc..), mais quelque soit la stratégie utilisée la synchronisation s’avérera complexe.
La présentation s’est terminée avec une démo très bien ficelée pour illustrer le tout !
7 idées pour transformer une bonne équipe en équipe exceptionnelle
Par Samuel Le berrgaud
Conférence réalisée par un sponsor de la Devoxx, elle pose 7 bonnes pratiques pour rendre le travail des développeurs plus efficace, et surtout plus motivant.
Les idées sont les suivantes :
- La zone : “la zone”, c’est le moment où le développeur est 100% productif.
But : l’équipe doit d’être dans la zone le plus possible
Problème : cela arrive rarement à cause des interruptions (de surcroît si l’équipe se situe en open space)
Première solution : définir des plages horaires où l’équipe ne doit pas être dérangée sous aucun prétexte (on peut même mettre une pancarte “Ne pas déranger” lors de ces moments)
Autre solution : définir un “bouclier humain”. Ce dernier est l’unique référent qu’on “doit déranger”. Et s’il n’a pas la compétence pour répondre, la personne demandeuse doit ouvrir un ticket.
Faisabilité : 3/5
Excellence : 5/5 - Alimentez votre cerveau :
But : L’équipe doit être à l’écoute de son environnement afin de rester efficace et d’améliorer ses compétences. Cela peut passer par des conférences, formations, sessions de DEV…
Problème : Les membres de l’équipe ne sont pas forcément disponibles le soir après le travail.
Solution : les “brown bags”. A la pause du midi, chacun des membres de l’équipe apporte son “sac de nourriture” et l’équipe se fait une session de veille en parallèle (dojo, discussion autour d’une vidéo…)
Faisabilité : 5/5
Excellence : 2/5 - Dites “Bon travail” :
But : Il faut montrer la reconnaissance auprès des développeurs. Ce sont les petites attentions qui peuvent faire de grandes choses. Il faut que la reconnaissance puisse être exprimée publiquement, pour tout le monde et facilement visible.
Une solution : Dans l’entreprise du speaker chacun avait droit à 2 “KUDOS” (reconnaissance) par an. Un exemple : une personne pouvait remercier une autre (via le portail de l’entreprise par exemple) et dire par exemple que cette dernière aime bien le cinéma. Quelque jours plus tard la personne remerciée recevait des tickets cinémas….
Faisabilité : 2/5
Excellence : 3/5 - Report robot :
But : Savoir où l’on est, où l’on va. Cette pratique vise à s’aider d’indicateurs en tout genre. Exemple : le temps passé sur une fonctionnalité/revue de code, le temps d’un build, les performances du serveur de test, la vélocité, les valeurs métiers, le trafic, le nombre de tickets fermés, le nombre de postulants, le nombre d’embauchés etc….
A partir de ces metrics, des rapports sont automatiquement générés et disponible pour toute l’entreprise.
Solution : Dans l’entreprise du speaker, ils ont un “radiateur d’information” où chaque développeur peut voir sur son “bureau PC” les différents indicateurs (un widget). Ce radiateur est géré par une seule personne.
Faisabilité : 2/5
Excellence : 4/5 - Eat your own dogfood :
But : C’est d’être le premier utilisateur du produit que l’on fabrique afin de mieux comprendre l’utilisateur et surtout avoir un retour rapide (plus coûteux si le produit est déjà “en PROD”). Le speaker nous sort l’exemple de l’Iphone dont les premiers prototypes étaient disponibles aux salariés de l’entreprise
Problème : ça peut faire mal à l’ego vu la “proximité du feedback”
Faisabilité : 2/5
Excellence : 5/5 - Faites une journée spéciale :
But : c’est le “clean up day” (journée de nettoyage). Cette journée hebdomadaire permet de traiter les tâches qu’on a pas le temps de faire le reste de la semaine et/ou des “choses pas marrantes” (refactoring de code, documentation utilisateur….). La philosophie de cette journée, c’est également de profiter de la synergie de groupe. En effet, à plusieurs sur une même tâche, c’est tout de suite plus facile.
Solution : un rédacteur technique est désigné pour décider de ce qu’il y a aura à faire lors de cette journée (cela peut-être fait le matin même). A la fin de cette journée un livrable doit être produit, celui-ci ne devra pas être trop gros.
Faisabilité : 5/5
Excellence : 3/5 - Le temps de l’expérience :
But : Favoriser l’innovation (ex: la journée chez Google où les salariés peuvent se consacrer à une autre tâche que le projet en cours)
Solution : cela peut se faire sur une journée par semaine. Chacun ramène son “brown bag” (cf. Alimentez votre cerveau). On se fait un mini-sprint. Le soir, chacun présente sa solution en 3 minutes, 1 gagnant est désigné.
Problème : on peut produire du “bad code”. Dans ce cas-là, il faudra faire attention à refactorer la solution.
Problème 2 : ce n’est pas toujours évident de réserver 20% de son temps. Dans l’entreprise du speaker c’est 5% du temps qui est consacré à l’innovation
Faisabilité : 2/5
Excellence : 2/5
Extra du speaker : il ne faut pas abandonner, les échecs sont possibles. De plus, il ne faut pas appliquer bêtement des solutions préconisées, mais trouver son propre style. Ce qui compte, c’est d’avoir la volonté de toujours s’améliorer.
Java EE 7 plus en détail
Par David Delabassee
Dans sa conférence, après nous avoir exposé le point de vue d’Oracle sur Java EE 7, David s’attache à nous présenter les nouveautés phares de cette version, tout en rappelant que le but premier est d’accroitre la productivité.
David nous présente les JSR incontournables de cette nouvelle version à savoir :
- JSR 342 : Elle prévoit l’amélioration de JAX-RS 2.0, EL 3.0 et JMS 2.0 ainsi que l’ajout d’une API pour les batches.
- JSR 353 : API pour parser et générer du JSON (à l’image de ce qui existe pour XML)
- JSR 356 : API pour les WebSocket (standardisé – supporte le full duplex)
- JSR 352 : API pour les batches (standardisé)
- JSR 236 : Concurrency Utilies for Java EE
Enfin, David termine sa conférence sur un bilan sur les changements survenues au niveau de JAX-RS 2.0, JMS 2.0, Bean Validation 1.1 et Java Server Faces 2.2.
Les tests : pourquoi et comment ?
Par Axel Haustant, Xavier Renaudin, Grégory Paul
Sous la forme d’un retour d’expérience sur des projets mis en place chez Mappy, cette conférence balaye les méthodes et bonnes pratiques de tests utiles.
Quelques pratiques/méthodes intéressantes sont évoquées comme :
- Le Definition Of Done
- Le code review
- Le coding dojo
- La stratégie Stop the line
- Mise en place de binôme de maintenance responsable de build
- Priorisation verticale selon le principe de la Pyramide de Cohn
- Mise en place d’une intégration continue (par exemple JENKINS) et publication des stats par équipe pour connaitre « la météo » de chaque équipe
- Mise en place de Fitnesse, un outil permettant de rapprocher dev/métier
- Mise en place de CasperJS/PhantomJS
- Optimiser les tests unitaires
- Mise en place de watchdog pour contrôler les données
- Utilisation de GitBisect pour comprendre l’origine d’un bug
La conférence s’achève sur la conclusion qu’il faut soigner les tests car il s’agit d’un investissement rentable. Enfin, il ne faut pas chercher à couvrir des 100 % du code mais plutôt chercher à couvrir 100 % des cas fonctionnels.
Implémenter la qualité sur un projet Java
Par Vincent MASSOL
S’appuyant sur le projet open source XWiki pour illustrer sa conférence, Vincent nous explique comment assurer la qualité sur un projet JAVA et les pratiques à appliquer pour y parvenir.
Quelques pratiques sont rappelées comme :
- Test coverage
- Tracks bugs
- Stable automated functional tests
- Ensure JAR stability
- Ensure JAR hell
Vincent détaille les risques de stabilité des API. Pour cela, il insiste sur :
- l’intérêt de l’annotation @Deprecated
- l’intérêt du plugin « clirr-maven-plugin » qui permet de prévenir des risques de casse de compatibilité binaire
- la possibilité de créer une annotation « @Unstable »
- la mise en place d’un projet de type legacy et son utilisation par le biais du plugin « aspectj-maven-plugin »
Pour corriger les problèmes de JAR HELL, les plugins maven suivants sont évoqués :
- maven-duplicate-finder-plugin
- maven-aforcer-plugin
Elément capital dans la qualité d’un projet Java : la couverture de test, Vincent nous présente ici le plugin « jacoco-maven-plugin », qui définit un niveau de couverture de test minimum sur un projet. Le cas échéant, la construction du build est mis en échec.
Outre les tests de stabilité fonctionnel, Vincent évoque la mise en place d’un Bug Fixing Day et nous montre les retombées positives sur la qualité du projet XWiki.
La présentation s’achève sur un dernier tour d’horizon de pratiques possibles.
