Pour XMPP, l'utilisation systématique d'UTF-8 est quasiment une conséquence directe de l'utilisation de XML partout. En particulier, la différence de performances des encodages doit être négligeable devant le temps de sérialisation/désérialisation XML.
[troll mode="violent"]
Comme indiqué dans le titre, je ne m'intéresse qu'aux technos web cools, et Symfony 2 ne rentre définitivement pas dans cette catégorie.
Déjà, il utilise les namespaces PHP avec des backslashs : namespace Bundle\HelloBundle\Controller;
use Symfony\Framework\WebBundle\Controller;
Les templates sont moches avec encore des <?php echo $name ?> (je pensais que ça ne se faisait plus depuis au moins 10 ans).
Les benchmarks qui ont servis à annoncer des performances aussi flateuses n'ont visiblement pas été faits avec la rigueur nécessaire à cet exercice : http://paul-m-jones.com/?p=1222
Pas un mot sur la sécurité. C'est vrai, c'est un détail pour faire des applications web.
L'utilisation de bases de données NoSQL ? Hum, rien non plus...
Sérieusement, il y a un seul truc cool dans tout ça ? Ou c'est juste une reprise en PHP des principes qui ont fait le succès de Django et Rails ?
[/troll]
Python Twisted: Non-blocking server in Python. Unfortunately it ate a lot of CPU and could not scale
Source : http://amix.dk/blog/post/19456
http://nodejs.org/#about explique également que Node.js intègre le modèle événementiel au cœur du langage, et pas simplement comme une bibliothèque. Cela a des conséquences comme le peut voir comme des avantages. Par exemple, il est quasiment impossible de faire un appel système bloquant.
> « un milliard de message jusqu'à maintenant » depuis quand ?
Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.
> Ça ne fait pas de présence ?
Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.
> Quel hardware/puissance ?
1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic level. node.js uses around 10x less than that).
> A prioiri donc, beaucoup moins de mémoire, un petit plus de CPU... quoi d'autre ?
Je ne connais pas Netty, mais d'après amix, node.js propose une API de plus haut niveau que Netty, et est donc plus facile à utiliser.
Ou pas. Plurk arrive bien à tenir les 100 000 connexions simultanées avec un seul serveur grâce à Node.js (source : http://news.ycombinator.com/item?id=1088699 ). Donc il n'y a pas forcément besoin d'acheter plus de matos.
Ça dépend des bases de données NoSQL. Redis ressemble très fortement à du memcached, il est "juste" plus rapide, a un jeu d'instructions un peu plus étendu et surtout a une notion de persistance. Quand on relance memcached, on a perdu toutes les données, alors que l'on retrouve toutes ses données quand on relance Redis. Ceci dit, redis reste très proche de memcached.
Par contre, il existe d'autres bases de données NoSQL qui n'ont pas grand chose à voir avec memcached. Par exemple, MongoDB est beaucoup plus proche d'une base de données SQL que de memcached. On peut faire des requêtes avec des opérateurs évolués et une sémantique qui s'inspire en parti du SQL (table <-> collection, colonne <-> champ, des critères de tri, ORDER BY <-> sort(), limit & offset <-> limit() & skip(), etc.). En pratique, des requêtes sur MongoDB, ça ressemble à ça :
On a regardé rapidement du coté RDF, mais ça n'a pas donné grand chose. Pour certains outils, nous n'avons même pas réussi à les installer. Pour les autres, nous n'avons pas été convaincus par l'utilisation : rien que des cas simples comme récupérer toutes les informations pour la fiche d'une œuvre d'art semblaient déjà très complexes avec ces outils. Donc, on a assez rapidement laisser tomber cette possibilité.
Dans le même style, il existe showoff [http://github.com/schacon/showoff], qui a pour gros avantage que l'on écrit ses slides avec la syntaxe Markdown. On peut ensuite les personnaliser avec du CSS et du JS.
Marrant, j'entends souvent cette remarque, mais dans l'autre sens. Les personnes impliquées dans le mouvement NoSQL considère que le SQL, ça permet de faire pas mal de choses, mais pas tout, et pas toujours très bien. Il est donc important d'avoir le choix dans le type de sa base de données, et de pouvoir choisir la base qui conviendra le mieux à ses besoins.
On peut alors être facilement effaré par ceux qui choisissent systématiquement des bases SQL sans se poser de questions, et essaye d'y mettre de force toutes leurs données même quand ça s'y prête très mal. J'ai déjà vu des gens utiliser MySQL pour des blobs binaires, des files d'attente, des données faiblement structurées (avec des tables 'objects', 'attributes', 'relations', 'contexts'...), et ça donne vraiment l'impression de considérer tous les problèmes comme des clous que le marteau SQL pourra enfoncer...
> Par contre, dans tout ce qui est grosse base de données au sens classique du terme ( banques et autres ) c'est tout sauf adapté.
Au contraire, pour les vraiment grosses bases de données, les bases NoSQL conviennent bien. De ce coté, on parle beaucoup moins de CouchDB, MongoDB, Riak, mais hbase/hadoop, cassandra et voldermort ont clairement la côte. J'ai entendu parler d'une société française dans le monde de la finance qui utilise voldemort pour traiter des petabytes de données.
Oui et non. Il n'y a pas à proprement parler d'index, mais les views remplissent un rôle similaire et permettent d'avoir des performances tout à fait correctes.
Quand on veut aller chercher des données dans MongoDB, on écrit une requête qui ressemble à une requête SQL. Par contre, pour CouchDB, il faut d'abord comprendre le système de map-reduce (et rereduce). Quand j'ai commencé à utiliser MongoDB, au bout de 5 minutes, j'avais compris comment faire des requêtes assez simples. Par contre, il m'a fallu un paquet de temps pour comprendre le map-reduce de CouchDB (et encore, je ne l'ai toujours pas totalement assimilé).
> Pas de migration pour le schema, certe, mais j'imagine que tes données, tu dois les migrer quand même?
Oui, bien sûr, mais ça reste un cas assez rare. Dans beaucoup de cas, les migrations SQL que je fais consistent surtout à ajouter une nouvelle table ou à ajouter une nouvelle colonne avec NULL comme valeur par défaut. Et pour faire l'équivalent à MongoDB, il y a juste rien à faire.
C'est aussi particulièrement agréable pendant la phase de développement.
Dans la société où je travaille, on développe des applications web, et on a eu l'occasion d'utiliser CouchDB sur un de nos projets. Le projet en question vise à devenir une sorte de wikipedia de l'art.
Nous avons donc des artistes, des fiches sur les œuvres d'arts, des périodes historiques, des lieux, et des relations entre tous ces objets (du genre tel tableau a été inspiré par le travail de tel artiste). Chaque fiche comporte des informations qui doivent notamment permettre des recherches. Ces informations rentrent plus ou moins bien dans des champs. Par exemple, si on prend le champ 'dimensions', il ne sera pas rempli de la même façon pour un tableau (2 dimensions) que pour une statue (3 dimensions). Pour les dates, nous avons parfois quelque chose de très précis (le 11/02/1827) ou au contraire de très imprécis (environ 400 ans avant JC). Enfin, il y a une multitude de champs possibles, mais généralement qu'une petite partie de ceux-là sont remplis. Cela vient notamment du fait que selon le type de l'œuvre, de nombreux champs ne sont pas pertinents : le champ "encadrement" s'applique bien à un tableau, mais pas vraiment pour une statue. Il arrive également qu'un champ est généralement une seule valeur, mais que dans certains cas ait plusieurs valeurs. Par exemple, on pourrait avoir plusieurs dimensions pour une œuvre qui serait en plusieurs parties.
Au final, si on avait essayé de faire rentrer toutes ses informations dans une base de données SQL, je vous laisse imaginer le nombre monstrueux de tables qu'il aurait fallu (ou alors, une quantité folle de colonnes et de NULL dans ces colonnes), et récupérer une fiche aurait nécessiter une requête SQL d'une complexité que je ne préfère pas imaginer. Nous nous sommes tournés vers CouchDB qui nous a permis de faire ça efficacement. Nous ne regrettons absolument pas ce choix, mais si nous avons rencontrés quelques défauts de jeunesse de CouchDB.
Pour avoir tester les deux (MongoDB et CouchDB) sur des applications wev, je recommande très fortement de commencer par MongoDB. C'est plus proche du monde SQL et, du coup, beaucoup plus facile à prendre en main. En plus, je n'ai pas trouvé de gros avantages à CouchDB par rapport à MongoDB.
Pour ce qui est des avantages du MongoDB sur les bases de données relationnelles, ils sont nombreux et je ne vais en citer que quelques uns :
- pas de schéma, et donc pas de migrations pour modifier le schéma
- les types composés (tableau et hash) sont bien pratiques
- c'est impressionnant de rapidité (en comparaison MySQL se traîne comme un escargot)
- on peut ajouter des index sans tout bloquer pendant des heures (http://www.mongodb.org/display/DOCS/Indexing+as+a+Background(...)
- ça supporte bien de grosses quantités de données.
La nouvelle version en RoR devait effectivement sortir fin de l'année dernière, mais j'ai pris du retard. Notamment, j'étais parti sur Rails 2.3, et j'ai remonté un certain nombre de patchs pour corriger des bugs qui trainent dans le bugtracker. J'ai donc décidé de passer à Rails 3, qui lui aussi est en retard. Bref, ça n'a quasiment pas avancé depuis 2 mois, mais là, avec la sortie de Rails 3 en beta cette semaine, je vais m'y remettre. J'espère pouvoir mettre en ligne cette version d'ici 2 mois.
Pour ceux qui veulent jeter un coup d'œil au code, ça se passe sur http://github.com/nono/linuxfr.org (github a l'air d'avoir des problèmes en ce moment, si ça doit durer, je mettrais un miroir ailleurs).
Sinon, j'ai effectivement très peu communiqué sur cette version. Je suis seul, et communiquer prend du temps (il faut répondre à tous les trolls du genre « c'est du rails, ça tiendra jamais la charge »). Et ce temps, je préfère le consacrer à coder.
Pour ma part, j'ai appris qu'il y avait une émission sur LinuxFr.org vers 14h30 en lisant cette dépêche. Donc, ça ne laissait pas vraiment le temps de mettre une tribune en place.
> Quoi qu'il en soit, j'ai aussi repéré Pylons, TurboGears ou encore Merb
Je te déconseille de partir sur Merb. C'est un très bon framework, mais peu documenté, et surtout, qui ne va plus évoluer. Les équipes de Ruby on Rails et de Merb ont décidé il y a un an d'unir leurs efforts pour fournir une nouvelle version majeure de Rails qui fournirait le meilleur de Rails et le meilleur de Merb.
Depuis, Merb et la branche stable de Rails (Rails 2.3) ont très peu bougé, les développements se sont concentrés sur Rails 3, dont une version beta devrait sortir d'ici peu (première quinzaine de février dit ma boule de cristal).
Comme très peu de personnes ont essayés Rails 3 pour le moment, il est encore assez difficile de savoir si Rails 3 sera une grand réussite ou un flop. Les premiers articles que l'on commence à voir sont très enthousiastes et montrent que l'API de Rails a profondément évolué entre Rails 2.3 et Rails 3. Il faudra donc sûrement réapprendre pas mal de choses pour suivre ce changement, et il serait donc dommage d'acheter maintenant un livre sur Rails. Par contre, ça me semble être une bonne période pour apprendre Ruby ;-)
Sylvain Durif souhaite utiliser son droit de réponse. Voici son commentaire :
« La diffamation publique par voie de presse est un délit passible de sanctions pénales.
(art. 29 à 35 bis de la loi du 29 juillet 1881)
Je ne mettrai plus les pieds sur votre site tant que le délit pénal y sera largement toléré.
Je reviendrai seulement quand j'y serai invité dans l'éthique la plus absolue pour travailler dur à la mise au point d'Elvita si toutefois vous avez les compétences pour faire et la motivation d'aller jusqu'au bout de ce difficile défi.
Je vous remercie de confirmer à Olorim, Chocho et Kowalski qu'ils commencent à comprendre ce qu'est Elvita avec quelques autres.
Oui il s'agit d'une technologie qui surpasse de loin les spécifications d'IPv6 et qui se rapproche d'un méta-moteur intelligent d'accès temps réel à l'information utile gérant les priorités de la personne en temps réel en fonction des multiples contraintes identifiées. Dites leur que tout est prêt pour réaliser cela au plan technologique, il suffit de marier les compétences des scientifiques des différents domaines concernés et des différentes techniques dans le cadre d'un prototypage évolutif pour faire effectivement une technologie transparente accessible par téléphone, GPS, PC internet, etc... sur un mode d'interrogation proche de celui de Kit de la série K2000, excepté qu'Elvita sera accessible via le remplaçant de l'iPhone (une téléphone miniature Open Source que j'ai imaginé - Zpearl) et via tous les accès possibles (téléphone fixe, téléphone mobile, cabine téléphonique, GPS, iTV, bornes interactives publiques, etc...).
Ce que je recherche c'est un équipe pour développer la technologie qui sera hébergée sur une infrastructure 32 millions de core à terme et déclinée sous forme d'un OS TR Linux spécifique (support de 7 milliards d'usagers et de 32 millions de cores), d'une puce incluant l'OS compatible téléphonie et PC, d'un MMPORG stratégie temps réel massivement parallèle (genre Entropia en beaucoup mieux), d'un périphérique de communication mobile miniature (Zpearl) Open Source et concurrent de l'iPhone et autres smartphones du marché. A préciser après étude d'architecture complète car les contraintes temps réel vont déterminer l'architecture cible. »
Patrick_g a déjà fait remarquer que ce journal porte sur le site publique et non pas la dépêche publiée (même si j'ai découvert le site via la dépêche en question), donc je ne vais pas m'attarder sur ça.
Si tu postes une dépêche, le risque que l'équipe de modération se moque de toi après avoir refusé ta dépêche est vraiment très faible : on reçoit régulièrement des dépêches maladroites, farfelues, parfois même insultantes, mais on essaye quand même d'en sortir des choses constructives : on réécrit certaines dépêches, on en améliore d'autres, on explique pourquoi on refuse une dépêche et surtout ce qu'il faut faire pour que les suivantes soient acceptées.
Par contre, si tu crains que l'on se fiche de ta poire, il faut effectivement mieux éviter de proposer des dépêches sur LinuxFr.org. Les lecteurs sont beaucoup moins tendres dans leurs commentaires, et j'ai déjà croisé des personnes qui ne veulent plus poster sur LinuxFr.org à cause d'une mauvaise expérience (ie essayer de faire des choses à un niveau local, communiquer sur ces actions sur LinuxFr.org, et ne recevoir comme commentaires que des messages très agressifs). Ces commentaires ne sont généralement le fait que de quelques lecteurs casse-pieds, mais fait plus de bruits que la large majorité des lecteurs silencieux.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.
* http://groups.google.com/group/nodejs/browse_thread/thread/d(...)
* http://groups.google.com/group/nodejs/browse_thread/thread/c(...)
* http://groups.google.com/group/nodejs/browse_thread/thread/6(...)
[^] # Re: Ou le vilain, il a oublié Symfony 2 :)
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 6.
Comme indiqué dans le titre, je ne m'intéresse qu'aux technos web cools, et Symfony 2 ne rentre définitivement pas dans cette catégorie.
Déjà, il utilise les namespaces PHP avec des backslashs :
namespace Bundle\HelloBundle\Controller;use Symfony\Framework\WebBundle\Controller;
Les templates sont moches avec encore des
<?php echo $name ?>(je pensais que ça ne se faisait plus depuis au moins 10 ans).Les benchmarks qui ont servis à annoncer des performances aussi flateuses n'ont visiblement pas été faits avec la rigueur nécessaire à cet exercice : http://paul-m-jones.com/?p=1222
Les outils décrits sur http://symfony-reloaded.org/tools doivent être intégrés à Django ou Rails depuis au moins 5 ans.
Pas un mot sur la sécurité. C'est vrai, c'est un détail pour faire des applications web.
L'utilisation de bases de données NoSQL ? Hum, rien non plus...
Sérieusement, il y a un seul truc cool dans tout ça ? Ou c'est juste une reprise en PHP des principes qui ont fait le succès de Django et Rails ?
[/troll]
[^] # Re: Quel est l'avantage de Node.js par rapport à Twisted ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.
Source : http://amix.dk/blog/post/19456
http://nodejs.org/#about explique également que Node.js intègre le modèle événementiel au cœur du langage, et pas simplement comme une bibliothèque. Cela a des conséquences comme le peut voir comme des avantages. Par exemple, il est quasiment impossible de faire un appel système bloquant.
Mais ce qui m'a vraiment convaincu de la pertinence de Node.js, c'est la présentation de Ryan Dahl (l'auteur de Node.js) à la jsconf : http://jsconf.eu/2009/video_nodejs_by_ryan_dahl.html
[^] # Re: Les adminsys en redemandent
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 4.
Bonne question ;-)
Je n'en sais rien.
> « un milliard de message jusqu'à maintenant » depuis quand ?
Plurk a été lancé en mai 2008, d'après http://en.wikipedia.org/wiki/Plurk. Mais j'imagine que de manière similaire a de nombreux services qui rencontrent du succès, la croissance est très rapide, et quasiment tout le trafic a été fait sur les 6 derniers mois.
> Ça ne fait pas de présence ?
Non, plurk ressemble plus à twitter qu'à de l'IM. Par contre, si tu as un lien qui explique pourquoi cette fonctionnalité est si demandeuse de ressources, ça m'intéresse.
> Quel hardware/puissance ?
1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic level. node.js uses around 10x less than that).
> A prioiri donc, beaucoup moins de mémoire, un petit plus de CPU... quoi d'autre ?
Je ne connais pas Netty, mais d'après amix, node.js propose une API de plus haut niveau que Netty, et est donc plus facile à utiliser.
[^] # Re: précisions diverses
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 2.
Arf, oui, je me suis fait avoir :/
> raphael c'est du SVG et pas du canvas non ?
J'étais persuadé que c'était du canvas, mais je viens de vérifier sur le site, c'est bien du SVG. Je corrige la dépêche.
Merci pour les précisions.
[^] # Re: Les adminsys en redemande
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 4.
[^] # Re: 2
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Les technos web cools du moment. Évalué à 7.
Ça dépend des bases de données NoSQL. Redis ressemble très fortement à du memcached, il est "juste" plus rapide, a un jeu d'instructions un peu plus étendu et surtout a une notion de persistance. Quand on relance memcached, on a perdu toutes les données, alors que l'on retrouve toutes ses données quand on relance Redis. Ceci dit, redis reste très proche de memcached.
Par contre, il existe d'autres bases de données NoSQL qui n'ont pas grand chose à voir avec memcached. Par exemple, MongoDB est beaucoup plus proche d'une base de données SQL que de memcached. On peut faire des requêtes avec des opérateurs évolués et une sémantique qui s'inspire en parti du SQL (table <-> collection, colonne <-> champ, des critères de tri, ORDER BY <-> sort(), limit & offset <-> limit() & skip(), etc.). En pratique, des requêtes sur MongoDB, ça ressemble à ça :
db.posts.insert({author: 'georges', title: 'foobar', body: 'blablabla', created_at: new Date('03-28-2009'), tags: ['titi', 'toto']});
articles = db.posts.find().sort({created_at:-1}).limit(10);
a_post = db.posts.findOne({}, {title: 1, body: 1});
db.posts.find({author:"george"}).count();
[^] # Re: Un exemple
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 2.
[^] # Re: css media presentation
Posté par Bruno Michel (site web personnel) . En réponse au journal Faire un diaporama commenté en HTML5. Évalué à 2.
[^] # Re: S5
Posté par Bruno Michel (site web personnel) . En réponse au journal Faire un diaporama commenté en HTML5. Évalué à 3.
[^] # Re: Question bête
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 3.
On peut alors être facilement effaré par ceux qui choisissent systématiquement des bases SQL sans se poser de questions, et essaye d'y mettre de force toutes leurs données même quand ça s'y prête très mal. J'ai déjà vu des gens utiliser MySQL pour des blobs binaires, des files d'attente, des données faiblement structurées (avec des tables 'objects', 'attributes', 'relations', 'contexts'...), et ça donne vraiment l'impression de considérer tous les problèmes comme des clous que le marteau SQL pourra enfoncer...
[^] # Re: Mongo sapin
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 2.
Rah, bien vu. C'est parti pour aller corriger ça dans la base de données...
[^] # Re: J'ai trouvé un site plein de références
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 3.
Au contraire, pour les vraiment grosses bases de données, les bases NoSQL conviennent bien. De ce coté, on parle beaucoup moins de CouchDB, MongoDB, Riak, mais hbase/hadoop, cassandra et voldermort ont clairement la côte. J'ai entendu parler d'une société française dans le monde de la finance qui utilise voldemort pour traiter des petabytes de données.
[^] # Re: La question que je me pose
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 3.
Oui et non. Il n'y a pas à proprement parler d'index, mais les views remplissent un rôle similaire et permettent d'avoir des performances tout à fait correctes.
[^] # Re: Mongo sapin
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 2.
Ça se discute. Il y en a un paquet sur http://linuxfr.org//2009/05/05/25414.html.
> Mongo plus proche de SQL? Tu peux développer?
Quand on veut aller chercher des données dans MongoDB, on écrit une requête qui ressemble à une requête SQL. Par contre, pour CouchDB, il faut d'abord comprendre le système de map-reduce (et rereduce). Quand j'ai commencé à utiliser MongoDB, au bout de 5 minutes, j'avais compris comment faire des requêtes assez simples. Par contre, il m'a fallu un paquet de temps pour comprendre le map-reduce de CouchDB (et encore, je ne l'ai toujours pas totalement assimilé).
> Pas de migration pour le schema, certe, mais j'imagine que tes données, tu dois les migrer quand même?
Oui, bien sûr, mais ça reste un cas assez rare. Dans beaucoup de cas, les migrations SQL que je fais consistent surtout à ajouter une nouvelle table ou à ajouter une nouvelle colonne avec NULL comme valeur par défaut. Et pour faire l'équivalent à MongoDB, il y a juste rien à faire.
C'est aussi particulièrement agréable pendant la phase de développement.
# Un exemple
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 4.
Nous avons donc des artistes, des fiches sur les œuvres d'arts, des périodes historiques, des lieux, et des relations entre tous ces objets (du genre tel tableau a été inspiré par le travail de tel artiste). Chaque fiche comporte des informations qui doivent notamment permettre des recherches. Ces informations rentrent plus ou moins bien dans des champs. Par exemple, si on prend le champ 'dimensions', il ne sera pas rempli de la même façon pour un tableau (2 dimensions) que pour une statue (3 dimensions). Pour les dates, nous avons parfois quelque chose de très précis (le 11/02/1827) ou au contraire de très imprécis (environ 400 ans avant JC). Enfin, il y a une multitude de champs possibles, mais généralement qu'une petite partie de ceux-là sont remplis. Cela vient notamment du fait que selon le type de l'œuvre, de nombreux champs ne sont pas pertinents : le champ "encadrement" s'applique bien à un tableau, mais pas vraiment pour une statue. Il arrive également qu'un champ est généralement une seule valeur, mais que dans certains cas ait plusieurs valeurs. Par exemple, on pourrait avoir plusieurs dimensions pour une œuvre qui serait en plusieurs parties.
Au final, si on avait essayé de faire rentrer toutes ses informations dans une base de données SQL, je vous laisse imaginer le nombre monstrueux de tables qu'il aurait fallu (ou alors, une quantité folle de colonnes et de NULL dans ces colonnes), et récupérer une fiche aurait nécessiter une requête SQL d'une complexité que je ne préfère pas imaginer. Nous nous sommes tournés vers CouchDB qui nous a permis de faire ça efficacement. Nous ne regrettons absolument pas ce choix, mais si nous avons rencontrés quelques défauts de jeunesse de CouchDB.
[^] # Re: Les perfs.
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 3.
[^] # Re: Mongo sapin
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. Évalué à 4.
Pour ce qui est des avantages du MongoDB sur les bases de données relationnelles, ils sont nombreux et je ne vais en citer que quelques uns :
- pas de schéma, et donc pas de migrations pour modifier le schéma
- les types composés (tableau et hash) sont bien pratiques
- c'est impressionnant de rapidité (en comparaison MySQL se traîne comme un escargot)
- on peut ajouter des index sans tout bloquer pendant des heures (http://www.mongodb.org/display/DOCS/Indexing+as+a+Background(...)
- ça supporte bien de grosses quantités de données.
Pour encore plus d'avantages, vous pouvez lire ce retour d'expérience : http://www.businessinsider.com/how-we-use-mongodb-2009-11
Et pour ceux qui ont envie de tester, il existe une démo en ligne : http://mongo.kylebanker.com/
Je me permets également de citer un billet écrit par un de mes collègues sur le sujet : http://dev.af83.com/mongodb/pourquoi-choisir-mongodb/2010/01(...)
[^] # Re: Si quelqu'un a le temps :
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Comment détruire votre communauté. Évalué à 6.
> BeOS le faisait il y a 10 ans.
[^] # Re: Nouvelle version du site
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Émission Symbiose du 7 février 2010 sur LinuxFr.org. Évalué à 7.
Pour ceux qui veulent jeter un coup d'œil au code, ça se passe sur http://github.com/nono/linuxfr.org (github a l'air d'avoir des problèmes en ce moment, si ça doit durer, je mettrais un miroir ailleurs).
Sinon, j'ai effectivement très peu communiqué sur cette version. Je suis seul, et communiquer prend du temps (il faut répondre à tous les trolls du genre « c'est du rails, ça tiendra jamais la charge »). Et ce temps, je préfère le consacrer à coder.
[^] # Re: Vous auriez pu être web 2.0...
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Émission Symbiose du 7 février 2010 sur LinuxFr.org. Évalué à 2.
# Merb et Rails
Posté par Bruno Michel (site web personnel) . En réponse au journal Choisir un framework web.... Évalué à 4.
Je te déconseille de partir sur Merb. C'est un très bon framework, mais peu documenté, et surtout, qui ne va plus évoluer. Les équipes de Ruby on Rails et de Merb ont décidé il y a un an d'unir leurs efforts pour fournir une nouvelle version majeure de Rails qui fournirait le meilleur de Rails et le meilleur de Merb.
Depuis, Merb et la branche stable de Rails (Rails 2.3) ont très peu bougé, les développements se sont concentrés sur Rails 3, dont une version beta devrait sortir d'ici peu (première quinzaine de février dit ma boule de cristal).
Comme très peu de personnes ont essayés Rails 3 pour le moment, il est encore assez difficile de savoir si Rails 3 sera une grand réussite ou un flop. Les premiers articles que l'on commence à voir sont très enthousiastes et montrent que l'API de Rails a profondément évolué entre Rails 2.3 et Rails 3. Il faudra donc sûrement réapprendre pas mal de choses pour suivre ce changement, et il serait donc dommage d'acheter maintenant un livre sur Rails. Par contre, ça me semble être une bonne période pour apprendre Ruby ;-)
# Droit de réponse de la part de Sylvain Durif
Posté par Bruno Michel (site web personnel) . En réponse au journal Elvita, faites tourner. Évalué à 3.
« La diffamation publique par voie de presse est un délit passible de sanctions pénales.
(art. 29 à 35 bis de la loi du 29 juillet 1881)
Je ne mettrai plus les pieds sur votre site tant que le délit pénal y sera largement toléré.
Je reviendrai seulement quand j'y serai invité dans l'éthique la plus absolue pour travailler dur à la mise au point d'Elvita si toutefois vous avez les compétences pour faire et la motivation d'aller jusqu'au bout de ce difficile défi.
Je vous remercie de confirmer à Olorim, Chocho et Kowalski qu'ils commencent à comprendre ce qu'est Elvita avec quelques autres.
Oui il s'agit d'une technologie qui surpasse de loin les spécifications d'IPv6 et qui se rapproche d'un méta-moteur intelligent d'accès temps réel à l'information utile gérant les priorités de la personne en temps réel en fonction des multiples contraintes identifiées. Dites leur que tout est prêt pour réaliser cela au plan technologique, il suffit de marier les compétences des scientifiques des différents domaines concernés et des différentes techniques dans le cadre d'un prototypage évolutif pour faire effectivement une technologie transparente accessible par téléphone, GPS, PC internet, etc... sur un mode d'interrogation proche de celui de Kit de la série K2000, excepté qu'Elvita sera accessible via le remplaçant de l'iPhone (une téléphone miniature Open Source que j'ai imaginé - Zpearl) et via tous les accès possibles (téléphone fixe, téléphone mobile, cabine téléphonique, GPS, iTV, bornes interactives publiques, etc...).
Ce que je recherche c'est un équipe pour développer la technologie qui sera hébergée sur une infrastructure 32 millions de core à terme et déclinée sous forme d'un OS TR Linux spécifique (support de 7 milliards d'usagers et de 32 millions de cores), d'une puce incluant l'OS compatible téléphonie et PC, d'un MMPORG stratégie temps réel massivement parallèle (genre Entropia en beaucoup mieux), d'un périphérique de communication mobile miniature (Zpearl) Open Source et concurrent de l'iPhone et autres smartphones du marché. A préciser après étude d'architecture complète car les contraintes temps réel vont déterminer l'architecture cible. »
[^] # Re: Pas sympa
Posté par Bruno Michel (site web personnel) . En réponse au journal Elvita, faites tourner. Évalué à 4.
Si tu postes une dépêche, le risque que l'équipe de modération se moque de toi après avoir refusé ta dépêche est vraiment très faible : on reçoit régulièrement des dépêches maladroites, farfelues, parfois même insultantes, mais on essaye quand même d'en sortir des choses constructives : on réécrit certaines dépêches, on en améliore d'autres, on explique pourquoi on refuse une dépêche et surtout ce qu'il faut faire pour que les suivantes soient acceptées.
Par contre, si tu crains que l'on se fiche de ta poire, il faut effectivement mieux éviter de proposer des dépêches sur LinuxFr.org. Les lecteurs sont beaucoup moins tendres dans leurs commentaires, et j'ai déjà croisé des personnes qui ne veulent plus poster sur LinuxFr.org à cause d'une mauvaise expérience (ie essayer de faire des choses à un niveau local, communiquer sur ces actions sur LinuxFr.org, et ne recevoir comme commentaires que des messages très agressifs). Ces commentaires ne sont généralement le fait que de quelques lecteurs casse-pieds, mais fait plus de bruits que la large majorité des lecteurs silencieux.