Tiens? une police conçue pour coder... À essayer.

A lire... Je ne sais pas trop dans quelle mesure l'analyse de décision peut vraiment aider à résoudre des pbs vraiment complexes...

Très intéressant, je résume:

1. Il faut écrire du code pour les gens, pas pour les ordis (programmes courts, noms consistents, prog cohérente)
2. Laisser l'ordinateur faire le travail (faire des macros pour tout)
3. Avancer de façon incrémentale (on avance petits pas par petits pas, on ne cherche pas à atteindre l'objectif final d'un coup, utiliser git)
4. Ne jamais se répéter dans le code (en particulier, chaque jeu de données ne doit avoir qu'une seule représentation de référence dans le code, modulariser le code plutôt que copier collé, réutiliser le code des autres plutôt que le réécrire)
5. Prévoir la présence d'erreurs (mauvaise utilisation, tester le code dans toutes les config possibles, etc.)
6. Optimiser seulement une fois que ça marche (en particulier, commencer par programmer en haut niveau avant de passer au bas niveau)
7. On documente le design et l'objectif, pas le fonctionnement du code (en particulier, il faut documenter ce que le code ne dit pas, pas résumerr ce qu'il fait).
8. Collaborer (partager le code; le gars recommande le version control à tour de bras + issue tracking tool)

Google commence à poser des brevets sur des idées en machine learning. Ça sent vraiment le roussi... Comme l'indique le commentateur sur reddit:

"I am afraid that Google has just started an arms race, which could do significant damage to academic research in machine learning. Now it's likely that other companies using machine learning will rush to patent every research idea that was developed in part by their employees. We have all been in a prisoner's dilemma situation, and Google just defected. Now researchers will guard their ideas much more combatively, given that it's now fair game to patent these ideas, and big money is at stake."

Ben putain, c'est bon à savoir:
some-command <(another-command)
va exécuter "another-command" -- il faut que cette autre commande écrive le résultat dans stdout -- et va passer le résultat à some-command (avec some-command une commande qui prend un nom de fichier comme argument). Donc pas besoin de stocker dans les fichiers, on passe directement le résultat du l'une à l'autre. Comme un pipe, sauf que (i) on peut substituer autant de commande qu'on veut, par exemple:
diff <(curl http://somesite/file1) <(curl http://somesite/file2)
va substituer les deux curl et les passer à diff; et (ii) les commandes substituées sont lancées en parallèle et pas à la suite.

Et le package R qui fait l'interface vers le service web.

Intéressant. L'UEFI est déjà un système merdique quand on veut utiliser un système linux. Je l'avais toujours compris comme un moyen coercitif de Microsoft de décourager l'utilisateur de se tourner vers un autre système. En fait, c'est pire que ça: même si l'on choisit de rester sous windows, si la carte mère plante, les données sont perdues puisque le disque dur est associé à une carte mère.
Enfin, comme il l'indique, ya toujours moyen d'utiliser linux pour récupérer les données, mais bon: (i) pour l'utilisateur moyen, c'est mort, (ii) dans tous les cas, le disque dur est foutu (puisque lié à la carte mère).

Et les constructeurs laissent faire...

Énormément de webinaires sur plein de sujets, autour de R.

Un joli comparatif comparant R et Python. Avantages et inconvénients de chacun. Sur le long-terme, python pourrait bien passer premier. Pour le moment, on en est encore loin...

Ah tiens, je connaissais pas: xmpp permet de faire du chat, un genre de msn libre.