wilk a écrit 1090 commentaires

Lancement prochain du mode autopilot. Plus besoin de tweeter soit-même. Grace à une IA, nommée KePenserDe, on pourra tweeter sans même avoir besoin d'être réveillé. Enfin des débats "sains" et non plus souillés par notre propre pensée archaïque soumise aux aléas biologiques d'un autre temps.

Bien vu, apparemment c'est un problème qui n'est pas résolu et qui concerne pas mal d'autres frameworks, y a une recherche de consensus au niveau w3 pour permettre que des attributs persos soient valides mais c'est pas encore le cas. Théoriquement il faudrait utiliser quelque chose qui commence par data-. Je ne sais pas si c'est possible de le configurer…

Désolé j'ai raté l'option, c'est une migration d'une boite française mais c'est pas en français…

A part ça je peux aussi témoigner sur l'intérêt de cette petite lib qui permet d'ajouter un peu de réactivité aux pages sans renier la logique du rendu serveur… Que du bonheur.

Dernier truc rigolo en date, en récupération de billet (acheté sur TER et transféré sur l'appli) il n'en récupère qu'un sur 4 et me l'affiche avec 2h en moins ! Ca sent le problème de timezone… J'imprime…

C'est que maintenant les gens sont tellement habitués à voir des applis pleins de bugs que soit mon appli en à aussi et c'est normal c'est comme ça, comme les grands, soit elle n'en n'a pas (et en plus elle est rapide) et je passe pour un génie !

edit:
Et maintenant je pourrai dire à mes clients, attention si vous ne testez pas la beta ça va finir comme à la SNCF.

J'ai trouvé le graal du serverless sans la contrainte de réécrire les apps ! Ca s'appelle Knative, ça scale de zéro… Je dis knative pour ne pas citer Scaleway et CloudRun qui le proposent « as a service ». Le principe est simple, l'application doit écouter sur le port 8080 comme n'importe quel serveur http.
Longtemps j'étais réticent à quitter l'infra à la papa où rien n'a changé ou presque sous le capot depuis 30 ans et qui permet de comprendre ce qui se passe et agir à tous les niveaux. Mais là j'avoue, c'est bluffant. Git push et voilà.

L'avantage du Go dans ce cas il est simple, un Dockerfile avec un distroless on ne plus simple et le démarrage à froid se fait dans la seconde, une empreinte mémoire ridicule, un cpu qui reste au raz des pâquerettes. Tout ce qu'il faut pour faire un serveur http est dans la lib standard, même les templates html, même l'embarquement des assets dans le binaire !

Autre avantage de Go c'est de pouvoir jongler soit avec des goroutines+channel en interne soit reproduire exactement la même chose en microservices séparés (les channels sont à sens unique). Il m'est arrivé plusieurs fois de passer de l'une à l'autre méthode en changeant quelques lignes de code simplement.

Niveau de la simplicité du langage personnellement ça me rappelle le C de ma jeunesse, que de bons souvenirs !

Bref, à part la partie cachée du serverless, je retrouve le côté simple d'unix un binaire qui vet voilà.

Tellement rapide. Je modifie un fichier, j'enregistre, le code est formaté, les imports ajustés, les erreurs de types détectées, le temps d'aller sur le bureau d'à côté et de recharger ma page le bouzin est déjà recompilé. C'est plus rapide que quand de relancer un serveur python !

Je viens d'essayer sur un vieux code, le résultat est assez précis :

Vulnerability #1: GO-2021-0052
Due to improper HTTP header santization, a malicious user can
spoof their source IP address by setting the X-Forwarded-For
header. This may allow a user to bypass IP based restrictions,
or obfuscate their true source.

Call stacks in your code:
main.go:71:12: godepot.main calls github.com/gin-gonic/gin.Engine.Run

Found in: github.com/gin-gonic/gin@v1.3.0
Fixed in: github.com/gin-gonic/gin@v1.7.7
More info: https://pkg.go.dev/vuln/GO-2021-0052

Donc j'ai l'explication de la vulnérabilité et la ligne de code où j'appelle la fonction dans la lib vulnérable.
Si j'enlève ma ligne de code je n'ai plus d'alerte.
J'ai le choix entre modifier mon app ou mettre à jour la lib.

Ensuite j'obtiens également des infos sur des problèmes que je pourrai rencontrer mais à priori pas.

=== Informational ===

The vulnerabilities below are in packages that you import, but your code
doesn't appear to call any vulnerable functions. You may not need to take any
action.

Ce ne nous rajeunit pas tout ça.

HP n'est plus ce que c'était, les trois dernières, une laser et deux jets d'encre que j'ai eu m'on énormément déçu.
La dernière blague c'est que les cartouches originales HP ont une date de péremption même sous blister ! Donc tu as acheté une cartouche de plus pour en avoir en réserve, tu la mets et elle te dit qu'il ne vaut mieux pas, que ça risque d'endommager ton imprimante. Tu appelles le support pour les rassurer sur le fait que tu prends l'entière responsabilité d’abîmer ton imprimante, mais non, rien à faire, c'est écrit dessus t'avais qu'à regarder.

L'automobiliste écolo, il laisse le moteur allumé pour ne pas couper la clim, ainsi il peut éviter une douche.
Sinon franchement quand il fait bien chaud dehors on transpire beaucoup plus en voiture qu'à vélo à allure pépère.

Les bains glacés en Norvège c'est le top. Mais on s'écarte un peu du côté éco-geste ! Alors on se console comme on peut avec une petite douche froide quotidienne.

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…