Yth a écrit 2680 commentaires

C'est vrai !

Bon, comme j'aime bien les trucs rigolos qui bougent, j'ai fait une animation en terminal.
On ajoute ça :

import os
import time
class display:
    def __init__(self):
        self.w, self.h = tuple(os.get_terminal_size())
        self.h -= 1
        self.delta = numpy.array((self.w//2, self.h//2))
        self.top = "*" * (self.w)
        self.line = "*" + " " * (self.w - 2) + "*"
        self.background = self.top + "".join(
            self.line for _ in range(self.h - 2)) + self.top

    def __call__(self, knots):
        x, y = self.delta + knots[0]
        if x <= 0:
            self.delta[0] += 1
        if x >= self.w-1:
            self.delta[0] -= 1
        if y <= 0:
            self.delta[1] += 1
        if y >= self.h-1:
            self.delta[1] -= 1
        txt = [c for c in self.background]
        for knot in knots:
            x, y = knot + self.delta
            txt[int(x + y * self.w)] = "#"
        print("".join(txt))
        time.sleep(.01)

d = display()

Et dans la boucle on ajoute à la fin : d(knots)
J'ai 11460 mouvements dans mon input, à cette vitesse - sleep(.01) - ça prends 2 minutes et quelques.

Ça commence centré sur le démarrage, et quand la tête déborde d'un côté, on translate tout pour garder dans le champs.

• Yth, du temps à perdre on dirait…

J'espère que dans vos solutions perso, vous aurez pensé à utiliser, en arrivant à la deuxième partie, à utiliser une seule corde pour simuler les deux…

Pas lors de la première résolution, mais après en nettoyant un peu le code oui… Comme d'hab, le problème arrivant en deux fois, on n'optimise pas dès le début pour la seconde partie :)

Voici mon code :

import numpy
input = [(r[0], int(r[2:])) for r in sys.stdin]

move = dict(
    U=(0, 1),
    D=(0, -1),
    L=(-1, 0),
    R=(1, 0),
)
def follow(head, tail):
    delta = head - tail
    if max(abs(delta)) <= 1:  # no move
        return
    if delta[0]:
        tail[0] += 1 if delta[0] > 0 else -1
    if delta[1]:
        tail[1] += 1 if delta[1] > 0 else -1


knots = [numpy.array((0, 0)) for _ in range(10)]
tail1_pos = {(0, 0), }
tail_pos = {(0, 0), }
for dir, nb in input:
    for _ in range(nb):
        knots[0] += move[dir]
        for n in range(1, 10):
            follow(knots[n-1], knots[n])
        tail1_pos.add(tuple(knots[1]))
        tail_pos.add(tuple(knots[-1]))
print(f"Tail positions visited : {len(tail1_pos)}")
print(f"LongTail positions visited : {len(tail_pos)}")

Pas trop modélisé, des vecteurs numpy juste pour avoir des simplifications comme l'addition, la soustraction ou la valeur absolue.
J'aime bien ton import_line qui fait un unique itérateur pour chaque mouvement unitaire, c'est propre !

Et donc :

def input():
    move = dict(
        U=(0, 1),
        D=(0, -1),
        L=(-1, 0),
        R=(1, 0),
    )
    for line in sys.stdin:
        direction = move[line[0]]
        for _ in range(int(line[2:])):
            yield direction

def follow(head, tail):
    delta = head - tail
    if max(abs(delta)) <= 1:  # no move
        return
    if delta[0]:
        tail[0] += 1 if delta[0] > 0 else -1
    if delta[1]:
        tail[1] += 1 if delta[1] > 0 else -1

knots = [numpy.array((0, 0)) for _ in range(10)]
tail1_pos = {(0, 0), }
tail_pos = {(0, 0), }
for direction in input():
    knots[0] += direction
    for n in range(1, 10):
        follow(knots[n-1], knots[n])
    tail1_pos.add(tuple(knots[1]))
    tail_pos.add(tuple(knots[-1]))
print(f"Tail positions visited : {len(tail1_pos)}")
print(f"LongTail positions visited : {len(tail_pos)}")

• Yth.

Ouais, c'est des glandus ces elfes, on dirait moi le lundi matin…

• Yth.

Mon premier parcours est moins bourrin, je ne cherche pas à savoir pour chaque arbre s'il est visible, mais bien à noter les arbres vus depuis chaque angle de vue, donc au lieu d'avoir size=width*height traitements, j'en ai 2*(width+height).

def check(rows, cols):
    h = -1
    for r in rows:
        for c in cols:
            if input[r][c] > h:
                visible[r * width + c] = True
                h = input[r][c]

visible = [False for _ in range(size)]
for r in range(height):
    check([r], range(width))
    check([r], range(width-1, -1, -1))
for c in range(width):
    check(range(height), [c])
    check(range(height-1, -1, -1), [c])
print(f"Visible Trees : {sum(visible)}")

Pour la seconde partie c'est algorithmiquement équivalent :

def look(h, rows, cols):
    n = 0
    for r in rows:
        for c in cols:
            n += 1
            if input[r][c] >= h:
                return n
    return n

scenic = [0 for _ in range(size)]
for r in range(1, height-1):
    for c in range(1, width-1):
        h = input[r][c]
        scenic[r * width + c] = (
            look(h, range(r-1, -1, -1), [c])  # top
            * look(h, range(r+1, height), [c])  # bottom
            * look(h, [r], range(c-1, -1, -1))  # left
            * look(h, [r], range(c+1, width))  # right
        )
print(f"Best scenic tree : {max(scenic)}")

• Yth.

Et un peu d'utilisation de fonction magiques chez moi ici :

class Directory:
    def __getitem__(self, name):
        return self.files[name]

Et là pour chopper le sous-répertoire "toto" de mon Directory(truc) je fais truc['toto'].
Je n'ai même pas pensé à inclure le '..' dans mes fichiers, j'ai un cas particulier si on fait cd .., c'était tellement évident de faire ça !

On pourrait accéder à truc/toto via truc.toto en implémentant __getattr__ comme j'ai fait le __getitem__, mais si "toto" est dans une variable il faut faire getattr(truc, variable_toto), ça ne simplifie pas la lecture, c'est plus simple d'utiliser truc[variable_toto].

Après on peut implémenter __truediv__ et faire que truc/"toto" retourne Directory(truc/toto).
Là on a root/"a"/"b"/".."/"c"/".."/".."/"e"/"f" = Directory("/e/f") :)
Mais les guillemets partout alourdissent la lecture et l'écriture…

