Les Joies du Code - Humour de développeurs : gifs, memes, blagues

Bonjours LJDC !

Je ne pense pas me tromper en disant que vous êtes un peu des geeks, au moins sur les bords.
Je vais peut-être faire un raccourcis rapide, peut-être même violent, mais vu que vous êtes des geeks, y a des chances que vous connaissiez l’existence des flux RSS.

Si oui, EST-CE QUE VOUS POUVEZ AFFICHER VOTRE FLUX RSS DANS LE CODE SOURCE DE VOTRE PAGE ?

Et sinon, EST-CE QUE VOUS POUVEZ AFFICHER VOTRE FLUX RSS DANS LE CODE SOURCE DE VOTRE PAGE ?

Comme ceci : https://i.imgflip.com/6m9njw.jpg

Merci.

Car ni vous ni personne n’allez me faire croire qu’un site qui partage 3,37 Mo de gifs va être ralenti par 0,000 97 Mo de HTML.

D’autant plus que ce flux RSS existe déjà : https://lesjoiesducode.fr/feed

RSS Feed Best Practises

Quelques conseils pour faire un flux RSS (ou surtout Atom) qui tienne la route.

Suivre des flux RSS avec FreshRSS

Un article pour présenter très rapidement FreshRSS et les lecteurs RSS en général.

Le RSS permet de suivre plusieurs blogueurs ou sites en même temps, sous une même interface, sans pub ni filtrage, au contraire des réseaux sociaux, donc.

Par contre à ceux qui ont des sites avec du RSS : mettez des flux avec les articles en entier. Si vos articles ne sont pas sous pay-wall, laissez-nous lire l’article chez nous plutôt que nous forcer à cliquer, attendre le chargement de votre site puis le lire chez vous. C’est chiant autrement et ça gâche l’intérêt du RSS.

Working With Web Feeds: It’s More Than RSS - CSS-Tricks

Un article promouvant le RSS.

Le RSS, sur un site, si vous n’avez pas déjà ça, ce n’est pas compliqué : plutôt que de récupérer les articles et des formater en HTML avec un template donné, vous le formatez avec du XML relativement standard et c’est bon.

Le RSS (ou l’Atom) c’est juste une autre façon de diffuser une liste d’articles, de posts, de liens…

On peut faire du RSS pour tout. Vous avez une galerie d’images ? Faites un flux RSS où chaque entrée = une image. Des vidéos ? Même chose. De la musique ? Même chose.

C’est pour ça que c’est si pratique : le lecteur RSS (le client RSS) récupère toutes les entrées au format XML, les trie, puis les affiche à l’écran (en HTML, pour les lecteur RSS web-based).

Changements à venir pour FeedBurner (Google): infrastructure plus moderne, des fonctionnalités en moins

C’est la fin de la fin pour les RSS chez Google. Ce système est (comme l’e-mail) trop ouvert, trop permissif, pas assez flicable pour Google (tu parles : une simple requêtre web, par un programme de fond et non un internaute, sans cookies ni rien).
Je sais, ils ne le coupent pas totalement, mais c’est le début : le système marchait très bien, tout changement ne peut donc que le détériorer.

Bref :
– aux blogueurs, installez votre propre flux RSS (c’est simple à faire : juste à mettre vos articles dans une page XML au lieu d’une page HTML)
– aux internaute, installez un votre lecteur RSS (c’est simple à faire aussi : juste un petit programme à installer, un lien à copier, et vous êtes abonnés ; et vous recevrez tous les articles de tous vos sites dans la même fenêtre, au même format)

PS : je prévois une release, bientôt, de oText, mon outil de blog/rss/liens/agenda/notes, nettement amélioré et plus joli, et toujours aussi léger !

Je ferais un article pour vous montrer comment le RSS c’est cool, simple, miam miam :-D

Why I Still Use RSS | atthislink

+1

