Zlib::BufError et repository de gems down

Posted in planet on February 9th, 2010 | Comments Off

Rails 3 enfin en beta

Fin 2008, les développeurs de Merb et Rails ont annoncé qu'ils allaient joindre leurs efforts pour sortir un Rails 3 qui combinerait les avantages de Rails et ceux de Merb. Depuis, nous avons porté beaucoup d'espoirs qui s'annonce très prometteuse, mais qui est également une source de frustration que cette version ne soit pas déjà disponible. Enfin, la semaine dernière, Rails 3 est officiellement sorti en beta (avec les release notes détaillées).

Pour le moment, Rails 3 reste encore le domaine des développeurs aventureux, ceux qui n'ont pas peur de rencontrer des bugs. Par exemple, de nombreux plugins ne sont pas encore compatibles avec Rails 3 (railsplugins.org est une bonne source pour connaître la liste de ceux qui le sont).

Si vous faites parti de cette catégorie, alors deux choix s'offrent à vous. Vous pouvez commencer une nouvelle application avec Rails 3. Le 200ème railscast est un très point de départ pour ça. L'autre choix, plus ambitieux, est de porter une application Rails existante vers Rails 3. Je vous conseille alors de vous faire aider par le plugin rails_upgrade en vous laissant guider par les explications du peepcode Rails 3 Upgrade.

Dans tous les cas, il est intéressant de commencer à se plonger dans les nouveautés de Rails 3. Les articles sur le sujet sont dispersés sur de nombreux blogs, mais des listes permettent de s'y retrouver. Celle de Ruby Inside me semble être la plus complète pour le moment.

Je vous encourage également à participer à l'initiative Give Back to Open Source. C'est très simple : prenez votre plus gros projet Rails, regardez les gems et plugins que vous utilisez, et pour chacun d'eux, contribuez en retour : donnez de l'argent, corrigez un bug, écrivez de la documentation, ou simplement, remerciez son auteur. L'important est de donner en retour.

Posted in planet on February 8th, 2010 | Comments Off

How to upgrade plugins to Rails 3.0

Rails 3.0 beta is out and it’s now time to upgrade all the plugins available. To show you how to do it I’ve decided to create a small plugin compatible with Rails 2.x and Rails 3.0. It’s a wrapper around Rack::Cache to insert it automatically in a Rails application.

It’s a gem

First things first we create the gem we will name rails-cache. Thanks to Jeweler it’s dead easy. Just a few lines of code in a Rakefile and it’s done:

To create the VERSION file a echo "1.0.0" > VERSION is enough.

Rails 2.x way

The code of the gem will be in lib/rails/cache.rb and it’s just the insertion of the Rack::Cache middleware:

We build the gem with rake build and we install it with gem install --local pkg/rails-cache-1.0.0.gem. Then we need to load it in our environment.rb:

Rack::Cache is now plugged with the Rails application!

The new way

Rails 3.0 comes with Bundler. A cool thing with Bundler is that you can load a gem which have a custom path:

The :path option is the path to our gem. We have a lot of solution to do the same in Rails 2.x, with a plugin instead of a gem for example, but it is not as elegant as with Bundler (Bundler is usable with Rails 2.x).

To create a plugin for Rails there’s an object for that now, Rails::Railtie. So we just need to write an object which inherit from Rails::Railtie in lib/rails/cache.rb:

The gem has been upgraded to Rails 3.0!

Rails 2.x and 3.0 in a gem

This is just an example here, but it’s possible there’s a better solution:

And you can find the whole code on GitHub.

More about Plugins/Engines

• José Valim has written a draft documentation about Rails::Railtie, Rails::Engine and Rails::Application.
• Yehuda Katz has made a blog post about it.
• rails3_datamapper is a good example to see how to write a Rails 3.0 plugin.
• The latest commits for CarrierWave have been made to upgrade it to Rails 3.0.

