ALIXSYS

Rapprocher la responsabilité de l’utilisateur

Sat, 15 Nov 2008 01:52:28 GMT

Les systèmes automatiques sont faits pour effectuer des opérations complexes tout en cachant la complexité a l’utilisateur. Si on ne fait pas attention en les concevant, ils cachent aussi la responsabilité. Pour pallier a ce problème, souvent, on ajoute des fonctionnalités de traçabilité : historiques et autres artefacts. Alors qu’il serait beaucoup plus effectif de concevoir le système dés le départ de façon à garder la responsabilité proche de l’utilisateur.

La responsabilité à un cout. C’est une sorte de taxe qu’on paie sur tous les produits qu’on en soit conscient ou pas. Quand elle est inscrite sur la facture, la responsabilité porte souvent le libellé : “Frais de gestion” ou “Assurance qualité”. Mais souvent, elle est sous évaluée. Bien évaluée, la responsabilité représentera probablement plus que 30% de la facture. Prenons un pain par exemple : c’est de l’eau, de la farine et du travail du boulanger. Dans le prix du pain, il y a le cout de la responsabilité du boulanger qui doit s’assurer que le pain est commestible et qu’il est de bonne qualité. D’ailleurs c’est principalement pour cela que les boulangers ne se valent pas. Mais il y aussi le cout de la responsabilité des services d’hygiène nationaux qui vérifient que les normes sanitaires sont respectées. Il y a le cout de la responsabilté de celui qui a vendu la farine et de celui qui a vendu l’eau et celui qui a loué le local. Chaque fois qu’il y a travail, il y a responsabilité et il y a un cout.

Maintenant, la responsabilité liée à un produit est fixe, elle ne peux pas être diminuée. Et la responsabilité ne se donne pas, elle se prend. Chacun est libre de prendre autant de responsabilité qu’il le désire. Mais pour l’acheteur, plus le vendeur prend de responsabilité moins il doit en prendre lui même. Parce qu’il faut bien que quelqu’un la prenne. Aussi plus de responsabilité engagée dans un produit est le seul argument de vente valable pour justifier d’un prix relativement élevé. Cet argument est souvent abusivement formulé : “meilleure qualité”. La qualité d’un produit c’est palpable, ce n’est pas un argument de vente. Et si le produit n’existe pas encore - le cas d’un logiciel ou d’une architecture - c’est qu’on parle d’assurance qualité et non pas de qualité. Et l’assurance c’est précisément le produit de la responsabilité. Il y a des vendeurs de responsabilité pure. Ça s’appelle les sociétés d’assurance.

A l’inverse, l’acheteur peut avoir une idée de la quantité maximale de responsabilité engagée dans un produit avec un calcul aussi simple que “30% de la facture” à titre d’exemple. Si vous achetez un jouet a 5 dinars, la responsabilité maximale engagée dedans est de 1.500 dinars. Le reste c’est vous qui l’assumez, alors ne le donnez pas a un enfant.

L’autre jour, je me suis arrêté a un passage à niveau et j’ai attendu. J’ai attendu jusqu’à me rendre compte que le passage à niveau était probablement cassé : c’était une fausse alerte, “False Positive” en anglais, il n’y avait pas de train. A ce moment là je me suis demandé si le passage à niveau ne demandait pas une intervention humaine pour fonctionner. Le chauffeur aurait il oublié d’appuyer sur le bouton pour lever la barrière? Et c’est très dangereux. Tous les experts en sécurité vous le diront : une fausse alerte est presque aussi dangereuse qu’une vraie alerte. La preuve, j’ai contourné la barrière pour traverser. Si le même problème s’était reproduit encore une ou deux fois, j’aurais probablement pris l’habitude de contourner la barrière et je me serais probablement fait écraser un jour ou l’autre. Ne vaudrait il pas mieux avoir des systèmes automatisés pour ce genre de chose? Un capteur sur les rails et un déclenchement automatique et on n’en parle plus.

