Hitchhiker’s guide to diversity in tech

A l’invitation d’à peu près tout Twitter, j’ai regardé ce week-end la keynote d’Audrey Neveu à bdx.io.

Et ce qu’elle dit dans cette présentation est à la fois très juste, et particulièrement frappant. Je ne vais pas paraphraser (parce que vous pouvez regarder la vidéo – ça ne prend que 45 minutes, et ça vaut vraiment le coup), mais plutôt vous parler des aspects qui m’ont marqué.

Le premier, qu’Audrey passe sous silence (sans doute parce que c’est assez pénible à expliquer clairement et que je vais échouer), est le côté séparateur de l’humour : généralement, quand on fait une blague, on la fait au dépens d’un groupe de personnes. De cette manière, on sépare le monde entre ceux qui rient et ceux dont on rit. Et évidement, on ne rit qu’assez peu de ceux qui ont le pouvoir, ou qui le représentent. Donc on rit des minorités : les femmes, les personnes racisées, les personnes aux sexualités différentes. C’est moche. J’ai beau le faire (de moins en moins souvent, j’espère), c’est quand même très moche. Et franchement, il est plus intéressant (dans ma position d’homme blanc hétérosexuel) de se moquer de ceux qui ont le pouvoir. C’est évidement un peu moins facile, mais plus gratifiant.

Le second, et là, Audrey en a bien parlé, c’est l’empathie. Sans elle, il est impossible de comprendre pourquoi la douzième blague sur le ménage dans la journée va taper sur les nerfs de la seule collègue du plateau. Sans vouloir pinailler, je relève toutefois que cette empathie s’oppose de façon frontale aux stéréotypes de genres des hommes, d’une part, et de l’aspect sociopathe des structures de pouvoir des entreprises. Et c’est peut-être le point qui rend la lutte contre les discriminations difficiles dans l’informatique : elle implique des qualités qui n’entrent pas dans le moule culturel de notre milieu.

Notez bien que je ne cherche pas là des excuses. Au contraire, je pense que ce que dit Audrey dans cette conférence est parfaitement juste. J’aimerais pouvoir lui dire que je m’excuse pour les abrutis qu’elle a pu rencontrer, parce que clairement, elle n’est pas tombée sur des génies.

Enfin, j’ai beaucoup apprécié l’émotion qui se dégageait de l’ensemble de cette présentation. Il n’était manifestement pas évident pour Audrey de faire cette présentation, et je la remercie pour ces efforts, en étant conscient d’un point spécifique : qu’une femme vienne faire une présentation à une conférence, c’est toujours bien. Que les femmes soient cantonnées à des présentations sur la diversité, ben c’est pourri. Je préfère dix fois qu »une femme vienne m’expliquer du Javascript ou d’un autre sujet technique plutôt que de diversité. Je n’étais pas sur place, je n’ai donc pas pu lui demander, mais j’ai l’impression qu’elle partage mon point de vue, et que ça, en plus de la standing ovation et du sujet évidement sensible, a pu rendre Audrey un peu émue en fin de présentation. Parce qu’elle est émue, ça se voit. Et (même si je me répète) je comprend parfaitement son émotion. J’aurais évidement préféré qu’elle n’ait jamais à faire cette présentation, mais malheureusement tout le monde n’est pas forcément capable de comprendre l’intérêt d’avoir de la diversité dans son équipe.

En tout cas, regardez cette présentation, c’est important.

Publicités

Quelques jeux de société pour plus tard

Vous connaissez Martin Vidberg ? Non ? Le dessinateur de patates ? Il tient un autre blog qui m’intéresse beaucoup : Un monde de jeux. Allez-y voir, c’est vraiment chouette.

J’y ai en vu quelques jeux particulièrement intéressants

  • Forteresse qui commence à mon avis très facilement avant de se compliquer rapidement
  • Fluxx parce que j’adore le nomic et les jeux qui jouent avec les règles
  • Mission pas possible, qui me paraît être réellement à mi-chemin du serious game pour « team-ressouding »
  • Peanut club, dont les enchères semblent furieusement amusantes

Je ne sais pas quand je les achèterai, mais je pense que ça viendra …

La RGPD contre les téléconseillers

J’ai eu l’extrême déplaisir de recevoir un coup de téléphone d’un téléconseiller aujourd’hui.

