Mon apprentissage de Ruby et Rails

[Sephi-Chan]

On peut effectivement rouvrir n'importe quelle classe. C'est effectivement à utiliser prudemment (c'est d'ailleurs l'objet d'une fonctionnalité de Ruby 2.0 : les refinements).

Les symboles sont effectivement des clés arbitraires de type singleton (un symbole :foo aura toujours la même identité qu'un autre symbole :foo, alors que deux chaînes "foo" et "foo" ont des identités différentes.

L'aspect implicite de Ruby et notamment le retour de la dernière expression d'un bloc (qu'on retrouve d'ailleurs en Scala ou en Erlang) est une force. Par exemple, les conditions retournent des valeurs.

class ApplicationController < ActionController::Base

  def current_user

    return nil unless cookies.signed[:persistence_token].present?

    @current_user ||= begin

      # Do something. It's only done when @current_user is falsy (eg. false or nil) so we won't call the database every time current_user is called.

      User.find_by_persistence_token(cookies.signed[:persistence_token])

    end

  end

end

end_game_type = if world.destroyed?

  :world_is_destroyed

elsif world.players.alive.one?

  :only_one_survivor

end

Enfin, plein de choses qui permettent d'éviter d'écrire des tartines ou de surcharger d'instructions inutiles.

[Holy]

Merci encore pour toutes ces précisions

Tiens, je me demandais si vous n'auriez pas une adresse pour débutant en ruby, parce que j'ai des questions assez triviales à poser. La doc est assez abondante pour commencer...

Par exemple :

string = 'lulin'

leetLetters = {'0' => 'o', '1' => 'i', '2' => 'z', '3' => 'e'}

string.gsub('/[' + leetLetters.keys.join + ']/', leetLetters)

Ca marche, mais j'imagine qu'il y a un moyen plus simple...

[Sephi-Chan]

Pour les questions que tu ne souhaites pas poster ici, tu peux te tourner vers le salon IRC #ruby du réseau freenode.net.

Je ne crois pas qu'il existe de méthodes plus pratique pour remplacer certains caractères par d'autres.

[Holy]

Merci ^^

Si je puis me permettre une bonne référence pour Ruby qui est très complète (trouvable en pdf sur internet...) Pragmatic Programmers : Programming Ruby 1.9 (2009) de Dave Thomas.

Sinon, j'ai lu dans cette ouvrage que les variables globales ($) étaient peu appréciées (classique) et les variables de classe (@@) peu utilisées.

Although we talk about global and class variables here for completeness, you’ll find they are rarely used in Ruby programs. There’s a lot of evidence that global variables make programs harder to maintain. Class variables are not as dangerous—it’s just that people tend not to use them much.

J'ai une petite question pratique : j'ai quelques constantes que j'utiliserai dans mes modèles comme dans mes vues et je ne sais pas trop où les placer ^^ Je pensais à créer un fichier dans le dossier initializers avec un bête module "Constant".

[Sephi-Chan]

Le pickaxe book, c'est la bible.

Cite-moi quelques unes des constantes que tu utilises, on verra où on peut les mettre. :p

[niahoo]

Généralement une constante se rapporte à quelque chose, par exemple le nombre de points de vie de base d'un joueur se place logiquement dans une classe ayant rapport avec ces derniers, à commencer par le model.

[Holy]

Le pickaxe book, c'est la bible.

Cite-moi quelques unes des constantes que tu utilises, on verra où on peut les mettre. :p

Par exemple le nom des nations auxquelles les joueurs peuvent appartenir, les statuts des joueurs (modo, joueur, admin).

[Sephi-Chan]

La liste des nations disponibles n'a-t-elle pas plutôt sa place en base de données ?

Quoi qu'il en soit, tu peux mettre ces constantes dans tes classes quand ça fait sens. Par exemple :

class Player

  AVAILABLE_NATIONS = %w( Allemagne Belgique France )

end

Tu peux même encapsuler les classes dans d'autres :

class Game

  class State

    WAITING_FOR_PLAYERS = 1

    FINISHED            = 2

  end



  def accepts_new_player?

    state == State::WAITING_FOR_PLAYERS

  end

end

[Holy]

La liste des nations disponibles n'a-t-elle pas plutôt sa place en base de données ?

A priori c'est une liste qui ne changera pas. On sait jamais m'enfin ^^

Sinon j'aime bien la deuxième solution qui me semble avoir pas mal de sens Autre question toujours sur le DRY. J'ai des constantes qui reprennent les pattern de certaines regex (email par exemple), ça vaut la peine de créer un module "Regex" (plutôt qu'une classe vu que j'aurai pas de méthode dedans à priori) ?

Autre question sur l'inclusion des classes (modèles, controlleurs et helpers), tout est inclus sur chaque page ou bien l'inclusion se fait de façon sélective (exemple : inclusion que de la classe controleur appelée par le routeur) ? Comme y a beaucoup de "magic" dans Rails, c'est pas évident de deviner ce type de comportement et j'ai encore rien trouvé sur le sujet

Je continue d'avancer en parallèle sur Ruby et Rails avec les deux dernières sources citées (Pickaxe Book et Apprendre Rails par l'exemple), ça marche assez bien pour l'apprentissage. Je commence à avoir une véritable idée de la puissance de Ruby qui est très souple par rapport à PHP au niveau de la syntaxe et qui dispose de beaucoup plus de structures de données (block, range, array, hash, symbol, regex, string, integer, float, boolean, nil, ...). Y a beaucoup de choses à assimiler du coup, surtout vu les nombreuses options mais je dois pas être loin de pouvoir tout déchiffrer (y a beaucoup d'interrogations syntaxiques qui ont trouvé leurs réponses dans le Pickaxe Book).

