Book Mark

Merci à Cristian :-)

Démarrer tftpd

J'avais parlé d'une net install de Debian sur Mac PowerPC : Mac mini de NetBSD à Debian

Eh bien il se trouve qu'il est parfois difficile de démarrer from scratch un tftpd pour que le Mac l'attaque. Alors voici une façon de faire, sur une Ubuntu 9.04 (eh oui : la 9.10 est d'une discutable stabilité).

$ sudo aptitude install tftpd

inetd ne veut pas démarrer au cours de l'install ? Pas grave, l'idée n'était justement de le rendre résiduel.

Modifier /etc/inetd.conf tout de même, en rajoutant l'option « -s » à : /usr/sbin/in.tftpd -s /srv/tftp

Mettre les fichiers à servir dans /srv/tftp/ : yaboot, etc.

Démarrer inetd :

$ sudo inetd

La persistance applicative comme un aspect

Dans le développement d'une application on pense souvent très tôt à la solution de persistance. Certains ont même une idée tellement précise du « modèle physique des données » — terminologie qui est une drôle de façon se se rassurer —, qu'ils vont à terme jusqu'à contraindre le comportement de l'application ou du système pour se conformer au schéma de la base. Ainsi du genre de réponses « on ne peut pas faire ce que vous demandez, à cause des clefs étrangères qui sont déclarées dans la base ». Ah… Et pourquoi ne pas faire des batchs d'audit et de rattrapage ? Et pourquoi ne pas gérer des états de mes données ? Et pourquoi ne pas laisser les transitions se faire de façon asynchrone ? Et surtout : si vous vous appuyez sur des clefs étrangères pour assurer l'intégrité métier de mes données, vous me faites plutôt penser que vous n'avez pas compris mon métier !
Quel métier se résume à des contraintes techniques d'intégrité ? (contraintes que du reste les DBAs font la plupart du temps sauter en production afin d'améliorer les perfs).

Cependant je ne veux pas reparler ici de centrer les objectifs du cycle de développement sur les processus métier, je considère que c'est acté.

Non, je voudrais parler de persistance.

