Présentation réalisée pour la 3eme édition du Startup Weekend Marseille

Après de nombreuses participations à des Startup Weekend, je me suis aperçu que les gens testaient peu leurs idées avant de se lancer dans le développement du service complet.

Voici 10 moyens d’affiner et tester votre idée avec le moins d’effort possible. Ils vous permettrons de mieux répondre aux besoins de vos clients et d’aller plus vite vers la bonne idée.

Itération

Pour tester son idée en un minimum de temps, il est toujours important de réfléchir à comment obtenir le maximum de retours avec le moins d’effort possible. Développer son service est rarement la meilleure solution…

La conception doit se faire de manière itérative. Partez à la découverte de vos utilisateurs potentiels, récupérez un maximum de retours et modifier votre business model/service en fonction.

Expert

Afin de comprendre le marché, les besoins… demander à un expert est souvent une bonne solution. Cela vous permettra de rapidement avoir les informations de base dont vous avez besoin.

N’hésitez pas à essayer de contacter des gens qui vous paraissent inatteignables. Dans des Startup Weekend, il m’est souvent arrivé d’avoir des CEO de sociétés connues au téléphone ! Ils sont souvent aussi passionnés que vous et se font un plaisir de vous expliquer ce dont vous avez besoin.

Interviews

Au départ, votre idée est floue et repose sur de nombreuses hypothèses pas toujours fiables. Pour mieux comprendre le besoin de vos clients, le plus simple est souvent de leur demander.

Pas besoin d’interroger beaucoup de monde. Essayez de poser un minimum de questions afin de ne pas trop influencer. Laissez la discussion dériver. Il est possible que vous n’ayez pas identifié le besoin et que cela n’intéresse pas du tout la personne interrogée.

Repérez bien les phrases du style : « Je ne suis pas sûr d’utiliser ton service, en revanche, si ton service fait [une idée], je suis prêt à payer pour ça ! »

Sortez !

Vous faites un service pour boulangers ? Sortez et allez interroger le premier boulanger du coin.

Qui mieux qu’un boulanger pourrait vous répondre ?

Article

Afin de vérifier, si la problématique que souhaitez traiter intéresse, vous pouvez communiquer dessus et voir si les gens lisent et diffusent ce que vous écrivez.

Avant de vous lancer dans de la formation en création d’entreprise, pourquoi ne pas vérifier qu’il y a un marché en publiant un article donnant les bases…

Questionnaire

Quand votre idée se précise, un questionnaire peut être très utile. Il vous permettra d’avoir des informations quantitatives cette fois. Google Docs vous permet d’en créer un en quelques minutes.

Pensez à publier le questionnaire à votre cible !

Votre service concerne le tourisme ? Postez votre questionnaire sur des forums, blogs, chats… qui concernent ce domaine.

Pensez à demander s’ils se sentent concernés, combien ils pourraient payer, de quelles fonctions ils ont besoin, ont-il d’autres problèmes…

Landing page

Une fois que vous avez mieux identifié le problème que vous voulez résoudre, il est bon de tester votre solution. Créez un site d’une page contenant le nom de votre projet, la description en une phrase de votre service et un call to action (champ pour laisser son email, bouton «plus d’infos»…)

Vous pouvez vous lancer dans l’achat d’un nom de domaine et la création d’une page web (des services comme LaunchRock peuvent grandement vous simplifier la vie).

Pensez pas à tester différents messages et regarder l’influence sur le taux de conversion !

Prototype

Une fois que votre business model et votre idée se précisent, il devient pertinent de développer un prototype. Regardez si les gens s’inscrivent, s’ils l’utilisent et si oui, quelles fonctions.

N’hésitez pas à changer le wording, ajoutez/modifiez/supprimez des fonctions pour voir si leur comportement change.

MVP (Minimal Valuable Product)

Ne développez pas une usine à gaz ! Construisez le plus petit produit qui vous permettra d’avoir des retours utilisateurs.

Si vous êtes tenté de construire une usine à gaz, si vous n’arrivez pas à résumer votre service à quelques fonctionnalités, c’est que votre vision n’est pas encore assez claire. Repartez à la découverte de vos clients potentiels.

Monétisation

Enfin, le grand luxe pour un Startup Weekend, essayez de gagner de l’argent. C’est la meilleure preuve.

Si les gens payent pour votre service, vous êtes sur la bonne voix. Il ne vous reste plus qu’à les garder.

Pour approfondir, voici quelques livres orientés Lean Startup que je vous invite à lire.

