Il est beau mon titre ?

Bon, j’utilise maintenant le client twitter hotot. Bien sous tout rapport, sauf pour un détail : celui de ne pas voir les twitts qu’on n’a pas lus alors que client en a rajouté dans votre timeline de lecture entre temps. C’est chiant.

Pour cela, j’ai rapidement patché le truc à l’arrache (fait sur la version 0.9.7).

Ah oui, et en prime, j’ai supprimé le tracker au sein de l’appli (oh! 3 fois rien, le programme donnait la plateforme et la version du logiciel et bien entendu votre adresse IP au serveur de Hotot : stats.hotot.org )

PS: le patch est dégueux, dans le sens où j’ai pas utilisé l’API exacte interne de Hotot mais l’API de Jquery et en allant directement à l’essentiel. Vous m’excuserez, je dois sauver le monde, pas trop le temps.

UPDATE: un petit bug dans le patch, c’est au niveau de la CSS « css/style.css » :
Dans le container « #view_title_bar .read_btn », virez « padding-left:60px; » et rajoutez « margin-right:25px; »
J’étais fatigué…

Houla, honte à moi, j’avais pas vu la libération de code opensource de la part de Disney R&D et disponible à l’adresse suivante: disneyanimation / technology / opensource

Au tableau, nous avons donc de bien beau outils :

• Ptex is a texture mapping system that requires no UV
  assignment. It maps a separate texture per-face using
  the implicit paramete rization of the mesh.
• SeExpr is a simple expression language that we use to
  provide artistic control and customization to our core
  software. We use it for procedural geometry synthesis,
  image synthesis, simulation control, and much more.
• Reposado is a set of tools written in Python that
  replicate the key functionality of Mac OS X Server’s
  Software Update Service. Reposado, together with the
  « curl » binary tool and a web server such as Apache 2,
  enables you to host a local Apple Software Update Server
  on any hardware and OS of your choice.
• Partio is an open source C++ library for reading,
  writing and manipulating a variety of standard
  particle formats (GEO,BGEO,PTC,PDB,PDA). It also
  has a python API and a collection of simple
  command-line tools.
• munki is a set of tools that, used together with a
  webserver-based repository of packages and package
  metadata, can be used by Mac OS X administrators to manage
  software installs (and in many cases removals) on Mac OS X
  client machines. munki is currently in use at organizations
  all over the world, managing software for tens of thousands
  of Macs.
• Dynamica is a plug-in for Maya that provides an
  interface to the Bullet rigid body engine. Bullet was
  originally created to simulate many rigid bodies quickly
  in a game context, but this plug-in helps extend its
  usefulness to film production. The Walt Disney Animation
  Studios used this plug-in to model the thousands of
  packing peanuts seen in BOLT.
• Pythoscope is a unit test generator for
  programs written in Python.

A relier avec le format OpenEXR mis à dispo par Industrial Light & Magic
(une toute petite boite de post-prod complètement inconnue…)

(Lire la suite…)

Récemment, je suis tombé sur un bug étrange dans le navigateur Chrome/Chromium.

Après un reload durant un développement, je me suis retrouvé avec une erreur 416 « Requested Range caused ».

Une erreur que je n’avais jamais vu auparavant. Les symptômes apparaissent au fur-et-à-mesure. Au début, Chrome va vous indiquer que le fichier sur le serveur n’existe plus. Puis n’est plus disponible. Et enfin (après quelques reloads), l’erreur 416 apparaît.

Au début, on se dit « Aaah, le système est entrain de partir en vrille, il a pas eu le temps de sauvegarder correctement le fichier ». En fait, pas du tout. C’est un « petit » bug de Chrome.

Pour résoudre ce problème, il suffit … de purger le cache. (ou de mettre à jour votre version de Chrome)

L’explication complète ici

Je vais vous présenter la DDD: Display Driven Development après ce petit laïus:

Alors que j’étais sur deux projets (voire trois) projets, je me suis aperçu d’un détail troublant: Il est parfois difficile de saisir « le futur » du projet. (élément troublant quand on doit assurer un suivi).

