XHTML.net

desfrenes said:

cf le micro-bench que j'avais fait de node.js: http://www.desfrenes.com/blog/post/node-js-plus-de-clients-moins-de-serveurs

La techno est très intéressante, même si je pense qu'il va falloir résister à la tentation de la mettre à toutes les sauces, même quand ça n'est pas judicieux.

Eric said:

Tout d'abord éviter de faire 1x5 est souvent possible, à base de jointures et/ou de code bien organisé.

Il y a aussi l'ORM DataMapper sur Ruby qui se rend compte de pas mal de ces situations et qui sait que quand tu vas demander un jeu de résultat puis que tu vas chercher une liaison séquentiellement sur chacun de ces résultats, il peut lancer une requête directement sur les 5 puis trier dedans.

Enfin, sur du ruby toujours mais je suppose que c'est similaire en python, tu dois toujours pouvoir lancer un thread pour ta requête et attendre le résultat.

Reste que la plupart des gens développent en séquentiel et que tu as beau utiliser un framework ou un langage à base de templates, si tu conçois les choses séquentiellement, tu ne gagneras pas de temps.

Sinon partir de "on peut avoir de meilleures performances avec une conception à base d'événements et des systèmes parallèles" et en tirer "frameworks actuels = poubelle", il y a quand même tout un monde.

Loïc said:

Eric, pour les frameworks actuels, je dis "poubelle" dans le contexte qui est "apprendre quelque chose de nouveau" et uniquement dans ce contexte. C'est d'ailleurs le titre de ce billet.

L'ORM DataMapper c'est un pansement sur une jambe de bois. Ce sont des implémentations (on en trouve aussi en Python/PHP) très ingénieuses et bien pensées qui ne font que compenser le décalage entre la manière de stocker l'information dans la base et son utilisation dans l'application. De même lancer un thread, c'est bon pour quelque chose de très compliqué (bonjour les thread lock, la synchro etc.) là où l'idéal serait simplement d'écrire dans le code quelque chose du genre :

in_parallel(res1 = do_one(), res_2 = do_two());

En pratique aujourd'hui on a les langages et les outils pour pouvoir manipuler ces concepts facilement et efficacement. Quand c'est facile, quand on n'a pas besoin de gérer la synchro de threads etc. les gens sont tout à fait capable d'analyser ce qui doit être fait en séquence et ce qui peut être exécuté en parallèle. Nous mettons tous le couvert en même temps que les pâtes cuisent, on sait ce que c'est s'organiser "en parallèle", mais jusqu'à présent, dans le monde du logiciel, les outils ne permettaient pas de faire de même facilement.

Mickaël, je suis bien d'accord, il ne faut pas le mettre à toutes les sauces, mais ne pas jouer avec pour un développeur web, c'est laisser passer le train. Je dis souvent que coder en Python améliore la qualité de mon code PHP et vice-versa. Chaque langage/approche permet d'accumuler de l'expérience et finalement de choisir l'outil et l'approche les plus adaptés aux besoins.

Attendez-vous à un peu de node.js ici (j'en ai vraiment besoin pour Cheméo).

Eric said:

Ok, j'avais loupé le contexte pour "poubelle", désolé. D'autant que je suis foncièrement en accord avec ton dernier paragraphe de commentaire, c'est indispensable de jouer avec tout ce qui arrive de nouveau, pour forger ses choix et ses expériences.

Loïc said:

Merci Eric, le poubelle était provocateur pour forcer les gens à réagir et attirer le lecteur. La ficelle était grosse, mais elle a le mérite de fonctionner un petit peu.

crazyball said:

Mais qui dit JS dit que si l'user a javascript desactivé ton projet il tourne plus donc => poubelle

metagoto said:

@crazyball
Le JS dont parle Loïc est exécuté coté server.

@Loïc
Tu as tout bon. JS et JSON ont tout ce qu'il faut pour déchirer coté server.. en théorie. Avec node.js et mongodb, c'est réellement le cas dans la pratique.

Armand said:

Les frameworks Erlang sont aussi pas mal de ce côté là. Nitrogen par exemple est sympa pour un développeur web voulant élargir ses horizons. :)

Loïc said:

Tout à fait Armand et je recommande d'ailleurs l'excellent livre "Programming Erlang" d'Armstrong, le père d'Erlang, pour qui veut découvrir ce langage. Le livre est disponible en version pdf sans DRM et/ou papier.

Armand said:

Sinon, on peut lire gratuitement sa thèse de PhD <http://ftp.sunet.se/pub/lang/erlang/download/armstrong_thesis_2003.pdf> qui explique très bien la philosophie du langage.