Non. C’est une question de responsabilité. Je ne m’y connais pas en passages à niveau, et après une petite recherche sur internet à ce sujet, je ne suis toujours pas en mesure de vous dire si c’est automatique ou manuel. Mais il serait probablement plus judicieux qu’ils soient manuels et assistés. Les systèmes automatiques, y compris les systèmes informatiques, ont une fâcheuse tendance à éloigner la responsabilité de l’utilisateur. Les systèmes automatiques sont faits pour effectuer des opérations complexes tout en cachant la complexité a l’utilisateur. Si on ne fait pas attention en les concevant, ils cachent aussi la responsabilité. Pour pallier a ce problème, souvent, on ajoute des fonctionnalités de traçabilité : historiques et autres artefacts. Alors qu’il serait beaucoup plus effectif de concevoir le système des le départ de façon à garder la responsabilité proche de l’utilisateur.

A ALIXSYS nous construisons des progiciels de gestion. Ce sont des applications critiques et nos clients nous demandent souvent de :

“verrouiller”
ajouter des contrôles
diminuer des droits d’accès
demander des confirmations à l’utilisateur
etc…

Tout se passe comme si nos clients faisaient plus confiance au logiciel qu’aux utilisateurs, y compris eux mêmes. C’est que les erreurs humaines ont souvent des conséquences graves et il est tellement facile de faire en sorte que le logiciel les empêche… à première vue. Vue de notre bout de la lorgnette, la situation est différente :

Le système ne peux en aucun cas empêcher l’erreur humaine.
Le système est là pour donner du pouvoir aux hommes, pas pour les brider. Du pouvoir de faire des choses qu’ils ne pouvaient pas faire sans.
On préfère que les hommes se trompent plutôt que le système.

Oui. On préfère que les hommes se trompent plutôt que le système. C’est une question de responsabilité. Quand un utilisateur se trompe, on ne l’en empêche pas, on essaye de savoir pourquoi il s’est trompé. Dans 50% des cas c’est notre logiciel qui est en cause; mais dans 50% des cas c’est la procédure qui est en cause. C’est aussi notre métier de savoir quand un problème n’est pas de notre compétence et d’en informer le client. C’est le conseil. Quand c’est notre logiciel qui est en cause, dans presque tous les cas, le problème est dans l’interface utilisateur et il y a une meilleur solution que de limiter la liberté de l’utilisateur. Il suffit de changer la position d’un bouton, pour que plus personne ne clique dessus par erreur. Il suffit de changer le libellé d’un champ de saisie de chiffre, pour que plus personne ne tape des lettres dedans.

Quand le système se trompe, qui porte la responsabilité à votre avis? Oui, c’est nous. Et qui paie? Oui, le client. La responsabilité liée à un produit est fixe, on a dit. Alors à ALIXSYS, nous préférons que ça soit le client qui la porte quand c’est possible. Après tout, en déléguant la responsabilité, il ne délègue pas le risque (l’histoire de la responsabilité et du risque, je vous la raconterais peut être une prochaine fois). Alors c’est tout benef pour lui aussi. Avouez que c’est cocasse comme manière d’être compétitifs sur nos prix. D’aucuns tapent dans l’assurance qualité pour diminuer leurs part de responsabilité, nous ce qu’on fait c’est concevoir des systèmes où la responsabilité est d’emblée déléguée à l’utilisateur.

Voilà. Vous connaissez notre secret. Bossez maintenant.

Les interfaces web de saisie rapide

Thu, 11 Sep 2008 10:12:55 GMT

La désynchronisation des activités est l’essence même de Ajax, c’est le “A” dans “Ajax”. Ces derniers temps, on commence a utiliser le terme “Ajax” pour dire “XMLHttpRequest” ce qui était prévisible : personne ne peux dire “XMLHttpRequest” sans attraper le hoquet.

Comme vous le savez déjà nous sommes en train de développer un Progiciel de Gestion Intégré (PGI) pour un grossiste en pharmaceutiques en Tunisie. L’activité de grossiste pharmaceutique est très particulière pour deux raisons :

le secteur pharmaceutique est relativement ancien et bien développé ce qui fait qu’il y a des “traditions”
le secteur pharmaceutique est très régulé pour des raisons de santé publique évidents

