tyPouypOblOg

Je viens de finir le livre de Véronique Messager Rota Gestion de projet – Vers les méthodes agiles .

Un très bon complément à mes précedentes lectures sur le sujet, ainsi qu’au divers informations lu de-ci de-là sur le web.

J’aimerais maintenant une chose, c’est pouvoir participer à un projet agile :-) En tant que développeur dans un premier temps, et pourquoi pas plus tard, avec plus d’éxpérience dans le domaine, en tant que coach agile.

Messieurs les coachs et autres chefs de projets, j’étudirais très sérieusement toute proposition de rejoindre une équipe agiles !

Et je vous conseil la lecture de ce bouquin

A force de placer mes fenêtres toujours au même endroit, avec la même taille (ou presque) et de repartir ces groupes sur les divers bureaux, je me suis dit qu’il étais peut-être temps de tester un autre gestionnaire de fenêtre.

Ion semblait un bon candidat, mais la configuration ne me donnais pas super envie, et les divers lectures au sujet de l’auteur et de la licence de l’application ont fini par me couper l’envie de l’adopté.

Alors j’ai continué à fouiller dans les gestionnaires de fenêtre accès clavier et simplicité. Sur la list misc@ d’OpenBSD il y avait eu une discussion sur le gestionnaire de fenêtre par défaut. Actuellement FVWM (premier du nom), certain voulais voir cwm prendre la place. Du coup, il fallait que je l’essaie.

Assez sympathique ma fois. Simple, avec quelque raccourci clavier rappelant Vi. Très rapide, et très agréable à utiliser.

Cependant, je n’etais pas encore convaincu. J’avais entendu parlé d’un autres gestionnaire qui pourrais remplacer Ion durant mes recherches: Wmii

Alors pour être dérouté, on peut l’être. C’est très interessant. Ici point de menu, d’icône, de boutons de fenêtre. Une petite barre, quelques touches et c’est parti. Un des concept est de ne pas avoir à gérer les fenêtre justement: on arrive sur une frame, une petite combinaison de touche et hop, un terminal en plein écran. On en lance un deuxième, pour voir, et voilà deux terminaux qui prenne chaucun une moitié d’écran, un troisième et … non, je vous laisse deviner. Une autre combinaison de touche plus loin et paf, c’est sur deux colonnes que ça se passe, royal. Plus la peine de placer les fenêtre ! :) Plus de place à force de lancer des applications ? Une petite combinaison et paf, je met la nouvelle appli sur une autre frame (on pourrais les apparentés à un bureau virtuel qui s’étend a mesure du besoin).

J’adore :)

Et pour ne rien gacher, je me rends compte qu’un figure du monde Ruby , Mauricio Fernandez aime et utilise (il me semble) lui aussi ce gestionnaire de fenêtre (il a d’ailleurs commencer à faire quelque script et autre bricole en ruby pour Wmii , mais c’est une autres histoire).

Et dans toute ces histoires de script et de config, je tombe sur encore une sommité du monde Ruby: Why qui apparemment aime et utilise Wmii ! (D’ailleurs, j’ai découvert qu’il utilisais DragonFlyBsd contrairement à tout les macaddict que l’on voit beaucoup dans le monde de Ruby sur les rails ;-) )

Finalement je ne suis pas trop surpris, je trouve que l’auteur de Wmii ressemble un peu à ces deux là. Anselm R Garbe est un doux dingue du petit code efficace, c’est d’ailleurs le concept du site dont il est fondateur sukless.org :

Dedicated to software which sucks less… The upper boundary on the size of the software we accept is 10,000 source lines of code (SLOC).

J’ai encore plein de chose à découvrir, mais si vous voulez essayé un gestionnaire de fenêtre innovant, je vous conseil d’essayer Wmii

ps: j’allais oublié. le peu d’intérêt d’un screenshot avec ce genre de gestionnaire de fenêtre explique le manque d’image de ce billet :)