Sinon, côté algo, et même implémentation, c'est pareil rien à signaler, pas de subtilité, j'ai juste utilisé du if line.startswith("$ cd"): cwd = cwd[line[5:]] plutôt qu'une regexp.

• Yth.

J'ai fait du Caml, j'ai joué un peu avec OCaml, et même un poil de Lisp Jadis, mais je ne code pas régulièrement dans ces langages là.

Réutiliser les opérateurs, c'est bien pour jouer, mais ça peut péter complètement la lisibilité, donc il faut faire très très attention quand on veut partager le code…

Bien fait c'est génial par contre.

• Yth.

J'aime bien réutiliser les opérateurs, mais j'ai fait ça assez rapidement, donc la pertinence est celle d'un truc pondu en vingt minutes.
Le ~chifumi est pratique et plutôt lisible, comme ça on normalise tout le temps.

Par contre réutiliser la classe chifumi pour qu'elle représente une choix ou un résultat d'affrontement, c'est plutôt moche, ça rendrait illisible un code plus gros, et c'est totalement lié à la présentation de la seconde partie du problème après la résolution de la première : comment bricoler vite fait du code qui répond à la question. C'était plus simple de rajouter un opérateur à une classe existante que de gérer une nouvelle classe.

Mais en plus propre on pourrait avoir une classe resultat d'affrontement, qui sait se multiplier (par exemple) avec une classe chifumi, avec __mul__ et __rmul__, pour pouvoir faire chifumi * resultat = resultat * chifumi = "mais qu'a donc joué mon adversaire ?"
On apprends à resultat à se multiplier dans les deux sens avec chifumi sans que celle-ci sache comment se multiplier avec resultat.

