En discutant de l’intérêt de l’usage de la javadoc, question primordiale il faut l’avouer, nous avons dérivé sur un sujet encore plus intéressant : l’utilité de la balise @Author dans la javadoc :p Meme si sur Twitter, le @Author est considéré comme inutile, quasiment à l’unanimité, ce n’est pas le cas partout.

Le pour

– Je suis auteur de mon code, je l’assume et je l’écris de manière professionnelle en pensant à ceux qui vont me lire. C’est une idée que partage Robert C. Martin.

The @author field of a Javadoc tells us who we are. We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

– Surtout dans l’open-source, cela permet de laisser une trace de son investissement. Voir de se faire un nom.
– Il peut contenir l’adresse d’une mailing-list, ce qui permet, lors d’une question sur une classe de contacter directement les personnes responsables.

Le contre

– DRY : don’t repeat yourself : l’information est déja présente dans le SCM (git, svn ..).
– Le code appartient à tous : le @author doit donc etre collectif.
– Si il ne contient que l’auteur initial, celui-ci ne vaut pas plus que les autres.
– évite la sacralisation d’un unique développeur
– Pose le problème de savoir quand on doit se rajouter dans la balise @author.

Je laisse à Emmanuel Bernard le tweet de la fin :

Merci à ‏Sébastien PRUNIER ‏ @sebprunier, Pierre TEMPLIER ‏ @ptemplier, Emmanuel LECHARNY, François Sarradin ‏ @fsarradin, Guillaume LOURS ‏ @guillaumelours, Jean-Laurent Morlhon ‏ @morlhon, Arnaud Héritier ‏ @aheritier , Sébastien Deleuze ‏ @sdeleuze , Yannick AMEUR ‏ @yannickameur , Robin Komiwes ‏ @robinkomiwes , Jollivet Christophe ‏ @jollivetc , Jérémy Sevellec ‏ @jsevellec, Julien Jakubowski ‏ @jak78 , Nicolas De loof ‏ @ndeloof, Nicolas François ‏ @nicofrancois , Francois Marot ‏ @FrancoisMarot , Jean Helou ‏ @jeanhelou, Benoît Dissert ‏ @bdissert , Olivier Jaquemet ‏ @OlivierJaquemet , Aline Paponaud ‏ @bootis , Benoît Dissert ‏ @bdissert , Nicolas Delsaux ‏ @riduidel et aux autres …

Pour me préparer aux sélections de code story et pouvoir coder pendant 2 jours une application devant des centaines de développeurs à Devoxx, je me suis entrainé à refactorer une méthode en m’enregistrant.

Le bénéfice que j’attendais de l’exercice était de :

• M’entendre parler pour détecter mes défauts d’expressions et les corriger, car le jour J il faudra expliquer ce qu’on fait et pourquoi, le tout en codant ! Pas facile…
• Maîtriser au maximum mon IDE pour être rapide à coder, rien de plus ennuyeux que de regarder un développeur coder trop lentement !

Pour la petite histoire, Read more »