Ruby (on Rails) est un petit marché en France. Je croise régulièrement des développeurs qui hésitent à se lancer dans ce marché ou encore qui ont une vision totalement faussée au sujet de cette techno et de sa communauté. Je croise également des porteurs de projets qui eux aussi ont du mal à se faire un avis sur Ruby même s’ils en entendent régulièrement beaucoup de bien en général.

La communauté Ruby bouge de plus en plus en France, mais les événements organisés sont pour la plupart destinés aux développeurs Ruby eux-mêmes. Je pense qu’il serait bon de se tourner un peu plus vers les gens qui ne font pas encore de Ruby. Les apéros Ruby se prêtent très bien à ça.

J’avais commencé à organiser celui de Sophia Antipolis (repris par Emmanuel Bastien), puis j’ai organisé celui de Montpellier en août dernier juste après mon déménagement. J’aimerais vous faire part de mon expérience pour vous montrer qu’il est utile et simple d’organiser un apéro Ruby.

Pourquoi organiser un apéro Ruby ?

• Les développeurs Ruby se rencontrent, échangent, travaillent entre eux.
• Les autres développeurs peuvent discuter librement avec des rubyistes pour découvrir la techno.
• Les porteurs de projets, CTO, DRH… peuvent rencontrer des développeurs Ruby pour échanger à propos de leurs choix techno et aussi pour embaucher.
• L’apéro Ruby permet de faire savoir qu’il y a des rubyistes dans votre ville.
• Ca coûte très peu de temps à l’organisateur. (1h par apéro et qlq heures pour lancer la machine au début)
• Il s’agit d’un moment convivial et de détente qui permet souvent de passer une bonne soirée !

Comment organiser un apéro Ruby ?

A faire avant

• Prendre contact avec l’association Ruby France pour qu’elle vous aide et vous annonce sur son site (contact AT rubyfr DOT org).
• Essayer de prendre contact avec un maximum de développeurs de votre région. Tous les moyens sont bons (votre propre réseau, Google, LinkedIn, Twitter, Facebook, mailling lists…).
• Penser à insister sur le fait que les apéros sont ouverts à tous (débutants, experts, non-développeurs…). J’ai proposé à des porteurs de projet et des développeurs PHP de venir à l’apéro Ruby de Montpellier, ils ont été très bien accueillis et ont passé une bonne soirée avec nous :)
• Créer une page Facebook.
• Créer un compte Twitter.
• Bloquer une date et une fréquence (ex: l’apéro Ruby Montpellier et Sophia ont lieu tous les 1er mardis du mois).
• Choisir un bar (critères de choix : calme, écran ou rétro à disposition, accessible, prix des consommations, heure de fermeture, possibilité de manger sur place…).

A faire avant chaque apéro

• Préparer quelques feuilles avec le logo Ruby (ou votre propre logo) que vous poserez sur les tables.
• Annoncer l’événement sur quelques médias bien choisis (Twitter, Facebook, mailling list Ruby et Rails France…). Il n’est pas utile de communiquer sur un grand nombre de médias car cela vous prendra beaucoup de temps sans être très efficace pour autant.
• Trouver des personnes pour présenter 1-2 lightening talks (10-15min chacun) sur des sujets de leur choix. Cela vous permettra d’avoir des contenus à publier sur le net et vous faire connaître.
• Prenez des photos de temps en temps. Les gens qui visiteront votre page Facebook ou votre site auront une meilleure idée de la manière dont se déroulent les apéros Ruby.
• Prévenir le bar de votre venue afin d’éviter les surprises.

A faire pendant

• Aller discuter avec les nouveaux, discuter de leurs attentes et leur présenter quelques personnes qui pourront leur être utiles et les inviter à se présenter.
• Trouver qui vont faire les lightenings talks du prochain apéro.

Après chaque apéro

• Publier les lightenings talks.
• Publier les photos.

Comment faciliter la création d’apéro Ruby en France

L’apéro Ruby est un formidable outil pour faire connaître Ruby. Voilà quelques idées qui permettraient, selon moi, de faciliter la création de ce type d’événement en France :

• Mise en place d’un site multi-site facile à administrer avec un joli template de base attribué à chaque apéro lors de sa création. Le site serait configuré avec tout ce qu’il faut par défaut. Libre à chaque organisateur de le configurer différemment voire ne pas l’utiliser. Un WordPress ferait très bien l’affaire (oui c’est du PHP, et alors? Ca marche bien non? :)). Chaque site pourrait avoir une URL du type <ville>.aperoruby.org.
• Création d’un mini guide pour aider les organisateurs à monter des apéros dans leur ville, délivré en même temps que le blog. Ce guide peut avoir pour base le paragraphe ci-dessus et être maintenu et amélioré collaborativement.
• Créer des synergies entre apéros : échange de liens, organisation d’événements, entraide pour la communication…
• Création d’un forum de discussion (Google Group) pour que les organisateurs puissent échanger. EDIT : Le groupe existe à présent : https://groups.google.com/group/aperos-ruby

