darkBlog

Après 4 ans de services plus ou moins bons ou loyaux, darkBlog ferme boutique. Cela fait trop longtemps que je ne prends plus vraiment de plaisir à écrire ici. Ce blog est devenu au fil du temps plus une forme de contrainte qu'autre chose, donc autant y mettre un terme plutôt que de le maintenir en état de mort clinique, mû par quelques spasmes de temps à autres lorsque la culpabilité de ne plus écrire devient trop forte. Merci à vous de l'avoir lu occasionnellement ou régulièrement. Kenavo !

Voilà un sujet qui est souvent revenu autour de la toile ces derniers temps : la compression gzip avec Domino. Et avec la multiplication des frameworks javascript plus puissants mais aussi plus lourds les uns que les autres (Ext, YUI, Dojo, etc), on comprend aisément pourquoi ce sujet est devenu critique. Initialement prévue pour la R7, puis finalement non (et voici peut-être pourquoi), plusieurs solutions personnalisées de compression gzip ont vu le jour ; en substance :

• Tout d'abord la compression native mais cachée et non supportée officiellement, qui n'a donné que des résultats désastreux de mon coté (bases extrêmement lentes sinon inutilisables).
• Ensuite, l'ajout de fichiers compressés dans les ressources partagées, qui nécessite, comme l'intitulé l'indique, de réaliser préalablement la compression manuellement, ce qui semble difficilement envisageable quand on souhaite appliquer la compression gzip à l'ensemble de ses bases existantes.
• Enfin, l'utilisation d'une servlet qui compresse à la volée, mais qui, tel que proposé, implique la modification de tous les liens existant, ce qui présente autant d'inconvénients que la solution précédente.

