fr.romain:blog:3.0

Un blog qu'il est bien pour le Java

SoftShake 2013 - Deuxième Jour

| Comments

Soft Shake 2013

Et c’est parti pour le second jour de la conférence Soft-Shake.

Keynote collaborative

La première keynote de la journée était une keynote “collaborative”. Chaque responsable d’un track de sessions avait la parole pendant 4 minutes pour nous exposer sa vision à moyen terme (entre 2 et 5 ans) concernant sa technologie. Par exemple, le responsable de la partie “web” nous a dit que le JavaScript sera encore plus présent qu’aujourd’hui, en particulier du côté serveur.

Keynote Programatoo

4.5/5

La seconde keynote parlait de ”Programatoo”, un projet lancé par Audrey Neveu (@Audrey_Neveu) et Aline Paponaud (@bootis) de SFEIR. Qu’est-ce que Programatoo ? Il s’agit d’apprendre à coder à nos enfants, n’y plus n’y moins.

Programatoo

Revenons 20 ans en arrière pour comprendre la génèse de cette idée. Au milieu des années 80, Aline et Audrey sont des petites filles (très sages, forcément) déjà attirées par les mystères de l’informatique et des ordinateurs. Elles veulent comprendre comment ça marche. 10 ans plus tard, leur intérêt est toujours intact, mais hélas elles se heurtent souvent à des stéréotypes (”ce n’est pas pour les filles !”) ou l’incompréhension du milieu scolaire pour ce domaine. Audrey apprend avec joie qu’il y a des cours d’informatique dans son lycée. Elle s’y inscrit, mais cela se résumera à apprendre à utiliser Word ou Excel. C’est la déception. De son côté, Aline n’a guère plus de succès. Fort heureusement, elles ne baissent pas les bras, et embrassent le métier de programmeuse.

En 2012, Aline va trouver Audrey pour proposer une idée géniale : et si on apprenait à coder à nos enfants ! C’est ainsi qu’en mars 2012 nait la première session “Programatoo”, avec les enfants des employés de SFEIR. Et c’est un succès.

Les choses ne sont pas pour autant parfaites. Elles font un constat navrant. Parmi les participants, il y avait deux adolescentes. Celles-ci sont parfaitement à l’aise avec les ordinateurs, du moins quand il s’agit d’utiliser Facebook, YouTube et autres services du genre. Mais elles sont incapables de vraiment utiliser un ordinateur, de comprendre comment cela fonctionne, ni même voir en cette machine un merveilleux outil de créativité !

On dit que la jeune génération est une génération “digitale”, qu’elle est née avec un smartphone dans les mains. Je le constate aussi, mon fils de 6 ans maitrise depuis un moment l’iPad, qui n’a plus de secret pour lui. Mais en réalité, nos enfants sont conditionnés pour ”consommer” de l’informatique. Il faut les aider à en devenir des acteurs, des vrais utilisateurs. Finalement, c’est un peu comme une carte et un GPS : aujourd’hui, l’utilisation d’un GPS est plutôt intuitive et il nous mâche tout le travail, on n’a plus qu’à suivre bêtement ses instructions. Du coup, il devient obsolète de savoir lire une carte papier classique, et pourtant cela reste la base pour savoir se positionner quelque part…

En tant qu’informaticien, il ne tient qu’à nous de changer la donne. Nous avons beaucoup d’outils, de langages destinés à l’aprentissage de la programmation, y compris destinés à de jeunes enfants. Ayant discuté ensuite avec Audrey, je vais sans doute essayer de mettre mon fils à la programmation. Bien entendu, point de Scala :) mais plutôt du Scratch qui a l’avantage d’être très visuel et ludique.

Il faut noter que le projet Programatoo n’est pas unique en son genre. Les conférences “Devoxx 4 Kids” s’organisent par-ci, par-là. Il y en avait justement une à Genève le samedi qui a suivi la conférence Soft-Shake.

Programatoo a également gagné le “Duke Choice Awards 2013” à la conférence Java One. Une très belle consécration amplement méritée. Bravo Audrey et Aline !

Speed-up your webapp

