wilk a écrit 1103 commentaires

Froides froides, glacées si possible !
Du coup ça entraîne une autre réaction que juste une sensation de température et c'est ce que j'aime bien. Une réaction genre éclat de rire et en hiver ça se transforme même rapidement en sensation de chaud…
Mais si je ne suis pas en forme je ne me force pas et dans ce cas je la prend chaude normale, je n'aime pas trop l'entre deux. En été c'est un problème du coup parfois je laisse un peu couler l'eau pour qu'elle se refroidisse !

Le plus efficace c'est de militer sur les bienfaits des douches froides (santé, prospérité, retour de l'être aimé etc.). J'ai réussi à convaincre une des 3 chevelues aussi grace au côté « t'es cap ? ».
Une fois la santé, la prospérité et l'être aimé revenu on peut actionner le côté éco-geste.

Bienvenu dans ce cas. Si tu connais le sujet autant rédiger une dépêche ou un journal ce sera plus instructif.

• le développement => 8.3 + 12.6 = 21 millions, ça ne me paraît pas hallucinant.

On parle de vente de billet de train, un formulaire principal, arrivée-départ (oui dans cet ordre !), une date.

A l'époque de captaintrain j'ai bossé pour un concurrent, on était 3 dev + 1 ops, l'algo de recherche d'itinéraires (jusqu'à 6 correspondances !), 1500 lignes de code. Chez Captaintrain ils n'étaient pas beaucoup plus nombreux.
Chez oui.sncf ils étaient 10 devs l'année dernière.

Là ils sont 200 devs pour une appli mal foutue et qui ne marche pas. Je trouve donc ça bel et bien hallucinant.

Y a un devoxx :
https://www.youtube.com/watch?v=dPfREPMacYc

comme si on allait toujours trouver des gens avec des compétences spécifiques d'un domaine hors du domaine.

Tu as raison, il est effectivement curieux que Mozilla ne recherche pas quelqu'un de compétent et d'expérience dans le domaine qui est le sien.

https://www.mozilla.org/fr/about/manifesto/

C'est déjà le cas, les langages polluants sont eux même des programmes écrits en C.

Des équipes qui se parlent ? Et pourquoi pas un décideur qui les écoute pendant qu'on y est ?
Hahaha, oui, évidement tu as tout à fait raison, d'où l'intérêt du chat de Scalingo… Je continue ma progression…

Merci, ça me rassure, vu la rapidité de réponse du support je me demandais si je n'étais pas tout seul sur le bateau ;-)
Pour les logs ça me va très bien de les télécharger avec l'api bien que j'ai trouvé surprenant que les logs routeur soit irrécupérables si on les désactive visuellement…

Je suis ma propre équipe d'admin sys (j'ai des besoins très modestes mais des besoins quand même), du coup ça n'est pas une question de budget mais de temps et surtout de motivation !

Au niveau deux métiers par contre je trouve que le fait de gérer les deux oblige à se poser des questions qui oriente l'un et l'autre et ça peut être très bénéfique. Par exemple j'ai choisi Go en grande partie pour faciliter le déploiement et économiser sur les ressources. Inversement j'imagine très bien des situations ou un choix de dev a des conséquences désastreuses sur l'infra, dépendre d'un fournisseur par ex.

Mais après oui, une fois sur le terrain c'est sur qu'il vaut mieux que chacun soit à sa place.

J'avoue qu'au niveau techno chez Scalingo ils parlent la même langue que moi, Go, ce qui m'arrange plutôt, d'autant plus qu'une partie de leurs outils sont sur github. Ca m'a permis de tester très rapidement leur api.
Chez Clever Cloud j'ai vu que c'était du Rust, y compris sur des traceback du CLI… J'ai eu pas mal de difficultés à faire des essais, utiliser des modules privés en Go, utiliser l'API etc… J'ai pas trop insisté vu que l'idée était justement de ne pas avoir à me prendre la tête.
Si j'ai bien compris Scalingo s'appui d'avantage sur des technos classiques existantes et un fournisseur, sans chercher à étendre trop les fonctionnalités, tandis que Clever Cloud essaye de faire beaucoup plus de choses eux même y compris au sein du kernel (vu sur des confs de Quentin Adam), y compris avec OVH (plus trop confiance…). Plus ambitieux mais ça me semble aussi plus risqué.
Dans un premier temps ce que je vais essayer de faire c'est de rendre mes applis les plus facilement portables de l'un à l'autre (conf en env, stateless etc). Le double effet c'est que si je dois revenir sur mes serveurs je conserverai le principe.

