URL: https://linuxfr.org/news/moi-expert-c-j-abandonne-le-c Title: Moi, expert C++, j’abandonne le C++ Authors: Oliver Ysabeau đŸ§¶, Davy Defaud, ZeroHeure, palm123, Nicolas Casanova, Pierre Jarillon et BenoĂźt Sibaud Date: 2019ćčŽ06月03æ—„T19:30:34+02:00 License: CC By-SA Tags: c++ et c++17 Score: 54 Ma carriĂšre professionnelle de dĂ©veloppeur C a dĂ©butĂ© en 1994 et j’ai naturellement adoptĂ© avec enthousiasme le C++ en 1999. J’étais un dĂ©veloppeur C++ heureux et j’avais considĂ©rĂ© la nouvelle version du standard C++11 juste comme une Ă©volution tant attendue. En 2015, je rĂ©alise enfin Ă  quel point, il a rĂ©volutionnĂ© l’écosystĂšme C++ et ses bouleversements dans l’état d’esprit de la communautĂ©. Je me passionne alors pour C++11, C++14, puis C++17, je m’implique beaucoup, je deviens un rĂ©fĂ©rent pour mes collĂšgues, je donne des confĂ©rences sur ce langage, j’organise des _meet‐ups_ Ă  Paris, je publie de nombreux articles C++ sur _LinuxFr.org_... En 2018, une expĂ©rience change radicalement ma façon d’apprĂ©hender le dĂ©veloppement logiciel. ---- [Journal Ă  l’origine de la dĂ©pĂȘche](https://linuxfr.org/users/oliver_h/journaux/moi-expert-c-j-abandonne-le-cxx) ---- Mieux dĂ©velopper pour les utilisateurs finaux =============================== Comprendre le client et dĂ©velopper vite --------------------------------------- En 2018, une expĂ©rience change radicalement ma façon d’apprĂ©hender le dĂ©veloppement logiciel. À cette Ă©poque, une Ă©quipe C++ se retrouve surchargĂ©e et ne peut implĂ©menter toutes les fonctionnalitĂ©s attendues. On rĂ©flĂ©chit Ă  une solution de secours, et me voilĂ  chargĂ© de dĂ©velopper une application en Python en intĂ©grant des briques sous licence libre. Je travaille alors en Ă©troite collaboration avec les utilisateurs finaux et on sort l’application en quelques mois. Ma nouvelle vision : > Il y a plus important que la technologie, c’est de se mettre dans la peau du client final et de comprendre ses frustrations au quotidien. Et on y arrive mieux en intĂ©grant l’utilisateur final dans son Ă©quipe de dĂ©veloppement. L’application *bricolĂ©e* en Python donne entiĂšrement satisfaction. Les utilisateurs sont contents d’avoir eu trĂšs tĂŽt leur outil, et cela a coĂ»tĂ© moins cher par rapport Ă  toute une Ă©quipe C++ dans sa « tour d’ivoire ». IntĂ©grer l’utilisateur final dans son Ă©quipe -------------------------------------------- Attention, je ne dĂ©nigre pas le C++, celui‐ci peut ĂȘtre une bonne solution face Ă  de nombreuses problĂ©matiques. Mais avant de courir tĂȘte baissĂ©e, s’assurer que la technologie choisie rĂ©pondra bien aux attentes *non exprimĂ©es* de l’utilisateur final. J’écris « attentes *non exprimĂ©es* » car bien souvent le dĂ©veloppeur se base sur sa propre interprĂ©tation d’un document prĂ©sentĂ© comme LA spĂ©cification qui a en plus Ă©tĂ© rĂ©digĂ©e par un intermĂ©diaire (MOA, MOE, Business Analyste, Product Owner, Architecte...). Nous l’avons peut‐ĂȘtre dĂ©jĂ  tous constatĂ©, l’utilisateur final ne sait pas vraiment ce qu’il veut, et a beaucoup de difficultĂ© Ă  exprimer clairement par Ă©crit ses attentes. Un intermĂ©diaire (MOA, MOE, BA, PO, Archi) est nĂ©cessaire pour lui permettre de prendre du recul et pour traduire une demande fonctionnelle en exigence technique. Mais l’intermĂ©diaire rajoute une couche intermĂ©diaire ! C’est humain, l’intermĂ©diaire aura tendance Ă  se rendre indispensable. Et sans le faire exprĂšs, l’intermĂ©diaire Ă©vitera que dĂ©veloppeurs et utilisateurs Ă©changent en direct. Le top est d’avoir l’utilisateur final dans son Ă©quipe de dĂ©veloppement, mĂȘme si ce n’est pas dans le mĂȘme bureau. Avec les habitudes de travail Ă  distance, dĂ©veloppeurs et utilisateur peuvent clavarder (*chat*) rĂ©guliĂšrement. Faire des sprints d’une journĂ©e ------------------------------- La durĂ©e idĂ©ale d’un sprint c’est la journĂ©e. Le matin on Ă©change rapidement avec le client de ce que l’on pourrait faire, on s’attelle Ă  la tĂąche, on livre, l’utilisateur peut tester, on re‐livre... Et, en fin de journĂ©e, on dĂ©briefe trĂšs rapidement. L’intĂ©rĂȘt du Python (par rapport au C++) dans ce mode de fonctionnement c’est la livraison : on peut se permettre de livrer directement le code source et hop l’utilisateur exĂ©cute l’application ! Ainsi, dans mon cas, quand l’utilisateur lançait le dĂ©marrage de l’application, la branche master du dĂ©pĂŽt Git Ă©tait automatiquement mise Ă  jour. J’essayais quand mĂȘme de le prĂ©venir quand une nouvelle version Ă©tait sur la branche _master_. La joie de livrer souvent, rapidement, et d’avoir du _feed‐back_ dans la foulĂ©e. :-) Le choix du langage : une comparaison ===================== Le C++ ne serait donc pas la panacĂ©e ? -------------------------------------- Nous pourrions caricaturer : * en C++, le dĂ©veloppement est lent, mais l’application est trĂšs rapide ; * en Python, le dĂ©veloppement est rapide, mais l’application est trĂšs lente[^1]. Bien souvent, le client final a besoin rapidement d’une fonctionnalitĂ©, mĂȘme si l’exĂ©cution n’est pas super optimisĂ©e. En livrant rapidement cette fonctionnalitĂ©, le client gagne en maturitĂ© et a de nouvelles idĂ©es, de nouvelles façons pour optimiser son travail... et ainsi de suite avec des itĂ©rations courtes. WebSocket en Python ------------------- Pour une application existante, nous avons besoin de fournir une interface WebSocket basique afin que nos clients puissent accĂ©der Ă  un service de Souscription/Publication. Je dĂ©veloppe la fonctionnalitĂ© en utilisant Python et Socket.io. Les tests JavaScript sont concluants. Cependant, nous nous apercevons que Socket.io rajoute son protocole par dessus le protocole WebSocket. Nous allons donc forcer les clients Ă  devoir utiliser Socket.io ce qui n’est pas acceptable. Nous voulons offrir une simple WebSocket afin que le client ne soit pas enfermĂ© dans une technologie et soit libre d’implĂ©menter son logiciel comme il le souhaite. Je m’oriente alors vers [WAMP](https://wamp-proto.org/) avec Autobahn... Mais, rebelote, le **P** dans WAMP signifie **P**rotocol. Pour ne pas rĂ©inventer la roue, je cherche alors une solution qui implĂ©mente dĂ©jĂ  la fonctionnalitĂ© Souscription/Publication et idĂ©alement avec des coroutines ([`async` et `await`](https://docs.python.org/fr/3.5/library/asyncio-task.html)). WebSocket en C++ ---------------- C’est alors que je dĂ©couvre uWebSockets (ÎŒWS), une implĂ©mentation C++17 Ă  couper le souffle qui intĂšgre la fonctionnalitĂ© Souscription/Publication tout en conservant le protocole WebSocket de base. \o/ Mon Ă©quipe est enthousiaste. Je clone le projet, j’adapte un exemple C++ Ă  nos besoins et je prĂ©sente un rĂ©sultat convainquant. C’est agrĂ©able de compiler un projet C++ qui ne tire pas des dizaines de dĂ©pendances. :-) Je prĂ©cise que pour ce nouveau projet, je viens de rejoindre une autre organisation, et j’ai Ă©tĂ© embauchĂ©, en partie, pour mes connaissances pointues en C++17. ![Benchmark fait par l’équipe uWebSockets qui montre que uWebSockets est largement la solution la plus performante](https://raw.githubusercontent.com/uNetworking/uWebSockets/master/misc/websocket_lineup.png "Benchmark fait par l’équipe uWebSockets qui montre que uWebSockets est largement la solution la plus performante") La compilation C++ est archaĂŻque -------------------------------- En Python, Node.js, Ruby, Go, Rust on a `pip`, `npm`, `gem`, `go-get`, `cargo` qui simplifie le tĂ©lĂ©chargement des dĂ©pendances, et l’intĂ©gration au projet avec un `import xxxx`. De plus, certains IDE prennent en charge cette gestion des dĂ©pendances. En C++, la gestion des dĂ©pendances et leur compilation ne sont pas standardisĂ©es. En fait, cela n’a pas beaucoup Ă©voluĂ© depuis les origines : le C++ a quarante ans et se compile toujours dans le mĂȘme esprit que le C qui a lui soixante ans. Pour cela, nous avons le choix du compilateur, dont voici une sĂ©lection avec leurs dates de naissance : * [GCC](https://fr.wikipedia.org/wiki/GNU_Compiler_Collection) et son `g++` (GNU, libre, 1987-2019) ; * [LLVM](https://fr.wikipedia.org/wiki/Clang) et son `clang++` (Apple, libre, 2007-2019) ; * [AOCC](https://en.wikipedia.org/wiki/AMD_Optimizing_C/C%2B%2B_Compiler) et son `clang++` (AMD, libre, 2017-2018) ; * [ICC](https://fr.wikipedia.org/wiki/Intel_C%2B%2B_Compiler) et son `icc` (Intel, non libre, ????-2018) ; * [MSVC](https://fr.wikipedia.org/wiki/Visual_C++) et son `cl` (Microsoft, non libre, 1993-2019) ; * [C++Builder](https://fr.wikipedia.org/wiki/C++Builder) et son `bcc64` (Embarcadero, non libre, 1997-2019). Construction logicielle C++ =========================== Pour la construction logicielle (*build*), nous avons une dizaine d’outils pour nous abstraire du compilateur, en voici une petite sĂ©lection sous licence libre : * [`make`](https://fr.wikipedia.org/wiki/Make) et son `Makefile` ; * [Ninja](https://en.wikipedia.org/wiki/Ninja_(build_system)) et son `build.ninja` ; * [Jam](https://www.perforce.com/documentation/jam-documentation) remplacĂ© par [Boost.build](https://github.com/boostorg/build) et leur `Jamfile` ; * [SCons](https://fr.wikipedia.org/wiki/SCons) et sa configuration en Python ; * [Waf](https://fr.wikipedia.org/wiki/Waf_(logiciel)) qui ambitionne de remplacer SCons. GĂ©nĂ©rateurs de configuration pour la construction logicielle C++ ---------------------------------------------------------------- Et pour nous abstraire de ces outils de construction logicielle, nous utilisons des gĂ©nĂ©rateurs de configuration de *build*, dont voici des projets toujours actifs : * [Autotools](https://fr.wikipedia.org/wiki/Autotools) gĂ©nĂšre du `Makefile` ; * [CMake](https://fr.wikipedia.org/wiki/CMake) gĂ©nĂšre `Makefile`, `build.ninja` et les fichiers projet pour de nombreux [IDE](https://fr.wikipedia.org/wiki/Environnement_de_dĂ©veloppement#Environnements_de_dĂ©veloppement_intĂ©grĂ©) ; * [Premake](https://fr.wikipedia.org/wiki/Premake) en cours de rĂ©Ă©criture active depuis une dizaine d’annĂ©es ; * [xmake](https://en.wikipedia.org/wiki/Xmake) gĂ©nĂšre `Makefile` et les fichiers projet pour quelques IDE ; * [Meson](https://linuxfr.org/tags/meson/public) gĂ©nĂšre `build.ninja` et est compatible avec quelques IDE. Autres outils de construction logicielle C++ -------------------------------------------- Avec les outils ci‐dessus, le *build* et les tests de non rĂ©gression d’une importante application C++ peut parfois prendre une demi‐journĂ©e. C’est beaucoup trop pour attendre si ce que l’on a implĂ©mentĂ© est correct ! D’autres outils de construction logicielle ont donc Ă©tĂ© dĂ©veloppĂ©es dans le but de construire et tester en un minimum de temps : * [Bazel](https://fr.wikipedia.org/wiki/Bazel_(logiciel)) codĂ© en Java et gĂ©rĂ©/financĂ© par Google ; * [Buck](https://en.wikipedia.org/wiki/Buck_(software)) codĂ© en Java et gĂ©rĂ©/financĂ© par Facebook ; * [Pants](https://github.com/pantsbuild/pants) codĂ© en Python et gĂ©rĂ© par une communautĂ© ; * [Please](https://github.com/thought-machine/please) codĂ© en Go et gĂ©rĂ©/financĂ© par Thought Machine. Ces projets ne rĂ©utilisent pas les outils de *build* citĂ©s plus haut, et ne gĂ©nĂšrent pas les fichiers projet des IDE. En revanche, ces outils analysent finement le graphe de dĂ©pendance, gĂšrent de gros dĂ©pĂŽts de code source, parallĂ©lisent la construction logicielle sur tous les cƓurs (CPU) de nombreuses machines (cloud). Les Ă©tapes du *build* sont [mĂ©moĂŻsĂ©es](https://fr.wikipedia.org/wiki/MĂ©moĂŻsation) pour Ă©viter de refaire la mĂȘme opĂ©ration N fois (par exemple, pour Ă©viter de compiler un fichier non modifiĂ©, ou de lier une bibliothĂšque inchangĂ©e). Sans avoir Ă  recourir Ă  ces outils, on peut amĂ©liorer les temps de compilation C++ et d’édition de liens *(link)* avec ces deux bons vieux outils : * [`ccache`](https://fr.wikipedia.org/wiki/Ccache) pour Ă©viter de recompiler (ou lier) un fichier inchangĂ© ; * [`distcc`](https://fr.wikipedia.org/wiki/Distcc) pour distribuer le *build* sur plusieurs machines (voir aussi [icecream](https://github.com/icecc/icecream)). Ces outils `ccache` et `distcc` sont pris en charge par CMake, SCons, ... Les dĂ©pendances : gestion, essais, Ă©checs et solution finale ====================== Gestion de dĂ©pendances en C++ ----------------------------- Mais au fait, comment gĂ©rer les dĂ©pendances C++ ? Quel est le [gestionnaire de paquets](https://fr.wikipedia.org/wiki/Gestionnaire_de_paquets) C++ officiel (*package manager*) ? Quel est l’équivalent C++ pour les commandes `pip`, `npm`, `gem`, `go-get` et `cargo` ? Eh bien... disons que nous avons des initiatives encourageantes : * le groupe de travail **SG15** (du comitĂ© de standardisation du C++) rĂ©flĂ©chit Ă  une nouvelle approche pour compiler le C++ (voir leurs propositions [P1482](http://wg21.link/P1482) et [P1484](http://wg21.link/P1484) en anglais) ; * le projet [**build2**](https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#tldr) est trĂšs bien pensĂ© et dont son auteur avait proposĂ© de standardiser arborescence des projets C++ avec [P1204](http://wg21.link/P1204) ; * le projet [**conan**](https://conan.io/) utilise une configuration en Python et propose dĂ©jĂ  600 paquets C++ disponibles sur les deux dĂ©pĂŽts publics principaux ([conan-central](https://bintray.com/conan/conan-center) et [bincrafters](https://bintray.com/bincrafters/public-conan)) ; * le projet [**vcpkg**](https://github.com/microsoft/vcpkg/tree/master/ports) se base sur CMake et propose 1000 paquets C++ dont une bonne partie sont compatibles Windows, GNU/Linux et macOS ; * le projet [**Hunter**](https://docs.hunter.sh/en/latest/packages/all.html) se base Ă©galement sur CMake et propose environ 300 paquets C++. Attention Ă  ne pas confondre l’exĂ©cutable `b` du projet **build2** avec l’exĂ©cutable `b2` du projet [**Boost.build**](https://github.com/boostorg/build) citĂ© plus haut. Copier les dĂ©pendances dans son code source ------------------------------------------- Une autre façon de gĂ©rer trĂšs simplement ses dĂ©pendances C++ est de carrĂ©ment copier le code source de celles‐ci (et aussi le code source des dĂ©pendances des dĂ©pendances) avec le code source de l’application. Ça compile toujours. Mais ce n’est pas une bonne pratique pour, au moins, deux raisons : 1. respecter les licences libres, c’est avant tout Ă©viter de mĂ©langer des codes sources de licences et d’auteurs diffĂ©rents ; 1. mixer les codes source complique leur mise Ă  jour (par exemple, comment intĂ©grer la correction d’une faille de sĂ©curitĂ© ?). Microsoft me fait perdre deux jours ----------------------------------- Je teste diffĂ©rents moyens pour obtenir le paquet uWebSocket : le *package manager* de ma distribution, Conan, Hunter... et finalement, le paquet uWebSocket a fraĂźchement Ă©tĂ© [intĂ©grĂ© au dĂ©pĂŽt **vcpkg**](https://github.com/microsoft/vcpkg/tree/master/ports/uwebsockets). Je teste, et, ĂŽ miracle, cela tĂ©lĂ©charge le code source et me l’installe sur ma distribution GNU/Linux ! L’outil **vcpkg** fonctionne avec CMake, donc ce sera CMake qui gĂ©rera la construction logicielle. Le temps de se documenter et bien prendre en main **vcpkg**, de tenter une intĂ©gration dans mon `CMakeLists.txt`, d’échouer, de recommencer... Pourtant l’[exemple avec SQLite3](https://github.com/microsoft/vcpkg/blob/master/docs/examples/installing-and-using-packages.md#cmake) fonctionne chez moi... Arg... En fait, c’est mal empaquetĂ©, le `find_package()` ne pourra jamais trouver la bibliothĂšque uWebSocket fournie par **vcpkg**. J’essaye de le faire moi‐mĂȘme. Puis, je me rends compte au second jour que **vcpkg** est un outil amateur, Ă  ne surtout pas utiliser pour aller en production : pas de version des dĂ©pendances, impossible de dĂ©cider des options de compilation des dĂ©pendances... Allez, on empaquette soi‐mĂȘme cette bibliothĂšque ------------------------------------------------ Bon, je connais bien C++, alors empaqueter proprement une bibliothĂšque qui ne dĂ©pend de rien ne devrait pas poser problĂšme. Je retrousse mes manches et je commence Ă  chercher si quelqu’un a dĂ©jĂ  empaquetĂ© uWebSockets... Je trouve surtout que le mainteneur principal a supprimĂ© les fichiers `CMakeLists.txt` et `meson.build` en [2017](https://github.com/uNetworking/uWebSockets/commit/c28ac971953a11569a5b1c2437abea5dbcd6f6ed). Et celui‐ci semble envoyer bouler les [contributeurs proposant la compatibilitĂ© avec CMake](https://github.com/uNetworking/uWebSockets/pull/769), supprime le titre des *pull requests* et on trouve mĂȘme des commentaires [supprimĂ©s](https://github.com/uNetworking/uWebSockets/pull/221). On trouve une explication dans la [FAQ](https://github.com/uNetworking/uWebSockets/blob/master/misc/FAQ.md) : > _I don’t accept any specific build systems because I know from experience that doing so opens up hell. People simply cannot agree on which build system to use, or even how to use one particular build system._>> _That’s why I no longer accept any such PRs. I’ve had too many CMake PRs dragging in completely different directions to know this is the only solution._>> _You’ll have to clone the repo and create a new project in whatever build system you want to use._ En gros, le mainteneur principal refuse tout systĂšme de construction logicielle, car les dĂ©veloppeurs veulent utiliser diffĂ©rents outils et que pour un mĂȘme outil, les dĂ©veloppeurs ne se mettent pas d’accord sur la bonne façon de faire. Un _commit_ trĂšs Ă©tonnant est le « [*Not my problem*](https://github.com/uNetworking/uWebSockets/commit/614d02e4620d5af5e4cdc654d9ac59cde86eb51f) » qui change la licence et remplace dans tous les fichiers la ligne :   `Copyright 2018 Alex Hultman and contributors.` par :   `Authored by Alex Hultman, 2018-2019.`   `Intellectual property of third-party.` CMake gagne, Meson rentre Ă  la maison ------------------------------------- Mon IDE prĂ©fĂ©rĂ© pour le C++ est QtCreator, mais celui‐ci ne prend pas [encore](https://bugreports.qt.io/browse/QTCREATORBUG-18117) en charge Meson. Et je n’ai plus beaucoup de temps pour prendre en main GNOME Builder. Et j’obtiens un joli `CMakeLists.txt` qui fonctionne sur deux diffĂ©rentes distributions GNU/Linux et aussi sur GitLab. Je me rends aussi compte que GCC 8 ne compile pas cette bibliothĂšque, et que nous devons utiliser seulement Clang. Mais, mon plus gros problĂšme est que je n’arrive plus Ă  faire compiler cette bibliothĂšque par QtCreator, alors qu’avec la ligne de commande cela fonctionne parfaitement... Argh... J’investis encore du temps... Échec C++ --------- Mes collĂšgues ne comprennent pas pourquoi je mets autant de temps pour faire l’équivalent d’un `pip install` en C++. De plus, je vais devoir refaire ce mĂȘme travail dĂšs que j’intĂ©grerai les autres bibliothĂšques : base de donnĂ©es, [file d’attente de messages](https://fr.wikipedia.org/wiki/File_d%27attente_de_message), [journalisation](https://fr.wikipedia.org/wiki/Historique_(informatique))... Nous dĂ©cidons ensemble d’arrĂȘter de s’obstiner, de relever la tĂȘte, et de lister les possibilitĂ©s : * continuer l’intĂ©gration de uWebSockets avec CMake ; * utiliser seulement les paquets Conan ou Hunter comme `boost::beast` pour la websocket (c’est mĂȘme disponible avec `apt install`) ; * revenir sur le Python et implĂ©menter la Souscription/Publication ; * passer sur Node.js et intĂ©grer la bibliothĂšque C++ uWebSockets avec la simplicitĂ© de `npm` ([uWebSockets.js](https://github.com/uNetworking/uWebSockets.js)) ; * prendre le virage Rust, seul rival au C++ avec la simplicitĂ© de `cargo` ; * *Go to the* langage Go qui est simple comme Python et est une des technos les plus performantes. WebSocket en Node.js -------------------- J’ai plusieurs collĂšgues trĂšs compĂ©tents en Node.js, alors c’est parti. Effectivement, l’installation de la dĂ©pendance est trĂšs simple et on implĂ©mente rapidement l’application. Le grand avantage de Node.js (et de JavaScript en gĂ©nĂ©ral) est la taille de la communautĂ© et l’esprit de partage et d’innovation incroyables. Alors qu’une dĂ©cennie est nĂ©cessaire en C++ pour se dĂ©cider, la communautĂ© JavaScript dĂ©cide en quelques mois. Les projets, les concepts de programmation, les mĂ©thodes de travailler ne cessent d’évoluer. J’entre dans un vaisseau qui se dĂ©place Ă  la vitesse de la lumiĂšre. En C++, la durĂ©e de vie d’un projet peut ĂȘtre d’une dizaine d’annĂ©es. En Node.js, c’est plutĂŽt dix mois. C’est aussi l’inconvĂ©nient, il faut s’adapter vite. Mais, nous nous apercevons que le projet uWebSockets.js ne prend pas en charge la Souscription/Publication de la bibliothĂšque sous‐jacente uWebSockets. Ça ne marche pas. Stop, nous venons de gagner en maturitĂ©, voyons voir les possibilitĂ©s : * Node.js (implĂ©menter la Souscription/Publication en JavaScript...) ; * Rust ; * Go. Les principaux enseignements ==================================================== WebSocket en Go --------------- Nous prenons conscience que la partie WebSocket risque d’ĂȘtre un point sensible au niveau performance. Finalement, nous mettons entre parenthĂšses notre tentative Node.js. Le Rust est encore trop jeune (peu de dĂ©veloppeurs maĂźtrisant Rust sur le marchĂ©). Et nous avons un collĂšgue devops fan du Go. Notre collĂšgue maĂźtrisant Go n’étant pas trĂšs disponible, on apprend se dĂ©brouille seul. Finalement, le principal du langage Go s’acquiert en quelques heures de programmation. Le test WebSocket est un succĂšs et nous implĂ©mentons une premiĂšre version basique de la publication/souscription en Go. Nous mettrons en place des tests de performance reproductibles, et seulement aprĂšs nous pourrons dĂ©cider quelles sont les parties qui nĂ©cessitent d’ĂȘtre optimisĂ©es. Valoriser l’échec ----------------- * C’est grĂące Ă  nos Ă©checs successifs que nous avons pu trouver notre solution pour les WebSockets ; * nous aurions pu dĂ©cider qu’il fallait Ă©viter les Ă©checs ; * mais nous avons plutĂŽt cherchĂ© Ă  nous planter car l’échec est un trĂšs bon moyen d’apprendre (de ses erreurs) ; * se planter plus rapidement/souvent permet donc d’apprendre plus vite ou souvent ; * donc, essayons d’augmenter nos Ă©checs (car c’est augmenter notre apprentissage) ; * pour encourager Ă  tester une idĂ©e, nous devons valoriser l’échec ; * tester simplement/rapidement une idĂ©e permet de gagner en maturitĂ©. Enseignements sur les langages ------------------------------ * Ce n’est pas une bonne idĂ©e de coder dans son langage de programmation (C++) ; quand on est le seul dĂ©v. de l’organisation qui connaisse ce langage ; * JavaScript et Node.js ça dĂ©coiffe ; * Go c’est vraiment simple (car c’est limitĂ©). Louanges sur la simplicitĂ© ------------------------- * La simplicitĂ© permet de se concentrer sur l’essentiel ; * faire simple est souvent compliquĂ© ; * avoir une IT simple permet d’intĂ©grer de nouvelles contraintes et idĂ©es plus facilement ; * dans un monde de plus en plus concurrentiel et qui s’accĂ©lĂšre, la simplicitĂ© Ă©vite de se perdre dans le brouillard. Je continue d’aimer le C++ ========================== Mais, non, je n’abandonne pas le C++ ! J’apprĂ©cie d’acquĂ©rir de nouvelles cordes Ă  mon arc, de m’ouvrir l’esprit sur de nouvelles pratiques. Certaines technologies sont plus adaptĂ©es Ă  certains contextes. N’ayons pas de dogme, choisissons la bonne technologie selon la situation. Cependant, je ne sais pas quand je coderai Ă  nouveau en C++... Peut‐ĂȘtre quand on aura un *C++ package manager* standardisĂ©... :-) On embauche =========== Un peu de publicitĂ©... Tu apprĂ©cies cet Ă©tat d’esprit et que tu aimes coder en Python, Node.js, JavaScript/TypeScript/Angular ou Go ? N’hĂ©site pas Ă  me contacter sur `oli (Ă ) Lmap (point) org`. Nous avons des postes Ă  Paris et Ă  Metz. On peut s’arranger pour le tĂ©lĂ©travail. Pour le moment, on ne publie rien sous licence libre. Mais je pousse pour libĂ©rer quelques briques intĂ©ressantes... [^1]: Utiliser [Pythran](https://linuxfr.org/tags/pythran/public), [PyPy](https://fr.wikipedia.org/wiki/PyPy), [Cython](https://fr.wikipedia.org/wiki/Cython), [Numba](https://en.wikipedia.org/wiki/Numba), etc. accĂ©lĂšre l’exĂ©cution, mais cela ralentit le dĂ©veloppement : compilation plus lente, dĂ©veloppement plus complexe, bogue difficile Ă  investiguer...

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /