De plus, l’article propose une méthode pour aller vers cet objectif. La méthode proposée et je trouve très interessante, elle propose de définir les domaines à travailler, d’identifier le but de tavailler ce domaine, puis de définir un ensemble d’actions concrètes. Rien de bien nouveau, cependant, j’ai trouvé intéressant la méthode qui est de travailler de manière incrémental, plutôt que de travailler full time un sujet. Mieux vaux travailler un ensemble de sujet et d’itérer dessus pour monter en compétence. Cela donne plus de recul et une meilleure vision d’ensemble. A titre d’exemple, l’année dernière en travaillant Spring,  je travaillais en parallèle les design pattern, le fait de comprendre des design pattern comme le « template » ou le « stategy » m’ont aidé à avoir une meilleure compréhension de Spring et de son utilisation.

Après avoir lu l’article j’ai créé mon propre tableau d’objectif, je vous le livre dans sa version alpha :

Je pense que cela vaut le coup de se définir des objectifs et d’y travailler quotidiennement. En effet, on a malheureusement tendance à ne se focaliser que sur les sujets que l’on connait ou qu’y sont les plus faciles. Or, être expert c’est justement avoir l’esprit ouvert et connaître tous les sujets connexes au sujet maitrisé.

Lorsque l’on atteint un niveau correct dans un domaine on a tendance à s’arrêter sur cet acquis et à ne plus voir le reste. Le schéma ci-dessous que j’ai piqué à Kathy Sierra l’illustre bien :

D’un autre coté, le premier article nous fait bien comprendre que l’on ne peut pas se reposer sur nos employeurs pour nous prendre la main et nous guider vers ce genre d’objectif. Nos buts ne sont pas les mêmes :

Your company expects results from your work: reliable, with minimal mistakes and focused on the company main goal – make money. Your employer could provide minimal training to help you with job requirements. However, your growth will be constrained by company needs, timelines, work assignments and acceptable methods.

En développement logiciel les technologies vont tellement vite que l’on ne peut surtout pas se permettre de se reposer sur une compétence acquise.

Enfin, je terminerai sur cet article, qui nous explique les qualités qui font selon lui un véritable expert  :

• les connaissances
• l’expérience
• des capacités de communications
• un réseau
• la curiosité

Pour y parvenir, il nous propose de travailler sur ces axes :

• travailler continuellement
• pratiquer
• se faire un réseau
• acquérir des capacité de présentation (plutôt au sens marketing, savoir en mettre plein la vue)
• partager son expertise

Rendez-vous dans 2, 3 ans pour voir si la méthode marche

Tout d’abord, notre besoin.
Nous travaillons à 8 sur un projet mais sur des parties bien différentes : un frontal .net, un middle Java et un backOffice PL/SQL. Avant, lorsque nous trouvons des bugs, des cas bizarres, ou lorsque nous avions des suggestions; la solution c’était un mail, un post-it ou bien à l’oral. Le client possède en interne un outil de gestions des incidents, mais c’est une énorme usine à gaz, ou l’on cible forcément toute l’équipe, et qui est bien trop lent : c’est surtout dédié aux relations MOA/MOE ou MOE/Production.
Du coup, on ne sais pas ce que deviennent ce que l’on signale, si c’est déjà corrigé ou pas, et on ne sait même plus ce que l’on a demandé, sauf à s’astreindre à une rigueur que nous n’avons pas forcément…
Premier essai : le fichier Excel !
Ca fonctionne, mais pas très longtemps… Coup de fil : tu peux me lâcher le fichier Excel pour que je puisse y rajouter quelque chose. Coup de fil n°2 : Tu as vu que ce matin, je t’ai rajouté plein de trucs.
Bilan : c’est vite chiant…
Deuxième essai : on cherche mieux
Suite à ces constats, on se dit :
- il faut une webapp ou l’on puisse bosser à plusieurs en même temps
- il faut que ça puisse envoyer des mails
- il faut que l’on puisse l’assigner à une personne donnée
- il faut que ça reste pas trop prise de tête comme mon fichier Excel sinon personne l’utilisera
- si on peut y mettre des fichiers joints en plus, ça serait bonus.
- et aussi il faut que ça s’installe et paramètre vite, pasque je suis embauché pour coder pas pour faire du consulting en productivité ou en qualité.

Jtrac!

