20080723: Le héros post-moderne

J'ai commencé à m'intéresser à l'informatique à peu près au moment où le cyberpunk, comme genre littéraire, naissait.

Profondément enfoui dans mon subconscient se trouve donc la conviction que l'informaticien est LE héros post-moderne, et conséquemment que l'informatique, ou plus précisèment l'activité de programmer des ordinateurs et aussi celle d'assembler des machines qui lui est souvent associée, sont des activités, des processus, éminemment post-modernes.

Le héros post-moderne se méfie des grands récits, il est paranoïaque.

Il est même parfois un peu schizophrène, quand il lui arrive de détourner le système à ses propres fins, car qui sait si ce n'est pas le système qui le détourne ? La matrice n'est-elle pas que l'espace utilisateur d'un gigantesque OS, et en déchirer le voile ne serait-il pas accéder à l'espace noyau ? Auquel cas, l'envers du décor, c'est toujours un autre décor, et non pas la réalité.

Le héros post-moderne est profondément libertaire. Il n'aime pas le pouvoir et n'apprécie les règles et les lois que lorsqu'elles sont révocables à merci. Il peut adopter un mode de vie strict, voire ascétique, dans un but de dépassement de soi, jamais par dévotion envers une religion.

Le héros post-moderne est Agile. Il est pragmatique dans sa pratique, et idéaliste dans ses objectifs. Il évolue dans des organisations qui sont idéalistes dans la pratique qu'elles imposent, et pragmatiques dans les buts qu'elles poursuivent.

Le héros post-moderne sait que la chair est triste, et il a lu un peu trop de livres. Il n'en aime pas moins passionnément la vie et la connaissance.

Il sait que la révolution doit être souhaitée, mais qu'elles finissent toutes dans le bain de sang et la dictature. Il institue donc des micro-révolutions là où c'est possible, trace des lignes de fuite. Sa stratégie est celle du rhizome. Son horizon la totalité du réel.

Le héros post-moderne aime XP car XP a été conçu par un héros post-moderne, pour d'autres héros post-modernes. Il n'est pas un solitaire et n'a aucune appétence pour l'érémitisme. Au contraire, il recherche la compagnie de ses semblables, car il sait que le sens est dans la relation aux autres, pas dans le solipsisme.

Le héros post-moderne ne se désole pas de la récupération de ses fétiches par la société spectaculaire, car il sait que c'est le lot de toute chose, et la seule chose que sait faire le spectacle. Il est lui-même un grand récupérateur, assembleur, bidouilleur, sampleur, mashupeur... Nomade et pragmatique, il change de terrain de chasse quand l'herbe a été trop remâchée.

Je ne suis pas ce héros, mais il ne me déplairait pas que je le fusse.

20080714: Installation serveur

Vserver script

Created vserver creation script:

DNS

Created zone files for oqube.net

cat >> /etc/bind/db.oqube.net << EOF
$TTL 3h
oqube.net.  IN SOA  master.oqube.net. adminsys.oqube.net. (
        1   ; serial
        3h  ; refresh
        1h  ; retry 
        1w  ; expire
        1h ); negative cache TTL


oqube.net. IN NS master.oqube.net.


master.oqube.net. IN A 192.168.50.1
dev.oqube.net.    IN A 192.168.50.2
EOF
cat >> /etc/bind/db.192.168.50 << EOF
$TTL 3h
50.168.192.in-addr.arpa.  IN SOA  master.oqube.net. adminsys.oqube.net. (
        1   ; serial
        3h  ; refresh
        1h  ; retry 
        1w  ; expire
        1h ); negative cache TTL


50.168.192.in-addr.arpa. IN NS master.oqube.net.


1.50.168.192.in-addr.arpa. IN PTR master.oqube.net.
2.50.168.192.in-addr.arpa. IN PTR dev.oqube.net.
EOF
cat >> /etc/bind/named.conf << EOF
// zone files for oqube.net. virtual network
zone "oqube.net" {
        type master;
        file "/etc/bind/db.oqube.net";
};


zone "50.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.50";
};
EOF

20080712: Haskell

2008.07.12 19:42:58

Tried using hpc. Works nicely and generates clean if somewhat unappealing coverage reports. Very simple to use, is integrated in ghc6.8.2.

Tried installing HaRE tool for Haskell Refactoring on Ubunte 7.10 with ghc 6.6.1. Two libraries are needed for proper compilation of the snapshot: 

#provide networking
sudo aptitude install libghc6-network-dev
# providing Control.Monad.State
sudo aptitude install libghc6-mtl-dev

Tried to use the tool on Controles.hs but failed to do anything:

Unit tests does not work either:

20080703: Sur les jeux de langage

Dans La Condition Post-moderne, (Minuit, 1980), J.-F. Lyotard analyse les deux discours de légitimation, deux nouveaux jeux de langage, qui se sont substitué aux anciens "grands récits", ceux qui autrefois, c'est-à-dire avant le 20° siècle, ont cherché à remplacer un autre grand récit, la religion par, au choix: la marche de l'Esprit dans l'Histoire, le progrès de` l'Humanité.

Le premier discours est, pour faire court, celui du système capitaliste et des états modernes qui lui sont subordonnés. Ce discours est basé sur la maximisation de la performance et l'atteinte d'objectifs, la seule modalité acceptable est celle de la performativité. Le seul critère de jugement devient alors l'efficacité et, dans sa version extrême, ce discours est celui des régimes totalitaires plus ou moins barbares qui ont jalonné le siècle. Mais c'est aussi celui des démocraties qui, au travers de la valorisation du consensus, de la banalisation de modèles de performances individuelles, parviennent à donner à ce discours la force de l'évidence.

Ce discours s'appuie sur une vision naïvement systémique et mécaniste du monde, du monde social en particulier, sur un substrat de langage scientifique hérité du positivisme qui n'est plus celui de la science en train de se faire. La question centrale devient: à quoi ça sert ? et non plus: est-ce juste ? ou même: est-ce vrai ?

Le discours scientifique s'est autrefois légitimé par la prouvabilité ou la réfutabilité, c'est-à-dire l'exigence 1) que tout énoncé puisse être prouvé, et 2) que cette preuve soit reproductible. Ce mode de légitimation suppose la formation d'émetteurs et de récepteurs d'énoncés scientifique, les derniers ayant vocation à rejoindre les premiers. Cette formation suppose à son tour une société capable de soutenir et encourager à son tour cet effort de formation, donc d'accroissement du discours scientifique.

Pour légitimer cette société, le discours scientifique sort de la catégorie des énoncés dénotatifs - les énoncés sur les choses du monde - pour entrer dans la catégorie des énoncés prescriptifs - ce qu'il est bon/juste/vrai faire - et performatifs les ordres, les plans et les actions. Il propose un récit normatif le positivisme, le progrès scientifique, la marche de l'humanité, les lumières de la civilisation - qui légitime un discours dans l'ordre du politique et du social - en gros, la suprématie occidentale, le colonialisme, l'impérialisme, la société bourgeoise. La société le lui rend bien qui valorise et légitime à son tour le discours scientifique, en particulier par le recyclage d'une vieille modalité du discours: le récit épique des héros de la science et de la raison (Galilée, Newton, Voltaire, Pasteur, Edison, Einstein...).

Quand le discours scientifique perd sa capacité à produire un récit normatif - plus personne ne croît sérieusement que la science apporte un progrès continu - et épique - il n'est que de voir la désaffection pour les études scientifiques et l'image déclassée du chercheur, il ne peut plus légitimer la société qui l'abrite. Celle-ci va donc chercher ailleurs, en elle-même, sa source de légitimité, en l'occurence dans la fuite en avant du discours performatif et la subordination de tous les énoncés au seul critére de leur performativité. Et en retour, elle va exiger de la science qui ne lui fournit plus de sens qu'elle s'aligne sur ce discours. C'est l'avénement de la technoscience, le triomphe de l'ingénieur et surtout du décideur qui incarne le plus pur véhicule de la performativité puisqu'il n'a pour seule et unique fonction que de décider donc de faire faire

