small_duck a écrit 139 commentaires

C'est au Royaume-Uni. Ce n'est pas énorme, je crois, peut-être 1 heure par semaine ?

Le langage Python est enseigné en tronc commun à partir de l'équivalent de la 6ème, avec un petit peu d'algorithmique avec les chaînes de caractères. Il y a ensuite divers clubs d'info et de robotique - Clairement, certains étudiants étaient des passionnés avec de l'expérience acquise à la maison, tandis que d'autres étaient venus les mains dans les poches.

Peut-être suis-je particulièrement sensible à cette problématique car j'ai travaillé de nuit étant étudiant, et après 36 heures debout, je me sentais vraiment défoncé et c'était une sensation que je trouvais particulièrement désagréable et qui est probablement assez néfaste pour la santé.

Maintenant, comme je le souligne, ils n'ont obligé personne. Peut-être d'ailleurs que l'étudiant malin qui est allé pioncer 6 heures et est revenu frais comme une rose et a codé comme un prince toute la matinée a finalement obtenu de meilleurs résultats ? J'aimerais à le penser.

C'est posté !

Merci, je vais creuser tout ça.

Ton pixel art est magnifique ! Quelle est ta technique ?

Signé : un programmeur qui aimerait se libérer du programmer's art

Mais ça roxxe du poney, eglot ! En effet, c’est plutôt léger et ça marche presque tout seul, à travers Tramp, et j’ai en plus de la recherche plutôt bien fichue les alertes clang et les annotations de paramètres. L’essayer c’est l’adopter.

Ça fait très plaisir, merci à l'équipe LinuxFR !

Je zieute depuis longtemps vers les Arduino, avec pour but de me construire un panneau de contrôle de pilote automatique pour la simulation aérienne. En gros, une manette de jeux fait maison, avec les poussoirs et les boutons rotatifs qui vont bien. Avec d'une part un kit Arduino sur ma liste au père Noël, et d'autre part ce bouquin qui a l'air de coller exactement à ce que je voudrais faire, je vais avoir un début d'année chargé ! Je tiendra évidemment les moules au courant.

Alors, histoire d'avoir vraiment tout faux, j'avais carrément viré les images de mon disque ! Je les ai récupérées grâce à archive.org, et téléversées à nouveau. Sauf que les images ne sont pas revenues dans les articles.

En regardant le source, je vois par exemple <p><img src="//img.linuxfr.org/img/68747470733a2f2f746563686e6f747572746c652e6e65742f696d616765732f677261706865312e706e67/graphe1.png" alt="Graphe de scene" title="Source : https://technoturtle.net/images/graphe1.png"></p>, donc manifestement ça pointe vers img.linuxfr.org, mais peut-être comme un cache qui se remet à jour régulièrement avec la source ?

Argh, je suis un boulet, j’étais persuadé que LinuxFr copiait les images et je les ai virées de mon site. Je remet ça ce soir !

J'aurais envie de dire, avec un OpenGL de base et les options fil de fer glPolygonMode(GL_FRONT_AND_BACK, GL_LINE) et de face culling (par défaut à ma connaissance). Ou alors, si le C++ est une option, carrément avec OpenSceneGraph et le PolygonMode qui va bien.

Après, peut-être est-ce qu'il y a mieux ?

Merci pour ces précisions. J’ai également omis le rendu par voxel, utilisé par exemple par le jeu d’hélico Comanche, qui permettait de rendre de très beaux paysages et qui restait du ray casting. Technologie qui a été en grande partie abandonnée faute de support matériel.

Merci pour cette conversation très enrichissante, j'en tire d'une part que nombreux sont ceux pour qui ces principes fonctionnent, et je vais tenter d'y être plus réceptif. J'y vois d'autre part la confirmation que les 12 facteurs s'appliquent plus particulièrement au monde des micro-services, et qu'il faut raison garder dans leur application à d'autres types d'applications.

Bisous à tous et à bientôt pour un autre journal qui dénonce grave !

Merci de cette explication détaillée. En effet, certains points sont parfaitement raisonnables - Le 9 par exemple, je ne vois personne qui disent que ça doit prendre des plombes à démarrer et à s'éteindre !

En revanche, sur d'autres, j'ai encore du mal : le coup des variables d'environnement, je trouve ça très implicite, pas facile du tout à découvrir, et sujet aux erreurs (typos?). Je préfère de loin une application qui prend en ligne de commande quelques éléments de base, comme un chemin vers un ou plusieurs fichiers de config, un --verbose, et autres. Comme ça, un --help indique immédiatement tout ce que je dois passer à l'app et tout ce que je peux faire avec. Et à ma connaissance, ça marche avec tous les langages, et tous les systèmes de déploiement que je connaisse (configmap K8 par exemple).