On pourrait garder le même opérateur partout, et faire du __mod__ et __rmod__ sur resultat. Sachant que dans tous les cas on retourne un score qui est un entier et n'a rien à voir avec aucune des deux classes.

Pour le total_ordering, c'est vrai, mais en pratique j'ai implémenté __lt__ qui n'est jamais utilisé. J'aurais pu nettoyer ça du code avant de le poster.

• Yth.

Je viens de voir le message, j'ai rejoins alors :)
Bon, par contre le leaderboard a la valeur qu'on lui donne : hors de question de me lever à 6h du matin pour faire ça parmi les premiers…

• Yth.

Ma solution vite faite.

import sys
input = sys.stdin.read().split("\n")
s = [0]
for i in input:
    if i == "":
        s.append(0)
    else:
        s[-1] += int(i)

print(f"Maximum = {max(s)}")
print(f"3 Best : {sum(sorted(s)[-3:])}")

time python3 01.py < 01.in
Maximum = 71506
3 Best : 209603

real    0m0,041s
user    0m0,034s
sys 0m0,007s

• Yth.

Sur celui-là, j'ai vachement modélisé au contraire :

class chifumi(int):
    lose = 1
    draw = 2
    win = 3

    def __init__(self, chifumi):
        self.chifumi = chifumi
        self.chifumi = ~self

    def __invert__(self):
        """~chifumi returns value in [1, 2, 3]"""
        return (self.chifumi % 3) or 3

    def __eq__(self, other):
        return ~self == ~other

    def __lt__(self, other):
        return +self == ~other

    def __gt__(self, other):
        return -self == ~other

    def __neg__(self):
        return ((self.chifumi - 1) % 3) or 3

    def __pos__(self):
        return ((self.chifumi + 1) % 3) or 3

    def __mod__(self, other):
        """score of self against other"""
        if self == other:
            return ~self+3
        if self > other:
            return ~self+6
        return ~self

    def __matmul__(self, other):
        """score when result is self, against other"""
        if ~self == self.win:
            return +other+6
        if ~self == self.lose:
            return -other
        return ~other+3

Et la résolution est triviale derrière :

import sys
input = [l.split(" ") for l in sys.stdin.read().strip().split("\n")]
values = dict(
    A=chifumi(1),
    B=chifumi(2),
    C=chifumi(3),
    X=chifumi(1),
    Y=chifumi(2),
    Z=chifumi(3),
)

score1 = sum(values[me] % values[you] for you, me in input)
score2 = sum(values[me] @ values[you] for you, me in input)

print(f"Strategy 1 = {score1}")
print(f"Strategy 2 = {score2}")

• Yth.

Franchement, je ne fais pas mieux.
Toute optimisation semble compliquer terriblement le code.
Et vu la taille des données…

C'est quoi la citation à propos des optimisations trop tôt dans le code ? :)

• Yth.

L'idée c'est que le « cloud » en lui-même a des serveurs, mais ton appli dessus n'en a pas, il est exécuté magiquement par de la puissance de calcul brute sortie du ciel, et le stockage est global sans espace dédié.

Donc de ton point de vue c'est sans serveur, que de la magie, tu alloues de la puissance d'un côté, du stockage de l'autre, et bingo.

Bien sûr derrière c'est très terre à terre avec des fermes de centaines de milliers de serveurs…

Mais le sens est là.

• Yth.

Mais il faut des montagnes pour ça.

La plus grosse batterie de France peut délivrer une puissance de 1,8Gw (deux réacteurs nucléaires) pendant 48h, sous 2 minutes.
Elle sert en recharge avec les surplus de production, et en décharge face aux pics de production.

