Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Choisir ROR pour débuter
Bonjour,
Évidemment si vous êtes ici c'est que vous êtes un défenseur de ROR mais je cherche malgré tout des retours d'expérience.
Je dois créer une WebApp rapidement mais je pars de zéro, je ne connais rien au développement Web, pensez vous que le choix de ROR est un bon choix dans ces conditions ?
Merci par avance pour vos avis.
Bonjour,
Rails est un bon choix pour le développement Web et permet d'atteindre des taux de productivité imbattables. Mais il demande un investissement assez important en programmation pour dépasser le stade du blog écrit en 15 minutes:
Ne pas avoir peur de la programmation orientée objet (Ruby)
Ne pas être effrayé par le paradigme modèle-vue-contrôleur
Donc si tu ne connais pas de langage de programmation objet (type Java), cela peut être assez dur pour aller au delà des exemples classiques. Un non développeur aura peut être intérêt à commencer avec PHP.
Côme
Bonjour,
Justement le coté MVC me plait bien, plutôt que d'avoir du script php qui contient tout en un bloc.
Donc pour toi la logique veut plutôt qu'on passe d'abord par php puis qu'on aille vers ror, au risque sinon d'être perdu.
A ton avis, en partant de zéro, ne connaissant aucun langage de programmation en particulier, juste la logique, combien de temps est nécessaire pour maitriser ror ? pour maitriser php ?
Merci
p.s : côme ça me dit qq chose, à mon avis on se connait ...
Possible... Un indice peut être ? Parce que patic est moins évocateur ;-)Envoyé par patic
Non, pour répondre à ta question, on peut très bien commencer directement par Rails. Au contraire. D'ailleurs, je n'ai moi-même jamais vraiment développé en PHP. Seulement il faut savoir que le "ticket d'entrée" est un peu plus cher qu'il n'y paraît au premier abord: Beaucoup commencent avec les nombreux exemples (blogs, ...) bille en tête et s'aperçoivent rapidement qu'ils sont coincés pour aller plus loin.
MVC n'est effectivement pas compliqué, c'est une façon d'organiser son développement qui est plus propre, comme tu l'indiques.
PHP est un langage. Rails est un framework (cadre de développement auquel on doit se conformer). Le langage de Rails est Ruby. Pour développer des sites complexes, il est intéressant de bien maîtriser Rails, mais cela n'implique pas forcément de maîtriser Ruby. Il faut trouver le juste équilibre. D'autant que Ruby est très simple à apprendre mais difficile à maîtriser.
Entre PHP et Rails, difficile à dire. Je dirais que les courbes d'apprentissage se croisent plusieurs fois. On arrive plus rapidement à quelque chose avec Rails si l'on développe un site orienté "base de données". En revanche, pour un site sans base, le résultat sera tout aussi rapide, voire plus rapide avec PHP. Pour dépasser le premier cap, PHP reprend l'avantage car on doit "perdre" un peu plus de temps avec Rails.
Au delà, c'est Rails qui repasse devant, au fur et à mesure que le site devient plus complexe car il intègre nativement plusieurs facilités pour des sites plus importants :
- L'organisation MVC qui facilite la maintenance du code,
- Les aspects "orienté objet" et la programmation dynamique pour la "rentabilité" du code (des résultats obtenus avec moins de lignes de code).
- Les aspects TDD (Test Driven Development) ou BDD (Behaviore Driven Development), qui viennent fiabiliser le code développé.
Quelle est ta spécialité, si ce n'est la programmation ?
Côme
Disons que si tu es bien expert Paradox alors on se connait surement pour s'être croisé dans une société d'e-tourisme.
J'ai creusé un peu coté php, j'utiliserai bien sûr aussi un Framework et je suis tombé sur Cakephp qui à priori reprend les principe de ror mais en php, je me demande bien si je ne vais m'orienter par là.
Il s'agit d'une petite application, il y a quelques particularités mais rien de bien compliqué à mon avis, coté base de données j'ai un peu près le schéma en tête mais pour les ihm, la gestion des droits et une sorte de workflow je ne sais pas encore comment faire.
Je suis autodidacte, je n'ai aucune formation en informatique, j'apprends de moi même sur le terrain en fonction de mes besoins, en achetant des livres, en regardant sur internet et en essayant de comprendre le processus à partir du résultat. L'avantage majeure c'est que je suis tout autant coté métier que coté technique.
Je te remercie en tout cas pour ton avis, je pense que dans un premier temps je vais m'orienter vers php avec un framework qui reprend le principe mvc, j'ai l'impression que j'irai plus vite de ce coté là et puis question hébergement ce sera plus simple dans la cas présent. De plus apprendre php me servira à l'avenir c'est certain. Je n'abandonne pas cependant l'idée de m'intéresser à ror à l'avenir.
Merci
Alors nous ne nous connaissons pas et ce prénom n'est pas si rare que ça car je n'ai travaillé qu'en secteur banque / assurance et je ne connais paradox que de nom....
Dans ton cas, PHP est peut être un choix de prudence, bien que Rails est assurément plus fun. Alors bon courage pour ta création de site.
Et le framework de Zend ? Je ne connais pas CakePHP, mais Zend est déjà excellent...
Bonjour,
A priori Zend est bien plus éloigné de ROR que CakePhp, de plus il ne se comporte pas vraiment comme un vrai Framework mais plus comme une série de composant si j'ai bien compris ce que j'ai lu. J'arrête là car ce n'est de toute façon pas le bon forum pour discuter des choix sur un framework php.
J'ai commencé mon apprentissage de cakephp et effectivement il semble qu'il y ait beaucoup de similitude avec ror donc si je l'essaie plus tard j'aurai déjà des notions, cela me semble donc être un bon choix
J'en profite pour souligner à toutes personnes qui s'intéresserait à ROR un article dans le dernier magazine ici : http://magazine.developpez.com/
Merci pour votre avis
Le problème c'est que Rails devient se plus en plus complexe et lourd, depuis la 2.0 c'est devenu du grand n'importe quoi
Ca va finir comme J2EE....
=> aie...ca fait peur làCa va finir comme J2EE....
tu peux nous expliquer un peu ?Rails devient se plus en plus complexe et lourd, depuis la 2.0 c'est devenu du grand n'importe quoi
merci
C'est faux.Rails devient se plus en plus complexe et lourd, depuis la 2.0
Au contraire le Core a été diminué afin de ne laisser dans le noyau que l'essentiel, qui marche bien et qui est fiable.
La plupart des fonctionnalités ont été dégagées, et on les retrouve sous forme de plugins.
exemple : "paginate" qui permet d'afficher les résultats sur plusieurs pages, était natif dans Rails 1.x et n'existe plus depuis 2.x.
Aussi depuis la 2.x et l'implémentation de Restful, les conventions sont devenues bien plus strictes.
Le "grand n'importe quoi", ou plutot là où ça commence à devenir complexe ça vient surtout :
- Du codeur : La façon de coder, le respect des conventions, le Railsway, Restful,...
- Des plugin : Un plugin douteux qui marche aujourd'hui et qui ne marchera plus demain, l'installation de 10000 plugins,...
- Lorsqu'on recoure à Java, et qu'on n'a pas l'habitude.
- Aussi parceque certains codent sous Windows, d'autres sous Linux et d'autres sous Macos, et qu'on se retrouve avec des accents pourris de partout
Sur les forums, on ne précise pas l'OS et les questions n'ont pas les memes réponses suivant les cas...
- Parceque Rails est tellement souple, qu'on a vite fait d'aller hacker le framework, et que ca provoque souvent des difficultés plus tard...
merci fred pour cette intervention rassurante.
cela dit, si on peut remplacer "depuis la 2.0 c'est du grand n'importe quoi" par un "depuis la 2.0 c'est + complexe"...
alors il faut bien admettre que kedare a un point ici
car au final la complexité se paie tjs
par le nouveau mainteneur qui s'y casse les dents plus longtemps
par le codeur ruby qui passe + de temps à se former aux nouveaux trucs,
par la communauté du IT qui continue à voir ruby et RoR comme qqch de pas encore mature (trop de changements...)
etc...
non ?
Hello,
Ou plutot :on peut remplacer "depuis la 2.0 c'est du grand n'importe quoi" par un "depuis la 2.0 c'est + complexe"...
Ca devient plus complexe parcequ'il y a de plus en plus de gens qui l'utilisent.
Et que la plupart des gens s'en foutent des conventions, ne prennent pas le temps de comprendre ce qu'ils font, ne pensent pas aux autres...
Et comme Rails est trés souple, il est possible de faire ce qu'on veut assez facilement.
Le probleme ne vient pas du langage, mais de ceux qui l'utilisent comme des cochons.le nouveau mainteneur qui s'y casse les dents plus longtemps
Et c'est vrai quelquesoit le langage, quelquesoit le métier,...
Le codeur n'est pas obligé d'installer 10000 plugin, d'avoir recours à Java pour faire une opération qui est native en Ruby, d'installer toutes les gems,...le codeur ruby qui passe + de temps à se former aux nouveaux trucs
Je pense que c'est lié à l'hébergement, plutôt.la communauté du IT qui continue à voir ruby et RoR comme qqch de pas encore mature
Zfed ==> on est d'accord pour l'hebergement
cela dit, ne jetons pas la pierre aux admins. apres tout, c'est d'abord ca leur job : faire en sorte que ca continue à marcher. donc necessairement ca tres conservateur
@kedare...
je voudrais bien que tu nous détailles ton point de vue sur
et si tu confirmes les interventions de zfredLe problème c'est que Rails devient se plus en plus complexe et lourd, depuis la 2.0 c'est devenu du grand n'importe quoi
Ca va finir comme J2EE....
Bonjour,
Sincèrement à lire vos dernières discussions cela ne va beaucoup motiver un débutant à se lancer. C'est moi qui ait lancer ce message au début, si j'avais lu cela je n'aurais pas pris plus d'une seconde pour me rediriger vers une autre technologie. Je ne connais pas ROR car je me suis finalement diriger vers php avec le framework cakephp, la seule chose que je puisse dire c'est que les conventions n'ont rien de mauvais, cela permet d'uniformiser et surtout lorsqu'on s'aperçoit par la suite que cela nous permet de développer automatiquement tout le code de base de l'application (avec la console sous cake) on est bien content de s'être attarder qq minutes sur les conventions. J'imagine que c'est pareil sous ROR car apparemment on dit que cake est le portage de ror sous php.
Bref, je crois que plutôt de descendre complètement un produit vous pourriez peut être faire part de vos retours à l'équipe qui gère le projet, et tenter d'encourager d'autres personnes à s'y intéresser.
bonjour patic,
en habitué de php, j'entends parler de ruby en TRES bien et depuis un bail.
Je ne me suis plongé dedans que recemment.
je dois avouer que j'ai trouvé ruby et surtout ror tres convaincant. simple, compact et efficace. oui vraiment j'ai adoré le fait d'avoir à la fois grande compacité et grande lisibilité.
par contre, je trouve la learning curve assez dure pour etre honnete. Enfin disons que c'est trompeur. Au début c'est séduisant et rapide pour faire des trucs simples. mais rapidement on se retrouve coincé sur des trucs qu'on arrive pas à faire comme on veut.
en comparaison en php, je pense que ca avance un peu moins vite au début, puis rapidement on arrive à faire un tas de trucs. Mais ca devient tres vite dégueulasse, difficile à maintenir + pbs de vulnérabilité/securité qu'on a du mal à comprendre alors que "ca marche"
par contre coté ror la plupart de ces pb bas-niveau sont déjà pris en charge :
* le autenticity-token dans les forms
* la protection contre l'injection sql et la facilité à changer de moteur
* le ajax les doigts dans le nez
* idem pour le rss ou xml
je pense que je recommanderais Ror sur php à un débutant, sous réserve que ce ne soit pas non plus une 1ere expérience en programmation (dans ce dernier cas, ce serait pe trop d'un coup par contre)
+1 pour ror
Bonjour fourchette,
Cela fait déjà plusieurs semaines que je me suis à la lecture de documents sur php et cakephp, ce n'est pas facile quand on commence de rien, car en même temps je dois comprendre le html ou plutôt le xhtml si j'ai bien compris, le css et le javascript. Tout ça en plus de la poo (là j'avais déjà compris le concept), de php 5 et du framework cake, en bref c'est la galère mais je commence à voir la surface. Je ne peux plus aujourd'hui faire marche arrière et changer de technologie mais je pense tenter l'aventure ror une prochaine fois, à moins que je mette à java.
Merci pour ton avis.
RoR : les gros couteaux suisses qui prennent trop de place dans une poche.
Je pense que si Ruby n'existait pas, aujourd'hui on aurait peut-être un autre Framework similaire à Django développé sous Python par DHH.
Quand on commence à écrire du Ruby, ça change complétement d'esprit et de syntaxe surtout quand on vient de chez PHP.
Pour moi Ruby est un des rares languages qui utilise le minimum de syntaxe pour une opération ou une procédure, c'est la puissance de l'Objet.
Après, tout dépend de ce qu'on va faire avec. L'idéal sera de choisir le language de programmation ou bien le framwork en fonction du projet. Mais comme il est difficile de maitriser tout ce qui existe sur le marché et l'opensource. On n'a pas le choix.
Revenant à Rails, on est toujours surpris par la rapidité de monter de simples applications ABC sous RoR, on commence à tout Scaffolder, puit on commence à modifier les vues.
Dans un second temps, "script/plugin" devient un raccourci sur le clavier
Après on se rend compte qu'il faut placer ces méthodes et procédure dans le Modèle plutot que dans le Controlleur ou les Helpers. On devient un partisan du DRY et on factorise au max avec les Partial.
Peu de temps après on tombe de nouveau amoureux du Terminal avec Rake, Capistrano et Git.
Je dirais que Rails ressemble à un Manuel de Jeu d'Echec concernant les ouvertures et les variantes. On commence à cerner les problèmes qui reviennent souvent sur le terrain. Afin de se concentrer sur les nouveaux cas jamais traités et le coeur de l'application.
Ca devient une fabrication en serie d'applications.
On analyse le cahier de charge, on prend notre temps pour dessiner les interfaces, l'intéractivité, l'ergonomie. On définie les Classes, la Structure de Base de données, on Choisie les plugins à utiliser. On crée l'application avec un template. Après en cours de route si on s'est planté sur l'architecture, les modifications sont très rapide à effectuer sans altérer la structure générale de l'application... la puissance du MVC.
La courbe d'apprentissage de Rails pour moi était rapide au début. Par la suite je me suis rendu compte qu'il fallait apprendre Ruby en profondeur pour simplifier le code sous Rails. Peu de temps après, je me suis mis à analyser le code des application RoR opensource. Et là !, on découvre un autre monde : Bienvenue chez Matrix. Je reprends mes livres et PDF pour réviser ActiveRecord... Avec Rails et Ruby, on se retrouve toujours à se remettre en cause à corriger ces mauvaises habitudes
Avec n'importe quel niveau en POO, avec Rails on peut rapidement achever une application sans soucis. Par contre avec de bonnes connaissances de Ruby, des Design Patterns, le développement sera plus rapide sans surprises, avec un minimum de Bugs.
On passe plus de temps par la suite à chercher des solutions plus simples, flexibles, afin de les replacer dans des futurs cas similaires.
C'est ce qu'il y a de plus difficile, c'est trouver la simplicité.
Si aujourd'hui je commence à m'interesser à MERB et à SINATRA comme d'autres personnes issues de Rails, c'est qu'on se rend compte qu'il y a beaucoup plus de 32 pièces sur l'échiquier et que ce dernier comprend bien plus que 64 cases.
Je pense qu'une application sous Rails en moyenne utilise 10% de ce que peut offrir l'architecture de Rails.
Le fait que les communautés anglophones sont plus actifs sous Ruby et Rails, m'a permit d'améliorer mon anglais, et de faire la découverte chaque jour de nouvelles idées, de nouvelles technologies . Rien à avoir avec la cadence du monde de développement francophone.
De l'autre coté de l'atlantique on s'interesse plus aux solutions de développement, à la durée et cycle de vie d'applications, des tests de controle, sécurité,...etc...
Malheureusement dans l'hexagone, la plupart des boites de développement, on du mal à quitter leurs vieilles habitudes et de penser à d'autre chose que le code de l'application.
Je pense que le sentiment de Kedare sur la complexification de Rails vient de son changement de philosophie.
Jusqu'a présent Rails c'était des choix pour chaque chose (l'ORM avec Active Record par exemple) ce qui déchargeait complètement le développeur de ce choix (hormis cas très particuliers).
Bref, un fonctionnement très simple : si je veux faire ça, c'est comme ça (ou presque)
Aujourd'hui, Rails intègre la philosophie de Merb (pour la future fusion) qui est son opposé : On a un core minimaliste, puis chacun fait ses courses de ce qu'il souhaite utiliser.
Toutefois, cela est fait en conservant la philosophie initiale. Il sera toujours possible de laisser a Rails le soin de faire les choix pour nous où de sélectionner les outils avec lesquels on se sent bien (Datamapper par exemple à la place d'ActiveRecord).
Si effectivement la philosophie Merb fait très Java, ce principe de dire, soit vous laissez Rails choisir, soit vous choisissez vos outils préférés rend le tout extrèmement souple sans pour autant complexifier les choses.
Enfin
Sisi, de plus en plusMalheureusement dans l'hexagone, la plupart des boites de développement, on du mal à quitter leurs vieilles habitudes et de penser à d'autre chose que le code de l'application.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager