Les pieds dans le code

Après pas mal de temps passé sur Scribbish j’ai repris un petit thème maison. C’est pas forcement aussi bien léché, mais au moins, C’est moi qui l’ai fait :-)

Et ça me permet également de faire mon premier repository public sur GitHub histoire de voir comment ça marche. Retrouvé donc les sources de ce thème sur github.com/yaf/to_the_left .

Maintenant il faut que je vois si c’est assez beau pour être proposé sur le typogarden

Hier, j’ai posé une question à la terre entière (ou presque):

http://identi.ca/notice/3568719

MyModel.paginate(blablabla) or just call MyModel.give_data and call paginate in MyModel ?

J’ai mis en place une pagination sur une liste de commande. Cela à plusieurs avantages.

• Graphique d’abord. On ne peut vraiment pas proposer une interface claire avec une liste de 150 commandes
• Performances ensuite. Aller cherche 150 commandes d’un coup, c’est faire attendre le client qui finalement n’en fera que 10.

Ceci étant dit, sur divers exemple que j’ai observé à droite et à gauche, l’appel au modèle pour récupérer la liste de commandes dans le contrôleur ce fait sous la forme:

  @ma_liste = MonModel.paginate :page => params[:page], :per_page => 10, :condition {mes_conditions}, :order => 'date DESC'

Je ne détail pas les conditions ici, mais pourtant ce sont elles qui me gène dans ce code. L’appel à paginate (ou une autre méthode) dans le contrôleur ne me gène pas, de toute façon, il faut bien qu’il travail un peu, même s’il est maigre ! Mais par contre j’ai beaucoup de mal avec le fait que le contrôleur connaisse les conditions pour la récupération de la liste. D’autant que j’ai dans ces conditions quelque valeur par défaut qui dépende d’un contexte non présent dans les paramètres aujourd’hui.

Je vais donc opter pour le déplacement de l’appel à paginate dans mon modèle. J’ai donc maintenant dans mon contrôleur quelque chose de plus clair, et plus simple (ou plus maigre :)):

  @ma_liste = MonModel.commandes_en_attente params

Et dans mon model

  def commande_en_attente params
    MonModel.paginate :page => params[:page], :per_page => 10, :condition {mes_conditions}, :order => 'date DESC'
  end

C’est bien beau, mais je me retrouve maintenant avec des éléments de présentation dans mon modèle. C’est mal.

Je vais pour l’instant passer la page demandé et la quantité par page en paramètre.

class MonController < ApplicationController
  def index
    @ma_liste = MonModel.commandes_en_attente params[:page], 2 
  end
end

class Commande < ActiveRecord::base
  def commande_en_attente params page, perpage
    MonModel.paginate :page => page, :per_page => perpage, :condition {mes_conditions}, :order => 'date DESC'
  end
end

Ce n’est pas top non plus, mais je préfère cela pour l’instant. Si quelqu’un a une idée, je suis prêt à l’entendre.

Alors que la version 5.3.1 avance, je viens juste de me mettre à jour.

Ce blog tourne maintenant avec “Typo 5.3 Robert Franck”. Principalement dédié au portage de l’application pour RubyOnRails 2.2.2 , cette version amène tout de même un paquet de corrections de bug et d’évolutions.

Il y en a une que j’attendais (par flème de la faire) depuis longtemps: la redéfinition du format des urls. Je pense que d’ici peu, les urls ici passeront d’un format /année/mois/jour/titre à /titre :-)

Merci à l’équipe, comme d’habitude, pour le bon boulot !

Alors que la version 5.3.1 avance, je viens juste de me mettre à jour.

Ce blog tourne maintenant avec “Typo 5.3 Robert Franck”. Principalement dédié au portage de l’application pour RubyOnRails 2.2.2 , cette version amène tout de même un paquet de corrections de bug et d’évolutions.

Il y en a une que j’attendais (par flème de la faire) depuis longtemps: la redéfinition du format des urls. Je pense que d’ici peu, les urls ici passeront d’un format /année/mois/jour/titre à /titre :-)

Merci à l’équipe, comme d’habitude, pour le bon boulot !

Pour noël on a eu le droit à une annonce très bruyante (mais plus très fraîche maintenant).

Rails 3 intègrera Merb

Personnellement, je trouve que c’est une bonne chose. Ces deux framework apporte la même chose aux développeurs: un confort de développement pour des applications web. Et on juste quelques divergence de point de vue qui explique l’existance des deux frameworks. Et pour des nouveaux venu, quelque semaine de tests sur l’un, puis sur l’autres pour vraiment savoir lequel choisir… Cette fusion devrait permettre d’apporter les bonnes idées de Merb dans Rails et inversement. De plus il semblerais que les développeurs de Merb travail beaucoup plus à l’écoute de la communauté d’utilisateur, si Rails peut s’enrichir de ce mode de fonctionnement, ça permettra surement à tout le monde d’en profiter. Nous verrons bien ce que cela peut donner.