A la sortie de Polytech’Nice (école d’ingénieur en informatique), ma formation m’avait amené à penser qu’une fois un bon site était mis en ligne, les visiteurs (et l’argent) viendraient tout seuls. Quelques expérimentations où le nombre de visiteurs flirtait avec le zero absolu m’ont permis de voir qu’il manquait quelque chose.

C’est derniers mois, j’ai participé à de nombreux événements (notamment des Startup Weekend) et j’ai entendu parler pour la première fois de Lean Startup (méthode pragmatique pour rapidement développer un prototype et le faire tester par ses clients potentiels), de Customer Development (méthode de développement d’un produit en interaction avec ses clients potentiels), de Business Model Canvas (outils pour rédiger un business model et y réfléchir dessus)… J’ai été très agréablement surpris par ces techniques aussi pragmatiques que celles que j’utilise pour le développement (méthodes Agile, par exemple : Scrum).

Depuis quelque mois, des livres de business ont remplacé mes livres de dev sur ma table de nuit, de nombreux blogs business se sont immiscés dans ma veille quotidienne. Je souhaite aujourd’hui partager avec vous 3 livres essentiels pour s’initier à ces techniques passionnantes.

Ce choix de livres n’est pas très original, vous les retrouverez cités dans de nombreuses de présentations sur le Lean Startup, mais ils sont vraiment parfaits pour commencer.

Business Model Generation

Ce livre vous apprendra tout d’abord ce qu’est qu’un business model et comment le représenter (à l’aide des Business Model Canvas). Vous verrez aussi les grands types de business models ainsi que des techniques pour tester et améliorer le vôtre.

La réalisation de ce livre est remarquable. Un must have !

The Entrepreneur’s Guide to Customer Development

Ce petit livre est en fait un résumé d’une des grandes références du Lean Startup : The Four Steps to the Epiphany. Il vous enseignera un nouveau modèle de développement basé sur des itérations avec vos (potentiels/futurs) clients. Cette méthode très pragmatique permet de sortir un produit répondant au mieux aux besoins de vos clients.

Court et facile à lire, un must have aussi !

Running Lean

Enfin, si vous ne deviez en lire qu’un seul, je vous conseillerais de lire Running Lean. Vous y trouverez une compilation des meilleures pratiques en matière de Lean Startup et Customer Development. Ce livre vous donnera d’excellentes méthodes pour faire un produit répondant au mieux au besoin de vos clients, le tout, en étant le plus efficace possible.

Vous l’aurez compris, c’est un must have de chez must have !

Le Lean Startup est un sujet qui me passionne en ce moment. Je vous proposerez d’autres articles sur le sujet prochainement.

A suivre …

Après Paris, Genève, Nice (en tant qu’orga), Montpellier, Toulouse, j’ai participé au Startup Weekend de Bordeaux ce weekend !

J’ai beaucoup appris durant ce Startup Weekend et je souhaitais partager avec vous quelques retours d’expérience.

Le pitch : le projet surprise

Pour ma 6eme participation à un Startup Weekend, j’ai choisi d’innover un peu. Le vendredi soir, ceux qui le souhaitent pitchent une idée. Je suis allé pitcher… mais je n’ai pas donné d’idée ! J’ai dit que, pour moi, la chose la plus importante dans une startup est l’équipe, pas l’idée. J’ai proposé qu’on trouve l’idée ensemble, une fois que l’équipe serait formée.

Au moment où j’ai pitché, j’avais conscience du côté fun du projet, mais je pensais que peu de gens me rejoindrait par peur de passer le week-end sur une idée qui ne leur plairait peut-être pas. J’avais tout faux ! Cela a été le 2eme pitch à recevoir le plus de billets et nous étions la plus grosse équipe du week-end !

Mais pourquoi l’idée a-t-elle autant séduit ?

L’équipe au coeur du projet

Afin de mieux comprendre, le succés du pitch, j’ai demandé aux membres de l’équipe pourquoi ils avaient voté et pourquoi ils étaient venus. A chaque fois les mêmes arguments revenaient :

• Le pitch étant fun, ils ont imaginé que le projet le serait aussi et qu’ils s’éclateraient tout le week-end.
• On a trouvé l’idée ensemble. Elle appartenait à chacun. Les membres de l’équipe se sont donc sentis plus investis.
• Beaucoup partageaient ma vision sur l’importance de l’équipe et pensaient qu’en venant dans ce projet, ils auraient plus de liberté, d’autonomie et de reconnaissance que dans un projet classique.