Bon, admettons: j'ai un monorepo, qui contient mes 3 libs et mes 25 binaires, je fais un changement de lib, revue de code, fusion, ça part dans le package manager, puis je mets à jour les dépendances de mes binaires en un coup (puisque monorepo), revue de code, fusion. J'ai donc réduit de 26 fusions à 2, ce qui est vachement mieux !

À voir à l'usage, donc. J'ai vraiment cette habitude de compiler tout mon système d'un coup, et de monter et descendre dans mes dépendances dans tous les sens pour ajuster mon code. Encore du mal à vraiment voir ce que ça m'apporte de séparer plus.

---

Effectivement, dans le problème initial que je présente, la solution eut été que SystemD s'en occupe, mais apparemment la version que nous utilisons ne le permet pas. Dans le cas de pods, je comprends l'idée de dire que c'est à kubernetes de balancer les logs là où il faut, et sur le principe, j'aime bien, parce que partir à la chasse du bon fichier de log, c'est plutôt lourd. Mais peut-être que Elk / ElasticSearch ne sont pas encore à la hauteur.

En début de semaine, j'ai du sortir l'équivalent d'une liste d'utilisateurs connectés, pour un besoin ponctuel. Bah, j'avais un beau fichier de log, grep | sed | sort -u, directement vers un fichier que je peux envoyer à qui le voulait. Avec ElasticSearch, c'est possible?

Bref - Y'a de l'idée, mais j'ai pas l'impression que ça soit encore ça…

Merci de ta réponse !

Alors, 1 repo pour 1 app, c'est un truc qui me semble super sur le papier, mais je ne vois pas comment le faire fonctionner efficacement passé une certaine complexité. Les systèmes avec lesquels je travaille ont typiquement des dizaines d'applications. Une moitié sont des applications de type "service", et l'autre moitié de type "outil console" pour contrôler ou requêter les services. Chaque application est typiquement très petite, et dépend de 3 ou 4 grosses bibliothèques avec beaucoup de fonctionnalités communes. Est-ce donc qu'il me faut un dépôt par bibliothèque, et 25 dépôts supplémentaires pour chaque application ?

En fait, c'est là que je ne comprends plus. Par exemple, je change une API dans ma bibliothèque, faut-il que je déploie ma bibliothèque (tests, revue de code, fusion…), puis que j'aille dans chacun des 25 dépôts pour vérifier si ça compile, faire les changements, et faire 25 déploiements (tests, revue de code, fusion…) ? Et rebelotte si je me suis vautré au début ? Je ne comprends absolument pas en quoi séparer les dépôts aide à quoi que ce soit.

Mais j'aimerais savoir si il existe un meilleur modèle, parce que sur le principe, un peu de modularité dans mon monorepo, j'aime bien, avec principalement l'idée de réduire le temps de compilation / test.

Ensuite, sur les logs, en effet, dans un cloud Kubernetes, je suis d'accord : c'est logique de sortir les logs sur la sortie standard, et de laisser Kubernetes balancer tout ça vers un Elastic Search ou équivalent. Mais… Elastic Search, que c'est lent ! C'est pratique pour trouver des lignes de log corrélées entre plusieurs applications, mais pour explorer un simple fichier, j'ai du mal à trouver quelque chose d'aussi efficace que tail / grep / sed. Je me demande d'ailleurs si il serait possible d'avoir un volume NFS rien que pour les logs, et d'avoir l'application qui monte ce volume et qui logge dessus, afin de pouvoir taper dedans plus facilement ?

Bref, je cherche encore, et je suis preneur de conseils.

Sympa, merci ! En ce qui me concerne, ce sont des adresses au Royaume-(des)uni. On dirait qu'ils ont un équivalent, même si ça semble un peu plus complexe d'accès à priori.

Vi, mais là on a une nimage avec les noms et adresses de personnages âgées vulnérables, et j'ai vraiment la flemme de flouter ce qui doit être flouté…

Ce que je comprends du zero cost abstraction, c'est que ce n'est pas plus cher que de passer le type plus le booléen, ce qui est déjà vachement bien. Mais il faut quand même passer le booléen, donc à moins d'inliner, il y a un coût. Méfiance également car c'est un coup à faire des copies là où des move seraient passés crème.

Après, c'est un type extrêmement bien fichu, et j'ai dignement fêté son arrivée dans C++17 (en remplaçant partout dans dans mon code son ancêtre de chez Boost).

L'approche par itérateurs de la bibliothèque standard permet de gérer très élégamment le problème des cas particuliers, c'est impeccable et permet effectivement un grand contrôle: lancer une exception, retourner un optionnel, renvoyer une valeur par défaut…

Mais dans ma question d'entretien, l'on demande expressément à renvoyer "le plus grand élément", pas un itérateur. Or, mathématiquement, le plus grand élément d'un ensemble vide, ça n'a pas de sens. Donc, renvoyer une exception est raisonnable.