Le RSS permet :
– de ne suivre QUE les sites que l’on veut (sans subir des postes sponsorisés qui viendraient s’y glisser — bien-sûr oubliez Feedly pour ça, qui faisait (fait ?) exactement ça) ;
– de suivre ce que l’on veut : une playlist vidéo ? un blog ? un forum ? des modifs sur un Wiki ? des nouvelles photos sur un site de partage de photos ? Tout est possible : tant que c’est au format RSS, on peut tout regrouper au même endroit et c’est trié selon vôtre envie : par date, par type, par source…
– de suivre tout ça sur l’appareil que vous voulez. C’est comme l’e-mail : peu importe l’appareil, ça marche partout.
– de choisir l’outil que l’on veut. Il y a des centaines de lecteurs RSS que l’on peut installer sur son ordi ou sur son espace de stockage en ligne. Un lecteur ne vous plaît pas ? Pas grave, y a le choix.
– de faire votre propre lecteur RSS. Aucun lecteur RSS du marché ne vous plaît ? Apprenez à coder et faites le vôtre.

Le RSS, c’est vieux et low-tech.
Y a pas d’Ajax qui fait des requêtes à tout va, ni d’API à la mode : c’est juste du XML statique dans un fichier texte.

Mais ça marche, c’est ouvert, libre, gratuit.

À tous les sites : remettez vos flux RSS ! Ne soyez pas con et ne virez pas ça !

Il fut une époque où Twitter avait des flux RSS, où Youtube ne les cachait pas et où Facebook permettait à la fois de suivre un profil via RSS, et de publier le contenu d’un RSS sur votre « mur ». Tout ça c’est du passé : c’était trop pratique, trop simple, trop gratuit probablement. Faites pas comme eux.

Ray Ortega ✊ sur Twitter : "RSS = direct connection to a creator.Anything less = someone else controls access to your audience. Podcasts are awesome cause they are inherently 'open.' If your podcast is not accessible via RSS, you don't actually have a podcast. Or ownership."

RSS = une connexion directe avec un créateur.

Tout ce qui est moins que le RSS = quelqu’un d’autre contrôle votre accès à votre audience.

Les podcasts sont géniaux, car ils sont naturellement « ouverts ».
Si votre podcast n’est pas disponible via RSS, vous n’avez pas réellement un podcast. Ni la propriété.

Encore faudrait-il que la plateforme proposant du RSS ne filtre pas le flux RSS en amont.
À part ça, ça résume bien la situation : le RSS c’est la liberté, le choix, l’ouverture, le contact, la neutralité.

La liberté : on est libre de l’agrégateur. Pas forcé de se connecter avec les outils imposés par un service (appli spécifique, site web spécifique).
Le choix : on peut choisir qui suivre, qui ne pas suivre, quand arrêter. On peut aussi filtrer des postes, les conserver, etc.
L’ouverture : le RSS est du simple XML. C’est un format ouvert, convertible, transportable… Pas un blob binaire ou une API bridée.
Le contact : ça permet à un créateur de communiquer directement des choses à ses abonnés, sans passer par un système de messagerie tiers.
La neutralité : ce qui passe dans le flux RSS arrive aux abonnés. Il n’y a pas d’algo de filtrage et de ciblage publicitaire comme sur Twitter, Facebook (normalement, et à condition d’utiliser un service digne de ce nom — exit Feedly donc, qui filtre, cible, suggère, monétise les flux).

GitHub - stefansundin/rssbox: I consume the world via RSS feeds, and this is my attempt to keep it that way.

Un outil similaire à RSS-Bridge. Il gère Twitter, YouTube, Vimeo, Instagram, Periscope, SoundCloud, Mixcloud, Twitch, Speedrun, Ustream, Dailymotion, Imgur, SVT Play.

Kill the Newsletter!

Un site qui transforme les newsletter en flux RSS.

Donnez un nom ; recevez une adresse mail "bidon" + un flux RSS ; inscrivez-vous sur le site avec l’e-mail et donnez le flux RSS à votre agrégateur.

A priori, ça devrait aussi fonctionner sur les réseaux sociaux : inscrivez-vous avec cet adresse, abonnez-vous aux gens que vous voulez, configurez le réseau social pour avoir les nouveaux posts par e-mail, et recevez-les par RSS.

Voilà :)

