Ruby on Rails [aka. RoR] est un framework Ruby.

• LA meilleur intro en français sur le sujet: ICI
• Tout a commencé ici: Basecamp, avec cette équipe: 37signals
• Ruby, c'est le langage, ICI
• Rails, c'est le framework, ICI
• RoR est au Ruby ce que Symfony est au PHP, SQLonRails à SQL, ou Turbogear/Django au Python.

Et les autres framework Ruby:

• Camping, le microframework (4ko) de Why
• Nitro

Les docs en ligne:

• La doc de l'API en ligne, ou en .chm téléchargeable
• La doc API de ruby
• La (très bonne) doc en ligne de Prototype (.pdf téléchargeable) et le wiki de Scriptaculos
• Pour approfondir Ruby: Why The Lucky Stiff avec son très conseillé tutorial Why's (Poignant) Guide to Ruby

Les screencasts

• Le "start-it-all" thingy (Ooops)
• http://peepcode.com/ - Payants, mais très bons
• Un bon index pour en trouver d'autres
• http://www.railscasts.com/ - Encore un autre

Les cheatsheets

• Ils sont tous linkés ICI

Les newsgroups

• Rails France
• Rails: talk
• Radrails
• Prototype

Les bouquins:

• The Pragmatic Bookshelf: Agile Web Development with Rails - Dec 2006 - Maintenant en seconde édition, la Bible, pour bien démarrer
• The Pragmatic Bookshelf: Rails Recipes - June 2006 - Orienté résolution de cas pratiques, excellent
• The Pragmatic Bookshelf: Rails for Java Developers - Feb 2007 - Convaincre votre boss que JBoss est encore plus improductif que lui
• Manning: Ruby for Rails - May 2006 - Pour comprendre le code Ruby de Rails et aller plus loin dans le framework
• OReilly: Rails Cookbook - Jan 2007 - Le pendant du Rails Recipes chez O'Reilly
• OReilly: Ruby on Rails Up and Running - Aug 2006 - Pour les débutants. Moins bon que le Agile
• OReilly: Web Services on Rails - May 2006 - REST, SOAP et XML-RPC serveurs
• OReilly: Ajax on Rails - Dec 2006 - Le seWeb 2.0 et Rails. Du lourd là-aussi
• Oreilly : Pratique de Ruby on Rails, reprend les bases et explique même la conception d'une base de données. En français

Pour le déploiement de Rails, on utilise Capistrano

• Livre Capistrano: Automating Application Deployment
• Newsgroup Capistrano
• Newsgroup Déploiement

Server Mongrel, utilisé derrière un load-balancer/serveur de données statiques.
Globalisation Voir ici

Les éditeurs recommandés:

• SciTE est en bundle avec Ruby. Pas de gestionnaire de projet correct. Par contre vous pouvez associer vos .rb/.rhtml avec, car il est très léger et bien foutu pour éditer un ou deux fichiers.
• Radrails est mort. Vive Aptana.
• Textmate est indispensable si vous voulez créer en harmonie avec le coté hype qui sommeil en vous. Par contre, Steve doit probablement faire pression pour que le logiciel ne soit pas porté sur PC, Mac only. (Rails sera inclus dans Panther)
• Vim est toujours dans la place. Pour les masos?
• jEdit Pour ceux qui ont une jvm qui traine. Le meilleur d'après certains, mais seulement quand vous aurez terminé d'installer les plug-ins..
• Arachno À tester. Commercial payant, avec une version trial.
• NetBeans est dans la place. More here: http://ruby.netbeans.org/
• Et le dernier arrivé, c'est IntelliJ IDEA

À ajouter:

• Pour le déploiement de Rails, Capistrano -- livre Capistrano: Automating Application Deployment
• Pour servir des applis rails, Mongrel (Attention, uniquement pour servir du Ruby, utiliser un autre serveur HTTP pour les fichiers statiques e.g. images, CSS, ...)
• Why The Lucky Stiff avec son très conseillé tutorial Why's (Poignant) Guide to Ruby
• Camping, le microframework (4ko) de Why
• Nitro, un autre framework Ruby (concurrent de Rails)

Pour les débutants qui voudraient un bouquin en français :

• Oreilly : Pratique de Ruby on Rails, reprend les bases et explique même la conception d'une base de données.

Très bonne idée ce topic et surtout les liens qui me seront très utile  
 
J'en profite pour une petite question, je doute que ça vaille le coup d'un topac: quid des IDE? Y'en a-t-il des corrects actuellement? J'ai testé un peu Mondrian, mais il crash assez régulièrement. Y'a plus stable ou vaut-il mieux utiliser un éditeur de texte plus ou moins bateau plus une console à côté?

J'utilise le plugin Eclipse, sinon apparemment y a un plugin NetBeans qui vient de sortir et qui est assez prometteur (voire déjà très très sympa, j'ai pas encore testé) :
http://blogs.sun.com/tor/resource/ruby-editing.png (screenshot)
http://blogs.sun.com/roumen/entry/ [...] y_on_rails (screencasts, pas regardés encore).
 
Tu as aussi Arachno, mais c'est payant (y a un trial). Pas testé non plus.

Ah oui, pas mal Arachno, et vu son tarif, ça peut être une bonne option. Au seul inconvénient que j'ai l'impression qu'on paie une licence par plateforme utilisée non? (D'ailleurs la version nunux est un peu périmée :s)
 
NetBeans, je l'ai essayé uniquement pour du Java et il faisait ramer ma bécane au boulot Faudra que je le teste chez moi, voir si c'est plus supportable.
 
A propos du plugin Eclipse, il a l'air pas mal du tout... Ca me donnera l'occasion de tester autre chose.
 
Merci

Le plugin Eclipse n'est pas encore ultra-évolué par contre (c'est assez jeune il me semble), mais c'est un bon début. Je pense qu'ils peuvent faire beaucoup mieux à terme.
 
D'ailleurs y a aussi le plugin pour Rails (RadRails, toujours sous Eclipse) qui est vraiment très très bien foutu/pratique, bref je recommande.

Pour ce qui est de l'évolution, je n'ai pas besoin non plus d'un IDE killer, je débute franchement donc, si c'est pour n'utiliser que 2% du bouzin, ça sert à rien non plus. Avec un peu de bol j'évoluerais avec ce plugin

P'tain quand je vois des trucs genre les modules ou les mixins, j'me demande qu'est-ce que je fous avec des langages arriérés

Perso j'utilise PSPad pour coder en RoR.

Oui. Mais la gestion des codes-highlighters est complètement buggée. Dommage, le reste est bien et va dans le bon sens.

D'après ce que je lis sur Ongoing, Netbeans 6 risque d'être franchement poutrant pour faire du Ruby.
 
Mais toujours aussi lent  

Pour commencer, je conseillerais de faire ça à la roots: SciTE ou JEdit, commences par apprendre le langage et ensuite tu verras pour les accélérateurs

C'est ce que je te dis depuis des mois, mais tu veux pas me croire

 
Pas si top que ça finalement les mixins    
 
 
Sinon faudrait que je teste Rail un jour l'intro citée plus haut m'a mis l'eau à la bouche

1. Comme noté, il faut éviter de mettre des données dans les mixins, ils sont là pour jouer le rôle d'interfaces et pour ajouter des comportements e.g. Enumerable, il suffit d'implémenter #each dans son objet et de mixer Enumerable pour avoir toutes ces méthodes dispos, sauf #min, #max et #sort qui nécessitent également d'avoir implémenté <=>. Si ça c'est pas de la puissance...
2. et dans tous les cas, l'analyse du code permet de comprendre pourquoi ça se passe comme ça:
 

class ScaleDemo

on ouvre notre classe

include MajorScales

on mixe "MajorScales" dans "ScaleDemo", ScaleDemo devient donc

# Current ScaleDemo
class ScaleDemo
  def majorNum 
    @numNotes = 7 if @numNotes.nil? 
    @numNotes # Return 7 
  end 
end

include PentatonicScales

on mixe "PentatonicScales", après cette instruction ScaleDemo devient

# Current ScaleDemo
class ScaleDemo
  def majorNum 
    @numNotes = 7 if @numNotes.nil? 
    @numNotes # Return 7 
  end  
  def pentaNum 
    @numNotes = 5 if @numNotes.nil? 
    @numNotes # Return 5? 
  end
end

L'initialisation de scaleDemo se termine, puis on crée un objet scale

scale = ScaleDemo.new

Que se passe-t-il à l'exécution? (=> indique qu'on rentre dans une nouvelle scope/méthode, avec la méthode indiquée, #=> indique la conséquence d'une exécution), ## sert à indiquer le contenu de certaines variables intéressantes, ~ sert à indiquer ce qui s'affiche à l'écran

