20th May 2008

Video blogging?

Pourquoi pas? Voici donc un petit essai…


Et pour que ce soit fun, n’hésitez pas à poster vos commentaires en vidéo!

posted in Books | 2 Comments

16th October 2007

Smart developers

Aujourd’hui, je visitais le site tout nouveau de Seesmic (nouvelle boite lancée par Loic Le Meur il y a quelques jours à peine). Comme je n’ai pas encore de clé d’invitation, ce n’est pas très intéressant… Mais comme le design est sympa, je me demandais quelle techno ils utilisent.

Que fait-on dans ce cas-là? Menu “View” > “Page Source” de mon browser, évidemment (on est geek ou on ne l’est pas). Quelle ne fut pas ma surprise, en découvrant les quelques premières lignes du code HTML:

<html lang="en">

<!--
Smart developers always View Source.

This application was built using Adobe Flex, an open source framework
for building rich Internet applications that get delivered via the
Flash Player or to desktops via Adobe AIR.

Learn more about Flex at http://flex.org
// -->

...

Smart developers always View Source“… Excellent!! Ca m’a fait bien rire 😉 Mais c’est bien, car je n’ai pas du chercher longtemps pour obtenir la réponse à ma question.

Je n’ai donc pas tardé à aller voir le site de http://www.flex.org. Et je dois dire que les applis qu’ils montrent dans leur show-case sont vraiment cool. Voir maintenant, étant donné que je ne connais pas du tout Flash, la difficulté de créer une petite appli. Je commence à penser qu’Ajax n’est sans doute pas suffisant si on veut faire quelque chose d’un peu “graphique”. La plupart des webapp qui offrent une GUI un peu raffinées semblent en effet utiliser Flash. Je pense a http://www.geni.com par exemple, pour l’affichage d’un arbre généalogique. Il semble par ailleurs que Yahoo! Maps utilise justement Flex. Sinon, il y a aussi Silverlight (de Micro$oft)…

posted in Software | 5 Comments

23rd September 2007

Tigermouse, un framework pour applications web

Cela fait quelques temps que je m’intéresse à la création d’applications web.

Parmi les plus connues aujourd’hui, il y a la “suite Google”: gmail, google docs, google spreadsheets, et (lancée récemment) google presentations. De merveilleux exemples d’applications web, qui à la différence d’un simple site web offrent les fonctionnalités d’un logiciel avec un browser comme GUI. Techniquement, cela fait longtemps que les webapp auraient pu voir le jour, en utilisant la technologie des applets Java, mais plusieurs facteurs (selon moi, entre autre: le fait qu’il faille installer Java, la lourdeur des applets, etc) ont ralenti leur développement. Aujourd’hui, AJAX semble remédier à certains de ces problèmes, et permettra peut-être aux webapp de se multiplier. AJAX couplé à Flash pour les applications gourmandes en graphismes (p.ex. google maps ou geni.com), permet de faire autant si pas mieux que les applets, et fonctionne dans tout browser “moderne”.

Bref, je voulais donc me lancer dans la programmation d’une webapp, et ai commencé à rechercher une technologie adaptée pour la partie serveur. Je vois au moins les choix suivants: J2EE (JSP, Servlets…), PHP, ASP… Quelles technologies les “grands” utilisent-ils? (Google, e-Bay, Amazon, YouTube, …) J’ai lu (ici) qu’e-Bay serait passé à J2EE, mais que cela n’aurait pas vraiment été un succès… Et ailleurs, la rumeur que google et amazon utiliseraient LAMP pour leurs gros serveurs… Si quelqu’un a des infos intéressantes dans ce domaine, je suis preneur.

J’ai commencé par explorer la piste PHP (qui me semblait plus “lightweight” pour commencer, que J2EE). Je cherchais un framework PHP qui me permettent d’implémenter une webapp de façon élégante; une bonne approche me semblait être le MVC (Model View Controller). Après quelques essais (j’ai exploré quelques frameworks listés ici), je suis tombé sur Tigermouse, qui m’a séduit par sa simplicité, et la “pureté” de son implémentation du MVC. Le code est extrêmement bien documenté, et répondait assez bien à mes attentes: en quelques lignes, on peut vraiment créer une webapp PHP/AJAX sans avoir à écrire une ligne de Javascript. Tigermouse me semble vraiment prometteur, même s’il manque encore de maturité pour l’instant.

Voilà le résultat de mes pérégrinations.  Pour les geek qui ont suivi jusqu’ici, je serais content de lire vos réactions.

posted in Software | 1 Comment

31st January 2007

JaSST ’07 à Tokyo: compte rendu

Hier et aujourd’hui, j’ai participé au JaSST ’07 à Tokyo (Japan Symposium on Software Testing in Tokyo) qui eu lieu dans le prestigieux hôtel de “Meguro-Gajoen” (目黒雅叙園). Voici donc un bref compte rendu.

Jour 1 (mardi, 30 janvier 2007):