La solution que je vais vous décrire est un peu un amalgame des deux dernières ; une servlet pour compresser à la volée les fichiers, mais (et c'est là toute la magie) avec des règles de sites web spécifiques pour réécrire les URL et compresser de manière transparente, sans toucher aux liens existants.

J'attire votre attention sur le fait que le peu de tests réalisés dans des environnements de production ne se sont pas révélés à la hauteur des attentes, et en outre, après quelques jours d'activité, la tâche HTTP a commencé à montrer des signes de faiblesses et une consommation mémoire anormalement élevée. C'est peut-être dû à l'utilisation intensive de la servlet, c'est peut-être dû à autre chose (mauvais paramétrage ?). Cette première expérience me laisse perplexe car j'utilise des servlets pour d'autres applis à fort taux de visite sans le moindre problème. Néanmoins, je reste convaincu que le concept est bon et c'est pourquoi je vous le présente, en attendant de trouver le fin mot de l'histoire. Gardez tout de même ceci en tête avant de le déployer sur vos serveurs !

La servlet de proxy

Vous vous souvenez de l'agent de proxy Domino ? Vous ne l'avez certainement pas vu puisque cela n'apparaissait que dans les commentaires, mais à l'époque je l'avais également codé sous forme de servlet. Et bien j'ai ajouté quelques fonctionnalités à cette dernière, et notamment celle de gzipper le contenu avant de le renvoyer vers le client (paramètre &gzip=1).

Vous pouvez la chopper ici :

• ProxyServlet.java (source)
• ProxyServlet.class (version compilée pour J2SE 1.4.2, soit Domino R7 et +)

Pour ce qui est de l'installation de la servlet, je vous renvoie à cet article un peu vieux mais plus ou moins toujours d'actualité : Domino development with servlets, ou sinon, en quelques mots, vous déposez le fichier ProxyServlet.class dans votre répertoire data\domino\servlets, et vous vous assurez que le gestionnaire de servlets de Domino est activé (document serveur > Internet protocols > Domino web engine).

Les règles de sites web

Vient ensuite la partie plus amusante : les règles de sites web¹. Les règles de substitutions et de redirections font un peu penser à une sorte de mod_rewrite du pauvre, mais avec un peu d'astuce on peut arriver malgré tout à faire des choses sympathiques.

L'idée va être la suivante : pour tous les fichiers ayant l'extension .js ou .css, on redirige (en interne) vers la servlet de proxy avec en paramètre l'URL du fichier susnommé. Le tout est alors totalement transparent pour l'utilisateur. Simple, non ? En réalité, un peu moins que ça, car les possibilités de réécriture des règles de sites web sont limitées et il va falloir mettre en place 2 règles de substitution par extension pour arriver proprement à nos fins.

La première règle va transformer les appels vers les fichiers *.js vers la servlet de proxy avec pour extension de fichier *.js2gzip, tandis que la seconde va intercepter les appels aux fichiers *.js2gzip pour les retransformer en *.js, ce afin de conserver le bon type MIME. Et de même pour les fichiers *.css. Sans cela, la tâche HTTP chercherait à invoquer la servlet indéfiniment (boucle infinie), jusqu'au plantage de la tâche.

*.js -> /servlet/ProxyServlet?url=*.js2gzip&gzip=1&expires=0
*.js2gzip -> *.js

Extrait de ma config :

Attention, notez bien que les règles définies dans la partie Global web settings ne s'appliquent pas pour le site par défaut, avec Domino 7.0.2 FP2 du moins. Cela relève probablement du bug.

Conclusion

A l'heure où j'écris ceci, je ne ne peux vous fournir de chiffre, mais les résultats lors de mes tests se sont montrés sans appels, et les temps d'affichage des applications massives (remplies de fichiers js et de css) nettement réduits au premier chargement. Et ce - c'est là l'intérêt - sans changer la moindre ligne de code des applis. Un simple test avec Firebug et YSlow le prouve.
Je n'explique cependant toujours pas pourquoi les performances de la tâche HTTP se sont dégradées avec le temps, mais je vais continuer à chercher. La solution est peut-être un tuning plus fin du côté des entêtes HTTP d'expiration (voir le premier point de ce billet de Julian Robichaux) afin de soulager un peu la tâche HTTP. Quoi qu'il en soit, si jamais vous essayez de votre côté, n'hésitez pas à me dire ce que cela donne.

Edit : Voilà quelques stats pour illustrer ces propos :

Edit #2 : La solution été a priori trouvée (merci Smicky) ; utiliser d'un côté des connexions "fermées" entre le proxy et le serveur Domino, et conserver des connexions persistantes entre le proxy et le navigateur (ce qui implique de retourner la taille du contenu gzippé via l'entête Content-Length). Le hic, c'est que ça pose des tas de problèmes dans IE ; les CSS ou les JS se perdent très souvent dans la nature. C'est un problème connu, il y a des tas de références là dessus sur Google, et presque autant de patchs chez Microsoft selon les versions de Windows et/ou d'IE. La solution globalement préconisée : ne pas utiliser la compression gzip avec IE. Super. N'ayant pas trouvé de workaround malgré un bon paquet d'heures perdues passées sur le sujet, j'abandonne. C'était pourtant une belle idée.

1 : Pour cela, vous devez nécessairement utiliser les documents de sites internet (document serveur > onglet Basics > Load Internet configurations from Server\Internet Sites documents).

Récemment, le camarade Julien a eu la curieuse idée de se lancer dans la vente en ligne de skins pour iPod avec skinizi. Généralement assez peu intéressé par ce type de gadget, mais malgré tout de nature curieuse, je lui ai demandé de m'en faire parvenir un exemplaire pour mon iPod Nano 2G : le modèle Swirl. Ce qui est maintenant chose faite, puisse que je dipose du fameux skin depuis quelques jours et l'ai expérimenté hier soir. Impressions :

Contenu du package : un skin, une protection écran, et un manuel
(iPod et nappe rouge ornée de grappes de raisin non fournis)

Le package, très pro, est composé du skin, d'une protection écran ainsi que d'un manuel succint mais clair. La pose du skin est franchement facile, sa texture légèrement alvéolée évite les bulles d'air. Le toucher de l'iPod est agréable et, contrairement à ce que j'aurais pu croire, la molette tactile reste très sensible malgré les adhésifs. La pose de la protection écran quant à elle est plus délicate, et je me suis lamentablement vautré en laissant une bulle d'air en plein milieu. Mais en même temps, il m'est arrivé la même chose à deux reprises (puis abandon) sur Nintendo DS, manipulation qui ne semble par ailleurs pas poser de problème à la plupart des gens, donc je ne dois pas vraiment être une référence en la matière.

Au final, je suis agréablement surpris par le produit, tant par sa qualité que par son attrait. J'avais demandé à Julien un modèle plus par curiosité qu'autre chose, mais au final je crois bien que je vais l'adopter. Une très bonne impression, donc.

---

Mais quel rapport avec le titre, me diriez-vous ? J'y arrive, j'y arrive. Mettez-vous d'abord en situation : une soirée entre amis, votre iPod en poche. Une situation assez courante somme toute. Imaginez maintenant qu'une charmante demoiselle célibataire (chose rare en soirée) vous apporte une bière (chose encore plus rare), et là, paf, pas de décapsuleur ni de briquet. Mais que faire, et comment rester en ces lieux le mâle dominant face à une telle adversité ? Et bien fort de la protection anti-rayure de votre skin, déboucher une bière avec votre iPod n'est désormais plus un problème. Et la péronnelle, surprise comme charmée, de prendre un malin plaisir à s'y exercer. La soirée commence bien.

Mais il y a mieux. En fin connaisseur de la gent féminine, vous savez que les femmes sont attirées par tout ce qui est frivole et chatoyant. Sans attendre, vous lui proposez d'observer de plus près l'objet nouveau de ses fantasmes (votre iPod skinné, pas vous). Après quelques hésitations, vous remarquez que ses réactions se font plus franches. Ne vous montrez pas trop hâtif, laissez la poésie du skin agir. C'est alors que la fougue s'empare d'elle. Passion, frénésie ; toute inhibition a soudainement disparu. Il ne vous reste plus qu'à transformer l'essai et lui mettre une cartouche, comme il est d'usage de dire dans le milieu du rugby. La soirée s'annonce décidemment de bonne augure.

Pour toute remarque sur les femmes et ces deux derniers paragraphes, n'hésitez pas à m'écrire. Du reste, si les skins vous intéressent, ça se passe sur skinizi. Et un grand merci à mon assistante photo.

PS : Toute ma considération à celui qui arrive à retrouver l'album qui passe sur la dernière photo (indice : c'est français).

Vous l'avez peut-être remarqué, étrangement, il n'y a pas d'instruction Exit while en LotusScript (du moins avec Domino 7), permattant de sortir d'une boucle While ... Wend. Une solution simple à ce problème est d'utiliser une boucle Do While ... Loop à la place puis l'instruction Exit do. J'aime quand un plan se déroule sans accroc.

Je ne sais pas si vous vous rappelez, mais il y a quelques mois, je me suis fendu d'un billet particulièrement assassin sur Lotus Sametime 7.0, dans lequel je relatais les nombreux déboires que nous avons rencontré lors de la migration de Sametime 6.5.1 en 7.0. Pour le coup, je gardais une image fondamentalement négative du produit.

Cet été, je me suis déplacé dans la filliale américaine d'un de nos clients pour établir une connexion entre les serveurs Sametime américain et européen (ce dont je viens de parler quelques lignes plus bas). Figurez-vous que j'ai été très surpris, en discutant avec les administrateurs locaux, d'apprendre que ceux-ci n'ont jamais rencontré le moindre problème avec le produit. Celui-ci tourne sur iSeries, alors que l'européen (celui sur lequel je suis intervenu pour la migration) tourne sur Windows 2003.

Lors de l'opération de rapprochement des deux serveurs, il est apparu que cela ne fonctionnait pas car les serveurs n'utilisaient pas la même nature de connexion vers l'annuaire. Je me suis alors orienté vers l'infocenter de Sametime en quête de la procédure de changement de type de connexion. Et j'ai été frappé par l'étape suivante : Copy and rename the .DLL files, edit the Notes.ini file, or edit the Sametime.ini file. En substance, pour mener à bien cette opération, sur Windows, il est nécessaire de renommer tout un tas de DLL ainsi que d'écraser d'autres fichiers plus ou moins obscurs, alors que sur les autres systèmes, il suffit de modifier un simple paramètre dans le fichier sametime.ini (DirectoryType=LDAP).

