Monter dans le train de Ruby et Rails

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.

Rester à jour : la responsabilité du développeur (traduction)

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, …

“Mais Moins Cher”, mais pas mieux pour autant

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.

---

Mise à jour du 4 juillet

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.

Twitter

C’est vrai que je blog pas beaucoup ces derniers temps. Par contre, je poste de temps en temps ds trucs via Twitter. Pour ceux qui connaissent pas c’est une sorte de mix entre le blog et le SMS : du nanoblogging comme on dit.

Vous pouvez suivre mes tweets ici : http://twitter.com/jlecour

La liste de ceux que je suis : http://twitter.com/jlecour/friends. C’est surtout l’univers du développement web, mais pas que.

 

À voir aussi, le flux de Neomarco (http://twitter.com/neomarco) pour suivre les annonces et infos rapides de Neomarco.

Soirée PLUG : Les services web et leur infrastructure d’hébergement

J’annonce rarement les réunions du PLUG, ce qui est une honte vu mon role dans cette association, mais cette fois, ça vaut encore plus le coup que d’habitude.

Nous organisons une soirée spéciale sur le thème : les services web et leur infrastructure d’hébergement.

Le domaine est très vaste et relativement peu documenté vu la vitesse à laquelle les choses évoluent. L’idée est de réunir des gens qui souhaitent faire part de leur expérience et écouter celle des autres pour enrichir leur connaissance du sujet.

La soirée aura lieu en 2 temps, les vendredi 7 novembre et 5 décembre, à La Bo[a]te à Marseille.

Pour plus d’info, référez vous au site du PLUG et la page dédiée à l’annonce de cette soirée.

N’hésitez pas à m’écrire directement ou par les commentaire à ce post pour donner des idées, poser des questions sur la soirée, …

Neomarco.com lance son Grand Jeu “Objets du Monde”

J’ai un billet sous le coude expliquant ma transition de Ubik Lab vers Neomarco, mais je ne résiste pas plus longtemps à l’envie de vous proposer d’aller jouer sur le Grand Jeu que nous avons lancé aujourd’hui.

Sur http://neomarco.com, vous trouverez l’accès au Grand Jeu ”Objets du Monde”. C’est très facile de jouer et de très beaux lots sont en jeu. Ça dure 6 semaines et c’est visible à partir de demain sur la page d’accueil de la chaîne Voyages d’Orange, puis la semaine prochaine chez d’autres partenaires très connus.

Vous avez déniché un objet en France ou au bout du monde, ou vous êtes artisan-créateur ? Proposez un objet insolite, authentique ou éthique.
Vous êtes simplement curieux ? Votez pour les objets proposés !

Cette semaine il est seulement possible de déposer des fiches d’objets. Dès la semaine prochaine il sera possible de voter dans la sélection préparée avec les fiches déjà déposées.

À chaque vote ou dépôt de découverte on peut tomber sur un “instant gagnant”.
Si sa  fiche a remporté le vote des internautes, on gagne, de même qu’à la fin du jeu, un grand jury décide des grands prix et des coups de cœur. Bref, y’a plein d’occasions de gagner. Le détail des lots est ici : http://jeu.neomarco.com/partenaires Dommage que je puisse pas jouer

Bon jeu !

Mongrel_cluster vs. Passenger Phusion : Round 1

Voici un premier post focalisé sur mes tests liés à l’hébergement d’applications Rails.

Depuis quelques temps, je fais tourner mes applis de cette manière :

• un cluster de process Mongrel (5-10 en général)
• un virtual host Nginx qui fait proxy et load-balancer

Le principe est assez rigide ; on définit un pool de process Mongrel qui instancient chacun la totalité de l’application (et du framework) et qui ouvrent un port pour répondre aux requêtes. Le proxy/load-balancer redirige les requêtes du port 80 vers ces autres ports de manière transparente, récupère le résultat et le renvoie au navigateur à l’origine de la requête.

Cette allocation de process se fait de manière statique, au lancement du cluster. Il faut donc bien calibrer le nombre de process lancés car ça n’évolue pas selon la charge. Qu’il y ait 1 ou 1000 requêtes simultanées, le nombre de process ne change pas. Dans le premier cas, c’est de la RAM qui est utilisée pour rien, dans l’autre ce sont des requêtes qui font la queue.

Grace à un gabarit (très simple) de configuration du cluster, à quelques scripts de lancement et un chien de garde qui surveille tout ça (Monit est parfait pour ce job), tout roule assez vite et vraiment bien.

Cependant, c’est un sacré pas en arrière par rapport à l’hébergement d’applis PHP. Il suffisait de placer son code source dans un dossier accessible via un VirtualHost et basta !

Au printemps 2008, la communauté Rails a déclaré (RubyInside et LoudThinking) que l’absence d’un vrai mod_ruby (ou rails) pénalisait fortement l’adoption de l’outil. Je l’ai constaté par moi-même a chaque présentation, les remarques fusent sur la complexité de l’hébergement.

Alors quelques farfelus se sont lancés dans le développement d’un module pour Apache qui permettrait de déléguer à Apache la gestion des process (leur lancement/extinction selon les besoins, le nombre max de process par appli ruby, …) et de se contenter d’un VirtualHost qui pointe vers le dossier principal d’une appli ruby.
Ce module a rapidement été surnommé “mod_rails” car il a assez vite permi de faire tourner des applis Rails, mais pas Merb, et autres framework à base de Ruby.
Son vrai nom est Passenger Phusion.
Depuis peu, il a atteint l’état “stable”, il permet de faire tourner d’autres framework, … et il gagne du coup une sacré popularité, à tel point que moi qui suis plutôt conservateur quand les choses marchent vraiment bien, je me suis laissé aller à faire un premier test de config, mais surtout à un comparatif de performance pour charger la page d’accueil d’une même appli Rails dans les 2 modes d’hébergement.

Situation commune

La machine est quasiment au repos ; MySQL tourne mais aucune autre appli Rails que celle de test n’est en service, pas de process lourd (copie, backup, transfert, …) au moment des tests.

Premier test : Nginx + Mongrel_cluster

J’ai mis en place un cluster de 30 process Mongrel et un VirtualHost dans Nginx pour le proxy/load-balancer. C’est ma config de prod courante (sauf que j’ai moins de process en général).

Un stress test avec ApacheBench : $ ab -n 1000 -c 50 http://serveur.dev/accueil

Au résultat il a fallu 94 secondes pour répondre aux 1000 requêtes, avec une moyenne de 10,58 req/sec

Aucun autre process gourmand et inutile ne tournait sur la machine (Apache était arrêté).

Second test : Apache + Passenger

J’ai configuré un Virtualost dans Apache2 avec un nombre maxi de process à 30

Un stress test avec ApacheBench : $ ab -n 1000 -c 50 http://serveur.dev/:81/accueil

Au résultat il a fallu 88 secondes pour répondre aux 1000 requêtes, avec une moyenne de 11,25 req/sec

Nginx était stoppé.

Conclusion

De la simplicité de mes tests et de leur rigueur très relative, je tire tout de même une première conclusion : ça va pas moins vite !

Ce qui veut dire que c’est a priori une solution aui est envisageable, moyenant des tests plus poussés.

Le grand bénéfice de tout ça serait certainement d’alléger mon environnement de dev. Ne plus avoir à paramétrer un cluster, un VHost, Monit, … pour une nouvelle instance de travail, ça sera un vrai progrès par le gain de temps.

Ensuite, pourquoi pas le mettre en environnement de production. La quantité de RAM dispo est assez importante, il suffit alors de permettre un grand nombre de process dynamiques pour que Apache s’adapte à la demande de manière plus souple.

Ça ne me fera pas changer d’avis quand à la qualité de Nginx en tant que serveur web ultra léger, particulièrement adapté pour les fichiers statiqueset très facile à configurer.

Le Vieux Port a 9h

WordPress natif pour iphone

Et voilà, l’application native iPhone de WordPress est diapo. Ce post est d’ailleurs écrit avec.

Le Comptoir de La Bo[a]te, 3ème rendez-vous

Déjà une habitude !

Comme chaque deuxième jeudi du mois “Le Comptoir de la Bo[a]te” réunit pour la troisième fois celles et ceux qui font l’innovation dans le web, les technologies et les réseaux.

Mais qui vient là ?

On s’y retrouve entre amis, collègues, partenaires, concurrents, entrepreneurs, investisseurs, chercheurs, etc … pour échanger sans formalisme et partager projets, idées, nouveautés.

On y rencontre régulièrement ou occasionnellement les habitués de Medinsoft, de Libertis, du Plug, d’Aix-Marseille Wireless, du Club de l’Arche Méditerranée, du Pôle média de la Belle de Mai, de collectifs créatifs, d’agences web, de communicants connectés, d’entrepreneurs et de dirigeants commerciaux, et bien d’autres.

Y’a un programme ?

Non, c’est vous le programme, mais ce mois-ci nous savons déjà que l’équipe de Buzz2biz présentera cette plate-forme de rencontres professionnelles.

Qui a dit qu’il n’y a du web 2.0 et des réseaux sociaux qu’à Paris, San Francisco ou Montréal ? Du bon buzz en perspective !

Ce sera aussi l’occasion de rencontrer Aurore Russo, de LudoTic, qui sait enregistrer et analyser tous nos mouvements du regard et des doigts face à un écran, et en tirer les points forts et les points faibles de l’interface. Epreuve vérité pour qui voudra tester le site ou le logiciel qu’il a vendu ou acheté, parfois assez cher.

Et on parlera aussi avec Aix-Marseille Wireless qui tisse sa toile de hotspots wifi.

Une présentation à faire ?

Bien sûr, si vous avez une initiative à présenter à cette communauté des innovateurs, dites-le nous, nous l’annoncerons à l’avance, ou misez sur la chance.

La Bo[a]te est équipée de vidéo-projection, d’ordinateurs, de hifi, de Wifi et de prises ethernet, pour montrer maquettes, prototypes, slides, bandes son, vidéos …

Le verre sur le comptoir

Et sur le grand comptoir on déguste les vins et les saveurs que Le Marmiton d’Itav nous aura dénichés et préparées.

Ce mois-ci Caroline et son complice La Compagnie des Vignes ont choisi de nous faire déguster la cuvée Vénus, en rouge, rosée et blanc, du Domaine Pinchinat à Pourrieres ; c’est un vin de Pays du Var issu de raisins de l’agriculture biologique, produit par Alain de Welle, vigneron récoltant indépendant.

Y’a des conditions ?

Le Comptoir de la Bo[a]te est une initiative privée qui ne reçoit aucune subvention ; chacun verse 5 € (en espèces) pour sa participation aux frais, ce qui est très peu eu égard aux bonnes idées, aux bons goûts et au bon accueil qu’on y trouve.

Il n’est pas obligatoire de s’inscrire, mais c’est une bonne idée de se signaler avant (pour la logistique) par un simple petit mail au Comptoir de la Bo[a]te : lecomptoir@laboate.com

A noter

le Comptoir suivant aura lieu le 13 Septembre, mais une réunion ouverte est proposée en juillet pour préparer la rentrée ; contactez-nous par e-mail si vous êtes intéressé(e).

Pour s’abonner à la newsletter de La Bo[a]te, envoyez un mail à annonces-subscribe@laboate.com.

Il y a également un flux RSS ici : http://laboate.com/annonces.rss