J’ai eu l’occasion d’assiter à une conférence sur les anti-patterns Hibernate par Patricia Wegrzynowicz à Devoxx hier. Elle a mis en avant certains effets de bords induit par l’utilisation d’Hibernate (les points suivants peuvent souvent s’appliquer à d’autres ORM, rien de personnel avec Hibernate . Cet article ne reprends qu’une partie du talk: les points que j’ai pu rencontrer en entreprise.

1. L’hydre

Hydra est une entité qui a la particularité de contenir une liste immuable de tête (heads.)

@Entity
public class Hydra {
  private Long id;
  private List heads = new ArrayList();
  @Id @GeneratedValue
  public Long getId() {...}
  protected void setId() {...}
  @OneToMany(cascade=CascadeType.ALL)
  public List getHeads() {
    return Collections.unmodifiableList(heads);
  }
  protected void setHeads(List heads) {...}
}
// creates and persists the hydra with 3 heads
// new EntityManager and new transaction
Hydra found = em.find(Hydra.class, hydra.getId());

La question est la suivante, combien d’appel sont fait en base de données lors de  la deuxième transaction (créer lors de em.find).

(a) 1 select
(b) 2 selects
(c) 1+3 selects
(d) 2 selects, 1 delete, 3
inserts
(e) None of the above

Read more »

Rien de prévu mardi prochain ? Rejoignez nous pour la première de la marmite, LA soirée récurrente des duchesses ! J’aurais l’occasion d’animer avec Brice Dutheuil, commiter Mockito, un Hands-On sur la mise en place de tests avec Mockito et comme il y en a pour tous les gouts chez les duchesses, on a également prévu en parallèle un open-space pour échanger sur les sujets qui vous intéressent !

Qu’est-ce qu’un open space ? C’est un peu comme un barCamp à part que les sujets sont présentés au début et que l’on ne traite que les sujets les plus populaires pendant un temps limité. Le but essentiel est de partager et de débattre. Tous les sujets autour de Java et de l’IT sont les bienvenus. Pour vous donner des idées, voici quelques pistes possibles :

• une problématique technique que vous avez rencontrée
• un super outil qui a changé votre vie de développeur
• votre sujet de veille préféré
• ou une problématique relationnelle (ex: comment travailler avec une personne au caractère difficile ?).

Pour vous inscrire a l’Hands-On ou a l’open-space

Plus d’infos

Etant bloquée chez moi, j’en profite pour vous partager un petit quizz destinée aux utilisateurs d’intelliJ IDEA sous linux/Windows. Le même pour les amateurs de la pomme à venir dans la journée/soirée

[wp-simple-survey-1]

Au commencement…

Comme beaucoup, il y a eu le passage « classique » en SSII. Pendant 2 ans, j’ai eu l’occasion de rencontrer quelques freelances qui avaient l’air plutôt satisfait. Je me disait qu’ils avaient de la chance et que j’aimerai moi aussi, être indépendante. Tous étaient très expérimentés. Je me disais que j’étais trop jeune et que finalement, la situation de salariée en SSII était confortable. Elle permet à la fois de parfaire mes connaissances techniques et de prendre des contacts durant les missions sans stress.

Et puis la chute

Read more »

http://www.mavieauboulot.fr/

Cette année, le Paris Java User Group fête ses 3 ans. Pour l’occasion une soirée exceptionnelle est organisée. D’autant plus exceptionnelle que Mathilde viendra raconter comment le statut d’indépendant permet à ceux qui ont fait ce choix de vivre différemment, de vivre mieux.

Tous les détails (lieu, date, programme et inscription) ici : http://www.parisjug.org

« J’en ai rêvé, je l’ai fait ». Voilà comment je résume mon état d’esprit en ce moment. Je suis Freelance parce que j’ai cette fibre d’indépendance, l’envie de voler par mes propres ailes. Je suis développeur parce que j’aime créer, j’aime réaliser des outils utiles, j’aime réaliser des outils de qualité et j’aime partager mes connaissances (ce blog en est la preuve). En cela je me considère comme un artisan, un « Software Craftsman ».

Read more »

L’article précédent a permis de comparer la syntaxe des trois frameworks sur les cas classiques. Un cas où Spock se détache vraiment des deux autres frameworks, c’est sur la gestion des arguments des méthodes mockées.

Les wildcards

Il est possible d’utiliser des wildcards au niveau des arguments appelés. Ainsi 1 * calendarDao
.getInfosByDay(_) veut dire ‘la méthode calendarDao.getInfosByDay est appelée une fois (1 *) avec n’importe quel paramètre (_). On peut également spécifier la classe de l’argument : 1 * calendarDao.getInfosByDay(_ as String) .

Il est également possible par exemple de compter le nombre d’appel aux méthodes d’un simulacre (quel quel soit : 3 * calendarDao._ passera uniquement si les instructions du bloc when font exactement appel à 3 méthodes de l’instance calendarDao. Il est également possible de donner des intervalles plutôt qu’une valeur, ce qui n’est pas permis par les autres frameworks (à part le ‘au moins 1 fois’) : Read more »

On a vu dans la première partie que l’on pouvait faire facilement du data-driven testing et que la syntaxe en bloc apportait beaucoup en lisibilité. Les blocs expect/where que l’on a vu sont les plus adéquats lors de cas de tests simples, où l’on peut facilement exprimer le stimulus et son résultat, typiquement monojbetA.maMethode()==monResultat. Dans le cas où l’on se retrouve face à des tests un peu plus compliqués, l’utilisation de la structure given/when/then est alors préférable. Cet article n’a pas pour vocation de comparer les fonctionnalités des trois frameworks, juste de présenter spock et de comparer la syntaxe des trois frameworks dans le cas de tests ‘classiques’.
Read more »

Au cours de mes tribulations, je suis tombée sur un nouveau framework de test : Spock, basé sur Groovy & JUnit.  Il est facile à prendre en main et est beaucoup moins verbeux que certains autres framework de tests même quand on ne maitrîse pas Groovy. Les tests sont structurés à l’aide de blocs  given/when/then et setup/expect/where ce qui permet d’améliorer la lisibilité et l’écriture. Ce framework est à suivre, il est rapidement pris en main mais il manque encore certaines fonctionnalités avancées. Cet article est le premier d’une série de trois, il permettra de comparer spock à d’autres frameworks similaires.
Read more »

Qui n’a jamais attendu de nombreuses minutes pour builder un projet ? Et qui n’en a jamais profité pour aller boire un café/regarder twitter/… ? Parce que l’on teste fréquemment, il est important d’essayer d’optimiser et de réduire la durée d’exécution des tests.  Tester souvent ne veux pas dire attendre souvent ! Il est donc primordial d’essayer de réduire cette durée en jouant sur différents paramètres. Comment obtenir le résultat des tests le plus rapidement possible ?

Ce qui suit est tiré de la conférence de David Gageot [ @dgageot / http://javabien.net ] à SoftShake 2010.

Sur une vingtaine de personnes présentes dans la salle, les durées de build vont de quelques minutes à plusieurs heures. David présente brièvement quelques frameworks comme Infinitest et JUnitMax. Ce sont des plugins pour IDE Java qui permettent de lancer les tests unitaires en continu et de manière intelligente, c’est à dire uniquement ceux impactés par le code modifié.
La première idée lorsque l’on cherche à optimiser cette durée d’exécution, c’est de vouloir déléguer le problème. C’est faire  tourner les tests sur des serveurs distribués qui permettront d’exécuter les tests en tâches de fond. C’est une mauvaise idée, les serveurs coûtent chers et on peut se retrouver submerger. Il existe des méthodes plus simples pour réduire cette durée.

Le KISS ( Keep It Simple, Stupid ) est également applicable lorsque l’on crée des tests. Chercher à optimises ses tests peut améliorer votre produit : ce qui est simple à tester sera simple à coder et à utiliser. Ce qui est compliqué n’en vaut surement pas la peine. Read more »

Si vous aussi vous perdez 3 minutes à chaque fois que vous faites un redéploiement, calculez donc combien cela coute à votre client sur : http://www.zeroturnaround.com/jrebel/

JRebel est un outil payant permettant d’effectuer des rechargements à chaud d’applicatif Java. C’est clairement l’outil qui fera de vous un développeur plus productif. Voilà une bonne façon de se faire bien voir, de rentrer plus tôt à la maison ou d’augmenter sa facturation Read more »

Au début de ma carrière, je me souviens qu’un de mes collègues m’a dit « Tu sais, au final, on se rend compte qu’il n’y a que très peu de différence de productivité entre un bon développeur et un développeur lambda ». Je l’ai cru,  et il m’a fallu quelques années pour me rendre compte qu’il avait complétement tort. Read more »

Il y a un an, je me lançais en tant que freelance. C’est le bon moment pour faire un bilan. Il me semblait que se lancer en tant que freelance n’était finalement pas risqué et ne changeait pas temps de chose.

Pourquoi ?

Malgré une famille, un crédit maison sur 15 ans et un crédit auto sur 6 et une expérience de 2/3 ans, j’avais envie de découvrir autre chose que le monde des SSII.
Mes expériences en SSII ne sont pas négatives, une SSII de taille moyenne grâce à laquelle j’ai pu faire une mission très intéressante mais pas vraiment au point pour entretenir une communauté de développeur en son sein et y favoriser le partage des connaissances. Une tout petite SSII où au final je ne serai restée que quelques semaines mais dont l’obligation de sous-traitance à d’autres SSII plombe le modèle économique et là encore pas assez de matière pour aider en interne à monter en compétence. Au niveau de la plupart des SSII, celles ci apportent effectivement une certaine sécurité au niveau de l’emploi (valeur tellement ancrée dans la société…). Mais tout a un prix. Read more »

Le test unitaire est un test qui provoque l’exécution d’une partie du code et qui l’analyse.  Il permet de garantir que le code exécuté fonctionne correctement. Il se doit donc d’être automatisé et répétable. Pour cela, cela nécessite fréquemment le besoin d’isoler le test unitaire des systèmes extérieurs (base de données, appels web-service distants).

Pour ce faire, il existe plusieurs méthodes, l’utilisation de bouchon (‘stub’) ou de simulacre (‘mock’). L’article de référence est un article de Martin Fowler « Les simulacres ne sont pas des bouchons« . Pour résumer, une méthode bouchonnée est appelée sur un objet bouchon réel, centré sur le système testé. Il ne peut jamais faire échouer le test. On regarde l’état de l’objet final à la fin du test et non les étapes qui ont permis d’obtenir cet état. C’est un test basé sur des états. Read more »

EasyMock est un framework de test qui peut dérouter dans un premier abord. Une fois qu’on a compris comment l’utiliser, on tombe sur un certain nombre d’erreurs qui reviennent très souvent et qui ne sont pas souvent explicites. Même si EasyMock 3.0 a clarifié un certain nombre d’erreurs, cet article (fait sous la 2.5.2) servira de pense-bête à ceux qui débutent avec ce framework. Read more »

Il y a différentes possibilités :

• S’abonner à la mailing list de son « Java User Group » local
• suivre les flux des différentes SSII proches de chez vous qui organisent de temps à autres des soirées.
• Twitter est également un bon moyen de se tenir à jour !
• L’équipe de JDuchess France fournit également un calendrier des évènements à venir : Agenda Conférences des Duchess. Il est possible d’ajouter facilement cet agenda à son Google calendar en tant qu’agenda ami : Consulter l’agenda Conférences dans Google Agenda

Si vous désirez ajouter un de vos évènements à l’agenda des JDuchess, tout est indiqué sur le blog des duchess

Être freelance présente beaucoup d’avantages pour très peu d’inconvénient. On peut toutefois faire l’exercice de lister les quelques problèmes que nous rencontrons:

1. 1/3 des missions sont pourvues sans qu’il y ait d’appel d’offre ou pourvues avant même la parution de l’AO (Copinage…). Sans copains, moins d’opportunités.
2. Tous les grands comptes ont un service achat qui référence les fournisseurs. En étant indépendant, impossible d’obtenir de référencement. Nous sommes obligé de passer par un intermédiaire qui se sert largement au passage (20% en règle générale).
3. Aucun pouvoir de négociation face à nos propres fournisseurs. Nous payons nos formations plein pot, nos conférences pleins pot et nos comptables pleins pot
4. Pas de support en cas de difficulté technique, commerciale ou même juridique en mission.
5. Pas d’image. Nous avons même plutôt une image « négative », certains nous voient comme des mercenaires.
6. Si vous êtes formateur, ou désirez donner des formations, difficile de proposer un catalogue de formations et de se faire connaître et en restant isolé.

Ce rassembler autour d’une structure commune devrait permettre de palier à toutes ces difficultés, c’est ce que propose Prosymna. Read more »

J’ai participé hier à la deuxième édition du kawa barcamp. Un bar camp c’est une rencontre ouverte autour de thèmes choisis par les participants. Nous étions hier une trentaine de personnes réunis pendant environ 3 heures. Après un bref tour de table où nous nous sommes présentés (nom + prénom + 3 mots clés), 8 personnes ont inscrits des thèmes d’ateliers sur un tableau. Nous devions choisir parmis 2 sujets au choix : Read more »