Et a bien y réfléchir à posteriori, tous les problèmes que nous avons recontré lors de la migration sont propres à Windows : crash de la tâche HTTP avec la JVM de Domino 7.0.2, services qui ne démarrent pas quand Sametime est lancé depuis Remote Desktop, les meetings qui peuvent ne pas fonctionner quand le processeur utilise l'hyperthreading, le partage d'écran qui nécessite plus de 256 couleurs, etc. Je crois que ça en dit long sur la stabilité de Lotus Sametime sur Windows. J'avais conclu par "C'est bien dommage, car Sametime est un beau produit quand il marche.". Aujourd'hui, je suis convaincu que Lotus Sametime est un beau produit, et qu'il marche très bien. Mais par sur Windows.

Disposer de deux serveurs Sametime dans deux organisations différentes, c'est bien, mais les connecter ensemble pour permettre aux utilisateurs de l'un de communiquer avec ceux de l'autre, c'est encore bien mieux. Et (curieusement ?), c'est quelque chose d'assez simple à mettre en oeuvre¹, et qui est très bien détaillée dans les deux articles suivants : How to enable communication between multiple Lotus Sametime servers et Getting two Sametime servers in the same community.

Ce que ces deux articles ne précisent pas toutefois, c'est qu'outre le fait que ces deux serveurs doivent partager le même annuaire, la connexion à ces annuaires doit être de même nature. Plus clairement : si vos deux serveurs Sametime pointent vers le même annuaire, mais que l'un utilise une connexion native à l'annuaire Domino, et que l'autre accède à l'annuaire Domino via LDAP, la connexion entre les deux serveurs ne fonctionnera pas. Et cela est aisément compréhensible ; respectivement l'un verra CN=Obiwan Kenobi/O=Ordre Jedi quand l'autre verra CN=Obiwan Kenobi,O=Ordre Jedi. Evident ? Peut-être, mais pas tant que ça quand on est dans le vif du sujet. La solution est bien évidemment de paramétrer les serveurs Sametime pour qu'ils utilisent le même protocole pour accéder à l'annuaire (et à ce sujet, je conseille vivement LDAP plutôt que les connexions natives à l'annuaire Domino).

1 : en dehors des problématiques liées au réseau si les organisations ne sont pas en LAN : autorisation des IP, ports, reverse proxy, DMZ, etc.

Déjà évoqué dans le second billet traitant du développement de portlets avec Jetspeed et Eclipse, les informations que l'on retrouve dans WebSphere Portal à l'issue du déploiement d'un portlet JSR 168 proviennent du descripteur de déploiement portlet.xml dudit portlet. Cela dit, comme ce fichier peut se montrer plutôt verbeux, et que sa représentation XMLAccess l'est encore davantage, difficile de déterminer le rôle et l'impact précis de chacune des données du descripteur de déploiement.

C'est pourquoi je me suis livré à une petite expérience visant précisément à lever le voile sur cette zone d'ombre. En ressort que peu d'informations sont réellement utilisées, mais qu'elles sont essentielles et qu'il convient de les manipuler avec précaution (j'y reviendrai plus loin). Voici deux extraits de ces fichiers, volontairement épurés :

Descripteur de déploiement du portlet :

<portlet-app id="FOO">
    <portlet>
        <portlet-name>BAR</portlet-name>
        <portlet-info>
            <title>PLOP</title>
        </portlet-info>
    </portlet>
</portlet-app>

Puis l'export XMLAccess du portlet :

