… juste un immense rube-goldberg électronique !

Sans aller jusqu’au binaire, quand on appuie sur le bouton « On » d’un PC, entre le BIOS, le POST, le lancement du chargeur de démarrage (boot-loader), le démarrage de l’OS, la connexion à un compte, le lancement automatique des services et des programmes… Ouais, c’est juste un rube-goldberg très finement réglé.

Et là encore : il y a la partie matérielle, mais aussi la partie logicielle : plutôt que de faire rouler des billes, on écrit des instructions compréhensibles par une machine qui dit où la bille doit aller…

Et comme les OS font plusieurs millions de lignes de code, ça fait un sacré nombre d’étapes, et un sacré nombre d’étapes qui peuvent foirer !

Faut pas non plus oublier que la création de ce rube-goldberg électronique se fait comme sa version matérielle avec des billes : des tests, des tests, des tests. C’est qu’une fois que ça marche bien — et bien à chaque fois — que l’on inclut une étape de plus dans tout le programme.

Tout ça pour que l’utilisateur final puisse râler quand ça marche pas au lieu de s’émerveiller quand ça tombe en marche.

I prefer coding everything by hand, because I don’t like the huge piles of garbage that the automated generators create. These programs that generate a website, app, or file for you spit out thousands of lines of unnecessary junk when really only 10 lines are needed. Then people wonder why their site is so slow, and they think it’s their phone or connection’s fault.

Pareil.

Je déteste les WYSIWYG précisément parce que leur code est globalement pourri et plein de merde.

Son exemple du SVG est typique : qui au nom de l’univers a besoin d’une précision au milliardième de pixel pour son logo ? Personne ! Mais les éditeurs SVG vont généralement mettre une dizaine de chiffres significatifs dans toutes les valeurs, là où un chiffre ou deux après la virgule suffisent amplement.

Et même chose pour les framework tout fait : les 3/4 du truc ne sert à rien et ne sera jamais utilisé dans le projet… mais sera chargé tout de même.

Normalement on met le HTML à afficher sur une image, qu’on envoie au nav en base64 dans du JSON. Côté client, on utilise une lib de décodage base64 (pas que tous les nav ont ça désormais, mais c’est mieux avec une lib de 600 ko) puis un scanner OCR de 3 Mo et ses dépendances (2 Mo, dont une implémentation de pong en webGL que personne n’a demandé) avant d’incorporer ça dans le DOM.

Une explication très simple :

The characters "Ow!" will be converted to three 8 bit byte(0x4F, 0x77, 0x21)
These 3 bytes will be transformed to 24 bits(01001111 01110111 00100001)
These 24 bits will be divided into groups of 6 bits(010011、110111、011100、1000001).
Each 6 bits will be a value between 0 and 63, it will map to one of 64 characters above. The end result after encoding is "T3ch".

Il a pris "null" pour sa plaque.
Depuis, tous les PV dont l’auteur n’est pas connu arrivent dans sa boîte aux lettres…

Y a pourtant une solution simple pour remédier à ça, ça s’appelle le typage ><.

Pour ceux qui ne programment pas, les variables ($variable) peuvent avoir différentes types : tableaux, nombres, chaines de caractères, valeurs booléens (vrai/faux), null, undefined…

Par exemple :

$variable = null

La variable reçoit la valeur "null". La variable existe, est définie, mais sa valeur est "null", autrement dit « rien ».

Dans le code :

$variable = "null"

La valeur reçoit comme valeur la chaîne de caractère « null ». Sa valeur est une chaîne de caractère « null », mais la valeur n’est pas "null" comme ci-dessus.

La différence est un peu comme la différence entre des chiffres et des lettres :

$variable = 6

Ici, la variable est un nombre : 6.

Par contre là :

$variable = "six"

Ici, la variable est une chaîne de caractères : « six ». Si on veut additionner « six » avec « cinq », le programme affichera une erreur : on n’additionne pas des chaînes de caractères, des mots. Ça n’a aucun sens.

De même là :

$variable = "6"

La variable est encore une chaîne de caractères, à cause des guillemets. En prog (généralement) les guillemets servent à délimiter une chaîne de caractères. Les nombres, eux, sont assignés directement, sans guillemets.

Malheureusement (je pense), certains langages sont laxistes.

