Julien Jorge a écrit 530 commentaires

Très intéressant :) Sur le sujet des données embarquées dans le binaire, as-tu regardé les travaux de JenHeyd Meneide ? Il semblerait que l'approche xxd soit la plus chère en temps de compilation.

Concernant cette histoire de bitcoins, je crois que c'est un problème qui va au delà de la monnaie ; c'est à dire que les réactions seraient les mêmes si GIMP avait reçu directement un million d'euros de dons.

Vous pourriez décider de dépenser le million en un salaire confortable pour, au hasard, le principal développeur, qui en plus a un impact positif et énorme sur la visibilité et l'image du projet. Sans partir dans des sommes énormes, lui donner une rémunération semblable à celle d'un poste équivalent dans une entreprise classique permettrait de le sécuriser pendant quelques années. Ça ne me semblerait pas déconnant mais je suis certain que vous vous feriez lyncher :)

C'est un peu un problème dans le libre qui marche. Vu que c'est un grand projet communautaire avec plein de contributions, il y a cette règle implicite que ce que tu reçois de la communauté doit repartir dans la communauté. Ça doit repartir quasiment tel quel ; le fait d'améliorer le logiciel n'est pas considéré comme un vrai retour, puisque de toute façon il aurait été amélioré même sans les dons.

Si quelqu'un tire un bénéfice des dons, tel que pouvoir en vivre, la question se pose de pourquoi cette personne et pas une autre. Pourquoi les sous n'iraient pas directement aux fondateurs du projet ? Pourquoi ça n'irait pas à telle autre personne qui, certes, soumet moins fréquemment des patchs, mais résout des problèmes sacrément difficiles ?

Au final toute décision est mauvaise dans un sens ou un autre, alors on dépense les sous pour des à côtés : serveurs, prestas pour un logo, quelques aides pour des conférences, etc. En tout cas rien qui ne sert directement à aider les principaux contributeurs à s'investir sur le projet.

Félicitation encore et encore pour ce beau logiciel. J'ai moins l'occasion de l'utiliser qu'auparavant mais chaque dépêche me donne envie d'y retourner.

Au delà de la qualité du logiciel, j'aime aussi beaucoup l'approche de Jehan sur le développement, la communication, la communauté. Bravo et merci :)

Comme il y a beaucoup de commentaires sur la page pointée, je me permets de mettre en avant cette information issue d'un commentaire : l'index Tiobe est du caca en barre.

Peut-être devrais-je écrire aussi à ma mutuelle pour l'informer, mais ne travaillant pas dans la cybersécurité, je ne me sens pas vraiment légitime (et je n'ai peut-être pas le temps ou l'envie).

Les observations de ton journal sont tout à fait pertinentes, tu devrais leur écrire.

Et si tu as le temps d'écrire un journal comme celui-ci, je pense que tu peux trouver le temps d'écrire un mail ;)

C'est marrant, j'ai récemment adopté la demarche inverse :) Entre des contenus éparpillés ici, sur Medium, sur mon site perso, sur developpez.com, sur gamedev.net, et sur deux blogs disparus, j'en ai eu assez et j'ai décidé de tout rappatrier au même endroit. J'ai pris un nom de domaine et un serveur et je rassemble tout là-bas.

Ça ne sert pas à grand chose mais j'aime bien avoir cette historique qui me rappelle d'où je viens. Et puis si Medium fait une crise de paywall ou si un site meurt, j'aurais toujours mon contenu.

Vidéo intéressante.

On reconnait la team bujo (bullet journal) :-)

Déformation professionnelle :) À force de

• découper des tâches en sous-tâches ;
• dérouler tous les scénarios d'une exécution ;
• décrire chaque étape d'un procédé pour qu'une machine puisse l'exécuter.

J'en viens à :