Bien-sûr, si votre site ne propose pas de flux RSS, commencez par contacter le site et lui demander d’activer ça. Si le site utilise des plateformes comme Tumblr, Wordpress, Blogger, Squarespace… il y a de bonnes chances qu’il existe un flux RSS mais qu’il n’est pas montré : il suffit de le forger et c’est bon.

Note : rapidité d’affichage d’un lecteur RSS

Je maintiens toujours mon propre lecteur RSS. C’est cool et ça me permet de faire face à des problèmes parfois incongrus pour des petits projets.

Déjà, faut savoir que ma connexion est pourrie (<2 Mo/s) et que je ne souhaite pas encombrer mon serveur de requêtes trop lourdes. Pour le moment, mon lecteur RSS tourne donc en local.
Si je met ça en ligne, ça me prendrait beaucoup de temps pour ne serait-ce qu’ouvrir le lecteur RSS.

Certains lecteurs RSS font une requête à chaque ouverture d’un post ou d’un site. C’est impensable pour moi : je ne veux pas attendre 3 secondes à chaque clics.

Depuis le début, l’ensemble des flux RSS "non lus" sont envoyés au navigateur. Généralement, ça fait entre 2 et 3 Mo, mais comme c’est en local, c’est instantané.

Je cherche à améliorer ça.

Je suis aussi sur le point de transformer mon lecteur RSS en PWA (application mobile en HTML/JS/CSS). Pour ça, je dois scinder l’interface de l’application des données. Vu que je bosse intégralement en JSON, c’est très simple.

Concernant la vitesse, en quelques lignes de JS j’ai ma page qui s’affiche et une fois chargée, fait une requête vers le serveur avec les données. C’est pas plus lent qu’avant (mais je fais un pas de plus vers la PWA).

Là où je m’interroge, c’est comment accélérer ça encore plus ?

Sur les 3 Mo transférés, la plus grande partie provient du contenu des articles, le reste étant plutôt des méta-données : date, ID, nom du flux et le titre de l’article.

J’essaye donc :
– à l’affichage de la page, l’interface s’affiche.
– Pendant ce temps, une première requête qui récupère titre + métadonnées et qui suffisent pour afficher les flux dans une liste.
– une seconde requête est ensuite faite qui récupère le contenu des articles et les attache à la liste principale.

La première requête suffit pour afficher la liste des flux : l’utilisateur peut commencer à lire les titres et à trier visuellement les articles qu’il souhaite lire (du moins, perso je fonctionne comme ça).
Pendant qu’il repère les articles qu’il va lire, la page récupère le contenu des articles (2,5 Mo).

Dans l’ensemble, ça prend peut-être quelques ms de plus pour charger, mais beaucoup moins de temps pour s’afficher : l’interface s’affiche instantanément, par exemple. C’est une question de perception de rapidité.

PS :
Quand je combine le résultat des deux requêtes, je fais deux boucles imbriquées, pour vérifier l’égalité tableau1[i].id === tableau2[j].id.
C’est un super-exemple d’utilisation du « break » dont je parle dans cet article. Une fois qu’il y a une égalité, on sort de la boucle et on passe à l’élément suivant.

Résultat : j’ai 471 éléments RSS à parser, donc 471×471 = 221 841 tours de boucles à faire. Avec le break, je prédisais qu’on gagne environ 50 % de la charge. Ça se vérifie sur cet exemple : le nombre de tours de boucle est de 111 214. Le gain est de 49,86 %. On y est.

En fait, je même beaucoup mieux : comme les deux requêtes renvoie deux tableaux de la même base de donnée rapidement à la suite, il est fort probable que les deux tableaux (triés en SQL) comportent la même indexation (sauf si une mise à jour des données RSS s’est glissée pile entre les deux requêtes).

On peut donc faire ça :


// si les ID sont identique, on ne reboucle pas (les deux tableaux comparent à la position « i »)
if (tableau1[i].id === tableau2[i].id) {
	# code here
}
// autrement, on recherche dans tout le tableau (tableau 1 sur « i », et le tableau2 sur « j »)
else {
	for (var j=0, len2 = _this.feedList.length ; j<len2 ; j++) {
		if (newFeeds[i].id === _this.feedList[j].id) {
			# code here
			break;
		}
	}
}