<web-app uid="FOO.webmod">
    <servlet referenceid="BAR.servlet">
    <portlet-app name="FOO" uid="FOO">
        <localedata locale="fr">
            <title>FOO</title>
        </localedata>
        <portlet name="BAR">
            <localedata locale="fr">
                <title>PLOP</title>
            </localedata>
        </portlet>
    </portlet-app>
</web-app>

Il apparaît que les deux données majeures sont la balise portlet-name ainsi que l'attribut id de la balise portlet-app : à elles seules, elles déterminent les données vitales du portlet déployé dans WPS.

Pourquoi tout ceci est important et que je vous bassine avec ? Parce qu'une mauvaise manipulation, même motivée par de très bonnes intentions, peut avoir des conséquences dramatiques. Un exemple ? Imaginez que pour une quelconque histoire de suivi de conventions de nommage (ce qui est tout à votre honneur), vous décidiez de modifier la balise portlet-name du descripteur de déploiement. Redéployez votre module web, et vous perdez tous les portlets issus du module dans votre portail¹.

Bug de WPS ? Non, en réalité, la modification du portlet-name a entrainé des modifications de la servlet sous-jascente ; en effet celle-ci se voit attribuée un nouveau referenceid (celui-ci étant basé sur la valeur du portlet-name), et du coup, d'un nouvel objectid, WPS devant considérer que la servlet a changé (et ça semble compréhensible, le referenceid étant le seul attribut utilisé pour l'opération de lookup). Et vos portlets existants, liés à cette servlet par l'attribut servletref, disparaissent soudainement de la surface de votre portail. Oui, c'est sournois, mais ça peut arriver, et très facilement. Les exports XMLAccess sont formels.

Que retenir de tout ceci ? Que le portlet-name comme l'attribut id de la balise portlet-app sont les données les plus importantes du descripteur de déploiement, et qu'une fois un module déployé, mieux vaut ne jamais toucher à ces valeurs.

1 : c'est du vécu. Et ce comportement est reproductible avec WPS 5.1 et 6

Ayant un peu de temps devant moi en ce début d'après-midi (GMT-5), j'en ai profité pour migrer le blog vers dotclear 1.2.7 (je tournais sur l'obsolète 1.2.3 depuis plus de 2 ans & demi, je sais, c'est mal). Ce fut aussi l'occasion de faire un peu de ménage dans les plugins et d'installer spamclear, en espérant que celui-ci me rende la vie un peu plus facile (peu avant que je ferme les commentaires, je me prenais dans la tronche environ 150 spams par nuit).
Au sujet de spamclear, celui-ci n'est pas tout à fait compatible avec les nouvelles mesures de sécurité de dotclear 1.2.7, mais le patch suivant permet de rendre fonctionnel les fonctionnalités d'entrainement du filtre. De même pour dcBlogmark, mais la mise à jour est facile (voir à ce sujet les conventions de codage de dotclear).

Les commentaires sont désormais réouverts (et toujours soumis à approbation en attendant que le filtre s'entraine un peu), n'hésitez pas à me signaler tout problème.

Demain je pars pour 11 jours avec quelques amis (dont Tetert l'expatrié) pour l'édition 2007 du Sziget Festival, qui se déroule à Budapest, Hongrie, pour 8 jours de concerts & autres activités sympathiques, puis 3 jours de découverte de la capitale hongroise. Musicalement ça risque d'être nettement différent du très humide Hellfest 2007 ; il y en aura pour tous les goûts (rock, pop, électro, musique du monde, tsigane, etc) - et même un peu pour moi, avec la présence de quelques groupes sympathiques comme Napalm Death (4^ème fois que je vais les voir en moins d'un an !) ou encore Satyricon. Mais la majorité des groupes me sont totalement inconnus, à part quelques têtes d'affiches (Nine Inch Nails, The Chemichal Brothers, et quelques autres que je ne connais que de nom...). Il s'agit donc de vacances clairement placées sous le signe de l'ouverture (et je vois déjà certaines mauvaises langues de mon entourage dire que cela ne me fera pas de mal).

Bref, comme je ne pourrai pas surveiller l'activité de ce blog d'une part, et comme en ce moment je me fais harceler de spams d'autre part (1200 spams en moins de 48 heures -- il faut vraiment que j'installe spamclear et/ou du captcha), les commentaires sont coupés jusqu'à nouvel ordre. D'ici là, amusez-vous bien et pas de bêtise.

