La première édition de Devoxx France s’est terminée depuis quelques jours, voici donc un bref retour d’expérience ainsi que les réponses au concours que nous avions organisé.

L’organisation était au top. Les gilets rouges ont bien pris en main l’organisation globale, et malgré la jeunesse de l’évènement, aucun aléa n’est venu perturbé ces 3 journées. Les sessions étaient très variées, et certaines demandaient un niveau technique assez élevé. D’autres au contraire permettaient de découvrir des sujets qui ne sont pas forcément connus des développeurs Java comme par exemple la session d’Alexandre Bertails sur la théorie des langages.

D’un point de vue personnel, j’ai adoré cette première édition. On sentait que l’expérience de Stephan Janssen a permis à Devoxx France de paraître déjà rodé. J’ai pu assisté à de nombreuses sessions très intéressantes et enrichissantes comme celle de Pablo Lopez présentant Hadoop pour gérer les 7Go de logs produites chez son client. J’en ai malheureusement loupé d’autres. Vivement que les sessions soient sur Parleys. Devoxx a vraiment été une cure technique revigorante de part la diversité des sujets et la maîtrise technique des speakers.
D’autre part, en jouant chez divers sponsors j’ai pu gagner un Samsung Galaxy Tab et un Kindle ! Un petit bonus qui a contribué à passer un excellent moment.

Application In Fine Devoxx France

Nous avions mis à disposition des utilisateurs Android une application permettant de gérer son planning pendant les 3 jours de Devoxx France. Les retours des utilisateurs ont été très bons et peu de bugs ont été recensés.
Lors du deuxième jour, le planning a pu indiquer des salles qui ne correspondaient pas à la réalité. Ceci est en fait dû une désynchronisation entre l’application et l’API du site Devoxx. L’API REST ne renvoyait pas les bonnes salles ce qui a pu en gêner certains. Le troisième jour, tout est rentré dans l’ordre et l’API renvoyait les données exactes.

Comme nous l’avons annoncé avant Devoxx France, nous mettons en open source le code de cette application. Le code source est en licence Apache 2 et est disponible sur mon GitHub.

Cette application est censée se connecter à un serveur qui renvoie des données JSON qui ont un format spécifiques. Cette partie peut être adaptée facilement pour récupérer les données renvoyées par le serveur devoxx.

Concours In Fine avec un Mac Book Air à la clé

En tant que sponsor, nous organisions un concours de code. Le gagnant pouvait emporter un Mac Book Air. Le principe était simple : modifier 6 morceaux de code en sept minutes trente.
La difficulté venait du fait que le code était édité dans un navigateur web et pas dans un IDE ! A chaque modification de code, une compilation automatique était envoyée à un serveur permettant de valider la réponse du candidat.

Les réponses aux questions ne nécessitaient pas de connaître les API du JDK par coeur, seules le nom des classes et leur constructeur étaient utiles. Les questions et réponses sont données un peu plus loin dans ce post.

Nicolas De Loof a emporté haut la main le concours en étant le seul à donner les 6 bonnes réponses dans le temps imparti. Les autres participants n’ont pas démérité, mais le fait de coder dans un navigateur a dû en déconcerter plus d’un.

Nicolas de Loof vient de gagner le Mac Book Air. Il fete ça en présence du boss Antoine Ramponi

Questions du concours

Chaque question comprend un énoncé, une partie de code éditable par l’utilisateur ainsi que du code non éditable. Les imports se font automatiquement.

Question 1

Comment faire en sorte que myMap puisse garder l’ordre d’insertion

// Début de la partie éditable

Map<String, Integer> myMap = new HashMap<String, Integer>();

// Fin de la partie éditable
myMap.put("val2", 2);
myMap.put("val1", 1);
myMap.put("val3", 4);

Iterator<Integer> i = myMap.values().iterator();
assert(result = i.next() == 2 && i.next() == 1 && i.next() == 4);

Réponse 1

Il faut une certaine connaissance des collections Java. TreeMap n’est pas utilisable ici car il réordonne les entréés à chaque insertion.

Map<String, Integer> myMap = new LinkedHashMap<String, Integer>();

Question 2

Le test est valide lorsque myVar vaut 66666

// Début de la partie éditable

long myVar = 5432l;

// Fin de la partie éditable
myVar += 12345;
assert(myVar == 66666);

Réponse 2

Il fallait mettre un 1 au lieu du l minuscule. Cette question est une référence à Josh Bloch.

long myVar = 54321;

Question 3

Ecrivez une méthode qui calcule la factorielle d’un nombre n . Si n est négatif alors on retourne Double.NaN

// Début de la partie éditable
double fact(int n) {
    return 0;
}
// Fin de la partie éditable

Réponse 3

Faire une fonction récursive était la manière la plus évidente et la plus naturelle.

double fact(int n) {
    if (n == 0)
        return 0;
    else if (n == 1)
        return 1;
    else if (n < 0)
        return Double.NaN;
    return n * fact(n-1);
}

Question 4

Ecrivez la méthode getDayOfWeek qui prend en entrée le nombre de jour depuis le 1 Janvier 1970 ( ce jour était un jeudi ) et qui retourne le jour correspondant.

public final static int SUNDAY = 1;
public final static int MONDAY = 2;
public final static int TUESDAY = 3;
public final static int WEDNESDAY = 4;
public final static int THURSDAY = 5;
public final static int FRIDAY = 6;
public final static int SATURDAY = 7;

// Début de la partie éditable
int getDayOfWeek(int day) {
    return 0;
}
// Fin de la partie éditable

Réponse 4

Cette question probablement était probablement la plus difficile. Ceux qui ont essayé de trouver une formule qui marche sur une ligne avec un modulo ont tous échoué. D’autres ont essayé d’utiliser la classe Calendar, mais sans auto-complétion et sans connaissance de l’API ils ont échoué également. La solution la plus simple est celle ci-dessous.

int getDayOfWeek(int day) {
    int moduloDay = day % 7;
    switch(){
        case 0 : return THURSDAY;
        case 1 : return FRIDAY;
        case 2 : return SATURDAY;
        case 3 : return SUNDAY;
        case 4 : return MONDAY;
        case 5 : return TUESDAY;
        default : return WEDNESDAY;
    }
}

Question 5

Modifiez le code pour que le resultat de la soustraction soit égal à 0.9

void substract() {
// Début du code éditable

    BigDecimal a = new BigDecimal(2.00);
    BigDecimal b = new BigDecimal(1.10);

// Fin du code éditable
    assert(a.subtract(b).doubleValue() == 0.9);
}

Réponse 5

Un énoncé et une réponse simple encore une fois. Il fallait connaître les spécifités de ce constructeur. En initialisant un BigDecimal avec un double, la valeur initialisée est une valeur approchante au paramètre. En utilisant un paramètre de type String, alors c’est la valeur exacte qui est utilisée.

    BigDecimal a = new BigDecimal("2.00");
    BigDecimal b = new BigDecimal("1.10");

Question 6

Comment accède-t’on dans la méthode getSuperVal à l’attribut val de la classe B ?

class B {

    int val = 2;
    A a = new A();

    class A {
        final public int val = 3;

        int getSuperVal() {
            // Début du code éditable
            return ;
            // Fin du code éditable

        }
    }
}

Réponse 6

Syntaxe peu utilisée, mais encore une fois cette réponse était simple à donner dans un navigateur sans auto-complétion.

return B.this.val;

Question 7

NB : Cette question a remplacé la question le dernier jour de Devoxx France.
Comment faire en sorte que myMap ait une taille de 3 ? La Map ne doit contenir que des clés “test”.

// Début du code éditable
Map<String, Integer> myMap = new HashMap<String, Integer>();
// Fin du code éditable

myMap.put(new String("test"), 1);
myMap.put(new String("test"), 2);
myMap.put("test", 3);

int size = myMap.size();
assert(size == 3);

Réponse 7

Encore une fois il fallait un peu connaître les classes qui composent l’API Collection.

Map<String, Integer> myMap = new IdentityHashMap<String, Integer>();

Merci à tous ceux qui sont venus nous voir sur le stand, on a passé de bon moments. A l’année prochaine !

In Fine, en tant que partenaire de l’évènement majeur qu’est Devoxx France, a le plaisir de mettre à disposition une application pour Devoxx France sur Android. Cette première version permet :

• De mettre en favoris vos sessions préférées
• De consulter le planning des sessions, et le détail des speakers
• De voir ce qui se passe sur Twitter avec le tag devoxxfr
• D’avoir accès au plan des 2 étages de l’hôtel où se déroulera la conférence
• Et d’autres fonctionnalités…

Cette application fonctionne parfaitement sur téléphone , mais n’est pas encore totalement adaptée pour les tablettes. Dans les semaines qui viennent, nous allons continuer à mettre à jour l’application pour qu’elle soit la plus simple à utiliser possible. Voici une prévision des futures évolutions :

• Complète adaptation de l’ergonomie de l’application aux tablettes
• Ajout de la recherche sur les speakers. Actuellement elle ne fonctionne que sur les sessions
• Quand on clique sur une salle, afficher la carte de l’étage correspondant
• Pouvoir mettre en favori des speakers
• Et bien d’autres choses qui dépendront des retours que nous aurons

Nous sommes très fiers de mettre à disposition cette application. Elle sera mise en open source au moment de la conférence Devoxx France, certainement en licence Apache 2.
Si vous rencontrez des problèmes ou avez des suggestions, écrivez un commentaire ici, ou envoyer un mail au compte indiqué sur la fiche du Google Play Store.

Dans la suite de l’article, nous allons approfondir l’aspect technique de l’application. Si au contraire vous souhaitez directement aller télécharger l’application, alors il faut aller ici : Play Store

Architecture technique

Architecture applicative de l'application Devoxx France In Fine

Comme le montre le schéma ci-dessus, nous n’avons pas directement connecté l’application Android avec les API RESTful fournies par le site Devoxx. En effet les temps de réponse sont très variables, certains service ont déjà mis plus de 5 minutes à répondre. D’autre part, certains service renvoient des données en double ou incomplètes.
Le serveur intérmédiaire permet donc de mieux maîtriser les données. Grâce à Play et à Mongo DB, les temps de réponse sont excellents et la charge que peut encaisser le serveur est bien au dessus de ce que nous atteindrons. Un test JMeter a mesuré que le serveur pouvait encaisser 300 requêtes par secondes. La plupart des requêtes répondent en moins de 0.1 seconde. Nous estimons que le serveur aurait à supporter, au maximum de son activité, 25 requêtes par minute

Voici un petit article issu d’une demande d’un client.

Le client : C’est bien la configuration par JNDI, ça serait mieux si on ne voyait pas le mot de passe en clair …

Moi: No problem, everything is possible (enfin je crois) …

Effectivement c’est possible. D’après la documentation, il suffit d’implémenter une classe de type ‘factory’ pour instancier les connexions avec la base de données.

Dans cet article, vous verrez comment crypter facilement un mot de passe ou autre mais aussi comment remplacer le pool de connexion DBCP  par le pool de connexion de Tomcat 7 (plus performant à  mon goût).

Tout ceci se fait en 3 étapes :

• Codage d’une classe ‘Factory’
• Configuration de la ressource JNDI
• Copier les jar dans le répertoire lib de Tomcat

Le processus de cryptage ne sera pas détaillé ici.
Pour plus d’information, vous avez une classe “EncryptHelper” dans les sources (voir à la fin).

1° La classe Factory

Ici j’utilise le pool de connexion de Tomcat 7 :

