Julien Jorge a écrit 710 commentaires

Cet argumentaire de « ne pas réinventer la roue » est pour moi un automatisme malvenu que les gens de conseil sortent à tout va pour se donner du crédit. Je pense au contraire que si tu es débutant tu as tout intérêt à réimplémenter des choses existantes ; c'est ce qui te fera passer du stade « connaître » au stade « comprendre ».

À titre d'exemple, j'ai appris à l'école ce qu'étaient des arbres binaires équilibrés mais ce n'est qu'en implémentant un AVL que j'ai compris comment ça fonctionnait. Pourtant mon implémentation n'était qu'une roue mal fichue, mais je l'ai utilisée, j'ai rencontré des problèmes qui m'ont amené à encore plus de réflexion, je l'ai confrontée à des outils plus mûrs pour en apprendre d'avantage.

J'ai aussi codé le chargement d'images bmp, tga, pcx, gif et autres. Cela n'a aucun intérêt dans un projet puisque de nombreuses bibliothèques le font déjà bien et que certains formats sont complètement obsolètes, et en plus je connaissais déjà tous ces formats. Et pourtant ça m'a fait me confronter au RLE, à LZW, à la question de la représentation des couleurs, aux formats palette, rgb16 et autres. À l'époque je confrontais mon code aux temps de chargement d'ACDSee, ce qui m'a amené à la question de l'optimisation. C'était aussi un bon exercice de suivi de specs puisque tous ces formats sont bien définis et que les documents techniques sont disponibles. Il y a en particulier plein de variantes de gif et j'avais dû rassembler de nombreux exemples pour valider l'implémentation.

Réinventer la roue c'est aussi apprendre à gérer un projet. Si tu te dis, par exemple, « je vais implémenter une messagerie instantanée » tu vas devoir poser un cadre. Est-ce que le client tourne dans un terminal, une app desktop, un navigateur ? Comment le serveur fonctionne-t-il ? Gères tu les sockets toi-même, utilises-tu des bibliothèques pour cela ? Est-ce que tout passe par le serveur ? Est-ce du pair à pair ? Comment gères-tu la sérialisation ? T'appuies-tu sur un protocole existant ?

Savoir poser des limites, sélectionner des fonctionnalités et cadrer le projet pour l'amener à terme, c'est aussi quelque chose qui se comprend en pratiquant.

Enfin même de manière professionnelle il m'est arrivé de réimplémenter des choses pour des raisons de coût : nous commencions avec l'outil d'un tiers puis nous le remplacions par quelque chose rendant le même service pour un coût moindre et des performances meilleures.

Moi je crois que les bons sportifs ne sont pas dans les gradins à manger des chips. Je crois que les bons musiciens jouent tous les jours, reprennent des morceaux existants qu'ils jouent du mieux qu'ils peuvent, avec des accords ratés et en passant à côté de subtilités. Ce n'est sans doute pas aussi bien que le morceau original mais ça peut quand même être une belle reprise, et surtout ça les rend meilleurs à ce qu'il font.

Alors si tu es débutant, et d'ailleurs ça marche aussi si tu es expérimenté, et que tu réponds à une offre de la boîte où je travaille, mon conseil est d'avoir :

• un CV court qui va à l'essentiel : « j'ai fait ceci et cela, ici et là bas » ;
• du code public et une explication du pourquoi, ce que ça tu as appris et comment tu t'y prendrais si tu devais le refaire ;
• éventuellement des liens vers des articles plus ou moins techniques que tu as écris (un journal sur LinuxFr.org par exemple :)), que je puisse voir que tu peux faire preuve de réflexion, d'analyse, de critique, ou que tu peux expliquer quelque chose à un tiers. Pas forcément lié à l'informatique : une recette de cuisine, comment tu as perdu 10 kg, comment tu as construit un abri de jardin, ou ton ressenti sur la gestion d'une vieille colonie de vacances ; peu importe du moment que ça ressemble à de l'analyse, de la critique constructive, de la réflexion.

Je vois que dune-dynasty se configure avec CMake, du coup pour commencer cloner le SDK d'Emscripten et lance

./emsdk install latest
./emsdk activate latest

et puis ensuite tu peux essayer cmake . -DCMAKE_C_COMPILER=path/to/emcc -DCMAKE_CXX_COMPILER=path/to/em++ du côté de dune-dynasty.

À partir de là c'est essai/erreur :)

Je tente une reformulation alors :)

Il n'y avait pas besoin d'un nouvel outil pour gérer du Json en C++, il y en avait déjà plein. Mais comme il n'y en avait pas dans Boost ça faisait comme un trou au niveau de ce projet.

As-tu rencontré des soucis dans les limitations d'Emscripten concernant les threads, exceptions ou autres ?

C'est vrai que Boost a pas mal perdu de son panache depuis C++11.