C'est une conduite forcée de 7m de diamètre sur plus de 1000m de dénivelé, 12 turbines hydrauliques, dont 8 réversibles, pour repomper l'eau du bas vers le haut, donc deux lacs de retenue, et deux écosystèmes totalement transformés.
Quantité de CO2 assez négligeable (plein de béton, des dizaines milliers de tonnes d'acier, un paquet d'ordinateurs) par rapport à la puissance. A priori pas de pollution à l'utilisation. Pas d'usure outre-mesure, au delà de l'entretient d'un gros ouvrage de type barrage hydraulique. Il tourne depuis 35 ans, et n'a pas a priori de limite d'usure, donc tout ces matériaux c'est un investissement unique.

Il s'agit de Grand-Maison, en Isère.
Le vidage/pompage fait perdre ~20% d'énergie, donc quand on produit 1GWh, il faut 1,2GWh pour recharger la batterie, c'est moins efficace que des batteries au lithium (apparemment proches des 100%), mais bien plus durable et moins polluant.

Mais faut des montagnes, la Belgique en est relativement dépourvue : elle culmine à 694m d'altitude…

Il y a 6 batteries de ce type en France pour une puissance totale de 5GW (mais je n'ai pas l'énergie totale stockable en GWh).
La plus ancienne datant de 1934, est démantelée en 2014, elle a essuyé les plâtres des défauts d'ingénierie, mais 80 ans c'est pas mal déjà pour un truc qui a explosé à la première mise en service.
Heureusement on fait mieux aujourd'hui…
Il n'est pas spécialement évident de pouvoir accroître cette capacité (il faut des lieux, et il faut casser des écosystème, inonder des lacs de retenue, etc), mais la France n'a peut-être pas besoin de plus que ça ?

Évidemment ça sert en complément d'une énergie produite « à perte », ça peut être utile avec un parc éolien/solaire dont la production dépend assez peu de la consommation recherchée, mais c'est surtout utile avec des centrales nucléaires qui ont une production constante, ça permet de lisser.
Ça sert aussi à kickstarter des centrales nucléaires, qui ont besoin d'un paquet de jus pour démarrer.

Et tout ça c'est la raison pour laquelle il ne faut pas découpler l'hydraulique du nucléaire en France.

Bref, je suis pas hyper convaincu pour le stockage au lithium, mais si on n'a pas de montagnes pour faire des piles hydrauliques, c'est peut-être la seule solution envisageable.
Ça me paraît être une aberration écologique cependant…
Le recul qu'on a sur l'usure des batteries au lithium des téléphones portables est assez déprimant, c'est un gâchis délirant de métaux rares et polluants !

