Une recherche sur Google ne donne pas de réponse simple. J’espère que celle-ci le sera.

Si vous avez plus simple, plus lisible ou si j’ai fait une erreur, merci de compléter.

Tout d’abord, qu’est-ce que je reprochais à mon imprimante Epson D78 ? Afin d’y accéder depuis n’importe quel PC, je l’avais branchée sur le port USB de la Freebox. Cela a l’avantage de la rendre visible sur le réseau (la Freebox sert de serveur d’impression). Le problème dans ce cas est qu’on accède plus aux fonctionnalités spécifiques de l’imprimante (niveau d’encre, alignement des têtes, …). De plus, cette imprimante est très bruyante. Dernier problème : sous Linux, il n’y a pas de driver dédié. Il est conseillé sur certains site de prendre les drivers d’autres imprimantes Epson, mais la qualité n’est pas géniale, et les temps d’impression très longs.
Le fait de brancher l’imprimante directement en USB sur un PC améliore les choses, mais dans ce cas il faut allumer ce PC si un autre veut imprimer.

Bref, j’ai cassé ma tirelire, et j’ai acheté la HP C309g sur Amazon au prix de 147 €.

Première impression : massive (surtout à côté de mon ancienne Epson).

J’ai pas voulu tenter le diable, et j’ai suivi la procédure d’installation en ethernet sous Windows. Après pas mal de temps (faut installer le logiciel et imprimer une photo de test), tout marchait nickel. J’ai quand même été obligé de désactiver mon pare-feu…

Ensuite, c’est là que ça devient intéressant : comment la faire marcher sous Linux.

Donc pour récapituler, l’imprimante est branchée sur le switch de la freebox en ethernet, et fonctionne sous Windows. Sur le site de HP, je tente de télécharger les drivers hplip, mais on me dit que la Mandriva 2010.0 a déjà une version suffisante, et qu’il vaut mieux utiliser les packetages fournis par la distribution. Tant mieux, c’est ce que je préfère.

Chez moi tout était déjà installé, mais dans le doute, faites un petit :
# urpmi hplip hplip-gui
Ensuite vous pouvez lancer l’utilitaire HP (hp-toolbox) qui se trouve dans le menu de KDE. Là on vous guide pour installer l’imprimante (il scanne le réseau et la trouve automatiquement). A partir de là vous pouvez imprimer une page de test.

Ensuite j’ai voulu tester le scanner, car c’est ce qui m’inquiétait. Dans l’utilitaire HP, le bouton « scan » ne faisait rien. En regardant dans les paramètres, j’ai trouvé qu’il est sensé lancer xsane. Qui n’était pas installé chez moi :
# urpmi xsane
Mais ça ne fonctionnait toujours pas.

En regardant sur le net, j’ai décuouvert le petit utilitaire hp-check, qui vérifie pas mal de trucs, et qui m’a permit de découvrir ce qui manquait :
# urpmi lib64sane-hpaio1
et également
# urpmi lib64cups2-devel (ça ne sert à rien d’autre qu’à avoir l’utilitaire cups-config, qui permet à hp-check de trouver la version de CUPS).

Après ça, $ hp-check -r ne retourne aucune erreur ni warning, et j’ai pu scanner sans problème.

Il est également possible de scanner depuis une page Web en se connectant directement sur l’imprimante via son adresse IP !

Je n’ai pas testé le Wifi, mais j’ai lu que ça ne posait aucun problème avec la Freebox.

Dernière astuce : l’imprimante étant en DHCP, elle va changer d’IP à chaque redémarrage, ce qui n’est pas bon, car CUPS ne va plus la retrouver, et il faudra supprimer et réinstaller l’imprimante. Je vous conseille donc de récupérer l’adresse MAC de l’imprimante (accessible via l’écran tactile), et de modifier la configuration de la Freebox pour lui assigner toujours la même IP.

Tout d’abord, quelques notions de base.

Les différentes métriques de couverture de code

Je vous laisse lire l’article de Wikipedia (plus complet en EN) si ça vous intéresse, mais sachez que les principales métriques utilisées (et utiles) sont :

• couverture des instructions (!= couverture de ligne)
• couverture des branches (if/else, try/catch/finally, …)
• couverture des expression booléennes (ou conditions)

Méthodes de mesure

Pour mesurer la couverture de code en Java, il faut un moyen de détecter qu’on est passé sur telle ligne/instruction/branche et pas sur une autre. Il existe plusieurs méthodes :

