Ateliers : classe Date en PHP et SproutCore

La gestion des dates sous PHP a toujours été compliquée (pour ne pas dire pénible). Aussi, nous avons commencé à réfléchir sur une classe Date (ou DateTime) qui simplifierait cela au cours d'un atelier du lundi.

read more

Mon petit mot sur Mozilla

D’un côté on a les personnes qui font des fêtes du libre sur invitation et ceux qui gueulent et qui ont raison. Moi je pense que tout le monde commence à comprendre que je suis fan de WebKit mais faisons une rétrospective.

Firefox a été le premier navigateur alternatif sérieux et open source. Tout le monde a poussé à son adoption et Spread Firefox a fait une action avec un bon esprit pour Firefox 2. Et puis tout le monde pendant ce temps se plaignant de la consommation de RAM du panda.

Avec Firefox 3 c’est le contraire. Les performances sont très bonnes, la consommation de RAM est vraiment très bonne et il y a pas mal d’améliorations. Mais c’est la communication qui dérape. Mozilla a revendu sa R5 Turbo pour une Mercedes et se triture la nouille un peu trop. Ils font des concours de celui qui a la plus grosse et font des comparatifs moisis (forcément Gecko n’étant plus utilisé que par… les produits Mozilla ?).

Conclusion ? Quand vous avez les geeks (NB : ceux qui sont un peu les promoteurs des produits libres) dans votre poche et que vous devez atteindre les autres, n’oubliez pas que les geeks peuvent vous descendre si vous faites un faux pas. GNOME passant à WebKit est à mon avis juste une très méchante claque dans la gueule qui j’espère fait réfléchir.

Tout est histoire de communication, on l’a vu avec Ruby, avec Firefox et on le voit avec WebKit actuellement. A cause de cette communication navrante, je viens de passer totalement à Safari, et je suis sûrement pas le dernier.

Bivouac 0.2.5

La version 0.2.5 de Bivouac est en ligne. Au programme, quelques corrections de bug, et la possibilité de forcer l’utilisation d’un server dans le fichier de configuration.

Un grand merci à Guillaume pour ses tests et ses retours…

Pour la prochaine version (0.3.0), je vais travailler sur la possibilité d’envoyer des mails, à la ActionMailer. De plus, la version 2.0 de Camping semblant imminente, je vais travailler sur la compatibilité avec la version 1.9.

Vivre avec Edge (ou quoi de neuf dans Rails Edge) #2 -amélioration des performances

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: partialsJavaScript 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: c1a9820566d717

Vivre avec Edge (ou quoi de neuf dans Rails Edge) #2 -amélioration des performances

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: partialsJavaScript 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: c1a9820566d717

Le monde du libre fait de la sélection même pour les fêtes

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.

Afficher les Log SQL avec Merb et DataMapper

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

Vivre avec Edge (ou quoi de neuf dans Rails Edge) #1 - changement d’API et des tests de performances

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 detailsTicket

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</code></pre>

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


	<p><a href="http://github.com/rails/rails/commit/8afa725f4b98a6e0ceee4792e8ebaebb6189e5f6">Changeset details</a></p>


	<h5>Core extensions: Object#present? et Enumerable#many?</h5>


	<p><span class="caps">DHH</span> a aussi ajouté une extensions au core. C'est quelque peu trivial, mais peu rendre le code plus lisible. Le première est <code>Object#present?</code>, qui est essentiellement <code>!Object#blank?</code></p>


<typo:code lang="ruby">[].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? changesetEnumerable#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.

mod_rails en mutu, c’est l’arnaque !

Tout le monde parle de mod_rails comme si c’était le messie alors que j’ai toujours été sceptique. Et alors quand on commence à dire que ça a été conçu pour l’hébergement mutualisé, je commence vraiment à m’inquiéter, surtout quand je vois ce genre de posts.

En gros, c’est pas si stable que ça (bon la version 2 doit l’être un peu plus). Mais la consommation mémoire, elle, explose tous les records ! Si on regarde de plus près, alors qu’une instance Mongrel/Thin prend entre 40Mo et 50Mo de RAM, un Spawn et les 2 autres processus communs à tous les spawns vont consommer à peu près 80Mo. Alors mod_rails sera moins gourmand avec plusieurs spawns, mais avec un seul (bah oui on est en mutualisé, faut pas déconner) on se retrouve avec une consommation mémoire 2 fois supérieure.

Les acteurs de l’hébergement comme Dreamhost et Hosting Rails doivent compter sur l’idle des spawns au bout d’un moment, mais un peu de traffic sur tous les sites et c’est totalement mort.

En conclusion, mod_rails avec Ruby Enterprise est très probablement une très bonne solution pour les serveurs dédiés voire les VPS (s’il n’y a pas beaucoup de sites dessus), mais c’est une grosse arnaque pour un hébergement mutualisé. Je craque d’impatience de découvrir mod_rubinius en tout cas.

Edit : Avec Ruby Enterprise Edition, la consommation ne baisse pas énormément sur juste un seul spawn.

mod_rails en mutu, c’est l’arnaque !

Tout le monde parle de mod_rails comme si c’était le messie alors que j’ai toujours été sceptique. Et alors quand on commence à dire que ça a été conçu pour l’hébergement mutualisé, je commence vraiment à m’inquiéter, surtout quand je vois ce genre de posts.

En gros, c’est pas si stable que ça (bon la version 2 doit l’être un peu plus). Mais la consommation mémoire, elle, explose tous les records ! Si on regarde de plus près, alors qu’une instance Mongrel/Thin prend entre 40Mo et 50Mo de RAM, un Spawn et les 2 autres processus communs à tous les spawns vont consommer à peu près 80Mo. Alors mod_rails sera moins gourmand avec plusieurs spawns, mais avec un seul (bah oui on est en mutualisé, faut pas déconner) on se retrouve avec une consommation mémoire 2 fois supérieure.

Les acteurs de l’hébergement comme Dreamhost et Hosting Rails doivent compter sur l’idle des spawns au bout d’un moment, mais un peu de traffic sur tous les sites et c’est totalement mort.

En conclusion, mod_rails avec Ruby Enterprise est très probablement une très bonne solution pour les serveurs dédiés voire les VPS (s’il n’y a pas beaucoup de sites dessus), mais c’est une grosse arnaque pour un hébergement mutualisé. Je craque d’impatience de découvrir mod_rubinius en tout cas.

Edit : Mes tests ont été fait sans Ruby Enterprise Edition mais même avec on arrive à une consommation de mémoire supérieure sur un seul spawn à Mongrel ou Thin.