Maven 2, coooool! Oracle, grrrrrrr! Merde, y'est où Cayer?

Written by Fneuch on 29.9.06

De retour... Comme je vous disait précédemment, j'étais dans le jus depuis qu'un collègue a levé les feutres.

Voyez-vous, mon chum Cayer (celui qui a foutu le camps) était comme qui pourrait dire LE développeur sénior dans la boite. (Des fois je me demande si le terme sénior est nécéssaire, j'aurais simplement pu m'arrêter avec LE développeur et ça aurait été aussi vrai!) La relation de travail que j'avais avec Cayer me faisait pensé à un article sur lequel j'était tombé, qui tentait de définir ce qu'est un architecte... (Faudrait d'ailleur que je retrouve cette article, si vous mettez la main dessus.) Dans cette article, il y mentionnait qu'un «Software architect» n'est pas un «lead developper», mais qu'il en dépend beaucoup. Un bon architecte devrait être appuyé par un développeur sénior. Celui-ci est en mesure de mettre en oeuvre rapidement et efficacement ce que l'architecte conçoit. Et le développeur sénior devrait être en mesure de challenger l'architecte et de signifier toutes invraiscenblance dans l'utilisation/réalisation de l'architecture. Et c'est ce genre de relation que j'avais avec Cayer. Cayer étant assigné a des projets réelles, il faisait beaucoup plus de code que moi et par le fait même, était souvent beaucoup plus efficace à produire la première version que ce que moi je pouvait faire. Il produisait généralement du bon code qu'il me restait simplement à optimiser.(je t'écoeure Seb, tu travaillais quand même bien...lol) On a fait ensemble plusieurs modifications au plugin Maven2 de JDeveloper, plusieurs optimisations aux applications sur lesquel il travaillait. Nous avons trouvé plusieurs bugs dans les composant oracle et avons tout le temps trouvé des solutions pour corriger une foule de problème. Je ne me souviens pas le nombre de fois où j'était assis dans son bureau, on gossait sur un problème, je voyais une solution, je commençait à la taper, pis aussitôt qu'il avait compris ce que je voulais faire, il me re-piquait le clavier, finissait en moins de temps que ce que ça m'avait pris pour faire le début... Le nombre de fois où j'ai pu dire, faudrait quasiment qu'on fasse ceci ou qu'on s'arrange pour que tel chose aient tel valeur et lui de me dire, facile, on a juste à prendre ça, faire ça et le tour était jouer, on venait de faire un bon bout de chemin pour solutionner le problème qu'on avait. Mon boss, très compréhensif, savait que 80% du temps, si je suis pas dans mon bureau, va voir dans le bureau à Cayer, tu vas me trouver, et que j'était rarement là sans qu'on produise qqe chose de bien. Combien de fois j'ai pu dire: "Aie Cayer, tu peux tu me tester ça?" ou bien: "Tu te souviens-tu cayer, tsé tel problème, on avait fait tel affaire, t'as tu encore la/le doc/code, tu peux-tu me l'envoyer?" (ceux qui me connaisse savent que j'ai pas de mémoire, je me souviens juste où j'ai mis l'info, pas c'est quoi l'info...).

Or, il est parti. Et tout les test ou idées que j'ai, je doit les faire seul. Avant son départ, nous avons converti à Maven 2 toutes les applications sur lesquels il travaillait. Sans lui, ça aurait été impossible. Nous les avons toutes converties à un détail près, il nous fût impossible de pré-compiler les pages JSP. Le plugin jspc-maven-plugin de codehaus utilise les librairies de Tomcat pour faire la compilation. Il insère dans le fichier web.xml toutes les références nécessaire aux servlets ainsi créer (pour ceux qui ne le savent pas, JSP compilé = servlet). Or, OC4j n'aime pas ce genre de procéder. Celui-ci utilise un autre type de servlet pour faire de l'héritage lorsqu'il compile une page JSP. Bref, ça plante au run!

Mais joie, bonheur et allégresse, Oracle dans son infiniment bonté nous fournis un utilitaire pour compiler les pages JSP... Foutu merde... Cet utilitaire nommé OJSPC fonctionne en mode "command line" mais ne veux absolument rien savoir lorsqu'appelé depuis un code Java (Si vous trouvez comment, dites le moi, j'ai gosser pendant 2 semaines, j'ai même décompilé la classe pour copier le code utilisé sans aucun résultat!). Je me suis donc inspiré de la tache ant pour faire un plugin Maven 2 qui compile les pages JSP contenues dans une archive (ear ou war).

Ce plugin, je vous le rend disponible à l'adresse suivante : ojspc-maven-plugin. Vous y trouverez une documentation sommaire, les sources (si vous voulez le modifiez... J'aimerais bien que vous me faisiez parvenir vos modifs que je les intègre) et une archive que vous pouvez déziper dans votre répository Maven pour l'utilisé tel quel!

Le processus de création du plugin aurait été certainement plus rapide si mon ex-collègue Cayer avait été là! Mais là, ça devrait être rentré dans l'ordre, je devrais être de retour plus fréquent sur ce blog, je vais encore probablement m'ennuyer de Cayer dans mon dev, mais que voulez-vous, l'appat du gain a eu raison d'une franche camaraderie et d'une équipe efficace...

PS: Sent toi pas mal Cayer, je t'agasse, et par ce billet, je te rend réellement un hommage à ma façon... Je l'ai toujours dit, ça fait parti de ma job de chialer... ;)