La plus grande partie de la journée fut consacrée à l’exposé d’Edward Yourdon, qui consista essentiellement en un résumé de son: “Death March: how to survive mission impossible projects”. Le matin, pour le speech principal du Symposium, Yourdon présenta les chapitres 1 à 3 du livre:

  • Qu’est-ce qu’un projet “marche de la mort”, et pourquoi diable se lance-t-ton dans une telle aventure? Son message est que la plupart des projets de développement logiciel sont essentiellement des “death march” (càd des projets dont certaines contraintes telles la durée, les effectifs, le budget, les fonctionalités requises, dépassent de plus de 50% les contraintes d’un projet “normal”)…
  • Le problème numéro 1 des “death march”: la politique. Autrement dit, ce qui cause le plus souvent l’échec d’un projet de développement logiciel sont les incessantes batailles politiques entre management, clients, et autres acteurs.
  • Le second majeur problème est celui des négociations: souvent un projet se transforme en “marche de la mort” lorsque le chef de projet échoue dans les négociations de compromis entre différentes composantes (durée, coût, resources, etc.).

L’après-midi, j’ai choisi d’entendre la suite de l’exposé d’Edward Yourdon (il s’agissait d’une session spéciale payante, mais puisque mon boss m’a permis d’y participer…). Il a présenté les chapitres 4 à 6 (et un peu du reste) de son livre:

  • Autre problème important d’un projet du type “death march”: les facteurs humains, ou selon le terme américain “peopleware”. Yourdon a d’ailleurs mentionné à maintes reprises le livre “Peopleware” de ses amis Tom DeMarco et Tim Lister. Obtenir le droit de se constituer une équipe valable et travailler le “team building” semblent être des facteurs importants dans la réussite d’un projet “death march”.
  • Yourdon a également évoqué les méthodes et outils (“processes and tools”) utilisés au cours du projet, tout en rappelant que ce facteur était sans doute moins déterminant pour la réussite ou l’échec du projet que les composantes évoquées plus haut.
  • Enfin,si je me rappelle bien, il a parlé brièvement d’autres aspects comme la planification (selon une méthode appelée “critical chain”), le controle et monitoring du projet, avant d’aborder la “dynamique des processus” (un concept que je n’ai pas bien compris).

Mon appréciation globale des exposés de Yourdon est plutôt positive, avec un bémol cependant: j’ai regretté qu’il se contente de nous présenter le contenu de son livre (car le livre, chacun peut le lire par soi-même), sans entre davantage dans le thème du symposium: le test software. Ceci dit, le contenu du livre (que j’ai acheté il y a deux semaines sur Amazon, et que je me suis fait dédicacer par Yourdon –yey!) est très interessant, et le fait d’entendre le contenu du livre expliquè par l’auteur en personne est quand même une chance à ne pas manquer.

Enfin, pour terminer cette première journée, j’ai assisté à une session sur un sujet tout autre, le “model-based testing“. L’idée est la suivante: supposant l’existence d’un modèle (UML par exemple) d’un logiciel, il doit théoriquement être possible de générer automatiquement des tests sur base de ce modèle, de les exécuter (toujours automatiquement) et de vérifier les résultats, tout cela sans effort. Très belle théorie, mais qui m’avait l’air un peu fumeuse. Autant la génération automatique de code (au moyen de CASE tools) ne semble pas être une réussite globale, autant j’ai de sérieux doutes sur les chances de telles entreprises. Mais bon, chez Hitachi, ils payent apparemment un gars (au moins, celui qui a donné l’exposé) pour faire de la recherche dans ce domaine…

Jour 2 (mercredi 31 janvier 2007):

La première session de la journée était plutôt basique et concrète. Il s’agissait d’une sorte de saynette mettant en scène un jeune programmeur inexpérimenté, confronté à des problèmes concrets de test, qui demande conseil à trois “sages”, des testeurs professionels expérimentés qui lui donnent des conseils pratiques.

Les trois “sages” étaient:

Le “jeune programmeur” leur a soumis deux problèmes, l’un concernant le test d’un tableau de bord (logiciel embarqué), et l’autre un système de vente de tickets par internet (type “entreprise”), et chacun des trois “sages” proposait une approche concrète pour tester le système en question. Suzuki était partisan de l’approche basique de “table décisionnelle” (Decision Table, DT). Akiyama partait d’un diagramme causes-effets (Cause Effect Graph, CED) mais pour construire également une table décisionnelle (réduite). Et Matsuodani lui, proposait l’approche du “diagrame de flux de causes” (Cause Flow Diagram, CFD), qui ne me rappelait rien de connu (une approche plutôt visuelle, ne me semblant pas adaptée à des problème de taille réelle).

C’était un exposé très concret et pratique, qui m’a fait prendre conscience de l’importance de revenir à la théorie pour l’appliquer dans les problèmes que je rencontre tous les jours. L’importance aussi de bien vérifier la couverture des test (“test coverage”), pas seulement des spécifications de cas nominaux, mais aussi des comportement interdits, et de la masse de comportements non couverts dans les spécifications.

