Au menu:

• Which style of WSDL should I use?
• JSF: the good, the bad and the ugly…
• Eclipse et mylyn, pour une gestion efficace des bugs et des tâches d’un projet de développement
• SpringSource Tool Suite Released
• Activer un aspect par JMX
• Build time vs. render time
• Choose your managers wisely; they have cookies on the dark side
• Software Architecture Document Guidelines

Which style of WSDL should I use?

Cet article n’est pas tout récent, contrairement aux autres. Cependant, si je vous le propose c’est parce qu’il est très intéressant et très didactique.
Il résume la problématique RPC vs Document et Literal vs Encoded. Cette problématique est toujours d’actualité et ne semble pas forcement résolu, comme par exemple chez mon client, où j’ai du me frotter aux urbanistes à ce sujet.
Pour résumé : RPC/Encoded c’est très mal car très lourd, Document/Literal c’est pas terrible car trop léger et les outils ont du mal à s’y retrouver (c’est le cas d’Axis). Enfin, les deux solutions cohérentes sont RPC/Literal et surtout Document/Literal « wrapped ».

JSF: the good, the bad and the ugly…

Un bref retour d’expérience sur JSF qui illustre bien ce que j’ai pu lire par ailleurs.
En résumé : Pour les plus on a : les managed beans, le support d’AJAX via java et taglib et sans horrible JavaScript, et l’aspect composants.
Pour les moins : un manque de support IDE, la bookmarkabilité des pages impossible de base, la difficulté d’utiliser le scope request, la création de composants personnalisés très obscure.

Eclipse et mylyn, pour une gestion efficace des bugs et des tâches d’un projet de développement

Une brève présentation des fonctionnalités de Mylin, un des projets les plus en vogue d’Eclipse.

Le but de Mylyn est de proposer une interface visuelle destinée à faciliter le traitement de tâches et de bugs directement au sein d’Eclipse. Ceci bien évidemment dans un but de gain de temps, d’efficacité et de synergie entre les outils.
Mylyn n’est pas un gestionnaire de bug, il s’agit d’une interface visuelle entre Eclipse et votre gestionnaire de bugs. Le choix de ce dernier repose donc toujours sur les besoins de cette gestion et les outils disponibles sur le marché.
Mylyn propose un connecteur générique pour n’importe quel outil de suivi mais s’intègre particulièrement bien avec Bugzilla, Trac et JIRA.
L’intérêt ? Disposer dans Eclipse des tâches et des bugs pour faciliter et automatiser les traitements.

SpringSource Tool Suite Released

SpringSource essaye de développer le support de Spring dans Eclipse. Elle a sortie cette semaine la bêta de « Spring Tool Suite », un ensemble d’outils Eclipse.
SpringSource précise bien que cet outil n’a pas la vocation de remplacer le projet SpringIDE.

So lets see what we got:
• Spring Development Tools
• Mylyn’s Task-Focused User Interface for Java, Resources and Spring application blueprints
• Task-Focused Tutorials
• Runtime Error Analysis
• Best Practice and Architecture Review tools

Activer un aspect par JMX

Un article sympa qui donne des idées sur les possibilités du mariage de l’AOP avec JMX. A développer.

Build time vs. render time

Cet article présente le problème de base entre JSF et les pages JSP et les tags JSTL. Ceci provient du fait que les composant et les pages JSP ne sont pas interprétés au même moment :

What I mean by JSF being a component technology, is that HTML is produced by the processing of a component tree by renderers. This design is much more similar to Swing than it is Servlets and JSP.
…
Most of the « work » of a component takes place during rendering. For example, the h:dataTable sets up the var attribute during rendering (and other phases too, but that is not pertinent to this article). This means that EL expressions that rely on variables that only have scope during the rendering phase are not valid during component creation. That is to say, there is no component lifecycle method for when the component is created.

Choose your managers wisely; they have cookies on the dark side

Un article marrant, mais malheureusement assez vrai…

…
I am saying that management is one of the professional areas that is relatively easy to get in to but extremely hard to perform well.
Somehow, in the Netherlands, it is fairly common that once a person becomes the best in his department (in operational sense), they get to lead the department.
Nobody has ever been able to explain that to me though; why does your best programmer/business analyst/etc. make a good manager?
The qualities that lead them to be the best in their field are mostly not the qualities that are required for a good manager.
Besides gaining a potentially bad manager you also lose your best operational person; sounds like a lose-lose situation to me.

