Peu de temps avant mon anniversaire qui a lieu le 11 Octobre, voici une nouvelle version de Pictrails.

Durant cette release, la grosse nouveauté est l'ajout des commentaires. Désormais sur chaque photo, des commentaires peuvent être ajoutés. Au niveau de l'administration, il y a la possibilité de gérer ces commentaires en les éditant et les supprimant. Ce n'est bien sûr que le début de l'ajout des commentaires sur pictrails. Si vous désirez formater vos commentaires, vous pouvez le faire avec le format redcloth.

Au niveau ergonomie, j'ai ajouter la vue des photos précédentes et suivantes dans la même galerie. Cette fonctionnalité n'était pas intégré dans Pictrails. Cette erreur est donc désormais résolu.

Les photos sont désormais triés de la photo la plus récente à la plus ancienne dans la vue des photos pour la galerie.

Tout retour est toujours le bienvenu ainsi que la proposition de design. Je rappele aussi qu'une version de démo est disponible. avec comme login admin/pictrails

English translation

Traduction de l'article de Ryan Daigle, What's new in edge rails : Connection Pools

Avec la venue prochaine de Rails thread-safe, il était nécessaire d'ajouter le pool de connection à la base de donnée. Moins qu'une fonctionnalité, mais un détail d'implémentation caché. Vous avez la possibilité de définir la taille de ce pool. Cette configuration est dans le fichier database.yml avec le mot clé pool:

development:   
  adapter: mysql
  username: root    
  database: myapp_dev
  pool: 10 

Vous voilà avec un pool de connection. Facile

Traduction de l'article de Ryan Daigle, What's new in edge rails : Mailer Layouts

Rails a ajouté la possibilité d'utiliser des layouts pour les mails exactements comme il est actuellement possible pour leurs grand frère les vues. Il faut juste noté que pour qu'un layout de mail soit automatiquement reconnu, il doit se finir par _mailer. Donc pour un mail:

ass UserMailer < ActionMailer::Base
  def registration(user)
    subject    "You've registered"
    from       "system@example.com"
  end
end

vous n'aurait besoin que d'un layout à layouts/user_mailer.html.erb. Si vous spécifiez explicitement le layout vous n'avez pas besoin du suffix _mailer. Ainsi, dans l'exemple suivant, un layout à layouts/email.html.erb suffit:

class UserMailer < ActionMailer::Base
  layout 'email'
  ...
end

A partir de maintenant, vous pouvez faire de joli petit email. Vous avez désormais tous les outils.

Traduction de l'article de Ryan Daigle, What's new in edge rails : Shallow routes

Le système des routes avec Rails est assez malin. Dans une optique d'être le plus descriptif possible, la description des ressources est fait au niveau des URL avec une DSL spécifique pour les routes :

       
map.resources :users do |user|         
  user.resources :articles do |article|
    article.resourcs :comments
  end
end         

Néanmoins, si cette configuration permet de voir les articles disponibles à l'URL /users/1/articles et les commentaires à l'URL /users/1/articles/1/comments, il y a des cas où on voudrais outrepasser cette hiérarchie et accéder directement à la ressource en question. Désormais avec l'option des shallow route, vous le pouvez.

                          
map.resources :users, :shallow => true do |user|
  user.resources :articles do |article|
    article.resources :comments
  end
end         

Cette configuration permet de conserver les routes imbriquées et vous donne accès directement au route comme ceci:

      
articles_path #=> '/articles'                             
comments_path #=> '/comments'                             
article_comments_path(@article) #=> '/articles/1/comments'

Plus besoin de déclarer séparement les routes directes en plus des routes imbriquées. l'option :shallow fait tout les routes nécessaires automatiquement pour vous.

Pour découvrir le bug dont j'ai reporté précédement les effets, j'ai voulu réaliser un profile de la requête executée. Ca devait me permettre de voir ce qui prenait vraiment beaucoup de temps dans l'execution de cette page.

Utilisation du script Request Profiler

Depuis Rails 2.0, un nouveau script a été ajouté, script/performance/request. Ce script permet de réaliser un profile d'une ou plusieurs requête internet.

Pour indiquer les requêtes à executer il suffit de réaliser un petit fichier de script avec le même format que les tests d'intégrations. Voici un exemple issue du changelog de rails.

get_with_redirect '/'
say "GET / => #{path}"
post_with_redirect '/sessions', :username => 'john', :password => 'doe'
say "POST /sessions => #{path}"

Une fois le script réalisé, il suffit de lancer la commande en définissant le nombre de requêtes qui seront effectuées

$ ./script/performance/request -n 10 login_session.rb

Par contre, il faut faire très attention, il n'y a aucune solution (ou tout du moins à ma connaissance) pour définir les valeurs de la session. La session est vierge à chaque lancement de script. Il faut donc réaliser la connection de login au préalable pour avoir un utilisateur loggé par exemple.

Incompatibilité Rails 2.1 et ruby-prof

Alors que j'avais indiqué l'ajout d'un nouveau script dans Rails Edge qui nécessitait ruby-prof 0.6.1, je pensais que c'était le seul endroit qui nécessitait cette version de ruby-prof qui n'existe pas encore (dernière version stable : 0.6.0 en téléchargement sur rubyforge). Hélas, ce n'est pas le cas. Depuis la version 2.1 de Rails, le script performance/request nécessite aussi ruby-prof 0.6.1. Mais cette version, n'est toujours pas encore sortie officielement. Il faut donc générer et installer ce gem pour arriver à avoir cette fonctionnalité. En effet, même en modifiant la version de ruby-prof des méthodes n'existent pas dans les versions antérieurs à la version 0.6.1

