Le Hollandais Volant

+1

Oui alors pardonnez mais NON.

Les Dell XPS sont des machines magnifiques, puissantes, très autonomes et j’adore les miens, mais leur clavier n’est pas fait pour programmer.

Je ne sais pas vous, ni les autres programmeurs, mais perso, j’utilise intensivement les touches "home", "End" ou "PgUp", bref, toutes les touches qui sont généralement sur la droite du clavier.

Sur ces portables, et sur beaucoup d’ordinateurs portables, en fait, ces touches sont refourguées en touches de fonction sur les touches fléchées (il faut donc faire Fn+Left pour avoir le "home"). Pire, sur les XPS les touches fléchées sont des demi-touches et c’est absolument MERDIQUE (à noter que Apple fait la même chose sur ses derniers mac-book-pro).

Pour ne rien arranger, le clavier sans fil Dell (de la même marque donc) est foutu de tel sorte que les touches citées plus haut sont tout en haut à droite du clavier (au dessus du pavé numérique). Ils sont là, mais ce n’est pas pratique.

Généralement, sur un clavier "normal", ces touches là sont accessibles sur le pavé numérique en désactivant le verrouillage numérique. Sur ce clavier Dell, il n’y a pas de bouton "num lock". Juste un bouton "CE" qui ne sert à rien. J’ai été obligé de remapper manuellement le pavé numérique pour avoir les touches home/pgUp/pgDn/… à la place du pavé numérique (que je n’utilise pas, je suis habitué à la barre numérique au dessus des touches alphabétiques).

Alors non, juste pour ça, je trouve que les XPS ne sont pas des ordis de prog (ni de jeu). Ce sont des très bons ordis, mais la disposition du clavier est à chier.

Une simple colonne supplémentaire à droite du clavier actuel, et remettre de vraies touches fléchées résoudrait tous les problèmes, mais autrement c’est la merde.

Je n’aime pas ça. C’est moche.
Il est donc impensable pour les designers de trouver un juste milieu entre un site tout bling-bling avec des animations absolument partout et une page sans CSS ?

Quant au fameux « ressenti utilisateur » il faut bien à un moment arrêter là aussi de se branler sur les Go de RAM dans les serveurs. Ajouter un super CPU et mettre 128 Go de RAM, c’est inutile si le script derrière est codé avec les pieds.

Apprenez à coder et à optimiser votre code !

L’ordre d’imbrication des boucles (for puis if, ou if puis for, ça peut tout changer…), le choix du moment où l’on fait son echo/appendChild, l’utilisation méconnue des "break" ou "continue", etc. ce sont ces choses là qu’il faut optimiser. Non je ne parle pas de grappiller des millisecondes. Inverser deux boucles imbriquées, ce sont parfois 300 ms de plus ou de moins. Sur un temps de chargement de 1s, c’est énorme.

Pendant 15 ans le web et le code a été écrit pour faire le truc le plus complet, le plus compatible et le plus fancy possible, sans tenir compte de la consommation des ressources système, tout simplement parce qu’on s’en foutait : il y en avait assez quoi qu’il arrive.

Aujourd’hui, l’ajout de hardware et la qualité du réseau ne suit plus bien. Il faut réapprendre à coder avec ta tête : non on n’a pas besoin d’un framework qui couvre toutes les fonctionnalités du monde. Un site web qui juste 3 boutons a besoin de 3 fonctions, pas 50 000 fonctions !

Faut apprendre à réutiliser sa tête, et ça c’est pas gagné…

Nan, c’est juste qu’ils ne permettent pas d’analyser des objets qui ont un trop grand nombre de niveaux d’imbrications. Le parseur en lui-même n’a aucun problème (je ne vois pas ça comme un soucis du parseur à proprement parler, c’est à dire le code qui va lire le JSON en entrée, bit par bit, et déclencher les fonctions qu’il faut au bon moment).

Selon l’article, Ruby plante à partir de 100 imbrications. C++ à 13 786.

C’est gênant, mais il faut bien une limite quelque part :/.

Il ne m’est jamais arrivé d’atteindre la limite sur le parsage du JSON. Par contre, j’ai déjà poussé à bout le moteur SQLite en PDO (qui a une limite de 1000 pour le nombre de variables que l’on peut mettre dans le prepare()).
Il me suffit alors de faire plusieurs requêtes plus petites au lieu d’un énorme.

Ce blog est une mine d’or.

Voilà au moins une bonne chose :

We are excited to have Microsoft, Google, The W3C, and Samsung on board as we continue on our journey to make MDN the premiere resource for developers.

Donc…
En JS, les mois vont de 0 à 11.
En PHP, les mois vont de 1 à 12.

Et les jours ?
En JS, les jours vont de 1 à 31.
En PHP, les jours vont de 1 à 31.

Le JS c’est à se taper la tête contre les murs, vraiment. Et là c’est juste une broutille (suffit de faire un −1 entre les deux langages [oui car mon PHP écrit du JS]). Mais parfois c’est bien plus chiant à corriger…

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