Les deux méthodes classiques d'exécution de scripts XMLAccess sont d'une part l'importation depuis l'interface d'administration du portail (Paramètres du portail > Importation XML), d'autre part l'outil en ligne de commande xmlaccess.sh (ou .bat) que l'on lance directement depuis le serveur. Mais il en existe une troisième, vraissemblablement moins connue - en tout cas non mentionnée dans l'infocenter - qui consister à communiquer avec le serveur directement via le protocole HTTP.

Le principe est simple :

• Une requête HTTP de type POST est effectuée sur /wps/config (ex : http://wps.ftel.lan:9081/wps/config)
• Les accréditations de l'administrateur sont transmises via les entêtes HTTP WPS-User et WPS-Password (pour les versions de WPS plus anciennes, l'unique entête WPS-Authorization, concaténation du login et du mot de passe séparés par un ':', était de vigueur. Le plus simple est de mettre les deux.).
• Le script XMLAccess à proprement parler est transmis en tant que contenu "brut" de la requête.

En guise de réponse, le portail retourne une page HTML dont le contenu est le résultat de l'exécution du script XMLAccess. Petite démonstration.

Tout d'abord, la requête HTTP :

http://wps.ftel.lan:9081/wps/config

POST /wps/config HTTP/1.1
Host: wps.ftel.lan:9081
WPS-User: wpsadmin
WPS-Password: mypassword
WPS-Authorization: wpsadmin:mypassword
Content-Type: text/xml
<?xml version="1.0" encoding="UTF-8"?>
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.3.xsd"
type="export">
  <portal action="locate">
  <skin uniquename="ftel.skins.BlackSkin" action="export"/>
</portal>
</request>

A titre purement informatif, la réponse du portail :

HTTP/1.x 200 OK
Server: WebSphere Application Server/5.1
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en
Transfer-Encoding: chunked

Nettement plus intéressant, le résultat de l'exécution du script XMLAccess :

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp5102_032" type="update" version="5.1.0.2" xsi:noNamespaceSchemaLocation="PortalConfig_1.3.1.xsd">
  <portal action="locate">
    <skin action="update" active="true" default="false" objectid="_K_002C1DBG030CI830_IP" resourceroot="BlackSkin" type="default" uniquename="ftel.skins.BlackSkin">
      <localedata locale="fr"><title>FTEL : Black Skin</title></localedata>
    </skin>
  </portal>
  <status element="all" result="ok"/>
</request>