Dans le cas idéal, on passe à 471 tours de boucle (pour 471 éléments)
… au lieu de 111 214…
… au lieu de 221 841.

C’est bien non ?

PPS :
Finalement, le truc où je fais deux requêtes séparées c’est pas une bonne idée.
Ça marche, et l’idée peut fonctionner ailleurs, mais ici le gain n’est pas aussi important que je pensais. En fait, je viens de voir que les données sont déjà compressées par Gzip/deflate par le serveur (réduisant le poids de 2,5 Mo à 0,6 Mo environ).
Ça reste beaucoup de données, mais même avec une connexion pourrie, le temps que la connexion se fasse et que le serveur exécute la requête, j’en suis déjà à 1/3 du temps. Autant éliminer une des deux requêtes et n’en faire qu’une seule : ça reste plus rapide.

Récupérer ses flux RSS dans Firefox - Blog de dada

L’extension « want my RSS » peut vous aider.

Perso je suis avec Awesome RSS (qui fait la même chose).

Firefox 64 – Adieu le RSS – Korben

WHAT ???

Firefox 64 ne détecte plus les flux RSS/Atom et ne permet plus de s’y abonner ou de les lire nativement dans le navigateur. Sniiiif.

Pour des questions de… performances ??

Ils se foutent de nous ?
Tu vas pas me faire croire qu’il coûte un bras en terme de performances pour afficher une icône dans la barre d’adresse s’il y a la présence ou non d’un tag <link> dans le code source ?

Que le nav ne soit un plus lecteur RSS (ce qu’ils appelaient les « marque pages dynamiques » : mettez un flux RSS en marque page et vous avez tous les derniers liens via un clic), c’est une chose, mais pourquoi ne plus détecter le flux dans les pages ? C’est débile !

ÉDIT : ça me fait chier.
À chaque fois qu’ils se plaignent que Firefox est en chute libre, deux semaines après ils se tirent une balle dans le pied.

Je vais *vraiment* finir sous Vivaldi si ça continue, même si ça m’embête…

Mini-outil : trouver le flux RSS d’une chaîne YouTube - Le Hollandais Volant

Et un petit outil !

Quelques lignes de JS, mais ça rend le travail bien plus simple.

Astronomy Picture of the Day

Ce site de la Nasa est très sympa (et aussi très ancien, plus de 20 ans) : chaque jour une nouvelle photo d’astronomie.

Ils ont un flux RSS mais ce dernier est merdique : pas de GUID, pas de date, pas d’ID, bref, de la merde.

Voilà un flux réparé : https://acme.com/jef/apod/rss.xml .

Note : à tous ceux qui utilisent un lecteur RSS en ligne…

… assurez-vous que la liste des flux ne soit pas visible publiquement (si vous ne le désirez pas).

Je regarde un peu dans Google Webmaster là, et je vois que mes sites sont référencés par des tas de lecteurs RSS qui sont totalement ouverts au public (principalement Kriss-feed, mais pas seulement).

Si vous vous en foutez, alors moi aussi, mais sinon on peut (et n’importe qui, et n’importe quel moteur de recherche aussi) voir la liste de vos abonnements RSS. Et ça ne vient pas de Google Webmaster : n’importe quel webmaster peut voir d’où viennent les visiteurs, grâce au referer (le lien d’origine, que le navigateur communique au site visité), que tous les serveurs web enregistrent dans les logs.

Pour se prémunir de ça, une des solutions suivantes suffit :
– dites aux moteurs de recherche de ne pas visiter votre agrégateur RSS (avec le robots.txt — mais on doit faire confiance à moteur de recherche pour qu’il respecte cette consigne)
– dites au serveur web de ne pas laisser un moteur de recherche accéder à votre agrégateur (.htaccess ou autre ; mais un moteur de recherche peut très bien s’identifier comme un navigateur quelconque)
– utilisez un agrégateur qui n’affiche les flux que derrière une page de connexion (solution la plus sûre à mon avis).