• 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.

• http://vimcasts.org/ : ce site met diffuse des screencasts sur vim. Chaque semaine, un nouveau screencast de 5 à 10 minutes est publié, mettant en avant une fonctionnalité particulière de Vim.

• http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/ : cet article d'Ilya Grigorik discute de la pertinence des bases de données NoSQL. En particulier, il souherait voir émerger un moteur Schema-free pour MySQL. Les discussions qui ont suivies cet article sont également intéressantes.

• http://www.opscode.com/blog/2010/02/28/chef-0-8-2-release/ : Chef est un outil d'automatisation pour son infrastructure. La sortie de la version 0.8.2 est la première de la nouvelle branche, et apporte des nouvelles fonctionnalités majeures comme une API REST complète, un outil en ligne de commande, knife, totalement opérationnel, ou encore un mécanisme d'authentification plus robuste.

• http://code.google.com/p/html5media/ : cette initiative vise à offrir la balise HTML5 <video> pour tout le monde. Tous les navigateurs web ne supportent pas cette balise, et pour ceux qui la supportent, les codecs ne sont pas toujours les mêmes. Ce projet permet aux développeurs web d'utiliser la balise <video> sans avoir à se soucier de ces problèmes.

• http://rickosborne.org/blog/index.php/2010/02/09/infographic-migrating-f... : ce document est une représentation graphique d'une transformation d'une requête SQL en requête MongoDB équivalente. Elle illustre une méthode permettant de convertir systématiquement des requêtes SQL relativement complexe en requête de type Map-Reduce pour MongoDB.

• http://groups.fsf.org/wiki/Group:GNU_Social : des personnes proches du mouvement GNU ont décidé de monter leur propre réseau social décentralisé. Celui-ci vise à offrir un équivalent distribué à facebook dans un premier temps. Il devrait également permettre un meilleur contrôle des données et de sa vie privée par la suite. Tout le code est diffusé sous licence AGPLv3.

• http://bsonspec.org/ : le BSON, ou Binary JSON, est un protocole de sérialisation dans le style de JSON. Il est notamment utilisé par MongoDB, et présente des avantages intéressants si on le compare à Protocol Buffers : légèreté, traversabilité et efficacité.

• http://www.cdncatalog.com/ : ce catalogue de CDN pour les bibliothèques javascripts et CSS est une ressource utile. Utiliser pour ces bibliothèques est très pertinent, car il permet aux utilisateurs d'avoir ces versions dans le cache de leurs navigateurs, ce qui accélère le temps de chargement des pages de manière non-négligeable.

Javascript avancé

Vision Media a publié un ebook sur le javascript avancé. Il ne coûte que 4$ canadien (moins de 3€), mais j'ai appris pas mal de choses avec sur le langage javascript lui-même (pas le DOM). Ses 64 pages sont découpées en 6 chapitres :

• Closures, Scope & Context
• Prototypal Inheritance
• Advanced Meta-programming Techniques
• Behavior Driven Development with JSpec
• Creating a jQuery Clone
• Tools of the Trade

Si vous souhaitez mieux comprendre le javascript, pour l'utiliser avec Node.js par exemple, ça serait vraiment dommage de passer à coté.

http://www.dev-mag.com/2010/02/18/advanced-javascript/

Rails 3 Upgrade Handbook

Jeremy McAnally a écrit un ebook de 120 pages avec tout ce qu'il faut pour passer une application à Rails 3 (actuellement en beta). La plupart des informations sont disponibles ailleurs, sur le site officiel ou des blogs, mais il est très difficile d'avoir une vue synthétique de l'ensemble des modifications. Le prix de cet ebook, 12$, se justifie très simplement par le temps gagné. Vous aurez toutes les informations sous les yeux pour faire votre migration, et la liste des points à ne pas oublier est vraiment très pratique. Pour ma part, je ne regrette absolument pas cet achat.

http://www.railsupgradehandbook.com/

Contribuer en retour à l'Open Source

Ryan Bates a lancé une initiative qui va être, je l'espère, suivie par de nombreux développeurs. L'idée est simple : on utilise régulièrement des Logiciels Libres, notamment des plugins ou gems pour Ruby on Rails, et il est souhaitable de participer à cet effort. Pour cela, Ryan Bates propose une méthode :

1. Trouver votre projet Rails le plus important
2. Lister tous les plugins et gems que vous utilisez sur ce projet
3. Pour chacun, faites une contribution avec, au choix :
   • Donner de l'argent
   • Corriger un bug
   • Ajouter de la documentation
   • Ou, tout simplement, remercier son auteur

Je compte sur vous pour faire la différence en faveur de ses plugins et gems Libres.

http://railscasts.com/give_back

• 1 attachment

Git permet d'ignorer des fichiers par projet en les listant dans un fichier .gitignore. On peut également ignorer des motifs comme log/*.log pour ignorer tous les fichiers du répertoire log avec l'extension .log

Ce mécanisme est souvent utilisé pour ignorer les fichiers temporaires utilisés par les éditeurs de texte. On retrouve alors des motifs comme *~ (emacs) ou *.swp (vim).

Pourtant, ce n'est pas l'idéal. D'une part, ce fichier est partagé par tous les utilisateurs, alors que cet usage voudrait qu'il soit spécifique à chaque utilisateur. D'autre part, il faut recopier à chaque nouveau projet les mêmes motifs, alors qu'il serait tellement plus simple d'avoir à les lister au même endroit.

La solution existe : un fichier .gitconfig par utilisateur. En plus, c'est très simple à mettre en place.

Il faut déclarer à git quel fichier utiliser pour ignorer de manière globale, et mettre les motifs qui nous intéressent dans ce fichier :


git config --global core.excludesfile ~/.gitignore
echo "*~" >> ~/.gitignore
echo "*.swp" >> ~/.gitignore
echo ".DS_Store" >> ~/.gitignore
echo "*.tmproj" >> ~/.gitignore
echo "tmtags" >> ~/.gitignore


Voilà, ce n'était pas compliqué !

• 1 attachment

Quand on développe une application web, la sécurité est toujours une problématique à prendre au sérieux. Négligez-la et vous pouvez être sûr qu'un jour ou l'autre, un petit malin se fera le plaisir de vous montrer vos failles. Une attaque simple mais très répandue est l'injection XSS (ou Cross-site scripting). Le principe est d'envoyer du code HTML dans un site web pour qu'il soit interprété par le navigateur d'un autre utilisateur. Par exemple, on peut poster la ligne suivante sur un forum pour essayer d'ennuyer les autres utilisateurs :

Cette attaque n'est toutefois pas à prendre à la légère. Elle permet par exemple de voler les cookies d'un utilisateur et donc sa session, ou encore de lui faire des actions indésirables sur le site attaqué.

Il est donc nécessaire de se protéger de cette attaque et, rassurez-vous, Ruby on Rails a tout ce qu'il faut pour faire ça simplement. Jusqu'à maintenant, la méthode pour faire ça consiste à indiquer à Rails les chaînes de caractères qui contiennent du contenu manipulé par l'utilisateur et qui pourraient donc être dangereuses. Dans le cas le plus fréquent, une telle chaîne ne doit pas du tout contenir de balise HTML, et on peut alors utiliser le helper h qui transforme les caractères dangereux en entités HTML. Exemple :

Dans le cas contraire où l'utilisateur a le droit d'entrer du texte HTMl enrichi avec des balises HTML, il convient de limiter les balises et attributs autorisés. Le helper sanitize permet de faire ça :

Cela fonctionne très bien, mais il y a toujours le risque d'oublier un h ou un sanitize, ce qui laisserait une porte pour un attaquant. C'est pourquoi il existe des plugins Rails qui favorisent l'approche inverse, à savoir indiquer quelles sont les chaînes de caractères qui sont sûres et d'échapper tout le reste. C'est également l'approche que Rails 3 offrira lors de sa sortie en février 2010.

Dans Rails 3, les chaînes de caractères auront un attribut html_safe, qui indiquera si la chaîne est sûre. Par défaut, l'attribut vaudra false, et cette chaîne sera échappée lors du rendering.

Bien entendu, votre page HTML contient des balises et il est donc nécessaire de pouvoir construire ces balises sans qu'elles soient échappées. Tout d'abord, cette protection ne vise que des contenus venant de l'utilisateur, il est donc inutile d'échapper le contenu "en dur" des vues : seul ce qui se trouvent entre <%= et %> est concerné. Dans l'exemple suivant, le nom apparaîtra bien en gras :

Une autre source de contenus légitimes est la génération de code HTML par les helpers de Rails. Heureusement, ces helpers génèrent des chaînes de caractères marquées comme sûres après avoir échappé leurs entrées. Exemple :

Enfin, il vous reste la possibilité de marquer vous-mêmes les chaînes comme étant sûres. Pour cela, vous pouvez utilisez raw quand vous êtes dans une vue, ou appeler html_safe sur la chaîne si vous êtes dans un helper. Exemple :

Si vous souhaitez en savoir plus, je vous conseille la lecture de SafeBuffers and Rails 3.0 de Yehuda Katz.

• 1 attachment