Boldr

Jour 4 : The Russian Doll Pattern, Mountable Apps In Rails 3

Thu, 07 May 2009 00:00:00 PDT

Jour 4 : The Russian Doll Pattern, Mountable Apps In Rails 3

Voici mes notes pour cette présentation :

Fatigué de faire des pages de login ? (oui un peu).
Un calendrier est juste un calendrier. Faut arrêter de se répéter.
Plusieurs applications, un groupe.
Mon app : Login, Facturation, CMS
Quel est le coeur de mon business (qu’est-ce qui est commun, qu’est-ce qui ne l’est pas) ?
Les engines c’est productif mais pas très flexible, Rails est moins productif mais plus flexible… Aucune solution n’est très productive et très flexible.
Django a déjà du multi app et c’est assez évolué.
La syntaxe qui permet d’avoir une application montable est montrée (ce n’est pas encore fait dans le core de Rails, mais ils sont en très de finaliser la forme de l’API). C’est juste un module, rien d’autre.
La génération d’URL cross-application. Là encore un exemple de code qui semble alléchant mais rien n’est codé pour (d’où la licorne juste avant). C’est plutôt simple, pas grand chose à ajouter pour la génération d’URL dans une autre application, c’est plutôt cool !
Pour une startup Web 2.0 générique, un petit exemple de multi-app. On sélectionne le layout qui sera utilisé, ensuite on définit les applications utilisées et l’imbrication des différentes applications entre elles.
On peut aussi faire des overrides de morceaux d’une application.
Pour customiser les templates, il faut plus de helpers (c’est là que erector peut être super utile). Tout ce qui est dit ici peut très bien s’appliquer dans vos applications actuelles.
Utiliser les parts (existe déjà avec Merb, en Rails il y a le plugin Cells mais qui doit être cassé dans Rails Edge).
Les migrations (même question que la présentation sur les engines de Mardi). Réponse : Ne faites pas de down ^^
Coopération cross-framework (et là Django est à la rue).
Maintenant qu’on va avoir des applications montables, il faut un système d’administration.
Et puis aussi créer un écosystème autour de ça, avec un dépôt de sources.
Mais tout ça n’est pas pour tout le monde. On peut ne pas avoir le contrôle de tout et ça peut être contrariant.

Maintenant je vais avoir du mal à attendre que ce soit intégré à Rails, j’attends cette fonctionnalité depuis bien longtemps et de voir à quel point ça va être génial ne me fait que plus saliver.

Jour 3 : Keynote Chris Wanstrath (GitHub)

Wed, 06 May 2009 00:00:00 PDT

Jour 3 : Keynote Chris Wanstrath (GitHub)

Mes notes sur la keynote de Chris Wanstrath aka Defunkt (GitHub) :

Chris parle de comment faire un blog qui va devenir populaire (très marrant).
Pour devenir populaire, il faut aussi un Twitter qui claque.
On crée des plugins ou des gems en un soir, on publie et on attend la gloire.
Et là c’est bon on arrive à devenir un people et à parler à RailsConf.
Mais être populaire ce n’est pas être bon.
Quelques conseils pour coder comme on aime.
Trainer à la RailsConf c’est cool pour rencontrer toutes les stars, les grosses sociétés et essayer de trouver un job ou créer sa boite.
Quelques sarcasmes (bon argumentaire cependant) sur Sourceforge :)
Arrêtons toutes les critiques, et investir plus de temps à coder.

En résumé faut arrêter de se la jouer, et commencer à coder et à aider la communauté à évoluer.

Utiliser un autre ORM

Wed, 06 May 2009 00:00:00 PDT

Utiliser un autre ORM

CouchDB m’attire beaucoup et encore plus avec la magnifique librairie qu’est CouchRest. Mais forcément si on n’utilise pas ActiveRecord, il faut aussi dire au revoir à certains plugins comme authlogic et paperclip. Est-ce que ça en vaut vraiment la peine ?

Comme Matt le disait dans sa présentation de Rails 3, si on ne veut pas des éléments par défaut il faut se poser cette question et bien sûr trouver une réponse. Evaluons donc si ça en vaut la peine.

Déjà il y a plusieurs raisons pour que je veuille utiliser CouchDB : ce n’est pas relationnel, le scaling horizontal est simple, c’est un projet bourré d’espoir, les vues c’est bien et enfin CouchRest est super cool. Et même si je suis loin d’en être sûr je pense que ça me permettrait d’être plus productif qu’avec un SGBDR classique.

Mais est-ce que toutes ces raisons pèsent plus dans la balance que la non compatibilité de ce que j’utilise avec ActiveRecord ?

Commençons par authlogic (ou un autre plugin pour l’authentification), le code est facilement extractable pour tout ce qui est sécurité et tokens, ensuite Warden est un super middleware Rack qui s’occupera de toute le reste.

Pour paperclip, on a rack-thumb que je trouve plutôt bien foutu. Pour le stockage d’informations dans la DB, c’est l’histoire de quelques lignes de code.

Jusque là on va dire qu’on a passé une grosse journée pour convertir les outils actuellement utilisés vers les nouveaux. Ce n’est pas grand chose et ça peut aider la communauté.

Enfin utiliser CouchRest avec Rails c’est se passer de beaucoup de helpers, ce qui n’est pas l’idéal. Bien sûr Rails 3 réglera le problème mais ne devrait pas sortir avant quelques mois. Sinon il est facile d’utiliser Merb 1.1 (bientôt disponible) ou Sinatra. Mais là encore il faudra se passer de certains plugins.

N’ayant pas le problème de me fixer à une version d’un framework ni d’avoir une multitude de plugins, je peux très bien utiliser CouchRest avec Merb 1.1 dans mon cas. Je n’aurais pas beaucoup plus de développement à faire et je pourrais utiliser CouchDB.

Ce que je voulais faire avec cet article c’est vous montrer ce que peut impliquer le choix d’un élément par rapport à un autre et la réflexion qui en découlait. Cette réflexion se fait avec tous les ORM existants actuellement, d’où le titre du billet, et se fera quand viendra Rails 3. Et on peut aussi étendre ça à n’importe quoi.

Ayez donc toujours en tête que le changement d’un seul élément dans votre boite à outils peut entraîner des modifications que vous ne pourrez peut-être pas assumer et si vous n’y réfléchissez vous foncez directement dans le mur.

Jour 3 : Interfaces Are Dumb

Wed, 06 May 2009 00:00:00 PDT

Jour 3 : Interfaces Are Dumb

Voici mes notes sur la présentation sur les interfaces :

Petite analogie entre les interfaces en programmation et l’électricité (les prises et autres).
Rack c’est génial (pas faux). Super interface, très (très) simple.
Phusion peut disparaitre, Rails peut disparaitre, Rack est là pour venir à notre rescousse.
“APIs are awesome”, exemple avec flickr.com, twitter.com (avec les différentes applications, c’est vrai qu’on voit à quel point les APIs sont cool grâce à ces applications).
YQL un langage unifié pour les APIs (mais je ne suis toujours pas convaincu par YQL).
Webhooks, exemple de GitHub (c’est vrai qu’avec on peut faire n’importe quoi), de astrotrain et de Paypal IPN.
PubSubHubBub (trouvez des infos par vous-même).
Faire une carte pour designer l’interface pour que n’importe qui puisse la comprendre.

Une vue d’ensemble des interfaces dans le web plutôt intéressante et marrante.

Jour 3 : Rails 3, Step Off Of The Golden Path

Wed, 06 May 2009 00:00:00 PDT

Jour 3 : Rails 3, Step Off Of The Golden Path

Mes notes sur la présentation de Matt sur Rails 3 :

Petit historique de Ruby et de Rails et on arrive au schisme.
Merb c’est un peu comme Rails avec performance et agnosticisme en plus.
Le problème du schisme c’est que ça a entraîné des tensions. Et c’est là que le merge arrive.
Rails 3 c’est quoi actuellement ? Du vent, c’est un vaporware (l’alpha sortira cette semaine apparemment quand même).
Rails 3 c’est de meilleures performances, une meilleure modularité, une API publique (houra pour les plugins !) et des applications montables.
Avec Rails 3 il y aura plusieurs voies, ce ne sera plus que ERB/Prototype/ActiveRecord/Test::Unit.
Plus de flexibilité, moins obstiné (pas envie de traduire opinionated mieux que ça).
Ne pas utiliser la stack par défaut, c’est avoir moins de documentation, moins de plugins… Est-ce que ça vaut le coup d’avoir une stack customisé ? C’est la question qu’il faudra se poser.
Petite présentation de Datamapper (ça rocks bien sûr).
Quelques bouts de code pour customiser Rails à l’extrême.
Le futur c’est d’utiliser Rails dans des endroits où on aurait jamais pu penser l’utiliser.

Très bonne présentation qui résume bien l’esprit de Rails 3 et surtout ce que ça va apporter dans la pratique. Bref complémentaire de la keynote de DHH.

Jour 2 : Scaling Rails

Tue, 05 May 2009 00:00:00 PDT

Jour 2 : Scaling Rails

Voici mes notes pour cette présentation :

scaling != requests/sec
Plusieurs solutions pour le scaling : Vertical scaling, Horizontal scaling.
Scaler les serveurs d’app c’est trivial, la BDD l’est moins.
Scaling vertical : en plus de la puissance peut être de passer d’Apache à Nginx.
Pour scaler la BDD : Plusieurs serveurs pour la redondance, Master-Slave replication ou multi master replication.
Mais il y a des limites à la réplication.
Sharding (découpage de la BDD). Mais quelques points faibles. DataFabric pour ActiveRecord.
Pour scaler on a aussi les optimisations (de l’application et des requêtes).

Et la présentation se termine par un Wolf3D écrit en Ruby avec Zed Shaw en boss. Hilarious !

Jour 2 : Keynote de DHH

Tue, 05 May 2009 00:00:00 PDT

Jour 2 : Keynote de DHH

Voici mes notes pour la keynote de DHH :

5 ans de Rails, ça commence à être pas mal.
“Pas prêt pour l’entreprise” → ça prend du temps à être accepté.
“Rails n’est pas pertinent si on crée un clone sur un autre langage”, “Java n’est plus chiant avec les scaffold” → Mais ce n’est pas vrai. Rails n’est pas juste scaffold, c’est bourré de détails qui font que c’est unique.
“Je reviens à PHP après 2 ans de Rails” → Il préférait PHP, il n’avait aucun besoin de Rails. Et ce n’est pas la peine de le lapider.
“Twitter à des problèmes à cause de Rails” → Il y a des incidents, la communauté les résolvent. Même chose pour des ajouts dans Rails (comme les second, third… pour un tableau dans ActiveSupport).
“Merb meilleure alternative à Rails en Ruby” → C’était plus les différences de philosophie que le scaffolding ou les trucs hype de Rails.
Après 5 ans, Rails est toujours là.
La philosophie de Rails 3 : Pas un rewrite complet ni résoudre tous les problèmes de tout le monde. Mais ça n’empêche pas de revoir des choses existantes et de se remettre en question (comme alias_method_chain, il y a mieux). “Have it your way” → on peut tous aimer Rails même s’il y a des choses qu’on aime pas dedans (et si on les aime pas on les enlève).
Nouveau routeur (mountable apps, plus rapide, rack…). Pour des exemples, allez voir rack-mount.
XSS protection, h sera le défaut mais on pourra faire l’inverse (avec raw).
Javascript unobstrusive & agnostic, pas de Javascript dans le code avec les helpers, des attributs à la place (plus DRY, mais pas compatible IE6).
Plus d’agnostic (orm, générateurs).
Enfin le gros refactoring (ActionController, ActionDispatch, Action Relation, Cherry picking pour ActiveSupport, callbacks plus rapide).
Le vrai secret pour une haute productivité : “Renegotiate requirements”. Le programmeur n’est pas juste un petit chiot mignon qui obéit (exemple avec un système de permissions, ça part d’un truc super customisable et tout et au final c’est tellement dur que le résultat est nul, il faut renégocier les exigeances pour avoir un système de permissions qui n’est pas ce qui était prévu mais qui est totalement satisfaisant). DHH parle ici de son expérience des permissions avec Highrise.
On n’est pas des programmeurs, on est des partenaires.

Jour 2 : Bilan

Tue, 05 May 2009 00:00:00 PDT

Jour 2 : Bilan

Bonne journée dans l’ensemble. Même si les différentes présentations ne m’ont pas appris grand chose, elles ont permis de me mettre les idées au clair et c’est au final ce que je cherchais. Et en plus de ces présentations, j’ai pu parlé avec Matt Aimonetti de CouchDB, de MacRuby et de Rails 3, avec Carl Lerche de rack-router et poser quelques questions à plein d’autres personnes, encore une fois tout ça pour avoir les idées claires sur les choses que je cherche à utiliser actuellement.

Vu la connexion merdique que j’ai à l’hôtel, je vais arrêter mon bilan ici, j’en aurais de toute façon un à la fin de la RailsConf qui résumera tout ce que j’ai vu.

Vous pouvez récupérer les présentations sur le site de la railsconf (page mise à jour régulièrement).

Jour 2 : UI Fundamentals for Programmers

Tue, 05 May 2009 00:00:00 PDT

Jour 2 : UI Fundamentals for Programmers

Mes notes sur cette présentation :

