Architecture as code is not an easy task

This article is of a kind I don’t like : it’s a failed experience feedback. And it’s written in english for one reason (and only one) : making sure Simon Brown (whom I don’t know french reading level) reads and understands it.

And what failed is a project I developped to leverage (at least that what I thought when I started) Structurizr ability at providing a lightweight model usable and editable by Java.

But first …

Context

I’ve discovered C4 and Structurizr some years ago (my external archive tells me it dates from ’18). And I’ve immeditaly loved the way it allows someone to describe a software system architecture with an ease that UML never ever dreamed of. Not long after, I read the agile architecture documentation template provided by Simon and really felt in love (undoublty because I do believe humans are story people) with the way it tells the story of the software system studied using C4 and Structurizr.

So, when I was missioned as cross-team tech lead for three projects, I decided to use that tooling to produce all my documentation. And I was able, thanks to these tools and my old architect tool belt (PlantUML and Asciidoc) to produce architecture documents of a very good level with little effort. However, there were some Java classes used to extract informations from the environment (K8s deployment information) and from the build artifacts (maven modules as containers) that were too much specific to my mind.

Need is mother of invention

As a consequence, when the pandemic locked me at home with no more mission, I took the time to get my ideas together and

  1. Write some french documentation explaining/paraphrasing agile architecture documentation
  2. Create a maven artifact project containing smart tools allowing my colleagues – and myself – to easily produce high quality architecture documentation at low cost.

I immediatly met some accidental complexities that I solved through … well … shenanigans.

Asciidoc is not so easy

Figure yourself, generating asciidoc in Maven is not so simple.

Indeed, as Asciidoctor is not a Java port of asciidoc, but rather a wrapping of the Ruby code using JRuby, customizing that generation is quite complex. Typically, each component of the system must have a version that allows all the components to work together.So when you update JRuby, you have to check « religiously » that the asciidoct-maven-plugin still works, and that asciidoctor-diagram works.

Speaking of which I had to solve a very specific bug with what can only be described as a hack.

Chaining Java code is not so easy

Considering I wanted to build a Java model of the code prior to feeding asciidoctor-maven-plugin with PlantUML diagrams generated from that model, I had to

  • Generate a basic architecture model of my application using Java code
  • Augment that model with informations extracted from that model metadata
  • Augment documentation with informations also extracted from that model metadata
  • Generate an include chain allowing human-written documentation to include all that generated content
  • Generate the correct diagrams

The augmentation part being modular (the curse of architects) to handle different cases, such as projects using GitHub or Gitlab, extracting containers from Maven and components from Spring/GWT/JavaEE components, I chose to use an old friend of mine, CDI (and in that particular case, JBoss Weld).

And, since all that code was to be run in maven, I had wrap that Java executable in a call to exec-aven-plugin, with all parameters sent as system properties (which worked well, but was quite ugly in the maven pom).

So, my Java code started a Weld container, loaded all CDI components, and orchestrated it. All in a maven build which job is … well … to orchestrate plugins, no ? So the concept was good, but the implementation was overly complex.

What was more annoying was that, since my maven build had to embed the exec-maven-plugin code and the asciidoctor-maven-plugin generation (which used asciidoctor-diagram and « some » configuration to handle niceties such as ability to send feedback to documentation author), the pom.xml file was of a rarely seen size (692 lines for the project documentation module).

A chain is as strong as its weakest link

But there is even worse. Acustomed to old french companies, which tend to despise external tools, I prefered to use C4-PlantUML to output diagrams instead of sending them to a structurizr workspace. It worked well, thanks to structurizr-plantuml module (which I contributed to), until the accident. Well, not a real accident, but more an incident. As you see in that question, I found a solution (the hack previously mentionned). But even after having solved that issue, generating the PlantUML diagram remains painfully slow.

To be honest, in my current mission, generating asciidoc routinely takes more than 2 minutes, mainly due to diagrams (yup, i’ve tested removing them). And, due to the accidental complexity of my pom, i never did the move from asciidoctor-diagram to asciidoctor-kroki (which is way faster, and accept ay more easily to generate diagrams using a locally unning docker image)

The final nail

I guess you see the end coming … but, you know, I’m quite persistant. And I tried to fix that, but then came the final nail. This one took the form of an opportunity : replaying in an evening event the presentation I did in my company, which you can see below

And when I started working on it, I took a look at this intriguing Simon Brown tweet (because I was intrigued by the concept of structurizr-lite)

And it was a blast : I was able to write my model in a cute DSL, and have all my diagrams rendered nicely. This was a very good presentation tool (I tested it on my colleague), but also a way to generate those diagrams that was undoubtly wayyyy better packaged than what I was building.

Time for introspection

I’m not good at introspecting as I tend to think i’m an awesome person, with genius ideas and the ability to deliver them flawlessly. But this time, the comparison was hard and I had to consider my frankenstein of a tool for what it was : a good idea, poorly delivered.

Isn’t it anything to salvage ?

It took some time (and this article is the realization of this introspection), but I’ve finally understood that there were good and bad ideas.

Let me sum them up here

