Archives d’Auteur

Post CDI 2.0 talk clarification

novembre 26, 2014 Laisser un commentaire

Recently Antoine Sabot Durand, co spec lead of CDI 2.0, went to the ElsassJug to present his (ongoing) work.

After the talk, I was pressed by some to share my views and was at the same time advertised as a « CDI hater », which doesn’t help sane and sound discussions.

I had to leave early (public transportation has its drawbacks) and thus hadn’t planned to speak, yet I did in a hurry and unformalized way which ended being some crappy rant. Thus, here are my apologies to Antoine and a more proper presentation of my thoughts.

Let’s dig in 🙂

CDI 2 : Programmatic binding possible but not out of the box

CDI 2.0 should see the integration of DeltaSpike work into the standard: users will finally be able, in a standardized way, to hook into the binding definition process, when the application starts.

While nice and needed, the chosen way is complex, with plenty of hooks and concepts to master, including a DSL over annotations.

Furthermore, it allows plenty: you could easily break completely your stuff, not even speaking of corner cases’ bugs. So, it’s not for the usual & common coding actions, but something to approach with care and time.

For sure, yet, such a mechanism was deeply needed, due to the early reliance on annotations, conventions & beans.xml for binding definition. Somehow a programmatic approach ended up being needed, who could have guessed?

However, the main use case I see for a dependency injection framework is something close to the following :
if (foo) bind(A.class).to(C.class) else bind(A.class).to(D.class)
This isn’t supported out of the box.

For sure, now, one could implement such mechanism on his own, all the hooks are there. But I don’t want to: it’s complex and comes with extra « rules » which I would like to see implemented as well, like for example to fail if the same binding is defined twice programmatically. This is extra work, bug prone and core to a DI framework: I want to reuse something which is common knowledge of the framework.

So here are my 2 cents on this topic: in CDI 2.0, deprecate alternatives in beans.xml (and everything in there actually), make it all possible through the binding definition process. So binding configuration would be a matter of XML, for the default/simple stuff, completed by programmatic bindings if needed. Then provide a proper way to do programmatic bindings, based on the above hooks but readily accessible to the usual dev for everyday work. Keep the above hooks for funky needs.

Qualifiers are actually way more…

Due to the (previous) lack of programmatic definition of binding, CDI has full blown support for qualifiers. This means annotations to specify which implementation to actually provide. On top, one can stack many qualifiers on the same injection point, plus pass some parameters through the annotations for the implementation provider…

In fact, qualifiers are so common in CDI they provide a way to do an annotation aliasing various qualifiers (a stereotype annotation as it’s called).

Sounds good to you?

Well, not to me. Yes, a qualifier is sometimes needed when the same interface has different implementations for different contexts. But it’s a convenience stuff provided by a DI framework. Indeed, one could actually create a new class/interface and bind it instead, skipping the need for qualifiers. And one should avoid, in client classes, to provide to much things about the injected service. I mean, the whole point of injection is to avoid implementation related details isn’t it?

Yet, in CDI, they seem so common the speaker himself spoke of annotations hell. Furthermore, the ability to provide parameters looks error prone as well. The example given was the following:

@Inject @HttpParam("someParam")
private String someString;

The provider then looks up the « someParam » and returns the matching value.

This has multiple drawbacks IMHO.

For example, the dependency of this class on the RequestContext is hidden, which doesn’t help, both for readability and proper dependency tracking. For example, Antoine rightly said that this could be an issue when no Request where at hand in the current context (for example creating brand new instances of Request for one time use on each call).

But the main issue here, IMHO, is to have runtime behavior depending on annotations, for example what if at runtime I need other params?

One could say « no worries, put them as well in the annotation ». And then you start to alter your design to adapt to CDI. Bad. And limitating: maybe you really want to get some value just once in a while and not every time, so the injection would be unneeded & clutter all the time. Worst, you can’t interact programmatically easily there: there’s no matching programmatic way to access such « injection outcome ». Well, actually, in CDI 2.0 they should provide hooks to get the « injector » and do stuff programmatically, but this is planned for third parties integration, not every day, proper, CDI code.

