Infaillible xD

Non, ce n’est pas une blague !

Ce langage reste très utilisé dans le domaine de la finance et des assurances.

Voilà ça c'est fait. D'autres questions tant qu'on y est ?

Belle illustration de la différence While / Do While :D

Chatted with someone who’s been working at a company as a front-end developer for 3 years. Their friend asked them to help build a website, but they had to decline. They didn’t know how.

Haha, c’est un des problèmes de produits tout faits tout prêts : ça empêche d’apprendre.

Bien-sûr, si le site devient un gros truc, il faut partager le taf et se spécialiser (front, back…), mais de là à ne même plus savoir écrire un index.html sans fautes tout simple, et à partir de là pour faire pousser le projet… Sérieux ?

Ah mais voilà un truc qui serait pratique, effectivement !

Cela dit, si les fanatiques de l’IA font leur job correctement, et que, comme ils disent, un jour les programmeurs seront inutiles, on pourra le faire.

Sauf que ça : https://www.commitstrip.com/fr/2016/08/25/a-very-comprehensive-and-precise-spec/

Et le machine learning comme avec Translate ne marchera pas car la plupart des langages n’ont pas d’équivalences en d’autres langages, car les applications ne sont pas les mêmes…

Le WebAssembly devient un standard du Web.

(via)

Affichez Couleur-Science dans un navigateur.
Mettez-vous en hors-ligne (dans Firefox : Touche "Alt" > Fichier > Travailler hors connexion)

Rechargez la page de Couleur-Science.

:D
Ça reste affiché avec un message spécial « offline ».

Bref, le site est dispo en PWA très basique.

Il n’y a pas de fonction de stockage local des articles, je n’en vois pas trop l’intérêt sur un blog comme le miens, mais ce genre de mini-PWA permet surtout de mettre en cache local très rapide certains fichiers utilisés par le site.

Les pages se chargent très rapidement après ça (et je ne cache pas (jeu de mot) que les moteurs de recherche aiment bien la SEO aussi).

Par contre, tant qu’on est en hors-ligne, ça n’affichera toujours que ce message là.

Les PWA permettent bien plus, ceci-dit. Au lieu du message « vous-êtes hors-ligne », on peut faire (tout en JS) un système de sauvegarde hors-ligne du contenu des articles, et une navigation hors-ligne également.
Dès qu’on repasse en ligne, le site récupère la page normalement.

Ce que j’ai fait là (je bricole :D) tient en quelques lignes de JS. Je ferais peut-être un article pour expliquer tout ça : c’est très rapide à faire.

De plus, ça permet aussi, sur mobile, d’afficher votre site en plein-écran et de le mettre sur le bureau avec une icône personnalisé. D’ailleurs, sur Firefox Android, une petite icône de maison a dû apparaître dans la barre d’adresse (je dis normalement car j’ai pas regardé, j’ai un maître-chat sur les genoux :-)).

M’enfin c’est cool, je bricole du JS.

--

Autrement, concernant CS : j’ai toujours essayé d’avoir quelques articles sous la main histoire d’avoir un rythme de publication régulier.

J’avoue être passé par une période un peu "vide" depuis 3 mois. Je n’ai pas d’explications pour ça, parfois c’est juste un peu dur d’écrire, ça vient pas (ou peut-être mon nouveau taf, depuis juin, qui me prend pas mal de temps).
Ça ne s’est pas trop vu grâce à ce stock tampon d’articles, que j’avais écrit à une époque où j’étais très inspiré.

Je viens de reprendre l’écrire d’un gros tas d’article (je suis plein jusqu’en mars 2020 là — où le blog fêtera ses sept ans :D).
Les articles sont à peu près rédigés, il me reste à les relire, les illustrer avec mes schémas et les retoucher un peu.

Bref, les blogueurs, et tout créateur connaît ça je pense.

--

Je suis aussi nettement moins actif sur LHV et côté prog. Mais je ne délaisse pas le blog.

Niveau prog, je code surtout pour moi, et en ce moment je suis plutôt satisfait de mon petit écosystème en ligne (liens, RSS, blogs, notes, agenda, outils en ligne…). C’est pas ce qu’il y a de plus puissant, mais ça me suffit.

Pour le blog, he manque de temps, et je publie davantage dans mes liens « au fil du web ».

Bref, bonne soirée à tous :-)

… 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...