Déjà eu envie de faire de l’open-source mais ne sachant pas comment débuter ? Vous avez un projet open-source et cherchez un coup de main ? Quelque soit votre situation, le Hackergarten qui aura lieu mercredi après midi  lors de Devoxx France est LE lieu où il faut être, vous y trouverez des commiteurs qui vous accompagnerons pour faire votre premier commit open-source sur un des projets représentés ! Organisé par Brice Dutheil et Mathilde Lemée, c’est un bon moyen de progresser et de se rendre utile.

Hackergarten c’est le rendez-vous des gens qui veulent participer aux projets opensource. L’idée c’est, dans un format de 3h, de contribuer un logiciel, un fix, un feature, une documentation dont d’autres pourraient avoir l’usage. Il s’articule autour de commiters actifs pour mentorer les hackers qui participent à l’évènement.

Bref que du bon.

Voilà la liste des projets qui seront représentés :

• Achilles
• FluentLenium
• CRaSH
• Ceylon
• Apache Maven
• Jenkins
• Restx
• Voxxrin
• Hibernate OGM
• Hibernate Search
• EasyMock
• Objenesis
• Spek
• et d’autres à venir !

La liste n’est pas fixée, commiters, vous pouvez vous ajouter ici ! Il vous faudra venir avec votre portable et n’hésitez pas à regarder les pré-requis pour pouvoir démarrer plus rapidement !

Devoxx France en deux mots : C’est la plus grande et la plus intéressante des conférences pour les développeurs Java en France.

Pour moi, ce fut une expérience formidable. En plus d’avoir appris quelques trucs, ce qui m’a fait le plus plaisir c’est d’avoir été conforté sur pas mal de choix que j’ai pu faire ou que je comptais appliquer  prochainement. Hormis l’absence de desserts sucrés et le nombre limité de boissons, l’organisation fut parfaite. Un grand bravo aux organisateurs !

J’ai choisi d’illustrer ces trois jours de conférences par une série d’articles qui racontent ce que pourrait être une success story pour un développeur Java ayant eu une « idée » :

Pour la petite histoire, je craignais au début que limiter à 25% le nombre de speakers anglophones allait mathématiquement faire baisser le niveau des speakers. Cela c’est avéré faux, le niveau des Français fut excellent, même meilleurs que les anglophones que j’ai pu voir. Bravo à tous et vive la France !