Après un petit tour sur le net je tombe sur Jtrac, c’est super, ça répond à tous nos besoins.
J’ai préféré JTrac à d’autres (Mantis, BugZilla, etc.) car il est beaucoup plus simple à mettre en place (tu dézippes, tu lances le batch, c’est fini) mais aussi car il est très minimaliste.
Jtrac en pratique c’est une webapp en java (Spring, Wicket, Hibernate) avec un jetty embarqué et une base de données XML embarqué (HSQLDB). Il permet de paramétrer facilement des projets, des utilisateurs, la configuration du serveur de mail est ultra rapide, au bout de 5 minutes j’ai fini et j’ai commencé à saisir mes premières anomalies. Je n’ai laissé qu’un minimum de champs possibles pour pas que les fiches fassent couteau suisse, de plus j’ai fait en sorte que le cycle vie des incidents soient très permissif.
Bilan, l’équipe aime bien et suit beaucoup plus facilement les incidents. Ca permet au chef de projet également d’avoir la vision de l’avancement des corrections.
Mon conseil, si vous n’avez pas ce genre d’outil mettez vous y. Ca permet d’avancer doucement vers d’autres outils aux fonctionnalités plus avancé et s’interfaçant avec Mylin…

Bilan au bout de 3 semaines : 125 enregistrements, une bonne adhérence de toute l’équipe, et le chef de projet qui nous ordonne de « Jtraquer » une liste d’évolutions

Quelques screenshot :

Le tableau de bord, simple mais efficace.  

L’Ajout d’un enregistrement.  

C’est minimaliste, mais cependant extensible via la console d’admin.

Tests Logiciel

View more presentations from nrichand. (tags: java tdd)

La première présentation de Guillaume Laforge sur Groovy était très intéressante et axée sur le point de vue d’un développeur Java. L’argument majeur que je retiens est que tout code java est lui même du code Groovy (mais pas l’inverse naturellement!). La prise en main est donc très bonne car on écrit du code java au début que l’on groovyse au fur et à mesure que l’on maîtrise les tricks du langage. Je vous épargne les détails ici car Xebia en fait un compte rendu très complet ici. Le seul aspect au final qui me laisse encore perplexe dans Groovy est le faible pouvoir de détection d’erreurs à la compilation. Guillaume Laforge estime que l’aide des IDE (notamment IntelliJ) combiné à un set minimaliste de test unitaire résout le problème, à voir…
La présentation finit par une présentation des DSL (Domain Specific Langage), je ne suis pas persuadé que n’importe quel utilisateurs puissent les utiliser, mais c’est en effet un vrai moyen de se rapprocher de son client et d’essayer de parler la même langue.

La deuxième présentation était une introduction à Grails faites de manière assez ludique. Le point de vue mis en avant (et c’est l’un des atout majeur de Groovy/Grails) était vraiment la productivité. Avec aussi une partie sur le fait que Grails produisent bien une applis standard J2EE (un War). Il est en effet bluffant de voir en 10 minutes tout ce que l’on est capable de produire. Entre une syntaxe très simplifiée (merci Groovy), un boulôt de génération massive pour la BDD et l’IHM (merci Rails) et le fait de pouvoir s’abstenir de redémarrer le serveur d’application, il est clair que la productivité est au rendez-vous. De plus, d’après les retours d’expériences il semblerait que Grails tiennent globalement bien la montée en charge.
A l’issu de cette présentation, j’ai appris que la communauté Groovy était en train de sortir un équivalent de Grails pour Swing, en cherchant un peu je viens de découvrir Griffon. A tester!

Dernier petit bonus de la soirée, j’ai gagné le livre « Filthy rich client » ce qui vraiment cool, merci au ParisJug!

Pour ceux qui n’auraient pas pu participer à la soirée, vous n’avez pas tout perdu car 2 présentations équivalentes sont disponibles, ce sont globalement les mêmes, celles du ParisJug étant justes un poil mise à jour et rallongées.

Présentation de Groovy sur parleys

Présentation de Grails : T18 – Innover sans contraintes, intégrer sans ruptures (s’inscrire gratuitement sur le site de l’université du SI).

• la fin de ma mission chez Groupama début juillet.
• le passage de la certification SCJP dans la foulée.

Je vais faire le bilan de la certification SCJP dans mon prochain post donc je ne vais pas plus m’attarder sur celle-ci maintenant. Par contre le fait d’avoir travailler la certification m’a permis de découvrir certaines subtilités du langage java. Si vous trouvez la réponse tout de suite aux questions ci-dessous c’est bon, la certif SCJP est dans votre poche, sinon au boulot…

Override & Overload

Connaissez-vous bien le fonctionnement de la surcharge (Override) et de la redéfinition (Overload) ? Quel est donc le résultat de ce bout de code :

1. class Animal{
2.   public void mange(Animal a){
3.     System.out.println("un");
4.   }
5. }
6. class Chat  extends Animal{
7.   public void mange(Animal a){
8.     System.out.println("deux");
9.   }
10.   public void mange(Chat a){
11.     System.out.println("trois");
12.   }
13.   public static void main(String[] args) {
14.     Animal animal = new Chat();
15.     animal.mange(animal);
16.   }
17. }

Interface

Ce bout de code est plus que trivial. Il n’y a aucun problème naturellement…

