Lorsque j’ai plongé dans la communauté Rails il y a 3 ans, elle n’était pas aussi riche qu’aujourd’hui : moins de monde, de livres, de blogs, de documentation, … Ça rendait les choses plus faciles car on trouvait assez rapidement les sources valables, mais en même temps il y avait beaucoup moins d’information disponible qu’aujourd’hui.

Je me suis dit que rassembler un peu mes sources et donner quelques conseils pouvait probablement aider des nouveaux venus.

Alors par où commencer ?

Contrairement à ce que j’ai fait, je pense qu’il faut commencer par aborder Ruby, en tant que langage.
Dans mon précédent article sur la comparaison de PHP/Symfony et Ruby/Rails, je disais qu’à mon avis, la principale force de Rails, c’est Ruby.

Ruby est un langage qui emprunte des concepts et tout un tas de mécanismes à d’autres langages, mais c’est aussi un langage qui étonne et surprend au début, par sa syntaxe et ses idiomes particuliers.
Pour éviter d’écrire du PHP ou du Java en Ruby, il est important de bien comprendre et intégrer le style Ruby ; la manière d’itérer dans un tableau, l’enchaînement des appels de méthodes, les blocks, l’absence de primitives, l’arborescence des types d’objets, …

Mise à jour : En tout premier lieu, jetez vous sur l’excellent Try Ruby! (in your browser) qui vous permettra en une quinzaine de minutes de voir différents aspects du langage. Merci à NiKo qui m’a rappelé cet oubli impardonnable, ou plutôt cette disparition entre mon brouillon et la version finale de l’article.

Pour cela, je conseille de parcourir la documentation de Ruby. N’ayez pas peur, c’est beaucoup plus concis que celle de PHP ou Java.
Ruby est composé d’une partie “Core” et d’un ensemble de “Standard Libraries”.
Chaque type d’objet dispose de méthodes, documentées de manière très lisible, avec des exemples d’utilisation.
On peut donc “lire” ces fichiers de doc et comprendre par exemple tout ce dont est capable la classe Array, le fait qu’elle partage des comportements avec Hash, via le module Enumerable, …
Les notions de manipulation/création d’objets personnalisés et d’instance de ces objets, l’héritage et la modularisation, la méta-programmation, l’introspection, … sont des concepts majeurs, qui seront mieux expliqués dans des livres et/ou articles de blog.

Le livre The Well-Grounded Rubyist (par David A. Black aux éditions Manning) est probablement le meilleur pour accompagner le novice en Ruby, y compris sur les terres de Ruby 1.9

Être capable d’écrire des bouts de programmes ou algorithmes simples, du genre de ceux qu’on apprend en cours à la fac est l’histoire de quelques jours où ont doit s’efforcer de rester un peu à l’écart de Rails.
Un bon petit exercice peut être de prendre un script shell et de le re-coder en Ruby, comme par exemple lister des fichiers dans des répertoires, renommer/déplacer certains qui seraient passés dans des filtres, …

Au mieux on aura assimilé Ruby, le plus vite on comprendra Rails.

Aborder Ruby on Rails, le framework de développement web

Pour commencer, je conseille la lecture de quelques articles :

• le guide “Getting Started”
• la page officielle “Get Better” et ses ressources liées

En parallèle, plonger dans 1 ou 2 livres est une très bonne chose car on y est accompagné par des experts particulièrement pédagogues :

• The Rails Way par Obie Fernandez, aux éditions Addison-Wesley, disponible en anglais seulement
• et aussi le très officiel Agile Web Development with Rails (3ème édition) par Sam Ruby, Dave Thomas et David Heinemeier Hansson, aux éditions The Pragmatic Bookshelf. Il est disponible en français et en anglais

On ne peut pas passer à côté des screencasts de Ryan Bates (Railscasts.com) et ceux de Geoffrey Grosenbach / Topfunky (Peepcode.com).

• les Railscasts sont gratuits. Un nouveau sort quasiment chaque semaine , il y a déjà plus de 180 épisodes, entre 5 et 20 minutes environ.
• les Peepcode sont payants et plus rares, mais la qualité du fond et de la forme en fond une ressource fondamentale. Je conseille l’abonnement illimité pendant 1 an, ça vaut vraiment le coup.

L’idéal est probablement de les regarder en diagonale une 1ère fois, en partant des plus anciens, sans trop s’attarder sur les détails car Rails évolue très vite et certains épisodes sont totalement obsolètes au niveau de l’implémentation. Par contre les passer en revue permet de se rendre compte des tendances et des techniques clés. Personnellement, je les ai tous en permanence sur mon disque dur et j’y reviens souvent.

Pour suivre les publications de tous les producteurs de screencasts, il y a Learnivore (par Thibaut Barrère – @tbarrere) qui les recense tous.

Le bon dosage théorie/pratique

Le risque à partir bille en tête dans un projet concret après avoir lu quelques articles et synthèses de livres, c’est qu’on va se limiter à la surface des choses, on va mal utiliser les outils à disposition ou utiliser le mauvais outil pour le boulot.

Je ne préconise pas non plus de passer 6 mois à lire tous les livres, sans toucher au clavier, car on apprend énormément en faisant soi-même, en confrontant ses idées à la réalité des fonctionnalités qu’on veut mettre en œuvre.

C’est pourquoi je pense qu’il faut conserver une bonne part de son temps à l’apprentissage pur. Revenir à la doc du langage et tester des méthodes qu’on connaît mal ou dont on avait oublié l’existence, lire et essayer de mettre en œuvre les bonnes pratiques décortiquées par les experts, …

Personnellement, je passe beaucoup de temps personnel à mon métier, mais c’est rare que je continue à la maison mon boulot de la journée. Je préfère utiliser ce temps pour mes lectures, mes recherches et tests, … Ça me permet de prendre du recul et avoir une perspective plus large. Au final, c’est ma compétence et ma productivité qui croissent, même si je ne passe pas plus de temps à pisser des lignes de code.

Sur ces points, je conseille vivement la lecture de la série d’article de Jamis Buck intitulée There is no magic, there is only awesome où il livre ses clés de la compétence : connaître ses outils, son langage, ses librairies et sa communauté. (NB : le début de la 1ère partie est assez particulière, ne bloquez pas dessus, le reste est passionant).