J’ai longtemps lutté contre cette nuisance par le biais de scripts de réponse autour desquels il est facile d’improviser. J’y ai rapidement ajouté la mention nécessaire de l’enregistrement de l’appel, qui me permet de prendre mon temps pour mieux justifier ma démarche : oui le téléconseiller va perdre beaucoup de temps (et peut-être de l’argent) avec moi sans aucune chance de conversion. Mais c’est nécessaire pour garantir que l’appel remonte la chaîne et que le prestataire ayant fourni mon numéro de téléphone soit correctement châtié.

Mais aujourd’hui, j’ai compris que tout avait changé grâce à une phrase clé : « pouvez-vous m’indiquer comment exercer mon droit à l’oubli au titre du RGDP ? ». Si la personne au bout du téléphone ne peut pas répondre … vous pouvez engager une demande de poursuites auprès de la CNIL, demande poursuite pouvant se solder par une amende de 4% du chiffre d’affaire mondial du groupe détenant l’entreprise.

Personnellement, ça m’a mis en joie cet après-midi après que j’ai raccroché avec ce fameux téléconseiller.

Un week-end avec MailSpring

J’ai parlé la semaine dernière de FoxMail. Et je voulais tester MailSpring. Le test a toutefois été très rapide.

En effet, l’interface est bien lissée (comme la police d’ailleurs). Mais la configurabilité est très limitée et … pire … le volet d’information sur le contact ne peut pas être supprimé ! Et franchement, il prend de la place ce volet. Qui plus est, la navigation entre les mails est un peu limitée.

J’ai donc désinstallé MailSpring environ 1/2 heure après l’avoir installé.

Résultat ? J’utilise toujours ce bon vieux Thunderbird qui a certes des défauts, mais qui marche bien.

Une semaine avec FoxMail

Je ne sais pas si vous savez, mais je suis un fervent utilisateur des mails. Je trouve en effet que cette interaction asynchrone par nature est parfaite dans notre ère du distribué, du rapide. Parfaite parce que ça permet à chacun d’avancer à son rythme. Et ça, contrairement à l’exigence d’instantanéité de l’horreur slackienne. Donc j’aime beaucoup les mails.

Et ça fait un bon moment que j’utilise Thunderbird, dont je n’apprécie que très peu certains éléments : une interface … datée. Mais bien plus que ça, des lenteurs, voire des blocages, difficilement explicables. Il faut bien reconnaître que j’ai une longue histoire de clients mails, avec Opera Mail, Outlook Express (quoi ?) et, depuis quelques années, Thunderbird, donc …

J’en ai donc eu marre, et j’ai voulu passer une semaine avec FoxMail.

FoxMail, c’est donc un logiciel chinois, traduit en français via un sale patch. Je ne dis pas par là que les traducteurs français sont mauvais, plutôt que la méthode de traduction est, à cause des développeurs de FoxMail, assez sale.

Alors évidement, il y a un support de l’IMAP très correct. En plus, l’interface est confortablement réactive. Mais il manque des possibilités de personnalisation. Et le navigateur web utilisé pour le rendu ne bloque pas les images distantes (ce qui est très mauvais en termes de sécurité, figurez-vous). Et les emojis ne sont pas supportés ! Et pour quelqu’un qui lit twitter par mail, les emojis, c’est utile (surtout pour les gens de CleverCloud qui semblent assez fans de ces emojis). Donc, ça ne va pas trop.

Alors que faire ? Revenir vers Thunderbird la queue entre les jambes ? Ou aller encore plus loin dans la trahison et essayer l’une des applications mail Electron ? En l’occurence, je vais aller voir du côté de MailSpring, qui malgré son poids énorme (un chromium + nodsjs + le backend C++ de synchro des mails) a l’air ergonomiquement correct …

Mastermind en Rust

Dans le monde du développement, il y a certaines idées qui semblent bizarre, mais qui sont en fait géniales. Les katas en sont un parfait exemple. Et comme on s’est lancés au bureau à un trimestre Rust, on a logiquement commencé par un kata pas trop dur …​ Mastermind. Et comme je l’ai promis à mes collègues, je me fends d’une solution annotée (si toutefois la sortie Asciidoc passe bien dans WordPress).

Démarrage

Facile

cargo init

Crée un projet cargo avec un code source basique, qu’on va modifier (évidement il faut avoir installé Rust et Cargo).