1. interface MyInterface{
2.   void myMethod();
3. }
4. class MyClass implements MyInterface{
5.   void myMethod() {}
6. }

Constructeurs

Toujours trivial, toujours sans problème ?

1. class Constructeur {
2.   public Constructeur(String s) {}
3. }
4. class Const2 extends Constructeur{
5.   public Const2(String s){}
6. }

float

Enrobé dans 10 lignes de codes, ce code bidon peut se révéler très piégeur :

1. float f = 1/2;
2. System.out.println("Mon QI : "+ f*2);

Autoboxing et widening

Tout s’explique, même ceci. Comment justifierez-vous le choix de la méthode à appeler ?

1. public static void coucou(Float f){
2.   System.out.println("Float");
3. }
4. public static void coucou(double f){
5.   System.out.println("double");
6. }
7. public static void main(String[] args) {
8.   float f = 0;
9.   coucou(f);
10. }

Il y en a bien d’autres, mais celles-ci sont déjà représentatives de l’esprit de la certification.

Réponses :

1) le résultat est … « deux » !
Le principe est : Overload est définit à la compilation, Override à l’exécution. Donc lors de la compilation le compilateur ne sait uniquement que notre « animal » est un Animal mais sans en savoir plus. Donc suivant le principe il va éliminer du choix des méthodes la numéro trois car elle prend en paramètre un Chat. Lors de l’exécution par contre la JVM sait que notre variable est un Chat, donc elle va choisir la méthode numéro deux qui est définit dans la classe Chat. C’est aussi simple que cela.

2) Ca ne compile pas bien évidemment.
Le problème vient du fait que les méthodes est variables dans une interface sont typées par défaut, même si vous ne le mettez pas. Le type par défaut d’une méthode est public. Donc quand on l’implémente en ne mettant rien on lui attribut le typage défault qui est plus restrictif que public est donc interdit…
Merci à Eclipse de l’avoir fait pour nous depuis tant d’années.
Le type des variables est par défaut lui public static final.3) Idem, ça compile pas.

3) Idem, ça compile pas.
Le problème vient de l’appel au constructeur par défaut. Ce qu’on appelle un constructeur par défaut est un constructeur sans argument qui est automatiquement rajouté à la compilation … si la classe ne définit pas déjà un autre constructeur. Ici donc, aucun constructeur par défaut n’est inséré car on en définit un dans chaque classe.
Le problème provient du fait que la première ligne de chaque constructeur doit contenir une référence vers un autre constructeur de la classe (this(…)) ou de la classe mère (super(…)). Si aucun appel de ce style n’est positionné sur la première ligne alors le compilateur ajoute tout seul : « super() ; »
C’est ce qui se passe sur l’exemple ci-dessus et qui provoque donc une erreur de compilation car le constructeur sans paramètres n’existe pas.

4) Le résultat est évidemment 0.
Un chiffre est considéré par le compilateur comme un int. Le résultat d’un int divisé par un int produit donc un int, le résultat est donc 0.

5) Le résultat est bien sûre « double ». On peut en effet utiliser en java la technique du « widening » qui permet ici de transformer notre float en double (no problem : un double peut contenir un float). On peut aussi depuis java 1.5 utiliser l’autoboxing, l’appel utilisant un « Float » est donc parfaitement valable également donc. L’autoboxing paraitrait plus logique, cependant c’est bien la méthode avec un double qui est appelé pour des besoins de compatibilité avec les versions de java antérieur. Too bad…

Je n’utilise que certaines de ces librairies par habitude, mais je me rend compte de plus en plus souvent que cela vaut le coup d’aller fréquemment y faire un saut pour éviter de réinventer la roue à chaque fois…

Ce coup ci je viens de retomber sur l’API commons lang qui vise à étoffer le comportement de java.lang. Elle contient quantité de classes utilitaires qui peuvent être utilisées sur énormément de projet, d’ailleurs je pense que beaucoup de projets réécrivent en partie ces classes (vécu)…

Voici un petit tour rapide de ce que j’ai découvert d’intéressant :

• La classe StringUtils avec notamment la méthode IsEmpty() qui permet de remplacer monString != null && !(«  »).equals(monString)
• HashCodeBuilder qui permet de coder un bon hashCode sans avoir à ressortir à chaque fois java efficace de Joshua Blosch (que je recommande)
• ExceptionsUtils.getStackTrace(e) qui permet d’écrire la stackTrace dans une log par exemple ce que ne permet pas e.printStackTrace()
• DateUtils qui contient des méthodes tels : addYear(), addMonth(), addMinute(), …
• EqualsBuilder pour aider à redéfinir la méthode equals
• NumberUtils avec par exemple toInt(str), toFloat(str), …
• …

Mon conseil du jour est donc : gagnons du temps et refouillons un peu dans les commons