J'ai l'impression que l'arrivée du parseur Json n'intéresse pas grand monde et est là plus pour combler un manque que pour répondre a un besoin. Aujourd'hui le Json en C++ ça se joue plutôt entre nlohmann-json et simdjson.

Dans les trucs que j'aimais bien dans Boost il y avait Boost.Signals2 et Boost.Preprocessor. J'avais joué avec Boost.Spirit aussi et j'espère que je n'aurai jamais à y retoucher. À part ça, quelques algorithmes ici et là.

Et puis quelle galère pour compiler tout ça :(

Lapin compris. Tu aurais un exemple ?

En l'occurrence je pensais à un truc qui ressemble à ce qui suit. Intuitivement j'aurais écris quelque chose comme :

some_list = # …

list_a = []
list_b = []

for s in some_list:
    if s[0] == 'a':
        list_a.append(s)
    elif s[0] == 'b':
        list_b.append(s)

Mais j'ai l'impression qu'on me dirait que ce serait plus Pythonic de faire :

def starts_with_a(s):
    return s[0] == 'a'

def starts_with_b(s):
    return s[0] == 'b'

some_list = # …

list_a = list(filter(starts_with_a, some_list))
list_b = list(filter(starts_with_b, some_list))

Cette notion de "Pythonic", on la retrouve notamment dans des réponses sur StackOverflow. Par exemple :

Using an additional state variable, such as an index variable (which you would normally use in languages such as C or PHP), is considered non-pythonic.

Et là, perso, je me dis qu'utiliser des indices dans les boucles répond au problème de l'itération depuis 1792, et n'importe quel programmeur de n'importe quel langage peut comprendre une telle boucle. Est-ce que ça vaut le coup de l'éviter ? Pour quel gain ?

Je ne connaissait pas Docker Desktop, merci.

Est-ce que la version OSX permet d'avoir un conteneur OSX ? L'idéal pour moi serait de pouvoir lancer par exemple XCode dans un conteneur, ou quelque chose dans le genre.

Ça marche bien par ici d’ailleurs, l’idée étant que tu peux débiter les pires saloperies, la modération ne fera rien tant que ton texte est bien écrit.

La modération aimerait ne pas avoir à être juge, ni se mettre à censurer ceux qui veulent s'exprimer. Les journaux sont explicitement ouverts à tous les sujets dans les limites de ce qui est évidemment illégal.

Personnellement j'aimerais vraiment que ces contenus disparaissent, mais voilà : on a des membres qui viennent colporter des bêtises, et au lieu de laisser le journal mourir à -42 sans commentaires on a une communauté qui vient alimenter la discussion parce qu'IL A TORT C'EST N'IMPORTE QUOI BON SANG ! Et on se retrouve avec un torrent de caca dans les commentaires pendant des semaines.

Alors qu'il y a au moins deux bonnes méthodes pour faire disparaître ce genre de contribution :

• ne pas y répondre pour leur faire passer l'envie de poster ce genre de sujets ici,
• soumettre des journaux pertinents pour amener une bonne ambiance et atténuer le poids de ces contenus sans intérêt.

Je vois que tu arrives à poster sur LinuxFr alors je t'invite à continuer à écrire des journaux, comme tu l'as déjà très bien fait par le passé, et à laisser mourir ce journal sans intérêt.

On peut avoir une idée du volume et de l'offre sélectionnée pour se faire un avis.

Oui, rclone size me dit:

Total objects: 15705
Total size: 82.180 GBytes (88240142824 Bytes)

Ce que confirme le tableau de bord sur AWS.

La facture de décembre est de $1.09. Je ne crois pas avoir sélectionné d'option en dehors d'avoir créé un compte AWS. Ensuite j'ai créé le bucket, je l'ai mis en ue-west et pour la classe de stockage c'est « Unizone – Accès peu fréquent ».

Je fais aussi mes sauvegardes sur aws, avec le même débit. De mon côté ça tourne la nuit.

J'avais regardé les tarifs de glacier et de souvenir il y avait un coût non négligeable lié aux nombre de requêtes. Comme je fais un rclone chaque nuit sur un gros dossier je craignais que le nombre de requêtes soit trop élevé, du coup j'envoie tout sur S3. Ça me coûte environ un dollar par mois.

Par rapport à ton script, que se passe-t-il quand tu reprends la main, la copie est en pause ? Interrompue ? Chiffres-tu tes données avant de les envoyer ?

Merci pour cette excellente dépêche, merci en particulier à Jehan car c'est toujours un plaisir d'avoir des nouvelles aussi détaillées de GIMP.

À titre personnel j'apprécie en particulier le côté « juste libre » de ce que vous faite avec LILA. On parle régulièrement ici de licences NC et ND, et que « oui c'est de l'art c'est pas pareil que du code ». De votre côté vous faite de l'art et du code, tout est en BY-SA, c'est juste simple. Bravo à vous.

Une petite question technique pour finir : maintenant que la migration vers GTK 3 est terminée, entamez vous la migration vers GTK 4 qui vient de sortir ?

J'aime bien l'idée mais j'y vois pas mal d'inconvénients :)