Software Architecture Document Guidelines

Ce document donne une ligne directrice pour l’écriture d’un dossier d’architecture. Très intéressant, à lire.

Il s’articule autour des points suivants :

1. Functional View
2. Non-functional View
3. Architectural Principles
4. Architectural Constraints
5. Process View
6. Logical View
7. Interface View
8. Technology Selection
9. Design View
10. Infrastructure View
11. Deployment View
12. Security View
13. Monitoring, Management and Administration View
14. Data View
15. Justification of the Non-functional Requirements

• La première est l’utilisation des regex dans l’éditeur « rechercher/remplacer ». Comment peut-on gagner beaucoup de temps et s’éviter un boulot à la con ?
• La seconde est l’utilisation des « tasks » (TODO, FIXME, …). Comment bien les utiliser, comment créer les siennes ?

Astuce 1 : gagnez du temps, utilisez les regex

Il n’y a rien de plus chiant quand l’on code que de faire des séquences répétitives comme par exemple : (appui sur la touche « fin », « ; », « flèche du bas » ) * 20 …

Plutôt que d’effectuer des tâches répétitives, je préfère bien souvent plutôt utiliser le temps que je passe d’habitude à effectuer ceci et ensuite à corriger les erreurs (qui s’insèrent souvent lorsque l’on fait ce genre de chose) par plutôt chercher une expression régulière qui effectuera ce boulôt.

Eclipse propose un support basique mais assez efficace des regex dans l’écran « Rechercher/Remplacer » (raccourci ctr+F). Pour celà, il suffit de cliquer sur la checkbox « Regular Expression ».

La syntaxe est identique aux expressions régulières java : « . » pour tout caractère, « * » pour répéter 0 ou n fois, « () » pour capturer un groupe, « [\w] pour récupérer uniquement les caractères de mots, etc…

Pour récupérer les groupes que l’on a capturé, on utilise dans la partie « replace with » les expressions $1 pour le premier groupe, $2 pour le suivant, etc…

Un petit exemple bateau :

A partir de l’exemple ci dessus, imaginez que l’on veuille vérifier que toutes les variables de classes ne soient pas nulles.

On copie colle la définition des variables dans notre méthode (voir image1).

On recherche l’expression : « Private String ([\w]*) = «  »; »

Que l’on remplace par exemple par : « if($1 != null && !($1).equals(«  »)){}

Ce qui produit comme résultat :

Marvellous!

Astuce 2 : n’oubliez rien, utilisez les tasks

Je suis un fan des TODO/FIXME. C’est à dire que plutôt que d’écrire sur trois milles post-it les choses restant à faire, ou à corriger ou bien d’utiliser l’éternel « Nouveau document texte.txt » posé sur le bureau. Je préfère que tous ces éléments soient directement intégrés dans le code.

La vue des tasks se présente comme suit :

On remarque tout de suite que l’avantage est que les tâches sont localisés à l’endroit ou elle doivent être. Un clic et on s’y rend. De plus, elle sont priorisable (high, normal ou low).

On peut de plus créer ses propres tâches personnalisées. Pour cela, se rendre dans les préférences -> Java -> Compiler -> tasks tags :

Le seul inconvénient, est que l’on sera le seul dans l’équipe à les voir si les autres ne rajoutent pas ces mêmes tâches. Dans l’exemple, j’ai rajouté une tâche NAT avec une priorité haute. J’ai aussi pour habitude de descendre la tâche XXX en priorité faible.

Un autre truc cool avec les tâches est la gestion facile des filtres. Ces filtres ressemblent pas mal à ceux de la vue « Errors » :

Ce qui est intéressant est de placer le filtre sur uniquement la classe ouverte lorsque l’on code (radio « On selected Element Only ») et éventuellement de filter sur les priorités. Quand on veux ensuite faire du refactoring global on enlève ces filtres, pratique!

Bonus :

En petit bonus aujourd’hui, je vous propose cet article que j’ai découvert hier, présentant diverses astuces Eclipse.

Une astuce utile à laquelle je n’avais pas réfléchi et de remplacer dans les templates la génération du try/catch pour insérer dans le catch :

logger.severe(« Exception caught:  » + ${exception_var});

Tout bête, mais pratique.

C’est tout pour aujourd’hui. En espérant vous avoir fait gagner 5 minutes sur votre prochaine journée