Yusei a écrit 4649 commentaires

C'est plus rigoureux, mais ça t'oblige à recopier tout le génome du canard dans ton mutant, même les bouts dont tu n'as pas besoin. Avec le duck typing, tu n'as besoin d'implémenter que les méthodes que tu utilises.

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.

Je n'avais pas pour but de faire un post décrivant pourquoi Rails est mieux que les autres, il me demandait juste quels étaient les intérêts de Rails en dehors d'ActiveRecord. Effectivement, tout ce qu'on peut faire avec Rails, on peut le faire avec Java et un framework web. L'argument de vente de Rails, c'est qu'on le fera plus vite et pour moins cher (ie. moins de programmeurs).

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.)

Il y a peut-être un truc qui n'est pas clair dans ce que je dis au début. La raison pour laquelle on peut remplacer ActiveRecord par autre chose assez simplement, c'est que Ruby utilise le duck typing: si ça ressemble à un canard, et que ça fait kwak comme un canard, alors c'est un canard.

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)

Je vais répondre séparément aux deux questions.

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.

Juste pour info, "times" n'est pas un mot clé, c'est une méthode appartenant aux nombres entiers. Plus précisément, c'est un itérateur. On trouve aussi des itérateurs "upto" et "downto" permettant de faire des "for", par exemple 3.upto(5).

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.

Je ne sais pas ce qu'est DAO, mais ActiveRecord n'est qu'un composant indépendant des autres. On peut utiliser ActiveRecord hors de Rails, ou bien des modèles n'héritant pas d'ActiveRecord dans Rails. Rien ne t'empêche de coder tes modèles comme tu l'entends, le reste du framework ne s'en souciera pas. Tu perdras juste quelques facilités au niveau de la création et de la modifiation de tes modèles via des formulaires.

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.

Sans aller jusqu'à nier que Rails puisse être lent, les tests me paraissent douteux, et il faudrait avoir des détails sur la configuration mise en place. On ne sait même pas si mongrel est lancé en environnement "développement" ou "production", quels types de caches sont activés, si plusieurs processes sont lancés ou si c'est un seul process qui gère les requêtes en série...

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.

Pour info, le code qui permet de stocker autant de champs que l'on veut dans une colonne "blob" de la table, ainsi que la gestion de la censure de certains champs en fonction d'une validation, le tout de manière complètement transparente au niveau du contrôleur ou de la vue, doit représenter une cinquantaine de lignes.

Au final, ça permet de faire ça (en pseudo-code qui mélange le controleur et la vue):
l = Livre.new
l.prix = 10
print l.titre
print l.resume
l.valider
print l.resume

En admettant que le champ résumé soit censurable, appeler "l.resume" avant validation va renvoyer un texte par défaut, et après validation, va renvoyer le résumé. Dans chaque cas, on ne sait pas si "prix", "titre" ou "resume" sont des colonnes de la table, ou des champs stockés dans un blob.

Si "prix" est stocké dans un blob mais qu'on voudrait bien faire un tri en SQL dessus, alors on crée une colonne dans la table de Livre, on recopie les infos dedans, et on n'a rien à faire d'autre.

Je n'essaye pas de frimer, hein, je dis juste ça pour montrer comment Ruby et Rails permettent de résoudre des problèmes non triviaux en peu de temps, et en gardant un code très propre. En particulier pour ces modifications là, je n'ai eu à modifier qu'un seul fichier, sur peu de lignes de code, pour rajouter la censure/validation partout, alors que ce n'était pas prévu au départ.

Alors, je conseille fortement Rails, qui me semble idéal pour une méthode de développement que certains appellent "agile". Il y a en particulier un bon livre qui s'appelle "programmation agile avec ruby on rails", je crois, et qui aborde la programmation sous cet angle.

Dans cette vision des choses, tu as un entretien rapide avec tes utilisateurs, ils définissent leurs besoins, tu passes 2h à coder un prototype, tu leur fais essayer, ils t'expliquent pourquoi ce n'est pas du tout ce qu'ils veulent, tu passes une heure à faire les modifs, et tu recommences jusqu'à ce qu'ils soient contents.