De la même manière, j’ai l’impression que Sinatra et Camping marche dans la même direction: faire un framework web ultra léger. C’est dommage de ne pas joindre leurs force.

Avant de juger trop vite il faut que j’étudie ce Sinatra… “Fly me to the moon”

Cela fait un moment qu’un nouveau troll à pointé son nez. Après vim versus emacs, gnome versus kde et tant d’autres, on a maintenant git versus mercurial.

Derrière ces deux noms se cache un outil de gestion de versions. Contrairement à CVS ou SubVersion ces deux là (et quelques autres) sont dit décentralisé. Ce mode permet de nouvelles possibilités dans la manière dont les équipes travaillent.

On trouve beaucoup de comparatif entre ces deux outils, et je ne suis pas convaincu par les uns ou les autres. Pour moi les seules différences que je vois aujourd’hui c’est:

• langage source : Git est écrit en C, Mercurial en Python
• Commande: Git utilise trois lettre git, Mercurial en utilise deux hg

Une des grandes forces de la communauté des utilisateurs de Git est d’avoir eu très rapidement accès à un outil d’hébergement : github . De plus, l’équipe du framework RubyOnRails ayant adopté Git, la communauté Rails l’a également adopté. Bien sur, beaucoup d’autres projets utilisent Git, notamment le noyau Linux.

Mais Mercurial n’est pas en reste (contrairement à ce que l’on pourrait croire).

La communauté d’utilisateur de Mercurial a également un outil d’hébergement: bitbucket ou encore freeHg, et pour ce qui est des projets phare ayant choisi mercurial on retrouve mozilla , NetBeans , OpenJDK , OpenSolaris, Xen , et beaucoup d’autres

Pour le moment mon choix c’est porté sur Mercurial (allez savoir pourquoi). Cependant, je crois qu’avant de faire un choix définitif, il me faut apprendre à me servir des deux. Je me suis donc créé un compte sur GitHub, un sur BitBucket et un sur freeHg. GitHub et BitBucket propose tout deux une utilisation de type premium. Par exemple:

• GitHub propose un nombre illimité de repository public associé à un nombre illimité de collaborateur le tout avec 100MB d’espace disque. Ensuite c’est une location par mois avec une augmentation des repository privée associé à un nombre restreint de collaborateur et une augmentation de l’espace disque disponible.

• BitBucket propose lui un repository privé et un nombre illimité de repository public le tout devant tenir sur 150 MB. Ensuite, ce sont des tarifs par MB et fonction du nombre de repository privée.

Ces deux là sont partis sur des offres payantes assez différentes. Chacune d’entre elle peut avoir sont intérêt selon les besoins.

• freeHg semble plus libre en apparence (je n’ai rien vu au sujet de ma carte bleu, à part un bouton donate). Par contre il impose l’utilisation de licence libre pour les projets hébergé, et décline toute responsabilité en cas de problème.

Pour être honnête, je viens de découvrir freeHg en écrivant ce billet… Je crois que tout ceci est un peu frais pour moi, je vous en dirais plus quand j’aurais manipulé un peu.

Dimanche: RailsParty

J’ai décidé de me rendre au Dune, lieu de l’évènement en voiture plutôt qu’en transport, pensant que pour le soir ça serait plus rapide. J’ai donc proposé à Guillaume de passer le prendre à l’hotel, porte de la villette. Avec les 10 minutes de retard habituelle du au embouteillage du périph, Guillaume arrive accompagné de Yann Lugrin venu de Suisse pour ParisOnRails ET la RailsParty (Nouveau membre de RubyFrance depuis d’ailleurs , Bienvenue ;-)).

Mais voilà, trop de bouchon, Guillaume ne fera pas de discour d’intro.

Finalement avec plus d’une heure de retard, nous arrivons dans un Dune bien rempli, avec, comme d’habitude dans les réunions Ruby et Rails, l’impression d’être dans une boutique Apple. Deux vidéoprojecteurs, un comptoir, des gens en train de pianoter : c’est bien décontracté, un évènement communautaire quoi.

Beaucoup de présentations, plutôt courte mais bien mené, Petite difficulté pour suivre puisque les deux se déroule presque cote à cote.

J’ai bien discuté avec Frederic et Cyril au sujet de Typo. Ils m’ont présenté l’énorme boulot accompli pour la version 6. Cette mouture devrait voir le jour depuis quelque semaine déjà, mais trop de nouvelle fonctionnalité semble manquer à Frederic ;-).

On a pu y voir aussi Eric Daspet, Nicolas Merouze, Sunny et plein d’autres ! Les sponsors sont venu en force, il me semble que Novelys a dépéché sur place 5 ou 6 personnes, et AF83 a innondé la salle de badge.

Merci à Jean-François d’avoir réussi à mettre cette évènement sur pied en a peine plus d’un mois.

