Bounga's Home

Beaucoup d'entre vous connaissent Ruby grâce à son fort potentiel Web au travers du framework Ruby on Rails. Mais Ruby excelle dans de nombreux domaines et s'avère particulièrement efficace dans l'écriture de DSL (Domain Specific Language).

Les DSL existent depuis toujours et vous les utilisez peut-être même sans vous en rendre compte. C'est un concept très à la mode ces derniers temps parce qu'avec les langages modernes, il n'a jamais été aussi facile d'en développer un.

Le but d'un DSL (du moins en Ruby) est de proposer à l'utilisateur un langage simple qui va lui permettre d'accomplir des tâches ciblées. L'utilisateur écriera du Ruby sans même s'en rendre compte.

Nous allons voir dans ce billet comment tirer parti de ces possibilités et créer notre propre DSL.

Avec l'intégration de Rack dans Ruby on Rails, de nouveaux outils commencent à voir le jour.

L'un d'eux est particulièrement remarquable et va faciliter la vie de nombreux développeurs.

Rack::Bug est un middleware qui va vous permettre d'inspecter dans le détail vos requêtes, directement depuis votre navigateur, sur la page en cours de développement.

J'ai très récemment décidé de switcher du couple Apache / Mongrel à Nginx / Thin pour mes applis Rails, les différences de performance sont visibles à l'oeil nu et les ressources utilisées (mémoire et CPU) ont été très largement réduites. Un vrai bonheur !

Sur ma lancée, j'ai décidé de migrer également mon blog pour pouvoir me séparer d'Apache. Mon blog, comme vous le savez peut-être, tourne sous DotClear en mode PATH_INFO ce qui permet d'avoir des URLs plus élégantes.

J'ai donc voulu partager avec vous mon expérience et vous propose une documentation sur la mise en place d'un DotClear en mode PATH_INFO avec Nginx.

Voici ma petite recette qui semble très bien fonctionner (surtout depuis la ré-écriture complète de la config suite aux problèmes liés à l'espace d'administration).

Mini-billet pour vous annoncer que j'ai publié la version 2.0.0 de acts_as_nice_url qui, pour mémoire, permet de générer facilement des URL significatives dans vos projets Rails.

Cette release marque un tournant important puisque le plugin se base maintenant sur la méthode parameterize introduite dans Rails 2.2.

Pour ceux qui souhaitent continuer à utiliser ce plugin avec d'anciennes versions de Rails, il faudra se tourner vers la version 1.0.0 (qui elle fait plus ou moins la travail de la méthode parameterize qui n'existait pas avant).

Le code est disponible, comme à l'habitude, sur BitBucket.

D'après le LightHouse de Rails, la version 2.3 de Rails devrait sortir le 31 janvier.

L'annonce a fait du bruit pendant ces vacances de Noël, moi qui commençait à découvrir Merb et prendre goût à ces aspects qui le caractérisent, j'ai accueilli la nouvelle à bras ouverts.

Les équipes de développement de Rails et de Merb se sont rapprochés et veulent unir leurs efforts pour fusionner les deux projets et ainsi tirer le meilleur de chacun.

Personnellement, connaissant les caractères des principaux acteurs des deux projets, je n'aurai jamais crû ça possible ! Mais il faut croire que tout le monde a réussi à trouver un terrain d'entente et je peux vous assurer que cela ne laisse présager que de bonnes choses.

En quoi les choses vont changer ? Je vais vous l'expliquer.

Je viens tout juste de releaser Flash Helper 1.0.2

Le plugin Flash Helper est maintenant disponible en Gem ce qui permet de l'installer une fois pour toute sur le système et de pouvoir ensuite l'utiliser sans avoir à l'ajouter dans vendor/plugins pour chaque projet.

Suite à mon ticket qui proposait un patch d'ajout du support de Mercurial à script/plugin, une discussion s'est ouverte proposant de développer un gestionnaire de SCM qui aurait pour but d'être facilement extensible par un système de plugin ce qui permettrait à tout un chacun d'ajouter très facilement le support pour son SCM préféré.

A terme, nous aurons donc une API extensible qui permettra de gérer les plugins, quelques soit le SCM utilisé pour le développement / hébergement. Ce gestionnaire de plugin devrait être extensible par système de plugins et de gems. Ce gestionnaire fonctionnera pour tout le système. Vous donc n'aurez pas à ré-installer la gestion de votre SCM pour chaque projet.

On pourra donc installer des plugins via, par exemple, Git, Mercurial, SVN, Bazaar, …

Il sera possible de gérer les versions des plugins qu'on installe, chose qui manque cruellement à l'heure actuelle.

Un ticket à été ouvert sur le LH de rails.

Je pense aider Daniel Schierbeck à écrire ce gestionnaire et me pencherai également sur l'écriture du plugin de gestion de Mercurial.

Le développement en cours est visible sur GitHub.

Toutes les idées sont bienvenues !

Un tout petit billet pour une toute petite nouvelle, un patch que j'ai proposé à Sven Fuch apportant quelques corrections mineures au projet de traduction a été accepté.

Ce projet de traduction devrait faire partie intégrante de Rails 2.2.

Voici le patch.

Comme vous le savez, mon SCM préféré est Hg mais ce dernier n'est malheureusement pas supporté par l'utilitaire script/plugin de Rails.

A ce jour, il n'y a donc qu'un seul moyen d'installer un plugin Rails dont le repository utilise

$ cd vendor/plugins
$ hg clone http://www.host.com/hg_repo

Le but du patch que j'ai proposé est de permettre d'utiliser directement script/plugin pour simplifier les choses :

$ script/plugin install http://www.host.com/hg_repo