## @numNotes = nil
puts majorNum
 => self#majorNum
    ## @numNotes = nil
    @numNotes = 7 if @numNotes.nil? #=> @numNodes = 7
    @numNotes
~ 7
## @numNotes = 7
puts pentaNum
 => self#pentaNum
    ## @numNotes = 7
    @numNotes = 5 if @numNotes.nil? #=> rien puisque @numNotes.nil? == False
    @numNotes
~ 7

Il est indéniable que Ruby ait des "quirks", mais ça c'est surtout un problème de compréhension des mixins

Je l'attendais un peu de ta part celle-là Mais c'est vrai que du moment que c'est stable, qu'il a la coloration syntaxique et peut ouvrir plusieurs fichiers à la fois, ça me suffira pour l'instant. Je verrais quand ça me gonflera

Je viens de tomber sur un fil reddit qui invite les gens à dire pourquoi ils haïssent Ruby. Et en lisant ce fil, je suis tombé sur une série de commentaires que j'ai du mal à percuter: http://programming.reddit.com/info [...] nts/c18myt
Les commentaires en question sont celui de fry (le premier) et celui de rictic, en bas de la page.
 
Les codes qu'ils donnent ne compilent absolument pas puisqu'ils font +1 (pour fry) ou *3 (pour rictic) sur nil (le retour donc de print ou puts); sans compter le "Surprise!" sans ';' dans le code de rictic.
 
Je me demande alors si leur critiques sont fondées?

Drapal

Va faloir que tu apprennes à lire l'anglais, le fil demande aux gens ce qu'ils détestent dans Ruby pas pourquoi ils détestent Ruby, et accessoirement il faut avoir le contexte: il fait partie d'une longue série de posts demandant pourquoi les gens utilisent/n'utilisent pas tel ou tel langage, et ce que les gens haïssent dans tel ou tel langage.
 

1. fry: Le premier bloc qu'il donne est considéré comme valide et renvoie n'importe quoi, le second (qui semble strictement identique à une différence triviale près) génère une erreur:

3.times{1;print (1) + 1}

est considéré comme valide et s'exécute sans erreur ni warning (il imprime "222" btw)

3.times{print (1) + 1}

est considéré comme invalide et génère un warning au parsing et une erreur à la compilation (il imprime "1" puis balance une NoMethodError)
 
Sa critique me semble parfaitement valide, pour quelle raison l'un est-il accepté alors que l'autre est rejeté? Cette différence de parsing me semble, en étant gentil, totalement incohérent.
 
2. rictic: Effectivement son code ne fonctionne pas (celui avec Suprise), mais si tu ajoutes le ";" qu'il a probablement oublié sans faire exprès tu te retrouves avec le comportement suivant:
 

[2,3,5,7,11].each {|prime| puts (prime + 2) * 3 }

génère un warning au parsing, imprime "4" puis balance une NoMethodError

[2,3,5,7,11].each {|prime| "Surprise!"; puts (prime + 2) * 3 }

ne génère aucun warning, ne balance aucune exception, imprime  

C'est le même problème qu'au dessus, mais là encore la critique me semble parfaitement valide

Foutu interprété... J'ai pas testé séparément...  
J'ai encore perdu une occasion de me taire

   
 
Ca t'apprendra

Merci d'avoir pris le temps d'expliquer quand même au fait

Ya pas de quoi, je suis aussi là pour ça
 
