Tom’s Quest

Review : Play Framework Cookbook

2011-10-06T00:00:00+02:00

Play!, the framework for the bored Java developers ! Very interesting and opinated framework. I didn’t play with it a lot in the previous months, but the new book “Play Framework Cookbook” by Packt Publishing, released this summer was a good way to dig into the framework. The ebook was offered for free to people who wants to review it. No excuse.

The chapters are :

Basics of the Play Framework
Using Controllers
Leveraging Modules
Creating and Using APIs
Introduction to Writing Modules
Practical Module Examples
Running Into Production

Each subsection is divided in parts: “Getting ready”, “How to do it”, “How it works”, “There’s more”, “See also”. The most interesting part for me is the explanation of the internals, not the “tutorial” part. I have found practical information in nearly each of these.

The “There’s more” parts are cools because it shows additionnal/alternate/better ways to think about what you read before. For example, here is an excerpt from this part from the chapter “Understanding bytecode enhancement”:

Overriding toString() via annotation

Peter Hilton has written a very good article on how one can configure the output of the toString() method of an entity with the help of an annotation by using bytecode enhancement. You can check it out at http://www.lunatech-research.com/archives/2011/01/11/declarative-model-class-enhancement-play

A lot of content is about modules (dependencies, events…) with some examples (Solr, cache…). The idea is to complete what you may find online or in the official documentation.

Review

I give a “B” to the book, as it is 1) easy to read and well written, 2) entertaining, 3) actionnable. The author, Alexander Reelsen, has done a very good work. I learnt a lot, even as a beginner on the framework. Many of my questions were answered. The main benefit of the book is to complete the online documentation and going further on many topics. I really liked the given explanations, the additionnal references and that the framework’s code was referenced (in the form: “See this class for more info”).

What’s missing ? Maybe a Scala chapter, but as the author wrote: “When I started writing this book, my Scala knowledge was far from competitive (and still is in many areas)”.

Better autocompletes with Fuzzy Matching

2011-05-13T00:00:00+02:00

This article is an introduction to Fuzzy Matching and how it can improve an Autocomplete widget. Fuzzy Matching is used to find the most appropriate strings into a set of strings, like finding “Sinatra” when you mispelled it “Senatra”.

We will setup a Sinatra application displaying an Ajax autocomplete widget, which call the backend to have the best matching results, even if the match is not strictly equal.

Fuzzy Matching ?

Fuzzy Matching, aka Approximate String matching on Wikipedia, is used mainly in spell checkers and in biology to measure the variation between DNA.

In this article, we will use the Levenshtein distance algorithm to fetch results when there would be none using standard methods. Some other matching algorithms are also popular: the Damerau–Levenshtein distance (Levenshtein with transposition of letters), the Soundex (a phonetic algorithm for indexing names by sound) and also the Bitap. Many of them can be found in Ruby, or could also be hand coded.

Using the Levenshtein algorithm, we get a distance between two strings. This gives for example :

$ distance("sinatra", "sinatra") #= 0, equality
$ distance("sinatra", "senatra") #= 1, one permutation
$ distance("sinatra", "rails") #= 6, many permutation

This allows us to display to the user not only the strings that match the input, but also the strings that are approximately equal.

The application

The application uses the following pieces of code :

