Rom's Code Corner

ça me play

2012-01-28T23:30:00.000+01:00

Il y a des jours comme ça ou vous avez l'impression d'avoir raté 10 ans de nouvelles technologies, de nouvelles méthodes de travail. Vous vous prenez de la grosse innovation en pleine poire. Ça réveille et ça perturbe.

Dans mon métier, j'ai l'habitude d'utiliser des technologies éprouvées. Jusqu'il n'y a pas si longtemps, c'était des applications en Java + EJB 2. C'était compliqué, c'était triste. D'autant que dans l'application en question, les EJB étaient forcément sur le même serveur que la webapp, les requêtes SQL pour aller chercher les objets devaient a priori être décrite dans les EJB. Les JSP contenaient du code métier. On s'avait ce qu'était MVC mais on ne retrouvait pas le concept dans notre application. J'avais pris l'habitude dans mon jeune temps de coder des sites web en php3 en un week-end en récupérant mes données en faisant directement du SQL sans prise de tête... Alors oui, c'était triste.

Pourtant, je sais bien qu'il y a des choses qui ont évolué le développement web java dans les années 2000. Il y a eu Spring, les POJO, l'inversion de contrôle, des choses qui permettaient de tester et découpler les systèmes plus facilement. Et puis il y a JPA / Hibernate, qui permet d'utiliser une couche de persistance sans même savoir ce qu'était le SQL ! Des trucs de déglingos, quoi ! A mon grand regret, ma connaissance de ce genre de chose m'est restée théorique (mon PC trop lent à la maison du temps où j'utilisais Eclipse).

Il y a quelques temps (années ?), j'ai vu la vidéo de présentation du Play! Framework. Puis j'ai vu Ruby on Rails. Puis j'ai vu Grails, Django. J'ai essayé tout ça très rapidement, ça avait l'air très cool.
Cette semaine, j'ai eu dans l'idée que ce serait pas mal de faire une web app pour gérer les livraisons de notre grosse application. Je ne savais pas trop quelle techno choisir : nous avons un accès restreint sur notre serveur de développement (!), celui-ci étant hébergé chez le client. Je n'avais pas envie d'argumenter une demande pour installer quoi que ce soit. J'ai alors réalisé qu'un JDK était disponible. C'est quoi ce truc qui permet de coder des appli web en Java rapidement ? Play! ?

Je décide de mettre les mains dans le cambouis, la réunion d'avancement hebdomadaire de une heure trente est un bon moment pour jouer. Je me lance. Je ne connais rien à JPA, j'ai regardé du Groovy du coin de l'oeil mais je n'ai pas peur. Je suis la doc intégrée. J'avance tranquillement.

Tout est très simple dans ce framework. On lance l'appli, on écrit du code, il est compilé et déployé à la volée (il suffit de recharger les pages). Les pages web sont générées par Groovy à partir de templates dans un dialecte plutôt simple. En une heure trente, j'ai écrit la base de mon modèle avec relationnel, mis en place mon contrôleur, des données de tests et des tests unitaires ainsi qu'un début de vue pour afficher mes objets. Le tout en regardant régulièrement la doc. Et pas dans un langage rapide à coder comme Python ou Ruby mais bien en JAVA.

Bref, c'est un truc de malade, je suis réconcilié avec Java. Je vais essayer de continuer mon appli (pendant une prochaine réunion ?). À ce train là, quelques jours me suffisent pour faire un truc cool. Et en plus, le framework intègre JQuery et Sass ! Génial !

Au fait, vous utilisez encore Eclipse comme IDE Java ? Essayez IntelliJ, ça décoiffe.

Pomodoro Technique

2012-01-27T22:54:00.002+01:00

Je m'essaie depuis quelques semaines à la pomodoro technique.

Il s'agit d'une pratique de gestion du temps. Les principaux éléments proposés sont les suivants :

Ce qu'on a à faire doit être divisé en tomates (pomodoros). Une tomate ayant une durée de 30 minutes, c'est à dire 25 minutes de travail et 5 minutes de pause.

Une pause plus longue (entre 15 et 30 minutes) est accordée toutes les 4 tomates.

Lorsqu'on commence une tomate, on règle un minuteur sur 25 minutes. Tant que le minuteur tourne, on se force à éviter les interruptions externes (un collègue nous demande quelque-chose) comme internes (envie de traîner sur twitter). Lorsque le minuteur sonne, on arrête la tâche en cours et on prend 5 minutes pour faire quelque chose sans rapport avec la tâche : gérer les interruptions, marcher, traîner sur twitter,...).

Cette méthode nous permet de réserver un temps pour ce concentrer sur les tâches à réaliser. Limiter le temps permet d'éviter une certaine forme de fatigue, la perte de concentration et de productivité. Combien de fois, dans le cadre d'un développement informatique, vous êtes-vous plongé dans votre code, faisant des sessions de 3 heures ou plus ? Vous en sortez fatigué et vous avez l'impression que sur la fin, vous n'avez pas été aussi productif que vous l'auriez souhaité. Vous avez en quelque sorte piétiné. D'autre part, il peut vous arriver aussi que des personnes viennent vous poser des questions ou demander un coup de main lorsque vous travaillez sur une tâche, voire que vous ayez besoin de chercher une information sur Internet et que vous divaguiez de lien en lien dans une spirale de procrastination. Je suis souvent confronté à ces cas de figure. La pomodoro technique vise à éviter cela.

Dans un second temps, la méthode propose de se faire un plan de tomates (!) à réaliser par jour et de répertorier le nombre de tomates nécessaires pour accomplir vos tâches. Cette pratique vise plusieurs objectifs. Tout d'abord, vous pouvez tenter d'améliorer votre organisation afin de réaliser un maximum de tomates par jour. Si deux tomates font une heure, vous devriez théoriquement être capable de réaliser 12 tomates par jour, si on prend en compte des pauses de 30 minutes. Essayez et vous verrez que ce n'est pas si simple. D'autre part vous pouvez tenter d'améliorer votre productivité sur les tâches récurrentes, de battre votre score. Enfin, si vous enregistrez à peu près tout ce que vous faites, vous serez capable d'estimer avec précision le temps qu'il vous faut pour réaliser une tâche donnée même si vous avez plusieurs tâches à réaliser dans le même laps de temps. Je trouve cet aspect assez génial sur le papier.

L'étape ultime sera d'utiliser la technique en équipe, d'une part parce que vous n'aurez ainsi plus l'air d'être le seul cinglé à compter des tomates, d'autre part, parce que cela donne une certaine culture d'équipe et permet de découper les séances de travail collaboratif, comme des réunions ou du développement en binôme.

Pour finir, peut-être considérez-vous comme irréalisable l'idée d'avoir un minuteur qui fait tic tac et qui sonne en plein openspace. Sachez qu'il existe une kyrielle d'applications pour vous minuter. J'utilise personnellement Flow Keeper, qui permet d'écouter le click au casque (j'ai toujours un écouteur dans l'oreille, tant pis). Les réels challenges de cette technique est de bien penser à démarrer les tomates, de bien penser à faire les pauses et surtout de savoir gérer les interruptions tant interne qu'externe. Il faut y aller progressivement et se laisser le temps de bien faire.

Autre lien :
Site officiel de la Pomodoro Technique.

KISOD

2011-12-14T20:00:00.000+01:00

Vous connaissez tous le Keep It Stupid Simple, qui est l'arlésienne du développement informatique (!). Je propose d'aller plus loin avec le Keep It Simple Or Die.

Petite anecdote de ma vie professionnelle cette semaine. Un collègue prépare une livraison pour un script shell devant installer un correctif. Le correctif est composé d'un fichier sql. Le use-case n'est pas compliqué :

Créer un répertoire de backup dans le répertoire de travail du script

Sauvegarder le script actuellement déployé dans le répertoire

Copier le nouveau script dans le répertoire applicatif

Je passe sur le script de désinstallation qui fait la même chose mais à l'envers. Bref.

Qu'est-ce que je trouve :

Le répertoire de sauvegarde est créé par un mkdir $(pwd)/backup. De quoi ??? mkdir backup, ça ne suffit pas ???

Pour copier le fichier existant vers le backup et le fichier à déployer, on passe par un for FILE in *.sql; do ... De quoi ??? on ne copie qu'un fichier ! Il y a des limites à la généralisation !

En fait, on ne fait pas des cp, on fait des mv. De quoi ??? et si je veux rejouer l'install, je redetare ???

Même combat sur la désinstallation, sauf qu'au milieu des boucles et autres mv, un bug s'est glissé, un .sql qui devenait un .ksh ou autre bizarrerie. Honnêtement, mon esprit a oublié.

Par jeu ou arrogance peut-être, je me suis dit que ce serait certainement une bonne idée de réécrire ces scripts... avec un mkdir et 2 cp...

Apparemment, le collègue a fait ça vite fait avant de partir en congés avec le post-it "plus qu'à tester et à envoyer". Je pense que c'est un code qu'il a récupéré d'ailleurs et qu'il a dû bricoler. Il y a des jours ou on se dit que le pair programming devrait être une rêgle de base.

Je suis sur un projet legacy. Il y a des trucs comme ça a tous les coins de fichier.

Comme dirait mon chef : "C'est pas possible les gars, vous ne savez pas faire simple ?". Pas mieux. KISOD.

Épilogue
La correction était dans un fichier sql. L'ancien bout de code était en commentaire malgré notre utilisation intensive de, oh mon dieu, subversion. C'est du sql pour Oracle 10g, avec le undo management en automatique. On y trouve un use rollback segment XXX bien obsolète... Je suis un peu fatigué là.

Le code mort de vaincra pas.

autotest du pauvre

2011-11-28T11:31:00.004+01:00