Il y a des cas où les processus métier sont suffisamment simples pour être embarqués dans une application transactionnelle, où il n'y a pas ou quasiment pas d'existant, bref, où on a la latitude pour développer. Pléthore de frameworks de persistance viennent en sus à notre rescousse, on peut citer Hibernate (https://www.hibernate.org/) dans les premiers.

Pourtant nombre d'entre nous continuent de vouloir poser le schéma de la base, quand bien même serait-il un mapping naïf des propriétés des objets Java, dès le commencement.

Pourquoi ne pas simplement développer l'application ? On met toutes les données en mémoire, et on optimisera ensuite ! J'ai juste besoin dans un coin d'un compteur transactionnel pour mes états métier (ben, oui), compteur que je peux implémenter par un synchronized tout bête, et je fais mouliner le reste avec des classes ad hoc.

Plus tard, quand j'aurai besoin de partager mes données sur un cluster, ou de performances, ou tout simplement de sauvegardes parce que j'aurai à mettre en place un PRA (Plan de reprise d'activité, en gros comment remettre d'aplomb un deuxième système informatique si le premier vient de calancher, par exemple suite à un incendie), alors là, oui, je me pencherai sur la persistance. Mais c'est un aspect de l'application, au même titre que la sécurité ou les logs. Ce n'en est pas le cœur ni le socle ; ce n'est pas fondamental : l'absence de persistance des données, dans le sens général, n'empêche pas l'application de tourner.

D'ailleurs combien, parmi ceux qui pensent de suite à la solution de persistance, le font réellement parce qu'ils envisagent un PRA ou des performances maximales ? Non, le plus souvent la couche de persistance est envisagée comme une nécessaire façon de réaliser une application. Dans d'autres domaines on sait s'affranchir de ce genre de préjugés : les compilateurs dégagent, avec Ruby ou Groovy et l'aide des IDEs, les descriptions XML sont supplantées par des conventions ou des annotations, le besoin de hardware diminue grâce au cloud, on se fiche de l'OS parce qu'on fait du web, etc.

La couche technique de persistance n'est pas nécessaire dans une application. En revanche la couche logique de manipulation simple des données, notamment avec des verrous voire des états, et des vérifications d'intégrité, oui.
Et il y aura toujours moyen plus tard d'orchestrer tout ça et d'y ajouter les aspects désirés.

Pour finir, l'approche que je décris vise à éjecter la problématique de la persistance lorsqu'on se centre sur du développement applicatif. Pour d'autres types de réalisations, par exemple techniques, la question de la persistance se rencontre évidemment dès le début du chemin.

svn://svn+ssh

Ceci sera un post légèrement cryptique pour les non informaticiens.

C'est juste pour me rappeler… comment accéder à Subversion par SSH avec clefs…

Sur le serveur : SSH. Permettre l'authentification par clefs.

Dans /etc/ssh/sshd_config :

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

Dans les ~/.ssh/ des intéressés, fichier authorized_keys avec une ligne par clef publique acceptée, du genre :

ssh-rsa AAAAB3Nz(…)PMRJl8=

ssh-rsa AAAAB3Nz(…)PM60l8==

ssh-rsa AAAAB35u(…)rT62zA== dandriana@ordinateur

Pour produire des clefs publiques, ssh-keygen sous Unix et Puttygen sous Windows. Si Puttygen, une fois la clef publique créée, l'exporter au format OpenSSH pour pouvoir l'utiliser sur un serveur Unix.

C'est lors de la génération des clefs qu'est demandée la « passphrase », mot de passe qui active la clef privée.

Sur le serveur : Subversion. Vu qu'on va faire du svn+ssh, pas besoin de lancer svnserve, donc.

Sur le client : SSH.

Sous Unix, clefs privées et publiques à mettre dans ~/.ssh. En général leurs noms respectifs sont « id_rsa » (-rw-------) et « id_rsa.pub » (-rw-r--r--). Connexion en : ssh -l <username> -i </path/to/private/key>

Sous Windows, clefs à mettre chais pas où, tellement c'est sécurisé. Faire pointer Putty dessus.

Rappel : les clefs publiques « xxx.pub » sont destinées à être fournies publiquement : envois par e-mail, publication dans un blog…

En revanche les clefs privées sont à protéger absolument. Elles sont plus précieuses que le mot de passe (« passphrase ») qui les active.

Sur le client : agent SSH. Pour éviter d'avoir à s'authentificer à chaque fois.

Sous Unix, ssh-agent :

exec ssh-agent bash

ssh-add </path/to/private/key>

Sous Windows, Pageant.

ssh-agent et Pageant peuvent être lancés au démarrage pour gagner du temps. Cela dépend de l'usage qu'on en a.

Sur le client : Subversion+SSH.

Sous Unix, déclarer dans son .profile une variable d'environnement SVN_SSH, du genre :

export SVN_SSH="ssh -l <username> -i </path/to/private/key>"

Si ça ne fonctionne pas, voir ~/.subversion/config.

Sous Windows, après une installation de la version de CollabNet de Subversion, j'ai mis ceci dans C:\Documents and Settings\<user>\Application Data\Subversion\config :

[tunnels]
ssh=<C:\path\to\>PLINK.EXE -l <username> -i <C:\path\to\private\key>

Mac mini de NetBSD à Debian

Après qu'il a déjà fourni trois ans de bons et loyaux services sous NetBSD, dont dix-huit mois à faire silencieusement des backups enfermé dans un carton à la cave, je me suis mis dans l’idée de passer un Mac mini PPC sous Debian.

C’était l’occasion de sortir, de son carton également, un écran cathodique dix ans d’âge, et de dépoussiérer un peu les étagères.

Une fois l’écran et un clavier Dell de base connectés au Mac, enfoncer les touches Windows-Alt-O-F au démarrage pour accéder à Open Firmware.

Pour lancer depuis Open Firmware un netboot d’installation de Debian 5.0.3 (dit « Lenny ») :

ok
0 > boot enet:192.168.0.12,yaboot

Cette ligne nécessite que sur le réseau local :

• les adresses IP soient attribuées par un serveur DHCP,
• la machine 192.168.0.12 fasse tourner un serveur TFTP,
• et serve par TFTP les fichiers d’installation de Debian, dont yaboot, yaboot.conf, vmlinux, etc.

L’installation ensuite se passe sans heurts majeurs, et va chercher sur internet tout ce qu’il convient.

Une fois l’installation terminée, après la configuration de SSH en clefs publiques, puis la mise au jour des postes clients « bureau », « salon » et « salle de jeux » en vérifiant qu’ils savent se connecter au nouveau système, le Mac mini, flanqué d’une nouvelle étiquette, a rejoint son grand carton.

Silencieusement, bientôt oublié dans le carton du fond avec sa pomme sur le couvercle, un vaillant petit serveur mouline.

Comment le Parlement européen avait voté contre Hadopi

Sur le bon blog « Coulisses de Bruxelles » un article qui narre le vote majoritaire (c'est important) du paquet télécom au Parlement européen, avec la fameuse obligation d'une décision judiciaire pour couper un accès internet : Surprise partis à Strasbourg.

Rappelons que le Parlement européen est élu au suffrage universel direct. C'est ce qui vient de se passer ce dimanche 7 juin 2009. Le suffrage universel direct est une disposition démocratique extrêmement importante, qui semble aller de soi, notamment en France, mais qui n'est pas naturelle. En pratique il faut d'abord la gagner (rappelez-vous 1789), la valider, vérifier son application, et l'alimenter au fil des ans et des générations (non, l'abstention n'est pas une façon d'entretenir le suffrage universel).

En revanche la Commission européenne n'est pas élue directement : elle représente peu ou prou les États (disons les gouvernements) en tant que nations, pas en tant que peuples. Or c'est elle qui propose 80 % des textes qui seront ensuite votés, pas le Parlement européen. S'il y a dissensions entre le désir citoyen et les « décisions de Bruxelles » c'est justement en grande partie parce que les textes proposés ne réflètent pas les simples problématiques des peuples.

Vouloir que l'entité européenne (aujourd'hui la Commission) qui propose les textes aux votes soit plus proche de l'expression populaire, c'est une certaine façon de vouloir l'Europe, absolument pas partagée par tous les membres de l'Union. En pratique cela consisterait à modifier les institutions, ce qui ne se fait pas pendant les élections européennes (dont les effets se limitent au Parlement), mais par des traités, généralement soumis à référendums populaires. Cela peut également se faire par une révolution populaire européenne ou un putsch de niveau Empire.

On fait mine de croire que tout est géré « en haut lieu », mais il faut au contraire être bien conscient qu'il y a actuellement un combat très tendu entre ce que pourrait être une Europe des citoyens et une éventuelle Europe des gouvernements.

Pour ce sujet, dans quel sens le défunt TCE et le Traité de Lisbonne vont-ils ? Eh bien vers un accroissement de pouvoir du Parlement européen. Ce nécessaire accroissement est-il suffisant ? Sans doute pas.

La face cachée d'Hadopi

Sur Agora Vox, un article intitulé La face cachée du projet de loi Internet & Création, dite « HADOPI », avec lequel je suis assez d'accord.

L'article parle bien du problème de la preuve : en gros ce qui fera techniquement preuve dans un premier temps sera l'adresse IP interceptée et qui aura permis de remonter jusqu'à la connexion à internet de l'abonné. Je détaillerais :

• Ces adresses peuvent être « forgées » : selon le niveau de protocole qui sera utilisé pour le filtrage, il est possible d'usurper l'adresse IP de quelqu'un d'autre.
  
• Ces adresses publiques ne concernent pas les sous-réseaux : dans le cas d'un accès partagé à internet (réseau domestique, Wi-Fi...), impossible de décider quel ordinateur est impliqué. C'est pour cela qu'un logiciel client est indispensable pour avoir des preuves tangibles. Sans logiciel client, la preuve est potentiellement fausse, d'où l'absurdité de la loi, or une loi absurde est dangereuse. Avec un logiciel client (et certainement pas open source, ce n'est pas l'esprit), adieu votre vie privée.
  
• Ces adresses concernent un accès à internet, mais pas une personne : en cas d'ordinateur partagé par une famille ou un groupe, impossible de savoir qui a fait quoi. Donc d'une part on peut vous pirater, d'autre part ça peut venir de chez vous. La loi va dans le sens de vous accuser a priori.

Problématique de la preuve, donc, et volonté de pouvoir accuser n'importe qui. C'est extrêmement grave.

Le deuxième énorme problème à mon sens est celui de la surveillance, dont parle également l'article d'Agora Vox.

Je pense que la question de la preuve, donc ici de l'arbitraire, voire du délirant (quand l'arbitraire est, en plus, « de bonne foi » !), est un cas d'école des coups de boutoirs que subit régulièrement la République. Dans le but de conforter une structure économique qui na pas su s'adapter (ici le modèle de distribution des œuvres numériques), on souhaite remodeler le consommateur lui-même (un peu comme Monsanto qui remodèle les graines pour imposer son modèle d'agriculture), quitte à ce qu'il y ait des effets nocifs sur l'individu en tant que citoyen, et quitte à se torcher avec les fondamentaux du droit.

Pour moi ce n'est pas une tension entre le fric et la République, tension qu'il s'agirait de régler par une voie médiane, mais très fondamentalement un combat entre des comportements débridés, qui se conçoivent eux-mêmes comme sans limites ou alors éventuellement extérieures — ainsi le droit est considéré comme une circonstance —, et une volonté positive, dont le droit est logiquement une conséquence.

Notes scolaires et Facebook

Je cite un article du Post :

Accro à Facebook ? Attention à vos notes !

Selon une enquête très sérieuse, faite par des chercheurs, les étudiants qui passent beaucoup de temps sur Facebook, à accumuler des amis, papoter ou poker les gens « consacrent moins d'une heure à leurs devoirs ».

Pour le Times, qui révèle cette enquête, elle confirme les craintes des parents et des profs, et va dans le même sens que ces entreprises qui empêchent l'accès à Facebook dans leurs locaux, pour éviter le gaspillage de temps par les employés...

« Chaque génération a ses distractions, mais je pense que Facebook est un phénomène unique » explique Aryn Karpinski, de la Ohio State University.

Je pense surtout qu'il manque un espace web ludique pour faire ses devoirs. Et qu'avec un tel type d'espace, les « notes » remonteraient. D'autant qu'il n'y a pas que les notes dans la vie, certes qu'elles soient bonnes est un préalable. Il s'agit au moins d'en donner les conditions aux enfants.

Quand je dis un espace web pour faire ses devoirs, ce n'est même pas que le prof ait à mettre sur le web ses énoncés, mais seulement que l'élève puisse y rédiger ses réponses et y travailler en groupe avec d'autres.

Petits robots mignons

Beaucoup de buzz sur cette expérience, qui à la lecture est sympa comme tout : Tweenbots: Cute Beats Smart

Le but, fabriquer un robot qui arrive à aller d'un bout à l'autre de Central Park.

Un gars a eu l'idée de construire un petit robot, qui ne sache aller que tout droit, mais arborant un petit papier « je veux aller [à tel endroit] » plus un grand sourire dessiné sur le carton.

Et donc les passants dans Central Park ont aidé le petit robot à trouver son chemin.

:-)

Hadopi la sorcière, votée

Ben voilà, l'infâme loi Hadopi vient d'être votée. J'ai réagi en premier lieu sur Twitter :

• Hadopi : loi, par importance 1. suicidaire pour notre droit, 2. rongeuse de libertés, 3. économiquement idiote, et 4. techniquement absurde.

• Hadopi loi tueuse de droit. Or seulement 60 députés au vote. Et personne dans les rues. Lendemains qui déchantent à prévoir pour le citoyen.
  

Je pense qu'on est dans un cas flagrant de délitement de ce qui constitue un État de droit. Ce n'est certes pas le seul de l'actuelle période.

Je suis assez d'accord avec l'article sur Numerama : La loi Hadopi votée à la sauvette par 16 députés ! et surtout solidaire de la phrase suivante que j'en extrais : 

(...) en tant que citoyens, cette violation des principes qui fondent la République nous révulse.

Il est anormal que les artistes français soient à ce point à la ramasse quant à leur propre avenir face aux échanges économiques que permettent les réseaux informatiques. Certes. Mais le coup d'instrumentaliser lesdits artistes, et de s'appuyer sur une si grande ignorance du peuple, pour faire passer en douce des lois contraires aux principes d'égalité des citoyens entre eux et à la liberté individuelle, c'est odieux.

Hadopi la sorcière

Des cerveaux suprêmes ont imaginé que le déboussolement des industriels de la culture par artefacts (notamment livres, musique et films) vis-à-vis d'internet (notamment web et P2P), pourraient servir à faire passer une loi de surveillance généralisée de l'usage d'internet  en France, et sans contrepartie en droit,  par le truchement de la mise en place du processus suivant :

1. soit un internaute qui télécharge illégalement une œuvre numérisée,
2. téléchargement dont l'illégalité est détectée par un système automatisé,
3. cet internaute reçoit un e-mail lui signifiant que telle Haute Autorité sait qu'il télécharge illégalement quelque chose, sans lui dire exactement quoi,
4. puis en tant qu'usager il reçoit un courrier recommandé avec accusé de réception, toujours sans qu'on lui précise exactement ce qu'on lui reproche,
5. puis toujours en tant qu'usager sa connexion se voit interrompue.

Je passe sur les suites judiciaires telles qu'amendes et procès.

Je passe sur l'aspect délibérément kafkaïen du scénario.

Le Parlement Européen de se déclarer pour une reconnaissance d'un droit inaliénable à la connexion à internet, les associations faisant remarquer que couper une connexion à internet dans le cas d'un accès partagé, tel qu'au sein d'une famille, pénalise tous les usagers sans distinction, les entreprises n'étant pas concernées, bref.

Les acteurs du web de signaler que l'interconnexion des réseaux et les comportements sociaux qui existent d'ores et déjà au-dessus d'internet impliquent nécessairement une évolution du modèle économique que suivent les industriels de la culture de masse, et qu'un repli irrationnel du genre loi Hadopi ne fera en tout état de cause que s'opposer vainement au sens de l'Histoire plutôt que l'accompagner, c'est-à-dire obligera tout le monde à subir les changements plutôt qu'en être les acteurs, bref.

Les techniciens qui connaissent leur sujet d'estimer que pour mettre en place un filtrage un tant soit peu consistant les moyens à mettre en œuvre, en plus de la coordination entre les services publics et les opérateurs privés, dépassent de beaucoup tout ce qui serait suffisant à radicalement moderniser les usages des NTIC par l'État, dossier dont on sait par ailleurs, et peut-être par une symétrie d'ignorance ? que les parlementaires refusent de le prendre en main par peur de l'effort à produire, bref.

Ce qui intimement me choque depuis le début se condense en deux points, qui ne sont pas relevés dans ce qui précède :

• un projet législatif qui consiste à surveiller et à demander des comptes aux citoyens de leur surveillance sans leur donner les éléments auxquels ils pourraient s'opposer. Au lieu de dire : « nous avons relevé que le 12 juin 2009 à 21 h 53 la connexion internet n°XYZ chez le fournisseur XYZ, dont vous êtes l'abonné, a été utilisée pour le téléchargement du film "Taxi 4" par le logiciel Peer-to-peer eMule en passant par les cartes réseau d'adresses MAC n°XYZ, ce qui sauf au cas où vous détiendrez par ailleurs le droit de ce téléchargement (copie privée) vous expose, etc. etc. », le projet de loi prévoit de pouvoir dire : « une activité illégale a été détectée sur votre ordinateur, veuillez désormais obtempérer aux ordres de telle Haute Autorité ».

• une surveillance et une analyse exhaustives des communications qui passent par le réseau internet, toujours sans à rendre de comptes aux usagers.

Le premier point contrevient frontalement à l'idée que je me fais du droit. Je sais que l'Habeas corpus a été un progrès dans l'Histoire, eh bien visiblement il faut continuellement expliquer les progrès passés et réaffirmer les acquis dont nous jouissons au quotidien.

De plus les NTIC permettraient à moindre coût une transparence d'information des citoyens, qu'il s'agisse de l'action de l'administration ou à plus forte raison de ce que la société serait en droit de leur reprocher. Envoyer un courrier à un quidam coûte au moins un timbre, mais mettre en ligne tous ses logs de connexion qui ont fait l'objet de telle surveillance automatisée, coûte bien moins, et garantirait une symétrie entre l'accusé et l'accusateur, symétrie qui devrait au-delà de l'épiphénomène Hadopi être revendiquée comme sacro-sainte, mesurée par des moyens objectifs et dont la mesure devrait être publiée.

Je trouve que le fait que la magouille évoquée concerne un projet de loi du domaine des NTIC est parfaitement secondaire. J'ai ainsi toujours été choqué que sous prétexte de radars automatiques on fasse payer des amendes sans en pratique fournir systématiquement la preuve du délit.

Le deuxième point, de surveillance absolue, concerne une question de projet de société. Voulons-nous ou non que nos agissements soient l'objet de surveillance systématique ? C'est en quelque sorte un retournement de la question démocratique, mais dans les deux cas la symétrie est une nécessité pratique : on ne peut pas imaginer une démocratie dans laquelle les citoyens n'auraient pas un accès égalitaire à l'éducation et à l'information d'une part libre et d'autre part publique, et on ne peut pas construire une société de la surveillance si, en gros, ce qui est relevé et désormais décortiqué n'est pas librement accessible en tant que données brutes à ceux qui sont surveillés.

Certes, la surveillance totale et la symétrie qui lui est un nécessaire corollaire dans un bête cadre de stabilité sociale, impliquent de refonder l'idée qu'on se fait de l'intimité et de la vie privée. Il faut simplement savoir ce qu'on veut.

Pour conclure et résumer je dirais que le projet de loi Hadopi ressort d'un monstrueux et pervers processus de démantèlement du droit et par conséquent d'aliénation de nos libertés. Que je suis effaré que le débat populaire sur Hadopi se concentre sur les aspects dits de progrès, qu'ils soient technologiques ou relevant de nouveaux modèles économiques, alors que les principes mêmes qui permettent qu'on s'accorde librement à se soumettre au droit y sont violemment souffletés.

C'est comme s'il y avait la volonté d'un divorce entre le droit subi et celui auquel on adhère. Petit à petit cela représente une catastrophe sociale.

Kissing the mirror

Je traduis :

Telle école privée aux USA a dû interdire à ses gamines d'élèves de laisser des bisous sur les miroirs de leur salle de bains.

Chaque matin, plusieurs jeunes élèves autour de douze ans, se peinturluraient les lèvres de rouge dans la salle de bains. Rien à dire à cela, sauf qu'ensuite elles imprimaient un bécot au miroir, y laissant ainsi des dizaines de petites traces écarlates, que chaque fin de journée l'employé chargé du nettoyage devait nettoyer, et chaque matin le coupable manège recommençait.

Finalement le principal décida qu'il fallait faire quelque chose. Il convoqua les filles dans la salle de bains, ainsi que l'employé qui effaçait chaque jour les rouges forfaits. Le principal expliqua que ces petites traces représentaient un problème majeur pour l'employé qui devait les nettoyer.

Afin d'expliquer la difficulté, il demanda à l'employé de montrer aux filles la somme de travail que cela représentait. L'homme sortit alors une longue raclette, la plongea dans la cuvette des toilettes, et nettoya un miroir avec. Depuis, il n'y a plus de ces petites traces rouges dans la salle de bains.

Kissing the mirror

J'aime beaucoup la structure narrative :-)

Développement : Dependency Analyzer

Oui, pardon, il y a un outil bien connu qui permet de voir des dépendances d'un projet Maven : Dependency Analyzer, de jfrog, ceux qui font Artifactory.

C'est bien et utile, mais ce n'était pas mon besoin. Mon besoin était un besoin de m'y retrouver dans mon développement, pas de nettoyer ma configuration.

Dependency Analyzer :

• me montre les dépendances extraites récursivement à partir d'un projet source donné,
• donne toutes les bibliothèques, donc en particulier pléthore de bibliothèques tierces,
• traite correctement les versions,
• s'appuie sur les POMs installés du local repository.

Mon outil :

• me montre les dépendances dans un espace de travail vu comme un ensemble,
• est centré sur les projets dont j'ai les sources de l'espace de travail plutôt que les bibliothèques tierces ou les projets déjà construits,
• fait n'importe quoi avec les versions (bug secondaire vu mon besoin),
• s'appuie sur les POMs en cours de développement de l'espace de travail.

Les deux types d'outils se complètent.

Développement : visualisation de dépendances Maven

Voici une micro-documentation sur l'outil dont je parlais dans mes précédents billets, qui produit un diagramme UML à partir d'une analyse des dépendances entre des projets Maven.

Pour télécharger l'outil

En utilisant Maven, avec l'adresse de mon repository :

http://ref.avcompris.com/nexus/content/repositories/public-releases/

Ou en prenant directement le JAR : JAR with dependencies.

Pour utiliser l'outil depuis Ant

Pour ne pas trop se prendre la tête, mettre le JAR téléchargé avec les autres bibliothèques de Ant : répertoire $ANT_HOME/lib/. Sinon, il faut renseigner <classpath> dans les <taskdef> ci-dessous.

Le principe ensuite consiste à enchaîner deux tâches :

1. concaténation de tous les POMs dans un seul fichier XML (xmlconcatscan)
2. analyse de ce fichier et génération d'un diagramme UML (poms2uml)

Voici un exemple :

<project name="umlgen" default="umlgen">

<taskdef name="xmlconcatscan"

classname="com.avcompris.tools.ant.XMLConcatScanTask">

<!-- <classpath> ... </classpath> -->

</taskdef>

<taskdef name="poms2uml"

classname="com.avcompris.all.uml.ant.Poms2UmlTask">

<!-- <classpath> ... </classpath> -->

</taskdef>

<target name="umgen">

<mkdir dir="target" />

<xmlconcatscan destFile="temp.xml">

<fileset dir="/home/blabla/workspace"> <!-- workspace location -->

<include name="*/pom.xml" />

</fileset>

</xmlconcatscan>

<poms2uml srcFile="temp.xml"

destFile="all-poms.uml" />

</target>

</project>

Ce projet Ant scanne le répertoire « /home/blabla/workspace », puis produit un diagramme UML dans le fichier « all-poms.uml ». Ce fichier peut ensuite être ouvert et manipulé avec l'outil StarUML.

Diagramme après nettoyage dans StarUML

Cet exemple est fourni, plus complet, dans le projet Maven avc-commons-all-umldep.

Pour poser une question au support ;-)

Écrire un commentaire dans cet article de blog http://snurl.com/azp1d

Ou par e-mail : david.andriana@free.fr

Pour récupérer les sources en local

Note : les sources sont en UTF-8.

Elles se récupèrent en lecture sur http://svn.avcompris.com/

Faire un checkout, projet par projet :

svn co http://svn.avcompris.com/avc-commons-all-noci/trunk avc-commons-all-noci

svn co http://svn.avcompris.com/avc-commons-all-umldep/trunk avc-commons-all-umldep

svn co http://svn.avcompris.com/avc-commons-databeans/trunk avc-commons-databeans

svn co http://svn.avcompris.com/avc-commons-lang/trunk avc-commons-lang

svn co http://svn.avcompris.com/avc-commons-parent/trunk avc-commons-parent

svn co http://svn.avcompris.com/avc-commons-testutil/trunk avc-commons-testutil

svn co http://svn.avcompris.com/avc-plugin-common/trunk avc-plugin-common

svn co http://svn.avcompris.com/avc-plugin-parent/trunk avc-plugin-parent

svn co http://svn.avcompris.com/avc-tools-ant/trunk avc-tools-ant

svn co http://svn.avcompris.com/avc-tools-common/trunk avc-tools-common

svn co http://svn.avcompris.com/avc-tools-databeans-plugin/trunk avc-tools-databeans-plugin