Il me fallait comprendre pourquoi sur un projet, nous « voyons » les moindres détails et sur l’autre, nous ne sommes pas capables de déterminer ce qu’on va faire le lendemain même.

J’ai mis du temps à comprendre, je crois l’avoir saisi lors de la lecture d’un article sur un cinéaste qui refusait de réaliser des films sans que l’idée ne soit de lui.

Je crois que ce problème vient simplement d’un déchargement de la conception en elle-même. D’un côté, nous avons des concepteurs externes à l’équipe (le client en général), et de l’autre les concepteurs internes à l’équipe.

Après réflexion, je pense que nous devons laisser le client assez éloigné de la phase de développement et de la conception; Ceci afin que les développeurs accaparent le produit, le développement et surtout le suivi: Décharger la conception du développeur, il ne devient plus qu’un pisseur de code. A la longue, il sera démotivé et n’aura plus qu’un principe: Arriver à la fin de l’itération le plus rapidement possible.

De part cette démotivation, le développeur n’aura plus aucune vision à long terme du développement: Du fait d’un déchargement de la conception, le développeur ne peut pas imaginer le futur du produit. Il a laissé cela aux concepteurs … qui ne sont pas les codeurs.

On peut y voir une forme de gymnastique intellectuelle plaisante pour le développeur. Lui enlever cela lui fait perdre 60% de son boulot (les 40% sont la découverte de facebook et de twitter ;)

Comme disait une personne qui se reconnaitra:

« J’ai embauché des ingénieurs et des développeurs; Si j’avais voulu des copistes de code, j’aurais embauché des secrétaires »

Attention, je ne dis pas qu’il faut écarter totalement le client, il faut simplement le remettre dans son contexte: il ne sait parfois pas véritablement ce qu’il veut et comment il le veut. Le mieux est de le « conduire » dans sa démarche intellectuelle.

Autrement dit, le plus simple est d’avoir une ébauche d’idée: « Je veux que l’application fasse ceci ». Durant cette phase, on ne décrit pas tout le logiciel dans ces moindres détails, mais seulement ce qu’il doit faire au final. Une sorte d’explication abstraite sur le pourquoi-du-comment. (si vous me suivez plus, bippez hein!)

Lors des conceptions, nous avons plusieurs techniques de développement, la méthode à l’arrache, les méthodes pyramidales de développement (on écrit un cahier des charges, les développeurs pissent le code et on se revoit dans 6 mois), ou alors les méthodes agiles.

« Maintenant, nous allons changer la façon de faire ici. Nous devrons faire/être [en méthode] Agile »
« Cela veut dire quoi ? »
« Rien ne change véritablement, sauf que maintenant les managers, les designers et les architectes ont une excuse pour tout changer le vendredi en fin de journée… »

Avec la méthode agile, vous avez une pratique qui consiste à diriger le développement par rapport aux jeux de tests. Ce principe est fortement intéressant sur plusieurs aspects. Déjà nous avons une sorte de container qui permet de délimiter le périmètre de développement et – si des modifications étaient apportées – de découvrir des problèmes inhérents à l’ajout de code (ou sa modification).

Ceci dit, après en avoir effectué pendant quelques temps, j’ai pu constater certains problèmes à ce genre de concept. Ils existent donc des limitations et leurs implications dans le concret peut parfois poser problème.

Si je lis Wikipedia, les TDD (Test Driven Development) sont :

En écrivant les tests d’abord, on utilise le programme avant même qu’il existe. On s’assure ainsi que le code produit est testable unitairement. Il est donc impératif d’avoir une vision précise de la manière dont on va utiliser le programme avant même d’envisager son implémentation. Cela évite souvent des erreurs de conception dues à une précipitation dans l’implémentation avant d’avoir défini les objectifs.

Ce qui me dérange dans ce concept, c’est le fait que les tests dirigent le « comment » on développe nos applicatifs.

