Difficile de parler de kaizen pour un projet aussi petit et qui finalement n'avance que par à coup, deux fois par an, mais pour tenir compte des retours utilisateurs j'ai été amené à tester quelques nouveaux outils pour améliorer la qualité de Yapsy et les interactions avec les utilisateurs qui contribuent des modifications:

• depuis quelques mois les sources (dans un dépôt mercurial sur sourceforge) sont synchronisées avec un répertoire git sur github, ce qui devrait simplifier la vie des contributeurs dont une bonne partie semble fan de github et qui pourront cloner et faire des pull requests à loisir.
• depuis sa dernière sortie yapsy est lié au serveur d'intégration continue Travis CI pour qu'à chaque commit la batterie de test soit lancée.

Ci-après mes impressions sur ces deux outils.

Lire la suite…

Cette revue concerne un livre qui m'a été offert cette année: Les grandes civilisations. C'est la transcription d'une série de conférences organisées par Carlo Ossola et Jack Ralite en 2009-2010. Chaque chapitre est une présentation faite par un professeur du Collège de France d'une civilisation liée à la chaire dont il est titulaire. Le livre est étonnamment court, se lit très bien et comme c'est un cadeau je peux déjà remercier le bienfaiteur.

Le thème général est donc de donner un aperçu des civilisations mais il faut dire que le but annoncé de "comprendre" ce qu'est une civilisation n'est traité que marginalement par certaines présentations: la démarche est laissée en exercice au lecteur ce qui n'est pas si mal.

Sans espérer l'originalité, je classerais en deux axes les éléments que j'ai retenus au travers des descriptions des différentes civilisations.

Lire la suite…

Pour me changer les idées et aussi un peu par curiosité parce que les problèmes d'ergonomie et d'expérience utilisateur m'intéressent, j'ai décidé de me cultiver un peu plus sérieusement sur l'UX (user experience) très à la mode ces dernières années.

Ce billet est une revue du livre Storytelling for User Experience par Whitney Quesenbery et Kevin Brooks sur lequel je suis tombé d'une façon bien mystérieuse (en fait j'ai réellement oublié, mais c'est peut-être bêtement via une promo chez O'Reilly).

J'ai trouvé le livre assez bien fait et plutôt instructif quoiqu'avec pas mal de longueurs à mon goût qui sont probablement dues d'une part au fait que je ne fais pas vraiment partie de l'audience pour laquelle il a été écrit et d'autre part parce qu'il y a beaucoup de redondance à travers le chapitre (peut-être à dessein pour que certains messages restent ?).

En fait le point le plus intéressant du livre est que les auteurs se sont administrés leur propre médecine en appuyant chacun de leurs arguments par une "histoire" et en s'assurant que le livre soit facilement "navigable" avec une structure claire et des résumés très concis en fin de chaque chapitre qui permettent au lecteur de sauter simplement les chapitres qui ne l'intéressent pas.

Lire la suite…

Dans mon élan actuel d'exploration de la littérature sur la gestion de projets informatiques, j'ai voulu chercher des réponses à une question que je me pose depuis quelques temps à propos des méthodes Agiles: le Manifeste Agile m'avait particulièrement plu parce qu'il met en avant les "individus et interactions devant les processus et les outils" et pourtant la quasi totalité des ressources  que j'ai pu lire sur le sujet tournent autour des carcans de tests, de l'intégration continue, des sprints, itérations, daily scrums et autres kanban... En bref: toutes ces ressources se focalisent sur les processus et les outils !

Il y a une explication simple à cela: les procédures sont plus faciles à décrire, critiquer et raffiner pour des gens avec un penchant technique comme les ingénieurs tels que moi, et après tout, les "processus agiles" sont conçus pour encourager les interactions et soulager les gens des problèmes inhérents au développement informatique (bugs, changement des spécifications etc).

Cela-dit ça revient tout de même à mettre les processus en avant en supposant que les personnes en bénéficieront automatiquement par la suite. Et c'est cette petite contradiction qui m'a motivée pour rechercher un livre qui traite explicitement des aspects "humains" des méthodes agiles et finalement de lire Individuals and interactions: An Agile Guide par Ken Howard, Barry Rogers .

Lire la suite…

Une revue en retard de la lecture elle-même déjà un peu tardive de ce livre très connu sur la gestion de projet informatique: Le Mythe du mois-homme par Fred. P. Brooks, 1995 (1ere édition 1975)

J'ai beaucoup entendu parler de ce livre ces dernières années et j'ai été étonné de constater que tout ce qu'on en dit est vrai !

Derrière une patine qui est en intéressante pour elle-même et aussi parfaitement attendue pour un livre écrit à l'aube du développement informatique (1975 !) tout semble curieusement actuel: de l'incapacité chronique des développeurs à concevoir les difficultés qui ne manqueront pas de perturber la retranscription de leurs idées sous la forme d'un programme stable, à la tendance naturelle des managers à chercher à faire grossir leurs équipes tout en négligeant les gains de performance atteignables par une meilleure circulation de l'information et la mise à disposition de meilleurs outils pour leurs équipes, tout y est !

Un autre point particulièrement intéressant: dans l'édition de 1995 l'auteur rajoute des observations qui lui permettent de répondre à ses premières critiques, de confirmer certaines de ses affirmations et de pointer à certaines de ses erreurs. Le livre contient sa propre revue !

Inutile de préciser que ce livre est incontournable pour ceux qui sont intéressé par la gestion de projet logiciel, et malgré cela, le premier aspect qui m'a plu réside dans la justesse avec laquelle l'auteur caractérise le "plaisir de programmer":

• la joie de fabriquer quelque chose
• la joie de faire quelque chose d'utile
• la fascination pour les puzzles
• la joie d'apprendre en permanence
• la joie de travailler de la matière qui est essentiellement de la "pensée pure"

Dans la suite de ce billet, je relève quelques uns des autres points saillants du livre en essayant de les classer en trois catégories: planification, développement, organisation.

Lire la suite…

Récemment pour le développement de ma librairie Yapsy, je suis tombé sur quelques subtilités liés à la création de "paquets" pour des librairies Python.

J'utilise distutils bien sûr et je place les paquets générés sur http://pypi.python.org, mais j'avais les problèmes suivants:

• les fichiers de données utilisés par mes tests unitaires n'étaient pas packagés
• je n'arrivais pas à faire comprendre à pypi que l'un des paquets "sources" ne pouvait être récupéré que par les utilisateurs de Python2 alors que l'autre devait l'être par les utilisateurs de Python3, bien qu'ils correspondent tous les deux à la même version du logiciel (typiquement je n'arrivais pas à avoir ces deux paquets sur la même page de pypi.python.org)

Les solutions étaient relativement simples mais étrangement peu documentées sur internet...

Lire la suite…