Tag Archives: java

Le meilleur code

est celui dont on peut se passer

J’aime bien cette citation

“Le meilleur code est celui dont on peut se passer.”
Le type qui va maintenir votre code

C’est la clé d’une réalité difficile à accepter et encore plus à prouver : un bon développeur peut être 100 fois plus productif qu’un mauvais.

Dans l’évolution d’un programmer python:

Le débutant écrit une implémentation naïve,
Celui qui connait le langage résout le problème en une ligne simple,
L’expert utilise tout simplement une librairie déjà existante.

Mais il manque un type de développeur: celui qui trouve la solution pour ne pas avoir à écrire ce code.

Illustration avec le Kata du game of life

Lors du code retreat de ce week-end la 3eme itération avec piwai m’a permis de trouver une illustration simple et concrète de ce précepte. (PRO tip: le pair programming est un moyen pour fabriquer des développeurs 10 fois plus productif à partir de deux développeurs normaux)
Le kata classique d’une code retreat est le game of life, la spec tien en 4 règles:

Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Chaque itération dure 45min, en pratique il est difficile de finir dans ce temps, ce qui tombe bien car le but d’un kata n’est pas de finir mais d’expérimenter librement. Dans une approche TDD naïve on va commencer par implémenter un test permettant de valider la première règle, puis implémenter le code permettant qui permet de faire passer le test.

Mais TDD ne veut pas pire pas de conception, bien au contraire, la première question à se poser est qu’est qu’on doit tester?

Dans le cas du game of life on réalise très vite qu’on à besoin de stocker l’état des cellules dans 2 structures, une pour la génération actuelle, une autre pour la suivante. Si l’on démarre toujours la génération suivante par une structure vide que l’on va remplir en parcourant la structure actuelle il n’est pas nécessaire d’identifier les cellules à tuer: elles sont déjà toutes mortes dans la prochaine génération. Ce qui permet de ne pas se soucier de 2 règles sur 4.

Ainsi

Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Devient

All cell are dead in the next generation
Any live cell with two or three live neighbours lives on to the next generation.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

La complexité du problème a été divisée par deux…

En partant sur ces bases on a pu finir de manière relativement élégante en 30 min.

package gol; import java.util.ArrayList; import java.util.HashSet; import java.util.List; import java.util.Set; public class World { Set<String> world = new HashSet<String>(); public void addLiveCell(int x, int y) { world.add(getkey(x, y)); } private String getkey(int x, int y) { return x + ":" + y; } private int getX(String key) { return Integer.valueOf(key.split(":")[0]); } private int getY(String key) { return Integer.valueOf(key.split(":")[1]); } public int getNumberOfNeighbour(int x, int y) { int numberOfNb = 0; List<String> neighbour = getNeighbour(x,y); for (String key : neighbour) { if (world.contains(key)) { numberOfNb++; } } return numberOfNb; } public int getNumberOfNeighbour(String key) { return getNumberOfNeighbour(getX(key), getY(key)); } private List<String> getNeighbour(String key) { return getNeighbour(getX(key), getY(key)); } private java.util.List<String> getNeighbour(int x, int y) { List<String> nb = new ArrayList<String>(); nb.add(getkey(x-1, y-1)); nb.add(getkey(x-1, y)); nb.add(getkey(x-1, y+1)); nb.add(getkey(x, y-1)); nb.add(getkey(x, y+1)); nb.add(getkey(x+1, y-1)); nb.add(getkey(x+1, y)); nb.add(getkey(x+1, y+1)); return nb; } public void tick() { Set<String> newWorld = new HashSet<String>(); Set<String> neighbourCells = new HashSet<String>(); for(String key : world) { if (ifThreeOrTwoNeighbour(key)) { newWorld.add(key); } neighbourCells.addAll(getNeighbour(key)); } for(String key : neighbourCells) { if (ifThreeNeighbour(key)) { newWorld.add(key); } } world = newWorld; } private boolean ifThreeOrTwoNeighbour(String key) { int numberOfNeighbour = getNumberOfNeighbour(key); return numberOfNeighbour == 3 || numberOfNeighbour == 2; } private boolean ifThreeNeighbour(String key) { int numberOfNeighbour = getNumberOfNeighbour(key); return numberOfNeighbour == 3; } public boolean isAlive(int x, int y) { return world.contains(getkey(x, y)); } }

Github, Cloudbees, Feature Flags

Quand les enfants ne sont pas là le geek code 😉

Mettre en oeuvre un processus d’intégration continue peut se faire rapidement, avoir une suite de test unitaire couvrant de manière satisfaisante son code est une autre histoire… Particulièrement sur un “code legacy” (qui a été écrit sans test unitaire) , trop souvent les bugs sont découvert en production par les utilisateurs finaux. Il faut alors revenir en arrière, reproduire et corriger le bug dans un environnement et re-livrer plus tard, sans parler d’une éventuelle reprise des données qui auraient été corrompues. Oui il y a du vécu.