Je vous explique le concept, dans une méthode TDD classique, vous codez d’abord le test qui teste la fonction, puis après vous codez la fonction. Cela est bien dans un système parfait, ou autrement appelé: théorique. Dans le concret, nous sommes parfois bloqués par des impératifs :

• Technologiques
• Conceptuels
• Temporels

Technologiquement: vous pouvez vous retrouver devant une impossibilité technologique que vous n’aviez pas estimé.

Conceptuels: le code produit ne correspond plus à vos attentes, il est tellement dirigé par le test que vous avez du produit du code alambiqué afin qu’il rentre dans « les cases » du test.

Temporels: vous perdez deux fois plus de temps, entre coder le test, l’implémenter la fonction … remodifier le test.

DDD: Les Développements Dirigés par le Dessin (ou en anglais: Display Driven Development)

Nous voilà enfin à la partie intéressante :)

Sur plusieurs projets, j’ai pu constater des différences de timing en terme d’implémentation et de résultat final pour le client (sauf si la demande n’a pas pu être comprise ou expliquée correctement, auquel cas, c’est un autre débat):

Dans une méthode classique agile, on code la fonctionnalité, on l’applique sur un affichage classique et lambda développé pour l’occasion pour les besoins de la présentation client et surtout pour l’affichage des données que le client a demandées. Ce dernier juge du travail et évalue la pertinence;

Généralement, le client voudra toujours modifier l’affichage qu’il trouve trop simpliste ou pas assez à son goût. Il voudra donc toujours « plus du comme-ci, plus du comme-cela ». Les développeurs modifieront donc l’affichage pour les besoins clients.

Manque de chance, cela « casse » une partie de la fonctionnalité ou comment cela s’imbrique au sein de l’application. On se retrouve donc avec une désynchronisation entre l’affichage et les fonctions internes: Nous avons finalement perdu du temps pendant la phase de développement, puis après la phase de modification. Vous rajoutez – à cela – la démotivation de devoir faire de nouveau, si finalement le client change d’avis sur le type d’affichage qu’il voulait.

Cela arrive plus souvent qu’on ne le pense: Un client veut une information en théorie, mais en pratique, il ne la trouve plus forcément pertinente, voire préfère un affichage complètement différent de ce qu’il avait en tête.

Il faut aussi prendre la vérité en pleine face: les « clients » ne veulent absolument pas savoir comment est construite l’application. Vous savez, votre belle fonction qui fait des trucs incroyables; Et bien cela va faire délirer que … vous (voire votre collègue, et encore … :)

C’est dommage à dire, mais cela est naturel: L’être humain normalement constitué ne veut qu’une chose: Du visuel. Ce n’est pas pour rien que les produits Apple marchent bien (je parle notamment des iPhones et autres iPods qui ont 10 fois moins de fonctionnalités que le constructeur concurrent de base)

Il faut donc probablement avoir une autre approche du développement plus graphique…





Voyons donc le problème (et donc la solution) d’un autre sens: Pourquoi ne pas voir la direction du développement directement avec une vision utilisatrice: on « design » l’interface en amont et avec le client.

Ainsi on voit tout de suite:

• Ce que le client veut
• Le client voit de suite si le résultat est satisfaisant ou pas du tout
• Cela permet surtout d’avoir un vecteur de communication standard
• Les erreurs et mauvaises interprétations sont mieux détectées
  (mieux ne veut pas forcément dire toute)

Cela peut sembler étrange, mais finalement pas tant que cela. Quand un projet de film arrive, on fait un storyboard (papier, voire des premiers shots) et cela n’étonne personne.

Pourquoi ne pas faire aussi dans l’informatique ?

Attention, quand je dis « on design l’interface », ce n’est pas dessiner rapidement trois rectangles et de définir leurs buts. Non. Le DDD va plus loin. Votre graphiste (voire un des développeurs qui manie bien le Photoshop/Gimp) va dessiner clairement les différentes interfaces.

Au final, la planche doit être à peu de choses près un screenshot de votre prochain applicatif. Cette dernière validée, on passe à la phase de conception: on ne code aucune fonctionnalité. On ne fait qu’implémenter l’interface « photosophée » pour une interface action-live (en gros, on peut cliquer dessus).

