Bruno Michel a écrit 3285 commentaires

Tu peux nous dire aussi combien il y avait de journaux en 2012 qu'on puisse savoir quelle proportion ça fait ?

Ça, c'est déjà dans les stats : http://linuxfr.org/statistiques/contents#annee (la réponse est ~1300).

Combien de journaux ont été créé cette année par des utilisateurs s'étant inscrit dans la journée ?

mysql> SELECT COUNT(*) FROM nodes JOIN users ON nodes.user_id = users.id WHERE DATE(nodes.created_at) = DATE(users.created_at) AND YEAR(nodes.created_at) = '2012' AND nodes.content_type = 'Diary';
+----------+
| COUNT(*) |
+----------+
|       33 |
+----------+

Est-ce que tu peux m'en trouver avec des notes positives ?

Un exemple parmi d'autres : http://linuxfr.org/users/gunther-freimann/journaux/l-open-source-un-gage-de-reproductibilite-en-science

mysql> SELECT COUNT(*) FROM nodes JOIN users ON nodes.user_id = users.id WHERE DATE(nodes.created_at) = DATE(users.created_at) AND YEAR(nodes.created_at) = '2012' AND nodes.content_type = 'Diary' AND nodes.score > 0;
+----------+
| COUNT(*) |
+----------+
|       23 |
+----------+
1 row in set (0.06 sec)

Cf https://github.com/nono/linuxfr.org/commit/f10995858c745689f1c144bf0cbfe06eb0074c6a

Le mode "push" en web s'obtient actuellement via WebSocket ou Comet.

Et surtout avec Server Sent Events, qui est vraiment fait pour ça et qui répond très bien à ce besoin.

Mais que ce soit du Server Sent Events, du WebSocket ou du Comet, le « push » se fait d'un serveur vers un onglet d'un navigateur. Cela veut dire que si j'ouvre 10 onglets avec la tribune de LinuxFr.org dans mon Firefox, je vais ouvrir 10 connexions vers le serveur qui vont toutes recevoir les mêmes données. C'est dommage de ne pas mutualiser ces ressources. La push API permet cela en ouvrant un canal de communication entre le navigateur et un serveur particulier, le serveur de push. Les applications pourront pusher des messages à ce serveur qui les transférera au navigateur, qui lui-même fera en sorte de les délivrer aux bons onglets.

Dans l'autre sens, si je ferme tous mes onglets, je ne pourrais plus recevoir d'événements. Un des cas d'usage de la push API est justement de pouvoir lancer une webapp quand un message arrive qui lui était destiné. Par exemple, si j'ai utilisé une webapp de météo pour configurer des alertes, je pourrais être prévenu qu'une tempête se prépare même si j'ai fermé l'onglet de cette webapp.

Il y a d'autres cas d'usage qui me laisse plus perplexe. Si j'ouvre mon webmail dans 2 navigateurs, alors je pourrais profiter de la même connexion (au sens TCP) pour recevoir des notifications pour les deux. Je suis d'autant plus perplexe que le choix de la méthode pour se connecter au serveur de push (Server Sent Events, SIP, SMS, etc.) est laissé au choix du navigateur.

Enfin, je doute que cette API soit rapidement utilisable : elle pose pas mal de questions de sécurité et vie privée. En particulier, je ne pense pas que ça puisse fonctionner sans la Web Crypto API, qui n'est, à ma connaissance, implémentée par aucun navigateur.

Je n'arrive pas à comprendre ce que tu n'arrives pas à saisir. Est-ce ça ?

[code]

Ou ça ?

<code>

Nope, la note était à +2 quand j'ai fait l'entrée. Des gens pas contents ont du voté « inutile » depuis.

Pour info, on peut faire tourner une instance de gitlab sur une Raspberry Pi avec 512Mo de RAM. Un collègue a testé et ça tournait très bien.

