16aR a écrit 240 commentaires

J'avais fait des pilates pour découvrir et notamment pour le renforcement des muscles profonds, vu ce que notre dos prend avec l'informatique.
J'avais bien aimé le formateur où j'étais, mais j'ai du arrêter pour d'autres raisons. Il m'a envoyé un email il y a peu sur le fait qu'il proposait du coaching en ligne:

Coaching Bien être et Forme by Angie et E.L Coaching ont le plaisir de vous présenter le coaching privé en ligne. 


👉 Souhaitez vous rester en forme ?
👉 Voulez vous perdre du poids ?
👉 Avez-vous besoin de faire du sport ?
👉 Avez-vous la motivations seul(e) ? 

Nous croyons plus que jamais, que l’activité physique et le mouvement sont essentiels pour prendre soin de soi, garder le moral, briser l’isolement, se défouler et surtout booster vos défenses immunitaires ! 💪

Angie & Eric vous proposent un programme sport personnalisé et du coaching Nutrition en ligne et en direct de chez vous en toute sécurité. 



Deux options aux choix :



1. Vous êtes déjà accompagné(e) par votre coach, vous souhaitez continuer vos séances Individuelles en ligne tout en étant PERSONNELLEMENT coaché(e).   

          👉 je reprend contact avec mon coach et continue mes séances en ligne.





2. Vous n’avez pas encore de coach et souhaitez découvrir les bienfaits d’une séance de coaching en ligne (confinement oblige).

          👉 Nous offrons une séance découverte de Sport ou un rendez-vous bilan Nutri Bien-être de 30 minute.



Appelez nous vite pour bénéficier de l'offre.


Eric Lemble au 06.38.14.42.92
Angélique Heckmann au 06.76.86.56.86

En Go, en 1 seul fichier:

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "path/filepath"
)

func main() {
    createUploadDir(uploadDir)

    // on enregistre le handler d'upload sur le / du site dans le routeur par défaut
    http.HandleFunc("/", handleUpload)
    // on écoute sur le port :9090 sur toutes les interfaces de la machine
    // en utilisant le routeur par défaut
    http.ListenAndServe(":9090", nil)
}

