Posts Tagged ‘en’

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 : , , , ,

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 : , , , , ,

CloudBees talk at the ElsassJug

Yesterday night, Sacha Labourey came to the Elsass Jug to introduce CloudBees.

It was pretty nice to see Sacha IRL: he’s a very friendly and humble person (while being, for those not knowing him, creator and CEO of CloudBees after quite a career). It’s really easy and interesting to speak with him so go and get him whenever you need/can.

CloudBees specializes in using the clouds resources and tools for developing and running Java (web) applications (Platform As A Service way). It’s what they call their Dev@Cloud and Run@Cloud.

Having Koshuke among their staff, the whole stack is centered around Jenkins: if you use it, then you’ll be like at home. Actually, you’ll be most likely better than at home: their jenkins come with slaves running each job (infinite scaling FTW) as well as the usual plugins plus some on top from third parties.

Roughly put, it’s a nicely already set up Jenkins environment, with some goodies like remote console line tools or Eclipse plugins. To me it really felt like all the tools you wanted to use with Jenkins but already there and waiting for you (like having slaves running the jobs to avoid bottlenecks).

The Run@Cloud part is also interesting: basically, once your jenkins jobs are done, you can decide to promote some to production. They are then deployed to your web apps. The web apps location(s) are pretty flexible: they can either host them (if I got it right), put them in some well known hoisters or, in fact, any cloud (as long as openstack compatible). Actually, it’s not only about web apps, they can also handle DBs (mysql only AFAIK).

One option I wasn’t aware of is that the deployment part can also be building images (VSphere ones, so VMWare) and push these images wherever you want. In line with their concept, looks like they handle the OS and stack parts of these images: you just have to put in your WAR file and you’re done. Sweet isn’t it?

For sure, they’ve plenty of goodies not spoken of here: they can have webdav based maven repos (you can also rent on top some artifactory), the monitoring tools for the running apps look great (again, the fancy tools you heard of but never bothered to actually put in use are available here) and so forth.

To sum up, they really aim on doing the « devops » part of development, so developers can concentrate on… developing. Not too bad isn’t it? In terms of target, they have pay as you go pricing and others one for bigger users.

One example Sacha put forward to showcase the whole concept is Loose It. Loose It is a mobile/web app helping you to loose weight. The interesting part there is that they’re only 5 developers and they’re able to deliver 1.5 millions users and up to 20 000 transactions per minutes. All this without scaling issues and dedicated staff. Just 5 devs in the wild. Well, for sure, I guess they owe CloudBees some money, but obviously only a fraction of what it would have costed them to handle it all on their own.

My thought being put to words, I’m off 😉


Side note: in case you wonder why this post is in english, it’s pretty straightforward: I wanted this dear uwe to be able to be able to read it, since his company looks like the perfect fit for CloudBees and… I would be eager to have some first hand feedback. Nasty me? You bet 😉
BTW, thanks uwe for proof reading this post.

Étiquettes : , , ,

mongoDB: 9 months on – conclusion

Article part of my « mongoDB 9 months » series:

First of all, if you made it till here, congratulations. I had much in my mind and I fear I wrote it too quickly, and even after some updates on different parts of the series I still feel poor with the way they’re written. I guess I’ll have to improve them over time. Hence, I would be eager to know how readers feel about it, so please, let me know!

Back to mongoDB, it’s a powerful tool, whose document orientation really help reducing the infamous impedance mismatch, thus greatly reducing mapping issues. Its indexation abilities, especially of « in document » lists, are also impressive, as are its performances overall.

This comes at the price of some radical technical choices: no join and no transaction (mostly).