Une technique pour réduire les effets néfastes d’un bug en production est de déployer progressivement à des populations restreintes les nouveautés. Pour cela il faut séparer la livraison du code de l’activation des fonctionnalités qu’il contient.

Un simple if/else peut suffire, on parle de feature flags chez Flikr.

if (newStuffIsOn) {
	doIt
} else {
	doNot
}

Voilà donc ce que j’ai codé ce week-end… Bon un peu plus en fait. Car il faut un moyen propre et élégant de gérer, d’activer et de désactiver ces flags en production.

Voici donc Feature Flags

L’idée est de gérer les flags dans un enum:

public enum Flags implements FeatureFlags {
    ONE("First Feature Flag"),
    TWO("Second Feature Flag", FlagState.UP),
    THREE("Third Feature Flag");
}

if (ONE.isUp()) {
	doIt
} else {
	doNot
}

Feature Flags génére dynamiquement à partir de l’enum une page html pour activer désactiver ces flags en live, mais aussi une interface RESTful pour les manipuler comme on souhaite.

RESTful

GET http://yourhost.net/flags/ONE pour connaitre l'état
POST http://yourhost.net/flags/ONE pour inverser l'état
PUT http://yourhost.net/flags/ONE avec UP ou DOWN en contenu pour forcer l'état d'un flag

Rien de fantastique que ce soit fonctionnellement ou au niveau du code mais il s’agissait aussi d’un pretexte pour me mettre à git et github

GitHub

Quelle claque. J’ai mis du temps à comprendre pourquoi Linus disait que svn ne marchait pas par conception, après tout ça a marché pour moi pendant des années. Git est clairement le bon concept. La preuve: github, il n’existera jamais de svnhub, avec github nous sommes tous à un click de pouvoir contribuer à des milliers de projets open source. D’ici quelques années github aura produit un impact majeur sur la croissance et la vitalité de l’open source. En fait c’est déjà le cas, mais j’ai la conviction que l’on a encore rien vu. Un peu comme les moteurs de blogs ont déclenché la vague web 2.0 du web participatif. On peut parler d’open source 2.0.

Cloudbees

Deuxième claque. Le projet Feature Flags contient une webapp de démo, le plus simple pour montrer ce que fait Feature Flags est encore une démo (vous allez pouvoir découvrir mes talents de designer web, please fork it ! du html là aussi). Mais héberger un war java sur Internet a toujours été un problème. Les différents clouds publiques apportent des solutions. Avec cloudbees déployer du code java est presque aussi simple qu’uploader une appli php. Il s’est écoulé une petite 1/2heure entre le moment où j’ai décidé de m’inscrire à Cloudbees et le moment où mon application était live, le plus long a été de lire un peu la doc. Petite déception, il n’est pas possible n’était pas possible hier de déployer directement un war généré dans le jenkins de DEV@cloud vers le tomcat RUN@cloud.

Age d’or du développeur

Ajouter à ça le mobile (android), html 5, l’adoption des méthodes agiles, le développement vit un nouvel age d’or.

Sites pour geek java

A découvrir, deux nouveaux sites dédiés aux geek java:

– Le service de Julien Dubois (ex Spring source): responcia, futur forum de référence pour les questions de dev pointues ? Le service payant à destination des entreprises qui est derrière me semble une très bonne idée.

– Le service du touilleur qu’on ne présente plus: express-board, c’est peut-être là que vous allez trouver votre futur job ?

Deux beaux exemples que les devs en java peuvent être très productifs (autant que du Ruby on rails?)

Mon dieu !

Oracle rachète sun

Heureusement que java est devenu open source l’an dernier. Tout ce que Oracle rachète Oracle tue.

On va peut-être enfin avoir un driver jdbc pour Oracle potable?

Quel nom pour le fork de Mysql?

Dommage pour Glassfish…

En tout cas c’est un sacré crash test pour la vitalité des technos open source.

JavaFx

Vous connaissez java, le langage objet, fortement typé, compilé, fait par sun.

Vous connaissez javascript le langage de script dynamique, faiblement typé, supportant la programmation fonctionnelle (une fonction est un elle même un objet) fait par netscape et sun.

Vous savez que javascript n’a rien à voir avec java.

Dites bonjour à javaFx script, le langage de script dynamique, faiblement typé, supportant la programmation fonctionnelle fait par sun et construit au dessus de java !

Javascript n’est pas un langage de script pour java, javaFx script est un langage de script pour java… Simple non ?

Question subsidiaire: pourquoi Sun n’a t-il pas fait javaFx script il y a 10 ans au lieu de supporter javascript? Dommage pour eux, entre temps Adobe Flex est Action script ont gagné leurs lettres de noblesses, même Microsoft a eu le temps de s’y mettre avec Silverlight. JavaFx la technologie née 10 ans trop tard.

Aurélien Pelletier

Web,Open source, Agile, Architecture, Innovation