func handleUpload(w http.ResponseWriter, r *http.Request) {
    log.Println("method:", r.Method)
    if r.Method == "GET" {
        // On écrit dans le ResponseWriter le code HTML, ce qui permet d'afficher
        // la page sur le navigateur
        fmt.Fprint(w, uploadHTML)
    } else {
        // Le serveur utilisera 10Mo en mémoire pendant l'upload, le reste
        // sera stocker sur des fichiers temporaire sur le disque.
        r.ParseMultipartForm(10_000_000)
        file, header, err := r.FormFile("uploadfile")
        if err != nil {
            // On logge l'erreur sur le serveur
            log.Println(err)
            // On renvoit une erreur 500 avec le message d'erreur sur le navigateur
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        // On ferme le Reader des données de formulaire à la sortie de la fonction
        defer file.Close()

        // On ouvre un fichier en écriture pour enregistrer l'upload, dans le dossier d'upload
        f, err := os.OpenFile(filepath.Join(uploadDir, header.Filename), os.O_WRONLY|os.O_CREATE, 0666)
        if err != nil {
            log.Println(err)
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }
        // On ferme le fichier créé à la sortie de la fonction
        defer f.Close()

        // On copie les données d'upload dans le fichier sur le serveur
        _, err = io.Copy(f, file)
        if err != nil {
            log.Println(err)
            http.Error(w, err.Error(), http.StatusInternalServerError)
            return
        }

        // On écrite les métadonnées du fichier uploadé dans le ResponseWriter
        fmt.Fprint(w, header.Header)
    }
}

// createUploadDir créé un dossier d'upload où stocker les fichiers
func createUploadDir(uploadDir string) {
    err := os.Mkdir(uploadDir, 0770)
    if err != nil {
        log.Println(err)
    }
}

const (
    // uploadDir est le dossier de stockage des fichiers uploadés
    uploadDir = "./test"

    // uploadHTML est une chaîne contenant le HTML de la page d'upload
    uploadHTML = `<html>
<head>
       <title>Upload file</title>
</head>
<body>
<form enctype="multipart/form-data" action="http://127.0.0.1:9090/" method="post">
    <input type="file" name="uploadfile" />
    <input type="submit" value="upload" />
</form>
</body>
</html>`
)

Pas le code le plus idiomatique, ni le plus beau, mais il est concis et j'espère "facile" à comprendre. Si besoin d'explications, n'hésite pas.
Mais clairement, il manque beaucoup pour en faire un truc vraiment correct (jeton CSRF, templating, CSS, etc).
L'un des avantages, c'est que ça produit un simple fichier binaire que tu peux copier coller sur n'importe quel serveur en ssh, et ça tourne. Pas besoin d'installer 100 packages ou des dépendances dans tous les sens. Juste le binaire et c'est bon.

C'est inspiré de https://astaxie.gitbooks.io/build-web-application-with-golang/en/04.5.html

C'est plus un gestionnaire d'issue intégré à git (et donc lié à ce projet git), donc je ne sais pas si ça correspond (j'avoue ne pas avoir tout compris au besoin).
Mais au cas où : https://github.com/MichaelMure/git-bug

On peut voir pour chaque tag de chaque architecture le log complet de build de l’image
(exemple pour gcc)

Ils chargent même la clé GPG que tu peux vérifier dans le log, et si jamais tu hésites encore, tu pourrais vérifier le hash du binaire une fois dans l’image pour voir que ce qui est loggé correspond bien à ce qui est dans l’image. Et pour gcc, on voit bien que l’image est buildée depuis les sources officielles de gcc.
Je ne pense pas que ce soit si compliqué à vérifier (un onglet tag, plus click sur chaque étape) et on peut le faire également localement. Et comme dit, si tu manques de confiance, tu peux copier ce Dockerfile et le builder toi-même. Dernière étape de paranoïa : est-ce que docker a un bon DNS configuré pour aller sur le bon site officiel de gcc et que le log indiquant récupérer le tar.gz n’est pas en train d’aller sur un site tiers.
Mais bon, à ce niveau là, on arrête l’informatique et on se fait berger, car on peut vraiment tout dévier, y compris le matériel. Tu fais confiance aux puces Intel ? Aucun composant d’espionnage n’a été glissé par les fondeurs techniques ?

Je monitore mon serveur mi-pro/mi-perso, docker tourne et gère 50 containers (serveur mail, nextcloud, subsonic, wordpress, hugo, appli web Go perso, gitea, ldap, perkeep, registry docker, etc). J’ai rajouté cAdvisor + prometheus + grafana, et je peux voir ce que chaque container bouffe en terme de CPU/réseau/IO en temps réel. J’avais suivi ce tuto là qui explique bien : https://blog.eleven-labs.com/fr/monitorer-ses-containers-docker/ . En vérité, ça me rajoute 20 lignes dans mon docker-compose.yml, donc c’est simple. Et tout ça tourne sur une dédibox à 29,99€, donc 4-core + 8Go de ram.
Mon problème actuel, c’est le manque d’espace disque, mais ça vient de mon nextcloud qui commence à être gourmand. Parce que JE suis gourmand.

s/gVisior/gVisor/

C’est ça.
Construire autour de LXC devenait plus dur, et du coup ils ont fait leur propre implémentation en Go plutôt que de manager du LXC depuis Go.

Exactement, je ne lis rien en quoi ils arrêtent le support de firefox.

Est-ce qu’on peut dire que les green threads sont du multi thread puisqu’ils n’utilisent pas les thread OS ?

Par éventuels donateurs, tu considères que ce sont tous des gens comme toi qui prennent pour attaque personnelle une initiative de contrebalancer le sexisme inhérent d’un langage  ?
Ok.
Je ne suis pas fan de l’écriture inclusive, mais de là à ce que ça me froisse pour ne pas faire de dons, faut pas charrier. Et puis, ça part d’un vrai problème.

Je suis d’accord. Autant, avoir des branches de release pour ton propre logiciel sur des versions maintenues en parallèle fait sens : v19 et v13 par example.
Par contre, avoir des branches par version majeure de dépendances, je pense que ça a plus de désavantage qu’autre chose.
Dans ce cas, tu as juste une dépendance vers gtk, donc ça va. Imagine tu aurais en plus des dépendances vers une lib audio + une autre. Tu ferais la combinaison de chaque dépendance dans une branche dédiée ? gtk3-pulseaudiov13, gtk3-pulseaudiov12, gtk4-pulseaudiov13, gtk4-pulseaudiov12, gtk3-jackv1, gtk3-jackv2, …

Du coup, si ton code est bien organisé, tu peux modifier une partie du code sans toucher au gtk et ça marchera bien sur toutes les versions des dépendances.
Et vice versa, si tu dois modifier une logique uniquement liée à gtk4, seule la partie gtk4 sera modifiée.
Je pense qu’un bon design de ton code devrait permettre cela, et les branches longues git ne serait que pour versionner ton code, pas celui des dépendances.

Je n’ai pas été assez explicite, je disais que je reprochais à gitflow la même chose que toi.
Et je suis aussi a vraiment plutôt faire du master first, avec une branche de feature/fix plutôt temporaire pour éviter les rebase/merge violent lorsqu’on se resynchro.

Perso je préfixe mes version publié par vX.Y.Z en mode versionnage semantique.
Et sinon, tout ce que je pushe est buildé par la CI, et ces version intermédiaires sont versionnées avec le hash du commit git.

carrément, c’est vraiment ce que je reproche.
Sur le papier, ça a l’air assez simple, mais une fois à gérer au jour le jour avec des merges à droite à gauche, ça devient vite le merdier.

La règle, c’est d’utiliser 1 branche de release par version majeure. Ou, d’1 branche release par version déployé, si c’est un logiciel déployé chez plusieurs client avec à chaque fois des devs spécifiques non mergeable sur la master/release dédiée.

Personnellement, j’étais à fond sur cette méthode au début, puis j’ai été face à plusieurs autres méthodes. Dernièrement, après quelques questionnements, j’ai vérifié ce que faisait le créateur de cette méthode: il ne l’utilise sur aucun de ses repo github récents ! Et il faut les chercher les peu de repo où il a utilisé sa propre méthode.
La seule défense que je pourrais avoir, c’est qu’il ne l’utilise que sur des repo privées professionnel d’envergure. Mais même là, j’ai un doute.
Le plus gros problème que je vois, c’est l’utilité de la branche master. Elle ne sert qu’à lister les différentes release. Sauf que je trouve que ça ne sert à rien et c’est même pas cohérent quand on a 2 versions majeures d’une même app.

Imaginons l’exemple d’une app en 2 versions: v2 et v3. v2 était en Node.js, et la v3 a été réécrite en Go.
Quelle est l’idée d’avoir sur master un tag v2.1.1 suivi d’un tag v3.0.0 puis ensuite un v2.2.0 ?
Pas du tout la même stack technique, on passe d’une branche a une stack node, vers du Go puis du node à nouveau ?
Pour cet exemple, je vois plus chaque version majeure sur sa branche de release. Excepté, la branche en cours de développement est sur master.
Seuls les tags garantissent une publication correcte. Le reste, c’est de l’état intermédiaire en plus ou moins bon état.

Le New York Times avait sorti à l’époque pour leur site de recette un système de Machine Learning qui extrayait les ingrédient d’une recette texte.
Évidemment, ils avaient un jeu de données énorme qui a en plus été augmenté par des petites mains.
L’histoire ici: https://open.blogs.nytimes.com/2015/04/09/extracting-structured-data-from-recipes-using-conditional-random-fields/
Et le code source est linké dans l’article.

Évidemment, ça ne marche qu’avec de l’angliche. Il faudrait faire le travail des petites mains sur des recettes françaises.

Le problème auquel je me suis confronté, c’est qu’après que tu as des recettes avec la liste des ingrédients, il faut consolider parmi plusieurs recettes avant d’aller faire les courses, et donc, 2 tomates + 1 conserve de tomate pelée de 400g + 1 conserve de tomate concassée de 200g, ça fait combien de tomates au final ? Tu prends déjà la tomate au plus près de l’utilisation de la recette ? Tu la pèles toi-même ?

Mais du coup, l’I²C devrait remplir le /sys correctement ?
Je répondais surtout au

Il faudra par la suite créer un programme (vraisemblablement en Python) qui lit la charge de la batterie pour afficher une notification à l’écran. Sur ce point, j’ai déjà des contacts mais tout volontaire est le bienvenu. ;)

Et proposer mon aide si c’était juste de lire le /sys ou de développer un module kernel.

Après avoir passé pas mal de temps sur du C++, et en remarquant que c’est difficile d’avancer rapidement quand tu es toujours à penser à ta gestion mémoire et ou multithreading, j’ai changé mon fusil d’épaule et me suis dit que j’allais tenter avec du Go, comme ça, des perfs plus proche du C++, mais pas la complexité qui va avec, donc du coup, une logique de code plus proche du python.

Du coup, je suis un peu les projets Ebiten, Oak pour la 2D/Web.

En 3D, je lorgne surtout du côté de g3n. Un des développeur a fait un Sokoban en 3D plutôt léché pour du hackathon : Gokoban.

Bonjour,

pour la lecture de la batterie, l’idée, c’est de lire ce que l’OS donne comme information sur la batterie ? Ou à l’inverse, rentrer les données de la batterie dans l’OS/kernel /proc ou /sys, etc ?

Faut que je retrouve la documentation que j’ai lu pour utiliser LDAP, car en effet, ce n’est pas classique comme fonctionnement.

En gros, ton LDAP contient autant ta config que tes données.
Le protocole LDAP (qui permet d’accéder à ton LDAP) est très souple pour te permettre d’accéder à ta config et tes données, sous quelque forme d’organisation que tu as choisi.
Et du coup, depuis n’importe quelle appli utilisant LDAP en backend, tu devrais pouvoir faire ta requête LDAP pour sélectionner la bonne liste de membre, vérifier leur password, etc.

J’avais besoin de multidomaine (.com, .org, .fr), du coup, j’ai créé une racine multi-domaine (multiverse) et ait placé l’ou=people en niveau 1 comme certains utilisateurs devait également être multi-domaine. Ça donne :

dc=multiverse
  # Les users qui peuvent être référencés
  + ou=people
  | + uid=user1
  | + uid=user2
  + dc=org
  | + dc=domain
  | | + ou=apps
  | |   + cn=nextcloud # type: groupOfUniqueNames, ça me permet de référencer les users qui peuvent utiliser ce nextcloud
  | + dc=autredomaine
  | | + ou=apps
  | |  + cn=gitea # type: groupOfUniqueNames, ça me permet de référencer les users qui peuvent utiliser ce gitea
  + dc=com
    + dc=myemail
      + ou=apps
        +cn=mail # type: groupOfUniqueNames, ça me permet de référencer les users qui peuvent utiliser les emails

J’avais découvert un projet il y a quelques années sur LinuxFR. Et les résultats étaient plutôt bons. L’avantage, c’est que ça te fait en plus une interface graphique pour toute ta paperasse, avec un moteur de recherche full texte.
Ça s’appelle paperwork

Et après, on s’étonne des gens qui font des burn-out.

https://words.steveklabnik.com/a-sad-day-for-rust

Alors OK, Rust c’est safe, et que cet auteur jetait toute cette safety par la fenêtre, mais pas besoin de faire du harcèlement.

Mais bon, de toute manière, osef : https://twitter.com/golang/status/1154402973914505221

Y’a que les haters pour être énervés.

Le Mr plus haut ne nous a pas dit ce qu'il reprochait à Kotlin à part le fait que Big Brother n'en soit pas le géniteur.

Le Mr plus haut a un nom, pas besoin de rentrer dans ces jeux, et c’est plus facile de rechercher par la suite.

De 2, je ne reproche rien du tout à Kotlin. D’où tu imagines ça ? Tu penses que parce que j’aime Go, je suis Google fanboy ?
J’apprécie la Go Team, mais clairement, si ça dépendait que de Google, Go n’aurait jamais vu le jour. Le manager de Rob et Ken et Robert leur a permis d’expérimenter sur ce langage sans être affecté ailleurs. Si ça avait été un autre manager Google, sans l’expérience qu’avait ce manager vis à vis de Ken et Rob (ils bossaient ensemble aux Bell Labs), le projet Go aurait été mis aux oubliettes de Google.
Je m’auto héberge mes données sur nextcloud et évite au maximum Google et autre GAFAM.
Le monde n’est pas que noir et blanc, et le gris, c’est la majeur partie du monde.

Comme dit dans un autre message, je ne veux pas jouer au "mon langage est plus mieux que le tiens", mais je n’aime pas laisser des messages faux sans réponses.

On voit facilement ce que Go n'apporte pas au 22 Janvier 2020: Pas de traitement d'erreur digne de ce nom

Ok, c’est toujours rustique (haha), mais ça marche. Ils ont voulu améliorer avec le mot clé try (qui est, incroyablement proche du try rust dans ton post de comparaison Go VS Rust). Seulement, la communauté n’en voulait pas et a renvoyé la Go Team au tableau blanc pour réfléchir à une meilleure manière de faire voire trouver une solution communautaire

un support du fonctionnel basique

Oui, ça reste un langage impératif. On a quand même l’avantage de fonctions en tant que type de base et la syntaxe est plus agréable/lisible que sur une syntaxe C classique.

même même pas de gestion de modules avec un dépôt officiel

L’idée était de laisser la possibilité d’héberger là où on veut et de ne pas donner plus de travail à l’équipe Go. La gestion des dépendances n’est toujours pas complètement réglée, mais ça a bien avancé avec les modules, et grâce à ça, une sorte de centralisation de module existe maintenant avec le module proxy officiel dont une interface est disponible

même pas de généricité

Ian Lance Taylor et quelques autres s’y sont frotté. Ça doit être la 7ème ou 8ème implémentation des génériques qui a été testé. Mais les résultats n’ont jamais satisfait : soit c’était trop lent au runtime, soit trop lent à la compilation, soit la syntaxe était dégueu.
La communauté bloque beaucoup sur la syntaxe car on apprécie tous la simplicité de lire du Go. Rajouter une référence vers un type peut alourdir la lecture de code. Mais personnellement, la lib math avec des cast en float64 dans tous les sens, c’est pas un exemple de lisibilité si tu es en int. Du generics là dedans ferait le plus grand bien.
Pour les prochaines estimations, on perdrait entre 10 et 30% de temps de compilation sur des libs en génériques.
Un moyen de tester ces futurs générique en cours de dev: https://ccbrown.github.io/wasm-go-playground/experimental/generics/
(et pour le try)
L’idée, ce n’est pas d’inclure les 8 itérations des generics, mais d’avoir une implémentation correcte sur laquelle on peut compter pendant plusieurs années, et pas une API qui casse au bout de 3 mois.

Mis à part les goroutines, réimplémnentation un peu plus intégrée d'un concept de l'aube de l'informatique

Qui pourtant n’avait jamais vraiment été implémenté sur un langage récent connu.

Au lieu de tirer sur un sujet, tu pouvais ouvrir un autre sous-fil et proposer une alternative sans chercher de conflit ?
Après, je connais et apprécie LinuxFR, donc j’en prends pas ombrage personnellement ni pour le langage que j’apprécie, mais en effet, ça ne donne pas envie d’échanger, mais juste a se retrancher sur ses positions et se battre à coup de : "moi mon langage il a un garbage collector", "moi mon langage il gère le cycle de vie de mes allocations". Ça ne me semble pas très productif.
On peut échanger sur les faits, et présenter ses émotions et expériences sur le sujet sans à avoir à taper sur un autre et dire qu’il est nul et que son langage c’est de la m****.