It really hilights the conceptual issue: it’s not about injection anymore, but interaction with a service. I don’t want annotations for that, it’s the wrong concept. Actually, I fear this code smell to become widespread: to provide services actions through annotations could become widespread and code smells waiting to blow up on their users.

Which leads me to a third issue with CDI, directly coming from this: the event bus.

An event bus… to avoid IMHO

Among the CDI annotations, some come regarding an event bus. With it, one can « fire » and « observe » events, using qualifier annotations to qualify which one(s) we want to observe (on top of the event type itself). Be cautious though, the qualifiers don’t work with event as they work with beans (different type handling mechanism). One can also use « Conditional Observer methods », for example:
public void processQualifiedPayload(@Observes(receive=ALWAYS) Type1 event) {}

The observers are triggered in a synchronous way: all must have finished their observations for the code of the fire to go on. On top, the events are mutable and we were told one could even go as far as modifying them on the go. Finally, these events are local to the current VM instance (or container even, I’m not sure) and… that’s it.

Being interested in event driven architecture, this implementation seems pretty weak to me.

First of all, API wise, conditional observer part is pretty weak: hard coded strings for the win! Or not… A proper method call, maybe with enum, would be ten times better isn’t it? Maybe one could be as crazy as providing some filter function.

More importantly: how do I monitor these events? What if some fire too many of them? What if I want to persist them? What if I want to timeout the observers’ actions?

Sure enough, I was told this stuff was limited and one should use it properly, meaning for none of the above use cases.

On top, asynchronous events should come in CDI 2.0, and maybe as well some way to persist, broadcast or order the observers. All through annotations AFAIK. Annotation hell anyone?

In fact, one real use case of events is for the binding mechanism from DeltaSpike: it’s partly based on events, to allow people to hook at given points in the cycle (they observe these events).

While a valid use case, the semantics at play are completely at odds with asynchronous events, persistence and broadcasting. Wanna broadcast/persist your wiring events anyone?

So here are my 2 cents: remove the event bus from CDI 2.0.

Instead, change it to do a configuration specific DSL used to hook into the startup phase. Then have a new JSR regarding a Java EE event bus, and do proper stuff there, not relying on annotations for all of its public API…

On a broader level, remove/deprecate parameters used by the provider from qualifier annotations, to avoid code smells. Qualifiers should be used to qualify, no more no less.


That’s the main points I wanted to raise after the talk, hopefully done this time in a proper way… Let me know !

On a bigger picture, CDI is usable for sure. It does its job roughly. If I had to use it, I would, taking care of avoiding the above pitfalls. Yet, in its present state, I prefer to avoid it.


Étiquettes : ,

Event driven architecture should be a must go (esp. for client side JavaScript)!

While reading Getting Started with Twitter Flight, I realized that only events provided an effective decoupling between data producers and consumers. Not Object Oriented Programming. Not services. Sounds crazy? Sounds wrong? Read on and let me know.

At first, with events, some benefits immediately pop up:
– internal changes have not effect on external code. None at all. No renaming or bigger change affect the other components, even the ones depending on this component (as long as the event itself is untouched).
– willing to change the event? Just have a look to who depends on it. No need to try to track use of some service/object/whatnot all the way through your application. And in JavaScript, doing so would be especially bad: no type, no compiler. Only plain text search through methods name (at best). Good luck with that. And if others depend on your code, well, they’re basically screwed. With events, it’s way simpler to do changes. Even deciding to version public events could be easy.

But, actually, events provide way more: they decouple events producers from listeners. Sounds trivial, for sure, but going deeper it means no need to inject some service, register somehow somewhere for callbacks, no need to look at an object with plenty of methods/stuff in it. The API to communicate with others parts of the software is actually uniform! You won’t have a specific way of doing it for each need. You just want the payload, no need to read some non existing documentation to figure out to use the crap.