• Je plussois sur l'intérêt de documenter le site d'appel, mais en l'état on n'a plus les noms ni les types des paramètres dans la signature de l'appelé.
• Second problème, l'appelé est forcément template. Ais-je envie d'augmenter mes temps de compilation pour pouvoir nommer les paramètres côté appelant ? Probablement non.
• Comment passer des paramètres par adresse ? Combien de copies des paramètres sont faites entre l'appelant et l'appelé ? Sur cet exemple j'ai déjà une copie superflue :

#include "../include/params14.hpp"

#include <cstdio>

using namespace params14::literals;

int copy_count = 0;
int assign_count = 0;

struct copy_counter
{
  int value;

  copy_counter(int v) : value(v) {}
  copy_counter(const copy_counter& that)
    : value(that.value)
  {
    ++copy_count;
  }

  copy_counter& operator=(const copy_counter& that)
  {
    value = that.value;
    ++assign_count;
    return *this;
  }
};

template<typename... KWArgs>
void foo(KWArgs&&... kwargs)
{
  auto args = params14::parse(std::forward<KWArgs>(kwargs)...);
  printf("value=%d\n", args.get("p"_kw).value);
}

void bar(const copy_counter& p)
{
  printf("value=%d\n", p.value);
}

int main(int argc, char** argv)
{
  copy_counter p(argc);
  foo("p"_kw=p);
  printf("named:\ncopies=%d\nassignments=%d\n", copy_count, assign_count);

  copy_count = 0;
  assign_count = 0;
  bar(p);
  printf(
         "good old syntax:\ncopies=%d\nassignments=%d\n",
         copy_count, assign_count);

  return 0;
}

Perso je trouve la difficulté dans le kn, à savoir si ça se prononce comme dans knife ou Knuth par exemple.

Au final je prononce le K à la française.

[…] ta question était purement théorique pour faire chier le peuple […]
[…] comme un bon facebookien, tu pollues les commentaires pour déverser ta rage extrémisante sans même avoir pris le temps de lire de quoi on parle.

Comme tu y vas !

Ça m'amuse parce qu'en lisant ton journal et en voyant « Creative Commons » sans précision j'ai tiqué aussi. Pas sur le sens des mots, c'est plutôt que j'ai trouvé cela très étonnant de ta part car je ne doute pas que tu connais très bien LinuxFr.org et que tu sais très bien que sans précision ça va dégénérer dans les commentaires.

Du coup je pense que tu as volontairement omis la précision pour générer ces commentaires, auxquels tu peux réagir pour faire encore plus de bruit et asseoir ta présence. Mais bon, peut-être que j'extrapole :D

C'est pas mal comme solution, merci. J'ai mis une IP fixe, pas de passerelle et pas de DNS, maintenant ça imprime bien.

Merci, grâce à cette commande (en root) l'imprimante apparaît bien. Elle est partagée deux fois : une fois par avahi et une fois par cups. Pas de chance, l'impression ne se lance sur aucune… Mais ça me fait déjà un peu avancer !

C'est obligatoire en effet, je préfère que l'imprimante n'ai pas accès à Internet et je n'ai pas envie de gérer des routes pour elle :)

Pour la procédure j'ai suivi cette page. En gros :

1. activer le débogage USB sur le téléphone
2. connecter l'appareil en USB
3. adb reboot bootloader, pour accéder au menu de boot
4. fastboot devices, pour vérifier que l'ordi voit bien l'appareil
5. fastboot oem unlock, pour débloquer le bootloader
6. redémarrer le téléphone s'il ne le fait pas tout seul
7. récupérer un TRWP récent
8. refaire 1 à 4 pour revenir au bootloader si nécessaire
9. fastboot flash recovery trwp*-mako.img
10. fastboot boot trwp*-mako.img
11. rebooter en recovery (i.e. lancer TRWP sur le téléphone)
12. cliquer sur Wipe puis Format data
13. récupérer une image de LineageOS, par exemple https://androidfilehost.com/?fid=8889791610682908446
14. dans TRWP cliquer sur Advanced puis ADB Sideload puis swiper
15. sur l'ordi, adb sideload lineage-15-1-20200807-UNOFFICIAL-mako.zip

Si jamais le téléphone se met à redémarrer en boucle, maintenir le bouton volume bas pour qu'il s'arrête au bootloader au redémmarrage.

C'est pas de leur faute, il faut dire qu'avec la crise qu'on traverse… Heureusement qu'ils étaient là sinon ça aurait été pire.

