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.

Conclusion

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.

Best
Joseph

√Č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 : , ,
Suivre

Recevez les nouvelles publications par mail.

%d blogueurs aiment cette page :