400,000 GitHub repositories, 1 billion files, 14 terabytes of code: Spaces or Tabs?

#16250

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.

https://medium.com/@hoffa/400-000-github-repositories-1-billion-files-14-terabytes-of-code-spaces-or-tabs-7cfe0b5dd7fd#.d13spy79y

Exact Instructions Challenge - THIS is why my kids want to kill me. - YouTube

#16221

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.

GitHub - timovn/simple-js-toc: Creating a table-of-contents in a HTML file, based on h1, h2, h3… elements

#16044

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

Note : la securité c’est hasbeen

#15925

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 ?

http://lehollandaisvolant.net/?mode=links&id=20160730191134

J'ai codé la nuit de noël - GBProd

#15868

J’ai quotidiennement ce problème dans mon métier, je suis sûr que vous connaissez ça.
Cette personne qui vient vous voir en disant :

“Gilles, je peux te déranger 5 minutes ?”

En réalité, juste en posant cette question, elle vient déjà de me déranger 20 minutes alors que je ne lui ai pas répondu.

S’il vous plaît, respectez l’état de concentration, de “transe” des développeurs.

http://gb-prod.fr/2016/07/20/j-ai-code-la-nuit-de-noel.html

Justice n’est pas toujours rendue | CommitStrip

#15783

Ben oui, c’est bien connu : les systèmes d’exploitation, les Facebook ou Google, les HTML et PNG, les algo et tout le reste, ça tombe du ciel sur un CD que t’as juste à mettre dans le lecteur de ton ordinateur, lui aussi apparu sur le marché du jour au lendemain…


… et surtout pas grâce à 70 ans de recherche en nanotech, quantique, matériaux, chimie, optique et en logique, langages, électronique, prog par des gens ayant 160 de QI pour imaginer, concevoir, créer concrétiser et améliorer des machines qu’on utilise du bout des doigts.

Mais tout ça n’est pas grave : même la plus inintéressée des personnes ne peut nous retirer la joie et l’excitation de voir son tout premier morceau de code afficher « hello world » sur un terminal en noir et blanc, même après 42 compilations ratées :D

http://www.commitstrip.com/fr/2016/07/07/justice-is-not-always-served/

La moitié des groupes de presse français viendrait de perdre toute trace de leurs abonnés – Korben – Matronix.fr

#15716

Une petite remarque à propos des lecteurs RSS : si j’ai fait mon lecteur RSS perso, c’est parce qu’il n’y en avait aucun qui ne fonctionnait comme je voulais.

Un des problèmes que je voyais, c’est le temps de chargement entre chaque lecture : à chaque ouverture de post, le navigateur contacte le serveur pour recevoir le contenu de l’article qu’on demande à lire. Entre le moment où l’on clic et le moment où le contenu arrive dans le navigateur, il s’écoule un temps où on ne peut rien faire et c’est chiant.

Le problème quand l’interface et la BDD ne se trouvent pas sur le même système, c’est de synchroniser les deux. À la fois pour le contenu et pour le les actions de l’utilisateur.

Mon lecteur, c’est l’ensemble des éléments non-lus qui se trouve dans le navigateur : donc pas de requête serveur pour obtenir le contenu d’un article, le navigateur l’a déjà. Oui, la quantité de données dans le nav peut sembler importante, mais c’est relatif : 500 articles, ça fait ~2,2 Mo. C’est beaucoup, mais c’est à peine plus que le poids moyen d’une page web aujourd’hui. Ça charge en 3 secondes avec une connexion 8 méga. Ce délai est unique, juste au chargement.

Ensuite, pour la sync des interactions utilisateur (marquage comme lu, etc.), je fais un cache dans le nav : plutôt que de faire une requête serveur à interaction lu, je ne sync que tous les 10 articles lus. C’est là aussi beaucoup plus rentable.

Ce qui prend du temps, aujourd’hui, ce n’est plus la quantité de données à transférer, mais la quantité de requêtes faites au serveur. 10 connexions de 1 Mo sont beaucoup plus lentes que 1 connexion de 10 Mo.
De même pour les requêtes SQL : faire une seule requête pour marquer 10 articles comme lu, c’est plus rapide que 10 requêtes pour un article.

http://www.matronix.fr/la-moitie-des-groupes-de-presse-francais-viendrait-de-perdre-toute-trace-de-leurs-abonnes-korben/