Mort? Non, juste ben chargé...

Written by Fneuch on 26.9.06

Désolé de mon absence, je suis un peu chargé depuis que mon collègue à lever les feutres... Je gosse sur ben des petites choses qui font que j'ai le feeling que mes projets n'avance pas!

Mais, je vous pitch en rafale 3 petits articles sur JSF :



Itou, un article qui m'a fait sourire, une loi sur les droits des programmeurs qui me fait dire que si j'avais un bon salaire, ma job serait parfaite: Coding Horror: The Programmer's Bill of Rights

Et pour finir, jusqu'à ce que je vous revienne de façon plus assidu, prenez vous dix minutes pour aller voir la création du monde vu par ... un dieu informatitien! God

Struts2 sur InfoQ

Written by Fneuch on 20.9.06

InfoQ commence une série d'article sur Struts 2. À lire...

Migrating Struts Apps to Struts 2

To SOA or to plugins...

Written by Fneuch on 18.9.06

OK, j'en met un peu... Je compare pas 2 façons de faire ici là.

Je viens de tomber sur un article qui parle de JPF... Mais qu'est-ce que JPF? JPF est un acronyme pour désigner Java Plugin Framework.

C'est une idée qui me tracasse depuis longtemps, mais n'ayant pas les besoins, ni l'occasion, je ne mis était pas attardé. Et si on développait nos applications comme étant un ensemble de module qui s'attache entre eux! Rien de nouveau, c'est le concept de base du SOA (Service Oriented Architecture). La question est: pourrions nous utilisé un concept de plugins pour définir chacun des modules? Un peu comme le fait Maven mais vis-à-vis une application!

J'ai pas regardé vraiment ce qu'est Java Plugin Framework (JPF), mais ce qui semble bien c'est le concept de "registry". Ils sembleraient qu'on peut chargé ou déchargé des modules en cours d'applications...

Le concept est à étudier!

Recherche sur la recherche?

Written by Fneuch on 18.9.06

Je viens de tomber sur un article qui intègre Compass avec Spring. (CompassContext and Spring) Je me suis donc demandé ce qu'était Compass.

Une vérification sommaire m'a permis de constater que Compass est un engin de recherche construit sur Lucene. Je me demandais si quelqu'un parmis mes fameux lecteurs avait déjà utilisé ce composant? Si oui, quels sont les résultats de vos expérimentations? Dans quel contexte utilisé vous Compass?

Merci pour toutes informations fournies...

Un autre outil de log...

Written by Fneuch on 18.9.06

Un autre outil de log vient de sortir... est-ce utile? On verra!

Welcome to Log Bag

Part 2

Written by Fneuch on 18.9.06