public class Tomcat7EncryptedFactory extends org.apache.tomcat.jdbc.pool.DataSourceFactory implements SecuredFactory{

	@SuppressWarnings("rawtypes")
	@Override
	public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment) throws Exception {
		Object o = super.getObjectInstance(obj, name, nameCtx, environment);
		if (o != null && o instanceof org.apache.tomcat.jdbc.pool.DataSource) {
			org.apache.tomcat.jdbc.pool.DataSource ds = (org.apache.tomcat.jdbc.pool.DataSource) o;
			// recuperation du login et mot de passe cryptes
			String cryptedUsername = ds.getUsername();
			String cryptedPassword = ds.getDbProperties().getProperty("password");
			// on decrypte le password
			if (cryptedPassword != null && cryptedPassword.length() > 0) {
				String pwd = EncryptHelper.decryptData(secretKeyPassword, cryptedPassword);
				ds.setPassword(pwd);
			}
			// on decrypte le login
			if (cryptedUsername != null && cryptedUsername.length() > 0) {
				String username = EncryptHelper.decryptData(secretKeyUser, cryptedUsername);
				ds.setUsername(username);
			}
			// on set la taille initiale avec le minimum idle
			// on doit laisser le initialSize a 0 car il ne faut pas cree de connexion tout de suite car on a les identifiants cryptes.
			int minIdleSize = ds.getMinIdle();
			ds.setInitialSize(minIdleSize);
			ds.setConnectionProperties(ds.getConnectionProperties());

			// on ferme le pool deja parametre
			ds.close();
			// on recree le pool avec les nouveaux parametres
			ds.createPool();
			System.out.println("Initialisation de la datasource JNDI : OK");
			return ds;
		} else {
			System.out.println("Initialisation de la datasource JNDI : KO");
			return null;
		}
	}
}

Juste que la rien de difficile ^_^

2° Configuration JNDI

Extrait du fichier de configuration des ressources de Tomcat 6 (conf/context.xml)

    auth="Container" type="javax.sql.DataSource"
    factory="fr.cnvt.tomcat.Tomcat7EncryptedFactory"
    username="sD20tsCeFQPP3HuQV17yXw=="
    password="LoPCUiDWD47S6wIOTZWvBX7X9XTLt2vS9Sv52csoEGo="
    driverClassName="my.driver.class"
    url="my.jdbc.url"
    initialSize="0" maxActive="20" minIdle="5" maxIdle="10"
    validationQuery="SELECT 1 FROM Dual" validationQueryTimeout="300"
    maxWait="30000"
    removeAbandoned="true" removeAbandonedTimeout="600" logAbandoned="true"
    timeBetweenEvictionRunsMillis="20000"
    testWhileIdle="true"
    connectionProperties="CHARSET=utf8;" />

Comme vous pouvez le voir, le login (username) et le mot de passe (password) sont cryptés.

Vous pouvez avoir le même login et mot de passe (c’est bizarre comme c’est fréquent…) , les 2 chaines cryptés seront différentes (normal j’utilise 2 clés de cryptage différentes ^_^)

3° Librairies dans Tomcat

Dernières étapes, il suffit de copier les fichiers tomcat-datasource-factory-1.0.0.jar et tomcat-jdbc-7.0.22.jar(dans le répertoire lib du zip) dans le répertoire “lib” de Tomcat 6.

Voila en 3 copié-collé, vous avez un pool de connexion sans mot de passe en clair ^_^

Pour générer vos propres login et password cryptés, il suffit d’utiliser la classe EncryptHelper comme ceci:

	@Test
	public void generateEncryptedValues(){
		String login = "monsupertest";
		String password = "monsupertestaussi";
		String cryptedLogin = EncryptHelper.encryptData(SecuredFactory.secretKeyUser, login);
		String cryptedPassword = EncryptHelper.encryptData(SecuredFactory.secretKeyPassword, password);
		String decryptedLogin = EncryptHelper.decryptData(SecuredFactory.secretKeyUser, cryptedLogin);
		String decryptedPassword = EncryptHelper.decryptData(SecuredFactory.secretKeyPassword, cryptedPassword);
		assertEquals(login, decryptedLogin);
		assertEquals(password, decryptedPassword);
		System.out.println("Login crypte : " + cryptedLogin);
		System.out.println("Mot de passe crypte : " + cryptedPassword);
	}

Pour les curieux, le fichier zip contient également un pool DBCP et C3P0 qui gèrent aussi le login et mot de passe cryptés. Les clés de cryptages sont dans l’interface SecuredFactory.

Enjoy

Les sources sont disponibles ici

Cet article a pour but de présenter brièvement la présentation de Stijn Van den Enden, lors du Devoxx 2011, sur les performances brutes de plusieurs frameworks connus et de partager quelques impressions sur ce sujet.

Dans la première partie, il présente la méthodologie de tests ainsi que les outils : le coté test.
Dans la seconde partie, il nous montre les résultats qu’il a obtenu : le coté performance.
Les slides de la présentation sont disponibles ici

En résumé, on y voit la mise en place de la plateforme de tests ainsi que les outils utilisés.

Plateforme de tests :

Conclusion :

Sa conclusion étant qu’en terme de performance brute, on a :

1. GWT
2. Spring MVC
3. JSF 2.1.2 (Implementation Mojarra) ou Wicket
4. MyFaces (n’apparait pas dans le slide)

Dans sa conclusion, qui n’apparait pas dans les slides, il dit aussi que souvent, ce n’est pas le framework web qui est la principale cause de la mauvaise performance d’une application.
Pendant sa présentation, il a souligné que le seul framework qui a posé problème est JSF 2 (problème de mémoire, ce qui ne m’étonne pas).
Enfin, il nous rappelle qu’il faut aussi penser à la facilité de développement pour garder une bonne productivité.