Posted in planet on February 5th, 2010 | Comments Off

Real World Node.js - Redis and streaming

Non-blocking async I/O frameworks are the new hotness, I’ve already said it. But aside the buzzwords, what can we do with these frameworks? Here’s a few examples using Node.js.

Track users with Redis

Rick Olson has developed a library to track what users are on which pages using Redis to store the data.

Now you can track users in real-time! It’s a neat feature to know who is editing a wiki page at the same time as you but real-time generates a lot of requests. If your server blocks the process for each request your server is gonna be stuck quickly.

Thanks to Node.js and the async Redis client your server will be in better shape.

Streaming

Remember my article about Twitter Stream with Websockets? There’s the same here but with Node.js. As you can see the RabbitMQ part is not present because it is not really necessary with a non-blocking framework. But having a queue is recommended at some point (generally when you use more than one process).

Streaming with a classic web framework is hard to code (= to avoid blocking the process). With Node.js you almost don’t realize that you stream data!

Here’s some useful code about streaming with Node.js:

• In addition to the tracker with Redis, Rick Olson has also developed a Twitter Stream library for Node.js.
• You can stream file uploads.
• In fact New Bamboo has a long article about different streaming techniques with Node.js
• If you want to use Comet with less than 10 lines of code, Faye is for you.

There’s more

Don’t forget to check out the Node.js wiki to have a longer list of applications.

Posted in planet on February 3rd, 2010 | Comments Off

Links of link lists about Rails 3

There’s a lot of articles about Rails 3 out there and it’s difficult to keep the list up to date. But here’s 3 pages full of links about the Rails 3 :

• Rails 3 reading material by Medium Exposure
• On the way to Rails 3 - a link list by Rails Love
• Rails 3 release notes. There’s a bunch of links with the very useful release notes.

These lists are already obsolete because José Valim has just published another article about Rails 3 I18n changes.

Rails 3 beta/RC? should be out today or tomorrow but you have a lot to read now ;)

Posted in planet on February 2nd, 2010 | Comments Off

Rails 3 et la protection contre les attaques XSS

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 :

<script>alert('All your base are belong to us!');</script>

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 :

Hello <%=h @name %>

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 :

Biographie : <%=sanitize @bio %>

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 mai 2009décembre 2009janvier 2010fé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 :

Hello <strong><%= @name %></strong>

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 :

<%= tag(:p, "<script>alert('hello');</script>") %>  # => "<p>&lt;script&gt;alert('hello');&lt;script&gt;</p>"

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 :

<%= raw @site_title %>

def evil_js
  "<script>alert('This site is evil. Mwahahah!');</script>".html_safe
end

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

Posted in planet on February 1st, 2010 | Comments Off

Release du gem has_media

AF83 sort une gem que nous utilisons dans nos projets de sites communautaires. Has_media est une bibliothèque pour ActiveRecord, pour gérer les médias dans les modèles avec une simple déclaration :


class User < ActiveRecord::Base
has_one_medium :avatar, :only => :image
end


On ajoute avec cette ligne un "champ" image pour un utilisateur. Il ne reste plus qu'à ajouter un file_field :avatar dans votre formulaire pour que l'image soit associée à l'utilisateur. L'upload est géré par carrierwave. Les méthodes de classe has_one_medium ou has_many_media ajoutent automatiquement les getter et setter pour l'avatar d'un utilisateur.

Les validations sont faites automatiquement selon le type de média défini par l'option :only => :image.

Cas d'utilisation :

# Créer la migration
./script/generate has_media



# Ajouter la gem dans config/environment.rb
config.gem 'has_media'



# Changer les options de has_media dans config/initializers/has_media.rb
HasMedia.directory_path = "media" # Placer les médias dans Rails.root, 'public', 'media'
HasMedia.directory_uri = "/media"
HasMedia.errors_messages = {:type_error => I18n.t('has_media.errors.type_error')}



# Pour le modèle voir plus haut et sur le formulaire
<p>
<%= f.label :avatar %>
<%= f.file_field :avatar %>
</p>
</code>


HasMedia ne gère pas les thumbnails (AF83 utilise une autre application pour cela), mais c'est facilement faisable avec carrierwave.

Plus d'informations : http://github.com/AF83/has_media
Installation : gem install has_media

Posted in planet on February 1st, 2010 | Comments Off

Outils pour une nouvelle charte graphique

Pour un de nos projets web, nous allons changer la charte graphique. Le projet en question est codé avec le framework Ruby on Rails, ce qui implique de passer sur chacun des fichiers dans app/views pour vérifier le markup, de modifier les feuilles de styles et de s'assurer que le tout est cohérent sur toutes les pages du site. Comme le site est conséquent, cela risque de ne pas être tout simple. Aussi, ai-je écrit deux scripts pour nous aider.

Le premier script sert à extraire toutes les URL appelées depuis les fichiers de logs Rails :

Le second script permet d'ajouter des commentaires HTML au début et à la fin de chaque fichier dans app/views pour l'identifier depuis le code source de la page HTML générée :

Je pense que cela va nous aider dans notre approche, mais je me demande s'il n'existe pas d'autres trucs pour cela. Avez-vous déjà été confronté à cela ? Si oui, comment vous en êtes vous sorti ?

Posted in planet on January 29th, 2010 | Comments Off

10 gems Ruby que nous utilisons sur nos projets

af83 utilise Ruby on Rails pour certains de ses projets. De projet en projet, nous prenons des habitudes comme réutiliser certains gems. Je souhaite vous faire partager la liste de ces gems. Cette liste n'a rien d'extra-ordinaire. Ce sont principalement des gems très classiques mais qui méritent d'être mis en avant.

1. Will Paginate est un plugin Rails pour gérer la pagination. Il est depuis longtemps la référence dans ce domaine et il continue de s'améliorer sans pour autant perdre sa simplicité. Indispensable. http://wiki.github.com/mislav/will_paginate/
2. Authlogic est une solution complète pour l'authentification et la gestion des utilisateurs. C'est toujours assez délicat de gérer les mots de passe des utilisateurs, les activations de compte, les mots de passe perdus, mais ce gem apporte une manière propre de le faire en gardant une haute exigence de sécurité. http://rdoc.info/projects/binarylogic/authlogic
3. Acts as state machine offre une solution très appréciable pour gérer des états sur les modèles, et les transitions entre ces états. Rails 3 offrira un module State Machine fortement inspiré de acts as state machine. En attendant, acts as state machine reste indispensable. http://github.com/rubyist/aasm
4. Friendly_id est un gem bien pratique pour avoir des URL très parlantes. Il permet de créer des slugs et permalinks très facilement en vous évitant les surprises : historique de slugs, mots réservés et support d'unicode sont de la partie. http://norman.github.com/friendly_id/
5. Thinking Sphinx est une bibliothèque pour connecter ActiveRecord au service de recherche fulltext Sphinx. Son DSL offre de nombreuses possibilités pour faire des recherches avancées sans difficultés. http://freelancing-god.github.com/ts/fr/
6. HTML Entities est un moyen très simple d'encoder et décoder les entités HTML. http://htmlentities.rubyforge.org/
7. FasterCSV est une bibliothèque pour manipuler des données au format CSV. Nous l'utilisons sur quasiment tous nos projets pour fournir des exports CSV des données présentes sur le site web. http://fastercsv.rubyforge.org/
8. rspec est un framework incontournable pour spécifier le comportement de nos applications et nous assurer qu'il n'y ait pas de regressions. http://rspec.info/
9. factory_girls permet de remplacer les fixtures de Rails, et d'avoir des données pour les specs qui soient faciles à maintenir au fur et à mesure des évolutions. http://github.com/thoughtbot/factory_girl
10. Pour finir, af83 utilise également has_media, une bibliothèque maison pour la gestion des médias. http://github.com/AF83/has_media

