M'enfin ?!?

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 13 décembre 2009

Je m'interroge sur twitter

Je connais Twitter depuis longtemps, mais je n'ai jamais senti le besoin de m'y inscrire. Et pourtant, récemment, j'ai créé un compte twitter.

Pourquoi ?

Je n'ai pas eu une soudaine révélation sur twitter. Je ne vois pas d'intérêt particulier à twitter, comparé aux autres moyens de communications à ma disposition. Autant pour Facebook, je peux voir un intérêt (mais je ne suis pas prêt à accepter les atteintes à ma vie privée qui en découlerait), autant pour twitter, je reste perplexe.

Alors pourquoi me suis-je inscrit ? Principalement par curiosité. Je travaille sur ce que pourrait-être le web de demain (Nodzle), et twitter est sensé être le meilleur représentant du web temps-réel. On m'a fait remarquer que le meilleur moyen de découvrir twitter est encore de l'essayer, principe qui peut être illustré par cette citation :

Twitter is like sex. You can read all the stuff (or look at it) about sex all you want, but if you’ve never had it, you simply have no idea what it’s like.

Et alors ?

OK, j'ai donc créé un compte twitter et j'ai commencé à twitter. Mais ai-je été touché par la grâce divine et suis-je devenu un fervent défenseur du twit ?

Non, loin de là. Pour le moment, l'usage que j'en fais est très proche de l'IRC, mais avec de gros défauts :

  • je n'ai pas trouvé comment faire l'auto-complétion des nicks ou des hashtags ;
  • je ne sais pas non plus comment voir les réponses à une question intéressante posée par une personne que je suis ;
  • déjà confronté aux spams :/
  • c'est dur de relire les anciens messages...

Bref, je ne me suis pas converti à la religion twitter, mais je vais continuer à l'utiliser pour voir si mon opinion évolue.

mardi 9 décembre 2008

The broken window theory

La théorie des fenêtres cassées (« The broken window theory ») a inspiré les forces de police de New York et d'autres villes importantes pour lutter contre la criminalité.

Cette théorie postule que la différence entre un immeuble propre et joli, et un autre en très mauvais état peut être la conséquence d'une simple fenêtre cassée. Cette simple fenêtre cassée laisse une impression de négligence et d'impunité. Des personnes commencent à laisser traîner des détritus, puis des tags apparaissent, et en un rien de temps, l'immeuble est devenu insalubre et mal fréquenté. La morale ? Il ne faut pas laisser traîner des fenêtres cassées, mais au contraire, les réparer de suite pour éviter que des dégâts plus sérieux n'arrivent. Jusqu'à récemment, cette théorie n'était qu'une hypothèse, mais des études récentes viennent soutenir cette théorie.

Chose intéressante, les pragmatics programmers ont appliqué cette théorie au développement logiciel. Les fenêtres cassées sont alors tous les code smells : le test unitaire qui ne passe pas, le module mal documenté, le FIXME qui traîne, la fonction mal implémentée... Il est alors important de corriger au plus vite ces petits défauts, sans quoi ils vont s'accumuler et donner une mauvaise impression de la qualité du code. Et alors, ce seront des défauts de plus en plus en gros qui vont arriver, chaque développeur se disant que ce n'est pas grave s'il introduit un nouveau code louche pour gagner du temps, car d'autres développeurs l'ont déjà fait ailleurs. Le même développeur qui aurait une base de code propre, sans fenêtres cassées, n'aurait pourtant pas osé être le premier à écrire du code sale (surtout s'il sait que son code fera l'objet d'un code review, mais c'est un autre sujet).

Pour avoir déjà rencontré souvent ce cas de figure, je sais que cette analogie est très pertinente. Ne laissez pas des fenêtres cassées dans votre code !

mercredi 3 décembre 2008

Le navigateur web Arora

J'ai récemment eu besoin de résoudre des bugs sur LinuxFr.org qui était lié au moteur javascript de Safari (les #883 et #900 si vous voulez tout savoir). Étant sous GNU/Linux, je ne pouvais pas installer Safari, et bien entendu, je n'arrivais pas à reproduire les bugs sous Firefox. Toutefois, le moteur de Safari, Webkit, est libre, et il en existe des ports sous GNU/Linux.

J'ai d'abord essayé epiphany-webkit, et j'ai pu constaté le problème mais pas faire grand chose de plus. Epiphany ne me donnait pas accès à un débugger javascript et ne me donnait même pas accès à l'erreur js. Après une phase de recherche sur google, j'ai tenté un navigateur web que je ne connaissais pas (même de nom) : Arora. Il dispose de l'outil Web Inspector (en gros, un équivalent de Firebug pour Safari), ce qui m'a donné l'erreur javascript et permis de faire quelques tests dans la console intégrée. Bref, même si ce navigateur n'a rien de révolutionnaire, je suis bien content de pouvoir utiliser le Web Inspector de Webkit sous linux.

mardi 19 août 2008

Firefox & about:config

