Bruno Michel a écrit 3285 commentaires

Le fonctionnel clairement inutilisable pour un projet web ?

Je ne serais pas aussi affirmatif que toi. Il existe des frameworks web dans des langages fonctionnels dont certains sont assez avancés/intéressants :

- Nitrogen en Erlang : http://nitrogenproject.com/
- HAppS en Haskell : http://happs.org/
- Ocsigen en OCaml : http://ocsigen.org/

> Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

Bizarrement, je ne connais que très peu de personnes qui utilisent des langages avec du typage statique vraiment efficace pour détecter des erreurs. Haskell propose ça, mais c'est loin d'être un langage très répandu.

Par contre, C++ et Java ne rentre pas dans cette catégorie : le typage statique est là principalement pour des raisons de performance, pas pour aider les humains. Il suffit de voir qu'il n'y a pas de moyen de faire 2 types qui aient le même stockage (entier 32 bits) sans avoir de conversions implicites de l'un à l'autre.

Exemple : avoir un type qui correspond à des distants en mètres et l'autre en pieds (tout ressemblance avec un engin spatial ayant dévié de sa trajectoire à cause d'une erreur de ce type ne serait pas forcément fortuite).

> Du refactoring en python, ruby ou autre langage dynamique, c'est quasi impossible

Heureusement que tu me préviens. Je faisais du refactoring en Ruby ou Javascript quasiment tous les jours, mais je vais arrêter. Sinon, l'univers va m'en vouloir de faire des trucs quasi impossibles aussi souvent...

> ça implique, pour l'outil de refactoring, de faire une reconnaissance des types utilisés à travers tout le code...

Ça fait 2 assertions avec lesquelles je ne suis pas d'accord dans la même phrase :

1. qu'il faille un outil pour faire du refactoring (c'est vrai pour du java où le langage est très verbeux, mais beaucoup moins pour les langages dynamiques)

2. qu'il faille analyser les types pour faire du refactoring (j'utilise régulièrement les techniques de refactoring listées sur http://sourcemaking.com/refactoring et dans la plupart des cas, on n'a pas besoin de connaître les types utilisés)

Oui, on peut facilement passer de l'un à l'autre.

Je n'ai pas essayé Catalyst. Dancer est pas mal du tout, mais comme je préfère le Ruby, je reste accroché à Sinatra.

OK, le terme ORM est très mal choisi. Dans le monde Ruby, on parle parfois d'ODM (Object Document Mapping), mais je ne suis pas sûr que cela parle à grand monde.

> Alors, est-ce que le nouveau linuxfr proposera une API web (http quoi :)) ?

Oui, c'est prévu mais pas tout de suite. Pour le moment, la priorité est de sortir le site web.

> Sur quel(s) point(s) les frameworks PHP sont-ils encore en retard, par rapport aux frameworks Rails/Django ?

Je ne suis pas les avancées des frameworks PHP, donc je vais probablement dire des bêtises, mais je me lance. Les personnes qui connaissent mieux les frameworks PHP que moi pourront me corriger ;-)

Tout d'abord, j'ai l'impression que les frameworks PHP sont très en retard sur tout ce qui concerne les tests. Je ne connais pas d'équivalent à rspec en PHP par exemple. Une anecdote me confirme dans cette opinion : lors d'une des présentations au dernier Forum PHP, le conférencier a demandé qui connaissait les mocks ou stubs à l'audience, et j'étais l'une des deux personnes à avoir levé la main.

Ensuite, il y a la gestion des assets. Il existe pas mal de plugins Rails pour compresser/minifier/bundler des fichiers javascripts. Sass et Less sont une grande avancée pour gérer les feuilles de styles. Il y a des outils pour créer des sprites CSS facilement.

Un troisième exemple est le possibilité de profiter des technologies NoSQL. Damien Tournoud, qui a fait l'introduction au monde NoSQL lors du forum PHP, considère que les frameworks PHP sont très en retard sur ce point. Les bibliothèques pour se connecter à redis sont des gros bricolages. Les ORM ne savent que très mal utiliser des bases NoSQL comme MongoDB.

> D'ailleurs ce site a-t-il une vocation ?

Oui, je cite les statuts de l'association LinuxFr : « L'association a pour objet de rassembler des utilisateurs francophones de logiciels libres, et de leur fournir un service d'information et de communication, par exemple via un serveur web. »

> Car j'entends souvent parler de Symfony, Zend Framework, ... et plutôt en bien !

Est-ce que ces personnes ont déjà essayé des frameworks dans d'autres langages comme Rails ou Django ?

Ça tombe bien, il est là : http://linuxfr.org/~NoNo/30482.html :)