Hence to me the following « rules » on when to use it:

  • Domain logic which can be mapped to document without needing relationships: go for it, mongoDB is the perfect match. Its high performance will do wonders. And since documents can embed so much, it actually means more than one could expect.
  • Domain logic with relationships and few if any transactional needs, where performance matters. mongoDB should be looked at. One should first carefully consider the handling of relationships. A proof of concept for it is a must have I think. The transactional needs are a different beast: one should make sure they could fit somehow in mongoDB non existing support for such things. And remember it’s highly unlikely 10gen will ever introduce new features there, due to its (potential) impact on performances. This actually leads me to the third point:
  • Domain logic with lot of needs for transactional operations: mongoDB doesn’t fit.

For sure, these are only my humble opinions and I’m eager to hear other ones.

Some side notes comes to my mind as well:

  • if ever a real need for transaction pops up, it won’t be solved for free. A solution will have to be found. For example, it could the limited 2 stage commit (more on it in the No transaction & limited ACID chapter). It could also be some other mechanism for ensuring transactional matters (some people went to mysql for this, but one could also consider something like JTA or, rather, multiverse). Finally, one could split the data in two between a « transactional able » DB and mongoDB. Anyway, the bottom line stays: transactions won’t come for free, whereas it’s a feature which is usually taken for granted due to the massive use of « traditionnal » RDBMS. This leads me to the next point:
  • Plan for quite some explanation about mongoDB choice. From JSON content and queries to document approach, all this without join and transaction, mongoDB has a lot which differs and which will, for sure, unsettle and disturb. It’s true for the developers, going away from their safe RDBMS land (« ugh, where is my transaction? »), to admin (« what, I can’t export to an CVS file? ») to business analyst/product lead with a past history in IT or some knack at it. They’ll all be surprised! Take the time to consider and win their heart & mind properly.
  • Plan to keep looking at mongoDB progress: new features will come often and bugs get fixed. One has to follow carefully not to miss some of them.
  • Finally, a point which I haven’t really spoken of it, but which matters as well: watch for your driver/mapping framework. It would be a pity for it to be the limiting factor, yet at the same time the limitation (mostly regarding type info) and flexibility of JSON makes the issue pretty hard, at least on the mapping side. On top of this, refinements like first and second level caches are still welcome performance booster. Then some support for relationships and their management would also be welcome. In the end, the driver business isn’t straightforward.

On a more personal matter, retrospectively, I’m also wondering if the approach of putting write and read all into (one) mongodb is the right approach. Indeed, de normalization means that, quickly, some decisions will be taken based on de normalized data which could be stale. Even without going so far, the documents can quickly end up being pretty messy, with de normalized content for specific views and the like. And still is lurking in the background the lack of transaction: how to be sure all potentially failing multiple updates in a row are well handled?

As such, my current interest in CQRS and EDA, which states the separation of view database and the write one, rings a bell. Indeed, mongoDB makes a perfect fit for the view database: it can handle both full text search and complex queries, yet being quite flexible in terms of mapping for your views. On the other hand, the write database could stick to some RDBMS able of join and transaction, where needed (which in CQRS should be less than in traditional « dump in all into the RDBMS » approach). Sure it may involve extra work, but if you choose mongoDB for write you weren’t afraid, most likely, of extra work anyway. And still, the clarity and flexibility given might well pay off quickly. Yet this is just wild thoughts: I hadn’t any occasion to test them, even if a akka/scala for events, some RDBMS for write and mongoDB for view feels like truly appealing to me.

Actually, I would also love a document oriented db for the write part. Basically mongoDB with better relationship support (from integrity constraints to join) and transaction would be perfect. Yet, while the relationship support can and is likely to improve over time, the transaction aspect feels like way more remote. It simply doesn’t match with the current performance minded approach and, furthermore, would imply a massive amount of changes… Pity!

Before we part, let me thank a hell of a lot codesmell, my tech lead, who has always been eager to endure my lengthy questions and talks on mongodb and related matters. Without him the current series wouldn’t have seen light, it’s as simple as this!

And don’t forget: I more than welcome your view on this series!

Étiquettes : , ,
%d blogueurs aiment cette page :