• L’utilisation des API de profiling de la JVM (JVMDI/PI)
• L’instrumentation du bytecode
• L’instrumentation du code source

Passons très vite sur la première méthode. Aucun des outils de mon comparatif ne l’utilise. Son principal défaut semble être le surcoût au niveau des performances (overhead).

Reste donc les 2 méthodes d’instrumentation. L’instrumentation, c’est le fait d’enrichir le programme original avec des instructions supplémentaires. Ces instructions vont être les témoins que l’on est bien passé à cet endroit du programme. Schématiquement, pour mesurer la couverture des lignes de code, il suffit d’ajouter après chaque ligne du programme original un petit bout de code qui va dire « la ligne XXX a été exécutée ». Ce bout de code va stocker son information en mémoire ou dans un fichier, et à la fin, il suffit de collecter les données et de générer un beau rapport.

L’instrumentation du code source

L’instrumentation du code source va réellement modifier le code du programme avant de le compiler et de l’exécuter.

Exemple (schématique) :

Avant instrumentation :

Après instrumentation :

N.B. : Je ne sais pas réellement ce qui est ajouté comme code, sachant que Clover est closed-source, donc ce n’est qu’indicatif.

L’instrumentation du bytecode

L’instrumentation du bytecode consiste à manipuler le code Java compilé (le fichier .class) pour y ajouter les instructions de « trace ». Le principe est donc le même que pour l’instrumentation de code source, avec les différences suivantes :

Avantages :

• pas besoin de posséder les sources du programme (mais dans ce cas on aura que la couverture des méthodes, pas des lignes)
• pas besoin de recompiler le programme, on modifie directement le .class

Inconvénients :

• le bytecode n’est pas exactement l’image fidèle des lignes de code. Le compilateur effectue des optimisations qui peuvent rendre difficile de distinguer l’exécution de lignes de code consécutives. Si le code est compilé avec l’option debug, il est quand même possible de « deviner » la ligne de manière assez fiable