while ( my $line = ) {


Templeet a mangé une partie de la ligne ?

L'autre option, c'est que ça initialise $line à un truc vide, mais dans ce cas, je ne vois pas comment les lignes suivantes fonctionnent.

Un peu des deux. La technique a restreint les possibilités à deux : MySQL et PostgreSQL. Aujourd'hui, la liste serait plus longue, avec des bases NoSQL comme MongoDB en plus.

Ensuite, j'ai choisi MySQL parce que je suis plus à l'aise avec et que je connais des personnes prêtes à m'aider en cas de problème qui connaissent bien MySQL et comment le tunner. Pour PostgreSQL, ça me faisait un peu peur de me lancer dedans sans trop d'expérience ni d'aide extérieure.

Oui, c'est juste le script pour migrer les données. Son temps d'exécution a effectivement très peu d'importance : il met 2h, mais je suis sûr qu'en y passant du temps, ça pourrait s'optimiser.

Et ça a bien été une des parties les plus difficiles. D'ailleurs, il reste encore des bugs bien compliqués à résoudre dessus.

> La version actuelle avec templeet utilisait [...] la redirection des 404 vers l'appli qui générait une page statique pour la fois d'après, page supprimée à la moindre maj.

C'est comme ça que ça fonctionne, mais quasiment toutes les templates ont maintenant la directive ~dont_cache(). Donc, quasiment toutes les requêtes passent quand même par templeet.

Il y a 2 raisons à cela. La première, c'est que la plupart des pages contiennent des informations spécifiques à un utilisateur (au hasard, le Bienvenue dans la barre de gauche).

La seconde, c'est qu'il n'est pas simple de faire expirer le cache. Par exemple, quand on vote sur un commentaire, ça peut changer la note moyenne des commentaires du contenu associé. Or, cette note moyenne est affichée à chaque fois que le contenu est affiché, c'est-à-dire au moins sur une dizaine de pages.

C'est donc beaucoup plus simple de gérer le cache au niveau des ~include(). En gros, on cache le bloc HTML pour un commentaire, ou juste la première partie d'une dépêche, puis avec templeet, on reconstruit la page à partir de ces blocs (depuis le cache quand c'est possible, avec les requêtes SQL sinon).

> Quel système de cache est utilisé dans cette nouvelle version ?

Ça fait parti des choses qu'il me reste à faire avant de pouvoir de passer la version Rails en production ;-)

SPIP ? Mais il ne fait quasiment rien de ce qui est attendu. Ça paraît déjà compliqué d'avoir des sondages ou des commentaires sous forme de fil de discussions sous SPIP, alors je ne préfère même savoir comment on peut faire pour les fonctionnalités vraiment difficiles (gestion du karma, seuil de modération des dépêches en fonction du nombre d'AMR, tribune).

> À mon avis, leur problème à facebook se situe plus du cotés des bases de données et de la bande passante.

Facebook est sûrement confronté à des tas de problèmes, mais si on compte les serveurs, les serveurs web seraient bien plus nombreux que les serveurs de base de données ou de cache. En gros, le nombre de serveur PHp se compte en dizaines de milliers, le nombre de serveur de bases de données en milliers et ceux de memcached "seulement" en centaines.

Quelques chiffres qui datent de 2008 : http://www.paragon-cs.com/wordpress/?p=144

> donc, bon, la migration des données, en moins d'une heure c'est fait, en voyant large :-)

Raté, faut compter environ 2h pour ça ;-)

> Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?

Quand j'ai commencé la version Rails, je pensais pouvoir faire ça en 6 mois. C'était il y a 2 ans, donc maintenant, je suis beaucoup plus réservé sur mes estimations ;-)

Oui, ça a été sérieusement considéré. LinuxFr.org est un site avec beaucoup de fonctionnalités et ça demande beaucoup de code pour ça (et donc du temps). Un CMS aurait sûrement permis de sortir plus rapidement une nouvelle version. Mais les performances ont effectivement été le point bloquant.

Django et Rails se valent. Le choix entre les deux s'est fait principalement parce que je connais bien mieux Rails et que je préfère le Ruby au Python.

Pour les frameworks PHP, quand j'ai commencé la nouvelle version (il y a 2 ans), ils étaient loin d'avoir le même niveau que Rails et Django. Aujourd'hui, je ne sais pas ce que valent les frameworks PHP comme Symfony, mais les dernières discussions que j'ai pu avoir à ce sujet me laissent penser qu'il reste encore du travail avant qu'il n'arrive au niveau de Rails ou Django.

Il existe aussi de bons frameworks dans des langages moins connus, mais je voulais rester avec un framework connu pour attirer des contributeurs et être sur qu'il soit maintenu pendant encore un paquet d'années.

C'est l'autre question que l'on me pose régulièrement. Pareil, il y a des débuts de réponses dans les commentaires mais faudrait que j'en fasse un journal. Ça attendra une prochaine fois (un vendredi de préférence).

En attendant, http://linuxfr.org/comments/1180393.html#1180393 explique pourquoi je n'ai pas utilisé un CMS.

Le serveur actuel (oui, il est tout seul) se porte bien. La question ne se pose pas du tout en termes de puissance, mais en termes de maintenance et évolutions.

J'étais parti pour te répondre dans ce commentaire, et à mi-chemin, je me suis rendu compte que ça pouvait intéresser beaucoup de lecteurs de LinuxFr.org. J'ai donc transformé le commentaire en journal : http://linuxfr.org/~NoNo/30481.html

> Moi je parie un coincoin en plastique qu'il sera deux fois plus lourd que l'actuel.

Selon quel critère ? poids de la page ? temps de chargement ? avec ou sans le javascript ? pour un utilisateur anonyme ou un utilisateur connecté ?

> Ce serait bien de refaire comme à la bonne époque des bench/troll en comparant cette version à templeet.

Est-ce vraiment utile d'avoir recours à un benchmark totalement biaisé pour troller ?

> Je t'envoie un mp ?

Une demande sur github ou le tracker sera très bien. Un MP ou un commentaire sur cette dépêche, ça marche aussi.

> En fait pour commencer, j'aimerais bien que tu affectes un id au bouton « rechercher »

OK, je fais ça.