Mais arrêtez de choisir des noms de framework à la noix !

C’est quand même pas possible !

C’est vraiment si compliqué de choisir un nom inutilisé sur internet ?

Vous cherchez un nom, vous le tapez dans Google, et si il y a un résultat dans le monde informatique, vous changez de nom. Ca vous évitera des horreurs comme, par exemple, Apache Click (impossible de trouver la moindre doc dessus rien qu’à cause du nom) qui est d’ailleurs arrêté.

Enfin, je prends celui-là, mais il y en a des dizaines dont le nom empêche toute recherche utile.

Vis ma vie de développeur de merde avec Java sur Mac

Bon …

Je ne vais pas forcément rentrer dans les détails, ils sont plus sordides que tout ce que vous pourriez imaginer, il suffit pour l’instant de faire l’hypothèse que je travaille pour une entreprise développant une application partiellement écrite en Java et dont un composant peut fonctionner sur Mac OS.

Notez bien que, personnellement, ça fait bien longtemps que j’ai compris la nature profonde de l’OS de Cuppertino, mais bon, hein, il faut savoir faire des con-promis (ceci n’est pas une faute).

Donc …

Et n’allez pas croire que je crois aux présages, mais quand même, Jobs sort ces jours-ci, et nous nous prosternons devant l’homme qui a, mieux que Bill Gates, mieux que les rêves les plus fous d’Orwell, mieux que la pub qu’il faisait en 84, réduire nos libertés individuelles au droit de faire ce qu’il veut (mêeme depuis sa tombe) puisque nous ne sommes que des invités chez lui.

Donc … (on va finir par se croire dans la NLDD ici)

Je me suis retrouvé la semaine dernière à corriger un bug approchant de cette histoire traînant sur les ML d’Apple.

En gros, mon application charge un composant JMX (ça, c’est prévu) qui, lui, charge AWT (le système de fenêtrage originel de Java) qui, lui, refuse de se charger pour une raison inconnue.

A l’origine de tout ça, une classe du système d’instrumentation de Java : com.sun.jmx.trace.Trace. Vous ne la trouverez pas sur le web puisque, comme l’indique son nom de package, c’est une classe privée de chez Sun/Oracle (par convention, les packages com.sun.* sont privés et ne sont pas accessibles aux simples développeurs, mais on peut y jeter un coup d’oeil dans les sources du JDK).

N’écoutant que mon courage (et la pile d’exception), j’ai été jeter un coup d’oeil autour des lignes indiquées par la pile d’exception : 

at com.sun.jmx.trace.Trace.out(Trace.java:180)

Parce que souvent, c’est là que les problèmes se trouvent …

Et là, je cite mon Eclipse : 

Image

 

Eh ouais, la ligne n’existe pas dans la version dont je dispose. Et c’est là que j’ai compris que je partais tout droit en enfer, juste armé d’une brosse à dents.

Parce que figurez-vous que le JDK d’un Mac n’est pas celui d’un Windows/Linux/N’importe quoi.

Non. Il y a quelques années, Apple voulait pousser en avant Java. Ils se sont donc mis d’accord avec Sun/Oracle pour repackager un JDK Apple avec quelques additions sympathiques.

Du temps est passé sous les ponts, et cet accord s’est arrêté vers … 2013 ? Je crois, à la demande d’Apple, qui préférait miser sur son propre langage de kalitaye (encore une fois ça n’est pas une faute) : Objective-C aussi pratique sur un iMac que sur un iPhone, ou encore un iFuckYouDeep.

Mais chez Apple, on aime bien laisser des bonnes surprises en partant.

Par exemple, la mise à jour Java 16 de Java qui, sur tous les ordinateurs utilisant MacOS, casse méthodiquement JMX en lui ajoutant une dépendance débile sur AWT. Parce que bon, cette mise à jour passe le Java des Mac en version 1.6.0_51. Cherchez donc chez oracle cette version … elle n’existe pas. Et ouais, l’effet zone 51 joue à fond.

Vous en voulez encore ?

Les ordinateurs ayant reçus cette mise à jour sont tous ceux tournant sous Mac OS 10.6.8. Pour bon nombre d’entre eux, la mise à jour vers 10.7 ou 10.8 est interdite par Apple (comme ils ont interdit d’ailleurs la mise à jour de mon iBook il y a quelques années – je vous laisse chercher dans le blog).  Ah, et en bonus Oracle ne livre pas de versiond e Java 7 pour cette version de Mac OS. Donc si vous utilisez cette version, vous êtes baisés et re-baisés.