• souffrir en faisant de longues phrases ;
• peiner à lier les phrases pour en faire un raisonnement logique ;
• abuser des point-virgules comme un gros snob pédant ;
• passer cinq minutes à me demander si mon interlocuteur va interpréter « je recopie ce qui est encore pertinent sur la suivante » comme « je regarde ce qui est pertinent sur la page pleine puis je recopie cela sur la page vierge » ou comme « je regarde ce qui est pertinent sur la page suivante (vierge) puis je recopie cela ». Le deuxième cas n'ayant aucun sens, le lecteur risque de buguer.

C'est pas facile pour tout le monde :)

Je prends aussi beaucoup de notes et je fonctionne beaucoup en checklists. Avant j'utilisais des feuilles de brouillon et j'avais des tonnes de boules de papier froissé dans la poubelle, autour de la poubelle, et sur mon bureau. En plus d'une pile de feuilles volantes avec des vieilles notes au cas où on sait jamais.

Depuis quelques années je suis passé à un combo cahier + stylo ; une technologie éprouvée. J'y trouve beaucoup d'avantages :

• Il n'y a plus de boules de papier froissé autour de moi.
• Ça m'aide à me focaliser. Quand une page est pleine, je fais le bilan des cases non-cochées et soit je m'y atèle, soit je recopie ce qui est encore pertinent sur la suivante. Ainsi tous les trucs qui seraient bien mais là je n'ai pas trop le temps et puis de toute façon il faudrait faire ceci avant disparaissent naturellement.
• Ça fonctionne partout, tout le temps.
• Je ne l'ai pas sur moi quand je sors du cadre du travail.
• C'est pas cher.
• J'imagine que c'est plus écologique.
• De temps en temps je le feuillette pour alimenter la satisfaction du travail accompli.

C'était bloqué pour moi aussi, puis j'ai cliqué sur le bouton « Poursuivre » qui se met sur la vidéo. Ensuite, une fois que la vidéo s'est lancée, j'ai pu faire défiler la page. Oui oui, ça n'a aucun sens.

J'ai mis LineageOS sur mon téléphone, avec l'idée initiale de me passer de Google. Pour l'instant ça ne fonctionne pas trop.

J'ai mis OsmAnd~ pour remplacer Maps et Waze, mais quand je cherche un resto j'en reviens toujours à Maps, qui me permet d'avoir des avis de personnes passées avant moi. Quand je cherche un itinéraire à vélo ou à pied, je suis souvent surpris par la complexité des trajets proposés par OsmAnd~. Les propositions de Maps me semblent plus simples pour la même durée de trajet. Pour les trajets en voiture OsmAnd~ ne prend pas en compte le trafic, du coup je lui préfère encore Waze.

Je n'ai pas encore d'alternative simple à Photos, et je suis un peu embêté à l'idée de devoir transférer des années de photos depuis le service de Google vers un autre. Surtout si l'autre ne me convient pas ou ferme dans quelque mois.

J'arrive un peu à me passer du PlayStore mais surtout parce que je n'installe pas grand chose. Les logiciels de F-Droid sont souvent décevants. On est loin de l'énergie du logiciel libre du desktop. J'ai aussi eu des soucis avec l'appli de ma banque en essayant de l'utiliser sans passer par le PlayStore.

J'ai tenté d'autres agendas mais j'ai fini par remettre celui de Google : partage facile avec les contacts, interface agréable, synchronisation facile. Par exemple les événements où je suis invités s'y affichent directement. Il me semble que ce n'était pas le cas avec les autres, y compris avec la version stock AOSP.

J'utilise encore un peu Drive. Comme pour les photos je n'ai pas trop d'alternative et je crains de me retrouver avec un service qui ne me convient pas ou qui ferme rapidement.

J'ai envisagé d'héberger un NextCloud ou un truc dans le genre pour remplacer Agenda, Drive et Photos, mais l'idée d'administrer un serveur ne m'emballe pas du tout.

Voilà, c'est pas facile. Ça aurait peut-être été plus simple si j'avais commencé sans Google il y a quelques années :)