l’UI n’est pas indépendante du software.
Pour le client, l’UI est toute l’application (justement j’en parlais il y a quelques jours avec des amis).
Il vaut mieux donc commencer par l’interface avant l’implémentation.
Avoir un modèle en tête permet de faire une UI qui sera plus adaptée et plus ergonomique.
Livre “Domain-Driven Design” : “Model-driven design” et “Ubiquitous language”.
Penser avec REST permet de diviser les écrans très simplement.
Avoir un design efficace, centrer l’attention sur ce qui est important. Un petit rien peut changer la donne.
Le contraste permet d’attirer l’attention.
Ce n’est pas parce qu’il y a des codes connus qu’il faut les utiliser. Certaines fois il sera plus adapté de ne pas reprendre certains codes.
Toute action a un début, un milieu et une fin. Il faut penser à tout le processus pour créer l’UI.
Pas de HTML dans les helpers.
Ne pas tout extraire dans tous les sens, ne pas être trop intelligent. Il ne faut pas y aller trop vite sur ce genre de choses.
Des CSS et des JS pour chaque action de chaque contrôleur.
Garder les vues claires.

Pour le coup des CSS et des JS pour chaque action, je suis assez sceptique. Si c’est bien pensé, ça peut être bien mais il faut penser à la production et écrire les choses en y pensant. Plein de bons conseils pour les développeurs devant faire de l’UI, mais aussi pour des designers.

Jour 2 : The Even-Darker Art of Rails Engines

Tue, 05 May 2009 00:00:00 PDT

Jour 2 : The Even-Darker Art of Rails Engines

Mes notes sur la présentation des Engines de Rails :

appable_plugins, le premier qui a existé.
Ensuite il y a eu desert de pivotal labs (qui est en fait un fork de appable_plugins).
Merb slices qui est “rails engines that doesn’t suck”.
Une engine à un répertoire app/ (avec des contrôleurs, des helpers, des modèles, des vues et des metals).
helper :all n’inclura pas les helpers inclus dans les plugins (ticket #1905)
Une engine à des routes dans config/routes.rb. C’est exactement la même chose que le routeur dans l’application principale.
Mais il manque des choses dans les engines de Rails 2.3 : fichiers publiques (css, js…) mais il suffit de quelques lignes pour les copier dans public/ (attention aux conflits), migrations (normal si on a des modèles).
Mais des migrations dans les plugins posent énormément de problèmes (ticket #2058, interblah.net/plugin-migrations).
Les contrôleurs on a le choix pour écraser des fonctionnalités : modules, écraser la classe, namespaces (puis héritage)
Problèmes avec le cache, mais simplement modifiable. config.reload_plugins = true
config.to_prepare { ... }
Tester les engines c’est compliqué, il faut avoir un environnement Rails dans le plugin pour pouvoir les écrire.
Eviter l’échec, l’utilisation d’une engine est simple par l’auteur, possible par un développeur mais plus compliqué.
Il y a des choses qu’on ne pourra pas mettre dans des engines.
Il y a des engines qu’on ne pourra pas utiliser (même si l’engine est bien faite, elle ne sera pas en adéquation avec le projet).
Extraire des fonctionnalités spécifique.
On est le premier client pour le code (et donc les engines) qu’on écrit. C’est donc nous qui décidons quoi extraire et quoi ne pas extraire.
Lire le code d’une engine est très important pour l’utiliser.

Bon je voulais aller à cette présentation voir si mes idées étaient claires sur les limites des engines, et malheureusement ça a confirmé ce que je pensais. Il y a des limites, elles sont surmontables, mais pour certains points c’est un peu lourd.

I'm back!

Mon, 04 May 2009 00:00:00 PDT

I’m back!

Un titre à double sens. Pour ceux qui l’ont remarqué, Boldr a été down une bonne semaine dû à un gros problème de serveur. Et comme j’étais en vacances, je n’ai rien fait pour remettre Boldr sur pied. La 2eme chose c’est que je n’ai pas bloggué depuis plusieurs mois dû à un emploi du temps plutôt chargé, parce que Twitter c’est bien pour blogguer aussi (Vous pouvez me suivre @nicolasmerouze) et parce que j’en ai marre d’utiliser Mephisto (ou Typo ou Wordpress).

Alors le serveur qui tombe m’a poussé à passer à autre chose et je me suis dit que j’allais me passer de serveur et mettre Boldr sur Github (avec Jekyll). Pour l’instant c’est raw, aucun design, rien. La raison est simple, je suis à Las Vegas et mon logo et mon design sont chez moi :(

Las Vegas = RailsConf, je vais donc essayer de blogguer ici et sur Twitter au maximum cette semaine sur la RailsConf. So stay tuned!

PS : L’URL est pour l’instant boldr.fr (une fois les DNS actualisés) mais elle pourrait repasser à blog.boldr.fr, ça dépend de comment je récupère mes billets.

Edit : J’ai retrouvé mon logo sur Google (en mauvaise qualité), j’en ai donc profité pour faire un design rapide.