De mon côté j'ai une cartouche en fin de garantie (2020) qui est refusée sur une HP6970, si quelqu'un veut essayer ?
J'ai eu beau expliquer à la fille du support que j'acceptais de prendre le risque de perdre la garantie, rien à faire, elle m'a suggéré l'abonnement instant Ink. Je lui ai parlé des dégâts écologiques de jeter une cartouche pleine, elle m'a proposé de m'envoyer une enveloppe de recyclage. Je lui ai demandé si elle me l'amènerait à vélo…
Le comble c'est que j'ai réussi à lui faire dire que c'était de l'obsolescence programmée !
La cartouche est programmée m'a t'elle dit. Programmée pour ne plus fonctionner après une certaine date ? Oui monsieur, la date indiquée au dos.
J'ai oublié de lui demander si mon imprimante s'arrêtera également à la fin de sa garantie, comme l'a fait la précédente…

Bon, du coup faut prendre quelle marque la prochaine fois ?

Oui mais ce n'est pas tellement le sujet.
Je passe la main à quelqu'un qui l'explique sûrement mieux que moi :
https://medium.com/capital-one-tech/closures-are-the-generics-for-go-cb32021fb5b5

Mais la question qui restera maintenant qu'on a du générique en Go c'est à quel moment préférer des fermetures ou du générique.

Dans ton exemple f et v ne sont pas capturés puisqu'ils sont passés en paramètres.
Les méthodes c'est exactement comme si on écrivait Abs(f MyFloat)

// une interface 
type Rendu interface {
    Rendu(i, j int) string
}

Oui, c'est exactement ce que je décrit, une interface qui utilise une fonction de fermeture. Ce qui est capturé c'est le tableau.
L'algo n'a pas à traiter le tableau, il va juste appeler les cellules par leur index.

Ceci à la place d'une interface, beaucoup plus classique qui serait :

type Rendu interface {
    Rendu() string
}
// mon algo
for c in range cellules {
    c.Rendu()
}

En Python je redéfinissais la méthode Rendu de ma cellule et cette méthode accédait aux cellules voisines par quelque chose comme self.parent.cellules[i-1]...

En Go je pourrai avoir une interface pour récupérer les cellules voisines

type Rendu interface {
  Rendu() string
  Voisines() []Rendu
}

Mais du coup je perdrais mon type de cellule… C'est là qu'avec des casts ou du generique ce serait faisable mais au final beaucoup plus compliqué.

Je comprend bien ce que sont les interfaces et les types génériques.
Mais le problème n'est pas tant que le code soit plus ou moins compliqué, ça dépend vraiment des cas, mais le fait qu'il crée une dépendance.
Si c'est un tri par exemple c'est bénéfique car une fois bien codé on n'y touchera plus, et surtout on n'ajoutera jamais de fonctionnalité.
En revanche si on passe à un niveau plus élevé, comme dans mon cas d'une lib qui génère un pdf, c'est bien plus délicat car il y a potentiellement des fonctionnalités qui vont s'ajouter et impacter tout le monde (problème classique des dépendances et de l'héritage).

Je ne vois pas de fermeture dans l'exemple que tu donnes par contre ?
J'en vois sur l'exemple de sort.Slice où la fonction less utilisera probablement un tableau en dehors.

people := []struct {
        Name string
        Age  int
    }{
        {"Gopher", 7},
        {"Alice", 55},
    }
sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })

L'intérêt des fermetures est de faire en sorte que l'algo central ne dépende d'aucun type particulier, même pas un type générique mais de la plus petite interface possible, par exemple func(i, j int) bool. Le code dépendant du type est dans la fonction avec fermeture et propre à chaque utilisation et donc en dehors de la lib.
Dans mon cas par exemple j'ai un tableau composé de lignes composées de cellules.
Il me faut faire un pdf de tout ça.
L'algo appelle chaque cellule et lui demande son rendu, pour ça une interface Rendu marche très bien. La où ça devient casse tête c'est quand une des cellules a besoin de ses cellules voisines pour calculer son rendu, par ex cellule 2 = cellule 0 + cellule 1
En Python la méthode Rendu de la cellule un = cellule.parent.cellules[0] + cellule.parent.cellules[1]
En Go tintin car cellule.parent.cellules[x] correspondra simplement à une cellule ayant l'interface Rendu. Il faudrait éventuellement faire un cast et perdre l'intérêt du typage statique, ce que je ne voulais pas.
Avec les fermetures la méthode rendu de ma cellule est appelée avec l'index de la ligne et c'est avec cet index que je vais chercher les cellules voisines (donc un tableau en dehors de ma méthode). Je n'ai même plus besoin de cellule.parent.