Grâce à ça, l’équipe a fait preuve d’une motivation remarquable tout le weekend !

L’expérience a été passionnante et j’ai passé un excellent weekend aux cotés de cette fabuleuse équipe (en photo ci-dessous).

Profiter du réseau

Autre point intéressant du week-end, dimanche matin, nous cherchons des chiffres sur le net. Nous souhaitons savoir combien les bars et les restaurants paient pour être mis en avant sur des sites comme les Pages Jaunes, Dismoiou, Cityvox… Pas d’info sur Google, personne ne sait dans l’équipe, personne ne connait des gens dans ces différentes sociétés.

J’ai alors proposé de faire jouer le réseau. Je poste un tweet en disant que je cherche une personne travaillant dans une de ces entreprises. Le tweet est retweeté par plusieurs participants. 10 minutes plus tard, nous avons Gilles Barbier, CEO de Dismoiou, sur Skype. Plusieurs personnes de Cityvox et Pages Jaunes, nous ont proposé de l’aide dans la journée.

C’est pas la première fois qu’on essaye d’appeller des gens qui paraissent difficilement contactables, surtout un week-end. Pourtant, à chaque fois, nous sommes avons eu des gens passionnés et qui nous ont aidés très volontiers.

OhMyGuest

Comme nous n’avions pas d’idée, nous avons dû en trouver une. Nous avons refait un genre de Startup Weekend en interne. Nous sommes finalement partis sur OhMyGuest, une application pour rencontrer des gens qu’on ne connait pas en leur offrant un verre dans un bar ou un restaurant.

Dès qu’on va sur l’application (web ou mobile), on tombe directement sur la liste des invitations proposées aux alentours. Si aucune ne convient, il est évidement possible d’en créer une. Lors de la création, on doit choisir un type de boisson qui représente le type de rencontre que l’on souhaite faire (café = business, champagne = chic …) ainsi qu’une date et un lieu.

Voici les slides de la présentation:

Vous pouvez suivre l’évolution du projet sur :

Twitter : @ohmyguest
Facebook : Page OhMyGuest
Site web : http://ohmyguest.com

Et vous qu’avez-vous appris durant le weekend?

Préparez votre environnement de travail

Réfléchissez aux techno que vous allez utiliser (surtout si vous êtes porteur de projet). Installez/configurez tout le nécessaire pour ne pas avoir à le faire pendant le weekend.

Faites un tour de table pour connaitre le niveau et les compétences de chacun

Dès le vendredi soir, il est important de bien connaître les compétences de chacun pour faire de bons choix techno et dispatcher au mieux les tâches. Effectivement, cela serait une erreur, par exemple, de sauver les données sur du MongoDB alors que personne ne l’a déjà utilisé et qu’une bonne vieille base Postgres ou MySQL aurait très bien fait l’affaire.

Travaillez de manière agile

Dès le début, dessinez sur un paperboard un tableau à 4 colonnes (backlog, todo, current, done). Dès que quelqu’un a une idée, il écrit son idée sur un post-it (en la décomposant si elle est trop complexe ou trop floue) et le colle dans le backlog. A chaque fois que vous faites un point (toutes les 3-4 heures), choisissez les idées les plus prioritaires (en fonction de leur complexité et de leur valeur business) et mettez dans la colonne todo. Ensuite, dès qu’un développeur commence une tâche, il la déplace dans current. Enfin, vous l’aurez compris, lorsque la tâche est terminée, le post-it va dans done.

48h, c’est très court, prenez bien soin de toujours travailler sur les tâches les plus prioritaires. Veillez également à toujours avoir peu de tâches en cours en même temps.

Pensez toujours à féliciter quelqu’un qui termine une tâche, qui a une bonne idée… C’est principalement ce qui va permettre de maintenir la motivation durant le weekend !

Déployez régulièrement

Afin de ne pas être pris au dépourvu 5 min avant la fin, je vous conseille de déployer régulièrement l’application (toutes les 3-4h). Cela permet aux non-dev de tester l’appli, de remonter des bug, de nouvelles fonctionnalités…

Keep focus on dev

Essayez au maximum de vous concentrer sur le développement. Ne vous occupez pas à faire le design si vous n’avez pas de designer, achetez un design sur ThemeForest, cela fera très bien l’affaire. Ne vous occupez pas de l’admin sys si ce n’est pas nécessaire, déployez votre application en utilisant du PaaS. N’ayez également pas peur de créer de la dette techno (par exemple, en omettant de faire des tests si cela est pertinent), vous pourrez corriger le code la semaine suivante.

Il y a un service pour tout

