La documentation compléte de cette fonctionnalité est sur le site de mongoid.
Grâce à cette fonctionnalité, on peut définir tout simplement qu’un champs de Mongoid est localizable. La gestion de la locale est faite de manière très intelligente et surtout en complète coordination avec MongoDB.
Contrairement à une gestion de traduction dans une Base de donnée relationnelle, qui créé une table de liaison, Mongoid stocke un hash avec la locale comme clé et la traduction comme valeur.
Mongoid n’a plus qu’à faire la glue entre le système pour que les accès en lecture/écriture en fonction de la locale et la recherche
]]>En gros faire plein de test comme si on jouait avec la prod mais sans toucher au donnée de production.
Le plus gros soucis que l’on rencontre et beaucoup d’entre nous l’ont rencontré, c’est l’envoi d’email. Tous les emails copié de la production sont valide et posséde un utilisateur au bout. Si nous envoyons un email réellement cela peut vite être problèmatique. Les solutions utilisées généralement sont les suivantes.
Une pratique simple est courant est la tâche qui remplace tous les emails de la base de donnée par des emails possédés par la société. Cette technique marche parfaitement, mais pose quelques problèmes :
Avec le framework Ruby on Rails, il est possible de définir que tous les emails envoyés sont mis dans un fichier plutôt qu’envoyer par SMTP. Il suffit de définir un nouveau smtp_delivery
1
| |
Cette technique permet d’être sûr qu’aucun email n’est envoyé au client finaux. L’inconvénient de cette technique est le stockage et la lecture des emails. Tous les emails sont stocké sous forme de fichier directement sur le serveur. Il peux donc être fastidieux de connaitre les nouveaux emails envoyés, car ils sont classé par destinataire. On peux ainsi ne pas constater qu’un email est envoyé sous certaine conditions. De même, si votre application est utilisé par des personnes n’ayant pas un accès shell à votre serveur, ils ne pourront pas lire les mails envoyés.
Cette technique est selon moi la meilleure actuellement. Elle consiste tout simplement à emuler un vrai serveur SMTP. Par contre, ce serveur ne transmet pas les emails qu’il reçoit. Il les stocke et vous permet de les consulter dans un client mail classique. Ils sont conservé entièrement.
L’avantage est que n’importe qui peux consulter les emails générés, sans aucune connaissance technique évolués et ils sont conservé entièrement.
A ma connaissance, il existe 3 produits qui permettent cela.
C’est un produit open source tres simple d’utilisation. Vous télécharger
le gem, vous lancer la commande mailcatcher et c’est fini. Vous avez
ainsi un serveur SMTP sur le port 1025 et un client mail sur le port
1080.
Je vous le conseille dans un environement de développement. Il a en plus quelques petits addons comme la notification growl.
Le seul soucis que j’ai rencontré avec est le deployement dans un
environement de staging. la commande mailcatcher ne permet pas
d’écouter sur toutes les interfaces. Il faut donc mettre un proxy devant
pour le rendre accessible à tout le monde. On doit donc le maintenir et
le gérer. Cela peux être un peu compliqué juste pour un simple mock.
Bien sûr rien ne vous empêche de le faire.
Voici un projet que j’ai découvert que très récement. Le concept est exactement le même que celui de mailcatcher, sauf que vous n’avez plus à gérer l’hébergement vous même. Tout est géré par railsware, l’éditeur de ce service.
Vous créer un compte sur leur site, vous créer un serveur SMTP fictif et c’est fini.
Vous obtenez les informations de connection à ce SMTP. Une fois que vous définissez ces paramètres dans votre application, tous les emails seront envoyé directement à Mailtrap.
Une gestion de collaboration sur les mailbox vous permet d’ajouter vos collaborateur à cette mailbox pour qu’ils puissent voir les emails.
Cette solution est vraiment simple a mettre en oeuvre et très pratique. Petit plus, c’est encore gratuit actuellement. Donc profitez en.
]]>
Le 21 Juin se tiendra à Paris un événement auquel je vous invite à venir. Cet événement sera dédié à MongoDB, le MongoFR.
J’ai la chance de pouvoir proposer une petite conférence sur un retour d’expérience : ma migration de SQL à MongoDB sur Oupsnow. Hormis les développeurs de 10Gen, il n’y aura que des Rubyists.
Selon moi, cette nouvelle technologie qu’est MongoDB est assez prometteuse.
Pour découvrir MongoDB, venez nombreux le 21 Juin !
]]>J’ai donc commencé à regarder un peu dans quels cas utiliser EventMachine. La première application que j’en ai trouvé c’est tout simplement le PeriodicTimer.
Son utilisation la plus simple est le remplacement d’une cronjob.
Je m’explique : une cronjob est vraiment une très bonne chose. On peut définir très précisément l’heure à laquelle on souhaite qu’une tâche s’exécute. Celle-ci s’exécute alors à ce moment précis. Cron est vraiment un outil magnifique. Cependant, dans le cas d’une tâche récurrente qui doit être effectuée régulièrement, l’utilisation d’un cronjob peut avoir un gros inconvénient.
Cron n’a aucune gestion de queue. Ainsi on peut se retrouver très simplement avec une quantité astronomique de tâches essayant de s’exécuter en même temps. Votre « load » explose et il faut redémarrer votre serveur. Bien sûr cela n’arrive que si vous lancez une tâche plus fréquemment que son temps d’exécution.
La seule solution serait d’avoir une petite application - comme : jobq - qui gére pour vous un système de queue. Bien sûr, si le fait d’avoir une queue ne sert strictement à rien, cette solution peut être un peu overkill.
L’avantage de PeriodicTimer est que les tâches sont exécutées après un temps défini. Il n’y a aucune gestion d’heure de lancement. Il y a juste un lancement de la tâche après X secondes une fois que la précédente tâche est finie et qu’aucune autre tâche ne soit en cours d’exécution. Cela entraîne effectivement un glissement progressif de l’heure de lancement. Mais globalement, ça ne pose aucun problème. L’important est que la tâche soit exécutée régulièrement. C’est le cas, par exemple dans le cas de récupération de statistique.
Voici un exemple de code qui utilise PeriodicTimer
1 2 3 4 5 6 7 8 9 10 11 12 | |
Voici la sortie qui est effectuée si on lance l’application pendant 50s.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | |
On peut constater que la tâche qui doit s’exécuter toutes les secondes le fait bien. Par contre la tâche qui s’exécute au bout de 10 secondes effectue un lock sur le thread. Ainsi la tâche qui s’exécute toutes les secondes attend que le lock soit libéré. Une fois terminée, l’exécution de la tâche toutes les secondes recommence. La tache qui doit s’exécuter toutes les 10 secondes attendra, quand à elle, 10 nouvelles secondes après avoir été terminée.
C’est là une grande puissance de PeriodicTimer. On a facilement une succession de tâche qui ne se marchent jamais sur les pieds. Désormais, je n’utilise plus que
cette solution pour créer des scripts de récupération de données.
]]>Enfin comme d’habitude voici mon fichier capistrano de déployement pour faciliter celui-ci.
<typo:code lang=”ruby”> set :application, “oupsnow” set :repository, “git://github.com/shingara/oupsnow.git” set :domain, “dev.shingara.fr”
set :deploy_to, “XXXXXXXXX”
set :scm, :git set :git_enable_submodules, 1
set :runner, “xxxx” set :user, “xxxx” set :use_sudo, false
set :thin_conf, “/etc/thin/#{domain}.yml”
set :rails_env, “production”
role :app, domain role :web, domain role :db, domain, :primary => true
task :update_config, :roles => [:app] do run “ln -s #{shared_path}/config/database.yml #{release_path}/config/database.yml” run “ln -s #{shared_path}/config/email.yml #{release_path}/config/email.yml” run “ln -s #{shared_path}/config/initializers/errornot.rb #{release_path}/config/initializers/errornot.rb” run “cd #{release_path} && echo ‘GOOGLE_ANALYTICS="XXXXXXXX"’ >> config/environment.rb” end
namespace :deploy do task :start, :roles => [:app] do
run "thin -C #{thin_conf} start"
end
task :stop, :roles => [:app] do
run "thin -C #{thin_conf} stop"
end
task :restart, :roles => [:app] do
run "thin -C #{thin_conf} restart"
end end
task :update_db do run “cd #{current_path} && RAILS_ENV=#{rails_env} rake db:update” end
after “deploy:update_code”, :update_config after “deploy:symlink”, :update_db </typo:code>
]]>Tout le monde est en droit de se poser la question. Voici donc, pour moi, l’avantage de Ruby par rapport aux autres technologies à l’heure actuelle.
Matz, quand il a créé Ruby, a voulu faire un langage fun avec lequel il pourrait s’amuser à coder. Aujourd’hui tous les développeurs Ruby diront à peu près la même chose. Coder en Ruby est plaisant. L’avantage de ce point est qu’un développeur Ruby est plus détendu. Un développeur détendu est un développeur plus heureux. Un développeur plus heureux est motivant pour une équipe. Un développeur heureux essayera de faire son travail proprement. L’ambiance d’une équipe de développeur Ruby peut ainsi être agréable. Moins de stress sur un projet, c’est un projet qui part avec un peu plus de chances de réussir.
La communauté Ruby actuelle est convaincue de l’utilité des tests unitaires. Ainsi, chaque librairie est poussée par la communauté à avoir des tests. Beaucoup de développeurs, moi y compris, privilégierons une librairie avec des tests unitaires plutôt qu’une sans aucun tests.
Cette philosophie permet d’avoir un environnement de développement de test simplifié directement dans Rails. Pas besoin de se prendre la tête pour faire des tests. Si vous ne faites pas de tests de base : soit vous ne voulez pas en faire, ce que je ne recommande pas, soit vous le faites exprès.
En ce moment, l’évolution logique du net est le Cloud Computing. L’idée du Cloud Computing est simple. Nos sites internet ne sont plus hébergés sur une seule machine. Les services sont séparés pour améliorer la scallabilité. Au sein de la communauté Ruby, les développeurs sont très attachés à cette idée. Ainsi beaucoup d’utilitaires pour gérer et utiliser son cloud commencent à voir le jour comme Chef. L’architecture même de Rails permet de facilement sortir de Ruby On Rails pour ainsi utiliser son Cloud. ActiveRessource en est la preuve.
Mais coder dans un Cloud implique de coder plusieurs briques. Le Ruby a des bindings pour tous ces utilitaires, comme les systèmes de queues ou les bases de Données Non-Relationnelle. Je ne dis pas que les autres ne peuvent pas le faire. Mais là encore c’est un effet de groupe. Chaque développeur ruby a envie de jouer avec un Cloud. On pense de plus en plus en cloud.
Ruby On Rails possède une très grande quantité de plugins. On peut ainsi facilement trouver la petite brique que l’on cherche pour sa propre utilisation. C’est plus que l’utilisation d’un module Drupal. Car là nous sommes dans un environement facilement modifiable et sans aucune limitation. Chose que Drupal peut vite avoir.
Le plus grand reproche que l’on fait actuellement au choix de Ruby On Rails, c’est le manque de ressources. Effectivement, les ressources de développeurs Ruby sont plus faibles que pour d’autres langages. Mais ceci est selon moi un faux problème. L’apprentissage de Ruby et Ruby On Rails est assez simple si on connait la logique Objet. Ainsi, n’importe quel développeur Java peut tout à fait se mettre à Ruby et Ruby On Rails. Donc avec un expert Ruby/Rails, on peut former facilement une équipe complète et compétente.
Cet argumentaire n’engage bien sûr que moi et peut donc être sujet à caution.
]]>Le nom de l’entreprise est toujours pratique ne serait-ce que pour zapper l’annonce si on aime pas cette entreprise. Ou alors rigoler encore plus en lisant l’offre d’emploi.
C’est toujours agréable de savoir si on va travailler pour une entreprise qui fait du beurre ou des sites Web. On peut ainsi éviter certains entretiens inutiles.
C’est une question plutôt inhabituelle pour un recruteur, mais avoir cette information permet de savoir tout de suite si on sera le geek dans son coin qui sera interrompu pour faire de l’assistance Words alors qu’il n’a plus touché à un windows depuis 3 ans. Au contraire, si on voit qu’il y a une majorité de développeurs, on pourra se dire que ça sera la fête aux trolls. Un développeur aime les Trolls \o/.
Comme dans tous métiers, on connaît certaines personnes de réputation. Cela peut facilement aider un développeur à choisir cette offre d’emploi si une personne connue y est. En revanche, c’est aussi à double tranchant. Certains feront l’entretien juste pour voir cette personne. D’autres zapperont encore plus l’offre d’emploi à cause de cette même personne.
L’OS utilisé en majorité par les développeurs de la société peut être un très bon indicateur parfois. Typiquement chez AF83 où je travaille encore en ce moment, tous les développeurs sont sous UNIX, soit GNU/Linux, soit MacOSX. Pour beaucoup, cela prouve la qualité des développeurs. Et là encore la guerre aux trolls pourra facilement être ouverte.
Avoir du temps pour faire de l’Open Source selon notre désir est un plus non négligeable selon moi. J’ai énormément de projets open source en cours que je fais en parallèle de mon emploi, mais si je pouvais les faire aussi durant une partie de celui-ci, je serais vraiment heureux. Ensuite le fait que la société produise du code Open Source, peut facilement permettre au développeur de jauger de la qualité du code de cette société. En effet, pourquoi est-ce toujours la société qui doit vérifier le code de ses futurs employés ?
Selon, moi ces 6 points ne sont hélas pas toujours renseignés dans une offre d’emploi et cela serait un plus non négligeable.
]]>A chaque release, une nouvelle admin fait son apparition, mais à chaque fois elle est meilleure que la précédente, donc c’est une excellente chose.
J’ai bien-sûr mis à jour ce blog et j’ai aussi switché sur le nouveau thème par défaut. Je suis toujours aussi nul en design.
En petit cadeau, voici mon fichier capistrano que j’utilise pour déployer ce blog. Ça peux toujours vous servir. On ne sait jamais.
Cette nouvelle version, outre son refactoring comprend aussi l’ajout de quelques nouvelles fonctionnalités.
Vous pouvez télécharger cette version sur rubyforge
Si vous souhaitez tester cette version, une version de demo de oupsnow est en ligne. Les login/mdp sont : admin@admin.com/oupsnow. Amusez vous bien.
]]>Il suffit d’inclure Devise::TestHelpers. Ensuite pour se logger avec un utilisateur, on utilise la méthode sign_in. La méthode sign_out existe aussi.
Le plugin d’authentification le plus connu à l’heure actuel est Authlogic. Ce plugin est vraiment très performant, mais tous les essais de le rendre ORM Agnostique ont été vain. C’est alors qu’au même moment, durant le Rails Summit 2009, George Guimarães et Carlos Antonio annoncent la sortie de Devise, un plugin Rails au dessus de Warden ( Rack middleware d’authentification). C’est exactement, ce qu’il me faut, un nouveau système d’authentification a tester et peut-être une possibilité d’ajouter une couche d’ORM Agnostique dedans. En plus Warden étant un RackMiddleware, je pourrais un peu tester ce que ça donne.
J’installe donc Devise et commence à l’utiliser dans Oupsnow. Tout se passe à merveille, jusqu’au moment où il faut faire les tests. Tout de suite le bât blesse. Les tests controlleurs de Rails ne communiquent pas avec la couche Rack qui n’est pas initialisée. On se retrouve donc avec une impossibilité de définir si un utilisateur est loggé ou non et si oui, qui est cet utilisateur.
Après de nombreux tests et essais. J’ai fini par trouver comment faire.
Warden ajoute à la requête une variable d’environment dans la requête. On peux
y accéder par
request.env['warden']. Il suffit donc de remplir cette
variable.
Pour avoir un utilisateur non loggé, il faut faire :
Pour se logger avec un utilisateur en particulier il faut faire :
Personnellement, j’aime beaucoup devise. A tel point que j’ai permis de le rendre ORM Agnostique et compatible avec MongoMapper.
EDIT du 30 Novembre 2009: la technique indiquée ici n’est pas optimum et ne marche pas avec les dernières versions de Devise. utilisez plutôt la technique décrite dans mon ticket Comment tester devise ? réélement ?
]]>Alors que je finissais une migration de SQL à MongoDB, j’en entame une nouvelle. Celle-ci beaucoup plus profonde.
La raison de ma migration ?
Rails 3. En effet, depuis Décembre 2008, soit presque un an, Merb s’est figé. Certain me diront que la communauté Merb est en train de revivre et c’est tout à fait vrai. J’en suis même ravi. Mais Merb a pris un immense retard en presque un an. Même si Rails n’a pas vraiment avancé dans sa version stable, sa version Edge a elle énormément avancée.
Voulant toujours tester les nouvelles technologies en Ruby, je voudrais tester Rails 3. Mais aucun système n’existe pour passer de Merb à Rails 3. Un rapide test m’a montré que la différence était par contre minime entre Rails 2.3.x et Rails 3. La migration de Rails 2.3.x à Rails 3 en sera donc d’autant plus simple.
Voulant vraiment sortir une version stable le plus vite possible, j’ai donc pris la décision de migrer Oupsnow vers Rails 2.3.x pour ensuite migrer sur Rails 3 pour cette fois sortir une version de Oupsnow compatible Rails 3.
Oupsnow devient donc un projet Rails/MongoMapper et non plus Merb/DataMapper comme sa dernière version. Toute aide est bien-sûr la bienvenue.
]]>rabbitmqctl. Prévoyant une migration vers Mac OS Snow Leopard et n’ayant pas un besoin urgent de RabbitMQ, j’ai repoussé la recherche du problème.
Mais voilà, maintenant que je suis sous Mac Os Snow Leopard, j’ai réinstaller RabbitMQ pour le réutiliser à nouveau. Et là, surprise toujours le même soucis. Après de longue recherche, je viens enfin de trouver la cause, le hostname.
Que faire si votre noeud de contrôle rabbitMQ n’arrive pas à discuter avec le noeud maitre ?
Très simple, faite un simple hostname -s et ajouter ce hostname en concordance de l’ip 127.0.0.1 dans votre fichier /etc/hosts. Ça y est tout fonctionne. C’est parfois tellement simple la résolution d’un problème.
Par défaut, on l’utilise en fournissant une string en paramètre comme ceci : Logger.debug("My object is #{self.map(&:id)}").
La différence entre ces deux écritures ?
La première permet d’éviter d’évaluer la chaine qui sera loggé si elle n’en a pas besoin. Contrairement à la deuxième qui sera toujours évaluée même si vous ne la loggez pas. Ainsi le temps de traitement pourrais s’en faire ressentir.
Grâce à ça, on peux facilement éviter les fameux :
En effet, ce genre de code est très fréquent en Java, pour gagner un petit peu en performance sans perdre ses logs.
]]>Pourquoi Rspec au lieu de Test::Unit ?
C’est vrai que je suis un adepte de Rspec et que je n’utilise que ça si c’est possible. mais je n’ai jamais expliqué ici clairement ce qui me pousse dans ce choix. Donc voici un résumé très bref de mon choix.
Une des options méconnues de Rspec est la possibilité de définir son formateur. Il existe ainsi plusieurs formateurs base. On peux ainsi avoir un retour direct sous format HTML ou text avec les points ( classique avec Test::Unit). Mais certain formateur peuvent aussi calculer le temps que dure un exemple. Ainsi nous avons une facilité de détection des test les plus lent pour les refactorer et essayer d’améliorer le temps de réalisation de ses tests. Dans ce sens, j’ai moi même créer mon propre formateur Rspec.
Rspec dispose d’une possibilité sous estimés, les tests partagés. En effet, on peux définir certain jeux de test comme “partageable” on a ainsi la possibilité de les incorporer facilement dans divers tests. C’est une fonction vraiment pratique dans le cadre de test fonctionnel principalement. Plus besoin de copier/coller son code. :)
Le passage a Rspec est assez aisé de part sa compatibilité avec Test::Unit. En effet, si vous n’êtes pas familier ou que vous n’aimez pas la formalation my_array.should be_empty, rien ne vous y oblige. Vous pouvez tout à fait utiliser la syntaxe Test::Unit assert my_array.empty?. La migration s’en trouve très largement aisée.
En tout cas je suis très heureux de pouvoir y présenter une petite conférence sur Cucumber. J’espère vous y retrouver.
]]>De fil en aiguille, le code s’est agrémenté et est surtout passé à Merb avec un système de persistance en CouchDB.
L’idée de base est extrêmement simple, gérer plein de notification de tous type. Il existe déjà ce genre de système comme messagepub. Mais là ca sera open source.
Open notification sort donc en version 0.1.0 pour sa première version. Le code sera mis sous licence AGPLv3. Il est composé d’un agent nanite qui gére l’envoi des notifications jabber et d’une application avec Merb/CouchDB.
La méthode de déploiement est assez compliqué je l’avoue car il n’y a aucune documentation. Cela arrivera dans les prochaines versions.
Une version complête est utilisable par tout un chacun sur open-notification.com. Ce service n’a pour l’instant aucune pérennité. Mais on verra dans le futur ce que ca donnera.
]]>Pour ceux qui ne le savent pas dm-sweatshop est un gem de génération de donnée, inspiré de Factory Girl.
Factory Girl a été conçu pour éviter les fixtures dans Rails. Il a aussi l’avantage de permettre une meilleure vue des données présentes dans sa base de donnée durant son test. Je conseille tout à fait son utilisation et migre progressivement tous mes tests à l’utilisation de ce genre d’outil.
dm-sweatshop est le Factory Girl dédié à DataMapper, même si Factory Girl peux tout à fait être utilisable avec DataMapper.
dm-sweatshop contrairement à Factory gril, génére un Hash d’attribut, qu’il surcharge avec les données fournis et génére un objet à partir de ce hash. Ceci entraine par exemple, l’impossibilité d’utiliser les méthodes d’association, il faut directement associer les identifiants.
Mais là où est son petit plus est que justement à cause de cette génération d’un Hash, il y a un Proc qui est généré et rien n’empêche de mettre du code ruby pour générer d’autre objets ou récupérer des objets déjà existant. On peux ainsi écrire l’exemple suivant :
Dans cette exemple, je crée un objet Membre qui est la liaison entre un Projet et un User. Mais au préalable, j’ai récupéré et créé des éléments Projet et User si rien n’existait.
Grâce à dm-sweatshop, c’est enfin fini, les problèmes de multiples liaisons qui avec Factory Girl ne peuvent être contourné (d’après mon expérience en tout cas) ce qui entrainait la création de méthode complète pour créer tout ça. Désormais tout est au même endroit.
Je ne saurais donc vous encourager à utiliser dm-sweatshop sur tout projet DataMapper à la place de Factory Girl.
]]>Dans Rails, il y a au premier abord une fonctionnalité vraiment intéressante. L’Observeur. Grâce à lui, on peux définir une classe qui vérifie le comportement d’un model et effectue certaine action suite à ses observations. Il permet d’ajouter des événements avant/après l’enregistrement, la mise a jour ou la destruction d’un model.
Pour mettre en place un observeur, il suffit de créer une classe héritant de ActiveRecord::Observer, mettre son code dedans et la définir comme observeur dans le fichier environment.rb. Rien de plus simple et ça marche très bien.
Mais Rails a déjà intégré dans ses models, les fonctions de callback utilisé par le observeur. En effet, on peux tout à fait définir N action after_save ou before_create. Ces méthodes seront appelés à l’événement voulu.
C’est là où je dis que le callback est plus intéressant que l’observeur. En effet, un callback fait exactement la même chose qu’un Observeur. Mais lui au moins on sait qu’il est là. En ouvrant la classe on découvre le callback. Pour détecter un Observeur, il faut regarder les fichiers de config de Rails et ouvrir une à une les classes Observeurs.
Même le cas du nombre de ligne n’est pas réel car il est tout à fait possible de sortir ses callbacks dans des modules. De même pour une réutilisation sur plusieurs classes. Le module le permet sans problème.
Personnellement, je n’ai jamais constater un seul cas où l’observeur avait plus d’intérêt que des callback. Si vous en trouvez, je suis vraiment curieux.
]]>
Cela est aussi vrai pour les utilisateurs de Merb. En général pour les utilisateurs de Merb, vous avez utilisé le plugin merb_cucumber de Roman. Hélas celui-ci a un générateur incomplet à l’heure actuel. En effet, la tâche rake features n’utilise pas les bonnes options pour cucumber.
Après un long et rude combat avec cucumber, j’ai fini par trouver les options adéquates pour avoir le même comportement que pour les précédentes version de Cucumber. Pour voir un exemple en “live” sur une application, vous pouvez regarder mon commit sur Oupsnow. Sinon, j’ai forké le merb_cucumber de roman, et ajouter un patch pour permettre l’utilisation de Cucumber 0.3.4 et plus
EDIT : Mes modifications de merb_cucumber ont été intégré dans la branche de Roman
]]>