Je pense l'avoir déjà dis, mais peut-être que le problème de vitesse de compilation de C++, c'est juste que les gens font de la merde, à tout inclure comme des porcs sans réfléchir?

Qu'est-ce qui te fait croire ça ? ;)

Oui, il suffit de ne pas exporter les symboles. Cet article en anglais décrit bien les cas d'usage.

Le problème des headers est qu'ils sont interprétés des tonnes de fois. Même avec des gardes, c'est lu et relu pour chaque unité de compilation les utilisant. Sur des gros projets ou de grosses dépendances ça se sent.

De plus le résultat de l'interprétation peut varier d'une unité de compilation à l'autre selon les paramètres du préprocesseur.

// header.hpp
#pragma once

#ifdef FOO
  using bar = int;
#else
  using bar = char;
#endif

// 1.cpp
#include "header.hpp"

static_assert(std::is_same_v<bar, char>)

// 2.cpp
#define FOO // ou -DFOO sur la ligne de commande
#include "header.hpp"

static_assert(std::is_same_v<bar, char>)
// Perdu, bar est int.

Les modules sont une réponse à ces problèmes.

J'ai testé un petit peu, ça m'a l'air d'être exactement ce que je veux, merci :)

Je me retrouve dans ces 4 sources mais je ne mets pas le même poids à chaque.

En ce qui me concerne, ce qui m'intéresse c'est sans doute de devenir meilleur à ce que je fais. Je ne saurais expliquer pourquoi et je n'ai pas envie de chercher, je sais juste que ça me stimule.

Au travail ce sera ma première motivation : atteindre un objectif en apprenant des choses au passage. Construire un logiciel, un outil, du mieux que je peux, en le découpant en petites tâches que je résoudrai une à une pour construire quelque chose de plus grand et d'utile à quelqu'un. J'apprends en pratiquant et l'aboutissement du projet, la confrontation au public, sert à confirmer que je m'en suis bien sorti.

Ensuite les technos jouent beaucoup. De tous les langages que j'ai essayé, je préfère faire du C++. J'ai trouvé insupportable d'utiliser Unity. Les langages du web et tout l'écosystème qui va avec m'ennuient. J'aime aussi bosser avec un tooling léger, moins il y en a, mieux je me porte. En gros tu me files Linux + CMake + Bash + GCC et je suis heureux.

Je dirais donc énormément pour « maîtrise » (il faut que ce soit un peu plus compliqué que ce que je sais faire), beaucoup pour « autonomie » (je choisis mes outils et contribue à la méthode de résolution) et pas mal de « sens » (il faut que ce que je fais serve à quelqu'un).

Pour ce qui est de l'effet tribu, il y a de ça aussi. Effectivement c'est mieux si je suis en phase avec les collègues et que nous marchons en rythme vers un objectif commun, en accord sur les méthodes. Je ne suis pas sûr cependant qu'on puisse trouver ça dans de grandes équipes ; à un moment il y a forcément des profils disons moins stimulants. Et puis il faut voir ce que chacun apporte. J'ai eu un collègue qui était très bon sur un domaine où j'étais nul, mais à côté de ça son code était plutôt médiocre et il n'avait aucune intention de faire des efforts sur ce point. Au final il n'y a pas grand chose à faire, chacun apporte sa contribution au projet.

Tu passes sur le salaire mais ça a sa pertinence aussi, pas tant pour la somme que pour le symbole de reconnaissance. Avoir une renégociation genre une fois par an avec une petite augmentation, c'est rassurant. A contrario, voir le coût de la vie augmenter et son revenu stagner, ça donne l'impression d'être coincé dans une impasse, c'est démotivant. Pareil pour les primes, recevoir une prime quand on dépasse les attentes, c'est encourageant. Sans ça on fait vite le ratio revenu sur effort et on arrête les efforts.

Alors j'ai lu ce livre et effectivement c'est un de ceux que je pointe. Je fais aussi référence à Code Complete.

C'est plein de bons conseils et lire ça me semble être un bon moyen d'acquérir une sorte d'expérience de plusieurs décades de développement avant nous. Mais que faire quand les autres ne l'ont pas lu ? Pire, que faire quand ils ne sont même pas intéressés par la notion de code clean ?

Il y a aussi des principes qui ont un peu vieillit dans ces livres. Dans le lien de blog que tu donnes plus bas il y a un lien vers un autre article qui explique que le DRY se fait avec modération. Oui, factoriser à tout va pose aussi des problèmes. Oui je m'y suis aussi brûlé.

Pareil pour le fait de favoriser le polymorphisme à la place d'if/else ou switch/case. Ça se discute. Des fois c'est plus clair d'avoir tous les cas à plat dans un switch plutôt que d'avoir plein de classes qui éparpillent la logique.