L’une des particularités du secteur c’est le traitement d’un nombre de commandes élevé dans une plage horaire très restreinte. Pour vous donner un ordre d’idée, ici, on traite à peu prés 900 commandes par jour dont 400 entre 11h et 13h. Il faut donc une logistique adéquate.

L’une des difficultés évidentes que nous avons identifiée depuis le début de projet, c’est l’interface de prise de commande qui allait être utilisée par les commerciaux. Les commerciaux sont généralement très peu connaisseurs en informatique : ils sont là pour appeler les clients au téléphone et saisir leurs commande le plus rapidement possible, par conséquent le niveau d’instruction est secondaire. Cela dit, vu la nature de leurs activité, ils maîtrisent parfaitement le logiciel qu’ils utilisent maintenant. Ils ont même développé des réflexes et des automatismes liés aux touches de fonction.

Quand nous avons présenté l’interface de prise de commande la première fois, nos interlocuteurs avaient des doutes. Pourtant la nouvelle interface etait loin devant l’ancienne en terme de fonctionnalités et même en terme d’ergonomie. Nous avons donc corrigé quelques détails par-ci par-là et donné l’application aux utilisateurs finaux pour la tester.

Le verdict fut unanime : la recherche des articles est trop lente. Quand vous cherchez un article dans les 7991 références, notre système met 300ms à répondre. Ce qui était beaucoup trop. Après avoir observé pendant une heure le plus expérimenté des commerciaux travailler sur l’ancienne application, j’ai été convaincu.

Après avoir étudié le problème et essayé différentes solutions, il n’y avait rien à faire : toute l’interface était à refaire. La seule solution était de grignoter sur les 300ms et pour cela il fallait reconcevoir l’interface.

La saisie d’une ligne de commande se passe comme suit :

L’utilisateur saisi les premières lettres de l’article recherché
Le système lui présente une liste d’articles qui correspondent à sa recherche
Il sélectionne l’article qu’il veut
Il saisi la quantité commandée
Il recommence

Pour bien faire son boulot l’utilisateur a aussi besoin de feedback. Il a besoin de savoir quelle est la quantité disponible en stock et d’être notifié en cas d’erreur (article mal saisi, etc…). Dans le système tel qu’il était conçu, il y avait une seule requête, ce qui nous avait semblé être un bon choix quand on avait conçu l’interface. La logique étant que 1 seule requête (Ajax) prend toujours moins de temps que plusieurs. Mais à y regarder de plus prés, l’activité pour laquelle on conçoit l’interface a une particularité qu’on peut exploiter : quand l’utilisateur veut vraiment (vraiment!) aller rapidement, il ne regarde pas la quantité disponible, il n’a pas le temps.

Ce que nous avons fait c’est séparer la consultation de la disponibilté en stock de la recherche d’article. En fesant cela nous avons gagné du temps doublement :

d’abord nous n’affichons la quantité disponible que pour l’article séléctionné et non plus pour tous les articles retournés par la recherche, ce qui décharge le serveur.
ensuite nous avons désynchronisé cette activité (remarquez les barres de synchro dans le diagramme) ce qui fait qu’elle se fait maintenant en parallèle avec la saisie de la quantité et donc ne prends plus de temps.

Cette nouvelle conception nous a permis de faire tomber la réponse du système à 30ms, et de réduire la responsivité perçue par l’utilisateur par - a vue de nez - un facteur 100. Notez aussi que nous n’avons pas fait que désynchroniser la consultation de la disponibilité en stock, nous avons aussi désynchronisé tous les autres feedbacks du système y compris l’affichage de la ligne saisie elle même (remarquez les 3 points de fin d’activité).

La désynchronisation des activités est l’essence même de Ajax, c’est le “A” dans “Ajax”. Ces derniers temps, on commence a utiliser le terme “Ajax” pour dire “XMLHttpRequest” ce qui était prévisible : personne ne peux dire “XMLHttpRequest” sans attraper le hoquet. Certains disent même qu’on fait tout et n’importe quoi avec Ajax et en fait ils veulent dire qu’on fait tout et n’importe quoi avec “XMLHttpRequest”. Je ne le pense pas. Je pense que “XMLHttpRequest” ne peux pas faire de mal, même s’il est utilisé n’importe comment.