svn co http://svn.avcompris.com/avc-tools-databeans-plugin-ut/trunk avc-tools-databeans-plugin-ut

(12 projets au total)

Ou alors une astuce sous Unix :

1. créer des répertoires vides « avc-commons-all-noci », « avc-commons-all-umldep », etc. puis taper la commande suivante :
2. for i in `ls`; do svn co http://svn.avcompris.com/$i/trunk $i; done

Pour construire tous les projets avec Maven en ligne de commande, se placer dans le répertoire « avc-commons-all-noci », et taper la commande : mvn install

Pour installer les sources dans son IDE

Pour Eclipse, une fois que tous les projets Maven ont été récupérés en local, se placer dans « avc-commons-all-noci », et taper la commande : mvn eclipse:eclipse

Cela crée les fichiers .project et .classpath attendus par Eclipse.

On peut ensuite importer les projets dans Eclipse.

Pour IDEA : File, Open Project..., et ouvrir avc-commons-all-noci/pom.xml.

Pour lancer l'outil depuis Eclipse

La classe de tests JUnit WorkspaceInsiemeUmlTest dans le projet avc-commons-all-umldep fait justement un test de scan, concaténation et génération d'UML. Il suffit donc de lancer le test JUnit, que ce soit depuis son IDE ou en ligne de commande. Exemple : mvn test