Bref, avec cette méthode de fermeture mon code de lib est réduit au strict minimum en manipulant uniquement des indexes, par rapport au Python où je pouvais me permettre de manipuler directement les lignes et cellules mais avec un code de lib du coup beaucoup plus complexe. Autrement dit je préfère dans certains cas un code de lib plus simple et déplacer ce qui est complexe au niveau de l'application. Parfois c'est l'inverse (tri par ex).

Avec le générique en Go il y aura moyen de se rapprocher de ce que l'on peut faire avec du typage dynamique. Avec par exemple un tableau qui contient des lignes de type T défini au niveau de l'application. C'est sûrement ce que j'aurai fait s'il y avait eu du générique à l'époque au lieu d'essayer la méthode avec fermeture que je préfère finalement pour ce cas de figure.

Je sais pas si je suis clair, c'est vraiment difficile à décrire…

J'ai eu le cas inverse en réécrivant une lib Python perso fortement basée sur generic + héritage.
Une lib pour faire des tables de rapports pdf avec gestion des cumuls, ruptures, sauts de pages & co avec comme principe que chaque colonne peut contenir n'importe quel type d'objet. Une lib que j'utilise dans quasiment tous mes projets.
Un vrai casse tête à réécrire en Go donc, sans generic ni héritage.
Finalement je me suis basé entièrement sur des closures et composition.
Miraculeusement j'ai réussi à ce que ça tienne en moins de ligne de code mais surtout j'évite ainsi tous les effets de bords qu'on retrouve avec trop de generic et héritage et mon code est beaucoup plus facile à maintenir malgré le fait qu'il soit utilisé dans beaucoup de projets.

Aussi ma conclusion pour le moment c'est que le generic c'est bien pour des codes très réduits et dont les fonctionnalités ne doivent plus bouger mais sur des libs plus grosses, comme toute dépendance c'est très difficile à faire évoluer.

Et encore, même pour des codes réduits, en Go on a l'habitude de faire des petites boucles à tous les coins de rues, pas sûr qu'on y gagne à les remplacer par des fonctions…

J'avoue qu'il faudrait montrer du code pour voir de quoi on parle !

Il me semble que dans l'exemple slice.Sort c'est bien le système de clôture/closure, la fonction n'est pas forcément anonyme.

On peut aussi en Go avec panic/defer.
J'ai essayé pour voir, dans des cas où ça ne changeait pas grand chose mais j'en suis vite revenu.
Aujourd'hui c'est quand je me remet au Python que ça m'angoisse de ne pas annoter tout de suite une éventuelle erreur ni de la retourner explicitement !

A force je ne me souviens même plus quand j'en ai eu besoin et que ça m'avait manqué !
La plupart du temps je m'en suis sorti avec des closures, je crois qu'on appelle ça comme ça, un peu comme pour sort.Slice.
Au final de ne pas avoir de généricité je crois que ça m'a évité pas mal de codes difficiles à maintenir, que l'on regrette après coup, comme j'ai pu en avoir dans d'autres langages.
Je suis quand même impatient d'essayer !

Prochaine étape, le faire tourner sur lynx avec l'extension vim, le tout dans un screen qui se connecterait par un tunnel websocket.

Attention aux clichés concernant l'Allemagne…
https://www.ifrap.org/emploi-et-politiques-sociales/emissions-de-co2-et-industrie-la-comparaison-france-allemagne

Principalement : le CO2 à d'avantage baissé en Allemagne, cela malgré une forte industrialisation et exportation.
En France le CO2 a baissé du fait de la désindustrialisation et des importations.
L'Allemagne est dans une période de transition, la France est assise sur des acquis (qui ne vont plus durer très longtemps).

Ca n'est pas pour vanter le modèle Allemand, qui doit lui aussi évoluer, mais il faut faire attention aux comparaisons hâtives.

Comme le montre RTE, il faudra trouver un juste milieu et ça ne sera pas simple.