On a tous nos petits soucis. Professionnellement, je développe beaucoup de shell (j'en vois qui rigolent au fond). J'aime bien développer de façon iterative, vous savez bien, ce truc là, avec des tests écrits avant le code de prod.
Là où le bât blesse est qu'il faut transférer le code sur le serveur de test. Souvent. Trop souvent. Comme j'en avais marre de basculer toutes les 30 secondes entre gvim, filezilla et putty, j'ai bricolé un autotest en python, du genre :


import os

def main():
    while True:
        test_ord_install()

def test_ord_install():
    tested_script = 'mon_scrip.ksh'
    launcher = "test_mon_script.ksh"   
    os.system('pscp data_test.dat prepdev1@server:testRto')
    os.system('pscp %s prepdev1@server:testRto' % launcher)
    os.system('pscp %s prepdev1@server:testRto' % "testLib.ksh")
    os.system('pscp ..\sh\%s prepdev1@server:testRto/sh' % tested_script)
    os.system('pscp ..\config\%s prepdev1@server:testRto' % 'ORDappli.env')
    os.system('plink prepdev1@server "cd testRto && chmod +x *.ksh && ./%s"' % launcher)

Vous ne le savez peut-être pas mais pscp et plink sont livrés avec putty. Il suffit de les avoir dans le path windows. Il s'agit d'équivalents à scp et ssh. J'utilise une clé RSA pour me connecter.

Après ça, il y a plus qu'à coder et regarder de temps en temps sur l'invite de commande si ça passe ou pas :).

Mauvaise expérience avec Rails

2011-11-05T20:58:00.004+01:00

Je viens d'essayer de faire un test avec Rails 3.1.1 installé pour Ruby 1.9.2 via rvm. Et bien c'est une bonne galère. Voici le scénario

Installation du gem rails pour l'environnement ruby 1.9.2 de rvm. C'est très long mais il n'y a pas d'erreur.

Premier essai d'un rails new truc pour créer une app. Boum, rails ne trouve pas sqlite3.

OK, il faut faire un aptitude install libsqlite3-dev, on relance la commande, ça prend encore 1 bonne minute et ça passe. Ouf. Et si je n'avais pas voulu utiliser sqlite3 ?

En suivant ce tutoriel, je vois qu'il faut créer la base avec une tâche rake db:create. Boum, rake veut un runtime JavaScript (heu, je voulais faire du ruby, là !). Quelque galère puis finalement J'installe rhino que je trouve dans aptitude et qui contente rake. La base de données peut se créer.

Ok, je peux lancer l'appli avec un rails server maintenant. Boum. Pas d'openssl. Ouais, c'est bon, je m'en fiche d'avoir des pages chiffrées, je veux juste tester rails moi ! Recherche sur le net, installation d'un libssl-dev, recompilation de l'extension openssl pour la version de ruby, webrick se lance. Superbe.

Je décide de paramétrer une première route, toujours en suivant le tutoriel. La page ne s'affiche pas, dû à une erreur javascript. Il semble que le runtime JS pour execJs ne soit pas totalement reconnu. Je mets therubyracer dans mon Gemfile et je fais un bundle install. Ça marche mais j'en ai assez, je vais faire une pause. Peut-être faire un peu de Django ?

Cette mésaventure m'attriste car je n'avais pas eu tous ces problèmes sur une version précédente de rails. Je ne comprends pas qu'on m'oblige a avoir sqlite3, openssl et surtout un runtime JS. Ce framework deviendrait-il trop complexe ? C'est d'autant plus énervant que j'aimerais faire des trucs avec ruby, que le langage me semble élégant et me parait entouré d'une certaine simplicité.

À titre de comparaison, j'ai également essayé sinatra cette semaine. Il s'agit d'un framework VRAIMENT léger, en fait principalement un descripteur de routes. Il possède évidemment moins de fonctionnalité que rails, mais permet de démarrer encore plus rapidement. Je me demande si on ne dirige pas vers un nouveau modèle de légèreté dans le domaine du développement web agile.

PS : je viens de refaire un essai en désinstallant rhino et en recréant un projet Rails intégrant therubyracer. Rake fonctionne. Je respire.

Github

2011-10-19T09:26:00.002+02:00

Rapidos, pour dire que j'ai ajouté mon profil github dans les liens →

Le blocage de la classe

2011-09-04T21:26:00.002+02:00

J'ai eu de la chance cette semaine, j'ai pu me réserver du temps pour coder au boulot. Et en Python en plus. Cela m'a permis de faire du TDD et de constater quelque chose : je bloque pour extraire des classes.

Extraire des méthodes ne me pose pas de problème. Un redondance apparaît ? Je fais une méthode pour encapsuler le traitement. Une méthode est longue et très concrète ? Je la divise en plusieurs méthodes.

Mais qu'en est-il de ma classe ?

Le boulot consiste en un petit module qui génère un Makefile à partir du contenu d'un répertoire pour faciliter la vie des développeurs. Ma classe en question génère une liste représentant les lignes du Makefile, c'est sa responsabilité. Au bout d'un moment, les différents cas de figure apparaissent, signe que la classe veut être étendue, j'imagine... Mais je n'ai pas envie de la faire ! Peut-être demain...

J'aimerais bien avoir l'avis d'un lecteur eXtreme Programmer : faites-vous un blocage à l'extraction de classe ?

LEAN

2011-08-13T23:00:00.004+02:00

Aujourd'hui, je suis d'humeur à m'attaquer à quelque chose qui m'a longtemps paru abstrait qui l'est d'ailleurs toujours un peu : le LEAN.

D'un premier abord dans notre métier de développeur d'applications (de gestion) le LEAN pourrait passer pour ce qu'on fait dans le cadre des méthodes agiles. On retrouve des similitudes dans les courants du LEAN IT et de l'agilité, mais je ne sais pas si les gars qui ont écrit le manifeste Agile pensaient qu'ils faisaient du LEAN...