Et voilà ! Quel intérêt me diriez-vous ? Et bien ceci rend possible l'exécution de scripts XMLAccess à distance (ce qui reste possible avec l'outil xmlaccess.sh sous réserve de l'avoir installé), mais aussi - plus intéressant - par programmation. Une des premières applications qui me vienne à l'esprit est de combler les manques et/ou palier aux lourdeurs de l'interface d'administration par de petits scripts PHP, par exemple pour faire du nettoyage (suppression des portlets applications qui n'ont plus de portlets), ou encore effectuer rapidement des tâches coûteuses en clicks (changer toutes les langues d'une page ou d'un portlet). C'est d'ailleurs ce que nous sommes en train de faire chez mon client, et c'est très prometteur.

Pour ceux qui se demanderaient pourquoi PHP, ce choix s'impose de lui même : PHP possède une extension à la fois simple et très puissante de traitement de données XML (SimpleXML), et le Zend Framework propose un client HTTP bien commode (Zend_Http_Client). Ces deux éléments réunis, exécuter scripts XMLAccess puis en analyser les résultats en PHP est un jeu d'enfant.

Pour la route et en guise de conclusion, voici un exemple d'export complet d'un portail avec Zend_Http_Client :

$script = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n
  <request xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:noNamespaceSchemaLocation=\"PortalConfig_1.3.xsd\" type=\"export\">\n
    <portal action=\"export\"/>\n
  </request>";

$client = new Zend_Http_Client("http://wps.ftel.lan:9081/wps/config");

$client->setHeaders(array(
  'WPS-User' => $username,
  'WPS-Password' => $password,
  'WPS-Authorization' => $username . ":" . $password
));
$client->setRawData($script, 'text/xml');
$client->setMethod(Zend_Http_Client::POST);

$response = $client->request();

$result = $response->getBody();

Difficile d'y échapper, en ce moment, c'est les promos, et à ce titre, Ytria, éditeur qui propose une large gamme de logiciels dédiés aux développeurs Lotus Notes, reconduit cette année son offre de licences gratuites jusqu'à la fin de l'été. Si j'en parle, ce n'est pas parce que Jérôme me l'a gentiment demandé, ni même parce qu'il s'agit d'une équipe fort sympathique que j'ai eu le plaisir de rencontrer à l'occasion de la LotusSphere 2007, mais bien parce que leurs produits sont tout simplement du bonheur en barre, dont mes collègues (hein, Renaud) comme moi sommes fans et bénissons chaque jour ses géniteurs.

Alors si vous avez un peu de temps devant vous - ce qui est souvent le cas en été, généralement signe d'activité réduite - je ne saurais que trop vous conseiller d'y jeter un oeil. Et si vous ne devez tester qu'un logiciel, essayez ScanEZ, un explorateur / éditeur de documents d'une puissance telle qu'on en vient à se demander pourquoi IBM n'a jamais intégré quelque chose de similaire à Lotus Designer. Leur slogan "Addiction may occur" est on ne peut plus juste ; une fois qu'on y a goûté, difficile de s'en passer.
Les plus démunis d'entre-vous seront ravis d'apprendre qu'une version en lecture seule de ScanEZ (une expérience qui devient vite frustrante, toutefois) reste disponible tout au long de l'année.

Après le permis voiture (2000) et le permis moto (2001), me voici depuis quelques jours l'heureux titulaire du permis côtier, permis qui autorise son propriétaire à naviguer avec tout batiment à moteur jusqu'à 6 milles¹ des côtes ou d'un abri. Son obtention a représenté 1 mois & demi d'apprentissage de la partie théorique (assez dense) dont 5 jours quasi-complets, ainsi que 3 heures de pratique (ça peut paraître peu, mais c'est suffisant pour passer l'épreuve). Un investissement somme toute conséquent qui s'est traduit en parti par un certain silence sur ces quelques pages, tout comme des vacances finalement très studieuses et peu reposantes. Mais bon ; c'est désormais derrière moi, je suis ravi et c'est une bonne chose de faite.

Modèle de navire sur lequel j'ai passé mon examen.
115 chevaux au cul, des pointes à 27 noeuds²
avec 5 personnes à bord, y'a pas à dire, ça décoiffe !
(photo : bateauxdepeche.com)

J'invite d'ailleurs tous ceux qui sont intéressés par ce permis à s'y pencher au plus vite, la nouvelle réforme de cette année, qui devrait entrer en vigueur dans les mois à venir, rend la partie théorique sensiblement plus difficile (25 questions au lieu de 20, temps limité pour les réponses [utilisation d'un boitier électronique au lieu d'un QCM papier], questions à réponses multiples, nouvelles connaissances requises [lecture des cartes marines], etc).

Sinon, que puis-je bien faire de beau avec tout ces permis, me demanderiez-vous ? Et bien comme tout le monde : m'entasser tous les matins dans la ligne 1 direction la Défense, quelle question.

1 : environ 11 km. Les 6 milles, c'est nouveau, avant c'était 5 milles.

2 : 50 km/h. Sur l'eau, c'est beaucoup.