Une fois le test lancé on peut récupérer le fichier « all-poms.uml » dans le répertoire « target », et c'est le même que ci-dessus.

Développement : packaging de l'outil de visualisation de dépendances Maven

Voici que quelqu'un qui lit mon blog me demande l'outil qui produit un diagramme UML correspondant aux dépendances entre mes projets Maven... Voir mon post ici : Visualiser les dépendances entre projets Maven.

OK, certes c'est à sa propre demande et à ses risques et périls, et il est par ailleurs simple d'envoyer le JAR par e-mail à cette personne.

Mais alors quid de :

1. la capitalisation ? C'est-à-dire, cette démarche d'envoyer le JAR, comment la répéter à moindre coût si on me refait plus tard la demande ?
2. la documentation ? Je n'ai pas tellement envie de passer du temps là-dessus.
3. le support ?
4. ... la capitalisation du support : il y aura des bugs, des questions, auxquelles je répondrai volontiers, mais comment capitaliser là-dessus ?
5. ... l'accès aux entrailles de l'outil : le mieux serait de donner accès aux sources.
6. la licence sur l'outil et son utilisation ? - voire sur ses sources.

Donc, cher fred que je ne connais pas ;-) je propose que nous fassions simple :

• pour le JAR, je le rends publiquement disponible sur mon serveur Nexus. Le téléchargement se fait donc par en utilisant comme repository Maven : http://ref.avcompris.com/nexus/content/repositories/public-releases/ Ou directement pour le JAR en question : JAR with dependencies.
• pour les sources sous Subversion, je les mets ici, accessibles en lecture seule par HTTP sans authentification : http://svn.avcompris.com/
• pour la documentation, eh bien je vais faire un article dans ce blog pour expliquer succinctement comment faire fonctionner l'outil. Prochainement. Le reste proviendra des réponses aux questions.
• pour le support, donc, envoyer questions/réponses dans le blog ou par e-mail.
• pour la licence :
• ... utilisation et modification qui imposent de respecter et de mentionner le nom de l'auteur David Andrianavalontsalama, ou encore David Andriana an nom d'usage
• ... application de la licence open source BSD, dont une version en anglais est ici : The BSD License
• ... utilisation et modification libres sans restriction à part celles qui précèdent.
• logiciel et sources mis à disposition sans aucune garantie de quoi que ce soit et attention ce logiciel peut partir en vrille et vous êtes responsable de ce qui arrive, à vous ou à d'autres, à partir du moment où vous l'utilisez.

