Finalement, Rails en lui même n'est pas très compliqué à appréhender. Il faut juste bien choisir la méthode et les bouquins qu'on va utiliser, et procéder dans l'ordre :
- Ne pas démarrer avec une version trop récente de rails, car le gros point noir de Rails justement est son manque de documentation.
- s'attendre au début à devoir faire un peu de configuration qui n'a pas forcément grand chose à voir avec rails (configuration de liens avec base de données, installation de modules ruby divers pour fonctionnement correct par exemple ...).
- ne pas croire les gens ou les bouquins qui vous disent qu'on peut apprendre Rails sans apprendre Ruby. Certes on est pas obligé d'être un guru Ruby mais il faut connaitre les notions de base. Attention de ne pas tomber dans le même piège que moi : je suis habitué de la programmation C, C++, Perl, Python, shell, etc .... mais Ruby a ses specificités qu'il faut bien identifier pour pouvoir comprendre Rails. Ne soyez pas trop impatients, le temps passé à apprendre Ruby sera largement profitable pour la suite de l'apprentissage de Rails. Cela permettra de bien différencier la compréhension du langage de la compréhension du framework.
Une fois ces étapes passées, Rails est un vrai plaisir. Le seul reproche que je lui fais est le manque de clarté dans les messages d'erreur retournés, mais au final on s'y fait. Je ne suis pas encore un guru de Rails ou de Ruby mais j'y arriverai ...
Pour finir, et pour répondre à ceux qui à l'époque m'avaient conseillé de me tourner vers des frameworks Perl ou PHP, je dis NON. J'aime bien Perl, mais j'aime pas trop PHP, que je trouve trop proche du C et inadapté au développement de sites modernes ( impose d'écrire beaucoup trop de code pour une tache donnée, manque d'élégance, en gros c'est comme comparer une Mercedes ou une BMW à une Simca 1000. Il a fait son temps). Perl quant a lui m'est très utile dans ma vie d'admin système, mais Ruby dispose d'atouts que Perl n'a pas.
Voila, ceci pour dire à ceux qui hésiteraient encore à s'y mettre de se lancer, et de ne pas se laisser décourager par les problèmes qu'ils ne manqueront pas de rencontrer au début.
PS : Pour apprendre, le HS de Linux Magazine est très bien, je trouve seulement que la première partie sur Ruby manque parfois d'un peu d'explications sur certains concepts, et qu'une doc complémentaire sur Ruby est parfois bienvenue).
# PHP/Perl/Ruby
Posté par Pierrick Le Gall (site web personnel) . Évalué à 3.
> modernes
Comme pour Rails, as-tu une expérience avec un framework web comme CakePHP [3] ou Symfony [2] ?
Je pense que PHP a un énorme avantage sur les 2 concurrents que tu cites : sa disponibilité par défaut sur les hébergements web (et depuis très longtemps maitenant). Mais cela ne veut pas dire que PHP est inadapté au développement de sites modernes, juste que c'est plus simple quand les choses sont disponibles sur le serveur.
> Perl quant a lui m'est très utile dans ma vie d'admin système, mais
> Ruby dispose d'atouts que Perl n'a pas.
Cela m'intéresse fortement. Est-ce que tu as regardé un framework Perl comme Catalyst [1] ? N'est-il pas justement strictement équivalent à Rails pour Ruby ? (et dans ce cas là ton expertise en Perl t'aurais permis de te focaliser sur le framework et pas sur le langage)
[1] http://www.catalystframework.org/
[2] http://www.symfony-project.org/
[3] http://www.cakephp.org/
[^] # Re: PHP/Perl/Ruby
Posté par fredix . Évalué à 8.
Moui j'avais testé CachePHP en 2006 et il fallait se faire chier avec des tableaux dans les vues, alors qu'en Ruby on utilise des objets ...
D'après un ami c'est toujours le cas ... Leur but est soit disant qu'ainsi ils supportent aussi PHP4 :) supAir !
PHP c'est legacy c'est tout. Si on veut vraiment utiliser un MVC objet bien conçu, à part Rails et Django je vois pas.
[^] # Re: PHP/Perl/Ruby
Posté par scoundrel . Évalué à 6.
N'importe quoi. Java avait son Apache Struts et ses WebObjects avant que Rails ne soient une poussière dans l'oeil de son créateur. Et pourtant Ruby est aussi vieux que Java, et Python bien plus vieux que ces deux là, et avant Rails et Django&Turbogears c'était la misère (Hahahaha Zope. Hahahaha.)
[^] # Re: PHP/Perl/Ruby
Posté par fredix . Évalué à 3.
MVC bien conçu ? :) Pourtant le gros avantage de Rails sur Struts c'est sa philosophie convention vs configuration. C'est pas pour rien que Grails (http://grails.org/) est sorti il me semble.
[^] # Re: PHP/Perl/Ruby
Posté par totof2000 . Évalué à 10.
Oui mais non, la on parle de frameworks _simples_, pas d'une usine à gaz comme java ....
[^] # Re: PHP/Perl/Ruby
Posté par Sébastien Le Ray . Évalué à 0.
[^] # Re: PHP/Perl/Ruby
Posté par totof2000 . Évalué à 2.
[^] # Re: PHP/Perl/Ruby
Posté par Temsa (site web personnel) . Évalué à 2.
Tapestry 5 ? Il génère pas le code crud mais le code à taper en lui même est clean et très faible en quantité, le tout assez facile à appréhender apres quelques heures, même s'il manque de documentation actuellement (son principal défaut).
Sinon... Archetype JS marche bien aussi ds le genre MVC objet, il nécéssite juste une couche de transport comme DWR pour l'accès couche métier côté serveur.
[^] # Re: PHP/Perl/Ruby
Posté par Moogle . Évalué à 2.
C'est un peu ce qui m'a fait switcher de Cake vers Symfony : dans ce dernier, on utilise des objets, bien plus pratique niveau conception.
[^] # Re: PHP/Perl/Ruby
Posté par totof2000 . Évalué à 2.
Pas spécialement, la dernière fois que j'ai essayé ce genre d'outil en PHPn j'ai mis trop de temps à comprendre le fonctionnement de l'outil en lui même (je ne me rappelle plus lequel c'était d'ailleurs) et j'ai été assez vite rebuté. Ne pas oublier que je ne suis qu'un développeur amateur, et que le dev web à la base, ça me gave.
Je pense que PHP a un énorme avantage sur les 2 concurrents que tu cites : sa disponibilité par défaut sur les hébergements web
Certes je ne le nie pas, mais ça ne me sert pas, les applis que je développe sont sur des intranet pour usage interne.
Est-ce que tu as regardé un framework Perl comme Catalyst [1] ?
Non, tout simplement parce que perl n'est pas ce que je qualifierai un "vrai" langage objet. La notion de POO est très rudimentaire sous Perl, etautorise le dev à faire trop de choses crades ou non maintenable (je suis souvent le premier à écrire un truc à l'arrache, comme un porc, en me disant que je modifierai plus tard, sans jamais le faire ensuite par manque de temps ou de motivation). Perl permet également de faire trop de choses illisibles, et pour la maintenance c'est pas top. Mais par curiosité je jetterai un oeil à ce que tu m'indique histoire de comparer.
[^] # Re: PHP/Perl/Ruby
Posté par Nicolas (site web personnel) . Évalué à 1.
Je te conseille de tester symfony à travers le tutoriel askeet : http://www.symfony-project.org/askeet/1_0/en/
[^] # Re: PHP/Perl/Ruby
Posté par Adrien . Évalué à 8.
Perso je trouve que Ruby a un énorme avantage sur Perl et PHP : sa syntaxe.
Le langage Ruby est extrèmement clair, concis et puis les block en Ruby sont quand même vraiment super à utiliser !
Alors que Php possède une syntaxe ... lourde, on dirais du c, c'est un langage d'un autre temps face à Ruby.
# Bons livres
Posté par laurent laffont (site web personnel) . Évalué à 4.
[^] # Re: Bons livres
Posté par totof2000 . Évalué à 2.
Exactement, d'ou ma remarque sur le fait de bien apprendre les concepts élémentaires de Ruby.
# IRC, ML
Posté par fredix . Évalué à 2.
cf http://railsfrance.org/ et http://rubyfrance.org
[^] # Re: IRC, ML
Posté par Elghinn . Évalué à 1.
[^] # Re: IRC, ML
Posté par fredix . Évalué à 2.
# pour passer à la vitesse supérieure avec Rails
Posté par Dreammm . Évalué à 2.
850 pages, uniquement des références : ce n'est pas le livre pour le débutant, j'insiste bien. Mais une fois que tu as digéré le "Agile Web Development with Rails", c'est LE bouquin sur lequel foncer.
[^] # Re: pour passer à la vitesse supérieure avec Rails
Posté par totof2000 . Évalué à 2.
# jifty
Posté par Yves Agostini (site web personnel) . Évalué à 2.
j'ai un vieux screencast ici :
http://www.crium.univ-metz.fr/docs/devel/jifty/screencast.ht(...)
d'ailleurs jifty permet depuis longtemps de gérer les fuseaux horaires, les migrations partielles ou complètes de base et plein d'autres originalités ... et sera dans la prochaine debian
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.