Ainsi, ils diront que « 6 » et « "6" » sont égaux. Alors oui, les valeurs sont égales, mais pas les types ! Le premier est un nombre, l’autre une chaîne de caractères.

Or c’est là que le typage est important : on peut faire des tests pour savoir si la valeur correspond ET si le type correspond. Et c’est bien ça qui manque au système informatique dans l’article : ils ne font pas un test de type, juste de la valeur.

Dans d’autres langages, le type est scrupuleusement respecté, et de telles erreurs n’apparaissent pas.

Il y a parfois pire : dans certains langage, la valeur booléenne « false », une chaîne vide « "" », le nombre « 0 », la chaîne « "0" », la valeur nulle « null », la chaîne « "null" », un tableau vide « [] », ou un tableau avec juste 0 dedans « [0] », sont tous égales entre-elles si on typages sont ignorés.
C’est très souvent la source de confusion et de problèmes…

Il y a parfois encore pire : en JavaScript, on peut tester si une valeur est un nombre. C’est pratique si on souhaite vérifier que la variable peut être additionnée, multipliée, etc.
Si on ne le fait pas et qu’on effectue des calculs sur une chaîne de caractères, on obtiendra la valeur/erreur « NaN », pour « not a number », ou « ce n’est pas un nombre ! ».

Ce qui est amusant, c’est que « NaN » possède le même type qu’un… nombre !

Haha !

Vous n’aimez pas votre code ? Cassez-le en mode "breakdown" directement dans Vim.

people started to realize the number of bugs was increasing, not decreasing. It turns out that developers were creating more and more bugs, only to fix them afterward and get the prize.

Oh tiens, c'est un peu comme en politique...

:/

C’est pour ça qu’il ne faut pas être surpris des applications qui, de plus en plus, se payent par abonnement (à commencer par des trucs Microsoft, ou Google) : ça assure un revenu continu et permet de voir sur le long terme (même si avec 100 G$ de cash, on peut voir l’avenir sereinement, concernant M$ ou Google).

Alors certes, pour un OS à 300 €, on est en droit d’avoir les mises à jours durant 5 ans… Mais pour une appli vendue 1 € sur le Play Store, ce n’est pas viable pour un dév de la vendre une fois et de proposer des mises à jours indéfiniment. Pourtant, si on veut qu’une app, même une petite app, reste à jour, sécurisée, suive les versions d’android, évolue avec la technologie… il faut du travail. Beaucoup de travail.

Le code, c’est réécrire constamment des portions du code avec des nouveaux trucs. Un peu comme réécrire des portions d’un livre pour suivre les évolutions du langage et toujours être compréhensible par tout le monde. La langue n’évolue pas vite, mais imaginez avoir à traduire un pavé comme la Bible de l’an 1 à l’an 2019, de l’hébreux, au français moderne, en passant par le latin et toutes les étapes intermédiaires.

Je comprends tout à faire la recherche d’un modèle qui dure dans le temps (pub, abonnement…), même si je n’approuve pas forcément toutes les solutions, et même si je n’ai pas moi-même de solution.

**

J’en profite pour le dire : soutenez les petits dév.

Ce sont de vrais gens qui font les applis à 1 € dont vous vous servez tous les jours. Surtout s’il n’y a pas de pub et que l’app est gratuite et que la version payante est basée sur le volontariat.

1 € ce n’est rien. Même si ça vous arrive une fois par mois.
Mais pour une application qui n’a même que 5 000 téléchargements, ça représente pas mal pour le développeur. Un salaire, en fait : de quoi vivre et abreuver le monde de nouvelles applications.
Il ne s’agit pas de mettre une pièce dans le téléphone à chaque fois qu’on utilise une app, mais une seule fois. Rien que ça, ça permettrait de faire vivre beaucoup de dév.

En tant que blogueur et codeur, en 10 ans, si chaque visiteur avait mis 1 centime dans son ordi la première fois qu’il a visité mon site, j’aurais touché assez pour ne plus avoir à me soucier de l’avenir, financièrement parlant.

C’est pour ça que je pense que, les modèles comme Patreon ou Tipeee sont pas mal, même si elles ont leur limites.
Un avantage, c’est que chacun peut donner combien un veut, peut, ou combien il estime que ça vaut.

J’ai ma propre page Tipeee, BTW, pour Couleur-Science pour le moment (pour voir). Il y a déjà eu quelques dons (le compteur est mis à 0 tous les mois sur leur site, j’en ai eu 4 ou 5 de montants variés) merci à vous !

