Mais c'est génial ça : Une radio physique à base de Rpi qui va écouter sur internet et qui démarre en 7 secondes !

via http://www.dotmana.com/weblog/author/tweepy/
via http://www.dotmana.com/weblog/2019/08/dual-sim-micro-sd-hack/
via http://nicolas-delsaux.hd.free.fr/Shaarli/?WH7wzA
via https://book.knah-tsaeb.org/?8tEERg

Ça vient idéalement compléter le petit hack que j'avais imaginé (à mon niveau de connaissance) : https://orangina-rouge.org/wiki/doku.php?id=radio

Parce que c'est une routine que je répète régulièrement afin d'encourager la sécurité : 

1. Considère que tout le monde veut te tuer ;
   littéralement, en particulier par omission.
2. Tu es invisible sur la route ;
   à toi de te rendre visible et d'anticiper les actions des autres .
3. Ne laisse jamais ton comportement être influencé par les autres ;
   tu roules à ta façon, c'est tout.
4. Tu as beau être prudent, un jour tu te prendras peur à cause de ton excès de confiance ; 
   ça va te donner une bonne leçon, tu sera plus attentif après ça, mais tu recommenceras ; c'est inévitable.

Édition 2020-05-26 : traduction en anglais :

1. Consider that everyone wants to kill you; literally, especially by omission.
2. You're invisible on the road; it's up to you to make yourself visible and anticipate the actions of others.
3. Never let your behaviour be influenced by others; you just drive your own way, that's all.
4. You may be careful, but one day you'll get scared because you're overconfident; this will teach you a good lesson, you'll be more attentive afterwards, but you'll do it again; it's inevitable.

#mes2sous

« Car pour coder des tests automatisés il faut prévoir du temps. Environ 20 à 30% de temps de dev en plus. »

Ce que j'avais appris c'est que pour être propre, le test « visible » ça représente 50% du temps de dév. Et si on inclue le test « invisible » (débug, tests unitaire, lecture de console, revue de code, …), en réalité tester prend autant de temps que coder.

« Le client veut les features 1 à 14, donc vous devez faire les features 1 à 14. Point.
On préfère donner au client une version instable et pleine de bugs avec des bugs qui contient ces 14 features, qu'une version ultra stable et testée qui contient que 10 features. Car contrat, engagement, tout ça. »

Et c'est de ce constat que l'on est passé d'une conception « cycle en V » au « développement Agile ».

« En plus, quand, en tant que dev, on doit estimer un sujet, ben on oublie tout ça. On estime "ok une journée pour ça, une journée pour ça, et une journée pour ça, donc 3 jours".
Sauf que t'as pas calculé qu'un logiciel plantera. Qu'un autre sera incompatible avec un prérequis. Que le besoin client sur un point précis changera pendant ces 3 jours. Que le serveur aura pas la bonne mise à jour pour un des plugins. Etc. »

Ou alors : « Fonction 1 = 1 jour ; Fonction 2 = 1 jour ; Intégration de fonction 1 avec fonction 2 = 1 jour. Total pour 2 fonctions = 3 jours. »
Après il faut faire attention car 3 fonctions = 6 jours, 4f = 10j, 5f = 15j, …

« Perso j'ai une règle ultra simple dans l'informatique. Tu dois estimer un truc ? Tu estimes honnêtement combien de temps il te faut pour le faire.
Ensuite tu fais x2 pour une estimation réaliste et réalisable.
Et si tu veux faire du code propre, tu fais x3. »

#tafdak

J'en profite pour essayer d'énumérer les types de préparation du café :

• Cafetière à piston, « Frenchpress »
• Café filtre
• Cafetière italienne à percolateur
• Machine à expresso, « moka »
• Chemex (que j'ai découvert au Québec)
• Cafetière Cona, « à dépression » (que quelqu'un dans mon entourage m'a fait découvrir) : https://www.maxicoffee.com/blog/test-de-la-cafetiere-cona/
• Café turque
• Senseo / Tassimo / Nespresso

1. Start Pilot : pas idiot d'avoir ça sous la main.
2. Batterie : quand je la rince à force d'insister, ça serait pas mal d'avoir un chargeur sous la main ; ou au moins une paire de pinces.
3. Poussette : cf quote ci-dessous.
4. Bougies : usure ou encrassement général ; écartement des électrodes.
5. Filtre à air : encrassement.

Savez-vous qu’auparavant, les départs des Grands Prix moto s’effectuaient à la poussette ? La difficulté pour démarrer seul une moto à la poussette dépend de son poids… et de votre force physique. Enclenchez la seconde et débrayez. Mettez-vous du côté de la moto qui vous convient le mieux, droit ou gauche, pour la pousser. Faites prendre le maximum d’élan à la machine. C’est sa masse lancée – autrement dit l’énergie cinétique – qui compte. Dès que vous sentez que vous ne pourrez pas pousser plus vite, sautez en amazone sur la moto en lâchant simultanément l’embrayage pour que la roue arrière accroche au sol sous l’impact de votre poids. Si le moteur est dans de bonnes dispositions, il démarre à ce moment-là. S’il tousse sans vraiment bien démarrer, redescendez de la selle pour continuer à pousser. C’est là que la position amazone révèle son intérêt : le postérieur sur la selle et les deux jambes du même côté permettent de reposer instantanément les pieds au sol et de reprendre la poussée jusqu’à ce que le moteur rugisse. Dès que ça ronfle, tenez le régime moteur à la poignée de gaz en débrayant. Arrêtez-vous doucement au frein avant, c’est gagné ! Inutile de dire que si vous trouvez une personne pour vous aider à pousser, ce sera plus facile…