Category Archives: architecture

When Your Framework Gets in Your Way

These days, my framework of choice got spectacularly in my way. Don’t get me wrong: D3.js is a good framework. It was the right tool for the job. But it slowed my progress nonetheless.

You know, I wanted to write a particularly fancy presentation. Everybody knows PowerPoint slides by heart, and even a nifty presentation framework like reveal.js has become boring. But there that nice little framework I always wanted to play with. And there’s this nice interactive sunburst diagram. What about converting it into an interactive presentation? And while we’re at it, why don’t you translate the code to TypeScript?

This turned out to be a stupid idea. Luckily I’m not in a hurry, so I don’t mind, and the result is impressive indeed. But with a tight deadline it had been a disaster.

It’s not the first time I experienced this. Even the best framework comes at a price.
Continue reading

AngularBeans: A Fresh New Take on AngularJS and JavaEE

I’m proud to have convinced Bessem Hmidi to present his AngularBeans framework at AngularBeans is a fresh, new approach integrating AngularJS with a JavaEE backend and has stirred some attraction in the JavaEE world recently.
Bessem works at “Business & Decision” as a Technical Architect. He is also founder and leader of the “Esprit Tunisian Java user Group” and was a part of the Research & Development program at ESPRIT (Tunisian school of engineering). Bringing over 9 years of working with Java related technologies especially Java EE, he is also a professional course instructor, an educator and an international speaker. Plus, he’s founder of the Tunis conference JUG Day.


The Java ecosystem doesn’t lack of web frameworks. There’s a framework for every taste. No matter if you prefer an action based, component driven, request driven… there’s a framework for everyone.
But at a closer look on what happened those few last years in web development, we will be driven to accept the evidence: it’s the era of single page applications, of client side rendering and of the real-time web. Users have become much more demanding. They don’t put up with a single black-and-white terminal screen any more. They’re familiar with highly responsive, interactive user interfaces which are both more fun and more efficient to use.
Those needs are the sources of countless modern client side JavaScript frameworks such as Ember.js, react.js, meteor.js and of course AngularJS. They all consider the server a “pure” service provider, only responsible for processing and providing data, as opposed to the the classic “dynamic views generator” server. Most – maybe even most – developers consider server-side rendering a thing of the past. From a technical point of view, server-side rendering was inevitable in earlier times, but nowadays browser technology has evolved to a point that allows us to shift both rendering and business logic to the client side1.
Continue reading

  1. Footnote: there are exceptions. Client-side rendering is bad when you’re concerned about you mobile device’s battery life

The State of Polyglot Programming in 2016: Mission Impossible?

Once upon a time, they used to say every programmer has to learn a new programming language each year, just to stay in shape. When I mention this to Java programmers, they usually start laughing. What used to be true in the 70s, maybe even in the 80s and the early 90s, has become utterly impossible in 2016. Modern programming ecosystems like JavaEE have reached such a level of complexity that it has become challenging to master a single programming language, let alone a second.

Learning the core language is not the problem

Thing is, it doesn’t suffice to learn the language. That’s easy. Once you’ve learned an object oriented programming language, you’ll quickly be fluent in any other object oriented language. Only shifting to another programming paradigm may give you a hard time. I, for one, have to admit I never managed to wrap my head around PROLOG. It’s not difficult, but it’s so different from what I’m usually doing. My rich experience which is so useful at other times prevents me from being a successful PROLOG programmer. But the vast majority of modern languages follow the procedural paradigm, spiced with object oriented programming or functional programming (and in same cases, both). So there’s not to much a challenge from the language side per se.
Continue reading

Does Super-Fast Storage Impact Programming?

Now, that’s a disruptive change. Actually, it developed in the open, but still, I didn’t really think about it until today. We all have learned to love SSDs. My old company PCs used to boot for a couple of minutes, sometimes even for a quarter of an hour, before I could start my daily work. If you’ve got an SSD, that’s typically done in a minute, and if you’ve got a Mac, it’s a matter of seconds. The extreme being tablets and smartphones: Most of the time they run in stand-by, so they are just there when you need them.