Lundi: ParisOnRails

Pas fou, cette fois j’y vais en transport en commun ! Du coup je suis à l’heure. Prise de badge, bonjour à plusieurs personnes déjà vu la veille (Yann, cette fois tu es à l’heure ;-)). Je suis avec une personne qui, avec un passif sur une techno propriétaire, s’interesse à Ruby depuis une petite année. Du beau monde, et une cité de science vide car fermé le lundi. Ca fait bizarre, je ne l’avais jamais vu comme ça.

Après une introduction assez breve de Richard et Laurent organisateur de l’évènement, Guillaume attaque direct sur les nouveautés qui nous attende dans la version 1.9 de Ruby . Du bon, du moins bon, mais on sent que le “Matz” et la CoreTeam de Ruby corrige certaine erreur de jeunesse, propose de nouvelle possibilité de syntaxe (c’est surtout là le bon et le moins bon je trouve), mais surtout apporte le support de l’unicode, propose une solution de gestion de Thread interessante (Fibre). A noter surtout, YARV qui va remplacé la MRI actuel: amélioration de performance a venir !

Ensuite, présentation du framework Mootools. Interessant, mais je crois que je me contenterais de prototype.js pour le moment. Ceci dit, c’est bon de savoir que cela existe ! :)

Vient ensuite une conf de Russ Olsen qui c’est levé très très tôt pour nous parlé de Ruby et de son expérience dans les langages en général. Exellent ! J’adore la façon dont il a traité des designs patterns en Ruby, et j’ai beaucoup aimé sont intervention à ParisOnRails. Respect.

L’après midi reprend avec deux conférences parlant de Selenium. J’ai un peu raté la première (trop de temps à table), mais la deuxième à été très agréablement présenté. Cependant, et même si je suis convaincu que mettre en place des test d’acceptance est important, je crois qu’il faudrait d’abord avoir une bonne habitude des tests unitaires dans les équipes… ça serait déjà pas mal. Mais pour l’étape suivante, j’ai bien noté, Selenium Grid ! :)

Michael Koziarski en passage à Paris depuis cette été (repartant dans les jour qui vienne) nous a fait une présentation sur les performances d’un application Web. Partant du plus important: le resultat que l’utilisateur voit et s’enfonçant jusqu’au memcahe et autre système d’optimisation. Très riche, très dense, très rapide… grosse présentation.

Intervention de DHH himself. c’est sympa de le voir, mais finalement, nous n’apprenons pas grand chose. Une présentaiton de Liquid. Un moteur de template… Mouais. Je ne suis pas convaincu, pas assez KISS pour mes besoins.

Une petite table ronde et puis s’en vont… Un peu dommage finalement la fin de cette journée. Je ne suis pas déçu, mais après la très bonne matinée, j’avoue que l’après midi ma paru un peu fade. Ca ne peut pas être à mon gout toute la journée, nous étions quand même prêt de 250.

Lundi soir Apéro Ruby #8 le soir de ParisOnRails…

Je n’y suis pas aller, no comment.

Avec les feuilles qui tombent vient le temps de ParisOnRails . Et cette année, plutôt que d’organiser un apéro Ruby la veille au soir, l’association RubyFrance a décider d’organiser une Rails Party

Au programme

L’après-midi sera consacré à des ateliers, sûrement autour de Typo, peut-être de Pictrails, RSpec et sûrement bien d’autres !

La soirée sera ouverte au Lightning talks (présentation courte d’une dixaine de minutes).

L’évènement se veut conviviale, c’est avant tout un moyen de ce retrouver entre raillers avant les conférences du lendemain.

Rendez-vous donc le dimanche 30 novembre 2008 de 16 heures à 22 heures au Dune, 18 avenue Claude Vellefaux, dans le 10ème arrondissement de Paris.

Cyril y sera, Frederic viens aussi (Typo, Ergonomie, Web, et plein de chose à dire, bien sur l’association RubyFrance avec tout plein de membre motivé autour de l’organisateur des évènements Ruby Parisien Jean-François !

A dimanche alors !

Ce blog tourne maintenant avec la version 5.1.2 du moteur de blog Typo (également appeler typoesphere). Comme d’habitude, du bon boulot.

Bravo à l’équipe !
Merci Cartier Bresson !

L’annonce officiel: Typo 5.1 Cartier Bresson is out

Et pour compléter ce billet, je tiens à vous signaler/rappeler que l’équipe de Typo à mis en place Redmine un gestionnaire de projet écrit en RubyOnRails et que vous pouvez trouver tout plein de thème dans le jardin de typo.

D’autres nouveauté devrait arriver d’ici le 15 aout dans les parrages…

Ca y est, l’équipe de Typo a trouvé sont jardinier pour le TypoGarden !

Bienvenue à Damien Mathieu !

L’annonce officiel sur le blog de Typo