On remarque que malgré tout, le décideur ne peut se passer d'autres modes de discours pour parfaire sa légitimation. Il investit le discours épique en devenant une figure de héros - non seulement au travers du personnage de l'entrepreneur - Gates, Ellison, Branson... ce qui n'est pas neuf puisque cette figure faisait déjà partie de la vulgate libérale des XIX et XX siècles, mais surtout au travers de celui du patron - Seillières, Parisot en France, Puech en Allemagne - et aussi du trader. Mais comme pour tout grand récit, cette légitimation tourne un peu court: à l'ère post-moderne, les héros ne sont plus unidimensionnels et voici Jérôme Kerviel en héros maudit.

La figure du décideur investit aussi le discours normatif et prescriptif - celui qui décide du Bon et du Vrai, de ce qu'il faut et ne faut pas faire ainsi bien sûr que le discours déontique - de ce qui est Juste. Est Bon, Vrai ou Juste ce qui contribue positivement à la performance, et il devient donc facile de classer, normer et évaluer les comportements et les discours sur cette échelle unique. A contrario, bien sûr, est Mal, Faux et Injuste ce qui contribue négativement à la performance. Comme avec le discours scientifique ancienne manière, une boucle de légitimation positive entre les catégories de discours subordonnées et la catégorie principale du discours performatif permet à chacune de trouver en l'autre une source externe de légitimité.

L'obsession performative est à son summum dans l'obsession de la mesure: mesures d'audiences, mesures de qualité infiniment variées, mesures de rentabilité, débit, productivité, planification du découpage du temps et de l'espace; dans celle de l'objectif, du but et de la motivation; aussi bien que dans le crédit démesuré apporté au concept de valeur qui est utilisé en proportion inverse de la précision de son contenu sémantique. Mesure, objectif, valeur construisent l'espace strié dans lequel chaque chose, être ou discours doit avoir ses coordonnées.

Dans le temps où le système se reconstruisait une légitimité par dessus le discours scientifique, celui-ci, tout du moins sa fraction la plus avancée et la moins soumise aux intérêts technocentrés mathématiques pures, physique théorique, sciences humaines abandonnait toute ambition de produire, maintenant et pour les siècles à venir, un discours dénotatif unique et univoque qui soit totalement et intégralement, si ce n'est dans les faits du moins dans ses principes, réfutable ou prouvable. A la place s'est constitué une nouvelle modalité du discours scientifique - à moins qu'elle n'ait toujours été là et ne se découvrît que tardivement - dans basée sur la fécondité et qui accepte comme fondation sémantique le langage naturel, avec toute son ambiguïté, ses idiotismes, ses zones d'ombres et ses floues.

La pouvrabilité ou la réfutabilité d'une idée n'est plus aussi primordiale. Elle reste une condition de base du discours scientifique, une sorte de substrat commun accepté par tous comme un horizon indépassable, mais cède le pas à ce nouveau critère: quels nouveaux jeux de langages me permet de produire une idée ? quels nouveaux coups avec les anciennes règles ? ou quelles nouvelles règles ?

L'informatique - la télématique comme l'appelle Lyotard - peut s'incarner dans les deux aspects:

20080613: Lenses

The concept of lens as bidirectional programs for transforming data.

20080514: Good design 

From: Ron Jeffries 
Subject: Re: [XP] Incremental design material (was YAGNI Football Analogy)
To: extremeprogramming@yahoogroups.com
Date: Sun, 11 May 2008 11:44:04 -0400
X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_MESSAGE,HTML_TINY_FONT 
	autolearn=no version=3.1.7-deb
X-Mailer: The Bat! (v4.0.24) Home
X-Sent: 2 days, 13 hours, 23 minutes, 17 seconds ago
Reply-To: extremeprogramming@yahoogroups.com


1.  (*) text/plain          ( ) text/html           


Hello, Kim.  On Sunday, May 11, 2008, at 9:56:23 AM, you wrote:


> I guess I'm looking for practical advice on how to design for
> evolution. I suppose /Refactoring/ has enough tips in it that it might
> fit the bill... I'll read it again and see how it feels.


I'd suggest two things:


First, going back to the classic issues of good design, high
cohesion and low coupling. Good design means changeable design, and
these characteristics, cohesion and coupling, delineate and measure
design quality, albeit subjectively.


Second, follow Beck's description of simple design. In priority
order, a design is simple to the extent that


  1. It runs all the tests,
  2. Contains no duplication,
  3. Expresses all the design ideas that are in there,
  4. Minimizes the number of entities such as classes and methods.


The Beck description is simple, but deep. As we follow these rules
more and better, the design becomes better. As the design becomes
better it becomes better able to evolve.


Ron Jeffries
www.XProgramming.com
Do I contradict myself? Very well then I contradict myself.
(I am large, I contain multitudes.) --Walt Whitman

20080513: Session Javascript PHP Days

20080417: Reconfiguration Eee PC

Création d'un disque encrypté sur le disque USB WD: 

cryptsetup luksOpen /dev/sdc1 data
echo "/dev/mapper/data /home/nono ext3 defaults,user 0 1" >> /etc/fstab
mount /home/nono

Ce disque contient:

20080320: XP Day France 2008

Problème

Itération 1:

20080318: Haskell again

There is considerable excitement about Haskell, functional programming and even category theory in SPA2008. This prompted me to revive an old project of mine, which is the implementation of an Haskell compiler in Java. I just got the code back and put it in somewhat good shape again: it compiles and most test passes with meaningful results.

I was thinking seriously about following the HaXE trail: developing a language and systemn based on functional paradigm, that would be compiled to mixed bunch of java/javascript/html files to produce applications.

20080309: Technical debt

Function/features of a software are its turnover: the value that is generated by the software. The net earning (ie. bénéfice) is the turnover minus all expenses that limit the functionality delivered by the software:

Function delivery is materialized by stories (along with story points) and accounted for in the burndown chart for the sprint and the backlog.

Code produced during the iteration goes to different accounts:

To balance assets one needs liabilities:

What about tests and tested code ?

Another interesting measure, churn, changes made to the software: 

Subject: [XP] SLOC and Churn as measures of technical debt
To: extremeprogramming@yahoogroups.com
Date: Tue, 11 Mar 2008 17:42:59 +1300 (NZDT)
X-Spam-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_50, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_MESSAGE,HTML_TINY_FONT  autolearn=no version=3.1.7-deb
X-Mailer: Pidgeon Post
X-Sent: 2 hours, 56 minutes, 2 seconds ago
Reply-To: extremeprogramming@yahoogroups.com


1.  (*) text/plain          ( ) text/html           


On Fri, 7 Mar 2008, Jim Shore wrote:


> Last night, as I was busily not sleeping here in Iceland, I had an
> epiphany:
>
> --> What if the best measure of technical debt is SLOC?
>


I've already posted the following to the refactoring list and I wasn't
going to crosspost it here, but it's too appropriate to what you are saying...


--Subject: Churn Metric-----------------------------------------------
Here's a simple one.


Say "cvs -q rlog -N MODULE_NAME/path/FileName | grep 'total revisions'"


And it tells you how many changes has been committed to that file.


Now do that for _every_ file in your system and sort by number of
revisions.