Intégrer les tests dans son apprentissage

Je ne vais pas faire l’article du Test-Driven Development (ni du Behavior Driven Development), mais j’insiste énormément sur le fait qu’il ne faut absolument pas négliger cet aspect là. Il ne faut surtout pas sauter les chapitres où les auteur parlent des tests, en se disant qu’on y reviendra plus tard, quand on on maîtrisera mieux le langage et le framework, et ce pour 3 raisons.

1. c’est très dur de revenir là dessus plus tard. On est vite pris dans la “production” et on a l’impression que c’est du temps perdu, ce qui est archi-indéniablement-faux.
2. ça aide énormément pour apprendre car on est en permanence à décrire ce dont on a besoin et implémenter ce qui satisfait ces besoins. On décortique systématiquement ce qu’on écrit lors des phases de refactorisation, …
3. c’est un pan entier de la culture Ruby et des avantages qui sont à porté de main. Le négliger serait comme ne jamais utiliser les tableaux ; on peut s’en sortir sans, mais quelle difficulté et quel dommage.

Sur la question des tests, je conseille le superbe livre The RSpec Book” (toujours en version bêta, en cours d’écriture), par un collectif d’auteurs (dont David Chemlinski) aux éditions The Pragmatic Bookshelf.

Lire du code, encore et encore

Une fois qu’on a compris le langage qu’on va manipuler, il n’y a rien de mieux que de lire du code
NB : regardez la vidéo de la conférence de JEG2 sur ce sujet

On préfèrera lire du code brillant, mais il faut aussi lire du code commun, voir sale, ça permet de mettre en perspective ce qu’est un code beau, efficace, lisible. Et d’ailleurs, plus on en lit, plus on sait faire soi-même la différence. Ruby encourage tellement l’écriture de code lisible et concis que lorsque ça ne l’est pas, c’est mauvais signe.

Les librairies standard sont un bon point de départ. Le code est principalement de très bonne qualité (à quelques exceptions près) mais n’est pas non plus sur-compressé et sur-intelligent (ça n’est pas son but).
Le code interne de Rails (ou plutôt ses librairies principales, comme ActiveRecord, ActiveSupport, …) est également une très bonne matière, mais comme tout bon framework, son code doit être le plus optimisé possible, le plus malléable et générique possible, au détriment de la clarté et de la transparence. On aura donc des fois du mal à démêler le fonctionnement de portion de code ou la méta-programmation et l’abstraction sont utilisés à plein régime.
Enfin, les librairies tierces les plus connues et utilisées sont de bonnes choses à lire. Leur succès au sein de la communauté est souvent signe de qualité du code.

Jamis Buck conseille de toujours lire le code d’une gem ou d’un plugin avant de l’installer et l’utiliser. Au mieux on aura parfaitement compris ce qu’il fait et comment l’utiliser à fond. Au pire on sera dégoûté de son fonctionnement et on le jettera aussitôt. Et souvent on se dira que ça vaut pas le coup de l’installer car on n’a besoin que de 10% de son code et qu’on ferai mieux de le recoder soi-même de manière plus adaptée à ses besoins.

Se tenir au courant de la vie de l’écosystème

Une fois qu’on a mise les pieds dedans et qu’on se dit qu’on n’a pas envie d’en sortir en courant, il faut bien se tenir à jour et continuer d’apprendre.

Pour ça je n’ai rien trouvé de mieux que de m’abonner à tout un tas de blogs et suivre pas mal de gens sur Twitter.

Avec un peu d’habitude on sait rapidement faire le tri entre ceux sur qui il faut se jeter sans attendre à chaque post et ceux qu’il faut garder dans un coin du radar car ils sortent de temps en temps un truc fort valable.

Je vous glisse ma liste de recommandations, à toutes fins utiles.

Les podcasts Rails Envy et Ruby5 permettent de suivre l’activité de la communauté Rails depuis de nombreux mois. À chaque épisode il y a les “show notes” pour retrouver ce qui a été évoqué.

Avec l’arrivée des listes sur Twitter, le mieux est de farfouiller dans les listes suivantes (dont la mienne).
En faisant des recoupements entre les personnes suivies, on se retrouve rapidement avec la crème de la communauté.

• @jlecour/ruby-rails
• @rails/core
• @joshpeek/rubyists
• @jamis/rubyists
• @bigfleet/rubyists
• @bitsweat/railed
• @bitsweat/rubyists
• @hashrocket/developers
• @rmanalan/ruby

Voici ma liste de blogs et sites suivis via RSS. Ils ne sont pas tous très actifs (heureusement) mais contiennent tous des articles très intéressants.

Quelques mentions particulières :

• Ryan’s Scraps ; Il décortique à l’avance les nouvelles fonctionnalités
• A Fresh Cup ; Les trouvailles quotidiennes d’un développeur Ruby/Rails fameux
• Giant Robots ; De très bons conseils et tutoriaux de la part d’une team qui produit beaucoup de très bons plugins/gems. Ils sont l’éditeur de Hoptoad (notifications d’exceptions)
• Ruby Best Practices ; Les meilleurs pratiques en Ruby, très avancé.
• Le blog de James Edward Gray 2nd ; Un développeur de très haut niveau qui poste des article très poussés sur les meilleures pratiques et des analyses de “produits”
• The Rails Way ; Les bonnes pratiques Ruby et Rails par KOZ (Mickael Koziarski)
• the { buckblogs :here} ; Le blog de développeur de Jamis Buck (état d’esprit, bonnes pratiques, analyses, …)
• The Journeyman Software Craftsman ; Le blog de Corey Haines sur son expérience de développeur itinérant. Beaucoup de réflexions et analyses sur l’attitude du développeur et les bonnes pratiques

Autres blogs et sites :

• 2dconcept – Ruby on Rails : http://www.2dconcept.com
• Brainspl.at : http://brainspl.at/
• code : http://norbauer.com/notebooks/code
• Code Snippets: rails code : http://snippets.dzone.com/posts
• Code Snippets: rubyonrails code : http://snippets.dzone.com/posts
• Delicious/popular/rails : http://delicious.com/popular/rails
• devpals – ruby : http://www.devpals.com
• Envy Labs : http://blog.envylabs.com
• err.the_blog : http://errtheblog.com/
• Frailers.net: Articles : http://www.frailers.net/articles.rss
• Frailers.net: News : http://frailers.net/posts.rss
• GitCasts Screencasts – HighRes : http://www.gitcasts.com/posts.html
• Gluttonous : http://glu.ttono.us/
• Hashrocket : http://www.hashrocket.com/blog/rss
• has_many :through : http://blog.hasmanythrough.com
• igvita.com : http://www.igvita.com
• J B. Rains : http://www.jbrains.ca/
• Join The Conversation : http://feeds.feedburner.com/JoinTheConversation
• JSBlogger : http://jumpstartlab.com/resources/rails-jumpstart/jsblogger/
• Labnotes : http://blog.labnotes.org
• Litany Against Fear : http://litanyagainstfear.com/
• Loud Thinking : http://loudthinking.com/
• Lucky Sneaks – Blog : http://feeds.feedburner.com/luckysneaks
• Nuby on Rails : http://nubyonrails.com
• overstimulate the feed : http://overstimulate.com
• Phusion Corporate Blog : http://blog.phusion.nl/
• PJ Hyett : http://www.pjhyett.com/
• pmade inc. Articles : http://www.contextualdevelopment.com
• Rails Jedi : http://www.railsjedi.com
• Rails Magazine : http://railsmagazine.com
• Rails Prescriptions 24 Hour Window Blog : http://blog.railsprescriptions.com/posts
• RailsLab : http://railslab.newrelic.com/articles.rss
• RailsTips : http://railstips.org/
• Riding Rails (blog officiel de Rails) : http://weblog.rubyonrails.org/
• rpheath.com : http://rpheath.com
• Ruby Best Practices : http://blog.rubybestpractices.com/
• Ruby Discoveries and Idioms : http://redcorundum.blogspot.com/
• Ruby Inside : http://www.rubyinside.com
• Ruby Lang (site officiel de Ruby) : http://www.ruby-lang.org/
• Ruby on Rails Plugins : http://agilewebdevelopment.com/plugins/recent/
• Ruby on Rails Resources : http://agilewebdevelopment.com/resources
• Ruby Plus : http://www.rubyplus.org
• RubyFrance : http://rubyfrance.org/rss/
• RubyTu.be : http://rubytu.be/
• sd.rb podcast : http://sdruby.org
• Segment7 : http://blog.segment7.net
• SoliSoft.net : http://solisoft.net
• The Budding Rubyist : http://buddingrubyist.wordpress.com
• The GitHub Blog : http://github.com/blog
• The Pug Automatic : http://henrik.nyh.se/
• Trek : http://wonderfullyflawed.com
• Viget Extend : http://www.viget.com/extend/

J’espère vraiment que cet article sera utile. Il ne reflète que mon avis et mon expérience.

Si vous avez des avis et des suggestions, n’hésitez pas à utiliser les commentaires pour ça.

J’ai suivi les conseils de Dan Benjamin et sur mon Mac, j’ai installé (entre autres) MySQL depuis les sources et non pas depuis un paquet préparé par MySQL Sun Oracle.
La procédure est très simple, pas de soucis de ce côté là.

Par contre on se retrouve avec un serveur qui est géré par launchd. C’est parfait à beaucoup d’égard (je ne vais pas faire l’article de ce superbe “logiciel”, vous trouverez tout chez Apple et Wikipedia) sauf lorsqu’on veut démarrer/arrêter le serveur MySQL manuellement, comme après un changement de config, …

Pour cela il faut lancer ceci via le terminal :
sudo launchctl unload -w /Library/LaunchDaemons/com.mysql.mysqld.plist
Pour le démarrage, c’est bien sûr load à la place de unload

C’est pas si simple à mémoriser si on s’en sert très rarement, et c’est un peu casse-pieds si on s’(en sert souvent. Alors comme en plus je ne suis pas très fort en shell, je me suis dit que je pouvais écrire un petit script pour le faire à ma place.

Remarquez, j’aurai pu faire un alias dans mon environnement Bash, mais j’ai préféré partir sur le script autonome.

J’ai choisi le nom mysqlctl pour ressembler à divers commandes existantes, comme apachectl, et comme me l’a fait remarqué Colinux, ça n’est pas le nom d’un binaire/script “officiel” de MySQL, donc pas de risque de confusion.

Vous trouverez ce script (et le fichier de config de MySQL pour launchd) sur GitHub. Vous pouvez librement le télécharger et l’utiliser, mais aussi faire un fork et proposer des corrections et/ou améliorations.

What I’ve found

A few minutes ago, I was watching a great screencast of Corey Haines doing a kata.
I stopped when he was refactoring a few similar assigments. There was something I’ve never seen elsewhere, particularly in the also great RSpec book ; he used the let() method.

Going back and forth a few times, I understood the the method was assigning the result of the given block to an object named after the argument of let().

I googled to see if there was an explanation ; is it a custom helper he wrote, is it built-in RSpec, … ? but “RSpec let()” is returning a lot of results, and none was close to the answer I was looking for.

I then looked at the Rdoc for the RSpec gem ; no luck either.

Finally, I open the whole gem in Textmate and looked for “let” as a word.

I’ve found a use of the method in a spec (RSpec is speced with itself, how great is it?) with a similar scenario. I’ve also found the method declaration, and I have to say that it’s pretty self-explanatory :

  def let(name, &block)
    define_method name do
      @assignments ||= {}
      @assignments[name] ||= instance_eval(&block)
    end
  end

You have to pass a name and a block. It defines a new method (named after what’s in ‘name’). This new method returns the result of the block (whatever it returns) but is memoizes it in a global hash.

You can use the let() method in a describe block, if you want to create a method that is always returning the same value, determined by the result of the passed block. It is something you can do with a traditional before block with a simple variable assignment, but it’d be evaluated each time, though it’s not necessary. A simple variable is also subject to change if it’s not frozen or a constant.
Here, it’s just what it is and only what it needs to be.

What I like

First, I like that some very simple but usefull tools are available. I really sounds like something build after hundreds of times of repeating the same calls, … It’s very concise and DRY.

But I also like very much the way the hash is created if it doesn’t already exist, and the value is set only once,even on subsequent calls of the new method.

The dynamically created method could have been defined this way :

  define_method name do
    @assignments = {} if @assignments.nil?
    if @assignments[name].nil?
      @assignments[name] = instance_eval(&block)
    else
      @assignments[name]
    end
  end

but it’s boringly verbose and repetitive. The first way is way more readable and elegant.

If I have remember just a thing from Corey’s screencast, it’s the existence and the use of this beautiful let() method and how well it is written.

About Corey Haines

Corey is a great guy, one of the few that I really admire.

Amongst the thing that I like about him, he’s doing something that I’d really like to do : he’s traveling all over the USA and is offering to share some working (and fun) times for hospitality and friendship.

You can find about what he does on his profile page.

Thanks Corey !

Update 1 : The entire Kata is available on GitHub. There are 3 branches : the first is the start of the kata, with only the setup and the cucumber expectations. The second and third are implementations.

It’s very useful to read the initial state of the Kata and see where it ends, with all the tests and the implementation code.

Dans le cadre de mon travail chez Autrement, je bosse principalement sur du développement web en Ruby, avec l’aide du framework Ruby on Rails.

Je suis focalisé sur le développement d’une appli web (encore un eu secrète pour le moment), mais là, Autrement édite par ailleurs le site web chambresapart.fr
Le développement de ce site a commencé bien avant que je rejoigne l’équipe et il s’appuie sur le framework Symfony, basé sur PHP.

Actuellement l’équipe Chambres à Part se compose de 2,5 personnes qui sont toutes les 3 des développeurs confirmés, spécialisés sur PHP / Symfony.

Avant le lancement de la “version 1″ de Chambres à Part, j’ai participé au développement de certaines fonctionnalités, mais principalement sur des aspects HTML, CSS, Javascript, cartographie Google + Maptimize, …
La dernière semaine a été uniquement consacrée à du debuggage et pour ça j’ai mis un peu plus mon nez dans le code source du site et donc dans la partie “vue” (le V de MVC).

Je ne peux surtout pas prétendre connaître Symfony dans ce qu’il a de particulier par rapport à d’autres framework web (et MVC en particulier), mais je peux comparer ce que j’ai vu et ce que l’équipe raconte au quotidien avec ce que je connais et vis au quotidien depuis 3 ans avec Ruby et Rails.

De plus, j’ai développé quasi-exclusivement en PHP depuis les premiers temps du PHP3 jusqu’à PHP5, donc même si j’ai passablement oublié certains réflexes de manipulation du langage et la plupart de noms de méthodes, je pense avoir un avis assez circonstancié sur PHP.

La question

Pour le développement de la partie visible du projet sur lequel je suis mobilisé, d’autres personnes de l’équipe vont participer activement et durablement. Une question se pose donc inévitablement : Ruby on Rails ou bien Symfony ?

Notre boss comprend bien quand on lui parle de technique, avec des arguments clairs, mais il ne se sent pas (à raison) en mesure de décider lui-même d’un framework ou d’un langage plutôt qu’un autre. Il nous a donc demandé de préparer une discussion sur cette question, en apportant surtout des faits et des remarques objectives afin de tout mettre sur la table et tenter en équipe de prendre la bonne décision.

Je suis convaincu qu’il ne s’agit pas de valider ou invalider les choix des uns et des autres, mais plutôt de faire un état des lieux et s’orienter dans la meilleure décision.

Comme je suis quelqu’un de passionné, et qui ne se lance dans les choses qu’avec une forte conviction, j’ai quand même envie de convaincre que mon choix de quitter le développement en PHP pour le faire en Ruby n’est pas juste “mon choix” mais un choix lucide et cohérent.

Alors j’ai sorti un bout de papier et un crayon (ou plutôt un document “untitled.txt” et mon beau clavier) pour pondre une liste d’arguments.

Et puis je me suis dit que garder tout ça pour nous, en interne, était un peu égoïste. Pourquoi ne pas partager mes observations et mon analyse. Je ne pense pas que quiconque (au delà de notre équipe et mes copains geeks) s’intéresse à mon avis sur la question, mais un avis, ça peut donner des idées, participer à une réflexion, …

Présentation factuelle de Ruby et Rails

Ici je ne présente que des points clés, du moins ceux auxquels j’ai pensé.
Je ne détaillerai pas ces points, d’autres l’ont fait bien mieux que moi.

Ruby

• 100% objet, pas de primitives
• langage concis et lisible : moins de code, moins de bugs
• langage dynamique, fortement typé
• imprégné des méthodes de tests TDD et BDD (nombreux frameworks disponibles)
• synergie avec les méthodes agiles
• Ruby en ligne de commande (IRB), pratique pour des essais, …
• Rubygems : gestionnaire de paquets additionnels
• vitesse d’apprentissage
• syntaxe et idiomes riches et avancés
• meta-programmation
• inspiré des meilleurs langages reconnus : Smalltalk, Lisp, Python, Perl, …
• forte implication et marques de confiance des ténors : IBM, Sun, Apple, Microsoft, SAP, …
• de nombreux frameworks de premier plan : Rails, Sinatra, …

J’invite à la lecture de la page de Ruby sur Wikipedia, que je trouve assez complète et claire.

Rails

• dédié au développement d’appli web
• architecture MVC
• naturellement REST
• forte incitation à DRY
• convention plutôt que configuration
• grand variété de helpers
• des outils annexes très utiles : débuggage, déploiement, monitoring, …
• des environnements d’exécution bien définis et cloisonnés
• WebServices-friendly
• système strict de migration des bases de données
• framework complet accessible en ligne de commande
• variété de backend pour le cache et les sessions : mémoire, fichiers, BDD, memcached, …
• I18n
• communauté très active
• documentation riche (en ligne, livres, …)
• Rack middlewares => empilement de briques fonctionnelles dédiées et modulaires : cache, debug, auth, …
• logging avancé et personnalisable
• fortes opinions, mais autres choix possibles : ORM, templates, framework JS, …

Pour une introduction à Rails, je vous renvoie vers le le guide de démarrage pour Rails ou Rails in a Nutshell (qui est encore en beta).

Analyse subjective (mais convaincue) de Ruby & Rails vs. PHP & Symfony

Là, je sors un peu des faits indéniables pour m’aventurer dans ma propre analyse des différences entre ces 2 frameworks (et leur langage sous-jacent respectif). Cette analyse est forcément subjective et je serai ravi d’entendre des avis contraires ou complémentaires.

PHP vs. Ruby

Prenons la métaphore de la caisse à outils.

PHP est une énorme caisse, dans laquelle il y a des outils pour presque tout, tellement que ça devient difficile de tout connaître. Il n’y a qu’à voir le site de la documentation officielle où le nombre de méthodes est impressionnant, sans parler de celles des librairies standards.

Il y a souvent plusieurs outils ou variantes pour faire presque la même chose. C’est pas forcément facile de savoir lequel choisir.

Cette boîte grandi très vite, il y a régulièrement de nouveaux outils, d’autres évoluent et certains disparaissent.

Ruby est une caisse beaucoup plus modeste, qui permet de faire tout autant de chose, mais il y a très peu de doublons ou recoupements.

Les outils sont robustes, stables et surtout cohérents entre eux. Le contenu de la boîte évolue peu, rarement et uniquement en cas de forte nécessité. Même entre les versions majeures (1.8 et 1.9) il y a très forte compatibilité. Au sein de la branche 1.8 il n’y a eu presqu’aucune perte de compatibilité importante depuis plus de 3 ans (sortie de la 1.8.5 en août 2006).

Les mises à jour de Ruby, en tant que langage, sont rares (12 à 18 mois entre chaque version stable) car il n’y a pas ou extrêmement peu de bugs, elles ne concernent que des nouveautés ou améliorations de fond. La raison de ce très faible nombre de bugs et failles de sécurité sont simples : le code est soumis à des tests systématiques et poussés (c’est dans la culture de la communauté Ruby) et le code étant simple lisible et clair, il est facile de l’auditer et le comprendre et donc d’en débusquer les failles.

À l’inverse, PHP est mis à jour beaucoup plus souvent (plusieurs fois par an) et contient de nombreux correctifs de bugs en plus de nouvelles fonctionnalités. Il est reconnu que les failles de sécurité importantes ou critiques sont relativement fréquentes.

La raison d’être de PHP n’était pas d’apporter une approche nouvelle du développement mais de répondre à un besoin simple et bien identifié : traiter les données issues d’un formulaire web. La simplicité et les fonctionnalités de ce nouveau langage l’ont rendu rapidement populaire chez les développeurs web car il n’y avait plus besoin de faire des CGI en Perl pour rendre des sites dynamiques.

Face à ce gain de popularité, le langage a grandi et permis de faire de plus en plus de choses assez facilement, mais rapidement on a constaté le manque de fondations solides, en particulier sur l’aspect Objet.

PHP rivalise alors, en terme de popularité et d’audience, avec Perl, Java, … et cherche alors à combler les manques et répondre aux critiques. Le résultat est plutôt efficace, mais les outils du début restent là et les mauvaises pratiques qui vont avec aussi.

Au final on a un langage riche, mais brouillon, fourre-tout, qui évolue par stratification et pas par transformation. Les fondations manquent de rigueur et de profondeur.

Ruby est un langage qui a été conçu avec une approche plus scientifique et globale. Son créateur voulait un langage moderne, plus proche des attentes de l’humain que de celles de la machine, mais qui reconnaisse et embrasse l’état de l’art, ce qui s’est fait de mieux. Il s’est donc contenté (si on peut dire) d’appliquer la parole des vieux sages dans un contexte moderne.

Ruby adopte le principe de la moindre surprise (au sens de la cohérence maximale) selon lequel le langage doit se comporter de manière à minimiser la confusion. Lorsqu’on découvre Ruby, qu’on vienne de Java, PHP ou Python, on est forcément surpris par la syntaxe, les idiomes, … mais avec le temps on adopte la “manière Ruby” et plus rien n’étonne. Dans d’autres langages, même après plusieurs années d’utilisation, on est parfois étonné ou dérouté par certains fonctionnements.

La syntaxe du langage est au service de son utilisateur, en favorisant la lisibilité et la concision. La simplicité des outils de base permet d’apprendre vite et de savoir rapidement lequel utiliser.

Ruby est bâti sur des fondations robustes et très strictes ; celles du tout Objet (il n’y a pas de primitives), de la meta-programmation, du typage dynamique mais fort, …

Symfony vs. Rails

Ruby on Rails est issu du développement d’une application web (Basecamp). Son créateur voulait se lancer dans le développement web et a cherché le langage avec lequel il se sentait le plus à l’aise et il s’est arrêté sur Ruby. Il a ensuite échafaudé un framework dédié au web en tirant réellement parti de ce que permet Ruby.

La démarche partait d’un objectif/besoin connu, il fallait trouver l’outil adapté pour l’atteindre.

Rails ne serait pas ce qu’il est sans Ruby. On ne peut pas recréer Rails sur un autre langage sans faire des tours de passe-passe et en perdre l’essence.

Symfony est issu du manque de bon framework web en PHP. Son créateur a voulu reprendre les bonnes idées d’autres frameworks (surtout Rails) sur d’autres langages pour les adapter sur PHP.

La démarche semble différente et partir d’un langage connu sur lequel construire en s’inspirant de références.

Pour ce que j’ai pu en voir et pour que Symfony ait le succès qu’il a, son développeur principal et la communauté qu’il a agrégée ont forcément accompli quelque chose de remarquable.

Pour autant, j’ai le sentiment que le plus grand handicap de Symfony, c’est PHP.

Conclusion

Au final, on sent que j’ai les idées bien arrêtées. J’espère ne pas avoir faire preuve de mauvaise foi ni avoir dit trop de bêtises.

Il m’arrive de dire que telle techno ou tel produit sont nuls. Mais pour le cas de PHP (et donc de Symfony), je ne dis pas que c’est nul et bon aux orties, au contraire.

Je dois certainement mon parcours de développeur web à PHP et à ce que j’ai pu faire avec. J’ai juste l’intime conviction d’avoir trouvé une évolution, une suite, qui me permet d’aller plus vite, plus loin, avec plus de plaisir/passion.

C’est un peu comme de passer de CVS ou Subversion à Git ou Mercurial. Vu de loin c’est la même chose, mais de près, ce sont 2 générations d’outils sui marquent un véritable progrès.

Mise à jour 1 : Au terme d’une longue réunion d’équipe, nous avons choisi une approche à 2 têtes. Le premier projet (Chambres à Part) reste évidemment développé avec Symfony (donc en PHP) mais le second sera entièrement développé avec Ruby on Rails.

Évidemment, je pense que c’est le bon choix. Pour moi, c’est surtout le bon choix technologique, pour toutes les raisons que j’ai déjà développées plus haut.

Du point de vue de la stratégie d’entreprise, je trouve que la prise de risque est modérée et ça va nous mettre dans une situation de réelle fusion et enrichissement des compétences.

Pendant les prochains mois, ceux parmi nous qui “viennent de Symfony” vont devoir apprendre de nouvelles choses en mettant à profit leurs années d’expérience en développement et particulièrement avec un framework MVC, … Le challenge sera de tirer le plus profit de cette expérience proche tout en “embrassant” les particularités de Ruby et de Rails.

Quelque part, ça va me mettre en situation de formateur, ce qui est très excitant mais aussi une responsabilité forte. Mais comme je suis absolument passionné par ce que je fais et connais, je vais me régaler dans cette partie de mon boulot.

Par ailleurs, cette juxtaposition d’outils va me permettre de voir plus en détail l’univers de Symfony et les évolutions de PHP (depuis que je l’ai laissé de côté). Même si je ne vois pas mon avenir de ce côté là, ça me forcera à être un peu moins monocorde.

Enfin bon, je suis bien content que la balance ait penché, non pas de mon côté (ça serait une marque d’égo) mais du côté que j’ai choisi.

Mise à jour 2 : Vous trouverez sur le site de Ruby une courte liste des similitudes et différences à quoi s’attendre en passant de PHP à Ruby.

Je suis récemment tombé sur le blog de Jay Fields et j’y ai lu cet article intitulé “Staying Current: A Software Developer’s Responsibility” avec lequel je suis complètement en accord.

Avec sa permission, je l’ai traduit en français, malheureusement de manière trop littérale.
Le contenu (au format Markdown) est disponible et modifiable sur http://gist.github.com/174953. Si vous proposez des améliorations de traduction, je les prendrai certainement en compte.

J’ai un dégoût personnel pour les conférences le week-end *. Pour moi, une conférence le week-end garanti que je vais “bosser” 12 jours d’affilée.

J’ai bien conscience que cette opinion n’est pas universelle.

Certaines personnes ont des difficultés pour “décrocher” pour aller à des conférences. Ces situations ont bien l’air d’une mécompréhension des responsabilités d’un développeur logiciel. Une partie de votre boulot (de développeur logiciel) est de rester à jour technologiquement. Ça signifie passer du temps de recherche durant votre journée.

(à peu près piqué directement à Ward sur le déficit technique)
Si vous passez toute votre journée à coder, sans jamais regarder du coté des nouvelles choses, vous accroissez votre déficit technique. À court terme (disons la dernière semaine avant une release), ça a du sens de prendre un peu de déficit. Par contre, à long terme, sans un minimum d’investissement, l’intérêt (où l’intérêt est égal à la distance entre vos compétences et les solutions actuelles) vous rendra NZPP (Net-Zero Producing Programmer). Dans une organisation type, vous pouvez peser en tant que NZPP pour environ 6 mois and doucement glisser vers un NNPP (Net-Negative Producing Programmer).

C’est de votre responsabilité de ne pas devenir un NZPP (ou un NNPP). Les développeurs les plus talentueux refusent de travailler avec des NZPP. Lorsque vous devenez un NZPP, vous devez habituellement déclarer faillite (au regard du développement logiciel). Vous avez généralement deux choix : prendre un travail moins payé où vous pouvez apprendre de nouvelles choses ou bien passer à un nouveau rôle. Si vous voulez être un développeur logiciel, aucune de ces issues n’est désirable.

Par chance, vous avez la force de ne pas devenir un NZPP. La plupart des employeurs seront ravis de vous acheter des livres techniques et de vous envoyer à des conférences techniques. À mon avis, que vous tiriez ou pas de ces avantages devrait être dans votre revue de performance. Ne pas rester à jour en tant que développeur logiciel, en lorsque l’opportunité vous en est offerte, est une mauvaise pratique logicielle.

Une fois, j’ai créé une liste de choses que je recherchais chez des collaborateurs potentiels.

• Avez-vous déjà testé le Test Driven Development ? Pouvez-vous citer quelque chose que vous aimez et que vous n’aimez pas ?
• Dans quel(s) langage(s) qui gagne(nt) en popularité, mais qui ne sont pas encore de pleine notoriété, avez-vous écrit un “Hello World” ?
• Lisez vous des livres ou des blogs à la recherche de nouvelles idées au moins une fois toutes les deux semaines (en moyenne) ?
• Essayez vous d’appendre au moins un nouveau langage tous les ans ?
• Avez vous déjà utilisé un outil de recherche de couverture de code ou de complexité cyclomatique sur du code que vous avez écrit ?

Quelqu’un a un jour commenté à peu près ceci :
Tout le monde n’a pas le temps personnel pour faire ce genre de choses
Et c’est là une faille fondamentale. Les employés (et même les employeurs) semblent penser que ce sont des activités qui doivent être conduites hors du temps de travail. Je ne peux être moins en désaccord. Ce sont des choses qu’un développeur responsable doit faire dans le cadre de leur travail, et donc dans les heures de travail.

20% du temps, ça n’est pas quelque chose que Google a inventé, c’est juste quelque chose qu’ils ont nommé, formalisé et rendu populaire. Cette activité en soi est quelque chose que les bons développeurs logiciel font depuis des années. J’applaudi Google pour en avoir fait un standard et ainsi d’assurer que ses employés aient l’opportunité de rester à jour. Cependant, votre entreprise n’a pas besoin de standardiser les 20% de temps pour que vous restiez à jour.

C’est votre responsabilité de prendre le temps dans votre journée de lire un livre ou un blog.

Vous devriez aussi tirer profit d’un déplacement (sponsorisé par votre entreprise) à une conférence. Si vous vous êtes déjà rendu à une conférence et que vous en avez tiré qu’un faible profit, je suggère grandement les conférences QCon et JAOO.

Une fois que vous avez commencé à faire vos recherches dans vos heures de travail, vous trouverez que ces conférences sont juste du travail, sauf que vous êtes focalisés à 100% sur la recherche. Et c’est pas quelque chose que vous souhaitez (ou devez) prendre sur votre temps personnel, c’est juste une autre journée productive à faire ce que vous avez la responsabilité de faire.

* C’est pourquoi Josh et moi organisons SpeakerConf mardi-jeudi. Vous pouvez y aller, participer et rentrer sans avoir à rater un jour de week-end.

Il y a juste un point sur lequel, je ne suis pas 100% d’accord, c’est la frontière entre temps perso et pro.
Je suis tellement passionné par ce que je fais que je passe aussi du temps perso sur des sujets de boulot. Mais il est clair que je le fait par passion, et en plus de ma journée normale de travail qui contient déjà du temps de recherche, lecture, …

La société Autrement (pour laquelle je travaille avec un immense bonheur depuis quelques mois) recherche un développeur web (indépendant ou pas) pour bosser sur du PHP/Symfony + HTML/CSS/JS pendant quelques mois (si possible à plein temps ou presque).

Idéalement c’est quelqu’un :

• qui connaisse bien le framework Symfony, sinon un framework MVC “mature”
• qui ait déjà travaillé concrètement sur des sites web ayant des fonctionnalités “modernes”
• qui puisse intervenir sur toute la chaîne ; du PHP au JS en passant par HTML/CSS
• qui soit rôdé au travail en équipe
• qui travaille sur Mac et/ou un OS libre
• qui ait son propre ordi
• qui soit geek et drôle
• qui apporte des croissants le matin et/ou qui sache faire des gâteaux ou toute autre sorte de bonne chose qui se mange (pas obligé de le faire tous les jours)
• qui aime les pâtes (on va souvent chez Delouss)
• …

Pour l’état d’esprit général de la boîte, il suffit de lire le blog : http://autrementleblog.com/

Si vous pensez pouvoir faire l’affaire, envoyez un petit mail à job [a] autrementlemail.com ou déposez un commentaire à ce post.

NB : ça se passe au 27 rue Fongate à Marseille (plein centre ville).

Mise à jour du 4 juillet : tout se termine parfaitement bien, les détails en fin de post.

C’est pas souvent que je pousse ma gueulante, mais là, j’ai vraiment envie.

En quête d’un appareil pour ma cuisine, je compare les produits dans une gamme de prix, je trouve celui que je veux et je cherche ensuite le moins cher. Merci internet, ça facilite vraiment la vie.

Le moins cher de la liste, donc, c’est “Mais Moins Cher” (http://maismoinscher.com/).

Moi qui ne suis pas un acheteur très régulier, je ne connais pas cette enseigne.

Bon, le design du site est moche, mais c’est pas ça que j’achète.

Je cherche un peu à savoir si il appartient à un grand groupe ; ça n’a pas l’air. La société est basée à Gaillac.

Ils ont l’air certifiés FIA-NET, … c’est rassurant. Je me dit que je vais tenter le coup, de toute façon les concurrents connus ne sont pas forcément au top non plus, donc va pour Mais Moins Cher.

Le processus de commande se passe bien, j’ai même la possibilité de payer avec une carte bleue Crédit Mutuel, je n’ai même pas à saisir mon numéro de carte, juste à m’authentifier sur le site de ma banque. C’est très pratique et je me dis que la sécurisation doit être plus importante, autant pour moi que pour le commerçant.

Vu que j’ai commandé assez tard, l’interface de suivi de commande (très bien foutue) m’indique que mon paiement n’a pas encore été autorisé.

Le lendemain matin, le paiement a l’air OK, et je reçois un mail de Mais Moins Cher me demandant un justificatif de domicile. C’est assez étonnant vu le montant de la commande (une centaine d’euros), mais pour une première commande en VPC, ce genre de demande n’est pas rare.

C’est là que ça se gâte.

En fait ils me demandent un original de facture EDF, FT, … en précisant que les copies ne sont pas acceptées. Pardon ??? un original ??? et je fais comment moi après ça, quand je l’ai plus mon original ?

Passons ce détail, j’envoie une facture Free en PDF. Il ne devrait pas y avoir de soucis, vu que la préfecture l’a acceptée pour un passeport.

La réponse ne se fait pas attendre :

“Merci de nous envoyer ce justificatif par courrier.”

Tiens, c’est étonnant, pourquoi ils veulent du papier ?

Il y a un mois de ça, j’ai créé mon entreprise en ne donnant aucun papier.

Ne sont-ils pas sensibles à l’économie de papier, d’encre, de temps, de place, … admettons que non. Ben ils n’ont qu’à l’imprimer eux-même, ou me donner leur numéro de fax.

Les réponses successives que j’ai eues tout au long de la journée ont toutes été du genre :

“je suis désollée, mais c’est la procédure.”

Je veux bien changer d’avis, mais il me faut des arguments. Le seul que j’ai eu est celui-ci (les fautes sont d’origine) :

“Pour le papier par la poste je n’ai pas le choix car n’importe qui peut scanné un papier sur l’ordinateur. Merci de nosu l’envoyer par courrier.”

Ah bon ! Mais mon document est un PDF dès l’origine ! La version papier n’est qu’une copie. Et en plus, falsifier une facture en papier est très facile, ça ne prouve donc rien de plus qu’un PDF.

J’ai essayé d’argumenter en retour, mais rien de concret n’en est sorti, que des

“c’est notre procédure”

Si j’avais voulu les arnaquer, j’aurai effectivement payé avec une CB volée ou autre et j’aurai envoyé par la Poste, sans rechigner, une très belle fausse facture ayant tout l’air d’un original.

J’ai fini par envoyer ma facture PDF imprimée, par la Poste, car je tiens plus à recevoir ma commande qu’à changer le monde.

Au final, personne n’a rien gagné.

De mon côté, j’ai perdu 1 ou 2 jours pour le traitement de ma commande à cause des délais postaux et de ces 12 mails échangés.

Du côté de Mais Moins Cher, ils ont perdu un client qui avait un fort a priori positif sur la marque et en plus ils n’ont même pas gagné en sécurité pour la transaction.

Je suis complètement abasourdi par ce genre de comportement et de rigidité.

J’ai tendance que c’est plus le manque de compréhension des réalités “techniques” qui les pousse à agir comme ça que la volonté de rendre les choses compliquées, mais bon …

Je ne sais pas si ce coup de gueule leur fera prendre conscience de l’inutilité de ce genre de chose. En attendant, ils ne me reverront plus sur leur site.

La commande est bien là, en bon état et dans les temps.

Par contre, ce matin, j’ai trouvé dans ma boîte, une lettre envoyée par Mais Moins Cher, avec mon adresse écrite à la main. À l’intérieur … ma facture Free ! Ils m’ont renvoyé l’impression de mon PDF ! Trois choses me sont rapidement venues à l’esprit :

1) ils pensent réellement qu’un PDF imprimé à la maison a une quelconque valeur. Ça n’est pas à leur avantage, car ça confirme leur faible culture technico-informatique.

2) ils renvoient la facture après s’en être servi. Là c’est tout à leur avantage car ils réclament un “original” mais ils le renvoient car ils ont conscience que ça a de la valeur. Par contre ils feraient bien de le signaler, on aurait moins peur de le leur envoyer en premier lieu.