Alexis Bernard (@alexis_bernard)

2/5

Je suis ouvert d’esprit, je vais donc dans le track “Ruby” pour la première session de la journée. Alexis nous parle d’optimisation quand on veut accélérer son site web.

Première question : pourquoi le faire ? A cela, Alexis nous donne les exemples de Amazon et Yahoo! : pour le premier, diminuer le temps de réponse de 100ms, c’est un gain de revenu de l’ordre d’1%, ce qui n’est pas négligeable quand on voit leurs revenus… Pour le second, une diminution de 400ms de ce temps de réponse, et c’est 9% de traffic gagnés ! Tout le monde n’est pas Amazon ou Yahoo! mais cela reste intéressant.

La technique d’Alexis est simple : mesurer, optimiser et mesurer encore.

Donc il faut mesurer. Pour cela, Alexis nous parle de quelques outils :

  • New Relic, une solution SAAS visiblement assez poussée, qui historise en plus les mesures. Pratique pour comparer dans le temps. Mais c’est une solution assez chère visiblement (de l’ordre de 150€ par mois et par serveur).
  • Rack Mini Profiler, un outil Ruby, un peu dans la même idée que New Relic, mais avec moins de fonctionnalités, et pas d’historisation.
  • Pingdom dont l’une des fonctionnalités est de vérifier que les recommandations standard d’optimisations des sites-web sont bien respectées.
  • WebPageTest, qui a l’astuce de tester chaque requête 2 fois de suite. Cela permet ainsi de vérifier l’efficacité du système de cache des ressources.
  • Chrome Dev Tools peut aussi être mis à profit pour mesurer les performances de l’application.

Une fois les mesures faites, il faut corriger les problèmes. Alexis nous dit qu’il faut toujours optimser le back-end dans un premier temps. La plupart du temps cela va se résumer à optimiser la base de données, les requêtes, les indexes, etc. Une fois ceci fait, on peut s’intéresser à l’optimisation front-end. Là aussi des outils peuvent nous aider, Chrome Dev Tools par exemple, ou imageoptim.com, pour améliorer la compression des images.

Une session intéressante, mais qui ne va pas à mon goût assez loin dans les détails. Les solutions proposées restent assez basiques au final.

Golo, le langage qui donne des super-pouvoirs

Philippe Charrière (@k33g_org)

3.5/5

Mais qu’est-ce que Golo, ce langage au nom rigolo ? C’est un langage créé par Julien Ponge (@jponge) qui tourne sur la JVM, avec Java 7 ou 8 (pas avant, car Golo nécessite invokedynamic pour tourner, introduit en Java 7). Ses principales forces sont sa simplicité, sa légèreté ainsi que la facilité d’étendre le langage.

Philippe nous montre quelques exemples de code, la syntaxe reste assez compréhensible pour un développeur Java. Les lambdas, qui se font toujours attendre dans Java, sont là, tout comme les structures, des objets créés dynamiquement (ObjectDynamic) ou encore la possibilité d’étendre (augment) des classes existantes pour leur ajouter des fonctionnalités.

Je vous invite à aller jeter un oeil sur le site du langage - http://golo-lang.org - pour vous rendre compte de ce qu’offre ce langage, et voir quelques exemples concrets de code. Voilà un basique Hello World :

1
2
3
4
5
6
7
8
module EchoArgs

function main = |args| {
    println("Hello World...")
    foreach arg in args {
      println("->  " + arg)
    }
}

J’ai aimé cette présentation, qui nous a donné un bon aperçu de ce qu’est Golo. Toutefois, cela reste un langage dont le but m’échappe un peu - hormis le côté “fun” d’avoir créer son propre langage !

Mobile Troll Party

Xavier Bourguignon (@xbourguignon)

3/5

Une session pleine de violences

Une session pour le fun. Le but ici est de troller sévèrement sur iOS et Android. Je m’attendait à un peu plus de trash, un peu plus de sujets polémiques. Le jeu des deux présentateurs n’était peut-être pas assez rodé je pense, mais d’après ce que j’ai compris, Xavier devait la faire seul jusqu’à la veille au soir où il a réussi à convaincre son partenaire de venir aussi. Malgré tout, c’était une bonne ambiance, et les trolls étaient effectivement nombreux !