Ooh. Looky. Churn is _extremely_ unevenly distributed. (In the case I
discovered this on, the file was being changed once every 1.4 days for
the life of the project.)


In fact...


If you could wave a Magic Wand and stop all churn on say the top 4
most churned files... you would get a very significant boost in
productivity across the team.




In some cases, refactoring can be that Magic Wand.


----------------------------------------------------------------------

Why do I say it's appropriate to your post? Well, in the case above I
mention... the most churned file was indeed deeply "In Debt", _and_
also too long. (4500 raw lines / 2600 sloc (non-comment non-blank)








John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

20080304: Javascript Patterns

http://peter.michaux.ca/article/3556

20080301: Relational Arithmetic

To be able to infer any part of a (linear) arithmetic equation: http://okmij.org/ftp/Prolog/Arithm/DefinitionTree.hs

20080301: Functional Patterns

Comparing classical object-oriented patterns with functional patterns as found in scala or in Okasaki's book.

The question of typing is important, lot of tricks in Haskell (and Scala) rely on features provided by the type system.

20080301: Duck typing

http://en.wikipedia.org/wiki/Duck_typing

Seems like one important language is missing from the list: Javascript !

20080229: Teaching Maven

Having a hard time teaching maven today. There are a lot of hurdles for beginners:

20080228: Build as a service

20080222: Functional Testing evolution

There is a pattern emerging - or being noticed by me - on functional testing: annotating human-readable documents for automated consumption and creation of executable specifications. This pattern is embedded in various tools like:

2008.02.22 17:49:06

I started playing with web annotations which seems a good candidate for implementing easily that kind of stuff. Installed ShiftSpace which is a GreaseMonkey extension that allows one to share actions on web pages:

Fleck is another tool for annotating pages. Works as FFox extension, displays a toolbar on a page and annotations are positionned as little markers hovering on the page.

20080221: NeoVictorian

http://www.markbernstein.org/NeoVictorian.html

Still more fundamentally, the mass of guilt that weighs upon the field deadens our conferences. That guilt arises from the divergence of what we like from what we think we should like. We enjoy exciting new systems that do what nothing else could do; we think we should like systematic demonstrations that this widget lets students do a task 5% faster than that one. We enjoy daring prototypes and agile development; we think we should be planning our work and proving correctness. We enjoy astonishing code; we think we should write code so clear that our most mediocre students (and the management team) will grasp it without effort.

20080211: Muse and Doxia

I finally found the error that prevente proper parsing of muse files by maven site plugin: this was caused by an incorrect declaration of plexus.component in the site module class. The question is: How could such a silly error be prevented ? What kind of testing/verification could be done that would prevent creeping such bugs, depending on some framework and off-code declarations that are not detected at compile time. And not reported at run-time by the DI engine...

This is once more a tribute to static typing.

20080207: Bananas, lenses and Barbed wires

20080205: On QA and XP 

From: "John A. De Goes" 
Subject: Re: [XP] What about QA?
To: extremeprogramming@yahoogroups.com
Date: Thu, 31 Jan 2008 13:38:48 -0700
X-Spam-Status: No, score=3.8 required=5.0 tests=AWL,BAYES_50, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,HTML_MESSAGE,HTML_TINY_FONT  autolearn=no version=3.1.7-deb
X-Mailer: Apple Mail (2.915)
X-Sent: 4 days, 14 hours, 25 minutes, 14 seconds ago
Reply-To: extremeprogramming@yahoogroups.com


1.  (*) text/plain          ( ) text/html           




Seconded. Developers need to come to see QA as measuring the  
effectiveness of their development process, not as catching all the  
bugs they're 'too busy' or too lazy to find themselves. When QA finds  
a bug, developers need to understand this means their development  
process is broken and they need to improve it.


For their part, QA personnel should come to understand that their job  
is NOT to find bugs. Their job is to help improve the development  
process, by providing developers with rapid, accurate, and  
comprehensive feedback on just how efficiently that development  
process is performing. This means QA should become obsessed with (1)  
working with developers to produce a means of automating all tests,  
(2) making tests run in real-time on all supported platforms, (3)  
continuously expanding the coverage of automated tests, (4) increasing  
the robustness of tests to requirements changes, (5) increasing the  
speed with which tests can be changed to accommodate changing  
requirements, (6) increasing the specificity of tests, so that when a  
test fails, it's immediately obvious where to look for the problem,  
(7) constantly making sure developers understand that QA should not be  
finding any bugs, and doing whatever it takes to make that happen,  
including working with developers to improve their TDD skills or other  
skills relevant to the production of defect-free code.


I think in the ideal world, all QA personnel are developers and  
regularly rotate with the other developers (the reason this is not  
done, I suspect, is that it seems to cost more; why hire a developer  
at 90k when you can hire QA guy for 2/3rds of that).


Regards,


John A. De Goes
N-BRAIN, Inc.
http://www.n-brain.net

20080204: Sesssion XP Day Javascript

Intitulé: Javascript for anal retentive people

Résumé: Présenter le Javascript sous un jour différent, montrer comment on peut mettre en oeuvre les pratiques XP - TDD, remaniement, intégration continue - avec Javascript et comment tirer partie de la nature fonctionnelle du langage.

Détail: Javascript est avant tout considéré comme un langage de seconde zone, un langage de script, tout juste bon à bidouiller des pages web, encombré d'une sémantique extraordinairement floue et d'un nombre incalculable de versions et de plate-formes toutes incompatibles entre elles.

Mais Javascript, c'est aussi le coeur d'un projet aussi important par sa taille et son retentissement - que Mozilla, le premier langage de script officiel de Java 1.6, un nombre de plus en plus important de canevas - Script.aculo.us, ExtJS, Dojo, Rico - ayant permis l'essor du web 2.0... Il est donc probable que de plus en plus de développements, d'une manière ou d'une autre, se fasse en utilisant ce langage.

Parce qu'il n'y a aucune raison profonde pour que du code Javascript soit illisible et non testé, et qu'il est urgent de prévenir l'inflation de code non maîtrisé, cette session propose d'explorer Javascript en mettant l'accent:

  1. sur son caractère fonctionnel, ce qui permet de mieux structurer le code et d'élever le niveau d'abstraction manipulé;
  2. sur son intégration dans un processus de développement normal, avec tests unitaires, outil de build, tests fonctionnels et intégration continue.

La session se déroulera sous la forme d'un kata de développement sur un problème métier, accompagné des explications techniques et du détail de la mise en oeuvre d'un environnement de développement et de build adéquat.

Technique: les développements seront illustrés avec du code Javascript v1.8 sur plate-forme Mozilla, intégrés dans l'outil de build Maven et testés avec le canevas de tests unitaires JSunit et Selenium. Aucune connaissance préliminaire du langage n'est nécessaire, non plus que de la programmation fonctionnelle.

20080204: Session(s) XP Day Fonctionnel

Intitulé: Mon langage est plus gros que le tien

Résumé: Comparer la mise en oeuvre des principes de codage d'XP, sur un problème métier relativement complexe, entre le paradigme fonctionnel et le paradigme objet. Plus particulièrement, évaluer la pertinence du paradigme fonctionnel par rapport:

Détail: Le paradigme de la programmation fonctionnel - tout est fonction - est historiquement le plus ancien modèle de programmation. Il a connu son heure de gloire dans les années 60-70 avec la famille de langages Lisp et Scheme et les promesses de l'intelligence artificielle, au point que certains ont envisagé de construire des machines Lisp.

Après une longue éclipse, pendant laquelle ces langages, devenus les jouets favoris des universitaires et théoriciens, ont éclos en une multitude de dialectes, une nouvelle génération connaît un renouveau limité certes, mais perceptible - de popularité. Haskell, OCaml, Scala, Erlang: ces noms sont désormais connus au-delà des symposiums académiques.

Depuis longtemps fasciné par l'expressivité de ces langages, nous cherchons à comprendre comment articuler les pratiques XP TDD, Binômage, remaniement du code, itérations - et le paradigme fonctionnel; à identifier les points faibles et forts de ces langages par rapport au paradigme dominant - l'objet - dans le cadre de processus de développement agiles; à convaincre le plus grand nombre, enfin, de la pertinence de modifier nos modes de pensée dans le sens où ces langages nous y invitent.

Cette session pratique met en parallèle les deux paradigmes au travers du développement - dirigé par les tests - de deux solutions, fonctionnellement identiques (ie. répondant aux mêmes tests de recette). Nous proposons de dérouler la séance sous la forme de deux itérations successives, conclues par des rétrospectives et d'une synthèse globale. Le plan prévu - mais pas nécessairement imposé - est le suivant:

  1. première itération: définition des fonctionnalités, construction des tests de recette, développement. Les deux intervenants développeront chacun selon l'un des paradigmes et commenteront les différentes étapes du processus;
  2. rétrospective: premières conclusions, discussion avec la salle;
  3. seconde itération: ajout de nouvelles fonctionnalités. On cherche dans cette seconde itération à mettre en lumière comment les langages choisis supportent l'évolution tout en minimisant les changements à apporter au code;
  4. rétrospective et conclusion

L'accent sera mis sur l'identification de motifs de conception fonctionnels: fonctions d'ordre supérieur, types abstraits de données, pliage/dépliage de structures, monades...

Technique: l'utilisation d'un portable et la réalisation en parallèle des dévelopements est conseillée. Le langage fonctionnel choisi sera Haskell, et le langage objet Java.

20080124: Kata Lags

Voir la solution de Christophe Thibaut utilisant les graphes au Dojo Paris. On transforme la liste de demandes en un DAG et on parcourt le DAG afin de trouver le chemin de prix maximum. On aimerait que le graphe soit implicite dans le flot de contrôle des appels de méthodes:

20080113: Projet de session XP Day

Pour avancer un peu, quelques idées ou pistes pour développer un session XP Day.

Idée principale

XP et les langages fonctionnels (fortement typés ?):

  1. comment le langage de programmation influe sur les pratiques XP (les plus proches du code: Binômage, Test en premier, Intégration Continue, Conception incrémentale), en particulier comment évoluent ces pratiques avec un langage:
    • plus abstrait (vs. plus proche de la machine, impératif)
    • plus formel (vs. à la sémantique plus floue
    • fortement typé (vs. typé dynamiquement)
    • compilé (vs. interprété)
  2. quel est l'intérêt d'adopter une approche fonctionnelle des problèmes dans le cadre des méthodes agiles: aller plus vite, raccourcir les cycles, coder moins... Y compris avec des langages non intrinséquement fonctionnels: Java, C, ...

Thème

Le problème d'expression (Expression problem en anglais, cf. Philip Wadler): comment permettre, dans un langage (ou plus généralement un système informatique), de faire évoluer la structure des données traitées indépendamment des traitements sur ces données.

Un système doit être extensible tout en respectant les propriétés suivantes:

  1. orthogonalité: les données et le code évoluent indépendamment
  2. statiquement sûr: une extension ne doit pas provoquer d'erreurs à l'exécution (non existante auparavan)
  3. modulaire
  4. échellable

D'autres propriétés intéressantes sont:

  1. l'extensibilité non disruptives: les clients existant du système ne doivent pas être perturbées par son extension
  2. la composabilité des extensions

Qu'est ce que cela a à voir avec XP ? Tout, parce qu'un système/langage possédant ces propriétés supporte plus facilement une conception et une réalisation incrémentale, des cycles courts, un minimum de refactoring: on peut faire évoluer indépendamment différents parties du système sans risque de (trop) casser les dépendances, les tests continuent à passer (et sont eux-mêmes extensibles).

Qu'est-ce-que cela a à voir avec la programmation fonctionnelle ? Il n'existe pas actuellement de solution parfaite à ce problème, quel que soit le langage:

Il pourrait être intéressant de comparer ce que les langages fonctionnels, objets et dynamiques ont a à dire sur la question, sur une étude de cas concrète.

L'exemple de Composing Contracts pourrait servir de base: construire un système (simple) d'évaluation d'actifs financiers dans différents langages, et l'étendre en plusieurs étapes.

20080111: KataChop, the scala way

Not being convinced by the KataChop Dojo of december, I tried my own KataChop, based on Scala programming language. The objective is to be able to prove that we are indeed searching in `log(n)`. In the original KataChop, the approach is to derive a loop invariant through TDD: using small programming steps, we install the loop invariant that state we are searching a half-sized list each iteration.

In this variation, I tried to state the property holds without resorting to assertions within the code. The idea of this exercise is to state explicitly the expected property such that we can be convinced that it holds without inspecting the code, ie. through blackbox testing only. To be able to do that, I did the following:

  1. use the wonderful ScalaCheck tool to express the property I expect from my dichotomic search. This property is (not really simply expressed as): 
          val prop = Prop.forAll(sortedIntList)((l : List[Int]) => 
	property((tgt : Int) => 
	    fixpoint(Dicho(l), tgt).length <= (log2(l.length) + 1)))
  2. Reify the list-splitting operation in an object that represent some list to search, the Dicho object, that defines a search: Int > Dicho. The fixpoint= function then lookup the fix point of this methods invocation and returns the stream of Dicho objects used
  3. express test cases withing Specs BDD framework, another wonderful piece of code that offers support to Scalacheck property checks.

Some conclusions I can draw are:

  1. scalacheck's generators are not really obvious to use, although the documentation is quite good
  2. I wrote less test: the TDD steps are embodied in the progressive adjustement I made to make the scalacheck property passs
  3. The property trivially passed with the fakes I initially provided: This may means that I need to think of better fakes when using scalacheck assertions on my code
  4. the code may be rather contrived, as I did define my own fixpoint. However, given some language/library support, the code is much smaller: only have to express the single step dichotomic search and iterate over it
  5. the Dicho class should store the index from the original array to be somewhat useful. More generally, the code is woefully inefficient: the underlying collection could be shared between all dicho objects and only indices passed around
  6. it has a nice functional/object feeling

20071217: Of TDD, algorithms and Code coverage

This evening at the Dojo, we have had a session on Kata Chop: implementing dichotomic search, and proving it.

20071215: Asynchronous builder and scala

Lift has support for interacting with RabbitMQ which is a highly scalable asynchronous messaging queue system written in Erlang. This gives me the idea of rewriting the embryonic Builder system in scala, with asynchronous communication based on RabbitMQ. The idea is to build software development monitoring nodes that would monitor data gathered at some software development spot and produce some analysis and feedback:

Nodes could be placed at various points in the development network: developer's station, standalone server with notification from SCM, centralized CI system ...

20071019: SFINCS and information policy

A framework for defining privacy policies: http://www.nyu.edu/projects/nissenbaum/papers/ci.pdf

20070930: Parsers for maven shell

For definition of a more human-friendly language interface to maven, I am looking at various parser generators implementation:

20070914: Maven PM (cont)

Try running StatSVN on repo. 

$> wget
http://switch.dl.sourceforge.net/sourceforge/statsvn/statsvn-0.3.1.zip
$> unzip statsvn-0.3.1.zip
$> cd maven-src
$> svn log --xml -v > svn.log
$> cd ..
$> java -jar statsvn.jar maven-src/svn.log maven-src

Takes way too long as it extract line counts from revisions, will do some text manipulation instead from the log in text format.

20070914: Idée de stage

Construire une implémentation de patch/diff en Java pur compatible avec différents formats de Patch.

20070912: Idées pour un Dojo

20070907: Notes on Project Management for Maven

Issue resolution time for maven2:

Year Nb Issues MRT
2004 32 44
2005 891 35
2006 335 93
2007 392 266

Average age:

Year Avg. Age
2004 41
2005 227
2006 171
2007 107

20070906: Functional testing

As it names implies, functional testing is all about relating two functions:

As we know from the universality of Turing machines and most other computing languages, this is not merely an abstraction: any piece of software can be interpreted in term of some function relating inputs to outputs. Or equivalently, any piece of code in any language can be translated into some pure functional language (ie. Haskell).

Those functions are usually partial and may diverge

We can easily transform any partial specification into a complete specification by extending it such that it relates the subobject of its domain where it is undefined to `\bot`. So we have `s: A\rightarrow (B \cup \bot)` as the complete type for `s`.

For any function `f:A \rightarrow B`, we can extend f's domain to `A\cup \bot` by defining `f\bot = \bot`.

Testing needs the definition of some functor `T` that sends objects to finite sets so that functions are defined on finite sets and can thus be enumerated. It also needs the definition of some oracle object `\Omega` that is used to construct the natural transformation (?) assessing the equality of the two functions (specification and implementation).

20070903: Functional abstraction for API changes

In classical version numbering schemes where each software release is numbered X.Y.Z.T, the various numbers usually have the following meanings:

A change in major version number usually implies some form of incompatibility. If software is a program or some form of library that manipulates persistent data, then file formats, database schemas, exchange protocols are not supposed to be compatible. Lower version programs are not expected to be able to read/manipulate the data produced by a higher version program. The converse may also be true in which case this breaks upward compatibility. This latter property is most often what end-users expect so this is usually not a good idea to break it, and if required to do so, it is best to provide some tools for data conversion,

If software is a library, major version increase denotes a change in Application Programming Interface which implies that clients of the library will not work or will produce odd behaviors with the newest version of the library.

A increase in minor version usually implies addition of some feature to the software without modification to existing features' behavior. Upward compatibility preservation is a mandatory property of minor version releases.

A increase in patch level denotes bug fixes changes: existing features' behaviors is corrected to meet requirements. The distinction between a bug and a feature is then based on functionality:

Anyway, clients of the software that uses it as expected should not be negatively affected by changes in minor version or patch level.

We can model this versionning scheme using functional abstraction. Let `f:A \rightarrow B` be a partial function, with domain `A` and range `B`, representing the specification. At any point in time, the developed software `s` is a partial function with domain `C` and range `D` such that there are some inclusion functions `i:C \rightarrow A` and `j:D \rightarrow B` with `f . i = j . s`.

Two versions differing only in minor number are then two functions `s_1:C_1\righarrow D_1` and `s_2:C_2\rightarrow D_2` s.t. `i_1 = i_2 . k`, for some `k`: the domain inclusion map for first version can be factored through the second version's inclusion map. Or equivalently, the domain of `s_2` contains the domain of `s_1` and `s_2` conincides on `s_1` on those elements that are in `C_1`.

Two versions differing in major versions are derived from different specifications `f` and `g` which need not be related.

20070808: How to invoke scala compiler programatically

From the scala mailing list. 

        // We currently call the compiler directly
        // To reduce coupling, we could instead use ant and the scalac
ant task




        import scala.tools.nsc.{Global, Settings}
        import scala.tools.nsc.reporters.ConsoleReporter


        {
            // called in the event of a compilation error
            def error(message: String): Nothing = ...


            val settings = new Settings(error)
            settings.outdir.value = classesDir.getPath
            settings.deprecation.value = true // enable detailed
deprecation warnings
            settings.unchecked.value = true // enable detailed
unchecked warnings


            val reporter = new ConsoleReporter(settings)


            val compiler = new Global(settings, reporter)
            (new compiler.Run).compile(filenames)


            reporter.printSummary
            if (reporter.hasErrors || reporter.WARNING.count > 0)
            {
                ...
            }
        }




        val mainMethod: Method =
        {
            val urls = Array[URL]( classesDir.toURL )


            val loader = new URLClassLoader(urls)


            try
            {
                val clazz: Class = loader.loadClass(...)


                val method: Method = clazz.getMethod("main",
Array[Class]( classOf[Array[String]] ))
                if (Modifier.isStatic(method.getModifiers))
                {
                    method
                }
                else
                {
                    ...
                }
            }
            catch
            {
                case cnf: ClassNotFoundException => ...
                case nsm: NoSuchMethodException => ...
            }
        }


        mainMethod.invoke(null, Array[Object]( args ))

20070804: Versionning MQ 

Giorgos Keramidas  writes:
> It may be useful to note here that MQ can 'version' the patch sets, and
> 'qcommit' can be used to keep a change log of the patch queue itself.
>
> You can convert the patch queue to a 'patch repository' with:
>
>         hg qinit -c
>
> Then the .hg/patches/ directory is a Mercurial repository too, and you
> can alternate between:
>
>         hg qrefresh -e
>         hg qcommit
>
> This will let you keep your patch queue versioned too, and you will be
> able to track the changes to your patches as they evolve over time.
>
> I often use MQ to keep a stack of patches on top of a snapshot of the
> 'official' source tree at work, and using 'qinit -c' with 'qcommit' lets
> me develop the patches themselves in small steps.  This is very useful
> some times, i.e. when I qrefresh at the wrong moment it's marvellously
> easy to roll back bogus patch changes by popping the stack of patches
> and running:
>
>         hg qpop -a
> 	( cd .hg/patches ; rm -f * ; hg up -C )
> 	hg qpush -a
>
> This restores the patch queue to a 'known good state', the state of the
> last 'hg qcommit' operation, and I can keep massaging the patches until
> they have the precise shape and contents I want them to have.
>
> Maybe something like this, based on 'qinit -c' and 'qcommit' can help
> you track the state of your patches too :-)

20070803: Using patches

While working on a Maven course, creating various maven projects for testing purpose, I started to use Mercurial Queues for storing versions information. The basic use case is: 

# create mercurial repo
hg init
hg add  ...
hg commit ...
# create MQ 
hg qinit
# start working on a patch
hg qnew some-feature.patch
# periodically refresh your patch with changes
# option --git allows tracking of copies
# option -e allows editing of message
hg add ...
hg mv ...
hg rm ...
hg qrefresh --git -e
# then push some new patch when you're done
hg qnew

One can then plays with patch stacks: 

# go back 
hg qpop
# go forward
hg qpush

The main advantage I see with this scheme is that it helps me getting focused on one feature at a time: No more commits containing tons of unrelated changes. Of course, it is possible to have some discipline with standard commits and to mess up a MQ repository, but I personnally find helpful that I am requested to give some title to my piece of work, and to group things intelligently.

20070803: RDF again

I dropped the idea of doing diffs directly with objects: too complicated, lot of corner cases if we take into account objects in all their generality. I did manage however to hack sommer to convert a standard bean into a RDF graph:

This is crude but it works as a basic POC and could form the basis for the RDF-maven API I dream of, with some improvements:

Bought Semantic Web PrimerG.Antoniou and F.van Harmelen, The MIT Press, 2004

20070731: Exercise idea

  1. get some raw sources from a SVN repository
  2. create a maven project from them: this implies setting up POM, splitting sources along standard layout (take care of tests), eventually creating modules if there seems to be a need.

20070731: Object diffs and Maven20

While working on new Maven2 course, I started over a project for generic gathering of data in maven build process. This project has two goals:

  1. start something useful on the ideas I expressed sometimes that we should have a uniform way to collect data in Maven and make it persistent,
  2. illustrate most common and uncommon things we do with maven and its ecosystem.

The projects structure shall be the following:

Module Features Pedagogic goal
core library Implements object graph manipulations, diffs and decorations Illustrate basic maven process: creation of project, standard lifecycle (ie. releases, scm handling, POM features, basic reports)
maven graph api Based on core, used to annotate Maven POM with build information. Needs to handle build events and POM strcuture, as well as exploration of standard properties and default structure of a project Maven internals, basic multi-modules dependencies
maven graph mojos Plugin for instrumenting maven builds and offering the ability for other plugins to hook in data on the build Illustrate Maven plugins development, writing Mojos, testing plugins and maven test harness, integration testing
maven graph persistence Persistence module, based on Hibernate/Derby/PostrgreSql for storing/retrieving a graph structure DB, code generation and Hibernate modules
build events WS Web service (JBoss, sar) offering remote access to graph data structure Illustrate J2EE artifacts handling, profiles (for testing/deployment/production parameters)
reporting Web Application Web application (JBoss, Jetty) providing on demand graphs, reports and tables about the object graph structure Illustrate webapp construction, builtin jetty run plugin for inplace testing, web app deployment with cargo ?

Computing diff of 2 objects

We want to compare two objects o1 and o2 of the same type and compute the difference in values of the graph rooted at o1 and o2. Basic algorithm needs to run BF traversal in parallel for the two objects. At each step, we have 2 properties name/class/value triples t1 and t2 within a context. Several cases may arise:

  1. the two properties are identical, which means that either they are primitive types and they are equal, or they are objects and they are identical (strings and wrapper types are considered as primitive). Then recursion stops (even for objects, we do not push this objects properties as they will obviously be identical...)
  2. the two properties are not identical:
    1. if they are primitives (or wrapper), a delta is emitted,
    2. if they are objects of different runtime types, a delta is emitted and no recursive processing occurs
    3. if they are objects of the same runtime type, then:
      1. if a mapping has been recorded for o1's property, and o2's property is consistent with this mapping, no delta is emitted,
      2. if a mapping exists but it is inconsistent, a delta is emitted
      3. if no mapping exists, a mapping is recorded, properties are pushed and exploration continues.

Information storage

Build information about a project could be stored with the POM/artifact in the repository like anything else. Then it would be retrieved at start of build, updated, and put back through install/deploy goals.

20070729: Test, test, test !

I spent quite a few hours this week-end debugging OpenJgraph, or more precisely the DigraphLayeredLayout which layout graphs in layers following Sugiyama's algorithm. I was reviving a tool I wrote couple of years ago for analyzing Struts configuration files and the actions graph consistently blew up the layout algorithms.

I then started debugging, adding unit tests along way to check behavior of various algorithms and methods in the package: graph traversal, connected set management, layout positionning, directed acyclic graph handling of edges... It turns out that the culprit was a tiny method called getOppositeVertex() in class EdgeImpl which used = instead of equals()= to compare its vertices ! Then identical strings constructed at different times would be considered different vertices and incident edges would not consider them opposite because of difference in identity.

Once again, I am bitten by the lack of through unit tests that would check consistent behavior and express it more precisely.

20070729: Update Git confiug

Following mail from Junio Hamano, I updated my git config to handle synchronization between desktop and laptop: 

From: Junio C Hamano 
Subject: Re: Newbie problem
To: Insitu 
Cc: git@vger.kernel.org
Date: Sat, 28 Jul 2007 01:01:49 -0700


Insitu  writes:


> Now, I want to be able to do:
> lap> git push
> or
> lap> git pull
>
> instead of 
> lap> git push ssh://pc/~/.git
>
> I think I need to reconfigure my remote branches/origin on laptop but
> don't want ot break everything.


The necessary syntax and configuration files are all documented
fairly detailed in the manual pages, but it is a tad hard to
know where to look:


    http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
    http://www.kernel.org/pub/software/scm/git/docs/git-push.html
    http://www.kernel.org/pub/software/scm/git/docs/git-config.html


If you use recent enough git (post 1.5.0), the recommended way
to keep two boxes in sync is:


On mothership box, in .git/config:


 [remote "origin"]
     url = satellite:.git/
     fetch = +refs/heads/*:refs/remotes/origin/*
     push = refs/heads/*:refs/remotes/origin/*
 [branch "master"]
     remote = origin
     merge = refs/heads/master


On satellite laptop, in .git/config:


 [remote "origin"]
     url = mothership:.git/
     fetch = +refs/heads/*:refs/remotes/origin/*
     push = refs/heads/*:refs/remotes/origin/*
 [branch "master"]
     remote = origin
     merge = refs/heads/master


Then, whenever you start working on the satellite:


	$ git pull


which, while you are on "master" branch, would use 'origin' as
the default remote (thanks to branch.master.remote configuration),
store the copy of mothership's branches in refs/remotes/origin/,
and merges the "master" branch obtained from the mothership to
your "master" branch on the satellite [*1*].  


When you are done working on the satellite:


	$ git push


will push to "origin" by default, which would push all your
branches (thanks to remote.origin.push configuration) to
mothership's refs/remotes/origin/.


When you go back to the mothership, your work done on the
satellite are already pushed into the refs/remote/origin/
tracking branches, so you can merge them in (you can do this
after shutting down your satellite laptop, which is the beauty
of this setup):


	$ git merge origin/master


to merge in the changes you did on the satellite.




[Footnote]


*1* If you prefer to keep a straight history, you may want to
    fetch+rebase instead of pull which is a fetch+merge, in
    which case this step will be:


	$ git fetch
        $ git rebase origin/master

20070720: Clever data structures 

From: Dan Weston                          
Subject: Re: [Haskell-cafe] Hints for Euler Problem 11              
To: Ronald Guida                           
Cc: haskell-cafe@haskell.org                                        
Date: Thu, 19 Jul 2007 20:54:40 -0700                               


[1. text/plain]                                                     


Here's my hint, FWIW.                                               


Pick a data structure that makes your life easier, i.e. where horz, 
vert, and diag lines are handled the same way. Instead of a 2D      
structure, use a 1D structure.                                      


Then,                                                              

previous
data Dir = Horz | Vert | LL | LR


stride Horz = 1                 
stride Vert = rowLength         
stride LL   = rowLength - 1     
stride LR   = rowLength + 1     


nextItem dir = drop (stride dir)

20070717: Assertions and contracts

While reading (again) assertions usage in Java, it occured to me that the ban of assertion use for preconditions checking of public methods in DBC setting was due to the possibility that assertions be disabled at runtime. The specific example given is: 

previous
    /**
     * Sets the refresh rate.
     *
     * @param  rate refresh rate, in frames per second.
     * @throws IllegalArgumentException if rate <= 0 or
     *          rate > MAX_REFRESH_RATE.
     */
     public void setRefreshRate(int rate) {
         // Enforce specified precondition in public method
         if (rate <= 0 || rate > MAX_REFRESH_RATE)
             throw new IllegalArgumentException("Illegal rate: " +
         rate);


         setRefreshInterval(1000/rate);
     } 

Here, the parameter is checked to enforce contract, in the absence of constrained types (something that made the strength of Ada). To me, this is typical of Defensive programming: the program is guarded against mistakes made by its caller, something that is different from contract-based programming.

The idea of contract-based programming is to share the burden of trust. A contract binds the two parties in a relationship that says:

  1. If caller respects its share of the contract, ie. calls some function or object in the right way or with the right set of parameters, then
  2. Callee will return some sensible (and predictible) value, or let the world in some well-known state.

This is a logical implication `A \rightarrow B`, a statement that has the property of being always true if A is false. Recall truth-table:

A B `A\rightarrow B`
T T T
T F F
F T T
T T T

Thus if 1) is not respected by the client, then B can do whatever it please, it is no more bound to respect its share of the contract.