Pour ceux qui en doutais, les design pattern du GOF on bien une raison d’exister dans Ruby. Alors certes, mon article sur les motifs de conception en ruby sur le site de rubyFrance n’est peut-être pas top top, ma seul excuse est que cet exercice m’a permis de découvrir ruby. Mais toujours est-il que l’utilisation de pattern dans un langage objet est fortement recommandé !

D’ailleurs, un livre (en anglais) est sorti sur le sujet (Russ Olsen m’a piqué mon idée :-p): Design Pattern in Ruby. Je crois que malgré le tarif ($42.99) et mon faible niveau d’anglais, je vais me le commander. Peut-être que cela me permettra de refaire quelque exemple mal choisi sur le site de RubyFrance…

via Ruby Inside

C’est le 25 décembre aujourd’hui… Et comme d’habtidue à cette période en hiver, c’est noël, ok, mais c’est surtout la sortie d’une version de Ruby !

Que du bonheur ! Monsieur Matz non content que certains test ne passe pas, a décidé de numéroter la version 1.9.0 au lieu de 1.9.1. Une autopunition :p M’enfin.

Pas mal d’avancé dans cette version: meilleur support d’unicode, rake et rubygem sont intégré à Ruby. Jean-François parle également d’un nouveau moteur d’expression rationelles sur le site de rubyfrance.org.

Bon code !

Me voilà donc revenue dans le monde du service informatique. En mission chez un grand compte comme on dit. Une étape, pour me remettre dans le bain.

Mais voilà, chez ce client, comme chez beaucoup d’autres je pense, c’est à l’ancienne (ben oui c’est pas juste ma reprise de service qui est à l’ancienne ;)).

J’entends par là, vieille technologie propriétaire, vieille méthodologie non approprié.

D’un point de vue technologique d’abord. L’utilisation de cette technologie est une erreur et pour preuve. J’ai passé a peut prêt 75% de ma journée à essayer de remettre mon environnement de développement en route.

Forcement, j’ai une machine sous windows, assez récente, mais je ne l’utilise que pour me connecter en TSE à un serveur, sous windows également (déjà il y a du gâchis là, un thin client m’aurais suffis pour cela non ?). Bon passons pour les systèmes d’exploitation et le gâchis de matériel.

Alors forcement, la dessus, on se connecte tous on viens taper sur le même serveur de base de données et quand un petit malin (genre moi) fait tout planter sur un test de migration, ben c’est une 10aine de personnes qui sont au chomage technique. Mais il arrive aussi (caprice du monde propriétaire) que d’un coup, sans savoir, sans pouvoir analysé d’où, un problème survient, vous empêche de vous connecter. Vous aller voir les voisins, eux aussi ne peuvent pas bosser… Alors on reboot, ça ne fait rien, on fait quelque danse grigri en priant pour que ça reparte (enfin ceux qui sont croyant, moi je vais prendre un café dehors en général :p).

Bref, matériel et technologie à l’ancienne

Pour ce qui est des méthodologies: Papiers, verrouillage des spécifications fonctionnelles.

Tu sais ce que tu veux pour dans 2 ans pour des utilisateurs que tu n’as vu que 8 heures il y a deux mois ? ok ! Alors on verouille, tu pourras plus rien demander de plus pendant l’année qui s’écoule (si on a pas trop de retard genre voir chapitre précédent).

Horrible non ? Et bien c’est un peu ça que l’on souhaite mettre en place là, car forcement, il y a trop de modification en court de développement... Ben voyons.

C’est agile ça non ? Non effectivement, c’est à l’ancienne ...

Mais il ne faut pas croire c’est une bonne chose qui m’arrive ici. Je peut essayer d’imaginer comment je ferais autrement. Je peut aussi vérifier les arguments divers et varié pour ou contre tel ou tel méthode, technologie. On le sait, on le lit partout, mais s’y frotter pour de vrai c’est encore une autre affaire. J’ai déjà eu cette occasion y’a un moment, mais y revenir ça fait du bien, ça rafraîchi la mémoire.

Ceci dit, vivement la suite quand même :)