On ferait (l'Europe, la Belgique) probablement mieux de faire de la recherche sur des batteries biologiques.

• Yth.

De plus, et c’est l’argument principal de l’article, absolument aucune compatibilité descendante n’a été prévue. On est en plein dans l’obsolescence programmée.

En fait, il y a exactement la même compatibilité descendante qu'entre la 4G et la 3G, ou la 2G.
C'est à dire que les réseaux fonctionnent en parallèle et qu'il y a des passerelles pour que ta connexion passant d'un coup de Edge à 5G, tu ne sois pas déco/reco, tu gardes ta conversation téléphonique fluide, etc.

• Yth.

Mais Twitter ET Mastodon sont client-serveur, ça n'a aucun rapport avec la centralisation, la décentralisation ou la fédération.

Le web est fédéré : tous les serveurs parlent le même langage (HTTP(S), aux variantes près), tous les clients parlent le même langage, on peut accéder à n'importe quel serveur avec n'importe quel client, et n'importe quel site web peut faire un lien vers n'importe quel autre (techniquement, juridiquement ou commercialement, c'est une autre question).

Après, à la différence de trucs comme Mastodon ou XMPP, ou le mail, tu ne passes pas par un serveur pour aller vers un autre (même si c'est possible, avec des proxy), donc c'est peut-être plus décentralisé que fédéré, il n'y a vraiment pas de lien entre les serveurs, à part les liens URL entre les pages webs.

Cela dit, la question est plus sur décentralisé/centralisé.
La fédération c'est une façon de décentraliser, c'est tout.

• Yth.

Mais est-ce positif de changer d'état d'esprit comme ça?

Est-ce négatif ?
J'ai un avis terriblement neutre sur la question…

et leur interdire en pratique d'évoluer, de naviguer entre plusieurs communautés.

Je te trouves de mauvaise foi là, c'est plus facile d'aller voir ailleurs, et différent, et d'en revenir ou pas, avec un Mastodon fédéré qu'avec ton compte Twitter unique noyé dans le magma global de l'Algorithme qui choisit ce qui t'intéresse en fonction de ce qui a pu t'intéresser par le passé !

Je trouve que les enfermements de Twitter, Facebook etc, sont bien pires que les communautés Mastodon dont l'auteur parle.
D'un côté c'est affiché et rien ne t'empêche d'avoir autant de communautés que tu veux.
De l'autre c'est insidieux et ça t'attaque doucement les biais cervicaux.

OK. Donc le moins cher de loin est Twitter, et ça ramènera les gens sur Twitter.

C'est possible. Plutôt qu'ils ne vont pas partir.
L'effet de Silo en fait : les gens qui ont des millions de followers aspirent à une audience globale, ils prennent internet pour le café du commerce avec 8 milliards de péquins. Ils sont terriblement minoritaires sur notre planète, et la plupart des gens n'aspirent pas à avoir des millions de followers.
Faut les comprendre ces élites du Twitter : il s'agit de leur gagne pain, pas envie de le perdre !

les débats, tout est sur Twitter, c'est voulu il faut croire.

Ah bon, ya des débats sur Twitter ?
Je suis néophyte en la matière, je croyais benoîtement que c'était juste un coin où chacun raconte que la pomme qu'il a mangé était une banane orange, et que le chien du voisin.
Un peu comme Facebook en gros.

• Yth.

Je trouve qu'il arrive à expliquer que l'état d'esprit à avoir c'est que si tu as une méga-communauté, ne va pas pourrir le serveur d'un autre, ouvre le tiens, et utilise-le pour ta propre communauté, et gère les problèmes en rapport avec ta communauté.

Tu seras toujours fédéré, les gens d'autres instances pourront participer à ta communauté, mais le gros du trafic sera interne et n'ira pas pourrir l'instance bénévole d'à côté.

J'en conclus que ça n'est pas un clone de twitter, mais que ça pourrait rendre le même service en changeant d'état d'esprit, un peu moins client, un peu plus acteur. Un peu moins à chercher à hacker l'Algorithme.

Et si t'as 20 millions de followers, a priori, t'as l'argent pour payer ta petite cousine nerd pour l'admin de ton serveur, ou un autre professionnel, ou les gens en charge de l'instance que tu veux charger, et qui ont le droit de refuser.

• Yth.

Oui, j'ai un peu fait exprès d'en rajouter pour chopper le prochain fd dans l'ordre des nombres, plutôt que la sortie de sort qui convient à comm et qui va te donner les fds suivants : 10, 100, 101 … 109, 11, 110, 111, …, 199, 20, 200, etc.

Voire, sachant que seq et ls te les mettent déjà dans l'ordre numérique, on peut virer tous les sort, mais comm se plaint que les sources ne sont pas ordonnées, il faut donc mettre un --nocheck-order à comm.
On aurait le même résultat avec significativement moins de processus, mais en étant moins à l'abri d'un comportement non standard. Avec les sort on est algorithmiquement sûr de notre résultat (enfin, sauf grosse bourde de ma part ^ ^ ).

À noter que le fd n°3 n'est jamais retourné : il est squatté par la ligne qui récupère le premier fd disponible, et rendu à la fin, donc on passe toujours au 4. Je ne suis pas très sûr de quelle étape génère ce fd n°3.

En tout cas ça fait des bashismes bien moches, miam :)

• Yth.

PS : comm c'est vraiment pratique, Jadis j'avais fait des coding game, en bash, et ça m'arrivait souvent d'avoir des perfs équivalentes que ce que d'autres faisaient avec des vrais langages et des algos chiadés, grâce à ce genre d'outils.

Le web est totalement décentralisé, n'importe qui peut héberger un site web comme il le souhaite, et n'importe qui d'autre peut y accéder (hors grande muraille de Xine ou trucs du genre).

Le mail aussi, c'est décentralisé - même si relativement pourri ces dernières années par des silos, ça n'a rien de définitif ou irréversible, les silos périront avant le mail - et ça fonctionne depuis longtemps.

Le P2P ça fonctionne très bien et c'est décentralisé aussi.
Ya qu'à voir l'inepte inefficacité de feu Hadopi pour s'en rendre compte (Ahem…).

XMPP est aussi un exemple de décentralisation qui fonctionne, s'il y a bien une question que je ne me suis jamais posé avec Jabber c'est bien de savoir si j'allais pouvoir ou non communiquer avec un autre utilisateur en fonction de son serveur hôte !
Et ça « scale » sans soucis. Au contraire même, ça va mieux tourner avec une nuée d'instances de tailles relativement modestes.

Le problème de Mastodon, si j'ai bien compris, c'est qu'on veut agréger une sorte de mur à-la-facebook avec un algorithme, qui va chercher des infos sur pleins d'instances différentes, pour nous regrouper tout ça.
Et donc oui, ça fait exponentiellement des requêtes de partout.
Parce que ça semble partir d'un concept centralisé (avoir un flux général de tout ce qui nous intéresse partout) pour le décentraliser (y accéder depuis ma petite instance dans mon coin).
Ça ressemble en effet à du defective by design.

À l'évidence, la centralisation apporte des avantages.
Par exemple, si tu utilises le même serveur mail que moi, les emails ne transitent pas entre des serveurs, et la vie privée de nos communication est nettement moins visible de l'extérieur : tout est chiffré avec les versions chiffrées des protocoles IMAP et SMTP depuis nos clients mails, pas de Man-in-the-middle !
Dans le cas de Twitter, mais aussi Facebook, l'Algorithme permet de piocher dans l'ensemble des flux pour te proposer des sujets, et c'est - on s'en rends apparemment compte avec surprise aujourd'hui - difficile à décentraliser cette fonctionnalité.
La centralisation offre aussi la possibilité d'agréger des masses de données personnelles que jamais un outil décentralisé ne pourra permettre d'accumuler, c'est la sève qui nourrit Google, point de salut pour leur business sans centralisation maximale.

Bah peut-être qu'il faut repenser cette portion de la décentralisation, mais si c'est une fonctionnalité centrale de Twitter, alors Mastodon ne sera jamais une alternative viable, sur le même modèle.

Cependant je peine à voir en quoi ça remet en question le principe même de décentralisation…

• Yth.

1 - l'exemple donné me fait un retour en « Error 400 (Bad Request)!!1 » sur google.com (copié-collé exact de l'exemple).
Et un « Bad Request. Your browser sent a request that this server could not understand. » sur mon apache local.
Donc ça marche plus mal que ça apparemment… :)