Avis personnel

Pour ma part, la conclusion de Stijn Van den Enden ne doit pas tenir compte du temps de rendu de la page, sinon Spring MVC serait 1er avec GWT voire même devant.

Sur le point où il faut privilégier la facilité de développement, on regrettera l’absence du comparatif des frameworks Grails et Play qui sont tous deux excellents sur ce point.

Si vous avez envie de changer de framework, d’après plusieurs présentations vu sur le même sujet (par exemple l’article de Peter Thomas), il faut se fixer un prototype de page à faire et si cela vous parait trop difficile, c’est que celui-ci n’est surement pas adapté à vos besoins.

Personnellement, je me demande pourquoi il y a tant de personnes qui démarrent un projet encore avec JSF pour le web alors qu’il a autant de problèmes de performance et qu’il est parfois si compliqué de faire des choses simples avec (exemple pagination coté serveur…).

Pour finir, son approche de Spring MVC est intéressante car elle tend vers une pratique que j’ai adopté. Pour ma part, j’ai abandonné l’idée que le Java était fait pour le web, car c’est loin d’être le cas. Je préfère juste garder Java pour la partie serveur et utiliser essentiellement des langages du web pour la vue : très peu de JSP et EL(Expression Language) avec beaucoup de HTML, CSS et JQuery (avec des données fournies au format JSON, d’ailleurs Spring MVC fait très bien cela).

S’il fallait choisir un framework pour le web en ce moment, je prendrai Grails pour un projet ‘from scratch’ ou Spring MVC pour un projet existant. Je n’ai pas assez d’expérience sur GWT mais sa génération du javascript me fait hésiter… Je garderai dans les deux cas, JQuery pour les composants riches car il existe énormément de plugins pour ce framework javascript ou ExtJS ou voir même du flash (flex).

En ce qui concerne Wicket, sa programmation ressemble un peu à du Swing (client lourd) qui pourrait dérouter un développeur web. Tapestry est intéressant mais le temps d’apprentissage est assez important.

Comparatif plus étendu

Pour ceux qui comme moi ont regretté l’absence de Grails et Play, voici un article intéressant avec un comparatif des deux et surtout une légère ‘customisation’ pour gagner en performance.
Notez que l’utilisation de Japid pour Play booste grandement ses performances et que Netty semble plus rapide que Tomcat.

Extrait du site JT Dev (vous pouvez cliquer sur les images pour les agrandir)

Plus de détails ici

La seconde édition de ce livre est sortie il y a déjà quelques mois. Cette nouvelle édition apporte le support de Maven 3 ainsi que des corrections. Je n’avais entendu que du bien de la première version, allons voir ce que donne cette seconde édition !
Depuis quelques années j’utilise 2 ressources principales afin de m’aider dans mon utilisation quotidienne de Maven : la documentation officielle et l’ebook Maven The Definitive Guide dont j’ai toujours une copie dans ma dropbox. Cet ebook a beaucoup de lacunes et n’approfondie par certaines notions Maven qui pourtant le mériteraient, mais je le consulte tout de même régulièrement.

Je me considère comme un bon utilisateur de Maven, mais je suis loin d’être un expert. Cela fait déjà plusieurs années que je le pratique, et je l’utilise quotidiennement dans le cadre de mes missions chez les clients. En lisant le livre Apache maven l’objectif était double :

• Apprendre de nouvelles choses ou appronfondir certaines notions que j’utilise peu
• Trouver un complément à Maven The Definitive Guide qui date désormais quelque peu

Ce livre propose un scénario…

Ceci peut paraître étrange pour un livre d’informatique, mais il y a effectivement un scénario. Arnaud et Nicolas sont 2 compères qui retrouvent un vieille application sur une disquette gérant une liste de courses. Cette application se construit grâce à des scripts spécifiques à chaque OS : un fichier .bat et un fichier .sh.

Ils décident d’améliorer l’application en lui ajoutant de nouvelles fonctionnalités. D’une simple application, elle deviendra un vrai gros site web. Qui dit grosse application, dit industrialisation dans le process de livraison, de tests etc… Et c’est là que Maven intervient.

Et en plus, cet ouvrage est drôle

Déboussolés par les divers problèmes qui se posent à eux, Nicolas et Arnaud seront aidés dans leur quête à créer l’application de gestion de course ultime, par d’autres personnes ayant les connaissances nécessaires afin de surmonter ces épreuves. Citons parmi ces seconds couteaux Olivier Lamy, Vincent Massol, Antonio Goncalves, Guillaume Laforge et bien d’autres.
Désolé de vous avoir spoilé une bonne part du scénario, mais je vous assure qu’il y a encore beaucoup de rebondissements dont je ne vous ai pas parlé.

Avoir un scénario est déroutant pour un livre d’informatique. La forme habituelle didactique est ici changé en “roman” avec ses rebondissements et une belle fin. Par conséquent ce livre se lit d’une traite malgré le sujet qui peut sembler difficile au premier abord. Le livre prend le parti de montrer des situations concrètes issues des expériences de Nicolas et Maven, et nous propose une solution généralement grâce à une fonctionnalité de Maven ou à l’un de ses plugins.

… Et du contenu

En effet Maven est généralement considéré comme compliqué. Cet ouvrage veut prouver le contraire. Maven est prévu pour répondre à plusieurs problématiques courantes des projets. Ce qui le rend difficile (son cycle de vie, ses plugins…) est abordé progressivement dans le livre au travers de problèmes que n’importe quel utilisateur de Maven pourrait rencontrer sur un projet.

Le livre n’aborde pas que les bases de Maven et par exemple des plugins peu courants sont présentés tels que le maven-osgi-compiler-plugin ou le flexmojos-maven-plugin. D’autres points liés à Maven sont abordés tels qu’une comparaison des IDE ou des différents gestionnaires de dépôt.