3) Ce ne sont pas de gens malhonnêtes ni des emmerdeurs. Ils sont de bonne volonté et finalement précis (délais, engagements, …), contrairement à ce que j’ai pu lire ça et là. Ils ont juste un gros problème de procédures qu’ils ne comprennent pas (en tous cas, qu’ils n’expliquent pas), ce qui donne beaucoup de temps perdu au client et aux services qui s’en chargent chez eux. Il faudrait certainement peu de chose pour améliorer ça.

En fin de compte, je ne suis plus aussi mécontent. Je vais leur envoyer un lien vers ce post, au cas où ils ne l’auraient pas déjà vu et leur proposer de discuter de tout ça s’ils en ont envie.

Comme tous les mois depuis bien longtemps, le PLUG organise sa soirée mensuelle.

Ouverte à tous les fans de technologie, informatique, logiciels libres, … c’est la bonne occasion pour discuter de ses passions, rencontrer du monde, discuter de sujets connus ou pas et dans un endroit particulièrement sympa et confortable (La Bo[a]te).

Au programme de juin :

• quelques sujets courts et libres inspirés de l’actualité et/ou de découvertes (l’improvisation est encouragée)
• introduction pour la série sur le “Contrôle de version” ; c’est quoi ? pour quoi faire ? …

Et comme à chaque fois :

