Julien Jorge a écrit 589 commentaires

Tu as des SDKs qui embarquent plusieurs sous régies pub pour faire de la médiation mais tu peux aussi faire de la médiation directement dans ton app. Par exemple tu demandes une pub à AdMob et en même temps t'en demandes une à Criteo, puis tu affiches celle qui te rapporte le plus. Tu peux aussi avoir un deal avec une régie en particulier et la solliciter directement.

Ça fait longtemps que je n'ai pas utilisé tout ça mais dans mes souvenirs ça donne un truc du genre :

• Adjust : top pour suivre les installations et tracer l'origine. Par exemple savoir que l'installation a été faite suite au clic dans une pub sur telle plate-forme. Avec ça tu peux voir lesquelles de tes campagnes de pubs sont les plus efficaces.
• Amplitude, Facebook Analytics, Google Firebase Analytics : de l'analyse. Par exemple savoir combien de temps les gens restent dans l'app, à quelle fréquence ils l'ouvrent, dans quels menus ils vont, etc. Tu voudras sûrement en mettre plusieurs pour croiser les mesures et confirmer que le service ne délire pas trop. Pour Facebook Analytics et Firebase tu dois pouvoir croiser les infos avec les campagnes de pub que tu fais sur lesdites plates-formes. À l'époque où je l'utilisais Firebase était le top du top, avec beaucoup d'excellents services en plus d'Analytics.
• Criteo, Facebook Ads, Google AdMob : régies publicitaires. Besoin d'une bannière pour encombrer l'écran ? D'une vidéo entre deux écrans ou pour faire gagner de la monnaie virtuelle ? Ils sont là.
• Facebook Login : s'identifier avec son compte Facebook. Tu peux t'en servir pour que tes utilisateurs retrouvent leur profil d'un appareil à l'autre par exemple.
• Google CrashLytics : remontée de stack traces et autres soucis. Essentiel pour savoir si ton app fonctionne bien en conditions réelles.

Le reste je ne connais pas mais je suppose que c'est du même acabit. Derrière tout ça il y a beaucoup de services utiles pour les devs et les utilisateurs, à part les pubs bien sûr :) Malheureusement il y a l'effet de bord habituel : profiling d'utilisateur, suivi, ciblage publicitaire, surveillance, etc. Après pour un développeur c'est difficile de s'en passer et je ne connais pas d'alternatives éthiques pour répondre à des questions telles que « mon app est-elle utilisée ? Par combien de gens ? Pendant combien de temps ? Rencontrent-ils des problèmes ? Ma campagne d'acquisition a-t-elle porté ses fruits ? etc. »

Tiens je m'auto link sur le sujet, comme un gros narcissique.

L'alternative ce sont des gens qui participent activement et publient des contenus substantiels. Là on a quelqu'un qui n'a jamais rien publié sur LinuxFR et qui, clairement, se fiche pas mal de la communauté à laquelle il s'adresse pour diffuser son communiqué de presse.

Bof, avant de participer activement et publier des contenus substantiels il faut bien commencer par quelque chose, et comme dans tous les domaines le premier essai est souvent mauvais.

Les commentaires sont là si tu veux poser des questions afin d'avoir plus de détails sur le produit. Après est-ce que l'auteur se donnera la peine d'y répondre alors qu'il s'est fait rejeter sous prétexte qu'après trois jours il n'a toujours pas l'expérience d'un contributeur à LinuxFr.org doté de 20 ans de pratique ? C'est pas dit.

Pareil ici, on a un abonnement Famileo et la grand-mère qui les reçoit aime beaucoup. Il y a des photos et des articles, plus ou moins longs.

On avait tenté un truc similaire chez moi mais bien plus DIY. Pendant un an nous avons écrit un petit journal de 4 à 6 pages, tous les mois, avec quelques photos et beaucoup de mots (environ 3000 mots par article si je me souviens bien). Nous faisions ça avec Scribus, sortions un PDF, et nous envoyions le fichiers à nos proches. Il y avait quelques membres de la famille partis à l'étranger, ou un peu isolés ; pour eux nous imprimions le journal et ils le recevaient par voie postale.