Nous sommes actuellement en train de tester la nouvelle interface avec les utilisateurs et vous savez quoi? Aucun feedback. Ils disent rien les utilisateurs. Ils utilisent l’application comme si tout allait de soi. Comme s’ils l’utilisaient depuis toujours. Et je me dis que faire des logiciels pour entreprise a cette différence par rapport à faire des applications grands public : l’efficacité prime sur l’effet. On n’est pas la pour faire du buzz, on ne veut impressionner personne. Et effectivement les utilisateurs ne sont pas impressionnés … mais ils ne se plaignent pas. Et c’est ça notre récompense.

doper le développeur avec du logiciel

Sat, 12 Jul 2008 09:49:25 GMT

En réalité, ce qu’on perdait de vue c’est que cela serait vraiment pratique de pouvoir comparer les montant des factures à l’ancienne avec nos nouvelles factures avec un seul clic de souris. Si on avait ça, on le ferait tous les jours. C’est parce que, justement, examiner les listings était pénible qu’on le faisait pas tous les jours.

Je me plais à dire que, dans notre métier, la programmation en tant que telle n’est ni une étape du processus, ni une activité. Elle est là à toutes les étapes : préparation, conception, test, amélioration. Si on devait la définir par une abstraction dans le processus ça serait celle ci : “Contexte”. C’est une erreur conceptuelle très courante dans les processus préfabriqués que de considérer la programmation comme une étape.

Nous sommes actuellement en phase de test intensif avant déploiement. C’est une étape plus ou moins critique selon le projet, et pour ce projet-ci, elle est très critique. Nous sommes en train de migrer l’un des plus importants grossistes en pharmaceutiques vers un nouveau système d’information intégré.

La difficulté dans ce genre de projets est toujours la même et peut se résumer à cette phrase du client : “n’oubliez pas que <nom de l’ancienne application> marche très bien depuis <nombre d’années supérieur à 10>“. Quelle que soit la définition du client pour “marche très bien” et quelque soit sa perception de son bon fonctionnement, le contrat est là : il faut qu’on remplace une application qui marche par une application qui ne marche pas encore.

Concevoir des tests n’est pas toujours chose aisée : une fois qu’on sait ce qu’il faut tester et combien, le “comment?” demande souvent des masses de créativité ou de ressources. L’avantage d’avoir une ancienne application comme étalon, c’est que justement, toute une classe de tests devient évidente : beaucoup de fonctionnalités doivent fonctionner EXACTEMENT comme l’ancienne application.

Hassen était aux prises avec des listings contenant des centaines de factures issues de l’ancienne application. Le but était d’identifier les différences entre les nouvelles factures et les anciennes. et jusque là la seule manière de faire que nous avions trouvée c’est de comparer manuellement les montants (des centaines, je rappelle). J’ai regardé Hassen faire ça pendant quelques jours, puis j’ai eu l’inspiration. J’avais pas encore une idée, juste une piste : si ce vieux logiciel DOS pouvait imprimer sur une feuille, on pouvait le faire imprimer dans un fichier.

J’avais l’idée, mais je ne savais pas encore comment j’allais faire, ni combien de temps ça allait prendre et surtout je n’avais pas le temps. A ce moment là Bechir était venu à la rescousse de Hassen, ils faisaient ça en XP, alors je leurs ai proposé l’idée. Nous avons réévalué les taches de la semaine ensemble et avons estimé que cela ne valait pas la peine. Dans ces moments là, on a souvent la hantise du YAGNI : après tout, on ne va pas examiner les listings des factures tous les jours. Une fois que c’est fait, c’est terminé.

En réalité, ce qu’on perdait de vue c’est que cela serait vraiment pratique de pouvoir comparer les montant des factures à l’ancienne avec nos nouvelles factures avec un seul clic de souris. Si on avait ça, on le ferait tous les jours. C’est parce que, justement, examiner les listings était pénible qu’on le fait pas tous les jours.

