Mon apprentissage de Ruby et Rails

[Ter Rowan]

Il est clair qu'écrire et maintenir une suite de test est coûteux en temps, mais je pense que ça vaut le coup. Déjà parce qu'il est possible de développer une application (même riche en Javascript) sans jamais lancer le serveur Web, et aussi parce que ça permet d'exécuter des choses potentiellement longue en quelques instants.

Par exemple, on peut simuler des fragments de parties (en établissant un contexte initial) pour s'assurer qu'elle se déroule comme prévu. Dans un navigateur, ce serait affreusement long (ouvrir plusieurs navigateurs avec des utilisateurs différentes, cliquer, revenir, supprimer certaines données, etc.) alors que via un test d'intégration, ça se fait en une poignée de secondes, et on peut même forcer le hasard (via des stubs de Rspec ou de Mocha), faire avancer le temps (avec des gems comme Timecop), etc.

(...)
J'essaye d'être pragmatique et j'écris seulement les classes/méthodes importantes en TDD. Celles de moindre importance sont généralement testées après (pour documenter une fonctionnalité ou un bug, par exemple) et il m'arrive de ne pas tester. Je ne cours pas après le 100% de couverture de test.

complètement d'accord, peu importe en quel langage d'ailleurs

En somme, une suite de tests (unitaires et d'intégration) est très vite rentabilisée.

un peu moins d'accord sur l'aspect rentabilisation , ça améliore la qualité, mais je ne suis pas convaincu à grosse échelle que ce soit visiblement rentable (au sens financier) je dirais équivalent d'un point de vue coût / charge (mais avec une plus grande satisfaction puisque de meilleure qualité)

[Sephi-Chan]

Dans notre cas, je parlais plus de temps que d'argent, à vrai dire.

Cependant, les tests peuvent t'épargnent l'envoi de daube en production qui peuvent coûter cher (un utilisateur ne peut pas commander, un client qui impose une compensations en cas de soucis, etc.).

[srm]

Je pense que c'est rentable puisque le temps de vérification (qui est donc de l'argent dans le monde de l'entreprise) est très largement diminué.

Du moins, plus le projet est complexe
Pour un simple blog ça n'a aucun intérêt.

[Holy]

Je comprends mieux l'intérêt des tests. Ca m'a l'air assez complexe à appréhender comme autodidacte, mais j'essaierai quand j'en aurai l'occasion histoire de pouvoir voir plus loin. Merci.

Autre chose, l'optimisation de base de données (notamment tout ce qui concerne les champs) n'est pas faisable via Active Record à moins d'utiliser execute non ? Bête exemple : je suis obligé de créer des champs string de 255 octets pour un champ "sex" qui ne peut contenir dans les faits "que" 'homme', 'femme' (un champ 'enum'). Même chose pour certains integers qui ne peuvent aller que jusqu'à 9. Vu la philosophie prescriptive de Rails, je dois conclure que ce type d'optimisation est totalement superficiel et que les concepteurs de Rails préfèrent compter sur les validations de Rails pour ne pas corrompre la base de données ?

[srm]

C'est loin d'être superficielle, surtout sur les gros volumes

[Sephi-Chan]

Je comprends mieux l'intérêt des tests. Ca m'a l'air assez complexe à appréhender comme autodidacte, mais j'essaierai quand j'en aurai l'occasion histoire de pouvoir voir plus loin. Merci.

Il faudra probablement y dédier un peu de temps, mais ça vaut clairement le coup.

Le plus difficile est d'intégrer l'exécution des tests dans ton travail. Il faut configurer son éditeur pour lancer les tests sur lesquels on travaille (d'un simple raccourcis clavier).

Ecrire les tests en eux-même est assez simple. Tu peux jeter un œil aux tests unitaires de Conquest on Rails pour te donner une idée. Les fichiers importants sont le Gemfile, le fichier test_helper, les définitions de factories et les tests eux-mêmes.

Autre chose, l'optimisation de base de données (notamment tout ce qui concerne les champs) n'est pas faisable via Active Record à moins d'utiliser execute non ? Bête exemple : je suis obligé de créer des champs string de 255 octets pour un champ "sex" qui ne peut contenir dans les faits "que" 'homme', 'femme' (un champ 'enum'). Même chose pour certains integers qui ne peuvent aller que jusqu'à 9. Vu la philosophie prescriptive de Rails, je dois conclure que ce type d'optimisation est totalement superficiel et que les concepteurs de Rails préfèrent compter sur les validations de Rails pour ne pas corrompre la base de données ?

Note qu'un champ de type VARCHAR occupe toujours N + 1 octets, où N est la longueur de la chaîne. Ici, 255 n'est qu'une longueur maximale.

Ensuite, ce que tu indiques est tout à fait faisable : jette un œil à la documentation du module TableDefinition. Tu peux utiliser l'option limit pour spécifier la capacité d'une colonne.

Enfin, tu peux utiliser tous les types que tu veux à la place de string, integer, etc. Mais tu perdras l'indépendance de la base de données. C'est notamment utile si tu veux utiliser des types de colonnes très spécifiques (par exemple POINT dans PostgreSQL).


Rails a la réputation d'un framework tyrannique, mais pas à ce point ! :p

[t.bodeux]

Pour ce qui est du TDD, je suis d'accord avec Sephi, l'utiliser pour tout tester peut être stupide (par exemple, tester une page statique ...) mais pour des classes plus complexes (une gestion d'utilisateurs ou de droits), cela devient vraiment un gain de temps énorme. Je pense donc qu'il faut savoir ou mettre ses priorités ...

Pour moi, le TDD c'est comme les gems, il faut savoir quand l'utiliser et quand le laisser tomber.

PS: En passant, ça fait du bien de voir que la communauté Rails évolue un peu sur le Fofo !!! Je me sentais un peu seul

[Holy]

(t.bodeux = Viciousity ? :o)

Bon, il est temps de faire un nouveau bilan intermédiaire avec les petites choses que j'ai apprises ces derniers jours.

D'abord, je commence enfin à me débrouiller avec Git et je perçois vraiment l'intérêt de l'open-source (j'ai arpenté les projets de Sephi). J'en ai une utilisation pour le moins basique pour le moment, mais je pige le principe des commits, des pulls, des clones, des push, toussa, toussa. J'ai juste pas encore le réflexe de faire régulièrement de commits, ce qui a pour conséquence des commits avec souvent une dizaine de fichiers édités et un descriptif du commit qui n'est pas vraiment approprié. J'utilise ST2 comme éditeur, existe-t-il un plugin particulier qui permette de m'aider à faire des commits plus régulier (ou alors un raccourci pour la ligne de commande) ?

J'ai eu l'occasion de découvrir le blog de Synbioz qui est vraiment super intéressant avec de très bonnes ressources francophones sur Rails, notamment une série d'articles sur les gems à ne pas manquer, ça m'a permis d'en découvrir pas mal (cancan et devise notamment).

Ensuite, je participe en tant que cobaye à un google group "Ruby-debutant" qui vise à apporter des ressources francophones adaptés aux devs junior de Rails. J'espère vraiment que le projet fonctionnera et que ça permettra de créer un espace de discussion avec une approche pragmatique de Rails.

J'ai pas mal de soucis avec la documentation et les sources sur Rails qui sont très éparses et pas toujours à jour. J'ai beau avoir un relativement bon niveau d'anglais commun, le langage technique m'échappe un peu ce qui rend ma progression parfois difficile dans les guides Rails. Il existe des traductions francophones plus que parcellaires de ces guides sur RailsDebutant.org, c'est toujours ça de pris, d'ailleurs le projet Ruby-débutant dont je parle au-dessus aimerait relancer ces traductions.

Je découvre les premiers points faibles de Rails que sont : l'absence de documentation francophone, la magie de Ruby et de Rails combinés (notamment lié à une grande dose d'abstraction) rend parfois le code de Rails assez opaque, et ce sentiment d'opacité est renforcé par le fait que je dois me référer à la documentation anglophone.
Dernier gros point négatif qui est sans doute la cause des points soulevés précédemment : l'absence d'espace communautaire fort au niveau francophone. Comme j'ai eu l'occasion de le dire sur le google group de Rails France, mon premier réflexe quand j'ai voulu commencer à bosser sur Rails a été de chercher des espaces de discussion, j'ai écumé les principaux sites de programmation (SdZ, developpez.com, ...) et j'ai trouvé la plupart du temps des forums quasiment vides, soit de quoi me passer l'envie d'y poster des sujets.
A cet égard, je trouve l'absence totale de tutorial sur le site du zéro assez symptomatique (pour moi c'est carrément une "faute" en termes de promotion de RoR). Je me souviens de Sephi qui disait que Ruby et Rails étaient des technologies intéressantes pour commencer la programmation, ben force est de constater que la communauté RoR a pas forcément mis en place les structures pour "accueillir" les devs junior qui voudraient débuter sur Rails. J'ai même éprouvé un étrange soulagement quand j'ai trouvé les google groups dédiés à Rails, alors que j'étais perdu au milieu de la jungle RoR ^^ Je trouve qu'il y a un gros travail à faire de ce point de vue là si vous voulez garantir la promotion de votre outil de travail auprès d'autres développeurs francophones. Visiblement les choses commencent à bouger et c'est tant mieux

[Sephi-Chan]

Effectivement, la communauté francophone de Rails n'est pas très développée et un développeur débutant doit absolument connaître l'anglais pour s'en sortir.

Normalement, les guides apportent de solides connaissances sur l'utilisation du framework L'API permet d'aller fouiller chaque recoin.

Pour la suite, ce sont les blogs. Pour une veille assez ciblée est souvent intéressante, je recommande le site PlanetRubyOnRails, qui fédère les articles de nombreux blogs.

[Argorate]

Perso, je commence mon nouveau projet de jeu en ruby à partir de lundi (partiels terminé to day ! )

On pourra sans doute s'échanger des avis, et s'entre aider dans notre approche neuve de rails, avec la bienveillance, je l'espere, de notre ami Sephi
En tout cas j'ai hâte de tester et de passer à l'étape "je me débrouille" pour enfin voir ce que ça donne.

Il me semble Holy, qu'on avait discuter un peu en privé et que jusqu'alors tu étais un peu comme moi, avec un php et un FW maison, du coup y a pas mal de changement et c'est intéressant de voir d'autres manières de faire même s'il y a fatalement perte de temps a s'adapter, surtout que comme toi apparemment, je ne pifre pas vraiment l'anglais et c'est assez pénible et même handicapant en terme de temps perdu de ce confronter si souvent à l'anglais en documentation ruby, dommage...

bref, je te dirais ce que j'en pense d'ici un petit mois