• API pas homogène (on sent bien que ça a de la bouteille et qu’il a fallut jouer avec la compatibilité ascendante
• Composants n’utilisant pas les generics (c’est en cours, mais est-ce que ça sortira un jour ?)
• Manque un bon éditeur graphique (je crois qu’on dit « RAD »)

C’est sur le dernier point que je vais essayer de faire un compte rendu de mes dernières recherches.

Tout d’abord, avant qu’on me pose la question, oui, je connais Matisse. Du moins je l’ai un peu manipulé à plusieurs reprises. Il a certes de nombreuses qualités, en partie du fait qu’il sert de vitrine à toutes les JSR qu’on espère voir un jour de base dans le JDK sans avoir à installer des JAR supplémentaires (appframework, beans binding, ..). Mais il a pour moi 2 inconvénients majeurs :

• C’est sous Netbeans, et dans ma société, l’outil recommandé est Eclipse.
• Le code est non éditable

Pour moi, le second point est vraiment gênant. En effet, en fonction de l’action à réaliser, j’aime bien faire les modifications à la main dans le code plutôt que de passer par l’éditeur.

Sous Eclipse, je connais deux outils open-source et gratuits répondant à priori à mes besoins :

• Visual Editor
• Visual Swing 4 Eclipse

Visual Editor

Visual Editor est un projet assez ancien. Tellement ancien qu’il semble abandonné. Sur le site officiel, la dernière version est pour Eclipse 3.2. Cependant, il semble que la société Soyatec ait repris les choses en main (merci à eux). Les instructions d’installation sont sur le wiki.

J’ai testé VE sous Windows et Linux. Son principal défaut est de forker un process Java pour chaque composant graphique affiché dans Eclipse (chaque onglet). Et vu que je n’ai pas l’impression qu’il y ait un mécanisme de libération (à moins de fermer Eclipse), on se retrouve vite avec des dizaines de process java dans le gestionnaire de tâches, chacun prenant environ 40 Mo de RAM. Mon astuce à 2 centimes : dès que j’ai plus de RAM, je kill manuellement tous les process java (sauf Eclipse bien sûr), et je peux continuer à travailler.
De plus, sous Windows, on a toujours dans la barre des tâches un élément supplémentaire qui correspond au composant qu’on est en train d’éditer dans Eclipse. Sous Linux, c’est encore pire, vu qu’on a également une fenêtre flottante contenant la même chose que ce qu’on a dans l’onglet d’Eclipse. Assez pénible à la longue.

Ses avantages :

• gère tous les layouts de base, dont les GridBagLayout. Il manque cependant la possibilité de pouvoir modifier en masse les GridBagConstraints de plusieurs composants, comme on peut le faire pour les propriétés « classiques »
• il est possible d’exécuter/prévisualiser de nombreux composants, et pas seulement les frames (par exemple les panels), en faisant Run As->Java Bean
• s’en sort très bien avec du code modifié à la main (sauf qu’il semble y avoir parfois des problèmes de cache, il faut fermet et ré-ouvrir l’éditeur)

Visual Swing 4 Eclipse

Je l’ai découvert très récemment. Il semble développé par une seule personne, William Chen. A la première ouverture, c’est une réelle surprise par rapport à VE : pas de process forké, donc pas de fenêtre flottante ni d’élément dans la barre des tâches. Seule la première ouverture d’un composant est un peu longue (j’imagine qu’il initialise pleins de trucs). A l’utilisation, je l’ai trouvé très stable.

A noter que VS4E fourni un GroupLayout custo qui n’est pas celui du JDK 1.6. Cela est est gênant car requiert une dépendance supplémentaire dans le code. Une issue est ouverte à ce sujet.

Donc pour moi, ce serait le parfait remplaçant de VE, sauf qu’il manque encore les fonctionnalités suivantes :

• gestion graphique du GridBagLayout. Il est quand même possible de faire les modifs dans le code, et l’affichage dans l’éditeur est parfait. Cependant, j’ai assez souvent mes modifications (GridBagConstraints) qui sont écrasées quand je fais des modifs dans l’éditeur.
• quelques améliorations d’ergonomie. Par exemple si je sélectionne un composant et que je « sors » trop vite ma souris de la zone, mon composant n’a pas suivi. Je dois repasser ma souris sur l’onglet des composants (sans cliquer) pour « rattacher » le composant à mon curseur et pouvoir le poser dans la zone.

Voici idéalement ce qui devrait exister…

Les générateurs de code

Tout d’abord, il faudrait que tous les outils qui génèrent du code fasse apparaître cette annotation. Voici quelques exemples (que j’utilise quotidiennement) :

• wsdl2java et les stubs Axis2
• javacc
• Magic Draw (et tous les outils d’UML)
• XmlBeans

Je pense que je vais soumettre cette idée dans les différents bug trackers de ces outils, n’hésitez pas à faire de même de votre côté.

Les IDE

Les IDE devraient exploiter cette balise en empêchant le développeur de modifier du code marqué comme @Generated. Bien sûr, le développeur peut retirer la balise et faire des modifs custo, mais dans ce cas le code devient du code qui sera considéré comme manuel. On peut même imaginer que les générateurs de code vérifient la présence de la balise avant d’écraser le code lors de générations ultérieures.

Question subsidiaire : comment empêcher un fourbe développeur de supprimer l’annotation, faire des modifs, puis remettre l’annotation ???

Les outils d’analyse de code

C’est là que ça devient très intéressant. Dans ma société nous utilisons beaucoup d’outils de mesure de la qualité du code. Liste non exhaustive :

• PMD
• Checkstyle
• Findbugs
• Cobertura
• Et Sonar pour piloter le tout

Il est très pénible de devoir configurer chacun de ces outils pour ignorer le code généré. En effet, ce code ne doit pas rentrer dans l’analyse d’un projet, car souvent :

• Il fonctionne de manière fiable (ou alors c’est un bug du générateur, pas du projet)
• Le code généré ne respecte pas le code style du projet (donc checkstyle explose)
• La couverture du code généré par les tests n’est pas toujours intéressante

Si tout ces outils pouvaient prendre en compte l’annotation @Generated, ce serait génial.

Bonus : l’annotation @Generated permet de spécifier l’outil responsable de la génération. Par exemple @Generated(value= »axis2″). On pourrait donc finement configurer le code à ignorer en fonction du générateur.

Bonus 2 : l’annotation @Generated peut se positionner non seulement sur une classe, mais également sur une méthode, un attribut, … Donc on pourrait au sein d’une même classe distinguer le code généré du code manuel !!! Chose qui n’est actuellement pas possible de configurer dans les outils que j’utilise (en général on exclut un package complet de l’analyse).

A suivre…

Récupération du DVD
Tout d’abord, j’ai téléchargé le DVD de la Mandriva 2009.0 64bit (par exemple ici). Je l’ai bien évidemment gravé après avoir vérifié la somme de contrôle MD5 (K3B la calcule automatiquement).

Installation
Une fois le DVD en main, je démarre mon portable, j’insère le DVD, et je boote dessus (appuyer sur le bouton bleu ThinkVantage, puis F12 pour choisir de démarrer sur le lecteur optique). Après divers chargements, viennent les étapes classiques :

• choix de la langue => Europe/FR pour moi
• choix du type de clavier => FR pour moi
• acceptation de la licence (il y a une licence pour du libre ???)

Arrive le seul moment difficile pour des non-initiés : les partitions. Pour moi, c’est simple, j’avais déjà une vieille Cooker, donc les partitions sont déjà faîtes, il faut juste faire attention à ne pas formater les partitions Windows. Je choisis donc l’option « Partitionnement personnalisé » et j’ai juste à cliquer sur mes partitions existantes pour leur affecter un point de montage (/ et /home). Puis clic sur « terminer » et je choisis de formater les 2.

Ensuite, je ne détaille pas trop, j’ai choisis l’environnement KDE, et je n’ai pas pu ajouter tout de suite des médias supplémentaires car ma carte Wifi n’est pas reconnue pour le moment (j’avais pas envie de sortir un câble ethernet à ce moment).

Après l’installation des paquets, et l’installation du boot loader, je me rapelle avoir changé le niveau de sécurité sur « normal » au lieu de « élevé ».

Rien de plus à ajouter ici.

Configuration des médias
Premier démarrage, tout se passe bien, sauf que je trouve pas le thême graphique très beau (question de goût, je sais). Arrivée sur le bureau dans KDE 4. Premier réflexe, installer les mises à jour. Dans drakconf, je vais dans le gestionnaire de media qui me propose d’ajouter automatiquement les sources internet (à ce moment, j’ai été obligé de sortir le câble Ethernet ;)). Pas de selection du miroir, je sais pas trop comment il le choisit. Seule action de ma part : j’ai activé les backports sur Main, Main32, Contrib et Non-free. A ce moment, le gestionnaire de mise-à-jour se réveille et me propose d’installer les dernières nouveautés/patchs, ce que je m’empresse de faire.