Quant à moi (beaucoup m’ont posé la question),  si je n’ai rien présenté et que je n’ai pas non plus voulu participer à la préparation de cette première de Devoxx France bien que je sois un Geek Passionné avec plein de choses à raconter, c’est que j’ai déjà beaucoup de projets en cours et  je pense qu’il est important de garder un certain équilibre entre vie professionnelle, loisirs, famille et amis afin de ne pas finir en « burnout » (En passant j’ai bien rigolé en lisant http://501manifesto.org/ ).

Je remercie ma société de m’avoir payé la conférence ainsi que l’hôtel au Marriott (4 étoiles c’est la classe !). Et si vous n’êtes pas encore Freelance ou que vous ne faites pas partie d’une société qui vous laisse gérer votre budget tel que Lateral Thoughts, il est peut être temps d’y réfléchir…

A l’année prochaine à Devoxx !

Web Oriented Architecture

Avant d’être Startupeur, Gérard était architecte urbaniste respecté et vénéré. Mais trop souvent, il a essayé de plier le web pour faire des applications dites « Stateful » où l’état du client est conservé côté serveur via les sessions. Ce qui amène pas mal de problèmes, en terme de performance bien sûr, car il est du coup difficile d’avoir un cache efficace, mais aussi des problèmes de développement, qui n’a jamais galéré à gérer le bouton « back » et à devoir mettre un bouton « back » spécifique dans son application alors que le navigateur lui-même en possède déjà un ?

La présentation de Habib, qui s’approche de la keynote a hypnotisé le public (et Gérard) en cassant les architectures dites « stateful » et antiweb, celle de Sadek et Guillaume montre que Play! pousse le développeur à embrasser le Web plutôt qu’à lutter contre lui.

Mais au fait c’est quoi une architecture Web ?

• Ressource based : Utilisation des URI et des mediatypes pour identifier et exprimer les « ressources » fournies par l’application
• Stateless : L’état de la conversation est gérée côté client, dans le browser. Le client change l’état de l’application via des commandes au serveur (verbes http PUT, POST et DELETE)
• HTTP powered : Utilisation du protocole HTTP et de ses verbes à bon escient : PUT, POST, DELETE, GET. Une application qui embrasse le web est une application qui ne fait que du CRUD.

WAT ? Mais comment va faire Gérard pour ne faire que du CRUD ? Son application fait des vrais trucs de barbus.

En fait c’est super simple, lorsque vous avez de faire un truc « compliqué » (qui n’est pas CRUD), comme par exemple, déplacer une somme d’argent d’un compte A (ressource) à un compte B (autre ressource) vous n’allez, côté client ni demander de modifier le compte A, ni demander de modifier le compte B, mais ajouter  une ressource à votre système (via un PUT) et ça, ben c’est du CRUD. Cette commande déclenchera l’exécution de notre traitement métier « complexe » de manière « Atomic » et « Asynchrone » (Toi qui es perspicace tu auras reconnu l’objet bancaire Transaction )

Ceci permet d’avoir entre autre une interface réactive, car l’envoie d’une commande dans une  queue est d’une complexité constante.

Ha oui mais du coup, quand on va requêter pour savoir combien il y a sur le compte B il va falloir parcourir toutes les transactions ! (Gérard est fier de sa perspicacité)

Biensûr que non !! La solution est dans le chapitre en dessous avec CQRS, on va séparer le modèle métier d’écriture et le modèle métier de lecture et pré-calculer, dé-normaliser pour être efficace autant en écriture qu’en lecture.

Pour aller plus loin : Implementing REST

CQRS

Le lien fort entre CQRS  et la WOA, c’est le CRUD, une architecture CQRS est une architecture à base de commande, comme en WOA, l’idée est de créer des commandes plutôt que de modifier plusieurs entités du modèle. Cela revient donc à faire du CRUD, comme en WOA.

Une architecture CQRS  (Command Query Responsabilty Segragation) sépare le modèle d’écriture du modèle de lecture  ce qui va permettre :

• De ne pas fetcher d’informations inutiles (On n’a pas besoin du nom du client B pour calculer le solde du client A …) Qui n’a jamais du fetcher des informations inutiles parce que le modèle est unique pour toute l’application ?
• De pré-calculer de manière asynchrone toutes les opérations fortement demandées pour s’approcher d’une complexité constante ( ou linéaire, mais sur un nombre réduit d’éléments).

Bien, se dit Gérard, mais si je suis asynchrone, je ne vais pas voir tout de suite le résultat de ma transaction sur mon compte ! C’est vrai. Mais ce n’est pas grave il faut être « relax », Habid appelle ça la « relaxation temporelle ».

Pour aller plus loin :

• CQRS by Martin Fowler
• Le slides de Jérémie Chassaing (CQRS)

Le mot de la fin

Maintenant qu’on ne fait que du CRUD, du Stateless et de l’asynchrone, cela permet de découper facilement nos applications en plusieurs petites applications ou API qui ne traitent que d’une seule problématique, réduisant encore la complexité du système d’information. Les applications web « finales » agrègent ensuite ces  API pour présenter quelque chose de « complet » à l’utilisateur final. Évidement ces APIs simples et « unitaires » sont réutilisables par autant d’applicatifs finaux que nécessaires, permettant ainsi une ré-utilisatibilité et une interopérabilité maximale.

Appelez ça comme vous voulez, WOA, REST, CQRS, HTTP, Web. L’avenir est dans la simplicité du CRUD, l’asynchrone et le Stateless.  C’est aussi l’avis de Gérard. Est-ce le vôtre ?

Yeah ! Maintenant que Gérard a son business plan qui roule, qu’il a mis en ligne un premier prototype et que les premiers clients commencent à taper au portillon, il est temps de passer à la vitesse supérieure : Créer sa société.

A Devoxx un quickie à particulièrement attiré mon attention : Celui de Andrew Spencer sur son idée de faire une SSII Coopérative. Ce qui est marrant c’est que c’est ce que nous avons fait depuis quelques mois en créant Lateral-Thoughts.

Pourquoi une SSII coopérative ?

Appliquons le « Lean Canvas » et répondons à quelques questions :

• Problem: En SSII il n’y a pas d’argent, pas de fun et pas de liberté, l’innovation n’est pas encouragée.
• Solution: Faisons une SSII qui donne de l’argent (tous actionnaires) du timeoff pour le fun et l’innovation et de la liberté d’action (management plat).
• Key metrics : Salaires moyen (Argent), Satisfaction des membres (Fun et Liberté)
• Uniq Value Proposition : Une bande de développeurs passionnés et auto-organisés qui s’éclatent à faire en codant et en apprenant ensemble.
• Unfair advantage: On s’en fout, copiez nous, ça nous fera plaisir. D’un point de vue business : Nos réseaux, notre toile « unique »
• Channels: Les réseaux de nos membres, leur rayonnance. Ce blog et d’autres ^^
• Customer segments: Les PME, grands comptes et startups.
• Cost Structure: Quasiment rien, un comptable à 1000€ / an. Pas de locaux. Pas de commerciaux. Pas de managers. Pas de boss.
• Revenue Streams: Prestations, Formations, Editions de solutions logicielles.

Il s’agit du canvas pour Lateral Thoughts mais vous pouvez tout à fait imaginer votre propre SSII coopérative pour répondre à une autre problématique. L’exemple du réseau libre-entreprise en est un autre.

Et pour ma startup ?

Les startupeurs sont des gens innovants. Le problème c’est qu’une fois que le produit est devenu « Legacy » où passe l’innovation ? Généralement on revend la structure et on part créer autre chose. Sauf qu’il n’est pas aisé de réussir à chaque fois, surtout lorsqu’on a qu’un seul cerveau. Pourquoi ne pas mettre en place dès le départ dans sa société une organisation qui permettra à l’innovation d’émerger et ce, de manière durable ? Certains l’ont très bien réussi, je pense à W.L. Gore, Whole Foods ou Google. Il suffit de copier, tous leurs secret sont expliqués dans ce livre : The Future of Management

La clé du management du futur et de passer par des sociétés coopératives, le modèle le plus connu est celui de la sociocratie que je résume en quelques points ici :

• Une personne = une voix
• Transparence totale (même et surtout du compte bancaire)
• Décision prise par consensus (tout le monde, à défaut d’être d’accord doit consentir pour qu’une décision soit prise)

Ce type de société à un coût, car une décision prise par consensus prend du temps alors qu’en société standard, le patron prend les décisions le matin seul dans sa douche. Mais le jeu en vaut la chandelle. Les membre d’une telle société donnent le meilleur d’eux-mêmes, ils se sentent investis, ils se sentent d’une même famille avec un but commun, mais aussi des objectifs individuels (qui ne vont pas contre les objectifs collectifs). La transparence fait que chacun a conscience de l’objectif de l’entreprise, de son business. Et chacun en est responsable.

Alors maintenant, qu’allez-vous faire ? Allez-vous continuez à subir ou allez-vous prendre votre vie en main (en intégrant une société coopérative) ?

En bon petit développeur Java, Gérard garde sa petite idée pour lui, développe la nuit et pendant ses congés pour finalement sortir de l’ombre et mettre en ligne THE application (pour l’instant hébergée directement sur son ordinateur personnel)

Et là, vous connaissez la suite, ça fait psssiiichhhhhttt. L’idée n’est pas trop mal mais :

• Elle n’atteint pas exactement la cible
• Il n’existe aucun vecteur pour que le client soit informé du produit
• Gérard n’a pas prévu de façon de gagner de l’argent
• Finalement, l’heure de gloire arrive enfin, un groupe de chinois tombe sur son site et  le copie en deux jours… (c’était bien la peine de l’avoir gardé secrète ton idée Gérard ! )

Ce que nous apprend Camille Roux lors de son talk à Devoxx (et sur  slideshare) c’est qu’une idée n’a pas de valeur, tout le monde à des idées. Ce qui a de la valeur c’est sa réalisation. Il nous raconte que lors d’un startup week-end, il s’est retrouvé avec six profils « business ». Six business-men qui ne savent pas coder, mais comment allait il pouvoir les occuper ?

Et là surprise, il existe un autre monde, un monde qui n’est pas le monde du développement et qui a aussi des méthodes et des outils qui ont fait leurs preuves.

Lean Canvas

Camille nous présente l’un de ces outils : le « Lean Canvas » et conseil que tous les voyants soient au vert avant de commencer le développement du produit.

• Problem : Quels problèmes résolvez vous ? Moins vous en résolvez, mieux c’est.
• Solution : Quelles solutions apportez vous ? Moins vous en apportez, mieux c’est.
• Key Metrics : Quels seront les indicateurs qui vont vous permettre de valider le succès de votre idée ? (Ex : le nombre de visites, d’utilisateurs ou de produits vendus)
• Unique Value Proposition : Qu’est-ce que vous apportez que les concurrents n’apportent pas ?
• Unfair advantage : Pourquoi on ne pourra pas vous copier facilement (Ex : une image de marque)
• Customer segments : Votre cible (Ex : La gamine de 13 ans avec un forfait bloqué à dépenser)
• Channels : Comment allez-vous atteindre votre cible ? (Ex : j’ai déjà un site qui fait 10 000 visites de ma cible par jour)

Pour remplir le tableau n’hésitez pas à parler de votre idée à vos amis, votre famille, au barman du coin ou évidemment à des représentant de votre cible. Une fois que tous les indicateurs sont au vert, vous vous rendrez compte que votre idée initiale n’est pas tout à fait la même qu’au départ, elle est largement meilleure.

Ce qui est marrant c’est que je me suis exercé à cette technique sur plusieurs types de projets et à chaque fois cela m’a apporté quelque chose. Même sur un projet open-source, même sur un projet d’entreprise de type « service ».

Pour aller plus loin :

• Running Lean: Iterate from Plan A to a Plan That Works
• Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers

Tester son idée

Maintenant que l’idée de Gérard a été retravaillée, il est temps de commencer à coder ! Enfin presque, pour tester une idée, un prototype c’est bien, mais il existe d’autres façons :

• Le questionnaire: Faites en un ! Pour savoir notamment si quelqu’un serait prêt à payer pour telle ou telle fonctionnalité. Ainsi vous pourrez démarrer avec la fonctionnalité qui a le plus de valeur et peut-être même avec déjà des clients !
• Sortez ! C’est en sortant, en allant voir vos futurs utilisateurs que vous aurez de nouvelles idées d’améliorations de votre produit,  en voyant comment ils travaillent et quels sont leurs problèmes.
• Un article de blog: Si je blogue sur mon idée et que ça buzze, c’est que je suis certainement sur la bonne voie. C’est aussi une façon d’obtenir du feedback.
• Le prototype : Enfin ! Nous allons coder. Mais là encore il s’agit de tester une idée, n’allons donc pas perdre de temps à faire une architecture scalable du feu de dieu, le truc c’est de développer vite mais aussi de développer quelque chose d’agréable à voir. N’hésitez pas à recruter votre pote designer à cette étape là, sinon vous pouvez utiliser Twitter bootstap ou acheter un CSS sur themeforest (c’est ce que j’ai fait pour buildwall.com ). Camille est un développeur Ruby, il nous explique que pour développer une page de type CRUD, il ne faut pas y passer plus de 15min… En Java on ira jeter un oeil à Spring Roo ou Play! framework

Et maintenant, qu’allez-vous faire de vos idées (et de votre vie)  ?

1. L’hydre

Hydra est une entité qui a la particularité de contenir une liste immuable de tête (heads.)

@Entity
public class Hydra {
  private Long id;
  private List heads = new ArrayList();
  @Id @GeneratedValue
  public Long getId() {...}
  protected void setId() {...}
  @OneToMany(cascade=CascadeType.ALL)
  public List getHeads() {
    return Collections.unmodifiableList(heads);
  }
  protected void setHeads(List heads) {...}
}
// creates and persists the hydra with 3 heads
// new EntityManager and new transaction
Hydra found = em.find(Hydra.class, hydra.getId());

La question est la suivante, combien d’appel sont fait en base de données lors de  la deuxième transaction (créer lors de em.find).

(a) 1 select
(b) 2 selects
(c) 1+3 selects
(d) 2 selects, 1 delete, 3
inserts
(e) None of the above

Pendant la recherche, em.find entraine un unique select en base de donnée sur l’hydre.
Pendant le commit qui est effectué à la fin de la transaction, hibernate vérifie que la collection n’est pas dirty, c’est à dire que les objets devraient être recréés en comparant les références objects des listes. Un deuxième select est alors effectué sur les têtes. Dans notre cas, les références ne correspondant pas, l’ensemble de la liste est alors recréé, ce qui explique le delete et les 3 inserts.

Contrairement à ce que l’on pourrait penser dans un premier temps, la bonne réponse est donc la réponse d.

Il faut donc être bien conscient que si on a un objet qui contient une collection et qui porte la liaison, si on affecte  une nouvelle liste à l’élément, la collection est recrée entièrement : un delete et n insertions d’éléments. On peut rencontrer également ce genre de problème si on utilise des outils qui suppriment les proxies hibernate sur les objets.

En régle générale, il vaut mieux travailler directement avec les collections retournées par hibernate à moins de savoir ce que l’on fait.

@Entity
public class Developer {
  @Id @GeneratedValue
  private Long id;
  private String mainTechnology;
  public boolean likesMainTechnology() {
    return "hibernate".equalsIgnoreCase(mainTechnology);
  }
}

// creates and persists a developer that uses hibernate as mainTechnology
// new EntityManager and new transaction
Developer dev = em.find(Developer.class, id);
boolean foundCoolStuff = false;
for (String tech : new String[]{"HTML5", "Android", "Scala"}) {
  dev.setMainTechnology(tech);
// othersAreUsingIt entraine select count(*) from Developer where mainTechnology = ? and id != ?
  if (othersAreUsingIt(tech, dev) && dev.likesMainTechnology()) {
    foundCoolStuff = true; break;
  }
}
if (!foundCoolStuff) {
// still use hibernate
  dev.setMainTechnology("hibernate");
}

(a) 2 selects
(b) 4 selects
(c) 4 selects, 1 update
(d) 4 selects, 4 inserts
(e) None of the above

La bonne réponse est la réponse d, 4 selects et 4 inserts. En effet, hibernate doit garantir la bonne valeur des requêtes exécutées et parfois doit effectuer une flush pendant une transaction. Si on n’effectue plus l’appel à othersAreUsingIt (qui entraine un select sur la table Developer), il n’y a plus d’update.

List semantics

@Entity
public class Forest {
  @Id @GeneratedValue
  private Long id;
  @OneToMany
  Collection<Tree> trees = new HashSet<Tree>();
  public void plantTree(Tree tree) {
    trees.add(tree);
  }
}
// creates and persists a forest with 10.000 trees

// new EntityManager and new transaction
Tree tree = new Tree(“oak”);
em.persist(tree);
Forest forest = em.find(Forest.class, id);
forest.plantTree(tree);

(a) 1 select, 2 inserts
(b) 2 selects, 2 inserts
(c) 2 selects, 1 delete,
10.000+2 inserts
(d) Even more

La bonne réponse est la réponse c. La combinaison de l’annotation OneToMany et d’une collection entraine un bag semantic. La collection est donc recrée.

@OneToMany with no cascade options
La première intuition est de remplacer le Set par une List (List<Tree> trees = new ArrayList<Tree>() ). Néanmoins, cela marche exactement de la même manière.
Le seul moyen de ne pas avoir de bag semantic est d’utiliser orderColumn ou indexColumn

Il faut faire attention à choisir une collection appropriée sur la partie qui contient  la liaison. Ainsi dans notre cas, Set<Tree> trees = new HashSet<Tree>() permet d’éviter toutes les insertions parasites.

Utilisation d’un set sur l’object qui ne contient pas la liaison.

@Entity
public class Forest {
  @Id @GeneratedValue
  private Long id;
  @OneToMany (mappedBy = “forest”)
  Collection<Tree> trees = new HashSet<Tree>();
  public void plantTree(Tree tree) {
    trees.add(tree);
  }
}
@Entity
public class Tree {
  @Id @GeneratedValue
  private Long id;
  private String name;
  @ManyToOne
  Forest forest;
  public void setForest(Forest forest) {
    this.forest = forest;
     this.forest.plantTree(this);
  }
}

// creates and persists a forest with 10.000 trees
// new EntityManager and new transaction
em.remove(forest);

L’appel à em.remove entraine java.sql.BatchUpdateException : cannot delete or update a parent row : a foreign key constraint fails.

Si on garde le modèle, la seule solution est de parcourir l’ensemble des arbres de la forêt et de setter leur forêt à null.
Il est ensuite possible de supprimer la foret. Ce qui entraine 10 000 updates et 1 delete …
D’autres types de collections auraient été plus adéquats.

Il existe beaucoup d’autres anti-patterns. Pour les débusquer dans votre code, il est plus que recommander d’observer attentivement les requêtes ! Les slides sont ici : http://www.yonita.com/2011_11_16_PERFORMANCE_ANTIPATTERNS_DEVOXX.pdf

La troisième journée est assez différente des deux précédentes. Le planning des journées change. Le matin, plus de session de 3 heures mais une Keynote de deux heures suivie par une conférence d’une heure.

Après un rappel de quelques chiffres (2500+participants, 56 jugs …),  Stephan Janssen, l’organisateur de Devoxx nous présente la prochaine version de parleys.com . Parleys.com permet de voir de chez soi l’ensemble des conférences de devoxx mais également d’autres évènements, comme par exemple certaines présentations des différents JUG. Le service est également proposé aux entreprises pour héberger leurs vidéos. Outre cette nouvelle version, les présentations de devoxx 2009 sont déjà arrivées en grand nombre,  les versions gratuites des conférences seront disponibles au compte goutte tout au long de l’année. Toutes les conférences seront disponibles gratuitement  à la fin 2010. A noter qu’il est possible de télécharger les présentations sur son PC très facilement avec ce site et de les revoir à volonté.

Oracle

Le deuxième sujet est une présentation d’Oracle. J’avoue avoir envisagé quelque chose de plus grand, mais l’acquisition de Sun par Oracle n’étant pas finalisé, il n’y aura rien de croustillant de ce côté là. On a le droit à la place d’une démo du moteur de module dynamique de Weblogic.

Sun

La présentation de Sun a été plus intéressante. Outre le fait que la final release sortira le 10 décembre 2009, une belle démo, bien rodée, a pu démontrer la puissance de JEE6. Création d’une Servlet, intéraction avec EJB et ensuite avec un service OSGi. La simplicité de l’ensemble est vraiment à remarquer, aucun plantage lors de la démo. Certaines fonctionnalités de Glassfish V3 notamment le rechargement à chaud … sans perte de session a vraiment eu un impact chez tous ceux qui auront essayés de debugger un problème liée à une session.

Flash Catalyst

La dernière présentation fut celle d’Adobe. Une démonstration de Flash Catalyst et son intégration avec les différents outils Adobe très bien ficelée, avec un vrai show des deux présentateurs. La puissance de Flash Catalyst et son intégration avec la suite Adobe donnent une réelle impression de simplicité, que ce soit pour mapper deux vues, pour modifier un bouton, pour permettre d’envoyer le code vers Flash Builder, qui est plus à destination des développeurs. A voir ce que cela donne dans la réalité.

JDK 7 Update

Place ensuite à JDK7 update. Les plus grandes nouveautés sont le project Jigsaw, qui permet une grande modularité de la jdk, avec la possibilité de n’embarquer que les librairies utiles à notre application. Le project coin qui regroupe quelques évolutions du langage :

L’apparition de l’opérateur diamond qui nous permet d’écrire :

Map<String,String> myMap  = new Hashmap<>();

Il sera également plus simple de construire des collections sans avoir des myList.add(…) à la chaine, la solution implémentée aura une syntaxe proche de celle des tableaux. D’autres nouveautés, comme la possibilité de faire un switch sur des String ou l’apparition  de closures (simples). Un point à également été clarifié sur la différence entre Java SE et le jdk, le Java SE représentant la spécification, le jdk7 l’implémentation. A noter que bien qu’il y ait un open jdk 7, il n’y a pas de Java SE 7.

Comet

Jean-Francois Arcand présente ensuite le framework Atmosphère qui permet de pousser un message du serveur vers le client.
Il existe trois types de méthodes pour pousser ce message :

• Le Polling
• Le long Polling
• Http Streaming, souvent utilisé dans les jeux mais qui devient compliqué dans certaines situations.

Atmosphère se veut un framework simple, basée essentiellement sur des pojos et disponibles sur de nombreux serveurs (de tomcat à google app engine) et supporte certains frameworks de présentations (GWT/Wicket). La démo, très simple, se déroule bien. Encore une fois, il faut voir ce que cela donne dans la réalité de nos environnements.

Distributed programming the google way

Gregor Hohpes présente ensuite une conférence d’une heure sur « Distributed programming the google way ». Cette conférence se révèle être une des plus intéressantes conférences de Devoxx. Il détaille le fonctionnement de BigTable, de MapReduce, de Sawzall et de Google File System au travers de 8 recommandations :

• Utilisez la fragmentation, ne pas hésiter à partionner les données.
• Rester simple et n’implémentez que les fonctions de base
• S’attendre à  l’échec
• Faites des processus autonome, pouvant poursuivre sans supervision
• Le runtime est le plus important. Mieux vaut une circulation fluide à des règles très strictes.
• Préférer la vitesse à la précision. Plus c’est rapide, mieux c’est.
• Privilégier tout ce qui est sans état. Les processes qui conservent un état sont plus couteux que les opérations sans états
• Tout est affaire de compromis

L’importance de ces 8 règles permettent d’avoir une bonne scalabilité. Il n’est souvent pas nécessaire de produire toutes les fonctions possibles pour avoir un outil scalable. Ainsi, les différents outils présentés ont chacun leurs limites :  par exemple, Sawzall permet de faire des aggrégations extrêmement rapide mais ne permet pas de faire de traiter la duplication.

Les deux BOFs auquel j’ai assisté de la soirée n’ont pas été interessante du tout. Trop de monde, impossible à entendre.

Première partie de la journée

La deuxième journée est la dernière journée de la partie université de Devoxx. La partie université à la particularité de présenter deux slots de 3 heures de conférence sur un unique sujet, un le matin et l’autre après midi.

JEE6

La journée débute par une présentation sur JEE 6 par Antonio Goncalvez et Alexis Moussine-Pouchkine. Bien ficelée, la présentation passe en revue l’ensemble des nouveautés. Beaucoup de démos rendent la présentation plus concrète, les mise à jour/nouveautés de la spécification sont bien détaillées. Une présentation un peu plus ‘pratique’ ( Qu’est ce qui ne va pas et qu’il faut revoir ? que conseillez vous ?) aurait pu également être interessant, heureusement que la BoF du soir (Why you should care about JEE6) a répondu en parti à cette problèmatique .

Google App Engine

La deuxième moitié de la présentation Google App Engine a porté sur des questions très pratiques. En ce qui concerne l’interaction avec les données, JDO est preferé à JPA. Tout simplement du aux constraintes de BigTable qui est le système de gestion de données de Google sur App Engine. JDO bien que décrié est remis au gout du jour, JPA n’étant pas totalement disponible sur GAE du à l’utilisation de BigTable, le type de système ‘NoSQL’ de Google qui ne gère que les one-to-many et pas les many-to-many.
Un autre point important, à l’autre bout de la chaine est l’intégration avec GAE de certains framework de présentation (Spring MVC / GWT / JSF 2). En ce qui concerne JSF2, l’intégration se révèle être la plus hardue. En effet, les problèmes sont nombreux (problème avec la sauvegarde d’état, avec les beans de scope session et application (uniquement request code and view code), l’ensemble des états doit être sérialisable, le component binding n’est pas possible pour la raison précédente. GWT se révèle plus facile mais ce qui est réellement conseillé, si l’on recherche quelque chose de pratique est l’utilisation de Spring MVC.

Pour développer l’interface utilisateur de l’application de démo, il a fallu environ 3 jours avec Spring MVC, 2 semaines avec GWT et énormément avec JSF. D’autres frameworks ne sont pas disponibles Rich Faces and Ice Faces par exemple. Pour savoir si une librairie est supportée totalement, partiellement ou non supportée, il suffit de chercher la page ‘Will it play on app engine’ où beaucoup de frameworks/librairies sont référencées, avec leurs limites.

SOA

La session de l’après midi était sur SOA(Service Oriented Architecture), avec une approche assez théorique. C’est un paradigme, une manière de concevoir les choses. L’objectif de SOA est de découper les fonctionnalités complexes en un ensemble de fonction simple, les services. Un des points de la présentation à montrer que chaque choix avait un coût, notamment la manière de coupler faiblement les données mais également d’utiliser un ESB. Il faut compter un ou deux ans avant de réellement avoir une architecture SOA, et bien sûr, commencer par un projet non critique, puis un deuxième, refactorer, ajouter un troisième, refactorer. Le refactoring est une composante essentielle : SOA ne s’achète pas, c’est une philosophie qui se crée sur le long terme et, parceque c’est du long terme, elle nécessite un investissement politique de l’entreprise.

Java-monitor & TeamCity

La première présentation sur l’outil java-monitor a montré des cas spécifiques de problèmes (java heap space, impossible d’allouer la mémoire pour lancer le thread …). Cette présentation très synthétique a permis de mettre en évidence quelques mauvaises pratiques : utilisation de System.gc(), une mauvaise configuration du garbage. Il existe une démo en live des possibilités de l’outil.
TeamCity est un outil d’intégration continue. La présentation était constituée essentiellement d’une démo. Quelques fonctionnalités à retenir : possibilité de déclarer plusieurs agents, par exemple en fonction des OS, bonne intégration avec les IDEs existants, possibilité de prendre la responsabilité d’un échec de build ou d’affecter la responsabilité à un membre de l’équipe, de garder un build propre en permanence (test de la construction du build avant le commit). Néanmoins, la présentation n’a pas montré un outil si simple que ca à manipuler. Un but de TeamCity semble être également d’avoir une place dans les outils qui permettent de monitorer la qualité du code (couverture de code avec Emma, d’autres métriques, la possibilité de voir des mauvaises pratiques) mais encore peut finaliser (pas encore possible apparement de pouvoir modifier les règles sans IntellijJ IDEA).

Les BoF

La première, Why I should carry about java EE6 a pu réunir une belle équipe de speakers. Les questions posées ont amené certaines bonnes pratiques à être définie, comme utiliser les @ManagedBean principalement avec CDI mais les approches JSR/JCP ont également était approchée. La prochaine session du Paris Jug aura j’espère l’occasion de développer encore plus le sujet.

Pour conclure, l’ensemble des présentations seront disponible prochainenment sur le site http://parleys.com/ pour une abonnement de 49€. Ce qui est une très bonne affaire !

Qu’est ce que c’est ?

C’est 5 jours de conférences, principalement orientés java à Anvers en Belgique.  La réception des devoxians à lieu au Metropolis, une salle de cinéma dans la banlieue d’Anvers, à environ 20 min de la gare centrale en tramway. Après avoir récupéré nos badges, on nous fournit un sac de goodies (sac/stylo/bloc note/Tee shirt).

Kanban

La première conférence à laquelle j’ai assisté sur Kanban a duré 3 heures. Kanban est une méthode agile avec un fonctionnement plus simple que Scrum, dans le sens où elle est beaucoup moins contraignante. C’est une méthode avec une forte composante visuel où un radiateur d’information constitue un point central de la méthode. Ses trois principes sont la confiance, l’esprit d’équipe et la transparence. Il n’y a pas de notions de sprint ou d’itération . Les demandes arrivent en permanence et sont traitées au fur et à mesure.

JSF

La deuxième conférence sur JSF 2 était assez pointue, organisée en 3 parties : une heure sur la vue, une heure sur le controleur, une heure sur le modèle. L’aspect orientation composant au lieu de contenu comme c’est le cas avec JSP est assez interessant. L’inconvénient de JSF 1.2 était la quantité très importantes d’XML, JSF 2.0 passe aux annotations, ce qui la rend beaucoup plus simple à manipuler. D’autres améliorations : pouvoir passer des paramètres en GET (sans commentaire), gérer des bookmarkables URLs …
Un des points qui a été souvent abordé lors de la présentation est le futur de JSF. Par exemple, le fait d’avoir une API standard pour AJAX mais également les points bloquants (certaines lourdeurs de configurations). J’ai beaucoup aimé la franchise de Peter, qui a bien montré ce que l’on peut faire et ce qui peut être améliorer.

Hadès & NoSQL

Place ensuite à 2 petites présentations qui m’ont laissé sur ma faim. En une quarantaine de minutes, difficile de rentrer dans un sujet technique, tout au moins d’en montrer ses limites.
Une présentation scolaire mais malgrès tout intéressante d’Hades, qui permet de simplifier l’utilisation de JPa n’a cependant pas montré les cas limites d’utilisation.
De même, la présentation NoSQL n’est pas rentrée assez dans les détails pour que cela deviennent vraiment interessant.

Et le meilleur pour la fin

De 19h à 22h, place à 3 BoFs : Une session très intéressante sur le NoSQL qui a abordé beaucoup de points, comme l’efficacité, les différents types d’outils, l’importance de choisir un système qui correspond à nos attentes. Pour choisir un bon type de base de données, il est conseillé de faire ressortir 2 priorités entre : Consistency, Partition Tolerance et Availability. Ainsi, Cassandra  par exemple,  dans le cas de serveurs distribués, va remonter la dernière information mais sans que cela ne soit garantie (choix fait sur Partition Tolerance et Availability ). L’utilisation pour les boutiques en ligne est tout indiquée (c’est le système d’Amazon). Alors que d’autres systèmes tel que HBase garantissent eux une consistance des données, ils seront plutôt utilisés dans des environnements type CMS, où ce qui est visible à l’écran doit correspondre aux dernières données.

Sur JSF2, la BoF est venu compléter la présentation de l’après midi.

La BoF d’hibernate a été assez intéressante. Une présentation assez longue de l’API Criteria (qui n’est pas très sexy au premier abord) ne m’a pas vraiment fait changé d’avis mais néanmoins, le fait que le meta-modèle soit généré automatiquement par l’IDE simplement est quand même important. Le principal intêret de cet specification est le fait que cela soit typé, néanmoins, peut être parceque je ne suis plus habituée à utiliser un ORM (JDBC pur), je trouve cela très (trop) verbeux. Cet aspect verbeux provient du fait que l’API critéria est très puissante et supporte énormément de choses. On peut l’imaginer encapsulée dans un framework plus simple pour ne retenir que les choses ‘utiles’ à son projet dans une forme verbeuse plus simple.

Et voilà le bilan de cette première journée. D’autre articles arriveront sous peu !