Mon apprentissage de Ruby et Rails

[Holy]

Bonjour à tous,

Suite à mes premiers pas avec Ruby, je décide de faire un petit bilan, comme Sephi l'a fait auparavant pour Erlang. Ca sera sans doute moins riche étant donné que j'ai un bagage moins important et que je m'oriente clairement vers le web (Rails ou Sinatra).

Avant d'aborder Ruby on Rails, j'ai décidé de travailler sur le langage soutenant le framework Ruby.

Premières impressions concernant Ruby :
- Mieux vaut être anglophile car la très grande majorité des ressources intéressantes sur le sujet sont en anglais. Même sur des sites généralistes comme le site du zéro ou developpez.com, il n'est pas évident de trouver son bonheur.
- Le code repose sur un postulat assez simple "tout est objet", avec une syntaxe relativement proche du javascript du coup (vive l'objet).
- Le langage est peu verbeux et si il peut paraître assez opaque au départ (beaucoup de conventions arbitraires), il se révèle vite assez intuitif et j'ai l'impression qu'on prend rapidement le pli.
- Beaucoup de racourcis de méthodes (souvent disponibles en deux syntaxes différentes) permettent de faire des choses simples sans se casser la tête. Exemple : [1, 2, 3, 4][-1] retourne 4, soit un index inversé sur les tableaux.
- A fortiori, le langage est plus "propre" que le php, la généralisation de l'objet permet d'éviter la répétition des typages dans les noms de méthode (substr devient juste .sub en ruby). Mine de rien, ça change énormément de choses.
- J'ai l'impression qu'une partie de la communauté confond Ruby et Ruby on Rails. On peut lire ceci sur Try Ruby par exemple : "Ruby is a programming language from Japan (available at ruby-lang.org) which is revolutionizing the web."

Note importante : je n'ai pas encore noté ici mes impressions concernant Rails, mais une chose est sûre, il faut avoir un parfait contrôle de son environnement. J'ai l'impression que développer en Ruby sous Windows doit pas être si évident que ça. Je trouve ça un peu oppressant au départ quand on est pas un professionnel de l'informatique.

Ressources intéressantes concernant Ruby :
- Ruby-lang.org : Une petite introduction à ruby. Vous devez avoir installé Ruby auparavant (moi j'ai utilisé Ruby Version Manager).
- RubyMonk : indispensable pour apprendre Ruby avec des exercices relativement simples pour qui a déjà fait de la programmation. Vous avez accès à deux "livres" d'exercice gratuits, agrémentés d'explication. Pour 10$ par mois vous pouvez avoir accès au reste du site, c'est probablement ce que je ferai.
- Try Ruby : Même style que RubyMonk.

[Sephi-Chan]

Cool ! J'ai hâte de lire tes découvertes, tes questions et tes doutes.

C'est clair que développer en Ruby sous Windows peut vite relever du parcours du combattant, surtout quand tu utilises des Gems qui ont besoin d'extension (libxml & cie).

Dallas, ton univers impitoyable !

[Holy]

C'est tellement mal foutu que j'ai décidé de réinstaller Ubuntu sur mon ordi en dual boot Je me suis épargné quelques heures de galère .

Premières impressions concernant RoR :
- Le système de Gem, une fois maîtrisé, est vraiment intéressant. Le système de dépendances géré en interne est vraiment cool, pas besoin de faire dix mille manipulations pour ajouter une Gem à son projet.
- J'ai choisi d'utiliser haml puisque mon propre moteur de template s'en inspirait. C'est très plaisant à utiliser. Je fais "que" bidouiller pour le moment mais je devrais essayer d'adapter le template de mon projet actuel dans les jours qui viennent.
- Je trouve l'arborescence sous ruby en même temps plus claire (tous les fichiers de configuration se trouvent au même endroit) et en même temps plus concentrée (pas de bundle) que sous Symphony.
- Je galère un peu avec l'Asset Pipeline. j'ai pas réussi à trouver de sources vraiment explicites sur le fonctionnement de l'asset, et en particulier le fonctionnement de l'arborescence. J'utilise Sass, j'arrive à générer mes fichiers Css dès qu'il y a une modification, mais actuellement mes fichiers sass sont aussi inclus par mon helper dans ma vue. Si vous avez une bonne ressource à ce propos...

<link href="/assets/application.css?body=1" media="all" rel="stylesheet" type="text/css" />

<link href="/assets/min/home.css?body=1" media="all" rel="stylesheet" type="text/css" />

<!-- En réalité ce fichier correspond à "/assets/sass/home.sass" -->

<link href="/assets/sass/home.css?body=1" media="all" rel="stylesheet" type="text/css" />

J'aimerais bien placer mes fichiers sass dans un dossier et mes fichiers compilés dans l'autre, la compilation fonctionne parfaitement, mais pas l'inclusion.

Autres observations sur Ruby :
- Il y a pas mal de façons différentes de gérer les boucles (for, each, loop, times), chacune ayant ses avantages. Ca me plait beaucoup.
- La manipulation de tableaux par méthode est parfois spéciale au niveau de la syntaxe, il faut utiliser des accolades pour ouvrir un filtre. Exemple :

Code :

[1, 2, 3, 4].delete_if{|i| i.even?}

- Les hash sont, de ce que j'en ai compris, rien d'autre que les tableaux associatifs en PHP. Vu d'ici je comprends pas trop la pertinence de la distinction syntaxique entre les hash et les tableaux simples. Pourquoi ne pas avoir écrire les hashs comme les tableaux (puisque finalement ce sont des tableaux avec clés et profondeur) ? J'imagine qu'il doit y avoir une explication.

[Holy]

Je continue mon petit bonhomme de chemin cette fois ci sur Rails. Je lis énormément en ce moment pour essayer de bien saisir toutes les notions. Une grande partie des concepts sous-jacents à Rails était déjà plus ou moins connus (CRUD, REST, DRY) ce qui m'aide un peu mais je dois avouer avoir parfois le vertige tant le nombre de conventions et de nouveaux outils sont conséquents.

Entre Git (déploiement sur Heroku, Github), les migrations, le scaffolding (qu'on déconseille à peu près d'utiliser dans 80% des articles que j'ai lus), les conventions à n'en plus finir, ça finit par me donner la :malade:.

Encore heureux que j'ai une petite expérience des frameworks parce que je pense vraiment que pour un novice en programmation, c'est un coup à se flinguer, à moins d'être particulièrement tenace (fou ?). Autant apprendre à coder avec Ruby est relativement simple et logique, autant son imbrication dans Rails est balaise.

Cela étant dit, c'est la même chose pour tout framework, il faut un certain temps pour s'adapter.

Sinon, concrètement :
- C'est la première fois que je bosse avec un contrôleur de version (ça fait longtemps que je voulais m'y mettre). Git me paraît être très puissant mais assez complexe à appréhender. J'avais déjà eu l'occasion de m'en servir à une reprise mais rien de bien folichon. Là je commence à prendre mes marques. J'imagine que c'est en s'en servant qu'on se rend compte de la puissance des merges et du déploiement. Je me demande juste à quel point le déploiement est une tâche "automatique et facile", je crains les premiers problèmes
- La gestion des formulaires et leur liens avec certains modèles est sympa. Ca facilite grandement la validation (plus qu'un seul endroit où ces règles de validation sont écrites).

En conclusion, j'apprécie Rails pour une raison particulière : il incite à adopter des bonnes pratiques de développement (pas juste de programmation !). Le fait que la majorité des développeurs Rails utilise Git, la migration et la gestion des bases de données, la double logique CRUD/REST, la logique de programmation DRY, ... Toutes ces choses forcent à s'impliquer dans la logique du Framework et, à fortiori, à analyser sa propre façon de programmer. J'ai la sensation que je ne peux que "mieux" coder en utilisant Rails, ce qui est une source de motivation inépuisable

Edit : J'ai oublié de dire que j'avais trouvé un bon tutoriel assez conséquent sur Rails : http://french.railstutorial.org/chapters/beginning

C'est moins indigeste que les guides officiels et plus complets que la majorité des tutos qui traitent d'une spécificité de Rails.

[Sephi-Chan]

Débuter dans plusieurs domaines à la fois ne facilite pas les choses.

L'automatisation des déploiement est une réalité : tu as pu le voir avec Heroku où un simple push provoque une cascade d'opération. Quand tu hébergera des applications sur un serveur de production tu auras probablement l'occasion d'utiliser Capistrano, qui te permet de définir des opérations à faire (sur la ou les machines distantes) lors d'un déploiement, ce qui te permet ensuite d'effectuer le déploiement en lançant une commande comme cap deploy.


Les scaffold sont généralement évités dans la mesure où tu te limites rarement à ces opérations dans des applications réelles et qu'ils génèrent pas mal de code inutile (comme le double rendu des actions).

Ensuite, le design REST peuvent être de bonnes choses : essayer de raisonner en entités sur lesquelles on appelle des actions permet de simplifier certains processus (par exemple, la connexion/déconnexion à un compte utilisateur peut être considéré comme la création/destruction d'une session).

Cependant, il ne faut pas pour autant se laisser enfermer dans cette logique CRUD/REST au point de devenir contre-productif : utilise-les jusqu'à ce qu'ils te gênent. N'hésite pas à définir tes propres routes (plutôt que de te limiter aux ressources), par exemple.



Concernant tes soucis avec SASS, je ne comprends pas. La compilation du SASS (ou SCSS) se fait dynamiquement : les fichiers générés ne sont stockés nulle part (en réalité ils le sont, dans le dossier tmp).

Tu dois simplement placer tes feuilles de styles dans app/assets/stylesheets, en les nommant par exemple home.sass.css (donc en respectant la convention <nom>.<moteur de template>.<format de sortie>. Note que tu as tout à fait le droit de n'utiliser aucun moteur de template : tu peux avoir un fichier endive.css.

Le guide sur l'asset pipeline est plutôt complet mais n'hésite pas à poser des questions sur JeuWeb.

[Holy]

Tu dois simplement placer tes feuilles de styles dans app/assets/stylesheets, en les nommant par exemple home.sass.css (donc en respectant la convention <nom>.<moteur de template>.<format de sortie>.

Je faisais l'inverse *.css.sass à cause de scaffold qui générait *.css.scss. Merci

[Sephi-Chan]

Tu dois simplement placer tes feuilles de styles dans app/assets/stylesheets, en les nommant par exemple home.sass.css (donc en respectant la convention <nom>.<moteur de template>.<format de sortie>.

Je faisais l'inverse *.css.sass à cause de scaffold qui générait *.css.scss. Merci

Ne me remercie pas : je me suis planté. xD Désolé, je débute !

C'est en fait <nom>.<format de sortie>.<moteur de template>


Cela dit, tu ne devrais pas avoir un dossier sass ou min.

[Holy]

Ne me remercie pas : je me suis planté. xD Désolé, je débute !

C'est en fait <nom>.<format de sortie>.<moteur de template>


Cela dit, tu ne devrais pas avoir un dossier sass ou min.

Aaaaah, ça y est, ça marche ^^

Bizarrement, ça fonctionnait pas après mon installation de Rails, mais ça y est. J'ai plus que mes fichiers .sass comme je l’espérais donc plus besoin de deux dossiers, effectivement

[Sephi-Chan]

Cool !

- La manipulation de tableaux par méthode est parfois spéciale au niveau de la syntaxe, il faut utiliser des accolades pour ouvrir un filtre. Exemple :

Code :

[1, 2, 3, 4].delete_if{|i| i.even?}

Les méthodes pour "filtrer" (ce n'est pas toujours le cas) acceptent en fait un block (qui peut être délimité par des accolades ou les mots do |i| ... end. Par ailleurs, il existe une notation courte quand l'intérieur du bloc ne fait qu'un appel de méthode sur l'élément itéré : [ 1, 2, 3, 4 ].delete_if(&:even?).

- Les hash sont, de ce que j'en ai compris, rien d'autre que les tableaux associatifs en PHP. Vu d'ici je comprends pas trop la pertinence de la distinction syntaxique entre les hash et les tableaux simples. Pourquoi ne pas avoir écrire les hashs comme les tableaux (puisque finalement ce sont des tableaux avec clés et profondeur) ? J'imagine qu'il doit y avoir une explication.

À vrai dire, PHP est l'un des rares langages à ne pas faire la distinction entre ces deux structures (tableau et table de hachage ou tableau associatif). Ce sont pourtant des structures de données différentes. Pour te donner un exemple basique, push ou << n'auraient aucun sens dans le cas d'un hash.

[Holy]

Je comprends mieux l'intérêt des blocs du coup, qui se retrouvent en fait dés qu'il s'agit d'une boucle ou du parcours d'un tableau par une méthode.

J'ai découvert que Ruby permettait la modification de classes déjà établies (notamment celles du core) et je trouve ça excellent. Faut pas s'en faire une habitude mais ça peut être intéressant.

Les ranges (a..z, 0..9999) sont cools à utiliser, ça permet de gagner en productivité et c'est simple à lire. Les symboles restent encore une énigme pour moi, ce sont des chaines déchargées de toute méthode. On dirait des sortes de clés arbitraires qui ne servent "que" de clés, j'ai juste ?

La "magic" de Ruby et de Rails fait parfois bader. Genre les return implicites, je trouve ça horrible. L'idée est facilement compréhensible mais après des années de programmation explicite, c'est très perturbant. Je sais pas si je m'y ferai jamais, j'ai l'impression qu'il me faudrait un langage hybride entre les raccourcis et la propreté du code Ruby et l'explicitation de PHP. J'aime beaucoup la syntaxe de javascript par exemple (qui me semble être un mix entre les deux pour le coup).
Je sais que Ruby permet les return explicites, les parenthèses (optionnelles) & co mais malgré tout ces pages de langage si peu marquées, c'est flippant .