Cette seconde édition apporte évidemment quelques nouveautés. La plus importante est lié à Maven 3. Dans cette édition, la plupart des chapitres contiennent un encart détaillant les spécificités de Maven 3. Ces encarts ne sont pas très nombreux, Maven 3 étant en grande partie compatible avec Maven 2. Les autres nouveautés concernent les corrections de la première édition, ainsi que l’ajout d’un chapitre. Pour être clair, si vous possédez la première édition, les nouveautés ne justifient pas de se procurer la nouvelle.

Le livre parfait ?

Ce livre comporte de très nombreuses qualités. Le sujet est bien maitrisé et l’apprentissage est progressif sans pour autant être trop lent. L’approche est très pragmatique et les fonctionnalités de Maven sont présentées par une approche très pratique, plutôt que par une approche théorique que de nombreux ouvrages d’informatique indigestes privilégient. De plus les livres en français et de qualité sont rares, celui-ci en fait partie, et je le recommande vivement. Apprendre Maven ou se perfectionner n’aura jamais été plus facile.

Quand je vous disais qu'il était drôle

Me concernant j’ai trouvé le parfait complément à Maven The Definitive Guide. Il ne me manque plus qu’une version électronique afin de l’avoir dans ma Dropbox, et je pourrais presque me passer de Maven The Definitive Guide.

Chaque lecteur, en fonction de sa propre expérience, trouvera des choses à redire. Pour ma part, j’aurais souhaité que certains points soient approfondis comme les extensions ou l’écriture de plugins. Cette seconde édition apporte certainement son lot de correction, mais inévitablement les nouvelles parties ajoutées comportent leur lot d’erreurs. Heureusement elles restent mineures et ne nuisent pas à la compréhension du passage concernée. La perle étant le listing du code de la page 185 (à lire si vous avez le bouquin sous la main ).

Assez de bavardages, cet excellent ouvrage est à mettre entre toutes vos mains, car vous utilisez tous Maven. Voici la page du livre chez l’éditeur contenant la table des matières ainsi que des extraits.

SCRUM, Extreme Programming (XP), Lean-management, le développement agile, c’est tendance !

Objectifs : améliorer la réactivité, la qualité et le coût du logiciel avec en ligne de mire la sacro-sainte satisfaction client.

J’ai participé, pendant deux ans, à un projet réalisé « from scratch » en suivant une méthodologie agile : l’Extreme programming. En tant que développeur (sur les deux ans), et « coach XP » (sur les six derniers mois).  L’objectif du projet était le développement d’une application de trading « in-house » dans une banque d’investissement, la taille de l’équipe a varié au cours de ces deux ans de 3 à 7 (manager compris).

Ce post a pour but d’expliquer les pour et les contre de cette méthode tel que je l’ai vécu.

L’extreme programming

Sans chercher à être exhaustif (wikpedia est ton ami), voici les grands principes XP :

• Pair-programming : on code à deux devant un PC, le codeur et le reviewer. les rôles s’inversant régulièrement. On change de binôme à chaque tâche.
• TDD (Test driven development) : chaque méthode, chaque portion de code est systématiquement testée avant d’être codée.
• KISS (Keep It Simple, Stupid) : On cherche toujours la solution la plus simple sans anticiper les besoins futures (pêché mignon du développeur ?).
• Refactoring : On cherche en permanence à avoir le code le plus propre possible
• Itérations courtes : le cycle développement-release est très court (1 semaine à 1 mois)

Les plus

• Un code clean : Non seulement l’XP via ses principes favorise une plus grande qualité de code, mais j’irai plus loin : il l’impose ! En effet, le TDD dans du code spaghettis, dupliqué, du code mort…c’est sinon impossible, franchement pénible. Idem pour le refactoring, très cher s’il n’est pas fait suffisamment tôt.
• Agilité : Je vous entends « Il est malin le type, c’est l’objectif ! ». Ok, mais c’est un objectif atteint. Le client peut changer d’avis et ses priorités comme de chemise (et il ne s’en prive pas).
• L’équipe te rend plus fort : Grace au pair-programming, les développeurs montent rapidement en compétence. Pour le développeur, c’est l’opportunité de se former grâce au reste de l’équipe. Se former sur l’application bien sur, mais aussi sur tout ce qu’on peut apprendre à observer un autre développeur à l’oeuvre.
• Interchangeabilité : XP refuse la spécialisation, chaque développeur doit maîtriser l’ensemble de l’application. C’est possible en associant sur chaque développement un « sachant » et un « ignorant » sur la partie concernée. C’est clairement un luxe pour le manager étant donné le turnover dans la plupart des projets informatiques. Les mauvaises langues parleront de développeur « jetable », mais pour le projet, c’est un plus.

Les moins

• Dites au revoir à votre « Touch » : Si vous aimez utiliser vos raccourcis « custom », vos conventions de nommage, vos patterns, vos lib. Bref ! VOTRE façon de coder : Oubliez ! vous allez coder la moitié du temps sur un autre PC, et quelqu’un d’autre codera sur le votre. L’uniformisation des l’environnement, des outils et des pratiques est par conséquent obligatoire. C’est positif pour le projet, mais l’effort d’adaptation est réel.
• Explications, négociations, compromis : Développer à deux, ce n’est pas naturel. Il faut en permanence argumenter, expliquer son cheminement de pensée. Quand au reviewer, il doit rester concentrer sans le clavier, challenger chaque décision,  être force de proposition et chasser chaque bug ou coquille, il doit enfin être patient s’il maitrise mieux le sujet sans chercher à « attraper » le clavier. Il faut aussi veiller à garder un équilibre, le plus timide ou le plus junior ne devant pas se faire « manger ». Bref, c’est formateur, le code écrit est meilleur, mais je suis convaincu que c’est plus exigent que de coder seul.
• Le TDD, ce n’est pas sexy : Je suis fermement convaincu de l’intérêt du TDD (limitation des bugs et des régressions, refactoring sure, spécification, code découplé), mais il faut avouer qu’écrire des centaines de tests et avoir la (fausse ?) impression d’aller deux fois moins vite, c’est parfois rébarbatif.
• Pas de petit chef : Le pair-programming, l’absence de spécialisation et la volonté en XP d’aller vers l’essentiel (le code) limite quelque part les responsabilités du développeur. Dans une équipe classique, chaque développeur deviendra probablement référent sur certains domaines, participera à des réunions, et prendra en charge certaines responsabilités.  En XP, le manager manage, les codeurs codent (PS : si c’est tout ce que vous aimez, vous pouvez passer cela dans la rubrique plus), et nul n’est indispensable.