N’hésitez pas à dépenser quelques euros dans un service qui peut vous faire gagner un temps précieux. Voici quelques services à connaître :

• Hoptoad : collecte les erreurs qui surviennent sur votre application (Rails, iOS, PHP, Java, .net…) et les agrège pour faciliter la consultation
• Pusher : Push temps réel sur une application web grâce à des WebSockets
• Redis To Go : hébergement Redis
• Sendgrid : envoi d’email
• Websolr : recherche full-text reposant sur Solr

Restez efficace et en forme

• Faites des pauses régulièrement
• N’hésitez pas à faire une sieste si la fatigue vous gagne
• Mettez en place du pair-programming au moins pour les tâches complexes

Si vous êtes un développeur Rails

Utilisez RailsWizard

RailsWizard permet de générer le code d’une application Rails avec certaines gems indispensables. Vous pouvez choisir les gems que vous voulez intégrer en fonction de vos habitudes et de vos besoins. Cela vous fera gagner quelques minutes.

Versionnez le code avec Git

C’est devenu un standard pour beaucoup de dev en Rails. Git est également indispensable si vous souhaitez déployer sur des services comme Heroku.

Déployez sur Heroku (si possible)

Heroku vous permet de vous décharger complètement de la partie administration système. Vous faites un push sur le Git de votre projet Heroku, et hop, l’application se déploie. Cerise sur le gâteau, la version de base est gratuite ;)

Vu que Heroku fourni un repository Git pour le déploiement, vous n’aurez même pas besoin de vous créer un git sur Github ou autre pour travailler en équipe. Travaillez par exemple dans une branche dev et pushez sur la branche master à chaque fois que vous voulez déployer.

Si Heroku est trop restrictif pour vous, regardez du côté de solutions comme Engine Yard, Dotcloud…

Il y a une gem pour tout

Evitez à tout prix de réinventer la roue. Si vous développez quelques choses d’assez classique, ayez le réflexe de regarder sur Rubygems s’il n’existe pas une gem qui fait ça très bien. Il y a près de 22 000 gems disponibles vous devriez trouver ce qu’il vous faut assez souvent.

Les conseils des lecteurs

Eclatez-vous et faites-vous plaisir (Frédéric Dupérier)

Pensez « lean » (Yann Klis)

Ce n’est pas la peine de bosser 24h/24. Il vaut mieux prendre le temps de construire un bon plan que de se jeter à corps perdu dans des choses qui ne sont pas forcément utile. Pensez « lean » -> « Eliminate waste »

Si vous avez d’autres conseils, partagez-les en commentaire, je les ajouterai dans l’article

Il y a un mois environ, j’ai eu le plaisir de présenter Ruby on Rails avec Maxime Menant dans le cadre des SophiaConf 2010. Comme nous avions beaucoup de choses à raconter, nous avons décidé de ne pas faire une conférence mais deux, d’une durée d’une heure chacune.

La première, que j’ai présentée, s’adresse principalement aux entrepreneurs, chefs de projet, directeurs techniques… Cette conférence explique pourquoi Ruby on Rails peut-être un très bon choix technologique, pourquoi ce choix peut faire gagner du temps et de l’argent… J’en parlais dans un précédent article : Pourquoi Ruby on Rails est génial? (d’un point de vu non technique)

Aujourd’hui, je souhaite partager avec vous la deuxième conférence, présentée par Maxime. Celle-ci s’adresse principalement aux développeurs. Elle présente Ruby et Ruby on Rails tout en mettant en avant les points forts de ce couple fusionnel.

Pourquoi Ruby et Ruby on Rails sont geniaux ?

• Les slides (pdf)
• La vidéo

Il y a un mois environ, j’ai eu le plaisir de présenter Ruby on Rails avec Maxime Menant dans le cadre des SophiaConf 2010. Comme nous avions beaucoup de choses à raconter, nous avons décidé de ne pas faire une conférence mais deux, d’une durée d’une heure.

La première, que j’ai présentée, s’adresse principalement aux entrepreneurs, chefs de projet, directeurs techniques… Cette conférence explique pourquoi Ruby on Rails peut-être un très bon choix technologique, pourquoi ce choix peut faire gagner du temps et de l’argent…

La deuxième, présentée par Maxime, avait pour but de démontrer la puissance de cette technologie aux développeurs.

Dans ce billet, je vais présenter la première conférence. Je parlerai de la deuxième dans un autre billet que je publierai prochainement.

Ruby on Rails d’un point de vue non technique

• Les slides (pdf)
• La video

Avant de montrer pourquoi Ruby on Rails est un bon framework, il est important de réfléchir à ce qu’est un framework de qualité. Pour ce faire, j’ai interrogé nombre de mes collègues, followers, amis ingénieurs…