Bravo pour tes articles en tout cas, tes contributions sont toujours intéressantes.

Raphaël said:

Tu es dans le timing puisqu'Heroku annonce aujourd'hui le support (en beta) de node.js : http://blog.heroku.com/archives/2010/4/28/node_js_support_experimental/

jpic said:

Nous avons fait pas mal de recherches sur les possibilités d'implémentation de couche metier, l'objectif étant de tirer parti des avantanges:
- du NoSQL, pouvoir ajouter/modifier/enlever des champs et relations de tout type sans altérer le schema,
- du SQL, pouvoir utiliser les bonnes vielles requettes quand meme pratiques pour exploiter les données.

Voici les détails des implementations qu'on a trouvé:
- EAV, plein de tables avec plein de requettes difficiles: de l'overbloat dans la majorité des cas (OpenGoo, Magento, eZ Publish...) http://en.wikipedia.org/wiki/Entity-attribute-value_model
- FriendFeed, une table avec une ligne par entité et des tables d'index http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Nous avons opté pour une table avec une ligne par attribut et des tables d'index.

Stocker la structure JSON dans une ligne d'une table (type friendfeed) est interressant car on garde quand meme une structure; tandis qu'on est jamais certain (dans le sens "scolaire" du terme) de la structure lorsqu'on réduit une entité à partir d'une ligne par attribut.

Par exemple, si un "article" a plusieurs attributs "comments", l'attribut récupéré est evidamment une liste; tandis que si l'"article" n'a qu'un seul commentaire, l'attribut "comments" arrive donc sans etre dans une liste. En pratique, on doit faire foreach( myIterator( $article['comments'] ) as $comment ) au lieu d'attaquer directement $article['comments'] comme une array, cela ne pose donc aucun probleme.

Le probleme du stockage en JSON est la gestion des relations. Particulierement M2M. Il faudrait peut etre une table de relations qui compliqueraient les requettes c'est pourquoi nous nous sommes éloigné de cette solution.

Les tables d'index permettent de tirer profit du SQL classique en faisant deux requettes au lieu d'une, une pour selectionner les ids d'abord: select * from attributes_table where id in (select id from foo_index [...]).


Au sujet des frameworks, il est certain qu'une solution legere en PHP basée sur les "vagues concepts" KISS, DRY et NoSQL sera la bienvenue en tout cas en ce qui me concerne.

J'ignore comment vous utilisez Django, personnelement je commence les projets au moins à partir du basic_project de Pinax, et je me voie mal me priver des miliers d'applications forkables sur github. Si Django permet d'etre 8 à 12 fois plus productif qu'avec PHP, c'est selon les projets et en connaissant un certain nombre d'applications génériques, par exemple:

- django-notifications
- django-ajax-selects
- django-authority
- django-debug-toolbar
- django-extensions
- django-filter
- django-generic-flatblocs
- django-frontendadmin
- django-pagination
- django-reversion
- django-staticfiles <- vraimment indispensable
- south

Je ne me voie pas du tout faire le moindre projet django sans *toutes* ces applications pour un client final.

Tout hardcoder: c'est plus performant, mais alors en ce qui concerne la maintenance et la répartition de la charge de travail .... c'est la catastrophe.

Et franchement, j'ai pas envie de réimplementer une appli d'un projet précédent, je préfére ressortir l'appli et commencer à travailler sur ce qui rend le nouveau projet *différent* du précédent. L'usage d'un framework qui permet au moins de brancher des applis entre elles est considéré comme primordial par pas mal de devs dont vous faites peut etre parti.

J'éspere que je ne vous ai pas trop ennuyé ;)

metagoto said:

@jpic
Kyle Banker (staff de 10gen, la société derrière mongodb) a un billet intéressant sur son blog à propos de e-commerce et mongodb:
http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/

Dans le cadre de mongodb, les relations M2M ne sont pas foncièrement simplifiées. Ca n'est pas la solution miracle. Comme le système supporte nativement JSON (en fait un superset de JSON), d'autres outils sont à notre disposition, comme map/reduce, les operateurs atomiques, des shortcuts sympathiques etc. Ce changement de paradigme ouvre de nouvelles perspectives.

sophie viger said:

Bonjour,

J'ai en charge les programmes et le recrutement des intervenants pour l'IESA Multimédia à Paris... donc, vous imaginez bien que votre article m'a beaucoup intéressé, d'autant que j'étais en pleine réflexion : symphony vs RoR pour nos étudiants !
Pourriez-vous me contacter par mail, car j'aimerais, si cela ne vous ennuie pas, vous poser quelques questions !
Merci beaucoup

Sophie Viger