Pour les personnes qui utilisent la version HTTPS du site, nous recommandons d'ajouter le certificat de cacert pour éviter d'avoir à accepter manuellement les certificats de LinuxFr.org. Cf l'aide.
Redis est très simple à mettre en place. La consistance ne pose pas de problèmes dans notre cas. Pour la persistance, on pourrait effectivement perdre quelques données en cas de crash, mais franchement, si le serveur crash, on aura des problèmes plus graves à régler que celui-là.
En particulier, LinuxFr.org ne tourne sur qu'un seul serveur, donc si le serveur lâche, il nous faudra quand même repartir d'une sauvegarde et accepter de perdre les données les plus récentes.
Si, redis persiste bien ses données sur le disque dur. Il n'offre pas les mêmes garanties qu'une base de données SQL, mais ça reste suffisant pour ce cas d'usage. Au pire, on aurait régénérer les entrées de redis en reparcourant tous les contenus et commentaires.
Est-ce que vous avez envisagé une solution à base de signature des URLs ?
Si linuxfr signe les URLs des images avec HMAC par exemple, le proxy peut vérifier que l'URL a bien été générée par linuxfr, et autoriser la requête. Et du coup pas besoin de stocker une liste d'URLs.
Il y a d'autres problématiques que je n'ai pas abordées dans la dépêche, dont une importante est l'aspect modération.
Par exemple, si une personne affiche une image nazie sur le site, on saura l'enlever des contenus et commentaires, mais l'URL de cette image sur img.linuxfr.org resterait valide. Du coup, cette même personne pourrait poster cette URL sur d'autres forums, ce qui pourrait potentiellement nous causer des ennuis avec la justice. J'ai donc implémenté un système pour bloquer les images.
Plus vicieux, cette même personne pourrait utiliser la prévisualisation des commentaires pour récupérer cette URL sans poster le contenu. L'équipe de modération du site ne verrait alors pas passer l'image et ne pourrait donc la bloquer. Nous avons donc également une galerie des dernières images utilisées sur le site dans la partie modération.
D'autre part, img.linuxfr.org garde en cache pour une durée assez courte les erreurs qu'il rencontre lorsqu'il va chercher une image distante (pour éviter de bourriner le serveur en question). Du coup, redis s'est trouvé être la solution la plus simple pour développer ce composant.
Sinon, ma conférence n'a pas été filmée (il y a juste un enregistrement audio). Mais si quelqu'un veut regarder une vidéo sur Go, il y a celles du dernier Google IO : http://blog.golang.org/2012/07/go-videos-from-google-io-2012.html (et les gens qui en parlent connaissent go bien mieux que moi pour ne rien gâcher).
Et ensuite une présentation de nono sur le monde merveilleux de Golang, présentation donnée au RMLL si je ne me trompe.
Je confirme.
Je n'y ait pas encore touché mais je trouve ça plutôt intéressant, et les différents articles (par exemple sur le blog d'af83 donnent envie d'essayer). Finalement peut-être un pont entre les langages classiques et bas niveaux tels que c/c++ et les langages plus haut niveaux comme python et ruby, tout en étant plus expressif que java.
Oui, c'est effectivement un langage qui cherche à combiner les avantages des langages compilés bas niveaux et ceux des langages dynamiques plus hauts niveaux. D'ailleurs, c'est intéressant de noter qu'il a été développé initialement pour des projets de large taille que l'on fait habituellement en C++ ou en Java, mais que les dévs qui font actuellement du Go viennent plus souvent du monde des langages dynamiques (Ruby, Python, JS). À ce sujet, je recommande chaudement la lecture de Less is exponentially more par Rob Pike.
Bref ça me tente pas mal, mais j'ai déjà d'autres langages à (ré)apprendre donc ça passer après…
Ça demande quel est ton objectif. Si tu souhaites apprendre de nouveaux langages pour voir de nouvelles choses, il y a plein de langages plus intéressants que Go. Par contre, si tu cherches un langages pour coder et être productif dans ce langage, Go est sûrement un très bon choix.
Dans l'ensemble, il n'y a rien de vraiment révolutionnaire dans Go. C'est juste un langage qui intègre pas mal de bonnes idées venant de divers autres langages pour en faire un tout cohérent et efficace. Les différentes fonctionnalités n'ont rien de complexes et se combinent bien entre elles. Avec ça et les outils go, on a l'impression d'être rapidement très productif dans ce langage.
Il n'y a quand même rien de plus complexe que la programmation par thread.
Non, ce qui est compliqué, c'est de gérer des locks, pas les threads en eux-mêmes. Il faut bien séparer les deux car il existe d'autres façons pour des threads de partager des données (communiquer par messages par exemple). Cf une présentation très intéressante sur le sujet : http://swtch.com/~rsc/talks/threads07/
Non, pour les forums, on peut continuer à modifier son post même s'il y a eu des commentaires postés. L'idée de départ était que des gens voulaient pouvoir indiquer dans leur post si le problème était résolu ou non et, éventuellement, indiquer la solution pour les suivants qui tomberaient dessus via un moteur de recherche.
Il est possible de modifier ses entrées dans un forum. C'est nouveau ?
Non, ce n'est vraiment pas nouveau. La version en Rails a toujours fonctionné comme ça, et il me semble même que la version templeet permettait aussi de faire ça.
[^] # Re: origine
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 5.
Oui, certaines personnes affichent une version miniature sur le site et en font un lien vers l'image en taille d'origine.
[^] # Re: Un essaie
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 5.
Pour les personnes qui utilisent la version HTTPS du site, nous recommandons d'ajouter le certificat de cacert pour éviter d'avoir à accepter manuellement les certificats de LinuxFr.org. Cf l'aide.
[^] # Re: redis vs signature
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Redis est très simple à mettre en place. La consistance ne pose pas de problèmes dans notre cas. Pour la persistance, on pourrait effectivement perdre quelques données en cas de crash, mais franchement, si le serveur crash, on aura des problèmes plus graves à régler que celui-là.
En particulier, LinuxFr.org ne tourne sur qu'un seul serveur, donc si le serveur lâche, il nous faudra quand même repartir d'une sauvegarde et accepter de perdre les données les plus récentes.
[^] # Re: Requêtes simultanées
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 8.
Pas de soucis de ce coté là, Go gère ça très bien. Le package
net/http
crée une nouvelle goroutine pour chaque connexion HTTP entrante.Une goroutine est un contexte d'exécution très léger et Go multiplexe ensuite les goroutines sur des threads.
[^] # Re: redis vs signature
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 10.
Si, redis persiste bien ses données sur le disque dur. Il n'offre pas les mêmes garanties qu'une base de données SQL, mais ça reste suffisant pour ce cas d'usage. Au pire, on aurait régénérer les entrées de redis en reparcourant tous les contenus et commentaires.
Oui, j'ai même fait plus que l'envisagée, je l'ai codée. En remontant un peu dans le temps, on peut voir https://github.com/nono/img-LinuxFr.org/blob/aa39a39d240797a44d34cf2d61b3c8984157b03b/img.go. D'un point de vue conceptuel, c'est une idée assez séduisante.
Il y a d'autres problématiques que je n'ai pas abordées dans la dépêche, dont une importante est l'aspect modération.
Par exemple, si une personne affiche une image nazie sur le site, on saura l'enlever des contenus et commentaires, mais l'URL de cette image sur img.linuxfr.org resterait valide. Du coup, cette même personne pourrait poster cette URL sur d'autres forums, ce qui pourrait potentiellement nous causer des ennuis avec la justice. J'ai donc implémenté un système pour bloquer les images.
Plus vicieux, cette même personne pourrait utiliser la prévisualisation des commentaires pour récupérer cette URL sans poster le contenu. L'équipe de modération du site ne verrait alors pas passer l'image et ne pourrait donc la bloquer. Nous avons donc également une galerie des dernières images utilisées sur le site dans la partie modération.
D'autre part, img.linuxfr.org garde en cache pour une durée assez courte les erreurs qu'il rencontre lorsqu'il va chercher une image distante (pour éviter de bourriner le serveur en question). Du coup, redis s'est trouvé être la solution la plus simple pour développer ce composant.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Bug sur les espace insécables. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/029ae8b983c1c659205076deb898970c356c9881
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Alertes de sécurité en HTTPS. Évalué à 3 (+0/-0).
Cf https://linuxfr.org/suivi/gestion-des-images-pointees
[^] # Re: Taiste
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Gestion des images pointées. Évalué à 5 (+0/-0).
Voilà, cette image a été servie par notre tout nouveau reverse-proxy cache : https://github.com/nono/img-LinuxFr.org
# Taiste
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Gestion des images pointées. Évalué à 5 (+0/-0).
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Erreur d'échappement markdown. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/1d99b313fda03f8157b62499e5585b54a742958c
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi caractère < qui coupe les commentaires. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/1d99b313fda03f8157b62499e5585b54a742958c
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajouter une CSS réduisant la taille de la fenêtre d'édition. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/976c10487def02a1d4463fc5845fdd9f634ba1f6
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi "Masquer" les journaux mal notés. Évalué à 3 (+0/-0).
Cf http://linuxfr.org/suivi/replier-les-journaux-n%C3%A9gatifs
[^] # Re: Une autre façon d'utiliser Pygments
Posté par Bruno Michel (site web personnel) . En réponse au journal UU.zoy.org, le site qui vous a à la colle.. Évalué à 2.
Je l'ai vu, mais je n'ai pas eu le temps de regarder d'où vient le problème.
[^] # Re: Une population qui vieillit
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 5.
On est bien d'accord. C'est un point que nous avons soulevé à l'oral lors de notre présentation (même s'il n'apparaît pas dans les slides).
# Une autre façon d'utiliser Pygments
Posté par Bruno Michel (site web personnel) . En réponse au journal UU.zoy.org, le site qui vous a à la colle.. Évalué à 5.
Pour info, la coloration syntaxique de LinuxFr.org se fait avec Pygments. Nous n'utilisons pas pygments.rb, mais albino et ça marche bien pour nos besoins : https://github.com/nono/linuxfr.org/blob/master/lib/lfmarkdown.rb#L55
[^] # Re: Nouvelle charte de modération
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 6.
Oui, il reste un ou deux points à boucler, puis elle sera mise en ligne et annoncée dans une dépêche.
# Patch appliqué
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Adapter la boîte d'édition au style. Évalué à 3 (+0/-0).
Merci pour le patch.
Cf https://github.com/nono/linuxfr.org/commit/acff1bc1f2104fe49ff1cd4be32a5e012af4f575
[^] # Re: Blabla sur go
Posté par Bruno Michel (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 5.
Sinon, ma conférence n'a pas été filmée (il y a juste un enregistrement audio). Mais si quelqu'un veut regarder une vidéo sur Go, il y a celles du dernier Google IO : http://blog.golang.org/2012/07/go-videos-from-google-io-2012.html (et les gens qui en parlent connaissent go bien mieux que moi pour ne rien gâcher).
# Blabla sur go
Posté par Bruno Michel (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 5.
Je confirme.
Oui, c'est effectivement un langage qui cherche à combiner les avantages des langages compilés bas niveaux et ceux des langages dynamiques plus hauts niveaux. D'ailleurs, c'est intéressant de noter qu'il a été développé initialement pour des projets de large taille que l'on fait habituellement en C++ ou en Java, mais que les dévs qui font actuellement du Go viennent plus souvent du monde des langages dynamiques (Ruby, Python, JS). À ce sujet, je recommande chaudement la lecture de Less is exponentially more par Rob Pike.
Ça demande quel est ton objectif. Si tu souhaites apprendre de nouveaux langages pour voir de nouvelles choses, il y a plein de langages plus intéressants que Go. Par contre, si tu cherches un langages pour coder et être productif dans ce langage, Go est sûrement un très bon choix.
Dans l'ensemble, il n'y a rien de vraiment révolutionnaire dans Go. C'est juste un langage qui intègre pas mal de bonnes idées venant de divers autres langages pour en faire un tout cohérent et efficace. Les différentes fonctionnalités n'ont rien de complexes et se combinent bien entre elles. Avec ça et les outils go, on a l'impression d'être rapidement très productif dans ce langage.
# Et zsh ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 9.
À tout hasard, est-ce qu'il y aurait un volontaire pour faire la même chose pour zsh ?
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Non, ce qui est compliqué, c'est de gérer des locks, pas les threads en eux-mêmes. Il faut bien séparer les deux car il existe d'autres façons pour des threads de partager des données (communiquer par messages par exemple). Cf une présentation très intéressante sur le sujet : http://swtch.com/~rsc/talks/threads07/
[^] # Re: voyance ou ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Atelier Vim, Paris, le 20 Juillet. Évalué à 3.
En version électronique, oui : http://pragprog.com/book/dnvim/practical-vim
[^] # Re: tant qu'il n'y a pas de reponse en dessous
Posté par Bruno Michel (site web personnel) . En réponse au journal Je viens de voir un truc étrange . Évalué à 7.
Non, pour les forums, on peut continuer à modifier son post même s'il y a eu des commentaires postés. L'idée de départ était que des gens voulaient pouvoir indiquer dans leur post si le problème était résolu ou non et, éventuellement, indiquer la solution pour les suivants qui tomberaient dessus via un moteur de recherche.
# Rien de neuf
Posté par Bruno Michel (site web personnel) . En réponse au journal Je viens de voir un truc étrange . Évalué à 3.
Non, ce n'est vraiment pas nouveau. La version en Rails a toujours fonctionné comme ça, et il me semble même que la version templeet permettait aussi de faire ça.