Posted in planet on January 28th, 2010 | Comments Off

Pourquoi Ruby et Ruby On Rails dans le développement d’application web ?

Cette question a été posé dernièrement sur la Mailling List de RailsFrance. Effectivement, si on veux promouvoir Ruby dans le monde informatique français, il faut pouvoir argumenter pourquoi on trouve que c'est une bonne idée.

Tout le monde est en droit de se poser la question. Voici donc, pour moi, l'avantage de Ruby par rapport aux autres technologies à l'heure actuelle.

Ruby c'est fun

Matz, quand il a créé Ruby, il a voulu faire un langage fun avec lequel il pourra s'amuser à coder. Aujourd'hui tous les développeurs Ruby diront à peu près la même chose. Coder en Ruby est plaisant. L'avantage de ce point est qu'un développeur Ruby est plus détendu. Un développeur détendu est un développeur plus heureux. Un développeur plus heureux est motivant pour une équipe. Un développeur heureux essayera de faire son travail proprement. L'ambiance d'une équipe de développeur Ruby peux ainsi être agréable. Moins de stresse sur un projet, c'est un projet qui pars avec un peu plus de chance de réussir.

Ruby aime les tests

La communauté Ruby actuelle est convaincu par l'utilité des tests unitaires. Ainsi, chaque librairie est poussé par la communauté à avoir des tests. Beaucoup de développeur moi y compris privilégierons plus une librairie avec des tests unitaires plutôt qu'une sans aucun tests.

Cette philosophie permet d'avoir un environement de développement de test simplifié directement dans Rails. Pas besoin de se prendre la tête pour faire des tests. Si vous faites pas de tests de base. Soit vous ne voulez pas en faire, ce que je ne recommande pas. Soit vous le faites exprès.

Ruby aime le cloud

En ce moment, l'évolution logique du net est le Cloud Computing. L'idée du Cloud Computing est simple. Nos sites internet ne sont plus hébergés sur une seule machine. Les services sont séparés pour améliorer la scallabilité. Au sein de la communauté Ruby, les développeurs sont très attaché à cette idée. Ainsi beaucoup d'utilitaires pour gérer et utiliser son cloud commence à voir le jour comme Chef. L'architecture même de Rails permet de facilement sortir de Ruby On Rails pour ainsi utiliser son Cloud. ActiveRessource en est la preuve.

Mais coder dans un Cloud implique de coder plusieurs briques. Le Ruby a des bindings pour tous ces utilitaires, comme les systèmes de queues ou les bases de Données Non-Relationnelle. Je ne dis pas que les autres ne peuvent pas le faire. Mais là encore c'est un effet de groupe. Chaque développeurs ruby a envie de jouer avec un Cloud. De plus en plus on pense en cloud.

Les plugins de Rails

Ruby On Rails possède une très grande quantité de plugins. On peux ainsi facilement trouver la petite brique que l'on cherche pour sa propre utilisation. C'est plus que l'utilisation d'un module Drupal. Car là nous sommes dans un environement facilement modifiable et sans aucune limitation. Chose que Drupal peux vite avoir.

Les Ressources

Le plus grand reproche que l'on fait actuellement au choix de Ruby On Rails, c'est le manque de ressources. Effectivement, les ressources de développeurs Ruby sont plus faible que pour d'autres langages. Mais ceci est selon moi un faux problème. L'apprentissage de Ruby et Ruby On Rails est assez simple si on connait la logique Objet. Ainsi, n'importe quel développeur Java peux tout à fait se mettre à Ruby et Ruby On Rails. Donc avec un expert Ruby/Rails, on peux former facilement une équipe complète et compétente.

Cet argumentaire n'engage bien sûr que moi et peux donc être sujet à caution.

Posted in planet on January 28th, 2010 | Comments Off