En bonus caché, certaines applications utilisent Java en version 32 bits (ou i386 si vous préférez). Or, quand bien même vous installez Java 7, il ne s’agit que de la version 64 bits ! Du coup vous vous faites chier à faire la mise à jour, mais le bug continue à exister pour toutes les vieilles applications. Et comment faire pour corriger ? Oh, be simplement demander à Adobe de se bouger le cul pour recompiler leurs applis en 64 bits.

Bref, vous êtes baisés, re-baisés, et re-re-baisés.

Comme moi maintenant qui dois trouver un contournement.

Trouver d’où vient une classe … facilement

Vous savez qui sait d’où vient la classe Java que vous avez sous les yeux dans le débuggeur, et qui ne correspond pas … exactement …. à ce que vous croyez ?

Le ClassLoader qui l’a chargé.

Et vous pouvez même lui demander :

https://gist.github.com/Riduidel/5337125

C’est rudement pratique pour débugger du code un peu tordu (comme un connecteur neo4j JCA, par exemple).

Tempus Fugit

Pour aller avec Contiperf, ou plutôt pour en compléter certains articles, Tempus Fugit est elle aussi une librairie intégrable dans JUnit (mais pas que) qui permet de faire un truc typiquement galère dans un test unitaire : du multithread.

Vous savez, tous ces trucs hyper galère comme par exemple tester si un deadlock se produit … Oui, neo4j, je regarde tes histoires de supernodes pour gaedo, et j’ai les boules.

Finalement, Github, c’est vraiment bien

Dans mes souvenirs, j’étais assez critique face à Git/GitHub …Seulement, il s’avère que c’est faux, et que mon dernier message à ce sujet était plutôt gentil. Et heureusement, parce que GitHub avec les clients Git des IDEs modernes est assez facilement utilisable. Aussi bien dans Eclipse avec EGit que dans NetBeans (par défaut !), on peut raisonnablement puller,pusher …Et c’est tant mieux, parce que je m’en sers de plus en plus sur deux projets plutôt pas mal :

  • gaedo … eh oui, gaedo a dû quitter Origo, qui s’est éteint brutalement en mai dernier … il a donc trouvé chez GitHub (qui me permet au moins d’avoir toujours le repository complet sur ma machine).
  • agorava-stackoverflow que j’ai créé aprés avoir écouté Antoine Sabot-Durand se faire interviewer chez les castcodeurs, et qui me permet de relancer, sous une forme différente mais que j’espére bien meilleure, ce fameux projet d’aspirateur de site. (et qui en bonus me permet de faire à la fois du GitHub, mais aussi du Weld /CDI ).

D’ailleurs, j’ai découvert grâce à GitHub deux ou trois choses bien sympatoches. Par exemple, je fais maintenant mes sites maven en Markdown, pour pouvoir utiliser les pages dans le site généré (grâce à doxia-module-markdown), dans le site sur GitHub (grâce au rendu Markdown de GitHub et grâce à GitHubpages , qui utilise pour mes projets les mêmes fichiers). Mais la grande force de GitHub, malgré son côté spartiate,c’est GitHub issues , qui intégre complétement le bug reporting au développement. Tenez, regardez comment j’ai fermé le bug #11 de gaedo ! Un simple commentaire dans le commit, et pouf, le bug est fermé. C’est un rêve tellement c’est pratique … Un rêve difficilement atteignableavec SVN (même en utilisant Mylyn , puisqu’il faut ajouter les webservices SOAP à mantis, ce qui n’est pas toujours possible). Et je vous parle même pas de la facilité avec laquelle on intégre les modifications des autres grâce aux pull requests. Autant le dire, je commence à étre convaincu par Git, grâce essentiellement à GitHub et aux plugins des IDE (aussi bien NetBeansqu’Eclipse) qui font de Git un DVCS aussi pratique que SVN (voir même encore plus pratique grâce à la gestion intégrée des issues).

Fork me I’m famous !

