Site original : le hollandais volant links
Je ne sais pas si vous connaissais ce site, mais il râle tous les jours contre les « petits trucs pourris » dans le design sur le web (mais parfois aussi ailleurs).
Il râle sur des détails, mais il faut dire qu’il a très souvent raison.
Le nav (en ligne) : https://worldwideweb.cern.ch/
Tiens, à l’époque ils n’avaient PAS DE PUB… ni de popup… ni de trackers sur les sites.
Un photographe japonais de chats. Des chats partout \o/
Mention pour celle là : https://www.instagram.com/p/BUhMS6UDuEz/ :D
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.
Mh…
Je vois qu’ils supportent le BQ Aquaris X chez LineageOS. Je pourrais éventuellement essayer (j’ai jamais fait ça, pour info).
Je sais que BQ permet de déverrouiller le bootloader, vu qu’ils fournissent leur propre outil pour le faire et qu’il y a un bouton dans les paramètres pour le faire (je ne sais pas si c’est comme ça partout).
(PS : je vois que ce blog, Holory.fr, est tout récent ! Je viens de l’ajouter à mes flux RSS =))
Ça devient un peu n’importe quoi le grand débat.
[…]
– Bon, toutes ces news des politiques à la con me dépriment. Je vais aller jouer un peu à ce jeu.
*joue 5 minutes*
*popup sauvage apparaît*
– bonjour, c’est Manu ! Tu as 5 minutes pourvoter pour moi au proch…parler #grandDébat ?
– AAAAAAAHHH
[…]
Ces dernières années le développement de avconv et de ffmpeg a été bordélique, en particulier avec les dépôts linux : l’un étant le fork de l’autre, ils sont entrés, sortis, re-rentrés dans les dépôts, etc.
Y a même eu des paquets de compatibilité qui faisaient des alias de l’un vers l’autre.
Aujourd’hui en 2019, c’est ffmpeg qu’il faut utiliser.
Je viens de passer 1 h à essayer de trouver pourquoi je ne pouvais pas utiliser ffmpeg : j’avais fait un alias à moi dans mon .bashrc >_<.
Bref…
Voici un script pour convertir tout un tas de MP4 en MP3. En prime, il déplace tous les MP4 dans un dossier "mp'.old" et affiche une notification quand une vidéo est terminée :
#!/bin/bash
for i in *.mp4;
do ffmpeg -i "$i" -c:a libmp3lame -ab 320k -vn "$i.mp3";
notify-send --icon="info" "Conversion terminée" "$i" --expire-time=2000;
mkdir mp4.old;
mv "$i" mp4.old/"$i";
done
notify-send --icon="info" "Toutes les conversion sont terminée !" ":-)";Sous Mint Mate : mettez ça dans un fichier "mp4tomp3.sh" puis dans le dossier ~/.config/caja/scripts. Rendez-le ensuite éxecutable :
cd ~/.config/caja/scripts && chmod u+x *.shEnsuite allez dans un dossier avec des vidéos, clic droit > scripts > mp4tomp3.sh et c’est bon =)
(d’autres scripts là)
Comment ne pas trouver ça absurde :
– un DVD : 10 à 20 € le film
– 223 films et payer 1 800 € : 8 € le film.
La fossilisation, c’est quand un être vivant (enfin, mort du coup) se retrouve à la merci des éléments : chaque atome organique de son corps finit par être remplacé par des minéraux inorganiques, en préservant plus ou moins sa structure biologique (organes, etc.).
Ici, un environnement riche en cuivre a permis de remplacer, atome par atome, son corps par des atomes de cuivre. Résultat, le scorpion est devenu 100% cuivre.
Repartager la thune d’une boîte à ceux qui font tourner la boîte est toujours une bonne chose : ce n’est que justice.
Pour rebondir sur ça :
Ce ne sont pas les salariés des grands groupes français qui en ont le plus besoin. Or ce sont eux qui vont très majoritairement la toucher.
Ça pourrait éventuellement en être autrement, si les boîtes qui font le plus de bénéfices payaient des impôts qui sont ensuite redistribués directement ou indirectement à ceux qui en ont besoin…
100 milliards d’euros d’évasion fiscale par an, ça représente plus d’un smic par habitant français (pas par foyer, par habitant).
100 milliards d’euros d’évasion fiscale par an, ça permet aussi de combler la dette en 15~20 ans, et donc de virer peu à peu la CRDS (et donc de bénéficier à tous les travailleurs).
Je suis en train de jouer du JS pour faire une PWA (progressive web app).
Un des aspects sympa est la gestion du cache : on utilise le cache et les données hors connexion du navigateur pour notre PWA.
Comme le dit la page, le truc c’est que c’est au PWA de gérer si une URL doit être cachée :
– url des images, des scripts, des CSS : mis en cache
– url des XHR et requêtes renvoyant des données JSON (par exemple) : pas de cache.
Dans ce dernier cas, la PWA ignore son cache et lance une requête, qui atterrit… dans le navigateur !
Les PWA sont des app (en JS/HTML/CSS) dont le moteur d’exécution est le navigateur. C’est le navigateur qui gère les requêtes réseau (entre autres).
Et concernant ces dernières requêtes non cachées par la PWA, le navigateur décide :
– soit il fait une vraie requête vers le serveur
– soit il cherche dans son cache disque à lui
Donc même avec un bouton « rafraîchir » dans la PWA, on n’est pas assuré que les données soient bien transmises au serveur, et il n’y a aucun moyen de forcer ça depuis la PWA.
… enfin si : en ajoutant un paramètre (timestamp par exemple) à l’URL, mais là, ça peut poser problème pour le cache interne au PWA (qui risque de cacher toutes les URL identiques ne différant que par leur timestamp).
La solution, c’est d’agir au niveau du serveur : ajouter une en-tête Cache-Control au fichier appelé par le XHR :
Cache-Control: max-age=0Soit en PHP :
header('Cache-Control: max-age=0');Là, le navigateur ne conservera pas le fichier en cache disque, et si la PWA fait une requête, elle atterrira sur le serveur à tous les coups.
J’ai pas de mots.
Le commentaire qui résume bien la situation, c’est ça :
AKA : too lazy to learn CSS specificity
La médiathèque digitale est victime de son succès ! C’est pourquoi, durant une courte période, nous diminuons le prêt de documents sur la plateforme numérique. Vous pourrez désormais emprunter 5 documents par mois au lieu de 10.
La photocopieuse à PDF est en état de surchauffe ?
*facepalm*
On parle des documents numériques, hein.
Pas un livre, pas un magasine. Non : un fichier. UN PUTAIN DE FICHIER.
OUI, LE TRUC QU’ON PEUT COPIER À L’INFINI SANS QUE PERSONNE NE SOIT LÉSÉ DE SA PROPRE COPIE !
Comment voulez-vous construire un monde numérique avec des tartuffes pareil ?
Ceux qui inventent ce genre de système, je crois qu’il ne faut pas leur demander l’heure dans la rue : ils risquent de ne plus l’avoir eux-même dès l’instant où ils nous la donnent… C’est n’importe quoi…
Une photo de 81 Mpx de la Lune.
Il a combiné 50 000 photos en une seule. L’idée ici c’est la précision de l’image de la Lune : une seule photo prise avec un appareil photo de 81 Mpx ne serait pas aussi nette à cause du flou atmosphérique. La combinaison d’un grand nombre de photos permet d’éliminer le flou.
Post original : https://www.reddit.com/r/space/comments/arer0k/i_took_nearly_50000_images_of_the_night_sky_to/egmo9s8/
(via)
TL;DR Legal : un site qui montre clairement ce qu’on peut faire ou pas avec une licence (ici, Apache 2).
J’imagine que ceux qui boycottent Amazon à cause des conditions de travail des employés vont aussi boycotter tous les jeux vidéos maintenant ?
Autant vous dire tout de suite : boycottez aussi les supermarchés, les hôpitaux, les services postaux, les smartphones et l’éléctronique en général, les vêtements de marque (et de sous marques aussi), les bijoux et autres produits de luxe manufacturés à la chaîne par des intérimaires sous-payés (y compris et surtout ceux des "grands" créateurs), bref, boycottez tout.
Bien évidemment, vous faites ce que vous voulez, mais le problème n’est pas une entreprise ou une autre. Le problème c’est que c’est comme ça partout. C’est que c’est comme partout et que ça l’est de façon légale…
Tiens, voilà un exemple parfait de la progression d’une onde sans déplacement de matière : les dominos ne se déplacent pas, mais la progression de la chute si.
Toutes les ondes ou vagues font ainsi, mais sur les dominos c’est très bien visible.