NOTE Si vous voulez développer plus vite, cargo a l’avantage d’être extensible (et un tas d’extensions intéressantes sont listées sur Awesome Rust). Je vous recommande d’installer cargo-watch, ça ira plus vite …​

On commence en TDD

Evidement, on est propres, donc on commence par écrire un test.

#[cfg(test)] (1)
mod tests {
    (2)
    use super::*; (3)

    #[test]
    fn can_evaluate_r_r() {
  1. Le module de test ne sera activé que dans la configuration test …​ qui est celle lancée par cargo test (ou cargo watch -x test)
  2. En Rust, on déclare les tests unitaires dans un module (qui peut être dans le même fichier, ou dans un autre).
  3. Pour appeler les fonctions déclarées dans notre fichier, il faut déclarer au compilateur qu’on utilise le module parent, grâce à cette syntaxe …​ un peu curieuse.
  4. Ensuite, comme avec l’annotation @Test de JUnit, on déclare notre test. Il ne reste plus qu’à coder un test !
  5. Evidement qu’il y a une bibliothèque d’assertions !

Et on implémente …​ intelligement

Là je sors du TDD classique des katas pour livrer tout de suite la solution complète.

Comme je n’ai pas envie de perdre mon temps, c’est le moment de lancer cargo-watch. Donc cargo watch -x test, et c’est parti pour le code ! Heureusement, j’avais une bonne idée de l’implémentation.

Une fonction

Les tests le montrent bien, on a une belle fonction evaluate(…​)

/// Public interface of the evaluation function
/// The return value is *ALWAYS* a two-elements array
pub fn evaluate(secret: Vec, user: Vec) -> (i32, i32) {

En théorie, évidement, personne n’utilise de Vec dans une interface …​ Ni de tuples, mais bon, c’est un kata, hein.

Des couleurs !

Parce qu’il nous faut de quoi stocker nos couleurs. Donc, hop, un enum !

#[derive(Clone, Debug, PartialEq)] (1)
pub enum Color {
    RED,
    GREEN,
    BLUE,
    YELLOW,
}
  1. Les enum peuvent implémenter des traits (ou des interfaces). Et le compilateur permet d’implémenter automatiquement les interfaces classiques via l’attribute derive.

Et du code

Enfin, il nous faut une implémentation.

pub fn do_evaluate(mut secret: Vec, user: &[Color]) -> (i32, i32) {
    let mut returned = (0, 0); (1)
    if let Some((first_user, next_user)) = user.split_first() { (2)
        if let Some(index) = secret.iter().position(|c| c == first_user) { (3)
            if index == 0 {
                returned = (1, 0);
            } else {
                returned = (0, 1);
            }
            secret.remove(index); (4)
        }
        if !next_user.is_empty() {
            let other = do_evaluate(secret, next_user); (5)
            returned = (returned.0 + other.0, returned.1 + other.1); (6)
        }
    }
    returned
}
  1. Créer un tuple, c’est facile !
  2. Là, c’est typique : la méthode split_first() découpe notre vecteur en extrayant la tête et la queue. C’est trèèèès lispesque. Mais surtout, comme il n’y a pas de null en Rust, cette méthode retourne une Option (qui est donc un enum avec deux variantes structurellement différentes). Et comme je ne veux pas m’embêter à gérer le cas None, j’utilise le if let de Rust. Et comme je sais que le contenu sera un Some qui contient un tuple, je me retrouve avec ce if let Some(…​.).
  3. Comme j’ai deux vecteurs à découper, je recommence l’opération sur l’autre.
  4. Ici, c’est l’élément fonctionnel intéressant : quand j’ai trouvé si un élément était dans la liste des secrets, je le supprime de cette liste. Oui, c’est un effet de bord et c’est mal. Mais c’est un kata.
  5. Et pour pouvoir parcourir toute la liste, un peu de récursion, c’est cool !
  6. Et enfin, un petit ajout de tuples. La syntaxe d’accès aux éléments du tuple est toutefois un peu curieuse.

Et ça marche ?

Ben oui !

running 2 tests
test tests::can_evaluate_r_r ... ok
test tests::can_evaluate_r_r_b_r_r_r ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Et le code complet est sur GitHub.

Un midiconf sur Keepass

Chez Zenika, on aime bien partager des trucs avec des collègues. Ca peut être l’apprentissage d’un nouveau langage, d’un nouveau framework, d’un nouvel outil. Et j’en ai fait une il y a quelques semaines sur Keepass. Parce que j’aime cet outil, et que je suis toujours effaré par les gens qui ne se servent pas […]

Et si j’arrêtais de faire n’importe quoi avec mon Raspberry ?

Parce que la dernière alerte a été sévère.

Je vais donc essayer ce soir d’améliorer deux ou trois choses …

Optimiser la gestion des logs

D’abord, l’article Comment prolonger la durée de vie de vos cartes SD sur Raspberry Pi (màj) montre comment utiliser un tmpfs et RAMLog pour ne plus saloper la carte SD avec les écritures de log. Ca m’avait l’air très bien jusqu’à ce que je regarde la méthode d’installation … Pas terrible.

Et en bonus, le démarrage m’avait l’air hasardeux …

Du coup, je ne l’ai pas installé, car je lui ai préféré log2ram (trouvé grâce à ce forum). Si l’installation n’est pas plus conviviale, il s’agit ici de script shells qui m’ont l’air plus inspectables, et surtout sont intégrés correctement avec la gestion des services de Raspbian.

Reste à voir sur le long terme si j’arrive à sauver l’engin …

Créer des backups corrects

Bon, ben là, il y a un bon paquet de solutions à base de dd. Ca ne m’intéresse pas trop, parce qu’il faut arrêter le Raspberry.

J’ai donc privilégié une solution basée sur un bon gros rsync bien massif.

Parce que même si ce rsync ne me permet pas de reconstruire de façon  immédiate un Raspberry fonctionnel, j’aurais au moins toutes les données sur mon NAS, ce qui aidera.

Introduction à JHipster au chtijug

Julien Dubois vient donc nous présenter le framework qu’il a créé …​ JHipster. Spring, c’est un gros paquet d’ingrédients. Spring Boot, c’est la même chose bien packagée. Et JHipster, c’est ce package encore décoré. Autrement dit, c’est un générateur d’application full stack avec Spring Boot en back-end, Angular et React en front-end (mais Vuejs arrive bientôt), et préconfiguré pour être facilement déployable.

A noter que JHipster est 100% open-source sous licence Apache (la meilleure pour le commerce, quand même).

C’est un projet qui réussit : 22 développeurs dans la core team, 500 contributeurs, des conférences, des étoiles GitHub, …​

Pourquoi ?

JHipster fait gagner du temps au démarrage (avec des études qui montrent un gain de 6 semaines au démarrage), au build (comme le projet est très utilisé, le code généré est stable et fiable), et au run (le monitoring est déja prévu).

Stack technique

front-end

JHipster propose une stack complète, avec des front bien connus. Mais attention : tous les widgets de l’univers ne sont pas supportés. Parce que ça fait trop de code d’une part, mais aussi parce que ce sont des technologies qui évoluent très rapidement.

back-end

Evidement, le back est intégralement Spring .. il y a toutefois quelques choix qui sont faits (par exemple, JHipster utilise toujours DropWizard Metrics, parce que la communauté n’est pas fan des nouvelles métriques Spring).

Outillage

Les tests de base sont déja préparés. En revanche, les tests Gatling ou Protactor sont optionnels …​ mais ajoutables facilement.

Par ailleurs, JHipster suppose que vous utilisez Docker …​ parce que c’est pratique et c’est quasiment un standard. Cependant, si vous voulez utilisez MySQL ou Elastic, il faudra en passer par là.

Le déploiement est préparé pour heroku (beaucoup utilisé parce que gratuit), Kubernetes, OpenShift, …​

Architecture

JHipster permet de générer une architecture microservice, en créant un module par service de back-end et un ou plusieurs modules de front-end.

Il peut aussi utiliser une service registry (celle de Netflix ou de Consul sont intégrées) ou une API gateway.

L’objectif étant d’avoir la même expérience développeur que pour un monolithe. Ca paraît séduisant sur le papier …​

Et enfin, il est possible de créer des microservices réactifs utilisant Spring Boot 2 …​ et les composants Spring réactifs, évidement.

Toutefois, sur le sujet des microservices, je me dois d’avouer qu’à mon ens on est déja là dans une démarche dépassée : aujourd’hui, le marché semble converger vers les service meshs (Istio, Consul Connect, ou Conduit). Et franchement, continuer à implémenter la couche de service dans l’application … c’est lourd, c’est peu efficace, et ça rajoute de la complexité au mauvais endroit.

Démo

Et c’est parti pour la démo à la cool !

Installation

On peut installer JHipster avec npm (wat ?), Homebrew, Chocolatey, …​

Mais on peut aussi, comme pour Spring boot (ou Wisdom Framework), créer le projet depuis le site web de JHipster. Donc on se connecte, et grâce à l’intégration GitHub/GitLab, le projet est directement créé dans le gestionnaire de source (comme avec Jenkins-X).

Les options de création de projet sont assez nombreuses (monitoring, authentification, base de données, …​). C’est l’un des intérêts de JHipster : gérer des sujets auxquels Spring Boot ne s’intéresse pas. L’impact évident, c’est que le démarrage est plus lent que Spring Boot …​ qui n’est déja pas fameux sur ce sujet. Parce que JHipster démarre un EHCache, un hibernate, …​

En dehors de ça, JHipster peut gérer l’accès à ElasticSearch, ou Kafka. Dans le cas d’Elastic, ça a un impact sur le front et sur le back (parce que JHipster génère les outils d’accès, et l’interface de recherche). Qui plus est, le docker-compose.yaml sera également généré pour le développement avec Elastic.

Et lorsqu’on clique sur « generate on GitHub », le projet est automatiquement généré avec les bons *ignore.

Ouverture du projet

Donc le projet a été généré avec un pom.xml pour maven, et un package.xml pour générer le front-end. Et au lancement, on démarre node et maven, le front et le back se lance (pour le front, après avoir copié 1/2 Go de dépendances Node). Ca me trouble un chouaï, parce que je ne vois pas pourquoi il faut lancer deux outils de build différents … pour produire les deux morceaux de la même application.

Spring-boot et webpack sont configurés pour faire du rechargement à chaud, ce qui fait qu’il n’y a pas besoin de relancer les outils de build. C’est quelque chose qu’on a aussi dans Spring-Boot, dans Wisdom Framework – mais bien mieux (désolé, mais c’est vrai) ou même en Rust avec cargo watch.

L’application est générée avec de l’authentification, ce qui est cool, mais aussi tout un tas d’écrans d’administration. On peut voir les métriques, les niveaux de logs (et les changer), …​ C’est franchement pratique.

Il y a également un browser-sync, qui permet d’avoir plusieurs clients synchronisés (c’est typiquement pratique pour le développement web avec des écrans réactifs).

Et encore la configuration Docker …​ avec le fichier de configuration permettant l’accès à la base de données.

Et beaucoup de configuration Java, pour optimiser les performances de Jackson, par exemple, ou pour corriger des implémentations pas optimales, ou pour lier le front-end et le back-end. Une librairie équivalente existe évidement côté Javascript, encore une fois pour faciliter la vie du développeur.

Et enfin les bases d’une application : un utilisateur, ses droits, les repository Spring Data, les contrôleurs web permettant d’y accéder, et même les messages internationalisés.

Ecrire du code

JHipster fournit des sous-générateurs. Donc pour créer une nouvelle entité, il suffit de taper jhipster entity Foo par exemple.

JHipster Studio

Avec ce studio, on peut décrire facilement des entités dans un DSL …​ qui ressemble furieusement à un descripteur UML. Ce studio est utilisable dans une interface web, ou via un plugin Eclipse (cool). Et le modèle peut être appliqué sur une application préexistante. L’avantage du studio web, c’est qu’il génère une pull request automatiquement, ce qui est cool. Ce qui l’est moins, c’est que 110 fichiers ont été générés pour 4 entités. 110 fichiers ! C’est pas un peu beaucoup ?

Si, mais il y a quand même un front-end, un back-end, et toute la connexion entre les deux. C’est malgré tout impressionnant.

Même si ça ne marche pas.

Méta-modèle

Julien rencontre à ce moment-là une difficulté qui l’oblige à tout régénérer …​. y compris le code Java. Pour ça, JHipster maintient un méta-modèle avec lequel il génère le code Java et le code Javascript.

Ca ne marche pas mieux après, mais c’est néanmoins impressionnant.

Surtout quand je me rends compte qu’en fait, JHipster est un outil de génération à base de modèle UML. Modèles qui sont bien cachés, c’est vrai, mais qui se révèlent bien pratiques.

Différence dev-prod

Pour aller plus loin, Julien nous montre que l’application, quand elle se lance en mode production, démarre plus lentement, parce que les comportements sont différents :

  • Le code Angular est minifié
  • Les stratégies de cache côté serveur sont plus aggressives
  • Les descripteurs Swagger peuvent (ou pas) être générés

Tests

Sur cette application, 160 tests sont générés pour le back et 152 pour le front. Et c’est là qu’on voit tout ce que cache ce générateur …​. Il y a 5 entités. Et ça mérite 300 tests ? J’imagine que oui, bien sûr.

Mise à jour

La ligne de commande contient une commande jhipster update qui permet de mettre à jour le projet par rapport à une version suivante, via un merge git. C’est conceptuellement vraiment, mais alors vraiment balaize. Et ça facilite évidement énormément les mises à jour de version.

Mise en prod

Pour finir, il existe des sous-générateurs permettant de déployer l’application dans les infrastructures de prod. Julien prend donc l’exemple de jhipster heroku …​ qui déploie chez heroku (dingue).

Et les différents cloudeurs ont produit des optimisations spécifiques. Par exemple, Google App Engine déploie le front-end sur son CDN, et les requêtes qui arrivent sur votre « serveur » sont celles qui concernent le back uniquement.

Conclusion

Julien vend particulièrement bien son outil. Et honnêtement, il a raison : JHipster est bien fichu, et fournit un certain nombre de services spectaculairement pratiques. L’un des plus importants, mais des moins visibles, est la mise en place d’une approche MDA pragmatique et efficace. En revanche, ayant utilisé pendant un certain temps Wisdom Framework, je trouve le choix de se baser sur Spring pour construire un générateur d’applications magnifié me paraît …​ discutable : je trouve la quantité d’éléments générés hallucinante, pour un résultat qui est raisonnablement joli, mais pas non plus fascinant (typiquement, les démos de Julien n’ont montré que Twitter Bootstrap (aucun des éléments visuels ne nécessitait Angular ou React). Malheureusement, je pense qu’il est de moins en moins pertinent de « gâcher » du CPU en fournissant un échafaudage de projet – aussi poussé soit-il. En effet, on voit maintenant émerger des approches – type « Function as a service » – qui interdisent totalement ce genre d’outillage.

Alors certes ça n’est pas la cible.

Mais quand même. Quelle application déployer avec JHipster ? Un outil « léger » non critique ? Quel genre d’outil peut encore avoir besoin de la « puissance » de la JVM, en étant toutefois assez simple pour être développable en PHP ?

Autrement dit, simplifier Spring, pour moi, est une « solution » qui ne me paraît pas, malgré tous les exemples de mise en oeuvre présentés – avec brio, je dois dire – par Julien, être applicable à un cas « utile ». Quelque part, c’est avant tout un outil de commodisation du développement, applicable dans les cas où le logiciel ne doit pas être un obstacle à une tâche, mais ne doit pas non plus être un facteur de succès.

Je change le NAS !

Comme trop souvent ces dernières années, mon vieux NAS a mangé un disque dur. C’est-à-dire qu’après un redémarrage, l’un des deux disques n’était plus reconnu.

Cette fois-ci, plutôt que de simplement racheter un disque SATA-3 chez ldlc, j’ai pris une décision coûteuse, mais rétrospectivement intéressante : j’ai acheté un nouveau NAS. En l’occurence un QNAP TS-231+. Sur le papier, c’est la même chose. Sauf que 9 ans, ça fait une sacrée différence en termes de processeur, d’interface, de fonctionnalités. Pour ne donner qu’un exemple, j’ai maintenant une belle interface web qui me permet d’installer un beau paquet d’applications, et en particulier Plex, qui me fournit un serveur UPnP vraiment très bien penssé et très riche en fonctionnalités. J’ai aussi un backup USB en one-button. J’ai encore d’autres fonctionnalités très chouettes que je verrai comment exploiter … plus tard.

Bon, au passage, j’ai aussi eu la acrte micro-SD de mon Raspberry qui a refusé de rebooter. Du coup, j’ai également mis à jour l’os du raspberry pour une version plus moderne de Raspbian. Et je suis en train de réfléchir (à moyen terme) à mettre en place une installation automatique via Ansible … A cause d’un collègue trop malin …

Bref, la panne a été réparée, j’ai appris des choses intéressantes, et mon informatique domestique fonctionne à nouveau correctement.