Je ne vais pas recopier tout de suite la licence dans les fichiers sources. Manque de temps, tout ça.

Déjà qu'il me faut faire les deux trois choses qui suivent...

...

Plus de quatre heures après (eh oui !), voici ce que ça m'a coûté :

• créer sur mon serveur Nexus un repository ouvert au public pour les 12 projets Maven concernés,
• changer la configuration <distributionManagement> des projets Maven pour qu'ils se déploient désormais dans ce repository,
• passer deux projets de mon repository Subversion privé vers mon repository public,
• rajouter une ligne de Copyright dans les fichiers,
• faire une petite revue de javadoc rapide « histoire de »,
• passer quelques tests maison orientés qualité,
• reconstruire les projets,
• lancer les releases Maven,
• rédiger et publier des articles de blog.

Je suis à quelques jours d'une mise en production d'un projet qui dépend de ceux-là : il était donc de toute façon nécessaire que je fasse tout ce qui concerne les releases Maven. On va dire que le fait de rédiger de la doc est un effet collatéral positif ;-)

Voilà fred, tu pourras me faire ton retour...

Développement : à propos d'injection de dépendances (DI)

Ce résumé n'est pas disponible. Veuillez cliquer ici pour afficher l'article.

Développement : visualiser les dépendances entre projets Maven