UPDATE: De plus cela vous permet de tester rapidement les limitations de votre interface graphique sans avoir à tout refaire. Ainsi si vous aviez designé un élément mais qu’il est -finalement- impossible de le faire (limitation technologique), vous n’avez revenir voir le client en lui proposant des modifications dans votre phase « screenshot ». Grâce à cela, vous n’aurez pas à re-développer une partie de votre interface graphique et de recabler les fonctions-datas (dans une phase de conception normale).

En HTML, sortez vos plus beaux CSS, DIV et Jquery. En application graphique, sortez votre plus belle librairie graphique (GTK, Cairo, OpenGL,…). Et ainsi de suite …

Sitôt l’interface terminée, le client (et vous-même) pouvez dès à présent « utiliser » l’application: Si on clique ici, cela ouvre ceci; Dans cette partie-là, on voit les informations et les données (factices bien entendu)

Sitôt terminé, on a plus qu’à remplacer les occurrences visuelles et conceptuelles « factices » par le résultat de votre code.

Ainsi, on ne développe que les fonctions dont on a besoin pour le rendu visuel: plus besoin de développer une fonction qui va récupérer X informations (au cas où le client change d’avis), mais une seule. Et le lien entre controller/model et le visuel sera beaucoup plus rapide et moins frustrant pour les deux parties.


Cette méthode utilisée sur quelques projets, je me suis aperçu que le rendu final et la rapidité de développement avait été accrue.

Et au final, le client était détendu du slip :-)


UPDATE: Petit worflow du DDD en pratique:




Note: si vous avez des observations sur vos méthodes de développement, sur la méthode indiquée ici-même, des contre-argumentations, des « jetages-de-tomates-pourries »; ou bien si vous remarquez des fautes, n’hésitez pas, toussa … commentaires .. toussa. (« lâchez vos coms’ » comme on dit sur skyblog :)

Les documentations sur Internet concernant Flex3/Flash et la compilation sous Linux sont nombreuses, mais parfois contradictoires (quoique, pour la dernière, c’est un peu « démerdez-vous » parfois)

Voici un résumé simple sur comment compiler un fichier .as (Flash/Flex3) sous Linux.

Déjà, allez récupérer le SDK d’Adobe à cette adresse. Prenez soit la version de 122 Mo bien closed-source, ou bien la version de 26 Mo open-source. Dézippez le tout et allez dans bin, et utilisez, pour vos compilations, le programme « mxmlc« .

Exemple de code source (/tmp/HelloWorld.as):

package {
     import flash.display.Sprite;
     import flash.text.TextField;
     public class HelloWorld extends Sprite {
         public function HelloWorld() {
             var display_txt:TextField = new TextField();
             display_txt.text = "Hello World!";
             addChild(display_txt);
         }
     }
 }

Compilez comme-ci:

Prenez le player Flash sous Linux, ou bien directement avec votre navigateur web, faites file:///tmp/HelloWorld.swf (si vous avez sauvegardé votre fichier source HelloWorld dans /tmp, bien entendu)

Bon, ca c’est la version simple, maintenant on a la version un peu plus complexe avec la vidéo:

 package {
         import flash.net.NetConnection;
         import flash.net.NetStream;
         import flash.media.Video;
         import flash.display.Sprite;
         public class MonPlayer extends Sprite {
                 private var nc:NetConnection;
                 private var ns:NetStream;
                 private var vid:Video;
                 private var client:Object;
                 public function MonPlayer() {
                         nc = new NetConnection();
                         nc.connect (null);
                         ns = new NetStream(nc);
                         vid = new Video(400,250);
                         addChild (vid);
                         vid.x = 0;
                         vid.y = 0;
                         client = new Object();
                         ns.client = client;
                         vid.attachNetStream ( ns );
                         ns.play('MaVideoDePr0n.flv');
                 }
         }
 } 

Sauvegardez le tout sous un fichier .as, puis à la compilation:

