Styles

jeudi 11 décembre 2008

Gentoo Linux, grandeur et décadence de Portage

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.

samedi 8 novembre 2008

Dette technique - Comment la présenter ?

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.

jeudi 16 octobre 2008

Contribuer en français à Wikipedia

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.

dimanche 12 octobre 2008

La journalisation n'est pas neutre

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...

mercredi 8 octobre 2008

Moyens de mieux vivre la prestation de service

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.

mardi 23 septembre 2008

Transformer sa Nintendo DS en tablette graphique avec Colors!

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 :)

vendredi 19 septembre 2008

Hacking de la sécurité de la Nintendo DS

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.

lundi 15 septembre 2008

Java mis au rebut par Sun

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é".

jeudi 11 septembre 2008

KeyPass, OpenID et mots de passe dur

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.

dimanche 7 septembre 2008

Nintendo DS, hombrews et mégadémos

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...

mercredi 3 septembre 2008

La Guerre des browsers est relancée !

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.

lundi 1 septembre 2008

Jargon, effets de mode et confusions dans l'informatique

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.

jeudi 28 août 2008

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

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.

dimanche 24 août 2008

Terminologie de la communauté des informaticiens

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.

jeudi 21 août 2008

Le capital-risque et la levée de fond

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.

lundi 18 août 2008

Programmer dans un langage

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.

vendredi 15 août 2008

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

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é.

mardi 12 août 2008

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

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.

samedi 9 août 2008

Le chemin bien sinueux de l'excellence

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 ?

mercredi 6 août 2008

Le contenu n'est pas une donnée

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 (m3). Il est assez difficile de s'engager sur une charge et des délais quand on ne connaît que le nombre de m3 à numériser, il faut alors donner une fourchette haute à l'estimation.

dimanche 3 août 2008

Architecture des Systèmes d'Information et le framework de Zachman

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.