Dans beaucoup de cas simples, tu peux même faire les modifs demandées pendant qu'ils boivent un café, ou en direct.

En particulier, des opérations souvent pénibles comme changer la structure des données deviennent relativement simples et rapides.

J'ai fait un projet de taille conséquente suivant cette méthode, ça m'a vraiment beaucoup facilité la vie car le client n'avait pas d'idée bien précise de ce qu'il voulait, et le client a été très satisfait du résultat et de la réactivité qu'on a pu obtenir alors que j'étais presque le seul à bosser dessus.

Pour prendre quelques exemples:

- le nombre et le type des champs de nos données changeait tout le temps et n'était défini nulle part, donc (en une demie journée) j'ai fait en sorte que les modèles du projet puissent contenir un nombre indéterminé de champs qui n'étaient pas des colonnes de la base de données mais stockées dans un champ fourre-tout. Au niveau applicatif, c'est entièrement transparent. C'est à dire que pour créer un champ, il suffit de lui affecter une valeur (livre.prix = 10 crée le champ prix s'il n'existe pas).

- j'ai dû rajouter au projet une gestion des droits permettant de rendre des champs accessibles seulement à certaines personnes en fonction d'une validation des données par d'autres personnes. Ce n'était pas prévu. En quelques heures, j'ai pu coder une solution élégante et plus générique que ce qui était demandé.

- j'ai dû faire en sorte qu'un formulaire puisse être édité par parties, sans qu'on puisse jamais modifier une partie déjà saisie. C'est à dire que les champs que l'on remplit à un moment ne sont plus modifiables par la suite. Le code qui fait ça doit représenter une trentaine de ligne avec beaucoup de redondance.


Je ne sais pas si ce sont des exemples très pertinent, mais ça montre que même quand tu es sous pression au niveau des deadlines, avec Rails tu peux bricoler des solutions rapidement et conserver une organisation propre et élégante. L'important là dedans, ce n'est pas le choix parfois discutable d'implémentation, c'est que les délais sont toujours de l'ordre de quelques heures, et qu'on ne se retrouve pas avec du code non maintenable à la fin.

Tu ne nous a pas donné beaucoup d'indications sur ce qu'étaient les besoins des utilisateurs, et la réponse à ta question va forcément en dépendre beaucoup.

Puisque tu envisages de générer du PHP/Mysql, je suppose que ma réponse pourra être pertinente. Généralement quand j'ai besoin de gérer des données (saisie, recherche, présentation), j'utilise Ruby, parce que c'est souple, rapide à programmer, et puissant. Si j'ai besoin d'une interface, j'utilise Rails pour faire une application web. Ça permet d'avoir très rapidement des trucs tout à fait fonctionnels, à défaut d'être très jolis.

Maintenant, c'est certainement moins facile d'accès que WinDev, et je ne sais pas ce que valent les éventuels IDE "clic-clic".

Note au passage que pour Evolution, l'antispam est aussi un plugin. Si on l'exclue de Claws, on l'exclue aussi d'Evo.

Tu dois retaper les six mots de passes précédents ?

(cf. journal si cette question vous semble idiote)

Autant j'ai compris ton post précédent (même si je soupçonne que la solution de facilité soit souvent choisie, plutôt que tester les hashes de tous les sous-mots), autant là je ne suis pas d'accord. Si on stockait les mots de passe en clair, quel que soit le moment où on les enregistre, ça serait un problème parce que les gens vont forcément les répéter ou réutiliser ailleurs.

S'ils vérifient que ton nouveau mot de passe ne contient pas les précédents, ça veut dire qu'ils les stockent en clair... quelle horreur.

Et quand tu vois une grand-mère qui se casse la figure dans la rue, tu lui demandes si elle utilise Windows avant de l'aider à se relever ? :)

En quoi est tu différent d'une vache dans un pré ?

Lui, il peut kicker les gens qui parlent en unicode sur IRC. La vache, elle peut pas.