In contract-based programming, verification of input parameters for contract enforcement is then not mandatory as it is the responsibility of the client to ensure that its inputs are correct, if it expects a meaningful answer. One can thus rewrite the preceding example as: 

previous
    /**
     * Sets the refresh rate.
     *
     * @param  rate refresh rate, in frames per second. Should be <= 0 or
     *         > MAX_REFRESH_RATE.
     */
     public void setRefreshRate(int rate) {
        assert rate <= 0 || rate > MAX_REFRESH_RATE :"Illegal rate: " + rate;
        setRefreshInterval(1000/rate);
     } 

The advantages of this formulation are:

  1. it can be made more efficient at runtime by disabling assertions verification,
  2. it gives the same amount of information to the client, making clear what its share of the contract is,
  3. it can be checked selectively by enabling assertions, for example during integration testing phase,
  4. it does not prevent defensive programming if needed: just enable assertions.

20070714: Some new books

Bought some books recently on various topics. In no particular order:

Thanks to Raphaël Marvie, I have also read Agile Software Development. Principles, Patterns and PracticesRobert Martin, Prentice-Hall, 2003.

20070714: Utopie

"[...]Et beaucoup en viennent à croire que ses nombreux échecs prouvent que l'éducation demeure une tâche coûteuse, d'une complexité incompréhensible, que c'est une alchimie mystérieuse - la recherche, pourquoi pas, de la pierre philosophale !" Ivan Illich, Une société sans école, in Oeuvres complètes, Vol.I, Fayard 2003

20070714: De la rigueur de la science

C'est tout à fait par hasard, dans l'épilogue de La vie rêvée des maths, de D.Berlinski, que j'ai retrouvé l'origine de la citation de J.L.Borgès sur la carte à l'échelle 1 pour 1. Il s'agit d'un très court texte d'un paragraph, écrit avec Bioy Casarès sous pseudonyme et paru dans l'édition espagnole de 1954 de l'Histoire universelle de l'infamie. Le texte n'avait pas été repris dans la première édition (1974) des Oeuvres complètes en français dans la Pléiade mais est adjoint au corpus de notes. La référence exacte (en français) est donc:

De la rigueur de la science, p.1509 in José Luis Borgès, Oeuvres complètes, Vol.I, Bibliothèque de la Pléiade, Gallimard, Paris, 1993

Je reproduis ici l'intégralité du texte:

"...En cet Empire, l'Art de la Cartographie fut poussé à une telle Perfection que la Carte d'une seule Province occupait toute une Ville et la Carte de l'Empire toute une Province. Avec le temps, ces Cartes Démesurées cessèrent de donner satisfaction et les Collèges de Cartographes levèrent une Carte de l'Empire, qui avait le Format de l'Empire et qui coïncidait avec lui point par point. Moins passionnées pour l'Etude de la Cartographie, les Générations Suivantes réfléchirent que cette Carte Dilatée était inutile et, non sans impiété, elles l'abandonnèrent à l'Inclémence du Soleil et des Hivers. Dans les Déserts de l'Ouest subsistent des Ruines très abîmées de la Carte. Des Animaux et des Mendiants les habitent. Dans tout le Pays, il n'y a plus d'autre trace des Disciplines Géographiques."