Sinon, Ruby est plutôt gourmand en RAM et Rails est une grosse base de code. Actuellement, les serveurs applicatifs fonctionnent avec plusieurs processus et comme Ruby n'est pas encore Copy on write friendly, ça peut vite faire une taille importante. Ruby 2.0 devrait justement régler ce problème (ou en tout cas, limiter son effet).

En fait, c'est l'inverse. Le code de gitlab était hébergé sur une instance lors des toutes premières versions de gitlab (les 0.x). Mais gitlab est fait pour des projets privés et non pas des projets Open-Source. Du coup, quand ils ont commencé à avoir des contributions externes, ça a posé problème et les créateurs de Gitlab ont donc décidé de passer leur code sur github pour favoriser les contributions externes.

Heu, je ne te suis pas.

Pour pouvoir lire hors-ligne sur une tablette, il va effectivement falloir télécharger tout le contenu de l'epub que l'on veut lire. Dans le cas du teabook open reader, les fichiers téléchargés sont ceux dézippés et retravaillés. Mais je ne vois pas en quoi ça perd de son intérêt.

Est-ce à cause de la taille qui va être plus conséquente une fois dézippé par rapport à avant ? Pour les epub qui font plusieurs Mo, c'est principalement parce qu'ils contiennent pas mal d'images et polices. Or, ce sont des contenus qui profitent très peu de la compression, la différence de taille est donc assez faible. Pour les textes en HTML, on est pénalisés mais je pense que ça reste tout à fait acceptable.

Est-ce à cause du fait que cela demande une action utilisateur pour télécharger un ebook pour le lire hors-ligne ? C'est gênant, mais les limitations de taille des stockages des navigateurs sur tablette (IndexedDB, WebSQL et localStorage) font qu'il serait de toute manière impossible de faire tenir toute la bibliothèque d'un lecteur sur sa tablette.

Donc, entre avoir sur sa tablette 6 ebooks au format epub, lents à afficher, ou 5 ebooks déjà dézippés, et donc plus rapides à afficher, je pense que la plupart des utilisateurs vont préférer la seconde solution.

Question intéressante. La partie serveur permet d'avoir certaines fonctionnalités comme la synchronisation de la position de lecture, mais pas seulement. Elle joue aussi un rôle important pour la simple lecture des fichiers epub.

Un epub est un zip qui contient des fichiers HTML, avec les images, CSS, JS, etc. qui vont avec, plus des métadonnées. On pourrait envoyer simplement le fichier epub au navigateur, puis faire tous les traitements coté client. Blaine Cook a, par exemple, écrit rePublish sur ce principe. Mais, on atteint vite certaines limites avec les ebooks que l'on peut acheter en ligne.

Prenons une BD au format epub (epub3 en fixed layout pour être précis), on va avoir un fichier HTML par page, et chaque page va afficher une image avec une résolution assez élevée. Le fichier va donc faire quelques Mo, disons 10 Mo. Des bibliothèques JS pour dézipper, ça existe mais celles que j'ai vu sont loin d'être aussi performantes qu'un unzip coté serveur. Sur un PC puissant, attendre une dizaine de secondes que le fichier 10Mo soit dézippé reste acceptable mais sur une tablette, vous risquez d'avoir fini votre trajet en métro avant que ça n'ait fini ;-)