Je pense l’ouvrir aux autres trucs (blog, outils en ligne…).

Un comparatif de différents systèmes d’encodage de données (JSON, XML, Avro…)

0 VS Null

L’image directe : https://pbs.twimg.com/media/D3EXyb7WoAASPpX.jpg

On pourrait ajouter undefined : il suffirait de retirer le porte rouleau.

ÉDIT : Ah ben voilà : https://twitter.com/Artheriom/status/1113085796117082112 :)

Pas forcément fan de tout, mais il y a néanmoins de bonnes astuces et conseils.

Je veux bien que les dév soient des humains, même chez Microsoft ou Google, mais y a des erreurs qu’on s’attendrait à ne pas voir dans un code aussi utilisé, aussi testé (et aussi cher) que le leur.

Par exemple, comparer des chaînes de caractères avec une fonction pour comparer des nombres…

C’est plus une erreur là, c’est de la négligence, voire de l’incompétence.

Les Services Workers JS sont pratiques, mais bordel que c’est chiant à débugguer !

Je suis obligé de mettre des console.log() à toutes les lignes pour savoir ce qui se passe :o

Ici, c’est *juste* la fonction qui intercepte les requêtes réseau de la page (toutes les requêtes : XHR, mais aussi les fichiers scripts, les CSS, les fonts, les background-image()…).

La fonction permet de voir :
– si une requête doit être mise en cache (fichier, image) ou pas (requête de type json/ajax).
– si elle doit être mise en cache, alors on regarde si le fichier s’y trouve. Si oui ? retourne le fichier. Si non ? fait une connexion réseau. La connexion, fonctionne-t-elle ? Si oui : récupère la réponse et la met en cache, puis retourne la réponse. Si non, emet une erreur.

Le truc c’est que pour que le script puisse prétendre être une bonne PWA, aucune requête ne doit finir sur une erreur (404 ou autre). Si l’app est offline, la requête ne marchera pas, mais l’erreur doit être gérée (normale, me diriez-vous, mais c’est assez lourd quand-même).

Autrement, une fois qu’on a notre fonction, comme ça, c’est à peu près tout ce qu’il faut pour transformer n’importe quelle page web en PWA avec capacité de faire du offline (du moment qu’on séparre bien le shell de la page des données, d’où l’intérêt de travailler avec des requêtes Ajax qui envoie des données (json ou xml, html…) qui sont ensuite incorporées dans la page.

Le rendu est spectaculaire et 'achement rapide.

Regardez sur le site de Stéphanie Walter (sous Firefox) : c’est rapide comme l’éclair ! https://stephaniewalter.design/

Et pour cause : la gestion du cache est gérée par la page web (le service-worker) : il suffit de naviguer quelques pages pour que toutes les données soient mises en cache et après c’est super rapide : seulement 14 ko de données sont transférées pour la page d’accueil !

Et normalement ça fonctionne aussi en offline.

Oui, le navigateur a son propre cache… mais il est imprévisible, d’une part, et d’autre part il y a toujours des requêtes réseau de faites, qui vérifient si les cookies sont bons, si les ETAG sont modifiées, si le fichier n’a pas changé, etc.

Ici, les requêtes réseaux sont interceptées par le Service Worker.

Bien-sûr, ce n’est pas une raison pour se lâcher et arrêter d’optimiser ses pages : cette rapidité doit servir à permettre un usage offline du site (c’est pratique pour lecteur RSS en JS par exemple). J’ajoute simplement le raccourcis sur le bureau android (ou iOS, ou Windows 10 comme "webapp") et c’est bon !

Si je suis en ligne, il rapatrie les données mises à jour, autrement il utilise ce qu’il possède en cache.

En plus, les navigateurs utilisent des bases de données locales pour les données en cache : on peut donc très bien utiliser des BDD pour nos données (pas besoin de rester au JSON/XML).

Ah ben si, ça existe : après le brainfuck et le whitespace, voici emojicode : fini les "function", "if", "echo" ! Maintenant on utilise ça :

🏁 🍇
  😀 🔤Hey!🔤❗️
🍉

Fini aussi les true/false, maintenant c’est 👍/👎.

:D

(via)

Toilet humor :)

(par contre c’est mal indenté)