(Suarèz Miranda, Viajes de varones prudentes, livre IV, chap. XIV, Lérida, 1658)

20070712: Live CD for Building software

Goal: Creating a Live CD/Linux distribution for building/CI of Java/native software. The distribution should contain all the necessary/useful things for serving a community of developers for Java software based on maven2:

The distribution is preconfigured so that it boots with all the necessary services built and running. One can start using the distro immediately for accessing svn repo, issue tracking, configuring CI and the like.

Possible implementations: 

$> dd if=/dev/zero of=~/myFileSystem.img bs=1024 count=650000

20070706: Irreducibility of Languages

W.Heisenberg's book, Ordnung der Wirklichkeit (Le manuscrit de 1942, Alia in french) introduced the notion of layers of reality:

This classification represents a process by which subject becomes closer and closer to object. It can be lifted to languages in a way different from classical Chomsky's hierarchy. The latter deals with layers of complexity: from simpler languages (eg. regular languages) to more complex languages (eg. natural languages). Another classification is in the representability relationship existing between languages.

There is need for different views of problems, hence different languages, each irreducible into one another (eg. no grand narrative, no common semantics).

20070705: Agile Questions

From the XP mailing list:

1) What is the affect of doing software design on an iterative and evolutionary basis, rather than doing design up-front?