Grâce à leurs réponses, j’ai pu composer une liste des principaux critères qui définissent ce qu’est un bon framework, en voici quelques-uns : Productivité, Agile, Hébergement, Déploiement, Performance, Licence, Evolution, Recrutement ,Actif, Confort, Coût, Bonnes pratiques, Communauté, Architecture, Sécurité …

Avant de voir comment Rails répond à ces différents critères, je vous propose une petit piqûre de rappel.

Ruby, le langage

Ruby est un langage de programmation interprété, orienté objet et multi-paradigme. Il est multiplate-forme et open source. Il vu la première fois le jour en 1995 grâce à son créateur Yukihiro Matsumoto (aka « Matz »).

Il existe plusieurs implémentations de machines virtuelles Ruby, chacune ayant ses spécificités :

• MRI : Il s’agit de la machine virtuelle standard.
• JRuby : Cette implémentation de l’interpréteur Ruby repose sur la JVM (la machine virtuelle Java). Elle permet d’utiliser du code Java en Ruby et inversement. Elle est aujourd’hui principalement maintenue par Engine Yard.
• MacRuby :  Cette implémentation est le pendant de JRuby mais avec l’Objective-C. Elle est aujourd’hui maintenue par Apple.
• Rubinius : Il s’agit en quelque sorte de l’avenir de la machine virtuelle Ruby. Toujours en développement, elle devrait apporter d’importantes améliorations en terme de performance et de gestion de la mémoire.

Quelques chiffres intéressants :

• +14 000 gems (bibliothèques packagées et faciles à utiliser)
• +185 000 projets Ruby sur Github
• 10eme position au classement TIOBE (juin 2009)

Ruby on Rails, le framework web

Ruby on Rails, également appelé RoR ou Rails, est un framework web open source écrit en Ruby. Il a été extrait de Basecamp en 2004, un outil de gestion de projets développé par David Heinemeier Hansson (aka « DHH »). Rails est basé sur deux principes fondamentaux :

• DRY (Don’t Repeat Yourself) : Tenter autant que possible de n’avoir des éléments de l’application qu’à un seul endroit. L’architecture MVC et la métaprogrammation en Ruby rendent cela possible.
• Convention over Configuration : Il est inutile de préciser des détails lorsqu’ils respectent des conventions établies. Rails exploite cela en proposant des comportements par défaut pour la plupart de ses fonctionnalités.

Pourquoi Ruby on Rails est génial?

Ce framemork est un outil très puissant. Il a été pensé afin d’être élégant, efficace, scalable, sûr, agile… Voici pour moi quels sont les principaux éléments qui rendent ce framework si différent :

• La structure : Rails impose une certaine structure au projet. De ce fait, lorsque vous commencez un nouveau projet, vous n’avez pas à vous casser la tête pour savoir comment l’organiser. De plus, comme chaque application Rails possède la même structure, lorsque qu’un développeur rejoint le projet il est très rapidement opérationnel car il n’a pas à étudier comment le projet est organisé.
• Les migrations : Rails permet grâce aux migrations de faire évoluer la structure et le contenu de la base de données de manière agile, le tout en restant indépendant du type de base de données (MySQL, Postgres, SQLite, Oracle…).
• Active Record : Il s’agit de la partie de RoR offrant une abstraction sur la base de données. Active Record est un ORM permettant de manipuler les données de la base très simplement car il profite de la puissance de Ruby.
• Scaffold : Rails peut, grâce au scaffolding, générer tout le code nécessaire pour faire un CRUD (Create, Read, Update, Delete) autour d’une entité. Ceci rend Rails très efficace pour le prototypage d’applications.
• Les environnements : Lorsque vous exécutez une application Rails, elle est exécutée dans un environnement spécifique. Par défaut, une application Rails possède 3 environnements : development, test et production. Chaque environnement possède ses propres paramètres de configuration, ses propres logs et permet de lancer des gems supplémentaires (par exemple des bibliothèques de test).
• La sécurité : Rails propose, par défaut, des systèmes de protection aux attaques les plus classiques (ex : CSRF, XSS, …). Il suffit de rester dans les rails et tout ira bien :)
• Javascript : Une biblothèque JS est disponible par défaut dans Rails, Prototype + Scriptaculous. Il est possible simplement d’utiliser JQuery à la place. La force de Rails est de proposer d’implémenter des vues en RJS. Le RJS est du code Ruby qui génère du javascript, il peut être utilisé pour implémenter des vues.
• Cache : Evidement, Rails permet de mettre du cache un peu partout (page, partial, modèle, action…)
• Test : Rails est livré avec tout ce qu’il faut pour rédiger des tests proprement. De plus, à chaque fois que vous créez un contrôleur ou un modèle, Rails vous créera automatiquement le squelette du test associé!