Avant de conclure, quelques remarques inclassables, ni en plus, ni en moins

L’extreme programming, à prendre ou a laisser.

Je ne vois pas les différentes pratiques de l’XP comme une boîte à outil où l’on prend et on jette en fonction des envies. Les différentes pratiques se complètent et se renforcent mutuellement.

• Pour livrer très fréquemment, il faut pouvoir valider une version très rapidement, d’où le TDD. (Si vous voulez tester l’application de fond en comble tous les 15 jours à la main, ce sera sans moi).
• Prendre systématiquement la solution la plus simple en négligeant le refactoring, c’est la porte ouverte au code spaggeti et autres rustines.
• Faire du refactoring fréquemment sans couverture de tests unitaires, c’est l’assurance de régressions.
• Refactorer, c’est bien plus sûr avec une deuxième paire d’yeux.

Bien sur, ça n’est pas vrai pour tout,  le TDD n’a pas attendu l’XP pour exister.

N’est pas XP qui veut

Tout projet n’est pas adapté à l’XP. Il faut un client accessible et prêt à s’investir et des développeurs ouverts aux pratiques XP. Il faut enfin que le manager soit convaincu par la méthode et à l’écoute des développeurs (accepter les coûts donnés par des développeurs et les dépassements inévitables par exemple).

L’environnement de développement est également primordial. Framework de tests unitaires, de mocking, outils de refactoring, d’analyse statique de code, de couverture de tests, usine de build…Tous ces outils « nice-to-have » dans un autre projet deviennent plus ou moins indispensables en XP. En conséquence,  un projet C++ ou dans un langage web est sans doute moins adapté à l’XP qu’un projet Java ou .NET.

Conclusion

Au final, même si j’ai la critique un petit peu facile par nature, je me range plutôt du côté des « pro-XP / pro-agiles » .Le projet auquel j’ai participé est à mon avis un succès, mais il est important de noter qu’il correspond en tous points au « contexte idéal » décrit ci-dessus.

Quant aux objectifs mentionnés au début du post (améliorer la réactivité, la qualité et le coût du logiciel), les deux premiers sont clairement atteints. Pour le troisième,  c’est la question à 1 Milliard.

Ce qui est sûr, c’est que l’on est très loin d’un coût multiplié par quatre. Certes on code deux fois plus (TDD), et à un instant donné, la moitié de l’équipe ne code pas (elle ne dort pas non plus). Mais cela est compensé par des bugs à fixer en moins, un code de meilleur qualité, une montée en compétence plus rapide et un scope correspondant exactement au besoin client. Est-ce que c’est « surcompensé » ou « sous-compensé », là est le vrai débat. Mon intuition c’est que le gain est négatif dans un premier temps (un an, peut-être deux) puis positif par la suite.

Voilà pour ma vision de l’Extreme programming, à prendre pour ce que c’est, un avis basé sur une expérience mais certainement pas une vérité.

Pour quantifier cet effet sur les dix dernières années, j’ai reconstitué les performances annuelles du CAC 40 depuis 2001 que j’ai comparées aux performances de ce même CAC 40 sur la période allant du 15 décembre au 03 janvier, chaque année. Ces performances sont ensuite annualisées pour faciliter la comparaison. Les résultats sont visibles dans le tableau suivant :

Performances comparées du CAC 40 sur la période des fêtes et sur l'année entière

La magie de noël semble faire son office avec une certaine régularité puisque tous les ans excepté 2007 (soit 9 années sur 10), le CAC 40 est monté sur la période des fêtes de fin d’année, toujours mieux que sa performance sur l’année entière ! En annualisé il enregistre une performance moyenne de 51.2% du 15 décembre au 03 Janvier, quand il a en moyenne perdu 2.8% sur l’année écoulée.

2011 et ses problèmes de dettes en Europe et aux Etats-Unis semblent annoncer une fin d’année un peu plus agitée que d’ordinaire, alors qu’attendre des marchés pour les jours qui viennent ?

Phénomène fantaisiste autoalimenté ou réalité saisonnière, le statisticien prônera la méfiance quant à l’interprétation d’un échantillon de données si petit, mais même à l’âge adulte, il est encore possible de croire au père noël ;-)

Ceylon est un nouveau langage s’exécutant sur la JVM. Il rejoint une liste désormais assez longue qui comprend notamment :

• Groovy
• Jython
• Jruby
• Scala
• Kotlin
• Fantom
• Gosu
• …

Gavin King a créé Ceylon parce qu’il était frustré par les limitations de Java. Cette session a été animée par deux français, Emmanuel Bernard et Stéphane Epardaud qui sont commiters sur le projet. Ils ont débuté la session en définissant les objectifs de Ceylon, avant de continuer sur ses fonctionnalités à l’aide de code. Je ne vais pas reproduire le code qu’ils ont utilisé pendant la présentation dans cet article, je vais essayer d’être plus concis.

Emmanuel commence par nous indiquer les objectifs de Ceylon :