Firefox est le navigateur que j'utilise tous les jours, et ce depuis un certain nombre d'années. Au fil du temps, je me suis habitué à un certain nombre de préférences, dont certaines doivent être configurées depuis la page about:config. Pour ceux qui ne connaissent pas cette page, je dirais juste qu'il suffit de taper about:config dans la barre d'adresse de firefox pour accéder à un écran qui permet de modifier de nombreuses fonctionnalités avancées. Les noms et valeurs des préférences sont souvent obscurs. Il existe une liste relativement complète de ces préférences, mais voici ceux que j'utilise le plus souvent :

  • browser.tabs.closeButtons à 3 pour avoir un seul bouton fermer les onglets, tout à droite de la barre d'onglets, comme dans les anciennes versions de firefox.
  • browser.backspace_action à 0 pour que la touche backspace permette de revenir en arrière dans l'historique.
  • middlemouse.contentLoadURL à true pour pouvoir aller sur l'URL dans le presse-papier en cliquant juste sur le bouton du milieu de la souris (à la façon d'un coller sous UNIX).
  • browser.blink_allowed à false pour désactiver les clignotements provoqués par les balises <blink>.

Mise à jour : vous pouvez trouver 28 réglages sur Make Tech Easier.

samedi 10 mai 2008

Outils pour tracer des graphes

Je cherche depuis un certain temps un outil pour tracer des graphes. En général, j'utilise la suite Graphviz pour faire cela. Le principe est relativement simple : on décrit le graphe dans un fichier au format dot, puis on utilise un des 5 outils (dot, neato, fdp, circo et twopi) pour générer une image. Cela marche plutôt bien, mais les graphes générés sont sobres, pour ne pas dire moches (voir la galerie).

Je connaissais également LGL, mais il est surtout adapté pour tracer des graphes avec beaucoup de noeuds et/ou arêtes. Il existe aussi des outils pour tracer des diagrammes (genre Dia) qui peuvent être utilisés pour tracer des graphes, mais je préfère de loin l'approche de graphviz.

Et récemment, je suis tombé sur Nodebox : le choc, des jolis graphes ! Malheureusement, Nodebox fonctionne sous MacOSX. Il existe bien un port pour GNU/Linux sous QT, mais je n'arrive pas à utiliser le module Graph avec celui-ci :/ Shoebox est une réécriture de nodebox (sous Cairo ce coup-ci), mais j'ai l'impression qu'il n'est pas encore assez avancé pour faire quelque chose d'utile avec.

Toujours à partir de Nodebox, j'ai découvert NetworkX, mais, si j'ai bien compris, c'est une surcouche à Graphviz. Les exemples de la gallerie me semblent quand même plus jolis que ceux de GraphViz. Est-ce que l'auteur de NetworkX a passé du temps pour faire ces exemples ou est-ce que je me suis trompé sur NetworkX ? Je ne saurais dire, mais cela vaudrait sûrement le coup que j'y rejette un coup d'oeil à l'occasion.

Enfin, la solution viendra peut être du Javascript. Le JavaScript Information Visualization Toolkit (JIT) est une bibliothèque pour tracer des graphes. Ce n'est pas aussi simple que GraphViz et, pour le moment, limité aux arbres, mais cela pourrait devenir une solution intéressante. Le projet Processing.js montre que l'on peut utiliser la balise Canvas pour faire un rendu qui n'a rien à envier au Desktop. Alors qui sait, peut être que JIT pourra vraiment devenir la solution pour tracer de jolis graphes même si l'utilisation de javascript peut surprendre pour cela...

Mise à jour : je viens de découvrir un nouveau venu : Ubigraph. Les démos sont impressionnantes, mais le serveur n'est malheureusement pas sous une licence libre.

mardi 12 février 2008

Portrait of a N00b

Steve Yegge, un blogger influent qui travaille chez Google, a posté un article intitulé « Portrait of a N00b ». Comme à son habitude, c'est un très long post où il explique les différences dans la manière de coder (et commenter son code) entre un développeur peu expérimenté et un développeur avec 20 ans d'expérience.

S'en suit une digression très intéressante entre langages à typage statique (Ocaml, Haskell), langages à typage dynamique (Perl, Python, Ruby), et les langages classiques (C++, Java) à typage statique mais qui vous laisse tricher avec les types. On y trouve quelques perles :

If static types are comments, then I think we can conclude that people who rely too much on static types, people who really love the static modeling process, are n00bs.

You can write C++ like straight C code if you like, using buffers and pointers and nary a user-defined type to be found. Or you can spend weeks agonizing over template metaprogramming with your peers, trying to force the type system to do something it's just not powerful enough to express.

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done.

Mais le plus simple reste d'aller lire l'original : Portrait of a N00b. C'est long, mais ca en vaut largement la lecture. Et si vous avez encore du temps, les autres articles sont aussi des lectures recommandées.

Ai-je précisé que je me retrouve plus dans la peau du dév expérimenté que du N00b, même si c'est un prétentieux, vu que je suis encore vraiment loin d'avoir 20 ans d'expérience ?