Mon blog

Annie Chéneau-Loquay avait déjà dirigé « Enjeux des technologies de la communication en Afrique » et continue à rassembler les contributions des meilleurs spécialistes du développement des NTIC en Afrique, via le programme de recherche Africanti (auquel succède le programme Net Suds).

Les contributions rassemblées dans ce livre couvrent de très nombreux aspects des NTIC. Elles sont très détaillées, parfois touffues : voici un livre dont on ne dira pas qu'il se lit « comme un roman ». Mais certaines contributions sont fascinantes comme celle Camille Lancri sur la région de Sikasso au Mali ou celle de Caroline Dulau et Annie Chéneau-Loquay sur les commerçants de Kayes au Mali ou, moins exotique pour un français (encore que...), celle de Claire Scopsi qui a étudié le monde étonnant des cyberboutiques du quartier du Chateau Rouge à Paris.

Loin des grands discours comme ceux tenus dans les réunions de l'IGF ou de NEPAD, un ouvrage qui permet de mesurer le dynamisme des africains, les difficultés recontrées et les progrès réalisés.

Le livre semble aujourd'hui être épuisé chez l'éditeur mais peut être commandé à la MSHA. Sinon, il sera sans doute bientôt en ligne.

Il existe de très nombreux livres de programmation. Et de très nombreux livres sur les détails pratiques de tel ou tel langage ou bien de tel ou tel environnement de programmation. Mais ce livre est original : il présente plutôt l'essence de la programmation sur Unix, pas les détails des outils mais plutôt comment faire des programmes qui soient bien conformes à l'esprit Unix.

Pas besoin de présenter Eric Raymond. L'un des meilleurs auteurs sur Unix et la programmation explique ici les principales caractéristiques d'Unix, pourquoi les programmes Unix sont comme ils sont et pourquoi il faut continuer. Par exemple, qu'il vaut mieux faire des petits programmes (Rule of Modularity), connectés par des interfaces simples (et pouvant donc être composés, comme on compose des fonctions), plutôt que des monstres comme OpenOffice, ininstallables et inutilisables sur un vieux PC et qui, surtout, ne permettent pas facilement de coopérer avec d'autres programmes.

Commme toujours avec Raymond, il présente toutes ses règles et aphorismes comme exprimant un consensus, alors que certaines sont plutôt personnelles. Des dix-sept règles qu'il présente, certaines (comme la Rule of Modularity donnée plus haut ou bien la Rule of Silence, qui dit qu'un programme doit se taire, sauf s'il a quelque chose d'utile à dire) seront en effet approuvées par tous les Unixiens mais ce n'est pas le cas de toutes.

Raymond, après avoir exposés les dix-sept règles, donne ensuite un bon cours de génie logiciel, qui est utilisable dans bien d'autres environnements qu'Unix. Il couvre un très grand nombre de sujets passionnants comme la conception de mini-langages. De nombreuses études de cas ponctuent son exposé.

Il passe ensuite à la mise en œuvre : quel langage de programmation choisir, quel système de contrôle de versions, la documentation, etc.

En résumé, un excellent livre, qui devrait être lu par tous les programmeurs et chefs de projet. Cela leur serait bien plus utile que de passer du temps à faire des diagrammes avec le dernier outil graphique à la mode.

Il existe de nombreux livres sur les outils et les techniques de production de logiciels. Il y a beaucoup d'ouvrages sur la gestion de projets logiciels. Mais il n'y avait guère de texte s'attaquant à la gestion de projets de logiciel libre, qui est pourtant assez spécifique (moins de camemberts et de diagrammes que dans les projets commerciaux, mais davantage de communication et de textes).

Karl Fogel a déjà écrit un livre sur CVS et a été un des développeurs de CVS et de Subversion. Mais son mérite ici est autre : il essaie d'expliquer comment fonctionne un projet de logiciel libre, du point de vue technique bien sûr, mais aussi et surtout dans les aspects humains.

Les textes précédents sur cette question étaient soient des proclamations très biaisées (tout est super, tout le monde est heureux, la liberté, c'est formidable) soit des productions très partielles, comme le célèbre article d'Eric Raymond, The cathedral and the bazaar, qui a l'avantage d'avoir été l'un des tout premiers à expliquer comment sont produits les logiciels libres, mais dont le principal inconvénient était de ne traiter qu'un seul type d'organisation (le bazar), en oubliant que la principale caractéristiques des logiciels libres est justement leur variété, technique bien sûr, mais aussi organisationnelle. Karl Fogel n'échappe d'ailleurs pas toujours à ce travers (pour des raisons évidentes, la plupart des exemples concernent Subversion) mais au moins il le reconnait.

Le livre couvre donc :

• L'infrastructure technique du projet. Si les logiciels libres n'utilisent pas MS project, ils dépendent néanmoins de beaucoup d'outils comme le système de gestion de versions.
• L'organisation du projet, analysée par notre Montesquieu du logiciel libre. Le projet peut être démocratique (au sens athénien du terme, donc une démocratie réduite à une petite élite) ou bien géré par un dictateur. (C'est le terme qui est utilisé, par exemple pour Python. Loin des hypocrisies de la gestion des ressources humaines, le monde du logiciel libre aime bien appeler un chat un chat. Les administrateurs de Wikipédia ont le titre officiel de "bureaucrates".)
• La question toujours délicate de l'argent et du financement.
• La communication entre les développeurs, avec tous ses pièges, s'agissant d'organisations internationales, et où l'ultima ratio de la hiérarchie n'est pas toujours possible.
• La gestion du personnel, celle dont le célèbre Andy Tanenbaum prédisait, dans un débat mémorable en 1993 avec Linus Torvalds, qu'elle serait l'écueil sur lequel se briserait tout projet de logiciel libre.
• Les questions juridiques, licences, brevets, etc.

Sur tous ces points, Karl Fogel est un grand connaisseur et sait toujours expliquer clairement les enjeux et les bonnes approches.

Un livre dont le but affiché est de servir aux auteurs de logiciel libre mais qui peut être lu par toute personne qui s'intéresse à ces projets qui semblaient utopiques il y a encore quinze ans. Ceux qui se demandent "Comment est-ce que cela peut marcher ?" trouveront sans doute des éléments de réponse dans ce livre.

Le livre est intégralement enligne, en http://producingoss.com/.

Les logiciels développés par Mozilla, dont le plus connu est le navigateur Web Firefox, sont très répandus mais beaucoup de leurs utilisateurs ignorent qu'ils sont aussi des environnements de développement, des plate-formes pour réaliser des programmes. Ce livre explique comment.

Un des charmes de Firefox est la disponibilité d'un grnd nombre d'extensions : non seulement on peut changer l'apparence du navigateur, mais on peut aussi ajouter des boutons, des menus, avec du code derrière. Par exemple, pour lire des flux de syndication, j'utilise en général Sage. Pour tester des pages Web, Web developer. Pour éditer des textes via des formulaires Web (comme pour Wikipedia), j'utilise ViewSourceWith.

De telles extensions (qui peuvent être développées pour n'importe quel logiciel Mozilla, pas seulement pour Firefox) sont écrites avec un mélange de nombreuses technologies : XUL pour décrire l'interface, CSS pour la présentation, JavaScript pour le code lui-même, XPCOM pour l'intergiciel, la communication entre les composants de Mozilla, RDF pour la description des composants, etc.

Ces technologies sont plus ou moins simples d'accès, plus ou moins documentées et évoluent parfois rapidement. Un livre de synthèse n'est donc pas inutile et c'est l'ambition de ce livre.

En 450 pages, il n'y réussit pas entièrement : il faut dire que le sujet n'est pas facile. On trouve peu de documentations synthétiques en ligne. L'API est particulièrement peu documentée. Et la technologie change rapidement (la version 1.5 de Firefox vient de sortir). Comme le livre est publié sous une licence libre, il est donc prudent de se fier à la version en ligne, la version papier datant de 2002, une éternité pour Mozilla.

Le livre couvre donc successivement toutes les techniques mentionnées plus haut. Vu le nombre d'auteurs, je suppose que chaque chapitre a été écrit très indépendamment car il y a peu de vision globale, juste une succession de techniques, qui semblent parfois redondantes (Javascript et les gabarits XUL, par exemple). Certains domaines qui me semblent importants, comme "chrome", le registre interne des ressources (code, images, etc) sont à peine traitées.

Tout est bien écrit et bien expliqué, certes, mais, en refremant le livre, on se sent un peu dépassé par l'ampleur de la tâche et le foisonnement d'information. Il existe heureusement des logiciels pour automatiser une partie des tâches de création d'une application Mozilla (ils sont décrits dans l'annexe B) et on peut toujours étudier les applications existantes pour voir comment elles marchent.

Je n'ai pas encore essayé de créer une vraie application avec ce livre comme guide, je vous tiendrai au courant.

Il existe désormais trois langages courants pour écrire des schémas XML c'est-à-dire pour décrire les éléments autorisés ou interdits dans un document XML. La norme du W3C, souvent appelée abusivement "schéma" tout court (une erreur que ce livre commet aussi) est la plus connue.

La norme "W3C Schema" est très complexe : mais ce livre réussit à l'exposer de manière simple, en commençant par un schéma minimum, puis en le compliquant au fur et à mesure que l'on souhaite décrire d'autres propriétés du langage qu'on développe. Il y a un seul fil conducteur dans le livre pour tous les exemples (une bibliothèque, avec description des livres) et cela facilite la plongée progressive dans les arcanes de XSD (autre nom des "W3C Schema").

L'auteur expose donc les schémas plats (où tous les éléments sont au même niveau) et les schémas en poupée russe, où les élément sont emboîtés. Il s'attaque ensuite au deuxième volet de XSD, après la structure du document : les types de données. Il expose en grand détail comment utiliser les types prédéfinis puis comment créer les siens.

À ce stade, on peut écrire son schéma (et c'est ce que j'ai fait avec succès). Mais les points plus subtils de l'écriture de schémas font ensuite l'objet d'un chapitre chacun (la documentation, la création de schémas qui pourront facilement être étendus, les espaces de noms...)

Personnellement, mes seuls manques ont été un chapitre de présentation de certaines normes utilisant les W3C Schemas (ce sont souvent de grosses normes très complexes et un tour d'introduction serait le bienvenu) et un autre chapitre sur les outils existants (validateurs, éditeurs).

En résumé, voici un excellent livre, par un auteur très compétent, qui est également l'auteur du livre "concurrent" chez O'Reilly, sur RelaxNG.