(aussi parce que je suis tout d'abord là pour recevoir vos sous. Envoyez des dons!)

juste un petit link a propos de vim pour les barbus:
http://devblog.famundo.com/article [...] ed-eclipse

Je suis de parti pris car j'adore vim mais ça vaut vraiment le coup d'essayer.

Salut à tous. Ce topic et tous ses liens m'a donné envie de voir ce que donne RoR. Je vais commencer par bouqiner un peu.

Bon, je vais parles ici des petits trucs qui m'intriguent pendant que je lis "Agile Web developpement with Rails". ça animera un peu ce topic, même si le niveau risque de ne pas être très haut pour l'instant, si je suis tout seul à l'animer. Bref, ma question du jour : dans un template rhtml, il existe un helper qui permet de convertir les caractères spéciaux en entitées (&amp; , &lt; , etc.). J'ai donc fait cet essai tout bête :  

Et bien seul l'arobase et les '>', '<' sont convertis. Mes accents sont toujours là. Déception. On peut changer ce comportement ?

Non, h() a pour but d'échapper les caractères HTML générant des risques (il échappe aussi les quotes), pas de tout convertir

Ce qui est parfaitement normal et logique, le reste ne présente strictement aucun danger

En quoi est-ce un problème?

 
Cool, une réponse !
 
En quoi est ce un problème... Tient, c'est une bonne question ça ! En fait c'est plutôt que c'est pas le résultat que j'attendais. Sinon, transformer les caractères accentués en entités, ça permet de les afficher quel que soit le charset de la page, mais bon, c'est pas d'un intérêt monumental non plus, puisqu'on est censé avoir le bon charset qui va bien, de toute façon. Bref, c'était plus une surprise qu'un problème. Merci de ta réponse, qui m'a fait comprendre que ce comportement est en fait parfaitement logique.
A bientôt ! (pour une question un peu moins simple peut être)

Exactement, donc pas de raison cohérente d'utiliser des entities pour ce genre de caractères si on code correctement
 
(surtout que ça limite méchamment, ou ça complexifie violement le code d'échappement comme tu préfères, parce que la transformations de caractères Han en entités HTML ça doit être bien marrant, sauf pour la personne qui doit l'implémenter... et encore je ne sais même pas si c'est possible en fait)
(quoi que si, ça doit passer avec les entités numériques)
(peut-être)

Je sais pas. Je l'avais fait avec des entités numériques pour des caractères hébreux. Je sais plus trop pourquoi, je crois que j'avais pas le choix. Par contre en hébreux il n'y a qu'une trentaine de signes !
 
Tiens, pendant que j'y suis. Une autre question que je m'étais posé :  dans la présentation d'intro à Rails, l'auteur mentionne les helpers suivants :  

Qui déboucherait sur le code généré suivant :  

J'ai pas le livre "Agile..." sous la main là. Mais je me demandais : y a pas moyen de faire qu'ERb génère plutôt du xhtml ?

En l'occurence ça sort du XHTML par défaut
(pas que ça ait le moindre intérêt, mais bon)

Donc par défaut ça sortirait pas comme dans la présentation du gars ?
Ben, sortir du XHTML ça permet d'être cohérent. Moi qui n'écrit que du XHTML par exemple (le HTML je connais pas), ça m'évite d'avoir en sortie un code tout brouillon qui mélange tout les styles !

drapal
et un petit lien qui manques dans la liste pour ruby : http://ruby-doc.org/
 
edit : et aussi ce forum sur lequel on trouve pas mal d'infos : http://www.railsforum.com/

J'avais pas vu, j'ai vu, je reste

Bon, je continue ma petit lectura tranquile de "Agile Web Development with Rails". Vraiment sympa. Et c'est rare que je qualifie ce genre de livre de "sympa". Il est clair, exaustif (je pense) et même marrant de temps en temps. Bref, c'est pas pour ça que je poste. Je viens d'aborder le chapitre parlant des sessions, il ce que j'ai lu m'a fait bondir : l'auteur nous annonce comme une fleur, que dans Rails, les sessions sont maintenues par des cookies et que cela explique que les appli Rails nécessite l'activation des cookies. C'est grave quand même, on ne peut pas demander l'activation obligatoire des cookies. L'url rewriting ça existe depuis longtemps et c'est utile quand même !
Y a quelque chose que je n'ai pas compris ?

Il n'y a aucun rapport entre les sessions et l'url rewriting, et les sessions via l'url (à la jsessionid) c'est moisi.

Rien de vraiment anormal, donc, pour qu'une appli rails fonctionne sans cookies il me semble qu'il "suffit" de ne rien stocker en session (ça limite, mais ça suffit pour un fonctionnement basique)

@El_gringo : J'ai pas lu ça, de plus, y'a cookies[] et session[], pourquoi avoir deux gestion distinctes pour une même chose.

Parce que ça n'a aucun rapport, Rails stocke l'identifiant de session dans un cookie pour pouvoir ensuite récupérer la bonne session de l'utilisateur, on ne stocke pas toute la session dans des cookies

J'imagine bien, c'est à El gringo que je répondais

Ca ne change rien  à ma réponse.

@El_gringo : Pour info, c'est le même fonctionnement que php par exemple