Jérôme Radix Blog

Linux - Comment convertir des vidéos MP4 (YouTube, DailyMotion...) en MP3 en leur appliquant un gain normalisé à 89dB (ReplayGain)

2011-07-14T14:48:00.000-07:00

Les sites d'hébergement de vidéos comme YouTube ou Dailymotion contiennent un grand nombre de vidéos correspondant à de la musique : soit des clips vidéo, soit uniquement la musique et des photos statiques en guise de vidéo. Il peut être intéressant de récupérer la musique de ces vidéos et d'en faire des fichiers audio pour les écouter sur votre lecteur audio préféré.

Tout d'abord il faut télécharger les vidéos de YouTube ou Dailymotion sur votre disque dur au format MP4. Pour cela vous pouvez utiliser les nombreuses extensions de votre navigateur préféré vous permettant de faire cela. Sous Firefox, j'utilise Video Download Helper. Sous Chromium, j'utilise Easy YouTube Video Downloader.

Attention à ne pas utiliser le nom de fichier d'enregistrement par défaut proposé par ces extensions car il y a souvent des caractères spéciaux qui ne sont pas forcément supportés par votre système de gestion de fichier.

Dans le cas de Easy YouTube Video Downloader, le nom de fichier par défaut contient en premier caractère, un caractère spécial invisible à l'oeil nu mais pourtant bien présent (je le vois avec Dired sous Emacs). Pour être sûr de ne pas avoir de problème, renommez ENTIÈREMENT le fichier. Dans XFCE Thunar par exemple, sélectionnez le fichier et faites la combinaison de touches suivante : F2 Ctrl-a Suppr. Puis saisissez votre nom de fichier.

Vous êtes sous Linux Ubuntu, vous voulez convertir un ensemble de fichier vidéo MP4 provenant de YouTube ou Dailymotion, en fichier audio MP3. Vous voulez aussi que le niveau sonore de vos MP3 soit normalisé à 89dB tel que défini par ReplayGain.
Cette normalisation est importante pour éviter de devoir monter ou baisser le niveau sonore de votre lecteur de MP3 à chaque changement de morceau.

Tout d'abord, installez les modules suivants via le Gestionnaire de Paquets Synaptic :

- ffmpeg
- sox
- libsox-fmt-all
- mp3gain

Ensuite, créez vous un fichier MP4toMP3 avec le contenu suivant :

#!/bin/sh
for i in *.mp4; do
 echo "$i"
 ffmpeg -i "$i" -vn -acodec copy "${i%mp4}m4a"
 sox "${i%mp4}m4a" "${i%mp4}mp3"
 rm "${i%mp4}m4a"
 mp3gain -c -r "${i%mp4}mp3"
done

Donnez les droits d'exécution à ce fichier :

chmod a+x MP4toMP3

Et voilà ! Placez vous dans le répertoire qui contient vos MP4 et lancez ce fichier de script MP4toMP3. Le script va convertir tous les fichiers MP4 du répertoire en MP3 et appliquer un gain normalisé à 89dB (ReplayGain).

Attention, il s'agit bien de l'application du gain sur tout le fichier, pas du stockage d'un "tag" REPLAYGAIN dans le fichier MP3. Comme cela, le fichier a le même niveau sonore quelque soit le lecteur MP3, même si ce dernier ne supporte pas la norme ReplayGain.

Vous pouvez maintenant lire tous ces fichiers audio avec votre lecteur MP3 préféré.

Apache Ant/Ivy versus Maven : Quel outil de construction maîtriser sur le long terme ?

2011-07-01T06:20:00.001-07:00

Un projet démarre toujours un peu dans l'euphorie, et bien souvent dans le stress dès la première minute où vous vous rendez compte que vous êtes en retard sur les échéances dès la réunion de lancement du projet avec votre client.

Dans ces conditions, il est déjà intéressant d'avoir dès le début du projet, un squelette d'application "vide" mais "fonctionnant", du code et tout son outillage (son attirail) s'exécutant sans aucune fonctionnalité particulière.

On veut tous passer du temps à ajouter des fonctionnalité à un logiciel, pas perdre son temps à mettre en place une architecture standardisée comme Oracle Java EE par exemple. L'avantage d'un tel standard est de proposer des briques et des protocoles standards pour la plupart des applications d'entreprise : une couche présentation (JSF, Struts), une couche métier (EJB3), une couche de persistance (JPA2), des modèles de conceptions tout prêt à être utilisés (Java blueprints), etc.

Ce qui fait que pour la plupart des applications d'entreprise, c'est à dire de gestion de l'information, il n'y a même plus à concevoir quoique ce soit : il ne reste plus qu'à programmer les règles métier et le fonctionnel. Il s'agit d'ailleurs de plus en plus de "configuration" ou de "génération" des composants standards et outils "sur étagère" plutôt que de "programmation" proprement dite.

C'est à la fois une bonne chose (la réutilisation se généralise) et une moins bonne chose pour l’ingénieur en informatique: la conception devient un art mineur et rare dans le monde de l'entreprise. Ce qui a pour conséquence d'offrir de plus en plus de travail à des techniciens et analystes métiers, plutôt qu'à des ingénieurs. Architecte Java ne veut maintenant plus rien dire si ce n'est pour désigner quelqu'un qui connait l'architecture standard Java et sait la mettre en place. Ce n'est plus quelqu'un qui conçoit, mais quelqu'un qui applique. Un architecte logiciel à proprement parlé n'est et ne doit pas être lié à des standards : il doit être capable de définir l'architecture adéquat à un besoin donné en respectant toutes les contraintes qualités qu'on est en droit d'attendre aujourd'hui d'une application logicielle.

Dans ce contexte, il est important de maîtriser à fond quelques outils qui seront présents quelque soit le type de logiciel. Il s’agit de tous les outils de développement : EDI, outils de construction, outils d’analyse de la qualité du code, outils de tests du code, outils de gestion des versions, d’intégration continue. Il est intéressant de passer du temps à maîtriser complètement ces outils, car ils ne seront pas remis en cause dans une dizaine d’année.

Pour ma part, dans le monde Java, je me suis concentré sur les outils suivants : Apache Ant et Ivy, JUnit, Checkstyle, PMD, Jenkins et les bibliothèques standards de la version Java SE.

De plus, j’essaie de maîtriser complètement mon EDI préféré : Emacs.

Par contre, même des technologies dites standards, ne le seront plus au bout de 5 ans, comme par exemple les technologies suivantes qui sont devenus obsolètes :

- toute la couche client de Java SE (AWT, Swing, Java Sound, Java2D, Applets, ImageIO, Accessibility) est maintenant remplacée par JavaFX 2.

- toutes les vieilles couches serveur sont obsolètes : EJB 1 et 2 remplacées par EJB3, les anciennes version d’hibernate remplacées par JPA, même Spring devient obsolète face à JSR-330 (supporté par Spring après coup via des astuces) et de nouveaux frameworks qui suivent cette nouvelle norme comme par exemple Google Guice.

Et bien sur, tout ça sera à revoir dans 5 à 10 ans. Ce qui fait tout drôle aux nouveaux venus dans le monde de l’entreprise informatique, c’est qu’ils vont être confronté à de nombreuses applications qui n’auront même pas franchi le gouffre entre Java 1.4 et Java 5. De nombreuses applications Java peuvent maintenant être appelées des « application legacy » au même titre que des applications codées en Cobol.

Il faut donc s'attendre à tout et maîtriser des outils suffisamment souples, extensibles et personnalisables pour s'adapter à tout type de situation. Ce qui ne va pas dans le sens des outils qui se basent surtout sur des "conventions" plutôt que sur de la configuration, comme par exemple Maven qui structure déjà un projet Java.

Dès que vous sortez de la convention et du comportement standard des plugin Maven, vous allez devoir hacker un plugin Maven pour vous adapter à votre contexte projet. Maven est intéressant pour démarrer un projet rapidement mais dès qu'un projet se complexifie, il y aura toujours des tâches très spécifiques et "tordues" à accomplir. C'est le propre d'un projet qui a son identité propre : si ce n'était pas le cas, ce ne serait pas un projet de développement, mais uniquement un projet de génération de code ou d'installation de composants sur étagère.

Mon vécu sur les outils Ant/Ivy et Maven m'a appris que Ant, par sa simplicité, sa personnalisation, son extensibilité et sa simplicité permet de survivre à des projets complexes et historiquement chargés. Maven, (considéré par certains comme l'EJB2 des outils de construction) permet de démarrer rapidement des projets complets sans avoir à se poser trop de questions sur comment est construit réellement le logiciel. Mais avec le temps qui passe, on est toujours confronté à ces questions précises sur ce qui se passe réellement en arrière plan, et comment changer ces détails.

Bref, Maven me semble aller dans le sens inverse du principe KISS. De plus Ant/Ivy est aussi "puissant" et générique qu'on le souhaite si on passe ne serait-ce que le temps d'un seul livre, à apprendre ce qu'il est capable de faire :

Ant In Action est un bon livre sur Apache Ant/Ivy et va jusqu'au bout de la logique de Ant pour montrer qu'on peut tout faire avec et ce en faisant un minimum d'adhérence aux spécificités d'un projet. J'ai adoré construire de bout en bout un fichier build très simple mais très puissant et surtout très lisible : je suis capable de faire tous les types de traitement que je souhaite et réutiliser mon fichier build.xml dans chacun de mes projets.

Digital Transmission Content Protection sur Wikipedia Français

2011-06-25T05:32:00.000-07:00

J'essaie régulièrement de soumettre des articles en Français à Wikipedia dans les domaines que je connais. Je viens de créer aujourd'hui la page Digital Transmission Content Protection, mécanisme de protection du contenu diffusé sur des appareils multimédias notamment par un protocole comme DLNA. Cela sert notamment dans le domaine de l'IP TV.

Comment apprendre quelque chose le plus rapidement possible ?

2011-05-20T05:26:00.000-07:00

Quelle est la seule et unique manière d’apprendre quelque chose dans ce bas monde ? La pratique. Seule la pratique permet d’acquérir au plus profond de soi les éléments d’un domaine de compétence particulier.

La pratique passe par l’exécution d’exercices. Dans ce contexte, les formations doivent se baser principalement sur les exercices plutôt que de long discours théoriques. La théorie s’assimile par la pratique, et on peut très bien introduire les nouveaux concepts au fur et à mesure, chaque exercice mettant en œuvre les éléments acquis dans le passé et 1 ou 2 nouveaux éléments à acquérir.

Un livre électronique pour l’apprentissage du langage Python reprend ces principes et propose de passer par une série d’exercices plutôt que de faire l’énoncé de toutes les particularités du langage. Il s’agit de Learn Python the Hard Way. Cela semble vraiment la manière la plus efficace et donc la plus rapide pour « apprendre » à programmer en Python.

L’auteur conseil de ne pas faire de copier/coller car un des éléments essentiels d’un programmeur est de savoir taper sur son clavier. C’est évident, mais c’est finalement un des secrets de la productivité : savoir taper à la machine et puis aussi : maitriser ses outils de développement.

Comment exécuter du code par projet dans Emacs

2011-03-16T08:48:00.000-07:00

Pour personnaliser Emacs, les emacsiens que nous sommes ont l'habitude de mettre toute notre personnalisation dans le fichier ~/.emacs sans même avoir besoin de structurer ce fichier. Or j'ai besoin de gérer une configuration particulière par projet, le terme projet correspondant ici à un ensemble cohérent de fichiers permettant de produire un certain nombre de livrables clairement identifiés (un peu comme le fichier build.xml pour Apache Ant).

Dans Emacs, il existe quelques fonctions bien pratiques pour faire cela. Par exemple, j'ai besoin de définir localement et de façon spécifique selon le fichier ouvert, certaines variables comme la variable compile-command pour un projet écrit un python. Je veux une configuration bien particulière pour ce projet. Pour cela, j'utilise les Variables de Répertoire et met le code suivant dans mon .emacs :

(dir-locals-set-class-variables 'python-dev
 '((python-mode . (
     (eval .
         (set
             (make-local-variable 'compile-command)
             (concat "python " (buffer-file-name))))))))

(dir-locals-set-directory-class
"c:/Users/jrx/src/tests/" 'python-dev)

Je construit la variable locale compile-command avec le nom du fichier affiché dans le buffer. Cela marche pour tous les fichiers qui sont dans le répertoire défini par l'instruction dir-locals-set-directory-class et tous ses sous-répertoires. On peut bien sûr imaginer sortir les instructions set, make-local-variable dans une fonction à part histoire de clarifier les choses.

On peut aussi créer des fichiers .dir-locals.el dans chaque répertoire que l'on veut personnaliser, mais je n'aime pas trop ça parce qu'on se met à écrire dans un répertoire projet des fichiers qui n'ont rien à voir avec le projet en soi. Et puis, il peut y avoir des répertoires où on n'a pas les droits en écriture.

Gérer une équipe comme on devrait enseigner les mathématiques

2011-02-12T01:39:00.000-08:00

Qu'est-ce qui est vraiment au fondement même de l'informatique ? D'où viennent les véritables progrès de cette discipline ? L'informatique paraît encore jeune et beaucoup de nouveautés apparaissent mais est-ce vraiment des innovations ou de simple créations ?

La plupart des choses qu'on appelle nouveauté en informatique, ne sont en fait que de nouvelles créations sans originalité fondamentale : un nouveau framework Web, de nouvelles librairies performantes, des nouveaux langages pour dire toujours la même chose.

Les véritables nouveautés en informatique ne viennent que d'une seule source : les mathématiques. On a beau chercher recréer des centaines de fois la roue, ce n'est toujours qu'une roue, et un framework Web est toujours un framework Web. La science informatique (computer science) est la branche des mathématiques qui a pour seul objectif le progrès et la nouveauté.

Or les mathématiques sont souvent mal perçues, car plus considérées comme un moyen de sélection à l'école plutôt que l'outil parfait pour la résolution des problèmes. La justification de l'apprentissage de certains concepts en mathématique à l'école est uniquement basée sur le fait que l'élève en aura besoin pour les classes supérieures. Mais comment faire comprend à un gamin qu'il faut qu'il s'intéresse et s'investisse dans les mathématiques uniquement parce qu'il risque d'utiliser ce savoir dans 2 ans ? Un peu de psychologie enfantine fait aisément comprendre que ça ne peut pas le motiver.

Ce qui motive le plus, c'est de résoudre des problèmes pratiques pour lesquels l'élève peut se sentir investi d'une responsabilité ou d'une curiosité naturelle. Les cours de mathématiques pourraient être adapté pour proposer à l'élève un apprentissage progressif en poussant l'élève à se poser les bonnes questions et demander au professeur des outils pour l'aider à résoudre son problème.

Une très bonne (et très belle en plus) réflexion sur le sujet est la présentation Math is not linear du professeur de Mathématique Alison Blank. Faire toucher du doigt aux élèves ce qui est intéressant dans les mathématiques est vraiment une tâche primordiale d'un professeur. Dans l'idéal le professeur ne fait qu'aider les élèves en leur offrant des problèmes intéressants, en provoquant des questions qui poussent à réfléchir, en donnant, quand le besoin se fait sentir les outils nécessaires pour la résolution des problèmes.

Le parallèle peut être fait avec les personnes en charge de gérer une équipe. Le plus important pour un gestionnaire est de savoir faire fonctionner une équipe, déléguer sans imposer un diktat qui n'aurait pour conséquence que la démotivation. Le mieux en tant que chef d'un projet est de savoir poser les bonnes questions et les bons problèmes pour que chaque membre de l'équipe propose leur propres solutions et prennent volontairement leurs responsabilités. C'est ici que l'expérience du chef de projet est primordiale car il doit savoir détecter dans toutes les solutions ou propositions, les problèmes à venir, les manques éventuels, et doit pouvoir mettre en perspective les solutions vis à vis des objectifs du projet (périmètre, délais, coûts, qualité, communications, ressources, risques et achats).

Mais le chef de projet doit résister à la tentation de dire ce qu'il faudrait faire, même s'il a une idée précise de la solution. Si sa solution est la meilleure, elle réapparaitra d'elle même dans les réponses des membres de l'équipe. Le chef de projet sera souvent surpris du fait que sa solution n'est finalement pas toujours la meilleure.

Comment bien utiliser OpenID

2011-02-05T04:42:00.000-08:00

L'enfer est pavé de bonnes intentions, c'est bien connu. OpenID est une bonne intention qui, si vous ne la maitrisez pas, vous rendra la vie infernale. J'ai eu la douloureuse occasion de m'en rendre compte récemment quand j'ai décidé d'attribuer un vrai nom de domaine (www.jeromeradix.com) à mon blog ici présent (jradix.blogspot.com). Mal m'en a pris ! J'avais naïvement cru que tout cela se passerait sans douleur, c'est tout l'inverse qui se passa.

Ce blog étant porté (à la date de ce billet) par blogger.com, je profite automatiquement d'un système de consolidation des autorisations pour l'identifiant OpenID du blog : http://jradix.blogspot.com/

J'ai utilisé cet identifiant OpenID dans de nombreux sites web. Résultat : tous ces sites Web me connaissent en tant que jradix.blogspot.com, pas en tant que jeromeradix.com ! Quand j'ai associé mon nouveau nom de domaine à mon blog, j'ai n'ai plus eu aucune possibilité de me connecter sur tous les sites utilisant mon OpenID jradix.blogspot.com.

Le seul moyen de retrouver mes comptes sur les sites Web est donc de passer par ce processus très fastidieux :

remettre mon blog sur jradix.blogspot.com
me connecter en OpenID jradix.blogspot.com sur le site Web duquel je veux changer/ajouter l'openID jeromeradix.com
une fois connecté, je remets mon blog sur jeromeradix.com
je demande ensuite au site de modifier l'OpenID de mon compte (ou ajouter un nouvel OpenID) pour utiliser jeromeradix.com
le site me demande alors de saisir le nouvel OpenID du compte (jeromeradix.com) et essaye d'authentifier cet ID
je suis redirigé sur la page blogger.com d'autorisation d'accès au site pour mon OpenID jeromeradix.com
le site met alors à jour l'OpenID du compte dans sa base de données.

On voit bien ici, les limites d'un tel processus. Si vous avez une centaine de sites Web sur lesquels vous avez un compte associé à votre OpenID, il va falloir aller sur chacun de ces sites et recommencer l'opération.

Heureusement, je n'ai pas un grand nombre de comptes protégés par OpenID, utilisant plutôt Keepass pour générer/stocker mes mots de passe. Keepass limite le risque de se faire voler ses comptes car vous pouvez avoir un mot de passe fort différent pour chaque compte. Si un de vos comptes est compromis pour je ne sais quelle raison (malveillance interne au site Web suite à la démission d'un prestataire furieux, ... ces choses arrivent plus souvent qu'on ne veut bien le croire ! regardez Wikileaks...) seul ce compte est perdu, les autres restent sécurisés car ils n'ont pas le même mot de passe.

Avec OpenID, vous centralisez l'accès à tous vos comptes sur tous vos sites Web. Si par malheur, votre compte OpenID est perdu, vous perdez tous vos comptes sur tous les sites en même temps. Tout cela sans parler du risque de Phishing inhérent à OpenID, ou de la nécessité impérieuse aujourd'hui de réduire votre dépendance et promouvoir votre indépendance...

Pour celui qui veut encore utiliser OpenID, de bonnes pratiques s'imposent donc à lui malgré tout :

- Définir un ID OpenID sur son propre nom de domaine : cela veut dire acheter un nom de domaine et héberger une page contenant deux balises <link> dans le <head> :

<link rel="openid.server" href="http://www.blogger.com/openid-server.g"></link>
<link rel="openid.delegate" href="http://jradix.blogspot.com/"></link>

La première ligne indique le serveur dans lequel vous stocker vos autorisations OpenID (pour moi, c'est le serveur blogger.com). La deuxième ligne indique quel est le compte OpenID sur ce serveur d'autorisations qui doit être utilisé pour représenter par délégation votre OpenID. J'ai mis ça dans la page correspondant à www.jeromeradix.com.

- S'enregistrer sur tous les sites Web avec l'OpenID correspondant à votre nom de domaine : pour moi, je me connecte maintenant avec l'OpenID : http://www.jeromeradix.com/

Ainsi, grâce à ça, vous n'êtes plus dépendant de votre fournisseur de service OpenId, ni de l'hébergeur de votre site Web. Vous pouvez très bien changer les deux et toujours retrouver vos comptes sur les différents sites sur lesquels vous vous êtes enregistré en OpenID.

Pour plus d'information, consulter la page Using your own URL as your OpenID.

La leçon de tout ça, est de savoir de qui vos comptes dépendent : de votre fournisseur de nom de domaine ? de l'hébergeur de votre site Web ? du service OpenId qui héberge vos autorisations ? de votre carte de crédit qui a déjà expirée et qui est pourtant la seule qui est enregistrée chez votre fournisseur de nom de domaine ?

A peser le pour et le contre, je pense que je vais préférer gérer mon compte/mot de passes avec Keepass et me faire personnellement des backups comme nous décrit très bien jwz.

A noter aussi que des doutes et des abandons apparaissent aussi chez les promoteurs de la première heure de l'OpenID.

Comment créer un flux RSS à partir de n'importe quelle page Web

2011-01-29T05:24:00.000-08:00

Le service StackOverflow.com a cela de magnifique qu'il permet de faire émerger de l'ensemble vague et indistinct des interrogations que se posent les informaticiens entre eux, les meilleurs questions et les meilleures réponses à celles-ci. Nombreuses sont, pourtant les questions sans intérêts ou trop particulières pour être bénéfique aux lecteurs curieux. La plupart du temps ces questions trouvent leur réponse dans les manuels de référence en ligne de chaque outil. Un simple RTFM suffirait, mais, bonté de la nature humaine, des âmes charitables prennent le temps de former les nouveaux venus à l'informatique. C'est aussi et surtout pour faire monter leur compteur de réputation. Ce n'est pas un mal en soi de pouvoir conjuguer vanité des uns et ignorance des autres et qu'en jaillisse une vérité.

Tous les sujets imaginables sont abordés, il faut donc s'exercer à rechercher finement ce qui est intéressant pour soi-même sans être submergé par des questions qui ne nous concerne pas. L'outil de recherche de stackoverflow est puissant, il permet de faire une recherche par tag (en saisissant [python] par exemple), de ne choisir que les questions qui ont un nombre de votes supérieur à une valeur (par exemple vote:5), etc. La FAQ sur les options de recherche est ici la bienvenue.

Pour pouvoir m'instruire à parler couramment le python, j'ai entrepris de consulter régulièrement les meilleurs questions et réponses concernant ce langage. Pour ce faire, stackoverflow.com ne permettant pas d'avoir de flux RSS correspondant à une recherche particulière, je me suis construit mon propre flux RSS grâce à l'outil en ligne feed43.com. Ce service permet de récupérer le code source d'une page web et d'en extraire du contenu grâce à des modèles de correspondance (matching patterns). On peut ensuite mettre en forme ce contenu dans un flux RSS qu'on pourra réutiliser dans n'importe quel lecteur de flux RSS. Feed43.com va régulièrement consulter la page Web en question et va mettre à jour le flux RSS en conséquence. Et voilà, on a donc les moyens de créer des flux RSS pour n'importe quelle page/service du web qui n'en propose pas.

Par exemple, je me suis créé un flux RSS rassemblant de bonnes questions (votes >= 5) sur python ([python]) ayant une réponse acceptée par l'auteur de la question (hasaccepted:1) et n'étant pas fermée pour diverses causes (closed:0). Dans feed43.com, j'ai configuré le flux de cette manière :
Je peux maintenant avoir dans mon lecteur de flux RSS préféré, les meilleures questions python avec réponse.

Grâce à feed43 je me suis constitué quelques flux RSS à partir de sites web qui n'en proposent pas, notamment pour analyser des résultats de recherche sur pajemploi (pour avoir les changements dans les salaires minimum en vigueur), sur ZDnet (pour n'avoir que les news Open Source)... Ce service est bien sûr dépendant des modifications des pages consultés : votre flux ne marchera plus si les pages scrutés ont été refondues.

Comment s'arrêter en plein milieu d'une installation Linux Gentoo

2011-01-22T11:21:00.001-08:00

Malgré les aléas que j'ai eu à subir dans le passé avec Gentoo, je me suis mis en tête de lui redonner encore sa chance avec un autre de mes vieux PC, un ordinateur portable Turion64 / 512 Mo de mémoire.

M'étant converti à cette nouvelle religion qu'on appelle Python, j'apprécie d'autant plus Gentoo Portage, système de gestion de paquets codé en ce langage.

Le manuel Gentoo est complet et décrit chaque étape de l'installation. Il n'y a pas d'installateur ("installer" pour les anglicisants) proprement dit comme on peut avoir l'habitude sur les autres distributions Linux ou *BSD : chaque étape est manuelle. On amorce ("boot") l'ordinateur sur un CDROM Gentoo minimal, et grâce aux quelques commandes de base disponibles, on installe petit à petit des partitions, des systèmes de fichiers, le réseau, le système portage...

Chaque étape est manuelle, ça à l'avantage de permettre une configuration personnalisée pour chaque élément du système. De plus, on apprend beaucoup plus facilement à repérer ce qui constitue votre système et où sont placés les principaux fichiers de configuration.

Un désavantage de cette méthode c'est que vous ne pouvez pas lancer l'installation et attendre que ça se finisse complètement à la fin. Vous devez passer par chaque étape manuellement. Pour réaliser une installation propre de Gentoo, en prenant en compte le temps qu'il vous faut pour adapter la configuration à vos besoins et votre ordinateur, il vous faudra environ une demi-journée. Et puisque rien n'est automatisé, soit vous faites l'installation de bout en bout, soit vous êtes contraints pour les autres aspects de votre vie (vie familiale, besoins naturels...) de cesser toute activité. Dans ce dernier cas, je conseille de faire au moins toutes les étapes jusqu'au changement de la racine du système ("chroot").

Après ça, vous pouvez vous arrêter quand bon vous semble et arrêter votre ordinateur, par un "halt" ou un "reboot" par exemple. Quand vous voudrez continuer votre installation, vous n'aurez plus qu'à amorcer sur le CD, et réaliser les quelques opérations suivantes :

# Montez toutes les partitions de votre nouveau
# système sur les répertoires adéquats, par exemple :
mount /dev/hda5 /mnt/gentoo
mount /dev/hda7 /mnt/gentoo/var
mount /dev/hda8 /mnt/gentoo/tmp
mount /dev/hda9 /mnt/gentoo/usr
mount /dev/hda10 /mnt/gentoo/home

# Activez le swap sur la partition de swap de votre
# nouveau système
swapon /dev/hda6

# Montez les répertoires proc et dev
mount -t proc none /mnt/gentoo/proc
mount -o bind /dev /mnt/gentoo/dev

# Changer la racine du système en cours
chroot /mnt/gentoo /bin/bash
env-update
source /etc/profile
export PS1="(chroot) $PS1"

Et voilà, vous pouvez maintenant reprendre le cours de votre installation manuelle Gentoo là où vous l'aviez laissée avant d'arrêter votre ordinateur.

Le langage de programmation le plus en vogue en 2010

2011-01-20T07:23:00.000-08:00

Il semblerait que je sois un être moyen puisque je suis la tendance au plus près : il y a quelques mois, je passais de mon langage favori, Perl, à un nouveau language favori : Python. Il s'avère que nombreux sont ceux qui font ce même chemin. C'est notamment ce que montre l'index TIOBE des languages les plus utilisés dans le monde. TIOBE vient d'attribuer une distinction à Python : Meilleur langage de 2010 :

En effet, Python est le langage qui, en 2010, a le plus progressé en terme de nombre d'utilisateurs et de part de marché. Il est même passé devant C#. On peut noter que PHP est juste au dessus mais est plutôt dans une tendance baissière. Les personnes à TIOBE note bien que ce sont beaucoup de mongeurs de perl qui se sont converti à Python :

"Python est devenu le standard "de facto" pour le scripting système (étant en cela, un successeur de Perl), mais il est utilisé pour beaucoup plus de types d'application différents aujourd'hui. [...] Comme Python est facile à apprendre, de plus en plus d'universités utilisent Python pour enseigner les languages de programmation"

Un greffon de recherche Firefox pour les manuels Linux

2011-01-19T00:46:00.000-08:00

N'ayant pas trouvé de greffon Firefox de recherche intéressant sur les manuels Linux, je me suis construit le greffon linux-die-net.xml suivant à mettre dans C:\Program Files\Mozilla Firefox\searchplugins :

<SearchPlugin xmlns="http://www.mozilla.org/2006/browser/search/">
<ShortName>Linux Manuals</ShortName>
<Description>Linux Manuals on linux.die.net</Description>
<InputEncoding>UTF-8</InputEncoding>
<Url type="text/html" method="GET" template="http://www.die.net/search/">
<Param name="q" value="{searchTerms}"/>
<Param name="sa" value="Search"/>
<Param name="ie" value="UTF-8"/>
<Param name="cx" value="partner-pub-5823754184406795%3A54htp1rtx5u"/>
<Param name="cof" value="FORID%3A9"/>
<Param name="siteurl" value="www.die.net%2Fsearch%2F#914"/>
</Url>
<SearchForm>http://linux.die.net/</SearchForm>
</SearchPlugin>

Relancer Firefox et il doit maintenant être disponible dans votre liste des moteurs de recherche.

Closures - Partie 1

2010-12-09T06:47:00.000-08:00

Alors que certains langages se posent encore des questions existentielles sur l'incorporation ou pas (et à quelle date) de closures, cette capacité d'un langage de haut niveau est largement déployée au sein des langages dits dynamiques (moins péjoratif que langage 'script'), sans parler des langages fonctionnels pour lesquels les closures sont aussi naturelles que les fonctions d'ordre supérieur.

Sur le Web, il n'est pas rare de voir des exemples explicatifs de ce que sont les closures, mais plus rarement des exemples d'application des closures à des cas concrets. Je vais, dans plusieurs billets de ce blog, essayer de vous fournir un aperçu de cas concrets où l'utilisation des closures est intéressante.

Avant de commencer, il est bien sur nécessaire de clarifier ce qu'on entend par closure.

Au départ étaient les mathématiques et tout était clair et non-ambigüe. Ils donnèrent au nom de 'fermeture' (closure)une définition algébrique : Un ensemble d'éléments est dit fermé (closed) sous une certaine opération si l'application de cette opération aux éléments de l'ensemble produit un élément qui est encore un élément de l'ensemble.

Puis vinrent les informaticiens qui par leur nature fainéante, firent des raccourcis honteux : la communauté Lisp employa le mot closure pour décrire un concept complètement différent : une closure est une technique d'implémentation pour représenter des procédures ayant des variables libres.

De cette non-conformité au concept mathématique provient une partie de l'incompréhension qu'ont la plupart des programmeurs de base. Et puisqu'il faut rester concret quand on fait de l'informatique, voici l'exemple de base pour créer une closure, qu'on retrouve dans tous les articles d'introduction. L'exemple est en Python 2.7 :

def multiplier(nb):
   def multi(value):
       return value * nb
   return multi

Ici, multi est la closure, multiplier est la fonction fabricant la closure. La plupart du temps, il s'agit d'encapsuler dans une fonction la création de la closure. La closure dispose alors des variables locales de la fonction dans laquelle elle a été créée. On peut appeler multiplier, l'usine à closures ('closure factory').

On peut utiliser cette closure de cette façon :

>>> multi10 = multiplier(10)
>>> multi10(2)
20

C'est un peut comme si on appelait l'usine à fabriquer des closures pour configurer au moment de l'exécution (runtime) une fonction particulière et d'en produire donc de toute sorte.

Comme il s'agit ici d'encloisonner des variables dans un scope particulier à la closure, on peut très bien définir le même comportement en utilisant la notion de classe classique. L'exemple ci-dessous converti en classe donne :

class MultiplierFactory:
   def __init__(self, nb):
       self.nb = nb
   def multiply(self, value):
       return self.nb * value

>>> multi10 = MultiplierFactory(10).multiply
>>> multi10(2)
20

C'est une façon de créer des pseudo-classes anonymes, sachant qu'une classe ne sert qu'à gérer la 'globalité' de certaines variables. Pour continuer le parallèle entre une closure et une classe, il va être possible, de façon beaucoup plus succincte d'exprimer des modèles de conception comportementaux en closure.

Une closure n'est pas simplement une fonction anonyme qu'on se passe de variable en variable. Pour réellement parler de closure, il faut qu'il y ait en jeu des variables libres telles que nb dans l'exemple précédent.

A noter aussi qu'une closure ne s'exécute qu'au dernier moment, lors de son appel explicite. La configuration de la fonction n'a pas nécessité de faire fonctionner du code source de cette fonction.

C'est par exemple, intéressant quand on veut programmer par évènements et appels en retour (callbacks). Par exemple, sans closure, on pourrait essayer de coder quelque chose comme ça, mais ce code ne peut pas marcher :

from threading import Timer

def show_message(msg):
   print msg

def set_alarm(msg, timeout):
   Timer(timeout, show_message(msg))

>>> set_alarm("Réveille Toi !", 3)
Réveille Toi !    ---> s'affiche instantanément

En effet, Timer(timeout, show_message(msg)) va appeler show_message(msg) avant d'appeler Timer. Timer va donc être appelé avec le résultat de l'appel à show_message(msg), ce qui n'est pas ce que l'on veut. Par contre, avec une closure, on peut écrire le code de cette manière :

from threading import Timer

def set_alarm(msg, timeout):
   def show_message():
       print msg
   t = Timer(timeout, show_message)
   t.start()

>>> set_alarm("Réveille Toi !", 3)

Au bout de 3 secondes on a :
>>> Réveille Toi !

Ce bout de code permet d'éviter l'emploi d'une variable globale msg, qu'il serait alors difficile de maintenir cohérente dans un environnement multithread par exemple.

Python en remplaçant de Perl

2010-12-02T02:56:00.000-08:00

Je me suis mis récemment au langage python. J'avais des préjugés sur ce langage au moment où j'ai entendu dire qu'il fallait respecter la tabulation pour que le programme fonctionne. Je voyais là le signe d'un langage complètement arriéré, digne des plus beaux langages de grand papa, notamment COBOL qui obligeait à respecter la tabulation, la taille des lignes, des sections particulières...

Comment ce fait-il que des gens aient choisi un tel retour en arrière pour créer ce langage ? En fait, il s'agit surtout d'une incompréhension. La tabulation en elle-même peut être celle que l'on souhaite mais la tabulation sert à définir le début et la fin des blocs de lignes de codes. C'est en fait un moyen astucieux de définir des blocs sans avoir à utiliser de symbole particulier comme { } par exemple :

def fib(n):    # write Fibonacci series up to n
 """Print a Fibonacci series up to n."""
 a, b = 0, 1
 while a < n:
     print a,
     a, b = b, a+b

Moins je tape de caractère, mieux je me porte. C'est un principe fondamental de la programmation : le meilleur programme c'est celui qui n'a pas de ligne de code.

Après m'être auto-formé à python, je me suis aperçu que python est aussi souple que mon autre langage de prédilection : Perl. Python comme Perl, centralise les packages disponibles au sein d'un même répertoire appelé PyPI. Sous Perl, c'est le répertoire CPAN.

La différence philosophique entre Perl et Python se situe au niveau des slogans qu'ils utilisent : Perl a choisi le TMTOWTDI (There's more than one way to do it) tandis que Python, justement, est parti sur le slogan "There should not be more than one way to do it". Et finalement, sur le long terme, c'est payant pour Python. Le langage Python reste simple et évite toutes les tortures mentales introduites par Perl. Cela permet à plusieurs programmeurs de travailler sur un même code, la maintenance est facilitée. De plus, quand vous arrêté de faire du perl, ne serait-ce que 6 mois par exemple, vous perdez la connaissance que vous avez des bricolages possibles de Perl, et les détails commencent à vous échapper.

