Logo journal du hacker middle
  1. 1

    Ils permettent de redonner une activité cardiaque au cœur d’une personne.

    Erreur, un défibrillateur permet de redémarrer en cœur en fibrillation, et non un cœur inactif.

    Bonne idée, sans se faire d’illusion : dans la panique, va-t-on penser à dégainer Osmand ? ;-)

    1. 2

      Pas forcément mais on peut imaginer qu’un dev créer une application “spéciale défibrillateur” en se basant sur les données OSM. Ou bien des cartes présentes dans l’espace public mettant une ptite icône de l’emplacement des défibrillateurs si l’info est bien présente en base.

    1. 3

      Le disclamer a la fin tue tout l’article et d’ailleurs, j’allais en parler : docker <> serveur linux

      Pourquoi ne pas proposer un Vagrant / VirtualBox ?

      1. 3

        À mi-chemin, je trouve que LXC peut aider. J’ai eut une très bonne expérience de conteneur LXC créés très rapidement grâce à btrfs dans un ramdisk : moins de 7s pour cloner, démarrer et éteindre un conteneur. Avec LXC, on a un système complet : réseau, systemd, SSH, etc. La limite est essentiellement sur le système de fichier et le kernel partagé avec l’hôte.

        1. 2

          Et pour ce genre d’utilisation, avec LXC ou systemd-nspawn (que je préfère, je le trouve bien plus simple à mettre en place), il y a la notion de conteneurs éphémères :)

      1. 2

        :fr: “As-tu l’esprit DevOps” aurait fait plus intriguant qu’un franglais fleurant le langage marketing. Rien n’a changé depuis https://www.youtube.com/watch?v=WIxS9-xhGfM

        1. 1

          Oui, je me suis fait la même réflexion. “esprit” ou “état d’esprit” auraient été des mots tout aussi appropriés et tout aussi modernes. =)

        1. 2

          Très orienté Mac & proprio, mais intéressant.

          1. 1

            On dirait que c’est traduit par un robot :/

            1. 1

              Sécuriser c’est craindre ^^

              1. 1

                L’article sur l’histoire du dév JS de 2014 est vraiment excellennt : https://www.mathieurobin.com/2014/09/il-est-temps-davoir-deja-quitte-jquery/

                1. 2

                  Autre blague que j’ai dans Python : from __future__ import braces

                  1. 1

                    C’est encore utilisé Saltstack ? Que de mauvais souvenirs …

                    1. 1

                      Je connais au moins une personne qui l’utilise encore… C’est vrai que le monde informatique semble tourner autour d’Ansible maintenant

                    1. 1

                      C’est tellement simple ^^

                      1. 2

                        Le lien semble cassé.

                        1. 1

                          Tout à fait d’accord avec cet article bien illustré.

                          À noter que la nature des va nécessairement influencer la structure des tests. Un projet Ansible aura peu de tests unitaires ! Je pense à kolla-ansible par exemple.

                          1. 1

                            À mon avis, le fond de la question est “La liberté de qui faut-il privilégier ?” Les licences permissives privilégient le développeur tandis que les licences copylefts privilégient l’utilisateur. L’air du temps est de coopérer sur les briques et de livrer une app propriétaire / SaaS pour son modèle économique.

                            1. 2

                              Je trouve un peu dommage de mettre en avant le cache autant. Je pense que le premier chargement doit lui aussi être rapide. Il compte beaucoup dans l'expérience.

                              1. 3

                                Pleins de bonnes choses.

                                Je pense qu'il faut concevoir les applications web en mode téléphone avec la 2G. Les navigateurs permettent maintenant de simuler cette contrainte. La fibre fait oublier l'inconfort d'un site lourd, pour la moitié des cas d'utilisations.

                                Une fois qu'on subit la contrainte, on peut attaquer radicalement le gâchi pour rester utilisable.

                                1. 1

                                  Arf, Cascador m'a doublé de 8 minutes :D. J'aurai bien ajouté le marqueur dev.

                                  1. 2

                                    Ton souhait est exaucé ;)

                                    Tcho !

                                  1. 1

                                    L'allusion à un ordre des développeurs est intéressant. Comment cela se concrétiserai ? Un syndicat ? Une profession réglementée ? Quels seraient les moyens d'actions ? Je ne vois rien de réaliste.

                                    1. 1

                                      Avec CoreOS, je ne me pose plus la question ^^

                                      1. 2

                                        Beuark. Pierre a-t-il déjà administré un ElasticSearch en prod pour utiliser ce gros bouzin pour faire un OU binaire ? DynamoDB ne sait pas faire d'Index pour avoir besoin d'ES ?

                                        Exemple parfait d'archi qui, sous couvert de consommation à la demande, consomme énormément d'énergie pour le résultat obtenu.

                                        1. 2

                                          Mettez #!/bin/bash -eu et sauvez un chaton d'une mort effroyable !

                                          1. 1

                                            Une petite explication du pourquoi ?

                                            1. 1

                                              -e délenche l'arrêt du script en cas d'erreur non gérée. Cela évite l'effet boule de neige où une erreur d'un script déclenche une avalanche d'erreur dans les commandes suivantes du script. Avec -e, bash s'arrête et affiche l'erreur à l'origine de toute la catastrophe qui aurait put se passer ensuite.

                                              -u change le comportement de bash en regard des variables indéfinie. Par défaut, une variable indéfinie est substituée par la chaîne vide. Avec -u, bash lève une erreur et arrête le script. Cela évite notamment les erreurs avec le typo dans un nom de variable.

                                              -eu est en quelque sorte le mode strict de bash, pour reprendre une terminologie de PHP. Autant, en interactif, -eu sont inutilisables, autant dans un scripts ils me semblent indispensables.

                                              1. 1

                                                Merci pour l'explication complète :)

                                                1. 1

                                                  Notons cependant qu'ils peuvent être inutilisables en script. Dès qu'on commence à faire des trucs un peu complexes, ça peut vite péter. J'ai quelques scripts qui supportent pas -e (ça pète pour rien).

                                                  Pour une suite de commandes à la makefile, ça se tiens, mais sinon c'pas toujours possible. Activer/désactiver les options au besoin à coup de set est intéressant et éviter de couper l'exécution durant un traitement correct.

                                                  1. 1

                                                    Mieux vaut ignorer explicitement les erreurs. ! joue ce rôle.

                                                    #!/bin/bash -eux
                                                    ! false
                                                    ! true
                                                    echo "on continue"
                                                    
                                                    1. 1

                                                      Heu… non, certainement pas. Ça sert à « inverser » le code de retour, l'effet d'ignorer les erreurs qui suivent n'est qu'un effet de bord. Et ça rends inexploitable le code de retour de la commande (sauf à vouloir explicitement inverser le résultat).

                                                      Autant adapter ses scripts à son usage, je veux bien, autant utiliser des bricolages du langage, bof. Sans parler de la lisibilité qui en prends un coup…

                                                      Personnellement, je préfère traiter les erreurs (pré-vérifications, récupérations des codes d'erreurs et/ou de la sortie pour déterminer les actions à faire, etc) plutôt que d'activer un réglage Bash qui pourrait me mettre des bâtons dans les roues (en ne catchant pas certains cas que je considère comme erreur malgré le code 0, ou en catchant des cas que je ne trouve pas anormaux malgré le code de retour > 0).

                                                      Il m'arrive d'utiliser -e, mais généralement je l'active que quand j'ai tout un bloc de commandes lancées sans conditions à la suite et qui ne sont pas censées foirer. Du coup si ça plante à cet endroit, c'est qu'il y a un cas totalement imprévu.

                                                      Au final, ça dépends de la situation, des préférences et habitudes, etc.

                                                      1. 1

                                                        Ça sert à « inverser » le code de retour

                                                        As-tu essayé le bout de script que j'ai partagé ? ! true n'arrête pas le script. C'est à dire que -e ignore le retour de !, quelque soit le résultat de la commande. En début de commande, ! est en bash comme le - de GNU Make. C'est un autre usage de !.

                                                        Toute erreur non gérée doit être une rédhibitoire.

                                                        1. 2

                                                          Ah mais j'ai pas dis le contraire. Je dis juste que ! true retourne 1. Même s'il arrête pas le script, ça fausse le code de sortie. ! sert avant tout à inverser le code de retour, pas à l'ignorer. Ça c'est qu'un effet de bord.

                                                          Quant à -u, ça permet d'éviter pas mal d'arrachages de cheveux. Perso je teste systématiquement à coup de test -z ou test -n les variables qui doivent absolument ne pas être vides (et j'ai aussi des cas de variables légitimement vides).

                                                          Après, mettre -eu par défaut et ne le virer que quand on a besoin (avec set par exemple), c'est plutôt une bonne idée, surtout si on a pas l'habitude de certains comportements de Bash (qui varient de ce qu'on trouve ailleurs).

                                                          Bref, question d'habitude, chacun fait ce qu'il veut, tant que c'est en connaissance de cause.

                                                          1. 1

                                                            Exactement, il m'arrive d'encadrer du code pas fiable avec set +eu; ...; set -eu dans le pire des cas. C'est très rare dans mon expérience.

                                                            Je trouve que les if $? ... sont très verbeux. Pire, j'ai vu un collègue écrire des script avec && à la fin de chaque ligne. -e rends les scripts plus lisible à mon goût.