En fait, j'ai même vu pire : Safari a préféré se suicidé lorsque j'ai fait ce genre de tests sur un ipad (au passage, je n'ai pas su si c'était à cause de la mémoire ou du CPU, quelqu'un aurait une idée de comment faire la différence ?). Du coup, avoir une partie serveur permet de profiter de toute la puissance d'un vrai PC pour l'opération de dézippage plutôt que d'être limité par celle d'une tablette.

Autre cas : on peut aussi trouver en epub des romans. On a notamment travaillé sur des best-sellers. On pourrait donc s'attendre à ce que les éditeurs aient un budget correct et que ces ebooks soient parmi ceux de meilleure qualité. Hé bien, pas vraiment. Dans certains cas, le HTML a l'intérieur de ces livres est une bouillie infâme (quelques centaines d'erreurs au validateur du w3c par chapitre). Pour d'autres, ce sont les chemins vers les images qui ne sont pas (les images sont dans un répertoire écrit en minuscules alors que le src des img fait référence au répertoire en majuscules, voire oublie complètement le répertoire en question).

On est donc obligé de préparer les ebooks à l'avance et ce travail est bien plus facile à faire coté serveur que coté client (tout particulièrement pour les histoires d'encodage). Ces hacks se trouvent dans le fichier app/models/ebook/epub.rb pour ceux qui voudraient y jeter un coup d’œil.

Enfin, il y avait aussi des raisons pratiques pour gagner un peu de temps de développement. Par exemple, on pourrait croire qu'extraire la couverture d'un epub est simple, mais pas vraiment. Du coup, avoir des bibliothèques comme Peregrin aide pas mal. Mais, ça reste anecdotique : les principales raisons du choix d'avoir une partie serveur ont été les fonctionnalités que cela apporte et les contraintes techniques (performances principalement).

http://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Flinuxfr.org%2Fjournaux.atom me dit que le flux est bien valide. À mon avis, le problème doit plutôt venir de claws-mail.

Le cache en question, c'est écrire sur le disque dur, donc pas trop de risque qu'il ne se vide. Je préfère toutefois parler de cache plutôt que de stockage permanent, car on va régulièrement rechercher l'image pour voir si elle a été mise à jour (en cas d'erreur, on garde l'ancienne version).

Merci, c'est corrigé.

Je trouve la critique assez sévère, mais admettons. Du coup, je me pose une question : à la place de TEA, tu ferais quoi pour améliorer le monde du livre numérique et le délivrer du joug d'Amazon ?

Pour un « simple » lecteur d'epub, il existe Readium. C'est une extension Chrome qui fonctionne de manière isolée, c'est-à-dire :

• il ne faut pas s'attendre à pouvoir l'utiliser avec son navigateur préféré dans un futur proche (sauf si celui-ci est chrome) ;
• aucune synchronisation entre plusieurs devices ;
• j'avais eu ds problèmes de stabilité avec Chrome après avoir importé certains epub (je n'ai pas retesté récemment, donc possible que ce soit corrigé) ;
• la communication se fait de manière assez agressive (par exemple, Readium se vante de sa prise en charge du format Epub3 Fixed Layout, mais celui-ci est assez ridicule, même la lecture de droite à gauche dans les mangas ne marche pas).

J'ai eu le plaisir de travailler sur ce projet, avec mes collègues d'af83, et de faire un retour d'expérience lors de Paris Web sur le choix du Web pour cette application, avec Anne-Sophie Tranchet. Donc, comme CrEv, je peux répondre aux questions dans les commentaires de cette dépêche.

Je voudrais également souligner l'effort de TEA, qui n'est qu'une jeune startup, et qui n'hésite pas à publier une base de code conséquente et à la faire vivre avec la communauté. Dans un monde, le livre numérique, où les DRM pullulent, où Amazon domine largement et peut même se permettre d'effacer des bibliothèques sans se justifier, j'espère vraiment qu'ils réussiront à faire bouger les choses.

Ma question c'est « comment nono développe ? »

J'ai tout installé sur ma machine. Elastic Search est particulièrement gourmand en RAM, donc je ne le lance que lorsque je travaille sur LinuxFr.org. Pour le reste (MySQL, Redis), ils tournent en permanence.

Oui, les images sont maintenant cliquables et pointent vers les photos sur flickr.

Seuls les modérateurs peuvent modifier les journaux. J'ai fait le changement d'image.

Question idiote : tu as remonté ce problème sur https://bugzilla.mozilla.org/ ?

Une raison de plus d'utiliser un vrai navigateur ;-)

Avec quel navigateur ?

Cf https://github.com/nono/linuxfr.org/commit/d496219f8d70e62ed7f39bc92eef8d82dee4aa81

Oui, ça devrait aller mieux suite à https://github.com/nono/linuxfr.org/commit/05163a148746552b19addab249767769c741f46d

La catégorie a été ajoutée.