Partie 2 de la comparaison Spring vs EJB.
Make the Right Decision with Our Side-by-Side Comparison of Spring and EJB 3.0, Part 2

Quelques news en retard...

Written by Fneuch on 15.9.06

Je suis un peu dans le jus, un de mes collègues termine aujourd'hui! L'organisation va s'en ressentir, c'est certain... (En tout cas, moi je vais m'ennuyer)

Jusqu'à son départ, on se dépèche pour terminer et faire une "release" de tout ce sur quoi il travaillait. J'ai donc un peu moins de temps pour me tenir au courant.

En attendant, voici donc en rafale quelques liens qui sont intéressant que je relirai quand j'aurai 2 minutes...

JAAS est le standard pour la sécurité dans les applications. Voici donc un article dans un environnement JEE et SOA.
Using JAAS in Java EE and SOA Environments

On en parle beaucoup dans la communauté pour les prochaines versions de Java, voici donc un autre article sur les closures.
Nominal Closures for Java (version 0.2)

2 articles un peu plus technique sur Hibernate et Spring.
Implementing an efficient Id generator with Spring framework
ONJava.com -- Don't Let Hibernate Steal Your Identity

Bon, sur ce, probablement à lundi!

Hibernate can meet your validation needs

Written by Fneuch on 14.9.06

Petit article intéressant sur les validations avec Hibernate.

Hibernate can meet your validation needs

En attendans Java SE 6

Written by Fneuch on 13.9.06

Tout le monde sait comment fonctionne les éditions java? Nous n'avons pas encore fini d'implanter la 5 que la 6 est en cours de réalisation et que la 7 est en planifications...

En attendant que la 6 soit réellement relaché, on peut tombé sur certains articles qui nous donnent une bonne idée de ce que ce sera.

Dont celui-ci, qui explique les MXBeans. Existe-t-il des différences d'avec les MBeans de Java 5? Aucnue idée! J'en fait pas assez de MBean pour le dire.

Si après avoir lù l'article, vous le savez, il serait intéressant de m'expliquer.

MXBeans in Java SE 6: Bundling Values Without Special JMX Client Configurations

Besoins de cluster?

Written by Fneuch on 13.9.06

Utilisé Terracotta sans changé une ligne de votre application, grâce à Spring...

Terracotta for Spring

Web 2.0

Written by Fneuch on 11.9.06

L'image est pourrie, l'auteur est sacadé, mais l'introduction est bonne...

Introduction to Semantic Web

AGILE /SCRUM Fails to get to grips with Human Psychology. - Clarety Consulting - IT Strategy Made Simple

Written by Fneuch on 11.9.06

Le billet que je viens de lire (AGILE /SCRUM Fails to get to grips with Human Psychology.) ainsi que les commentaires qui le suivent, me rapelle fortement les observations que j'ai pu faire au sein de notre organisation.

Pourquosse faire...

Pourquoi qu'à chaque fois en informatique, que quelqu'un tente de changer les façons de faire, les habitudes, il y en a toujours quelques un qui s'y opposent le démollissent, ne comprennent pas.

Je suis dans une organisation gouvernemental, tout est très hiérarchisé, très waterfall! Le directeur dirige, le chargé de projet à toutes les responsabilités de management, l'analyste analise et le technisien écrit le code que l'analyste lui demande...

Ça va faier bientôt 10 ans que je suis ici. Quand je suis arrivé, il n'y avait pas vraiment de méthodologie, le développement informatique s'effectuait selon les taches que j'ai décrit ci-haut. Les projets dépassaient les couts et les échéanciers, cela ne semblait pas catastrophique puisque ça continuait ainsi.

En 2004, nous avons tenté d'instaurer une méthodologie plus agile (une méthodologie développé au gouvernement). Cette méthodologie (sans nom) était un espèce de mixte entre du waterfall et de l'agile. On se disait que ça serait parfait pour changer une organisation qui croule sous le poid administratif. Il s'en est vu plusieurs pour critiquer. La méthodologie ne décrivait pas dans les moindres détails chacune des taches que chaques personnes devaient exécuter. On demandait au gens en place de réfléchir, on tentait de forcer les techniciens de sortir de leurs rôles de secrétaire de code qu'ils étaient. On demandait aux analystes d'arreté de concevoir tout dans les moindres détails en partant... On essayait de démontrer qu'il n'est pas toujours sein d'avoir placé la configuration exacte de toute les fenêtres d'écran avant d'avoir écrire une ligne de code...

On a aussi tenté de démontrer aux analystes qu'il existait des spécialisations en informatique. Que l'analyste n'était pas le maitre d'oeuvre de tout... Qu'un web designer est meilleur qu'un analyste pour la conception d'interface. Qu'un architecte organique est en meilleur position qu'eux pour définir l'architecture du système. Que le technicien devrait être en meilleur position qu'eux pour créer l'application. Les 2 premières personnes auraient probablement mieux passé que d'admettre que les techniciens étaient aussi important que les analystes...

Mais, l'humain étant ce qu'il est, l'implantation de cette méthodologie, sans dire que c'est un échec, fut un périple incroyable.

Nous pensons passé au RUP. J'ai confiance que ça peut marcher au sein de l'organisation. Le momentum est bon. On a de nouveaux directeurs qui connaissent mieux l'informatique. L'organisation reconnait que les spécialistes en informatique sont dans notre direction et non au communication. La grosse difficulté serait la direction en tant que tel!

En lisant l'article cité ici, je me rends compte que nous ne sommes pas les seules. Le monde entier ne comprends pas que la création d'une application ne fait pas partie du fabuleux monde de l'industrialisation... On ne crée pas une application comme on conçoit une bicyclette. Il n'y a pas de chaine de montage où chacun prends le morceux précédents, lui applique un traitement, et le passe au suivant et qu'en bout de ligne, 200 000 applications seront conçues d'ici la fin de l'année.

Pour avoir un succès, une application doit répondre en tout point au besoin d'un client. Je ne veux pas dire qu'il faut faire tout ce que le client demande. Je veux simplement dire, qu'au moment où on conçoit l'application, la présence du technicien peut être utile. C'est lui qui va la coder l'application. Si ce que le client demande est irréalisable d'un point de vu technique, on peut tu le savoir au début. Si l'interface que le client demande comporte des spécifications spéciales, on peut tu le savoir au début. Si l'interface que le designer pense, comporte des choses irréalisables, on peut tu en discuter en partant... Au lieu que l'analyste prenne tout en note, pense à son affaire tout seul dans son coin et se confronte par la suite au designer et au tech, on peut tu assoir tout le monde dans la même pièce, en discuter avec le client et décider ce que nous réaliserons...

Vous n'y voyez pas là les bases d'une méthodologie appelé SCRUM?

En conclusions, comme il est si bien dit dans les commentaires de l'articles, ce n'est pas Scrum ou Agile qui échoue, mais toutes les organisations qui ne sont pas en mesure de gérer le coté humain. Toutes les organisations fermés sur elle même n'utilisant qu'une seule façon de faire et se rébutants à tout changement sont définitivement voué à l'échec. Que ce soit en informatique, en industrie ou une compagnie de service, si vous ne voulez pas vous améliorer, vous mourrerez...

Pour M. Java...

Written by Fneuch on 8.9.06

Petit vidéo intéressant qui rend hommage à M. Java : James Gosling.

Tribute to James gosling

Getting Started With Spring 2.0 in Oracle JDeveloper

Written by Fneuch on 7.9.06

Spring 2.0 sort seulement le 26 septembre (date prévue pour l'instant) on trouve déjà plusieur tutoriel sur le sujet.

Selui-ci nous explique comment démarrer avec Spring 2.0 dans JDeveloper.

Getting Started With Spring 2.0 in Oracle JDeveloper

Spring, Axis et Acegi

Written by Fneuch on 7.9.06

Cet article explique comment développer un web service avec Apache Axis, Spring et Acegi.

Separation of Concerns in Web Service Implementations

Improving Code Quality with PMD and Eclipse

Written by Fneuch on 7.9.06

Petit tutorial sur l'utilisation de PMD avec Eclipse.

Improving Code Quality with PMD and Eclipse

JDev Working Sets

Written by Fneuch on 6.9.06

Pour ceux qui travaille encore avec JDeveloper :

Sharing Working Sets with your Team

Continuous Integration server

Written by Fneuch on 6.9.06

Petit article intéressant sur la comparaison entre les serveurs d'intégration continue.

Au bureau nous avons installé Continuum, pour sa simplicité et sa facilité d'intégration avec Maven.

Automation for the people: Choosing a Continuous Integration server

Contract-First Web Services with Apache Axis2

Written by Fneuch on 5.9.06

Petite introduction sur Axis2 d'apache.
Contract-First Web Services with Apache Axis2

The Pragmatic Programmers

Written by Fneuch on 5.9.06

Une liste intéressante de "tips" à lire pour tous les développeurs : The Pragmatic Programmers, LLC

JUnit 4 vs. TestNG

Written by Fneuch on 5.9.06

Grâce à Alex, (c'est lui qui a décidé que nous allions utiliser TestNG au bureau) nous commençons à nous intéresser à ce framework de test.

Une des premières choses que j'ai constaté en l'essayant (et je peux vous dire que ça saute aux yeux car je n'ai pas fait des tonnes de test) c'est la flexibilité de TestNG. Et j'ai pas découvert grands choses, car l'article suivant nous fait une comparaison entre TestNG et JUnit 4.0 et nous donne quelques comparaisons entre les 2...

In pursuit of code quality: JUnit 4 vs. TestNG

Encore la sécurité...

Written by Fneuch on 1.9.06

Ce coups-ci, c'est seulement qu'un livre parlant de sécurité vient d'être rendu disponible gratuitement en consultation sur le web.

Security Engineering - A Guide to Building Dependable Distributed Systems

Note personnelle

Written by Fneuch on 1.9.06

Kirill Grouchnikov présente une façon d'utiliser le SVG pour faire les UI d'une application Swing.

Va falloir que je tcheque le tout, question de savoir si y a pas qqe chose à faire pour le monde web. Gou, noter web-designer, nous a déjà fait quelques graphiques en SVG pour un site interne, et la grosse problématique de ce mode de fonctionnement, c'est qu'un client SVG doit être installer sur chacun des postes clients...

Je ne sais pas s'il existe une solution qui garderait le traitement du SVG du coté serveur, mais quand j'aurais deux minutes (ça peut être long avant que j'aille 2 minutes), j'y jetterai un oeil.
SVG and Java UIs part 3: using Batik for asynchronously-loading UIs

Utile...

Written by Fneuch on 1.9.06

Quel titre, c'est justement un hack pour les librairies "util.jars"...

Tout le monde à une librairie d'utilitaire, (si ce n'est pas encore fait, vous êtes en retard, je suis donc en retard) ce hack permet de changer le Main-class dans votre librairie d'utilitaire!

Cheap Hack I: rename your jar file, get a different Main-Class

Spring vs EJB 3.0

Written by Fneuch on 1.9.06

Dans le coin gauche, pesant version 1.0, le champion en titre : Spring... Dans le coin droit, pesant version 3.0, le nouveau prétendant: EJB!

Méchant combat de boxe.

Il s'agit en fait d'un premier article d'une série de 2 publier par Devx. Je vous vois déjà grimper sur vos grands chevaux par le fait qu'on compare des pommes avec des oranges. Mais l'auteur, Rod Coffin, en est très conscient. Avant de juger, lisez l'article qui est intéressant. Ce n'est pas une propagande pour l'un ou l'autre, spring ou EJB, il est objectif et donne des bons points pour le choix. Il conclut même en disant qu'il ne sont pas mutuellement exclusif, ce qui est vrai.

Donc, c'est à lire: Make the Right Decision with Our Side-by-Side Comparison of Spring and EJB 3.0

Qui suis-je ?

Je suis un "accro" de Java: que vous parliez de programmation, ou de café! Je suis architecte organique pour une compagnie de consultation à Québec.

PLAYSTATION®Network

Utiliser vous Twitter?

Twitter Updates