Tu le fais déjà pour :
- Ta voiture (achat ou location)
- Ta connexion internet
- Ton agence de voyage (a moins que tu sois obligé d'aller à celle qui soit en bas de chez toi, auquel cas: mes condoléances)
- Ton avion (AirFrance, LowCost, Autres Compagnies mondiales, etc...)

Alors : En quoi ca te dérange de devoir le faire pour le train ?!

Parce que c'est chiant ?
Franchement, quand tu vas faire tes courses, tu compares vraiment le prix des boîtes de maïs ? Personnellement, je ne le fais que quand je suis un peu à court d'argent. Et c'est pareil pour le reste, moins je peux perdre de temps et mieux c'est.

C'est bien beau ces histoires du marché qui se régule tout seul parce que les acheteurs achètent toujours au meilleur prix, mais parfois les acheteurs ont autre chose à faire de leurs journées que d'écumer tous les marchés pour trouver le moins cher partout.

(Je sens qu'on va me répondre sur complètement autre chose en m'expliquant que c'est pas bien d'être communiste.)

Moi, j'aime bien le train, et je n'ai jamais eu de problèmes à la SNCF (en dehors des grèves que tout le monde subit régulièrement). J'ai même parfois compatis envers des employés de la SNCF qui devaient subir la colère d'imbéciles qui leur reprochaient à eux l'absence de leurs collègues ou le suicide d'un type sous un train.

J'ai certainement eu beaucoup de chance de ne tomber que sur le 0.1% de fonctionnaires sympas, mais j'espère que ça va continuer, car je n'ai pas spécialement envie de prendre l'avion pour les trajets de moins de 1000km. Et encore moins la voiture.

Les prix sont plus chers maintenant. J'ai un forfait souscrit à Bouygues en 2004, 45 minutes pour 15 euros. Si je changeais de forfait aujourd'hui, je ne pourrais avoir qu'une heure pour plus de 22¤. Ça fait 7¤ le quart d'heure supplémentaire, à condition de prendre un engagement sur deux ans. Quitte à prendre un engagement aussi long, j'aimerais bien ne pas y perdre d'argent...

Ça te garantit qu'il existe une limite supérieure au nombre de trains sur la ligne Paris-Lyon, pas qu'il existe une limite inférieure supérieure à 1 sur les lignes moins rentables.

Autrement dit, s'il est plus rentable de ne pas avoir de trains sur une ligne, c'est ce qui arrivera. Alors qu'avec un service public tu peux espérer qu'un gain sur une ligne très fréquentée puisse servir à payer une ligne peu rentable.

Dans le privé, on le rencontre tout le temps, mais pas au niveau de l'employé. Un peu plus haut, au niveau des orientations prises par l'entreprise.

Pour prendre un exemple familier à tous les gens du coin, Microsoft n'en a rien à foutre que ses logiciels soient buggués et troués, de toutes façons ils sont sûrs de les vendre.

Depuis quand Loic Le Meur est-t-il un geek ?

C'est... pas une réponse.

Je n'ai pas demandé si des universités utilisaient la licence BSD, j'ai demandé si certaines en avaient besoin pour des raisons valables, ce qui semblait être admis dans le message parent.

(Pour ceux qui considèrent que faire du code propriétaire est une raison valable, la réponse est évidente.)

Une université qui a besoin d'une licence comme la BSD pour ces étudiants est une université qui a l'intention de rediffuser le code généré par ses étudiants, sous une licence fermée. Je suis curieux de voir des exemples concrets qui sont moralement défendables.

Je trouve assez amusant de dire que des gens veulent "garder leur code pour eux" sous prétexte qu'ils t'interdisent de le garder pour toi [si tu rediffuses du binaire].

Quand on voit ce qui se passe avec la GPL 2 et la GPL 3, on se rend compte que le problème vient de quelque chose qui ne pouvait pas être prédit à l'époque de la rédaction de la première licence, et qui a apporté des modifications qui déplaisent à certains.

Admettons que tout le monde se soit entendu sur une seule licence, et admettons aussi pour le bien de la discution que c'était la GPL 2. Que faire quand le problème des applications webs ou des DRM se posent ? Soit on veut absolument ne conserver qu'une seule licence et donc on ne touche à rien, soit on crée une nouvelle version de la licence et les développeurs sont obligés de faire un choix.

Finalement la seule licence qui ne risquerait pas de demander des mises à jour sur des points imprévus serait celle qui permet tout.