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

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)

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.

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.

• 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 ?

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

Capture du menu contextuel

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.

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.

Ta 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

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.

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 ?

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.