Chez moi j'ai mis du Grade 3 qui supporte donc du 10 Gbits/s. C'est branché à un bout sur une prise Ethernet murale, et à l'autre bout sur le coffret VDI, qui est lui-même connecté à la box. Cette dernière prend le rôle du routeur.

Pour l'instant je n'ai eu aucun souci avec cette config. Je me branche au mur dans le bureau, à l'autre bout du logement, et ça dépote. Ailleurs j'ai mis un petit routeur wifi sur une prise électrique, branché en Ethernet sur la prise à côté. Ça aussi ça fonctionne très bien :)

Je devrais bientôt ajouter un switch dans le coffret pour pouvoir profiter de plus de prises.

Pour info le câble que j'ai installé est celui-ci : https://www.123elec.com/gaine-prefilee-ftp-grade-3-sat-2200mhz-d20-couronne-de-100m.html

Que penses-tu de cibler archive.org plutôt que de supprimer les liens ?

+1, ça fait tellement longtemps que l'on met la performance au second plan à grand coups de « premature optimization is the root of all evil » qu'on en vient à tout pessimiser. Même en C++ je vois encore plein de std::list là où un std::vector serait mieux, des std::map là où il faudrait utiliser std::unordered_map, des paramètres passés par valeur… Je ne parle même pas de faire des optims algorithmiques ou bas niveau ; juste d'utiliser de meilleurs outils par défaut.

C'est pas mort dillo ? La plupart des liens ne fonctionnent plus sur le site. Pas de source, pas de téléchargements… :(

Le directeur technique : « On va utiliser le framework F pour notre app, ça gère le mobile et apparemment on peut aussi générer un site web, une app native, cibler des smartouatch ou faire du WebAssembly. Avec ça on est futur prouffe ».

Le directeur artistique : « on va utiliser une version personnalisée de PoopFontPro2.ttf pour l'interface, c'est pas mal non ? »

Le dev : « Bon j'ai téléchargé leur truc et réussi à faire un POC en twiquant un peu. Ça a l'air de marcher. J'ai dû convertir la fonte mais il y avait quelques glyphes mal fichus que j'ai dû corriger. ».

Le dev senior : « Non mais quelle usine à gaz ! [insérer une référence à "réinventer la roue"] Laisse-moi une semaine et je te vire ce framework et je refais ça dans 42 octets en [insérer une obscure technologie] ».

Le product owner : « J'ai regardé un peu ce qu'il se fait et avec 45 Mo on est plutôt bien placés par rapport aux autres apps du marché. C'est combien la limite de téléchargement hors wifi dans le store ? 500 Mo ? Bon écoute, niveaux priorisation je préfère que tu intègres Firebase pour qu'on ait un peu de métriques rapidement »

Voilà, même quand tout le monde veut bien faire son travail, ça ne donne pas toujours un produit optimal à la fin :)

Il n'y a pas de souci avec l'auto-promo. L'article est dans les clous thématiquement même si le comparatif m'a l'air tout à fait biaisé.

Juste pour alimenter la discution sur la forme, xkcd a une belle représentation de grosses sommes d'argent à base de carrés :)

je me pose la question de savoir si il y a lien

Si tu veux un lien va plutôt dans la rubrique liens. Ici ce sont plutôt des journaux.

J'arrive un peu tard mais je participe quand même.

Alors, s'il vous plaît, dites moi comment vous faites pour échapper à l'enfer des dépendances.

Sur mes petits projets il y a peu de dépendances et pas de conflit de versions. Je prend donc ce qui est disponible sur le système ou alors je compile et j'installe dans ~/.local/. Pendant un moment je m'embêtais à gérer dans mes CMakeLists.txt la possibilité d'utiliser la version locale ou de télécharger la dépendance via FetchContent. C'était une très mauvaise idée, ça fait plein de cas à gérer et amène trop de questions. Du coup maintenant c'est seulement du local, beaucoup plus simple.