Mon projet global est constitué d'une bonne centaine de projets Maven. Cette structure est assez pratique pour l'intégration continue (voir le tableau de bord Continuum 1.0.3) et pour vérifier que tout fonctionne sur différentes plates-formes, pratique pour les releases, pratique pour construire morceau par morceau et intégrer de même. Par exemple on peut segmenter la difficulté d'intégrer des Web Services en isolant les responsabilités suivantes dans des projets différents :

• logique applicative,
• liens avec la base de données,
• interopérabilité,
• distribution,
• sécurité.

Cependant au fil des développements les projets évoluent, et les liens entre eux. On se retrouve avec une sorte de plat de spaghettis dont il nous manque une vue d'ensemble. Pour cela je n'ai pas trouvé mon bonheur dans des outils comme le Maven Dependency Plugin, plugin certes très utile, mais cantonné à des analyses projet par projet.

À défaut d'avoir trouvé un outil qui réponde exactement à mon besoin, j'en ai développé un moi-même. Ce n'est certes pas mon métier de faire ça, je ne vais donc pas aller plus loin pour cet outil que la bête réponse, non intrusive, au besoin initial.

C'est un programme qui scanne les fichiers pom.xml de mon espace de travail, et produit un diagramme UML.

Dépendances entre mes projets Maven.