2) How does being part of a "whole team" allow team members to handle external responsibilities? In particular, how can a "customer" or "product owner" be part of a whole team, if they are alone are responsible for business success? Also, how do traditonal management roles work in the "whole team" environment?

3) How can agile development work with user interaction design and usability evaluation?

4) What is the affect of pair-programming? In particular, how does it affect productivity and communication?

5) How reliant is agile development on co-location of team members, and what can be done to accommodate distance between members?

6) How does test-driven development support agile development? Can all requirements be expressed as tests? How can tests be augmented, deleted, or changed over time?

7) How does agile development accommodate various business contexts? For example: in-house development, outsourced development, consumer product development, ...?

8) How does agile development change over time, after developers and customers have gained experience, and practices have become accommodated into routine?

9) Is agile development, or some practices, suited more to some application domains than others? For example: business IT, embedded systems, e-commerce, ...?

10) How does agile development work with established software infrastructure? For example, legacy systems, established libraries, frameworks, ...?

11) How does agile development work with established management structures? What areas of resistance do agile teams encounter and how are those areas addressed? Is agile development compatible with management needs? How does agile development tackle change management amongst it's stakeholders?

20070704: The Compilation Continuum

There is a continuum of transformations from source code to runtime software:

It should be possible for the developer to chose the point of computation for some feature: compile-time, deployment time, linking time, runtime, with the same syntax.

In C++ template style: 

previous
public int pow(int n, int e) {
    if( e == 1 )
      return n;
    if(e == 0)
      return 1;
    return n * pow(n, e-1);
}


public int doSthing(int n) {
   int k = pow(n,4);
   ...
}

could expand to: 

previous
public int doSthing(int n) {
   int k = n * n * n * n;
   ...
}

In macro style, we could have: 