Perl est bien si vous en fait régulièrement, que vos programmes n'ont pas besoin d'une architecture orienté-objet (bien qu'il soit possible de faire de l'orienté-objet avec du Perl, mais c'est vraiment une horreur à écrire).

Perl, par toutes ses particularités et ses bricolages, a permis la constitution d'une communauté soudée, car assez élitiste finalement, Elite dans le sens de : qui maitrise tous les aspects de perl.

Je crois que je vais définitivement arrêter de coder en Perl mes programmes, et passer sur Python parce que je n'ai plus le temps de réapprendre les tortures mentales nécessaire à la programmation en Perl.

Hypocrisie et gestion de projet

2010-11-29T05:46:00.000-08:00

Quel est le plus vieux métier du monde ?

Non, ce n'est pas péripatéticien, c'est le métier de chef de projet. Depuis la nuit des temps, l'Homme a souhaité une vie meilleure, a projeté son être vers un avenir plus radieux, a ambitionné de créer ce qui n'existe pas encore.

Sous un qualificatif pompeux (tout le monde veut être chef à la place du chef aujourd'hui) se cache le métier le plus ingrat qui soit quand on borne sa définition à ce qui se fait dans une société de service par exemple.

En effet, l'intérêt d'un projet est de profiter des biens faits produits par ce projet, soit de façon directe (utilisation des produits et services), soit de façon indirecte (gagner de l'argent sur les bénéfices offerts par les produits du projet)

Un autre intérêt est l'estime de soi, une certaine fierté d'avoir réussi à produire quelque chose de nouveau dans ce monde. Les personnes dont l'égo est habitué à recevoir de tels émoluments seront satisfaites par le simple fait d'avoir terminé un projet.

Dans beaucoup de sociétés, notamment les sociétés de service, chef de projet n'est pas un grade, mais une fonction, au même niveau que développeur débutant, architecte ou expert d'un domaine.

Par définition, un chef de projet est responsable de tout. S'il ne respecte pas ses engagements initiaux, il sera tenu pour responsable et souffrira des conséquences. S'il réussi son projet en temps et en coût, aucun remerciement, aucune gratitude ne sera offert au chef de projet victorieux.

Nombreux sont ceux qui, informaticiens à la base, se dirigent vers la gestion de projet, très souvent leurrés par la dénomination de "chef" quand il faut lire "gestionnaire". L'emprunt d'une telle carrière par une personne de culture scientifique comme l'est l'informaticien peut être semé d'embuches, de désillusions et de déconvenues.

Dans toute société, l'hypocrisie est au cœur du système pour fluidifier, apaiser, permettre les relations interpersonnelles. Ce n'est pas forcément une mauvaise chose que les gens ne disent pas toutes les vérités à tout le monde. Si nous vivions dans un monde sans hypocrisie, le chaos ne serait jamais très loin car plus de rêve ne serait possible, tout le monde serait ramené immédiatement à la raison triomphante, froide, inhumaine.

Dans ce monde du double langage, il est donc important de rappeler quelques règles à suivre quand on est en face de comportements hypocrites, pour que la vérité apparaisse, sans froisser les égos et rompre les communications.

L'article Hypocrisy in Project Management de l'équipe Project Perfect en Australie, analyse justement cette hypocrisie inhérente à toute activité commerciale, donc humaine.

iPad versus le Livre

2010-05-28T00:00:00.000-07:00

Que faudrait-il pour que je me mette à lire la majorité de mes livres sur un iPad ?

Les qualités d'un livre sur papier sont nombreuses :

Ultra-résistant : je peux le jeter contre les murs (ça peut arriver si l'auteur méprise le lecteur que je suis), je peux l'emmener à la plage le laisser dans le sable en plein soleil, le tordre dans tous les sens. Le livre a aussi l'avantage de ne jamais tomber en panne et est relativement résistant sur le long terme.

J'ai dans ma bibliothèque le livre Sainte Jeanne de Georges Bernard Shaw. C'est un livre ancien tel qu'on peut maintenant facilement les acheter sur des sites web comme chapitre.com ou abebooks.fr. Ce livre date de 1932 et est toujours aussi lisible qu'à l'époque de son impression. Chez mes parents, j'ai trouvé des livres de poche des années 1960 qui sont, certes, en moins bon état que le "Sainte Jeanne" mais tout aussi lisible.

ultra-pratique : ne tombe jamais en panne, n'a pas besoin de pile ou de batterie, je peux passer à n'importe quelle page en un seul et très léger mouvement de doigts. Je peux marquer les pages qui m'intéressent, je peux gribouiller, écrire dessus ou souligner des lignes. Je peux offrir cet objet réel qu'est le livre à une personne et y apposer un petit mot.

ultra-plaisant : je peux lire un livre pendant des heures, voire des jours entiers sans avoir mal aux yeux, que ça soit en plein jour et plein soleil ou la nuit, à la lumière d'une lampe de chevet. Un livre de poche pèse dans les 300g je peux le tenir à bout de bras dans tous les sens, il permet une bonne prise en main.

très peu cher : un livre de poche ou un livre de taille moyenne est très peu cher. Je peux prêter mon livre à tout ceux que je connais sans qu'ils aient besoin de quoique ce soit. Je peux même revendre mon livre sur amazon ou ebay et rendre ce livre encore moins cher à l'utilisation. Je peux relire le livre autant de fois que je le désire. Je n'ai pas de problème d'obsolescence technologique, je peux donc garder mon livre jusqu'à la fin de ma vie sans avoir peur de ne plus pouvoir le lire.

Si on met en parallèle tous ces avantages, est-ce que l'iPad tiens la comparaison ?

résistance : bien que conçu pour être un appareil électronique portable, l'iPad n'est pas conçu comme un PC durci (rugged computer) aux normes militaires par exemple. Je ne vous conseille pas de laisser votre iPad en plein soleil toute une journée sur la plage dans le sable ou encore moins de le laisser tomber régulièrement de vos mains.

pratique : les batteries de l'iPad, comme toutes les batteries, finiront par s'user et devront être changée, pour un prix élevé bien sur (car l'utilisateur ne peut pas changer lui même les batteries). Qui dit pile, dit rechargement. Bien qu'il ait une bonne autonomie, (on parle de 10 heures de vidéo ou 140 heures d'audio), c'est toujours très court par rapport à un livre qui a une autonomie aussi longue ... que votre vie !

plaisir : j'ai beau avoir essayer tous types d'écrans, quand il s'agit de lire pendant des heures, d'être plongé dans un récit et de ne pas en décrocher, le seul moyen viable est l'utilisation d'un écran non rétro-éclairé. L'éclairage d'un écran, bien que pratique pour l'informatique générale ne permet pas une lecture longue d'un texte. Je peux passer toute ma journée à travailler sur écran, mais l'activité de lecture est différente, elle nécessite de se concentrer sur un espace réduit d'un écran et de faire défiler ses yeux sur des caractères et ce, dans la durée. Lire sur du papier est bien plus plaisant que lire sur un écran rétro-éclairé.

Sur ordinateur, je suis parfois amené à lire de long passages de texte ardus comme des lignes de codes. Je le fais sur un éditeur configuré pour afficher le texte en blanc sur noir, ou plutôt, en saumon clair sur vert foncé. Ce sont les couleurs les plus agréables que j'ai pu trouver pour coder pendant des longues heures. Je ne suis pas sure que l'iPad propose de configurer complètement l'apparence du texte sachant qu'iBookstore contiendra des livres des éditeurs classiques sur papier et que ces derniers imposeront l'apparence de leurs livres.

prix : Le modèle économique de l'Apple iPad :

- justifier un prix élevé du produit (il va coûter dans les 500 euros en France) grâce à une marque forte qui flatte l'acheteur (un des ressorts du luxe)

- mettre une taxe à chaque utilisation du produit pour lire un livre, le prêter, etc. La taxe doit être suffisamment faible pour être indolore pour le client. Mais la taxe doit être à tous les niveaux.

Je n'ai pour le moment pas trouvé beaucoup de livres sur l'iBookstore mais ça peut s'arranger avec le temps. Je n'ai vu que des livres gratuits où valant 0,99$ :

Alice au pays des merveilles

Twilight

Je ne pense pas que ça soit le prix de base des livres de qualités qui pourront être mis dans l'iPad. Les éditeurs pourront faire des économies de papier, mais pas de distribution : au lieu que ce soit les distributeurs traditionnels qui se sucrent sur les prix des livres, ce sera Apple. Un livre de poche aujourd'hui vaut entre 2 et 7 euros. La différence ne sera jamais très grande entre le prix d'un livre sur iPad et le prix d'un livre papier.

De plus, comment faire pour prêter un livre sous iPad ? et comment revendre un livre ?

En bref : l'iPad est moins intéressant sur toutes les caractéristiques d'un livre papier. Mais il y a quand même des éléments intéressants pour certaines personnes (pas moi, malheureusement) :

Avec un iPad, vous pouvez lire dans le noir complet, vu que c'est rétro-éclairé. Personnellement, je me vois mal lire dans le noir complet.

Avec l'iPad vous pouvez avoir pleins de livres sous la main, disponibles en 1 seul clic. Personnellement, je ne lis au maximum que 2 ou 3 livres en parallèle, et les mettre dans un sac n'est pas un surpoids énorme quand je pars en voyage. En général je ne lis qu'un livre à la fois. L'argument comme quoi on a plus besoin d'avoir une énorme bibliothèque chez soi ne me convainc pas : avoir une bibliothèque ne me gène pas, cela me permet de revoir en quelques coups d'œil l'ensemble de me livres.

Avec l'iPad, il est beaucoup moins cher d'avoir des livres en couleur. Cela est intéressant quand on veut lire des bandes dessinées. Mais quand il s'agit de "beaux livres" d'art, une reproduction sur papier est bien plus belle et précise qu'une reproduction sur un écran rétro-éclairé.

Pour que l'iPad devienne plus intéressant face aux livres, il faudrait :

mettre suffisamment de cellules photovoltaïques pour permettre de fonctionner sans batteries... mais ça semble assez difficile vu la taille de l'objet.

durcir l'objet aux normes militaires : avec de telles normes, on a plus du tout peur de casser ou d'emporter son iPad n'importe où.

permettre des hyperliens directs vers toutes les références citées. Mais là encore, si tout est payant dans le monde iPad, sauter de référence en référence signifie sauter de livre en livre, donc de taxe en taxe. On n'est plus dans un modèle gratuit du web mais dans un modèle de contenu payant. ça peut être intéressant pour des chercheurs, ou autres étudiants, mais pas pour le lecteur de base que je suis.

permettre un modèle économique similaire au livre : achat / prêt / revente.

A noter aussi que l'iPad n'est en rien une nouveauté, et qu'il existe de nombreux concurrents : on se demande d'ailleurs ce que fait le CSA car tous les médias parlent d'Apple comme si c'était un phénomène unique, alors que de nombreuses autres marques existent. Je pensais qu'il était interdit de citer des marques pendant les émissions ?

Règles pour le Codage

2010-04-09T13:29:00.000-07:00

Ce que je trouve très intéressant dans un livre technique c'est quand celui-ci liste explicitement de "bonnes pratiques" que l'on sent sortir tout droit de l'expérience de l'écrivain.

L'œuvre majeure dans ce domaine est bien sur Code Complete 2 mais je suis tombé sur une page Web contenant une liste très intéressante, tirée du livre Programming Pearls.

Il s'agit de l'Annexe 4 : Rule for Coding qui est une retranscription d'une liste que l'auteur, Jon Bentley, avait constitué en 1982 dans son livre "Writing Efficient Programs". Oui, 1982 !!! et toutes ces pratiques sont toujours valides. Qui peut se targuer d'une telle longévité de ses conseils en matière informatique ?

Quand vous lirez ces règles, vous vous direz certainement que c'est évident, que vous mettez déjà en pratique ce genre d'heuristiques programmatoires. Oui, mais Jon Bentley a réussi à mettre des noms aux activités que nous menons tous les jours quand nous programmons. Comme dirait le poète, une chose n'existe pas si elle n'a pas de nom. Mettre des noms à tous les aspects de l'activité de programmation sert à faire reconnaitre le véritable travail qui est effectué. Sans cela, la programmation, pour le non-informaticien reste du ressort de la magie.

Aujourd'hui, 2010, le problème n'est plus vraiment de ressortir toutes ces "bonnes pratiques", toutes ces règles. La difficulté réside dans l'application systématique de ces règles. Comment faire pour que tous les programmeurs d'un projet de développement logiciel connaissent, utilisent, appliquent toutes ces règles de façon exhaustive ? Comment, au niveau de l'activité d'assurance qualité, vérifier l'application complète de ces règles pour l'ensemble de code concerné sans devenir un tortionnaire envers ceux qui programment ?

La programmation se base sur le mécanisme d'abstraction pour permettre de construire des systèmes complexes et gérables par des êtres humains. Or le revers de la médaille "abstraction" est le fait que chaque programmeur peut cacher l'implémentation d'une fonction sous des aspects de code fonctionnant correctement.

Le meilleur moyen pour qu'un programmeur mette en œuvre les règles et les bonnes pratiques est de lui fournir des outils lui permettant de tester par lui-même la qualité de son code. Car, comme l'optimisation est la cause de tout mal en se bas-monde, il faut optimiser, et donc essayer d'appliquer les règles explicitement que si on constate un problème de performance. Il est donc utile de repérer dès la conception de l'architecture les points clés dont dépendent les performances attendue. La qualité de tous ces points clés doit être soigneusement vérifiée.

Ainsi, lors de la façon de définition de l'architecture, il faut non seulement définir les éléments statiques, dynamique et l'allocation des ressources matérielle, mais en plus, identifier les éléments critiques en terme de performance.

Ecran mat ou brillant ?

2010-03-17T01:58:00.001-07:00

Je me suis toujours demandé pour quelle raison la tendance actuelle est de vendre des écrans brillants plutôt que des écrans mats. Les écrans brillants reflètent toutes les sources de lumière et rend très désagréable le travail sous des néons (cas très courant faut-il le rappeler).

Je ne suis pas sure que le coût soit véritablement différent à la production entre un écran brillant et un écran mat. Peut-être que les gens achètent plus des écrans brillants parce que "ça en jette". Personnellement, autour de moi, la plupart des personnes préfèrent des écrans mats.

C'est d'ailleurs aussi la préférence de AnandTech dans leur revue du Netbook Asus Eee PC 1001P :

"The screen also has a matte finish, thankfully one of the few computers to forego the trend of featuring a glossy screen." (L'écran a aussi une finition mate, heureusement l'un des rares ordinateurs à renoncer à la tendance à faire figurer des écrans brillants).

Ce nouveau Eee PC a un écran vraiment incroyable à en croire les performances mesurées :

Assurément un des meilleurs netbook du moment...

Microsoft, l'anti-pattern économique

2010-02-17T18:10:00.001-08:00

A tout ceux qui voit en Microsoft un exemple à suivre, un modèle d'entreprise, à tout ceux qui croit que Microsoft a des clients parce qu'il a de bons produits, je recommande la lecture de deux graphiques :

Où on apprend entre autres choses le coût d'achat d'un point de marché des moteurs de recherche (bing) : 667 millions de $ et que perdre 2 milliards de $ par an pour un produit qui ne marche pas n'est pas un problème pour Microsoft.

Quand Microsoft génère autant d'argent de son Trust Windows/Office, il plonge allégrement dans l'irréalisme économique. Microsoft semble vraiment incapable de faire du business rentable sur internet.

Déplacement de code invariant de boucle

2010-01-16T00:13:00.000-08:00

L’optimisation de code est un vaste sujet, car il s’agit plus d’un art que d’une théorie axiomisée. Elle n’est que la conséquence des limitations auxquelles sont confrontés les informaticiens.

Il est bien connu que l’optimisation prématurée est la source de tous les malheurs, mais il est quand même recommandé de connaître les limites des outils et langages que l’on utilise pour pouvoir coder juste au premier coup.

Avec les RIA, ils est maintenant nécessaire d’écrire des portions de code relativement importantes en Javascript alors que ce langage n’était prévu à l’origine que pour dynamiser un peu les pages Web statiques.

Javascript n’a pas été conçu pour réaliser des optimisations de code en amont de son exécution comme pourrait le faire un compilateur C ou Java. Une des optimisations à faire absolument est le déplacement du code invariant de boucle (« Loop-invariant code motion »).

Par exemple si vous avez du code comme ça :

for (i = 0; i < n; ++i) {
  x = y + z;
  a[i] = 6 * i + x * x;
}

Alors il vaut mieux le réécrire comme ci-dessous sous peine de laisser l’interpréteur Javascript recalculer à chaque itération des valeurs invariantes :

x = y + z;
t1 = x * x;
for (i = 0; i < n; ++i) {
  a[i] = 6 * i + t1;
}

Ce genre d’optimisation est généralement bien réalisé par les compilateurs C ou Java mais Javascript n’a pas ce genre d’intelligence. Le déplacement de code invariant de boucle est une des optimisations préconisées par Jon Bentley dans Programming Pearls, livre O combien recommandé dans ce domaine.

Répertoire de sons pour vos homebrew...

2010-01-11T08:24:00.000-08:00

Je surfais par hasard sur la toile, à la recherche de sons gratuitement réutilisable pour une création multimedia sur Nintendo DS.

Je suis tombé sur ce répertoire de liens vers des sites collection de sons divers et variés.

C'est un bon point de départ pour ceux qui font du homebrew sur Nintendo DS ou autre, et qui cherche des sons réutilisable sans frais.

Quelle est votre opinion la plus controversée sur la programmation ?

2009-10-30T07:13:00.000-07:00

Je me baladais l’autre jour sur stackoverflow.com, le site de questions/réponses de Jeff Atwood que tout le monde attendait (vu le nombre de questions et réponses déjà présentes sur le site). Il y a toujours des questions qui cherchent à polémiquer, à créer des controverses, à relancer des guerres maintes fois débattues (la guerre des éditeurs, des OS…).

Je suis tombé par hasard sur cette question : Quelle est votre opinion la plus controversée sur la programmation ? Autant dire que ça doit inspirer pas mal de monde… et en effet, des pages et des pages d’opinions les plus diverses sont reliées à cette question.

Plusieurs opinions m’ont paru intéressantes, voici traduit en français celles de la première page, donc celles les plus intéressantes, puisque c’est l’objectif de stackoverflow.com de faire remonter le plus en haut les meilleures réponses aux questions :

La seule “bonne pratique” que vous devez utiliser tout le temps est “Utilisez votre cerveau”.

Les programmeurs qui ne codent pas pendant leur temps libre pour s’amuser ne deviendront jamais aussi bon que ceux qui le font.

La plupart des commentaires dans le code sont en fait une forme pernicieuse de duplication de code.

Les programmeurs ne sont pas tous nés égaux.

XML est très surfait.

“Trouver sur google” (googling) est bien.

Je n’arrive pas à comprendre pourquoi les gens pensent que Java est absolument le meilleur langage de programmation à enseigner en université

Si vous ne connaissez qu’un seul langage, quel que soit le niveau de connaissance de celui-ci, vous n’êtes pas un bon programmeur

La performance compte.

Les instructions “print” sont une manière valide de débugguer du code.

Les “Getters” et les “Setters” sont bien trop utilisés

SQL est du code. Traîtez-le comme tel.

Votre travail est de vous mettre au chômage.

Si vous êtes un développeur, vous devez être capable d’écrire du code.

La lisibilité est la chose la plus importante de votre code

Les diagrammes UML sont très surfaits.

L’utilisation de la notation hongroise doit être punie par la mort

Les modèles de conception font plus de mal à une bonne conception qu’ils ne l’aident effectivement.

Les tests unitaires ne vous aideront pas à écrire du bon code.

Ecrivez des méthodes courtes.

C’est acceptable d’écrire du code jetable de temps en temps.

Moins de code est mieux que plus de code.

PHP craint ;-)

Code == Conception

Il n’y a rien de mal à mettre des binaires dans le système de contrôle de code source.

Le développement logiciel n’est qu’un job.

Chaque développeur doit être familiarisé avec l’architecture des ordinateurs modernes

Les architectes / concepteurs de logiciels sont très surfaits.

Il n’y a pas d’approche « taille unique pour tout le monde » du développement.

Et ce n’est que la première page ! C’est du même acabit pendant 13 pages. On peut noter les autres opinions suivantes qui ont le mérite de provoquer aussi la controverse et force à réfléchir sur la futilité ou l’utilité de nos pratiques au jour le jour :

La plupart des programmeurs professionnels craignent un max.

Vous devez savoir taper à la machine pour être un programmeur

C++ est l’un des pires langages de programmation jamais conçu

Le monde a besoin de plus de GOTOs

Les programmeurs fainéants sont les meilleurs programmeurs

Les architectes qui ne codent pas sont inutiles

Les programmeurs qui passent leur journée à répondre à des questions sur Stackoverflow ne font probablement pas le travail pour lequel ils sont payés.

Les mauvais programmeurs sont Langage-Agnostiques

Les données sont le système.

Les utilisateurs ne sont pas idiots, vous l’êtes.

La documentation générée est presque tout le temps totalement inutile

Vous n’avez pas toujours besoin d’une base de données

Chaque développeur doit passer plusieurs semaines, voire des mois, à développer des systèmes sur papier avant de commencer à construire des systèmes sur électronique. Ils doivent aussi être forcés à utiliser leur système.

Tout cela est un méli-mélo de sagesse populaire, d’opinions tout faites, l’intérêt étant que tout porte à controverse, ça permet de se confronter à ce que ressent profondément notre profession (pour certains) ou notre « art » (pour les autres).

Bases de données temporelles

2009-10-13T06:10:00.000-07:00

Quand il s'agit de gérer des périodes de temps, SQL n'est pas très bien pourvu, et le modèle relationnel classique ne s'y prête pas naturellement. Sans essayer de passer par du TSQL2 et de s'attacher une technologie que finalement peu de monde utilise (l’utilisez-vous ?, je ne l’ai jamais vu en pratique sur des applications d'entreprise), on peut, avec malice, trouver des solutions pour représenter les différents états dans le temps d'un fait.

Tout est affaire de point de vue. Si vous avez une application tournant au dessus d’un modèle relationnel, il n’est pas nécessaire de modifier le code de celle-ci pour permettre l’historisation automatique des données manipulées.

Il n’y a qu’à remplacer les tables à historiser par des vues :

la vue a exactement les mêmes colonnes que la table qu’elle remplace

la vue est construite au dessus d’une table d’historisation contenant les mêmes colonnes qu’initialement, plus 2 nouvelles colonnes :

- DEBUT
- FIN

[DEBUT;FIN[ correspond à l’interval de temps pendant lequel l’entité a la même valeur (dans ses autres colonnes) (attention : DEBUT est inclus, FIN est exclu)

On peut vouloir stocker le temps-valide ou le temps transaction :

* Le temps-valide (ou « temps logique ») dénote la période de temps durant laquelle un fait est vrai par rapport avec la réalité.

* Le temps-transaction (ou « temps physique ») est la période de temps pendant laquelle un fait est stocké dans la base de données.

* La donnée bitemporelle combine à la fois le temps-valide et le temps-transaction.

A noter que ces deux périodes de temps n'ont pas à être égales pour un fait unique. Imaginez que nous ayons une base de données temporelle stockant des données relatives au 18ème siècle. Le temps-valide de ces faits se situe quelque part entre 1701 et 1800, tandis que le temps transaction débute quand on insère le fait dans la base de données, par exemple le 21 janvier 1998.

L’objectif est de pouvoir consulter la base de données à un instant T. Pour cela, il faut faire attention d’historiser aussi les données dépendantes par contrainte.

Les bases temporelles permettent souvent de différencier les programmeurs sur framework des programmeurs sur base de données. Un programmeur sur base de données va implémenter une base de données temporelle avec des vues et des triggers, offrant une vue propre des données à un instant T. Le programmeur sur framework va implémenter les règles de gestion du temps en Java au lieu d’utiliser des triggers et des vues et va aboutir, avec une grande probabilité, à une machine à gaz inmaintenable au bout de 3 mois.

Les vues et les triggers des bases de données sont des outils puissants et naturels pour implémenter :

le contrôle d’accès fin aux données,

l’historisation des données sous la forme de base de données temporelle.

Il est vain d’essayer de reproduire ces fonctionnalités au niveau de la couche applicative. Bizarrement, la mise en place de base de données temporelle est rarement évoquée sur asktom.oracle.com

Pour info, j'ai traduit la page Temporal database (Base de données temporelle) dans Wikipedia, histoire de combler à mon humble mesure le vide sidéral des articles informatiques en Français.

Pour en savoir plus sur les bases de données temporelle, autant consulter la liste de liens de Troels ou encore cette Introduction aux bases de données temporelles.

Efficacité des tests unitaires

2009-09-28T06:59:00.000-07:00

Les tests unitaires ne sont pas une solution à un problème, mais plutôt le symptôme de notre incapacité à produire du code correct dès le premier jet. Quand la même personne réalise le test unitaire et le code à tester, elle a toujours du mal à s'auto-critiquer, même en voulant honnêtement produire le code le plus propre possible. Un code est beaucoup plus critiqué, explicité, quand ce n'est pas la même personne qui code et qui teste. Cela me rappelle une étude citée par Steve McConnell dans "Code Complete 2nd Edition" qui m'apparut alors comme une révélation :

"Le test logiciel a une efficacité limité quand elle est utilisée seule - le taux moyen de détection d'erreur est seulement de 30 pourcent pour les tests unitaires, 35 pourcents pour les tests d'intégration et 35 pourcents pour des beta-tests de petits volumes. Par contre, l'efficacité des inspections de la conception et du code est de 55 et 60 pourcents. (Jones, Capers. 1996. "Software Defect-Removal Efficiency," IEEE Computer, April 1996)." -- Code Complete, 21.1. Overview of Collaborative Development Practices

L'inspection de code, formelle ou pas, est plus efficace que les tests unitaires et d'intégration. Avec de bonnes checklists, il est très intéressant de provoquer des critiques constructives sur chaque aspect d'une architecture et du code correspondant, en commençant par les plus sensibles. De plus, une personne porte beaucoup plus de soins à son code quand il sait que celui-ci va être inspecté par une autre personne. Une fois le squelette d'une architecture revue, il devient moins critique de relire tout le code développé sur celle-ci. Et on peut accélérer le développement comme nous le rappelle Jamie Zawinski :

"Les tests unitaires semblent biens en principe. Avec un rythme de développement tranquille, c'est certainement la voie à prendre. Mais quand on regarde de plus près, "nous devons aller de zéro à terminé en six semaines", et bien, je ne peux pas le faire à moins d'enlever quelque chose. Et ce que je vais enlever sont tous les trucs qui ne sont pas absolument critiques. Et les tests unitaires ne sont pas critiques. S'il n'y a pas de tests unitaires, le client ne s'en plaindra pas". -- Coders at Work

Quand les délais de livraison sont très courts par rapport à l'ampleur du code à développer, le ratio nombre de fonctionnalités sur le temps devient tel que le respect des délais est entièrement déterminé par la rapidité de frappe des développeurs sur leur clavier.

Et dans ce cas là, s'il n'y a pas de temps pour faire des tests unitaires, autant avoir des codeurs expérimentés codant juste du premier coup, ou sachant trouver la source de n'importe quel problème en un temps fini. Mais quand on en est à ce niveau, c'est qu'on n'est pas sure d'avoir du boulot si le logiciel à produire ne sort pas à la date cible.

Il peut être raisonnable de choisir de coder des solutions "Quick & Dirty" dans une première phase pour pouvoir respecter les délais tout en sachant qu'on contracte une dette technique importante qu'il faudra un jour payer dans une prochaine release sous peine de voir le logiciel se scléroser complètement.

Mais quel projet informatique, une fois parti sur le chemin séduisant du "quick & dirty" est prêt à payer sa dette pour revenir à un système "sain" de corps (le code) et d'esprit (la conception) ? Tant que le paiement des intérêts de la dette technique permette de continuer à développer de nouvelles fonctionnalités dans les temps impartis, qui se soucie de rembourser la dette ? s'il n'y a aucun intérêt business de nettoyer le code et l'architecture, mieux vaux continuer à coder comme avant.

J'ai rarement vu une maintenance d'un logiciel prenant régulièrement du temps sur chaque release pour corriger/mettre au propre des parties du code. J'ai toujours vu des applications devenir de grosses machines à gaz et être à terme refondue entièrement (la dette technique de l'application disparaît alors complètement). C'est peut-être malheureux à dire, mais c'est la sombre réalité du monde de l'informatique : la plupart des applications sur lesquelles nous sommes amenés à intervenir ont une énorme dette technique, et on a rarement l'espoir de voir s'améliorer une application sans que celle-ci soit entièrement refondue.

Il faut s'y faire, et autant apprendre à coder juste et de façon défensive dès le premier coup.

Inadaptation d’impédance objet-relationel : plus qu'une inadaptation, une incompréhension

2009-09-17T08:00:00.000-07:00

Cet été 2009, Thomas Kyte, expert développement sous Oracle bien connu, s’est largement étendu sur son site AskTom de questions/réponses, sur l’inadaptation d’impédance objet-relationel (object-relational impedance mismatch). Sur un ton direct et tranchant, il nous délivre son point de vue sur la place des « applications » notamment Java EE et de leurs rôles dans la gestion des données. Il fini par énoncer cette règle à suivre absolument :

Ne laissez aucun développeur qui code en Java, Visual Basic, C et autres langages de ce genre, écrire du code contenant SELECT, INSERT, UPDATE, DELETE ou MERGE dedans. Donnez leur accès à une série de procédures stockées qui retournent les données dont ils ont besoin, ou qui traitent les transactions nécessaires au système lui-même.

Assez radical il est vrai, Tom ne considère les applications au dessus des bases de données que comme de simples interfaces homme-machine (en gros, de simples JSP ou pages PHP suffisent pour faire interagir un client avec le serveur de données). Pour lui, autant ne pas donner aux applications un accès direct aux tables, au modèle de données parce que les applications vont et viennent rapidement mais les données,… les données vivent pour toujours ! :

… je peux à la rigueur mettre tout le SQL dans la base de données au lieu que dans du XML, ce n’est ni un gros problème pour moi ni un gros gain d’un côté technique…

Cela m’indique (« ni un gros gain ») que vous n’avez pas fait de bases de données depuis longtemps. Votre application – la chose pour laquelle vous vous concentrez aujourd’hui en 2009 – elle n’existera plus vers 2013. Mais la donnée, elle, sera toujours là. Et si vous avez caché tout ce qui concerne les données dans votre application obsolète écrite dans un langage mort, avec des frameworks que personne ne considère plus utiliser (rappelez-vous, c’est 2013, plus 2009 maintenant) – vous nous forcerez à l’en arracher entièrement et à le recommencer.

Le reste des réponses de Tom est du même acabit. C’est comme si le monde était séparé en deux : les programmeurs sur framework et les programmeurs sur base de données. En entreprise, la plupart des applications existent pour gérer l’information, gérer des données. Les traitements associés sont rarement compliqués et ne font jamais appel à des experts en algorithmie.

Dans quel cas a-t-on réellement besoin d'une machine à gaz ORM ? Quels sont les clients qui analysent leur métier en termes d’objets ? Parmi ces clients, quels sont ceux qui comprennent toutes les notions, aspects et pièges de l’orienté-objet ?

J’ai rencontré il y a quelques temps, en 2007, un client pour lequel j’ai du réaliser un audit de sécurité sur son application Java. Quand arrive le moment de lire le code source de l’application (qui date de 2002), un effroi (les englishs diraient, « WTF » à ce moment là) m’envahi quand je réalisai que ce qui avait été codé était un véritable serveur d’application complet codé à la main, spécifiquement pour ce client !

Ah, les développeurs s’en étaient donné à cœur joie pour créer cette majestueuse machine à gaz, capable de gérer des composants aussi complexes que des EJB 1.0, inmaintenables et inmaintenu actuellement, puisque plus personne n’a plus le temps de se pencher sur son fonctionnement, les développeurs initiaux ayant changés au moins 3 fois de société de service entre temps. Et puis, ce n’est pas un simple serveur d’application minimaliste qui a été codé, mais un énorme tas de technologies du moment comme par exemple, CORBA et IIOP qui étaient en vogue au moment du développement de cette application.

J’aurais pu me dire que tout cela était nécessaire à l’époque, notamment pour supporter une charge importante, des changements de configuration fréquents, un clustering, de la réplication de sessions, de l’intégration d’autres systèmes… Que nenni ! Toute cette machinerie ne sert qu’à gérer une cinquantaine de tables dans une base oracle et ne fait qu’1 ou 2 appels vers des WebServices, 1 intégration avec un LDAP… et puis c’est tout !

Autant dire que tout ce code Java ne sert strictement à rien ! Et coûte énormément à maintenir… Une simple application générée par « Oracle Application Express » aurait suffit. Je vous passe les autres détails de l’architecture de cette application, qui révèle bien que le client n’a pas du tout investi sur sa base de données mais uniquement sur des programmes en Java… Pour quelle raison ? J’ai beau tourner maintes et maintes fois la question dans ma tête je ne vois pas de raison logique à tout ça. C’est certainement une question de mode du moment.

Template, Modèle de Construction, Code Snippet : une réutilisation nécessaire

2009-09-10T08:00:00.000-07:00

Quelle est la plus importante habitude à prendre dans sa carrière d’informaticien ? On passe souvent des heures voire des jours à faire fonctionner un morceau de code, et on apprend toujours beaucoup de choses pendant ce processus de conception. La conception a cela de pervers qu’on ne connaît la bonne solution qu’une fois qu’on la conçue.

Ainsi, la conception est toujours un processus assez long et périlleux, il est donc plus que nécessaire de capitaliser sur ses expériences et les expériences des autres. La meilleure application étant celle pour laquelle on n’a à développer aucune ligne de code, la capitalisation qu’on entend ici est donc la constitution d’un ensemble de « modèles » (templates) ou « d’extrait de code » (code snippet) configurables, personnalisables et extensibles à souhait.

Quand on y pense, même pour des applications simples à concevoir comme des sites Web au dessus d’une base de données, il y a tellement d’exigences et de contraintes à prendre en compte (comme par exemple, la disponibilité, la sécurité, les performances…) qu’un cerveau humain n’est pas la plus fiable des machines pour les concevoir. Ne serait-ce que du simple fait qu’un être humain n’est pas constant et oublie vite les détails.

Ce qui motive le plus un informaticien à faire de la conception c’est l’objectif de ne jamais avoir à recoder deux fois la même chose, ou, mieux encore, ne jamais recoder deux choses similaires. Le copier/coller de code à la main (pratique la plus répandue dans notre profession, bien plus que l’exercice de réflexion) est à généraliser dans le cadre de la construction. Les « templates » permettent de générer des milliers de lignes de code et ce, sans l’introduction de bug si votre modèle est parfait.

Les templates : bien mieux qu'une photocopieuse...

La programmation orienté modèle (Template-oriented programming) devient de plus en plus pertinente du fait de la standardisation des solutions et des conceptions sous-jacentes, notamment par l’application des « modèles de conception ». A l’instar des modèles de conception, les templates de code pourraient s’appeler des « modèles de construction », puisqu’il s’agit de standardiser/automatiser la construction d’application. Autrement dit, il devient facile de récupérer des applications correctement codées comme, par exemple, les exemples d’application fournis par Spring (situées dans le bundle Spring) ou dans le Java EE SDK, d’en créer des modèles de code et d’automatiser la création d’application standard en fonction d’un modèle conceptuel des données et des traitements.

La meilleure pratique à s’imposer dès son plus jeune âge dans le métier est donc la transformation de code s’exécutant (« running code ») en code réutilisable pour d’autres projets. Personnellement, je me suis construit une petite application Web pour recueillir tous mes templates, et me permettre de générer du code en fonctions de configurations et de modélisation des informations à gérer. Mais ce genre d’outil se retrouve dans pratiquement tous les IDE dignes de ce nom par exemple Visual Studio, Eclipse, Emacs (avec aussi les abbrevs par exemple) ou dans d’autres outils innombrables (par exemple CodeSmith) …

J’essaie de passer du temps en fin de projet pour réutiliser de tout code qui a été programmé à la main. Comparez le temps nécessaire pour transformer du code en template et le temps que l’on peut gagner quand on va générer des applications avec ces nouveaux templates, et vis-à-vis du nombre de fois qu’on va générer ce code. On y gagne dans la plupart des cas. Il faut bien sur, faire attention à la licence associée au code source.

Qu’est-ce qui sépare un développeur d’un développeur expérimenté ? Le nombre de « modèles de construction » à sa disposition et sa capacité à programmer automatiquement. Faire soi-même un système de génération de code source ou d’application complète permet de maîtriser ce que l’on génère pour mieux en connaître les limites.

Qu’est-ce qui sépare un développeur expérimenté d’un guru respectable et respectée ? Le guru fait de la génération de code qui génère du code qui génère du code… Il fait de la production de modèle de construction, un processus récursif.

On peut extraire des modèles à partir de ses expériences sur des projets, mais on peut tout autant tirer parti des expériences des autres, à partir des exemples donnés dans les livres techniques. Toute lecture d’un livre doit s’accompagner d’un enrichissement de son système de génération de code. A chaque fois que je crée un modèle, je me demande « qu’est-ce qui peut être différencié dans ce code : qu’est-ce qui peut être demandé par un client, qu’est-ce qui est du ressort de l’implémentation uniquement ».

Les templates peuvent être utilisés pour autre chose que la génération de code comme par exemple :

générer automatiquement de la documentation (avec des formats de fichier sous format texte comme le RTF, XML par exemple)

générer automatiquement de la configuration de middleware comme la configuration d’Apache httpd ou tomcat, ou la configuration de progiciels…

Le domaine d’application de la génération de fichier est sans limites… Un système de gestion de templates peut servir aussi à se souvenir de l’ensemble des paramètres à saisir, l’ensemble de questions à se poser, comme une checklist ce qui permet de ne rien oublier.

A chaque fois que je code quelque chose j’essaie de me poser la question : est-ce que je serai capable de reproduire ce code dans 5 ans sans réfléchir ? Pour être sur de pouvoir ressortir ce code plusieurs années après, je le transforme en template et mon système doit permettre de générer du code qui s’exécute sans problème ou doit fournir des instructions suffisamment claires pour l’intégrer ou l’exécuter.

Et après ça, je peux oublier ce bout de code et dormir sur mes deux oreilles…

L'orienté objet : plus qu'un cache misère

2009-09-03T08:00:00.000-07:00

Quels sont les caractéristiques principales d'un programme écrit par un néophyte ? des noms de variables incompréhensibles ? aucune organisation du code ? La pire, et malheureusement la plus fréquente, car inhérente à l'incompréhension de la notion d'abstraction, c'est l'utilisation généralisée de variables globales.

L'emploie de variables globales, faut-il le rappeler, est considéré comme une mauvaise pratique, du fait même de sa "non-localité" : une variable globale peut être modifiée de n'importe où (sans même parler de sa volatilité), et n'importe quelle partie d'un programme peut en être dépendante. Cela rend donc le programme inmaintenable à partir d'une certaine taille.

Vulgaire pédanterie d'un béotien en mathématique : l'emploi de variables globales et les dépendances qu'il instille entre toutes les parties d'un programme me fait penser visuellement à un pavage hyperbolique du disque de Poincaré. Il montre bien que toute chose est dépendante d'une autre et change de couleur aux croisements des autres dépendances.

L'orienté-objet force à l'abstraction mais n'empêche pas les variables globales de proliférer. Au delà d'éléments globaux d'une application, l'emploie de variables globales s'est immiscé subrepticement au cœur des classes d'objet, et le paradigme Orienté-Objet en a fait son beurre.

On pourrait même croire que, suite à la reconnaissance, par toute la communauté des programmeurs, de l'emploie de variables globales comme mauvaise pratique, des êtres mal intentionnés auraient inventés un paradigme leur permettant de programmer localement avec des variables globales, de restreindre, en fait, les variables globales à quelques fonctions.

L'orienté-objet n'est qu'une manière déguisée de programmer en utilisant des variables globales. Il pousse (mais n'oblige pas) à s'intéresser aux invariants de classe et d'objet, de savoir, en fait, gérer des variables globales pour qu'elles ne posent aucun problème lors de l'appel des méthodes.

Nombreux ont été les échecs quant à la préservation de l'intégrité des données d'une classe vis à vis de ses méthodes. Il est apparu, avec le temps, des principes de construction d'une classe, qui permettent de mettre de l'ordre dans la gestion de ces variables globales, locale à un objet ou à une classe d'objet. Ces principes ont été clairement exprimés par Robert C. Martin dans ses livres et sur le site Web de sa société Object Mentor.

Les principes de conception de classes orientée-objet sont regroupés au travers de la mnémonique SOLID, et permettent ainsi de surpasser la difficulté de maintenir des données globales dans un objet :

S : Single Responsability Principle (SRP) : There should never be more than one reason for a class to change.
O : Open-Closed Principle (OCP) : A module should be open for extension but closed for modification.
L : Liskov Principle (LSP) : Subclasses should be substitutable for their base classes
I : Interface Segregation Principle (ISP) : Many client specific interfaces are better than one general purpose interface
D : Dependency Inversion Principle (DIP) : Depend upon Abstractions. Do not depend upon concretions.

Robert C. Martin énonce aussi des principes d'architecture des modules (packages) très intéressants qui permettent de mieux gérer les dépendances des modules entre eux à fin de tenir la plus grande promesse de l'orienté objet : la réutilisabilité.

Release Reuse Equivalency Principle (REP)
Common Closure Principle (CCP)
Common Reuse Principle (CRP)
Acyclic Dependencies Principle (ADP)
Stable Dependencies Principle (SDP)
Stable Abstractions Principle (SAP)

Ces principes sont tout aussi importants que ceux relevant de la conception de classes, et des outils permettent de vérifier de façon automatique dans la plupart des cas, qu'on ne les enfreint pas. C'est le cas de JDepend dans le monde Java, NDepend pour le monde .NET, PHP Depend, Module::Dependency pour Perl...

C'est bien le genre de métrique qu'on a envi, en tant que chef de projet, de mettre dans les 'hooks' de subversion et de bloquer tout commit qui ne les satisferait pas. Quand on a la responsabilité d'un projet pour lequel on vous a affecté sans possibilité de discuter, des débutants, on croit toujours pouvoir être Big Brother et scruter le moindre faits et gestes des développeurs, en leur mettant par exemple, comme dans les sous-doués passe le bac, une bonne décharge électrique à chaque fois qu'ils essaient de commiter du code pas convenable.

Le problème c'est que tout ces principes ne sont pas toujours mis en œuvre dans les modules et librairies de base des langages comme Java notamment (par exemple, la fameuse classe Date qui au fur et à mesure des versions de java s'est vue refondre entièrement sans jamais atteindre une bonne implémentation, des fous sont même allez jusqu'à déposer un brevet logiciel pour refondre cette classe. La description du brevet est instructive sur les limites de la classe Date)

Ceci dit, une orientation objet bien maîtrisée peut aboutir aux nobles objectifs qu'elles s'était fixés dans la mesure où l'on sait que l'on joue avec le feu des variables globales.

De l'agilité des légos et des logiciels afférents

2009-08-27T08:00:00.000-07:00

Il faut bien avouer cette sombre évidence : un informaticien cherche toujours à ramener son travail à un jeu de légo.

Loin d'être un trouble obsessionnel compulsif, il lui semble que le monde devrait être plus simple, et devrait normalement se soumettre à la réduction induite par la modélisation.

Si la construction d'application s'apparentait à des Légos comme le sous-entend OSGi, on n'aurait pas besoin de développeur, il suffirait d'emboîter des composants les uns dans les autres. Or, l'innovation d'une application n'est pas là. Vous pouvez faire de très belles constructions en légo, mais l'utilité de celles-ci restera à démontrer par l'expérience. Le simple rapprochement de fonctionnalités dans une combinaison originale peut s'avérer intéressante dans certains cas, et toute une profession s'en contente largement en attendant la prochaine véritable innovation.

Au delà de la réduction à un jeu de légo, nombreux sont ceux qui cherchent à insuffler une marque de sérieux à une activité dénigrée dès qu'on prononce son nom : la programmation. Le mot programmation est connoté négativement par tous les professionnels et clients du secteur informatique. Ce terme ramène trop à la base de l'activité, au travail le plus bas niveau et pourtant le seul qui produise de la valeur réelle : la création d'un programme en vue de le faire exécuter par l'automate informatique. Pour cacher la dure réalité d'une profession de tapeur à la machine, nombre d'informaticiens ou pseudo-informaticiens se vêtissent d'un jargon sans cesse renouvelé pour mieux périmer les vieux termes et ceux qui les utilisent encore.

Aujourd'hui, seules les méthodes "agiles" sont considérées comme crédibles. Une pratique de développement logiciel qui ne s'apparente pas au mouvement "Agile" est à priori suspecte. L'ajout d'un adjectif comme agile à des noms déjà vagues, prête souvent à confusion, car cela pousse à croire que les objets en questions sont relatifs. Cela s'apparente au relativisme ambiant : le relativisme culturel que des intégristes religieux cherchent à promouvoir pour justifier leurs agissements dans certaines contrées, ou comme dernièrement, le Président de la République Française avec sa "Laïcité positive" (sous entendu, il existe une laïcité négative). Une méthode agile exclue toutes les autres et les ramène au rang de méthodes forcément non-agiles, donc lourdes, dépassées, ...

Hep, Hep, toi qui veux être dans le coup, sache que "Agile" est maintenant un terme dépassé, il faut parler de ARxTA ... "Agile", comme tout terme-réclame est utile aux professionnels, tant pour les clients que pour les fournisseurs de solutions. Cela permet de rapprocher des points vus autour de mots clés clairement identifiés, ce qui créé une sorte de communauté avec ses codes, son jargon, ses pratiques, techniques et traditions : une véritable culture en sorte.

Au delà de ces mouvements passionnés, des individualités surgissent, émergent, montre les nouvelles cimes à atteindre par leurs actions au jour le jour. Il est toujours étonnant de voir que malgré les énormes entreprises commerciales aux bénéfices records (même en ces temps de crise), de simples individus arrivent à imposer leurs créations comme autant de nouvelles évidences pour la profession. C'est pourtant dans de petits bureaux, dans de non moins petites salles IRC de discussions que se forgent les technologies de demain. Une startup sait qu'elle est sur la bonne voie quand elle peut produire son application sans recours à des fonds extérieurs, ces fonds ne servant qu'à accélérer plus ou moins un mouvement incessant et irréductible, dirigé vers la réussite.

Pour illustrer la capacité d'un individu à produire de petites merveilles, j'ai pensé vous faire profiter de la voix cristalline de Imogen Heap qui, aidé par un MacBook il est vrai, arrive, à elle seule, à oindre de saintes notes de ses propres mains dans nos esgourdes.

Non, on a beau dire que la perfection n'est pas de ce monde, mais le chemin de l'excellence cherche à nous y mener en tout cas, chaque jour nous ramenant à la dure réalité et à notre propre dépouillement face à la grandeur des exigences et contraintes de nos applications. Ce n'est pas ce qu'on appelle le mythe de Sisyphe ?

Grippe A (H1N1) : l'avez-vous mise dans les risques de votre projet ?

2009-08-20T08:00:00.001-07:00

La grippe A (H1N1) va (ou est déjà) arriver massivement en France, avec normalement un pic en septembre 2009. Ce n'est pas une grippe qui semble plus grave qu'une autre mais elle a la particularité d'être très contagieuse. Ce qui veut dire qu'il y a un risque réel d'avoir 5 % à 15 % des effectifs des projets absent 1 ou 2 semaines un jour ou l'autre pour arrêt maladie. Ce peut être aussi des parents qui s'absentent pour garder leurs enfants car ceux-ci ne peuvent plus être reçus à l'école pour cause de grippes trop nombreuse dans leur classe.

En bref, la probabilité d'avoir des ressources en moins sur les projets est très forte et doit normalement être prise en compte dans votre suivi des risques, sous peine d'avoir de grosses surprises et d'autant plus grosses déconvenues sur les estimations des délais de livraison.

Si vous pensez pouvoir arguer que vos retards de livraisons sont dus à la grippe et que votre client ne va pas ciller face à cet argument, bien à votre aise de ne pas suivre ce risque et de laisser aller vos projets tels qu'ils sont aujourd'hui.

Dans le cas contraire, il est temps de suivre le risque, de se préparer à contrer les absences, ainsi que renégocier les modalités de livraison avec vos clients : vous pouvez toujours tenir vos délais et enlever certaines fonctionnalités de la listes des fonctionnalités obligatoires à livrer (les mettre alors dans la listes des fonctionnalités "si possible").

En tout cas, il faut être clair avec le client sur ce risque pour éviter toute surprise mal venue.

Il est toujours inquiétant de voir que dans certaines sociétés, le rythme des projets et des livraisons envisagées n'a pas baissé, voire a même augmenté pour répondre à la crise. Mais c'est prendre un gros risque que d'ignorer ce qui va arriver de façon quasi certaine. Le fait qu'on ne maîtrise pas les impacts de la grippe n'est pas une excuse pour ne pas les anticiper.

Que vous soyez chef de projet, directeur de projet ou simple exécutant, pensez à voir l'impact de votre absence ou de l'absence de vos confrères sur les projets sur lesquels vous travaillez. Je serais vous, je ne prendrais pas d'engagement inconsidérés durant la période de cette rentrée 2009. Mais qui prend d'ailleurs d'engagements inconsidérés ? Le tout est de considérer que les changements sont inévitables sur les projets, et il s'agit de les gérer explicitement.

Dates cibles et échéances : compromis comme promis

2009-08-13T08:00:00.000-07:00

Tout le monde a, un jour, travaillé sur un projet si mal défini ou si maladroitement suivi qu'on a plus qu'une seule envie : quitter le radeau avant qu'il ne coule. Vu la proportion gigantesque de projets ne respectant ni ses délais, ni son périmètre initial ou ses coûts (source), il est très probable que vous ayez déjà participé à ce genre de fiasco.

Dans les projets à la dérive, les échéances (deadlines) sont souvent dépassées, faisant éclater des disputes sans fin dans le but de trouver des coupables, mais surtout pas d'essayer de remettre de l'ordre pour la suite du projet.

Quand ces horribles projets finissent par mourir définitivement (et ça peut prendre beaucoup de temps !), il est toujours intéressant de se pencher dessus à froid, pour essayer de comprendre ce qui n'a pas marché. Ce travail de reflexion à posteriori (les anglosaxons aiment bien utiliser le terme « project post-mortem ») est malheureusement trop rarement effectué, ou seulement de façon incomplète.

Sur plusieurs de ces projets, on s'aperçoit que les échéances ont été définies avant même d'estimer quoique ce soit sur le projet. De plus, ces dates n'ont jamais été remises en causes pendant toute la durée du projet. Est-ce que ce sont réellement des échéances (deadlines) ou seulement des dates cibles (« target dates ») ? Une date cible est bien différente d'une échéance. C'est ce que décrit clairement Conrad Weisert dans son article « Les échéances et dates cibles des projets : 5 conseils pour éviter le désastre » :

La plupart des « échéances » (deadlines) ne sont en fait que des dates cibles. La différence réside dans ce qui survient si la date n'est pas respectée :
quand une échéance est ratée, il ne reste plus aucun intérêt à compléter l'engagement. Par exemple :
s'inscrire à une compétition
publier le catalogue de Noël prochain
Quand une date cible est ratée, les conséquences peuvent être aussi désastreuses que pour une échéance, mais vous avez toujours à finir le travail. Si « date cible » semble trop vague pour vous, alors remplacez cette expression par « date de fin » ou « date de livraison ».

Encore faut-il gérer correctement la planification d'un projet de développement pour pouvoir définir des dates cibles ou des échéances. Cela nécessite de maîtriser un tant soit peu l'art délicat de l'estimation et d'être en mesure d'offrir des preuves de celle-ci.

Sur son site, Conrad revient sur ces notions importantes, en relation avec la gestion de projet et le développement logiciel. L'estimation n'est pas qu'une affaire d'expérience. C'est aussi et surtout le moyen de montrer par « a + b » qu'un projet tiens la route et saura tenir ses délais. Or seul celui qui dit que quelque chose peut être fait doit en apporter la preuve. Un client ou une division Marketing d'une entreprise se doit d'être ambitieux quant à la définition du produit et à ses dates de livraison ou de mise sur le marché. Or ce n'est ni le client ni cette division marketing qui vont prouver qu'on est capable de réaliser ses rêves. C'est au chef de projet (ou au chargé d'affaire dans le cas de sous-traitances de développement) de trouver des solutions qui puissent répondre au mieux aux exigences et contraintes exposées.

La définition de plan permet d'éclaircir le projet et de notamment exprimer de nouvelles exigences et contraintes liées aux solutions. Ce n'est qu'en face des éléments issues de toutes les parties que l'investisseur (le client, la division marketing...) lance le projet.

Dans le cadre de la sous-traitance de production (pour le développement logiciel au forfait par exemple), il est facile pour un chef de projet de se faire imposer des dates cibles du simple fait:

de la relation contractuelle qui existe entre le client et son cahier de charge d'un côté, et le fournisseur et sa volonté de gagner le contrat de l'autre (souvant « à tout prix »).
de la rédaction de la réponse à l'appel d'offre par une personne (un « chargé d'affaire ») autre que celui qui va mener le projet jusqu'à son terme.

Même dans le cas de sous-traitance, il est souhaitable que la réponse à l'appel d'offre soit ambitieuse et rédigée par une personne autre que le chef de projet, car ce dernier a naturellement tendance à voir énormément de risques et à avoir une attitude extrêmement prudente, encore plus s'il n'est pas « intéressé » personnellement (oui, oui, par cette basse chose qu'on appelle « l'argent ») au projet. Mais c'est au final, au chef de projet de ramener tout le monde à la réalité.

AJAX et Performance : un oxymore

2009-08-06T08:00:00.000-07:00

N'avez-vous pas l'impression qu'AJAX (Asynchronous Javascript and XML) nous ramène en un temps où les ressources matérielles étaient chères et lentes, où les compilateurs ne savaient rien optimiser et qu'il était difficile de fiabiliser son code ? Développer en Ajax, c'est retrouver le bidouillage d'antan, quand il fallait lutter à chaque pas contre les limites du système cible. Oui, ce satané Javascript qui a plus à voir avec Lisp qu'avec Java, est bien la cause de ce problème. Où plutôt la mise en œuvre de ce langage dans un paradigme (AJAX) créé dans le but unique de palier aux problèmes d'un autre paradigme (le Web) pour obtenir des applications d'un paradigme historiquement éprouvé (le Client-Serveur).

En effet, les technologies supportant l'AJAX sont plus qu'inefficaces, elles sont inappropriées. Les navigateurs Web ne sont pas conçus à la base, pour être des plateformes d'exécution d'application.
Javascript a été mis en place dans les navigateurs (Netscape Navigator à l'origine) pour palier à l'aspect statique des pages et du protocole orienté document qu'est HTTP.

Pour que Javascript s'exécute rapidement, il a donc fallu implémenter un interpréteur très simple et ne réalisant que peu d'optimisations. On ne retrouve pas en Javascript les optimisations que l'on considère comme évidentes dans n'importe quel autre compilateur :

Il faut donc coder en Javascript d'une manière spécifique, en connaissance de cause. Cette leçon nous est donnée par Douglas Crockford dans sa présentation « Ajax Performance ». Il nous donne quelques exemples puis exprime la philosophie générale de l'optimisation Ajax : Alors qu'il est logique de penser qu'il faut toujours essayer d'avoir des algorithmes de complexité en O(1), O(log n) plutôt que O(n), O(n²) ou O(eⁿ), l'important est d'avoir n le plus petit possible quelque soit la complexité. Le client Ajax n'est là que pour présenter une vue réduite des données du serveur.

Ce qui est étonnant c'est l'intitulé de la série de présentation de Douglas qui s'appelle « Javascript : the good parts ». Je comprend bien qu'il veuille prêcher pour sa paroisse, son langage de prédilection, mais heureusement qu'il a un œil critique sur sa technologie fétiche et montre bien qu'il faut aller bien loin pour trouver de « bons côtés » à Javascript. Il a du vouloir attirer tous les zélotes de l'Ajax et du javascript à sa présentation pour mieux leur montrer les limites de leurs croyances. Car toute « nouvelle » technologie , s'apparente plus à l'émergence d'une secte qu'à une avancée scientifique majeure. AJAX n'est plus très nouveau d'ailleurs.

Heureusement la réalité est toujours là et les « bonnes pratiques » informatiques sont toujours d'actualité même en Javascript. Douglas ne fait que reprendre à raison les principes éprouvés de l'optimisation de code.

On a beau critiquer Javascript, on peut aussi l'apprécier pour ses aspects qui le différencient tant de Java justement, comme par exemple : l'héritage par prototype, la programmation fonctionnelle que l'on peut en faire, notamment, grâce aux fonctions d'ordre supérieur. Le Javascript est, de fait, un des langages les plus utilisés aujourd'hui.

Ça peut être amusant de faire de l'Ajax (c'est d'ailleurs quelque chose que nombre de développeurs réalisaient il y a de cela déjà bien longtemps, avant même qu'on y mis un nom dessus) mais franchement, aujourd'hui, ce qui est le plus productif c'est de ne carrément pas coder du tout : utiliser des outils pour générer les interfaces graphiques et des applications.

Qu'on le veuille ou non, le coût d'un développeur français est tellement élevé par rapport à un développeur indien (7 à 10 fois son prix) par exemple qu'il devient complètement improductif de lui demander de développer à la main des applications Ajax.

En france, à Montpellier, il y a PC SOFT (un nom de boîte qu'on imagine sans hésitation sortir des années 80) qui produit WEBDEV dans le même esprit que WINDEV. Parmi mes collègues développeurs, rare sont ceux qui préconise de développer avec de tels outils de génération d'application. J'ai l'impression qu'ils disent cela parce que WINDEV est vieux et que tout ce qui est vieux en informatique devient plus ou moins ringard.

Personnellement, leur nouvel outil WEBDEV semble intéressant pour produire des applications Web / AJAX sans coder quoi que ce soit. Pour la plupart des petites et moyennes applications, c'est largement suffisant car ce sont essentiellement des applications de gestion de l'information. Dans le cas de besoins spécifiques, on peut toujours développer spécifiquement une extension et l'intégrer à l'application.

Il existe aussi Oracle Application Express pour la génération automatique d'application au dessus d'une base Oracle sans écrire une seule ligne de code. Ce composant est souvent disponible chez les client qui ont achetés des licences database serveurs, sans qu'ils le sachent vraiment. Le client paie cher des technologies dont seulement 10% sont réellement utilisées (et ces 10% se retrouvent souvent aussi bien en Open Source...)

Tout cela va dans le sens de considérer XML, HTML, CSS et Javascript comme étant du binaire illisible qu'il s'agit de traiter uniquement via des outils de haut-niveau et des ateliers de génie logiciel (AGL). Seul les développeurs de composants et d'atelier logiciels ont à se pencher sur ces technologies au jour le jour.

Travailler de manière productive

2009-04-15T06:13:00.000-07:00

Faisant parti d’un grand groupe de télécommunication, je suis amené à être en contact avec de nombreux interlocuteurs, pour les divers projets que je mène en parallèle. Par jour je reçois entre 50 et 100 emails nouveaux. Mon travail est asservi par de nombreuses « deadlines », des échéances qu’on ne peut louper sous peine de retarder le projet de 4 à 6 mois.

Pour gérer un tel flux d’informations, d’actions à entreprendre, et de travail à réaliser, il faut s’organiser. Par la force des choses, j’ai du adapter ma façon de travailler pour rendre les choses maîtrisables et efficace.

Tout d’abord, mon outil principal, quand je fais de la direction de projet (ou de programmes dans certains cas), c’est mon client email : Outlook en l’occurrence. Par bien des aspects, cet outil peut en énerver plus d’un, mais, par d’autres, il devient indispensable et irremplaçable par d’autres outils du marché (que ça soit opensource ou non).

Quand mon flux d’email quotidien ne dépassait pas les 20 emails par jours, je triais chaque email reçu en fonction de son projet associé, et du type d’email. Mais quand on en est à plus de 50 emails par jours, le tri devient inutile voire constitue une perte de temps certaine. Quand on se rend compte que la durée de vie d’un email est parfois très courte (quelques minutes) à quoi bon trier.

La solution : ne plus trier ses emails et faire de la recherche full-text ou par champs dans tout vos emails. Pour ne pas surcharger le serveur d’email, j’archive tous les emails du serveurs qui ont plus d’1 jour. L’archivage consiste à mettre les emails du serveur sur mon disque local dans un répertoire Outlook du même nom : Inbox. Oui, tout est dans Inbox, je ne trie plus rien, à quoi bon perdre du temps quand on peut faire une recherche détaillée sur l’ensemble de ses emails.

Bien sur, inutile de compter sur l’outil de recherche fulltext de Outlook qui est complètement désuet par rapport à l’ampleur de la tâche : rechercher un email particulier dans une archive contenant plus de 2 ans d’emails (20Go de données) est impossible pour l’outil standard Outlook. Il vous faut un outil de recherche bien plus puissant. Et j’ai trouvé ça avec Lookout, outil maintenant disparu mais que le développeur original de l’outil à montré comment l’installer par soi-même via une petite manip.

J’ai réussi à installer Lookout sur Outlook 2003 sans problème en suivant la procédure. Et maintenant je n’utilise plus que cet outil pour faire de la recherche fulltext. Rendez-vous compte, avec son puissant système d’indexation basé sur Lucene.NET, il est capable de me retrouver un email par tous mes emails en moins d’une seconde ! C’est vraiment un outil pratique quand on a gérer des tonnes d’emails. En plus, il permet de faire des recherches compliquées sur les emails, par exemple, selon les valeurs de certains champs (To, From, Subject…)

Pour s’y retrouver parmi les emails, j’utilise aussi les Flags et les vues. Si je détecte des actions à réaliser lors de la lecture d’un email, je me pose la question : est-ce que l’action prend moins de 2 minutes à réaliser (cf. GTD). Si oui, alors je fais l’action tout de suite, sinon, je flaggue l’email :

o En Rouge : pour une tâche à faire ASAP

o En Orange : pour une tâche qui peut être remise à plus tard (peut attendre)

o En Vert : pour une tâche que je dois déléguer

o En bleu : pour une tâche déléguée pour laquelle j’attends une réponse

o En violet : pour un email qu’il faut que je lise mais qui peut me prendre du temps

Quand un email nécessite plusieurs tâches, ou si la tâche n’est pas évidente d’après l’email, je crée un nouvel email que je m’envoie et retrouve donc dans mon Inbox. Je luis attribue alors un flag comme décrit ci-dessus. Pour chaque tâche j’essaie de mettre aussi la « Due date », l’échéance à respecter pour finir la tâche.

Avec une telle organisation, adaptée de Getting Things Done de David Allen, je suis capable de gérer des centaines d’emails par jour tout en « prioritisant » mon travail et permettant ainsi de travailler de long moment sur une seule activité tout en sachant qu’est-ce qu’il me reste à faire après, sans oublier une seule tâche.

Ce qui est important dans tout ça, c'est de déterminer quelles sont les tâches qui ont vraiment de l'importance et celles qui n'en ont pas ou moins. Car faire plein de choses sans importance permet de remplir facilement sa journée de travail, mais n'aboutis à aucune valeur ajoutée.

Délire paranoïaque de programmation

2009-03-28T08:41:00.000-07:00

N'avez vous jamais eu envie de contrôler entièrement l'environnement informatique cible de votre programme pour être sûr à 100% de ce que vous développez ? C'est certainement le rêve d'un paranoïaque doublé d'un introverti incapable d'accepter les limites de ce monde (et de lui-même par la même occasion). Mais dans le monde en crise qu'est supposé est le notre, avoir l'entière maîtrise d'un monde binaire peut se révéler rassurant pour certains. Même si cette passion est destructrice quand on ne s'ouvre plus sur le reste du monde.

Le vrai délire créatif des paranoïaques que nous sommes, nous les informaticiens, passe par la connaissance des fonctionnements les plus bas niveau de la machine, d'arriver clairement à savoir ce qui se passe en temps réel dans chaque partie de l'ordinateur. Quelle joie alors de programmer pour une console de jeux plutôt que sur un boufficiel comme l'est un système d'exploitation commercial. C'est ce que nous rappelle Jasper Vijn dans son excellent tutoriel pour le développement GBA :

D'un point de vue programmation, le GBA (ou n'importe quelle autre console) est totalement différent d'un PC. Il n'y a pas de système d'exploitation, pas de pagaille avec des drivers et des incompatibilités avec le matériel. Ce sont des bits aussi loin que l'oeil puisse voir. En fait, les PC ne sont aussi que des bits, mais c'est plusieurs niveaux en dessous. Sur une console, c'est juste vous, le CPU et la mémoire. En gros, c'est le rêve du Vrai Programmeur.

Quand on en vient au niveau bit, on est confronté à plein de ravissantes choses comme l'ABI (Application Binary Interface) et plus spécifiquement l'EABI ARM pour ce qui est du développement pour GBA ou NDS.
La compréhension de ce qui se passe en dessous du langage de programmation de haut niveau devient nécessaire, si ce n'est obligatoire pour éviter de grosses bévues. Savoir programmer au niveau assembleur n'est pas forcément inutile quand vous êtes embarqué dans un projet de type Java ou .NET. Comprendre le bytecode et la JVM peut se révéler utile dans certains cas, notamment pour la maîtrise des performances.

C'est ce que nous montrais brillamment Peter Haggar dans son livre Mieux programmer en Java , maintenant épuisé en Français mais qui se trouve encore en version anglaise dans son livre Practical Java Programming Language Guide.

Il avait organisé son livre en ateliers avec pour chacun, un point particulier d'attention où la solution Java n'est pas aussi simple qu'elle n'y parait. Dans plusieurs de ces ateliers, la référence au bytecode produit pour expliquer le pourquoi du comment est inévitable, comme par exemple l'atelier 40 page 118 : "Utiliser System.arrayCopy pour copier des tableaux".

On peut s'en apercevoir aussi dans ses articles en ligne comme par exemple Double-checked locking and the Singleton pattern où il y a encore un deassemblage du code pour mieux comprendre ce qui se passe.

Des particularités de la machine sont à prendre en compte quand on développe si bas, comme par exemple l'alignement de données et de structures, l'endianness, les différentes méthodes de copie de données (tableaux, copie de structure (le C permet de faire de la copie de structure sans appel de fonction particulière : que se passe-t-il vraiment alors ?) , copieurs standards comme memcpy(), et des routines spécifiques à GBA ou NDS comme CpuFastSet() et le DMA).

Pour la plupart des applications de gestion de l'information (disons que la règle du 80/20 s'applique encore ici), le développeur n'a pas besoin de se soucier de tous ces détails, les langages de haut niveau (je les appellerais plutôt des langages plus abstrait) arrivant bon an, mal an à offrir des performances acceptables dans la plus part des situations les plus courantes. Mais, il y a toujours ce 20% des applications (ou disons les 20% des fonctionnalités des 20% des 80% de toutes les applications ... ) qui sont toujours importantes à maîtriser complètement sous peine de ne pouvoir délivrer le logiciel. Dans ces cas, là, deux choix s'offre à vous, puisque le monde est toujours divisé en 2 :

- soit tu creuses (tu cherches à comprendre la complexité des ordinateurs et les conséquences de tes paroles en langage de programmation)

- soit tu tiens un pistolet chargé sur un autre qui creuse (l'autre qui creuse est celui qui va maîtriser le sujet et la machine pour toi... et qui en redemandera encore après çà ;) )

OpenBSD et les caractéristiques "par défaut"

2009-02-19T08:00:00.000-08:00

L'intérêt d'un système d'exploitation comme OpenBSD c'est qu'il ne fait pas de compromis sur plusieurs sujets et ainsi, offre des caractéristiques par défaut sans avoir à réfléchir plus que de dérouler les manuels utilisateurs.

OpenBSD est sécurisé par défaut, et est mis à jour par défaut tous les 6 mois. Quand on a autre chose à faire que de régler des problèmes d'interopérabilité entre les composants hardware, les composants software ... c'est l'idéal, on peut alors se concentrer sur ce que l'on désire réellement faire.

Oui, même s'il est toujours intéressant d'installer de configurer et d'optimiser un système d'exploitation, à moins que vous soyez un développeur du système d'exploitation, l'important se trouve ailleurs, dans l'utilisation du matériel et du système d'exploitation pour atteindre un but qu'on s'est fixé. C'est ce que nous rappelle Miod Vallat et Marc Espie dans leur interview à la radio, dans l'émission Symbiose. On peut toujours aboutir à l'augmentation/amélioration du code de l'OS, mais c'est pas le but en soi.

Cet aspect "par défaut" serait intéressant à généraliser à d'autres éléments d'un ordinateur. Je pense notamment, qu'il serait intéressant de pouvoir acquérir des PC sauvegardé "par défaut" avec un système de backup matériel et logiciel correctement configuré par défaut pour ne plus avoir à se soucier de ce sujet.

Au moins pour les ordinateurs personnels. Notamment avoir des ordinateurs portable dont les données sont cryptées et sauvegardées par défaut. C'est rarement fait par défaut, il y a toujours une procédure longue et fastidieuse (mais c'est parce que ce n'est pas un sujet simple).

Système embarqué et programmation Nintendo DS

2009-02-12T08:00:00.000-08:00

M’étant épris de la nintendo DS, je me suis mis à expérimenter un développement pour cette merveille de raffinement technologique. Quand on étudie l’architecture de cette machine, on ne peut s’empêcher de penser que ses concepteurs ont pris du plaisir à la concevoir. En voyant la représentation de l’architecture ci-dessous, cela m’a tout de suite rappelé celle de l’Amiga qui tirait plus sa force de son chipset original que de son processeur proprement dit :

La nintendo DS a deux processeurs différents : un ARM7TDMI et un ARM946E-S partageant des espaces mémoires en commun, ayant à leur disposition, différents types de mémoire plus ou moins rapide (DTCM et ITCM, WRAM, ICACHE et DCACHE de l’ARM9…)

Programmer pour la nintendo DS, c’est bien programmer pour "un système embarqué" (embedded). Un des concepts importants en programmation embarqué est l’utilisation de registre mappé sur la mémoire : « memory-mapped registers ». Ce genre de technique apporte son lot de problèmes et de solution, notamment par l'emploi, en langage C, du mot clé "volatile", qui n'a rien à voir avec les oiseaux, comme nous le montre très bien Nigel Jones dans How to use C's volatile keyword et que je vous traduirais ainsi :

Les système embarqués contiennent du vrai matériel, habituellement avec des périphériques sophistiqués. Ces périphériques contiennent des registres dont les valeurs peuvent changer de façon asynchrone vis à vis du déroulement du programme. Pour prendre un exemple très simple, considérez un registre de status sur 8 bits qui soit mappé sur la mémoire à l'adresse 0x1234. Il est nécessaire de scruter le registre de status jusqu'à ce qu'il ne soit plus égal à 0. Une implémentation naive et incorrecte pourrait être comme cela :
uint8_t * pReg = (uint8_t *) 0x1234;

// Wait for register to become non-zero.
while (*ptr == 0);
// Do something else.
Cela va très certainement ne pas fonctionner dès que vous allez autoriser les optimisations du compilateur, du fait que le compilateur va générer de l'assembleur qui va ressembler à ça :
     mov ptr, #0x1234
    mov a, @ptr
loop bz loop
La logique de l'optimisateur est assez simple : ayant déjà lu la valeur de la variable dans l'accumulateur (à la deuxième ligne de l'assembleur), il n'y a pas besoin de la relire puisque la valeur sera toujours la même. Ainsi, en troisième ligne, on abouti à une boucle infinie. Pour forcer le compilateur à faire ce que nous voulons, nous modifions la déclaration en :
uint8_t volatile * pReg = (uint8_t volatile *) 0x1234;
L'assembleur va maintenant ressembler à ça :
      mov ptr, #0x1234
loop  mov a, @ptr
     bz loop
Le comportement désiré est obtenu.

C’est dans ce genre d’exemple qu’on s’aperçoit qu’il est toujours bon de savoir ce qui se passe en dessous (en assembleur) du langage que l’on utilise (le langage C).

La programmation sur Nintendo DS regroupe un ensemble d'avantages certains pour le jeune programmeur (comme pour les moins jeunes comme moi :) ) :

- programmation directe pour la machine : il n'y a pas de système d'exploitation entre le programme que vous concevez et la machine. Cela oblige à comprendre comment fonctionne réellement un système embarqué, et un système informatique tout court.

- programmation d'une console de jeu : c'est motivant (c'est fun quoi :) ) parce qu'on peut arriver à avoir beaucoup d'effets graphiques 2D, 3D et sonores, et puis il y a aussi une véritable tablette graphique, une connexion réseau Wifi, un microphone intégré (et bientôt un appareil photo sur la nouvelle console Nintendo DSi)

- simplicité du kit de développement grâce à devkitpro qui contient tout ce qui est nécessaire pour développer correctement sur Nintendo DS. Cela permet d'apprendre le langage C pour ce qu'il a de meilleur : un accès très bas niveau et performant.

Aujourd'hui, j'imagine que pour un gosse qui découvre l'informatique et veut y mettre les mains, la Nintendo DS est bien plus motivante, dans un premier temps, que d'attaquer directement des systèmes embarqués ou de la programmation Web. Il est toujours important de s'essayer dans le domaine où on a le plus d'endurance aux échecs, là où vous retrouverez le plus facilement de la motivation même en face de problèmes insondables. Garder du plaisir à programmer c'est ça qui permet d'aller au delà des bugs et problèmes, et d'aboutir à des systèmes géniaux comme ce à quoi ont aboutis les concepteurs de la Nintendo DS.

Dans un deuxième temps, après s'être fait la main sur cette console, on peut toujours se tourner vers des systèmes qui nous plaisent mieux, comme des systèmes embarqués (Arduino ou le .NET Micro Framework par exemple), des systèmes d'exploitation (Linux ou pourquoi pas OpenBSD, voire même s'essayer à décoder les tripes de Windows) ou encore des applications Web / SGBD...

Les télécoms et leurs acronymes

2009-02-05T08:00:00.000-08:00

Dans tout métier, il y a un jargon qui permet de parler plus rapidement de choses reconnues et employées par toutes les professionnels du domaine. Pour aller encore plus vite, on peut aussi employer des acronymes ou des abréviations. Ils permettent :

- d’accumuler en un minimum de lettre un ensemble de mots

- d’aider sa mémoire en fournissant de fait, des mnémoniques pour la remémoration de choses complexes, abstraites ou longues.

On peut aller encore plus loin en construisant des acronymes à partir d’autres acronymes, comme par exemple l’acronyme issu du domaine des Télécommunication : LNS qui veut dire L2TP Network Server, où L2TP veut dire Layer 2 Tunneling Protocol. On peut bien sur en citer d’autres : AJAX, GTK…

Quand les acronymes d’un domaine professionnel arrive dans le grand public, on arrive souvent à des incompréhensions, des exclusions entre les personnes qui savent et les personnes qui ne comprennent pas.

Par exemple, l’acronyme PCMCIA bien connu des informaticiens, est inconnu pour la plupart des personnes qui achète un PC portable grand public, mais c’est pourtant un élément mis en avant sur les étiquettes destinées aux acheteurs. Aujourd’hui on n’en parle plus puisque personne ne comprend ce terme. Il y en a même qui ont finit par traduire PCMCIA par un rétro-acronyme : People Can't Memorize Computer Industry Acronyms.

Quel est l’informaticien qui a retenu ce que PCMCIA veut dire : Personal Computer Memory Card International Association Maintenant, les cartes PCMCIA sont appelée PC Card, terme hypergénérique qui ne veut rien dire en particulier si ce n’est que c’est une carte qui va dans un PC.

Le domaine des télécom est celui où j’ai vu le plus d’acronymes employés. Les acronymes sont parfois en français ou en anglais. Toute la journée, il n’y a pas une phrase où on n’emploie pas un. Ce sont parfois des acronymes du domaine des télécom, mais ce sont aussi des acronymes spécifiques à l’entreprise. Il faut plusieurs mois, voire plusieurs années pour s’y retrouver. Il y en a tellement que leur décomposition en mot n’est parfois plus connue par les gens qui les emploie.

Quand j’écoute mes collègues travailler, discuter, et quand je m’écoute parler (ça m’arrive souvent :) ), je me rends compte que réellement, toutes les phrases, sans exception, emploie au moins un acronyme. Comme derrière un jargon, il est facile de se cacher derrière eux. On a toujours l’impression de passer pour plus intelligent que l’on est, comme s’ils allaient de soi et que si vous ne le connaissez pas, c’est que vous êtes certainement dépassé.

Un des livres qui m’a permis de mieux comprendre l’ensemble des acronymes du domaine des télécoms est Telecommunications Essentials (2nd Edition) de Lillian Goleniewski. L’intérêt de ce livre est qu’il couvre l’ensemble du domaine, ce qui est assez impressionnant en 928 pages. Il ne rentre pas dans les détails les plus infimes de chaque protocole, technologie ou standard, mais va suffisamment loin pour permettre une compréhension solide de tout ce qui a trait aux télécoms (du champ électromagnétique aux architectures de service sur IP, en passant par le bon vieux téléphone RTC…)

Mais tout cela prend du temps, bien qu’ayant eu une formation en informatique et télécommunications, il faut quand même plusieurs années pour maîtriser l’ensemble des acronymes qu’il est nécessaire d’utiliser pour construire les offres de service de télécommunication d’aujourd’hui. Car, comme dans la plupart des domaines, une entreprise offre une valeur ajouté à un client, quand elle arrive à intégrer l’ensemble des technologies (on parle souvent de convergence, puisque des technologies différentes, voix, réseau, video, services, convergent vers une offre de service particulière au client). Or pouvoir construire des offres convergentes, nécessite de comprendre la multitude de technologies en présence, même s’il n’est pas nécessaire de les maîtriser.

Au-delà des acronymes, le jargon des informaticiens est parfois imagé et enrichi par des néologismes, et étrangement, le français n’est pas délaissé. En voici un florilège :

- Babasse: nom générique pour un ordinateur (voir aussi ordi ou bécane). Son utilisateur s'appelle un babasseur, on dit souvent babasseur fou quand il y a excès.

- Brouteur : Jeu de mot avec le terme routeur, machine qui achemine les paquets réseaux. Fréquemment utilisé lorsque celle-ci sature.

- CLCLMPALC : Comité de lutte contre les messages persos à la con : message utilisé principalement par les amoureux de la langue française, de l'orthographe, de la syntaxe, et des belles phrases, en guise de contestation à l'émergence d'un nouveau style d'écriture, se retrouvant dans les messages personnels dans certains logiciels de messagerie instantanée, ou encore dans les forums.

- Impacter : avoir un effet

- Interface chaise-clavier : surnom péjoratif donné à l'utilisateur. Souvent utilisé comme manière détournée de dire qu'un problème informatique a comme origine l'utilisateur.

- PetitMou : Traduction française (péjorative) du nom de Microsoft (micro = petit et soft = tendre, doux, ou mou dans le cas présent) En vogue dans les années 1990, probablement apparu avec Windows 95.

- Plat de spaghettis : Se dit d'un programme non structuré, dont le déroulement est aussi aisé à suivre que de trouver les extrémités correspondantes de spaghettis dans une assiette.

- Prout : Abréviation française peu élégante du terme iproute, ou routage IP.

- Usine à gaz: lorsque, généralement suite à de nombreuses maintenances successives ou en raison d'une mauvaise identification des cas généraux au profit des cas particuliers, un logiciel est devenu trop compliqué et inefficace, il devient "une usine à gaz". Sa refonte et la suppression du code mort sont alors impératifs.

- Windaube : Surnom irrévérencieux donné au système d'exploitation Windows de Microsoft afin de stigmatiser ses imperfections.

Je ne vous parle pas des acronymes récursifs qu’affectionnent les hackers.

Disque dur externe et capitalisation

2009-01-29T08:00:00.000-08:00

Pourquoi faire simple quand on peut faire compliqué. Étant en possession d’un disque dur externe de 120Go Western Digital (il n'en font plus des comme ça, le remplaçant étant le Western Digital My Passport Essential), j’ai pour objectif d’y déposer tout mon environnement de travail, que ce soit les applications ou les données que j’utilise au jour le jour.

Mon but est de ne plus avoir besoin de quoi que ce soit sur le disque dur interne du PC sur lequel je travaille, de considérer réellement le PC comme un terminal banalisé, interchangeable de façon transparente avec n’importe quel autre PC Wintel compatible.

Mais pourquoi tant d’efforts pour être indépendant de la machine ? Tout simplement parce que je suis parti du constat suivant :

- tout d’abord entre mes lieux de travail (j’en ai plusieurs), chez moi, chez des amis ou la famille, je suis amené à travailler avec 8 PC différents :

3 PC au travail (1 desktop pour le développement, 1 ordi portable, 1 desktop chez le(s) client(s) )
4 ordinateurs chez moi (3 ordi portable + 1 vieux PC de 1998)
1 PC différent par ami ou la famille

- Sur tout ces PC, des systèmes d’exploitations différents sont installés (principalement Windows et Linux, mais aussi un OpenBSD).

- Quand je change de projet, de mission ou de client, quand le temps passe et que mes PC deviennent obsolètes, je dois les changer et me retrouve avec des PC vierge de toute installation environ tous les deux ans.

- J’aime travailler avec des environnements riches en outils (130 applications installées sur mon disque dur externe pour le moment)

Bref, l’installation d’environnements complets entièrement adaptés à mes besoins prend beaucoup de temps et je ne peux pas me permettre d’installer certains outils sur tous les PC que je rencontre.

Ainsi, il est apparu bien pratique de posséder un disque dur externe d’une capacité suffisante pour y stocker :

- toutes les applications de bureautique, de développement (y compris des serveurs comme par exemple Jboss Server, Apache httpd/php/mysql), de loisirs dont j'ai besoin

- Toutes mes données de travail, et ce de façon sécurisée et facilement backupable.

Globalement, sur le disque dur externe, j’ai :

- à la racine, un fichier script d’initialisation par type d’environnement (1 pour Windows, 1 pour Linux, etc.) qui s’exécute au branchement sur le PC du disque dur et configure le PC d’une certaine manière pour me permettre de lancer n’importe quelle application sans problème. Il s’agit notamment de déclarer des variables d’environnement utilisées par les outils.

- Dans un répertoire soft non-crypté, j’ai rassemblé l’ensemble des applications Windows de mon environnement. Chaque application est dans son répertoire dont le nom est construit de la manière suivante : nomduproduit-version (par exemple emacs-22.2). Les applications sont la plupart du temps déposées directement dans ce répertoire, sans configuration particulière. Je ne backup pas le répertoire soft, considérant que si le disque dur est défaillant, je pourrai toujours retrouver les applications sur internet et les réinstaller.

- Je crée des volumes truecrypt (plusieurs s’il le faut) pour y stocker toutes mes données de travail. Ces volumes sont encryptés avec un mot de passe dur. Je crée des volumes truecrypt d’une taille de 4Go histoire de pouvoir facilement les graver sur un DVD-ROM pour faire des backups, et formatés en FAT32 histoire de ne pas avoir de sécurité associée à tous les fichiers et pouvoir ainsi passer de PC en PC sans problème. Les scripts de démarrage me demandent mon mot de passe et montent automatiquement ces volumes sur le système hôte. L'intérêt de truecrypt, c'est qu'il fonctionne aussi sous linux, ça permet d'ouvrir mes volumes truecrypt quelque soit le système d'exploitation.

- Un script de fermeture (appelé « stop ») permet de déconfigurer proprement l’environnement pour le remettre comme précédemment, d’arrêter toutes les applications issues du disque dur externe et de démonter les volumes truecrypt

- Un menu avec des liens vers toutes les applications installées sur mon DD externe est placé dans le menu Démarrer / Programme de l’utilisateur en cours. Cela permet de retrouver des liens pour lancer toutes les applications disponibles.

- J’ai même mis un Raccourci vers Emacs dans le menu contextuel SendTo (Envoyer vers) histoire de pouvoir envoyer n’importe quel fichier vers mon éditeur préféré.

Concrètement, lorsque je branche mon DD externe sur un machine Wintel, une fenêtre me demande automatiquement mon mot de passe truecrypt, puis monte les volumes truecrypt grâce à ce mot de passe et configure tout l’environnement pour permettre à toutes les applications de fonctionner.

Je lance automatiquement svnserve sur un repository placé sur un disque crypté. J’ai ainsi tout un environnement de développement avec versionning prêt à l’emploi et configuré pour s’intégrer avec Emacs.

Ainsi, dès que j’ai une nouvelle application à essayer, des nouveaux composants emacs lisp à installer, le temps que je passe à installer les composants sur le disque dur externe est capitalisé pour l’avenir et je n’ai pas à refaire toutes les manipulations sur chaque PC que j’utilise.

Pour ce qui est des applications Windows qui doivent absolument utiliser la base de registre, j’utilise l’outil sandboxie qui permet de faire fonctionner toute application dans un bac à sable entièrement fermé. Mais finalement, après 2 ans d’utilisation de mon disque dur externe, je m’aperçois que je n’utilise jamais d’application de ce type, et donc je ne recours jamais à sandboxie.

Quand mon installation prend un certain nombre d’opérations manuelles non évidentes, ou pas très bien décrites dans le manuel utilisateur, je me construis une check-list reprenant l’ensemble des étapes que j’ai réalisé pour installer le logiciel. Cela m’assure que si mon disque dur externe plante, je peux très rapidement réinstaller le logiciel sans trop réfléchir.

Globalement, je ne regrette vraiment pas d’avoir tout passé sur ce disque dur externe. Avec 5400RPM sur USB 2.0 (480Mb/s), la vitesse de transfert me suffit amplement pour travailler correctement.

La base de données cette inconnue...

2009-01-22T18:29:00.001-08:00

Aujourd'hui, la plupart des applications développées sont des applications Web. Non pas qu'on ne construise plus d'autres types d'applications, mais, en quantité d'applications développées, ce sont bien les applications de types Web qui sont les plus nombreuses.

Quand on analyse ce qui constitue la plupart des applications Web, on s'aperçoit ensuite que chaque site Web est secondé par une base de données en arrière plan. Ce qui fait la force du Web c'est la facilité avec laquelle il est possible de publier des données en grand nombre et d'offrir des fonctionnalités sur ces données. Quand les années passent, les technologies de présentation des données (client lourd, client Web...) sont les premières à faire les frais de l'apparition de nouveaux concurrents. Mais, en arrière plan, la base de données est toujours là, fidèle au poste, toujours aussi importante dans l'architecture globale de l'application.

Quand on veut faire carrière dans l'informatique, on cherche à maitriser les outils dont on dispose et qui sont généralement mis en œuvre dans les projets. Personnellement, je n'ai pas le temps de réapprendre tous les 3 ans une nouvelle technologie de présentation (par exemple, en ce moment, c'est le phénomène Adobe AIR et toutes les technologies Flex qui ont le vent en poupe). Je n'ai plus l'age de passer des heures inconsidérées sur mon ordi à essayer la moindre nouveauté.

Et puis, les technologies se succédant les unes aux autres, on s'aperçoit que, bien que nouvelles, elles ne sont pas innovantes, ce ne sont que de nouvelles créations, très reluisantes, mais n'apportant pas de réelle nouveautés. Dans ce cadre là, un programmeur a tout intérêt à maîtriser au moins un système de gestion de base de données quel qu'il soit pour avoir à se pencher sur les défis réels de la mise en place de sites web : la montée en charge d'une application à accès concurrents.

Le coût global d'une requête Web sur un site Web secondé par une base de données est en grande partie due à l'accès et au traitement de la donnée, pas à se mise en forme à travers des pages HTML, Ajax, ou autre. Avec un jeu de données de test automatisé, et un grand nombre de requêtes clientes, le programmeur est tout de suite confronté à un problème de capacité. Il doit surtout faire preuve de maîtrise de son système de gestion de bases de données pour pouvoir le régler correctement pour répondre à la demande, et ce pour toutes les requêtes concurrentes.

La maîtrise d'une technologie comme Oracle, PostgreSQL ou MySQL prend déjà tant de temps que je ne vois pas où est l'intérêt de passer tout son temps sur des technologies de GUI qui évoluent au gré des modes et du temps. De toute manière, il existe de nombreux outils de développement suffisamment évolués pour ne pas avoir à taper une ligne de codes pour réaliser les tâches les plus classiques de la couche présentation.

Je ne comprend pas pourquoi tant de développeurs que j'ai côtoyé utilisent le système de gestion de base de données comme une boîte noire, comme étant juste un système de persistance d'objets. L'erreur classique est de trouver du code itératif dans une couche métier Java alors qu'une simple requête SQL aurait suffit. Les systèmes de persistance comme Hibernate ont longtemps promu des méthodes de programmation où le système de gestion de bases de données est réduit à une réceptacle abstrait et dont on doit absolument pouvoir interchanger si l'humeur nous en dit. Or, tous ces systèmes d'abstraction vis à vis du SGBD sont finalement la plus part du temps complètement inutiles sachant :

- qu'il est extrêmement rare de changer brusquement de technologies de base de données puisque, à part faire un mauvais choix, la plus part des SGBD sont maintenant extrêmement bien rodés pour ce qu'ils ont à faire.

- qu'on a tout intérêt à tirer au maximum partie des services offerts par le SGBD pour réaliser les fonctionnalités à implémenter car le paradigme de programmation SQL, bien qu'imparfait, reste toujours supérieure à une approche procédurale classique quand il s'agit de traîter des lots de données.

- si on doit utiliser un SGBD payant comme Oracle, c'est vraiment du gâchis de le considérer comme une boîte noire et de ne pas utiliser toutes les fonctionnalités que vous avez chèrement payées.

Tom Kyte résume très bien cette situation dans son livre Expert Oracle Database Architecture :

The single most common reason for database project failure is insufficient practical knowledge of the database - a basic lack of understanding of the fundamental tool that is being used. The black box approach involves a conscious decision to protect the developers from the database - they are actually encouraged to not learn anything about it ! In many cases, they are prevented from exploiting it. The reasons for this approach appear to be related to FUD (Fear, Uncertainty, and Doubt). The accepted wisdom is that database are "hard", and that SQL, transactions, and data integrity are "hard". The solution: don't make anyone do anything "hard". They treat the database as a black box and have some software tool generate all of the code. They try to insulate themselves with many layers of protection so that they do not have to touch this "hard" database.

Philip Greenspun le disait déjà de son temps dans Philip and Alex's Guide to Web Publishing :

Any interesting Web/RDBMS problem can be solved using just the standard software shipped with the RDBMS. If you can't solve it with those tools, you can't solve it with any tool no matter how glitzy and turnkey. The critical element is not the tools, it is the programmer.
In terms of maintainability, clarity of code, software development cycle, and overall Web server performance and reliability, the simplest tools such as Microsoft Active Server Pages are superior to virtually any of the expensive Web development systems out there.

Il est vraiment dommage de ne pas s'intéresser à son SGBD car il permet pourtant de réaliser de grandes applications, solides et montant correctement en charge. De plus, il permet de faire face à des situations délicates de façon élégante.

Propriété intellectuelle et développement au forfait

2009-01-15T08:00:00.000-08:00

A chaque fois que je développe un logiciel au forfait, je ne sais jamais quelle licence mettre en haut de chaque fichier source. Les contrats de développement au forfait ne sont pas toujours explicites sur le sujet de la propriété intellectuelle. Quelle est la loi qui s'applique ? quelles sont les jurisprudences en la matière ? Je suis tombé sur la collection de ressources juridiques du Munci qui donne pas mal de pointeurs vers des documents intéressants, notamment à propos du contrat de développement de logiciel spécifique. La nature juridique est énoncée en ces termes :

La nature juridique du contrat de création (développement) de logiciel ne pose donc pas de problème particulier : l’élaboration d’un logiciel constitue une prestation de service et entre donc dans le cadre d’un contrat d’entreprise ou louage d’ouvrage (article 1710 Code civil contrat « par lequel l’une des parties s’engage à faire quelque chose pour l’autre moyennant un prix convenu par elles »).

L’originalité juridique du louage d’ouvrage est double : le contrat est valable, bien que les prestations essentielles, l’ouvrage et le prix, puissent être dans les faits largement indéterminées ; le concepteur de logiciel ne peut savoir à l’avance quelles seront les difficultés présentées par celui-ci et le prix dépendra souvent du temps passé qui ne peut être fixé avec précision. Ces contrats échappent à la nullité car les parties s’entendent pour enfermer l’indétermination dans certaines limites.

En effet, ce qui est assez déroutant pour le chef de projet néophyte, c'est que le contrat n'est pas complet sur ce qui va être livré tout en obligeant à s'engager sur le résultat. La programmation s'apparente à une œuvre de l'esprit et tombe ainsi sous la loi des droits d'auteurs :

Le contrat de développement n’emporte pas cession automatique de la propriété du logiciel ; les règles du contrat de louage veulent que la propriété du résultat soit transmise au client, mais le contrat doit le prévoir expressément, faute de quoi le droit commun s’applique et c’est le créateur du logiciel qui en est le propriétaire.

Néanmoins, CA Bordeaux 24 sept. 1984 décide que même dans le silence du contrat, le prestataire est tenu de transmettre le code source du logiciel au client afin que celui-ci puisse en faire assurer la maintenance. L’arrêt, isolé, ne va pas jusqu’à dire que le prestataire doit transmettre ses droits de propriété au client, et CA Montpellier (2 juillet 1991) a jugé que « la mise à disposition de l’utilisateur des sources, surtout s’agissant d’un logiciel spécifique, n’est pas de nature à établir une cession de tous les droits d’auteurs ». La doctrine estime toutefois qu’il peut s’agir d’un indice permettant de déduire, combiné par exemple au prix payé, que les droits d’exploitation ont bien été cédés.

Ainsi, si rien n'est dit, le propriétaire du code source est le fournisseur, et celui-ci donne le droit au client d'exploiter (maintenir) le code source uniquement pour son usage personnel. Le code source étant la propriété du fournisseur, il peut réutiliser les sources pour un nouveau projet au forfait. Les marchés publics contiennent toujours une partie cession de la propriété intellectuelle au client et il est malheureusement impossible d'utiliser le code source pour d'autres projets. Ainsi, je met toujours :

Copyright (c) [ANNEE], [PROPRIETAIRE]
All rights reserved.

en haut de chaque fichier source, avec pour PROPRIETAIRE soit ma société si le client ne requiert pas de transfert de propriété, soit le client, s'il y a transfert de propriété. Normalement, un logiciel avec transfert de propriété intellectuelle doit être vendu plus cher qu'un logiciel sans cession de propriété. Il est toujours assez triste de laisser partir du code source qu'on a mis tant de temps à peaufiner, tous les jolis composants réutilisables que vous avez concoctés ne peuvent même pas vous servir. Dans le cas de cession de propriété intellectuelle, cela ne pousse pas à concevoir l'architecture du logiciel pour promouvoir la réutilisation.

Parfois les clauses de cession de propriété intellectuelle sont abusives, c'est ce que nous rappelle le document Clauses et Pratiques des Contrats Informatiques de Droit Privé :

Les prestataires informatiques ont pris note de l’insertion de nombreuses clauses inacceptables dans les contrats parmi lesquelles on compte, notamment, les clauses suivantes :

- Clauses précisant que les spécifications développées par le prestataire dans le cadre de l’exécution du contrat appartiennent au client et cela même dans le cadre de la sous-traitance et lorsque ces développements sont réalisés atour d’un progiciel. [...]

- Clauses donnant le sentiment au prestataire que le client lui impose la cession de la propriété d’un progiciel ou encore la délivrance des codes sources dans le cadre de contrats portant sur des licences d’utilisation de progiciel standard ou en cas de résiliation du contrat,

- Clauses excluant toute possibilité de résilier une licence accordée à un utilisateur lorsque ce dernier l’a revendue à un tiers. Ce type de clause organise la violation du droit d’auteur.

Il convient de prêter attention au moment auquel intervient le transfert de propriété. Les clients demandent souvent au prestataire de prévoir un transfert de propriété au fur et à mesure de la réalisation alors que le transfert doit s’opérer postérieurement au prononcé de la recette sans réserve et après complet paiement.

L'aspect propriété intellectuelle est souvent mise de coté, ignorée, sous-estimée alors qu'elle peut avoir des conséquences importantes sur les projets futurs qu'ils soient chez le client ou chez le fournisseur. Des sociétés entières ont fondé leur succès commercial uniquement sur la propriété intellectuelle, comme par exemple ARM, ou encore Thomson qui tire la majeure partie de son chiffre d'affaire de vente de licence d'utilisation de ses brevets et logiciels.

Mémorisation, apprentissage et éducation

2009-01-13T08:00:00.000-08:00

Tout le monde cherche à être "productif". Mais on peut vouloir être productif dans son travail :

soit pour pouvoir faire plus avec autant de temps,
soit pour pouvoir faire la même chose avec autant de temps mais avec beaucoup moins d'effort.

En informatique, où les lazy programmeurs sont légions, c'est souvent le deuxième point qui est mis en pratique. C'est bien sur mon cas. Les outils, techniques, procédures, templates servent à faire autant avec beaucoup moins d'effort. Tous ces artifices sont le reflet des limites de nos capacités mentales et physiques... S'il y a bien un domaine où je suis limité c'est ma mémoire. J'ai toujours du mal à retenir des choses sur le long terme...

C'est pour cette raison que j'ai découvert avec énormément de bonheur que les techniques et mnémoniques décrites dans Your Memory de Kenneth L. Higbee, fonctionnent et son vraiment puissantes. Je me suis dit, quand à essayer de nouvelles techniques pour apprendre à mémoriser, la première chose à apprendre est l'ensemble des techniques d'apprentissage décrites dans ce livre.

J'ai utilisé la mnémonique de liaison (Link Mnémonique) pour apprendre l'ensemble des éléments essentiels du livre. Un des principes évoqués est l'organisation du contenu à apprendre. On oubli beaucoup plus vite du contenu non-structuré par rapport à du contenu organisé logiquement. Il est donc conseillé d'organiser ce que l'on apprend autour d'un système d'archivage mental ("mental filing system"). Les mnémoniques sont des outils puissant, mettant en œuvre naturellement tous les principes de base de la mémorisation, dont l'organisation.

Ainsi, j'ai commencé par apprendre la liste des chapitre sur une première chaine de liaison mnémonique, puis sur chaque chapitre j'ai créé une sous chaine de liaison mnémonique pour tous ces sous-chapitres, etc. jusqu'à arriver à mémoriser chaque idée principale de chaque sous-chapitre de chaque chapitre. Ce qui est étonnant c'est avec quelle facilité on arrive à apprendre des choses concrète et visuelle par rapport à des choses abstraites. Grâce à la mnémonique de liaison, on mémorise uniquement des aides à remémoration sous forme d'objet concret et nets, mis en scène avec les objets suivants à travers des scènes frappantes pour l'esprit.

Suite à ce petit succès, qu'est-ce qu'il serait intéressant de retenir pour être encore plus productif en tant qu'informaticien : les design patterns du GoF ? bof..., Java for dummies ? Certainement pas. Tous les trucs et astuces pour nettoyer la maison, évidemment, car avec ça, on optimise le temps passé sur une activité essentielle, cela permet après de se concentrer sur l'informatique. Bon, ok, on peut toujours faire appel à une femme de ménage...

Personnellement, s'il y a un seul bouquin informatique pour lequel je serais prêt à investir du temps à en mémoriser les bonnes pratiques, c'est Code Complete 2 de Steve McConnell, car c'est un bouquin assez "intemporel" (le mot fait rire en informatique) et est assez bien organisé. Mais bien sur, la programmation ne s'apprend pas dans les livres, mais uniquement avec la machine pour interlocuteur.

Il y a la mémoire à court-terme, la mémoire à long-terme et la mémoire sensorielle. Cette dernière sert aussi grandement en informatique. En effet, la mémoire sensorielle est ce qui est le plus essentiel en informatique car c'est elle qui vous permet de taper sur votre clavier à la vitesse d'un éclair. La vitesse de frappe est ce petit secret inavouable du monde de l'informatique. La productivité d'un programmeur se mesure au nombre de caractères à la minute qu'il est capable de débiter puisque le résultat de son travail passe par le clavier.

Enfin, quel que soit le type de mémoire, j’ai toujours l’impression que les techniques de mémorisation sont méprisées par les enseignants, quelles sont vues de haut et ne sont pas considérées comme suffisamment noble comme peuvent l’être la compréhension, la pensée créative et critique, pour être étudiées et transmises à travers de véritables cours d’apprentissage. Kenneth L. Higbee nous rappelle très clairement ce qu’il en est :

Two points may be made regarding the role of memory relative to loftier goals or “more laudable, higher mental processes” in school. First, whether we like it or not, there is lot of straight memory work in school. Education consists of “basic school tasks” involving list and paired-associate learning, as well as “complex school tasks” like meaningful prose learning. […] The fact is that the loftier educational goals are in addition to, not instead of, memorization.

[…] The second point regarding the role of memory in education is that remembered facts serve as the basis for the loftier goals.

Je me rappelle du collège et du lycée, je trouve qu’il aurait été intéressant de connaître ces techniques à ce moment là. Enfin, le passé n’existe plus, seul le présent est important mais la mémoire s’écrit au futur.

Incantation Perl

2009-01-11T06:42:00.000-08:00

Étant en train de lire Object Oriented Perl de Damian Conway, de petites perles de programmation m'apparurent comme cette merveilleuse façon d'implémenter un itérateur en Perl :

package Iterator;
$VERSION = 1.00;
use strict;

sub new {
   my ($class,@data) = @_;
   @data = @$class if !@data && ref($class);
   bless [ @data ], ref($class)||$class;
}

sub each {
   my ($self) = @_;
   my @next = splice @$self, 0, 2;
   return wantarray? @next : $next[0];
}

Pour le hacker en Perl, rien de plus trivial que de coder de cette manière. Pour celui qui ne parle pas cette langue, c'est tout de même assez déroutant. Le succès de Perl en son temps, était du en parti à sa simplicité de mise en œuvre, à sa disponibilité sur toutes les plateformes. Comme nous le dit très bien Michael Schwern dans sa présentation "Perl is unDead" lors de la YAPC::Asia 2008, il s'agit de ce qu'il nomme le Folk Programming :

Ce qui fait qu'un langage de programmation émerge et fini par être utilisé par tout le monde, c'est son adoption par le peuple des programmeurs de base, puis le constat de son omniprésence par les managers dans les entreprises. L'adoption se réalise quand le langage apporte avec lui une nouveauté, un moyen de faciliter et d'accélérer le développement. En son temps, Perl apportait une facilité de programmation sans commune mesure avec ce qui se faisait alors. De plus, il profita de l'arrivée du Web et de son modèle de développement très rapide et itératif car il était devenu très simple de coder quelque chose en Perl et d'avoir immédiatement le résultat sur son écran, un feedback en quasi temps-réel en quelque sorte.

Mais tout ça c'était les années 90. Aujourd'hui pour faire de la programmation orienté objet en Perl, on est loin de la simplicité des autres langages. Cela fait longtemps que Perl n'est plus le choix le plus évident, qu'il n'offre plus de nouveautés vraiment intéressantes pour le programmeur de base. Depuis, nombreux sont les logiciels qui ont apportés des nouveautés que Perl n'a pas su fournir le premier : Rails sur Ruby, PHP et son extrême simplicité (un langage fourre-tout), JavaScript et Web2.0 ... Si Perl veut revenir sur le devant de la scène, c'est en proposant des moyens aussi simples et puissants tout en proposant de nouvelles techniques encore plus indispensables.

C'est l'objet notamment de Perl6 et de sa machine virtuelle Parrot. Comme pour s'approprier les succès de ses pseudo-concurrents, Perl6 vise à proposer une machine virtuelle réellement optimisée pour les langages dynamiques, et réellement portée sur de nombreuses architectures (pas comme Java qui se targue de permettre de la programmation multi-plateforme, mais qui ne supporte que 3 systèmes (Linux sur x86/x64, Solaris, et Windows) alors que perl a été portés sur une centaine de systèmes)

Cette machine virtuelle permettra de faire fonctionner ensemble des programmes écrits dans des langages différents, un peu comme la .NET CLR (ou la JVM aujourd'hui où l'on voit apparaître de nombreux langages compilant du bytecode, comme JRuby). L'important c'est que cette machine virtuelle ait été conçue dans le même esprit que perl : TIMTOWTDI. Elle permet de faire fonctionner des langages aussi compliquer à implémenter que Perl tout en permettant de faire tourner des langages comme Ruby, PHP, et pourquoi pas Java d'ailleurs. C'est ce que nous explique le Primer Parrot :

Parrot is designed with the needs of dynamically typed languages (such as Perl and Python) in mind, and should be able to run programs written in these languages more efficiently than VMs developed with static languages in mind (JVM, .NET). Parrot is also designed to provide interoperability between languages that compile to it. In theory, you will be able to write a class in Perl, subclass it in Python and then instantiate and use that subclass in a Tcl program.

Personnellement, je verrais bien Parrot comme machine virtuelle d'un Emacs refondu à la sauce XXIème siècle. En ajoutant à Parrot les types de base de Emacs (buffer, window, frame, ...) on devrait pouvoir porter un compilateur elisp vers Parrot et avoir l'éditeur de texte le plus puissant du marché :) Ça permettrait de palier à la lenteur de la machine VM de Emacs (qui d'ailleurs, et ce n'est peut-être pas une coïncidence, a été codée initialement par James Gosling, le papa de Java et de la JVM).

Gentoo Linux, grandeur et décadence de Portage

2008-12-11T08:00:00.000-08:00

De nombreuses fois je me suis dit qu'il serait intéressant de voir comment marche la distribution Gentoo Linux. Ayant un peu d'expérience dans le monde *BSD, et une utilisation purement gui-oriented de Ubuntu, je me suis dit qu'il serait intéressant de voir d'un peu plus près comment fonctionne une distribution orientée package, c'est à dire qui offre toute la souplesse d'installation de package comme dans les distributions *BSD, tout en permettant un maximum de configurabilité de ceux-ci.

Donc, je viens de faire mes premiers pas avec Gentoo Linux et son système de gestion de package nommé "Portage". La documentation Gentoo est assez clair lorsqu'il s'agit de faire l'installation de base d'un système Linux sur un PC, le tout, en ligne de commandes pour autoriser un maximum de flexibilité.

Quelques fdisk, chroot et grub plus tard, j'arrive enfin à rebooter et démarrer pour la première fois un Gentoo Linux sur mon vieux laptop, un Packard Bell Easynote C3300 (S/N:101981130134). Oui, c'est vraiment un vieux portable, de 2004 si je me souviens bien. Bien que la soufflerie soit bruyante, l'ensemble de ce laptop reste assez cohérent avec 512Mo de mémoire (dont 32Mo de mémoire partagée pour la carte graphique sis740 intégrée).

De base, la configuration ACPI marche bien (ce qui n'est pas le cas avec FreeBSD par exemple) ce qui fait que la soufflerie fini quand même à s'arrêter au bout d'un moment.

Le système Portage, et surtout la commande "emerge" est très pratique. Pour chaque package, il y a une gestion cohérente des numéros de version, et surtout des dépendances entre packages. Tout cela est écrit dans un fichier ebuild (1 fichier ebuild par package) qui rassemble l'ensemble des dépendances et contraintes sur le package.

De plus, comme un package a des fonctionnalités en option (comme le support d'une interface x11 par exemple, ou l'utilisation de gtk plutôt que qt4) les options que l'on souhaite supporter sont stockées dans une variable d'environnement nommée USE. Celle-ci, définie globalement au niveau du fichier /etc/make.conf ou localement sur la même ligne de commande que emerge, permet de lister l'ensemble des drapeaux (USE flags) indicateur de fonctionnalités supportée.

Par exemple, il suffit de mettre USE="gnome gtk -kde -qt3 -qt4" pour que tous les outils que vous téléchargez et compilez avec emerge le soit pour gnome et pas pour kde et les librairies qt.

Jusqu'à quelques temps, tout allait bien, mais c'est quand j'ai voulu installer gnome, et donc xorg avant tout, que ça c'est mis à devenir plus compliqué.

Moi, benoîtement, j'essaie un truc comme ça :

emerge --pretend gnome

histoire de voir ce que va faire emerge pour installer gnome. C'est alors qu'il m'indique tout un tas de dépendances circulaires entre les drivers video et les composants de base xorg. Un rapide tour vers la documentation gentoo me laisse en plan avec cette phrase sibylline :

Two (or more) packages you want to install depend on each other and can therefore not be installed. This is most likely a bug in the Portage tree. Please resync after a while and try again. You can also check bugzilla if the issue is known and if not, report it.

Même après:

emerge --sync
emerge -auDN world
emerge --depclean
revdep-rebuild

un emerge --pretend gnome me renvoie encore des dépendances circulaires. Aaargs, y aurait-il un bug dans Gentoo lors de l'installation de base de X Windows. Franchement, j'en doute, j'imagine que si c'était le cas, il y aurait eu quelqu'un pour corriger ça tout de suite...

Mais après une recherche avec mon ami Google, je m'aperçois que j'ai trop confiance dans la communauté open source et sa réactivité. Je tombe sur le bug report n°225091 qui montre exactement mon problème. Bon alors là, je deviens plutôt sceptique quant à la robustesse de gentoo linux. Heureusement, je trouve le commentaire #17 pour m'aider et me permettre d'installer X Windows.

C'est là que je me dis que je ne vais pas passer mon temps à résoudre des problèmes de dépendances circulaire alors que précisément, je pensais que Gentoo Linux avait soigné cet aspect dépendance. L'avenir me le dira, je n'abandonne pas maintenant un système qui me paraît malgré tout assez prometteur.

Ce qui est sympa c'est de mettre en place son Linux, petit à petit, du CDROM vers le disque dur tout en pouvant faire des choix à chaque étape. Comme tout est en ligne de commande et qu'il n'y a pas d'installeur à proprement dit tel qu'on en a l'habitude sur Debian ou les *BSD, on arrive à beaucoup plus comprendre ce qui constitue le système, où se trouve tous les fichiers de configuration, d'initialisation, de gestion des packages, etc.

C'est instructif, et permet de mieux comprendre Linux.

Dette technique - Comment la présenter ?

2008-11-08T08:00:00.000-08:00

La dette technique n'est pas quelque chose de nouveau, cette métaphore datant de 1992. On trouve finalement assez peu de textes sur le sujet, et elle mériterait certainement d'être approfondie. Steve McConnell a essayé de classer cette dette dans des catégories. Il est allé jusqu'à essayer de montrer quel genre de dette pourrait être pris sur les projets. Andy Lester a présenté la dette technique lors de la YAPC::NA 2006, dans le ton bien à lui, plein d'humour, de dérision, de conseils vraiment très concrets.

Personnellement, au travail, je rencontre souvent des présentations assez mornes dans leur forme, et c'est bien dommage. Andy arrive à faire rire son assistance, à faire participer et contribuer les personnes présentes, à rendre plaisante sa présentation.

J'ai cru repérer chez Andy ce genre "d'effets" qui permettent de rendre attrayant une présentation :

- mettre très peu de chose sur 1 slide : ne pas surcharger, avoir un seul message par slide, sans fioriture,

- jouer sur l'enchaînement des slides pour introduire de l'humour

- mettre des illustrations qui frappent l'esprit, souvent prises en dehors du monde l'informatique,

Une présentation, ça se prépare, et cette préparation à l'avance permet de "jouer" avec les slides. Les slides ne sont qu'un support, ne servent qu'à établir un fil de narration. Mais en fait, le plus important dans une présentation, c'est le discours, pas les slides. Il ne faut pas chercher à tout mettre dans les slides. Le discours doit être préparé et assimilé à l'avance, et les slides doivent permettre de montrer le cheminement de l'esprit sur un sujet.

Ainsi, dans le discours on retrouve :

- l'explication des énoncés affichés sur les slides,

- des exemples concrets, de la vie réelle, vécus personnellement,

- des questions fermées posées au public, notamment pour demander qui a vécu une telle situation (Andy lève le doigt pour montrer qu'il fait partie de la "réunion")

On retrouve ce genre de technique dans les présentations de Andy Lester, comme celle qu'il a tenue à l'OSCON 2007 :

Si on essaie de mettre toute l'information dans les slides, cela devient vite un fourre-tout, et le présentateur n'a plus vraiment d'interêt, le public s'efforçant de lire l'information à l'écran. Pour partager une expérience, rien ne vaut la relation directe entre être humain, la discussion orale plutôt qu'écrite.

Contribuer en français à Wikipedia

2008-10-16T08:00:00.000-07:00

Quand on parcours le site wikipedia.org, on se rend compte rapidement qu'il y a beaucoup plus de pages en anglais qu'en français. Cela est bien naturel, il y a beaucoup plus de monde parlant plus ou moins couramment anglais que français. De plus, beaucoup de personnes parlant français contribuent à wikipedia en anglais, simplement du fait qu'ils ne souhaitent pas créer de nouvelles pages ou faire une grosse contribution et qu'aucune page en français n'existe sur leur sujet de prédilection.

Face à cet état de fait, on pourrait avoir deux positions différentes :

- abandonner le français, ne consulter et contribuer qu'en anglais à en.wikipedia.org.

- contribuer uniquement en français mais se confronter à un manque flagrant de pages en français.

Si vous pensez que le français peut encore avoir une utilité pour comprendre le monde, on peut adopter la méthode suivante : quand vous consultez une page wikipedia en anglais, posez-vous la question : est-ce qu'il existe l'équivalent en français de cette page ? si oui, est-elle aussi riche que la page en anglais ?

Si la page en français n'existe pas, vous pouvez, au minimum, traduire la page, anglais vers français. Si elle existe, vous pouvez vous assurer qu'il y a au minimum toutes les informations déjà présentes dans la page en anglais.

Avec cette petite méthode, cela permet :

- de s'assurer qu'on a au moins autant d'information que sur la page en anglais,

- de permettre à des contributeurs français de produire des contributions petites ou moyennes sur tous les sujets.

J'ai créé pour la première fois une page entière de Wikipedia en français : Problème de satisfaction de contrainte rejoignant mon intérêt pour ce sujet.

J'ai traduit la page en langue anglaise : Constraint Satisfaction Problem. Même si ce travail ne paraît pas très enrichissant au niveau de wikipedia, cela permet à mon avis de faire grandir globalement (quelque soit la langue) le contenu de cette encyclopédie. Ces pages traduites deviennent le support de nouvelles contributions, la page en français s'éloignant petit à petit de la traduction initiale. Il est toujours intéressant de vérifier qu'on a bien tous les sujets traités du côté anglais et du côté français, les différentes traductions s'émulant mutuellement.

Bien sur, cette méthode peut s'appliquer avec n'importe quelle langue, pas seulement l'anglais et le français.

Quand on contribue à wikipedia, il ne faut pas oublier toutes les dépendances de la page :

- Ne pas oublier de mettre un référence sur la page des abbréviations (par exemple, dans mon cas : CSP)

- Mettre la liste des traductions sur la page et sur la page en anglais.

- Ajouter des liens externes vers des documents en langue française sur le sujet.

Vous pouvez suivre la page que vous avez créée/modifiée. Cela permet de se tenir au courant de l'évolution de vos contributions. Pour ma part, je rajoute dans mon agrégateur de fils RSS le fil des dernières modifications de chaque page qui m'intéresse. Pour ce faire :

- quand vous visualisez une page, cliquer sur l'onglet "historique" en haut de la page

- à gauche dans la case "Boîte à outils" vous avez deux liens : un lien RSS, un autre au format Atom.

Mettez un des deux liens dans votre agrégateur, vous pourrez ainsi suivre toutes les modifications effectuées sur la page sans avoir à sortir de votre outil préféré. Le taux de mise à jour de ces fils sont assez variables selon la page concernée. Il y a malheureusement, quelque fois, des modifications qui sont dues à des volontés de détruire ou brouiller le contenu...

Wikipedia, bien qu'imparfaite, est une encyclopédie qui ne demande qu'à s'améliorer. On peut facilement critiquer son contenu du simple fait qu'il n'y a pas de revue explicite par des experts du domaine. Wikipedia essaie de rester neutre pour référencer le plus grand nombre de définitions. Mais une définition ne suffit pas à la compréhension du phénomène. L'explication des différents aspects d'une réalité passe par le recensement critique des points de vues existants.

La journalisation n'est pas neutre

2008-10-12T08:00:00.000-07:00

Je viens de lire ça sur le blog de Miško Hevery dans son billet Root Cause of Singletons :

The other kind of Singletons, which are semi-acceptable are those which don’t effect the execution of your code. Logging is perfect example. It is loaded with Singletons and global state. It is acceptable (as in it will not hurt you) because your application does not behave any different whether or not a given logger is enabled.

Non, non, non, comment peut-on dire qu'une application n'est pas affectée par l'exécution ou non d'un code dont elle dépend, surtout un système de journalisation (Logger). Un logger peut amener un tas de problèmes. Il suffit de jeter un coup d'oeil sur les changements effectués sur la dernière version stable de log4j par exemple pour prendre peur : une cinquantaine de bugs fixés il y a plus d'un an et pas de release stable officielle depuis malgré une quarantaine de bugs ouverts...

Mais sans parler des bugs, si on réfléchi un minimum à ce que peut faire un Logger comme log4j, on s'aperçoit que, oui, votre application peut avoir un comportement différent simplement du fait de sa dépendance au Logger:

- le logger peut écrire dans un fichier qui peut exploser le disque sur lequel votre application souhaite y écrire des données

- le logger peut écrire dans une base de données et s'arroger pour un temps incertain des connexions qui sont normalement allouées à l'application

- vous ne maitrisez aucunement le temps que passe le Logger à réaliser sa tâche (je vous conseille dans tous les cas, d'utiliser un système de logging asynchrone qui vous rend la main aussi vite que possible. Sous log4j, c'est AsyncAppender qui se charge de ça)

Dans tous les cas, il est important de savoir ce que fait exactement le logger, car le logging est peut-être l'activité la plus répétitive et la plus longue que va réaliser votre programme. Si vous ne voulez pas avoir la désagréable sensation d'être revenu au temps préhistorique (c'est-à-dire, comme sur une machine de plus de 3 ans) quand vous exécutez votre programme, ne laissez pas votre logger vous bouffer. Des systèmes comme Oracle Database Server ont poussé l'expertise jusqu'à en faire une science quasi-exacte ;)

Toute ligne de code a un impact sur l'exécution. J'ai bien dit "Toute ligne de code", même celles qui théoriquement ne seront jamais appelées. Ça m'est déjà arrivé avec du code Visual Basic 6, il y a for longtemps il est vrai, mais c'est une expérience que je ne souhaite absolument pas renouveler...

Moyens de mieux vivre la prestation de service

2008-10-08T08:00:00.000-07:00

En France, le secteur des SSII (Sociétés de Service en Ingénierie Informatique) est fleurissant. Malheureusement, le travail réalisé par leurs employés n'est pas toujours des plus valorisant du simple fait que les clients ne maîtrisent pas ou peu l'outil informatique. Par conséquent, les contrats négociés entre client et SSII se basent surtout sur le TJM (Taux Journalier Moyen) plus que sur l'objectif de la mission de service ou l'expression précise du besoin métier.

Nombre de missions au forfait ou en "assistance technique" sont très peu exprimées au niveau métier, la réflexion et l'analyse de système n'ayant pas ou peu été menée en interne chez le client avant de lancer un appel d'offre.

Cet état de fait abouti souvent à faire travailler directement un employé de SSII dans les équipes du client sans objectif clair sur la mission de service. Cela est prohibé par la loi et nommé « prêt illicite de main-d’oeuvre » et « marchandage dans le cadre d’un contrat pour prestation de services ».

Cette situation se rencontre malheureusement souvent. Elle est rarement poursuivi en justice, ou alors uniquement dans des cas retentissants. Si vous vous demandez si vous êtes dans ce cas, demandez vous si vous vous sentez plus intégré dans les équipes du client qu'à votre SSII. Si c'est le cas, cela montre que la SSII n'apporte aucune valeur ajoutée au client, si ce n'est un rôle de société d'intérim.

Pour éviter d'être dans cette situation là, vous pouvez entreprendre plusieurs actions :

- demander un ordre de mission : quand une société vous envoie sur le site d'un client particulier de façon régulière, elle doit préciser les modalités de prestation par un "Ordre de Mission". Comme on peut le lire sur munci.org :

L’ordre de mission constitue un contrat de prestation (Droit du commerce), signé en sus du contrat de travail (Droit du travail). Il doit être en effet libellé pour protéger le salarié détaché et non pas pour transformer son lien à l’employeur.

Sans y mettre les formes, cela risque de permettre petit à petit de transformer le salarié "presté" de SSII en mission en clientèle en "indépendant" à qui l’on va réclamer des résultats. Alors que le Droit du Travail n’attend du salarié que des moyens, puisqu’il n’est pas fournisseur au même titre que le commerçant, sous-traitant, etc.

- définir la liste exhaustive des livrables attendus de la prestation de service : cela peut-être de simples compte-rendus, l'important est d'expliciter l'engagement de la SSII envers le client.

- organiser une réunion de suivi régulière de la prestation, au minimum tous les 3 mois : en effet, le suivi de mission a pour objectif de reprendre la liste des livrables définis dans l'ordre de mission et d'en vérifier l'avancement. Par un tel suivi, on empêche la mission de dévier vers des tâches non prévues initialement.

- à chaque réunion de suivi, se demander si la SSII contribue d'une manière ou d'une autre à la prestation. Notamment, avez-vous des contacts avec des personnes pratiquant le même métier que vous, dans le même domaine. Avez-vous des échanges avec d'autres personnes de votre métier dans votre entreprise ?

Le métier d'informaticien peut être très gratifiant quand on est capable de mesurer le travail réellement effectué, la valeur réellement apportée au client.

Transformer sa Nintendo DS en tablette graphique avec Colors!

2008-09-23T08:00:00.000-07:00

Quand on plonge dans le monde des homebrews nintendo DS, on pense tout de suite à jouer à des jeux homebrews. Bien qu'intéressants, les jeux homebrew ont rarement toute la richesse graphique et sonore des jeux commerciaux, et c'est normal. il est toujours coûteux de produire du contenu. Il n'y pas que des jeux parmi les homebrews, il y a des applications. Et c'est à mon avis là où le homebrew prend tout son sens. Grâce à ces applications, on peut transformer sa nintendo DS en véritable PDA ou même en iPod survitaminé :

- un système multimedia de visionnage de video, de lecture MP3 et de lecture de eBook : MoonShell
- un système d'organisation de son travail, genre PDA : DSOrganize
- un système riche de lecture de eBook et de Bandes Dessinées : ComicBookDS
- des browsers Web via Wifi

Il y a des tonnes d'applications, et on se demande où est la limite quand on voit les capacités d'ouverture de la console (Wifi). Là où j'ai vraiment été bluffé, c'est avec le homebrew Colors!. C'est un outil qui permet de dessiner avec le stylet de la console en tirant partie de l'écran tactile, de sa résolution et du niveau de pression. En effet, la nintendo DS est une véritable tablette graphique.

Mais vous allez me dire, l'écran est tout petit ! Oui, ce n'est pas un immense écran, mais avec la fonctionnalité de zoom, avec la boîte de dialogue Palette très bien conçue, puissante bien que très simple, on est capable de réaliser de véritables dessins, aussi bien que sur du papier. Vous allez dire que là, c'est pas possible, mais je pense exactement ça : avec la nintendo DS et Colors!, vous avez un cahier virtualisé pour prendre des croquis sur le vif, aussi pratique qu'avec un bloc note.

Si vous pensez vraiment qu'il est impossible de réaliser une œuvre de bonne qualité avec une simple nintendo DS, allez voir cette gallerie de dessins réalisés avec Colors!, et révisez votre jugement. La cerise sur le gateau : Colors! est aussi disponible pour votre iPhone...

Une fonctionnalité intéressante de Colors! après coup est l'enregistrement du séquencement de tous les traits. Vous pouvez rejouer le traçage du dessin depuis le début. On trouve pleins de videos montrant le traçage de dessins Colors.

Quand on voit la facilité avec laquelle on arrive à dessiner avec un simple stylet et un écran tactile, il est clair que la tablette graphique est l'outil indispensable pour faire du graphisme sur votre ordi. De nombreuses tablettes graphiques existent, Wacom étant le leader sur ce marché. Si vous souhaitez en acheter une, faire attention, bien sur à la taille mais aussi à la résolution et au niveau de pression. Plus il y a de niveaux de pressions et une bonne résolution, plus vous aurez l'impression de réellement dessiner sur du papier.

Je n'ai pas essayé, mais il paraît qu'une tablette graphique pour remplacer la souris de l'ordi, c'est excellent. Je n'ai pas essayé, mais c'est clair que quand on y réfléchi, avec de la pratique, ça doit être bien plus précis et rapide que de déplacer le pointeur par la souris. Mais peut-être qu'il faut, pour cette usage là, ne pas prendre une grande tablette pour éviter de fatiguer son bras, son poignet et sa main avec des mouvements trop grands. Il existe des tablettes graphiques relativement peu chères, ça peut faire un beau cadeau de Noël :)

Hacking de la sécurité de la Nintendo DS

2008-09-19T08:00:00.000-07:00

Il est assez impressionnant de voir tous les efforts qui ont été déployés pour permettre de réaliser un développement d'application "homebrew" pour Nintendo DS. La réussite commerciale d'une console de jeu tient à la fiabilité de son système de sécurité anti-copie. Les jeux sur cartouche officielle nintendo DS sont cryptés selon un algorithme secret qui l'est resté plusieurs années.

Les premiers logiciels "faits à la maison" pour nintendo DS ont pu voir le jour par la découverte de bug dans le firmware de la console. Une fois un bug détecté, le hacker de la nintendo DS peut en tirer partie pour rediriger le Program Counter sur la première instruction de l'homebrew. Ce premier logiciel s'appelle PassMe.

Nintendo DS ayant eu vent de cette technique a immédiatement corrigé son bug et livra alors des nintendo DS avec un firmware corrigé. Un nouveau bug a été découvert dans cette nouvelle version du firmware qui a permis de mettre au point une nouvelle carte appelée PassMe2.

Cela rappelle une première évidence : la qualité d'un logiciel est l'aspect majeur de sa sécurité.

Selon, la version du firmware, il fallait à l'époque faire tourner ou une carte PassMe ou une carte PassMe2, or il n'y avait pas de possibilité de voir sur quel firmware fonctionne une nintendo DS. Hasard heureux, quelqu'un c'est aperçu par une combinaison d'actions que la nintendo DS était capable d'indiquer le numéro de version du firmware : en forçant la NDS a planter, celle-ci répond par des écrans de diverses couleurs, caractéristiques de la version du firmware !

Mais il n'a pas fallu très longtemps pour qu'un hacker arrive à backuper le firmware et a en faire une ingénierie inverse pour en trouver l'algorithme de cryptage. Depuis ce jour là, tout carte homebrew pu se faire passer pour un véritable jeu sous licence Nintendo.

Les hackers de tout poils s'acharnent à trouver comment faire fonctionner n'importe quel logiciel sur n'importe quel matériel. Nintendo essayant vainement de stopper l'hémorragie. D'autres cherchent à savoir comment pourrait être empêché toute corruption de machine. C'est ce que montre brillamment Michael Steil et Felix Domke dans leur présentation The XBox360 Security System and its Weaknesses :

C'est vraiment une guerre de l'homme contre l'homme, du hacker contre le hacker autour d'une même ressource qui ne souhaite qu'être comprise.

Java mis au rebut par Sun

2008-09-15T08:00:00.000-07:00

Le titre un brin racoleur de ce billet d'humeur cache une tendance beaucoup plus profonde qu'il n'y paraît. Aujourd'hui Sun vient d'ouvrir son nouveau site de "forge" de projet open source : kenai.com.

Ouvrir un tel site pourrait sembler une bonne chose, mais il n'en ai rien puisque toute initiative "open source" autour d'un concept déjà largement développé est redondante, et donc contre-productive.

Mais le pire n'est pas ce n-ième "sourceforge" qui se veut révolutionnaire près de 10 ans après l'apparition de sourceforge.net. Ce n'est pas non plus parce que ce site porte le nom d'un gros ours balourd de Walt Disney :

Non, le pire c'est bien sur que ce site ne tourne pas en Java mais en Ruby on Rails !

On sent bien en ce moment que Sun essaie de s'ouvrir à d'autres technologies, parce que ces clients eux-même ont envi de passer moins de temps à debugger des machines à gaz pour simplement servir quelques formulaires Web.

Quand on regarde du côté des autres promoteurs initiaux de Java, on vois partout ce penchant du côté des langages dit de "script". Ça me rappelle le début des années 90 avec cette même tendance à aller plus vite pour développer. C'est toujours à peu près le même scénario :

- des applications sont codées dans un langage dit structuré (= typé)

- on s'aperçoit que ces applications sont coûteuses en maintenance car trop compliquées pour le développeur de base.

- on se tourne vers des langages à typage dynamique ou non typé, des langages léger, "agiles", de script

- des applications sont développées beaucoup plus rapidement, mais les développeurs codent dans tous les sens, sans aucune structure claire

- on s'aperçoit qu'à terme, ça coûte toujours aussi cher de développer une application

- on cherche alors un nouveau langage structuré qui devrait permettre de cadrer le travail des développeurs et obliger à avoir du code "propre".

- retour à la première étape.

Tout cela cache une réalité bien plus banale et répandue : la volonté de mécaniser la production d'application par la création de schéma de pensée en apparence structurant. Mais cela abouti à un "déni de réalité", à un refus de vouloir considérer la "construction" de programme pour ce qu'elle est : une activité de réflexion.

Tant que ce déni de réalité perdurera, une attention trop faible sera porté sur le processus créatif sous-jacent à la programmation. Et les entreprises auront encore besoin de nombreuses "ressources humaines" pendant des années pour produire des applications de "qualité".

KeyPass, OpenID et mots de passe dur

2008-09-11T08:00:00.000-07:00

Un de mes amis s'est fait piquer son compte eBay parce qu'il n'avait pas mis de mot de passe dur. Bien sur, eBay ne peut rien faire contre quelqu'un qui arrive à se connecter normalement sur son site avec le bon mot de passe. Autant dire que cet ami était furax de ne pouvoir rien faire.

Le problème c'est que sur la plupart des sites, pour utiliser des services, même gratuits, il est demandé de créer un compte avec un mot de passe. Pour que de nombreuses internautes créent leur compte, les sites n'empêchent pas l'utilisation de mot de passe faible, facilement "crackable". Il y a pourtant des sites pour lesquels on ne veut pas avoir de problème de sécurité, comme par exemple son compte email principal.

Or avec la multiplications des comptes, chaque internaute finit par devoir se rappeler d'une multitude de mots de passes (forcément des mots de passe faible). Il y a plusieurs solutions à cela :

- soit les sites propose de se connecter via OpenID : il suffit d'avoir un compte chez un fournisseur OpenId pour que tous les sites compatibles puissent se baser sur se compte OpenId pour vérifier les informations de l'utilisateur. De nombreux sites proposent l'hébergement de compte OpenId par défaut, comme Blogger ou Orange. Malheureusement, les sites supportant l'OpenId sont encore trop rare. Mais bon, ... autant avoir un compte OpenID quelque part.

- soit on utilise un logiciel comme l'excellent KeyPass : celui propose de stocker dans une base de données protégée par mot de passe ou via un certificat, l'ensemble des mots de passe que l'on possède. Il propose de générer des mots de passe dur pour chacun d'eux. On n'a donc plus qu'à se rappeler que d'un seul mot de passe (ou avoir un certificat). Je ne pensais pas qu'un tel logiciel soit vraiment utile même en entreprise, mais après utilisation et stockage de tout mes mots de passe, je m'aperçois que, rien que pour l'entreprise ou je travaille, j'ai déjà une vingtaine de mots de passe différents à retenir.

Avec ces deux méthodes, on est paré pour affronter la cohue de crackers déambulant dans les chemins dangereux de l'information.

Nintendo DS, hombrews et mégadémos

2008-09-07T08:00:00.000-07:00

Quand on commence l'informatique, quand on a pour seul bagage la passion et pour seule alliée l'ignorance, le choix de la plate-forme de développement pour laquelle on va dévouer un nombre d'heures inimaginable pour en tirer quelque chose, devient crucial. De ce choix va dépendre la transformation de cette passion en véritable hobby, voire même en métier pour tout une vie.

Pour des générations d'informaticiens, tout est parti de la volonté de faire réaliser à une machine ce pour quoi elle n'a pas été conçue, d'aller au delà de ce qu'elle est sensée faire. Pour ma génération, nombreux se sont fait les mains sur des machines aux doux noms de ZX81, ZXSpectrum, Amstrad CPC, C64, Atari ST ou Amiga. Les heures acharnées à produire de nouveaux effets, multipliées par le nombre de passionnés de cette époque là, a abouti à ce qu'on appelle la Scène Démo. La vision de démos telle que la RSI Megademo a produit sur moi une impression vraiment indélébile.

Pour réaliser ces démos, et pour que ça soit fun, le but était bien sur de parler directement à la machine, pas de parler à un bloatware ou un bugware comme le système d'exploitation. Pour un gosse qui commence à se passionner, l'important est d'avoir accès à toute la machine, de pouvoir en faire ce qu'il souhaite, une sorte de bac à sable. Ce qui était vraiment le plus sympa était de voir qu'une machine en apparence limitée pouvait se surpasser.

Aujourd'hui, j'ai retrouvé toutes les joies de mon enfance (snif:) avec la nintendo DS. Cette console portable est si bien conçue qu'on a envie d'en faire quelque chose d'extraordinaire.

Pensez à tout ce que l'on peut faire avec deux écrans, dont un écran tactile, un microphone... et tout ça pour beaucoup moins cher qu'un véritable ordinateur. A mon avis, les gosses d'aujourd'hui ont tout intérêt à se faire la main sur ce genre de machine bien plus abordable qu'un PC, et surtout, bien plus fun :) Il n'y a qu'à installer 2 ou 3 trucs sur le PC de papa sans avoir besoin de faire planter Windows définitivement.

Tout d'abord, la nintendo DS n'est pas du tout une console banale, mais tout simplement un véritable ordinateur très évolué basé sur une double architecture ARM (ARM7TDMI, ARM946E-S). Cette architecture est une merveille de conception, elle a pour grand avantage de consommer très peu d'énergie et de permettre donc une autonomie bien meilleure que celle d'un PC portable par exemple.

Ensuite, il faut un moyen de faire exécuter du code dessus. Il existe de nombreux systèmes à base de cartouches plus ou moins évolués. Pour ma part, après comparaison, j'ai opté pour la CycloDS Evolution surtout pour les fonctions suivantes :

- fonctionne sur slot-1, pas besoin de faire du PassMe ou autre techniques de ce genre, et pas besoin d'avoir de carte GBA.

- permet de lire les cartes microSDHC de 4Go à 32Go,

- auto-patching DLDI

- nombreuses fonctions embarquées (soft reboot, autolaunch de la dernière appli)

Je l'ai trouvée sur Metashop, elle m'est arrivée assez rapidement et sans problème. Par contre, j'ai acheté une carte 4Go MicroSDHC sur Amazon, c'est beaucoup moins cher que chez Metashop. Attention à prendre une carte de class 4 minimum (4Mb/s) sinon, risque de ralentissement quasi-garanti.

Avec un tel matériel, faire fonctionner un homebrew sur sa console est un jeu d'enfant :

- glisser la carte microSDHC dans la clé USB fournie par CycloDS

- brancher cette clé USB sur un PC et y déposer directement les fichiers .nds non-patché DLDI (par défaut de toute manière)

- mettre ensuite la carte microSDHC dans la carte CycloDS Evolution.

- allumer la nintendo DS sur cette carte CycloDS.

Et voilà, on se retrouve avec un navigateur, genre Windows Explorer sur sa nintendo DS et cela permet de sélectionner le homebrew à exécuter. Le gamin que je suis resté a trouvé ce tutorial bien complet pour commencer à développer soi-même un homebrew. Le site de drunkencoders.com est une référence pour la programmation avec plein de liens et de tutos.

Et forcément, il y en a qui ont eu la bonne idée de porter Linux sur Nintendo DS...

La Guerre des browsers est relancée !

2008-09-03T08:00:00.000-07:00

Oui, ça fait déjà un petit moment que la guerre du navigateur Web est relancée avec de superbes logiciels comme Safari, Opera ou Firefox.

Aujourd'hui c'est Google qui s'y met et c'est certainement pour faire avancer à grand pas le sujet. En effet, grâce à Google Chrome, Google montre clairement sa volonté de faire du Web la seule et unique plateforme de travail, de faire de l'application client Lourd une technologie du passé.

On peut se demander pourquoi Google se met-il à faire encore un nouveau browser alors que de nombreuses alternatives existent déjà. C'est qu'il souhaite clairement innover dans le sens qu'ils souhaitent, c'est à dire une plateforme d'exécution complètement reliée au Web, aux applications en réseau, ... et aux publicités ciblées qui ont fait la fortune de Google.

Si Google fait du logiciel opensource, ce n'est pas par philanthropie, mais c'est parce qu'il ne tire pas leur revenu de la vente de logiciels mais par l'utilisation de leur logiciel. Plus leurs logiciels sont utilisés, plus ça leur rapporte par des publicité ultra ciblées.

Comme le fait remarquer Eric Schmitt dans "The Future Of Technology", le marché des médias (communication/publicité) est beaucoup plus gros que le marché de l'IT. Le business case de Google est d'arriver à cibler au maximum les clients des publicitaires, et d'obtenir un maximum de clic significatif sur ces pubs.

It's gonna be huge !

Ainsi, le développement de solutions informatique pour Google n'est qu'un moyen pour arriver à toucher à ce marché. Mais Google n'a que très peu de revenu grâce à la vente de ces technologies (technologies de recherche notamment).

Même si j'ai noté quelques bugs par ci par là sur Google Chrome (petit problème de menu contextuel Copier/Coller sur champ de formulaire), l'outil semble déjà bien abouti et assez stable. Les applications comme Gmail ou GoogleReader tourne très vite, même si sur Firefox, s'était déjà assez rapide. Google Chrome prendra tout son sens avec la multiplication des "Core" dans les processeurs, grâce au choix qu'ils ont fait concernant la création d'un processus à part entière par onglet.

Reste plus qu'à souhaiter que Google innove un maximum sur ce browser, en espérant que cela puisse réellement mener à des applications aussi rapide et aussi riche que les applications client lourde. L'important c'est que les applications Web arrive à tirer profit de leur nature distribuée pour proposer des services qu'on pourrait difficilement mettre en oeuvre sur des RDA (Rich Desktop Application) classiques.

Il paraît que Microsoft a encore 75% du marché des navigateurs, Microsoft finira bien par se bouger et a enfin suivre les innovations du marché si Google Chrome se répand. Google veut certainement produire des applications bureautique plus riche et plus performantes. Google Docs est bien, mais n'a rien de comparable avec une suite bureautique comme Microsoft Office.

Peut-être qu'à terme, ce sera à Microsoft de convertir son Microsoft Office en Web 2.0 ? Tout le problème pour Microsoft c'est que justement, leur modèle économique est basé sur la vente de licence de logiciel, pas sur l'utilisation des logiciels. Ca risque d'être un moment très dur pour Microsoft s'il est obligé de suivre Google.

Jargon, effets de mode et confusions dans l'informatique

2008-09-01T08:00:00.000-07:00

En lisant de nombreux blogs sur l'informatique, j'ai comme l'impression que de nombreux débats sont futiles voire contreproductifs. Ça me semble particulièrement le cas dans le monde de "l'Agile Development" ainsi que tout ce qui tourne autour de la SOA (Service Oriented Architecture)

Beaucoup d'opportunistes s'empressent de construire un jargon pour représenter des concepts qui n'en sont pas. Pourquoi tous ces termes lourds et vagues comme "agilité" "orientation service" "orchestration", "chorégraphie", ... L'utilisation d'un de ces termes ne fait pas avancer un chouilla dans la résolution d'un problème.

"L'agilité" n'est pas une méthode et encore moins une méthodologie : qui ne souhaite pas être agile sur un projet ? Face à temps de jargon, les termes se mélangent. Ce sont des termes pièges qui visent à enfermer les naïfs dans des schémas de pensées clé en main. Or le problème de ces schémas c'est qu'ils veulent donner des recettes toutes faites alors que justement, l'important est de reconnaitre que (surtout en informatique) chaque problème est unique.

Si un problème n'est pas unique, il faut partir du postulat qu'il doit normalement exister un logiciel tout prêt pour le résoudre.

L'important est de savoir s'adapter à la situation. Le seul art à maîtriser correctement est la gestion de projet. La gestion de projet ne présuppose pas le processus de développement à employer. Un projet pourra viser de nombreuses itérations avec écritures de scenarii et développement dirigé par les tests si la solution le nécessite. Mais cette façon de travailler n'est pas forcément la meilleur à adopter pour n'importe quel projet.

Par exemple, l'utilisation de "releases" fréquentes pour le client et la définition au fil de l'eau des spécifications via des scenarii risque de faire aboutir à des logiciels coûteux alors qu'une analyse, une réflexion d'ensemble au début du projet aurait pu aboutir au choix de la mise en place d'un progiciel du marché.

Car c'est bien là l'enjeu de l'informatique aujourd'hui : faire un maximum de réutilisation, ne pas réinventer la roue. La principale activité pour arriver à cet objectif est l'analyse de système.

La sclérose en plaque n'est pas seulement dans le cerveau des prophètes de "l'agile". On la retrouve partout, notamment chez Microsoft, qui en 2008 est fière de sortir enfin un composant DataGrid digne de ce nom !

Quelle avancée dans le domaine de l'informatique ! ça fait juste 30 ans que les grilles de données existent sur PC et Mac ! quand on pense aux premiers tableurs comme VisiCalc, et qu'on regarde ce qui est reconnu comme une avancée dans "Microsoft .Net Framework 3.5 WPF", on se dit que vraiment, on a fait du surplace pendant 30 ans

L'important pour un informaticien est la reconnaissance que l'informatique n'est pas une solution en soi pour le client. L'analyse du besoin est l'activité déterminante du succès ou de l'échec d'un projet.

La lecture plaisante de code source, ou comment éviter de perdre son temps

2008-08-28T08:00:00.000-07:00

Vous n'avez pas l'impression que l'informatique tourne en rond en ce moment, qu'elle ne cherche plus à innover mais simplement à recréer ce qu'elle a déjà oublié ?

Pourquoi recréer le client lourd dans le navigateur Web quand justement, on n'était sorti du client lourd sous Windows ? Pourquoi tant d'effort déployé par des myriades de passionnés d'informatique pour produire des outils permettant uniquement de créer d'autres outils, etc ?

Quand on voit le nombre de frameworks redondants, d'applications Web reproduites à l'identique en des milliers d'exemplaires différents mais pourtant bien semblables tel que les CMS... on peut se demander d'où vient le problème.

A mon avis, c'est que le développeur de base, chez lui, le passionné d'informatique s'imagine capable de créer un monde à son image quand il se met à développer un nouveau logiciel "from scratch".

Le problème c'est que quand il décide de partir de zéro pour créer un nouveau logiciel, dans 90% des cas, son effort est négatif pour la communauté opensource.

En effet, l'effort qu'il pourrait passer à améliorer un logiciel déjà existant, ce passionné le passe à recréer entièrement un logiciel et tout ce qui va avec, toutes les fonctionnalités communes à tous les même type de logiciel, bref à recréer la roue.

Traduction pour le nerd moyen : La création d'une nouvelle itération d'un logiciel déjà existant n'a pour résultat que de diviser l'effort qui pourrait être mis sur une seule itération, sur un seul logiciel.

Développer un nouveau logiciel à partir de rien pourrait sembler intéressant dans un premier temps, mais quand on y pense, cela est vain. A quoi bon recréer toutes les routines de support de l'application alors qu'elles existent déjà sous d'autres formes dans des logiciels similaires ?

Il est pourtant beaucoup plus intéressant d'essayer d'améliorer les logiciels existants. Pour un développeur qui cherche de la reconnaissance par son travail de programmation, la contribution à des projets largement établis sur le Web est beaucoup plus valorisant et instructif que de recommencer dans son coin un bout de code.

La difficulté première, c'est que la plupart des développeurs n'aiment pas lire : que ce soit des livres ou du code source. Or tout est là : c'est dans la capacité à comprendre le code source de logiciels complexes que la productivité d'un développeur peut augmenter.

Lire du code source est extrêmement instructif, il permet de se confronter personnellement à des schémas de pensés contradictoires, à s'immiscer dans la logique profonde d'un autre développeur, voire, plusieurs développeurs.

Au delà du langage de programmation, c'est toute l'intelligence d'un être humain qui apparaît à travers le code source. On peut y voir comment un développeur met en œuvre des outils limités pour obtenir le comportement réellement souhaité.

La lecture du code source est très instructive car elle permet de s'apercevoir que même pour des problèmes en apparence simple, le programmeur doit déployer toute son intelligence pour aboutir à une solution élégante.

L'élégance est affaire de bon goût mais dans le cas de la programmation, chaque développeur y apposera son échelle de valeur. Alors que certains vont chercher l'optimisation à tout prix, d'autres, rechercherons la robustesse, d'autres la maintenabilité, etc. C'est par l'appréciation de toutes ces caractéristiques, qu'un développeur peut sentir l'élégance d'une construction.

Terminologie de la communauté des informaticiens

2008-08-24T08:00:00.000-07:00

Je viens de finir de regarder un épisode de "Dr. House". Cette série télé est tellement bien écrite et réalisée qu'elle suscite un désir profond de "faire" de la médecine. Avec tous les termes médicaux qui sont jetés au téléspectateur, la série réussie à flatter notre ego, parce qu'on a l'impression d'y comprendre quelque chose alors que vraiment tout nous échappe.

Cet épisode m'a fait réalisé qu'il nous manquait peut-être quelque chose en informatique, chose que la médecine utilise largement. Il s'agit du nommage scientifique de la moindre petite chose, ou technique. En médecine, j'ai l'impression que l'accumulation du savoir tourne autour du nommage de chaque savoir, une terminologie précise, scientifique, commune à tous les praticiens.

Or quand je lis des livres comme Code Complete ou d'autres, il y a une liste impressionnante de symptômes de mauvais code, de techniques de codage, mais presque aucun nom commun n'est donné pour représenter spécifiquement ces choses. Il serait pourtant vraiment intéressant de pouvoir construire un corpus de noms (un "jargon" ?) pour chaque phénomène, méthode de programmation, style d'écriture de code...

On voit quand même apparaître depuis quelques années un effort dans ce sens avec la volonté de la formalisation de modèles de conceptions ("design patterns") avec des noms spécifiques. Certains informaticiens vont aussi dans cette voie, en essayant justement de définir précisément chaque méthode, fait, causes, en informatique comme Martin Fowler avec son bliki.

Mais, nombre de méthodes, bonnes pratiques, mauvaises pratiques n'ont pas encore de nom propre pour devenir commun à tous les développeurs. Cela ne veut pas dire qu'elles n'existent pas !

L'informatique étant une discipline basée sur la mode du moment, toute référence au passé est suspecte et est considérée comme inutile. On se prive pourtant de nombre de bonnes pratiques, qui malheureusement finissent par être largement ignorées.

Peut-être faudrait-il employer une dénomination à base de racine Grec ou Latine pour provoquer volontairement de la distance avec ces effets de modes. Ça donnerait de la classe aux informaticiens, flatterait aussi leur égo :) Mais en tout cas, cela n'empêchera pas d'avoir de mauvais informaticiens.

Le capital-risque et la levée de fond

2008-08-21T08:00:00.000-07:00

Je me suis toujours demandé quel est l'intéret il peut y avoir de créer une startup aujourd'hui, en France. Rêver de devenir le prochain Google ne nourri pas son homme, surtout quand on sait le nombre si faible de Capital investissement en France ou de Business Angels.

Et puis vient un jour un gars nommé Paul Graham qui vous dit que trouver de l'argent c'est très dur (on s'en serait douté :) mais que cet argent n'est pas une fin en soi quand on créé une startup. En effet, dans son article A Fundraising Survival Guide, Paul nous démonte toutes les mauvaises conceptions que l'on a de la levée de fond.

Il part du principe de base que tous les investisseurs sont, à la base, incompétents :

"All investors, including us, are by ordinary standards incompetent. We constantly have to make decisions about things we don't understand, and more often than not we're wrong."

et qu'il ne se feront donc jamais une opinion sur votre société d'après une jugement raisonné :

"the biggest factor in their opinion of you is the opinion of other investors".

Face à un tel décalage entre les aspirations des entrepreneurs et celles des investisseurs, le plus importants message a faire passer c'est que la startup va réussir avec ou sans eux :

"The message (and not just the message, but the fact) should be: we're going to succeed no matter what. Raising more money just lets us do it faster."

"There is nothing investors like more than a startup that seems like it's going to succeed even without them. Investors like it when they can help a startup, but they don't like startups that would die without that help."

Mais ce qui est le plus difficile est d'avoir une idée à la fois bonne et nouvelle ce qui est paradoxal quand on y pense :

"A good startup idea has to be not just good but novel. And to be both good and novel, an idea probably has to seem bad to most people, or someone would already be doing it and it wouldn't be novel."

En France, les gros éditeurs de logiciels ou de solutions fortement basé sur l'informatique sont rares ou se font racheter par des sociétés étrangères.

Face à tant d'obstacles, Paul Graham nous rappelle ce qui est vraiment important quand on décide de se lancer dans l'aventure :

- l'endurance,

- l'adaptabilité,

- la détermination.

Avec ces qualités, on arrivera bien quelque part... peut-être pas vers une réussite pécuniaire, mais en tout cas vers une expérience enrichissante.

Programmer dans un langage

2008-08-18T08:00:00.000-07:00

David Gries, dans son livre The Science Of Programming (page 235, 18.3.11) énonce un principe plein de sagesse :

Principle : Program into a programming language, not in it.

que l'on peut difficilement (et très librement) traduire en français par :

Principe : Programmer dans un langage, pas pour un langage.

C'est une mauvaise traduction, les mots, "in" et "into" n'étant pas très facile à distinguer.

L'idée est de programmer de façon quasiment abstraite (j'ai dit quasiment, j'ai pas dit complètement :) avec le langage comme simple support du programme. Il faut éviter de programmer pour un langage, c'est à dire, que son programme ne soit structuré par les contraintes et possibilités d'un langage particulier.

David Gries propose de construire son programme et ses structure de données indépendamment du langage utilisé. Cela rejoint un peu la programmation par pensée désirée qui vise à construire un programme en partant d'une vision abstraite et désirée du monde.

Une fois que le programme désiré a été codé, on peut ensuite raffiner les données et le programme pour qu'il "colle" mieux au langage, et ce pour des raisons performance, lisibilité, cohérence avec l'ensemble des librairies à dispositions, etc. Mais ce raffinement ne vient que dans un deuxième temps. Il est nécessaire de ne pas se laisser guider/contraindre par un langage particulier.

On pourrait croire, qu'avec un tel principe, il est nécessaire de savoir coder dans n'importe quel langage. C'est aller un peu vite en besogne, et c'est même l'inverse que je préconiserait. En effet, la véritable maîtrise d'un langage de programmation nécessite plusieurs années d'apprentissage.

Il ne suffit pas de connaître la syntaxe de base du langage. Celle-ci est souvent très simple et peut s'apprendre très rapidement (sauf certains cas significatifs comme Perl qui justement vise à offrir un langage très riche en raccourcis et tournure de phrase). Le plus important est de connaître ce qui existe déjà dans ce langage, les librairies et comment les utiliser.

Ce dernier aspect est crucial pour la productivité d'un programmeur. C'est souvent au bout de plusieurs années qu'un développeur maîtrise aisément toutes ces API. Le problème est bien là : la maîtrise prend du temps. Et le temps, personne n'en a jamais assez.

C'est pour ça que la popularité d'un langage de programmation est rarement due à sa capacité à exprimer tous les paradigmes informatiques connus mais plus par sa capacité à montrer qu'il est le seul et unique langage qu'on vous demandera d'utiliser en milieu professionnel.

La période nécessaire d'apprentissage étant longue, un informaticien professionnel choisissant d'avoir quand même une vie en dehors de l'informatique et de son boulot, choisira nécessairement un seul langage.

A cause de cet apprentissage long, il est important de "maîtriser" au moins un langage de programmation, tout en gardant l'esprit ouvert sur les autres langages existants. Autant choisir un langage qui permet de mettre en œuvre un maximum de paradigmes. Même si il est vrai que le domaine du développement logiciel a largement avancé en restreignant ce que peuvent faire les programmeurs avec leur code, comme nous le rappelle Steve McConnell dans Code Complete 2 :

At one time or another, someone thought that each of the following control structures was a good idea:

- Unrestricted use of gotos

- Ability to compute a goto target dynamically and jump to the computed location

- Ability to use goto to jump from the middle of one routine into the middle of another routine

- Ability to call a routine with a line number or label that allowed execution to begin somewhere in the middle of the routine

- Ability to have the program generate code on the fly and then execute the code it just wrote

At one time, each of these ideas was regarded as acceptable or even desirable, even though now they all look hopelessly quaint, outdated, or dangerous. The field of software development has advanced largely through restricting what programmers can do with their code.

A vous donc, de choisir le bon langage de programmation pour lequel vous êtes prêt à investir un nombre d'heures déraisonnable pour en acquérir toute la maîtrise.

Système de suivi d'un développement logiciel

2008-08-15T08:00:00.000-07:00

En milieu professionnel, le développement logiciel s'apparente à une construction d'une maison. On fait des plans à l'avance, et on s'organise pour que tout le monde travaille dans le bon sens. L'important est de pouvoir savoir que le projet avance, de suivre son avancement.

Rien de mieux pour cela que d'organiser un projet autour d'un système de gestion d'exigences, reflet exact du besoin du client. L'important dans un projet informatique est de s'assurer que toutes les exigences sont "couvertes", et que seules les exigences demandées sont implémentées. La liste des exigences n'est que le reflet exhaustif du contrat passé avec le client.

La gestion des exigences est parfois obligatoire notamment lors de marchés publics. Mais, même (et surtout) quand un contrat est ambigüe, n'est pas clair sur chacun des besoin du client, il est important de détailler le contrat en exigences.

Un des meilleurs bouquins que j'ai pu lire sur le sujet est Exploring Requirements: Quality Before Design de Donald C. Gause et Gerald M. Weinberg. Ce qui est intéressant dans ce livre c'est qu'il montre comment faire ressortir toutes les exigences d'un produit et comment les différencier en fonctions, attributs, contraintes, préférences et attentes.

Ainsi, quand on a plusieurs intervenant à faire travailler sur un projet, l'important est de s'assurer que le travail de chacun est lié directement à l'implémentation d'une exigence. La mise en place d'outils de gestion de projet devient inévitable dès qu'on a plus de 2 développeurs simultanés.

Le système d'information de base à mettre en place pour une gestion de projet s'articule autour des types d'outil suivant :

- un gestionnaire d'exigences
- un gestionnaire de tests, de scenarii de test et de plan de tests
- un outil de suivi des anomalies
- un outil pour relier au code les exigences et les anomalies.
- l'intégration de tous ces outils

L'idéal est bien d'intégrer tous ces outils pour avoir une maîtrise de ce qui est développé. Le processus de développement peut alors se décrire comme suit :

- une exigence est rédigée dans le système de gestion des exigences.

- des tests et des scenarii de tests sont rédigés pour cette exigence, permettant de s'assurer qu'elle a été correctement implémentée.

- des plans de test sont construits pour organiser les phases de vérification et de validation.

- quand un développeur veut commiter du code, il indique dans le message de commit la
référence de l'exigence concernée par ce commit.

- quand un test montre qu'il y a un problème, l'anomalie est tracée dans le système de suivi des anomalies.

- quand un développeur corrige l'anomalie dans le code, il indique dans le message de commit la référence de l'anomalie.

L'important dans tout ça est de contraindre le processus pour qu'il soit suivi :

- tout commit doit avoir soit une référence d'exigence, soit une référence d'anomalie
- toute anomalie doit avoir une référence à l'exigence sur laquelle le défaut a été constaté
- tout test doit avoir une référence à l'exigence testée

On peut mettre en place un tel système de suivi du développement logiciel avec de simples outils Open Source :

- Mantis pour le suivi des anomalies,

- Testlink pour le suivi des exigences, des tests, des scenarii de test, des plan de test. Il a l'avantage de s'interconnecter facilement avec Mantis. On peut faire correspondre des bug Mantis avec des tests Testlink.

- scmbug pour relier les commits au référentiels que sont les exigences et les anomalies.

Intégrer Mantis et Testlink est un jeu d'enfant, la mise en place de scmbug elle, est plus difficile (et le sera tant qu'il n'y aura pas d'interface au niveau de Mantis sur laquelle scmbug puisse connecter ses évènements).

Travailler avec un tel système nécessite d'adhérer à cette vision d'implémentation d'exigences. Il est important que chaque développeur comprenne que ce n'est pas contraindre la créativité que de baser le développement sur les exigences.

De toute manière, si vous avez correctement implémenté ce système, le développeur est obligé de préciser sur quelle exigence, ou quelle anomalie il commit son code, le tout est de s'assurer que le code correspond effectivement à ce qu'il prétend. Cela est normalement fait au niveau de l'assurance qualité.

Les affres de la gestion de projet de développement au forfait

2008-08-12T08:00:00.000-07:00

Pour les informaticiens travaillant en SSII, le travail sur des projets au forfait peut s'avérer beaucoup plus intéressant que de travailler en régie dans une équipe du client.

En effet, quand vous êtes en régie chez un client, vous avez beau être intégré dans les équipes en places et faire ami-ami avec vos collègues, vous n'êtes pas un employé de la société cliente, vous êtes un représentant de la société pour laquelle vous travaillez réellement, la SSII.

Travailler sur un projet au forfait dans la société qui vous à engagée est inconsciemment plus gratifiant que de travailler sur un projet d'un client. C'est mon sentiment personnel, ce n'est peut-être pas le cas pour vous, je le comprend bien.

Le problème d'un chef de projet en SSII, c'est que souvent, il récupère un projet au forfait qu'il n'a pas lui même vendu et dont il n'a pas estimé les charges. Ce découpage se retrouve souvent car le chef de projet a toujours tendance à avoir peur face aux risques qui apparaissent et donc à surestimer les charges de réalisation.

Le commercial ou chargé d'affaire, lui, est intéressé au chiffre d'affaire et est donc plus enclin à prendre des risques. Risques qu'il doit quand même mesurer pour qu'il puisse un jour espérer toucher sa commission lors de l'émission de la facture finale du projet.

Il se peut qu'on ne puisse pas évaluer correctement les charges de développement au début du projet, et c'est normal. La vente au forfait se base sur des présupposés et pré-requis plus ou moins explicités.

Le chef de projet, avant d'accepter tout nouveau projet doit comprendre entièrement les contraintes, présupposés, réserves et prérequis qui ont été utilisés pour l'évaluation des charges vendues au client. Il ne doit accepter de le gérer que suite à la revue complète de son estimation et de son acceptation.

Un projet au forfait engage la société de service:

- sur le résultat,
- sur le prix,
- sur les délais,
- et la qualité des produits livrés.

Le projet au forfait ne peut être viable que dans la mesure où une plus ou moins grande partie du cahier des charges est clairement explicitée et non ambiguë. Plus le cahier des charges est ambiguë, plus il y a de risque au forfait. Un client aura plus intérêt à internaliser les projets complexes (au niveau technique, organisation...)

Si vous vous trouvez dans la situation (si commune de nos jours) où on vous impose un projet qui vous semble intenable, plusieurs choses peuvent être entreprises pour arriver à s'en sortir :

Tout d'abord, il est important d'expliciter entièrement la formule qui a permis de calculer l'engagement au forfait (le nombre de jours, les délais, la qualité, etc.). Les commerciaux, chargés d'affaire doivent être capables de vous expliquer exactement ce qui leur à permis de mettre un prix de vente global sur la proposition commerciale.

Avec une telle formule, normalement apparaît tout de suite les éléments qui ont été sous-estimés par la "force de vente" (le commercial). Attention aux remises commerciales, concédées par le commercial pour gagner le projet "à tout prix".

Ensuite il est important de lister de façon exhaustive les points qui n'ont pas été explicité dans le contrat et qui auront un impact important sur le projet. Il s'agit souvent d'information provenant du client, que l'on n'a pas encore au moment de l'écriture du contrat. Le commercial a souvent un ressenti qu'il est important de recueillir car il n'est écrit nul part.

Identifier les exigences à risques et les exigences pour lesquels des solutions toute prêtes sont disponibles (soit en interne dans la société, soit par l'achat d'une brique sur étagère, soit par l'utilisation de technologies "Open Source".)

Enfin, d'après tous les éléments que vous avez à votre disposition, estimez les délais, coûts, qualité, ressources, risques et la rentabilité du projet.

Avec tous ces éléments, vous devez faire une réunion interne de lancement de projet pour remonter à votre hiérarchie toute ces informations et notamment toutes les charges que vous ne pouvez assumer (remise commerciales, flou dans le besoin client, flou dans la solution vendue.)

Rien de pire que d'accepter un projet infaisable sans broncher. Quand ça sera la cata (et ça sera la cata à un moment ou un autre !), ça sera vous le responsable !

Le plus important c'est que la société de service assume, dès le début du projet, les éléments que vous ne pouvez assumer seul. Et alors, seul le Compte Rendu de la réunion interne de lancement sera votre bouclier contre toutes les attaques qui se feront (forcément) jour lors du projet. Si vous ne pouvez pas faire de Compte Rendu, un email largement diffusé fera l'affaire.

L'important pour un chef de projet est de ne pas assumer les charges sur lesquels il n'a aucune prise. On ne peut être responsables des choses sur lesquelles on ne peut agir.

Le chemin bien sinueux de l'excellence

2008-08-09T08:00:00.000-07:00

On dit toujours qu'il faut savoir programmer quelque soit le langage. Mais, il est illusoire de croire que l'on peut arriver à un tel degré d'abstraction que l'on saurait alors coder proprement dans n'importe quel langage.

Bien que les bases de la programmation soient toujours nécessaires à acquérir d'une façon abstraite, la maîtrise d'un langage passe essentiellement par la connaissance aiguë des librairies offertes autour de celui-ci. Car un bon programmeur est avant tout un programmeur qui réutilise un maximum ce qui existe déjà.

Mais la capacité d'un programmeur à réutiliser des librairies existantes passe aussi par la compréhension des concepts véhiculées par celles-ci. La mesure de la compétence est quelque chose de difficile à estimer. La meilleur chose est de s'estimer en comparaison des véritables hackers, les demis-dieux, voire, les dieux tout court.

J'ai trouvé une matrice de compétence bien intéressante. Celle-ci offre une vue de ce que devrait être capable de faire un développeur expérimenté (ou avoir comme bagage), comme par exemple :

- Capacité du code à être lu (code readability) : les présupposés du code sont vérifiés par l'utilisation d'asserts, le code défile naturellement - pas d'emboîtement profond de conditionnelles ou de méthodes

- IDE : a écrit des macros personnalisées

- exposition aux langages : Concurrent (Erlang, Oz) and Logic (Prolog)

- années d'expérience professionnelle : 10+

- livres : Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , by C. J Date, Thinking Forth, Little Schemer

On retrouve plein d'idées d'amélioration de ses propres compétences, plein de sujet d'étude à découvrir.

Cela me fait penser à l'article "How To Become A Hacker" qui recense les caractéristiques d'un hacker, au sens "noble" du terme s'entend. Il est toujours bon de connaître le chemin même si l'important est de l'arpenter ensuite, comme dirait l'autre.

Le problème dans tout ça, c'est souvent le temps qui manque, et il n'est pas toujours facile de concilier la vie courante et la vie de hacker.

Où vous situez-vous dans la matrice de compétence, ou alors, pensez-vous que tout cela n'est pas bien réaliste et que les critères sont biaisés ?

Le contenu n'est pas une donnée

2008-08-06T08:00:00.000-07:00

Il n'est pas toujours facile d'expliquer la différence entre du contenu et des données. Surtout à un développeur. Non, du contenu n'est pas simplement des données à stocker dans une base de données. Il faut prendre de la distance avec l'outil informatique. C'est ce qu'a très bien expliqué Seth Gottlieb dans son article "Content is not Data" :

1. Le contenu a une voix : le contenu essaie de communiquer quelque chose (exprimer une idée, convaincre quelqu'un). Cette communication demande un processus créatif et en entreprise, des approbations sont peut-être nécessaires avant sa diffusion.

2. Le contenu a un propriétaire : Les données n'ont généralement pas de copyright mais le contenu si.

3. Le contenu est destiné à un auditoire humain : les auteurs de contenu ont un souci constant d'un bonne présentation de leur contenu.

4. Le contenu a un contexte : En plus de savoir qui écrit le contenu, savoir où le contenu est présenté est aussi important.

Toutes ces caractéristiques du contenu implique des fonctionnalités que doivent proposer les CMS (Content Management Systems) notamment les plate-formes WCM :

1. Gestion des versions : le but est de suivre l'évolution d'un contenu. Selon le type de contenu, il peut y avoir de nombreux changements sur un même contenu. Il est important de pouvoir revoir des anciennes versions, comparer des versions, annoter des versions...

2. Gestion de la publication : la maîtrise de la diffusion et de la présentation du contenu implique des fonctionnalités importantes à offrir à l'auteur (éditeur WYSIWYG, prévisualisation, ...)

3. Feedback : il est important qu'un auteur ai un retour sur son contenu (commentaires, votes, statistiques, systèmes d'analyse d'influence...)

4. Métadonnées : stockage et exploitation des caractéristiques du document comme la source, le propriétaire, ...

5. Utilisabilité du système : pour faciliter la création et l'exploitation de contenu, car il est coûteux et difficile de produire du contenu de qualité.

Le terme de gestion de contenu chevauche la notion de gestion électronique de document (GED), qui elle, vise à stocker/indexer des documents électroniques (pdf, word...) ou des images de document papier.

On parle souvent de GED dans le cas de la numérisation d'un stock de documents papier existant. Dans ce dernier cas, on tombe souvent dans des problèmes de numérisation de vieux documents agrafés, recto-verso, A3, couleur, etc.

Des sociétés spécialisées, comme Jouve ou Xerox Global Services, s'occupent de ce genre de travail. On mesure le nombre de documents à traiter au mètre cube (m³). Il est assez difficile de s'engager sur une charge et des délais quand on ne connaît que le nombre de m³ à numériser, il faut alors donner une fourchette haute à l'estimation.

Architecture des Systèmes d'Information et le framework de Zachman

2008-08-03T08:00:00.000-07:00

Le système d'information d'entreprise est apparu petit à petit dans l'entreprise, simplifiant certaines tâches répétitives ou compliquées. Bien qu'on pourrait croire qu'elle est issue d'une volonté forte des directions des entreprises, elle a souvent été introduite par de véritables passionnés, des amateurs qui, de leur poste de travail, ont su voir des applications novatrices de l'ordinateur.

Il n'est pas rare de rencontrer encore aujourd'hui des systèmes construits il y a fort longtemps, et maintenus jusqu'à aujourd'hui. C'est souvent le cas dans le monde de la banque ou dans les gros systèmes d'informations comme, par exemple, celui de France Telecom.

Quand l'informatique ne fait pas parti de la stratégie de l'entreprise, elle s'immisce petit à petit dans son environnement, jusqu'à contrôler des parties vitales de son l'activité.

J'ai vu en 1993, dans une entreprise de l'industrie chimique, un système construit de toute pièce par un enthousiaste de l'informatique. Le système a évolué du simple programme de suivi de l'activité d'une vanne au contrôle total d'une chaîne de production chimique de l'usine. Seules une ou deux personnes connaissaient le fonctionnement du logiciel (pas de documentation, pas de formation du personnels à l'informatique). Les personnes en charge de l'ouverture/fermeture des vannes se tournaient les pouces toute la journée, n'ayant plus d'opération à réaliser à la main.

On ne sait jamais ce que va devenir du code que l'on produit dès qu'on le lâche dans un environnement (une entreprise, sur internet...). Les entreprises ont voulu maîtriser leur informatique. Est apparu alors ce que l'on appelle "l'Architecture des Systèmes d'Information" qu'on rencontre aujourd'hui sous le nom de Architecture d'Entreprise, Urbanisme...

Nombre de méthodes et de cadres de travail sont apparus au cours du temps, et ce, depuis des lustres. L'un des travaux les plus intéressants a été la définition d'un cadre de définition d'une architecture d'une système d'information par J. A. Zachman, aussi nommé le "Zachman Framework". Le but était de trouver un cadre de travail pour cerner complètement l'ensemble des aspects d'une architecture d'un système d'information, sans contraindre les méthodes de travail.
On peut dire que Zachman a emprunter la méthode du reporter, du journaliste d'investigation. Pour tout système à analyser, il faut se poser les questions : quoi, comment, où, qui, quand, pourquoi (What, How, Where, Who, When, Why). En partant de ces différents aspects, il étudie le système à tous les niveaux de détail : de la stratégie d'entreprise à l'implémentation en passant par la conception, la construction...

En fait, il construit une sorte de hiérarchie de vues basée sur les différents métier de l'entreprise : Planner, Owner, Designer, Builder, SubContractor, Functioning Entreprise. Ce qui est vraiment intéressant avec ce cadre, c'est que les vues métier découlent les unes des autres : La vue Owner découle de ce qui a été défini au niveau de la vue Planner, la vue Designer découle de la vue Owner, etc.

En France, il n'y a pas eu de cadre comme le Zachman Framework mais une méthode très générique de spécification d'un système d'information d'entreprise : Merise. Cette méthode a défini différent modèles (MCD, MPD, MCT, etc.) qui se retrouvent dans le framework de Zachman. Merise a eu beaucoup de succès en son temps, mais il faut dire qu'aujourd'hui, seul le MCD/MLD ont réussi à résister au temps (même si on appelle aujourd'hui MPD alors qu'il s'agit la plupart du temps du MLD défini dans Merise).

Le temps passe, des méthodes apparaissent et disparaissent... Mais il faut bien séparer plusieurs notion :

- un cadre de travail : vision de l'architecture d'entreprise indépendante de la méthode de travail (par exemple : Zachman Framework)

- une méthode de travail : offre une définition claire des tâches et processus de travail pour obtenir une définition de l'architecture d'entreprise (Merise).

- un répertoire de bonne pratique : pour l'organisation du SI ou pour travailler sur la définition du SI (par exemple ITIL, CMMi).

Toutes ces notions ne recouvrent pas les même objectifs, et sont donc souvent complémentaires : on peut utiliser le framework de Zachman, en définissant des modèles Merise (MCD, MPD) en suivant un processus de développement logiciel basé sur CMMi tout en structurant les services IT autour de la notion de client/contrat : ITIL.

Il est rare de voir les entreprise adhérer à tous les concepts portés par ces notions. Le poids de l'existant est souvent trop lourd à porter. En effet, dès que le nombre de personnes entrant et sortant de l'entreprise est faible (le turnover), les personnes se mettent à travailler selon un schéma plus ou moins efficace mais avec une très forte inertie.

Et puis, il est plus risqué dans une grosse entreprise de faire les choses différemment plutôt que de faire comme tout le monde fait depuis des années sans se poser de questions. Les méthodes et cadres ont l'avantage de provoquer le personnel des entreprises en confrontant une vue "idéale" au monde des processus réels de l'entreprise.

How to convert a file to a specific coding system without the help of iconv

2008-07-31T08:00:00.000-07:00

I've once had a problem with coding system. I inadvertently inserted an euro (€) sign into a classic (Unix) buffer, and when I asked emacs to save it, it told me that the coding system I was using was not able to save correctly my buffer.

I saved it using UTF-8, but after that, when I opened the file, Emacs was unable to guess that it was UTF-8.

I found a little command set-buffer-file-coding-system that you can call by C-x RET f that allow me to specify which coding system I want to use for the current buffer and file. This is not like reverting to a specific coding system, no, emacs is really converting the file and each and every character in it to the coding system I want.

That way, I then save the file with the correct coding system, emacs having done the conversion.

Les vues et le contrôle d'accès fin aux données

2008-07-30T08:00:00.000-07:00

La caractéristique principale d'un développeur est la fainéantise ! Si un développeur n'est pas assez fainéant, il ne se préoccupera pas de minimiser le nombre de lignes de code qui lui sont nécessaires.

Dans le cadre des systèmes d'information, il existe un moyen important à maîtriser pour réduire un maximum le code source redondant, comme le code source servant à vérifier l'accès aux données qu'a le droit de voir l'utilisateur. Nombre d'applications sont complètement sclérosées par du code dupliqué, répété à chaque fois qu'un accès à lieu à la base de données.

Un développeur orienté programme aura tout de suite envie de parler Programmation par Aspect, alors qu'il y a pourtant une méthode bien plus simple et d'ailleurs bien plus éprouvée.

Quand les utilisateurs d'une application ne doivent être autorisés qu'à consulter et modifier qu'une partie des informations existante en base de données, le plus simple est de créer des vues au dessus des tables contenant les données. Cela permet :

- d'encapsuler la logique de sécurité à un seul endroit : la vue

- de masquer la logique de sécurité au code source, permet ainsi de rendre l'application indépendante de la logique de sécurité

- de changer de logique de sécurité sans se soucier des impacts au niveau du code source de l'application.

La vue est un concept très simple à comprendre, mais si peu utilisée malheureusement ! Il n'est pas rare de retrouver le même code alambiqué recodant la même logique de sécurité (la clause WHERE de chaque requête SQL). C'est souvent le cas pour MySQL, car ce SGBD n'offre pas toutes les caractéristiques que l'on attend des vues.

J'ai cherché comment coder proprement avec MySQL, un système de gestion des droits fins d'accès au données, comme on peut le retrouver classiquement dans des systèmes de gestion de bases de données "sérieux". J'en ai fait un article : MySQL 5.0 Fine-Grained Access Control (FGAC).

On peut voir sur le site mysql.com que la notion de Fine Grained Access Control n'est pas comprise dans son acceptation la plus courante. Chez MySQL, elle se contente d'aller jusqu'au contrôle d'accès au niveau des colonnes. Mais quand on parle de Fine Grained access control, on pense à un contrôle d'accès au données au niveau de la ligne ("row level security").

Le contrôle d'accès au niveau ligne peut s'implémenter dans à peu près tous les systèmes offrant des vues, même si certains "se la pètent" plus que d'autre comme SE-postgreSQL :

"Only a few commercial DBMS products provide such functionality."

Euh... non. Même sur PostgreSQL (pas SE-PostgreSQL) on peut le faire avec un système similaire à celui que je propose dans mon article. PostgreSQL est beaucoup plus propre que MySQL au niveau des vues, l'implémentation du FGAC est moins tordue.

Le choix d'un système de vues pour contrôler comment l'application voit des données est une décision qui doit être prise au moment de la conception. Il est intéressant de définir clairement quelles sont les vues, et notamment, dans le dossier de politique sécurité, comment est implémenté le contrôle d'accès fin aux données.

Les vues se retrouvent plus ou moins dans tous les systèmes de gestion de bases de données, avec beaucoup de variantes, SQL ayant certainement la palme de la norme la moins suivi au monde :)

Les mises à jour perdues sont trop souvent perdues

2008-07-26T08:00:00.000-07:00

Il est assez honteux de voir encore aujourd'hui des applications Web ne pas traiter les problèmes de mises à jour perdues ("lost updates"). Ce problème est vieux comme le monde, des solutions plus ou moins complexes existent, et pourtant, cela n'empêche pas de le retrouver dans beaucoup d'applications de type concurrente et même dans les frameworks récents comme Grails par exemple.

J'ai rarement vu des dossiers de conception parler explicitement du problème et des solutions choisies. C'est pourtant une des rares choses à étudier.

Pour rappel donc, voici le scénario de ce problème :

Sur une application concurrente (comme le sont toutes les applications Web) :

- une session 1, lit l'information A
- une session 2, lit l'information A
- la session 1, met à jour l'information A
- la session 2, met à jour l'information A

La session 2 va écraser les mises à jour de la session 1 sans s'en apercevoir !

Ce problème arrive dès qu'une information est gérée concurremment (par plusieurs personnes en même temps).

Le problème est très bien explicité dans Expert Oracle Database Architecture de Tom Kyte.

La première chose à faire quand on construit une application Web, c'est de déterminer quelles sont les informations qui risquent d'être mises à jour par plusieurs personnes en même temps.

Ce ne sont pas toutes les informations qui sont accédées en même temps. Même si plusieurs utilisateurs accèdent à la même table en même temps, il se peut que par conception, il soit impossible aux uns d'écraser les données des autres.

Ensuite, on peut utiliser plusieurs méthodes pour empêcher le problème des mises à jour perdues:

- sérialiser tous les accès à l'information (on empêche d'accéder et mettre à jour une information tant qu'elle est en train d'être prise en charge par quelqu'un) : cela revient à mettre un verrou sur l'information, on perd alors tout l'intérêt d'une application concurrente.

- mettre un marqueur sur chaque information pour signifier à quelle date l'information a été mise à jour pour la dernière fois. Concrètement, si l'information est stockée dans une base de données, il s'agit de rajouter par exemple une colonne LAST_MOD contenant la date de dernière modification.

Avant chaque mise à jour, il doit y avoir une vérification que la date de dernière mise à jour LAST_MOD n'est pas plus récente que la date LAST_MOD existante lors de la lecture de l'information. Le scénario se déroule alors comme suit :

- la session 1, lit l'information A et le date LAST_MOD (last_mod1)

- la session 2, lit l'information A et le date LAST_MOD (last_mod1)

- la session 1, vérifie que LAST_MOD n'est pas plus récent que last_mod1. Ce n'est pas le cas donc l'information A est mise à jour, la date LAST_MOD contient maintenant la date à laquelle session 1 a mis à jour l'information (disons last_mod2),

- la session 2, vérifie que LAST_MOD n'est pas plus récent que last_mod1. C'est le cas puisque LAST_MOD en base vaut last_mod2 qui est plus récent que last_mod1. Le problème doit être alors remonté à l'utilisateur (par exemple, un message l'avertis que l'information A a été mise à jour depuis qu'on lui a présenté.)

- Le problème de LAST_MOD c'est qu'on n'est pas sûr à 100% qu'il n'y ai pas de mise à jour exactement au même moment par rapport au système. Si la précision de LAST_MOD est la seconde, il peut arriver le cas où les deux mises à jour se passent dans la même seconde. Le cas est rare il est vrai mais peut exister. Pour pallier à ce problème, il faut recourir à une valeur unique, calculée en fonction de la valeur de l'information. On calcule donc une chaîne de hachage et on la gère comme LAST_MOD (dans une colonne HASH par exemple)

- On peut ne pas vouloir bloquer les mises à jour quand ce n'est pas la même colonne qui est mise à jour. Pour une ligne dans une table de base de données, il y a plusieurs informations. Parfois deux utilisateurs veulent mettre à jour en même temps la ligne mais pas la même colonne de cette ligne. Ainsi, avec LAST_MOD ou HASH, on s'assure qu'il n'y a pas de mise à jour de toute la ligne en même temps. Mais il peut être intéressant de stocker les valeurs de chaque colonne de la ligne dans la session de l'utilisateur et de les comparer à celle de la base avant de faire la mise à jour.

On met à jour seulement les informations qui ont changées, le risque de mise à jour perdu diminue puisque la probabilité de mettre à jour la même colonne de la même ligne en même temps est plus faible. Cela permet d'être moins sensible aux mises à jour perdues et de remonter moins de problème à l'utilisateur.

Quelque soit la méthode employée, il est important d'en choisir une et de s'y tenir pour l'ensemble de l'application, pour qu'il soit plus facile de la maintenir. La méthode doit bien sur être explicité dans le dossier de conception.

Il faut bien garder à l'esprit que le problème des mises à jour perdues peut se produire pour n'importe quelle information, pas seulement en base de données. Dès que les données sont partagées (dans un fichier, en mémoire...), il faut faire attention aux utilisateurs qui vont les mettre à jour.

Parfois même un seul utilisateur peut perdre ses mises à jour s'il ne fait pas attention à ce qu'il fait sur chacun de ses écrans :)

Surqualification en SSII, les ingénieurs analystes programmeurs

2008-07-22T08:00:00.000-07:00

C'est un peu triste à constater mais la majorité des informaticiens professionnels ne développe que des applications Web. Aujourd'hui nombreux sont les ingénieurs informatique qui, dans les SSII (j'en ai fait parti) n'effectue qu'un travail d'analyse et de programmation.

Ce profil s'appelle l'analyste-programmeur, et c'est ce que, normalement, on est 2 ans après le bac avec un DUT Informatique. Il n'y a rien qu'à voir les débouchés cités sur la plaquette de l'IUT Lyon par exemple, pour s'apercevoir que c'est exactement ce que font des milliers d'ingénieurs en SSII.

Les applications de Système d'Information ne nécessite qu'un profil d'analyste programmeur pour correctement modéliser l'information et la mettre en œuvre. Dans les branches dites d'Intégration ou de Système d'Information, les SSII ont finalement peu recours à la formation de leurs employés. L'analyse du Munci sur le malaise en SSII est assez flagrant :

Bien souvent, les jeunes recrues des SSII, qui n’ont connu que ces sociétés (et qui ne connaitront peut-être qu’elles), qui plus est dans un contexte conjoncturel qui leur est favorable, n’ont pas encore conscience de tous ces problèmes (quelques années sont généralement nécessaires pour y voir plus clair...) : beaucoup font preuve d’une certaine naïveté (pour ne pas dire une certaine suffisance) par manque de repères et de comparaisons possibles. Et c’est ainsi que toute une génération, plus ou moins résignée, subit progressivement une mise en condition dictée par le "moins-disant professionnel"...

Beaucoup de problèmes d'organisation du métier d'informaticien semblent liés à la jeunesse des acteurs, à leur naïveté (j'ai été moi même très naïf sur le métier d'informaticien). Si jeunesse savait, si vieillesse pouvait :) Le problème c'est que les vieux informaticiens se font rare, ou sont au chômage...

Sortir du monde XML

2008-07-18T08:00:00.001-07:00

XML, c'est bien connu, est verbeux à outrance. L'objectif initial de XML était de permettre de rendre lisible par un humain les données structurées. Cela présuppose qu'avant XML, les données n'étaient pas lisibles.

Perso, je préfère lire du CSV ou équivalent (comme par exemple les fichiers de conf sous Unix comme httpd.conf) plutôt que du XML. Certains vont même jusqu'à considérer XML comme un fichier binaire dans lequel il ne faut jamais regarder et qu'on n'utilise qu'à travers des outils.

Ce n'est pas étonnant qu'on en soit arrivé là sachant que la plupart des promoteurs des technologies XML et associées (je pense surtout à SOAP) sont des éditeurs d'outils qui ont tout intérêt à ce que XML ne soit pas lisible facilement par un être humain normal, et qu'on soit obligé de passer par un outil pour le manipuler. Ces éditeurs sont toujours les même : Microsoft, IBM en tête.

Non, XML et sa complexité inhérente, n'est pas issu d'un besoin client. Des formats simples comme le CSV par exemple ont été mise en oeuvre avec succès depuis très longtemps sans aucun problème d'incompatibilité. Quand une application doit gérer des flux importants, même avec nos serveurs surpuissants et nos réseaux terabytes, nous n'avons pas assez de bande passante pour supporter la verbosité d'XML.

C'est pourquoi de nouveaux formats sont apparus à la suite d'XML, car c'est bien connu en informatique, comme dans l'industrie de la mode vestimentaire, une nouvelle technologie rend, au yeux du public, les anciennes technologies ringardes et dépassées :

Les outils de développement logiciel et les technologies de l'information en général, partagent ces traits communs avec l'industrie de la mode vestimentaire:

- elle préfère des employés jeunes,

- elle change souvent,

- ce qui est vieux est "repackagé" en quelque chose de nouveau après une décade ou deux,

- la preuve de la supériorité de cette Nouvelle Chose n'est pas vraiment attendue

On peut noter que malgré ça, le CSV à toujours de beaux jours devant lui. JSON est apparu suite à l'émergence des applications Ajax.

Mais c'est maintenant Google qui se met à rendre public le format d'échange de données qu'il utilise partout en interne (justement parce qu'XML est trop lourd). Il s'agit de Protocol Buffers.
Ce nouveau format fait beaucoup de bruit, on peut lire un article de Ted Neward sur le sujet.

Face à XML, on voit donc tout un front de nouvelles technologies qui visent à remplacer la génération des protocoles et technos XML décadente, tellement encrée dans les années 90 :) :
- JSON
- Protocol Buffers
- REST
- Flex & consort
- YAML
- ...

Avec ces "nouvelles" technologies, on est toujours en face d'une guerre sans merci pour se disputer le marcher juteux de l'IT. Mais est-ce pour le bien de l'humanité ? :)

Insert random Japanese Hiragana to overlearn them

2008-07-15T08:00:00.000-07:00

Here are some functions I wrote to create a page of random hiragana for me to exercise for character recognition. The main goal is to learn to recognize quickly hiraganas and pronunce them correctly. As hiragana are written in a random order, it's not an exercise for learning to read japanese :


(defun delnth (n l)
 (if (zerop n)
     (cdr l)
   (let ((prev (nthcdr (1- n) l)))
     (setcdr prev (cddr prev)))
   l))

(defun random-insert (nb l)
 (let ( (remaining (copy-sequence l) ) (inserted nil) (num -1) )
   (while (> nb 0)
     (while (and (> (length remaining) 0) (> nb 0))
       (setq num (random (length remaining)))
       (setq elem (nth num remaining))
       (insert elem)
       (setq inserted (cons elem inserted))
       (setq remaining (delnth num remaining))
       (setq nb (1- nb)))
     (if (> nb 0)
         (progn
           (setq remaining inserted)
           (setq inserted nil))))))

(defvar jp-hiragana '("か" "け" "き" "こ" "く" "じゃ"
                     "ぐ" "げ" "が" "ご" "ぎ" "と"
                     "て" "た" "お" "ひゃ" "あ" "え"
                     "い" "しゅ" "みゅ" "ぷ" "ぴゅ"
                     "ぱ" "ぺ" "ぴ" "う" "ぽ" "びゅ"
                     "じょ" "みょ" "ぴょ" "よ" "や"
                     "ゆ" "ひ" "ほ" "は" "へ" "きょ"
                     "ど" "で" "だ" "ちゃ" "しょ" "ぎゃ"
                     "つ" "りょ" "ぎょ" "め" "ま" "も"
                     "きゅ" "み" "む" "ちょ" "じゅ" "し"
                     "ひょ" "ぞ" "ぜ" "ざ" "ず" "づ"
                     "びょ" "ぎゅ" "ん" "る" "にゃ"
                     "れ" "ら" "ろ" "り" "ひゅ" "りゃ"
                     "に" "の" "な" "ね" "ぬ" "びゃ"
                     "りゅ" "じ" "ぢ" "ち" "わ" "を"
                     "ふ" "にゅ" "す" "そ" "さ" "べ"
                     "せ" "ば" "ぼ" "び" "ぶ" "みゃ"
                     "ぴゃ" "しゃ" "ちゅ" "にょ" "きゃ")
 "List of all Japanese Hiragana with different sonorizations and
 concatenated syllables")

(defun jp-insert-exo (nbchar)
 "Print a page of Japanese exercice."
 (interactive "nNumber of characters to print: ")
 (random-insert nbchar jp-hiragana))

The function delnth returns the list with the nth element removed. Random-insert randomly insert elements of a list of strings or characters. The variable jp-hiragana bring together all hiragana including different sonorization, and syllable concatenation.

The function jp-insert-exo command insert the given number nbchar of hiragana into the current buffer.

One limitation is that hiragana are inserted on a line. One could enhance these functions to correctly write them from top to bottom and left to right.

We can imagine the same kind of thing for katakana or even kanji. This exercise is interesting when you start to learn kana. The goal is to overlearn the kana in order to be really at ease with them.

Print a page or two of them and now, let's practise Hiragana ! Just pronounce each hiragana loudly (or loudly in your head) one after the other.

Un boufficiel de plus : le système d'exploitation

2008-07-14T08:00:00.000-07:00

Il n'y a plus besoin de recherche sur les systèmes d'exploitation depuis les années 70. Comme nous le rappelle fort bien Linus Torvald :

Heureusement, je n'ai jamais senti de pression pour suivre les microkernels. L'université d'Helsinki fait de la recherche sur les système d'exploitation depuis les années 60, et les personnes là-bas, ne voient plus les noyaux des systèmes d'exploitation comme des sujets de recherche. En un sens, ils avait raison : la base des systèmes d'exploitation, et par extension du noyau Linux, sont bien connus depuis le début des années 70. Toute chose après ça a été, à un certain niveau, un exercice d'auto-gratification.

Les Un*x, Windows et autres systèmes d'exploitation, sont construits autour d'implémentations très similaires, voire même identiques. Notamment la couche réseau Windows, qui fut longtemps basée sur l'implémentation BSD et qui seulement récemment à été re-développée.

On peut se demander pourquoi redévelopper une couche réseau extrêmement éprouvée à tous les niveaux (performance, sécurité, etc.). En effet, il y a de grandes chances qu'on voit réapparaître des bugs critiques sous Windows qui ont déjà été résolus il y a longtemps sur la couche réseau BSD.

Mais c'est certainement pour implémenter les nouvelles spécifications IPv6, IPsec, MobileIPv6 (c'est d'ailleurs aussi l'objet du projet KAME sur BSD)

Mais je pense aussi que ça fait parti de la logique de ce boufficiel. Microsoft dispose d'un ensemble de programmeurs qu'il doit bien occuper à quelque chose sous peine de perdre la connaissance du fonctionnement interne de Windows ! En effet, le code de Windows n'est plus documenté et est donc difficile à comprendre. C'est ce que nous raconte Gene Michael Stover à travers son expérience à Microsoft :

Chez Microsoft, si vous voulez savoir comment utiliser une fonction de Windows, vous êtes censés lire le code source de cette fonction pour apprendre comme elle marche et comment l'utiliser.

Notre mémoire étant volatile, seules des personnes qui travaillent régulièrement sur ce logiciel peuvent continuer à comprendre celui-ci. C'est tout le problème. Microsoft ne peut pas réduire la voilure, ne peut pas réduire le nombre de développeur sur Windows sans risquer de perdre de la compétence.

Heureusement, ce problème se marie fort bien avec une disposition réelle des utilisateurs à préférer leurs souhaits à leur besoins, à s'enthousiasmer pour n'importe quelles nouvelles fonctionnalités, comme nous le rappelle Niklaus Wirth dans A Digital Contrarian Retires :

Les programmes fiables et transparents ne sont généralement pas intéressant pour un concepteur de logiciel. Les souhaits des utilisateurs comptent plus que leurs besoins.

L'informatique a donc encore de beaux jours devant elle, ... ainsi que les systèmes d'exploitation :)

Intellisense, ennemi de la pensée désirée ?

2008-07-10T08:00:00.000-07:00

N'avez-vous jamais été embêté par Intellisense ? Ne sentez-vous pas qu'il vous bloque parfois dans votre créativité ? La preuve, dès que j'essaie d'envisager un appel à une nouvelle fonction, dès que j'appuie sur "Enter", j'ai le message désagréable suivant :

En fait, intellisense est incompatible avec la méthode de développement par pensée désirée. Mais qu'est-ce donc que la pensée désirée en informatique ? L'architecte parlera d'approche top-down, mais c'est assez réducteur et simpliste car faisant croire à un processus de conception rationel fonctionnant par décompositions successives.

Comme nous le raconte très bien Steve McConnell dans Code Complete 2, et que je vous traduirais ainsi :

La conception est un problème "perfide" (wicked). Horst Rittel et Melvin Webber définissent un problème comme "perfide" quand il ne peut-être clairement défini qu'en le solutionnant ou en solutionnant une partie de celui-ci (1973).

Bien que la conception soit un problème perfide, on peut adopter des approches qui permettent d'être créatif quand à la solution à apporter.

Une des méthodes les plus intéressante est l'approche de la programmation par la pensée désirée : vous codez des algorithmes, des routines, des classes selon ce qui est plaisant d'imaginer, en imaginant un monde idéal et en faisant abstraction (dans un premier temps) du réel, de ce qui existe et de ce qui reste à développer.

Ainsi, si vous désirez développer une application de gestion de contacts personnels, vous commencez par écrire un programme utilisant une API idéale de gestion de contacts :

ContactCollection.GetMyContacts() ContactCollection.GetMyProfessionalContacts()

Ce n'est qu'ensuite que vous pouvez vous pencher sur l'implémentation de chacune des fonctions GetMyContacts, GetMyProfessionalContacts(). Cet exemple est trivial et vraiment simpliste mais ce qu'il faut retenir c'est qu'une telle approche permet de s'abstraire des détails d'implémentation, ce qui promeut une architecture orienté "problème métier" plutôt que "problème technique".

C'est là ou intellisense peut poser problème pour le développeur distrait. Sans faire attention, intellisense pousse à utiliser ce qui existe déjà, à penser implémentation avant de penser modélisation.

Et voilà comment on en arrive à développer des applications sans séparation claire entre les responsabilités de chaque module. Intellisense peut être vraiment intéressant quand l'architecture est complète et clairement définie, mais il serait bien de pouvoir désactiver cette fonctionnalités quand on se met à réfléchir à une architecture indépendante de l'implémentation.

Goto implicites et structures de données

2008-07-06T08:00:00.001-07:00

Qu’est-ce qu’on reproche à ce fameux GOTO ? D’être indiscipliné ? De semer l’anarchie dans le code source ? Oui, c’est vrai qu’il nous ramène en plein moyen-âge informatique, à une époque où on connaissait à peine la notion de routine. Aujourd’hui, il est rare de trouver explicitement des GOTO dans du code. Il y a eu et il y a toujours beaucoup de bruit autour de l'emploi du GOTO, mais franchement, la hache de guerre est depuis longtemps enterrée.

Mais est-ce qu’implicitement il n’y aurait pas des sortes de GOTO qui se cachent discrètement dans mon code ?

Les structures des données traitées par un programme, contraignent les algorithmes chargés de leur manipulation. L’utilisation de tableaux indexés contraint très peu les algorithmes, ce qui fait qu’il peu exister une organisation implicite, non visible des données contenues par un tableau.

Un programmeur sera donc tenté d'accéder directement à n'importe quel élément du tableau et ainsi, reproduit au niveau du code un flux de traitement non séquentiel, voire même aléatoire : un peu comme des GOTO !

Ainsi, des sortes de GOTO implicites mais bien présents (par exemple, l’inflation du nombre de if(), de switch() et de break sans parler des IF arithmétique qu'affectionne les programmeur en Fortran) dans les algorithmes peuvent être employés pour gérer les données d’un tableau.

Comment s’assurer que les développeurs d’un logiciel ne se mettent pas disséminer des GOTO implicites ? En leur interdisant d’utiliser des tableaux indexé et en les obligeant à employer de véritables conteneurs comme les ensembles (Sets), les piles (Stacks) et les files d’attentes (Queues). Ces conteneurs obligent à accéder de façon séquentielle à leurs éléments et évitent ainsi l’introduction de GOTO implicites.

A éviter donc toutes les méthodes du type Collection.toArray()... ces méthodes ont l'inconvénient d'exposer partiellement l'implémentation, de dénaturer la collection en question.

Ce qui nous ramène donc à l'analyse statique du code, avec les outils classiques que sont les outils OpenSource FindBugs et PMD pour le monde Java, mais aussi commerciaux comme le puissant Polyspace que j'ai utilisé une fois sur un projet, ou d'autres. Il n'existe pas de règles déjà définit pour empêcher l'utilisation de tableau bien que de nombreuses règles portent sur le mauvais emploi des tableaux à travers les classes.

Alors, prêt à jouer les dictateurs et empêcher tout emploi de tableau indexé ? Allez... j'accepterai peut-être un Array si c'est correctement justifié :) mais alors, je considerai ça comme un nouvelle dette technique.

Prévision de changement de besoin

2008-07-02T08:00:00.001-07:00

La seule et unique constante dans l'univers c'est le changement. Il en va de même avec les besoins des utilisateurs, clients, maîtrise d'ouvrage d'une application. Comment faire pour suivre cette évolution à moindre frais. Bien que certains proposent de multiples techniques de "refactoring", l'objectif est de ne pas avoir du tout à refactorer.

On peut y arriver si on envisage comment l'application va évoluer au cours du temps. Oui, mais ... qui peut prédire l'avenir ? personne, en tout cas, pas moi. Pour essayer de limiter les dégâts et prévoir au maximum les changements à venir, la gestion des exigences a été pour moi ce qui m'a le plus permis d'avoir une approche rationnelle de la gestion et de la prévision du changement.

L'article de Wikipedia est clair sur le sujet :

En ingénierie, et plus particulièrement dans les procédures d'appel d'offres publiques et privées, les exigences sont l'expression d'un besoin documenté sur ce qu'un produit ou un service particuliers devraient être ou faire. Elles sont le plus souvent utilisées dans un sens formel dans l'ingénierie des systèmes et dans l'ingénierie logicielle.

et notamment, sur les différents types d'exigence :

- Les exigences métier qui décrivent le quoi dans les termes du métier. Elles décrivent ce qui doit être fourni ou réalisé pour produire de la valeur.

- Les exigences produit qui décrivent le produit ou le système à un haut niveau. Elles répondent aux exigences métier et sont couramment formulées comme les fonctionnalités que le système doit réaliser. On les appelle également exigences fonctionnellles ou spécifications fonctionnelles.

- Les exigences de processus qui décrivent le comment. Ces exigences prescrivent les processus que l'on doit suivre et les contraintes auxquelles on doit se conformer pour la réalisation du système. Dans ce cas, on trouve par exemple des exigences de sécurité, d'assurance qualité, ou de management.

Le découpage en exigences des besoins permet de mettre un nom (un identifiant) sur chaque besoin élémentaire, le but étant d'avoir une liste exhaustive.

Au delà de permettre dans un projet, un suivi de bout en bout des exigences, l'intérêt principal c'est de ne pas perdre le besoin client dans une foule de détails plus ou moins techniques. Cela permet notamment au client d'être plus confiant et de lui permettre de valider l'expression écrite de son besoin.

Une fois la liste d'exigences rédigée, apparaît alors la phase qui permet de se protéger contre les changements du besoin. C'est une phase d'assurance qualité qui vise à s'assurer que toutes les exigences respectent les propriétés suivantes:

- Nécessaires – Elles doivent porter sur des éléments nécessaires, c'est-à-dire des éléments importants du système que d'autres composants du système ne pourraient pas compenser.

- Non ambiguës – Elles doivent être susceptibles de n'avoir qu'une seule interprétation.

- Concises – Elles doivent être énoncées dans un langage qui soit précis, bref et agréable à lire, et qui de plus communique l'essence de ce qui est exigé.

- Cohérentes – Elles ne doivent pas contredire d'autres exigences établies, ni être contredites par d'autres exigences. De plus, elle doit, d'un énoncé d'exigence au suivant, utiliser des termes et un langage qui signifie la même chose.

- Complètes – Elles doivent être énoncées entièrement en un endroit et d'une façon qui ne force pas le lecteur à regarder un texte supplémentaire pour savoir ce que l'exigence signifie.

- Accessibles – Elles doivent être réalistes quant à aux moyens mis en œuvre en termes d'argent disponible, avec les ressources disponibles, dans le temps disponible.

- Vérifiables – Elles doivent permettre de déterminer si elles ont été atteintes ou non selon l'une de quatre méthodes possibles : inspection, analyse, démonstration, ou test.

Mais on peut aller plus loin pour se protéger des futurs changements : imaginer au moins 3 possibilités d'évolution pour chaque exigence.

L'important est d'identifier ces évolutions comme de nouvelles exigences internes. Selon l'état d'esprit de votre client ou donneur d'ordre, vous pouvez faire apparaître ces nouvelles exigences ou pas.

Lors de la phase de définition de l'architecture, il est donc alors possible de faire des choix informés qui permettent à moindre coût l'évolution de chaque exigence métier, et d'en faire un véritable suivi.

Il existe beaucoup de techniques permettant l'extensibilité et la personnalisation d'une architecture. Savoir à l'avance ce qui va changer permet de ne pas oublier de mettre en place ces techniques aux bons endroits et de renforcer la solution face à l'avenir.

Ce travail implique bien sur un surcoût, mais beaucoup moins important que de répondre à un changement d'exigence non anticipé. Dans le cas de société de service, le surcoût est inutile dans le cas de développement au forfait, mais devient beaucoup plus justifiable dans le cas de TMA où la rentabilité des contrats s'avère dépendant de la qualité de l'application.

Ce processus de prévision des changements du besoin peut être pondéré par la prioritisation de ceux-ci. Il peut être bien sur être plus qu'intéressant d'interroger le client sur chacune de ces évolutions possibles. Car finalement, c'est quand même lui le mieux placé pour répondre.

L'arme absolue de la qualité : la CheckList

2008-06-28T08:00:00.000-07:00

Le problème avec l'informatique c'est qu'elle ne supporte pas l'imprécision, l'à-peu-près. La machine sur laquelle tourne un programme n'ayant aucune intelligence en soi, et les langages employés sont finalement, tellement bas niveau qu'il faut toujours penser à tous les détails, ceux qui font toute la différence entre un code qui tourne correctement et un code boggué.

Le diable est dans les détails, c'est sûre, mais l'excellence aussi. On trouve dans tous les bonnes bibliothèques informatiques, des tonnes de livres remplis de bonnes pratiques qu'on doit mettre en oeuvre dans tous les cas possible est imaginable de l'activité de développement d'un logiciel.

Or qui peut se targuer de connaître toutes ses bonnes pratiques, et qui est capable de les utiliser à bon escient et à tous les moments opportuns ? Avoir tous les détails en tête n'est pas humain, puisque le fondement de l'esprit humain est l'oubli. Le programmeur de base est ainsi fait qu'il a une mémoire bien plus volatile que son PC. Comment faire pour qu'un développeur puisse coder proprement sans avoir à lire des milliers de pages de livres informatiques ?

Un des problèmes est que la maîtrise d'une matière demande beaucoup de temps, au minimum une dizaine d'année, quelque soit la matière. Or, en France tout du moins, les ingénieurs informatique ont tous tendance à ne plus vouloir programmer, passé les quelques années d'expérience, principalement par le fait que l'activité de programmation est déconsidérée par rapport aux autres métiers tournant autour. Résultat, les personnes en charge du développement d'application sont souvent jeunes et inexpérimentées, même si elles ont beaucoup de volonté.

La solution classique, simple, c'est bien sur d'utiliser des "checklists", des listes de vérification à chaque étape du processus de développement.

Un projet sans checklist ne peut produire que du code propre à chaque développeur. Il ne sera pas forcément mauvais, mais le code source sera construit sous la forme d'un écosystème avec plusieurs façon de coder différentes, de façon de traiter les erreurs différentes, d'organiser et de nommer les éléments du code, etc.

La checklist est un moyen simple et efficace. Elle peut être employée pour améliorer n'importe quel type d'activité même créative. On la voit malheureusement trop peu employée là où elle aura pourtant le plus d'impact sur la productivité de nos activités.

Dans des domaines où la qualité est un facteur important, les checklists sont au coeur de l'assurance qualité, comme par exemple chez Renault où la validation de la conception d'un nouveau modèle passe par la vérification de toutes les checklists maison, construites au cours de années et rassemblant toutes les bonnes pratiques durement apprises par l'expérience.

La checklist implique un processus minimal :

- un travail

- la vérification de ce travail au regard de la checklist.

La conception et l'utilisation de checklists est bien l'activité fondamentale de ce qu'on appelle couramment "l'assurance Qualité". La vérification à la main des checklists est assez longue et coûteuse, et on a tout intérêt à mettre les vérifications dans un processus automatique, notamment par l'utilisation d'outils.

Au niveau du code source, on dispose de beaucoup d'outils plus ou moins puissants, comme les analyseurs statiques. Chacun peut les utiliser pour soi-même mais cela prend tout son sens quand on effectue les vérifications au niveau du système de gestion des sources, lors d'un "commit" dans Subversion par exemple. Il est aisé d'ajouter des "hooks" aux évènements de base des systèmes de gestion de configuration comme CVS ou Subversion.

On ne peut pas tout vérifier au niveau d'un commit, cela prendrait trop de temps, et les développeurs se mettraient à attendre trop longtemps avant de commiter et y réfléchiraient à deux fois, voire, il ne commiteraient jamais ! C'est pour cela qu'il est intéressant d'effectuer des vérifications régulièrement sur un serveur d'intégration continue.

Aujourd'hui l'intégration continue à le vent en poupe, tout le monde en parle. Mais là où on a le plus intérêt à effectuer des vérifications, c'est aux phases amonts de la simple activité de codage.

Le coût d'une erreur étant dépendant de la phase dans laquelle elle est détectée, une erreur d'expression de besoin coûtera beaucoup moins chère à corriger lors de la phase d'expression de besoin que lors du codage de l'application. Ainsi, on a tout intérêt à vérifier les phases amonts pour éviter de grosses embûches en phase de construction.

On trouve beaucoup de checklists sur le Web, mais je n'ai pas réussi à trouver beaucoup de sites proposant une mise en commun de checklists, notamment par profession.

Ca serait vraiment intéressant de mettre en commun toutes les bonnes pratiques, sous forme de checklist à un seul endroit, directement utilisable sur les projets de développement logiciel. Les livres de Steve McConnell sont particulièrement riches en checklists et méritent vraiment qu'on s'y intéresse.