URL: https://linuxfr.org/users/ploum/journaux/linuxfr-en-j2ee Title: Linuxfr en J2EE Authors: ploum Date: 2009年01月07日T02:05:40+01:00 Tags: admin, templeet, ubuntu, firefox, j2ee, jython et python Score: 130 Que nous propose donc Pierre Tramo, J2EE Lead Architect, pour la refonte de Linuxfr en 2009 ? Du J2EE bien sûr ! Le cahier des charges : Refaire linuxfr pour noel 2009. La version beta doit être livrée le 1er septembre. Buget : mieux vaut ne pas y penser. Déroulement : Janvier 2009 #### Arrivée des consultants. Ben oui, tout projet J2EE digne de ce nom vient avec sa panoplie de consultant avec des cravates mal attachées et qui jouent tout le temps à cochonland, miniville et autres jeux en flash. C'est un peu une sorte de symbiose naturelle : vous ne trouverez jamais l'un sans l'autre. Un laptop est donné à chaque consultant. Les deux premières semaines sont passées à configurer le laptop. Chacun installe Eclipse sauf deux qui installent IntelliJ et réclament les licences pour pouvoir l'utiliser. Tous les consultants sont sous Windows sauf un, qui connait bien Linux. Il a installé une Ubuntu puis installé tout à la main depuis les sources. Les premières réunions sont tenues pour décider de l'architecture. Parce qu'un bon projet, c'est avant tout une bonne architecture. Il est décidé d'utiliser Jboss parce que c'est un serveur d'application libre, ce qui correspond à la philosophie du site. Un représentant de Linuxfr demande ce qu'est un serveur d'application. Un consultant lui fait un diagramme qu'il avoue ne plus comprendre lui-même à la fin. Les premiers shémas voient le jour. Prise de contact. Le projet est baptisé "Linuxfr-NG". Il suivra un modèle MVC strict. Il utilisera Spring, Struts et plein d'autres noms que seuls les javaistes semblent comprendre. Février #### Les consultants installent tous Jboss et, en conséquence, demandent un triplement de la taille de la Ram de leur portable. Deux consultants sont déjà infestés de virus et spamment tout le réseau. Un autre des consultant leur installe un antivirus piraté mais "qui est bien mieux que celui fourni (sic)". Le shéma des classes est commencé en UML. Fin février, ce shéma s'imprime déjà sur 8 feuilles A4 avec polices en taille 8 qu'il faut assembler dans la salle de réunion. Un des meneurs identifies différents mécanismes fort semblables et décide de les abstraire avec des Design Patern. Les commentaires et les journaux seront issus d'un FactoryOfUserInput. Beaucoup de discussions sur le meilleur wiki et le meilleur bugzilla à adopter. Mars ### Un problème fondamental est identifié dans ce premier design UML. Tout est refait. Un des consultants entre dans le top 10 de miniville. Beaucoup de discussions pour savoir si une classe donnée du diagramme UML appartient à M, à V ou à C. Avril ### Ce nouveau design semble beaucoup mieux que le précédent. Chaque commentaire est maintenant généré à partir d'un objet FactoryOfSingletonFactoryOfUserComment, ce qui est beaucoup plus propre d'un point de vue MVC (sic). Les consultants suivent une formation sur le développement agile et chacun assigne un rôle à un autre consultant tout en lui collant des post-its de couleur sur l'écran de chaque bug dont il doit s'occuper. Un couche d'abstraction est créée afin d'intégrer dans la View certains éléments du Controller. Mai ### Un des consultants remarque que les tests unitaires écrit en janvier ne se lancent même plus depuis des mois. Il corrige le problème et installe un plugin qui envoie un mail à chaque fois qu'un test ne tourne plus après un commit. À chaque commit, chaque consultant reçoit 150 mails. Le chef de projet estime que le bouton "poster un commentaire" fait partie de la View, pas du controller. On décide faire des classes abstraites avec héritage multiple pour satisfaire tout le monde. Juin (2009 toujours) ### Réunion avec les clients. La deadline va être difficile à tenir. Si un dépassement de budget est envisageable, on suggère d'embaucher de la main d'oeuvre supplémentaire. Le nombre de consultants est doublé (et tant pis pour la dépense). Les nouveaux arriveront début juillet. Le fichier UML fait à présent 16 pages A4. Le code source (pour la plupart généré) atteind 300Mo. Certains fichiers XML de description des propriétés atteignent les 20.000 lignes. Le but de ces fichiers est d'être facilement modifiable par un non-programmeur, le XML étant plus facile que le java. Juillet ### Les nouveaux arrivent. Dans le tas se trouve 2 tchèques qui parlent anglais pas trop mal mais sont électroniciens de formation, il n'ont jamais fait de java, 2 italiens qui ne parlent qu'italien. Le mois de juillet est passé à leur installer l'environnement de développement. On découvre que la procédure d'installation (17 pages sur le wiki, et des longues) n'est plus du tout à jour. Suite à l'utilisation de librairies spéciales, le projet ne tourne plus que sous Windows. Le consultant qui était sous Linux réinstalle WinXP. Aout ### La moitié de l'ancienne équipe travaille à "lancer" les nouveaux dans le projet. Cela commence par leur expliquer ce qu'est Eclipse et comment créer un projet. Les italiens ne pigent rien mais prennent note sur des cahiers. La compilation du projet avec Maven prent 34 minutes en moyenne mais sur une installation fraîche sans aucun cache, cela peut monter à 2h. L'output de la console tourne dans les 30.000 lignes à chaque fois. Un des tchèques demandent si les tests unitaires vont dans M, dans V ou dans C. Trois réunions s'en suivent parce que certains jugent la question pertinente. Septembre ### Implémentation de l'objet AbstractFactoryOfFactoryOfSingletonFactoryOfUserComment. On assigne à un des tchèques la tâche d'écrire les tests unitaires pour tout ce qui a été écrit entre mai et septembre. La beta est reportée au 1er octobre avec démonstration devant les managers. Le code source fait à présent un total de 800Mo. Le consultant qui utilise Linux ajoute, dans le prototype, un interpréteur Python utilisant Jython car "ça peut toujours servir". Le wiki comporte 179 pages et la page de garde ainsi que ses descendants directs n'ont plus été modifiés depuis juillet. À chaque modif, le projet doit être entièrement recompilé pour pouvoir tester. Le serveur doit être également relancé. Octobre ### Démonstration du prototype. Le chef de projet ouvre 5 consoles et tape, dans chacune, une commande qui fait facilement 3 lignes de la console en question. Il appuie sur enter, le PC crie et chauffe. Après quelques minutes de défilement ininterrompus dans les consoles, une interface ressemblant à éclipse apparait. Le tout utilisant la skin Swing. c'est moche à souhait mais le chef de projet, tout fier, explique qu'ils ont utilisé le toolkit eclipse qui permet, par exemple, d'ajouter des "satellites". Au milieu de cette interface, une fenêtre affiche une vue de ce qui ressemble à une liste, genre ce que phpmyadmin affiche quand on explore une table mysql. Le chef de projet explique que ceci est l'interface d'administration de l'administration du serveur de commentaires. Personne ne comprend. Il passe ensuite sur une fenêtre Firefox qui met 15 secondes à s'afficher ("désolé, ce PC n'a que 2 Go de Ram mais sur un cluster de serveur, y'a pas de problème hein"). Dans son Firefox apparaît un page blanche avec quelques liens incompréhensibles et un logo Jboss dans le haut de la page. "Bon, bien sûr, c'est pas l'interface définitive hein ! Ici j'utilise l'interface Jboss et EJB." Il scrolle. Dans le bas apparait un champ avec un boutton "poster le commentaire". Le chef de projet tape un petit texte et appuie sur le bouton. Le texte s'affiche alors en haut du champ, en noir. "Et voilà, commentaire posté !" Il se retourne avec un grand sourire. Voyant le visage des clients, il ajoute : "bien entendu, ce n'est qu'un exemple ! Notre architecture permet une grande souplesse. Imaginez que je souhaite définir un journal, il me suffirait de modifier ça et ça (il ouvre eclipse puis étale sur la table 32 pages attachées sur lesquelles est affiché l'architecture UML). Les managers sont un peu perplexe. Novembre ### La pression de la démo étant passée, le projet n'avance plus trop. Beaucoup de vacances avec la toussaint. Le code des tests unitaires est refactorisé. Trois consultants travaillent sur un framework permettant de gérer plus facilement les tests unitaires du projet (dont près de la moitié passent). Décembre ### Le projet a du retard et ne pourra pas être mis en production en janvier 2010. Il est décidé de reprendre la maitenance de la version Templeet et de réduire l'équipe qui travaille sur Linuxfr-NG. Le chef de projet livre une documentation de 240 pages sur l'état actuel du framework, sur l'étude de faisabilité, sur les forces et faiblesses du projet. Le tout compile un rapport que chaque consultant a du faire. Il y est estimé que le site sera fonctionnel en juin 2010 mais qu'il est important de ne pas s'éparpiller. Juin 2010 ### Seul 5 consultants sont encore présents pour travailler sur le projet. Ils font principalement la documentation des bugs qu'ils trouvent et qui empêche le projet de se lancer depuis la mise à jour de Windows en SP3. Novembre 2010 ### Le projet est abandonné mais comme les consultants sont partis petit à petit, personne ne s'en rend vraiment compte. Deux consultants sont d'ailleurs encore là et aide l'équioe templeet depuis 2 mois. On leur donne des trucs à faire par ci par là. Decembre 2010 ### Personne ne se souvient plus réellement de cette idée. Officiellement, le projet a été fusionné avec la maintenance de la version existante. Le serveur SVN et son 1,6Go de code source crashe, personne ne le restaure.

AltStyle によって変換されたページ (->オリジナル) /