Utiliser Eclipse derrière un proxy à la con

Vous connaissez les proxy à la con ? C’est une spécialité des grandes boîtes françaises qui ont une vision assez … restrictive … de ce qu’est un « bon » usage d’internet.

Par exemple, j’ai dû il y a peu installer un Eclipse pour me connecter à un serveur Subversion chez un client qui n’autorise pas l’accès à bintray. Pas grave ? Ca dépend.

Par habitude, j’utilise Subclipse. Or, récemment, ils ont changé leur hébergement pour passer .. chez bintray. Du coup, le plugin n’est plus téléchargeable. Heureusement, eclipse est modulaire, et j’ai pu installer Subversive « facilement » : pour installer Subversive, on installe d’abord le plugin, qui télécharge indépendamment les connecteurs sur un site qui a changé. Ca se passe bien sans proxy à la con. En revanche, dans le cas contraire, il faut télécharger l’update site contenant les connecteurs. Et c’est tout aussi merdique (même si, en fait, Subversive semble mieux que Subclipse – au merge dialog près).

Publicités

Interruption du développeur … veuillez patienter ….

Au début de la semaine, je suis tombé sur ce dessin assez éclairant sur le coût de l’interruption d’un développeur (quelquesoit son domaine) (via SebSauvage)

C’est assez clair, non ?

Seulement voilà, la démarche isolationiste n’est pas toujours bonne : le développeur ne peut pas toujours s’isoler dans sa grotte le temps de rejoindre « la zone » (l’état d’esprit de productivité maximum du développeur, pour les non-hipsters parmi vous), parfois pour des raisons géographiques, parfois également parce que ces interruptions sont bonnes.

Bonnes ? Pas comme … une personne physiquement appréciable, mais plutôt comme positives.

Parfois, un mec qui vient vous voir et vous interrompre avec une question à la noix vous amènera à changer d’oeil sur votre travail, pour éventuellement produire une amélioration plus que significative. Et ça, c’est bien.

Bon, parfois, aussi, ce sera un rappel à l’ordre de la hiérarchie, qui concerne évidement un problème insignifiant. Et qui n’améliorera rien. Mais bon, il faut savoir accepter le fait de vivre dans une structure hiérarchisée … même si ça n’est pas toujours aussi évident que ça.

Du coup, si je trouvais le dessin intéressant d’un point de vue privé, je ne le trouvais pas partageable : il n’apportait pas de valeur ajoutée en ne faisant que constater un état de fait.

Aujourd’hui, je tombe (via Rui Carno) sur cet article bien plus intéressant, mais sur le même thème : Programmer Interrupted. Si le thème est le même, l’objectif est proche : voir comment les développeurs gèrent ces interruptions. Et comme ce blog est mon lieu d’introspection favori, je vous livre ici quelques solutions qui me permettent de gérer au mieux les interruptions (pour ceux qui suivent ce blog depuis longtemps, vous verrez que je ne fais que répéter des choses déja écrites).

Donc, qu’est-ce qui me permet de survivre aux interruptions ?

Le compilateur

C’est à mon avis mon premier allié. C’est lui qui me dit où j’en suis précisément : si je m’arrête au milieu d’un statement, c’est lui qui va me permettre d’identifier le point d’écriture. Du coup, évidement, j’ai un désir particulier de voir tout mon code vérifié par le compilateur (on me dira évidement que ça ferait de moi un parfait développeur Scala …. mais je n’y crois pas. je crois plutôt que je serai pour un Groovy où l’annotation @StaticCompile est activée par défaut). Pour ça et pour d’autres choses, hein.  Je me demande d’ailleurs toujours si je ne pourrais pas aller plus dans cette direction avec error-prone, même si je le soupçonne d’être fortement redondant avec les assistances que fournit Eclipse.

L’éditeur

Un autre allié, que j’ai longtemps méprisé, c’est la coloration de la ligne courante. Je me souviens qu’il y a cinq ou dix ans, je désactivai toujours ce truc que je trouvais ridiculement intrusif. Et puis je suis passé à Solarized Light. Et je dois dire que ce thème de coloration syntaxique dans Eclipse utilise une couleur non intrusive pour la ligne courante, qui fait que je l’ai laissé activée et que j’ai découvert tout son sens : quand on m’interrompt et que je reviens dans mon éditeur, je vois tout de suite la ligne sur laquelle je bosse. Et comme je ne mets qu’un statement par ligne, ben même si il compile je sais précisément sur qui je travaille.