WiFi
Mon système est désormais à jour et avec les médias internet configurés (pour PLF on verra plus tard). Première chose à tester : le WiFi. Sur la 2008.1, ça marchait très mal avec mon chipset intel 4965. J’utilise l’assistant graphique pour configurer le WiFi, et miracle, ça marche dès que je retire le câble ethernet. J’ai même la DEL qui s’allume. Pour info je suis connecté à une Freebox avec du WPA (TKIP + AES), mais tout est détecté automatiquement, j’ai juste à saisir la clé.

Étape suivante, j’ajoute les médias PLF grâce au site easyurpmi. Ça se fait en un clique.

Flash 10
Firefox 3 se lance sans problème, mais viens l’épreuve ultime (en 64bit) : l’installation de flash. J’étais en cooker sur un autre PC (avec une carte graphique ATI je précise), et ça marchait pas top (souvent un carré blanc au lieu de l’animation flash, problème de pilote graphique ?). Donc cette fois, je n’ai pas téléchargé le RPM sur le site de Macromedia, mais j’ai téléchargé le tar.gz et j’ai suivi les instructions du forum Mandriva. Pour rappel :

1. copier libflashplayer.so dans /usr/lib64/mozilla/plugins
2. # urpmi nspluginwrapper libcurl4 libnss3
3. # nspluginwrapper -i /usr/lib64/mozilla/plugins/libflashplayer.so
4. redémarrer Firefox
5. Dans about:plugins j’ai bien Shockwave Flash 10.0 r12 et les vidéos fonctionnent sur Youtube (avec le son)

Maintenant, testons les autres fonctionnalités du portable.

L’interrupteur WiFi
J’ai démarré en position « ON ». Quand je le passe sur « OFF », la DEL s’éteint et le réseau se coupe : parfait !
Mais quand je le remets sur « ON », rien ne se passe (pas de réseau, pas de DEL). Je suis oblige de faire

# service network restart

pour que ça reparte. J’ai ouvert un bug chez Mandriva, vous pouvez voter si ça vous importe.

Les touches « multimedia »
Les touches de luminosité fonctionnent, mais n’affichent pas l’OSD comme j’avais sur un portable ASUS. Dommage.
Les touches de volume ne fonctionnent pas, ainsi que toutes les autres Fn+F2 à F12.

Touchpad, pointing stick
Ça a l’air de marcher, mais je m’en sert jamais.

Lecteur de cartes SD
SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
Ça marche du tonnerre. A l’insertion, KDE m’ouvre un petit panel et en cliquant dessus je peux lire mes photos.