• Permettre d’écrire du code plus simple que l’équivalent en java
• Éviter au développeur de tomber dans les principaux pièges de java

Ceylon est pensé pour être lu facilement par des développeurs venant du monde Java. Emmanuel insiste bien sur ce point : Ceylon doit être simple à utiliser mais également simple à lire. Le code ne doit pas soulever d’ambiguïté.

Principes de base

Classe simple

shared class User(String username, Natural age) {
    shared String username = username;
    shared Natural age = age;

    shared void printUser() {
        print("User name : " username " with age " age " is printed");
    }
}

Cette classe est courte, mais il y a déjà plusieurs choses à dire dessus :

• Le mot-clé class indique évidemment qu’il s’agit d’une déclaration de classe
• Le mot-clé shared est l’équivalent du public de Java. Si le mot-clé shared est omis, alors la visibilité est privée (visibilité par défaut en Ceylon)
• A la suite de la déclaration de la classe User se trouvent des paramètres (String username, Natural age), il s’agit de la déclaration du constructeur. Je dis bien du car une Ceylon interdit la surcharge de méthode et donc un seul constructeur est autorisé
• Natural est l’objet représentant un nombre entier naturel. En Ceylon, il n’y a pas de type primitif
• Les attributs de la classe sont obligatoirement initialisés, il n’y a pas de valeur par défaut, même null n’est pas implicite. Ici, les valeurs sont celles fournies au constructeur
• La déclaration de la méthode printUser se fait comme en Java, le mot-clé shared en plus si on souhaite l’exposer
• La concaténation de chaîne de caractère peut se faire sans le caractère +. La concaténation avec le caractère + fonctionne également

Méthodes

shared class Parent() {
    shared default void printMe() {
         print("I'm in parent class");
    }

    shared void printMessage(String messageToPrint = "default argument value") {
         print("I'm in parent class and I print " + messageToPrint);
    }
}

shared class Child() extends Parent() {
    shared actual void printMe() {
         print("I'm in child class");
    }
}

void testCeylon() {
    // appel de méthodes
    Parent p = Parent();
    p.printMe();
    p.printMessage(); // default value of parameter used - will work on milestone 2
    p.printMessage("message given as argument");  // classic call
    p.printMessage {  // name argument used
        messageToPrint = "message with named arguments";
    };
}

Encore une fois, malgré la petite taille de code et sa lisibilité, plusieurs fonctionnalités sont à décrire :

• Comme dit plus haut, les méthodes ne sont pas surchargeables. Pour palier à cette obligation les paramètres peuvent avoir des valeurs par défaut (ligne 6), des varargs peuvent être utilisés (comme en java), ou des union types peuvent être utilisés (voir la doc pour plus de détails)
• Les paramètres des méthodes sont nommés – ligne 22
• Les méthodes peuvent être redéfinies dans les classes filles mais il faut l’autoriser explicitement grâce au mot clé default dans la classe parent (équivalent du virtual du C++ utilisé dans la classe parent) – ligne 2
• Lors de la rédéfinition de la méthode dans une classe fille, il faut obligatoirement utiliser le mot-clé actual (équivalent à l’annotation @Override de Java) – ligne 12

null et immuabilité

Par défaut toutes les variables sont immuables en Ceylon. Afin de les rendre modifiables il faut explicitement adapter la syntaxe de déclaration d’une variable en ajoutant le mot-clé variable et effectuer l’affectation avec l’opérateur := :

shared class ImmutableExample(Natural year) {
    // immutable
    Natural year = year;
    // Mutable
    variable Natural writableYear := year;
}

Afin d’éviter les trop nombreux NullPointerException de Java, une variable qui pourrait contenir la valeur null doit être déclaré à l’aide d’un ?. Ceci a des conséquences sur la manière d’utiliser ces variables comme le montre le code ci-dessous :

// myBestVariable can be null
String? myBestVariable = functionThatCanReturnNull();
// to work on myBestVariable, a null check must be done
if (exists myBestVariable) {
    functionThatNeedAString(myBestVariable);
}
else {
    functionThatNeedAString("default value");
}

Autres fonctionnalités

Emmanuel et Stéphane ont présenté d’autres fonctionnalités importantes de Ceylon telles que les union type et les intersection type. Pour plus de détails, reportez vous à la documentation officielle.
Malgré les arguments nommés, il est possible d’utiliser les generics. Les annotations sont également disponibles.
La compatibilité entre Java et Ceylon est également disponible. Ceylon peut utiliser du code écrit en Java, et Java peut appeler du code Ceylon.

En pratique

Emmanuel et Stéphane, après avoir transmis les bases à l’auditoire, effectuent une démo en live de Ceylon dans Eclipse. Un plugin Eclipse a été développé et est déjà fontionnel. L’autocomplétion fonctionne bien, la coloration syntaxique et le refactoring également. Plus d’infos sur le repo git associé.

Aucune version de Ceylon n’a encore été releasée. La prochaine version à sortir sera la milestone 1 qui ne comprendra pas encore toutes les fonctionnalités de la spécification. Trois milestones sont prévues avant que la version 1.0 ne sorte.

Test de Ceylon

Il est évidemment possible aujourd’hui de tester dès aujourd’hui Ceylon et pour cela, j’ai réalisé un petit screencast afin de vous montrer qu’avoir le compilateur Ceylon utilisable sur son poste est vraiment simple et rapide.

Les prérequis sont d’avoir sur sa machine Java 6, Ant et Git. Dans le screencast, je clone les trois repositories Git nécessaires à la création du compilateur. Chacun nécessite Ant afin d’être compilé. Une fois le compilateur généré, je le teste en compilant l’exemple de code que j’ai donné ci-dessus dans le paragraphe Méthodes, et je l’exécute.

Pour ceux qui veulent tester, je vous retranscrits les commandes utilisées dans le screencast afin de faciliter le copier coller