The good

  • Provided I’m working on a monolith, I can assume maven modules are mapped to structurizr containers, and this helps producing immediate understanding of the project architecture
  • Collecting informations from the maven model to augment the structurizr architecture model is really useful for developers : I don’t have to indicate Structurizr it’s a Spring project, as my code is already able to understand that by scanning dependencies
  • In the same fashion, extracting GitHub conventionnal project files (README.md, CONTRIBUTING.md) is a great idea, as developers are used to fill those files with great content, that has its own place in architecture documentation
  • Speaking of GitHub extraction, I played with the idea of using GitHub token to connect to GitOps repository to extract K8s deployment files and transform them into standard architecture documentation. This was poorly made, but already understandable AND useful

The bad

  • As I already mentionned, build asciidoc content in maven, when using some plugins and wanting modern versions, is just a nightmare. The build file becomes very fast huge, and nobody can maintain a maven pom cumulating 5 profiles, 3 different plugin configurations – each using hundred of lines of XML). Beware : it’s not a critic of Maven, more a citic of the non-optimal integration of Asciidoc in the maven way (yeah I’m a believer)
  • Using another plugin system in a maven build is just plain stupid
  • For the first time, I decided not to deliver my artifacts on maven central (due to the needed bureaucracy) but on Jitpack. It was a bad iead, since companies tend to maintain maven mirrors which mirror maven central (cool), possibly Spring repository (of no interest to me), but never Jitpack, which is way too volatile. So I couldn’t download my artifacts in CI machines, and one of the promise of Structurizr (considering the architecture documentation as one of project by-products, always generated on build, and as a consequence alays up-to-date and available ina rtifact repositories)

The weird

  • Being able to reuse architecture diagrams in reveal.js diagrams (thanks to asciidoctor-reveal) was quite funny, but was hardly used (which is quite normal, to my mind)
  • I built a quite complex system to hide the Asciidoc content I generate, and I still can’t decide if it was a genius idea, or the weirdest fuckery I’ve ever produced

What to do next

I tink this article quite sums up the next step : I should refocus on the parts of the project that adds value to Structurizr ecosystem, and give up the other fragments.

But, instead of immediatly giving a method (what I did in my first draft which I immediatly seen as wrong), I think I should first use agile architecture documentation lessons and redefine my goals and non-goals. So, what are my goals ?

  • Use build-time analysis to enhance Structurizr models
  • Use build-time analysis to also enhance produced documentation
  • Integrate as much as possible in Structurizr ecosystem

And what are my non-goals

  • Force users to choose between enhancements and conformance to Structurizr tooling
  • Produce a virtual power plant, too complex to maintain
  • Multiply the moving parts

I think I’m gonna try to use Hacktoberfest to rewrite my tooling in a smart way …

It’s the economy, stupid!

Vous connaissez cette phrase ? Vous l’avez sans doute déjà entendue, parce que c’est un slogan de campagne qui a eu un certain succès. Mais pourquoi je mentionne ce slogan ? (on va venir doucement au coeur du sujet, installez-vous au coin du feu, et laissez-moi vous raconter cette fable)

Parce que si l’homme est une créature de chair et de sang, l’entreprise est une créature de pouvoir et d’argent. Je ne sais pas si vous avez lu Sapiens (personnellement, je n’en ai lu que la version dessinée), mais l’auteur énonce à un moment une idée forte

Yuval Noah Harari – Sapiens

Toute coopération humaine à grande échelle – qu’il s’agisse d’un État moderne, d’une Église médiévale, d’une cité antique ou d’une tribu archaïque – s’enracine dans des mythes communs qui n’existent que dans l’imagination collective. […] Pourtant, aucune de ces choses n’existe hors des histoires que les gens inventent et se racontent les uns aux autres. Il n’y a pas de dieux dans l’univers, pas de nations, pas d’argent, pas de droits de l’homme, ni lois ni justice hors de l’imagination commune des êtres humains.

Autrement dit, l’entreprise est une fiction entretenue par le pouvoir de ceux qui la créent (pensez par exemple à Steve Jobs, Jean-Marie Messier, Carlos Ghosn) et elle existe grâce à la circulation de l’argent qui lui vient de ses clients pour subvenir à ses besoins (salaires, fournisseurs, actionnaires, achats divers, …). La différence importante entre une entreprise et un corps réel est que, comme il s’agit d’une fiction, il est aisé de confondre les moyens et les fins. C’est-à-dire qu’il est facile de croire que l’objectif d’une entreprise est de gagner de l’argent. Gagner de l’argent est pour l’entreprise l’équivalent de se nourrir à satiété : avec suffisamment d’argent, l’entreprise peut payer tous ses besoins et envisager de s’étendre, tout comme suffisamment de nourriture permet à un humain de réfléchir à améliorer son mode de vie. Pourtant, bien peu d’humains considèrent que leur but dans la vie est de disposer de suffisamment de nourriture. Dans la France du XXIème siècle, en dehors des gens sous le seuil de pauvreté, se nourrir est rarement un but prioritaire. C’est ce qu’exprime la (désavouée) pyramide de Maslov. Une telle pyramide des besoins existe-t-elle pour les organisations ? (je ne trouve pas, ça ne veut pas dire que ça n’existe pas, ça veut plutôt dire que la terminologie doit être différente)