J'entends régulièrement parler de Git/GitHub/Mercurial/toussa depuis maintenant environ quatre ou cinq ans.
Depuis toutes ces années, j'en retiens une impression de complexité, sans doute dûe à des à-prioris antérieurs. Cela dit, ces derniers temps, ça a changé.
D'abord, grâce à EGit, le plugin pour Eclipse. Parce que je ne sais pas si vous savez, mais moi, je suis PC, et Eclipse, c'est mon idée … Mais qu'est-ce que je raconte, moi ? Bon, il se trouve en fait plutôt que j'utilise Eclipse depuis … environ … 9 ans. Et depuis toutes ces années, s'il a bien une fonctionnalité qui fait la différence, c'est sa gestion du travail en Eclipse … pardon, en équipe (c'est le soir, j'en ai marre). Tiens, par exemple, vous saviez, vous, qu'Eclipse est sans doute l'un des meilleurs clients Subversion (comble du luxe, en fait, c'est un double client Subversion basé sur deux librairies bas-niveau totalement interchangeables – et si vous voulez tout savoir, j'ai du écrire un bon paquet de code avec SVNKit, et même si c'est assez curieux, ça fonctionne finalement très bien) ? Tout ça pour dire quoi ? Eh bien simplement que EGit est au niveau de Subclipse. C'est un plugin qui s'intègre très bien dans Eclipse et permet de faire la plupart des opérations sans y penser : pas de problème pour faire des push/pull, pas non plus de soucis pour créer des branches, commiter, … Bref, EGit, c'est l'anti-ligne de commande et ça c'est bien !
Seulement, avoir le client, c'est bien, il faut aussi avoir le projet sur lequel travailler … Et il se trouve que, récemment, j'ai dû utiliser plusieurs projets hébergés sur GitHub pour lesquels existaient certains bugs qui m'affectaient particulièrement et qui étaient assez faciles à corriger.
Prenant donc mon meilleur clavier, j'ai entré un bug dans le bugtracker de l'un de ces projets, forké la branche master sur mon compte GitHub, récupéré cette branche sur ma machine, implémenté la feature, commité, pushé, fait la pull request … (dit comme ça, c'est long, et je dois dire que j'ai été impressionné … pas par la complexité, mais par le fait que, justement, avec EGit, c'est aussi facile que du Subversion). Et voilà ! Mon commit a été intégré !
Bon, je sais, pour vous, tout ça, c'est rien. Mais pour moi le monde de Git et de GitHub est longtemps resté très mystérieux. Avec cette expérience, les choses se clarifient notoirement. Et d'autres bugs vont bientôt être corrigés !

Pourquoi j’ai un à-priori contre git

Le titre semble provocateur, pourtant il reflété très exactement mon état d'esprit. Oui, j'ai un authentique à-priori contre git.
Quel est cet à-priori ? Facile, j'ai envie de penser que git est une espèce de truc typiquement linuxien : très puissant, mais vraiment pas pensé pour être utilisé. Plus pensé pour être bidouillé, en fait.
Mais revenons au début.
La mode de ces dernières années, en ce qui concerne la gestion de sources, est de diaboliser Subversion (trop nul pour gérer les branches, typiquement) pour pouvoir lui préférer des outils distribués. Parmi ces outils, on trouve évidement Mercurial, Git, mais aussi Darcs, Arch, Bazaar et quelques autres qui tentent de se faire une place au soleil. De tous, c'est évidement git qui s'est fait le plus vite une place au soleil. D'abord par sa naissance : la légende veut qu'il soit sorti habillé de pied en cape de la tête de Linus Torvalds, à la façon d'Athena. Et ça, pour n'importe quel linuxien, c'est un signe de perfection. Ensuite, comme Linus Torvalds a un peu d'influence, il a fait en sorte que git soit utilisé pour le noyau Linux, ce qui a immédiatement permis son utilisation dans le cercle des alpha-geeks (parce que n'en déplaise aux grognons, les mainteneurs du noyau Linux sont clairement des alpha-geeks, au même titre que, je sais pas, moi, les Java Champions, ou les leaders de JUG, voire les multiclassés champions/JUG leaders/pubs vivantes pour L'Oracle ;-)). Du coup, très vite, git est apparu comme le DVCS à utiliser (bien plus que darcs, par exemple, pourtant bien plus ancien – à peu prés 2002, fondé – d'après un ancien collègue qui doit se retourner dans sa tombe devant la trahison de Linus – sur une théorie du patch complètement conceptuelle), et s'est répandu dans toutes les sphères où le buzz fonctionne … typiquement, la sphère du Ruby on Rails. Et c'est comme ça qu'on a vu apparaitre le plus gros argument commercial en faveur de git : GitHub.
Pourtant, git n'est pas exempt de problèmes, le moindre n'étant pas sa ligne de commande, réputée "délicate" à manipuler. Et personnellement, si il y a bien un truc qui me rend fou, c'est les softs en ligne de commande où c'est le quatrième argument qui compte.
Le pire, en fait, c'est de se dire que l'alternative "compatible" existe … ben oui, avec mercurial, vous avez aussi un client de gestion de sources puissant, mais à la ligne de commande beaucoup plus compréhensible, d'après ce que j'en vois. Surtout que, contrairement à git, mercurial n'est pas un monolithe, mais une application extensible. Et franchement, vous en utilisez encore beaucoup, vous les geeks, des applications sans plugins ? Le must étant évidement qu'on trouve, parmi ces extensions, Hg-git qui permet de se connecter à un repository git avec mercurial. Notez bien sûr que le contraire n'est pas vrai. Du coup, git, utilisé pour le développement le plus visiblement open-source, apparaît comme une solution un peu plus fermée que son concurrent le plus direct …
Bon, après, mercurial ou git, j'ai l'impression que c'est plus une question de goûts personnels qu'autre chose …

copier/coller, c’est mal ?

En lisant cet article de Jeff Atwood, plusieurs idées me sont venues à l’esprit, que je jette dans ce coin de l’internet.

  1. un détecteur/empêcheur de copier/coller pour Eclipse, ça doit exister, non ? Ah, tiens … non.
  2. Si les gens utilisent du code d’internet avant celui du projet, c’est que les moteurs de recherche de code sur internet sont plus performants que les moteurs de recherche de code dans la base de code. Comment améliorer ça ? Avec un moteur de recherche interne genre fisheye ou krugle ? Auquel il faut évidement ajouter plus de commentaires de code (pour l’indexation), et, éventuellement, un système de forum autour du code pour discuter de ses corrections.
  3. Pour le GUID, he trouve que c’est une excellente idée. Mais GitHub, par exemple, permet d’archiver du source de manière visible du monde. Alors, ce GUID, est-ce que ça ne va pas dans la direction d’un contrôle de sources distribué à l’échelle d’internet ?

Agile ?

Grâce à mon collègue désuet, j'ai découvert ce joli petit badge de développeur expérimenté en programmation extrême. Ca me tente bien, je vais peut-être le mettre sur mon blog …

Par la même occasion, j'ai trouvé quelques articles intéressants sur ce blog, comme celui sur le bûcheron et sa scie

Un article d'autant plus intéressant qu'il ne me donne pas de réponses toutes faites, mais me pose plutôt des questions.

En effet, si je passe beaucoup de temps à faire en sorte de n'avoir à corriger les bugs qu'une fois, il y a d'autres domaines sur lesquels je me pose moins de questions, et où je laisse plus bosser mes collègues sans poser la moindre question. Mais est-ce un mal ? Je m'explique .. Quand je suis arrivé dans mon entreprise, on était deux développeurs et demi. Grâce à la croissance mondiale, on est passés à cinq développeurs, ce qui provoque naturellement l'accrétion de compétences autour de points clés : créer des versions, produire une architecture puissante et évolutive, faire rentrer des ronds dans des carrés, …

La question clé est : sur quels compétences suis-je en train de progresser, et où diable est-ce que j'exerce mon agilité ?

Pour parler franchement, je n'en sais plus rien.

Je suis toujours capable, s'il le faut, d'acquérir des compétences sur une partie du code ou une autre, de la maintenir et de la faire évoluer vers un code plus propre, plus testé, plus … comment dire … atomique (au sens où on ne peut pas faire plus petit sans perdre la fonctionnalité). Mais je n'ai plus l'impression que l'avenir du logiciel qu'on est en train de développer se situe sur le plan du code. A mon sens, tout au moins dans mon entreprise actuelle, le problème n'est plus technique, mais organisationnel. Et là, il y a beaucoup de boulot pour lequel il va bien falloir que quelqu'un se motive. Hélas, j'ai utilisé le mot maudit … "il va falloir". Je déteste réellement utiliser ce genre de phrases. Mais est-ce que j'ai vraiment envie de mouiller ma chemise là-dessus ? Voilà peut-être la question qui va de plus en plus m'agiter …

PS : pour le badge, voici un test à faire … Dont le résultat sonne comme un verdict peu flatteur :

Vos résultats :

Management : 5.88%

Ingéniérie : 30.43%

préconditions en Java

Quand on développe en Java et qu’on écrit des méthodes, on a souvent le cas de paramètres ayant des valeurs incorrectes (genre un paramètre nul).

Ce qu’on fait d’habitude, c’est une vérification simple :

if(toto==null) {
    toto = "toto";
}

C’est laid, hein ?

Et en plus, ça pollue le code.

En me baladant sur internet à la recherche de la solution à un problème compliqué de collection basée sur le hash contenant des éléments mutables, je suis tombé sur cet article : mutable entries in a collection qui m’a mené à celui-ci (beaucoup plus intéressant) : RuntimeExceptions and Gurus failing to meditate bon, j’aime bien la GuruFailedToMeditateException, mais ce que j’aime surtout beaucoup, c’est les vérifications de préconditions avec la classe Preconditions. J’aime même tellement ça que je me demande comment je pourrais inclure ça dans mon projet à grands coups d’annotations (pour que ça marche bien et que ça puisse aussi générer de la doc).

Du coup, j’ai commencé à re-jeter un coup d’oeil aux frameworks de programmation par contrat en Java.

Bref, c’est un sujet assez intéressant, sur lequel je vais essayer de creuser un peu.