Let’s think this to the end. Imagine that storing or retrieving data on your hard disk doesn’t take any perceptible time. Imagine that external storage of mass data isn’t your system performance’s bottleneck. What does this mean to programmers? What does it mean to hardware designers?

Actually, that doesn’t seem to be an utopia. Today I’ve learned that it’s possible to buy super-fast external storage plugged into your system’s PCIe bus. In other words: very close to your CPU. Flash memory – i.e. SSDs – are only the start. It’s fast, but NVDIMMs are way faster. Putting it in a nutshell, these are traditional RAMs backed by a flash memory, so they don’t loose data after switching the system off. If I’ve got it right, NVDIMMs are future tech, while PCIe flash memory is already there. It costs a lot, but it doesn’t seems to be an exotic technology. So let’s assume NVDIMMs were already there. Just for the fun of it.

Now for the exciting question: How does such super-fast memory affect us?

The idea is new to me, so I may have missed a lot of details, but it seems obvious to me that this is a game-changer.

For example, consider hardware design. It’s built on a hierarchy. Fast memory is scarce, but there’s an abundance of cheap and slow memory. So hardware designers started to invent caches. Later, they added a cache to cache the first level cache, and nowadays even third-level caches are mainstream technology. This continues at the hard disk level. Many hard disks employ caches themselves.

If mass storage was as fast as the CPU, all these optimizations were superfluous. Actually, they were a waste of energy, possibly even performance.

Software design would be affected, too. Software designers know that external storage is slow, so they try hard to keep all the data they need in memory – or, if you’re really power-hungry, in the CPU cache. A lot of thought went into finding ways how to keep your program and your data small. How to avoid database accesses. And so on. Mind you: would you implement your programs they way you do today if storing data in the database is just as fast as storing it in a temporary hash table?

My bet is that affordable NVDIMMs require us to redesign both our hardware and our software on all levels. For example, currently the programming API differs vastly if you write data to memory or if you write data to the hard disk. I suspect that’s one of the things that’d change with affordable NVDIMMs.

And what about database design? Technologies like SAP HANA indicate that databases running on RAM require – or allow for – a new programming model. SQL is optimized for relational databases running on slow memory. Databases that are as fast as the CPU may need a different optimization. For instance, many recent RAM-based databases are column-based, not row-based.

Did I make you curious? If so, I’d like to point you to the article I read this evening. As it seems, four guys had the opportunity to explore PCIe SSDs for four years and wrote an article about it. Highly recommended!

Oh, and one of the affected branches is the book industry. Almost every IT text book needs to be rewritten with the advent of super-fast external mass storage. 🙂


These days it’s kind of official: AngularJS implements the Model-View-Whatever paradigm. That’s a nice solution to a series of fruitless discussions about whether AngularJS implements MVVM, MVC or something else.

However, one of these days I stumbled upon a couple of slides claiming AngularJS implements the MVC pattern during my research for another article. I knew from various tutorials that this isn’t exactly true. My curiosity was piqued. What exactly is the difference between MVC, MVVM and MVP? Are there other useful design patterns? And while we’re at it: do JSF and AngularJS implement one of these design patterns?

Model-View-Whatever 🙂

Actually, I already knew there are different design patterns you can use successfully. When I implemented my former company’s framework, I got the idea of MVC wrong. So I implemented something slightly different. That earned me a lot of trouble with external consultants. You know, every once in a while we invited a consultant to look over our architecture. Inevitably, they would complain about our non-standard implementation. But our implementation worked, and it worked well, so what?

That’s an important thing to keep in mind: don’t waste your time on this nonsense. It’s like talking about politics: it’s a lot of fun to discuss about the advantages of MVP over MVC and whether your program following on paradigm or the other. But at the end of the days, it’ll change little. It’s more important to chose a clean, sustainable architecture and stick to it. If you need a name, call it Model-View-Whatever. Whatever works for you.

But today I’m not going to listen to the voice of reason. Today I want to have fun. Let’s dissect the design patterns, and let’s see how JSF and Angular fit into the pattern.

At a glance

Look at these pictures. They cover three of the most popular patterns: MVP, MVC and MVVM. Don’t soak yourself in the details – that’s what the rest of the article is about. Just look at the general picture. Do you notice anything?
Continue reading