The mental noise is tremendously reduced. You need to signal something to others? Easy, fire an event. You want to know of something? Easy, listen to the event. That’s true decoupling, way more that some abstract FooService with plenty of methods, related objects and extra funky behaviors or dependencies. Just the stuff you need, always through the same mechanism.

What does it mean in practice?

Well, very nice stuff:
– willing to test something when receiving an event? Plain simple, just fire it! No need to mock or whatnot the sender.
– needing to add 10 new ways of firing the same event in the UI? Plain simple, you just fire the event in the new places and all the listeners will get them. No need to change the listeners!
– you need to kill some component and fire the same event in a different way? Fear not, delete without looking anywhere else and produce the same event wherever you need it.
– you rely on some external component that you want to swap for something better. For sure, since you’re on the UI side, you didn’t code defensively. So you’ve plenty of reference to the old component’s events. Screwed? Not at all, write a component translating the events from the new format to the old one and… done!

Such ease of coding is something I would love to have whatever the language, be it Java, Scala and even more JavaScript, which has way less tooling for code exploration and refactoring.

It made me realized a funny point: Object Oriented Programming (OOP) came with the concepts of objects to encapsulate logic and data, and (public) methods to communicate with others objects. Actually, in the beginning of OOP, methods where sometimes called messages. It’s still used and visible in Ruby nowadays. Theses messages were supposed to help decoupling. The internals would be nicely hidden from the others, only the stuff needed by the outside would be visible.

Yet, in fact, you can’t get the message/public method without the object. And the object doesn’t come for free. You need to get an hand on it, to figure out what it intends you to do and so forth. The decoupling aspect of methods is pretty bad in the end. Whereas for events, it’s all bright and sunny 😉 You can get the message without the object mess. Crazily good no ? And you can change the internal, even drastically (aka delete), without affecting the outside at all.

It sounds like the Single responsibility principle done right isn’t it? Damned, I tried for so long to do that in plain old OOP…

Anyway, thanks a lot Tom, the author of Getting Started with Twitter Flight, for having made me realize this point so clearly.

All is not rosy though for sure. Infrastructure code, utilities, libraries and the like may still be used in many different parts of the same application. However, this kind of code is generally pretty focused, trying to do one thing well, and has few, if any, state. As such it’s easily testable and refactoring is seldom needed. Should the need arise, it’s generally pretty strait forward. Domain related code is a completely different story: state is everywhere, refactoring frequent. So an event driven architecture, if only for domain and application level code, already provides plenty. And is, IMHO, way better than all the alternatives I know of as of now.

Étiquettes : , , ,

Book review: Growing Object-Oriented Software, Guided by Tests

mars 17, 2014 1 commentaire

Not being fully satisfied about my TDD practices, I was reading The Failures of « Intro to TDD », which sums up nicely bits of the uneasiness I’m facing and offers a nice way of handling it. While tweeting about the article, I was once more told to read Growing Object-Oriented Software, Guided by Tests, and so I finally did and here is my feedback on it 🙂

Lire la suite…

Étiquettes : , , , ,

Présentation Coder propre en ligne :)

février 20, 2014 1 commentaire

Presque un an après les quelques confs sur le sujet, j’ai enfin pondu la version oueb présentable, par là : Coder Propre

Un bon bout de temps me direz vous ? En effet, mais le hic était que la présentation initiale était « zen ». Autrement dit, des diapos minimalistes, avec très peu de contenu afin de préserver autant que possible le discours. A priori ça avait plutôt bien marché, mais par contre, traduire ça en présentation à lire, galère… Sans compter que le bébé était en impress.js, soit pas quelque chose qui ait prévu dès le début d’avoir des notes associées…

Bref, pour la prochaine fois, je me dis que peut être je ferai le tout direct en diapos. Certes, ça rend moins bien qu’une présentation JS avec des transitions minimalistes et sympas. Mais bon, c’est ensuite bien plus simple à mettre en ligne, surtout quand on se dit que cela pourrait être utile pour plus tard à l’auditoire.

A propos, si vous en faisiez parti, ne soyez pas surpris si le contenu diffère un peu de la présentation : le format m’a fait réaliser quelques coupes. Des bouts qui étaient à priori confus et que je tentais d’éclaircir par le verbiage l’ont été à la hache.