Au boulot on a des tonnes et des tonnes de dépendances. Du coup on fait des RPM pour chaque, et je suis bien content de ne pas m'en occuper. Parmi les trucs qui m'embêtent il y a le problème que lorsqu'on modifie une dépendance il faut refaire les RPMs pour toute la chaîne jusqu'au produit pour pouvoir enfin tester, voir qu'on a oublié un truc, re-patcher la dépendance, et recommencer. L'autre souci est que ça devient tellement gros que ça bloque tout le monde sur une distribution donnée. Du coup si t'es sous Windows, ou sous un Linux non corporate, il te faut une VM Linux, ou un Docker, avec la distrib' officielle pour pouvoir travailler. C'est un vrai frein au quotidien, tous les outils deviennent dépassés hyper vite.

Avant ça dans une autre boîte sur un projet plus petit et une petite équipe j'avais pris une approche à base de script. Pour donner une idée de l'échelle, nous étions trois développeurs au maximum et il y avait une petite quarantaine de dépendances. En gros ça ressemblait à ça :

• Du côté du produit final, on avait un fichier listant les dépendances selon la plate-forme ciblée (Android, iOS, OSX, Linux), et un script qui récupérait les dépendances pour les mettre dans un dossier .local du build. Les dépendances pouvaient être des bibliothèques ou des outils de build (par exemple le SDK Android). Les dépendances étaient récupérées au choix uniquement localement ou alors depuis un bucket S3. Il faut voir le dossier .local comme un / dans lequel les dépendances étaient cherchées par le système de build.
• Pour la construction des dépendances on avait un lot de scripts outils et d'autres scripts qui utilisaient ces outils pour faire des archives prêtes à être consommées par le produit. Certaines dépendances étaient des binaires fournis par divers services (par exemple des .framework de régies pub pour iOS), auquel cas on les rangeait juste dans un dossier pratique dans le faux /. D'autres dépendances étaient compilées, installées dans un dossier temporaire puis archivées pour être prêtes à être mises telles quelles dans le faux /.

Dans les aspects bien pratiques :

• chaque développeur pouvait compiler les dépendances nativement pour son système,
• on pouvait surcharger les dépôts des dépendances pour cibler nos dépôts locaux, et ainsi tester des modifs sur des dépendances sans reboucler par le central,
• le build était isolé, pas autant que dans un Docker ou un fakeroot mais suffisamment pour nous,
• les outils de build faisaient partie des dépendances (on avait besoin que de bash, sed, grep, tar, et un compilateur pour lancer le tout, et encore ce dernier pouvait faire partie des dépendances).

Dans les aspects pas pratiques :

• le code des scripts outils n'étaient pas très accueillants pour ceux qui ne sont pas à l'aise en Bash,
• j'aurais dû faire ça en Python pour que ça fonctionne sous Windows (mais en même temps ça demande d'avoir un Python d'installé et on revient au problème du journal ; et puis personne n'utilisait du Windows),
• on a eu quelques mauvaises surprises de link en utilisant sur un système des dépendances compilées sur un autre système,
• je suis quasi sûr que ça ne scale pas avec de plus grandes équipes ou plus de dépendances.

De mon côté je n'ai jamais utilisé Conan ou vcpkg et je me demande si ces outils auraient permis d'installer des dépendances d'outils de build telles que le SDK Android ou autres outils. Ou encore de construire les dépendances à partir de dépôts locaux. Concernant l'intégration dans les outils de build, je ne vois pas trop comment on pourrait par exemple lancer CMake en ciblant Android tout en essayant de récupérer le SDK via Conan intégré à CMake. Ça se mort la queue. Pour moi l'installation des dépendances se fait forcément en amont de la configuration du build. Donc forcément il y a un peu de scripting.

Quel type de machine faut-il pour émuler des jeux Wii U ?

À titre tout à fait personnel ça me donne envi de privilégier rust partout où c'est possible, je sais que ça irrite les développeurs C++, mais si rust c'est des perfs sans pour autant sacrifier à la fiabilité, ça conviendra plus à mes aspirations.