Il y avait plein de côtés positifs à tout ça. Déjà ça faisait plaisir à tout le monde d'avoir des nouvelles de la famille. Ceux qui le recevaient par la poste était contents d'avoir un petit journal tous les mois. De notre côté c'était sympa de toucher du doigt le métier de maquettiste, et ça nous a un peu forcé à documenter notre vie, à prendre des photos. C'est amusant de voir a posteriori que, finalement, il se passe plein de choses dans nos vies même si ce ne sont pas de grands événements exceptionnels. Il fallait juste savoir regarder :) Par exemple : une simple promenade, ce n'est pas une chose sur laquelle nous nous étalerions en discutant au téléphone, ou par messagerie, mais dès lors qu'on a la démarche de prendre des photos et des notes, finalement ça fait une histoire sympathique à partager. En bonus, nous avions commencé le journal en décembre 2019, donc dans un an d'écrits, si tu fais le calcul, nous avons bien documenté tout notre confinement.

Côté négatif, il n'y en a qu'un seul : c'est beaucoup, beaucoup, de boulot !

La modération est partagée, cf. le commentaire d'Ysabeau plus haut pour des explications.

La modération est partagée, cf le commentaire d'Ysabeau ci-dessus. Nous comptons beaucoup sur le moinsage.

Personnellement je n'arrive pas à comprendre comment les utilisateurs du site peuvent encore laisser autant de commentaires sur ces journaux. On a des journaux super bien notés avec zéro ou un commentaire, mais quand quelqu'un vient poser sa bouse au milieu de la place ça rameute tout le monde ; c'est dingue.

La meilleure réponse à ces journaux en l'état actuel de la modération est de moinser, passer son chemin, poster un meilleur journal. Ça aidera à évacuer tout ça :)

Du coup je plusseois. Ici on a l'abonnement à mon petit quotidien ; nous nous étions orienté vers ce journal car l'enfant se plaignait d'être à la ramasse dans les discussions de la cour d'école. Le journal lui a beaucoup plu. Quelques numéros sont marqués comme « difficile » et un message invite l'enfant à le lire avec ses parents. L'enfant ne cessant de grandir nous sommes passé à Mon quotidien, qui lui plaît bien aussi.

Du coup.

Quand une compagnie vous vend un produit rendu volontairement défectueux, n'a-t-on donc aucune loi qui puisse la faire condamner ?

Ces fabricants t'expliqueront sans sourciller que tout cela fait partie d'une politique assurance qualité du plus haut niveau pour le grand bien de tous. Tu comprends, on ne peut pas garantir la qualité de la maintenance faite par [insérer prestataire], et vu les bas prix qu'ils proposent on ne peut que douter de la qualité du service. Nous, chez Good Corp., nous mettons un point d'honneur à assurer une maintenance du meilleur niveau, et pour cela nous devons maîtriser toute la chaîne. Nous avons même intégré des pannes aléatoires sur le modèle Chaos Monkeys qui a déjà fait ses preuves.

Alors certes c'est plus cher, mais tu ne voudrais pas qu'un défaut de maintenance fasse dérailler un train et tue des milliards de passager, si ?

Merci pour ce journal très intéressant et bravo pour ce beau rapport de bug bien clair. C'est un bel exemple :)

J'apprécie la simplicité de la correction aussi et j'apprends au passage que les tests unitaires de systemd sont de simples script Bash. Pas de framework ou autre dépendance, ça marchait hier et ça marchera demain.

Un problème avec devnewton aujourd'hui ? Je te trouve un poil agressif, et quand je vois, plus bas, que toi même tu ne sais plus trop ce que tu lui reproches, je crois que c'est le signe d'une pause nécessaire :)

Je sais bien que les liens et les journaux peuvent être en dehors de la ligne éditoriale mais là c'est tellement hors-sujet que je ne comprends même pas comment ça a pu finir ici.

J'ai aussi rencontré le problème, des lignes interminables et des diffs illisibles même en plein écran en enlevant toutes les fioritures autour. J'ai aussi l'impression que les devs qui codent ainsi passent proportionnellement trop peu de temps à lire le code des autres, et la réaction est toujours là même : change d'outil, achète un écran plus grand, et autres variantes du « chez moi ça marche ». Toujours plus de dépendances et de ressources, il n'y a personne pour pousser vers un environnement de dev plus léger :(

Ça manque d'une petite présence sur f-droid :)

An email is essentially just an HTML document

-_-

L'article parle de mise en page dans les e-mails via HTML et CSS. Il s'avère que ça ne marche pas très bien parce que les clients mails ne sont pas des navigateurs. Cela étant dit, les e-mails en HTML qui tentent une mise en page sont des plaquettes publicitaires. Est-ce que ça m'embête que ça ne s'affiche pas correctement ? Bien sûr que non :)