L’automatisation de l’IDE

En plus des vertus propres à l’éditeur, je n’oublie pas les capacités formidables d’Eclipse à modifier mon code de façon automatique. Générer des getters/setters/toString/hashcode, faire des refactorings complexes, tout ça me libère d’une charge intellectuelle assez importante et me permet de ne pas avoir à me demander si un ttruc est bien implémenté ou pas : j’écris ce que je veux voir apparaître et, si ça n’existe pas, Eclipse et moi travaillons ensemble pour le faire apparaître. Ca peut apparaître comme de la simple optimisation de productivité mais c’est bien plus que ça : le fait qu’Eclipse puisse me faire les bonnes propositions me permet de ne pas m’encombrer l’esprit de considérations inutiles, et allège donc mon contexte intellectuel (la fameuse conceptual memory mentionnée dans l’article, autrement dit l’espèce de modèle en non patates que je me fais du code sur lequel je bosse).

La définition de la tâche en cours

Dans l’idéal, cette définition serait immédiatement accessible grâce à Mylyn, mais ça n’est hélas pas le cas de notre version de mantis, par exemple, et dans le contexte économique actuel, Tuleap n’est pas une priorité. J’utilise donc de plus en plus les bugs mantis qui me sont assignés comme un vrai journal de travail : j’y note chaque avancée ou découverte significative pour éviter d’avoir à m’en souvenir. Parce que les souvenirs partent, et que les écrits restent (un peu plus).

Et ce qui me surprend avec ça, c’est qu’on soit très peu nombreux à agir de la sorte, alors même que les bugs à résoudre sont toujours aussi complexes.

Autrement dit ?

Je ne pense pas être meilleur que mes collègues pour résister aux interruptions.

En revanche, je crois réussir peut-être un peu mieux à persister mon contexte de travail d’une manière qui me permette d’y revenir d’une façon efficace. Ce qui est marrant, c’est que c’est exactement comme pour les méthodes de productivité : ceux qui sont conscients de leur existence sont tjours à la recherche d’une amélioration potentielle, alors que ceux qui les méprisent continuent de brasser de l’air …

Un template de setter fluent

Supposons que vous souhaitiez développer une API « fluente ». Ou plutôt, pour étre un peu plus simple (parce que bon, je l’ai déja fait, enfin, j’ai essayé, et c’est vraiment pas de la tarte), vous souhaitez implémenter facilement le pattern builder.
Une manière simplifiée de le faire est d’ajouter des « setters fluents », comme je les appelle, c’est-à-dire des setters qui retournent this au lieu de ne rien retourner. Ca ne pourrit pas les classes (puisqqu’on retourne quelque chose là où il n’y avait rien), et ça permet d’éviter la multitude de constructeurs qu’on peut être amenés à écrire. Tenez, regardez donc cet exemple :
Facile à utiliser, non ?
Bon, par contre, comme il s’agit de méthodes, il faut les écrire. Et, franchement, écrire à la pelle des méthodes toutes identiques, c’est pénible. J’ai donc écrit un petit template Eclipse pour me faciliter la vie :
Et une fois qu’on a fait ça, la face du monde n’est pas changée, mais le code devient plus facile à écrire.
Bon, par contre, si vous ne savez pas à quoi servent les tags @category, je vous encourage à aller voir chez Eclipse

Expériences typographiques

Depuis mon passage au travail à un écran Full HD 21″, j’ai constaté que j’avais plutôt mal au cou (plus précisément à la nuque) le soir. La raison ? Elle est assez simple. Ayant une vue « médiocre », au mieux, j’utilise systématiquement la fameuse technique du JMMPP.
Faut dire aussi que ma police de caractère de codage, Proggy Clean TTZ, rend franchement mal au-delà de 12 points, ce qui, sur un écran à forte résolution, rend assez mal.
Je vais donc devoir me livrer à une migration pas évidente du tout : le changement de police de caractère.
Heureusement,c ‘est le genre de sujet sur lequel l’internaut est prêt à toput pour me donner son avis. je peux déja aller voir
  • Hivelogic
  • Codinghorror, qui deux fois reprit le sujet
  • Et bien sûr DaFont, qui, avec la bonne catégorie et le bon texte d’exmple, donne un bon aperçu du résultat …