Génération et installation de ruby-prof-0.6.1

Il faut d'abord récupérer les sources directements à partir du svn de ruby-prof

svn co http://ruby-prof.rubyforge.org/svn/

Ensuite, il faut générer le gem

$ rake package

Enfin, il suffit d'installer le gem.

# gem install pkg/ruby-prof-0.6.1.gem

Désormais, ruby-prof 0.6.1 est installé et vous pouvez utiliser pleinement le script performance/request.

English translation

Ce que j'écris en français peut par le plus grand des hasard avoir un intérêt pour des personnes anglophile. J'ai donc décidé de traduire certain de mes articles directement en anglais. Typo n'ayant pas encore de support pour le multi-blog (en prévision), j'ai donc voulu avoir un blog vraiment léger. Pour cela, rien de plus simple, j'ai décidé d'utiliser rassmalog.

Si vous voulez donc lire ma prose anglaise suivez le guide. Bien sûr toute correction est la bienvenue au vu de mon pauvre niveau d'anglais.

Voilà, aussitôt sortie aussitôt installée. Alors que Typo-5.1.3 est sortie dimanche, j'ai mis à jour ce blog. Comment faire une migration si rapide ? Simple un bon script Capistrano :

require 'mongrel_cluster/recipes'

set :application, "typo"
set :repository,  "http://svn.typosphere.org/typo/trunk"
set :domain, "shingara.fr"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
set :deploy_to, "/var/rails/blog-typo"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
set :scm, :subversion

set :runner, "rails"
set :user, "rails"
set :use_sudo, false
set :mongrel_conf, "#{current_path}/config/mongrel_cluster.yml"

role :app, domain
role :web, domain
role :db,  domain, :primary => true

task :update_config, :roles => [:app] do
  run "cp -Rf #{shared_path}/config/* #{release_path}/config/"
  run "ln -s #{shared_path}/files #{release_path}/public/files"
end

after "deploy:update_code", :update_config

Il ne suffit plus que d'avoir dans le dossier /shared/ le dossier /config/ comprenant les fichiers de configurations : database.yml et mongrel_cluster.yml. Après à chaque mises à jours de typo : cap deploy:migrations. Tout sera fait pour toi.

C'est pas beau la vie en Ruby ?

Après que Peter Cooper ait libéré le code original de rubyflow, Bruno Michel a pris les choses en mains pour traduire l'application. L'association RubyFrance a ensuite hébergé le tout. Nous voilà donc maintenant avec notre propre rubyflow FR. Bravo pour cette initiative.

Aujourd'hui, j'ai passé la journée à essayer de comprendre un problème que j'avais sur l'application que je réalise dans le cadre de mon nouveau travail. Ce bug est très simple. Durant la validation d'un formulaire, si celui-ci n'était pas valide, je retournais sur la même page qui m'indiquait les champs en erreur. Dans la pratique, ceci est très simple. Mais dans notre cas, la page mettait pas moins de 40 secondes à se renderer. Car la latence n'avait pas lieu dans le controlleur, mais bel est bien durant le rendering de la page.

Pour essayer de comprendre la cause de tout ça, j'ai fini par réaliser un profile de ma requête avec le script /script/performance/request qu'il a déjà fallu faire fonctionner, mais ceci fera l'objet d'un autre billet. Une fois le profilling réalisé, j'ai constaté que ce qui me posait problème était une recherche incessante de traduction des messages d'erreurs. Après de longues recherche dans le code, j'ai fini par découvrir la vraie cause du problème.

Dans Rails, durant chaque création de tag, il y a une demande de récupération de errors.on pour connaitre là où les erreurs sont et ainsi mettre en surbrillance le champs ou non. Mais là où normalement dans Rails, ce n'est qu'un appel vers un valeur figée, Gettext a décoré la méthode pour réaliser une traduction de la chaine. Bien sûr si ce n'était que ça, ça pourrait encore passer, car finalement c'est le comportement en production. Les chaines étant misent en cache, l'accès est quasiment aussi rapide que sans gettext. Mais dans le cas d'un environnement en Développement, il n'y a aucun cache des chaines de Gettext. Ainsi à chaque tentative de traduction le mo file est chargé et une itération à lieu sur tout ce fichiers pour trouver la chaine à traduire. C'est ces itérations incessantes qui entrainait un temps de traitement extrêmement long de ma requête.

Ce phénomène n'a lieu uniquement qu'en environnement de développement, car il y a un test sur le nom de l'environnement. Dans tous les autres cas autre que développement, les mo sont mis en cache.

Pour résoudre ce problème, soit vous changez le nom de votre environnement par défaut, par exemple dev au lieu de développement, où alors mettre le code GetText.cached = true dans votre environnement.rb. Cela implique par contre que si vous modifiez les fichiers mo, il faudra redémarrer le serveur pour avoir les nouvelles entrées.

English translation

Alors que j'ai commencé à travailler professionnelement parlant avec Rails depuis mon départ de CapGemini et mon arrivée à JTEK. En une semaine et demi, je constate 1 bug sur rails 2.1, un bug sur Edge et un comportement ajouté en Rails 2.1 qui disparaitra en Rails 2.2 (déjà disparu sur Edge)

#has_one demande la validation de sa liaison

Durant la migration de l'application développé au sein de Jtek de Rails 1.2 à 2.1, j'ai constaté que les éléments #has_one sont désormais validé durant la validation du parent. En effet, ce comportement n'était pas présent dans les versions antérieurs à Rails 2.1. Par contre, la validation du #has_many est quand à elle effectuée depuis plusieurs version de Rails.