Pas de souci avec le Rust, c'est un super langage qui résout des problèmes du c++ et ne se traîne pas des décennies d'historique :)

Je veux bien voir un bench réaliste qui montrerais l'impact réel de ce genre de trucs.

Que je sache il n'y a pas de tel benchmark, simplement parce qu'on parle d'un coût faible qui ne ressort que lorsqu'on regarde une appli dans son ensemble. Le profiler ne pointera jamais tous les ifs éparpillés dans l'app, mais ça ne veut pas dire que leur coût est négligeable.

Pour moi il y a deux mondes : les logiciels pleins de « on ne sait jamais », « ça sera future proof », « ça coûte moins cher d'acheter une machine plus puissante » ; qui sont la raison pour laquelle on trouve que les ordis d'aujourd'hui prennent plus de temps à faire des choses simples que les ordis d'hier, et de l'autre côté un monde où on ne fait pas ce qui n'est pas essentiel, où on ne s'engage que pour certains cas d'utilisation, et qui tire fortement profit de la puissance des machines.

Du coup en release ta fonction est UB avec une collection vide ? :|

C'est l'idée oui :)

L'UB n'est pas qu'une mauvaise chose, ça veut juste dire que la fonction à un périmètre limité. Il y a plein de situations en UB et on ne met pas des verifications pour tout : le débordement d'un signed int, la comparaison d'itérateurs provenant d'instances de conteneurs différents…

L'assert est très bien pour documenter ces cas et pour servir de garde fou pendant le développement.

Moi je trouve très bien que des boîtes comme Google partagent leurs règles de codage, surtout quand les choix sont justifiés. Sur le plan éthique j'aurais des choses à redire de Google ou Facebook mais sur le plan technique ils ont plus à nous apprendre que l'inverse.

Je me suis d'ailleurs parfois appuyé sur eux (et sur Linux, Mozilla et d'autres) pour justifier certains choix pour lesquels tout le monde a un avis. Puisqu'on ne peut tomber d'accord en interne on va faire comme les autres, et celui qui n'est pas d'accord se charge d'écrire à Mozilla/Google/autre pour leur expliquer qu'ils se débrouillent mal. Ça n'a pas toujours été la solution qui m'arrangeait mais ça permet de débloquer les discussions.

Je sais bien que c'est bien confortable pour eux puisque du coup c'est le reste du monde qui s'adapte à leurs pratiques. Ça leur fait toujours ça de moins à expliquer aux nouvelles recrues. Mais ce n'est pas une bonne raison pour ne pas écouter ce qu'ils ont à dire.

Pour moi les questions à se poser concernant n'importe quelle pratique sont :

• pourquoi les pros font comme ils font ?
• qu'est-ce que ça donnerait à mon échelle ?
• qu'est-ce que ça va me coûter si je change d'échelle ?

Concernant les exceptions en particulier, j'ai vu tellement de cochonneries où elles traversaient justement plusieurs couches et qu'on ne pouvait de toute façon rien en faire, ou, pire, elles étaient lancées et rattrapées dans la même fonction, que je préfère éviter autant que possible. Ce n'est pas une question de perfs, c'est une question d'éviter le bazar et d'éviter le cas du fainéant qui va passer l'erreur à son voisin plutôt que de la gérer lui-même. En fait je me demande si les exceptions ne seraient pas le pire mécanisme de gestion d'erreur qui soit.

Je préfère largement quelqu'un qui ne veut pas mettre d'exception juste parce que Google a dit de ne pas le faire plutôt que quelqu'un qui en met systématiquement parce que son prof, qui n'a jamais écrit que du code confidentiel, lui a présenté ça comme une bonne manière de faire.

Du coup pour un max dans une collection, puisque la solution du max_element est exclue, je mets en précondition que la collection ne soit pas vide. C'est l'appelant qui doit gérer sous peine de comportement indéfini, et comme je suis cool je mets quand même un assert en debug :)