L'auteur de l'article semble travailler chez https://oblik.studio/. Je vous invite à visiter le site sur un ordi et à passer votre souris sur la page. Le comportement est amusant, surtout quand on vient de lire dans l'article que « Most email clients […] live 20 years in the past ».

Merci, je vais essayer :)

J'ai mis un bépo sur mon téléphone mais j'ai l'impression que même une fois que je serai habitué au layout ça ne sera pas aussi efficace que sur l'ordi. Je me retrouve souvent à utiliser un seul côté du clavier, ce qui fonctionne bien quand on a tous les doigts sur le clavier mais pas quand on n'y met que deux pouces.

C'est un peu le problème avec cette tendance à vouloir tout réécrire. Une fois passée la hype il n'y a plus grand monde. En attendant, GNU ls est toujours maintenu 30 ans après :)

Le compilateur n'a aucune obligation de conserver l'ordre des variables locales ou globales.

J'allais le dire ! La direction de la pile n'est pas spécifiée dans le standard si je me souviens bien. En plus des arguments que tu as listé.

Mais ce int* const b non initialisé m'embête. Je suis surpris que ça compile.

a est un entier de valeur indéterminée.
b est un pointeur constant vers un entier, l'adresse pointée est, heu…, indéterminée mais fixe ?
c est, heu…, un tableau de 10 pointeurs non initialisés de fonctions sans paramètres qui retournent un pointeur vers un entier.
d est un tableau de deux pointeurs sur entiers, le premier est l'adresse de a et le second est null.

J'ai bon ? C'est pas facile de tête sur téléphone en vacances :)

Idem, ça me manque aussi. Ça m'a beaucoup motivé à écrire sur des sujets qui m'intéressaient, ce qui par effet de bord m'a obligé à creuser ces sujets et donc à m'améliorer. Maintenant même de simples blogs ont des bandeaux cookies ou des overlays pour s'inscrire à une newsletter. C'est nul.

Oui, ça ne change pas la taille de mon binaire. J'imagine que CMake a déjà émis une commande similaire. Par contre ça fait une recherche surprenante quand on oublie le tiret.

J'ai testé sur une machine plus récente, avec de plus gros caches (sauf L1, celui là ne grossi pas d'une génération à l'autre) et le problème était toujours présent :) Pas de tests sur un AMD par contre.

Il me semble que la LTO à l'époque de GCC 4.8, c'était pas extraordinaire.

Je ne suis pas allé dans les détails mais en réalité j'utilise ICC 18, qui s'appuie sur le GCC du système pour la lib standard, en l'occurrence GCC 4.8. Par conséquent c'est ICC qui s'occupe du LTO. J'ai testé dans un autre cadre avec des compilateurs plus récents (GCC 11, Clang 7, ICX 22, ICC 22) et ils donnent tous de meilleurs résultats, sauf ICC 22 !

Est-ce que tu utilises function-sections, data-sections et gc-sections pour découper les fichiers .o en sections séparées et supprimer les sections inutiles?

Pas encore ! J'aimerais bien tester mais avec un compilateur récent. Tant que la boîte ne fait pas la transition c'est pas très motivant d'aller fouiller dans les options des compilateurs.

Faut-il répondre à un journal déjà noté -15 en écrivant un autre journal ?

Non.

Perso j'ai convergé vers CMake + Ninja + Ccache + Bash. Le premier s'améliore sans cesse et répond à quasiment tous les cas. Pour le second j'ai une légère préférence par rapport à make car il ne flood pas mon terminal, et je peux utiliser ninjatracing avec. Le troisième me rend la vie plus agréable quand je passe d'une branche à l'autre.

Et puis il y a Bash pour tout le reste. Par exemple, Ccache a beau être très efficace il ne gère pas le link, donc j'en viens souvent à mettre en place un petit cache de binaires pour les dépendances ou pour des builds complets. Par exemple au boulot sur la CI on se compare à une branche de référence. Le fait de conserver les artefacts de build et de les restaurer plutôt que de recompiler ladite branche fait gagner environ 15 minutes (sur 15) pour les builds suivants. Sur un projet perso j'ai le même genre de choses pour les dépendances.