Je vais donc me lancer dans une expérience utilisant au moins Inconsolatas, et peut-être changer la semaine prochaine pour une autre, jusqu’à trouver une police satisfaisant différents critères de goûts personnels.
En bonus, et toujours dans une optique d’optimisation de mon environnement le plus immédiat de travail, j’ai découvert la semaine dernière l’expérience Solarized, reprenant une idée que j’avais expérimenté il y a une bonne dizaine d’années : utiliser un fond d’écran jaune clair, plutôt que blanc, pour dimuniuer un peu le contraste de l’éditeur de code et, de cette manière, limiter également ma fatigue occulaire. Et pour ça, j’ai décovuert, ce matin même, un ensemble plugin Eclipse/site web très bien pensé : Eclipse Color Themes. Parce que je sais pas si vous avez déja essayé de changer les couleurs de votre éditeur dans Eclipse, mais personnellement, je l’ai fait, et franchement, j’en ai chié pour un résultat pas forcément flatteur.
Donc avec Eclipse Color Themes, vous allez sur leur site, vous trouvez un thème qui vous convient (par exemple … Solarized Light), vous téléchargez le fichier XML, et pouf ! Entre parenthèses, je pense qu’ils auraient pu se fendre d’un client web dans le plugin, c’aurait été carrément plus chouette, mais bon, c’est de la beta, hein.
Et une fois toute ces opérations effectuées, votre meilleur éditeur ressemble à ça :
_2014-01-09_11-00-43
C’est sûr, ça change pas mal du noir et blanc « classique » mais je vous en dirai plus la semaine prochaine.

Infinitest ? Done

Vous le savez peut-être, au bureau, on utilise un langage qui n’est pas le Java. Qui n’est pas non plus le C#. Qui n’est pas non plus le {langage bien connu qui figure dans le Tiobe index}. En fait, pour être honnête, il n’y aucune espèce de chance que vous le connaissiez si vous n’avez pas travaillé dans l’entreprise qui m’emploie actuellement, ou en avez été un client.
C’est une situation assez difficile, parce que les outils qui existent pour les langages plus connus n’existent pas chez nous. Pas plus, d’ailleurs, que n’existent les frameworks de développement que vous utilisez, ou même les outils de build qui vous sont imposés. Les outils dont on dispose, ce sont ceux qu’on crée nous-mêmes.
Je suis donc assez fier de pouvoir affirmer que, nous aussi, nous pouvons écrire des tests unitaires à la JUnit (éventuellement paramétrés). J’en suis fier, parce que c’est moi qui ai écrit (avec l’aide d’un expert local, évidement), l’outil d’exécution des tests unitaires. D’ailleurs, dans une optique d’intégration continue, on a depuis des mois un job Hudson qui les exécute à distance pour agréger leurs résultats.
Mais bon, tout ça, c’est de la rigolade, ça vaut pas mieux que le plugin JUnit pour Eclipse.
Ce qui serait vraiment canon, ce serait de disposer d’un outillage à la Infinitest qui, quand on modifie un fichier source, repère les tests intéressants, les exécute, et affiche les résultats. Enfin, Infinitest, c’est peut-être un peu ambitieux, on pourrait peut-être se contenter de quelque chose comme JUnitFlux.
Et bien devinez quoi ? C’est ce qu’on a fait.

 

En fait, on a ajouté à nos fichiers un commentaire

 

@testedBy UneClasseDeTest

 

Et, quand le fichier est compilé, toutes ces annotations sont lues, les tests unitaires de ces classes sont exécutés, et les résultats sont affichés dans la vue JUnit d’Eclipse (grâce à un bon coup de reverse engineering sur le format XML de JUnit/Ant – merci encore à StackOverflow). Et franchement, c’est incroyablement pratique : à la sauvegarde d’un fichier, on sait tout de suite si le test unitaire fonctionne encore. On a donc, en plus de la compilation, une information supplémentaire sur la qualité du code produit. Et ça, ça donne envie d’aller encore plus loin, justement en essayant enfin Infinitest … mais évidement, c’est beaucoup plus compliqué d’analyser quels tests unitaires s’appliquent à un fichier donné quand on ne dispose pas des innombrables librairies d’analyse de code dont dispose Java.