Carte graphique
J’ai activé les effets 3D de KWin (pas de compiz). Ça marche correctement, mais il ne faut pas s’attendre à une fluidité exceptionnelle. J’ai essayé d’installer Nexuiz, et dès que je le lance, ça plante. Je peux le killer en passant en console (Ctrl+Alt+F1) mais la résolution et la souris restent bloquées. Plus qu’à relancer X…

Indicateur de batterie
OK, ça fonctionne.

Mise en veille
Quand je rabats l’écran, la session est verouillée (je suis sur secteur). Si je débranche l’alimentation et que je rabats l’écran à nouveau, cette fois rien ne se passe (je m’attendais à une mise en veille ?).
Le « Suspend To RAM » fonctionne très bien et je retrouve mes applications ouvertes et fonctionnelles (même le WiFi se relance correctement).
Le « Suspend To Disk » fonctionne également, même si j’ai eu un peu peur car l’écran est resté noir pendant un long moment avant de restaurer la session.

Divers
La touche ImpÉc ne marche pas. C’est une fonctionnalité manquante de KDE 4.

Je compléterai plus tard au fur et à mesure de mes expériences. Si vous êtes intéressés par une fonctionnalité en particulier, n’hésitez pas à demander.

Dans les temps anciens, un POJO n’était qu’une sorte de struct (comme en C) permettant de stocker des infos. Ces infos viennent généralement de la BD, et sont utilisées dans la couche métier, dans la couche présentation, puis éventuellement retournent en BD.

Avec Hibernate, il est très tentant de créer des POJO représentants les objets métier et de les persister en BD directement (pas de DAO). Il suffit même de mettre de jolies annotations dans le POJO !!

Avec Tapestry 5, il est très tentant d’utiliser directement les POJO métier pour générer des formulaires et des tables de CRUD (pas de DTO). On ajoute donc les annotations Tapestry dans le POJO métier ??? C’est ici que je me suis arrêté, me doutant que ça n’allait pas bien marcher.

En effet, bien souvent, on ne veut pas toutes les informations en même temps (par exemple selon les droits d’une personne, toutes les infos d’un objet ne sont pas affichées). Le problème des annotations est qu’on ne peut en ajouter/enlever dynamiquement (à ma connaissance). Par exemple, si je mets l’annotation @Required sur l’attribut « nom » de ma classe « Personne », ce champ sera tout le temps requis dans tous les pages Web où je vais l’utiliser.

J’arrive donc à la conclusion qu’il faut au minimum 2 couches d’objets : un objet de présentation, et un objet métier/dao (pour le moment ça ne m’a pas posé de problème). La nécessité d’avoir un objet de présentation dédié n’est pas propre à Tapestry 5. Cherchez sur le net GWT + Hibernate, et vous verrez que le sujet est brulant.

Bon, sauf que dans 90% des cas, mon objet de présentation va beaucoup ressembler à l’objet métier (avec peut-être quelques champs en plus ou en moins). De plus, je vais passer mon temps à faire des copie d’attributs dans les deux sens (ce qu’est sensé faire le framework Dozer).

Un autre cas très concret. Souvent, l’objet métier contient beaucoup trop de champs pour être remplis avec un seul formulaire. On utilise alors une succession de pages (wizard) pour remplir petit à petit toutes les informations.

Ce que j’aimerais, c’est pouvoir exprimer ce découpage avec des objets.

Par exemple, prenons un objet métier « Personne ». Cet objet possède les champs : nom, prénom, téléphone, adresse, age
Je veux découper la saisie en 3 étapes :
1) Saisir le nom+prénom
2) Saisir téléphone + adresse
3) saisir l’age

Avec Tapestry 5, je peux générer un formulaire et tout le traitement/validation associé à partir d’un objet, donc je vais avoir les objets :
PersonneWizStep1
PersonneWizStep2
PersonneWizStep3

Les champs nom et prénom de l’objet PersonneWizStep1 vont correspondre exactement aux champs nom et prénom de mon objet « Personne ».
Solution 1 : faire de la recopie avec Dozer (pas top)
Solution 2 : créer un objet NomPrenom qui va remplacer l’objet PersonneWizStep1 et qui sera un composant (au sens Hibernate) de l’objet Personne. Mais bon, on retrouve le même problème. Si en fonction des droits, je veux pouvoir saisir uniquement le nom et pas le prénom (exemple stupide je sais), il me faudrait un autre objet pour y mettre des annotations différentes.