De même pour les 50 options CMake des multiples variantes de build. Plutôt que de configurer ça à la main je fais un petit script que je lance avec l'option qui va bien pour lancer la config qui correspond ; par exemple ./setup.sh --build-type tsan configure le projet en debug, active ThreadSanitizer, et lance le build. Ça n'empêche pas d'utiliser CMake pour les intégrateur mais pour mon quotidien ça simplifie bien la vie.

Ah cool un journal de serge_sans_paille, je vais apprendre des trucs.

Merci pour ce super journal qui me fait découvrir un nouvel outil :) Mais tu oublies de nous parler d'un autre moyen d'éviter le conflit de noms à l'édition des liens : utiliser le mot clé static. Et oui, ainsi la fonction aura la visibilité hidden dans chaque unité de compilation qui inclut l'entête et pour peu qu'il n'y ait pas de problème de gardes d'inclusions ça devrait passer.

Bon évidemment il ne faut pas faire cela. Déjà parce que sémantiquement c'est tordu, et aussi parce qu'on passe pour un débutant qui débarque d'un de ces langages ésotériques où la déclaration et la définition sont dans le même fichier. Mais surtout, il faut éviter d'implémenter les fonctions dans les entêtes parce que ça crée du couplage entre l'implémentation de la fonction et le code qui inclut l'entête ; et y'en a ras la casquette de recompiler la terre entière dès qu'on touche à un entête, non mais, hein !

À part ça je regardais le style-check.yml de xsimd et puisque j'en suis à donner mon avis alors que personne ne le demande, je vais vous dire deux choses les enfants : Premièrement, n'écoutez pas les inconnus qui affirment des trucs sur Internet. Deuxièmement : les étapes de votre CI doivent être lançables par les devs sur leurs machines. Ici on a un bon exemple puisque l'étape qui vérifie l'oubli d'inline dans les entêtes consiste à lancer un script bash dispo dans le dépôt. Je suis plus mitigé pour le clang-format qui lance une action GitHub tirée d'un autre dépôt ; impossible de lancer ça simplement en local. Quant à cross.yml et ses commandes shell qui s'étalent sur 40 lignes… bien malheureux celui qui aura à reproduire le build sur sa machine. À mon humble avis, ces 40 lignes devraient plutôt ressembler à sh ./test/cross-compile.sh --compiler ${matrix.sys.compiler} --compiler-version {matrix.sys.version} …

Pourquoi faut-il sortir les scripts des fichiers de config de la CI vous demandez-vous?

Déjà comme on vient de le voir, pour que les développeurs puissent lancer les tâches sur leur machines de développement. Pourquoi attendre d'avoir poussé sa branche, lancé la CI, construit 50 images Docker, exécuté 30 étapes de configs, pour au final apprendre que le fichier foo.cpp n'est pas bien formaté ; alors qu'on peut avoir l'info lors du commit en configurant une hook Git qui lance exactement le même script que la CI ? C'est une perte de temps pour les devs.

D'autre part, vous souvenez-vous de Jenkins ? De Travis-CI ? Des autres outils de CI qui promettaient une config déclarative hyper simple ? Peu importe :) La CI ça va ça vient, et c'est bien dommage de lier ses tests avec une CI donnée. Que va-t-il se passer quand Elon Musk achètera GitHub et que tout le monde partira sur GitLab ? Il faudra encore réécrire tous ces fichiers de config. Adieu l'action clang-format, adieu cross.yml, il faut trouver autre chose. Mais on peut faire mieux ! Si tous ces tests étaient dans des scripts, ça marcherait partout ; et la config de la CI ne serait qu'une légère couche pour faire la glu entre les deux.

Bon j'ai l'air d'un vieux râleur mais franchement merci pour ce journal, je suis impatient de lire les suivants :)

Moi ça me gêne un peu d'affirmer que c'est quelque chose qui n'est visiblement pas représenté. Je suis d'accord sur le fait que le café passe bien pour le grand public mais dès lors que l'on dit que c'est autre chose, les possibilités sont infinies. Pourquoi de l'alcool plutôt qu'un autre stupéfiant ?

En fait je crois que c'est tout l'intérêt d'utiliser un truc commun ou ambigu : ça en dit autant sur l'auteur que sur le spectateur. Au final ce qu'on y voit est un bout de réponse à la question : si moi spectateur je me trouvais dans un tel état de tristesse, vers quel échappatoire me dirigerais-je ? Alcool, drogues, travail, isolement… Les possibilités ne manquent pas.