Pour les détails :

• le programme est en Java (le scan et la concaténation étaient au départ une tâche Ant),
• le diagramme UML final est un fichier XML au format du logiciel StarUML,
• le temps d'exécution (scan, analyse, génération) est de 10 secondes pour 113 projets.

Quelques différences de principe avec le Maven Dependency Plugin :

• je m'appuie sur les sources des fichiers POM, et non sur les artifacts déjà installés dans le repository local - je peux donc aussi analyser les POMs de projets qui sont en erreur,
  
• l'analyse porte sur l'espace de travail complet,
• le rendu est graphique.

Je traduis ainsi en UML les liens entre projets Maven :

• <parent> : héritage UML
• <dependency> : association UML
• <module> : agrégation UML
• <plugin> : dépendance UML

Certes, le diagramme UML produit par défaut est illisible parce que surchargé. L'intérêt d'avoir un résultat lisible par un logiciel tiers, StarUML en l'occurrence, est qu'on peut ensuite y déplacer à la main des éléments et en supprimer, afin d'en extraire des sous-diagrammes orientés par domaine.

Voici par exemple un extrait du diagramme ci-dessus, limité à une vingtaine de projets, pour une couche applicative sur laquelle je bosse en ce moment.

Ce genre de petite documentation extraite des fichiers sources est bien utile. La cohérence est importante entre la documentation et le développement.

Pour en revenir à Maven, cette vue permet entre autres de visualiser les dépendances inutiles (quand A dépend de B qui depend de C, A ne devrait pas avoir à déclarer qu'il dépend de C), ou les incohérences entre les versions des bibliothèques.

Si quelqu'un connaît des outils plus évolués pour faire la même chose je suis preneur...

Développement : Custom Maven Repository

Depuis 2007 j'utilise Artifactory comme repository Maven pour :

1. déployer les bibliothèques tierces que je ne trouve pas dans des public Maven repositories tels que ceux d'Apache ou de Codehaus. De telles bibliothèques sont par exemple jvyaml, ou encore les outils Sun pour JMX, pourtant importants dès qu'on tape un peu dans du Lo4J 1.2.15 par exemple,
2. pouvoir déployer mes propres artifacts, notamment ceux en version release.

Artifactory a de nombreux avantages. Il est facile à installer, et son interface HTML est pratique d'utilisation. Il est depuis peu en 2.0.0, version stable et dont l'IHM s'appuie sur Ajax à relativement bon escient. Je compare cela avec des versions d'Archiva livrée avec Maestro, par exemple.

Artifactory fonctionne très bien, et les déploiements Maven s'y font sans souci.

En revanche, il souffre d'un gros défaut : il fait systématiquement planter la Dedibox sur laquelle je l'ai installée.

C'est une Dedibox V1, avec un processeur C7 à 2 GHz et 1 Go de RAM, sous Debian. Les services que j'y ai installés sont :

• BIND9
• Apache 2.2 + PHP + MySQL
• Subversion
• Java 5 + Tomcat 5.5.20 pour : Confluence, Jira, Artifactory
• scripts de backups

Tomcat5.5 démarre avec les options de mémoire suivantes : -Xmx512m -XX:MaxPermSize=256m

Concernant les fuites mémoires connues dans Jira je suis bien en Tomcat 5.5.15+ et j'ai bien -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true

Rien n'y fait, même en désactivant le service de backup (une tâche répétitive pilotée par un serveur J2EE, bonjour l'architecture) et en limitant les repositories à indexer, Artifactory me fait tomber la machine. Certes pas tout à fait à heure fixe, mais en moyenne cinq fois par semaine.

Plantage de machine, ce qui signifie notamment que le wiki et Subversion sont inaccessibles. De plus un redémarrage matériel est nécessaire, ce qui n'est jamais très bon.

Sachant d'autre part que -Xmx256m suffit à faire tourner Confluence et Jira sans Artifactory.

Alors pour le remplacer je vais regarder Nexus. Une comparaison trouvée par ici : Comparing Nexus and Artifactory évoque bien les différences de philosophie, notamment dans le stockage des artifacts. Faire une sauvegarde d'un repository Nexus (un répertoire, tâche pilotable par un bête script) semble bien plus simple que dans le cas d'Artifactory (une base de données JackRabbit, et surtout tâche à piloter par le serveur J2EE... N'importe quoi).

Si cela pouvait m'éviter d'avoir à dédier une machine puissante à ma solution de Custom Maven Repository...