Tu vas rire, j'avais commencé par utiliser la syntaxe creole pour la version Rails de LinuxFr.org (en 2009). Et quand j'avais commencé à montrer cette version aux AMR, le premier retour qui m'avait été fait était de pointer le fait que personne ne connaissait cette syntaxe et qu'il fallait en changer.
J'ai trainé des pieds mais les AMR ont été suffisamment insistants pour que je décide de changer de syntaxe, et après un vote entre AMR, c'est markdown qui a été retenu (juste devant la syntaxe de mediawiki).
Non, ce n'est pas juste une mode. Pour servir des pages dynamiques, la différence est effectivement insignifiante, même ces pages viennent avec des ressources statiques (images, css, js). Là, la différence dans le temps de chargement peut commencer à se faire sentir surtout si le serveur est bien chargé.
Un autre avantage est que nginx commence beaucoup moins de mémoire qu'apache (du genre 5x à 10x moins).
Je pense que le problème venait d'une entrée du suivi qui était dans un état bizarre. Je l'ai corrigé. Si le bug se produit à nouveau, on rouvrira cette entrée pour chercher plus en détails le problème.
Par défaut, seuls les dépêches et sondages sont affichés sur la page d'accueil. Mais les utilisateurs authentifiés peuvent aller dans les préférences pour choisir les types de contenus affichés sur cette page.
Sinon le principal problème actuel me semble être la page d'accueil. [...] Je pense que le mélange de tous les items (news, journaux, entrées dans le suivi, etc) en page d'accueil est une erreur.
Seuls les dépêches et sondages apparaissent maintenant sur la page d'accueil par défaut. On peut choisir les types de contenus que l'on veut afficher dans les préférences pour ceux qui, comme moi, préfèrent le bazar ;-)
Nginx est tout à fait capable de servir des applications dynamiques. En fait, il a même de meilleures performances qu'apache pour ça ;-)
Maintenant, il y a aussi de bonnes raisons pour utiliser apache : les admin sys ont souvent une plus grande expérience d'apache que de nginx. Apache a aussi plus de modules que nginx. Enfin, souvent, il y a un historique : tout tournait avec apache, et on a passé les fichiers statiques sous nginx pour gagner en perfs mais la partie a une configuration complexe avec de nombreuses Rewrite Rules donc elle est restée avec apache.
Par contre, je n'ai pas utilisé lighttpd depuis plusieurs années, donc je ne vais rien dire à son sujet.
Passenger (aka mod_rails) est très bien pour déployer des applications Rails sans se casser la tête. Mais unicorn reste meilleur pour les performances et la souplesse d'utilisation. J'apprécie particulièrement la manière dont Unicorn me permet de mettre à jour mon application sans perdre la moindre connexion HTTP. Ce n'est pas pour rien que twitter et github utilise unicorn et pas passenger ;-)
Il doit y avoir un autre paramètre qui entre en jeu. Je viens de tester en désactivant le javascript et les images et je peux voter sans problème : pas d'erreur 500 et le score est mis à jour.
Est-ce que d'autres personnes ont rencontré le problème ?
La dernière news parlait d'une mise en production prochaine, mais n'annonçait pas de date.
La dépêche parlait d'une mise en production dans les tous prochains jours sans effectivement indiquer le jour précis.
En plus, je bosse dans une boite spécialisé dans l'intégration et le maintien opérationnel en production des applications, donc ce sont des sujets qui me parlent.
Certes, mais l'équipe qui fait tourner LinuxFr.org n'a en rien les mêmes moyens qu'une boîte spécialisée.
J'aurais bien aimé une marche en double pendant quelques jours
Cela aurait demandé un travail considérable et des ressources que nous n'avons pas.
une validation des utilisateurs avant la mise en production finale.
Ça fait plusieurs mois que http://alpha.linuxfr.org/ est en ligne, je ne vois pas ce que tu veux de plus. Si les gens ne veulent pas tester cette version, on ne va pas non plus les forcer.
En même temps, vous (linuxfr) avez fait vos développeurs de base en balançant un produit non validé en production.
s/vos développeurs/votre développeur/ : je suis le seul développeur et je ne souffre pas (encore) de personnalités multiples.
[^] # Re: Je suis français donc je râle
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 2.
Tu vas rire, j'avais commencé par utiliser la syntaxe creole pour la version Rails de LinuxFr.org (en 2009). Et quand j'avais commencé à montrer cette version aux AMR, le premier retour qui m'avait été fait était de pointer le fait que personne ne connaissait cette syntaxe et qu'il fallait en changer.
J'ai trainé des pieds mais les AMR ont été suffisamment insistants pour que je décide de changer de syntaxe, et après un vote entre AMR, c'est markdown qui a été retenu (juste devant la syntaxe de mediawiki).
[^] # Re: Pourquoi ne pas utiliser mod_rails ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 2.
Je parlais d'un apache2 configuré pour juste servir des fichiers statiques.
[^] # Re: Pourquoi ne pas utiliser mod_rails ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 9.
Non, ce n'est pas juste une mode. Pour servir des pages dynamiques, la différence est effectivement insignifiante, même ces pages viennent avec des ressources statiques (images, css, js). Là, la différence dans le temps de chargement peut commencer à se faire sentir surtout si le serveur est bien chargé.
Un autre avantage est que nginx commence beaucoup moins de mémoire qu'apache (du genre 5x à 10x moins).
# Corrigé (a priori)
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Erreur 500 sur le tableau de bord. Évalué à 2 (+0/-0).
Je pense que le problème venait d'une entrée du suivi qui était dans un état bizarre. Je l'ai corrigé. Si le bug se produit à nouveau, on rouvrira cette entrée pour chercher plus en détails le problème.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Texte de l'article absent lors de la rédaction d'un commentaire. Évalué à 2 (+0/-0).
C'est fait. D'ailleurs, je peux voir l'entrée su suivi alors que je suis en train de taper ce commentaire :-)
[^] # Re: Avatar que jamais
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Avatar gueule à la récré. Évalué à 2 (+0/-0).
C'est bon, je l'ai récupéré, il peut rechanger d'avatar s'il veut.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Filtrer le contenu de la page par défaut. Évalué à 2 (+0/-0).
On peut à nouveau filtrer les types de contenus affichés sur la page d'accueil.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pour le retour des dépêches en page d'accueil. Évalué à 3 (+0/-0).
Par défaut, seuls les dépêches et sondages sont affichés sur la page d'accueil. Mais les utilisateurs authentifiés peuvent aller dans les préférences pour choisir les types de contenus affichés sur cette page.
[^] # Re: Je suis français donc je râle
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 10.
Seuls les dépêches et sondages apparaissent maintenant sur la page d'accueil par défaut. On peut choisir les types de contenus que l'on veut afficher dans les préférences pour ceux qui, comme moi, préfèrent le bazar ;-)
[^] # Re: Avatar que jamais
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Avatar gueule à la récré. Évalué à 2 (+0/-0).
Ha zut, la licence est effectivement contraignante. Une autre proposition ?
[^] # Re: bien sur le lien image ne marche pas :(
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Avatar gueule à la récré. Évalué à 2 (+0/-0).
Vendu, c'est le nouveau avatar par défaut.
[^] # Re: Pourquoi ne pas utiliser mod_rails ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 5.
Oui, elle marche bien donc on la garde :)
[^] # Re: Pourquoi ne pas utiliser mod_rails ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 10.
Nginx est tout à fait capable de servir des applications dynamiques. En fait, il a même de meilleures performances qu'apache pour ça ;-)
Maintenant, il y a aussi de bonnes raisons pour utiliser apache : les admin sys ont souvent une plus grande expérience d'apache que de nginx. Apache a aussi plus de modules que nginx. Enfin, souvent, il y a un historique : tout tournait avec apache, et on a passé les fichiers statiques sous nginx pour gagner en perfs mais la partie a une configuration complexe avec de nombreuses Rewrite Rules donc elle est restée avec apache.
Par contre, je n'ai pas utilisé lighttpd depuis plusieurs années, donc je ne vais rien dire à son sujet.
[^] # Re: Pourquoi ne pas utiliser mod_rails ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 10.
Passenger (aka mod_rails) est très bien pour déployer des applications Rails sans se casser la tête. Mais unicorn reste meilleur pour les performances et la souplesse d'utilisation. J'apprécie particulièrement la manière dont Unicorn me permet de mettre à jour mon application sans perdre la moindre connexion HTTP. Ce n'est pas pour rien que twitter et github utilise unicorn et pas passenger ;-)
Un petit lien sur le sujet : I like Unicorn because it's Unix.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Liens statistiques cassés. Évalué à 2 (+0/-0).
En fait, elles n'ont pas encore été recodées.
Cf http://linuxfr.org/suivi/statistiques-inaccessibles
# Hum
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pertinenter avec javascript/images désactivées. Évalué à 3 (+0/-0).
Il doit y avoir un autre paramètre qui entre en jeu. Je viens de tester en désactivant le javascript et les images et je peux voter sans problème : pas d'erreur 500 et le score est mis à jour.
Est-ce que d'autres personnes ont rencontré le problème ?
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Désactiver les avatars. Évalué à 2 (+0/-0).
Cf http://linuxfr.org/suivi/cacher-les-avatars-et-certains-formatages
# Oops
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Changements dans "derniers commentaires". Évalué à 2 (+0/-0).
À vouloir faire plusieurs choses en même temps, je me suis raté. Merci de me l'avoir fait remarquer, je corrige de suite.
[^] # Re: Reproduction
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Interprétation du code HTML (risque de XSS ?). Évalué à 2 (+0/-0).
Bien vu. Le bug venait de ma bibliothèque pour tronquer le HTML. C'est corrigé.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Petit bug d'affichage sur le dernier journal de patrick_g. Évalué à 2 (+0/-0).
C'est corrigé
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Localisation du mois affiché. Évalué à 2 (+0/-0).
C'est corrigé
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pas de sommaire sans titre. Évalué à 2 (+0/-0).
Corrigé
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Consistance des titres de page. Évalué à 2 (+0/-0).
C'est corrigé.
[^] # Re: Bravo pour la migration !
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 10.
La dépêche parlait d'une mise en production dans les tous prochains jours sans effectivement indiquer le jour précis.
Certes, mais l'équipe qui fait tourner LinuxFr.org n'a en rien les mêmes moyens qu'une boîte spécialisée.
Cela aurait demandé un travail considérable et des ressources que nous n'avons pas.
Ça fait plusieurs mois que http://alpha.linuxfr.org/ est en ligne, je ne vois pas ce que tu veux de plus. Si les gens ne veulent pas tester cette version, on ne va pas non plus les forcer.
[^] # Re: Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Séparer section et titre dans la CSS Suse (entre autres). Évalué à 2 (+0/-0).
J'ai pris la version du wiki et je l'ai intégrée au dépôt git. Merci