Alors, le lean (je vais l'écrire en minuscules maintenant, ce sera moins fatiguant) est avant tout un paradigme de production industrielle qui a apparemment été lancée par le constructeur automobile japonais Toyota (on l'appelle d'ailleurs parfois Toyotisme). Plutôt qu'aller acheter un livre de Mary Poppendiek, j'ai bien envie de voir ce que nous dit la méthode industrielle proposer une interprétation pour étudier comment cela peut s'adapter au développement logiciel. Les deux domaines étant très éloignés on peut se demander comment une méthode appliquée à l'un serait pertinente pour l'autre.

Jarvis, on passe en mode materiel

Souvent, la philosophie lean est représentée par une maison avec des termes compliqués. Je n'ai pas envie de lancerIinskape, je vais vous en faire une version simplifiée en ascii art :

(Une image car j'ai eu un petit pb de formattage avec blogger...)

Pas mal. Passons aux explications.

Le toit
Je pense que c'est le plus simple à comprendre. L'objectif est de pouvoir soutenir la qualité, dans les meilleurs délais aux coûts les plus faibles. Un classique : on ne parle pas de mettre un temps infini pour sortir des produits chers de qualité merdique.

Les piliers
Pour arriver à nos objectifs, nous nous appuyons sur 2 principes :

JIT pour Just In Time, comprendre flux tendu. L'idée est que la production n'est pas pilotée par la capacité à produire mais par la demande du consommateur. Je pense qu'il s'agit de consommateur au sens large : le client mais aussi l'ouvrier qui à l'étape N de la chaine de production demande et attend que l'élément produit à l'étape N-1 soit disponible. C'est un point fort d'opposition avec le Taylorisme, l'idée que la production est rythmée par un tapis roulant dont l'action sur l'allure permet de réguler la production. Au push (pousser) est opposé le pull (tirer).

JIDOKA rien à voir avec la praticien de la planchette japonaise. Souvent on l'associe au fait d'arrêter la chaine dès qu'il y a un problème. Sur Wikipedia, j'ai lu que c'est la capacité des machine a auto-diagnostiquer un problème, arrêter la chaine et appeler l'opérateur pour corriger le problème.

Les fondations
On ne peut pas faire tenir les piliers sans de solides fondations.

TPM pour Total Productive Maintenance. Ce concept est lié à la discipline des ouvriers. On la connait aussi sous la forme de 5S:

Seiri : ranger et trier. Ce terme concerne surtout l'outillage, ce dont on a besoin pour faire le travail. Il faut ranger ses outils, garder à portée de main ceux qui nous servent le plus souvent et se débarrasser ce qui est inutile.

Seiton : ordonner. Lorsqu'on a débarrassé et trié ses outils, ils faut les ranger à une place précise, bien définie. Une place pour chaque chose et chaque chose à sa place.

Seiso : nettoyer. Seiri concerne l'outillage, seiso concerne les déchets de production (huile, sciure, etc.). Il faut que l'espace de travail soit impeccable.

Seiketsu : standardiser. Ces formes de nettoyage représentent des procédures standard, une habitude et non un événement exceptionnel. L'espace de travail doit être toujours être nettoyé lorsque les tâches sont terminées.

Shitsuke : maintien de la discipline. La constance dans l'application des 4S doit être contrôlée. Une sorte d'autodiscipline doit s'instaurer au sein des équipes.

KAIZEN pour amélioration continue. On veut définir le processus, le lancer, l'observer et le corriger s'il ne donne pas satisfaction (build, operate, check)

Okay, c'est quoi le rapport avec l'IT

Une chose est claire pour moi, le développement logiciel à peu à voir avec la construction de bagnole. Cela a d'ailleurs peu à voir avec la construction de bâtiment, même si on utilise encore le vocable du BTP (architecte, urbaniste,...). Pourtant, ce n'est pas de ma faute, le lean est a la mode dans notre metier. Comment peuvent s'appliquer les concepts du lean pour nous ?

JIT

Une application de JIT dans le domaine du développement est le Kanban, qui est également une pratique issue du lean. On organise les tâches en entrées, elles sont tirées par les acteurs dans différentes étapes d'un workflow ou chaine de valeur (en dev, en test, en livraison, etc.). La règle est que le nombre d'items par étape est limité pour les empêcher de stagner, le but étant de les sortir le plus vite possible. L'usage veut que les tâches et le workflow soient représentés sur un tableau. On retrouve ce système de management visuel dans les méthodes Agile. Ça marche bien. Ce qui est intéressant et que le Kanban peut permettre de voir les goulots d'étranglement dans notre chaine de valeur pour pouvoir l'améliorer, ce qui est déjà un aspect du Kaizen.

Jidoka

Ce qu'en entend par l'application du jidoka en IT est que tout le monde arrête ses actions en cours si une tâche est bloquée dans la chaine de valeur. On cherche à mettre un maximum de ressources pour régler les problèmes. Cela peut aussi s'appliquer à une situation de blocage en production, par extension.

Le concept d'auto-diagnostic est intéressant car on le retrouve dans la pratique d'intégration continue. Un système que se teste en continue et averti les développeur quand quelque chose ne marche plus est une application du Jidoka.

TPM / 5S

Les idées de la TPM peuvent s'appliquer au principe de développement. Le code est maintenu propre, la structure révèle les intentions, les fichiers sont stockés de façon corrélée avec l'architecture, les règles de développement sont respectées. Enfin, le principe de propriété du code cher à l'agilité rentre aussi dans ce principe. Il stipule que chaque développeur doit pouvoir intervenir sur n'importe quelle partie du code. Je pense que cela reflète bien cette idée.

Kaizen

Le kaizen va être représenté par les différentes boucles de feedback que l'on trouve là encore dans l'agilité. On pense d'abord à la rétrospective, qui permet de faire le bilan et tirer des actions à entreprendre entre deux sprints, mais c'est aussi le cas avec les tests d'acceptation, l'intégration continue, le TDD et la programmation en binôme.

Conclusion

Je crois que j'ai fait plutôt un article catalogue sans trop de parti pris. Le lean est quelque chose de pensé au départ pour de la production industrielle. Le lean IT est-il une nouvelle tentative de calquer le processus de développement logiciel sur un modèle connu, comme on l'a fait jusqu'à maintenant avec la métaphore du bâtiment ? Le fait est que les notions offertes par le lean trouvent leur écho dans les pratiques Agiles, qui sont je pense de plus en plus populaires parmi les équipes de développement.

Toutefois, le lean ne doit pas se limiter à une pratique particulière au sein de l'entreprise, adoptée par exemple uniquement dans un département faisant du développement, ou construisant des voitures. Il est censé être adopté à tous les niveaux d'une société, car l'efficacité d'un sous-sytème dépend de ses interactions avec le système global. Le vrai défi du lean est de voir la chaine de valeur dans sa globalité et de l'améliorer constamment. De ce point de vue, quoi de mieux que les pratiques Agiles pour les équipes de développement pour s'accorder avec à une politique lean en entreprise ?

Je pense que les idées seraient bonnes à compléter, je laisse l'espace libre aux commentaires.

Mon premier client

2011-08-13T22:04:00.003+02:00

Ce qui est bien quand on est développeur, c'est qu'on peut soi même créer un logiciel qui va nous simplifier la vie.

Pour ma part, comme je m'occupe encore de Grandir Autrement, je croulais un peu sous les factures à générer. J'ai donc fait un bout de code qui me permet de le faire à la chaine plus rapidement.

C'est très productif d'être son propre client. Pour pousser la réflexion, on pourrait se dire que chaque développeur devrait travailler un certain temps sur les application qu'il développe. Je suis sûr que ça ferait évoluer les mentalités !

Ce qui est bien pour partager ce genre de chose, c'est d'avoir des sites comme github !

Car ça y est, moi aussi je partage mon code !

Scrum bashing

2011-07-30T15:00:00.000+02:00

Dernier article sur le thème "pas d'agilité en forfait" de mon cahier. Je vais écrire ici à propos des pratiques agiles de conduite de projet applicables même dans un cadre non agile, comme un projet au forfait. Il s'agit cette fois de pratiques qui découlent (entre autres) de Scrum : le morcellement des tâches, le chiffrage par échelons, le management visuel et les réunions sur un temps limité.

Commençons par le morcellement des tâches. Lorsqu'une affaire est conclue, que les parties se sont mises d'accord sur un périmètre, le plan du projet est constitué de morceau trop gros au chiffrage incertain. Cela peut être un bon exercice de reprendre les différents items avec l'équipe afin de les morceler en tâches d'un ou deux jours. J'y vois plusieurs intérêts. Tout d'abord, cela déclenche une discussion technique. On élabore rapidement une solution technique au problème posé. La décomposition en tâches vient alors naturellement. Cela mène également à une réévaluation du chiffrage global de la partie. S'il est moins élevé, on se réjouit. S'il est plus élevé, on peut faire le paris que les autres éléments seront sur-chiffrés ou alors revoir la conception technique et refaire une distribution en tâches. C'est quelques chose que j'ai fait en contexte Scrum pour chiffrer des stories complexes[1] avec l'équipe.

Toujours concernant le chiffrage, j'ai adopté le façon systématique le chiffrage par échelon, classiquement avec les termes de la suite de Fibonacci (1, 2, 3, 5,...). Le chiffrage reflète l'incertitude. Pourquoi choisir 4 au lieu de 3 ou 5 ? Est-ce qu'on a une connaissance suffisante du problème pour faire une estimation supérieure à 5 ? Le chiffrage par échelons permet de comparer les différents items chiffrés : cet item est plus complexe que celui-ci que j'ai chiffré à trois, je le chiffre donc à 5. La pratique de chiffrage est quelque chose d'abstrait après tout. Elle permet juste d'avoir un budget.

Sans transition, parlons du management visuel. Beaucoup de fanatiques d'Excel doivent trouver cette pratique ridiculement réactionnaire. Cependant, avec un tableau et des post-it, vous aurez un contrôle étonnant sur vos projets ! Utiliser les principes du Kanban avec un nombre limité de tâches par étape est également une bonne idée pour améliorer la productivité. Le tableau doit pouvoir être vu et être accessible à chaque membre de l'équipe pour le faire évoluer en temps réel.

Terminons par les réunions quotidiennes. Elles sont une bonne idée s'il y a un nombre limité de membres dans l'équipe (5 ou 6 personnes ?). Dans le cas contraire, cela demande beaucoup d'effort pour bouger tout le monde et ces réunions deviennent ennuyeuses. Je vous déconseille d'adopter cette pratique si vous n'avez pas de tableau de tâches sur lequel vous appuyer, le but étant que chaque membre puisse avoir un aperçu global de l'avancement du projet. Vous pouvez sinon vous limiter à une réunion hebdomadaire d'une heure maximum dans laquelle vous pouvez fixer les objectifs de la semaine suivante et faire le bilan de la semaine passée.

Ceci est le dernier article de ma mini série. Comme vous pouvez le voir, mon point de vue est de minimiser l'usage des pratiques Scrum quand la situation ne s'y prête pas. Tout n'est pas à jeter mais Scrum perd grandement de sont intérêt dans une démarche non agile. Ne cherchez pas à utiliser des buzzwords, de faire des standups et des burndown charts à tout bout de champ. Ne communiquez pas de product backlog si vous êtes contractuellement engagés à livrer des spécifications. Concentrez-vous plutôt sur les pratiques d'ingénierie qui restent applicables à toutes les situations.

[1] vous l'aurez compris, complexe ici signifie d'une charge supérieure à deux jours.

ctags

2011-07-26T23:43:00.004+02:00

ctags a participé à sauver ma journée.

C'est un outil qui génère un fichier tag contenant les endroits où sont définis les éléments (fonctions, classes) dans les fichiers source. Ce fichier tag est ensuite utilisable par des éditeurs de texte comme vim. Je pensais qu'il ne marchait que pour le C et le C++, mais en fait il prend en compte beaucoup de langages :


romain@lilibox:~$ ctags --list-languages
Ant
Asm
Asp
Awk
Basic
BETA
C
C++
C#
Cobol
DosBatch
Eiffel
Erlang
Flex
Fortran
HTML
Java
JavaScript
Lisp
Lua
Make
MatLab
OCaml
Pascal
Perl
PHP
Python
REXX
Ruby
Scheme
Sh
SLang
SML
SQL
Tcl
Tex
Vera
Verilog
VHDL
Vim
YACC

Vous construisez le fichier avec


ctags -R

Dans le code source avec vim, faites Ctrl+] pour aller à la définition d'une fonction[1] et Ctrl+t pour revenir à l'endroit précédent.

L'inconvénient est qu'il faut générer les tags dès qu'on retouche aux fichiers où sont définies les fonctions appelées, mais pour débugger du shell ou du C tordu, ça aide bien !

[1] et oui, cela marche mieux avec la disposition américaine des touches !

OMFG

2011-07-25T20:06:00.003+02:00

On peut dire que j'ai appris quelque chose aujourd'hui dans le fastidieux travail de remise d'aplomb de la plateforme de qualification du client.

Le problème

Un transfert de fichier ne se faisant pas entre 2 serveurs

L'errance

Transfert de fichier ? Facile, c'est du scp (non). Du rcp (non) ? Un montage nfs (NON) ? Ben quoi alors ?

La solution

Le transfert est réalisé par dd, initié sur la plateforme de départ, pipé dans un remsh pour terminer sur la plateforme d'arrivée. Et bien, je ne savais pas que c'était possible.


dd if=$input bs=$block | remsh arrivee dd of=$output bs=$block

Détail amusant, la commande n'est pas lancée directement mais au travers d'un autre remsh en local, afin de rebondir sur un utilisateur qui avait l'équivalence sur la plateforme d'arrivée et les droits sur le répertoire de destination.

Un ajustement des .rhosts de tout le monde et ça doit être résolu. Pas de remarque sur la problématique de sécurité apportée par la commande remsh et le système des rhosts.

C'est dans notre code...

Avoir du fun avec cat

2011-07-24T14:31:00.003+02:00

J'ai appris un truc récemment sur cat. Il ne sert pas seulement à concaténer et lire des fichiers. On peut aussi écrire des lignes de façon interactive, ce qui est très pratique pour ajouter des lignes dans un fichier de configuration par exemple.


# Ecriture
romain@lilibox:~$ cat > test.log
some 
text

# Lecture
romain@lilibox:~$ cat test.log
some
text

Les bonnes pratiques n'ont pas de cadre

2011-07-23T16:36:00.002+02:00

Dans mon article précédent, j'ai essayé de convaincre qu'il fallait arrêter d'essayer d'adopter une conduite agile de projet dans un contexte de forfait. Cela vous attriste : vous déprimez à l'idée de travailler à l'ancienne. Vous voulez quand même de l'agilité dans votre vie de développeur. Bien.

Scrum met peu l'accent sur les pratiques de développement pourtant décrites par extreme programming. Il y en a peu mais toutes sont intéressantes.

Tout d'abord, le développement dirigé par les tests (TDD). C'est un point difficile. Si on suit les principe d'XP, aucune ligne de code ne doit passer en production si elle n'a pas d'abord fait l'objet d'un test unitaire en échec. On est dans la discipline pure. Pourtant, cette pratique permet d'avoir un contrôle quasi total du code en frôlant 100% de couverture par les tests. L'intérêt est d'autant plus grand lorsque cette pratique est couplée à de l'intégration continue (voir plus bas). Le paradigme qu'elle met en place est que la première nécessité d'un module développé est de pouvoir être testé rapidement de façon automatisée. Ce point surclasse le principe d'encapsulation cher à la programmation orientée objet. De prime abord, on peut penser qu'une telle pratique engage un surcout, surtout si on n'est pas habitué à automatiser les tests. D'habitude, on commence par rédiger le code de production et on s'assure manuellement de son bon fonctionnement. De plus, les tests représentent du code supplémentaire à maintenir ce qui n'est pas compris dans le budget... D'autorité, je dis que les avantages dépassent le surcout. Les tests sont maintenus car lancés et mis à jour avant chaque retouche de code. Le surcout en temps doit être pris en compte dans les chiffrages.
La vraie difficulté est de dépasser le barrage culturel et de former l'équipe à cette pratique.

Une deuxième pratique intéressante est l'intégration continue. L'IC consiste à faire tourner la construction du projet régulièrement, en la déclenchant par exemple sur la validation de fichiers dans le système de gestion de code source. Le point fort de cette pratique est qu'elle est peu couteuse à mettre en place, même longtemps après le début de développement, comme dans le cadre d'une tierce maintenance applicative. Les intérêts sont multiples.
Tout d'abord, vous pouvez contrôler que les sources compilent toujours après une validation. C'est un peu le niveau zéro de l'intégration[1].
Ensuite, le système permet d'installer une plateforme de test automatiquement, même vierge. Vous contrôlez ainsi qu'il n'y a pas de problème d'installation et vous disposez d'une plateforme "propre" pour faire des tests manuels.
Enfin, lorsque vous avez une bonne couverture de tests unitaires, vous pouvez les lancer à chaque mise à jour du dépôt de code source. Avec la pratique du TDD, vous mettez ainsi en place une non régression permanente pour un coût nul.
Les systèmes populaires d'intégration continue aujourd'hui sont Jenkins et Hudson (c'est le même système) mais si vous ne voulez pas (ou ne pouvez pas) utiliser Java sur votre plateforme, vous pouvez très bien développer un système simple avec des scripts et cron.

Dernière pratique d'ingénierie, le développement en binôme (pair programming). Pour moi, elle est la plus difficile à mettre en place mais ses bénéfices sont intéressants.
Le plus évident est le transfert de connaissance, l'apprentissage. C'est efficace pour montrer une technique comme le TDD, l'intérêt d'une règle de développement, des raccourcis clavier ou autre fonctionnalité de l'IDE pour aider le binôme à augmenter sa productivité. Cet aspect n'est malheureusement intéressant que pour le moins expérimenté[2].
Un autre aspect est la relecture de code, l'un pouvant voir des problèmes dans le code que l'autre ne saisit pas au premier abord ; même si la personne au clavier est la plus expérimenté, elle bénéficiera d'un autre point de vue sur son code. La discussion sera également bénéfique pour les deux parties.
Enfin, en mélangeant les binômes sur différents aspect du produit, on améliore la connaissance globale du code par l'équipe.
Il y a effectivement de bonnes choses mais il est compliqué de mettre cette pratique en place de façon systématique : elle a un côté "socialisation forcée" qui peut ne pas convenir à tout le monde. Elle est en outre difficile à argumenter avec la hiérarchie qu'on veut mettre deux personnes au lieu d'une sur une tâche. Ne prétendez pas que la tâche sera terminée deux fois plus vite : c'est faux même s'il y a un gain de productivité. C'est en terme de qualité de code et de capacité d'apprentissage de l'équipe que cela se joue.

Pour conclure ce deuxième article, disons que ces bonnes pratiques d'ingénierie ont été promue aux travers des valeurs de l'agilité. Elles sont adaptables à n'importe quel type de projet car elles mènent à une meilleure qualité du produit livré[3], avec moins de bogues mais aussi une architecture plus flexible, que l'on peut remodeler sans crainte grâce au tests. Elles visent à donner une meilleur maîtrise du processus de livraison. Soyez honnêtes, intégrez le surcout de ces pratiques dans vos chiffrages. Ne badinez pas avec la qualité du produit, votre réputation et celle de votre entreprise est en jeu.

Cet article aborde des techniques connues avec un point de vue candide mais quand je vois les gens travailler autour de moi, je pense que ça valait le cout de l'écrire.

Pour la suite, j'aborderais les pratiques de conduite de projet issues de l'agilité bénéfique même dans un cadre forfaitaire.

[1] si le code en gestion de source ne compile même pas, il va falloir en discuter avec l'équipe
[2] je me demande toutefois si la personne qui a posture de mentor dans cette situation ne va pas vouloir "briller" devant le n00b et faire une performance :).
[3] un contrat de TMA est plus rentable quand le produit n'a pas de bogue.

Scala est performant

2011-07-19T23:36:00.001+02:00

Comme en témoigne cet essai de compilation à froid du classique Hello World :


romain@lilibox:~/development/scala$ time scalac HelloWorld.scala

real    0m9.971s
user    0m9.541s
sys     0m0.288s

J'ai peur.

Pourquoi s'embéter avec l'agilité...

2011-07-17T13:15:00.003+02:00

...en SSII. C'est la question que je me pose. Les pratiques de conduite de projet agiles, dont l'implémentation la plus populaire en France est a priori Scrum[1], restent encore globalement méconnues (il faut dire que le manifeste a seulement 10 ans. Il faut du temps pour traverser l'Atlantique). Elles sont assez souvent jugées comme peu sérieuses (mon expérience). C'est encore délicat aujourd'hui pour les évangelistes, je pense, d'en faire susciter l'adoption dans l'enthousiasme général. Alors, pourquoi ne pas arrêter ?

Rassurez-vous, je ne vais pas vous suriner avec tout le bien que je pense des projets en cascade, en V, en Y... Les spécifications mal écrites, mal lues, pleines d'erreurs... Les cahiers de tests manuels mal écrits, jamais rejoués, périmés... Les règles de développement jamais discutées en équipe, prônant l'usage de cette saleté notation hongroise (je crois que je m'égare...).

Reprenons. Scrum, c'est quoi ?

C'est un ensemble de pratiques et de rôles qui va permettre à l'équipe de développement de se rapprocher d'un collège d'utilisateurs afin de développer une application informatique censée les aider dans leur travail, les rendre plus efficaces, heureux et riches.
Ils sentent ce qu'ils veulent mais ne savent pas -au sens de compétence mais aussi de disponibilité, de temps à consacrer- le formaliser de façon exhaustive dans des spécifications.
Ainsi l'équipe de développement fait de son mieux pour interpréter ces besoins et les traduire en application afin de les montrer rapidement aux utilisateurs. À la vue du travail effectué, leur besoin se précise et l'application évolue. On s'aperçoit que finalement, une fonctionnalité A est suffisamment remplie par une fonctionnalité B qui devient donc très peu prioritaire, que ce serait bien d'avoir telle et telle information dans un nouvel écran. Oh et Jean-Jean, tu nous ferais pas un tableau de bord là en page d'accueil ? Ce serait tellement pratique pour les gars...

Dans ce cas de figure, ça mène à un niveau de synergie étonnant. On arrive à faire de grandes choses à couts maîtriser et avec une vraie satisfaction du client en la personne de l'utilisateur final. Je l'ai vécu. En SSII. Et c'est une exception.

La règle habituelle des projets au forfait est très différente.
En premier lieu, l'équipe n'est jamais au contact des utilisateurs. Les utilisateurs formulent un besoin à une maîtrise d'ouvrage (MOA) qui la transmet accompagnée d'un budget à une maîtrise d’œuvre (MOE) qui va la traduire en cahier des charges et parfois même en spécifications (chance pour vous). La MOE fait appel à la SSII pour sous traiter le vil travail de développement (elle n'est pas obligée, mais là ça m'aide pour écrire un article sur les SSII).

La MOE n'a pas besoin du projet. Elle n'a pas un besoin viscéral du projet. Faire le plus beau logiciel du monde ne va pas rendre son travail plus efficace, plus facile. Il ne va pas rendre ces personnes plus heureuses chaque matin d'aller utiliser une application faite uniquement pour eux, pour leur besoin spécifique.

Alors pourquoi vouloir faire du Scrum ? Où est l'agilité dans ce processus ?
Un processus dans lequel le besoin des utilisateurs est livré entre 6 mois et 1 an après leur demande. Un processus au cours duquel de multiples équipes se sont interposées entre l'utilisateur et son besoin et le producteur capable de le satisfaire, avec ce que cela représente de coûts mais aussi de déformation du besoin exprimé ? Où est l'agilité lorsque le logiciel n'est pas en accord avec l'interprétation des spécifications et que les acteurs repartent dans un cycle demande-chiffrage-planning-réalisation ? Je cherche encore...

J'ai vu une fois un projet soi-disant Scrum avec une structure décrite ci-dessus et au forfait. Cela est revenu à développer un une liste d'exigences mouvante sans réviser l'engagement sur le périmètre à livrer. Un beau massacre.

On peut éventuellement se dire qu'on peut faire un contrat forfait pour rassurer la partie cliente et obtenir le budget et ensuite ne pas honorer l'engagement sur les fonctionnalités. En d'autre terme, on signe un contrat forfait pour au final de la régie. Cela peut marcher... si on aime faire de l'escalade sans corde (avec de la graisse sur les mains). C'est à refuser absolument.

Restons simples. Rendez-vous service. Rendez service à votre hiérarchie et à votre client. Si vous avez une MOE qui veut du forfait, donnez lui du forfait. Si elle veut faire du Scrum et du forfait, dirigez votre interlocuteur vers ce billet : il est possible qu'il n'ait pas réellement saisi l'intérêt.

Vous voulez cependant travailler de façon moderne malgré ce carcan austère ? Ajoutez mon journal dans votre agrégateur RSS et laissez moi formaliser la suite (on peut aussi faire du blabla incrémental :)).

Ouais, c'est un to be continued, baby.

[1] n'insistez pas, je n'ai pas de source. Vous connaissez Crystal et DSDM vous ?

A la mode ?

2011-06-22T14:39:00.001+02:00

Il y a quelques temps j'ai commencé à faire un Langage Dédié pour faire des tests de validation sur des processus Dollar Universe (c'est un outil d'ordonnancement).

Dans un shell (ksh), les étapes de test se présente ainsi :


test_session 47ZMPUGRFM contient "47ZMPRFM_D 47ZMPRFMIN 47ZMPRFMAL 47ZMPRFMSA 47ZMPRFMCO 47ZMPRFM_F"
test_uproc 47ZMPRFM_D necessite_ressources 47Z_PUGRF_EC
test_uproc 47ZMPRFMIN contient ARCinitPurgeReferentielFixe.ksh
test_uproc 47ZMPRFMAL contient ARClanceAlimTableAuxiliaireFixe.ksh

Ce qui est sympa c'est que le contenu des tests devient facile à parser. Il est alors envisageable de générer du texte automatiquement pour remplir un cahier de test grace à un script idoine (en Python, évidemment !)

Avancement projet...

2011-05-26T22:33:00.003+02:00

J'ai parlé il y a quelque temps d'un projet d'appli CRUD que j'avais commencé pour gérer les abonnés du magazine Grandir Autrement. L'application est utilisée en production ! Elle a même géré avec succès l'envoi du dernier numéro. Il manque encore des fonctionnalités, je les ajoute au gré de ma motivation. C'est un cycle de développement qui me convient bien !

Je ne sais pas trop comment donner suite à ce système pour l'instant. J'aimerai bien diffuser la version desktop, mais il va falloir que je fasse de la doc. J'ai également l'idée d'en faire une webapp, peut-être en l'hébergeant dans GAE... Et peut-être que je pourrais en faire une appli cloud pour d'autres magazines ~~sans le sous~~ associatifs. J'essaie de vous tenir au jus !

Langages dynamiques

2011-04-17T11:58:00.001+02:00

Je prends quelques minutes pour écrire un truc sur les langages dynamiques.

J'ai dernièrement fait un peu de Python pour développer mon logiciel de gestion d'abonné. J'aime beaucoup ce langage finalement, même si certains éléments de syntaxes sont bordelliques.

En trainant sur le Net, je m'aperçois que Python est assez peu représenté au profit de... Ruby ! La mode pour le développement Agile c'est Ruby on Rails, les craftsmen font beaucoup de promo sur Ruby... Pourtant pourquoi Ruby serait plus Agile que Python ? Tous deux sont des langages dynamiques, multi-paradigme (orientés objet, mais pas que), basés sur un interpréteur C permettant de dialoguer avec du code compilé natif. Tous les deux permettent de faire du Web : RoR pour Ruby mais Django pour Python. Tous les deux disposent de gestionnaires d'extensions : gem pour Ruby, pip ou easy install pour Python... Bref, ils sont proches.

Personnellement, je trouve que Ruby instruit des points qui me gênent avec Python (so far... je ne connais pas encore suffisemment Ruby) :

L'encapsulation
C'est vrai que Python à tendance à détendre le développeur sur le principe d'encapsulation. Cependant j'aime bien faire BEAUCOUP de méthodes que je voudrais privées (export till you drop comme dirait Uncle Bob). Certes, on peut fonctionner par conventions mais qu'un dir(MaClasse) me renvoie dix lignes d'attributs, ça me dérange... Si on veut exposer des méthodes publiques, faut-il systématiquement des façades ? Quant à la convention des préfixes _ et __ pour les membres protégés ou privés, je trouve ça juste attroce. Au moins, avec Ruby, on peut a priori faire de VRAIS membres privés...

Self
Le truc que je déteste en Python : l'accès aux membres avec l'utilisation systématique de self. C'est juste CHIANT. Je veux qu'on considère qu'une classe utilise ses membres A PRIORI. Encore pire : mettre self en tant que premier paramètre des méthodes. Ca sent un peu trop la démarche "Je veux faire de l'objet avec du C" en passant un pointeur de structure comme premier paramètre de fonction. Berk.

Mais il s'agit de détails. Je suis sûr que Ruby possède également ses casseroles syntaxiques (déjà le #{foobar} pour l'interprétation des variables en string c'est un peu chiant).

Le vrai plus de Ruby je pense, c'est le côté bling bling, je m'explique :

Le nom
OK cet argument est nul, mais il appuie bien le côté bling bling de Ruby.

La promo sur les sites Webs
Dans les réponses de Tarek sur LinuxFr, il décrit qu'une grosse faiblesse de Python réside dans son site officiel www.python.org très peu sexy. Quand on voit le site officiel de Ruby www.ruby-lang.org, traduit en plusieurs langues, coloré,... Avec un gros plus : le lien Apprenez Ruby en vingt minutes ! De même, le site de Ruby On Rails, rubyonrails.org est plutôt direct, genre "chope le, code et mets en prod ce soir". Ruby est cool et sexy, Python est austère et destiné aux matheux.

Communauté
Le développeur Ruby a l'air riche. Il fait des screencasts dans lesquels il développe sont site sous Rails en 30 minutes avec son macbook pro en utilisant TextMate. Il fait quoi le développeur Python ? Il utilise gVim sous Debian tournant sur un vieil Athlon des familles ? Snif.

Alors voilà, je vais me mettre à Ruby parce qu'il a une image sexy et parce que je pense que ça gonflera mon CV. Mais je ne vais pas laisser Python parce que je trouve ce langage super cool !

PS : je n'ai pas parlé de Perl. Qui parle encore de Perl en 2011 (^-^) ?

MixIT

2011-04-10T23:08:00.002+02:00

J'ai assisté cette semaine à la conférence Mix-IT coorganisée par le LyonJUG et le Club Agile Rhône Alpes, tout naturellement autour des dernières technologies Java et de l'Agilité.

Arrivée dans les locaux de l'Epitech Lyon vers 8:15 ; les étudiants me dirigent vers l'amphi où se tiendra la keynote. Blabla ds organisateurs, applaudissements... On retiendra qu'il faut faire attention en traversant la route pour aler au batiment où se tiendront les différentes sessions. Suit une présentation d'Objet Direct, le principal sponsor de l'événement... Je n'ai pas pris de CV... Mainenant, présentation de Nicolas Martignolle, connu pour être le blogger derrière Le Touilleur Express. Il parle de la beauté du métier de développeur. J'ai envie de pleurer mais je ne sais pas si c'est l'émotion ou le manque de sommeil.

On passe au petit déjeuner (CAFÉ) et à la récupération du badge. Puis attente. C'est le moment où j'arrète la narration temps réel pour quelque-chose de plus direct. Voici un résumé des sessions auxquelles j'ai assisté.

Comment j'ai mis ma suite de test au régime en 5 minutes par jour

Tout le monde doit en être convaincu : écrire des tests joués lors du build, c'est bien. Cependant, la durée du build augemente fatalement avec le nombre de fonctionnalités et de tests associés jusqu'au point où il devient impossible de le jouer quotidiennement. Plutôt que de désactiver l'exécution des tests, le speaker donne plusieurs pistes :

Utiliser Maven 3 et ses capacités de multi-threading

Supprimer les testes inutiles, redondants et le code mort

Limiter les tests IHM et end to end pour privilégier les test unitaires rapides

Mocker et utiliser des ressources en mémoire si possible.

On est dans le bon sens mais la piqure de rappel est importante.. On sent que le speaker maîtrise son sujet.

Grails

Grails est la contraction de Groovy et Rails. Il s'agit d'un framework permettant le déploiement rapide d'applications web. Le principe est d'avoir un squelette d'application normalisé et un serveur tomcat démarré pour les tests en une seule commande. Ça a vraiement l'air efficace, ce qui donne envie de l'essayer.

Point positif : la compatibilité avec l'écosystème Java.

Point négatif : les performances qui tombent même en dessous d'un combo Ruby on Rails + JRuby. Les évangélistes diront que c'est suffisamment rapide. Des sites web à gros trafic utilisent tout de même Grails.

Clojure

Clojure c'est du lourd : il s'agit d'un langage fonctionnel pour la JVM. J'essaie de m'y mettre avec un peu de peine. À chaque fois que je suis un tutoriel, j'ai du mal avec les particularités sémantiques et je suis vite largué. Le speaker est développeur du plugin Eclipse Clojure. Il connait très bien le sujet. À l'issue de la session, je suis à nouveau largué et je ne pense pas être le seul. Les gens se demandent ce qu'on peu faire avec. Réponse : le langage est généraliste. Ah bon... Personnellement, je trouve la syntaxe très élégante et je compte bien persévérer pour apréhender le paradigme de la programmation fonctionnelle.

NoSQL

Qu'on se le dise, NoSQL signifie Not Only SQL. Le speaker se focalise sur Hadoop, qu'il présente comme une base orientée colonnes et Cassandra, qu'il présente comme une base clé-valeur (!). Je trouve que le speaker ne sait pas trop sur quel pied danser entre présentation technique ou plus globale. On retiendra que pour fonctionner efficacement de façon distribuée, ces bases font une entorse au principe ACID. Je resterai avec mes interrogations, notemment sur les performances de Hadoop en lecture...

DevOps

J'ai entendu ça et là des choses sur le mouvement DevOps. En se moment, nous faisons beaucoup de soutien à la production au travail et ce serqit bien d'améliorer l'exploitation du projet. Je pense que l'idée forte développée au cours de cette session est qu'il faut considérer les exploitants comme des utilisateurs à part entière de l'application. Dans la mouvance Lean, une fonctionnalité ne devrait être considérée comme terminée que lorsqu'elle est déployée en production. Pour le soutien, les développeurs et les exploitants devraient avoir les mêmes outils et accès aux mêmes informations. Pour cela, il faudrait déjà simplement que les acteurs des deux mondes commencent à se parler. Le speaker est intéressant. Il semble très impliqué dans le mouvement DevOps. Il lance évidemment quelques trolls contre les développeurs, ce qui donne lieu à quelques débats très animés (alors JMX, c'est le bien ou non ?).

C'était une gentille journée que ce Mix-IT ! Merci aux organisateurs. Je n'ai pas nommé les speakers mais je vous invite à aller voir sur le site du Mix-IT pour de plus amples informations.

ETL, piège à cons ?

2011-03-27T23:45:00.002+02:00

Je travaille actuellement avec la Rolls des ETL : Ab Initio. ETL est un acronyme pour Extract Transform Load. Ces outils permettent d'extraire des données de sources diverses (bases de données, fichiers plats ou binaires,...) de transformer et / ou d'agréger ces données et de les injecter dans une autre source de données.
D'un point de vue pratique ces outils prennent la forme d'un environnement de développement intégré dans lequel un développeur assemble des boites réalisant les différentes opérations :

Extraction

Transformation des champs

Dédoublonnage

Agrégation

À partir des graphes tracés, l'outil génère des exécutables pouvant être intégrés dans le système. Pour le besoin, c'est plutôt efficace.

Qu'est-ce qui me dérange ? J'ai du mal à les voir comme des outils pour développeurs. Mes problèmes avec le concept d'ETL sont les suivants :

Couplage : le code est exécuté sur le serveur (dans le cas d'Ab Initio). Il y a un connecteur par vendeur de base de données, il y a peu de possibilité d'abstraction.

Il est très aisé de générer des graphe complexe difficiles à maintenir

C'est chiant à tester (tu mets un fichier en entrée, tu croise les doigts pour avoir une bonne sortie 1 minutes après)

Je reconnais que les avantages sont indéniables. Ce n'est cependant pas un outil pour mois : je me sens tout nu sans mon XUnit !

Ah, Windows...

2011-03-02T07:10:00.001+01:00

Pour rappel, je suis toujours en train de développer mon premier projet perso en python. Ça avance plutôt bien car j'ai releasé la première version ! Quelle bonne surprise, j'ai plein de problèmes de cractères accentué sous Windows... Il faut que je me fasse un tracker.
J'aimerais le distribuer mais je me heurte a quelques soucis :

Le modèle de données est très spécifique

Ce n'est pas internationalisé

Ça ne respecte pas les standards de distribution Python

et en plus le code de l'IHM est dégueulasse (ben oui, je découvrais !). J'ai donc encore pas mal de travail.

Merci pour l'héritage

2011-02-22T23:02:00.002+01:00

Je viens de terminer le livre de Michael Feathers "Working Effectively With Legacy Code". Ce livre donne des pistes pour travailler sur du code dépourvu de tests unitaires, l'objectif étant de développer suffisamment de tests unitaires pour pouvoir faire évoluer le code.
Cette problématique n'est pas triviale. En effet, l'intéret d'une pratique comme le TDD est que le code est construit pour être testé ce qui permet de faire évoluer en toute sécurité le design du système.

Que trouve-t-on quand on doit faire évoluer l'héritage (legacy) de plusieurs années développement en SSII :

de grosses classes / fichiers ;

de grosses fonctions ;

un couplage fort entre les composants, comme du code métier appelant directement une base de données (merci le Pro*C !).

Les techniques proposées dans le livre visent à réduire le couplage pour permettre d'écrire une couverture suffisantede TU.

Le point fort d'après moi est d'adopter un point de vue très pragmatique : bien souvent, on intervient sur du vieux code pour faire une corerction ou une simple évolution. Le budget est rarement propice à une refonte globale du design du système. M. Feathers ne propose pas de changer du code critiquable en code parfait mais bien de se donner les moyen d'intervenir efficacement de manière sécurisée. Ainsi, plusieurs solutions proposées présentent des entorses au principe d'encapsulation*.

Pour moi, ce livre est un must read pour tout développeur professionnel tant les situations décrites font partie de notre auotidien. On le vaincra, ce mauvais code !

* Je conseillerais aux puristes de l'encapsulation d'essayer Python, ça les détendra (ou le contraire).

Le bug du ls

2011-02-12T23:52:00.001+01:00

Difficile vendredi avec un dépannage imprévu en production.

Une erreur sur un ls : arg list too long... Comment ?

Il semblerait qu'il y ait une légère limitation à ls notre HP-UX. Prenez un répertoire dont le chemin est stocké dans une variable $REPERTOIRE et mettez-y 28000 fichiers représentant 1 To de données...


ls -l $REPERTOIRE/*.txt

ne marche pas


cd $REPERTOIRE
ls -l *.txt
cd -

Marche...

A qui j'envoie la notification de bug ?

Le software craftsmanship c'est quoi

2011-02-04T19:05:00.003+01:00

Je suis fatigué alors je vais faire un article bookmark.

Robert Martin a récemment fait une déclaration à ce sujet pour mettre tout le monde d'accord.

C'est là

Ça vend du rêve, non ?

Plus sur le site "Le Touilleur Express"

Bref, ça commence à prendre :). À quand un gros rassemblement de craftsmen en France ?

PS : sur le Yammer de ma boite (SSII internationale), le manifesto semble avoir fait beaucoup rire parmis les agilistes... S'ils savaient ce que je pense de Scrum...

Projet personnel

2011-01-25T11:07:00.001+01:00

Ca fait un moment que je n'avais pas écrit. Je suis très occupé. Si, je le jure.

En ce moment, je développe une petite applicaiton CRUD pour le magazine Grandir Autrement. Il s'agit d'une application pour gérer la liste des abonnés du magazine, effectuer un export vers un service de routage, créer, supprimer et modifier des abonnés. Ca avance petit à petit, j'en suis assez content. Voici les choix que j'ai fait :

*Application de bureau, à l'ancienne, car il n'y avait pas besoin de le rendre accessible simultanément à plusieurs personnes.
*Python
*Sqlite pour la base de données
*wxWidget pour l'interface graphique.

Pour l'instant, je ne regrette aucun de ces choix. Au boulot, j'ai l'impression que faire du logiciel est un gros truc complexe, même si on travaille de temps en temps de façon Agile. Là, tout se fait simplement. Python y est pour beaucoup, c'est très relaxant pour un habitué de Java...

Essayez de faire une liste en Java. Vous devez choisir le bon type concret, spécifier le type des éléments, instancer... En Python, créez une liste vide et ajoutez des élements. Cela prend au-moins 2 fois moins de lignes.

Sqlite : une base de données qui ne prend pas là tête. On se connecte, on crée le modèle et c'est parti. La base de données est stockée dans un fichier local. Sqlite 3 est intégré à Python, génial, non ?

Enfin, wxWidget est une libraririe multi-plateforme d'interfaces graphiques écrite en C++. wxPython est le binding Python. Je suis un novice en UI. Mon a priori est que c'est plutôt lourd à réaliser. En vérité... c'est effectivement le cas. Toutefois, wxWidget est assez simple d'utilisation et après un minimum de galère on arrive à placer des widget à peu près correctement. J'ai encore pas mal de boulot mais je devrais sortir quelque chose pour la deadline à la fin du mois.

A peu près tout le dev est dirigé par les tests... c'est un peu fatiguant mais ça permet de moins vaire de validation à la main :).

Une base de données tentaculaire

2010-11-26T12:00:00.001+01:00

J'ai été convié cette semaine à un forum sur les nouvelles technologies Oracle concernant le Data Warehousing et la Business Intelligence. Encore une fois nous avons eu le droit à une présentation du dernier produit Oracle dans le domaine de la base de données relationnelle : Exadata.

Il s'agit d'une offre software et hardware pour afficher un maximum de performance et de disponibilité.

Un rack est constitué de serveurs d'instance et de cellules de stockage reliés par un lien à 40 Gb/s (InfiniBand). Les serveurs sont organisés en clusters (RAC) et le stockage est réalisé par ASM.

Outre le débit proposé entre l'instance et les données qui est déjà hallucinant, la véritable valeur ajoutée se situe au niveau des cellules de stockage qui sont de vrais petit serveurs à elles seules. Voilà ce qui est proposé :

Le Smart Scan : les données demandées par la requête sont filtrées au niveau du stockage pour ramener un minimum de déchets à l'instance. Des calculs plus avancés (décisionnels) peuvent également être pris en charge niveau stockage.
La compression par colonne : ils annoncent des taux de compression de 10 à 40 (ce n'est pas des pourcentages).
Une pseudo indexation automatique qui fait que les données sont organisées par blocs dont les valeurs minimales et maximales sont connues des cellules de stockage. Il est annoncé qu'une application migrant vers Exadata verra beaucoup de ses index devenir inutiles.

Je ne parle pas du cache de second niveau réalisé par des flash cards ni de la redondance en terme de machine, stockage et liaison car cela me parait plutôt classique pour une configuration RAC + ASM + baie SAN.

Ils ont clairement mis le paquet pour offrir un «killer product».

Enfin, les coûts de migrations sont minimes pour une application déjà sur une BdD Oracle puisque le système est vu comme une base 11gR2. Si tout va bien, il suffit de passer à la caisse et de constater que les performances sont monstrueuses :). J'ai hâte d'être convié à un proof of concept !

À noter que la même chose avec WebLogic server, via le produit Exalogic.

L'avenir est intéressant...

La culture du développeur

2010-11-25T06:42:00.003+01:00

Sur mon nouveau projet, je fais un bon en arrière de quelques années en redécouvrant la programmation en C.

J'en gardais de mauvais souvenir depuis l'école d'ingénieur : les erreurs de segmentations fréquentes, le sentiments de ne pas savoir ce que le code faisait, la gestion des pointeurs et l'obscurantisme des fichiers Makefile.

Pourtant, j'éprouve moins de difficultés que je ne prévoyais. Est-ce que c'est l'expérience en tant que «pro» qui m'a apporté une vision globale de la programmation ou la curiosité qui m'a fait fouiner dans les sources de certains logiciels libre ? J'ai l'impression que le C est un langage simple car mettant en jeu peu de concepts comme il y en a en C++, Java et même Python et que rien ne peux m'arrêter. C'est encourageant de voir à quel point l'expérience permet d'avancer en terrain connu malgré les nouveautés et un contexte différent.

Je vais me lancer dans un programme en Pro*C multithreadé... même pas peur !

Erlang

2010-10-24T21:11:00.002+02:00

On entend beaucoup parler d'Erlang en ce moment. J'ai relu un article qui parlait d'Ejabberd (serveur XMPP en Erlang), un autre sur CouchDB (base de données orienté documents), on en parle souvent sur InfoQ. J'ai même vu un livre dessus dans le rayon informatique de la Fnac (aux éditions Pearson, j'imagine que c'est le seul ouvrage en Français :)).

C'est un langage fonctionnel créé par Ericsson il y a une vingtaine d'année. Il est donc très orienté réseau. Si j'ai bien compris, il s'adapte naturellement à des évolutions hardware (ajout de cpu, voir de cluster), supporte très bien les augmentation de charge et est super robuste. On en parle beaucoup en ce moment puisque beaucoup d'application cloud l'utilisent pour faire communiquer des machines.

Le code est exécuté sur une machine virtuelle. Le tout est open source et peut être récupéré sur le site officiel.

Cependant, c'est un langage qui est considéré comme "exotique". C'est vrai je n'ai pas une culture qui me permet de comprendre ça (pour l'instant):


%% quicksort:qsort(List)
%% Trie une liste d'éléments
-module(quicksort).
-export([qsort/1]).

qsort([]) -> [];
qsort([Pivot|Reste]) ->
   qsort([ X || X <- Reste, X <>= Pivot]).

Source : wikipedia

Mais ça reste intéressant par les temps qui courent.

A votre avis, ça vaut combien un expert Erlang sur le marché ?

Nouveau projet...

2010-10-21T22:14:00.002+02:00

Fin d'une époque, après 3 ans à intégrer une solution d'OSS, me voilà parti sur un projet de data warehouse... Changement total de perspective !

Appli critique
Des To de données
De l'ETL Ab Initio classos
Encore des To de données
Du Pro*C
Des To de données
De l'Oracle en intraveineuse
Il te restera bien un peu de To de données, non ?

Pas d'agilité, mais beaucoup à faire a priori. Je vais bien pouvoir caler un peu de tests unitaires dans tout ça...

Craftsmanship

2010-10-21T09:00:00.000+02:00

Un courant dont on parle de plus en plus dans le monde de l'agilité est celui du software craftsmanship. C'est un point de vue d'avantage tourné vers les aspects techniques qui apparaissent comme parents pauvres de la conception de l'agilité aujourd'hui orienté gestion de projet et de ses ressources.

Les valeurs de se courant sont énoncées dans un manifeste qui se veut être un complément du manifeste agile. Le but avoué est de viser l'excellence technique, de devenir meilleur développeur, d'apprendre sans cesse. Le but n'est plus de livrer un logiciel qui marche mais un logiciel globalement bien construit. Un peu si on disait "bien sûr que le logiciel marche, mais dites moi plutôt ce que vous pensez de mon code source" !

On peut se demander pourquoi un tel mouvement émerge, alors que l'agilité est au départ orienté vers la technique, avec des pratiques comme la programmation en binôme et surtout le développement dirigé par les tests, lié à eXtrem Programming. Peut-être est-ce en réponse au fait qu'aujourd'hui XP est un peu oublié au profit de Scrum, qui a ceci de pratique qu'elle ne spécifie aucune pratique de développement ! Est-ce bien réaliste de demander à l'équipe de réaliser des livraison incrémentales installables en production sans un filet de sécurité offert par les tests unitaire et une non reg automatisée ? Je l'ai fait, il faut aimer l'adrénaline !

Ce principe d'artisanat (crafstmanship) prend une dimension aujourd'hui une dimension "économique" avec l'émergence des offres PaaS comme l'AppEngine de Google. Aujourd'hui, le développeur peut directement mettre son application à disposition avec une faible mise de départ. Plus besoin de couteuses études et d'acheter un serveur à plusieurs kilo euros. On développe, on déploie, on fait un peu de promotion et on voit si ça marche. Si ça ne marche pas, on abandonne et on cherche une autre idée. Et boum, tout un pan du management IT vient de tomber (enfin je plaisante, mais il faut réaliser que les choses vont peut-être changer).

Personnellement, les valeurs de ce mouvement me plaisent parce qu'elles remettent le développeur au centre du système. C'est la personne qui crée la valeur et il faut la motiver à devenir meilleure professionnellement. J'en ai marre de voir des gens qui s'arrêtent de développer parce que leur métier n'est pas reconnu, voire littéralement méprisé (oui, je veux parler de l'offshore).

Présenation Software Craftsmanship

2010-10-20T09:11:00.002+02:00

L'artisanat, la première entreprise IT ?

Voici une belle présenation du mouvement "Software Craftsmanship". Si vous avez un peu de temps (1 h).

http://www.infoq.com/presentations/Software-Craftsmanship-Beyond-The-Hype

Révélation sur couriel

2010-09-09T22:51:00.003+02:00

Attention, ce qui suit révèle ma stupidité.

Mon client a des serveurs de production virtuels, naturellement hébergés sur un ESX VMWare. Je ne comprenais pas pourquoi alors que le serveur était au repos (base de données hébergée arrêtée), la mémoire libre indiquée par top était de 1 Go sur 8 Go alloués. Je ne comprenais pas pas pourquoi cette même mémoire ne variait pas quand la base était lancée... Jusqu'à un certain moment.

Du coup, j'ai essayé de trouver de l'info. En écrivant un mail pour la liste de distribution des "techos", j'ai eu la révélation... Hey, mais si l'ESX allouait la mémoire de façon dynamique ? Est-ce ce que ce ne serait pas un des buts de la virtualisation ?

J'étais tellement focalisé sur le fait que "les VM c'est que pour nous arnaqués sur les machines qu'on demande" que j'avais oublié de réfléchir.

J'ai un peu honte... Mais je suis rassuré car ça fait un problème d'écarté :).

Ça ne m'a pas empêché d'avoir une dure journée... la messagerie instantanée entre client et fournisseur n'est pas une bonne idée...

Java VS PL/SQL

2010-09-02T15:01:00.000+02:00

Depuis que je bosse je fais beaucoup de PL/SQL. Le PL/SQL c'est le langage procédural pour les bases de données Oracle qui reprend grosso modo la syntaxe SQL. Mais bon, c'est vieux. Les structures de données sont toutes pourries, le langage n'est pas sensible à la casse, la longueur des noms est limitée, les valeurs des variables ne sont pas isolées lorsqu'on joue le code plusieurs fois.

Par contre, ça va vite, enfin j'imagine ou j'espère parce que c'est Oracle et il sait ce qui est bon pour lui...

Depuis quelques temps, je me demande si ça ne pourrait pas être mieux d'implmenter certains traitements en Java. Est-ce vraiment moins performant ? Est-ce que la coolitude d'un langage un peu actuel peut compenser un manque de performance ?

En plus, on fait des tests unitaires avec JUnit sur les procédures PL/SQL :)

J'aimerai bien avoir des avis là-dessus mais je ne me fais pas d'illusion, je crois que le nombre de lecteur est passé sous la barre de zéro.

PS : je sais, Java c'est aussi à Oracle
PPS : SQL*Plus, c'est naze pour faire des csv...

Ben ça, ça tombe bien alors

2010-09-01T15:00:00.000+02:00

Ça vaut bien un post !

Vim 7.3 est sorti → par là.

C'est juste le meilleur éditeur de texte. Mes documents Word contiennent plein de ":w" maintenant !

Oui c'est très objectif.

Javascript

2010-08-30T01:17:00.003+02:00

Il y a une époque, tout le monde considérait que le JavaScript, c'était sale et globalement pourri. Maintenant que Google est passé par là et que la navigation sur Internet nécessite un CPU 4 cœurs pour un minimum de confort, le paradigme a un peu changé.

Alors pour faire un site pour madame, je m'y mets.

Au départ à l'ancienne, avec les évènements imbriqués dans le HTML (pas taper, merci).

Puis j'ai découvert le concept de JavaScript non-intrusif.

Et là, ça commence à être classe !

Vous tremblez, Néron.

2010-08-29T10:00:00.001+02:00

Il y a bien un truc que je déteste maintenant que je suis ultra fan du TDD, c'est que les gens de l'équipe développent sans mettre à jour les tests. Tu reviens sur ton code pour ajouter un truc, tu lances les tests et bam, t'as le droit de débugger ta suite de test.

Alors, je me suis enfin décidé à les mettre dans le build >_<.

On va bien se marrer.

PS : encore faut-il regarder le résultat du build... vive le développement informatique...
PPS : allez, je vais mettre checktyle aussi. On va bien se fendre la gueule !

Premier truc cool dans le monde du libre!

2010-08-28T02:10:00.003+02:00

J'ai avancé sur la dockapp wmauda. Ca marche ! Avec dbus et tout !!!

Le plus long était de savoir pourquoi le logo ne s'affichait pas dans la doc app... c'est parce qu'il fallait forcer le depth à 24 ! J'ai bien mis du temps pour comprendre ça.

Un peu de refactoring et de packaging et je pourrai diffuser.

Si ça ce trouve, les modifs sont faites depuis longtemps dans les distrib mais bon, c'est fun quand meme !

Je vais me coucher...

Édition : après vérification, il semble que je sois arrivé à peu près à la version empaquetée dans Debian. Je vais donc m'arrêter là je crois. Ce qui est marrant c'est que nos codes sont très similaire... à part que le mien allait être plus propre ;).

Nouveau projet (perso)

2010-08-05T07:21:00.005+02:00

Je me suis dit que pour m'amuser j'allais faire fonctionner la dockapp wmauda avec audacious 2.3 en utilisant dbus pour communiquer avec le lecteur.

Quand on n'a pas fait de C depuis longtemps c'est un peu la douche froide et après avoir galéré pendant 2 - 3h, je commence à avoir une idée de ce qu'il faut faire :) (merci le code de audtool en tout cas :)).

Dans un second temps, j'essaierai de voir si on peut pas coder la dockapp en python. Communiquer sur dbus en python ou en C, ça n'a RIEN à voir :D.

Uncle Bob

2010-06-03T00:38:00.001+02:00

Je reviens d'une formation extrem programming. C'était bien cool.

J'ai dégoté une conférence de Robert C. Martin dont je conseille à tout développeur de lire au moins une fois "coder proprement".

Manuel d'installation

2010-05-03T15:25:00.001+02:00

Au boulot, le dernière livraison majeure que j'ai faite était plutôt tranquile, merci les pratiques agiles et l'intégration continue. J'ai pu me concentrer sur l'élément de documentation le plus important : le manuel d'installtion. En effet, vous pouvez livrer le meilleur soft du monde, si l'installation est hasardeuse, votre travail sera tout de suite regardé d'un mauvais œil.

Dans mon jeune temps, je pensais que les personnes qui installaient les softs étaient des informaticiens cheuvronnés. Des gens qui savent éditer un fichier avec VI, chercher les informations de configuration sur le système et la base dedonnées et lancer des scripts shell. Grossière erreur :

Parfois, la qualification est réalisée par des équipes spécialisées, on parle de Tierce Recette Applicative (TRA). Il ne faut pas penser que ces équipes sont faites de geeks développeurs hardcore. Les personnes de ce genre sont embauchées pout faire du développement ! D'un autre côté, pour faire de la recette, il vaut mieux embaucher des gens avec des connaissances métier, non ?

D'autres fois, les équipes qui installent ne font que ça tous les jours (j'en ai vu). Je ne pense pas que ces gens, mêmes s'ils sont très compétents, aient envie de se taper des dizaines de fichiers de configuration pour installer un soft. La solution livrée est censée être intégrée, non ?

D'un autre côté, lorsque la procédure d'installation est fastidieuse, il est d'autant plus complexe de la documenter de façon satisfaisante. Comme c'est quelque chose de maîtrisé par l'équipe de développement, on a facilement tendance à oublier des étapes...

Alors, voilà mon parti pris: améliorer l'intégration de la procédure d'installation, que ce soit en terme logiciel et documentaire. Idéalement, l'installation d'un logiciel doit pouvoir se faire depuis une seule machine en ne tapant qu'une commande, sans éditer de fichier. Mon manuel d'install est light, il n'expose que les prérequis logiciel, dit ou doivent être déposé les archives et donne LA commande à lancer. Les paramètres de l'environnement de prod sont dans des champs du document qui sont mis à jour par une macro. Perte de temps minimal pour la mise à jour.

Je n'ai même pas été contacté pour faire une assistance à la mise en production.

Latex on my nerves

2010-05-02T14:51:00.001+02:00

Finally, I see that I got bored writing a weblog in English. Let's switch to French, the best language in the world.
Surtout que j'écris tout le temps en Anglais pour le boulot. C'est fatiguant.

Il y a quelques temps déjà, j'ai aidé ma belle sœur pour un devoir de maths. Ça a été plus difficile que prévu de calculer des coordonnées de vecteurs (snif, c'et loin).
J'ai terminé assez tard à la maison et je me suis demandé comment transmettre les résultats. Voyons voir, quelle est la façon la plus élégante pour un développeur de rédiger des formules mathématiques ? Latex bien sûr !

Le problème est que je suis un vrai noob en Latex. J'ai passé toute ma soirée à chercher les imports de modules manquants et a régler mes problèmes en feuilletant mon livre (parce que je ne fais jamais de Latex, mais j'ai quand même un livre -_-'). Ce qui m'embête avec Latex, c'est qu'il faut être une espèce de mutant pour se rappeler tous les éléments de syntaxe. Peut-être que les profs d'enseignement supérieur sont des mutants, ça expliquerait des choses.

D'autre part, je me demande pourquoi j'utilise encore un clavier AZERTY... Parce que passer son temps à écrire des antislashes et des accolades avec un tel clavier doit certainement être catalogué comme torture par Amnesty International. C'est assez frustrant quand il est 1:30 et qu'soit en train de taper des trucs comme:


\begin{align}
\left\{ \begin{aligned}
x + 1 &= y + 4 \\
\frac{y + 1}{3} &= x - 5
\end{aligned} \right.
...
\end{allign}

Ensuite, je trouve que pour faire un document basique on a besoin de pas mal de modules. Je crois que sous Debian, je dois avoir installé près de 200 Mo de package rien que pour rédiger et formatter une lettre. Bon, ça ne concerne que moi mais... c'est un compilo quoi !!!

Extreme Programing

2010-03-02T23:15:00.001+01:00

That's how we should work...

Having fun with Google Buzz

2010-02-28T14:33:00.000+01:00

I've found that Google provides an API for Buzz. For fun, I've tried to begin desktop client using python.

Unfortunately, it seems that only read access is provided by now. It works with RSS feeds. Finding my userid to build feed url was such a pain in the ass !

References

API documentation
Universal Feed Parser: Python lib to parse RSS feeds soooo easily!
My Buzz Feed, 'cause my life is so cool.

Howto launch openoffice.org in Window Maker

2010-02-27T17:12:00.000+01:00

I like Window Maker as a desktop manager. But sometimes, software developers don't like it as I do. That's the case for openoffice.org. It doen't know what graphic toolkit to use. You have to help it a bit.

If you always want to launch OOO from a terminal then type


$ export OOO_FORCE_DESKTOP=gnome
$ oocalc

and it could be a good idea to add the 1st line in your .bashrc.

If you want to set it in WM menu, write as command:


OOO_FORCE_DESKTOP=gnome oocalc

And it works !

Weak coder review

2010-02-17T19:00:00.000+01:00

Sometimes it's such a pain in the ass to figure out how your colleagues are weak developers. Worse, they believe they are too smart to ask for help.

Here is the review of today's refactoring session on some ksh scripts.


#!/bin/ksh

##########################
## Variable definition
##########################

logInfo "Variable definition"

SH_DIR=something
BASE_DIR=something/else
SCRIPT_DIR=other/stupid/path

#############################
##Functions
#############################
function sourceLogInitScript {
. $SH_DIR/.logInit
}

################
# Main
################

sourceLogInitScript

#Other stupid code lines and comments

Unfortunately, logInfo is defined in .logInit as are variables BASE_DIR and SCRIPT_DIR. I guess it is too boring to have a look at a script where 50% of the functionality you are scripting is written. Of course, logInfo not found error is displayed at execution, but why giving a fucking damn at errors when you are testing your stuff??? Silly idea, right ?

I avoid mentioning the comments that seem to be there to make the script look bigger and sooo hard to understand...

I wish I had TDD.

2010-01-18T00:17:00.000+01:00

Has you know, I was recently on a PLSQL package to produce a 60 colums report. And it is still buggy. Two lessons for me:

1. Never believe that a code work because you are told so.
2. Begin the job by creating an automated test (...suite).

Not so long ago, I though the idea of Test Driven Development was kinda weird. Why starting by writing tests ? Where is the value ???
Step by step I gave it a chance. It's the only reasonable way to do refactoring. By refactoring, I mean changing large blocks of code, not renaiming functions or deleting unuseful comments.

Now I've figured out that it is the only way to perform as stressfree as possible firefighting (that we all eventually do, don't we ?).

Try to manually check results of a 60 columns sql report 30' before delivery to validate some bug fix. No, don't even try: you can't.

Now I'll let the machine do it for me. EVER. Spending 2 hours to write an automated test suite is not a waste of time, after all.

For Kent Beck fan boys oblidged to develop in PLSQL: a unit test framework ALREADY exists : utplsql (I've never used it yet though).

Private procedures un plsql

2010-01-08T14:55:00.000+01:00

Hi, and happy new year for you, few readers.

I began this year with Oracle plsql. I like this language because I find it very efficient and quite easy to test and debug. However, it's a bit out of date compared to fashinable languages.

I had to debug a huge plsql package (1500 lines, believe me, it's huge for a piece of code!) made of 3 procedures :'(. My first action is to split it in more functions and procedures (remember that this is 2 distincts objects in plsql).

As I'm a huge fan of a book by Robert C. Martin[1], I put functions bellow the place it is called, to make code reading easier. Unfortunately, the code doesn't work unless I put declaration in spec package. So boring ! Moreover, the function then become public, what I want to avoid.

Then I discover something one day before leaving. Here is the example of code:

PACKAGE BODY FOOBAR IS
PROCEDURE MAIN IS
BEGIN
   PROC_ONE;
   PROC_TWO;
END MAIN;

PROCEDURE PROC_ONE IS
BEGIN
...
END;

PROCEDURE PROC_TWO IS
BEGIN
...
END;
END FOOBAR;

This does not work unless PROC_ONE and PROC_TWO are declared in spec package but


PACKAGE BODY FOOBAR IS
PROCEDURE PROC_ONE IS
BEGIN
...
END;

PROCEDURE PROC_TWO IS
BEGIN
...
END;

PROCEDURE MAIN IS
BEGIN
   PROC_ONE;
   PROC_TWO;
END MAIN;

END FOOBAR;

works !!!

I think I haven't searched enough in the documentation -_-'.

[1]: Clean Code: A Handbook of Agile Software Craftsmanship
# ISBN-10: 0132350882
# ISBN-13: 978-0132350884

Playing with Perl

2009-11-28T13:05:00.000+01:00

I'm a Perl beginner. Actually, what I read here and there let me think Perl is a pretty cool language. It does not need compilation, can be compatible with *nix and Windows. It has a powerful regex engine and quite a simple syntax. Finally, the large amount of modules available on CPAN can extend it in an amazing way.

The first real thing I made with is a tool to convert gmail contact list export file to something I can enter in my .muttrc (yeah, I use mutt with imap to retrieve my mail on gmail).

Data processing was quick to write. But it was hard to make it work. After a couple of hours (gimme a break, I'm a n00b, remember !), I figured out the contact.csv file was encoded in UTF16... Wait, what?! I've never seen this encoding before. Then, I was obliged to use iconv to preprocess the file and everything went fine!
Another trick is to check for unicity of mutt aliases.

If you're interested source is here. Obviously, it needs improvements.

Intro

2009-11-28T12:58:00.001+01:00

`/0 !

I'm a French developer. I work for a big service - consulting company in Grenoble, a little that some people often call "French Sillicon Valley" (please, don't laugh). I'll try to share some things about code, agile practices and other experiences.
I'm kinda free software supporter, so I will bother you a lot about that!

Do not hesitate to comment!

And sorry in advance for my "English mistakes" (nobody's perfect) ^^.