Ergonomie, Rails et Architecture de l'information web (2.0)

Si comme moi vous possédez un iPhone première génération jailbreaké et désimlocké, que ce soit parce que vous ne pouviez pas attendre la sortie officielle ou pour profiter des applications tierces, peut-être êtes-vous frustré de ne pouvoir profiter des nouveautés de l’OS fourni avec l’iPhone 3G. Qu’à cela ne tienne, la dev team a travaillé pour vous et a sorti hier le Pwnage tool, qui permet de s’attaquer aux iPhones et iPhone 3G – malheureusement sans desimlockage – mais également aux iPod Touch.

Finie la ligne de commande et les manipulations compliquées, cette fois tout se fait nativement en graphique et en quelques étapes.

La phrase du jour (un peu vieux, mais quand même) :

Saying “Rails doesn’t scale” is like saying “my car doesn’t go infinitely fast”. Alternatively, saying “We’ll have no problems scaling because we’re using Django” is like saying “I will win every race because my car is the most powerful”. Maybe so, but you suck at driving, and you’re up against professionals.

If you’re having scalability problems and blaming it on a single technology, chances are, you’re doing it wrong.

Shut up about scalability, no one is using your app anyway.

En termes de planification, la maintenance évolutive d’un projet web est toujours la plus délicate à mettre en place. D’abord parce qu’elle ne participe pas du cycle de développement normal de ce dernier, mais de son cycle d’exploitation, elle risque donc interférer avec celui-ci. Ensuite parce qu’elle fait souvent participer de nombreux intervenants de culture différente, aux intérêts parfois divergents au sein d’une même structure. Enfin parce qu’elle répond souvent à des impératifs extérieurs qui la rendent difficile, sinon impossible à planifier.

Après confier la maintenance de ses projets web et Les cycles de maintenance collective, ce troisième volet de notre série sur la mise maintenance des projets web vous invite à vous intéresser à la maintenance évolutive.

Pas de repos pour les braves en ce 14 juillet – normal il est hollandais, il n’en a donc pas grand chose à faire – puisque Hongli Lai vient d’annoncer la sortie de Passenger mod_rails 2.0.2, qui corrige un certain nombre de bugs critiques. Passenger est un module Apache qui rend le déploiement d’une application Ruby on Rails, mais pas seulement, aussi simple qu’un site en PHP, retirant la principale épine du pied de mon framework web favori.

Cette nouvelle version de Passgenger corrige en particulier une importante fuite de mémoire qui survenait chaque fois qu’un client web quittait le ApplicationPoolServerExecutable. Celle-ci, après avoir mis le serveur à genoux et rendu le site indisponible pendant un week-end entier m’avait finalement forcé à downgrader en 1.0.5 nettement plus stable.

Et comme une bonne nouvelle n’arrive jamais seule, cette version arrive avec un paquet Ubuntu tout chaud.

David vient d’annoncer le passage de Spam Karma en GPL, ce qui, quand on connaît le monsieur, est à la fois une bonne et une mauvaise nouvelle. Une bonne, car cela signifie que ce projet, au point mort depuis un moment, va connaître une nouvelle jeunesse. Une mauvaise nouvelle puisqu’elle signifie que David, qui a été un contributeur phare de la communauté Wordpress, en a définitivement tourné la page, pour les mêmes raisons que moi il y a trois ans.

Pour l’instant, honnêtement, il n’y a pas grand chose, mais c’est déjà ça…

Je suis tombé hier soir à la faveur de mes lectures vespérales et inter-plats sur Think Before You Voicemail, un intéressant – une fois n’est pas coutume – article publié sur Techcrunch US. Michael “Captain Obvious” Arrington y constate la mort du répondeur téléphonique, cette survivance de l’entreprise d’un autre âge, et y oppose deux alternatives que sont l’email et les services de transformation des messages vocaux en email.

Effectivement, hors d’un contexte émotionnel fort, le répondeur vocal est mort et bien mort, et j’irai jusqu’à dire que c’est tant mieux. En revanche, je crois, je suis même certain qu’Arrington est à coté de la plaque en ce qui concerne ses remplaçants ou successeurs.

Pourquoi faut-il que, chaque fois que recherche d’un album ou un morceau sur les sites de téléchargement légaux, celui-ci en soit absent alors qu’il est systématique à portée de main sur bittorrent ?

Il y a un an et demi, je supprimais la blogroll de ce site, principalement parce que, sur le web, les éditorialistes importaient moins que les contenus qu’ils publiaient ici et là. Mais également pour des raisons techniques : un blog se lit via un lecteur de flux, pas directement, et une blogroll perd donc tout son sens dans ce contexte.

Depuis quelques temps, vous êtes plusieurs à me demander quels sont mes “indispensables”, en termes métier, c’est à dire finalement les sites dont je lis systématiquement les articles de la première à la dernière ligne. En ayant marre de répondre systématiquement la même chose, j’ai profité de ma dernière pause café pour les ajouter dans ma sidebar.

Je viens de tomber sur cette vidéo très didactique émise par Google à destination des webmestres se retrouvant un jour mis à l’index par Google. Il est d’ailleurs amusant de voir comment, dans l’univers des moteurs de recherche, il est important d’être bien indexé, alors même qu’être mis à l’index ne possède en rien une connotation glorieuse.