A Sinatra application
JQuery UI for the Autocomplete
The “text” gem which has an implementation of the Levenshtein distance algorithm (source: https://github.com/threedaymonk/text/blob/master/lib/text/levenshtein.rb)

The source code is available on : https://github.com/tomsquest/better-autocompletes-with-fuzzy-matching

Frontend

The JQuery Autocomplet widget is simple to setup. The source is defined to call the “countries” URL and it will send it the input like “countries?term=my_input”.

1. Add an input

.ui-widget
 %label(for="country") Country:
 %input#country

2. Bind the JS

$(function() {
  $("#country").autocomplete({
    source: "countries",
    select: function( event, ui ) {
      $("#results").text("input was: '"+ this.value + "' and selection was: "+ ui.item.value);
    }
  });
});

Backend

Even simpler, the backend is a simple get method which respond with JSON :

get "/countries" do
 content_type :json
 find_countries(params[:term]).to_json
end

The real stuff is in the “find_countries” method :

def find_countries(term)
  # Exact match
  countries = COUNTRIES.find{|c| c.downcase == term.downcase}.to_a

  # Partial match
  if countries.empty?
    countries = COUNTRIES.find_all{|c| c.downcase.include? term.downcase }

    # Here is where we call the distance method of the text gem. It computes the Levenshtein distance and
    # appends the results to the partial match done before
    max_distance = 5 # Should be tweaked
    countries += COUNTRIES.find_all{|c| distance(c, term) < max_distance}.sort_by{|c| distance(c, term) }

    countries.uniq!
  end

  countries
end

The find_countries method can serve as an example. It uses exact and partial matching and use the Levenshtein distance to add some more results. A real-world-awesome-production implementation would be different, by narrowing the results (less results, lower distance).

Wrapping up

With a minimal mathematical background and a minimal technical setup (no indexing, no DB specific feature), we have boosted our autocomplete results.

We’ve seen how to setup a quick-and-simple sinatra app which computes on the Levenshtein distance on the backend. The Frontend was easily done using the JQuery UI Autocomplete widget.

For advanced use cases, we should improve the way we mix the Fuzzy-maching results with the strictly matching results. Switching to a better algorithm, or a set of algorithm (Longest common substring + Dameau-Levenshtein) could also be easily done.

The complete source code is available on Github : https://github.com/tomsquest/better-autocompletes-with-fuzzy-matching

FitNesse technical setup

2010-12-04T00:00:00+01:00

Getting FitNesse working for a development team is not particularly evident. You have many possibilities and some of them are not so effective.

The Setup proposed here has a good combination of pros and cons. It will enable the work of two teams: one team of functional people using a central server and one team of developers writing the fixture straight from their workspace.

Advantages and disadvantages

Pros:

Developer friendly
One unique source of test cases: the central server
Test pages backup along the source code

Cons:

Pages cannot be created locally; they have to be created on the central server
The backup task seems hacky, but it does the job

Team process

The functional people use the central server to manage the test pages

Each developer has its own FitNesse server, which imports the page from the central server and use the local workspace

A job adds, delete and commits the changes made on the central server’s pages

Basic rules:

Pages must be created on the central server, never locally
Pages must be modified remotely (using the “Edit Remotely” button); Local pages may be erased at the next sync, so use them carefully

Setup

Central Server

Launcher

The launcher will use a local checkout of the project. This checkout is used for compiling the fixture and project code, and also to be able to commit the changes made to the test pages.

Launcher command line:

java -jar fitnesse.jar -p 8086 -e 0 -r $dir_with_fitnesse_pages

The “-e 0” argument disables the built-in versioning system of FitNesse.

The “-r $dir” argument tells FitNesse to use this directory as the repository of pages.

The whole command line arguments are described here: http://fitnesse.org/FitNesse.UserGuide.CommandLineArguments

Classpath

We use the “root” page (http://localhost:8086/root) to declare the server’s configuration and classpath.

This page won’t be added to source control, because its content will be different on a developer’s workstation.

The fitnesse-maven-plugin is used to create the list of jars we depend on. It reads the pom.xml file of our maven project, but it can also read a pom file directly from the central repository.

Content of the root page:

Use Slim engine instead of Fit
!define TEST_SYSTEM {slim}

Change the default port to avoid conflicts
!define SLIM_PORT {62123}

Classpath and pom file
!path /home/hudson/workspace/myproject/fitnesse/target/test-classes
!pomFile /home/hudson/workspace/myproject/fitnesse/pom.xml

Backup job

The backup job is simple. It is run by our Build server, every minute and launches a basic script, which adds, deletes and commits all changes within a directory.

Here is a simple batch file for Subversion. The first argument should be the directory to backup.

for /f "tokens=2*" %%i in (‘svn status %1 ^| find "?"’) do svn add "%%i"
for /f "tokens=2*" %%i in (‘svn status %1 ^| find "!"’) do svn delete "%%i"
svn commit -m "Automatic commit" %1

We did try to use a FitNesse plugin for Subversion to backup the pages automatically (and in a less hacky way) but that simply did not work at all. This plugin was: http://code.google.com/p/cm-subversion

FitNesse has also a pseudo-native support of Git (see here) but corporate Git repositories are still not the standard.

SVN ignore

All files in the working directory of FitNesse can be versioned, except:

The “root” page we used earlier, this is the content.txt and properties.xml at the root of the working directory
The “ErrorLogs” directory
All zip files “*.zip” (there should be none because of the “-e 0” flag

Source: http://stackoverflow.com/questions/249580/how-do-i-add-fitnesse-pages-to-version-control

Developer server

Launcher

On a developer server, we don’t need the “-r” flag. The pages will be imported from the central server.

Launcher command line:

java -jar fitnesse.jar -p 8086 -e 0

Classpath

As on the central server, the “root” page is used to configure the classpath.

The content is the same, with the exception of the local path:

Use Slim engine instead of Fit
!define TEST_SYSTEM {slim}

Change the default port to avoid conflicts
!define SLIM_PORT {62123}

Classpath and pom file
!path /home/tom/dev/myproject/fitnesse/target/test-classes
!pomFile /home/tom/dev/myproject/fitnesse/pom.xml

Wiki import

The Wiki Import feature is used to, well… import the pages from the central server.

How-to:

From the developer’s server, create a new page
From the properties, paste the URL to the parent page you wish to import (something like http://fitnesse:8086/MyProject)

Debugging

Debugging is easy. Add a breakpoint to a fixture then create a “Remote Debug” configuration (within the Debug menu).

Under FitNesse, just append the following at the end of the page you want to debug:

?responder=test&remote_debug=true

Random problem (Bind, Socket exception)

If you experience strange errors with no output, or better Socket and Bind exceptions (like in the screenshot), you should use the SLIM_PORT option (as used in this article). This basically shift the ports used by Slim to avoid conflicts with, let’s say, Tomcat.

Add this:

!define SLIM_PORT {62123}

Industrialisation des développements : automatisez votre base de données

2010-09-16T00:00:00+02:00

Le grand oubli dans l’industrialisation des développements est la base de données, cette chose monolithique et statique qui n’évolue pas aussi vite et aussi aisément que le code. Au même titre que l’intégration continue et les systèmes de gestion de version pour le code source, il existe des outils permettant de fluidifier et d’automatiser le travail autour du schéma physique des données. Travailler avec ces outils permet de compléter une démarche Agile en permettant une réactivité forte face aux changements.

Une première partie de cet article concernera les principes et pratiques autour de ces outils (partie « boss compliant »). La deuxième est orientée technique (partie « geek aware »).

Principes directeurs

Dans son article paru en 2003 intitulé « Evolutionary Database Design », Martin Fowler pose les principes du design évolutif de base de données. Les points clés en sont :

La base de données évolue en même temps que le code ;
Il faut donc tester en continu la base de données pour permettre un refactoring sans conséquence, comme on le fait avec le code source ;
Il faut outiller les processus autour de la base de données afin d’améliorer la productivité des développements et leur industrialisation.

Les outils existants reposent sur les principes suivants :

Un schéma doit pouvoir être détruit et recréé de manière répétable ;
La version du schéma doit être identifiable ;
La montée et la descente de version doivent être automatisées ;
Les changements appliqués doivent être connus ;
Un changement doit pouvoir être défait ou annulé ;
Un changement précédemment appliqué ne doit pas être modifié mais un nouveau changement doit être créé.

Principes techniques

Sur le plan technique, le fonctionnement des outils de migration est simple. Ils se basent sur une table contenant la version de la base de données. La liste des scripts exécutés est conservée ainsi qu’une empreinte de chaque script afin de détecter une altération d’un script déjà exécuté.

A chaque lancement, l’outil de migration compare la version de la base et les scripts existants et propose la mise à jour le cas échéant.

Il est également possible de « descendre de version » le schéma (fonctionnalité disponible dans quasiment tous les outils). Il s’agit de remettre la base de données dans un état cohérent. Deux cas d’usage :

développement d’une nouvelle fonctionnalité : il est ainsi possible de créer un script et de l’exécuter plusieurs fois (montée de version, test, modification, descente, puis nouvelle montée de version). La descente de version permet ainsi de faire revenir la base de données dans l’état précédent ;
Ré-alignement automatique du schéma avec le code quand la version de la base de données n’est plus la bonne. Ce cas intervient quand il faut corriger un bug sur la version de production ou au passage à une autre branche de développement, ou encore quand un script a été exécuté puis modifié.

Même si la descente de version est utile, elle a néanmoins deux inconvénients. Le premier est que les instructions de descente doivent être écrites à la main. Les outils les plus simples fonctionnent sur le principe où chaque script contient une partie montée de version et une partie descente (voir l’exemple plus bas avec MyBatis). Seul Liquibase est capable de générer les instructions de descente de version grâce à son DSL.

Le deuxième inconvénient est que certaines montées de version ne sont pas réversibles (suppression de table ou de données). Dans ce cas, la descente ne sera possible que jusqu’à la version incluant ce type de modification. L’alternative est de recréer le schéma de zéro, une fonctionnalité que tous les outils proposent et qui est en fin de compte très rapide.

Bonnes pratiques

Les bonnes pratiques poussées par ces outils sont :

Scripts (SQL ou XML pour Liquibase) stockés avec le code source
Une base de données par développeur (réaliste quand la gestion de la DB est automatisée, hors problème de coût de licence) ;
Une base de données commune à l’équipe qui représente l’état complet et stable ;
L’intégration continue déroule l’ensemble des scripts à chaque livraison ;
Un script qui a déjà pu être exécuté ne doit plus être modifié. On risque sinon de désynchroniser les scripts et le schéma La livraison d’un nouveau script est nécessaire dans ce cas. Ce script est un refactoring du précédent. La seule exception est un script buggé qui provoque la perte de la donnée. Il ne faut donc pas que ce script atteigne les autres environnements.

Les outils existants

Liquibase : puissant mais complexe

Liquibase est le plus connu des outils de migration de base de données. Il se base sur les patterns décrits dans le livre « Refactoring database ». À ce titre, il est conçu autour d’une approche théorique par pattern de refactoring.

Le noyau de Liquibase est son DSL basé sur XML qui a les avantages :

d’être compatible avec plusieurs moteurs SQL ;
de donner une sémantique aux opérations (on écrira un <renameColumn> plutôt qu’un alter table) ;
de générer automatique des instructions de rollback (par exemple, un <createColumn> sera compensé par un <dropColumn>).

Liquibase est complet. Il s’intègre à Maven, Grails, Spring et Hibernate et supporte la génération de documentation ou encore la création d’un diff entre schémas.

L’inconvénient principal de Liquibase est une certaine complexité qui ne se retrouve pas dans les autres outils (XML, notion de changelog et de changeset, versionning sur id/auteur/chemin). La courbe d’apprentissage est donc plus élevée que les autres outils se basant purement sur du SQL.

Exemple de changeSet Liquibase :

<changeSet id="1" author="bob">
 <createTable tableName="department">
  <column name="id" type="int">
   <constraints primaryKey="true" nullable="false"/>
  </column>
  <column name="name" type="varchar(50)"/>
 </createTable>
</changeSet>

Les pragmatiques

D’autres outils ne vont pas aussi loin que Liquibase en termes de fonctionnalités et d’abstraction mais leur approche est pragmatique et plus simple. Ils visent avant tout à automatiser la gestion des scripts SQL. Les principaux sont MyBatis Schema Migration, DbMaintain et C5 DB Migration.

Le principe de ces outils est assez simple et consiste à lancer une série de scripts stockés dans une arborescence répartie en version. Les actions sont tracées ce qui permet de connaître l’état du schéma.

Exemple d’arborescence organisée pour DbMaintain :

scripts/01_v1.0/01_products_and_orders.sql
                02_users.sql
        02_v1.1/01_add_barcode_column.sql
                02_drop_itemcode_column.sql

Le schéma de base de données est mis à jour en exécutant :

dbmaintain.sh update chemin/vers/les/scripts

Dans le cas de MyBatis, les instructions de montée et de descente de version sont écrites dans le même script SQL. Exemple :

–// create product table
CREATE TABLE PRODUCT (ID INT, NAME VARCHAR(255));

–//@UNDO
DROP TABLE PRODUCT;

Conclusion

Les outils de migration de base de données permettent une meilleure productivité en levant certaines barrières au changement du schéma des données et ils rendent l’industrialisation accessible.

Les points clés à retenir sont :

Les outils de migration de bases de données nous permettent de gagner en efficacité lors de la manipulation du schéma de la base de données ;
Ces outils fiabilisent les traitements en les automatisant et en les intégrants à l’usine de développement ;
Ces outils apportent de bonnes pratiques permettant un travail en équipe plus efficace ;
Ces outils sont disponibles, simples à mettre en place et OpenSource.

Par extension, on peut imaginer qu’une application puisse se mettre à jour d’elle-même. En effet, il s’agirait de permettre à l’application de lancer les migrations de schémas quand elle démarre. Cette fonctionnalité réduit le temps de mise en production en supprimant l’étape de passage des scripts par les DBA. Liquibase propose déjà cette fonctionnalité.

Notes sur Rework de 37signals

2010-08-29T00:00:00+02:00

Mes notes sur le deuxième livre de la société 37signals, Rework. Il fait suite à Getting Real. J’ai avalé rapidement le livre car les idées sont tranchantes, inspirantes et quelque fois révoltantes. Mais le but est là : réaliser qu’il y a d’autres façons de faire du business. de concevoir son entreprise et de travailler.

Oui, il est possible de concevoir des applications avec moins de fonctionnalités que la concurrence. Non, l’argent des investisseurs n’est pas toujours bon à prendre.

Le livre est composé d’un ensemble de courts chapitres et décrit les recettes qu’applique 37Signals pour ces produits et sa façon d’être en tant que business.

Learning form mistakes is overrated

Apprendre de ses erreurs est surévalué, il vaut mieux apprendre de ses succès. L’échec n’est pas un pré requis du succès. Quelqu’un qui a déjà eu un succès a plus de chance de l’être à nouveau. Ceux qui ont eu un échec n’ont pas plus de chance d’avoir un succès que les nouveau.

[Voir l’article de Leslie Berlin “Try, try again, or maybe not” qui montre que l’échec ne garantit pas le succès mais que le succès participe au succès].

Why Grow ?

Une entreprise avec beaucoup d’employé n’est pas forcément saine. Avec la taille viennent de nouveaux problèmes et une plus grande complexité. Chacun doit trouver la bonne taille pour son business en commençant petit et en voyant comment il grandit.

Start making something

Une idée ne vaut rien tant que vous n’en avez rien fait. La vraie question est de quelle bonne façon on la réalise.

No time is no excuse

Il est toujours possible de prendre quelques heures dans son planning pour travailler sur nos projets. Pas de temps, n’est pas une excuse !

Outside Money is plan Z

Prendre l’argent d’investisseurs peut ne pas en valoir le coût, car :

il fait perdre une partie du contrôle : devoir prendre en compte les ordres d’autres personnes par exemple ;
il occasionne une baisse de qualité au détriment du retour sur investissement rapide ;
Dépenser l’argent des autres est addictif ;
C’est souvent un mauvais coup financier (au début, on n’a aucun levier pour gérer mieux le deal) ;
Le client ne devient plus le premier objectif, mais les objectifs des investisseurs le deviennent ;
Obtenir de l’argent prend beaucoup d’énergie et de temps.

Start a business, not a startup

Le mot Startup signifie être dispendieux, ne pas affronter les réalités du marché, être dans une bulle. Or la réalité est là. Mieux vaut créer un business qu’une Startup.

Embrace constraint

Moins (de temps, d’argent, de personne, d’expérience) est une vraie bonne chose. Cela force à être créatif et à éviter le gâchis.

Illusions of agreement

Essayer de supprimer les niveaux d’abstractions (docs, plans, rapports). Chacun peut imaginer une chose différente de chaque niveau. Seul le résultat (le produit) met tout le monde d’accord.

Reasons to quit

Questions à se poser pour s’assurer que l’on travaille sur des choses qui importent :

Pourquoi faites-vous cela ? A qui cela bénéficie, quelle est la motivation…
Quel problème résolvez-vous ?
Est-ce utile finalement ? Faire quelque chose ou quelque chose d’utile ?
Ajoutez vous de la valeur ?
Est-ce que cela changera quelque chose ?
Que pourriez-vous faire à la place ? Priorité…

Ne pas hésiter à abandonner ce que l’on est en train de faire. Des fois, c’est la bonne chose à faire.

Make tiny decisions

Mieux vaut faire un ensemble de petites décisions qu’une grosse décision. Grosse décision égale de grosses erreurs. Cela n’est pas vrai pour de petites décisions qui seront réparables. Cela n’empêche pas d’avoir de grosses idées et de grands plans, juste que la meilleure façon de les réaliser, c’est par petite décision.

Les meilleurs buts sont ceux que l’on peut atteindre, puisqu’une fois réalisés, on peut construire dessus.

Underdo your competition

Pour battre un compétiteur, pas besoin de faire plus. Viser à moins faire que ses concurrents, mais faire mieux. [Philosophie à la base des produits de 37Sgnals]

Emulate Chefs

Apprendre aux autres ce que l’on connait de son business, ne veut pas dire que les autres pourront nous copier plus facilement (image des chefs cuistot qui donnent leur recette).

Drug dealers get it right

Pouvoir faire essayer un produit (une dose) car s’il est bon les clients reviendront pour se le payer.

Résumés are ridiculous

Un CV est toujours exagéré mais aussi toujours vague. Embauchez sur la base du CV est dangereux. Une lettre de motivation est déjà mieux car il n’est pas possible que le candidat ait envoyé une lettre personnalisée à 100 entreprises.

Years of irrelevance

Les années d’expérience ne veulent pas dire grand chose. Connaitre combien de temps une personne a fait une chose ne vaut pas savoir avec quelle qualité et comment elle l’a fait.

Hire great writers

Le talent pour l’écriture est un critère de choix entre candidats. Savoir bien écrire signifie savoir penser correctement, communiquer et savoir expliquer.

Take a deep breath

Les gens sont des créatures ave des habitudes, c’est pour cela que le changement est souvent vu comme négatif. Une réaction négative est presque toujours plus forte et plus passionnée qu’une réaction positive.

Quand on réalise en changement, il y aura toujours de mécontents. Il faut les écouter, attendre un peu, montrer que l’on est conscient du problème. Souvent les gens s’adapteront.

Decisions are temporary

Une décision n’est pas définitive. Il faut se laisser la possibilité d’y revenir. Décider pour maintenant et s’inquiéter pour le futur plus tard.

Liens annexes

Le site du livre : http://37signals.com/rework/
Les notes d’Ulrich Vachon sur le livre : http://ulrichinaction.blogspot.com/2010/08/retour-sur-rework.html

Construire la nouvelle génération de leaders techniques

2010-08-24T00:00:00+02:00

Transcription de la session de Patrick KUA à l’USI 2010 : Building the next génération of technical leaders.

Définition

Un leader technique est un développeur qui passe 30% de son temps à coder avec l’équipe et 70% en activités de leader. Il a donc deux types de compétences : le développement et le leadership.

Un leader technique ne doit pas être déconnecté de ce qu’il prône, sinon il risque de se baser sur ses opinions plutôt que sur des faits.

Un leader est facteur important pour la réussite d’une équipe.

De mauvais Leaders Techniques

Différents types de mauvais leader technique :

“Benevolent Dictator” : il dicte ce qu’il fait en étant soutenu par ses opinions plutôt que par du concret
“Do it yourself” : ne sait pas déléguer
“Hard Problems are mine” : ne prends que les sujets difficiles (intéressants)

Il existe des développeurs dont la valeur produite est négative (leur impact nette est négative). Il en est de même pour les leaders techniques. Ceux-ci peuvent provoquer une perte d’enthousiasme de l’équipe, de l’apathie ou encore de la déresponsabilisation.

Former de bons leader techniques

Nos systèmes ne savent pas produire de bons tech leads. Le principe de Peter est souvent de rigueur. Ce principe stipule que dans une hiérarchie, un employé tend à s’élever jusque son niveau d’incompétence.

Patrick raconte une anecdote sur des chercheurs italiens qui ont démontré qu’une société est plus efficace si elle fait monter en grade les personnes aléatoirement plutôt qu’en se basant sur le mérite.

Un bon développeur ne fera pas forcément un bon leader technique. Les compétences de ces deux métiers ne sont tout simplement pas les mêmes.

Des compétences différentes

Compétences du développeur :

Implémenter une fonctionnalité
Changer un comportement existant
Ecrire des tests
Coder proprement
Challenger les choses établies
Proposer des solutions annexes

Compétence du leader technique :

Aligner chacun sur une même vision
Résoudre les conflits
Prendre la responsabilité de la livraison
Raconter une histoire
Faire croitre les talents
Faire en sorte que chacun puisse décider
Créer un environnement d’équipe sain

Solutions

Pour avoir de meilleurs leaders techniques, Patrick recommande de :

Reconnaître officiellement les différences entre un développeur et un leader technique : expliquer ce qu’est un leader technique, quelles sont les compétences à acquérir ;
Développer les compétences : un apprenti tech lead peut travailler avec un tech lead expert (pairing, one-on-one), donner le droit explicitement à l’apprenti de faire des erreurs et sans conséquence pour lui (cela maximise sa progression).

Liens

Blog de Patrick KUA

Slides de la présentation faire à la QCon London (PDF)

JPA : les illusions sur les NamedQueries

2010-03-28T00:00:00+01:00

Un certain nombre d’idées reçues existent sur les NamedQueries. On les dit plus performantes car mises en cache, on les dit plus sûres car validées au chargement. Etudions ces points et regardons quels sont les réels avantages des NamedQueries.

Rappel sur les NamedQueries

Une NamedQuery est une requête nommée. Ce n’est pas une nouveauté de la norme JPA car elles existaient dans Hibernate bien avant. Une namedQuery est un moyen de donner un non à une requête JPQL et de la rappeler par ce nom par la suite.

Création :

@Entity
@NamedQuery(name = "findAllCustomers", query = "Select c From Customers c")
public class Client {
        …
}

Utilisation :

public List findAll() {
        return entityManager.createNamedQuery("findAllCustomers").getResultList();
}

Une NamedQuery est plus performante

La rumeur dit qu’une NamedQuery est plus performante car elle est mise en cache.

Techniquement, au démarrage, le moteur JPA va compiler la NamedQuery puis la mettre en cache dans le statementCache des Connections. Cela rappelle fortement les PreparedStatement, non ? Or, Hibernate utilise de toute façon des PreparedStatements si le driver Jdbc le permet. Une NamedQuery ne fait donc pas mieux qu’une requête dynamique, même s’il y a le coût de parsing de la requête si celle-ci est dynamique.

Je n’ai pas trouvé de benchmark entre les deux approches (NamedQuery versus requête dynamique). La principale variable en jeu est le driver Jdbc et donc la base de données utilisée.

Une NamedQuery est validée

Une NamedQuery est validée au lancement de l’application avant d’être soit placée dans le statementCache. Cela permet théoriquement de contrôler la syntaxe JPQL, que le mapping est correct, que les entités utilisées sont annotées et que les colonnes ont bien un attribut (ou un getter/setter) dans les entités.

Dans les faits, cette phase de validation est très limitée (testée avec Hibernate 3.3 et mysql) :

Pour une entité inexistante (“From EntiteInexistante”), une erreur est remontée
Pour une colonne inexistante (“From Client where colonneInexistante is null”), aucune erreur n’est soulevée

Aujourd’hui, je ne vois donc pas en quoi cette phase de validation apporte de la valeur. Si la conversion JPQL vers SQL n’est pas complète, elle n’empêche pas de valider les requêtes sur la base de données cible.

NamedQuery, alors pourquoi ?

Une fois éliminées ces illusions, il ne reste pas grand-chose d’attrayant aux NamedQueries. On sait qu’elles ne sont pas systématiquement pas plus performantes et que la validation n’est pas complète. Il leur reste cependant trois petits avantages :

Les NamedQueries sont réutilisables en plusieurs endroits. Ce cas est principalement utile quand l’entityManager est injecté dans la couche de service (et donc qu’il n’y a pas de couche de DAO) ;
Elles sont chargées au démarrage ce qui permet de diminuer la réponse de l’application au premier accès, mais c’est au détriment du temps de chargement de l’application ;
Les requêtes sont regroupées avec le mapping (@Column…), ce qui permet de faciliter leur écriture.

Pour conclure, je pense que les NamedQueries résultent plus d’une question de goût et de convention d’écriture que d’un réel intérêt technique et factuel.

8 raisons d’aimer Ruby

2009-11-11T00:00:00+01:00

Ruby est un langage qui évolue vite, qui monte fortement et qui est utilisé pour faire de vraies choses (même en prod !). Cet article contient 8 points qui font de Ruby un très bon langage et une plateforme de choix pour réaliser ses futurs projets.

Plus productif

Martin Fowler a fait une synthèse de l’utilisation de Ruby chez ThoughtWorks.

La conclusion est une impression très forte d’une meilleure productivité. La majorité des projets ont ressenti un doublement de leur productivité (une impression car la productivité n’est pas mesurable).

Je vous encourage à lire l’article sur le site de Martin Fowler : ”Ruby at ThoughtWorks”

Meta-Programming

Le meta-programming c’est la génération de code par le code. Cela permet par exemple d’écrire des DSL et de simplifier son code. C’est aussi une arme puissante à utiliser modérément.

L’équivalent de la génération d’une méthode au Runtime en Java donnerait :

void genereUneMethode() {
    /* cette méthode sera ajouté à la classe appelante */
    void nouvelleMethode() {
        // Les commentaires de Chuck Norris sont compilés
    }
}

Duck Typing

Le static typing s’oppose au duck typing. En Ruby, il n’y a pas de notion de type vérifié à la compilation.

Cela veut dire, qu’il est possible d’appeler une méthode avec un Array à la place d’une String. Tant que l’autre objet répond aux méthodes de l’objet attendu, le code est valide.

Le Duck Typing permet d’avoir du code beaucoup plus souple. La forte orientation vers les tests de Ruby en est la conséquence.

Il y a eu beaucoup de débats sur au sujet de « Static typing » contre « Duck typing ». Les auteurs de « Programming Ruby 1.9 » expliquent que le typage statique ne rend pas forcément un code plus fiable et peut diminuer la productivité. (Non, pas de Troll)

Plus d’info sur le duck typing sur Wikipedia.

Closures

Les Closures ont fortement animé les débats autour de leur inclusion (ou pas) dans Java.

Elles font partie de la syntaxe de base de Ruby.

Les Closures sont des méthodes dont l’exécution peut être retardée tout en retenant le contexte quand elles ont été créées. Elles ont plein d’usages mais ne sont pas pourtant pas évidentes à appréhender.

JRuby

JRuby est une implémentation de Ruby pour la JVM. Avantages : un super garbage collector (merci Java), des threads efficaces, multi-plateformes… Il fait tourner des projets Rails sans problème.

L’avantage est également de pouvoir faire du Ruby sur nos serveurs d’app Java, comme Glassfish 3 qui supporte JRuby.

Frameworks novateurs

Rails, Capistrano ou encore Cucumber sont les fers de lance de Ruby et montrent ce que le langage permet de construire.

Rails : c’est le Framework Web qui a donné de la visibilité à Ruby. Rails permet de produire des sites Web très rapidement et de manière simple
Capistrano simplifie fortement le déploiement de projets Ruby et permet par exemple de se brancher sur un SVN pour faire de la mise en production en continue
Cucumber est un framework de BDD simple à prendre en main. Le Meta-Programming apporte beaucoup aux frameworks de tests en permettant l’écriture de DSL de tests

GEM : le packaging facile

Les GEM sont des archives de projet Ruby. Un peu comme nos JAR/WAR/EAR mais en mieux. Une Gem permet de packager son code, ses tests et ses scripts selon un format normé.

On installe une Gem en ligne de commande, idem pour la mettre à jour ou en rechercher d’autres.

Il est également très simple de pousser une Gem sur les repos (voir par exemple l’impressionnant de simplicité Gemcutter)

Une communauté riche (et aussi en France)

Ruby bouge beaucoup et sa communauté est importante. Comme avec Java, il y a des sites de news, des podcasts, des screencasts…

Des news : RubyInside, About Ruby
Des podcasts : RailsEnvy
Des screencasts : Learnivore
Des challenges de programmation : RubyLearning

Les Apéros Ruby ressemblent à nos JUGs. Le prochain a lieu ce jeudi 12. Ils sont moins cadrés que les JUGs mais tout aussi intéressants : Coding Dojo, Lightning talk…

Conclusion

Ruby dispose de nombreux atouts pour plaire, même face à ses concurrents dynamiques ou statiques (Scala par exemple).

Une des principales qualités de Ruby est sa communauté vivante et innovante. Découvrir une plateforme comme Ruby donne un nouvel élan et permet de faire fonctionner ses neurones sur d’autres paradigmes.

J’ai choisi Ruby pour toutes ces bonnes raisons et il y en a encore bien d’autres à découvrir.

Tests d’intégration : quid de la base de données ?

2009-10-12T00:00:00+02:00

La base de données est un élément important des tests d’intégration. Les deux questions à se poser sont :

Puis-je utiliser une base de données embarquée ?
Puis-je désactiver les contraintes d’intégrité ?

Base de données embarquée ou non ?

C’est Rod Johnson qui en parlait sur InfoQ : ”System Integration Testing using Spring” : une base de données embarquée est inutile dans la plupart des cas.

L’argument majeur en faveur d’une base embarquée est le travail en mode déconnecté. Dans une équipe disséminée (télétravail, multiples bureaux, déplacement fréquent), ce type de base fait l’affaire.

Mais il y a certains inconvénients importants :

Moteur SQL différent de la cible : il est possible de certaines requêtes s’exécutent sur la base embarquée mais pas sur le type de base utilisée en Prod (différences d’implémentation SQL par exemple, expérience vécue avec SQL Server) ;
Debugage difficile : si la base meurt à la fin des tests, il devient difficile d’étudier les opérations faites et d’étudier pourquoi une requête ne fonctionne pas.

Je vois peu d’intérêt aujourd’hui à utiliser une base de données embarquées si c’est pour se rendre compte qu’on ne valide pas un comportement similaire à celui de production. Créer une base par développeur sur Oracle ou autre, n’est pas si difficile.

Un inconvénient d’une base standard est qu’elle nécessite d’être maintenue (passage des scripts), mais cela est automatisable grâce à des outils comme DBMaintain ou LiquiBase.

Contraintes d’intégrité actives ou non ?

Filip Neven, le créateur d’Unitils et de DbMaintain, pointe le problème sur son blog (traduction libre) :

Les gens pensent que la désactivation des contraintes produit une sérieuse dévaluation des tests, car le code qui a été validé avec succès par les tests unitaires pourrait ne pas fonctionner avec une base de données normales - Filip Neven

La chose à retenir est : “il faut limiter au maximum les données de test”.

Autrement dit : le moins de données de test il y a, le plus maintenable sont les tests.

Filip Neven résume parfaitement la situation :

Les tests doivent valider un fonctionnement et non vérifier l’intégrité de la base
Les tests unitaires ne sont pas le bon outil pour découvrir des problèmes de contraintes
Dans la plupart des cas, d’autres tests, comme les tests fonctionnels, permettront de découvrir les problèmes de contraintes
Désactiver les contraintes est un gain de temps important pour l’écriture des tests

En effet, les jeux de données ne font généralement que croitre. Une fois qu’une donnée est ajoutée à un jeu de tests, il devient laborieux de savoir si cette donnée est utilisée d’une manière ou d’une autre et donc de la retirer.

En désactivant les contraintes d’intégrité, il devient possible que les jeux de données ne contiennent que les données utilisées dans les Where et dans les jointures ; c’est-à-dire les données réellement utiles. Cette façon de voir les choses simplifie énormément la maintenance des jeux de tests. Finis les fichiers DBUnit.xml qui contiennent 80% de données dues aux colonnes not-null donc inutiles pour le test courant.

Unitils/DbMaintain propose une méthode rapide pour désactiver ces contraintes (not null et foreign key).

Une fausse sensation de sécurité

Il faut se poser la question : est-ce que l’on nuit à la qualité de nos tests si nous touchons à l’intégrité de la base de données par la désactivation des contraintes ?

En effet, si les tests passent sur une base qui sera identique à la production (colonnes non nulles, clés étrangères, utilisateur non privilégié), alors nous validons en totalité le fonctionnement cible. Au contraire, si nous avons désactivé les contraintes, alors nous risquons de rencontrer des erreurs plus tard dans la vie du projet, et donc que cela soit plus dur à corriger.

La réponse est double :

Oui, nous nous écartons du fonctionnement cible (like “Prod”) en modifiant le comportement de la base de données ;
Non, ce la ne nuit pas à la qualité des tests.

Pourquoi ?

Tester “comme en prod” donne un faux sentiment de sécurité. Les erreurs susceptibles de ne pas être détectée avant la production ne sont pas des problèmes récurrents. Ok, vous allez détecter qu’il manque un “GRANT select” mais cette erreur ne se reproduira pas.

D’autant plus que les tests d’intégration seront complétés par les tests fonctionnels et que détecteront les erreurs de not-null/foreign key laissées derrière.

Conclusion

Je suis aujourd’hui pour une gestion “Agile” de la base de données utilisée pour les tests. La bonne voie est pour moi d’éviter l’usage d’une base embarquée car il y a trop de différences entre moteurs SQL mais de désactiver certaines contraintes sur la base de test afin de faciliter le vrai travail : l’écriture de test qui valident les requêtes (le DML) et non les restrictions SQL (le DDL).

Et vous, avez-vous d’autres recommandations pour vos tests d’intégration ?

MoreUnit : les tests plus vite sous Eclipse

2009-07-29T00:00:00+02:00

J’ai découvert aujourd’hui le plugin MoreUnit pour Eclipse. Celui-ci accélère grandement le passage code/test et la création de tests.

Il permet de :

Passer d’une méthode à ses tests et des tests à la méthode testée (ctrl+j depuis une méthode)
Montrer les méthodes et classes testées
Créer un test pour la méthode en cours (ctrl+u) [même si ça ne remplace pas “Ctrl+3 > New Junit test case”]
Changer le nom et déplacer les tests lors d’un refactoring

Je le trouve vraiment pratique pour switcher d’une méthode aux tests et inversement. Il montre également les méthodes et classes qui ne sont pas testées et synchronise les tests quand je renomme une méthode. Un vrai gain de temps ! (c’est mon manager qui va être content).

Quelques infos

MoreUnit est compatible avec Eclipse 3.5 (Galileo). Il fonctionne parfaitement avec un project Maven.

Le site : http://moreunit.sourceforge.net

L’update site : http://moreunit.sourceforge.net/org.moreunit.updatesite/

Astuces

La configuration qui fonctionne pour un projet Maven et Junit 3.x est :

Directory for test cases : src/test/java
Test prefixes : vide
Test suffixes : Test
Enable flexible naming of tests : coché

Pour voir le marqueur sur les méthodes (caché par d’autres annotations Eclipse), il est intéressant d’activer le soulignement des méthodes ou :

Préférences > Editors > Text Editors > Annotations > MoreUnit Marker > Cocher “Test as Suiggly line”

Il est possible de créer une nouvelle méthode de test en appuyant plusieurs fois sur ctrl+u depuis la méthode de test.

La vue qui montre les tests manquants fonctionnent partiellement donc je ne m’en sers pas.

Critique du livre “Passionate Programmer”

2009-07-19T00:00:00+02:00

Dans ”The Passionate Programmer”, apprenez comment gérer votre carrière de geek, comment booster votre vie professionnelle, et avoir du fun et l’argent du fun.

L’auteur, Chad Fowler, établit une stratégie pour planifier et créer une vie réussie dans le développement logiciel. Il explique comment prendre le contrôle de sa carrière, s’activer pour en faire une réussite.

Sa carrière comme un business

Il faut se voir comme un produit qu’il faut construire et vendre

Une entreprise ne nous emploie pas parce qu’elle nous aime, mais pour faire de l’argent (pour en gagner ou ne pas en perdre). En nous embauchant, la société investie en nous. Donc le challenge est de devenir un bon investissement pour elle, être rentable. Il faut juger ses performances par rapport à notre valeur ajoutée pour la société.

C’est sur cette notion de R.O.I. personnelle que Chad Fowler conseille de se poser régulièrement cette question : “Suis-je un bon investissement ?”.

Ta carrière, c’est ta vie (ou presque)

Vivre une vie remarquable n’est souvent pas un but quand on débute sa carrière. C’est beaucoup plus facile de suivre le courant et de se laisser guider par les autres. Vous avez déjà entendu le commercial vous dire : “C’est la mission qu’il te faut” pour être déçu dès les cinq premières minutes de l’entretien.

Le travail représente 50% du temps éveillé. Si vous n’aimez pas ce que vous faites au boulot, ce chiffre devrait vous choquer. Cela veut aussi dire que l’on passe plus de temps avec ses collègues qu’avec notre femme !

Donc aimer son boulot, c’est aussi aimer sa vie. On se leurre souvent en cherchant simplement le prochain job mieux payé qui ne nous apportera pas grand-chose. Il faut chercher la satisfaction : “qu’est-ce qui me fait plaisir ?”.

Quelques conseils tirés du livre

La Roadmap personnelle

Chad Fowler conseille de se construire une liste des compétences que l’on veut acquérir. Cette liste est une roadmap équivalent à celle d’un projet qui permettra de planifier et de définir vers où on veut aller. L’exercice peut se faire sur son passé : de où je viens, ce que j’ai appris à chaque fois jusque maintenant.

Ne pas mettre tous ses oeufs dans le panier de quelqu’un d’autre

Java, Java et rien que Java ? Pour l’auteur, l’intégrisme technologique est une mauvaise chose. Chaque techno, langage, framework progresse, stagne et décroit. Pour éviter d’investir sur un mauvais choix (une techno en déclin), il faut étudier le marché et dans tous les cas se diversifier.

Une entreprise a les moyens (argent et temps) de passer d’une techno à une autre. Ce n’est pas le cas pour un individu, car il n’aura pas les ressources pour le faire (moins d’argent, moins de temps).

S’élargir à d’autres technos, c’est limité les risques. Comme en bourse, il s’agit de diversifier son portefeuille.

Savoir dire Non

Oser dire Non à son client ou à son manager est un bon challenge quand on commence sa carrière. Nous avons tous un devoir de conseil qui passe, parfois, par l’émission d’un Non motivé. C’est assez dur à faire car on se sent souvent en infériorité (par exemple, développeur contre client). Il faut être courageux pour savoir dire Non.

D’autre part, savoir dire Non renforce notre Oui car les personnes savent alors que cette réponse est sérieuse et motivée.

Petit bémol, dans certains contextes un “Oui, mais” permet de sauver sa peau.

Mon avis

J’ai aimé ce livre car j’ai découvert un nouveau point de vue intéressant et une vision du business différente de la vision traditionnelle. On ne vit pas dans un monde de Bisounours comme diraient les Cast Codeurs.J’en tire de nombreux conseils et des actions afin de me remettre régulièrement en question et progresser.

Ce que je n’ai pas aimé :

Certains chapitres sont trop simplistes ou évidents. Mais, sur 53 chapitres, c’est normal que tous ne soient pas bons.
Beaucoup d’anecdotes divertissantes sur l’auteur et la musique mais quelquefois trop écartés du sujet (Chad Fowler est un ancien musicien professionnel)

Note finale : 7/10

Will code for food

Pour l’anecdote, la première version du livre était intitulée : ”My Job went to India” (ce qui a bien fait rire mes collègues de Singapour).

Sur la couverture, on voit un homme tenant une pancarte “Will code for food”.

Gradle : vos builds aux petits oignons

2009-06-26T00:00:00+02:00

Gradle est un outil permettant d’écrire ses scripts de build en groovy. Il nous a été présenté hier soir chez Zenika par son créateur, Hans Dockter.

A première vue, c’est un outil puissant et extrêmement souple. Il apporte beaucoup de bonnes idées et on s’amuse vite à le comparer à Maven.

Alors, Gradle pour tous ou seulement pour votre pire ennemi ?

Donner du sens à vos builds

Gradle, c’est avant tout un DSL en Groovy pour décrire ses builds. Il bénéficie donc des améliorations du langage comme les closures et d’une syntaxe épurée.

Hans Docker insiste sur ce point : un script de build qui épouse votre projet est beaucoup plus intéressant qu’un projet où la structure est imposée par l’outil de build (comme Maven).

Il fait un parallèle avec « l’Anemic Object Model » de Martin Fowler et le DDD dans le sens où votre build se décrit lui-même et ses buts se documentent eux-mêmes.

Gradle propose donc de donner du sens à nos builds en permettant d’améliorer la compréhension du système et des tâches réalisées.

Hans oppose les notions de « Langage de build » (Gradle) et de « framework de build » (Maven). L’un offre la flexibilité, l’autre pose un cadre défini.

Attention, outil coupant

Vous avez déjà eu des projets complexes à construire, avec par exemple de la génération de code ou des fichiers à emboiter. Vous vous êtes battu avec Maven et vous avez souvent perdu (c’est mon cas, je n’ai pas encore ma ceinture noire de Maven).

Gradle vient directement répondre à ce besoin : simplifier les builds complexes. C’est d’ailleurs son moto : « Make the impossible possible, the possible easy, and the easy elegant”.

Discussion faite avec Florent Ramière de Jaxio, nous sommes du même avis : Oui, Gradle est adapté pour les builds complexes mais 80% ont des besoins simples, réalisables avec Maven.

Gradle est un outil puissant qui permet de faire précisément ce que vous voulez. Cette flexibilité extrême permet aussi de faire n’importe quoi, y compris se tirer une balle dans le pied. Maven a pris beaucoup d’ampleur en proposant des conventions et une structure commune (par exemple, les phases et les packages).

Franchement, c’est un bonheur de s’y retrouver entre différents projets. Malheureusement, ces conventions ne peuvent pas se conformer à tous les projets.

Un peu jeune

Gradle est « production ready » comme le dit Hans. Il est utilisé par certains gros projets aux besoins complexes. Pourtant, il est encore en fort développement, signe de bonne santé, mais aussi manque de maturité. Le projet n’a pas encore un an.

Il lui manque un certain nombre de fonctionnalités avant de devenir réellement complet, par exemple le support d’autres langages que Java ou encore celui de Netbeans (mais « Why bother ? » comme dirait Antonio Goncalves).

Bref, il y a du travail et ce n’est pas la crise comme l’indique la Roadmap.

Mon avis

J’aime :

L’usage d’un DSL pour donner du sens à ses scripts de build ;
La puissante de ce DSL pour faire des choses qui font rêver (par exemple, une tâche à accès à la liste des tâches suivantes afin de pouvoir modifier son comportement) ;
La réutilisation des tâches Ant facilement, ce qui veut dire qu’on peut presque tout faire ;
La flexibilité offerte. J’adore les outils coupants qui me permettent de faire ce que je veux comme je le veux. Mais je reconnais que je n’ai pas rencontré souvent de besoin très exotique ;
Le Gradle Wrapper qui permet de dérouler un build Gradle sans aucune installation préalable (il télécharge ses dépendances automatiquement).

Je n’aime pas :

Le fait de ne pas avoir une intégration/réutilisabilité complète avec Maven (la faute aux Plugins apparemment) ;
Le trop peu de convention, même si c’est le but du projet, car les conventions permettent d’entrer dans l’entreprise pour éviter que chacun puisse faire ce qu’il veut. Adieu structuration et normalisation entre projets. Mais rien ne dit qu’on ne puisse pas poser une structure à respecter. Ce serait l’équivalent des normes de codages ;
Il n’est pas à mettre entre toutes les mains. Gros risques de faire dans le non maintenable (quid du debugging, du diagnostique, des performances ?)
La jeunesse du projet qui ne garantit pas encore une pérennité suffisante pour l’entreprise.

Pour allez plus loin

Zenika a publié des articles à propose de Gradle ainsi que deux podcasts. Le deuxième podcast couvre bien les avantages et inconvénients de Gradle :

Les articles ;
Les podcasts.

Nicolas Martignole du Touilleur Express a fait un compte rendu de la présentation faite à Jazoon. Les commentaires sont également intéressants. J’aime beaucoup le « Gradle as the assembly language for builds » de Vincent Massol.

Les limites de Wicket

2009-05-03T00:00:00+02:00

Connaître un framework, c’est aussi reconnaître ses limites et ses points faibles. Pour Wicket, il m’a fallu creuser profondément. J’ai interrogé les pros de Wicket présent à cette soirée, Carl Azoury, un des boss de Zenika et Martin Dashort, committer Wicket.

Quelles sont les limites de Wicket ? Quelles sont leurs solutions ?

Mise à jour le 02/06/2010 : une discussion intéressante sur les limites de Wicket a eu lieu sur les forums developpez.com. Il y a des arguments intéressants et de vrais retours d’expérience.

Un mot sur la conférence Wicket/Zenika

L’invité de la soirée Zenika du 29 avril était Martin Dashorst, un des committers principaux de Wicket et coauteur du livre « Wicket In Action », dont vous trouverez la critique ici-même.

Martin a réalisé une introduction d’une heure à Wicket en montrant ses principaux avantages et les façons de faire les choses. La présentation a été convaincante mais j’aurai aimé plus de détails et d’exemples sur le futur de Wicket.

La soirée a encore été une nouvelle belle réussite pour Zenika, après les très bonnes sessions Terracotta et Lean.

Le markup n’est pas toujours prévisualisable

Quand votre application commence à être découpée en composants (et c’est le but final de Wicket), le markup HTML est lui aussi scindé en différents fichiers. Adieu pré-visualisation, le Designer peut recommencer à s’arracher les cheveux comme avec ces bonnes vieilles JSP.

Un designer intervient principalement au début du projet. C’est donc à ce moment-là que la pré-visualisation est importante. Wicket n’est pas un frein dans cette situation, car il offre trois choix pour gérer son markup. Quand le nombre de pages est inférieur à dix, les auteurs conseillent tout simplement de dupliquer le code dans toutes les pages (hé oui, pour moins de 10 pages, le R.O.I. nous dit : « fais-le avec tes mains »). Au-delà, Wicket propose d’utiliser le Markup inheritance qui est simplement une hiérarchie de classes et de markup qui composent le layout final. Finalement, il est possible de créer un ensemble de Panels pour découper ses écrans, mais la pré-visualisation devient difficile (inclusion de code HTML entre les balises Wicket qui sera ignoré au runtime).

Wicket ne tient pas la charge

Wicket stocke beaucoup d’informations en session et il est donc trop lourd pour gérer plusieurs milliers d’utilisateurs simultanés. Le versionning des pages qui conserve l’historique de l’état des pages ouvertes par l’utilisateur en est le principal responsable. Martin a quelques références de sites à fort trafic, mais un vide se fait sentir à ce sujet.

Oui, Wicket stocke beaucoup d’infos en session mais celles-ci sont nécessaires pour les fonctionnalités avancées comme la gestion du back button et les requêtes Ajax. Wicket propose un tas d’optimisation et un modèle de programmation qui permettent d’alléger cette charge. Par exemple, les LoadableDetachableModel permettent d’attacher et de détacher les objets à chaque affichage plutôt que de maintenir la donnée dans la session ;
Certes certaines pratiques recommandées par Wicket sont assez dures à comprendre. Dans mon cas, je me pose souvent la question : si je mets mon attribut là, est-ce qu’il sera sérialisé en session avec ses dépendances ? Pour s’en convaincre, l’article suivant illustre certains de ces cas : « Wicket Anti-Patterns: Avoiding Session Bloat ».

Tester une application Wicket est difficile

Le projet WicketTester est intégré au framework même s’il n’a pas été développé par l’équipe principale. D’après Martin, il s’écarte un peu du modèle du framework lui-même et souffre de certaines limitations. Parmi celles-ci, il faut connaître le chemin complet d’un composant dans la hiérarchie pour y accéder (exemple : pour tester un lien d’un form d’un panel, il faut connaître cette hiérarchie pour cliquer sur le lien).

En réalité, ces limitations ne sont pas bloquante, juste gênantes. Certains projets Wicket utilisant WicketTester ont une couverture de code importante. Martin nous a montré après la conférence des exemples de tests réels assez convainquant. Ca reste proche de l’API Selenium (sans ses bugs aléatoires, j’espère);
Wicket 1.5 devrait apporter un framework de test plus complet et basé sur une partie du travail accomplit sur JDave. JDave est un framework de BDD (Behavior Driven Development) qui permet de spécifier par l’exemple les comportements des objets. Plus d’infos sur : http://www.jdave.org/bdd-wicket/;
L’article « Testing Wicket with FitNesse » illustre également certains problèmes rencontrés et leurs solutions pour l’écriture de fixture FitNesse.

Les URLs générées sont moches

Wicket génère par défaut des URL de type : http://cheer.com/shop?wicket:interface=:0:detail1::ILinkListener::

Moche, non ? Et surtout pas facile à retenir et pas terrible pour le référencement. Ces URL contiennent de plus un numéro de version propre à la session courante. De ce fait, il sera impossible de la bookmarker.

Problème récurrent des frameworks Web, la génération des URL par Wicket peut être configurée par pas moins de six stratégies d’encodage. Un exemple tiré du livre, la stratégie « IndexParamUrlCodingStrategy » est Restful car elle génère une URL de type : http://cheesr.com/cheeses/edam, où « edam » est le paramètre d’indice 0. D’autres exemples figurent sur le Wiki.

Spring Security s’intègre mal à Wicket

Intégrer SpringSecurity/Acegi à une application Wicket n’est pas une sinécure. SpringSecurity réalise ses contrôles essentiellement à partir d’URLs (par exemple : « l’utilisateur Hadopi est-il autorisé à accéder à www.thepitatebay.com »). Hors les URL de Wicket contiennent toutes par défaut un identifiant de version, ce qui limite fortement l’usage de SpringSecurity.

Wicket dispose de son propre framework de sécurité orienté composant (au lieu d’être orienté URL) donc il est plus granulaire. Avec ce système, Martin nous explique qu’il est très simple de ne pas afficher un lien si l’utilisateur n’a pas accès à sa destination. Illustration :

Link adminPage = new Link("admin") {
    @Override
    public void onClick() {
        setResponsePage(AdminPage.class);
    }

    @Override
    public boolean isVisible() {
        UserSession userSession = UserSession.get();
        return userSession.getUser().isAdmin();
    }
};

Pour aller plus loin et centraliser les autorisations, Wicket propose d’autres projets. Wicket-auth-roles couvre des besoins simples et Wicket-security-wasp/Wicket-security-swarm émule JAAS. L’article suivant compare ces solutions : « Security Framework comparison » ;
Au passage, il est même possible de développer ses propres annotations et de les poser sur les composants à protéger. Wicket, ce n’est que du Java après tout :-)

Wicket n’est pas un framework managé

Avec Wicket, vous allez réapprendre à utiliser les mots-clés « new » et « extend » pour lier vos composants. Il n’y a pas d’injection de dépendances natives entres les composants.

Et c’est tant mieux car on n’en a pas besoin ! Avec Wicket, il y a pas de Xml pour pseudo-découpler vos composants. Et franchement, vous en avez eu souvent besoin ?
Côté Injection de dépendances, Wicket s’intègre très bien avec Spring et Guice. Notamment, il propose pas moins de trois solutions pour utiliser des beans Spring (service locator, proxy et annotation). Plus d’infos sur la page du Wiki dédiée à Spring.

Wicket n’est pas outillé

Même si Wicket enlève sa part de Xml, il nous reste quand-même les pages en Java avec leur markup Html et leurs ressources Xml. Il peut devenir vite fastidieux de manipuler ces fichiers séparément alors qu’ils ne forment en réalité qu’une seule page.

En réalité, il n’y a pas vraiment besoin d’outils pour manipuler Wicket. La plupart des choses se passent en Java. Le markup doit être valide (bons identifiants) sinon Wicket refusera de se lancer ce qui permettra de valider son code ;
Si vous cherchez vraiment un outil, Wicket est assez bien supporté par les IDE. Pour Eclipse. WicketBench propose quelques fonctionnalités intéressantes, mais il n’est pas toujours stable.

L’intégrable avec des frameworks JavaScript est difficile

A l’usage, on se rend compte que l’intégration manuelle avec le JavaScript n’est pas évidente. Toujours ces histoires d’Id générés qui rendent plus compliqué un framework orienté Composants qu’un bon vieux Struts.

Comme toujours, un framework Javascript est d’un grand secours et Wicket ne fait pas l’impasse là-dessus. Wicket s’intègre aux principaux frameworks JavaScript : YahooUI, Dojo, Scripaculous ou encore JQuery.

L’exemple suivant montre l’usage de WiQuery qui intègre Jquery/JQueryUI à Wicket au travers des Behaviors, qui permettent d’ajouter des comportements à des objets existants (dont des attributs JS ou Ajax) :

public MyWebPage() {
    Label example1 = new Label("example1", "Example 1"); 

    example1.add(new WiQueryEventBehavior(new Event(MouseEvent.CLICK) {
        @Override
        public JsScope callback() {
            return new JsScope() {
                @Override
                protected void execute(JsScopeContext scopeContext) {
                    scopeContext.self().chain(CssHelper.css("border", "1px solid red"));
                }
            };
        }
    })); 

    add(example1);
}

Conclusion

Ah Wicket. Quand l’utiliser ou s’en passer ? Une chose est sûre : aucun framework n’est « One size fits all ». Ainsi connaître les limitations de Wicket et leurs solutions est un bon moyen de mieux l’utiliser et de l’apprécier. Et moi, j’adore.

Vous aussi, vous avez certainement rencontré des problèmes et touché les limites de Wicket. Lesquelles ? Les avez-vous trouvées bloquantes ?

Retour du Barcamp “Travailleurs Du Web”

2009-04-27T00:00:00+02:00

Samedi a eu lieu le premier Barcamp TDW destinés aux personnes travaillant dans le Web ou s’y intéressant : designers, développeurs, webmasters, curieux et même un mec qui fait du Java (vous avez deviné qui).

Le but du Barcamp était de faire rencontrer les acteurs du Web afin d’échanger des points de vues et des idées, ainsi que de passer un moment convivial. Mission réussie.

Les sessions étaient nombreuses et j’ai assisté à :

Web Mobile
Freelance
SCOP
Vie/Travail

Web Mobile

Le Web sur mobile est avant tout un moyen d’attirer le client, en assurant une continuité totale. L’équivalent du “partout, toujours”.

Rémi d’Hekletic déclare que 60% du Web mobile se fait par un IPhone. Le reste étant divisé en Symbian, Windows Mobile, Black Berry et Androïd.

J’ai tenu mon rôle en expliquant que Java était donc disponible (presque) partout.

Oui, l’Iphone se porte bien avec ses 1 milliard d’application téléchargés en deux ans (cf cette news sur techcrunch).

Les principales contraintes de développement sur mobile sont :

la taille de l’écran
la rapidité de réception/envoi des données
la puissance du processeur

Pour Rémi, la principale limitation est le débit de réception. En effet, il faut éviter de streamer trop de données au risque de gâcher l’expérience utilisateur.

Certaines applications sont designées entièrement au type de téléphone. Facebook est cité et démonstration à l’appui : le Facebook de Symbian et celui de l’Iphone sont bien deux interfaces complètement distinctes. Du point de vue financier, seulement certains éditeurs vont se permettre de développer une interface par téléphone. A quand une homogénéisation ?

A ma question : “le Web Mobile pour quels usages ?”. Je n’ai pas eu de réponse claire : oui pour les mails, la géo-localisation, les news, twitter… Mais est-ce tout ? Pas de réponse franche, mais une chose est sûre : le mobile est une nouvelle console de jeu et sert aussi de gadgets (avec en preuve cette application IPhone qui affiche des chiens en train de lécher l’intérieur de l’écran, si si, j’vous jure, 79 centimes sur l’AppStore). Quasiment tout le monde autour de la table a déjà acheté plusieurs applications sur Iphone.

Le Wap est mort, je suis triste. En plus, j’ai enterré mon minitel la semaine dernière.

Freelance

Les freelances ont, entre autres, certains problèmes comme le manque de crédibilité (statut, ancienneté) et le risque personnel.

Quelqu’un raconte que sa société s’est fait auditer de A à Z par son client, une grande marque de luxe. Le but était de rassurer le client sur sa solidité financière. Cette garantie de “pouvoir être là dans 3 ans” n’étant apparemment pas réaliste pour un freelance. Ce que le client n’a jamais su, c’est que le projet a finalement été développé par des indépendants. Donc la “continuité” n’est de toute façon pas assurée.

Passer freelance est toujours difficile, tout le monde est unanime.

Il peut donc être intéressant de transiter de son activité salarié vers le statut de Freelance en passant par celui d’auto-entrepreneur, afin de pour tâter le terrain, travailler avec des clients et se faire connaître.

Le statut d’auto-entrepreneur permet d’avoir une activité annexe sur laquelle on ne paye des charges que s’il y a chiffre d’affaire. Dans les services, le chiffre d’affaire max est de 32000 euros (au-delà, il faudra changer de statut).

Mais attention, on me souffle à l’oreille que le statut d’auto-entrepreneur engage la responsabilité illimité de l’entrepreneur. Ouch ! A lire dans “Odyssée d’une traducteuse au régime - l’entreprenariat, volet 2”.

Au niveau de la concrétisation, un freelance jouît d’une plus grande liberté. Tous les freelances à la table organisent leur journée à leur convenance. La liberté est en effet un des attraits du statut. Travailler tôt ou tard, faire sa veille quotidienne, coder, toutes ces tâches s’enchaînent différemment selon les individus.

La crise ! Ah, le gros mot. Au final pas grand monde pour me dire que la crise se fait durement sentir. Grosse surprise, pour Sébastien d’Altrasys, la crise lui a apporté de nouveaux clients. Ceux-ci ne veulent plus payer pour des licences Windows onéreuses, ils veulent de l’OpenSource car c’est gratuit et non parce que c’est mieux.

Au niveau des contrats/paiement, la méthode “forfait puis à l’heure travaillée” semble convenir. Certaines personnes ont eu des problèmes de règlement quand le client fait le difficile pour payer la dernière partie de l’ardoise. Il faut bien s’arranger pour que cette dernière partie soit le “bonus”, le bénéfice. Autrement dit, il ne faut pas compter dessus pour vivre et continuer à exercer son travail.

SCOP

Cette session visait à échanger autour du statut de SCOP (Société Coopérative de Production). C’est, de façon simplifié, une forme d’entreprise à but social (par exemple, tous les salariés ont droit de vote).

Mes notes ne seront jamais aussi complètes que la documentation de cette forme d’entreprise. Je vous renvoie à :

Wikipedia pour la définition de SCOP
Un de mes compte-rendus traite aussi du sujet : Ma petite entreprise ne connaît pas la crise

Cédric, un des fondateurs de la Scop ”La Green Team”, était présent et nous a brièvement parlé de sa société. Comme son nom le dit, sa Scop est axée développement durable dans ses statuts. Ses salariés allouent une partie de leur temps (2 jours par mois) à former leur membre, assister aux formations des membres et participer bénévolement à un projet de développement durable. La Scop apporte également une marque et une vision. Elle se rémunère quand elle apporte une affaire.

Je pense que le statut de Scop est un moyen de faire passer ses idées. L’orientation sociale et l’axe donné, comme dans le cas de La Green Team, sont pour moi un vrai moyen de faire du business en allant plus loin dans ses idées. Faire des affaires en changeant le moyen de le faire.

Vie/Travail

Cette session a fortement dévié de son but initial et on a donc fait pas mal de prospective.

On s’interroge sur pourquoi tant d’intérêt pour le Web. Car Internet réduit avant toutes les distances et les intermédiaires. A tel point qu’il est dorénavant possible de trouver des fournisseurs, presque qu’au même prix que des fournisseurs des pays à bas coups de mains d’oeuvre. Le fondateur de LaFraise est cité, son nouveau business aura des partenaires français sans payer beaucoup plus qu’en allant les chercher en Chine.

Sous cet angle de la réduction des intermédiaires, Babozor de TDW imagine une nouvelle version de la politique où le contact avec le citoyen est quasi-direct. L’idée est intéressante. Il a lui-même essayé de prendre rendez-vous avec un député sans avoir de vrai succès. Les contacts peuvent se faire mais ils ne sont pas faciles.

On parle également d’identité des entreprises. Il est possible de devenir l’identité d’un domaine ou, autrement dit, la personne de référence d’un secteur, d’une marque ou d’une entreprise. Babozor explique cette personne qui twittait tout ce qui se faisait sur CNN et qui est ainsi devenu le représentant CNN non-officiel. Son compte Twitter a depuis été racheté par la société. Et vous, deviendrez-vous un porte-parole d’une marque par votre activité sur le Web ? Y a-t-il des places à prendre ?

Pour revenir au sujet initial côté horaire de travail, Sébastien d’Altrasys se fixe sur ceux des bureaux : 9h-18h. Il souhaite limiter ses activités afin de ne pas dépasser et s’offrir une vraie coupure travail/Vie. Cela n’est pas facile quand on travaille de chez soi. De même, il ne répondra qu’exceptionnellement aux mails tardifs à 11h du soir afin de ne pas envoyer de message “je suis corvéable, allez-y à n’importe quelle heure”.

Conclusion

Une bonne journée destinée au Web et pour les gens du Web. Ces sessions m’ont permis de rencontrer des gens beaucoup plus créatifs que la moyenne. Il y avait une forte concentration de freelances, de fondateurs de sociétés innovantes et de codeurs. De quoi animer plusieurs jours en sujets de toutes sortes. (D’ailleurs, je crois bien qu’il y avait aussi assez à manger pour plusieurs jours. Oh ces rillettes, qu’elles étaient bonnes !).

Si vous voulez continuer l’aventure, rendez-vous sur le site des travailleurs du web.

Merci à Babozor et à Fred pour la très bonne organisation.

Les photos

Voici un échantillon des photos réalisés par Seb. Vous en trouverez d’autres sur son site.

Démarrer avec JPA, Spring, Maven et Glassfish

2009-02-26T00:00:00+01:00

Je vous propose un projet qui permettra de démarrer avec JPA et Spring, de déployer sous Glassfish v3 et de lancer les tests d’intégration sans serveur d’application, le tout avec le pom Maven qui va bien.

JPA

Le projet contient deux configurations de JPA : l’une pour le déploiement, utilisée par Glassfish, l’autre pour les tests d’intégration.

Les PersistentUnits sont configurés par :

le fichier « persistence.xml » pour Glassfish, l’attribut transaction-type doit valoir « JTA », sinon Glassfish refuse de démarrer ;
le fichier « orm.xml » pour les test. L’Attribut transaction-type vaut « RESOURCE_LOCAL »

Spring est lui aussi configuré en deux fois (déploiement et test). Grâce aux classpath de Maven, le bon fichier est sélectionné.

Le fichier JPA pour le serveur est le suivant :

<jee:jndi-lookup id="dataSource" jndi-name="jdbc/springify" />
<jee:jndi-lookup id="entityManagerFactory" jndi-name="persistence/springify"/>
<tx:jta-transaction-manager />

Le fichier JPA pour les tests d’intégration est le suivant (un peu plus copieux) :

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"
    p:driverClassName="com.mysql.jdbc.Driver" p:url="jdbc:mysql://localhost:3306/springify"
    p:username="root" p:password=""/>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
    p:dataSource-ref="dataSource" p:persistenceXmlLocation="META-INF/orm.xml"
    p:persistence-unit-name="springify" p:jpaVendorAdapter-ref="jpaAdapter" />

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager"
    p:entityManagerFactory-ref="entityManagerFactory" />

<bean id="jpaAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"
    p:database="MYSQL" p:showSql="true" />

Glassfish

Côté Glassfish, il suffit de créer une nouvelle DataSource. Rien de très compliqué. Si vous utilisez MySQL, veillez à utiliser le moteur InnoDb afin que les transactions soient activées (sinon pas de rollback). Par exemple :

CREATE TABLE Tag (
    id      INT NOT NULL AUTO_INCREMENT
    ,label  VARCHAR(256) NOT NULL
    ,PRIMARY KEY (id)
) Engine=InnoDB;

NoClassDefFoundError: javax/interceptor/InvocationContext

Cette erreur est visible au lancement de Glassfish mais elle n’impacte pas le fonctionnement de l’application. Apparemment, un Glassfish v3 n’aurait pas les Jars EJB par défaut, comme dit dans ce message. Je n’ai pas poussé plus loin, « if it works, don’t try to fix it ».

Détail de l’erreur pour info :

SEVERE: Class [ javax/interceptor/InvocationContext ] not found. Error while loading [ class org.springframework.ejb.interceptor.SpringBeanAutowiringInterceptor ]
WARNING: Error in annotation processing: java.lang.NoClassDefFoundError: javax/interceptor/InvocationContext

Maven

Les dépendances dans le pom.xml ont été limitées au maximum. Pour démarrer, il faut :

Spring et Spring-test pour les tests d’intégration JPA ;
Hibernate entity manager, c’est l’implémentation JPA utilisé pour les tests d’intégration. Elle fournit aussi un lien vers le package javax.persistence ;
J’ai ajouté Spring-MVC pour monter une stack complète avec un Controleur Web annoté.

Améliorations

Le “petites” choses à faire :

Utiliser la même implémentation JPA que le serveur (EclipseLink avec Glassfish) pour les tests d’intégration (Hibernate) pour éviter d’éventuels écarts de comportement ;
Configurer les transactions de manières déclaratives en utilisant Spring-AOP plutôt que des @Transactional un peu partout ;
Séparer les tests d’intégration des tests unitaires comme conseillé dans Better Builds With Maven ;
Utiliser DBUnit pour ré-initialiser la base de données au démarrage des tests, ou passer à Unitils pour faire tout ça et encore plus.

Le projet

Le code source est disponible sur Github : https://github.com/tomsquest/spring-jpa-maven-glassfish

JavaCamp 3 : Compte-rendu

2009-02-01T00:00:00+01:00

J’ai assisté hier au JavaCamp n°3 organisé par Valtech chez Sun. Une quinzaine de personnes étaient présentes et les sessions se sont rapidement organisées. Un compte rendu rapide des sessions auxquelles j’ai participées.

Le TEST

Sujet général où nous avons parlé outils et méthodes.

Eric Lefevre explique que le test est avant tout une question de retour sur investissement (ROI). Le test pour le test n’est pas une finalité, il faut tester ce qui est important et ce qui apporte de la valeur.

Il dessine rapidement la pyramide de Mike Cohn appliqué aux tests que je ne connaissais pas.

Il y a quelques années la majorité des projets faisaient peu de tests unitaires, plus de tests fonctionnels et une majorité de tests graphiques (ah les fameux dossiers de recette).Aujourd’hui, la tendance est à un maximum de tests unitaires et à beaucoup de tests graphiques (Selenium, robots). Hors ce type de test est coûteux en temps et dans la majorité des cas, on peut se contenter de tester les services plutôt que la couche graphique.

Eric conseille de renverser la pyramide afin d’avoir beaucoup de tests unitaires, un peu moins de tests fonctionnels (que l’on pourrait appeler tests d’intégration) et le moins possible de tests graphiques, servant uniquement à valider que la couche graphique soit fonctionnelle.

Nous avons parlé d’autres outils que FitNesse et GreenPepper. Sébastien Letélié a repris la liste sur son compte rendu du JavaCamp.

DDD, quoi, qu’est-ce ?

Cette session fut animée par Sébastien que je viens de citer. Je fais un rapide passage ici car il en a parlé sur son blog et Xebia en a fait un article dernièrement.

Sébastien nous explique qu’en DDD, on ne parle plus de classe mais d’interface. Comme exemple, il cite un politicien qui a plusieurs rôles (Speaker, Décideur, Escroc). Chacun de ses rôles étant représentés par une interface qui seront combinées en Mixin qui sont en quelque sorte des classes d’interface. On imagine déjà les avantages de séparer les responsabilités (testabilité) et le fait de pouvoir les combiner dynamiquement (réutilisabilité, évolutivité, souplesse).

Scrum is Evil

Réuni pour parler de Scrum en général et notre façon de le pratiquer sur nos projets, on échange rapidement nos points de vue… différents. Eric est une nouvelle fois très à l’aise pour discuter du sujet (voir son article sur le sujet).

Une discussion est lancée sur la question « est-il possible d’affecter certaines tâches d’une itération plutôt que laisser l’équipe les choisir ».

Pour Tarik Filali, il est possible que le ScrumMaster affecte une tâche à quelqu’un qui pourra la mener à bien, selon la criticité de celle-ci.

Pour Eric, ce n’est pas conseillé. Cette action a un effet bénéfique à court terme (tâche bien réalisée et finie à temps) mais elle a un mauvais effet à long terme. En effet, que doivent penser les développeurs à qui on n’a pas osé confier cette tâche ? Quel est l’effet sur leur moral ?

Je vous passe les détails de la discussion que nous avons eue sur le fait de rester travailler tard le soir. Quel est l’effet sur le moral de l’équipe si le Scrum Master reste tard ? Ne doit-il pas montrer l’exemple en prouvant que les estimations ont bien été faites et que tout va bien ?

Sur la partie « Scrum is Evil », Eric nous rappelle que Scrum a des mauvais côtés, mais ce n’est pas la méthode elle-même, c’est sa popularité. Il rappelle le système de certification pyramidal et le fait de mettre en oeuvre les pratiques de Scrum sans penser aux valeurs qui doivent venir avec (collaboration, individus & intéractions, logiciel fonctionnel, adaptation).

Moralité : tous les mauvais côtés de Scrum se retrouvent dans les autres méthodes, donc Scrum est autant Evil que les autres :-) .

Mock ou pas Mock

Eric, très en forme ce jour-là, nous parle de trois approches : l’approche Mock où on utilise un framework de Mock (EasyMock, JmockIt…) afin de vérifier le comportement de la classe en cours de test ; l’approche Stub où l’on va soi-même mettre en place des fausses classes pour comparer les entrées/sorties ; l’approche « je ne teste pas les interactions mais uniquement la partie intéressante ».

Cette 3ème approche mérite d’être détaillée. Imaginez que vous vouliez tester la méthode suivante :

public calculeLaMoyenneDesSalaires() {
    List employésSousPayés = chargeLaListeSilTePLait();
    Pour chaque employé {
        ajoute à la moyenne;
    }
    return laMoyenne;
}

Dans ce cas, on peut voir que ce qui est important dans la méthode, c’est le comment on calcule la moyenne, non pas le chargement de la liste des employés. La 3ème approche consisterait à revoir le code pour avoir une méthode qui calcule la moyenne à partir d’une liste d’employés :

public calculeLaMoyenneDesSalaires() {
    List employésSousPayés = chargeLaListeSilTePLait();
    moyenne = calculeMoyenne(employésSousPayés);
    return laMoyenne;
}
/* package */ calculeMoyenne(List employés) {
    Pour chaque employé {
        ajoute à la moyenne;
    }
    return laMoyenne;
}

Dans cette approche, le test se passe sur la méthode calculeMoyenne(List employés) et non sur la méthode appelante. L’avantage est de se concentrer sur le code utile et non pas sur la glue (qu’il faudrait mocker). L’inconvénient principal est qu’il faudra des tests d’intégrations plus complets que dans une approche Mock ou Stub.

L’approche Mock consiste à vérifier les appels de méthode de la classe testée. Mais nous avons tendance à tester que tous les appels sont faits, dans l’ordre, avec tous les bons paramètres. Eric pense qu’il ne faut pas procéder ainsi. Il vaut mieux vérifier les appels qui nous intéresse vraiment. Par exemple, vérifier que la donnée est bien chargée et sauvegardée, mais ignorer la méthode fait un appel à une autre méthode en plus (approche NiceMock plutôt que StrictMock chez EasyMock).

L’approche Stub ne permet pas de contrôler tous les appels. On est donc plus libre dans les vérifications mais moins sévère. Dans ce cas, on utilise souvent une méthode Bottom-Up, c’est-à-dire qu’on va plutôt partir des DAO et remonter vers les services. C’est l’inverse de la méthode Mock où il est possible (et conseillé) de partir des services et de mocker les classes du dessous en attendant une vraie implémentation (« Top-Down »). Cela se rapproche du TDD et influence beaucoup le design des couches basses.

Nous avons comparé rapidement les différents frameworks de Mock. EasyMock est le plus populaire mais pourtant pas le meilleur. Il n’est pas facile d’accès et il contraint à définir le comportement avant l’appel à la méthode testée, ce qui rebute au début (on s’attendrait à tester après).

Une bonne journée

Mon premier JavaCamp ne sera pas le dernier. Plein de gens intéressants et motivés avec leurs expériences, cela donne un bon moment. Pas forcément de venir un samedi, mais c’est tant mieux : seuls les gens motivés se déplacent :-) .

Merci à tous pour ce que j’ai appris ce jour-là et à Valtech pour l’organisation.

30 secondes avec Glassfish v3

2009-01-15T00:00:00+01:00

Retour rapide sur Glassfish, le serveur d’app dont on entend parler un peu partout.

1. Intégration avec Maven : semi-Echec

Glassfish n’a apparemment pas de support de Maven officiel. Il existe quelques plugins Maven mais d’après cet article, rien de vraiment fonctionnel à part le plugin de l’auteur.

J’ai donc essayé le plugin Maven « Asadmin » qui m’a permis de déployer un War Wicket dans Glassfish. Pour info, seule la version 0.3-snapshot » de Asadmin a fonctionné.

Une autre solution serait de démarrer soi-même un Glassfish via l’API Embedded (voir ce commentaire d’Alexis MP). Mais apparemment, il s’agit toujours de déployer un War. Il faut donc générer à chaque changement de code.

Pour résumer :

Pas de plugin Maven pour Glassfish aussi facile d’accès que celui de Jetty ;
Mais possibilité de déployer un War en ligne de commande facilement.

2. Installation : succès

Le site du projet a plusieurs liens vers différents guides de démarrage qui donnent à peu près les mêmes infos.

Dézipper le zip ;
Lancer $GLASSFISH_HOME/bin/asadmin start-domain ;
Pour tester, copier l’application hello.war dans le répertoire autodeploy ;
En quelques secondes, l’application devient accessible ainsi que la console d’admin.

Aucun problème d’installation, Glassfish est très rapidement mis en place.

Le démarrage est très rapide mais si on suppose vite que plein de choses se passent en tâche de fond (comme le précise la console au lancement).

3. Intégration à Eclipse : succès

L’ajout d’un serveur dans le WTP d’Eclipse propose de télécharger des « server adaptor » additionnels, chose requise pour utiliser Glassfish. Ici encore, la documentation est détaillée avec des captures d’écran.

Mon impatience a failli me coûter cher. La liste a mis plusieurs minutes pour trouver le connecteur Glassfish. Si ça vous arrive, allez prendre un café en attendant.

Une fois le serveur ajouté, le déploiement sur Glassfish d’un projet Web prend quelques secondes, démarrage du serveur compris. Une modification d’une classe Java est prise en compte quasiment immédiatement.

Conclusion

Glassfish est facilement installable. Sa mise en place dans un projet est rapide au travers d’un IDE. Il démarre en quelques secondes, aussi vite que Jetty.

Pourtant sur l’aspect configuration et intégration à Maven, Jetty est encore imbattable (plugin Maven au Top et simple fichier de config pour les dataSources).

Il m’a manqué du temps pour tester le rechargement à chaud des classes et la persistance des sessions mais si c’est aussi facile que le reste, je l’adopte pour mes dév.

Critique du livre “Don’t Make Me Think”

2009-01-14T00:00:00+01:00

J’ai eu le plaisir de lire le livre de Steve Krug « Don’t Make Me Think » dont le sujet est l’usabilité Web. L’usabilité, c’est la conception d’un site afin qu’il fonctionne au mieux. Pourquoi faire un site utilisable ? Steve Krug cite sa femme : « Si quelque chose est difficile à utiliser, alors je l’utilise moins ».

Je cite Wikipedia :

Les critères de l’usabilité (ou utilisabilité) sont : - l’efficacité : le produit permet à ses utilisateurs d’atteindre le résultat prévu ; - l’efficience : atteint le résultat avec un effort moindre ou requiert un temps minimal ; - la satisfaction : confort et évaluation subjective de l’interaction pour l’utilisateur.

L’auteur

Steve Krug est consultant, il aide les concepteurs d’un site à le rendre plus utilisable. Il est donc payé pour établir des recommandations afin qu’un visiteur trouve l’information qu’il cherche, puisse utiliser le service au mieux de ses possibilités ou tout simplement pour acheter plus.

Il propose dans son livre des conseils pour ceux qui n’ont pas les moyens d’embaucher un expert comme lui dans ce domaine.

Le livre

C’est un bel objet, on prend plaisir à le feuilleter. Il est aéré et son contenu est bien mis en valeur. Il contient beaucoup d’illustrations et de captures d’écran pour montrer par exemple les d’améliorations avant/après (convainquant !).

Le livre a été traduit sous le titre « Je ne veux pas chercher ».

Mon avis

Je recommande chaudement ce livre qui se veut très simple d’accès, intéressant et agréable à lire. Il m’a fait prendre conscience de nombreuses choses, aussi bien sur comment les utilisateurs voient un site, que les tests utilisateurs ou encore l’accessibilité. Le livre m’a étonné plusieurs fois. Et ça, c’est ce que je lui demandais.

Il faut noter qu’il est réservé à des débutants, il n’y a pas de concepts très avancés.

Le livre une remise à plat de ce que l’on pense au niveau ergonomie et conception d’un site. La première chose est qu’il n’y a pas de réponse toute faite (« les utilisateurs n’aiment pas ça ») mais que seuls les tests utilisateurs peuvent dire ce qui fonctionne ou pas. Steve Krug nous apprend beaucoup de choses à ce sujet. Il revient sur les bases et expliquent quels sont les éléments fondamentaux d’un site (son identifiant, son sous-titre, sa navigation…) et comment faire en sorte que le site soit plus efficace.

Test Driven Website

Un des chapitres qui m’a le plus marqué dans le livre est celui où Steve Krug affirme que les discussions sur l’usabilité sont une perte de temps.

Pour lui, seul les tests avec des utilisateurs montrent ce qui fonctionne ou non.

Pour limiter les débats au sein d’une équipe (auxquels on a tous participés), il propose de se poser les bonnes questions. Ce n’est pas : « Est-ce que les gens aiment les menus déroulants ? », mais « Est-ce que ce menu déroulant est utile dans ce contexte avec ce style et ces éléments sur cette page ? ».

Et il n’y a qu’une seule réponse à ces débats : le test utilisateur. Tester une page donne des réponses concrètes. On passe de « Ce qui est vrai ou faux » à « Ce qui fonctionne ou non ». Pour Steve Krug, les tests sont donc le moyen principal de rendre un site « utilisable » (ça et les quelques règles des premiers chapitres). Un autre chapitre détaille ce qu’est un test utilisateur, comment le mener (c’est facile), ce que ça coûte (presque rien) et surtout ce que cela apporte (beaucoup).

Un dernier mot sur le test : quand on démarre la conception d’un site, il est intéressant de tester les sites concurrents. Ceux-ci servent de prototypes fonctionnels et gratuits. Intéressant, non ?

Une affaire de bon sens

Le slogan du livre est « A Common Sense Approach To Web Usability ». Pour Steve Krug, tout le monde peut améliorer son site car c’est essentiellement une affaire de bon sens. Pas besoin d’être un expert pour voir qu’un titre de page doit ressembler à un titre de page et qu’il doit encadrer le contenu. Cet aspect « bon sens » se retrouve dans chaque chapitre. L’auteur a réussi parfaitement son exercice de vulgarisation.

L’accessibilité

Steve Krug expliquent que les aveugles scannent les pages, comme nous le faisons, mais de manière auditive. Les « screen readers » qui lisent les pages sont réglés pour lire très rapidement les premiers mots des phrases, permettant à l’utilisateur de sauter de section en section. L’accessibilité est un sujet important, mais il pense qu’il demande beaucoup d’efforts qui seront comblés par les outils et la technologie. Il ne s’attarde pas sur le sujet, mais il propose des références annexes.

Quelques points négatifs

Certaines affirmations ne sont pas prouvées. Quelques fois certaines choses sont exprimées comme des faits alors qu’elles sont une opinion de l’auteur. J’aurai donc aimé qu’il cite ses sources.
Le chapitre « Mon boss me dit de faire » aurait mérité d’être plus étoffé. Dans ce chapitre, Steve Krug cite des arguments qui permettent de lutter contre un manager qui veut demander beaucoup d’infos personnelles au moment de l’inscription ou encore qui veut ajouter une multitude d’éléments Bling-bling inutiles. Ce chapitre est trop court.
Le site de l’auteur est pauvre. Dommage pour quelqu’un qui donne des conseils sur la conception d’un site. J’aurais aimé trouver d’autres exemples de ce qu’il a accompli ailleurs (quitte à changer les logos et couleurs).

ClearCase : changer le comparateur de fichier

2008-12-30T00:00:00+01:00

L’astuce du jour est : “se passer de ClearCase pour comparer les fichiers”.

ClearCase permet de comparer les différences entres les versions de fichier avec ses propres outils. Mais les comparateurs proposés par défaut de ClearCase ne sont pas les meilleurs. Il y a des outils plus souples comme WinMerge.

Comment faire ?

Pour associer tous les fichiers texte (Java et autres) avec WinMerge, il suffit d’éditer le fichier $CLEARCASE_HOME\Rational\ClearCase\lib\mgrs\map et de remplacer :

text_file_delta xcompare ....\bin\cleardiffmrg.exe

par :

text_file_delta xcompare D:\Softs\WinMerge\WinMerge.exe

Ce qui donne avant et après :

Les autres formats de fichier comme le HTML et le XML peuvent être également modifiés. Il suffit de remplacer les lignes qui contiennent “xcompare”. Exemple :

_xml xcompare    ....\bin\xmldiffmrg.exe

Bonne année 2009 !

Présentation et retour sur GreenPepper

2008-12-21T00:00:00+01:00

Au boulot, nous évaluons GreenPepper de la société Pyxis. GreenPepper est un outil de test fonctionnel et nous souhaitons à terme que les MOA l’utilisent afin de rédiger les spécifications et les tests associés.

Nous ne sommes qu’en phase de POC technique et nous avons rencontré quelques soucis. Je vous fais mon retour au bout d’une semaine avec GreenPepper.

Spécification exécutable

La base de GreenPepper est le concept de spécification exécutable. Une spec est dite exécutable quand elle fournit directement les cas de tests qui permettent de la valider et que ceux-ci sont exécutables afin de déterminer si les règles sont bien implémentées. Le site du projet héberge une vidéo de présentation.

Dans la pratique, la création d’une spécification exécutable avec GreenPepper prend la forme suivante :

La MOA se connecte au Wiki et exprime sa règle métier en bon français ;
Elle décrit également comment tester la fonctionnalité. La syntaxe se fait à base de tableaux qui permettent au système d’extraire les méthodes et données de test à utiliser ;
L’équipe de développement écrit ensuite le liant entre la page de test et le code réel. Ce branchement est appelé « fixture ».

Exemple de spécification fonctionnelle

Chaque page GreenPepper dispose d’un bouton « Execute » qui permet d’appeler les fixtures avec les paramètres du tableau. L’appui sur ce bouton invoque le système testé qui récupère dans la page les classes à créer et invoque les méthodes avec les données.

Dans l’exemple ci-dessus, GreenPepper instancie la classe Cart et invoque deux fois la méthode « add » avec en paramètre « Persian Cat » puis « Dalmation » et enfin invoque la méthode numberOfItems. Celle-ci doit retourner 2. Si ce n’est pas le cas, la case du tableau sera coloriée en rouge ou en vert si le résultat est valide.

Le coin de la technique

GreenPepper est en réalité un plugin pour Confluence, le wiki édité par Atlassian.

C’est LA différence avec FitNesse, un autre outil très populaire de test fonctionnel. FitNesse embarque son propre serveur Web et son propre Wiki. Chez Pyxis, il a été décidé de s’appuyer sur un outil existant, réputé et fiable.

GreenPepper se contente donc de rentre les pages du Wiki Confluence testables en leur ajoutant des macros et le fameux bouton « Execute » vu plus haut.

Qualités de GreenPepper

GreenPepper, c’est avant tout Confluence. Ce dernier apporte une plateforme puissante permettant à tous les acteurs de communiquer autour du logiciel. C’est un wiki donc il apporte des notions de collaboration, de versionning et de partage.

GreenPepper s’intègre également avec Jira, un autre produit Atlassian permettant de faire du bug tracking. On peut donc imaginer avoir un rapport de bug lié à une page de spécification qui contient le test permettant de reproduire le bug.

L’écriture des fixtures peut se faire en Java et en .Net. Une fixture est une simple classe et GreenPepper ne pose aucune contrainte à ce niveau. Le produit propose aussi de créer un SUD (System Under Developement) permettant de réaliser des actions quand une fixture est instanciée/libérée (sorte de « setUp/tearDown »), d’enregistrer des convertisseurs (par exemple, convertir un numéro de client en Client) et d’importer des packages de fixture par défaut. Dans notre SUD actuel, nous démarrons également le contexte Spring afin d’injecter les beans dans les fixtures.

Problèmes rencontrés

Nous avons rencontré plusieurs problèmes avec GreenPepper. Nous étions très confiants pour un produit « packagé » comme GreenPepper, mais la machine fut difficile à démarrer.

La documentation

Le plus gros point noir du produit est sa documentation. Elle forme un patchwork difficile à ingérer. On trouve des exemples mais pas toujours le code associé. Certaines fixtures sont détaillées, mais je n’ai pas trouvé les exemples simples ni percutants.

La courbe d’apprentissage n’est donc pas basse. C’est laborieux. La documentation est difficilement compréhensible à la première lecture, voir à la deuxième. Après quelques jours, je commence enfin à en comprendre certaines sections.

Un exemple vécu lors de l’installation : le « step by step » est simple à suivre mais rien ne fonctionnait à la fin. Nous avons du désinstaller le plugin GreenPepper et le réinstaller différemment de ce qui est précisé dans la documentation. Pour cela, il a fallu chercher dans les forums afin de voir qu’il était conseillé d’installer le plugin directement dans WEB-INF/lib (plutôt que par l’installateur Confluence comme indiqué dans la doc).

Le plugin Eclipse

Le plugin permet de rapatrier les pages de tests et de les exécuter localement. Il offre la possibilité de générer le squelette des fixtures à partir des pages.

Beaucoup d’options sont proposées et on a du mal à savoir quoi mettre. Il faut un répertoire de spécs que je n’ai pas. Un SUT ? Non, je n’en ai pas (encore). Et le classpath, j’ai celui d’Eclipse, pourquoi j’en utiliserai un autre ?

Au bout de quelques heures, ça fonctionne à peu près. Entre temps, on a essayé toutes les options dans tous les sens. C’est rigolo 5 minutes.

A titre d’info, voilà la procédure :

Ecrire sa page dans Confluence et la marquer comme « Implemented » ;
Rafraichir la vue « Repository » dans Eclipse : la page apparaît ;
Executer une première fois la page depuis le menu de cette vue ;
Ouvrir avec le WebBrowser d’Eclipse le HTML de la page crée plus haut (répertoire /greenpepper) ;
Executer la page une deuxième fois mais depuis le menu Run d’Eclipse ;
La page doit enfin montrer les résultats (du jaune si les fixtures n’exisente pas) ;

Autres points :

Le plugin Eclipse n’est pas stable. La vue se freeze de temps en temps ;
Il est en version bêta depuis un moment ;
Eclipse 3.4 n’est pas supporté mais il s’est installé sans soucis.

Capture du lancement depuis Eclipse

Le classpath et Maven

Je n’ai pas mis en place cette partie là sur notre projet actuel donc j’ai peu à en dire. Ah si, une chose : beaucoup de sueur.

Le plugin Maven permet de construire le classpath contenant l’ensemble des dépendances pour permettre à GreenPepper d’appeler les fixtures qui utilisent les classes de votre projet.

Comme pour le plugin Eclipse, il a fallu batailler pour comprendre la doc, savoir quels paramètres saisir et comment configurer le SUT dans le plugin GreenPepper de Confluence (ne cherchez pas de définition de SUT dans la doc, il n’y en a pas).

Et quand ça ne fonctionne pas, il est difficile de trouver les erreurs et les exceptions remontées.

Quelques conseils autour de GreenPepper

Eric Pantera, d’Octo Technology, est venu nous faire un retour sur GreenPepper. Il l’utilise depuis 10 mois chez un de ses clients.

Comme nous, l’équipe a eu beaucoup de mal à mettre en place l’outil. Mais dès les premières itérations, ils ont commencé à sentir d’énormes gains : leur communication s’est largement améliorée, tous les acteurs y voient plus clair, les MOA produisent les tests permettant d’éprouver le système et le logiciel est au final beaucoup plus fiable.

Pour accélérer la mise en place de GreenPepper, Eric nous a conseillé de :

Soigner la HomePage. Au début du projet, il faut donner envie. La MOA va devoir se former à un nouvel outil et un Wiki est toujours un peu complexe. Il faut lutter contre la résistance au changement et montrer les avantages de cette solution ;
Laisser libre la MOA pour les premières pages, puis repasser derrière et compléter les tests avec les noms des fixtures, par exemple. La MOA voit ensuite les modifications et utilisent celles-ci pour les tests suivants. Il faut donc éviter un maximum de restreindre la MOA à ses débuts.
Regarder les plugins Confluence. Certains sont très utiles comme le plugin Office permettant d’éditer ses pages depuis Word ;

Conclusion

Pour résumer, GreenPepper est un produit très intéressant, mais qui souffre d’une documentation défaillante. Il offre de nombreux avantages comme l’intégration à Confluence, le plugin Eclipse et le support de Maven. La mise en place est déroutante car elle est laborieuse.

D’autre part, le produit évolue lentement. Les pages de documentation datent pour une bonne partie de 2007 et la dernière news du site concernant GreenPepper date de janvier 2008.

Une question reste : est-ce que son concurrent direct, FitNesse, fait mieux ?

Tom’s Quest

Review : Play Framework Cookbook

Contents

Review

Links

Better autocompletes with Fuzzy Matching

Fuzzy Matching ?

The application

Frontend

1. Add an input

2. Bind the JS

Backend

Wrapping up

FitNesse technical setup

Advantages and disadvantages

Team process

Setup

Central Server

Launcher

Classpath

Backup job

SVN ignore

Developer server

Launcher

Classpath

Wiki import

Debugging

Random problem (Bind, Socket exception)

Industrialisation des développements : automatisez votre base de données

Principes directeurs

Principes techniques

Bonnes pratiques

Les outils existants

Liquibase : puissant mais complexe

Les pragmatiques

Conclusion

Notes sur Rework de 37signals

Learning form mistakes is overrated

Why Grow ?

Start making something

No time is no excuse

Outside Money is plan Z

Start a business, not a startup

Embrace constraint

Illusions of agreement

Reasons to quit

Make tiny decisions

Underdo your competition

Emulate Chefs

Drug dealers get it right

Résumés are ridiculous

Years of irrelevance

Hire great writers

Take a deep breath

Decisions are temporary

Liens annexes

Construire la nouvelle génération de leaders techniques

Définition

De mauvais Leaders Techniques

Former de bons leader techniques

Des compétences différentes

Solutions

Liens

JPA : les illusions sur les NamedQueries

Rappel sur les NamedQueries

Une NamedQuery est plus performante

Une NamedQuery est validée

NamedQuery, alors pourquoi ?

8 raisons d’aimer Ruby

Plus productif

Meta-Programming

Duck Typing

Closures

JRuby

Frameworks novateurs

GEM : le packaging facile

Une communauté riche (et aussi en France)

Conclusion

Tests d’intégration : quid de la base de données ?

Base de données embarquée ou non ?