Renvoyer un optionnel, par exemple, va m'empêcher de chaîner les appels, et va me forcer à écrire beaucoup de boilerplate moche, à moins de n'avoir que des optionnels partout (bonjour la complexité pour vérifier chaque optionnel au début de chaque fonction, sans compter l'impact sur les perfs).

Maintenant, le candidat qui me dit que cela dépend de la manière dont l'équipe a décidé de gérer les erreurs, et qui peut vraiment comparer les avantages et les inconvénients des différentes méthodes, je suis ravi ! C'est quelqu'un qui réfléchit, et qui s'adapte au contexte du problème.

Je te rejoins sur cette histoire de 0.1% qui me semble bien trop élevé. Je fais régulièrement tourner gdb avec un "catch throw" dans nos binaires, et je vois bien que dans les faits, quand tout se passe bien, l'on ne jette pas une seule exception, ou alors à la rigueur à l'initialisation parce qu'il y a toujours des choses à jeter dans nos jeux de données. En revanche, quand ça se passe mal, on nettoie tout bien, on a de belles erreurs à peu près claires, et l'on peut continuer le traitement.

Je pense que c'est exactement ce pourquoi Google n'utilise pas les exceptions, et c'est leur strict le plus droit (du moment qu'ils n'embêtent pas les autres avec). Écrire du code "exception safe", ça veut effectivement dire de pleinement utiliser RAII et de ne jamais être en position d'avoir une fuite mémoire, de ressource, de transaction… Difficile à rétrofitter, donc. Mais quand le code est écrit avec les exceptions en tête, c'est toute une classe de problèmes qui disparaît. Et le code est généralement plus dense et lisible, la gestion des erreurs aux étages qui n'en tamponnent est complètement transparente.

J'aime beaucoup le defer, mais j'aime aussi beaucoup le unique_ptr, et je le préfère pour gérer la création et la destruction de ressources à travers des API C, comme pour SDL, justement.

  std::unique_ptr<SDL_Window, decltype(&SDL_DestroyWindow)>
    window(SDL_CreateWindow("Viewer",
                            SDL_WINDOWPOS_UNDEFINED,
                            SDL_WINDOWPOS_UNDEFINED,
                            1280,
                            1024,
                            0),
           &SDL_DestroyWindow);

est pour moi plus clair et plus sûr, car dans la même commande on gère à la fois la création de la ressource, et on prépare sa destruction. Et impossible de s'emmêler les pinceaux et de détruire la mauvaise ressource. Cerise sur le compilo, il est même possible d'utiliser le std::move et donc d'expliciter un transfert de la ressource.

Je vois donc le defer comme un plan B, lorsque la sémantique est différente: afficher un message de log en fin de fonction, par exemple, ou encore aller écrire un fichier.

Notons que ce dernier cas est assez mal géré par la RAII au cas où l'opération jette une exception (je n'entre pas dans les détails, mais en gros lancer une exception depuis un destructeur, c'est le mal). Ici, le defer nous donne une opportunité pour gérer ce cas d'erreur plus proprement.

La Mère Zaclys est mon amie ! J'aurais un peu les foies d'administrer un NextCloud, je laisse faire les (et je donne des sous aux) pros :)

Je confirme, ça ne marche pas partout, parfois je dois revenir au Ctrl-C / Ctrl-V, par exemple quand je veux copier quelque chose depuis la console vers Emacs. Je n'ai jamais trop creusé la logique, il y a probablement moyen de mieux configurer ça.

Cela fait presque 15 ans que j'utilise quotidiennement, au turbin et à la maison, un Typematrix Dvorak (au niveau du clavier) avec US-International (au niveau de l'OS). J'ai fait la transition depuis Azerty (à la maison) et Qwerty (au turbin): j'ai commandé deux claviers d'un coup, et j'ai passé quelques semaines à me réhabituer. Le processus était très intéressant, sentir mon cerveau se reprogrammer doucement et acquérir les nouveaux automatismes. L'avantage principal fut la disparition des douleurs au poignet, et la capacité d'aller chercher les accents via la disposition US-International.

À l'époque, Bépo n'était pas encore très connu, et Typematrix ne fournissait pas la disposition, il aurait donc fallu taper à l'aveugle ou ajouter soi-même les étiquettes.

À l'usage, cette disposition fonctionne très bien. Bien sûr, tout un tas de raccourcis claviers deviennent bizarres, en particulier dans Emacs où sauver / quitter pouvait se faire d'une main et requiert maintenant les deux. On peut changer les raccourcis, mais j'ai préféré ne rien changer et tout faire avec les deux mains.

Niveau code, alors oui, il faut aller chercher certains caractères un peu plus loin, en particulier l'apostrophe et guillemets, à cause de l'US-International: Shift + guillemets + barre espace. Mais c'est maintenant pour moi un automatisme, et je ne pense pas que cela me ralentit (surtout comparé aux collègues qui tapent avec 2 doigts…).

Les copier/coller ont leurs propres touches sur Typematrix, donc pas de soucis de ce côté là.