veille technologique

• http://googlewebmastercentral.blogspot.com/2010/03/googles-seo-report-ca...
  Google a mené en interne une enquête sur le respect des bonnes pratiques SEO dans leurs propres produits. Les résultats ont été rendus publics, même s'ils ne sont pas flatteurs. On peut par exemple se rendre compte que même les éléments de base comme la balise title sont très mal utilisés.

• http://martinfowler.com/bliki/VcsSurvey.html
  Cette enquête sur les outils de gestion des versions montre que le trio Subversion, Git et Mercurial est très apprécié. Ceci est d'autant plus vrai quand on les compare aux équivalents propriétaires que ce sont ClearCase ou Microsoft VSS. Si l'on rentre plus dans les détails, on se rend compte que Git sort du lot : 65% de ses utilisateurs considèrent que c'est le meilleur outil pour leurs besoins, contre 20% pour svn et 33% pour hg.

• http://github.com/progrium/DrEval
  DrEval est un serveur web qui exécute du javascript et renvoie le résultat. Sa particularité est d'avoir été conçu spécialement pour faire tourner des scripts utilisateurs dans des environnements sandboxés. Cela en fait donc un serveur applicatif idéal pour utiliser des webhooks créés par des utilisateurs.

• http://www.regexprn.com/2010/03/nosql-paradox-of-choice.html
  Cet article met un avant le paradoxe du choix pour les bases de données NoSQL : il y a un choix très large de bases de données NoSQL, mais cela n'est pas forcément pour les aider à devenir populaires. En effet, choisir une base de données ne se fait pas à la légère et prends du temps. Le nombre important de bases de données fait qu'il devient difficile de trouver la base de données qui nous convient, et dans le doute, il est parfois plus simple de rester sur une base de données relationnelle. Il serait donc bienvenu qu'une base de données NoSQL (ou un nombre très réduit) sorte du lot.

• http://dean.edwards.name/weblog/2010/03/ie7js-update/
  IE7.js est une bibliothèque javascript qui vise à combler les déficiences des différentes versions d'Internet Explorer Elle corrige notamment des problèmes HTML et CSS, et permet d'utiliser des PNG transparents sous IE6. En théorie, cela doit permettre de se concentrer sur les standards, tout en faisant un site qui va passer sous IE.

• http://jashkenas.github.com/coffee-script/
  CoffeeScript est un langage qui se compile vers du javascript. Il apporte une syntaxe qui se veut plus agréable : pas de points-virgules, utilisation simplifiée des objets et tableaux, interpolations pour les chaînes de caractères, etc. De plus, le code javascript généré respecte les règles de JSLint et n'est pas pénalisant pour les performances. Le seul point que je regrette est le choix des espaces significatifs à la Python.

• http://www.smashingmagazine.com/2010/03/08/entering-the-wonderful-world-...
  Christian Heilmann nous offre ici un tour d'horizon sur les données géospatiales. Il aborde différentes techniques comme la récupération de la localisation d'un utilisateur via les API Geo du W3C, le géocodage (transformer une adresse en latitude/longitude) et son inverse (trouver le nom d'un lieu à partir de ses coordonnées). Cet article est vraiment un bon point de départ pour savoir ce qu'il est possible de faire et trouver les pointeurs pour le faire.

• http://jashkenas.github.com/docco/
  Docco est un outil de génération de documentation à partir des commentaires d'un code source. On parle de Literate programming, car le code et sa documentation sont mélangés au sein d'un même document et évoluent simultanément. Docco génère un fichier HTML avec deux colonnes : la première contient les commentaires transformés via Markdown, et la seconde reprend le code source avec de la coloration syntaxique grâce à Pygments. À noter : il existe également un portage en Ruby de Docco qui se nomme Rocco.

• http://ozmm.org/posts/man_what.html
  Chris Wanstrath explique l'intérêt des pages de man, à savoir être une documentation syntaxique permettant de trouver facilement une information précise. Il fait également le tour des outils qui permettent de les créer, les trouver et les lire.

• http://vagrantup.com/
  Vagrant est un outil en ruby qui permet de construire facilement des machines virtuels pour des projets. Il facilite notamment tout ce qui est la mise en place de l'environnement (via Chef), ainsi que le partage des fichiers entre l'hôte et l'environnement virtuel. Je me verais bien l'utiliser pour partager un environnement complexe sur certains projets avec des personnes qui n'interviennent que ponctuellement.

• Le blog de Bruno Michel

Le web évolue en permanence. Certaines tendances ne sont que des effets de mode passagers, tandis que d'autres transforment de manière profonde le web. En particulier, ces évolutions peuvent amener de nouvelles façons de concevoir et construire les sites web.

En ce moment, nous entendons de plus en plus parler de « web temps réel ». Cette dénomination est assez floue, mais derrière elle, on peut retrouver le fait que l'information navigue rapidement et relativement facilement entre le sites web : google va récupérer dans google buzz vos images en provenance de flickr et picasa, de nombreux sites intègrent des flux twitter, même ce blog récupère de l'information en provenance de github et de delicious.

Cette approche a des conséquences techniques non-négligeables. Les sites web ne sont plus juste un intermédiaire entre une base de données et des utilisateurs, mais sont de plus en plus obligés de se communiquer entre eux. Or, la communication entre deux sites web est un phénomène assez lent à cause de la latence. Cette lenteur est toute relative : en générale, c'est de l'ordre de quelques centièmes de secondes. Pourtant, cela a un impact énorme sur des applications web qui étaient jusque là capable de générer une page web en moins d'un dixième de seconde.

Les frameworks actuels comme Ruby on Rails ou Django reposent leurs capacité à encaisser un trafic conséquent sur cette rapidité, mais quand ils se retrouvent littéralement à piétiner en attendant que d'autres sites web répondent, cela peut rapidement devenir le drame : le site s'engorge puis finit par ne plus répondre.

La solution existe et est bien connue : il faut changer de paradigme de scalabilité au profit d'architectures asynchrones. L'idée est simple : quand un site web attend la réponse d'un autre site web, il va en profiter pour commencer à répondre à un deuxième client, puis à un troisième, un quatrième, etc. Il va alors se retrouver à gérer un certain nombres de requêtes en parallèle.

Ça ne paraît pas très compliqué, mais pour le développeur, c'est l'enfer : il doit savoir quand il peut traiter une requête, quand il doit passer la main, éviter à tout prix de mélanger les données de l'un avec celle de l'autre, etc. À l'heure actuelle, ce style de programmation est vraiment très exigeant, et une erreur est très vite arrivée.

Heureusement, des personnes ont décidées de s'attaquer à ce problème et de proposer des outils pour simplifier ça. Les frameworks Event-Driven commencent à apparaître, mais cela demande de mettre en place de nouvelles API, d'apprendre de nouveaux réflexes aux développeurs.

Par exemple, là où un simple tweets = Twitter::Base.new(credentials).user_timeline aurait suffit pour récupérer les tweets d'un utilisateur (en Ruby avec le gem twitter), il faut utiliser une approche bien plus compliquée dans un monde asynchrone (exemple libre) :

Comme on peut le voir, le code intéressant doit maintenant se trouver à l'intérieur de la fonction de callback passée à close. On va alors avoir tendance à imbriquer des fonctions dans d'autres fonctions, elles-mêmes imbriquées dans d'autres fonctions, et ainsi de suite. Au final, cela le rend le code difficilement lisible, et assez peu flexible.

Les créateurs de frameworks sont à la recherche de solutions pour proposer des API plus agréables à utiliser. EventMachine, coté Ruby, et Tornado, coté Python, essayent d'encapsuler le tout dans des classes. Cela donne un code relativement lisible, mais très verbeux (trop à mon goût) :

D'autres frameworks comme Node.js tâtonnent encore. Cela se voit par exemple sur ce long de fil de commentaires, qui a amené à la suppression des Promises dans node-v0.1.30. L'article "Do" it fast! est également une réflexion très intéressante sur le sujet.

Une des solutions possibles est de s'inspirer du modèle de passage de messages proposé par Erlang ou des chans et goroutines de Go :

Pour conclure, je dirais que la seule chose qui est sûr aujourd'hui, c'est que les frameworks de demain seront asynchrones et proposeront des API adaptées à ce nouveau fonctionnement, mais pour le moment, nous n'en sommes encore réduit à explorer les différentes possibilités.

• Le blog de Bruno Michel
• 1 attachment

Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
Google Chrome Frame

• Le blog de Bruno Michel

Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
OS & Navigateurs

• Le blog de Bruno Michel

Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
Campagne Microsoft

• Le blog de Bruno Michel