Par contre après une lecture du code de Rails edge, actuellement, ce comportement disparaitra complétement en Rails 2.2. En effet, une option :validate a été ajouté au méthode #has_many, #has_and_belongs_to_many et #has_one. J'ai parlé de ce comportement dans une news Vivre avec Rails.

Pour palier ce problème, j'ai créé un petit plugin rails qui permet de couper la validation sur le #has_one. Vous pouvez trouver les sources sur le github de JTek.

Bug de logger dans le Runner de Rails-2.1

Sur ce point j'ai reporté un bug sur le lighthouse de Rails. En effet, j'ai constaté que si on utilisait le logger par défaut de Rails, et qu'on réalisait un log dans le code executé par script/runner il ne se retrouvait pas loggé dans le fichier production.log en mode production. Par contre en mode développement, tout se passait bien. En fait, le problème vient du nouveau Logger par défaut de rails qui est une surcouche au Logger de Ruby. Ainsi, il contient un buffer qui est flushé régulièrement. Mais en fait en mode production, le flush est désactivé. On peux ainsi retrouvé différent moment de flush dans le code de rails pour vider ce buffer. Mais voilà, avec script/runner, on peux se retrouver à ne pas avoir flusher tout le logger à la fin de sa tâche. Pour palier le problème, il suffit de faire un RAILS_DEFAULT_LOGGER.flush à la fin du fichier script/runner. Sinon vous pouvez essayer de faire bouger le rapport de bug que j'ai ouvert

Eager Loading empêchant la migration en production

Voulant testé un peu Pictrails avec Edge, pour reporté le bug précédent, je me suis retrouvé bettement à ne pas pouvoir réaliser la migration en mode Production de Pictrails. J'ai ainsi trouvé la cause qui est en fait le eager loading des models durant l'initialisation. Dans mon model Pictures, il se trouve que je fait une demande d'information sur un autre model. Du coup Rails tente de faire une requête SQL avant de réaliser la migration. Forcement, ca peux pas fonctionner. La seule méthode pour éviter ca est de mettre l'option config.classe_cache à false dans le fichier de configuration. J'ai bien sûr reporté un bug à ce sujet.

Alors que je commence un nouvelle emploi, voici la nouvelle version de Pictrails. Cette version 0.4.0 sort assez rapidement après la version 0.3.x. Elle apporte effectivement assez peu de nouvelles fonctionnalités, mais elle a l'avantage d'être maintenant compatible avec Rails 2.1 Les prochaines versions de Pictrails seront peut-être un peu moins fréquente. Mais la roadmap se charge de plus en plus et même quelques personnes commencerait à utiliser Pictrails.

Voici la liste des nouveautés de cette version :

• Ajout du support des Tags. Ainsi chaque image peux avoir une série de Tag qui lui ai associé.
• Ajout d'un flux Atom relié au gallerie
• Ajout d'une bar de coté avec la liste des galleries disponible sur l'application. Elle est organisé sous forme d'arbre exactement comme est l'arborescence.
• Ajout d'un nuage de Tag global et gallerie par gallerie dans la bar de coté.

traduction de Vivre avec Edge #3