Bref, tout retour bienvenu, comme d’hab, et voyons si j’ai le courage de m’atteler à une présentation du Domain Driven Design, la suite logique, AMHA, de la présentation de l’an passé 🙂


Étiquettes : , ,

Book Review : Implementing Domain-Driven Design

février 11, 2014 Laisser un commentaire

I had a bit of free time recently (I guess finishing the 15 books of Games of thrones I was given did help as well lol), so I could tackle some books resting on my shelves. Among them, Implementing Domain-Driven Design, by Vaughn Vernon.

Well, first of all, contrary to Mobile First Bootstrap (cf previous review), Implementing Domain-Driven Design is a massive kind of book: about 600 pages. With plenty of code samples. And actually, that’s were, IMHO, the book is a pain: it goes too much into details. I don’t care too much of Spring xml config. Or some coherence API details. Or some REST based communications between parts of the same application (heck, is it really a good idea anyway ?). My mind is set more on akka, and turns out Vaugh Vernon just as well.

The level of details and the lengthy code samples really killed my attention times and times again. It’s a pity. A first the book starts well, Vaugh Vernon does a great job highlighting the usual pitfalls of non Domain Driven Design. It really rings a bell quite a few times. But then, the technical details get in the way, especially for opinionated coder like me. Supposedly immutable value objects without final fields always hurts me. The extensive use of static methods as well (I just remind one « disclaimer » saying it was for the sake of concision, and pretty late in the book).

That’s why, I think, very detailed and framework related code samples are quite a gamble in a « design level book » : if you don’t care too much about the frameworks and some code hurts your eyes, you tend to forget about the design level stuff.

It wasn’t all bad, for sure. It was nice to go through, again, the ideas contained in Domain-Driven Design: Tackling Complexity in the Heart of Software (I wrote a review on it in 2010, here). Some refreshers were really welcomed.

Another aspect which disappointed me was a feeling of a lack of « hands on » feedbacks, of first hands experiences/insight. When reading Uddi Dahan, for example, there were plenty of times where I thought « yes, that’s the issue, he nailed it ». It almost didn’t happen on Implementing Domain-Driven Design. Maybe the burden of detailing Spring and the others chosen stacks killed the « light revealing » feedbacks, the perls of wisdoms which really help one progress. Maybe, as well, I’m biased there: I’ve read a lot on the matter, played with akka persistence, helped Uwe creating his homegrown CQRS framework (still unpublished by the way, isn’t it mate ?). And I’ve plenty of design/implementation related questions in mind which haven’t found their answers yet, but maybe only walking the path would provide them. Yet, nothing about handling eventually consistency in the user interface in the book for example, despite it being quickly an issue, potentially at least, in event driven systems. What if events change over time, how to handle such changes in the event store ?

So, to sum up, if you’re planning to use Spring and some RESTish stuff, the details could be a real enhancement of the book. Otherwise, like me, I fear they risk to wear you off quickly, killing the interest of the book. Furthermore, if you’re a lot into event driven/CQRS and the like, these parts aren’t handled with too much details, more as an overview, which might disappoint as well.

Well, I feel a bit hard. I hope I’m not unfair and that my disappointment doesn’t make me harsh. If you think so, let me know…

Étiquettes : , , ,

Book review : Mobile First Bootstrap

février 11, 2014 1 commentaire

The other day, I was trying to grab a free copy of Getting Started with Twitter Flight, but instead I got a choice among a few titles and settled for Mobile First Bootstrap. Why is that ? Well, I’m mostly a Java developer, and there is no plan yet to move our 10 years old web app to something recent, but still I’m willing to keep an eye on Mobile First and the like, so I gave Mobile First Bootstrap a try.

In short, with my limited daily use of html and mobile related web apps, it was really instructive. The book does a lot to present the differences between desktop and mobile and provides helpful ways of solving them both. Well, actually, turns out the help comes from the third version of Bootstrap, but still, the overview and the solutions presented are interesting. For example, the way Bootstrap components display differently depending on the resolution is really impressive. And it’s not something straightforward to get by just looking at the github project, as I did before.