Une fois le compilateur généré, je l’ai testé. Mon fichier source se nomme florian_boulay.ceylon et se trouve dans le répertoire samples. Le répertoire build contient les fichiers Ceylon compilés. testCeylon correspond au nom de la fonction appelée pour lancer le programme.

Ceylon est un langage simple à comprendre pour qui vient de Java. En écrire est également à la portée de tous. Jusque là les objectifs de Gavin King sont atteints.

Fin de la session

Pour finir, Emmanuel nous indique que Ceylon a enfin sont site web : http://ceylon-lang.org

Il contient une documentation très complète, la spécification du langage écrite par Gavin King, un blog et tout ce qu’il faut pour contribuer au développement du langage. C’est là bas qu’il faut aller si vous souhaitez tester le langage qui n’a pas encore été releasé, mais peut être testé via la récupération du code source sur Github.

Comme vous le voyez, le logo de Ceylon est un éléphant, est-ce un hommage à PHP ? On peut lui souhaiter qu’il ait le même succès que PHP

De nombreux nouveaux langages ont émergé ces derniers mois fonctionnant sur la JVM (Eclipse Xtend, JetBrains Kotlin). Comme dit plus haut, Ceylon veut rester accessible à tout le monde en restant simple et facilement compréhensible. Est-ce que ces atouts seront suffisants pour faire de Ceylon une alternative à Java réellement utilisée, comme l’est Scala aujourd’hui ? Faites vous votre propre opinion et essayez le.

L’openGL existe depuis les premières versions d’Android pour les jeux et certains autres composants mais l’interface graphique des applications a toujours été “SOFTWARE”.
Depuis Android 3.0 il est possible d’activer l’accélération graphique pour chaque application ce qui nous permet d’avoir une meilleur expérience utilisateur, avoir des animations plus fluides et de libérer un peu le CPU.

Software rendering vs Hardware rendering

Lorsqu’une application utilise l’accélération matérielle, l’OpenGL est utilisé lors de l’appel de la fonction Canvas.draw().

Activation de l’accélération matérielle

Pour activer l’utilisation du GPU sur Android 3.0+, il suffit d’ajouter android:hardwareAccelerated=“true” dans le tag application du fichier AndroidManifest.xml. Ce simple ajout devrait activer l’accélération matérielle pour toute votre application, cependant certains composant ne peuvent pas (encore) bénéficier de cette fonctionnalité c’est pourquoi nous allons voir par la suite comment la contrôler.

Contrôle de l’accélération matérielle

Si votre application a des problèmes sur certains éléments avec l’accélération matérielle, il est tout à fait possible de définir quels éléments doivent ou non utiliser le GPU.

On peut donc l’activer ou la désactiver sur ces différents éléments :

• Application
• Activity
• Window
• View

Pour utiliser l’accélération matérielle au niveau Application ou Activity il faut utiliser le fichier AndroidManifest.xml

<application android:hardwareAccelerated="true">
    <activity ... />
    <activity android:hardwareAccelerated="false" />
</application>

Voici ci-dessous un exemple de code à utiliser pour l’utiliser au niveau “Window” :

getWindow().setFlags(
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

Pour finir, on peut désactiver l’utilisation du GPU seulement pour un partie de l’écran (View) :

view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Vérifier si un élément utilise le GPU

Il peut être important de savoir si un élément utilise l’accélération matérielle à un moment donné.
Il existe 2 façons de le vérifier :

• View.isHardwareAccelerated(), retourne “true” si la View est attachée à une Windows qui utilise le GPU
• Canvas.isHardwareAccelerated(), retourne “true” si le Canvas est acceleré

Fonctions supportant l’accélération matérielle

La plupart des fonctions habituelles de la classe Canvas sont supportées, cependant certaines ne le sont pas mais le seront peut-être dans les futures versions d’Android.

Voici la liste des fonctions non supportées :

Certaines autres fonctions fonctionnent différemment lorsque l’accélératrion matérielle est activée :

Play

La version 2.0 de Play a déjà été annoncée il y a plusieurs semaines. Une pré-version de test avait été mise à disposition. Aujourd’hui la sortie de la beta a été annoncée.

Lors de la présentation faite par Sadek Drobi (@Sadache) et Guillaume Bort, les nouveautés ont été détaillées :

• Intégration de Scala directement dans Play : les templates ne se feront plus en Groovy mais en Scala. Les classes pourront être faites en Java ou en Scala. Cela a pour conséquence la mise à disposition de la console Scala qui permettra, par exemple, d’appeler directement du code applicatif à parti de la ligne de commande.
• Un système de build est désormais intégré, il s’agit de SBT (Simple Build Tool). Ce choix est certainement la conséquence de l’intégration de Scala. Cela remplacera l’ancien système basé sur Ivy.
• Intégration d’Akka
• Les scripts javascript et les feuilles de styles sont compilés

Plus d’infos disponibles sur le site officiel : http://scala.playframework.org/2.0

L’autre annonce est que Play intègre désormais la stack Typesafe. Cela signifie que Typesafe fournira du support sur Play. De plus Guillaume Bort va désormais siégé au board of advisor de Typesafe (Je ne sais pas comment le traduire, conseil d’administration ?) en tant que conseiller sur les choix techniques web d’après ce que Guillaume a dit durant sa présentation.

Devoxx France

Une version française de Devoxx se tiendra du 18 au 20 avril 2012 à Paris ! Elle est inspirée du modèle belge et elle durera 3 jours et sera à 75% en français et 25% en anglais. Elle est organisée par les membres du Paris Jug (Antonio Goncalves, Zouheir Cadi, José Paumard et Nicolas Martignolle). Ce sera la plus grosse conférence Java francophone, venez nombreux !
In Fine sera bien entendu partenaire de cet évènement.
Plus de détails sur le blog de Nicolas Martignolle.