• convivialité
• apéro, pizza, …
• rencontres, découvertes, …

Tous les détails sont dispo sur le site du PLUG : http://plugfr.org/

Lorsque je travaille sur des applis web, j’aime bien avoir un environnement de développement local et lorsque tout est OK, j’envoie ça en production. C’est un processus classique et devenu très facile avec les outils de versioning et de déploiement. C’est encore plus vrai dans l’écosystème de Ruby on Rails où tout est pensé pour facilité cette séparation des environnements d’exécution tout en ayant des procédures de déploiement fiables et simples.

Je travaille actuellement sur un site basé sur WordPress (en PHP donc). Le site n’est pas encore en production, sur un sous-domaine temporaire, pour autant je n’aime pas travailler avec un client FTP et ouvrir les fichiers un par un, … et surtout être dépendant de la connexion internet pour avancer.

J’ai souhaité avoir un environnement pour ça aussi facile qu’avec des applis Rails. Le principal soucis était la gestion d’un domaine local et d’un Virtual Host pour Apache car pour les applis Rails il existe un outil accessible dans les Préférences Système qui s’appelle Passenger Prefpane [1] et qui configure en 3 clics le DNS local et Apache pour servir une application Rails via Apache + Phusion Passenger.

Les purs *nixiens me crieront dessus qu’il suffit d’éditer le fichier /etc/hosts + créer un bout de conf pour le VHost. Je sais parfaitement faire ce genre de manipulations, mais j’ai aussi un goût prononcé pour la stratégie du moindre effort.

