Ruby on Rails
- Auteur de la discussion WRC Cobra
- Date de début
C'est un choix comme un autre, ruby à ses adeptes et semble avoir de bon échos, mais étant moi aussi spécialisé dans le dev PHP, j'aurais plutôt tendance à refuser vu que je ne connais pas ruby, je ne pourrais pas mettre facilement mes doigts dans le "cambouis" ce qui me gène fortement.
En plus n'ayant aucune compétence ruby, on se retrouvera plus ou moins lié avec cette agence, car les compétences ruby ne sont pas courantes (sans parler des hébergements)
En plus n'ayant aucune compétence ruby, on se retrouvera plus ou moins lié avec cette agence, car les compétences ruby ne sont pas courantes (sans parler des hébergements)
Ce qui me gêne c'est pas d'apprendre le ruby, ça me ferra un langage de plus, c'est plutôt que j'ai peur de ne pas trouver d'autres prestataires maitrisant le ruby si besoin.
En plus, ca fait des années que j'entends parler de nouveaux langages ou de frameworks "super" qui disparaissent rapidement.
En plus, ca fait des années que j'entends parler de nouveaux langages ou de frameworks "super" qui disparaissent rapidement.
Déjà, c'est Ruby on Rails, pas and 
Ensuite, RoR monte, cela m'étonnerait pas mal qu'il disparaisse sous peu.
Après, connaitre la syntaxe de RoR, ce n'est que la face visible de l'iceberg. La force de RoR, c'est surtout son architecture (basée sur MVC) et son principe : pas de configuration que de la déduction.
Après, si tu ne veut pas apprendre de nouveau langage, il y a CakePHP qui est à l'origine un clone de RoR en php (à l'origine car maintenant, les deux commencent à évoluer légèrement différemment).
Ensuite, RoR monte, cela m'étonnerait pas mal qu'il disparaisse sous peu.
Après, connaitre la syntaxe de RoR, ce n'est que la face visible de l'iceberg. La force de RoR, c'est surtout son architecture (basée sur MVC) et son principe : pas de configuration que de la déduction.
Après, si tu ne veut pas apprendre de nouveau langage, il y a CakePHP qui est à l'origine un clone de RoR en php (à l'origine car maintenant, les deux commencent à évoluer légèrement différemment).
Perso, je ne suis pas trop pour une nouvelle ligne dans le CV, les différents langages de j'utilise sont déjà suffisamment complet savoir qu'il me reste encore beaucoup de choses à voir (parfois cela ne sert a rien de s'éparpiller)
Pour ma part, même si rubi à bonne presse, PHP à une avance indécente, et j'ai de gros doute sur rubi niveau concurrentiel.
Je pense que pour un soucis d'évolutivité et de maintenance, qu'il faille préférer PHP
Pour ma part, même si rubi à bonne presse, PHP à une avance indécente, et j'ai de gros doute sur rubi niveau concurrentiel.
Je pense que pour un soucis d'évolutivité et de maintenance, qu'il faille préférer PHP
Le problème énorme de PHP, c'est qu'il est beaucoup trop simple d'accès.
Cela peut paraitre être un avantage au premier abord.
Cependant une entreprise qui travaille avec JE22/Spring, Ruby on Rails ou toute autre technologie "de pointe" passera pour beaucoup professionnelle qu'une qui travaille en PHP, et qui peut très bien développer de manière absolument affreuse.
L'avantage de ces langages, en plus d'apporter de la rigueur et de la propreté au code est qu'ils montrent au client dès la présentation du projet que les développeurs ne sont pas des branquignoles.
Cela peut paraitre être un avantage au premier abord.
Cependant une entreprise qui travaille avec JE22/Spring, Ruby on Rails ou toute autre technologie "de pointe" passera pour beaucoup professionnelle qu'une qui travaille en PHP, et qui peut très bien développer de manière absolument affreuse.
L'avantage de ces langages, en plus d'apporter de la rigueur et de la propreté au code est qu'ils montrent au client dès la présentation du projet que les développeurs ne sont pas des branquignoles.
Je viens d'être embauché par une entreprise qui travaille avec JE22, .net, websphere, webdev... et pourtant, ces langages la je ne les connais pas (enfin, j'ai effleuré un peu .net par curiosité), ils m'ont bien pris pour ma spécialité : PHP.
Enfin de toute façon on peut coder de manière affreuse dans tous les langages de programmation, c'est pas parce que tu codes en JE22 que tu feras un code plus propre.
PHP trop simple d'accès, oui et non, cela dépend à quel niveau tu l'utilises, et cela tu le retrouve dans tous les langages aussi
Enfin de toute façon on peut coder de manière affreuse dans tous les langages de programmation, c'est pas parce que tu codes en JE22 que tu feras un code plus propre.
PHP trop simple d'accès, oui et non, cela dépend à quel niveau tu l'utilises, et cela tu le retrouve dans tous les langages aussi
je ne vois pas le rapport. J'ai vu nombre de développements en langage objet (java ou php5) qui étaient codés comme des gorets.kazhar a dit:
La technologie ne fait pas tout, de même qu'avoir des frameworks qui prennent tout en main. Si derrière l'algorithme créé est bancal, ça donnera du code de m...
Après, qu'on utilise ça comme argument commercial pour abuser le client c'est une autre histoire.
apprendre à coder propre, ce n'est pas une histoire de langage objet ou procédural et quelque soit le langage, une astraction complète est quasi impossible, le MVC pur n'existe pas ou peu, dès que l'on commence à rentrer dans du réellement opérationnel, sauf à faire une vrai usine à gaz avec 3 fois trop de lignes de codes, qui en plus, ne seront même pas aisément maintenables :cry:
chuuutWRC Cobra a dit:
En fait, ça permet :
1) de montrer (faire croire) au client qu'on est en avance sur les concurrents et si on ajoute "j'vous fais un vrai site web 2.0" là c'est le ponpon
2) comme peu de développeur travaillent sur ruby, on bloque la maintenance du site du client, car il aura du mal à trouver un concurrent qui maitrise, si tant est que nous on maitrise.
Bref beaucoup de buzz. En plus, il me semblait avoir vu il y a de nombreux mois un argumentaire comme quoi n'importe qui pouvait se créer un blog avec RoR en 10' sans le connaitre au préalable.
N'importe qui, donc pas un vrai langage de développeur :roll:
Pour te faire une vraie idée, il existe plein de tuto sur RoR tres simple a mettre en place, qui ont l'avantage de te présenter vite fais mais efficacement ce a quoi RoR ressemble. Une installation n'est pas tres compliqué à faire, ainsi que le test (meme pas besoin de disposer d'un serveur apache fonctionnel) la mise en production par contre c'est autre chose.WRC Cobra a dit:
Je te dis ca, parceque d'aprés moi rien ne faut un ptit test pour savoir de quoi l'on parle, et admirer la chose
Pour info ovh supporte RoR même sur les mutu, léopard l'inclus dans son sytéme, et plein d'autre language PHP, Perl ce risquent sur le même chemin.
Mon avis: de la technologie pour nous simplifier la vie, voila ce que c'est .
elie33 a dit:Pour te faire une vraie idée, il existe plein de tuto sur RoR tres simple a mettre en place, qui ont l'avantage de te présenter vite fais mais efficacement ce a quoi RoR ressemble. Une installation n'est pas tres compliqué à faire, ainsi que le test (meme pas besoin de disposer d'un serveur apache fonctionnel) la mise en production par contre c'est autre chose.
Je te dis ca, parceque d'aprés moi rien ne faut un ptit test pour savoir de quoi l'on parle, et admirer la chose
Pour info ovh supporte RoR même sur les mutu, léopard l'inclus dans son sytéme, et plein d'autre language PHP, Perl ce risquent sur le même chemin.
Mon avis: de la technologie pour nous simplifier la vie, voila ce que c'est .
J'ai déjà fait pas mal de recherche et j'en ai entendu beaucoup de bien.
Mais des tas de bonnes idées ne trouvent pas leur place.
Mon problème n'est pas de savoir si c'est bien mais si c'est un choix intéressant pour l'avenir et si ca n'est pas risqué pour une entreprise de faire ce choix.
Pour une agence web je vois l'intéret mais pour une PME ?
WRC Cobra a dit:
Bein je dirais qu'en temp de developpement le gain est important, que cela permet de ce concentrer plus facilement sur le but à atteindre que les moyens d'y arriver.
Dis toi que si jamais vous changez, pour une raison ou une autre, de sgbd, l'application reste fonctionnel, il y a une abstraction vraiment compléte à ce niveau.
Plein de bonne chose sont déja intégré dans le système, qui sont autent de choses en moins à coder.
Tu supprimmes aussi les requétes Sql de l'application sauf surement dans certains cas spécifique.
Je peut pas vous pousser à utiliser RoR si vous préférez PHP le choix vous appartient, je vais me repeter: fais un test, regarde, tu prends un tuto banal sur comment faire un formulaire en lecture ecriture modif recherche(CRUD), avec sgdb -> quand tu connais cinq minute au maximum, avec vérification que certain champ soit bien remplie avec un type et pas un autre, message d'erreur personnalisé , ca c'est le truc de base.
Tu te souviens de la premiere fois que tu as fais ca en php ?
Ok maintenant tu vas me dire que tu as créer tes propres modules similaire , et si un jour tu n'est plus de la boite, que quelqu'un doit prendre ta releve il fais comment ? bein j'espere que tu as soigneusement documenté ton module
EDIT: une derniere chose, pour etre négatif envers RoR, ce qui peut être chiant mais incontournable ce serais l'eclatement de fichier engnedré par un simple formulaire.
Niveau code, jviens de lire une reflexion assez bisarre juste en haut (qui tendrais a dire que si c'est pas compliqué c'est pas intéressant) il y a une trés simple analyse ici -> http://blog.nozav.org/post/2006/08/24/5 ... on-et-ruby
php n'est pas pris en compte je te laisse faire l'exercice :twisted:
A savoir que php c'est tellement bien codé qu'il n'existe aucune abastraction qui rox un tant soit peut, mysql_ étant tellement pourrie qu'il ont du créer mysqli_ et MDB2 n'est pas des plus apprécié comme module.
WRInaute accro
Ruby est tres certainement un des langages objet de demain, qui fait une percé fulgurante dans le monde de la programation d'apres le magazine Hivemind.
De l'aure coté de l'atlantique, Ruby prends des parts de marché au basic et au java. L'asp baisse et le php reste stable. De plus en plus d'entreprises travaillent avec Ruby, pas d'inquietude pour l'avenir de Ruby, il est devant lui!
De l'aure coté de l'atlantique, Ruby prends des parts de marché au basic et au java. L'asp baisse et le php reste stable. De plus en plus d'entreprises travaillent avec Ruby, pas d'inquietude pour l'avenir de Ruby, il est devant lui!
elie33 a dit:
Ce n'est pas parce que cela tient en une ligne que c'est simple.
Sur ton exemple, j'ai plutôt l'impression d'avoir un concours d'obfuscation.
J'exagère peut-être, mais quand je vois que l'auteur écrit Simple, lisible, compact, compréhensible (du moins si on a compris le concept de bloc et d'itérateur). En un mot : é-lé-gant., je me dis quil ne faut pas exagérer.
Compact, oui, c'est certain, mais la compacité pour la compacité, aucun intérêt.
L'expérience me prouve que plus un code est compact, moins il est maintenable.
Lisible et compréhensible, non : je préfère la version python (compréhensible alors que je ne connais pas ce langage, mais la structure est logique, et ne prend au final qu'une ligne de plus : la présentation du code correspondant montre un gros parti pris)
Quand à l'élégance, on s'en fout, le plus important est la lisibilité (dans le sens compréhension) et la maintenabilité.
Le reste, c'est du pipo.
Peut-être que ror est très bien, mais dans ce cas autant montrer des exemples intéressants et pas des trucs de ce genre.
WRInaute accro
le portail officiel de Ruby en France parle lui aussi d'elegance et de simplicité... "Sa syntaxe élégante en facilite la lecture et l'écriture"
Si tu as 20 minutes ?
http://www.ruby-lang.org/fr/documentation/quickstart/
Si tu as 20 minutes ?
http://www.ruby-lang.org/fr/documentation/quickstart/
KOogar a dit:
Merci pour le lien.
Je viens de regarder les différences ruby/c++/php
Ma conclusion : bof;
Pour commencer, je n'aime pas les langages qui s'amusent à redéfinir quelques conventions largement admises (remplacer this, changer les déldélimiteurs et les constructeurs des classes) : ça sert à quoi à part vouloir marquer son territoire?
La gestion des classes permettant d'ajouter des définitions quand l'envie nous en prend, c'est peut-être pratique, mais cela ne peut que nuire à la structure (et bonjour la maintenabilité du code)
Et d'autres petits détails qui ne me plaisent pas.
Les deux seuls points positifs qui sont intéresants (par rapport à php) sont les suivants :
-seuls false et nil s’évaluent à faux : 0, array(), "..." valent tous vrai dans les tests conditionnels ;
-chaînes de caractères, tableaux, hash, etc. tous sont des objets
-le typage est fort. Il faut utiliser des méthodes comme to_s, to_i pour faire les conversions de types
Sous php, ces contraintes ne sont pas là et cela peut poser de gros problèmes.
Ah, finalement cela fait trois :lol:
Tiens, je viens de lire En définitive, Ruby essaye de ne pas contraindre le programmeur.
Le problème, c'est que moins le programmeur à de contraintes, plus il fait n'importe quoi :lol:
salut tout le monde,
pour ceux qui utilisent Ruby on rails comme framework de développement:
je voulais savoir qu est ce qui est l equivalent du javabean dans ROR,ou plutot comment on modélise la couche métier dans une application Rails,les business class outre les ActiveRecord qui sont très fortement liés à la base de données.merci d avance
pour ceux qui utilisent Ruby on rails comme framework de développement:
je voulais savoir qu est ce qui est l equivalent du javabean dans ROR,ou plutot comment on modélise la couche métier dans une application Rails,les business class outre les ActiveRecord qui sont très fortement liés à la base de données.merci d avance
RoR est basé sur le principe de MVC.
http://fr.wikipedia.org/wiki/MVC
Ainsi, ta couche métier base de données sera ton modèle.
Ta couche utilisateur sera la vue, et le contrôleur fait l'interface entre les deux.
Les ActiveRecords permettant de manipuler la base de données sont situées dans les modèles.
Un modèle par base evidemment. Mais cela doit être similaire en java.
http://fr.wikipedia.org/wiki/MVC
Ainsi, ta couche métier base de données sera ton modèle.
Ta couche utilisateur sera la vue, et le contrôleur fait l'interface entre les deux.
Les ActiveRecords permettant de manipuler la base de données sont situées dans les modèles.
Un modèle par base evidemment. Mais cela doit être similaire en java.
y a pas que ROR dans la vie
Il existe d'autre framwork ruby tout aussi bien voir mieux.
Merb n'en mérite pas moins le détour, toujours MVC of course, toujours en Ruby, mais en plus rapide. Choix de l'ORM (AR, DM, Sequel) J'en regrette qu'il n'y ai pas une comuneautée fr.
.
C'est définitivement le choix que j'ai fais, (moins grande consommation de mémoire etc).
On me l'as déjà sortie le coup du "piège à utilisateurs", woué... ça faut ce que ça faut, peanuts, même si c'est potentiellement vrai, avec ce genre de résonnement on évolue plus. Avant le php y avais que html, personne n'a crié au loup quand on est passé du cgi à php et ainsi de suite.
PHP t'est moche et t'est pas beau, il faut des années pour bien arriver à te maîtriser. Tes lib sont mince et pas belle elles aussi . Quid de facets ? Quid de rmagick ?
Prenez deux modules faisant le même chose et .... lisez le, utilisez le. Alors on est pas bien là, détendu du gland ?
On vas sur, par exemple developpez.net et on compare les section php et ruby, y en a un qu'est plus limpide avec plus de [résolu] ! Même les forums y gagne en clarté \o/
Il existe d'autre framwork ruby tout aussi bien voir mieux.
Merb n'en mérite pas moins le détour, toujours MVC of course, toujours en Ruby, mais en plus rapide. Choix de l'ORM (AR, DM, Sequel) J'en regrette qu'il n'y ai pas une comuneautée fr.
.
C'est définitivement le choix que j'ai fais, (moins grande consommation de mémoire etc).
On me l'as déjà sortie le coup du "piège à utilisateurs", woué... ça faut ce que ça faut, peanuts, même si c'est potentiellement vrai, avec ce genre de résonnement on évolue plus. Avant le php y avais que html, personne n'a crié au loup quand on est passé du cgi à php et ainsi de suite.
PHP t'est moche et t'est pas beau, il faut des années pour bien arriver à te maîtriser. Tes lib sont mince et pas belle elles aussi . Quid de facets ? Quid de rmagick ?
Prenez deux modules faisant le même chose et .... lisez le, utilisez le. Alors on est pas bien là, détendu du gland ?
On vas sur, par exemple developpez.net et on compare les section php et ruby, y en a un qu'est plus limpide avec plus de [résolu] ! Même les forums y gagne en clarté \o/
kazhar a dit:
oui c'est vrai que la couche métier est bien évidament représenté par les modèles ou bien par les composants Active Record mais le problème c'est que par convention dans ruby on rails les modèles vont être mappé avec les tables (et inversement) et moi je veux développer des simples classes métiers indépendament de la base de données. merci
Il y a les plugins pour cela.
http://wiki.rubyonrails.org/rails/pages/Plugins
http://wiki.rubyonrails.org/rails/pages/Plugins
Discussions similaires