Pour Rails, je suis un peu dubitatif sur le développement dirigé par les tests. J'ai l'impression que pour certaines choses simples c'est une perte de temps et que ça ajoute encore une couche de code à maintenir pour pas grand chose. Fin, je vois pas trop la pertinence du processus en fait.
Sinon, quelle Gem utilisez-vous pour vos tests, celle de base de Rails ou Rspec (ou autre ?) ?

Sinon, j'ai pas encore lu grand chose sur la façon de documenter son code en Ruby. Des infos à ce sujet ?

Désolé de vous bombarder de questions mais je me dis que vous aurez toujours de meilleures réponses à me donner qu'un moteur de recherche, surtout que les ressources sur Rails sont éparses et pas toujours actualisées.

[Sephi-Chan]

La liste des nations disponibles n'a-t-elle pas plutôt sa place en base de données ?

A priori c'est une liste qui ne changera pas. On sait jamais m'enfin ^^

L'utilisation d'une constante paraît donc appropriée.

Autre question toujours sur le DRY. J'ai des constantes qui reprennent les pattern de certaines regex (email par exemple), ça vaut la peine de créer un module "Regex" (plutôt qu'une classe vu que j'aurai pas de méthode dedans à priori) ?

Si vraiment il y a des regexp que tu utilises fréquemment, c'est une possibilité. Pour les emails, tu peux aussi utiliser une gem (à moins qu'un test simple mais inexact suffise, comme dans bien des cas).

Autre question sur l'inclusion des classes (modèles, controlleurs et helpers), tout est inclus sur chaque page ou bien l'inclusion se fait de façon sélective (exemple : inclusion que de la classe controleur appelée par le routeur) ? Comme y a beaucoup de "magic" dans Rails, c'est pas évident de deviner ce type de comportement et j'ai encore rien trouvé sur le sujet

Dans Rails, l'ensemble de l'environnement est chargé dans le processus (que ce soit Passenger ou des workers FCGI) au lancement de ce dernier (c'est pour ça qu'il faut relancer les workers lors d'un nouveau déploiement).

Pour Rails, je suis un peu dubitatif sur le développement dirigé par les tests. J'ai l'impression que pour certaines choses simples c'est une perte de temps et que ça ajoute encore une couche de code à maintenir pour pas grand chose. Fin, je vois pas trop la pertinence du processus en fait.

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.

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

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.

Sinon, quelle Gem utilisez-vous pour vos tests, celle de base de Rails ou Rspec (ou autre ?) ?

J'utilise souvent Test::Unit mais je sais aussi utiliser Minitest (qui est intégré à Ruby) et Rspec. Je les ai tous utilisé plusieurs fois et les apprécie tous.

Pour mettre en place mes conditions de tests, je n'utilise pas les fixtures (bien trop pénibles à maintenir dans une application un peu complexe) mais Factory Girl.

J'utilise Capybara pour mes tests d'intégration (avec Capybara Webkit pour tester du Javascript).

Je m'efforce d'être pragmatique dans l'exécution des tests : une exécution un peu lente à cause des nombreux objets créés en base ne me dérange pas, je préfère ça que d'utiliser des mock à tour de bras (que je ne rechigne pas à utiliser quand je trouve ça pertinent). Tant qu'on reste dans la poignée de secondes, ça me va.

Sinon, j'ai pas encore lu grand chose sur la façon de documenter son code en Ruby. Des infos à ce sujet ?

RDoc est intégré au langage. C'est ce qui est utilisé pour générer la documentation de l'API de Ruby on Rails. Jette un oeil au code de Rails, tu verras à quoi ça ressemble. Il y en a d'autres (Yard, notamment) mais je n'en utilise aucun.

Désolé de vous bombarder de questions mais je me dis que vous aurez toujours de meilleures réponses à me donner qu'un moteur de recherche, surtout que les ressources sur Rails sont éparses et pas toujours actualisées.

Ce genre de sujet est fait pour ça. En plus de pouvoir répondre à tes questions, ça permet également d'intéresser les curieux.