I like as well the way tools and useful libraries are covered… My coworkers already had some samples of it. IMHO it’s a part which is always bit tricky to get purely online (which tools, which libraries to go to for what), so I really appreciate.

However, I feel some parts would have deserved a deeper coverage, especially the bit about touch enhancement through jquery mobile, which then interacts with Bootstrap own’s JavaScript. If ever I want to go more into this direction, I would have to dig around significantly: the book doesn’t provide enough leads, IMHO, which it does for the rest.

In terms of target audience, I guess people already pretty familiar with Bootstrap would already know most of the content of the book. Neither does the book contain any extra hint on how to make the latest crazy hot design magic.

In the end, a book worth reading, putting my web design knowledge on a better foot. Exactly what I wanted !

Étiquettes : , , , , ,

Enseignants en informatique… enseignez l’informatique !

janvier 27, 2014 3 commentaires
Billet d’humeur qui dormait depuis longtemps sur mon disque, écrit avec passion et qui m’a bien apaisé… Puisse t il en faire autant pour vous !
Récemment encore, une soutenance. Projet de l’étudiant ? Faire du développement. Réaction des professeurs ? Allons, tu es bon, tu devrais viser chef de projet.
Ca a à tout l’air d’une boutade ? Que nenni, école après école, même rengaine.
Attention, scoop : il existe des formations pour être chef. Si si. On appelle cela des formations en management. Ceux qui désirent être chefs y vont en général. Et voici un autre scoop : la plupart des étudiants en informatique ne veulent pas être chefs. Si si. Je ne sais pas bien pourquoi chaque école d’ingénieur, ou presque, reprend le mantra du « tu seras chef, jeune ingénieur », mais il se trouve que certains étudiants sont plutôt attirés par les connotations scientifiques et techniques du mot ingénieur. Genre résoudre des problèmes, progresser, apporter des solutions innovantes, plutôt qu’encadrer.
Pas d’inquiétude, j’entends déjà les arguments habituels : nous leur apprenons à apprendre. Ils sont intelligents et s’adaptent : ils ont les bases, la suite est aisée. 
Les enfants de 10 ans aussi ont les bases du langage. Ils savent lire, écrire, compter même. Ils peuvent reproduire des choses déjà vues. Pourraient ils pour autant rédiger un acte notarié ? Comprendre une notice technique ? Ecrire un roman qui présente un intérêt pour le lecteur ? Bien qu’il y ait des exceptions, dans l’immense majorité des cas la réponse est non.
Figurez vous qu’en informatique c’est pareil. Connaître et avoir vaguement pratiqué les bases d’un langage ne suffit pas. Connaître les bases d’un langage ne permet pas de développer correctement en utilisant ce langage, ni même de se qualifier d’informaticien. En toute franchise, apprendre un langage est devenu trivial de nos jours. Plein de personnes, de tous horizons, le font de leur propre initiative, sur le temps libre, aisément, sans encadrement scolaire. C’est facile à faire, après tout, on a tous déjà appris un langage… Ces personnes sont elles pour autant des informaticiens ? Des personnes hautement qualifiées ? J’en doute. 
En fait, en pratique, c’est même quasiment l’inverse : les premiers jets dans un langage sont généralement primitifs et guère attrayant. Pire encore, passé le cap initial requiert de l’approfondissement, de la réflexion, de la pratique. Combien font cette démarche ? Combien d’entreprises ont elles les moyens ou l’envie de les y accompagner ? D’ailleurs, figurez vous, les entreprises en général ont une perception proche de celle des écoles d’ingénieur : faut devenir chef. Pour ça, pas besoin d’être bon informaticien, mais plutôt de suivre les ordres et reproduire l’existant. Rien ne permettant ou favorisant l’apprentissage nécessaire et, pire, la mise en pratique résultante.
J’en fais trop me direz vous, qu’y a t il de bien compliqué à l’informatique, à la programmation ? Quelques pistes, en vrac, à titre d’illustrations…
Etre informaticien, c’est connaître les différentes façons de résoudre un même problème, avec à chaque fois les forces et faiblesses respectives. Vous voulez accéder à des données en base ? Plusieurs possibilités. Utilisation d’une classe pour chaque table, représentant simplement les données, puis avoir des utilitaires pour peupler ces classes. Utiliser des classes encapsulant une bonne partie de la logique d’accès, voir exposant des types évolués. Avoir un modèle objet riche, avec héritage, composition, au plus proche des besoins, que l’on adaptera ensuite à la représentation en base. Avoir un stockage des données sans représentation commune avec l’usage qui en est fait, avec un mécanisme de récupération et construction des structures utilisées. Combien d’élèves connaissent ces approches ? Combien en connaissent les forces et faiblesses ? Combien d’enseignants ? Attention, cela n’a rien d’un secret jalousement gardé. Là encore, internet donne tout ça. Des livres existent sur le sujet (« Patterns of Enterprise Architecture » de Martin Fowler par exemple).
Mais en fait, l’informatique, c’est bien plus que cela. Etre informaticien, c’est savoir comment écrire son code pour qu’il soit lisible, juste et aisément modifiable. C’est éviter de faire une usine de gaz quand on veut simplement moudre le grain. Faire simple est l’ultime sophistication disait Léonard de Vinci (un ingénieur avant l’heure pour la peine, plutôt reconnu comme bonhomme). Faire simple est nécessaire en informatique : le code va vivre, sera maintenu par différentes personnes, devra répondre à des besoins non anticipés. Et faire simple s’apprend. Non des commentaires toutes les lignes n’aident pas. Non mille lignes de code à la suite n’aident pas. Oui on évite la double négation. Oui on fait du « fail fast »…
Mais en fait, l’informatique, c’est bien plus que cela. Pour limiter les risques, le code doit être testé. Et pas de façon artisanale sauce pré histoire, avec ses doigts et un gourdin, mais avec des outils automatisant la chose, exécutant les tests à chaque changement, de façon transparente. Ca parait fou, mais aujourd’hui c’est la norme pour les informaticiens soucieux de leur travail. Pourtant je n’ai pas encore vu un seul étudiant ayant appris la chose pendant ses cours. Je ne suis même pas certain que 20% des enseignants connaissent les notions de tests unitaires et intégration continue. 
Mais en fait, l’informatique, c’est bien plus que cela. Parce qu’en fait, généralement, on écrit pas du code. On reprend l’existant, on le modifie. C’est d’un coup bien plus compliqué. Il faut rentrer dedans, comprendre son fonctionnement. Il faut connaitre les outils disponibles : debugger (des élèves ingénieurs ne connaissaient pas), outils d’inspection du code (hiérarchie des classes, références vers une classe, appelant d’une méthode). Il faut connaitre les subtilités des langages, qui ont sans doute été utilisées de ci de là, souvent pour des pièces critiques de l’architecture (réflection, invocation dynamique, mixins, proxy…). Il faut connaitre les patterns classiques (factory, decorator). Et après il faut aller modifier tout cela. Faire plus propre que cela ne l’était (cas général) ou rester au même niveau que l’existant (l’exception). Cela a même un nom : le refactoring. Là encore, le nom est inconnu pour bien des étudiants et enseignants… Quand aux méthodes et outils associés, n’en parlons pas.
Mais en fait, l’informatique, c’est bien plus que cela. Le code n’est qu’une partie du tout. Il y a la construction du livrable. Le processus de déploiement. L’environnement de recette. Il y a les différentes versions au cours du temps. De son propre logiciel ou de ses dépendances. Ou même, en production, différentes versions au même instant afin de faire du canary release. Il y a la mise à jour sans interruption de service. Il y a le besoin d’avoir des informations de contexte en cas de bug, les informations permettant d’identifier le problème. Il y a la possibilité de savoir qui a fait quoi quand pour comprendre l’historique du problème, ses raisons, pour ensuite le corriger ainsi que tout le mal fait entre temps. 
Mais, en fait, l’informatique c’est bien plus que cela. Il y a les milles spécificités de l’environnement retenu. Du système d’exploitation, des serveurs, du réseau, des systèmes embarqués. Du web. Des sockets. Ces détails de l’environnement technique utilisé qui nécessitent toutes les connaissances ci dessus pour en tirer le meilleur. Mais cet environnement technique qui est un monde à lui tout seul, à nouveau. Avec ces bonnes pratiques, ces rouages essentiels, son histoire.
Mais en fait, l’informatique, c’est bien plus que cela. C’est déterminer ce que veut l’utilisateur, quand, pourquoi. C’est se mettre d’accord sur la solution, sa mise en oeuvre, en proposant le meilleur de ce qui a été énuméré jusqu’ici. Savoir que son environnement peut proposer telle fonctionnalité aisément ou que telle autre sera très longue et couteuse à atteindre. C’est trouver ce qui est déjà existant pour ne pas réinventer la roue. C’est livrer tout cela à l’utilisateur, s’assurer que ça lui convient, que ça fonctionne, que ça répond aux attentes. C’est s’assurer que la solution s’intègre bien avec son environnement, avec l’existant, les évolutions dans les habitudes et outils. Avec toujours un donneur d’ordre, des utilisateurs et des informaticiens. Dans les délais, le moins cher possible, correctement, le tout sur fond de communication permanente.
Au risque de me répéter, l’informatique, c’est, en fait, bien plus que cela. En fait, c’est tout cela, et bien plus plus, tout le temps, sans cesse en changement. Avec des gens qui réinventent la roue, des intérêts personnels, commerciaux, des à priori et beaucoup de choses non étayées. Des intervenants par millions. Aussi, aller de l’avant, c’est savoir se concentrer sur ses vrais problèmes. C’est avoir les bases nécessaires pour distinguer le bon grain de l’ivraie. C’est savoir déceler dans ce magma bouillonnant la perle qui résout votre problème. C’est savoir de ne pas suivre la mode du moment, comprendre les implications de ce qu’on lit, tout en sachant se remettre en cause. C’est oser de démarquer, se justifier. C’est se remettre en cause et remettre en cause l’existant, sans cesse, pour avancer, le tout dans un terrible brouillard confus d’intérêts, de bruits et de beuglards contradictoires. C’est se forger sa vérité dans tout ça, pour son contexte et ses besoins.
Aussi, je pense qu’enseigner l’informatique c’est comprendre que les bases ne sont pas suffisantes. C’est comprendre que l’informatique est bien plus, un métier à part entière, capable de remplir largement les quarante années à venir d’un étudiant. C’est comprendre que former des gens à même d’être compétents dans un tel métier est une chose difficile. C’est comprendre qu’en France, malheureusement, la plupart du temps, l’informatique c’est bien moins que cela, que ces compétences ne sont pas présentes, pas prisées. Qu’il va falloir changer les habitudes afin de produire réellement de la valeur ajoutée. Quitte à bouleverser quelques hiérarchies et à recentrer l’enseignement informatique sur… l’informatique.
J’espère sincèrement que des enseignants ont lu ces lignes. Elles sont pour eux. Pour que leurs discours et leurs enseignements soient plus en accord avec mon quotidien d’informaticien. Pour que l’enseignement évolue enfin. Clairement, c’est un acte isolé, mais néanmoins murement réfléchi, présent depuis mes débuts professionnels. Et j’espère que, petit à petit, l’enseignement de l’informatique en France changera pour le meilleur. Si cette contribution aide à cela, alors cela me va. A vrai dire, pour avoir donné des conférences sur le « code propre » et avoir refusé les offres d’enseigner qui ont suivi, le fond de ma pensée est qu’il serait temps que les enseignants en informatique enseignent vraiment l’informatique. Et je suis plus que volontaire pour aider, mais pas pour faire leur travail à leur place : je n’ai déjà pas assez de temps pour … l’informatique !
Étiquettes : , ,
%d blogueurs aiment cette page :