De plus, sous Mac OS X il y a mieux qu’éditer le fichier Hosts : dscl – Directory Service command line utility [2]

Un amateur de toute cette facilité, qui comme moi ne trouvait pas son plaisir avec la gestion générale (hors applis Rails) des domaines+VHost a écrit un script en ruby [3] qui permet de créer facilement une entrée DNS et un virtual Host.

$ sudo apacherb create my_app.local /path/to/my_app/

Je suis donc ravi car je peux très facilement ajouter des domaines + VHost locaux, en une seule ligne.

• [1] http://www.fngtps.com/passenger-preference-pane
• [2] http://developer.apple.com/(…)/dscl.1.html
• [3] http://chrisroos.co.uk/(…)

Mise à jour

Apacherb devient Hostess : http://chrisroos.co.uk/blog/2009-06-23-apacherb-is-now-hostess

Je viens de terminer et (assez longuement) raconter la migration que j’ai effectuée au boulot.

J’ai transformé le fonctionnement de plusieurs sites web à base de Nginx/Mongrel/Rails et Nginx/PHP-FCGI en Apache/Passenger et Apache/mod_php.

Tout est là :
- préambule
- Ruby Entreprise Edition
- VirtualHosts
- épilogue

Je me suis régalé à faire ça tranquillement, mais avec tout de même une bonne pression, car c’est sur un serveur de prod et c’était une première dans le genre pour moi.