Il n'y a pas grand chose à noter comme gros changements ou fonctionnalités dernièrement dans edge Rails, alors je vais parler des commits rails concernant quelques bugs fixes et changements mineurs que je n'ai pas indiqué précédement. Il y a eu un travail en cours avec un refactoring et multithreading de ActionPack ainsi qu'un peu d'activité sur ActiveModel, mais rien de réelement concret encore (c'est toujours en cours de travaux).

Comme d'habitude n'hésitez pas à laisser des critiques ou suggestions dans les commentaires.

Support de Thin avec script/server

script/server vérifie désormais la disponibilité de Thin et l'utilise. Pratique si vous utilisez Thin comme serveur de production (et voulez lancer avec le même serveur durant le développement). Vous devez ajouter config.gem 'hin' en premier dans votre environment.rb pour que cela fonctionne.

Ce patch est une contribution d'un des gars de fluxin.

Changeset

String#humanize peux être configurable par les régles d'inflection

La méthode d'extension du core String#humanize est utilisé pour convertir les string avec des underscores en texte lisible plus facilement (utilisé pour les noms des colonnes). Par exemple,

"actor_salary".humanize
=> "Actor salary"
"anime_id".humanize
=> "Anime"

Parfois cela ne fonctionne pas aussi bien, quand vous avez des héritages de tables ou des noms de colonnes "inhumain" comme "act_sal_money" (qui est réellement "Actor salary", mais qui sera #humaize-d en "Act Sal Money").

Vous pouvez désormais spécifier une régle d'inflection (exactement comme pour les règles de mots pluriel/singulier/irrégulier/invariable).

Inflector.inflections do |inflect|
  inflect.human /_cnt$/, '\1_count'
  inflect.human 'act_sal_money', 'Actor Salary'
end

Remarquez que vous pouvez aussi utiliser une expression régulière pour convertir une colonne comme "click_cnt" en "Click count".

Merci à Dan Manges et Pascal Ehlert pour ce patch.

Changeset

Possibilité de spécifier des conditions sur des tables multiples en utilisant un hash.

Pratik a commité un petit (mais très pratique) changement d'ActiveRecord qui permet de spécifier des conditions sur les jointure dans leur propre hash. Un exemple sera plus explicite:

Anime.all(
  :joins => :character,
  :conditions => {
    :active => true,
    :characters => { :gender => 'female' }
  }
)

La requête ActiveRecord précédent permet de trouver tous les anime "actif" qui comme charactère une "femme".

Changeset

Outro

C'est tout pour cette semaine dans "Living on the Edge". Faites moi savoir si vous désirez voir plus d'information sur les changement et bug fixes mineurs que j'ai mis à l'écart cette semaine.

traduction de Vivre avec Edge #3

Il n'y a pas grand chose à noter comme gros changements ou fonctionnalités dernièrement dans edge Rails, alors je vais parler des commits rails concernant quelques bugs fixes et changements mineurs que je n'ai pas indiqué précédement. Il y a eu un travail en cours avec un refactoring et multithreading de ActionPack ainsi qu'un peu d'activité sur ActiveModel, mais rien de réelement concret encore (c'est toujours en cours de travaux).

Come d'habitude n'hésitez pas à laisser des critiques ou suggestions dans les commentaires.

Support de Thin avec script/server

script/server vérifie désormais la disponibilité de Thin et l'utilise. Pratique si vous utilisez Thin comme serveur de production (et voulez lancer avec le même serveur durant le développement). Vous devez ajouter config.gem 'thin' en premier dans votre environment.rb pour que cela fonctionne.

Ce patch est une contribution d'un des gars de fluxin.

Changeset

String#humanize peux être configurable par les régles d'inflection

La méthode d'extension du core String#humanize est utilisée pour convertir les strings avec des underscores en texte lisible plus facilement (utilisé pour les noms des colonnes). Par exemple,

"actor_salary".humanize
=> "Actor salary"
"anime_id".humanize
=> "Anime"

Parfois cela ne fonctionne pas aussi bien, quand vous avez des héritages de tables ou des noms de colonnes "inhumain" comme "act_sal_money" (qui est réellement "Actor salary", mais qui sera #humaize-d en "Act Sal Money").

Vous pouvez désormais spécifier une régle d'inflection (exactement comme pour les règles de mots pluriel/singulier/irrégulier/invariable).

Inflector.inflections do |inflect|
  inflect.human /_cnt$/, '\1_count'
  inflect.human 'act_sal_money', 'Actor Salary'
end

Remarquez que vous pouvez aussi utiliser une expression régulière pour convertir une colonne comme "click_cnt" en "Click count".

Merci à Dan Manges et Pascal Ehlert pour ce patch.

Changeset

Possibilité de spécifier des conditions sur des tables multiples en utilisant un hash.

Pratik a commité un petit (mais très pratique) changement d'ActiveRecord qui permet de spécifier des conditions sur les jointures dans leur propre hash. Un exemple sera plus explicite:

Anime.all(
  :joins => :character,
  :conditions => { 
    :active => true,
    :characters => { :gender => 'female' }
  }
)

La requête ActiveRecord précédent permet de trouver tous les anime "actif" qui comme charactère une "femme".

Changeset

Outro

C'est tout pour cette semaine dans "Living on the Edge". Faites moi savoir si vous désirez voir plus d'information sur les changement et bug fixes mineurs que j'ai mis à l'écart cette semaine.

Ce blog a été mis à jour avec succès avec la nouvelle version de Typo. En effet, la sortie a été réalisé hier et ce blog est déjà à jour. Pour la première fois plusieurs de mes contributions sont présentes directement dans cette nouvelle mouture avec quelques remerciement de Neuro. Ca fait vraiment plaisir.

J'ai aussi mis le thème par défaut de Typo qui est vraiment très bien. Merci à jeuxdemaux.org

traduction de Vivre avec Edge #2

La première news Vivre avec edge a parlé des changement de l'API depuis Rails 2.1, et durant cette news, les améliorations de performances seront indiqué comme promis.

En avant...

Les templates Erb plus rapide

Jeremy Kemper a rendu le processus d'Erb plus efficace, spécialement les méthodes d'helper concat et capture.

Le "spécial" Erb _erbout a été remplacé par une variable d'instance qui permet ceci:

• Meilleur performance (mémoire) parce que bindings ne pas pas longtemps autour
• Moins de d'évaluation qui est généralement couteux.
• Il n'y a pas besoin de séparer la variable _erbout quand vous remplacer un nouveau buffer (de string)
• Le buffer est généralement disponible via une méthode output_buffer écriture et lecture (alors vous pouvez les overrider si vous le souhaitez)

Changesets en relation: 933697a - 0bdb7d3 - 4d4c8e2

Les helpers JavaScript et les partials sont plus rapide.

L'initialisation des templates partial et des helpers Javascript ont été refactoré et optimisé pour une meilleure vite et efficacité grâce à Jeremy Kemper. Quelque optimisations de Jérémy ont été commité récement. Vérfiiez avec les commits de Rails (comme pour tout projet Open Source de qualité) - Vous apprendrez plein de chose.

Changesets en relation: partials – JavaScript helpers

Accélération de la méthode RecordIdentifier

Le RecordIdentifier est plus rapide avec la simple utilisation de memo-ization, réduisant ainsi l'utilisation des Inflections entre autre. Le RecordIdentifier est largement utilisé dans le cache des clé, des chemins des templates de partial, et dans la plus part des endroit où vous identifiez un model ActiveRecord sans le savoir avec ton id actuel.

Changesets en relation par Jeremy Kemper: c1a9820 – 566d717

Après avoir lu les remarques de frédéric au sujet de la soirée Firefox 3. Je ne peux m'empêcher de l'approuver et de rédiger ce billet. J'écris rarement pour critiquer quelque chose, mais j'avoue que cette pratique est vraiment anti-libriste.

En effet, la fondation Mozilla trie sur le volet ses invités pour la grande soirée Firefox 3. Que Mozilla fasse une grande fête chez elle avec les invités qu'elle souhaite c'est tout à fait normal. Mais qu'elle annonce une grande fête et ouvre les portes de cette fête à seulement des personnes triés sur le volet en fonction de leur projet open source et de leur contribution au standard du web, je trouve ça affligeant.

Le personne qui permette de faire ces fêtes sont justement les madame Michou. Ceux qui télécharge Firefox et qui trouve juste le produit bien. Par des personnes qui font de l'open source ou contribue à des standards. C'est peut-être même pas des utilisateurs de Firefox. En effet, Firefox n'est pas le seul navigateur à suivre les standards. Que ce soit Opera ou Safari, ces deux navigateurs sont au moins aussi respectueux des standards si ce n'est plus. Là vraiment Firefox me déçoit.

Personnellement, j'aurais largement préféré une bonne réunion à la bonne franquette. Chacun se retrouve sur le champs de Mars avec sa bouffe. Pas de micro, pas de speech pompeux. Juste des gens réuni en un point pour être heureux.

Depuis peu, je tente d'utiliser Merb et DataMapper. Une différence notable entre Merb et Rails est le système de log. Comme Merb est ORM Agnostique, il n'affiche pas de base les logs SQL. J'ai cherché plusieurs fois comment avoir mes logs SQL de DataMapper directement dans ma console. J'ai fini par la trouvé sur le wiki de DataMapper. Je vous livre donc l'astuce :

Merb::BootLoader.after_app_loads do
  DataObjects::SQlite3.logger = DataObjects::Logger.new(STDOUT, :debug) 
end

Vous pouvez bien-sûr modifier le SQlite3 par Postgres ou MySQL. Cette comment fait une sortie en mode debug sur STDOUT. On aurait aussi pu mettre un fichier ('log/dm.log').

Pour connaitre la liste des niveaux de logs, la voici :

• fatal
• error
• warn
• info
• debug

Voici la nouvelle traduction de Vivre avec Edge. Par contre, cette fois ci, comme annoncé dans cette news, cette news est issu du blog officiel de rubyonrails et non plus du blog de Chu Yeow

Comme Gregg Pollack l'indique il y a une semaine, Je conserve une note hebdomadaire au sujet des changements de edge Rails. C'est la première fois que Living on the Edge(of Rails) est apparu officiellement sur le blog officiel de Ruby on Rails.

Living on the Edge est une note hebdomadaire que je mettais sur mon propre blog après plusieurs récupération par Gregg Pollack of Rails Envy depuis décembre 2007. J'avais l'habitude d'être une contributeur actif de rails et non pas trop une personne qui réfléchis. Gregg et Jason ont été génial de m'ajouter à leur podcast hebdomadaire.

Et maintenant je suis ici, alors je vais essayer de faire de mon mieux et n'hésitez pas à être très critique pour que ça soit utile pour vous. Quand je blogguais cela dans mon petit blog personnel, ce n'était pas vital d'avoir une audience large et significative (NdT: Au moins sur ce blog ça reste toujours le cas). Laissez vos suggestions et critique dans les commentaires. Ils seront grandement appréciés.

De toutes façon il y a eu énormément de nouveauté durant les deux semaines après la release de Rails 2.1, changement de l'API et amélioration des performances. Donc au lieu de faire une très gros post, j'ai décidé de le séparé en 2 posts pour les nouveautés et changement d'API et les améliorations de performances. Dans ce post, je parlerais des nouveautés et changement de l'API

Changements mineurs de l'API

Commençons avec les changements mineurs de l'API.

link_to peux désormais prendre un block

Le helper link_to peux désormais prendre en argument un block. Utile dans les cas où vous avez long texte d'hyperlien avec des variables.:

<% link_to(@profile) do %>

  <strong><%= @profile.name %></strong> -
  <span>Status: <%= @profile.status %></span>
<% end %>

Certaine personne trouve cela plus propre que:

<%= link_to "<strong>#{@profile.name}</strong> -- <span>Status: #{@profile.status}</span>", @profile %>

Ce changement a été apporté par Sam Stephenson (du fameux Prototype) et DHH.

Changeset details

ActiveRecord::Base#merge_conditions fait maintenant partie de l'API public

Jeremy Kemper a rendu public la méthode ActiveRecord::Base#merge_conditions.

C'est vraiment très pratique si vous avez des conditions issues de multiples sources ou qui se combine pour différentes raisons.

Post.merge_conditions(
  {:title => 'Lucky ☆ Star'},
  ['rating IN (?)', 1..5]
)
=> "(`posts`.`title` = 'Lucky ☆ Star') AND (rating IN (1,2,3,4,5))"

Notez bien que cela merge uniquement avec un boolean SQL AND (pas ORs).

Changeset details

Les associations peuvent prendre une option :validate

les associations peuvent désormais accepter une option c:validate comme ceci:

class Anime < ActiveRecord::Base
  has_many :characters, :validate => true
end

Cela indique à ActiveRecord de valider l'association characters quand vous enregistrer le model Anime - exactement comment fonctionnait :validates_associated. La valeur par défaut est false, qui est le comportement actuel dans Rails 2.1 et plus récent, donc pas d'agitation à avoir. Cela fonctionne pour toutes les autre associations comme (has_one, belongs_to, has_and_belongs_to_many).

Merci à Jan De Poorter et Pratik Naik pour cela, qui permette aussi de résoudre un mauvais bug.

Changeset details – Ticket

ActiveSupport::StringInquirer et avantage de la méthode Rails.env.development?

David Heinemeier Hansson (généralement abbrégé par DHH – désolé!) a récemment ajouté un sous-classe à String, ActiveSupport::StringInquirer qui permet de faire ceci:

s = ActiveSupport::StringInquirer.new('awesome')
=> "awesome" 
s.awesome?
=> true
s.sucks?
=>; false

Une utilisation immédiate de cette classe est quand vous voulez vérifier l'environnement de votre application en fonctionnement : Rails.env est enrobé en StringInquirer alors vous pouvez utiliser des méthodes comme Rails.env.development? et Rails.env.production?.

Changeset details

Core extensions: Object#present? et Enumerable#many?

DHH a aussi ajouté une extensions au core. C'est quelque peu trivial, mais peu rendre le code plus lisible. Le première est Object#present?, qui est essentiellement !Object#blank?

[].present?
=> false
[1, 2].present?
=> true
"".present?
=> false
"i'm here".present?
=> true

Une extension Enumerable#many? a aussi été ajouté qui réalise simplement un test conditionnel sur enumerable.size > 1:

[].many?
=> false
[:just_me].many?
=> false
[:just_me, 'my_friend'].many?
=> true

Object#present? changeset – Enumerable#many? changeset

Syntaxe de block déclaratif pour l'écriture de tests

DHH s'est inspiré de Jay Fields quand il commita cette nouvelle syntaxe. Vous pouvez maintenant écrire vos tests (Test::Unit) avec un style de block déclaratif comme :

test "an anime should be invalid if any of its characters are invalid" do
  # Your usual test code here.
end

J'utilise rarement Test::Unit (sauf pour soumettre des patchs à Rails) et préfère RSpec – Ce style déclaratif pour écrire des tests est vraiment plus lisible.

Tous les tests générés par Rails utilisent désormais cette syntaxe.

Changeset details

Performance tests

Jeremy Kemper a fait un travail en profondeur pour optimiser et améliorer les performances de Rails, alors c'est sans surprise que cela a été introduit comme nouveau type de test d'intégration. Les tests de performances.

Vous pouvez utiliser le générateur de test de performance (ajouté par Pratik dans 23232a) pour générer des tests de performances.

script/generate performance_test LoginStories

Le lancement du test de performance nécessite ruby-prof >= 0.6.1, qui n'est pas encore sortie. Mais vous pouvez récupérer sa version en développement à partir des sources et en installant vous même le gem (Je vous conseille de récupérer le ruby-prof que Jeremy a forké). Il est intéressant de remarquer qu'avec la sortie de ruby-prof 0.6.1, ruby-prof supportera le profiling des tests écrits avec Test::Unit

Attention - Si vous faites un petit code de test (requêtes sur plusieurs actions, quelque soit le cas d'utilisateur que vous voulez testez en performance) et lancez le test. Vous aurez la sortie suivante (si vous avez dirigé la sortie habituel de ruby-prof vers le répertoire test/tmp/performance de votre application Rails):

> ruby performance/login_stories_test.rb 
Loaded suite performance/login_stories_test
Started
LoginStoriesTest#test_homepage (32 ms warmup)
        process_time: 11 ms
              memory: unsupported
             objects: unsupported
.
Finished in 0.870842 seconds.

Les résultats memory et objects ne sont pas supporté, parce que je n'avais pas patché mon interpréteur Ruby au support du proflling de mémoire. Vous aurez besoin de patcher certain interpréteur ruby pour activer le profiling de la mémoire et de GC. Je souhaiterais vous en dire plus à ce sujet, mais je suis en terrain inconnu. Il y a plus de détail ici (en) sur la méthode à suivre pour patcher Ruby pour le profilling de la mémoire. Je laisse les personnes plus qualifiée sur ce sujet expliquer tout ça.

Changeset details

Outro

C'est tout pour le moment concernant les nouvelles fonctionnalités et changement dans Rails depuis Rails 2.1 - Les améliorations de performances arriveront dans un prochain post et j'ai laissé aussi intentionnellement de coté le support de Rack qui n'est que partiellement mergé dans Edge.

Si il y a des erreurs ou que vous avez des suggestions sur comment faire un meilleur post, s'il vous plait indiquez le en commentaire. Toute information sur le patch de l'interpréteur Ruby pour supporter le profiling de la mémoire et aussi le bienvenue. Si j'ai laissé de coté des éléments qui ne vous semblez pas le nécessiter, laisser moi un commentaire.

Alors, que je testais Pictrails pour la release en version 0.3, j'ai par hasard créé une galerie s'appelant "new". Ayant implémenté un système de PrettyURL pour pictrails, j'ai changé les routes REST pour non pas afficher l'id de la galerie dans l'url mais son nom. Ainsi, comme ma galerie s'appele "new", je devais allez sur l'URL : /galleries/new.

Mais voilà comme galerie était une ressource REST, la route /galleries/new est déjà réservé et je me suis donc retrouvé sur l'url de création d'une Gallerie et non sur l'url de visualisation de la galerie new. C'est ainsi que je suis tombé dans le piège des routes à éviter.

Maintenant, que j'ai trouvé le bug il a fallu trouvé la solution et plus que de trouver la solution, il fallait trouver une solution propre. En effet, basiquement, on peux créer un validateur qui vérifie que le nom n'est pas "new", mais cette technique ne me semblait pas idéal surtout pour l'avenir et le maintient à terme de cette solution. J'ai donc commencé à en discuter avec les personnes présentent sur le chan #rubyonrails.fr. C'est ainsi que webs m'a proposé une solution tout à fait élégante en me donnant un code de sunny. La vérification directe de l'existence ou non de la route. Voici le bout de code qui permet cette vérification :

permalinks = ActionController::Routing::Routes.routes.collect {|r|
   r.generation_structure.match(/"\/galleries\/([\w]+)/)[1] rescue nil
}.uniq.compact

On récupère ainsi tous les mots utilisés dans nos routes et commençant par galleries. Sur Pictrails, nous obtenons ainsi "pages" et "new". Il suffit ensuite d'empêcher la création de galerie avec ces noms.

Presque 3 mois jours pour jours après la dernière release de Pictrails 0.2.3, voici la release de la version 0.3.0

Cette nouvelle version apporte son lot de fonctionnalités. La plus importante étant l'ajout du support des sous-galerie En effet, désormais, on peux créer des galeries photos dépendant d'une autre galerie. Cette galerie sera donc visible avec la liste des photos de sa galerie parente. Pour que la navigation soit ainsi plus fluide, j'ai ajouté un fil d'ariane ou breadcrumb pour les anglophiles. On sait ainsi désormais dans quel galerie nous nous trouvons et si celle-ci a des parents.

La deuxième fonctionnalité est surtout la refonte compléte du mass_upload. En effet, le mass_upload ne fonctionnait pas trop si on avait énormément de photo a ajouter. Les threads mongrel ou FastCGI s'arrêtait avec un time out et plus aucune solution de continuer la tâche. Pour ce faire, la première requête liste toutes les images à importer et dans quel galerie. Ensuite à chaque nouvelle requête dans la partie d'administration une série de 5 photos est ajoutés. Pour rendre le système plus conviviale, une progress bar a été ajoutée. Celle-ci évolue progressivement si le Javascript est activé sur votre navigateur. Ce système de mass_upload a bien évidement suivit l'évolution de Pictrails en supportant lui aussi les sous-galeries. Ainsi, il liste de façon récursive les répertoires et créé les galeries avec leurs parents associés.

J'espère que cette nouvelle version vous satisfera. Bien-sûr la liste des fonctionnalités a ajouter n'est pas fini pour arriver à la version 1.0. Si vous avez envie de contribuer n'hésitez pas. Pour plus de détails sur cette version, le site de pictrails a été mis à jour

Thin is a new Web server / daemon written in Ruby by Marc-André Cournoyer that uses the EventMachine, Rack, and Mongrel libraries. EventMachine makes it super fast at processing network I/O, Rack makes it easy to integrate with existing Ruby Web app frameworks, and Mongrel helps it parse HTTP. So, yes, the title is slightly misleading. Thin actually relies on Mongrel, but is ultimately faster than it, even against Mongrel's EventMachine-enhanced guise.

You can get started with Thin with a simple sudo gem install thin and then you can use it with any Rack supporting Web app / framework. With a Rails app, for example, a simple thin start in the base directory will get things moving.

Dr Nic has written a tutorial on testing JavaScript in Rails using a new javascript_test plugin.

Once you ruby script/plugin install javascript_test you can ruby script/generate javascript_test maths. Then you can write a test a la:

You can go further though with the autotest watching over files, and Nic shows some TDD in action.

Users of the command line are familiar with the idea of building pipelines: a chain of simple commands strung together to the output of one becomes the input of the next. Using pipelines and a basic set of primitives, shell users can accomplish some sophisticated tasks. Here's a basic Unix shell pipeline that reports the ten longest .tip files in the current directory, based on the number of lines in each file:

 wc -l *.tip | grep \.tip | sort -n | tail -10

Let's see how to add something similar to Ruby. By the end of this set of two articles, we'll be able to write things like

puts (even_numbers | tripler | incrementer | multiple_of_five ).resume

and a palindrome finder using blocks:

words            = Pump.new %w{Madam, the civic radar rotator is not level.}
is_palindrome = Filter.new {|word| word == word.reverse}

pipeline = words .| {|word| word.downcase.tr("^a-z", '') } .| is_palindrome

while word = pipeline.resume
  puts word
end

Great code? Nope. But getting there is fun. And, who knows? The techniques might well be useful in your next project.

A Daily Dose of Fiber

Ruby 1.9 adds support for Fibers. At their most basic, let you create simple generators (much as you could do previously with blocks. Here's a trivial example: a fiber that generates successive Fibonacci numbers:

      fib = Fiber.new do
        f1 = f2 = 1
        loop do
          Fiber.yield f1
          f1, f2 = f2, f1 + f2
        end
      end

      10.times { puts fib.resume }

A fiber is somewhat like a thread, except you have control over when it gets scheduled. Initially, a fiber is suspended. When you resume it, it runs the block until the block finishes, or it hits a Fiber.yield. This is similar to a regular block yield: it suspends the fiber and passes control back to the resume. Any value passed to Fiber.yield becomes the value returned by resume.

By default, a fiber can only yield back to the code that resumed it. However, if you require the "fiber" library, Fibers get extended with a transfer method that allows one fiber to transfer control to another. Fibers then become fully fledged coroutines. However, we won't be needing all that power today.

Instead, let's get back to the idea of creating pipelines of functionality in code, much as you can create pipelines in the shell.

As a starting point, let's write two fibers. One's a generator—it creates a list of even numbers. The second is a consumer. All it does it accept values from the generator and print them. We'll make the consumer stop after printing 10 numbers.

    evens = Fiber.new do
      value = 0
      loop do
        Fiber.yield value
        value += 2
      end
    end

    consumer = Fiber.new do
      10.times do
        next_value = evens.resume
        puts next_value
      end
    end

    consumer.resume

Note how we had to use resume to kick off the consumer. Technically, the consumer doesn't have to be a Fiber, but, as we'll see in a minute, making it one gives us some flexibility.

As a next step, notice how we've created some coupling in this code. Our consumer fiber has the name of the evens generator coded into it. Let's wrap both fibers in a method, and pass the name of the generator into the consumer method.

    def evens
      Fiber.new do
        value = 0
        loop do
          Fiber.yield value
          value += 2
        end
      end
    end

    def consumer(source)
      Fiber.new do
        10.times do
          next_value = source.resume
          puts next_value
        end
      end
    end

    consumer(evens).resume

OK. Let's add one more fiber to the weave. We'll create a filter that only passes on numbers that are multiples of three. Again, we'll wrap it in a method.

    def evens
      Fiber.new do
        value = 0
        loop do
          Fiber.yield value
          value += 2
        end
      end
    end

    def multiples_of_three(source)
      Fiber.new do
        loop do
          next_value = source.resume
          Fiber.yield next_value if next_value % 3 == 0
        end
      end
    end

    def consumer(source)
      Fiber.new do
        10.times do
          next_value = source.resume
          puts next_value
        end
      end
    end

    consumer(multiples_of_three(evens)).resume

Running this, we get the output

0
6
12
18
. . .

This is getting cool. We write little chunks of code, and then combine them to get work done. Just like a pipeline. Except...

We can do better. First, the composition looks backwards. Because we're passing methods to methods, we write

    consumer(multiples_of_three(evens))

Instead, we'd like to write

    evens | multiples_of_three | consumer

Also, there's a fair amount of duplication in this code. Each of our little pipeline methods has the same overall structure, and each is coupled to the implementation of fibers. Let's see if we can fix this.

Wrapping Fibers

As is usual when we're refactoring towards a solution, we're about to get really messy. Don't worry, though. It will all wash off, and we'll end up with something a lot neater.

First, let's create a class that represents something that can appear in our pipeline. At it's heart is the process method. This reads something from the input side of the pipe, then "handles" that value. The default handling is to write that value to the output side of the pipeline, passing it on to the next element in the chain.

    class PipelineElement

      attr_accessor :source

      def initialize
        @fiber_delegate = Fiber.new do
          process
        end
      end

      def resume
        @fiber_delegate.resume
      end

      def process
        while value = input
          handle_value(value)
        end
      end

      def handle_value(value)
        output(value)
      end

      def input
        source.resume
      end

      def output(value)
        Fiber.yield(value)
      end
    end

When I first wrote this, I was tempted to make PipelineElement a subclass of Fiber, but that leads to coupling. In the end, the pipeline elements delegate to a separate Fiber object.

The first element of the pipeline doesn't receive any input from prior elements (because there are no prior elements), so we need to override its process method.

    class Evens < PipelineElement
       def process
         value = 0
         loop do
           output(value)
           value += 2
         end
       end
    end

    evens = Evens.new

Just to make things more interesting, we'll create a generic MultiplesOf filter, so we can filter based on any number, and not just 3:

    class MultiplesOf < PipelineElement
      def initialize(factor)
        @factor = factor
        super()
      end
      def handle_value(value)
        output(value) if value % @factor == 0
      end
    end

    multiples_of_three = MultiplesOf.new(3)
    multiples_of_seven = MultiplesOf.new(7)

Then we just knit it all together into a pipeline:

    multiples_of_three.source = evens
    multiples_of_seven.source = multiples_of_three

    10.times do
      puts multiples_of_seven.resume
    end

We get 0, 42, 84, 126, 168, and so on as output. (Any output stream that contains 42 must be correct, so no need for any unit tests here.)

But we're still a little way from our ideal of being able to pipe these puppies together. It's a good thing that Ruby let's us override the "|" operator. Up in class PipelineElement, define a new method:

    def |(other)
      other.source = self
      other
    end

This allows us to write:

    10.times do
      puts (evens | multiples_of_three | multiples_of_seven).resume
    end

or even:

    pipeline = evens | multiples_of_three | multiples_of_seven

    10.times do
      puts pipeline.resume
    end

Cool, or what?

In The Next Thrilling Installment

The next post will take these basic ideas and tart them up a bit, allowing us to use blocks directly in pipelines. We'll also reveal why our PipelineElement class I just wrote is somewhat more complicated than might seem necessary. In the meantime, here's the full source of the code so far.

    class PipelineElement

      attr_accessor :source

      def initialize
        @fiber_delegate = Fiber.new do
          process
        end
      end

      def |(other)
        other.source = self
        other
      end

      def resume
        @fiber_delegate.resume
      end

      def process
        while value = input
          handle_value(value)
        end
      end

      def handle_value(value)
        output(value)
      end

      def input
        source.resume
      end

      def output(value)
        Fiber.yield(value)
      end
    end

    ##
    # The classes below are the elements in our pipeline
    #
     class Evens < PipelineElement
       def process
         value = 0
         loop do
           output(value)
           value += 2
         end
       end
     end

    class MultiplesOf < PipelineElement
      def initialize(factor)
        @factor = factor
        super()
      end
      def handle_value(value)
        output(value) if value % @factor == 0
      end
    end

    evens = Evens.new
    multiples_of_three = MultiplesOf.new(3)
    multiples_of_seven = MultiplesOf.new(7)

    pipeline = evens | multiples_of_three | multiples_of_seven

    10.times do
      puts pipeline.resume
    end