D'où sort la division par 5 ? dans la synthèse c'est une division par 3.
C'est une moyenne, 30% des camions roulent à vide, la moitié des trajets font moins de 5km, on jette 30% de la nourriture, 6 millions de passoires thermiques, obsolescence programmée etc…
L'effet falaise et le temps de construction c'est dans le rapport de l'AIE-RTE.
On aura plus de précisions demain sur ce qu'il est possible de faire ou pas. Mais dans tous scénario il faut surtout retenir les bonnes idées, à part les chinois personne n'appliquera une planification à 30 ans !

Tu n'es pas idiot et je comprend l'intérêt de ce que tu dis de maximiser les solutions. Ce pourrait-être l'idéal modulo le danger et les déchets (mais à la rigueur c'est un autre débat).

Mais les scénarios de type Negawatt obligent en quelque sorte à faire des économies car comme tu dis sinon ça ne marchera pas. Donc on va mettre les bouchées doubles.
Tu penses que c'est risqué mais je pense que c'est motivant (le cap) et qu'on n'a pas le choix.

En revanche les scénarios qui tablent sur une abondance d'énergie nucléaire donnent des excuses pour ne pas faire d'économies (c'est déjà ce qui se passe en France) d'une part et est risqué car on peut avoir un effet falaise à tout moment et manifestement trop tard et trop cher.

Autrement dit, ton scénario je le vois bien pour 2100 quand on aura déjà atteint une sobriété heureuse et que la recherche aura permis de résoudre les problèmes des risques, des déchets et du terrorisme :-)

Les scénarios RTE qui vont sortir demain nous donnerons également de la matière car on pourra comparer les différences de plusieurs scénarios plutôt que d'en juger un seul et spéculer sur les autres.

A demain ?

Est-ce que je me trompe ou bien négawatt ne compte pas sur une réindustrialisation ?

Attendons la présentation complète mais oui bien sûr la prise en compte de l'énergie grise et des importations est essentielle.
En tout cas c'était le cas dans le scénario précédent, notamment en favorisant l'économie circulaire, les circuits courts, l'efficience etc.

Ce sont des technologies relativement matures et maitrisées.
Je pense que sur ce point tu oublie qu'au niveau climat c'est à l'échelle mondiale qu'il faut raisonner.

Dans tes exemples de scénarios tu ne mentionnes pas les proportions ni les délais, hors c'est capital pour le climat. Le nucléaire représente moins de 5% à l'échelle mondiale et ça n'est pas près de changer avant des décennies même avec la meilleur volonté.
Installer des capacités ENR et faire des économies ça peut être fait dès maintenant, et c'est déjà en partie le cas.
Tu parles aussi de combler le trou des fossiles, mais encore faut-il creuser ce trou ! Si on ne raisonne qu'en terme de construction de nouvelles unités de production, quelles qu'elles soient on ne creuse pas de trou pour autant…
Par exemple si on réduit la consommation des voitures et que du coup on roule plus ça ne change rien.

Bref, pour moi l'essentiel reste de réduire la consommation d'énergie pour que le reste soit de moins en moins important. Changer une vieille voiture qui pollue a moins d'importance si on ne l'utilise quasiment plus (c'est même contre productif). C'était le piège du nucléaire, pas cher donc on chauffe plutôt qu'isoler.

Au contraire, plus on arrive à se passer d'énergie en direct (isolation vs chauffage) plus ça en laisse aux industriels et autres.
Plus on roule à vélo plus ça laisse de la place aux voitures restantes.
Par contre penser que tout le monde peut pomper sans regarder et qu'il en restera toujours indéfiniment commence à être de plus en plus illusoire.
De fait les coupures arrivent quand on tire trop, jamais quand on tire moins.

La question c'est plutôt est-ce imaginable d'avoir une action sur le climat sans décroissance de la consommation d'énergie ?

Ca ne me dérange pas de diminuer mes revenus si je n'ai plus à me chauffer parce que ma maison est bien isolée, plus à avoir de voiture parce que toute ma famille peut se déplacer à vélo ou en TC, plus changer mes appareils alors qu'ils pourraient être réparés, plus à verser des impôts pour subventionner des politiques de gaspillage, plus à acheter des logiciels privateurs ;-) etc.
Il ne faut pas confondre décroissance de la consommation d'énergie et récession économique.
https://bonpote.com/decroissance-et-prejuges/