RailsCamp : atelier de refactoring

Bonjour à tous,

Je compte proposer un atelier de refactoring lors du RailsCamp ce 17
mai.

Au programme :

  • Allégement des contrôleurs
  • Structuration de l’application en REST (avec l’aide des namespaces)
  • Centralisation de la logique métier dans les contrôlleurs
  • Utilisation des Presenters pour DRYer les vues
  • Utilisation des Observers pour lancer des actions
  • etc…
  1. Qu’en pensez-vous?
  2. Je suis donc à la recherche de code à refactorer.

Si certains courageux m’envoie leur code, je me ferai un plaisir de
l’utiliser pour illustrer cet atelier. (Je cherche bien entendu du
code qui ne respecte pas (toutes) les techniques décrites ci-dessus)

Si d’autres ont des suggestions pour des sujets et techniques qui
pourraient être présentées dans un tel atelier, vous pouvez me les
transmettre (à l’avance ou durant l’atelier même). L’idée est bien que
tout le monde participe et qu’un réel échange de connaissances se fasse.

Bonne journée,

Jean-Baptiste

Jean-Baptiste E.
Belighted.com | Web 2.0 Consulting & Training
Email : [email protected] | Phone: +32 486 377593

On 29 avr, 09:36, Jean-Baptiste E. [email protected] wrote:

  • Centralisation de la logique métier dans les contrôlleurs

Tu voulais dire “dans les modèles” :wink:

Si non je suis très intéressé par ce sujet. Je démarre bientôt le
remaniement d’une application developpé avec la version 1.0 de Ruby on
Rails. Ce serait donc intéressant de comparer nos point de vue.

Oups oui… Bien entendu :slight_smile:

On 29 Apr 2008, at 10:34, mourad hammiche wrote:

remaniement d’une application developpé avec la version 1.0 de Ruby on
Rails. Ce serait donc intéressant de comparer nos point de vue.


Jean-Baptiste E.
Belighted.com | Web 2.0 Consulting & Training
Email : [email protected] | Phone: +32 486 377593

Je t’invite à fouiller
là:Recent codes - RefactorMyCode.com


Baptiste

Utilisation des Observers pour lancer des actions

Perso, je ne pense pas que ce soit la meilleure maniere de d’approcher
le probleme. Je prefere 100 fois utilisé tous les callbacks qui
existent plutot que les Observers. En plus d’etre un gaspillage de
mémoire les observers ne fonctionnent qu’avec ActiveRecord :frowning:

Sinon je trouve que l’atelier est une excellente idée, je suggererai
peut etre d’aussi regarder les Conducteurs.

-Matt

Il est vrai qu’un CallBack dans la plus part des cas plus simple. Mais
l’utilisation d’un Callback n’est pas toujours judicieuse ou possible.
Par exemple dans le cas où l’action à déclencher n’a rien à voir le
modèle: Envoyer des messages de notifications, maintenir un journal
d’audit etc.

Peut-tu préciser en quoi l’utilisation d’un Observer gaspille de la
mémoire ?

On 29 Apr 2008, at 18:20, Matt Aimonetti wrote:

Perso, je ne pense pas que ce soit la meilleure maniere de d’approcher
le probleme. Je prefere 100 fois utilisé tous les callbacks qui
existent plutot que les Observers. En plus d’etre un gaspillage de
mémoire les observers ne fonctionnent qu’avec ActiveRecord :frowning:

Juste… Mais c’est aussi un bon moyen de garder le code bien propre.
Je ne savais pas que c’était un gaspillage de la mémoire.
Dans les cas où tu désires garder ton code séparé, que penses-tu de
rassembler les callbacks relatifs dans
un module et étendre les modèles avec ces derniers. Tu peux même
imaginer utiliser le même observer pour plusieurs modèles (p.ex. un
module “Logger” qui s’appliquerait à plusieurs modèles).

Sinon je trouve que l’atelier est une excellente idée, je suggererai
peut etre d’aussi regarder les Conducteurs.

Bien que je ne les utilise pas encore. Je me pencherai sérieusement
dessus pour le 17 mai.

Merci pour les conseils,

Jean-Baptiste

Jean-Baptiste E.
Belighted.com | Web 2.0 Consulting & Training
Email : [email protected] | Phone: +32 486 377593

Envoyer un message de notification peut être un contre exemple.

En effet, ActionMailer ne connait pas l’environnement dans lequel il
évolue a priori. Par exemple, si le mail en question doit contenir une
URL en rapport avec le site, il est beaucoup plus facile et
maintenable de construire l’objet ActionMailer dans un controller, et
avoir accès au cycle normal de traitement de la requête,
plutôtqu’écrire un observer qui impliquera toute une mécanique de gestion
des URLs assez fastidieuse.

++

yk

Le 29/04/08, mourad hammiche[email protected] a écrit :

Je suis d’accord avec avec Yann par rapport au contre-exemple du
mailer.

Quand je parle de gaspillage de mémoire, c’est un peu exagéré mais ca
t’oblige a creer une instance d’un nouvel object qui en gros utilise
de la “magie noir” pour creer des callbacks.

Regarde le source:
http://www.railsbrain.com/api/rails-2.0.2/doc/index.html?a=M001427&name=observers#

Apparement, tu dois en plus declarer tous tes observeurs dans ton
environment.rb : config.active_record.observers
= :comment_observer, :signup_observer

Tout ca pour quoi? juste pour mettre tes callbacks dans un autre
fichier.
Je te parie que la majorité des gens ne se rendent meme pas compte
qu’un observeur n’est qu’un peu de metaprogramming pour creer des
callback grace a un DSL.

De plus, je suis partisant d’un code qui se lit facilement, et a moins
que je me trompe, dans ton model il n’y a aucune references vers ton
observeur.

Si tu veux simplifier ton model, tu peux tres facilement utiliser un
module avec tous les call backs et inclure ton module dans ton model.
Moi, se prefere avoir tous mes callbacks dans mon model (les fonctions
elles meme peuvent etre dans un module, ca ne me gene pas du tout).

Ceci dit, il n’y a rien de grave avec l’utilisation des observers,
c’est juste que c’est plus trop au gout du jour.

-Matt