2 - les file descriptors, tu les choisis dynamiquement hein !

Ensuite, il faut choisir soi-même un numéro de descripteur de fichier, bon courage pour éviter les conflits.

url="www.google.com"
fd=$(comm -13 <(ls /proc/$$/fd | sort) <(seq 255 | sort) | sort -g | head -1)
eval 'exec '${fd}'<>/dev/tcp/'${url}'/80; echo -e "GET / HTTP/1.1\r\nhost: http://'${url}'\r\nConnection: close\r\n\r\n" >&'${fd}'; cat <&'${fd}

Bon, ça les rends pas par contre hein les file descriptors :

ls /proc/$$/fd -l | cut -d\  -f10-

0 -> /dev/pts/21
1 -> /dev/pts/21
2 -> /dev/pts/21
255 -> /dev/pts/21
4 -> socket:[1870185]
5 -> socket:[1870235]
6 -> socket:[1867560]
7 -> socket:[1871095]
8 -> socket:[1864698]
9 -> socket:[1869500]

• Yth, en bash on peut toujours faire plus GRUIIIIICK !!!!

PS: On avait déjà le serveur web en bash https://github.com/avleen/bashttpd avec un obscur fork capable de gérer les requêtes POST d'un webhook gitlab ici https://gitlab.com/Arn0/bashttpd2
Maintenant on a le brouteur bash ..?

