23rd 3月 2008

Twitter: gazouillements du Web 2.0

Connaissez-vous Twitter? http://twitter.com/

Selon ses créateurs, “Twitter est un service pour amis, familles et collègues, permettant de communiquer et de rester connecté par l’échange de rapides et fréquentes réponses à la question: Qu’est-ce que vous faites?

Twitter

Ma définition serait un peu différente, car je n’ai que peu d’amis qui utilisent (déjà) Twitter. Je dirais que la question: “What are you doing” est une excuse, une invitation a parler. Comme quand on rencontre quelqu’un et qu’on dit: “ça va?”. Pour moi, Twitter est un lieu d’expression. Twitter est parfois qualifié d’outil de “micro-blogging”, car une particularité est que chaque phrase (tweet = gazouilli) que l’on poste est limitée à 140 caractères. Cette limite est importante, car elle force à être concis. Cela permet de laisser à tous la liberté d’expression.

Vu sous un autre angle, Twitter est un lieu d’écoute. Il suffit de voir la “public timeline” http://twitter.com/public_timeline, c’est-à-dire l’ensemble de tous les tweets postés par l’ensemble des utilisateurs. On a beau rafraichir la page, il y a sans cesse des nouveaux tweets, le débit est impressionnant! Et il est amusant de voir la diversité des langues utilisées. Twitter est vraiment un échantillon du monde.

Ma première réaction en voyant Twitter, fut: “Mais qu’est ce c’est que ce truc? Comment est-ce possible de passer sa journée à raconter sa vie?” Car il n’est pas rare de voir des utilisateurs poster plusieurs tweets par heure. Par la suite, en découvrant Seesmic http://www.seesmic.com/ (voir ici), je me suis enregistré sur Twitter et c’est ainsi que, par le biai des autres utilisateurs de Seesmic, je suis entré dans l’univers de Twitter, le “Twitterverse”.

Ce qui me plait beaucoup est la flexibilité de Twitter, notamment la possibilité de “suivre” et d’ “être suivi”. Contrairement a Facebook, par exemple, ou on est obligé d’être l’ami de ceux qui sont nos amis, sur Twitter, cette relation n’est pas nécessairement réciproque. Le fait de savoir qu’on peut suivre et être suivi librement permet de poster sans se soucier de “polluer” la timeline: si ce que je dis n’intéresse pas quelqu’un, cette personne n’a qu’à ne pas me suivre.

La simplicité de Twitter est aussi un atout: offrir juste le strict minimum, et un API pour permettre à d’autres d’y ajouter des fonctionnalités. Twitter est une mine d’information, et si on l’utilise correctement, peut devenir utile outre son aspect ludique.

Ceci étant dit, je trouve toujours (peut-être pas autant qu’au début) que le rapport “signal-bruit” est faible. A part peut-être quand il s’agit d’amis proches, on n’est pas toujours intéressé de savoir qu’untel s’est brossé les dents ou a fait la grasse matinée. Un peu de vie quotidienne est sympa, car cela donne un côté “humain”, mais en ce qui me concerne, j’attends davantage de cet outil, notamment pouvoir l’utiliser pour diffuser ou obtenir l’information. C’est la raison pour laquelle je suis relativement sélectif par rapport aux gens que je suis, sans quoi je risque de ne suivre plus personne.

Quand je vois aujourd’hui l’évolution de l’intérêt que je porte à Twitter, celui-ci pourrait bien être décrit par ce graphe. J’ai le sentiment que Twitter est un outil intéressant, mais reste à voir dans le long terme (selon les cas, le graphe pourrait ressembler à celui-ci). Si Twitter n’est pas un mode de communication nouveau à l’instar de l’e-mail ou du SMS, c’est en tout cas un rendez-vous du Web 2.0 à ne pas manquer!

posted in Opinion | 2 Comments

12th 3月 2008

Fabrication du miso – How to make miso

Last week, I made miso, you know, a brownish paste made of fermented soybeans, used in japanese cooking, especially for miso soup (味噌汁 miso shiru). So here is the recipe of homemade miso.

First remark: it is recommended to prepare miso in the winter (preferably in February; I started a bit late…), to avoid mold.

La semaine passée, j’ai mis la main à la pâte pour fabriquer du miso. Pour rappel, le miso est cette pâte brunâtre faite de soja fermenté, que l’on utilise dans la cuisine japonaise, particulièrement dans la soupe (味噌汁 miso shiru). Et je vais donc tenter de vous résumer le procédé de fabrication du miso.

Notons pour commencer qu’il est recommandé de fabriquer le miso en hiver (de préférence au mois de février; je m’y suis pris un peu tard…), pour éviter que de la moisissure se forme.

Ingredients / Ingrédients

You will need / Vous aurez besoin de:

  • 1 kg soybeans / 1 kg de grains de soja
  • 1 kg rice malt / 1 kg de malt de riz
  • 500g salt / 500g de sel*
  • water / de l’eau