J’avais laissé la porte ouverte, disant : “si vous sentez que ça va vous aider, je le fais”. Ils ont fini par me demander de le faire. ça m’a pris quelques jours pour essayer différentes solutions qui n’ont pas marché et pour trouver la solution qui marche : j’ai installé dosemu sur un vieux poste linux, je l’ai configuré pour envoyer tout ce qui était destiné à l’imprimante dans un fichier texte accessible sur le réseau et j’ai installé la vieille application dessus. J’ai même pris la peine d’écrire un peu de code pour transformer les listings malpropres en fichiers CSV parfaitement acceptables pour notre base de données.

Nous ne fûmes pas déçus. Avec le recul, maintenant on est sur qu’on y serait jamais arrivé sans avoir fait cela. La morale de cette histoire c’est : donnez du pouvoir à l’équipe, ce n’est jamais une perte de temps. Faites comme Abraham Lincoln , si vous avez 8 heures pour couper un arbre, passez 6 heures à aiguiser votre hache. ça vaut la peine.

Contact

Wed, 09 Jul 2008 10:22:21 GMT

ALIXSYS
km 7 route de Mateur - Manouba 2010
Tunisie

Téléphone : +216.25070517

Mel : info@alixsys.com

Abonnement

Wed, 09 Jul 2008 10:17:11 GMT

Ce site est régulièrement mis à jour avec des articles relatant notre expérience des projets en cours. Pour être tenu au courant des mises à jour choisissez la manière qui vous convient.

Abonnez vous à notre flux RSS :

http://alixsys.com/rss

Abonnez vous à notre lettre d'information :

Votre adresse Mail :

HTML 5 differences from HTML 4

Wed, 11 Jun 2008 14:13:39 GMT

http://markkit.net/archive/www.w3.org_TR_2008_WD-html5-diff-20080610_.html?s=jqgl31750e71cf4nog1en5va41#introduction

une petite histoire de ALIXSYS

Sat, 07 Jun 2008 12:39:52 GMT

je suis désormais patron d’entreprise. une très petite entreprise de 3 développeurs d’applications web que nous avons nommée ALIXSYS.

ALIXSYS est né de la scission de l’unité Recherche et Développement en Systèmes d’Information (RDSI) de AlphaStudios. En d’autres termes l’équipe ALIXSYS à toujours existé sous cette forme mais sous une autre appellation et sous une direction différente : j’étais le patron de l’équipe, mais j’avais moi même un patron.

A AlphaStudios j’étais “Directeur des Projets”, à l’époque j’avais estimé que le titre de “Directeur Technique” ne convenait pas parce que dans l’entreprise telle qu’elle était structurée tout était technique. Ce qui mettait sous ma responsabilité les deux unités constituant AlphaStudios : RDSI et Web et Multimédia (WM) . WM étant l’unité historique de AlphaStudios. AlphaStudios crée des sites web et des applications multimédia depuis 1997. Date à laquelle j’ai rejoins l’entreprise.

L’unité RDSI est née vers 2001 d’une constatation simple : nous avions des compétences trop importantes pour ce que demandais le marché des sites web et des (défunts) cdroms multimédia. Nous avons donc décidé d’investir le marché des applications pour entreprise et nous avons d’emblèe cru dans les applications web.

Notre idée première c’était de proposer une meilleure solution aux entreprises multi-sites qui jusque là travaillaient avec des applications client-serveur relativement couteuses à maintenir. Mais notre premier client aller nous orienter sur un autre marché auquel nous n’avions pas pensé : celui des sous traitants exportateurs.

Les sous-traitants ont typiquement un donneur d’ordre à l’étranger à l’égard de qui ils doivent montrer le plus de transparence possible. Nous avons donc développé pour cette société une solution simple qui permettait à son client de suivre la production sur internet. Mais les circonstances ne nous ont pas permis d’exploiter ce filon. Il n’en reste pas moins que je crois que nos solutions sont idéales pour les sous-traitants exportateurs et je compte engager ALIXSYS dans cette direction.