Cette liste est loin d’être exhaustive, mais elle permet déjà d’avoir un bon aperçu de ce qui rend Rails si unique.

Ruby on Rails 3

Ruby on Rails est un framework qui évolue vite. La version 3 de cet innovant framework devrait voir le voir le jour dans les semaines qui arrivent.

Rails 3 est en fait l’union de Merb et Rails 2. Merb est un framework web léger écrit en Ruby. Il privilégie la performance au confort alors que Rails 2 propose plutôt un compromis entre les deux. Rails 3 est modulaire. Vous pouvez ajouter/supprimer des couches d’abstraction en fonction des besoins en performance que vous avez.

Rails 3 arrive avec une pléiade de nouveautés : compatibilité HTML 5, Javascript non-obstrusif, Bundler (nouveau gestionnaire de dépendance des gems), réécriture de la partie modèle…

Une communauté prolifique

Ruby étant un langage de haut niveau, c’est-à-dire qu’il propose une forte abstraction, permet de développer très rapidement. De ce fait, il existe un très grande quantité de bibliothèques open source que l’on peut utiliser librement dans tout projet Ruby.

Dans le monde Rails, il y a des plugins pour tout : authentification, tâches de fond, upload de fichiers, paiement en ligne, NoSQL, indexation, BDD, pagination, geolocalisation, cache, Twitter, parsing, Facebook…

La communauté est également très active pour l’entre-aide. Lorsque vous avez besoin d’aide, de nombreuses sources d’information sont à votre disposition : documentation officielle, forums, les Guides Rails, des screencasts (railscast, learnivore…), des conférences, des livres…

IDE

Souvent lorsqu’on parle de langages interprétés, nombreux sont les développeurs qui pensent que lorsqu’on code avec ce genre de langages il n’est pas possible d’avoir droit à un debugger, à de l’auto-completion, à de l’analyse statique de code, à faire du refactoring…

Je vous rassure tout de suite, cette époque est bel et bien terminé. Tout ceci est disponible avec les IDE Ruby de qualité qui sont aujourd’hui présents sur le marché : Rubymine, Netbeans, Aptana.

Pour ma part je vous conseille Rubymine.

Qui utilise Ruby on Rails?

Ruby on rails est utilisé pour de nombreux sites web à fort trafic. Voici un image présentant les applications web les plus connues faisant confiance à ce framework :

Parmis ceux-ci :

• Scribd (39 700 000 visiteurs uniques/mois)
• Twitter (30 000 000 visiteurs uniques/mois)
• Hulu (24 900 000 visiteurs uniques/mois)
• WhitePages (21 800 000 visiteurs uniques/mois)
• Justin.tv (19 300 000 visiteurs uniques/mois)

Ruby on Rails est également utilisé en interne dans de grandes sociétés/organisation : Amazon, BBC, Capgemini, Cisco, CNet, Electronic Arts, IBM, Siemens, Nasa, Yahoo!, Oracle, The New York Times, Symantec, Pixar, LinkedIn…

Des outils et des hébergeurs uniques

Les développeurs Ruby, en plus d’avoir un langage et un framework web extraordinaires, ont des outils et des hébergeurs eux-aussi uniques!

Comme outils, on peut tout d’abord citer Github qui est un hébergeur Git beaucoup utilisé par les rubyistes. Ensuite, un outil que j’aime tout particulièrement : Newrelic. C’est l’outil idéal pour analyser et puis optimiser les performances de votre application. Les fonctionnalités de Newrelic sont assez vastes, c’est finalement un peu le Google Analytics de la performance des applications Rails. Si Newrelic vous intéresse vous pouvez utiliser le code suivant qui vous permettra de bénéficier gratuitement pendant 30 jours du service en version Gold : Sophia2010

Ensuite, coté hébergement, en plus des hébergeurs classiques, il y a Engine Yard et Heroku.

Engine Yard facilite grandement l’administration des serveurs. Pour résumer, EY sous-loue des machines Amazon EC2 sur lesquelles il installe une stack logicielle bien pensée qui permet l’exécution d’applications Ruby on Rails. Pour déployer une application sur ce service, il suffit d’indiquer l’URL de votre repository Git, de choisir la configuration de la/des machine(s) que vous souhaitez et de valider, Engine Yard s’occupe du reste! Il également possible d’ajouter/supprimer des machines à chaud ou encore de cloner un environnement entier (pour, par exemple, faire des tests de charge). Il est également important de noter que cette entreprise contribue à de nombreux projets open source comme : Ruby on Rails, Rubinius, JRuby…