N’oubliez pas « use-network=false« , sinon la vidéo ne s’affichera pas.

En regardant le site des Godillots, je me demandais si c’était possible de récupérer en direct les informations sur le site de l’Assemblée Nationale sans trop se prendre la tête (sans passer 2h sur un #$* parsing par exemple).

Une constatation, le site ne permet pas d’avoir, d’un seul bloc, les informations relatives aux interventions séances et commissions, les propositions de lois, etc… d’un simple coup d’oeil. Et on comprendrait pourquoi: on constaterait assez rapidement que beaucoup serait proche du zéro.

Voici donc un script écrit à l’arrache pour récupérer ce genre d’info pour l’ensemble des députés de l’Assemblée Nationale.

#!/bin/bash
# License BSD - Benjamin GIGON / Prae

function get_info {
    local DEPUTEID=$1
    local DOCTYPE=$2
    lynx -source  »http://recherche2.assemblee-nationale.fr/resultats_tribun.jsp?id_auteur=${DEPUTEID}&legislature=13&typedoc=${DOCTYPE} »  \
        | grep ’<span class= »nbres »>’ \
        | html2text \
        | sed ’s/^[[:space:]]*\(.*\)[[:space:]]*$/\1/’ \
        | sed -e  »s/ /+/g » \
        | bc
}
function get_listing {
    lynx  »http://www.assemblee-nationale.fr/13/tribun/xml/liste_alpha.asp » -dump \
        | grep  »fiches_id » \
        | awk ’{ print $2 }’ 
}
function get_name {
    local DEPUTEID=$1
    lynx -source  »http://www.assemblee-nationale.fr/13/tribun/fiches_id/${DEPUTEID}.asp » \
        | grep -rs  »<title> » \
        | awk -F’:' ’{ print $2 }’ \
        | html2text
}

echo  »;ID;Nom Depute;Interventions Seances;Interventions Commissions;         Rapports Informations;Propositions Lois; » 2> /dev/tty
echo  »Nombre total:`get_listing | wc -l` » 1> /dev/tty 
get_listing | while read LINK;
do
    DEPUTE_ID=`basename $LINK .asp`;
    DEPUTE_NAME=`get_name ${DEPUTE_ID}`
    INTERVENTION_SEANCES=`get_info  »${DEPUTE_ID} »  »ComptesRendusIntegraux »`
    INTERVENTION_COMMISSIONS=`get_info  »${DEPUTE_ID} »  »ComptesRendusReunions »`
    RAPPORTS_INFO=`get_info  »${DEPUTE_ID} »  »Rapports »`
    PROPOSITIONS_LOIS=`get_info  »${DEPUTE_ID} »  »PropositionsLoi »`
    echo  »;${DEPUTE_ID};${DEPUTE_NAME};${INTERVENTION_SEANCES};        &nbsp${INTERVENTION_COMMISSIONS};${RAPPORTS_INFO};${PROPOSITIONS_LOIS}; » 2> /dev/tty

    let index=${index}+1;
    printf  »Processing: #%d\r » ${index} 1> /dev/tty
done;

Utilisation simpliste, il suffit de lancer le script comme-cela:

$ ./get_deputes_listing.sh > listing.csv

L’output sur le canal de sortie « normal » est le contenu CSV, vous pourrez l’importez dans OpenOffice sans difficulté (il suffit juste de prendre comme caractère de séparation, le point virgule et encodage ISO-8859-1). En output terminal, vous aurez des informations sur le processing en cours.

Côté Terminal:

$ ./get_deputes_listing.sh > listing.csv
Nombre total:577
Processing: #7

Côté fichier CSV:

$ cat /tmp/listing.csv
;ID;Nom Depute;Interventions Seances;Interventions Commissions;Rapports Informations;Propositions Lois;
;226; M. Jean-Pierre Abelin;7;2;2;11;
;267457; M. Élie Aboud;10;4;;39;
;230; M. Bernard Accoyer;2;17;1;3;
;267695; Mme Patricia Adam;14;24;1;23;
;236; M. Manuel Aeschlimann;9;3;2;28;
;243; M. Yves Albarello;21;34;2;50;
;253; M. Alfred Almont;9;14;4;38;

Un petit output des députés de l’Assemblée Nationale pour Avril 2009: Download

Tony – alias Tony-De-Koh-Lanta – a pasté ce *wonderful* cadeau dans les commentaires: Intel ® Integrated Performance Primitives 5.3

Cette merveilleuse librairie propose aloooooooooors:

Video Decode/Encode

Audio Decode/Encode

JPEG/JPEG2000

Data Compression

Cryptography – CAVP Validated!

Speech Coding

Speech Recognition

Image Processing

Image Color Conversion

Computer Vision

Signal Processing

Vector/Matrix Mathematics

String Processing

Rah la la ! y’a tellement de truc, que je peux pas les évoquer là … Regardez et mangez !
Bon, par contre, c’est OpenSource-à-la-mode-Intel …

Je suis tombé sur cette page: http://gimp-brainstorm.blogspot.com.
Je kiff :

La petite vidéo qui va faire chier les 3/4 des lecteurs (donc pas les techs) : Vidéo LGM: GIMP branlette-brainstorming

Le redesign de GIMP est important … mais bon, y’a aussi le support de plus de format d’image, l’ajout de fonctionnalité, etc…

A une certaine époque, je m’occupais d’un Registrar français (non, ce n’est pas gandi et encore moins OVH ;-).

Pour mes besoins, je devais interfacer tout le NOC à une seule et même base de donnée: le site web, le DNS (Bind), le serveur de mail (Postfix), les VirtualHosts (Apache), les redirecteurs transparents (Apache+Mod_Proxy) et le Whoisd (codé par himself),

En gros, je ne voulais pas à me prendre la tête: si un domaine expirait (ou pas), les requètes SQL – implementées dans les différentes configurations – devaient suffire à gérer les différents services: soit à produire un résultat viable, soit à rejeter la demande, tout ceci en direct bien entendu. (pas de couche d’abstraction entre les applis, comme un soft-crontabisé générant le fichier de config Bind ou Apache)
.
Pour le DNS, je me suis basé sur un patch existant : Bind-DLZ.

Bind-DLZ permettait des interconnexions vers les différentes grandes bases de donnéees OpenSource: MySQL, PostgreSQL, (Open)LDAP ou non-free avec ODBC.

Un pur bonheur…. oui, enfin pas tout à fait, j’avais quelques petits problèmes de performance au niveau du DNS lors des « queries » classiques.
Même la plus belle des requètes n’aurait pas pu régler ce problème: il fallait se rendre à l’évidence: j’avais besoin de « tags » supplémentaires dans la configuration de Bind patché avec DLZ.

Après quelques minutes/heures, j’ai produit une serie de patch pour les différents « drivers » Bind-DLZ pour l’ajout de deux tags: le « zone_tld » tag et le « zone_domain » tag.

Le « zone_tld » s’occupait des gTLD comme .com, .net, .org, etc…
Le « zone_domain », lui, s’occupait de la partie « nom » du domaine: « sherpadown« , « google« , etc… par exemple.

Après test et mise en production, les latences ont disparus.

Les différents patchs et packages :

Bind DLZ – Patchs Extended-Tags

Bind DLZ

Unofficial Debian packages for Bind DLZ + Patch Extended-Tags

Lorsque l’on gère une nouvelle équipe en eXtreme Programming, ils existent des aspects auquels les développeurs – qui proviennent du développement classique – vont devoir se confronter.

En général, les développeurs travaillent suivant un concept relativement simple: chacun dans son coin et on centralise à interval régulier (si cela est le cas) l’ensemble du travail (à l’aide d’un repository par exemple)

Dans la méthodologie XP, beaucoup de points divergent entre méthode classique et eXtreme Programming;

Dans l’ensemble, la plupart des nouveaux aspects – traités en XP – sont relativement simples à mettre en oeuvre pour une équipe fraichement déabarquée: la publication rapide des travaux, les tests unitaires, la conception simplifiée, le refactoring sont des points qui – après un petit temps d’adaptation – deviennent naturels chez les néo-développeurs XP convertis;

Il existe cependant un point qui (peut) se révèler des plus trouble pour pas mal d’entre eux: Le pair programming (ou programmation à deux).

Pour faire simple, je prendrais la définition provenant de Wikipedia :

 "Pair Programming"  ou  "Programmation en binôme" La programmation se fait par deux. Le premier, appelé driver, a le clavier. C'est lui qui va travailler sur la portion de code à écrire. Le second, appelé partner, est là pour l'aider, en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Les développeurs changent fréquemment de partenaires, ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe.              Extreme Programming / Wikipedia 

L’aspect semble relativement simple au premier regard;
Chaque développeur travaille avec un autre programmeur.

Simple non ?
Pas forcément;

Il existe un élément qui a été écarté : L’aspect psychologique de la chose: celui de la proxémie et du concept » d’espace vitale »

Le concept de l’espace vital se présente sous cette notation :

 Chaque personne dispose d'un espace vital virtuel. Si un inconnu rentre dans ce périmètre, l'autre peut l'interpréter comme une attaque. On peut estimer ce périmètre à une longueur de bras. Le regard qui se situe dans cet espace vital prend donc beaucoup d'importance. Le périmètre public se situe environ à deux mètres de l'autre personne.                  Texte de ciao.ch 

Il se peux que je me trompe [1], cependant je n’ai pas remarqué une allusion dans les analyses que j’ai pu lire ou entrendre (publications ou rencontre avec des experts XP).

Devant un écran, il est (très) souvent difficile d’être parfaitement concentré lorsqu’il existe une présence derrière ou à coté de soit.
Que ce ne soit par des accès fréquents derrière son dos (une porte, un couloir fréquenté, …), ou bien un collègue venant regarder votre écran.
( Avouez que vous vous êtes déjà retrouvé dans une situation pareil et que cela vous rendez nerveux :-)

La méthode XP impose cette restriction: celui d’avoir un pair qui valide le code avec vous.
Si les programmeurs s’entendent et se respectent, la « fusion » peut très bien se passer;
Cependant, Quid lorsque deux développeurs ne peuvent s’entendre ?

Il existe de nombreux cas qui peuvent s’accorder avec cette problématique :

• Un développeur qui n’aime pas un collègue bien particulier
• Un développeur trop orgeilleux
• …

La méthode classique consiste à placer les deux développeurs devant un même écran et un même clavier;

Cependant, une autre approche permettrait de démarrer progressivement le pair programming sans braquer le ou les développeurs.

Elle consisterait à séparer les unités de contrôle et de vision: l’écran et le clavier.
Rendre indépendant ces deux périphériques mais connecté toujours sur un seul et même ordinateur (unité centrale ou portable)

De plus en plus (voire la majorité maintenant) de machine – même portable – propose aux moins deux ports USB;
Il suffit de brancher deux claviers pour que les deux développeurs puissent ne pas ressentir de frein ou la sensation de ne pas maitriser le développement en cours.
Concernant les écrans, ils existent des cartes gérant le DualHead, qui permettent, soit de créer une copie parfaite de l’un des écrans virtuels (TwinView, Clone, etc…), soit d’avoir un écran virtuel indépendant (TwinView).

Les deux développeurs peuvent avoir une légère séparation entre eux: Allant de quelques centaines de centimètres, voire être l’un en face de l’autre de la table.

Le développement en Pair Programming n’est pas bouleversé par ce changement car l’écart se révèle être très minime pour la communication entre les deux protagonistes;

Les deux ayants la même perception du développement et pouvant interargir directement sur la construction du code sans subir une quelconque pression de leur(s) environnement(s): les deux développeurs qui ne pourraient travailler en pair programming peuvent le faire sans être restreint.

Cela ne constitue pas une fin en soit, mais testé sur une équipe de développeurs, les résultats ont été plutôt positifs