Vers 2003 nous sommes passés par un bref épisode de service web d’audience des médias. Malgré la brièveté (relative) et l’échec (certain) de ce projet, cela m’a néanmoins fait réaliser l’importance du SaaS comme modèle de vente de logiciel. à ALIXSYS nous développons, hébergeons et maintenons les applications de nos clients.

Au bout de quelques années de fonctionnement l’équipe à fini par développer un noyau d’application pour entreprise que nous avons appelé AliX. Plus tard l’unité RDSI sera rebaptisée AliX aussi. Ce noyau à servi par la suite de base à une série de Systèmes de Gestion Intégrés (ERP) que nous avons développés pour quelques entreprises tunisiennes. Cet expérience de l’entreprise Tunisienne fut capitale : un logiciel, au delà d’une certaine taille, n’est pas fait que de code; il est fait de négociations, de politique et de relations humaines complexes. je ne suis pas sûr que nous continuerons à faire des logiciels de cette taille là dans ALIXSYS.

Ces dernières années, j’ai fini par m’occuper exclusivement de l’unité AliX, devenue aujourd’hui ALIXSYS. Parce que Anis s’occupait très bien de l’unité WM et parce que cela me convenait parfaitement. Au début de cette année j’ai décidé que pour assouvir mes ambitions, et après 10 ans de travail, je devais fonder ma propre entreprise. J’en ai parlé à Zied, mon patron, et on s’est mis d’accord pour que j’attends encore 6 mois. Le problème étant que la survie de l’unité AliX était menacée sans moi. Mon idée à ce moment là c’était de faire la startup markkit. C’était risqué, mais j’étais volontaire.

Au cours d’une réunion un peu dure avec un client de AliX, le client décide d’arrêter son projet (ce sont des choses qui arrivent). L’étau se resserre sur l’unité AliX, mais je vois une opportunité. Je propose à Zied de séparer AliX de AlphaStudios et au client de travailler avec la nouvelle entreprise. Au bout de 4 mois de négociations ALIXSYS est né.

L'équipe ALIXSYS

Mon, 02 Jun 2008 13:37:05 GMT

Nous sommes 3 développeurs avec une expérience cumulée de prés de 25 ans dans les applications web. Ce qui est raisonnable compte tenu du fait que le web n'existe que depuis 1994. Nous travaillons ensemble depuis à peu prés 5 ans, ce qui donne à notre petit groupe une cohésion importante.

Contactez nous!

Position géographique : Tunis, Tunisie

Téléphone : +216.25070517

Bechir Hatira

Mon, 02 Jun 2008 12:45:00 GMT

Bechir Hatira <bechir@alixsys.com>
"En general je m'occupe des taches imprévues et urgentes en parallèle avec mes objectifs (ce qui explique en partie que je ne termine que
rarement tous mes objectifs ).

J'administre les serveurs de nos clients et ceux d'ALIXSYS, nous sommes exclusivement sous Linux Debian et Ubuntu ce qui ne nécessite
pas un très grand effort. mais c'est la partie la plus sympathique de mon travail donc je fais durer le plaisir au maximum.

Je partage mon expérience de conception et de développement avec toute l'équipe même quand ça ne me regarde pas... ça m'est utile pour le contrôle qualité et la validation."

Hassen Marzouki

Mon, 02 Jun 2008 12:40:28 GMT

Hassen Marzouki <hassen@alixsys.com>
"Mes principales taches consistent à développer, tester et maintenir.
La compréhension des cas d'utilisation que le système à élaborer doit résoudre.
Je participe a la conception du point de vue technique. Trouver les méthodes de résolution les plus optimisées."

Slim Amamou

Mon, 02 Jun 2008 12:33:45 GMT

Slim Amamou <slim@alixsys.com>
"Ma tache principale c'est de maximiser ma disponibilité. En d'autres termes essayer de ne rien faire. Je gère les projets, je les documente, je fais les PV, les réunions avec le client et tout ce que mes collaborateurs ne veulent pas faire. Je code aussi et participe à la conception des systèmes que nous développons. Mais la tâche que je préfère c'est surveiller les standards W3C et IETF."

La prothèse mémorielle (l’impact de la publication des historiques sur la société de l’internet)