Enfin, autre hébergeur remarquable, Heroku. Ce service est très différent de ce qui existe aujourd’hui. Il simplifie la tâche de l’administration serveur au maximum. Vous n’avez pas accès aux machines, tout se fait grâce à une interface web toute simple. Vous n’avez qu’à choisir le nombre de dynos (nombre de requêtes en parallèle), le nombre de workers (nombre de processus exécutant les tâches de fond), la taille de la base de données (Postgres) et les services que vous souhaitez intégrer. Pour déploiement, il suffit simplement de pusher votre repository Git chez eux!

Heroku est le service idéal pour lancer vos projets. Dernier point, le service de base est gratuit!

Le monde Ruby bouge!

Avant de terminer, quelques chiffres très intéressants :

• L’utilisation de Ruby a augmenté de 40% en Amérique du nord entre 2008 et 2009 (source : Evans Data)
• Le nombre de développeurs Ruby devrait augmenter de 400% entre 2008 et 2013 (source : Gartner Group)

Conclusion

J’espère que cette conférence vous a convaincu, ou, du moins, intrigué. J’espère également que la prochaine fois que vous ferez un choix technologique, vous penserez à ajouter Rails sur la liste des choix possibles! :)

N’hésitez pas à réagir à ce billet en postant un commentaire si vous avez des questions ou des remarques.

Du mercredi 30 juin au vendredi 9 juillet se tiendront pour la première fois les SophiaConf. Pendant une semaine, se dérouleront, sur Sophia Antipolis, de nombreuses conférences sur différents sujets comme le Web, Java, Scrum…

Les SophiaConf 2010 se clôtureront, le 9 juillet, par une série de 12 conférences. 2 de ces conférences seront dédiées à Ruby on Rails!

La première (9h – 10h), que j’aurai le plaisir de présenter, aura pour but de montrer que Ruby on Rails est une excellente techno (pour ceux qui n’en seraient pas encore convaincu :-p), le tout d’un point de vue non technique. L’idée est de montrer à des chefs d’entreprise, des développeurs, des entrepreneurs… que Rails peut être un très bon choix technologique. J’expliquerai pourquoi des sites très fréquentés, comme Twitter, SlideShare, Getsatisfaction… ont fait le choix de Ruby on Rails.

La seconde (10h15 – 11h15), présentée par Maxime Menant, un collègue, montrera comment Ruby on Rails peut faciliter la vie de nombreux développeurs web.

Je vous invite à regarder le programme pour plus d’information. C’est une journée à ne pas manquer!

Update: Vous pouvez suivre l’actualité des SophiaConf2010 en direct sur SophiaConf2010 in live (application Rails3 déployée sur Heroku)

Enfin, après avoir participé à un atelier sur le personnal branding puis un sur la centralisation de l’identité numérique, j’ai choisi de participer à un autre atelier dont j’avais proposé le thème : « Anonymat et identité numérique ». Cet atelier avait pour but de discuter des traces qu’on laisse tous les jours en surfant et de réfléchir aux effets qu’elles peuvent avoir sur notre identité numérique et surtout sur notre e-réputation. Lors de cette réflexion nous avons cherché des réponses à plusieurs questions comme:

• Pourquoi être anonyme?
• Quelles traces laisse-t-on?
• Comment puis-je supprimer des traces que j’ai laissé?
• Comment tracer/espionner quelqu’un?
• Quels sont les impacts des traces que je laisse sur mon e-réputation?
• Comment puis-je être anonyme?
• …

Voici un résumé de notre réflexion sous forme de mind map:

Voilà, c’était le troisième et dernier atelier auquel j’ai participé. Nous avons ensuite été convié à un buffet très convivial. Cela a été l’occasion de continuer quelques débats non terminés, de faire des contacts et de se détendre après une après-midi de brainstorming intensif ;)

Je ne peux terminer cette série d’articles sans remercier Sandra. Une organisation sans faille du début jusqu’à la fin ! Bravo et merci ! Vivement le prochain…

Après l’atelier sur le Personnal Branding, j’ai participé à un atelier sur la centralisation de l’identité numérique. Cet atelier, que j’ai moi-même proposé, part du constat que nous sommes très souvent amenés à créer ou modifier ces profils sur la toile. Quel enfer de tous les maintenir lorsque l’on change d’adresse, de travail, …

L’idée était de réfléchir aux besoins que nous avons et de voir les solutions qui s’offrent à nous pour nous simplifier la vie. L’atelier a pas mal dérivé sur la sécurité ainsi que sur de nombreuses anecdotes, hors-sujet mais très intéressantes!

Voici le mind map (de la partie non-hors sujet) de l’atelier :