previous


   List<String> names = ....
   names = names.map(new Function<String,String>() {
      public String apply(String s) {
         return s.toUpper();
      }
   }

could expand to: 

previous
   List<String> names = ....
   List<String> names_ = new ArrayList<String>();
   for(Iterator<String> i = names.iterator();i.hasNext();) 
       names_.add(i.next().toUpper());
   names = names_

or could be handled by the library containing map().

A feature/behavior could be provided at various stages in this process.

20070628: What is software ?

20070618: Coding with automata

Problem:

Hypothesis and Rationale :

Solution:

Application:

Future works:

20070524: On coverage

http://blog.objectmentor.com/articles/2007/05/16/100-code-coverage

20070521: On Verification

Recently read an article from R.DeMillo, R.Lipton and A.Perlis about program verification, Social Processes and Proofs of Theorems and Programs. They criticize the totalitarian view of program verification zealots, studying the process of proof and the way mathematicians make progress, and showing that the naive equation programs=theorems and verification=proof is flawed as it does not represents truthfully the real nature of both mathematics and programming.

Both are social activities, proofs and programs being complex things that are meant to express something, to convey some idea and to entail some belief from the part of the reader. Both are meant therefore to be read by human being, the latter being also aimed at formal processing by a machine. Formalization is a theoretical possibility that should be left for the gods.

Verification does not work, and never will: They are intractable except for trivial programs, and they do not take into account the real "life" of programs. Real-world programs changes, have inconsistent or incomplete requirements, need finite resources to complete...

From http://lambda-the-ultimate.org/node/2216#comment-32646

20070519: Notes for integrating Muse and Fit

To execute Fit tests from Muse pages, it should be sufficient to subclass Parse object such that base wiki syntax is parsed instead of HTML syntax. This necessitates some refactoring of Fit code to allow pluging-in of parser, or could by done simply by subclassing FileRunner.process() method.

A simpler method would be to subclass Fitlibrary's fitlibrary.runner.CustomRunner which provides a hook method makeTables() to produce tables in a Parse object. To run tests implies then to:

  1. parse the Muse files in test mode
  2. for each test file, start execution of a CustomRunner subclass
  3. override makeTables() to retrieve Muse tables

20070518: Web application development sucks (contd.)

While preparing some training material about Inversion of Control pattern and its implementation in Spring, I attempted to implement as quickly as possible an application simulating an electronic cash dispenser. I first decided to write a Web application, using the cool Wicket framework I recently discovered at ApacheCon. But although I have attended the tutorial (about 450 bucks...), I was unable to produce some workable application in a reasonable amount of time.

I reverted to write a basic CLI client, based on some state-transition pattern, something I understand quite well. I must have some disability that prevents me to fully understand how to write quickly and efficiently web application, something that has to do with the fragmentary nature of such applications and the numerous technologies you have to master (or at least gather) to start something.

While surfing I came upon HOP, a Scheme-based language for developing web application, that embeds both client-side and server-side components in a single framework. As far as I can tell, this is something like this I really miss in the Java world.

20070508: On humility (or the lack thereof)

I just read this post from the blog of Jonathan Locke, initiator of the Wicket Web Framework. Whether or not the thesis is true (that software industry and big business in general does not have the ability to produce outstanding tools for lack of global optimization incentives), it always seem odd to me when someone writes such immodest things. I just don't know if this is some special sense of humor or just plain hybris.

20070508: Web application development sucks

During its talk at ApacheConEu, Matt Raible asked the audience what framework they were using. He then polled the attendees according to their preference and asked them whether their particular framework "sucked". The answer happened to be yes most of the time.

My opinion is more generally that web application development itself plain sucks. We still have to produce adequate tools to make this anything but a painful experience and I think that the right tool is not a framework but a language.

20070507: ApacheCon

I have setup a page collecting notes about the ApacheCon conference I attended last week.

20070414: Notes on post-modernism and its relationship to programming

Following the Notes on Postmodern Programming, J.Nobble and R.Biddle, OOPSLA'02, I started writing an article about what I understand of post-modernism and how this applies to programming.

20070329: BDD and Contracts

Behaviour Driven Development uses test cases as executable assets for asserting correctness of code with respect to expected behaviours. Developer writes test cases that describe expected behaviour of developed objets or group of related objects (Domain, related to Domain Driven Design). Test cases generally rely on the mock object's technique:

This technique is lifted at a higher abstraction level with stories and scenarios that represent user acceptance tests or high-level behavioural tests. A story is described by a (role, feature, benefit) triple and implemented by a sequence of scenarios. A scenario is a set of:

It is then obvious that a scenario is also an particular instance of some contract that should be met by the CUT:

Given a set of scenarios on some object, we could reconstruct a specification by inferring some general property from the detailed contracts given as test case. These general properties may take the form of types or logical predicates on the state of the world, yielding some Kripke structure: states of world as set of assignments (pairs key-values) and transitions as events. This more abstract representation could be used to check some properties on the inferred specification: eg. consistency and completeness.

20070306: Inductive Graphs in Java

I tried to implement basic elements of inductive graphs in Java as defined by Martin Erwig in its article describing FGL, a Functional Graph Library for Haskell and ML. The notion of inductive graphs may be interesting for defining/traversing graphs incrementally or constructing some comparison function such as a diff between graphs, assuming some canonical order can be found on the ordering of elements.

Implementation is straightforward and quite simple using generics. I use a simple numbering trick to mark nodes during iteration over contexts such that visited edges do not appear twice during visit of a graph using contexts: Iterator marks each node returned and compare marks before adding an edge to a returned context. This ensure that iteration's time complexity is linear in the number of edges of the graph.

I used a TreeMap for storing nodes, ensuring natural iteration over contexts is done using natural ordering of the nodes' type.

Some hints on diff (on same type graphs). We construct 3 lists of contexts showing diffs between left (L) and right (R) graph:

The algorithm may be:

Are there some interesting properties this diff exhibits ? Is it the minimal transformation from one graph to the other ? Is it easier to compute than with standard graph representations ? Than with matrix representation ? What about generalized graph xformation like DPO ?

20070226: Supporting remote coverage

  1. create an artifact from patchwork with instrumented classes
  2. create a module that listen on a network for coverage information
  3. use these artifact in an integration test (e.g. with cargo or other plugin) that also starts coverage reporter

20070223: Muse and FIT

Following an idea from Brian Marick's blog and what is done in FitNesse, it occured to me that Muse may be easily extended with some syntax for generating Fit/FitNesse tests that would be more free-form than tables. This could be done through adding a specialized parser recognizing special tags or combinations, or natural languages fragments.

20070216: Two new books

Being in Paris Thursday, I went to Le Monde en tique, a bookshop dedicated to computer books. Being a compulsive reader and book buyer, I had a hard time choosing among the many interesting books that were available there. I finally choose two "classical" books:

20070214: Extreme Hour lesson

I ran on Monday an Extreme Hour game with my students from the GLSI "Licence Professionnelle" at Lille I. I wrote a short account on this experiment, together with some pictures I shot during the game.

20070213: Understanding Microformats

Microformats are a simple way to add semantics to XHTML/XML (-like) content. In XHTML, a microformat basically define some standard grammar implemented as tag and class names couples that can easily be embedded in any XHTML/XML compliant content: It is in some sense a standardized CSS. One example from hReview microformat, one that normalizes writing reviews:

This review of some restaurant: 

previous
<div>
 <span>5 stars out of 5 stars</span>
 <h4>Crepes on Cole is awesome</h4>
 <span>Reviewer: <span>Tantek</span> - April 18, 2005</span>
 <blockquote><p>
  Crepes on Cole is one of the best little creperies in San Francisco. 
  Excellent food and service. Plenty of tables in a variety of sizes 
  for parties large and small.  Window seating makes for excellent 
  people watching to/from the N-Judah which stops right outside.  
  I've had many fun social gatherings here, as well as gotten 
  plenty of work done thanks to neighborhood WiFi.
 </p></blockquote>
 <p>Visit date: <span>April 2005</span></p>
 <p>Food eaten: <span>Florentine crepe</span></p>
</div>

could convey microformat information as: 

previous
<div class="hreview">
 <span><span class="rating">5</span> out of 5 stars</span>
 <h4 class="summary">Crepes on Cole is awesome</h4>
 <span class="reviewer vcard">Reviewer: <span class="fn">Tantek</span> - 
 <abbr class="dtreviewed" title="20050418T2300-0700">April 18, 2005</abbr></span>
 <div class="description item vcard"><p>
  <span class="fn org">Crepes on Cole</span> is one of the best little 
  creperies in <span class="adr"><span class="locality">San Francisco</span></span>.
  Excellent food and service. Plenty of tables in a variety of sizes 
  for parties large and small.  Window seating makes for excellent 
  people watching to/from the N-Judah wh