La seconde session était donnée par un représentant de la firme Mercury (récemment acquise par HP), qui nous a parlé de l’importance d’une vision globale des activités de test en regard avec le cycle de développement. Depuis la définition des spécifications jusqu’aux tests d’acceptance, l’importance de planifier les tests, d’en garder la trace, de les documenter, de les monitorer, etc. Tout cela pour en arriver à la présentation de leur outil “Test Director for QC”. Un outil permettant de gérer les spécifications, de créer des cas de test, de vérifier la couverture des spécifications par les tests, d’exécuter les tests automatiquement (via un language de controle de GUI), d’enregistrer les résultats, ainsi que les problèmes survenus lors des tests. Tout ça m’avait l’air très intéressant, mis à part le fait que cela implique une dépendance totale à leur outil. Tout est intégré, mais que faire si je souhaite utiliser DOORS pour gérer mes spécifications, ou encore gérer mes bugs via Bugzilla plutôt que via leur truc?

L’après-midi, Toru Matsuodani (Debug Engineering Institute) nous parla de sa “Vision future dans le domaine du test logiciel“. Dans la pratique, on observe que tout projet software coûte 30% en développement, et 70% en test. Comment réduire le coût (relatif) du test? Selon Matsuodani, on a pendant un temps cru que l’approche visant simplement à améliorer les mèthodologies de développement (CMM, et autres) seraient suffisantes, mais apparemment cela ne change pas le coût relatif de 70% pour les tests. La raison selon lui, est que ce n’est pas en améliorant la qualitè du logiciel produit que l’on rèduira l’effort nécessaire pour le tester. En effet, l’effort de test est lié à la taille de l’espace des entrées-sorties du système, càd l’espace que les testeurs devront parcourir pour trouver les bugs. Qu’il y ait moins de bugs ne réduit pas cet espace, mais c’est en réduisant la complexité du système (p.ex en divisant le logiciel en plus petits composants) que l’on pourra réduire l’espace à parcourir lors des tests. Et cela n’est réalisable, selon lui, qu’en passant d’un design du type “facile à fabriquer” à un design du type “facile à tester”. Autrement dit, prendre en compte le problème du test dès la conception du logiciel.

Cela nous mène déjà à la dernière session de ce symposium: une table ronde mettant en scène les orateurs suivants:

  • Edward Yourdon (NODRUOY Inc.)
  • Yamaura (Tokai University)
  • Toru Matsuodani (Debug Engineering Institute)

Le thème du débat était “Taming a Monster“, càd: “Dresser un monstre”, faisant allusion au “monstre des bugs” auquel s’attaque l’équipe de testeurs corps et âme. Chaque orateur avait préparé un court exposè, présentant sa façon d’aborder le problème.

Matsuodani dans son exposé très imagé, pointa l’importance de: (1) réduire les attentes des clients, du management etc; (2) augmenter la motivation de l’équipe de test/développement; et (3) réduire la complexité du logiciel à tester en “divisant pour régner”.

Yamaura, lui, parla de l’importance des compromis dans la négociation des spécifications, du “triage”, de l’importance de faire comprendre au management que le coût du software en fonction des resources ne répond pas à une loi linéaire (cf loi de Putnam), et proposa d’assigner une personne seulement responsable de vérifier la couverture suffisante des tests entrepris, ainsi qu’un “gardien des spécifications”.

Enfin, Yourdon mentionna une fois de plus les problèmes politiques, l’importance de la collaboration (au sein de l’équipe et en dehors), et de la négociation de compromis, rejoignant donc l’exposé de Yamaura.

Le temps de questions-réponses fut intéressant également. On y aborda notamment les points suivants: le fait que très peu de CTO (ou CIO) deviennent CEO montre que les priorités des entreprises de nos jours sont davantages dans la finance que la technologie. Egalement, l’importance de s’intéresser au phénomène “open-source”, mentionnant notamment Linux et Wikipedia.

Conclusion

Je ne vais plus la faire longue, juste dire que j’ai trouvé ce symposium très intéressant. Dépassant largement la discussion du test logiciel, il m’a donné envie de me plonger dans d’autres bouquins pour approfondir un tas de concepts nouveaux.

posted in Software | Comments Off on JaSST ’07 à Tokyo: compte rendu

28th January 2007

Symposium

Cette semaine, j’aurai la chance de participer à un symposium sur le test logiciel: “Japan Symposium on Software Testing in Tokyo (JASST ’07 Tokyo)“.

Se déroulant sur deux jours, mardi et mercredi, ce symposium promet d’être intéressant, notamment car l’un des orateurs n’est autre que Edward Yourdon, un fameux consultant dans le monde du développement logiciel. Outre des centaines d’articles techniques, Ed Yourdon a également écrit plusieurs livres, dont “Death March”, un ouvrage présentant des stratégies pour survivre à des projets de développement voués à l’échec (qu’il appelle de façon très imagée les “marches de la mort”).

J’attends pas mal de ce symposium et espère qu’il m’apportera des éléments d’information intéressants et concrets.

posted in Software | Comments Off on Symposium