5 ans, 500 releases en 50 minutes

Freddy Mallet (@FreddyMallet) et Olivier Gaudin (@gaudol)

4/5

Compte tenu du temps imparti (45 minutes), cette session a été renommée ”4 ans, 400 releases en 40 minutes” :) Cette session raconte la vie de la société SonarSource, éditeur de l’outil d’analyse de code SonarQube (connu anciennement simplement sous le nom Sonar).

Lorsque SonarSource a été créée, il y a 5 ans, c’était une petite startup lancée par trois personnes (en particulier Olivier et Freddy), sur leurs fonds propres. La société marche bien aujourd’hui, et a bien grossi (une 20aine de personnes d’ici la fin de l’anée), mais il y a eu beaucoup de problèmes, de “douleurs”. En particulier 5 :

  • Les tests.
  • L’architecture.
  • L’infrastructure.
  • L’organisation.
  • Sonar on Sonar.

Un gros travail a été fait sur les tests. Les tests unitaires d’abord, mais aussi les tests d’intégration. Le fait que Sonar supporte 5 bases de données différentes, qu’il existe une soixante de plugins ne rend pas les choses simples. Toutefois, ils arrivent à tout tester de façon assez efficace.

Initialement, HibernateORM et GWT avaient été choisis. Le premier car gérer 5 bases de données et autant de spécificités n’est jamais aisé. Le second, car à l’époque cela répondait bien aux besoins de l’équipe. Mais ces choix se sont finalement avérés être des maillons faibles, et progressivement ont été remplacés.

Les développeurs ne font pas que des développements, il a fallu embaucher une personne dédiée à part entière pour gérer l’infrastructure et les releases. Mais un tel cloisonnement n’est jamais très efficace, et SonarSource a ainsi créer une équipe de “DevOps”.

Afin de ne pas être désynchroniser avec les utilisateurs de l’outil, l’équipe de SonarSource utilise SonarQube directement. Le fameux principe du ”Eat your own dog food” en somme. Ils ont ainsi une instance de “production” interne pour laquelle ils font des releases toutes les semaines. Cela implique donc d’être capable de faire des releases presque tous les jours, les développements de type “big bang” sont donc exclus.

Un dernier point abordé par Freddy et Olivier concerne le Quality Gate (un sujet qui mériterait sans doute une session à part entière). Il s’agit d’une sorte de contrat de qualité pour pouvoir faire une release. En gros, il faut respecter certaines règles, atteindre certains objectifs pour engager la release : par exemple, avoir clos tous les tickets JIRA, avoir une note SQALE de A (la meilleure), ne pas avoir de violations bloquantes ou critiques, ou même de violations non revues par l’équipe.

Bilan

Au final, ce sont deux très belles journées qui viennent de s’écouler. La qualité des présentations et le niveau des speakers sont très bons.

Les plus :

  • Du beau monde. C’est toujours un plaisir de revoir des gens qu’on apprécie, et de rencontrer physiquement des personnes que l’on ne connait que par Twitter.
  • De bons sujets.
  • Des tracks très variés : Java, agilité, web, mobile, IA/Robotique, BigData et NoSQL, Microsoft, Ruby on Rails.
  • Le repas des speakers (miam miam la fondue !)
  • Genève, très jolie ville.
  • Les organisateurs, très accueillants et toujours disponibles.
  • Les dessins en live des sessions (voir prochain billet).

Les moins :

  • La séparation des salles. Elles se trouvaient soit au 1e étage, soit au 5e. Changer de salle pouvait ainsi demander un peu de gymnastique !
  • A peu de choses près, les mêmes repas le midi sur les deux jours. Un peu plus de variété aurait été appréciable. Pas de problème au niveau de la quantité toutefois.
  • J’aurais bien aimé que SoftShake se tienne en hiver, Genève sous la neige doit être très agréable.

Pour résumer, Soft Shake est une très belle conférence, dans l’esprit de Devoxx ou Mix-IT. J’y retournerais avec grand plaisir !

Comments