Nice, mais il y a toujours une frontière entre le matériel et le logiciel. Pourtant il faut bien passer de l’un à l’autre à un moment, et cette étape là est assez abstraite à expliquer…

Je m’étais tenté à le faire là : https://lehollandaisvolant.net/tuto/computer/#materiellogiciel

Mais je n’ai jamais été vraiment satisfait de ça. Je vais peut-être refaire un article tiens.

Je fais évoluer un peu mon lecteur RSS.

La principale amélioration se passe sur l’interface qui a été réécrite entièrement (en JS) et est maintenant beaucoup plus rapide, même pour trier ~200 flux et 2000 entrées (ah et y a les favicon maintenant)

« Je pose ça là », comme on dit.
À nouveau comme BT-RSS, il ne risque pas d’évoluer beaucoup. C’est un outil que j’utilise pour moi avant tout, et actuellement il me va.

(BT-RSS devenait 'achement lent donc j’ai tout recodé le JS et en voilà le résultat, ça marche dans Firefox et Vivaldi sous SQLite, pas testé ailleurs).

Je ne vois pas de différence entre un logiciel de notes chiffrées et un CMS avec une couche de chiffrement (façon Zerobin) par dessus.

À la limite, on pourrait même transformer n’importe quel CMS en blog chiffré. Même pas besoin de mettre les articles en "brouillon" ou "caché" : chiffrées, les données sont inexploitables.

==

Autrement j’en ai raz-le-bol de tous ces outils qui ne font que 99 % de ce que je veux. Je veux un truc qui fasse 100 % de ce que je veux (mais pas 101 %).
Pour ça, je suis content d’avoir appris à coder des trucs

Apprenez à programmer, les gens !

Atom feeds with ActivityStreams, Portable Contacts, Threads extensions for the actual content

Ah ben oui, donc Mastodon c’est juste un agrégateur Atom en temps réel :D

Ce sont des fous : ils ont analysé 14 To de code pour voir quelle méthode d’indentation est la plus utilisée : les tabulations ou les espaces.

Et ils ont aussi classé ça par langage, ce qui donne un résultat assez intéressant.

Marrant à voir :).

C’est également une métaphore de la programmation : quand on code, on ne fait que parler à l’ordinateur. Ce dernier est bête à manger du foin et il faut tout lui expliquer et dans bon ordre pour avoir le résultat attendu.

La phase où les deux enfants reprennent leurs instructions pour les améliorer, c’est la phase de débogage : on regarde ce qui va pas et on essaye de corriger, avant de redonner ça à l’ordinateur pour un nouvel essai.

À la fin, on voit que le sandwich est correct malgré le fait que certains points ne sont pas 100% acceptables (le couteau dans le mauvais sens, par exemple).
Ceci peut constituer une faille de sécurité (risque de blessure, ici), ou alors un point d’amélioration (tartiner avec le manche du couteau c’est pas aussi efficace que le faire avec la lame).
Le problème, c’est que si la gamine donne l’instruction à son père, qu’elle s’en va, puis qu’elle revient pour examiner le résultat, elle ne voit pas forcément ce qui ne va pas. Il faut analyser l’exécution du programme en profondeur (avec le stack-trace par exemple). Dans d’autre cas, pour analyser les éventuelles failles de sécurité, il faut avoir accès au instructions écrites (c’est le cas ici), qui est donc un argument pour les logiciels open-source.

Enfin, quand le résultat est correct et que la procédure est bonne, il reste toujours de la place pour l’amélioration :
– étaler la garniture sur *toute* la surface du pain ;
– le faire de façon régulière ;
– optimiser le nombre de passages du couteau ;
– bien faire plaquer les morceaux de pain ;
– …

L’analogie peut-être assez poussée.

Un bout de JS pour faire un TOC dans un document HTML.

Marre d’avoir seulement des scripts avec jQuery pour faire ça, ou alors des codes soit utilisant des regex, soit utilisant innerHTML (qui est lent) ou qui n’utilisent pas la gestion du dom correctement, soit utilisant des div/p, soit produisant un code non-valide.
Voici ce que j’ai et qui pallie à tous ces problèmes.

Résultat visible ici : http://lehollandaisvolant.net/linux/checklist

J’ai un problème dans Blogotext : parfois, quand je fais des requêtes trop vites, les tokens à usage unique sur mes formulaires POST n’ont pas le temps d’être mis à jour et seule la première requête est prise en compte.
Une des solutions a été de mettre les requêtes en cache dans le navigateur et de faire une seule grosse requête plutôt que 10 petites, donnant ainsi le temps aux requêtes de se faire (on fait rarement 10 clics par seconde sur une page web).

Je me dis d’aller voir dans d’autres projets pour voir comment ils s’en tirent (n’ayant jamais vu ce problème ailleurs) et trouver une solution.

Dans les codes que j’ai été voir :
– formulaires en GET (pas en post), donc une simple URL à copier-coller pour lancer une requête
– pas de token à usage unique
– pas de vérification de session (une URL d’une session fonctionne dans une autre session).
– heureusement, il y parfois une vérification de connexion à la session (on doit être connecté pour que l’URL fonctionne).

Visiblement la solution aux problèmes de sécurité c’est supprimer la sécurité.

Je veux bien qu’un moteur de blog ou un lecteur RSS ne soient pas des applications critiques et que les token CSRF c’est assez lourd, mais quand même : pas même vérifier la session, WTF O_o ?