Le développement qui a duré une année a permis l'ajout de nombreuses fonctionnalités, la résolution de beaucoup de bugs, une orientation tournée vers le REST, et pas mal d'allégements au niveau du core (externalisation de fonctionnalités en greffons).
DHH, le créateur du framework Ruby on Rails, a commenté ces nouveautés lors de Paris on Rails. Pour les absents, des slides et/ou des podcasts des présentations devraient être mis en ligne prochainement. Ressources et webservices
Rails a tranché dans le débat REST - SOAP au profit du REST.
Le module ActionWebservice a été sorti du core et placé en greffon pour ceux qui veulent continuer à utiliser du SOAP. ActiveResource est le nouveau module qui est similaire à ActiveRecord mais avec une approche ressource.
Au passage, l'url des ressources a été modifié, l'utilisation du point virgule ( ; ) pour séparer l'action de la ressource a été remplacé par un slash ( / ), à cause de navigateurs et bibliothèques HTTP qui ne le supportaient pas en tant que séparateur de requêtes.
Multi-vues
Rails 2.0 sépare le format du template (html, xml, atom, rss, ...) du moteur de rendu. Le template show.rhtml devient donc show.html.erb (ERB étant le moteur de rendu par défaut).
D'autres moteurs de rendus existent aussi, builder utilisé pour générer du atom+xml, et HAML principalement utilisé aujourd'hui pour générer des templates adapté à l'iPhone.
Identification des records
On avait l'habitude en version 1.2.X d'utiliser person_url ou person_path pour générer des URLs du record person, il est plus facile avec Rails 2.0 de gérer les redirections ou les liens:
# person est une instance de la classe Person,
# qui sera mappé en person_url
redirect_to(person)
link_to(person.name, person)
form_for(person)
Authentification HTTP
L'authentification basique HTTP est maintenant supportée, ce qui permet facilement de sécuriser efficacement les appels d'APIs
Javascript, CSS et images
Il est plus facile en tant que développeur de séparer ses fichiers javascripts ou CSS en plusieurs parties logiques que de maintenir un seul gros fichier. Mais cela génère du coup un surcoût au niveau HTTP car cela génère des requêtes de beaucoup de fichiers.
Il est maintenant possible de mettre en cache ses fichiers javascript et CSS en un seul fichier en production, tout en les gardant séparés pour le développement.
Pour augmenter le nombre de connexions conccurrentes, il est possible de spécifier dans les fichiers de configuration des adresses de serveurs qui hébergeront les fichiers statiques :
ActionController::Base.asset_host = “assets%d.example.com”
Sécurité
Rails 2.0 embarque un mécanisme interne pour contrer les attaques CSRF sur les formulaires et les appels AJAX.
De même pour les attaques XSS, la méthode sanitize qui utilisait une blacklist pour fonctionner, ce qui compliquait la tâche pour la mise à jour de cette liste, utilise dorénavant une whitelist qui garantira une meilleure protection.
Gestion des exceptions
En plus de pouvoir gérer les exceptions par action (par un bloc rescue), une nouvelle macro rescue_from permet de capter toutes les exceptions d'un certain type de manière globale aux controllers.
Session basée sur les cookies
Les sessions ne sont plus stockées par défaut sur le système de fichiers du serveur web mais au niveau du client sous une forme qui ne peut pas être forgée. En revanche, le contenu sera visible, donc ce mécanisme de stockage de sessions n'est pas adapté si vous avez besoin d'y stocker une information que ne doit pas voir l'utilisateur.
Profileur de requêtes
Pour détecter les points de contention de votre application, il est possible grâce à un nouveau script de générer un rapport qui détaillera tout cela (script/performance/request)
Performance
La plus grosse avancée au niveau des performances se situe au niveau du cache introduit directement dans l'ActiveRecord, ce qui permet de mettre en cache des requêtes SELECT similaires qui permettra d'éviter des requêtes inutiles sur la base de données.
Les fixtures ont été grandement améliorées, on parle de gain pouvant atteindre 100 à 200%.
Beaucoup de chose dans le core de Rails ont été externalisés en greffon (tous les acts_as_*, in_place_editor, autocomplete_for, paginate, ...), ce qui allège considérablement le core et permet de charger uniquement ce qui est nécessaire.
Migrations plus sexy
Un nouveau format, plus efficace et moins verbeux a été mis en place :
Avant
create_table :people do |t|
t.column, "account_id", :integer
t.column, "first_name", :string, :null => false
t.column, "last_name", :string, :null => false
t.column, "description", :text
t.column, "created_at", :datetime
t.column, "updated_at", :datetime
end
Après
create_table :people do |t|
t.integer :account_id
t.string :first_name, :last_name, :null => false
t.text :description
t.timestamps
end
XML en entrée, JSON pour la sortie
Il existe maintenant la désérialisation en XML et la sérialisation en JSON.
Le debuggueur de retour !
Grâce au paquet (gem) ruby-debug, il suffit de placer le mot clé debugger quelque part dans le code et de lancer le serveur avec l'option -u pour bénéficier d'un point d'arrêt directement dans le terminal exécutant le serveur, avec possibilité de retour arrière, lister les variables...
Comment installer Rails 2.0
Pour installer Rails, il est plus facile de passer par la commande gem (installateur de paquets ruby) :
gem install rails
Ca marche aussi pour la mise à jour, mais pensez bien à installer les greffons qui ont été éjectés du core et que vous utilisez !
Aller plus loin
- Ruby on Rails (24 clics)
- Architecture REST (27 clics)
- Blog de Ruby on Rails (26 clics)
- Rails 2 Upgrade Notes (41 clics)
- Summary of Major Rails 2 Features (22 clics)
- Ruby on Rails sur dmoz (29 clics)
# Célèbre ?
Posté par IsNotGood . Évalué à -3.
Je ne le connais pas, j'imagine que beaucoup beaucoup de gens ne l'a pas utilisé ni le connait.
Perl, php, python, java doivent être plus "célèbre".
NB : Je ne remet en rien en cause les mérites de Ruby (que j'ignore totalement ; oui, c'est de ma faute).
[^] # Re: Célèbre ?
Posté par Nicolas Blanco (site web personnel) . Évalué à 6.
Bon, encore un qui mélange Framework et langage !
Perl c'est un langage, PHP un langage, Java un langage.
Ruby c'est un langage et Rails un framework Web 2 basé sur Ruby.
Et pour ta non connaissance de Rails, sûrement tu n'es pas développeur ou alors tu t'intéresses pas aux actualités... Mais je te confirme : oui, Rails est - devenu en quelques années - le plus célèbre des frameworks Web, bien loin devant ceux en PHP par exemple. Recherche le nombre de livres traitant de Rails sur amazon.com tu verras (doit bien y avoir quelques dizaines).
Ayant essayé de nombreux frameworks Web, Ruby on Rails est celui qui m'a le plus branché, et celui que je conseille à tous les développeurs Web. Ruby est très facile à appréhender, très lisible, et les automatismes de Rails font qu'il est possible de se lancer dans le développement d'un site Web avec un potentiel "fun" énorme.
Rails ne serait jamais devenu incontournable sans son énorme communauté de passionnés qui ont développé des centaines de plugins et d'améliorations...
Pour parler de Rails 2 il s'agit moins d'une révolution, mais d'une très belle évolution et maturation. Le coeur du projet a bien été nettoyé des fonctions non essentielles qui ont été éclatées sous forme de plugins optionnels.
[^] # Re: Célèbre ?
Posté par EppO (site web personnel) . Évalué à 3.
Pour les modules du core qui ont été replacés en plugins, j'ai oublié de mentionner les connecteurs de bases de données: tous les connecteurs de bases de données autre que MysSQL, PosgreSQL ou sqlite ont été mis en plugin (ce qui facilite l'ajout de nouveaux connecteurs car il est plus facile de proposer un plugin qu'un patch sur le core de rails)
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 3.
C'est surement un tres bon framework pour le web, mais je l'ai connu apres avoir entendu parler d'autre framework pour PHP (vu que c'est le language que je pratique).
Mais effectivement Rails est précurseur pour beaucoup de choses et est une sorte de réference.
Pour ce qui est de son incontournabilité, je serais beaucoup plus mitigé ! Déja il faut vouloir faire du Ruby. Il font donc se taper la syntaxe du ruby, a laquelle perso je n'accroche mais alors pour pas un sous, il faut aussi ensuite trouvé un hebergeur qui accepte Ruby, et enfin il faut accroché au mode de fonctionnement de Rails.
Donc pour se lancer dans un projet web je prefere largement resté sur un PHP avec un Framework qui me plait.
Dernier point, toutes ces techno sont tres jeunes, on sort a peine la version 2 de RoR et c'est a peu pres parreil dans les autre language, les framework de ce style sont tous tres jeunes, donc a mon avis il faudrat de nombreuse années avant que ces techno prenne pied chez la majorité des developpeurs.
[^] # Re: Célèbre ?
Posté par zerchauve . Évalué à 5.
sinon pour l'histoire des hebergeurs c'est à la fois pas vrai et surtout pas bien grave, Rails et Ruby ne sont pas là pour remplacer les 25 lignes de "colles" en PHP qu'il y a sur beaucoup de sites (c'est pas forcément une critique pour php hein, ca a son utilité)
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 8.
Ou ai-je dit que Ruby etait chiant ?, j'ai dit que j'accorchai pas.
Pour les hebergeurs, c'est une constatation toute simple, j'ai fait le tour des differents lien que j'avais qui proposais de l'hebergement (pas forcement gratuit) et j'en ai pas trouvé qui proposais, Ruby, j'ai donc cherché, et apparement y en a quelques uns mais ca reste tres marginal, on trouve apparement bien plus d'hebergement proposant Python que d'hebergement proposant Ruby.
Alors apres y a peut etre un truc que j'ai pas capté avec Ruby, et peut etre qu'il y a pas besoin de l'installé pour s'en servir, vu que tu semble dire que c'est pas bien grave ....
Apres donne moi un truc a faire et je suis sur que mes ligne de code seront bien plus moche si je le fait en Ruby que si je le fait en PHP. On peut tres bien faire quelque choses de tres propre en PHP, et on peu je suis sur faire quelque choses d'horrible en Ruby.
C'est pas pasque le succes de PHP fait qu'une grande majorité des débutant se lance dans PHP en bidouillant sans vraiment apprendre les bases et donc font des trucs à se faire suicider Rasmus avec son string qu'on peut en tirer des conclusions sur la qualité du language !
[^] # Re: Célèbre ?
Posté par zerchauve . Évalué à 1.
voir les frameworks genre CakePHP qui essayent de pomper Rails (au lieu d'etre originaux) ce me fait un peu de la peine tellement c'est affreux.
Quant a Rasmus, il a des tonnes de qualités, mais franchement (comme Rick Hunter) qu'est ce qu'il y connait aux applis web hein....
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 1.
Apres pour les framework PHP je dois te dire que perso je n'es jamais utilisé de framework sur un projet réel donc je ne me prononcerai pas sur eux, parreil je ne me suis pas plongé dans le code de Rails pour tout comprendre et pouvoir comparer avec ceux fait en PHP.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 9.
On peut aussi programmer proprement en C. Il n'est pas nécessaire de faire de la programmation object en utilisant toutes ses subtilités.
J'ai fait beaucoup de C, c'était propre. Je fais beaucoup de C++, c'est toujours propre. La "propreté", c'est le développeur qui la fait, la cultive. Par exemple, tu peux prendre le meilleur des languages, si tu choisis des noms de fonctions ou de variables comme une patate, ça va être moche.
M'enfin, un peu d'aide du language ne fait pas de mal.
[^] # Re: Célèbre ?
Posté par Erwan . Évalué à 2.
http://zestyping.livejournal.com/124503.html
Alors PHP, je l'utilise pour certains projets, ça a son utilité parfois, mais même quand tu programmes proprement tu peux tomber sur des aberrations qui peuvent rendent les bugs difficiles à identifier.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 0.
Le transtypage de PHP est tres puissant, mais il faut savoir ce qu'il fait pour éviter les erreurs.
Le gros soucis de PHP c'est que ce n'est pas un language de débutant, mais qu'il est utilisé en tant que tel !
Je ne connais pas assez le Ruby et je ne sais pas ce que fait quelque choses du genre :
machaine = "3"
monentier = machaine
mais du coup a j'imagine qu'il doit y avoir une methode spécifique la classe entier pour recuperer la valeur entiere contenu dans un string, un peu comme en Java ?
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 3.
C'est le contraire: un String sait se convertir en entier ou en flottant. Un nombre (et n'importe quel objet) sait se convertir en String, etc. Les méthodes standards s'appellent to_i (integer), to_f (float), to_s (string), etc.
Cette manière de faire est un peu plus propre, car ça signifie que quand tu programmes ta classe d'objet, il suffit de leur ajouter une méthode to_i, to_s, etc. selon tes besoins. Dans l'autre manière de faire, il faudrait créer un Integer.parseIntFromToto(Toto t) pour créer un entier à partir d'un Toto. Je préfère n'avoir à modifier que ma propre classe, et pouvoir appeler toto.to_i.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à -1.
Je trouve la méthode Java moins chiante perso.
La vrai question est : Est ce le type de destination qui doit connaitre la méthode de transtypage, ou le type de départ.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
C'est aussi une question de syntaxe. Si tu préfères faire "i = Fixnum.from_string(str)" au lieu de "i = str.to_i", pourquoi pas. Après, ça va produire des cas étranges. Par exemple si ton string contient un nombre très grand, au lieu d'obtenir un Fixnum tu vas obtenir un Bignum, ce qui est un peu surprenant quand tu écris Fixnum.from_string.
Je ne sais pas si c'est un débat très intéressant, mais je voudrais encore apporter un exemple dans lequel je pense que la solution de Ruby est plus élégante:
a = Catalogue.find(:all).to_a.reverse
Catalogue est un modèle de Rails (ActiveRecord). "find" renvoit un truc qui ressemble superficiellement à un Array, mais parfois on a besoin d'un vrai Array, d'où la conversion avec to_a.
Maintenant, suivant l'autre approche:
a = Array.from_active_record_model_query_result(Catalogue.find).reverse
Ok, le nom de méthode que j'ai choisi est peut-être artificiellement long, mais c'est pour souligner que tu as dû créer un constructeur dans Array qui est très spécifique. Ça ne fonctionne que sur le genre de trucs renvoyé par "ActiveRecord::Base#find".
Est-ce que ce constructeur de tableau a sa place dans Array, ou dans ActiveRecord ? Je pense que tu seras d'accord: c'est propre à ActiveRecord, ça ne doit pas être une méthode de Array.
On peut imaginer une solution intermédiaire, en faisant: ActiveRecord::Base.array_from_query_result( Catalogue.find(:all) ), mais bon, c'est encore plus laid.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à -1.
Apres je sais pas trop comment se débrouille Java enfait car il existe un methode toArray() dans les objet implementant List je crois.
Du coup j'ai l'impression qu'un hybride serait fait, tous les objets peuvent se transtyper en chaine (toString) ou en array (toArray) et apres pour les transtypage plus complexe on fait avec ca et une methode dans la classe d'arrivé.
[^] # Re: Célèbre ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Les classes en ruby sont extensibles au fur et à mesure de l'execution.
Donc il suffit de mettre :
class Integer
def to_toto
# Le code qui va bien
end
end
et tu peux appeller 42.to_toto
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 5.
Mouais... La logique, c'est surtout que ça été conçu par un guignol qui a trouvé intelligent d'avoir des conversions implicites dans tous les sens histoire de taper x au lieu de str(x).
[^] # Re: Célèbre ?
Posté par Gniarf . Évalué à 6.
c'est peut-être pas le langage qu'il faut changer, là.
[^] # Re: Célèbre ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à -1.
Je ne suis pas d'accord du tout. Pourquoi est-il interdit de demander si une pomme est égale à une orange ?
[^] # Re: Célèbre ?
Posté par Gniarf . Évalué à -1.
[^] # Re: Célèbre ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Moi ça me semble normal de dire qu'une pomme n'est pas égale à une orange. La comparaison me semble légitime, et devrait renvoyer toujours "faux".
De plus, si on admet qu'il n'est pas cohérent de comparer des objets de types différents, alors pourquoi PHP autorise ces comparaisons, et renvoie une réponse contre-intuitive ? Lorsque le programmeur fait n'importe quoi, un bon langage se doit de renvoyer une erreur.
[^] # Re: Célèbre ?
Posté par Gniarf . Évalué à 1.
sinon, "un langage strict se doit de renvoyer une erreur" je veux bien.
[^] # Re: Célèbre ?
Posté par Erwan . Évalué à 3.
Le vrai problème c'est que l'erreur est humaine, mais sans message d'erreur clair pour mettre le doigt dessus et réparer, ça peut devenir un enfer.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 1.
Perso le PHP demande beaucoup beaucoup plus de rigueur du fait de sa permissivité. Quand un language a un haut niveau de repport d'erreur on a tendance a se reposer sur lui, et du coup le jour ou il laisse passé un trucs qu'on avait pas prévu ben on est tout pantois.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 4.
Ah oui ça c'est l'argument qui tue : PHP est nul, mais comme on sait que PHP est nul on ne risque pas d'être surpris. Il respecte donc le Principle of Least Astonishment.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 2.
J'ai pas dit que c'etait forcement bien mais perso quand je code en PHP j'ai tendance a bien tout reverifier 15 fois, alors qu'en Java j'ai tendance a me reposer un peu plus sur le repport d'erreur. J'ai pas dit que c'etait foncierement bien. Mais je n'es jamais prétendu etre un bon programmeur.
En meme temps je fait du PHP donc du coup ca montre bien tout de suite a quel point je suis limité, car comme tu dit PHP est nul.
[^] # Re: Célèbre ?
Posté par Ontologia (site web personnel) . Évalué à 4.
Personnelement, étant assez tête en l'air, je préfère avoir un compilateur hyper chiant, qui ne m'autorise absolument aucun écart, aucun code "dangereux" et me garantit donc aucune surprise.
C'est la garantie de ne pas passer des heures à debugger des conneries.
Parce que passer 1 journée à debuguer un truc que j'ai écrit en moins d'une heure, ça m'est arrivé, et c'est très frustrant, sans compter qu'il faut faire avaler la pilule à ton chef, qui le prend pour de l'incompétence pur.
Les langages non typés ne me dérange pas, mais à condition qu'ils ne soient pas dynamiquement typés, hors PHP l'est :-(
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Célèbre ?
Posté par Bozo_le_clown . Évalué à 1.
C'est une vraie question .
[^] # Re: Célèbre ?
Posté par Ontologia (site web personnel) . Évalué à 5.
Oui, sauf que contraîrement à Ruby, PHP n'es pas totalement objet :
Tu n'as pas de type Block en Php, c'est à dire que tu ne peux pas (à ma connaissance) définir de blocs de contrôle dans la librairie du langage.
En ruby, comme en Smalltalk ou en Lisaac, times est une méthode d'un entier auquel tu passes un block, c'est à dire une fonction qui prend en argument un entier et exécute le code :
3.times do |it|
puts bonjour("petit canard")
puts it
end
C'est à mon avis un des principaux intérêt de Ruby.
(Après, et je peux pas m'en empêcher, ça va quand même beaucoup moins loin que Lisaac, mais ne crachons pas dans la soupe, c'est un très beau langage, et surtout une très bonne idée)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Célèbre ?
Posté par 태 (site web personnel) . Évalué à 3.
0 3 FOR i
"Petit canard" BONJOUR
i
NEXT
[^] # Re: Célèbre ?
Posté par totoro . Évalué à 2.
Je ne sais pas si c'est le meilleur mais RoR est clairement devenu un référence dans le monde des frameworks web, il paraît donc relativement logique de d'autres s'en inspire avec plus ou moins de bonheur
[^] # Re: Célèbre ?
Posté par Gniarf . Évalué à 1.
la bonne blague, RoR a également pompé sur ses prédécesseurs et a fait des choix classiques (patterns MVC, Active Records...), la seule originalité technique est le choix de Ruby
[^] # Re: Célèbre ?
Posté par zerchauve . Évalué à 3.
tu as deja regardé CakePHP pour comprendre ce que je veux dire par "pomper" ?
sinon effectivement AR et MVC sont vieux, mais je suis pas sur que quiconque ai jamais dit que Rails les avaient inventés.
Ce qui est mis en avant et (je pense) novateur c'est la convention qui prime sur la configuration. Un peu dictatorial mais bon, la philosophie est très Apple-ienne.
M'enfin je vais surement me prendre un bonne remarque Gniarfienne de merde derrière, du genre "pfffouaaa mais tu dis n'importe quoi ca pue etc..."
trolle bien.
[^] # Re: Célèbre ?
Posté par Gniarf . Évalué à 2.
> tu as deja regardé CakePHP pour comprendre ce que je veux dire par "pomper" ?
lui et les autres, merci. sinon, toi, ca va ?
> sinon effectivement AR et MVC sont vieux, mais je suis pas sur que quiconque ai jamais dit que Rails les avaient inventés.
> Ce qui est mis en avant et (je pense) novateur c'est la convention qui prime sur la configuration. Un peu dictatorial mais bon, la philosophie est très Apple-ienne.
quelques unes génantes ou plutôt définitivement trop alien mais bon on peut s'en sortir quand même. et puis sinon on peut toujours changer de crèmerie, il n'y a pas qu'Apple dans la vie.
ces conventions (enfin, celles qui ne me foutent pas des batons dans les roues) sont effectivement le gros apport par rapport à ce qui existait avant. oui, c'est un framework cohérent, bien foutu, j'avais trouvé. les réserves des trolleurs habituels (le clan J2EE et son "pouah, ca va pas monter en charge") ne m'ont pas spécialement inquiétées, ni même perturbées, en fait.
il est normal que les gens voulant reproduire avec d'autres langages comme PHP ou Python ce qu'ils ont apprecié dans RoR "pompent" ce côté conventions/séparation dans des répertoires bien rangés/tests/migrations/etc... : une dernière réussite qu'on ne remarque pas de prime abord est que RoR tient debout tout seul, contrairement à d'autres bidules pas livrés en un seul morceau, aux ressources très éparpillées, très disparates, à recoller soi-même avec du scotch sans jamais trop savoir si on a bien pris les bons morceaux et les bonnes versions
> M'enfin je vais surement me prendre un bonne remarque Gniarfienne de merde derrière, du genre "pfffouaaa mais tu dis n'importe quoi ca pue etc..."
toujours ce syndrôme de Tourette, c'est triste.
> trolle bien.
pfffouaaa mais tu dis n'importe quoi ca pue, voilà, j'espère que ça t'aura réchauffé le coeur.
[^] # Re: Célèbre ?
Posté par Nicolas Blanco (site web personnel) . Évalué à 4.
MWAHAHAHAHAhahahahah ! ça fait du bien une franche rigolade le soir. Nan t'es sérieux là ou c'est juste un méchant troll pas beau ?
Moi je pense juste que certains développeurs se sont trop attachés à la syntaxe C-style. Forcément, lorsqu'on fait que ça toute la journée on s'habitue et on trouve que les langages n'ayant pas ce style de syntaxe sont nuls (ou bien réservés aux newbies).
Moi aussi j'ai trouvé ça bizarre au début après des années de programmation PHP de voir des bouts de code ruby.
Au final c'est une question de goût. Certains développeurs se sont peut être tellement habitués à la syntaxe C qu'ils ne pourront jamais se faire à Ruby.
Mais la question est : quelle personne n'ayant jamais fait de prog pourrait trouver un bout de code du style :
for($i=0; $i < 3; $i++) {
echo "Ho !"
}
plus lisible qu'un :
3.times do
puts "Ho !"
end
J'apprécie aussi de nombreux mots clés tels que "unless" plutôt que l'opérateur not (!) dans les expressions booléennes ou bien le ? qui suit les méthodes renvoyant un booléen. Exemple : exit unless result.nil?
Bon je m'arrêterai là. Tout ça pour dire que je suis un ancien adorateur de PHP qui a bien switché dans le monde joyeux de Ruby.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 2.
> for($i=0; $i < 3; $i++)
for est d'un usage très général. Par exemple, comment tu fais "for(;;)" avec "times do" ?
Le language doit rester général et ne pas avoir 10 000 mots clés pour chaque cas.
Le "times do", tu peux le faire avec une "hideuse" macro (j'ai oublié un peu le php) :
#define TIMES_DO(nb) for(int i_times_do=0 ; i_times_do < (nb) ; i_times_do++)
Donc ton exemple devient
TIMES_DO(3) {
printf("Ho !")
}
Et voilà.
PS : évitez les macros à la con comme TIMES_DO. Apprennez le language que vous utilisez.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 4.
Utiliser des méthodes appartenant à ce qu'on considère généralement comme des "types de base" peut paraître bizarre, mais ça donne généralement un moyen assez élégant de faire du code autodocumenté. Et une fois qu'on est habitué aux itérateurs, ce genre d'écriture devient très naturel. On apprécie justement de ne pas avoir besoin d'un mot clé pour faire tout ça (le mot clé while existe quand même pour les cas plus compliqués).
Dans un autre style, mais toujours montrant comment on utilise des méthodes pour avoir du code autodocumenté, rails fournit plein d'aides supplémentaires. On peut écrire:
3.gigabytes (renvoie une quantité de bytes)
3.months (renvoie une durée en secondes)
3.months.from_now (renvoie une date)
L'enchaînement months.from_now fonctionne parce que Fixnum#from_now crée une date à partir d'un nombre qui est interprété comme un nombre de secondes. Je trouve ça élégant.
[^] # Re: Célèbre ?
Posté par Farzad FARID (site web personnel) . Évalué à 1.
A ton tour tu compares des pommes et des poires puis tu déguises une poire en pomme :)
L'instruction "N.times do ... end" est un itérateur auquel on passe en argument un bloc de code, pas une simple instruction de boucle. Ce sont deux concepts qui n'existent pas en PHP, en tout cas pas avec la simplicité et l'intégration qu'offre Ruby.
Certes il y a ça [1] mais c'est loin d'être élégant et naturel à écrire...
D'autre part, un exemple tel que 3.times do puts "Hello" end est juste là pour illustrer les itérateurs, et ne donne pas vraiment une idée de la puissance réelle de ceux-ci et de leur l'utilité dans un contexte plus complexe (par exemple la création d'un framework tel que Rails).
Ces concepts ne sont certes pas novateurs (les itérateurs par exemple existent en Smalltalk depuis longtemps), mais Ruby est celui qui les implémente le mieux parmi les langages les plus couramment utilisés [2].
1 : http://frederic.bouchery.free.fr/?2004/11/01/30-Creer-Un-Ite(...)
2 : http://www.tiobe.com/tpci.htm
[^] # Re: Célèbre ?
Posté par desfrenes (site web personnel) . Évalué à 2.
ça a le même nom... c'est la même chose ? ;-)
http://frederic.bouchery.free.fr/?2004/11/01/30-Creer-Un-Ite(...)
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 0.
Du devrait relire le commentaire auquel du répond.
[^] # Re: Célèbre ?
Posté par desfrenes (site web personnel) . Évalué à 0.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 2.
Mmmh plus précisément ? En quoi les implémente-t-il "mieux" que, par exemple, Python ?
[^] # Re: Célèbre ?
Posté par Farzad FARID (site web personnel) . Évalué à 2.
- Parce que Ruby a intégré les itérateur et les blocs de code depuis la première version ?
- Parce qu'en Ruby tout les types (y compris les nombres) sont des de vrais objets, extensibles et modifiables par le développeur, et ce depuis le début ?
- Parce qu'en Python tout ceci n'a été ajouté que tardivement, et que ça se ressent dans la syntaxe ?
J'ai utilisé Python pendant plus de 12 ans, j'aime beaucoup ce langage, et je parle donc en connaissance de cause.
[^] # Re: Célèbre ?
Posté par Gniarf . Évalué à 3.
d'ailleurs Ruby rame depuis le début :(
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 2.
Je ne vois pas le rapport entre "implémenté avant" et "mieux implémenté".
Parce qu'en Ruby tout les types (y compris les nombres) sont des de vrais objets
En Python aussi. Oui, y compris les nombres, les classes, les modules, les fonctions...
Parce qu'en Python tout ceci n'a été ajouté que tardivement, et que ça se ressent dans la syntaxe
Ca ne se "ressent" que parce que tu as une vision religieuse des choses liée à ton expérience avec Ruby. En fait c'est très naturel : une fonction est la même chose qu'une méthode (on peut d'ailleurs binder l'une sur l'autre), c'est donc normal que le self soit explicite. De même le cls est explicite sur les méthodes de classe.
Et c'est avant tout justifié par un principe directeur de Python : explicit is better than implicit. En Python il y a peu de magie, la logique est apparente partout, contrairement à Perl et dans une moindre mesure Ruby.
Dire que c'est à cause d'une limitation quelconque du langage qu'il n'y a pas de self implicite est une grossière erreur : il n'aurait pas été compliqué de modifier l'instantiation des méthodes pour rajouter la logique correspondante. Il y a même des gens qui se sont amusés à implémenter cela en pur Python, sans toucher à l'interpréteur ( http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3623(...) ).
... Ceci dit, la question d'origine est "en quoi les itérateurs de Ruby sont-ils mieux implémentés", et tu n'as pas répondu. :-)
[^] # Re: Célèbre ?
Posté par Farzad FARID (site web personnel) . Évalué à 2.
Apparemment tu n'as pas fait de Python 1.x comme j'ai pu en faire, avant que ça devienne un vrai langage à objets, et tes explications sur "self" sont peu convaincantes.
J'arrête de commenter, ça ne sert à rien, je retourne à mon développement Rails.
Happy Python hacking, et sans rancune, il y a de la place pour tous les langages sur terre, du moment qu'on n'utilise pas la pensée magique pour en vanter les mérites ;)
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 2.
Effectivement je n'en ai pas fait. Ceci dit ce n'est pas terriblement important, vu que Python en est à la version 2.5 et qu'une alpha (très alpha certes) de la 3.0 est déjà sortie...
encore une fois tu diverges du sujet initial
La paille et la poutre ?
Bon, on ne saura apparemment jamais pourquoi "les itérateurs de Ruby sont mieux implémentés". Merci pour cette belle intervention :)
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 2.
Apres les question sur les boucle bon je serais tenté de te dire que ton exemple couvre quelque choses qui risque d'etre utilisé une fois tous les 32 du mois. Apres pour ce qui est des itérateur entre un :
foreach($array as $element)
{
echo $element."\n";
}
et
array.each do |element|
puts element+"\n"
On a deux syntaxe assez lisible je trouve.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 3.
Je ne sais pas si un foreach de php peut être considéré comme un itérateur. foreach est pratique.
Dans le cas du C++ (et sa librairie standard), il y a des itérateurs. Un itérateur est un type, donc il peut être utilisé avec toute classe (si elle l'implémente).
Par exemple :
// recherche la position de val dans list
X::const_iterator pos = find(list.begin(), list.end(), val) ;
// depuis val jusqu'à la fin
while (pos != list.end()) {
[...]
pos++ ;
}
Qu'on peut aussi écrire pour les accros du for() :
for (X::const_iterator pos = find(list.begin(), list.end(), val) ; pos != list.end() ; pos++) { [...] }
list peut être presque n'importe quoi (vecteur, liste chainée, map, flux E/S, etc). Donc c'est utilisable avec les modèles. Le polymorphisme est supporté via mem_func. M'enfin, force est de reconnaitre que ce n'est pas trivial.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 1.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 1.
Pourquoi pas.
De toute manière la qualité d'un language ne se limite pas à la somme de ses fonctionnalités. Il y a tant de compromis...
J'ai utilisé php, j'ai adoré.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 4.
Il y a des tonnes d'autres manières d'imaginer une itération:
- on peut vouloir parcourir les éléments dans un autre ordre que celui "intuitif"
- sur une table de hachage, on peut vouloir parcourir les clés ou les valeurs
- on peut vouloir parcourir un arbre ou un graphe de plusieurs manières (profondeur, largeur...)
- on peut vouloir parcourir un graphe en spécifiant de quel sommet on part
- on peut vouloir faire autre chose qu'exécuter du code sur chaque élément, par exemple construire un tableau contenant les résultats de chaque visite d'un élément. Ça oblige, soit à faire du code pas très beau, soit à ajouter un mot clé "map" au langage, qui souffrira des mêmes limitations que foreach sur l'ordre du parcours.
[^] # Re: Célèbre ?
Posté par Ontologia (site web personnel) . Évalué à 1.
- foreach_while cond:BLOCK do action:BLOCK
qui exécute la fonction action sur la liste, tant que cond renvoi vrai, pour l'élément.
de même :
- foreach_until cond:BLOCK do action:BLOCK
plus marrant, on a écrit une méthode sur la lib INTEGER, qui permet de faire des espèces de compréhensions
1.to 50 items {i : INTEGER ; i*2} do {
j : INTEGER;
j.print;
" est pair\n".print;
};
En gros on lui donne l'ensemble de départ, une fonction, et il parcours le block en calculant la compréhension.
Bon c'est à améliorer..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
class Toto < Array
def each_while(cond)
self.each { |item|
break unless cond.call(item)
yield(item)
}
end
end
t = Toto.new
0.upto(9) { |i| t << i }
t.each_while( lambda { |i| i < 5 } ) do |i|
puts i
end
[^] # Re: Célèbre ?
Posté par Stephane Wirtel (site web personnel) . Évalué à 5.
puts i
end
oups :d
[^] # Re: Célèbre ?
Posté par Farzad FARID (site web personnel) . Évalué à 2.
# On construit un tableau de 10 entiers
t = Array.new
10.times { |i| t << i }
# On simule "foreach_while"
t.select { |i| i < 5 }.each { |i| puts i }
Elégant et compact, du Ruby quoi :)
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
Par contre dans mon exemple, je n'aurais pas dû dériver la classe Array mais lui ajouter une méthode, ça aurait été plus simple.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 1.
t = range(10)
# On convertit tout en itérant et on accumule le tout
print "\n".join(str(i) for i in t)
Concis et stylé, du Python quoi !
Vous en avez d'autres, des exemples stupides ? :)
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 3.
Ou alors "toto".join n'est pas un appel de méthode comme ça en a l'air, mais "." est l'opérateur de concaténation, auquel cas il n'y a plus aucun doute, tu mets le retour à la ligne avant le texte, c'est normal ?
[^] # Re: Célèbre ?
Posté par 태 (site web personnel) . Évalué à 3.
s.join(liste) crée la chaine constituée des éléments de liste séparés par s. Donc là il met des passage à la ligne entre chaque paire de nombres (et il y aura un pasage à la ligne de moins que de nombres, comme il faut quoi).
[^] # Re: Célèbre ?
Posté par pa_pitufo_pa . Évalué à 1.
[^] # Re: Célèbre ?
Posté par 태 (site web personnel) . Évalué à 1.
[^] # Re: Célèbre ?
Posté par Thomas Douillard . Évalué à 4.
Mouais, une liste c'est surtout une séquence d'éléments. On dit plutôt une collection d'ailleurs. Genre un ensemble mathématique il y a pas forcément d'ordre, une liste est ordonée, on peut voir ça comme un ensemble de couple {(1,e_1), ... ,(i,e_i), ... ,(k,e_k)} avec i différent pour tous les couples et i<=k, i>0. Donc non, une liste c'est différent d'un ensemble. Après effectivement tu peux utiliser une liste (de "e") comme une sorte d'implémentation d'un ensemble (de "e").
[^] # Re: Célèbre ?
Posté par 태 (site web personnel) . Évalué à 1.
[^] # Re: Célèbre ?
Posté par Sylvain Sauvage . Évalué à 3.
[^] # Re: Célèbre ?
Posté par 태 (site web personnel) . Évalué à 1.
[^] # Re: Célèbre ?
Posté par feth . Évalué à 1.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 2.
Non justement, ça construit un itérateur, d'où le rapport avec vos exemples.
Et si vos exemples sont stupides, c'est parce qu'ils portent sur un type de code qui est absolument inutile dans la vraie vie (afficher tous les entiers de 1 à 10, chouette...). Un langage qui est plus "joli" sur des exemples totalement académiques, la belle affaire.
j'ai du mal à comprendre pourquoi join est une méthode de la chaîne
Et tu n'as pas de mal à comprendre pourquoi "times" est une méthode des entiers en Ruby ? Marrant ça, je croyais que la notation objet était naturelle pour les rubyistes ?
Ou alors "toto".join n'est pas un appel de méthode comme ça en a l'air, mais "." est l'opérateur de concaténation
Heu, comment dire, peux-tu lire un peu de doc sur Python histoire qu'on évite ce genre de question basique ? :-)
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 4.
Pour la dernière fois (parce que t'es lourd et que j'arrête là), nos exemples n'affichent pas les nombres de 1 à 10, nos exemples montrent différentes manière d'écrire un itérateur "foreach_while".
J'ai du mal à comprendre pourquoi join est une méthode de la chaîne, et pas du tableau. Maintenant que quelqu'un de plus serviable que toi m'a expliqué ce que ça faisait au lieu de me demander d'apprendre le Python avant de vouloir discuter, je ne comprends toujours pas la raison de ce choix. Ce n'est pas la chaîne que l'on joint avec quelque chose, c'est le tableau que dont on joint les éléments en les collant avec la chaîne. Intuitivement, je penserais que join est une méthode du tableau, comme c'est le cas dans beaucoup de langages.
Quant au fait d'apprendre le Python avant d'avoir le droit de te répondre, j'oserais souligner que c'est toi qui a pris l'initiative de participer à cette discution où l'on parle essentiellement de Ruby. Je ne vois pas pourquoi on devrait apprendre ton langage favori avant de te répondre.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 1.
C'est bien ce que j'appelle un exemple académique sans incidence sur le monde réel. Dans la vraie vie, on a autre chose à faire que d'implémenter ou réimplémenter des "itérateurs foreach_while", cette dernière chose n'ayant aucune utilité.
J'ai du mal à comprendre pourquoi join est une méthode de la chaîne, et pas du tableau.
Précisément parce que join peut accepter autre chose que des listes en argument. Dans mon exemple join reçoit un itérateur. N'importe quel objet peut être un itérateur s'il implémente le protocole idoine (très simple).
Mais dans la notation "5.times { ... }", on pourra arguer de même que c'est le bloc de code qui s'exécute cinq fois, et non le nombre 5 qui effectue l'opération de répéter le bloc. Ou alors pourquoi pas "true.if { ... }" ? (et là je suis sûr qu'il y en a qui vont me répondre qu'ils l'ont fait)
Quant au fait d'apprendre le Python avant d'avoir le droit de te répondre
Oui mais savoir que le signe "." réalise un accès d'attribut ou de méthode plutôt qu'une concaténation de chaînes, ce n'est pas à proprement parler apprendre le Python, c'est juste savoir grosso modo à quoi ressemble le langage :-)
Ainsi je n'ai pas eu besoin d'apprendre le Ruby pour comprendre vos exemples.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 4.
Si tu penses que pour aborder un aspect d'un langage (itérateurs et blocs) il faut étudier des cas concrets, je peux t'en sortir à la pelle, mais ça risque de prendre un peu plus de place. Par exemple je peux t'écrire un exemple où on veut parcourir un graphe en profondeur, et s'arrêter au premier sommet non marqué. C'est typiquement une variante de foreach_while.
Concernant la remarque sur join, je suis bien d'accord que ça ne s'applique pas qu'aux tableaux ou aux listes, ça s'applique à tout ce qui est énumérable. C'est pour cette raison que c'est une méthode appartenant au module Enumerable en Ruby. Ce module est implémenté par Array, mais aussi par d'autres objets. Je ne vois toujours pas en quoi on peut penser que c'est une méthode de String, mais admettons, c'est peut-être une autre manière de voir qui est valide.
Enfin, concernant l'opérateur ".", je pense que mon raisonnement est devinable dans la manière dont j'ai écrit mon post. D'abord j'ai supposé que c'était un appel de méthode, parce que c'est ce à quoi je suis habitué, mais je ne trouvais pas ça logique. Ensuite, je me suis rappelé qu'en Perl ou PHP, le point était l'opérateur de concaténation, d'où ma question.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 1.
Oui mais tu n'as nullement besoin du foreach_while avec ses blocs de code. Tu peux très bien utiliser une fonction de haut niveau prenant en paramètre un itérateur et un prédicat, et retournant un nouvel itérateur qui renvoie la même chose que le premier jusqu'à ce que le prédicat devienne vrai.
C'est exactement ce que fait la fonction takewhile() du module standard itertools en Python ( http://docs.python.org/lib/itertools-functions.html ).
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 3.
Formulé autrement, est-ce que tu changes de thèse à chaque message parce que tu essayes seulement de prouver que ton interlocuteur a tort ?
Au cas où tu serais de bonne foi, ce qui me semble improbable, je voudrais te faire remarquer qu'il s'agit d'un exemple sorti en 5 minutes dans une discution sur les itérateurs, pas d'une thèse de doctorat sur les langages, ou d'un cours de génie logiciel. Il s'agit d'une illustration de comment on peut écrire un certain type de choses, plus précisément de comment on peut "passer" plus d'un bloc à un itérateur.
Il est assez facile d'écrire la même chose en permettant de choisir l'itérateur, mais le code est moins accessible à quelqu'un qui ne connaît pas Ruby, et donc illustre beaucoup moins le sujet de la discution. Ca donne quelque chose comme ça:
class Object
def takewhile(iterateur, predicat)
self.send(iterateur) do |element|
break unless predicat.call(element)
yield(element)
end
end
end
(0..10).takewhile(:each, lambda { ... }) do |element|
...
end
Ca ne marche pas bien avec les itérateurs qui renvoient plus d'un élément à la fois, mais j'ai la flemme de faire un exemple parfait, surtout aussi stupide et académique. Tu remarqueras que le code est presque identique au précédent, puisque la seule différence est qu'on passe l'itérateur en paramètre, en plus du bloc et du prédicat.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 0.
Les deux :-)
Ainsi, la raison pour laquelle la fonction takewhile() est fournie dans les modules standard de Python, c'est qu'elle y est écrite en C et permet donc des gains de performance substantiels sur certains algorithmes. Sinon, c'est une primitive qui s'écrit en quatre lignes de Python, ça n'a donc pas grand intérêt de l'abstraire : pareil pour le foreach_while.
La morale, c'est que l'exemple donné des trucs géniaux qu'on peut faire avec les itérateurs de Ruby 1) se fait aussi sans problème dans d'autres langages 2) n'apporte à peu près rien en pratique.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
2) De la même façon que "for" n'apporte rien face à "while", ou bien que Python n'apporte rien face au C, je suppose. On peut toujours tout faire en C, peu importe que ce soit inélégant et que ça prenne 30 lignes au lieu de 3. Sur l'utilité des itérateurs, je pense qu'actuellement le consensus est clair. De même sur l'utilité de la programmation fonctionnelle.
(Je commence à croire que tu considères que si c'est possible en Python, alors ça ne mérite pas d'être mentionné pour les autres langages. Ca expliquerait tous ces messages, en fait, et peut-être que j'ai eu tort de réagir.)
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 2.
Ce n'est pas que ça mérite pas d'être mentionné.
C'est juste que l'idée originale (exprimée par un posteur plus haut) que "Ruby est le seul langage populaire à avoir des itérateurs bien implémentés" est un mensonge.
Mais je suis d'accord que les mêmes concepts exprimés en C, assembleur ou même PHP sont bigrement moins élégants.
[^] # Re: Célèbre ?
Posté par Batchyx . Évalué à 1.
Non. cela s'applique sur les énumérables qui retournent des chaînes et uniquement ceux la.
<blockquote>Je ne vois toujours pas en quoi on peut penser que c'est une méthode de String, mais admettons, c'est peut-être une autre manière de voir qui est valide.</blockquote>Si ça s'applique à l'objet basestring c'est que dans la liste il ne peut y avoir que des basestring.
Après on peut se poser la question de pourquoi on à pas une méthode générale qui prendrai autre chose que des chaînes. Mais cette méthode générique, dans le cas des chaînes devrait répétitivement faire des resultat+=unechaine, qui en python (tout comme strcat en C) est lent comme la pluie, et qui rendrait au final la méthode pas très intéressante.
Si la méthode join est intéressante, c'est qu'elle est optimisée pour traiter des chaînes et qu'elle doit sûrement accéder à la représentation interne des chaînes de la liste. Mettre cette méthode sur un objet liste ou un type énumerable, c'est autoriser qu'une méthode d'un objet aille fouiller dans la représentation interne de l'autre et c'est Mal.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 1.
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
Si tu en es vraiment convaincu, tu pourrais éviter de garder ton argumentation implicite.
Pourquoi join ne convertit pas automatiquement en string, sachant que join n'accepte que les strings ? Ca veut dire que le langage t'oblige à expliciter quelque chose que tu dois toujours faire. Pourquoi ? Si j'ai besoin d'un string, pourquoi ne pas convertir l'objet en string ?
Il y a des cas où ce n'est pas évident, et dans ce cas la conversion ne doit pas être automatique. Par exemple, si j'écris "a + b" alors que a est un string et b un int, il n'est pas évident de conclure que je veux convertir "b" en string. Peut-être qu'en fait je voulais convertir "a" en int. Mais quand il n'y a pas d'ambiguité, forcer la convertion explicite n'a pas l'air justifié.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 2.
Je n'en suis pas "vraiment convaincu", je rappelle juste la règle qui justifie ce choix. Après, chacun a le droit d'être en désaccord, c'est juste qu'il y a une cohérence dans la conception du langage.
Pourquoi join ne convertit pas automatiquement en string, sachant que join n'accepte que les strings
Précisément parce qu'ainsi, tu lèves les erreurs tôt plutôt que tard. Quiconque a déjà programmé en PHP sait à quel point c'est préférable ;-))
quand il n'y a pas d'ambiguité, forcer la convertion explicite n'a pas l'air justifié
Oui, comme ça une erreur dans ton programme apparaît cent lignes plus tard sous une forme incompréhensible plutôt qu'en levant la bonne exception au bon endroit...
D'autant que la conversion explicite n'est pas bien lourde à écrire. Par exemple : "".join(str(x) for x in my_iterator)
(on peut aussi choisir une notation plus fonctionnelle avec map ou imap)
[^] # Re: Célèbre ?
Posté par Farzad FARID (site web personnel) . Évalué à -1.
Merci d'avoir répondu à côté de la question, ça fait progresser la discussion dans la bonne direction.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 1.
Essaie d'argumenter un peu, sinon ça ne va pas très loin...
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 1.
Comme dlfp ?
[^] # Re: Célèbre ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Sinon, DLFP serait un très bon candidat pour passer sous Rails. Le seul obstacle, c'est la quantité de code à migrer (on parle de 30 000 lignes de code pour les templates) par rapport au peu de temps libre dont les admins dispose.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 1.
> Sinon, DLFP serait un très bon candidat pour passer sous Rails.
Non, c''est un très mauvais candidat. Dlfp marche. Les quelques reproches sur dlfp n'ont pas de réponse par manque de temps. Pas à cause de php.
Et le passage à Rails posera probablement des problèmes de tenu en charge. Or le budget de dlfp est très serré (pas de pub).
[^] # Re: Célèbre ?
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Célèbre ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
C'est quoi cet a priori ?
[^] # Re: Célèbre ?
Posté par Ontologia (site web personnel) . Évalué à 2.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
A ajouter au fait qu'il n'y a pas de module apache Ruby, qu'il est nécessaire de rajouter un serveur, c'est peut être là un problème de montée en charge qui a impliqué cette réputation ? Ce pourrait être une hypothèse..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Célèbre ?
Posté par Yusei (Mastodon) . Évalué à 2.
Rails de base est plus rapide que PHP de base, parce qu'il fournit plein de caches à différents niveaux sans effort de programmation.
Par contre, il faudrait comparer Rails à un framework PHP proposant les mêmes outils.
Pour info, il existe un module apache Ruby, mais il n'est pas utilisé par Rails, probablement parce qu'il n'est pas assez puissant. Il ne permet que d'intégrer du Ruby dans des pages web, à la PHP.
[^] # Re: Célèbre ?
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
[^] # Re: Célèbre ?
Posté par Antoine . Évalué à 4.
L'association Linuxfr compte sur toi pour acheter tous ces serveurs :)
[^] # Re: Célèbre ?
Posté par Bruno Michel (site web personnel) . Évalué à 7.
[^] # Re: Célèbre ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
[^] # Re: Célèbre ?
Posté par gertrude . Évalué à 1.
Hahaha :) MDR!!!
Qu'est ce qu'on s'en tape des "$" .... en plus, il y en a (et je ne vois pas ce qui empeche des les utiliser si on es un dev php accro à cette syntaxe pourrave) donc je ne vois pas ce qu'il y a de chiant.
Comparativement, je pourrais donc qualifier PHP de laxatif vu que par rapport à Ruby on Rails c'est quand même beaucoup plus de taf
Enfin bref ça fait toujours plaisir une petite blague comme ça dès le matin
[^] # Re: Célèbre ?
Posté par Jordan Bracco . Évalué à 1.
[^] # Re: Célèbre ?
Posté par zerchauve . Évalué à 2.
[^] # Re: Célèbre ?
Posté par totoro . Évalué à 2.
Faudrait p'tet comparer ce qui est comparable parceque dans le même genre servir des pages statiques c'est plus performant qd même ;).
Enfin une comparaison Symfony/RoR/Django est sûrement plus pertinente http://wiki.rubyonrails.com/rails/pages/Framework+Performanc(...)
[^] # Re: Célèbre ?
Posté par BAud (site web personnel) . Évalué à 3.
si quelqu'un a d'autres méthodes utilisées pour vérifier la tenue à la montée en charge, ça m'intéresse.
[^] # Re: Célèbre ?
Posté par totoro . Évalué à 0.
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à -1.
[^] # Re: Célèbre ?
Posté par pa_pitufo_pa . Évalué à 1.
merci
[^] # Concours de b.....
Posté par desfrenes (site web personnel) . Évalué à 2.
Dés qu'on parle de Rails il y a toujours quelqu'un pour comparer avec PHP et dés qu'on parle d'un framework en PHP il y a toujours quelqu'un pour comparer avec Rails. Drôle de phénomène.
Sinon pour le débat sur les syntaxes C-like/Ruby... quand on fait déjà du javascript, de l'actionscript ou même du java (enfin bref, rien que des trucs pas du tout répandus dans le web...;-) ), ne pas avoir à prendre de nouvelles habitudes avec une syntaxe trés (trop?) différente ça peut quand même, peut-être, aider à adopter le nouveau langage. non?
Bon d'accord, j'avoue, les mot-clés m'ont traumatisé depuis les cours forcés de visual basic, ahahaha !
Sinon question aux utilisateurs de Rails pour satisfaire ma curiosité... si on ne veut pas faire d'activeRecord mais plutôt du DAO... gérable avec Rails ou c'est hors-cadre ?
@+!
[^] # Re: Concours de b.....
Posté par Yusei (Mastodon) . Évalué à 2.
En implémentant les bonnes méthodes dans tes modèles, tu récupères ces facilités sans utiliser ActiveRecord, mais c'est peut-être un peu plus pénible.
[^] # Re: Concours de b.....
Posté par desfrenes (site web personnel) . Évalué à 2.
mais plutôt faire comme ça : http://martinfowler.com/eaaCatalog/dataMapper.html
J'imagine que oui, mais en réalité je me demande jusqu'à quel point ça peut retirer de l'intérêt au framework. La question cachée c'est, à part l'activerecord les doigts dans le nez, qu'est-ce qui déchire sa race dans Rails ? :-)
[^] # Re: Concours de b.....
Posté par Yusei (Mastodon) . Évalué à 7.
D'abord, est-ce qu'on peut ?
Dans une certaine mesure, ActiveRecord permet déjà tout ça, mais peut-être pas de la manière la plus élégante qui soit. C'est à dire qu'il est conçu pour te permettre d'utiliser une BDD qui existe déjà, si tu ne peux pas la créer en respectant les conventions qu'il aime bien.
Après, si tu atteinds vraiment les limites de ce qu'AR permet, ou bien si ça devient vraiment trop porc, tu peux coder ton propre truc pour faire ça. Deux possibilités: soit tu le codes comme tu veux, sans te préoccuper de Rails, et tu perdras quelques aides fournies par Rails dans la suite, soit tu prends soin de faire les choses comme Rails apprécie.
Si tu veux conserver tout ce que permet Rails, en gros tu vas avoir besoin de réimplémenter à ta sauce les méthodes d'AR. Du moment qu'elles sont nommées pareil, ça va fonctionner. En particulier, si tes modèles possèdent des méthodes "save", "update_attributes", "delete" et "find", tu couvres la plupart des cas.
Ensuite, quel intérêt dans Rails à part AR ?
Déjà, tu as un framework MVC tout prêt, c'est un début. Si aucun de tes modèles n'hérite d'ActiveRecord, ça ne t'empêche pas de les utiliser, et ça fonctionne très bien. Pouvoir coder du web en autre chose que PHP, pour moi, c'est déjà un plus.
Le framework, en plus d'AR, est composé d'ActionController, ActionView, et quelques trucs mineurs (ActionMailer...).
Si tu combines AC et AV, tu vas disposer:
- d'un moteur de templates pour générer du XHTML, XML, Javascript, avec du code ruby dedans, un peu à la PHP
- d'un autre moyen pour générer des documents XML, sous forme arborescente cette fois
- des outils nécessaires pour que tu puisses développer ta propre gestion des vues qui ne sont pas couvertes par les cas précédents
- d'une gestion très simple des urls "jolies", c'est à dire qu'au lieu d'avoir catalogue.php?action=voir&id=3, tu vas avoir http://hote/catalogue/voir/3
- d'un système de vues partielles ou de composants, qui te permettent d'éviter de dupliquer ton code de présentation
- de plein d'outils tout faits pour intégrer de l'ajax
- de plusieurs systèmes de caches, chacun adapté à différents types d'applications (selon que tes pages sont plus ou moins dynamiques)
J'en oublie certainement :) En plus de ça, tu as un système de plugins vraiment bien fait. Tellement bien fait que tu te retrouves parfois à faire toi-même un plugin pour ta propre application, parce que ça rend le code vraiment plus élégant de faire comme ça. Tu as également un framework de tests qui est très élaboré. Plus un profiler, un débugger, etc. qui te permettent d'interrompre l'exécution de ton programme et d'aller l'inspecter, puis de reprendre. C'est très classique pour un développeur C ou Java, mais je n'ai aucune idée de comment on peut faire ça en PHP, par exemple.
[^] # Re: Concours de b.....
Posté par Yusei (Mastodon) . Évalué à 2.
Donc si ton modèle ressemble à un modèle ActiveRecord, tu peux l'utiliser à la place d'un modèle ActiveRecord, n'importe où. Ressembler, en Ruby, ça veut dire répondre aux mêmes méthodes (de la même manière, c'est à dire en prenant les mêmes paramètres et en renvoyant le même type de valeur).
Comme le code est assez bien découpé, le nombre de méthodes auxquelles un objet doit répondre pour ressembler à un objet AR est relativement réduit. C'est pour ça qu'il doit être assez facile d'implémenter un autre système pour avoir des données persistantes. Tu as besoin d'avoir de quoi enregistrer, lire, modifier, obenir la liste des attributs, éventuellement leurs types, et c'est à peu près tout.
(Mais, peut-être faut-il encore le préciser, dans de nombreux cas tu n'as même pas besoin que tes modèles ressemblent à des modèles AR)
[^] # Re: Concours de b.....
Posté par Ummon . Évalué à 3.
Personnellement je préfère les interfaces (au sens Java/C#) au duck typing : si l'empreinte génétique est celle d'un canard alors c'est un canard, c'est quand même plus rigoureux.
[^] # Re: Concours de b.....
Posté par BAud (site web personnel) . Évalué à -1.
~~> [ ] :D
[^] # Re: Concours de b.....
Posté par Yusei (Mastodon) . Évalué à 5.
En particulier, si tu as seulement besoin que ton "canard" flotte, tu n'as pas besoin d'implémenter le cancannement. Et donc, tu peux faire:
class Sorcière
def flotte
...
end
end
Et ensuite utiliser ta sorcière comme un canard dans certains cas, malgré le fait qu'elle ne fasse pas "coin".
L'idéal serait de pouvoir faire les deux, et de pouvoir spécifier dans la signature de ta méthode que tu veux un objet répondant à un ensemble de méthodes. Je crois me souvenir avoir vu quelque chose de semblable dans le système d'objets d'OCaml. Le type des objets était représenté par la liste de leurs méthodes, si je ne me trompe pas.
[^] # Re: Concours de b.....
Posté par Guillaume Rossignol . Évalué à 2.
=> []
[^] # Re: Concours de b.....
Posté par RB . Évalué à 1.
[^] # Re: Concours de b.....
Posté par desfrenes (site web personnel) . Évalué à 1.
- d'un moteur de templates -> vu partout
- d'un autre moyen pour générer des documents XML -> je ne vois pas précisément ce que tu veux dire mais bon... ça doit se trouver...
- d'une gestion très simple des urls "jolies" -> vu partout
- d'un système de vues partielles ou de composants-> pas nouveau
- de plein d'outils tout faits pour intégrer de l'ajax-> houlà!!! surtout pas, non merci, j'ai déjà tout ce qu'il me faut :-)
- de plusieurs systèmes de caches-> vu ailleurs
- profiler, un débugger -> vu ailleurs
L'intérêt, le pourquoi du buzz, doit être ailleurs, peut-être dans la façon dont tout ça travaille de concert, peut-être dans même dans Ruby. Dommage que je ne dispose pas d'assez de temps en ce moment pour le découvrir par moi-même.
[^] # Re: Concours de b.....
Posté par Bruno Michel (site web personnel) . Évalué à 5.
J'aurais tendance à penser que Rails a toujours un coup d'avance sur les autres frameworks. Etant parti plus tôt, il est le premier à arriver à maturité (d'après ce que j'ai entendu, les frameworks PHP, ce n'est pas encore cela, pour les autres je ne sais pas). Il possède également une communauté plus importante que les autres frameworks, ce qui lui permet également d'avoir un grand nombre de plugins (cf [http://agilewebdevelopment.com/plugins/list]).
J'ai également l'impression que Rails est toujours le leader, même si c'est nettement moins marqué que par le passé. Par exemple, Rails a tranché pour REST (contre SOAP), et je ne serais pas surpris que cela devienne la norme pour les frameworks l'année prochaine. Sur les tests unitaires, Rspec [http://rspec.rubyforge.org/] me semble également très en avance sur ce que l'on peut trouver ailleurs.
Enfin, je préfère largement Ruby à PHP, mais c'est un choix tout personnel :)
[^] # Re: Concours de b.....
Posté par IsNotGood . Évalué à 1.
Je connais peu Java, mais le peu que j'ai vu de java/jboss est impressionnant.
Au passage RH a libérer du code (GPLv2 après avoir acheté à Exadel qui l'avait mis en proprio) :
http://www.redhat.com/developer_studio/?intcmp=70160000000HE(...)
http://www.jboss.com/products/devstudio
http://jboss.com/partners/exadel
Ce qui est "amusant", c'est que RH dit vendre beaucoup plus DevStudio pour Windows que pour RHEL. Si ça limite l'essor de .net et C# c'est tant mieux.
[^] # Re: Concours de b.....
Posté par Yusei (Mastodon) . Évalué à 2.
Après, plus spécifiquement, parmis les avantages propres à Rails, le langage Ruby est un élément de réponse, et après on trouve la philosophie de conception (convention plutôt que configuration, etc.)
[^] # Re: Concours de b.....
Posté par Bruno Michel (site web personnel) . Évalué à 2.
D'autre part, quitte à ne pas utiliser Active Record, ca peut valoir le coup d'essayer d'autres frameworks en Ruby comme Merb [http://merbivore.com/].
[^] # Re: Concours de b.....
Posté par desfrenes (site web personnel) . Évalué à 1.
"Unlike Rails, Merb is ORM-agnostic, JavaScript library agnostic, and template language agnostic, preferring plugins that add in support for a particular feature rather than trying to produce a monolithic library with everything in the core."
[^] # Re: Concours de b.....
Posté par gallenza . Évalué à 2.
C'est comme du côté des frameworks python : Django a tout intégré, et Pylons récupère des bouts d'un peu partout.
Le problème c'est que ce qui fait la valeur ajoutée/utilisabilité/performance d'un framework, c'est bien l'intégration, qui fait que tout se goupille bien parce que c'est fait pour.
Au final y'a pas photo...
[^] # Re: Concours de b.....
Posté par ccomb (site web personnel) . Évalué à 1.
[^] # Re: Concours de b.....
Posté par TheGuit (site web personnel) . Évalué à -1.
[^] # Re: Concours de b.....
Posté par ccomb (site web personnel) . Évalué à 2.
mmmh bien. ok.
[^] # Re: Célèbre ?
Posté par zerchauve . Évalué à 4.
ca fait un peu trop fanboy, quand tu fais une ressucée de tous les posts de DHH, de 37signals and co "evolution not revolution", blablabla
la communauté rails n'est pas du tout ENORME. Elle est certes importante, mais c'est vraiment peau de zob par rapport au monde Java quand meme (les frameworks toussa) etc..
Quant au "plus celebre" faut ptetre se calmer. Le plus hype c'est sur. Le plus celebre je sais pas hein, encore une fois y a quand meme deux trois trucs en java qui trainent... et pas beaucoup de sites en Ruby dans les 500/1000 plus gros du monde.
Mais j'avoue que le buzz est monstrueux, et que l'outil est super intéressant, surtout pour des applis d'entreprise (pas si sur que ca que ca percera pour des sites communautaires importants avec grosse charge et tout et tout... oui je sais pour twitter et je trouve quand me que twitter ca rame sa maman)
Et je précise que je ne fais QUE du Rails, depuis un moment deja...
[^] # Re: Célèbre ?
Posté par TheGuit (site web personnel) . Évalué à 0.
[^] # Re: Célèbre ?
Posté par Nicolas Blanco (site web personnel) . Évalué à 2.
[^] # Re: Célèbre ?
Posté par IsNotGood . Évalué à 1.
Ratais, je suis développeur (quasi exclusivement C++ actuellement).
> oui, Rails est - devenu en quelques années - le plus célèbre des frameworks Web
Ben les sites faient en ruby sont rares (ou alors ce n'est pas visible et je ne l'ai pas remarqué).
Qu'il y a-t-il comme fournisseur qui propose du ruby ?
Free ?
Que Ruby/ROR soit "hype", qu'il est une progression "fulgurante", etc. OK.
Mais célèbre...
Où peut-être tu veux dire "célèbre" dans une communauté ?
Les développeurs web 2.0 ?
> Ayant essayé de nombreux frameworks Web, Ruby on Rails est celui qui m'a le plus branché, et celui que je conseille à tous les développeurs Web.
Je répète, je ne mets pas en cause Ruby on Rails. Mais merci pour ton avis. Merci à linuxfr de popularisé plus largement Ruby et Ruby on Rails. Il semble avoir des innovations et donc il le mérite très probablement (je suis mal placé pour en juger).
# Herbergement
Posté par GaGadget . Évalué à 2.
[^] # Re: Herbergement
Posté par Lagoon . Évalué à 2.
[^] # Re: Herbergement
Posté par Bruno Michel (site web personnel) . Évalué à 3.
[^] # Re: Herbergement
Posté par BAud (site web personnel) . Évalué à 3.
- la tenue à la charge pour des sites sur serveur mutualisés ? (ou des métriques : tel serveur tient tant de sites avec chacun tant de visiteurs...)
- la mise en oeuvre de sécurité entre sites sur serveur mutualisé ?
ce qui permettrait de répondre objectivement à http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...) (déjà pour Ruby)
# Un Troll...
Posté par Ummon . Évalué à 2.
Personnellement j'ai toujours aimé le Ruby pour pleins de raisons (depuis bien avant Rails)... mais une chose qui me fait un peu peur c'est la lenteur du bouzin.
Petite comparaison : Erlyweb / Rails :
http://yarivsblog.com/articles/2007/12/09/erlyweb-vs-ruby-on(...)
(j'aime aussi l'Erlang)
(oui je sais, 1: le test n'est pas significatif, 2: ya pas que les performances brutes qui comptent, 3: etc..)
Bon je me taille avant que tout pète ->[]
[^] # Re: Un Troll...
Posté par Yusei (Mastodon) . Évalué à 2.
Si on ne fait aucun réglage particulier et qu'on reste en mode developpement, alors tout le framework est lancé/interprété à chaque requête. Forcément, c'est un peu lourd. Quand on passe en mode production, une énorme partie du code est pré-chargée, ce qui accélère énormément les choses. Seules les vues sont interprétées à chaque requête, sauf erreur.
Ensuite, dès qu'on a plusieurs mongrels et un apache pour répartir les requêtes, le débit augmente tant qu'on a de la RAM pour lancer des mongrels.
Enfin, selon le type de contenu, on peut mettre en place très facilement des systèmes de caches plus ou moins efficaces. Pour le type de contenu du bench, on devrait obtenir un débit identique à celui d'apache sur des pages fixes, une fois que chaque page a été mise en cache. Mais bon, je conçois que le but du bench n'ait pas été de mesure les performances du système de cache.
[^] # Re: Un Troll...
Posté par Erwan . Évalué à 3.
Par exemple, (et là ça devient un peu polémique parce que Hansson affirme qu'ils ont tort et auraient pu grossir en gardant ActiveRecords) ils ont du arrêter d'utiliser ActiveRecords pour avoir une séparation claire entre un site web "stateless" et la couche de données. En gros, perdant un des principaux avantages de Rails.
[^] # Re: Un Troll...
Posté par Dring . Évalué à 1.
...plutôt que...
...ça dénote déjà un manque d'esprit pratique ? Comment peut-on imaginer une syntaxe ou taper une chaîne de caractères exige déjà 6 caractères de contrôle là où la plupart des langages, y compris les plus vieux, n'en demandent que 2 ?
Bon, je connais pas Erlang et ses avantages, mais après avoir lu ça j'ai pas trop envie de creuser. J'ai tort ?
[^] # Re: Un Troll...
Posté par Ummon . Évalué à 1.
<<"ma chaine">> est une syntaxe binaire ou chaque caractère est représenté par un octet (sauf codage genre utf-8).
Personnellement je n'ai jamais utilisé la deuxième solution, je pense qu'il l'a utilisé pour ces meilleures performances.
[^] # Re: Un Troll...
Posté par Ummon . Évalué à 2.
http://fr.wikipedia.org/wiki/Erlang_%28langage%29
et
http://www.framasoft.net/article2089.html
[^] # Re: Un Troll...
Posté par Dring . Évalué à 1.
Effectivement, la page sur Wikipédia est très enrichissante, mais ça n'empêchera pas la syntaxe de me rebuter. Après, j'ai peu l'occasion de faire du traitement en parallèle, donc je survivrais.
[^] # Re: Un Troll...
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: Un Troll...
Posté par Ummon . Évalué à 1.
Par contre je trouve l'excuse de la syntaxe pour ne pas aller voir plus loin plutôt mauvaise. Je suis d'accord que c'est un effort à fournir au début mais une fois qu'on a un peu tout vu ça n'est plus un problème majeur sans compter que la syntaxe d'Erlang est plutôt facile d'après moi.
[^] # Re: Un Troll...
Posté par reno . Évalué à 3.
L'avantage de Erlang c'est sa 'scalabilité' (aucune idée comment traduire ça correctement en Français): avec Erlang on peut exploiter des muti-processeurs "efficacement" dans le sens ou N processeur peut impliquer N fois plus rapide en Erlang (ce qui est *très* interressant vu l'évolution actuelle des CPUs) mais attention:
- sur un mono-processeur Erlang est beaucoup plus lent que le C donc même si c'est une application "Erlang-friendly" il faudra avoir 2-3 CPU pour atteindre les mêmes perf que le C sur un seul CPU!
- toutes les applications ne fonctionnent pas bien en multi-processeurs: certains ont leurs performances qui restent faible même quand on ajoute des processeurs..
[^] # Re: Un Troll...
Posté par Ummon . Évalué à 3.
Erlang a des objectifs précis : "tolérance à la faute" et "monté en charge", Il ne se veut pas comme un remplaçant du C.
Pour donné un exemple "grand public", ejabberd est un serveur XMPP(Jabber) réalisé en Erlang et qui s'en sort pas trop mal : http://www.jabber.org/admin/jsc/
[^] # Re: Un Troll...
Posté par reno . Évalué à 2.
Sais-tu ce qu'apporte quoi la R12?
Il y a eu une version avant qui était "majeur": elle apportait le support du SMP a Erlang de manière transparente: avant il fallait le programmer pour utiliser plusieurs CPU, maintenant les processus peuvent être sur des CPUs different de maniere transparente (je crois).
[^] # Re: Un Troll...
Posté par Ummon . Évalué à 1.
Notamment, par exemple, un module "Array" ( http://erlang.org/doc/man/array.html ).
[^] # Re: Un Troll...
Posté par Sylvain Sauvage . Évalué à 2.
Extensibilité, capacité de monter en charge…
[^] # Re: Un Troll...
Posté par BAud (site web personnel) . Évalué à 2.
# mise à jour?
Posté par NickNolte . Évalué à 1.
euh... oui merci d'avance :)
[^] # Re: mise à jour?
Posté par Nicolas Blanco (site web personnel) . Évalué à 2.
Comme dit plusieurs fois du code qui fonctionne sur Rails > 1.2.3 fonctionne avec Rails 2.0 sans modification. Si des parties du code utilisent des fonctions de Rails qui ont été externalisées il suffit d'installer ces plugins dans Rails 2.
Au niveau des nouvelles conventions dans Rails 2 elles ne sont pas nombreuses (les vues à appeler dans le style : vue.minetype.render plutôt que vue.render (edit.html.haml plutôt que edit.haml))...
[^] # Re: mise à jour?
Posté par NickNolte . Évalué à 1.
# ROR et ses limites
Posté par mister popo ポポ (site web personnel) . Évalué à 7.
Autre problème, RoR est une application, sans possibilités de contraindre simplement l'utilisation mémoire ou le temps maxi pour exécuter une page, ce qui le rends inutilisable sur un hébergement mutualisé dans le genre de Free.
Autre fantasme, la migration d'un site en PHP qui va bien mais pas joli, vers du RoR qui rulez. Il y a eu récemment un post sur SlashDot sur ce sujet. Le type avait embauché un des dev de RoR pour faire la migration, et au bout de 2 ans, ils ont jeté l'éponge. RoR est un logiciel de prototypage, très bien pour créer from scratch un site, et surtout pas quelque chose vers quoi migrer.
La gestion des sessions en Cookie, comme évolution me parait tout simplement risible. La taille des cookie est limité, et les logiciels civilisé savent gerer les sessions en RAM, sauf si ils sont en cluster ou il faut passer à quelque chose de de suite nettement plus compliqué. PHP a le bon de laisser l'admin s'occuper du choix, sans faire passer une astuce pour une évolution.
La qualité indéniable de RoR est d'être un aiguillon pour tous les autres, il n'y a qu'a voir l'arrivé de Grail, PHPCake ou Django. Un serveur peut être simple, et le volume des fichiers de configurations ne doit pas dépasser le volume de code. Le MVC, l'ORM, l'intégration d'un framework JS, un outil de build, le REST et JSON font maintenant parti des ingrédients d'un bon framework web.
[^] # Re: ROR et ses limites
Posté par EppO (site web personnel) . Évalué à 1.
Quand au serveur fourni, je ne le considère pas pour un usage en production, il est évident qu'il est très pratique pour du développement mais ca ne vaut pas un apache ou même mieux un lighttpd bien configuré avec un cluster de moteur FastCGI.
[^] # Re: ROR et ses limites
Posté par Thomas . Évalué à 2.
# Django
Posté par _p4_ . Évalué à 3.
Je voulais savoir quelles sont les grosses différences par rapport à Django. J'ai développé plusieurs sites avec et je l'apprécie beaucoup, le trouvant rapide et efficace. J'ai survolé Rails en testant guère plus loin que quelques hello world. Je ne demande pas qui est le mieux, mon lance-troll est éteind; juste quels sont les avantages majeurs de l'un et l'autre. Il y a des fonctionnalités très alléchantes dans Rails qu'il n'y a pas dans Django, je pense à ActiveRdf [ http://www.activerdf.org/ ] notamment qui me fait envie.
[^] # Re: Django
Posté par Dreammm . Évalué à 4.
Une chose très intéressante dans Django et qui n'existe pas dans rails, c'est l'approche composante : dans Django, tu peux utiliser des composants pour bâtir ton application, et chaque composant à un espace MVC séparé (si j'ai bien compris). Dans rails, tu as un ensemble MVC mis en commun, et le rajout d'un plugin vient taper là dedans.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.