Feed on
Posts
Comments
Article en preparation:

surprise...

(x%)

Voila un post qui va etre mis a jour de temps a autre. Tout simplement car je debutte dans Ruby on Rails (RoR).

J’ai commence a programmer en C++ en 1996 et je me suis recemment mis a Ruby On Rails (Janvier 2013). Du coup, y’a beaucoup de choses qui me reste a apprendre, ou tout smplement comprendre avec Rails et certains de mes positions pourront naturellement etre amenees a changer (quoi que).

Apres avoir lue une presentation globale d’un ami sur Ruby On Rails (http://news.humancoders.com/t/ruby/items/4716-presentation-technico-commerciale-de-ruby-on-rails), chque slide amenait une emotion differente. Aussi d’un slide a l’autre je passais de l’enchantement a la douleur. Comme Twitter est bien top limite en nombre de characters, je marque ici ce que je pense en gros de certaines partie que tout developer de Ruby on Rails va rencontrer. Puis j’ajoutterai/modifierai au fur et a mesure.

Dernier detail avant de commencer, RoR, j’adore vraiment beaucoup. Bref, voila plusieurs points, pelmel:

1. Ruby

J’aime beaucoup le language. Faut juste connaitre, et meme si c’est simple une fois qu’on connait, j’avoue que y’a beaucoup de facon de faire la meme chose au final, ce qui probablement contribue au sentiment de faire quelquechose d’artistique. Puis ca se lit joliement. On peut se demander pourquoi le choix de Ruby, mais bon c’est comme ca et c’est pas la fin du monde.

2. ActiveRecord

Le moins qu’on puisse dire c’est que je suis pas un fan d’ActiveRecord. C’est probablement le point de RoR que je deteste le plus.

Le belong_to sent pas bon, il pollue. Une “classe” utilisant belong_to expose le nom d’une autre classe qu’elle ne connait pas. Imaginons une class couleur (si tu veux pouvoir ajoutter/retirer des noms de couleur de facon dynamique). Ta classe couleur va “connaitre” toutes les classes l’utilisants car c’est pleins de belongs_to. Le sens est pas bon, ca devrait etre les classes qui ont besoin de couleur qui references couleur et seulement celles la. Ce qui veut dire que d’un point de vue maintenance c’est pas l’ideal, tu retires une classe machin et faut te rappeler que couleur reference machin. Peut mieux faire.

3. Routing

Genial comme concept. J’ai passe pas mal de temps a comprendre comment ca marche vraiment en fait (et toujours pas creuse plus loin que ce que j’ai besoin), la doc aide pas a simplifier la chose qui est pourtant assez simple losqu’on a compris. Je suis pas un fan des “helper” qui bundle 125 routes en une ligne, genre resource. A part leur example classique de blog, y’a toujours qqchose a changer. Au final c’est juste pour epater la galerie.

4. L’asset pipeline

J’suis pas  impressione. C’est juste un fichier qui indique quoi qu’on met dans la page, pas de quoi en faire tout un bruit (clairement j’ai pas explore plus loin :)). Le truc que j’ai mis un peu de temps a voir, c’est que les lignes importantes sont en commentaire… c’est quand meme pas tres malin.

5. Les compilateurs

Rajoutter .x.y.z fait que ca compile z, puis y pour obtenir un fichier de type x. Ca c’est super bien trouve et tout simplement genial.

Puis HAML, PUTAIN, ca j’adore! Ca me tue apres ces annees passees a faire du <div></div> a la con. HAML pourrait mieux faire pour la syntaxe mais c’est deja vraiment pas mal. On m’a conseille de regarder Jade, faudrait que je jette un coup d’oeil.

6. Test/rspec/…

Mon point faible, pas encore regarde ca. Je pense qu’il me faudrait une gem qui me donne une page ou j’appuie sur un bouton pour voir si mes tests passe a la place de console et lignes de commandes pour ca 😉

7. I18n

Les fichier Yaml pour les traductions, c’est vraiment le pied. Simple, efficace. J’adore.

8. La communaute

J’en ai entendu des vertes et des pas mure dessus. Moi je lis juste les questions StackOverflow, donc j’ignore et ca me pose pas de probleme.

9. Gem

Ca c’est cool, y’a toujours une gem pour resoudre un problem. C’est pas mal sympa et ca aide pas mal au development. Derriere ca suppose qu’une gem peut faire vraiment tout et n’importe quoi, faut que je me fasse ma bibliotheque de gem un de ces 4 pour voir comment c’est d’en faire.

J’adore l’ingeniosite et partage dont fait preuve les createurs de gem sur RoR. Comme disait un autre pote, y’a des “gem” aussi dans d’autres languages, mais c’est un peut comme dire que Android a des app comme IOS. LOL

10. Devise

Putain l’usine a gaz. Ca devrait etre un truc tout con. Il m’emmerde avec les routes des qu’on ajoutte un peu trop de trucs (genre locale + omniauth)… suis pas fan des gros trucs comme ca et surement pas de devise.

11. Mes gems coup de coeur

gem ‘better_errors’
gem ‘binding_of_caller’
gem ‘meta_request’
gem ‘letter_opener’

Les 3 premieres m’ont vraiment impressione (capable d’executer des lignes de code au point de l’exception, c’est un gain de temps monumental pour debugger/developer)

Letter opener est super pratique pour pas s’embeter avec les email.

12. Windows

Putain les mecs, faut arreter avec MAC et Linux only. C’est tout de meme assez convivial de developer sur Windows. Ca ca m’ennuie pas mal car c’est du development web et ca devrait pas faire de difference la platforme development ou on dit Linux et c’est tout car c’est pas hoste sur MAC non plus alors faut pas deconner . Peut vraiment mieux faire la. La vitesse d’acces des fichiers ralenti tout (serieusement, qui a code ca?), puis des gems marchent pas sur Windows (putain la blague)

 

A suivre…

 

 

PS: Mon projet RoR: http://Getjobs.ch

 

 

 

4 Responses to “Mon point de vue sur Ruby on Rails”

  1. on 03 Jul 2013 at 16:18 yannski

    Tu n’es pas obligé d’utiliser ActiveRecord si tu n’en as pas envie. Il y a des alternatives comme DataMapper par exemple http://datamapper.org/

    Bon par contre, moi j’aime bien ActiveRecord et je connais beaucoup de gens qui ont switché à Rails rien qu’à cause d’ActiveRecord.

  2. on 04 Jul 2013 at 10:23 David Bourguignon

    Un petite réponse sur quelques points :

    2 – Activerecord

    Laisse un peu de temps à l’utilisation. C’est assez génial à l’usage et très bien pensé.
    Le principe de Rails, c’est de rester simple, au moins au début.

    Le belongs_to par exemple fait sens car il correspond à une donnée dans la base de donnée. Il y a bien un lien entre les 2 classes, autant qu’il apparaisse dans le code.

    3 – Routing

    Rails est un framework avec des opinions, si tu suis les conventions, les ‘resources’ font sens et marche dans beaucoup de cas.
    Si on ne les suis pas, c’est un peu comme essayer de nager en remontant un cascade sans être un saumon, c’est pas se simplifier la vie.

    4 – L’asset pipeline

    Ça va quand même un peu plus loin. Là où ça prend tout son sens, c’est en production, quand on on minifie/compresse/… les JS et CSS mais qu’on maintient quand même des sources de dév lisible.

    9 – Gem

    Alors, oui c’est génial, il y’a des perles. Mais il faut juste faire attention de ne pas se laisser enfouir sous du code inconnu : toujours regarder le code d’une Gem, voir si ça vaut bien le coup ou pas.
    Y’a des gems qui sont overkill pour certain besoin, ou pas efficace pour ce qu’on en veut.

    12 – Windows

    C’est du dévelopement web dont je pense 99% des déploiements se font sur des UNIX, et probablement du Linux, donc développer sur une plateforme à base UNIX ça parait raisonable, ce qui inclut Mac et Linux, mais pas Windows.

    Alors, c’est sur dans un monde idéal, ça devrait marcher sans soucis sous Windows, mais c’est juste très dur à maintenir certaine chose avec des librairies natives sous Windows.

    Faut peut-être plutôt se tourner vers du JRuby alors.

    David

  3. on 04 Jul 2013 at 10:35 Jeremy Chatelaine

    Pour JRuby, y’a une lettre de trop pour mon gout :)

    @Yann & David: Pour l’active Record, je vois ca comme les templates/std en C++. C’est facile de faire un truc totallement inefficace car on comprend pas comment ca marche. Comme dit David, faut laisser le temps, ca viendra surement.

    Pour le belong, je suis pas d’accord du tout, la relation est a sens unique A -connait-> B et pas l’inverse, ca fait pas de sens d’avoir A reference d’une quelconque facon dans B. De plus l’implementation cree une table de relation a part, donc c’est invisible. C’est juste pas propre comme ca.

  4. on 04 Jul 2013 at 16:08 David Bourguignon

    Pour le belongs_to, je crois que tu confonds avec has_and_belongs_to_many :

    Pour le belongs_to, si A belongs_to B, ça veut dire que la table A a une foreign key sur la table B.

    Exemple :

    Invoice belongs_to Customer –> tables invoices à une colonne customer_id
    Customer has_many Incoices –> idem, ça permet de retrouver les invoices d’un customer directement

Trackback URI | Comments RSS

Laissez un message