Mon, 17 Mar 2008 12:48:44 GMT

L’historique commencerait à la date ou on a commencé à s’intéresser à lui et finirait quand on ne s’y intéresse plus. Ce serait une sorte de prothèse mémorielle gérée qui garderait une trace de tout ce qu’une personne à vécu dans sa vie. incidemment. Cette année, parait-il, la tendance est aux “life streams”. en français “historique [...]

JTI2008 : Les Journées Tunisiennes de l’Internet organisées par le chapitre Tunisien de ISOC

Sun, 24 Feb 2008 16:31:19 GMT

Le premier jour la salle était pleine d’étudiants mais ils n’avaient pas l’air très au courant. Le deuxième jour il y avait moins d’étudiants mais ils avaient l’air plus au fait des discussions. Comme si ceux qui étaient venus le premier jour avaient passé le mot : ça parlait de izoque, ipévéssisse, idééenne, yeutééeffe et [...]

Utilisabilité des applications web : La conception de Bazdig illustrée

Sat, 09 Feb 2008 15:36:01 GMT

D’un coup je me suis rendu compte que la console SQL que j’utilisais n’était pas pratique. J’ai fait quelques recherches, Bechir en a fait aussi et Hassen aussi. Aucun de nous n’a trouvé de console valable. Alors j’ai décidé de relever le défi. J’ai dit a Hassen de me donner deux week-ends; il m’en a [...]

deux mesures pour la censure

Fri, 18 Jan 2008 11:26:33 GMT

Mon idée c’est que a l’instar de notre surprise face a l’audience de Tunis 7 les décideurs du ministère de l’intérieur seraient surpris de l’impact réel des informations jugées offensives. Et dans tous les cas je serais plus rassuré s’ils basaient leurs décisions de censure sur des données solides. Au début du troisième millénaire, je travaillais [...]

programmer un clone de del.icio.us en 30 minutes avec Appjet

Sun, 16 Dec 2007 14:25:07 GMT

J’ai commencé par modifier quelques lignes de code pour voir si on pouvait faire accepter a l’application des paramétres avec la méthode GET, ensuite j’ai modifié le type d’enregistrement (storage) pour qu’il accepte plusieurs champs, toujours en factorisant a chaque étape pour que le code ressemble a ce qu’il doit faire. Enfin j’ai publie l’application [...]

le recrutement des programmeurs avec un test écrit en anglais

Sat, 01 Dec 2007 13:58:51 GMT

Anis avait trouvé un questionnaire LAMP en anglais qu’il s’est empressé d’envoyer a Bechir. Bechir me l’a envoyé pour que je le traduise. J’avais des candidats qui venaient pour entretien l’après midi même, alors j’ai pris le questionnaire tel quel (en anglais) et je leurs ai fait passer. depuis une année a peu prés nous [...]

le président Hu Jintao est il derrière un firewall?

Fri, 16 Nov 2007 01:39:29 GMT

lettre, oblique plus que ouverte, au président chinois les voies de l’esprit humain sont impénétrables. dernièrement un concours de circonstances a fait naviguer mon esprit dans une direction insoupçonnée. les circonstances sont les suivantes : un virus a infecté la moitié des ordinateurs au bureau et nous a obligé a revoir notre politique de sécurité. youtube et dailymotion [...]

Software Freedom Day 2007

Sun, 28 Oct 2007 16:58:08 GMT

hier j’ai été au SFD2007 a la cité des sciences. si vous n’avez pas pu me suivre en direct sur twitter, voici un résumé. grosso modo c’est bien organisé : un hall pour les sociétés et un hall pour les association. sauf que le hall des associations était un peu éloigné : on pourrait faire [...]

OpenUP le RUP agile de IBM

Sat, 13 Oct 2007 17:10:43 GMT

IBM qui a bien senti que son RUP n’est plus en phase avec les bonnes pratiques actuelles; à décidé d’adopter un nouveau processus agile. elle a confiè l’exécution a Per Kroll et ses acolytes. Le cahier des charges spécifiait bien sûr que le processus doit être compatible avec RUP, et que sa finalité était d’être [...]