On voit bien, pourtant, qu’il existe des besoins d’entreprise au-delà de « survivre » (qui se traduit par « gagner assez de l’argent »). Je citerai par exemple le besoin de vision : savoir ce que fait ou veut faire une entreprise est un besoin crucial, ne serait-ce que pour que les salariés puissent s’aligner avec cette vision, pour être capable de produire de la valeur sans avoir besoin d’instructions explicites. Sauf que construire une vision, ça nécessite une chose : comprendre le métier de l’entreprise et être capable de prendre, dans ce métier, une position claire.

(et maintenant, c’est le moment qui fait mal)

Reprenons donc mon article sur la structure du marché informatique en France.

Et regardons, à la lumière de cet article, le top 250 des entreprises SYNTEC. Qu’est-ce qu’on y voit ? Une domination évidente en nombre et en chiffre d’affaire des ESN. Pourquoi dominent-elles à ce point ce classement ?

Parce qu’être éditeur nécessite une vision, dont sont souvent incapables les dirigeants de ces entreprises (je vais me fâcher fort avec mon chef, là, #NotAllESN toussa toussa). En effet, pour produire un logiciel et arbitrer les envies de ses clients, il faut nécessairement se positionner d’une manière bien plus complexe que ce que font les grosses ESN qui se contentent de répondre à tous les appels d’offre, parce qu’elles ont un besoin terrible de faire circuler l’argent en leur sein (autrement dit, leur taille les a rendues incapables d’agilité et d’évolution, comme dans agar.io). Et, comme une conséquence logique, leurs dirigeants ne sont plus des visionnaires, mais des gestionnaires. Des gens dont l’objectif unique, la vision, est simplement d’assurer la rentabilité attendue par les actionnaires. Et si ces entreprises sont incapables de travailler avec les petites et moyennes entreprises du monde de l’informatique, c’est sans doute à cause de ce fossé entre gestionnaire et visionnaire.

Et ce fossé, on le retrouve à un autre endroit qui fera grincer encore plus de dents.

Est-ce que vous vous souvenez du « I have a dream » de Martin Luther King ? Ou de JFK promettant un américain dans l’espace avant 1970 ? Ou de De Gaulle avec sa vision de la France libre ? J’imagine que vous me voyez venir avec mes gros sabots. Le monde politique lui aussi est devenu un monde de gestionnaire, pour des raisons un peu semblables au monde des chefs d’entreprise : il y a tellement de gens à qui rendre des comptes qu’avoir une vision y est un luxe impossible … Enfin, c’est la théorie appliquée dans les écoles qui forment l’élite de la fonction publique en France (typiquement l’ENA).

La conséquence est logique : ministères et grandes entreprises se font confiance parce que ces lieux partagent une communauté de culture, communauté où l’innovation est considérée comme un jeu trop dangereux pour être joué. Je pourrais par exemple citer l’exemple historique de la voiture électrique, qui existe depuis 100 ans mais qui ne décolle que parce qu’un fou visionnaire s’y est lancé, ou celui de ces fleurons industriels des transports qui ont pour la plupart été mis sur une voie de garage, parce que si il y a bien un domaine où l’innovation est nécessaire – et risquée – c’est le monde du transport.

Au-delà de ces exemples, il me semble que le marché de l’informatique en France est un exemple trop parlant pour être ignorable. Citez donc une entreprise française d’informatique qui propose de l’innovation autre que de façade. Je vais juste me permettre de définir « innovation de façade ». Pour moi, une innovation de façade c’est, par exemple, créer un réseau social quel qu’il soit : l’innovation ne sera pas technique, elle ne sera que dans l’usage. Et l’usage, surtout pour le grand public, c’est sans doute l’un des éléments sur lesquels il est le plus facile de créer une envie, et donc un marché. Au-delà de ces innovations de façade dont la french tech se gargarise, quelles entreprises informatiques françaises sont authentiquement innovantes ? Bien trop peu.

Parce que ces innovations se heurtent à des gestionnaires de tous ordres, pour lesquels l’innovation est un risque avant d’être une opportunité. Et parce que les gestionnaires confondent les moyens (le besoin de faire circuler l’argent dans l’entreprise) et les fins (avoir une vision qui permette à l’entreprise de continuer à faire circuler l’argent après la prochaine révolution technologique).

Hier soir, c’était chitjug Java 17 !

Et Rémi et José venaient nous parler de Java 17. Franchement, pour moi, c’est un super sujet.

Sauf que ….

Le chtijug peut offrir ce genre de soirée grâce à ses sponsors. Et l’entreprise dans laquelle je travaille actuellement, Zenika, fait partie de ses sponsors.

Du coup, j’avais le même problème que Logan

Et donc, hier soir, j’ai dû choisir. Et même si j’aime beaucoup Rémi et José, j’aime aussi beaucoup le chtijug, et le buffet qui a lieu après chaque conf.

Résultat, hier soir, pour moi, c’était soirée préparation de buffet.

J’ai donc fait amener par des collègues (merci encore à eux) toutes les boissons de la soirée (une centaine de bouteilles de bière, et une cinquantaine de bouteilles de soft). Puis j’ai cherché, avec l’aide de Younès d’Euratech, des frigos aux quatre coins du bâtiment pour rafraîchir un peu les bouteilles (parce que la bière chaude, c’est moins bon). J’ai ensuite eu un petit créneau pour voir José nous parler des nouvelles méthodes dans les streams (avec un exemple d’utilisation de mapMulti assez rigolo). Et je repartais pour accueillir les plateaux du buffet et commencer à installer tout pour que les spectateurs et els orateurs puissent se détendre au mieux. Résultat, pour moi, l’image qui symbolise le mieux ma soirée d’hier soir, c’est plutôt celle-là

Et franchement, ça fait plaisir de refaire un chtijug, même si je n’en ai presque rien vu. Vivement le prochain !

Et l’open-source, ça change quoi au marché ?

J’ai écrit dans mon précédent article que j’allais écrire au sujet de l’open-source. On est Dimanche, il fait beau, c’est le moment idéal !

Parlons donc du lien entre l’open-source et l’économie de l’informatique – en France avant tout.

Il y a quelques années, en mission chez Adeo, j’ai assisté à une très intéressante présentation d’un des membres du board de la fondation Apache sur le rôle de cette fondation.

Le présentateur y expliquait que le rôle de la fondation Apache était avant tout d’offrir une couche d’isolation contractuelle aux développeurs open-source. Et il y expliquait aussi comment l fondation a été créée. je vais commencer par ça, parce que c’est assez typique.

A ce sujet, l’article de la wikipedia est aussi parfaitement exact qu’inexact. Ce qu’a expliqué Dirk-Willem, c’est que les scientifiques qui ont écrit le serveur Apache, sur leur temps libre parce que leur employeur n’avait pas les moyens d’en acheter un, se sont rendus compte qu’en cas de poursuite judiciaire, ils étaient pénalement responsables. Il leur fallait donc une structure juridique les isolant des endroits où ce logiciel serait déployé, ce qui est le rôle des fondations open-sources.

Ce que je trouve fou dans cette histoire, c’est que ces gens ont travaillé pour leur employeur en plus, et que, pour schématiser, leur employeur s’est contenté de leur signaler qu’il pourrait se retourner contre eux. Bon, leur employeur, ou plutôt les parties de l’employeur qui voient dans les employés de petits rouages bien efficaces. Pour le dire autrement … les comptables. Les mêmes qui voient depuis toujours l’informatique comme un coût.

Et on pourrait croire que l’attrait du prix nul était suffisant pour convaincre les entreprises … En réalité, ça n’a pas été aussi simple : pendant longtemps, incitées par des fournisseurs à la moralité élastique (comme Microsoft ou Oracle), les entreprises refusaient d’utiliser de l’open-source, à cause de la viralité de la GPL, par exemple, ou d’autres considérations à base de « je ne vais pas laisser s’exécuter du code qui n’est pas audité » (croquignolet, quand on entend les récits de guerre de certains vieux développeurs ayant installé des backdoors plus ou moins nocives). Mais très vite, l’avantage du code gratuit, facile à intégrer (surtout dans des langages disposant d’un écosystème riche ainsi que de moyens commodes d’y accéder, comme le Java) a vaincu ces réticences, et on s’est retrouvé avec de plus en plus de code open-source maintenu par des équipes plus ou moins payées mis au service de … toute l’industrie de l’informatique du monde.

libssl, curl, et tant d’autres. je suis sûr qu’ils en parlent sur explain xkcd

Résultat, aujourd’hui, vous écrivez tranquillement votre code Spring en rajoutant des dépendances (comme Failsafe ou Retrofit) sans vous soucier des gens qui ont développé ces dépendances. C’est bien ? Pour avoir utilisé moi-même ces dépendances, et avoir codé un peu d’open-source, c’est surtout bon … pour le comptable de mon client, qui réduit le coût de développement du logiciel à mon tarif horaire.

Et franchement, ça fait du développement logiciel l’une des activités les moins coûteuses au monde. En fait, il n’y a que les métiers de service faiblement qualifiés qui coûteront moins cher : organiser une fête, faire livrer du matériel … Toutes les activités d’investissement (comme l’est le développement logiciel) coûtent infiniment plus cher.

Et si vous voulez l’une des raisons pour lesquelles les éditeurs logiciels souffrent, c’est précisément ça : comme le logiciel est un coût, et que l’open-source ne vaut rien, chaque produit payant se retrouve concurrencé par une alternative open-source moins performante, mais aussi beaucoup moins chère (je le sais, je joue à Mindustry plutôt qu’à factorio).

A ce sujet, une petite parenthèse : ce qui arrive aujourd’hui à Elastic (qui se fait dévorer par Amazon) ou à Docker (qui se fait étouffer par Google – entre autres) est normal : un éditeur logiciel ne peut pas lancer un produit open-source s’en s’attendre à ce que des gens plus à l’aise en stratégie produit, et disposant de moyens supérieurs, ne vienne dévorer son marché par tous les moyens possibles. C’est mal. Mais c’est une partie de la nature humaine.

Attention, je n’écris pas ici que l’open-source est mal en soi. Au contraire, je crois vraiment que c’est l’une des transformations les plus enthousiasmantes qu’ait apporté la révolution numérique. J’écris plutôt que les entreprises consommatrices d’informatique y voient un moyen commode de réduire ce qui n’est vu que comme un coût.

Et c’est peut-être la raison pour laquelle les initiatives de financement de l’open-source ressemblent à ce point aux cagnottes qu’organisent les américains pour pallier leur système de santé défaillant … Dans les deux cas, c’est une forme de charité douteuse, qui n’existe que parce que les gens qui ont l’argent ont trouvé des façons intelligentes de ne pas payer pour le service rendu.

Cela dit, il y a quelque chose de profondément positif à tout ça. Je crois que cette chute des coûts est à l’origine de la transformation numérique que subissent les entreprises françaises : comme le développement de nouveaux logiciels ne coûte pas grand chose, les entreprises en développent des tonnes, et financent une partie du développement des solutions open-source, tout en s’enfonçant dans une informatisation de plus en plus poussée. Ca ne veut malheureusement pas dire que les entreprises deviennent plus efficaces (et franchement, j’ai des doutes). En revanche, ça veut dire que le travail d’informaticien va devenir de plus en plus central, ce qui changera sans aucun doute les structures de pouvoir.

Quel impact a la structure du marché sur les postes disponibles ?

J’ai écrit il y a peu un petit truc sur La structure du marché informatique en France. Si vous ne l’avez pas lu, je pense que ça le mérite. Et maintenant que vous l’avez lu, on va passer à autre chose. Et comme la question est en titre, je ne me répète pas.

Où travaillent les développeurs en France ?

Ou plutôt, qui sont les employeurs en France ? Je n’ai pas de chiffres précis … Mais j’ai quand même une approximation. Enfin, ZDNet dispose d’une approximation que j’ai même traduit en image

Oui, je suis un infographiste de compétition

Comme vous le voyez, si vous voulez travailler ailleurs que dans une ESN, ça va être dur.

Mais d’où ça vient ?

C’est assez simple structurellement, et franchement, vous vous en doutez déjà : dans un marché dominé par des entreprises développant des logiciels sur-mesure, les éditeurs de logiciels, qui produisent du logiciel « standard » et moins adaptable sont désavantagés sur le plan de l’adaptation au besoin, mais évidement intéressant financièrement.

Cependant, et c’est la partie délicate, une partie significative du logiciel développé en France est cachée : les entreprises développent beaucoup plus de logiciels correspondant à leurs besoins internes que de logiciels publiquement exposés. Et ces logiciels internes sont, la plupart du temps, développés sur mesure. Sans doute parce que, dans une rhétorique du sur-mesure très « la France, le pays du luxe », chaque dirigeant est incité à penser que son entreprise est et doit être absolument spécifique.

Autrement dit, le marché incite les clients à consommer (c’est un poil le concept de société de consommation). Et qui dit incitation à consommer, dit aussi produit de qualité médiocre, mais comme je l’ai écrit, ça n’est pas l’objectif …

Cependant, si la qualité n’intéresse pas le client ni le vendeur, ça intéresse quand même un peu plus le consultant qui va honorer la promesse vendue.

Et il y a pire

Est-ce qu’informaticien est un job qui fait rêver ? D’après le parisien .. pas vraiment (oui, j’ai parfois des sources de qualité) ou plutôt ça n’est pas un métier dans la liste de ceux qui font rêver. En revanche, même l’état le dit, c’est un métier qui recrute. Et, pire encore, on retrouve le « métier » d’informaticien par exemple dans cette liste des dix métiers que les français ne veulent pas faire. Il s’agit donc d’un métier pour lequel on cherche des compétences, et qui ne fait pas rêver, ok, la démonstration est faite. Mais ça implique quoi ?

Ca implique d’abord que les gens sensibles à l’image qu’ils projettent ne feront pas ce métier à cause du stigmate social (c’est rare, mais ça arrive). Ca implique aussi que, puisqu’on ne trouve pas assez de gens motivés pour faire ce métier, il s’agit aussi d’une voie de reclassement. On trouve donc régulièrement (et j’ai eu également des collègues très sympathiques qui étaient dans ce cas) des gens en reconversion, qui n’ont aucune appétence particulière pour ce métier. Ceux qui vont passer leur pause à vous parler du dernier match de foot ou de la dernière série à la mode. Cette population a un point commun avec ceux qui, dirigés par leur ambition (ou leurs enseignants en formation), souhaitent avant tout devenir des chefs, parce qu’être chef, c’est cool.

Ca crée donc une population de développeurs peu sensibles à la qualité des logiciels produits, et plus à la satisfaction de leur hiérarchie. Ca n’est pas une mauvaise chose en soi, mais ça n’aide pas à la satisfaction du travail bien fait.

Mais alors, on fait quoi ?

C’est la question que m’a posé un collègue cette semaine. Globalement, en tant que développeur, vous avez le choix entre

  • Travailler chez un client final, auquel cas votre travail est avant tout politique. Ca n’est pas une mauvaise chose, pour peu que vous aimiez l’idée de convaincre les gens du bien-fondé de vos plans stratégiques, et que vous ne vous intéressiez que modérément à la réalisation technique de ces plans. Vous aurez par ailleurs accès à des locaux spacieux, à un salaire plutôt élevé et aux moyens d’une entreprise établie, mais chez laquelle l’informatique n’est qu’un moyen (puisque vous vous replacez dans le contexte historique de développement de l’informatique : un moyen d’optimiser les coûts de l’entreprise pour faciliter son développement).
  • Travailler dans une ESN, où vous serez confrontés à des projets variés, dans des contextes variés, mais où vous ne choisirez pas le contexte métier. Ca veut dire aussi que vous serez envoyé en mission à peu près n’importe où, et traité par vos interlocuteurs quotidiens (les clients de votre employeur) comme un fournisseur.
  • Travailler chez un éditeur de logiciel, où le contexte ne changera pas (ce qui ne veut pas dire que vous aimerez ce contexte), et où la réussite de l’entreprise dépendra directement de la qualité de ce que vous produisez. Évidement, vous serez un peu moins bien payé, sans doute à cause des difficultés existentielles des éditeurs. Et votre « aventure » a des risques de mal se terminer.

Ecrit comme ça, aucun choix n’est bon. Mais en vérité, aucun n’est non plus vraiment mauvais … Sauf bien sûr si vous croyez à la fin du capitalisme … Mais on en reparlera.

Pour ma part, j’aime continuer à coder … mais je me rends compte que je suis de moins en moins intéressé par le développement dans le contexte d’entreprise. Et comme j’ai une expérience significative, je peux aider mes clients en fournissant d’autres services : de l’architecture, de l’accompagnement des développeurs (et des équipes). Et je pense que pour les développeurs un peu passionnés, les opportunités d’évoluer dans des environnements favorables (autrement dit où on ne se fait pas trop emmerder) sont en ce moment innombrables.

Cela dit, ce serait bien que les choses changent. Mais ce sujet mérite lui aussi un article complet (et je suis sûr qu’il y aura un lien avec le dernier épisode des castcodeurs)

La structure du marché informatique en France

Cet article correspond à un sujet qui me tient de plus en plus à coeur, qui explique beaucoup de choses, (et dont j’ai déja parlé à mes collègues) mais dont j’entends peu parler.

L’histoire rêvée de l’informatique

Quand on parle de l’histoire de l’informatique, les premières choses auxquelles les développeurs pensent (et pas qu’eux, encore que je ne suis pas sûr que Catherine Dufour – la trop peu célèbre autrice d’une biographie d’Ada Lovelace – soit disqualifiée comme informaticienne) est Ada Lovelace, la déesse tutélaire, Alan Turing et son test ou encore Von Neumann et ses machines. Ces éléments sont certes intéressants, mais ils font partie d’une histoire fantasmée, d’une espèce de récit national. Et si, pour de trop peu nombreuses personnes, l’histoire est une science, pour le plus grand nombre, l’histoire est un moyen de définir son identité.

Et cette définition des informaticiens comme des héros incompris colle avec la démographie, à défaut de coller avec la réalité.

Or, comme je l’écrivais, l’histoire est souvent un moyen de définir son identité. Si au lieu de regarder du côté des développeurs, on regarde du côté des entreprises, le site du CIGREF présente une histoire de l’informatique vue par le spectre des entreprises particulièrement intéressante, et que je me permets de me recopier ici.

Merci patron !

Si on regarde cette préhistoire de l’informatique, on constate que Bull, IBM existent avant les travaux de Turing. Et ça n’est pas un hasard, parce que ces entreprises fournissent alors des machines d’automatisation et de comptabilité. Et la comptabilité, avant tout, c’est une source de coûts : avant ces machines, il faut des calculateurs, souvent humains, par dizaines, voire plus (c’est d’ailleurs ce qui s’est passé à Los Alamos, qui rassemblait pour le projet Manhattan tous les étudiants américains sachant compter). Et comme souvent, la guerre sera un terrible accélérateur qui permettra à ces entreprises de faire le virage de l’électronique, puis de l’informatique : dès les années 70, les ordinateurs nécessitent des systèmes d’exploitation, des langages de programmation plus performants.

Mais qui dirige ces innovations ? Les laboratoires de recherche ou les grandes entreprises ? Mon point de vue est évident : l’informatique est apparue comme un outil d’optimisation des coûts, en effectuant les calculs plus vite (plus correctement, et pour moins cher) que des humains. Et c’est à mon avis en accord avec le fait que, pendant longtemps, l’informatique s’est cantonnée dans les entreprises au back-office … Parce que l’informatique a été vue, historiquement, comme un outil de comptable : un moyen commode de connaître la santé d’une entreprise sans pour autant déployer des armées de comptables dans tous les services.

Et cette « histoire alternative » n’inclut évidement pas certains événements récents, qui font partie de la révolution industrielle de l’informatique : l’explosion de l’ordinateur individuel, la transformation du monde par internet, la première bulle des startups de l’an 2000. Pourtant, je pense que ces différents éléments restent explicables dans ce cadre.

Mais en France ?

Si cette vision est à peu près globale jusqu’en l’an 2000, l’explosion d’internet précipite toutefois une bascule géopolitique : les états-unis prennent nettement le pouvoir dans ce domaine, reconnu dès cette époque comme essentiel (peut-être que les liens entre les start-ups de l’époque et les agences de renseignement ont aidé). Alors qu’en France … il ne se passe rien.

Et c’est bien normal.

Un jour, je détaillerai pourquoi la France n’est plus un pays techno-scientifique (n’hésitez pas à me le demander en commentaires). Disons pour l’instant que les patrons d’entreprise sont plus souvent issus d’écoles de commerce que d’écoles d’ingénieurs, et qu’il en va de même des responsables politiques.

Toujours est-il qu’en France, une révolution technologique, ça n’intéresse pas grand monde, sans doute parce qu’il n’y a pas de leader technologique mondial en France. De ce fait, l’informatique, qui est devenue aux états-unis un moteur de croissance, reste en France un centre de coût. C’est-à-dire une capacité technique (par opposition à un élément du métier) que les entreprises souhaitent acquérir à un tarif validé par les comptables.

Et c’est là que Quentin Adam entre en scène

Enfin, Quentin, et une petite explication sur les ESN

C’est quoi le rapport avec les ESN ?

Parce qu’après tout, une ESN est simplement une entreprise de services numériques, non ? Elle offre à ses clients une prestation technique, non ?

Je pense que, dans la plupart des cas, une ESN offre un tout autre service. Si on comprend l’informatique comme un centre de coût et non un moteur de croissance, il est important de limiter ce coût. Pour le limiter, le plus efficace (en France) est de ne pas recruter de collaborateurs dans l’entreprise, parce que ça coûte cher, et qu’il est long et difficile de s’en séparer. Et c’est le service fondamental qu’offre la plupart des ESN : fluidifier la gestion de la masse salariale en permettant aux clients de disposer facilement de personnel qualifié au moment opportun.

Que je sois bien clair.

Cet objectif n’a rien de mal ni pour le client du service ni pour le fournisseur de ce service.

Mais il faut bien comprendre quelque chose : ce service n’a aucun rapport avec la production du logiciel ni avec sa qualité.

Et ça explique à mon sens pourquoi l’informatique reste, en France, un sujet de plainte chez la plupart des gens : si la qualité du logiciel produit n’a que peu de rapport avec la qualité de la prestation réalisée par un sous-traitant (et croyez-moi, les ESN conçoivent leurs contrats de prestation dans le but express de ne pas inclure la qualité technique de la prestation technique dans l’évaluation du projet, avec l’accord du client), il est évident que les logiciels réalisés, dont notre vie dépend de plus en plus, sont d’une qualité aléatoire.

Qui plus est, les ESN n’ont pas intérêt à développer des logiciels polyvalents, puisque ça limiterait le nombre de prestataires de service placés chez les clients. Pour aller plus loin, les ESN n’ont pas vraiment intérêt à permettre l’apparition d’éditeurs de logiciels, sauf ceux permettant de multiples missions d’adaptation, comme le permettent les fameux logiciels d’entreprise qui apportent une plus value douteuse, simplement parce que l’éditeur et l’ESN fournissant l’intégration sont motivés pour vendre des prestations, plus que pour fournir un service optimal.

C’est un tableau assez sombre, et malheureusement je ne sais pas trop comment en sortir. Qui plus est, ce tableau a des conséquences qu’on verra plus tard …

L’enfer de la mise à jour Android

Donc, j’ai chez moi une tablette légèrement obsolète (et surtout non mise à jour par son fabricant).

Puisque je déteste jeter du matériel encore en état de marche, et que la réutilisation est la clé d’un un umérique responsable (oui, c’est une référence subtile au précédent article), je me suis dit que j’allais chercher si il existe des voies moins officielles que les mises à jour constructeur. Evidement, ça existe, sur des sites russes ou autres étrangetés putaclic. Sans doute parce que c’est loin d’être simple. Jugez plutôt …

Pour changer de distribution Android, il faut

  1. Devenir root (avec KingoRoot ou autre)
  2. Changer le recovery Android (puisque c’est une espèce d’OS allégé qui permet quelques opérations basiques) par TWRP qui permet de flasher des images, de faire des backups et des restaurations de l’OS installé
  3. Trouver une distribution compilée pour cette tablette Lenovo 18-50 (ou A5500-F, selon les endroits)
  4. Flasher cette distribution
  5. Ajouter les applications Google évidement interdite de présence sur les distributions Android open-source

Ecrit comme ça, ça paraît simple.

En pratique, c’est un peu l’enfer.

  1. Evidement, le root que vous avez trouvé peut ne pas marcher …
  2. Figurez-vous que Google a changé l’API permettant au recovery de flasher correctement les images (ce qui rend selon moi le terme de « flash » assez incorrect. Du coup, ceux qui vous recommandent naïvement la version « standard » de TWRP se trompent. Et pour trouver la bonne version de TWRP pour cette tablette, c’est l’enfer : j’ai fini par trouver, au fond du forum XDA, une version raisonnablement récente, malgré certains messages en russe 🤔.
  3. Normalement, cette liste d’images devrait être bonne, non ?
  4. Eh bien en fait, c’est au moment où on flashe une image qu’on se rend compte … que ça ne marche pas. En testant l’image resurection remix, j’ai évidement brické ma tablette (avec ce très chouette message « Kernel image incorrect!! »)
  5. Et en bonus, il ne faut pas oublier de télécharger la bonne version d’opengapps … Et chaque erreur vous coûtera cher.

Bon, et alors pour ce brick, il y a apparement une solution. Mais j’aime beaucoup l’idée d’enlever la batterie sur une tablette non démontable 😭. Bon, j’ai trouvé, hein, mais je commence à avoir un peu peur … Et puis il faut l’identifiant du chipset (à priori, ce serait un MT6582).

Et surtout, après avoir tenté de débricker cette tablette pendant littéralement des mois, je n’ai atteint aucun résultat et transformé du matériel qui marchait en matériel qui ne marche plus, ce qui est l’une des choses que j’aime le moins.

On s’arrête, et on respire bien fort

Au pied du mont Margeriaz

Ces trois dernières semaines, je voyais cette montagne depuis mon lieu de vacances du matin au soir. Et c’était bien.

J’ai fait de la marche à pied (beaucoup), un peu de bateau sur le lac du Bourget qui n’est pas loin, un peu de jeux de société (dont quelques parties de BloodBowl aussi acharnées que spectaculaires).

Et puis contrairement aux autres années, je n’ai pas du tout pensé au travail.

En revanche, en rentrant, j’ai fait le point sur mes quelques dernières idées (c’est le bon moment). Je vais donc abandonner quelques projets qui n’étaient pas fait pour être réalisés

  • Le plugin Keepass qui aurait permis de saisir automatiquement les chiffres dans les calculettes des sites bancaires. J’abandonne parce qu’il faut me mettre au C# et lancer une API de détection de chiffres dans l’image
  • Le bout de code Python à lancer dans OBS pour générer des génériques de fin de réunion. L’idée est belle, mais je n’ai rien réalisé sur ce sujet.

En discutant ce matin avec un collègue, je vais faire exactement ce que je lui ai recommandé : je vais noter soigneusement chaque idée et essayer d’en noter autant de détails que possibles (sans doute dans un coin de ce blog) avant de juger de leur faisabilité ou pas.

Ca me permettra de décider si je dois me lancer dans une implémentation de la version de BloodBowl que j’ai chez moi en application web (spontanément, je pense que c’est une erreur, mais j’ai envie de tenter une fois dans ma vie de développer un jeu vidéo)

lftp, c’est quand même mieux

Vous savez que depuis des années, j’essaye de maintenir à peu près à jour un lifestream chez free, à partir de mes contributions sur WordPress, Shaarli, Goodreads, … J’ai un gros bout de code Java qui génère le site web localement (assez lentement, mais ça n’est pas grave pour l’instant). Mais jusqu’à aujourd’hui, j’avais un autre problème au moins aussi pénible : l’upload sur ftpperso.free.fr. J’utilisais WinSCP et son mode de synchronisation, mais d’une part c’était très lent, et surtout, WinSCP semble ne pas être capable de bien gérer le maintien des connexions avec free.fr. Du coup, j’avais des tonnes de déconnexions. Un truc vraiment pénible.

Je savais bien que ça venait en partie du fait que j’envoyais quelques milliers de petits fichiers, plutôt que quelques gros fichiers. Alors en réfléchissant un peu, je me suis dit que je pourrais envoyer un ZIP que je dézipperai sur le serveur. Par exemple, ce script PHP permet de dézipper localement un fichier. Malheureusement, la version de PHP disponible sur free.fr n’inclut pas le support des fichiers ZIP. Du coup je me retrouve avec des messages d’erreurs pénibles : « Your PHP version does not support unzip functionality. ». Bref, ça ne marche pas.

Alors, en désespoir de cause, je me suis dit que je pouvais revenir aux fondamentaux. Le fondamental du client ftp, c’est évidement lftp. Et donc, en cherchant un peu, je suis tombé sur ces exemples de commande lftp. Et en particulier sur cette commande, qui répondait bien à mon besoin : mirror -R.

Résultat ? C’est un poil plus rapide :

lftp nicolas.delsaux@ftpperso.free.fr:/lifestream> mirror -R
Total: 141 directories, 2681 files, 0 symlinks
New: 25 files, 0 symlinks
Modified: 1487 files, 0 symlinks
123219275 bytes transferred in 7127 seconds (16.9 KiB/s)
To be removed: 399 directories, 11059 files, 0 symlinks

Evidement, 7127 secondes, ça paraît long (ça fait 1 heure, 58 minutes, 47 secondes). Bon, ça paraît long, mais au moins, ça marche (parce que les transferts avec WinSCP avaient une sale tendance à planter au bout d’une heure). Autrement dit, ça marche bien mieux !

Maven – smart code, dumb pipe

J’ai eu la chance ces deux derniers jours d’animer une formation maven. Oui, en 2021, il y a encore des gens qui ont besoin d’être formés sur cet outil.

Pendant ces deux jours, j’ai parlé abondamment des qualités de maven.

Parce qu’il a plein de qualités, évidentes ou pas :

  • La gestion de dépendances, évidement, qui fait partie des apports fondamentaux
  • Le cycle de vie, qui augmente considérablement les chances de pouvoir faire des builds corrects
  • Mais aussi, et surtout pour moi, le côté « chiant as a service »

Parce que maven n’est pas un outil commode à tordre. Il est rempli de postulats sur la bonne manière de construire un projet. Et souvent, ces postulats rentrent en conflit avec l’envie des développeurs d’ajouter de l’intelligence dans le build. On retrouve cette discussion notamment dans cet échange sur Hacker News : l’article initial dit bien que maven est limité parce qu’il s’appuie sur des plugins sans être turing-complete, ce que disent également les commentaires.

De mon point de vue, c’est une erreur conceptuelle.

Maven, comme je l’expliquais hier, est l’un des premiers maillons de la chaîne d’intégration continue.

Et comme Kafka a réussi parce que c’est un tuyau idiot, je pense qu’une bonne chaîne d’intégration continue doit être idiote. C’est-à-dire accomplir simplement les différentes étapes amenant le code de la machine du développeur jusqu’à la production. Et pour ça, avoir un outil comme maven qui pousse les développeurs dans la direction de la simplicité est, à mon avis, une bonne idée.