smplayer c'est vraiment au top !
Par contre, en tant qu'utilisateur de mplayer en backend qui n'a jamais trop cherché, sur le mode « ça marche, c'est cool », je ne connais pas les différences avec mpv, tu saurais si ça change grand chose entre les deux ?

• Yth.

D'expérience, un GPS capricieux, ça peut juste être un GPS de merde, et passer sur Android/Google n'y changera rien…

Là j'ai un casque bluetooth qui reboote mon téléphone de temps en temps à la connexion, sympa.
Mais d'une façon ou d'une autre ça vient du casque, puisque les précédents ne faisaient pas ça.

Doit y avoir un virus dans le câble ! (…)

• Yth.

Et d'un témoignage disant que sans microG plus rien ne fonctionne.
Je peux témoigner de mon côté, que c'est très largement - et fort heureusement - faux…

• Yth.

Tellement qu'après avoir visité cette page, j'ai lu le lien suivant, celui sur futura-science en premier commentaire :
https://linuxfr.org/users/pamputt/liens/if-you-die-in-the-game-you-die-in-real-life
Et presque tout y était : les demandes de newsletter, le bandeau à cookies, la vidéo qui reste scotchée à l'écran quand tu scrolles, les pubs qui restent un peu partout même après passage de ublock (j'imagine pas sans).

On se croirait revenu vers l'an 2000 quand les gens encaissaient les plantages et autres vérolages de leur windows parce que « c'est comme ça, pas le choix ! »

Combien de site je quitte directement quand je vois qu'ils sont de cet acabit…

C'est moche !

• Yth.

10 - Keep development, staging and production as similar as possible

Bah oui, on veut éviter le "ça marche sur ma machine pourtant". Si le développeur est capable de tester en condition de production, c'est pas mal de bug trouvés à la source.

Bah là je suis moyen d'accord…
Alors staging et production identiques, c'est une évidence, mais les environnements de dev peuvent être bordéliques.
Justement pour avoir du « ça marche chez moi mais pas en staging », comprendre pourquoi, et savoir dans quelles conditions réelles ton bouzin peut ou pas fonctionner.

Si par exemple t'as un truc en Python et qu'un des dev a une pile pas très à jour avec encore un python 3.6 antédiluvien, le jour où ça explose chez lui, tu peux dire « minimum requis = python 3.7 ».
Sinon, bah tu sais pas, et en général, quand on est sérieux, on préfère savoir.

Ça fonctionne dans l'autre sens aussi, un DEV qui fait du PHP 8.1 au lieu du 7.4 de la prod, et qui a un comportement bizarre, va pouvoir préparer la migration future vers PHP 8 en pré-corrigeant des soucis, ou peut-être simplement prévenir que tel truc va péter le jour où on voudra migrer en PHP 8.

Il y a moyen de voir apparaître des bugs masqués par telle version d'une dépendance mais pas telle autre, etc.

Bref, des environnements de dev hétéroclite, ce n'est pas obligatoirement un mal.

Par contre, ya pas photo, ça n'a aucun sens d'avoir une pré-prod qui ne soit pas autant que possible un clone de la prod.

• Yth.