Un template bien pratique pour Eclipse

Vous connaissez déja depuis longtemps le template pour créer un logger facilement dans Eclipse. J’en ai quelques autres, mais celui dont je voudrais vous parler aujourd’hui, c’est celui pour le code des méthodes.
Allez dans « Preferences …/Java/Code Style/Code Templates », sélectionnez « method body », et remplacez le code existant par
// ${todo} Auto-generated method stubthrow new UnsupportedOperationException("method "+${enclosing_type}.class.getName()+"#${enclosing_method} has not yet been implemented AT ALL");

De cette manière, quand vous créez une méthode, soit en implémentant une interface, soit  en surchargeant une méthode parente, vous vous retrovuez, si vous l’appelez, avec une belle exception qui vous rappelera à cahque exécution qu’une partie de votre code n’a pas encore été implémentée, plutôt que d’avoir simplement une méthode vide qui ne vous poussera qu’à vous creuser la tête.

C’est peut-être pas le standard dans Eclipse, mais si vous cherchez un peu, vous verrez que c’est assez courant dans le monde Java.

ActionScript, c’est … moins bien

Depuis quelques temps, je suis un peu obligé de faire de l’ECMAScript … Enfin, de l’ActionScript 3 … Enfin, du Flex. Et globalement, c’est vraiment pas glorieux.
La plateforme de développement (un Eclipse salement customisé) est lourde, payante (argh), franchement pas performante, et ne contient aucun des outils typiquement agrçables (comme le refactoring).
Les API sont encore plus obscènement lourdes, avec en plus des détections d’erreur franchement comiques.
Et, pour finir, tout ça sert à produire du Flash qui va juste bouffer la mémoire de la machine du client pour un rendu tout sauf agréable.
En fait, le seul avantage, c’est que je peux faire des closures. Et je crois que, du coup, je ne vais pas me priver !

Une semaine de XText

Outline_eclipse

Cette semaine (et la semaine dernière) je n'ai pas passé mon temps avec mes enfants. Non, comme tout jeune embauché, j'ai passé mon temps au bureau à bosser sur un domaine que je connaissais jusqu'é présent assez mal : l'écriture de grammaire. En fait, à l'origine, je devais juste écrire un éditeur avec coloration syntaxique pour un langage propriétaire utilisé par le logiciel de mon entreprise. Seulement, je me suis dit qu'il ne serait pas beaucoup plus compliqué, mais en revanche vraiment plus intéressant, d'extraire la grammaire du langage et de laisser Eclipse se débrouiller avec pour faire la coloration syntaxique, l'outline et peut-être même un peu de complétion. Dit comme ça, ça a l'air fou. Mais grâce à Xtext, c'est possible. Et aujourd'hui, après moins de dix jours de boulot (ce qui pour un débutant dans le domaine est vraiment très court), j'ai une grammaire à peu prés complète du langage (regardez l'image jointe pour vous en convaincre).
je dois dire que Xtext est particulièrement bien fichu. on dispose d'un éditeur avec coloration syntaxique pour les fichiers antlr et, une fois ces fichiers compilés, on peut lancer un eclipse configuré pour reconnaître le langage sur lequel on travaille, ce qui permet de tester très facilement la qualité de l'arbre syntaxique généré (grâce à l'outline, justement, qui affiche tous les symboles reconnus).
Mon fan doit être fou, lui qui attend chez mon ancien employeur depuis environ 2 ans de pouvoir faire ce que j'ai fait sur un langage encore plus merdique 😉
Moi, de mon coté, je vais m'attacher à améliorer cet outline pour n'afficher que les éléments utiles dans l'outline, pour éventuellement ajouter un peu de complétion (et surtout l'affichage de la doc associée). Mais à mon avis, pour tout ça, je vais devoir plonger dans l'enfer des modèles ECore de Eclipse … Et ça risque de pas être de la tarte, même avec la doc de Xtext.

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 ?