* salt at 12.5% : 500g, at 11.5% : 450g (do not use salt of concentration less than 11.5%)
sel à 12.5% : 500g, à 11.5% : 450g (ne pas utiliser du sel de concentration moindre que 11.5%)

Fabrication process / Procédé de fabrication

1. Soak dried soybeans in water for 12-16 hours (put about 2-3 times more water than the beans in volume)

Faire tremper les grains de soja dans l’eau pendant 12 à 16 heures (mettre 2 à 3 fois plus d’eau que de soja en volume).

2. Cook soybeans in water for about 2h: they should become soft enough that you can crush them with your fingers.

Cuire les grains de soja dans l’eau pendant 2 heures environ: les grains doivent être suffisemment mous qu’on puisse les écraser du bout des doigts.

3. Remove the beans from water. !!! Be sure to keep the cooking water for later.

Egoutter les grains de soja. !!! Attention de garder l’eau de cuisson pour plus tard.

4. Mash soybeans.

Ecraser les grains de soja.

Mash up soy beans   Soy beans paste

5. Mix rice malt with salt.

Mélanger le malt de riz et le sel.

Mix rice malt with salt

6. Mix the malt & salt with soybeans. Add cooking water as needed so that it becomes like clay.

Mélanger la mixture obtenue avec les grains de soja. Ajouter de l’eau de cuisson au besoin, jusqu’à ce que le mélange ait la texture de la terre glaise.

Mix all together   Add cooking water to soften

! Don’t use water other than the cooking water, in order to avoid mold.
! Ne pas utiliser de l’autre autre que l’eau de cuisson, afin d’éviter la moisissure.

7. Make little balls with the mix, and put it in a jar by making sure there is no air gap.

Former des boulettes de pâte et les mettre dans une jarre en veillant à ce qu’il n’y ait pas de fentes d’air.

Make balls to eliminate air   Stuff balls in a big jar

8. After having covered the paste with a plastic wrap, put a hermetic lid on the jar and a weight on it to keep in closed.

Après avoir recouvert la pâte d’un film plastique, fermer la jarre au moyen d’un couvercle hermétique et poser un poids pour la maintenir fermée.

Wrap with plastic film

9. Put the jar in a cool and dark place and wait until fermentation is done (about mid to end of July).

Placer la jarre dans un endroit sombre et frais et attendre la fin de la fermentation (environ mi- à fin juillet).

Enjoy and bon appétit!

posted in Hobby | 7 Comments

1st 3月 2008

Software Testing: Dogmatic or Pragmatic?

As a software engineer, and particularly in the medical field, software testing is a subject I find very important, so I’d like share with you some thoughts about it.

I watched on InfoQ a debate about TDD which took place at JAOO ’07 with Jim Coplien and Bob Martin. Martin started the debate by declaring: “it is irresponsible for a developer to ship a line of code he has not executed in a unit test.

First thought: of course! We, software engineers, learn by experience that code which has not been executed (tested) cannot be considered working (understand: should be considered not working). So yes, Martin is right. We tend to like clear and straight statements, because they are easy to understand and agree with: yes, every line of code should be executed in a unit test. But when you think of it, there are several problems with this:

  • Is it because a line has been executed in unit test that it is properly tested? Read: 100% code coverage in terms of executed line of code is not that meaningful in itself: I can write 100% coverage tests and still ship buggy code.
  • (Assuming you write meaningful tests:) What is the cost of writing unit tests to achieve this 100% coverage? And is the cost justifiable, does it really add value for the customer?

Recently, I also read this article on Javalobby: Practical Unit Testing. And I liked it, because it is more balanced and reflected than the single statement of Martin.

In fact (and this is the tricky problem in software testing): the most meaningful test is the most difficult to write. To take a practical example: in my organization, (a year or two ago) we’ve been an using automated test tool called Agitator (by Agitar Software; note that it is now part of a tool called AgitarOne). This tool basically automatically generates tests based on Java code and allows you to “agitate” your code, that is, run methods with all sorts of arguments, to try finding bugs. The problem is if you agitate your code “randomly”, at best, you find trivial bugs such as lack of null-checking etc. On the other hand, if you want to use the tool in a meaningful way, you need to spend a lot of time creating mock classes and test datasets, to introduce domain knowledge in your tests (which the tool does not have). Whether you do it using using a tool such as Agitator, a xUnit framework, or manually, this effort is not going to change a lot. (I’m not saying you should not use a tool, but don’t think using a tool will substantially reduce the effort of writing meaningful tests).

The goal of software testing is simple to understand: ship bug free code. But it is extremely difficult to achieve due to the gigantic size of the search space. And it is therefore difficult to give good advices on how to do that in practice. In my opinion, we ought to be very careful with dogmatic statements, and always ask ourselves how to increase test efficiency (increase pay-off for the effort spent in writing tests), rather than increase test coverage.

posted in Opinion, Software | Comments Off on Software Testing: Dogmatic or Pragmatic?