Category Archives: software design

Too Old to Learn a New Language?

The other day, a co-worker and I held a talk at the Java Forum Stuttgart. Our topic was the UI techradar we’re currently developing. So much of the talk was devoted to comparing UI frameworks, raving about Angular, about the advantages of programming your smartphone natively in ObjectiveC, and why it’s still a good idea to stick to Java and JSF.

All of a sudden one of the attendees asked a question I wasn’t prepared for. It was a good question, but I didn’t take it as seriously as it deserved. Even worse, I laughed it off. That’s something you must never do. When I noticed my mistake, it was too late to correct it. So I decided to blog about it. It’s a late answer, and I don’t know if it’s ever going to be read by the guy asking the question, but here it is.

The question was:

Angular and React may be great. But do you really expect everybody who’s crossed the 35 years mark to learn a new programming language each year, just to use the UI framework of the week?

Continue reading

Progressive Web Apps

The other day, we had a discussion in the office. Is HTML5 the solution to every problem, or are native apps the way to go?

For a long time, I was very reluctant to force our users to use the browser to do their work. At the time, we had a nice Java applet running in the browser, which seemed to be a nice compromise to me. We could offer a rich user interface, and every user who had access to the internet could install our application. But installing the applet soon turned out to be above the skill and will of the average user, causing a lot of hotline calls. Plus, developing simple HTML pages was cheaper. That tipped the scales. We kissed Swing goodbye and never looked back.
Continue reading

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 BeyondJava.net. 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.

Introduction

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

Newsflash: The Wrong Abstraction

I’ve just read an interesting article of Sandi Metz. I consider it important (and provocative) enough to dedicate a newsflash to Sandi’s article. Basically, my article is a commented link. Mind you, how often did you do stupid things during your working hours just because you valued existing to code high?

That’s a common trap I’ve often watch catching other people (and myself, of course). Like Sandi says,

Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.

Existing code tricks you into believing it’s good code

Every once in a while you come across complicated code, and you say by yourself, “whow! Such a sophisticated code! It has to be the essence of wisdom of generations of programmers!” More often than not, it’s just clumsy code generations of programmers contributed to without knowing what they did. It’s really hard to detect such a situation. Because you sometimes the code is complicated because it has to be. You never know.

Don’t be overly respectful!

However, sometimes it’s good not to be afraid of redundant code. Adding the wrong abstraction is worse than suffering from a few duplicated lines of code. Often my team tried to unify objects that are identical in the eye of the stakeholder. Consider the simple example of a mailing address. It’s simple, it’s even standardized by your postal office (and probably the ISO and DIN committees, but I didn’t check). Thing is, when we tried to implement the unified address in my previous company, we started to hear “yes, it’s identical, except for…”.

That’s a surprisingly common example. Trying to merge concepts that are identical – only differing by a small margin – may be the first step to unhappiness.

You can refactor in two directions: back and forth

I’d rather you developed an instinct when to introduce abstractions, and – more important – when to unravel abstractions that already have been introduced in your code base. Refactoring isn’t a one-way road. Most of the time you go forward, but there’s a good reason why you can apply refactoring also the other way round. In fact, the notion of “forward” and “backward” is misleading. We’ve been taught to believe that reducing code duplication is good, which is why we instinctively attribute a direction to refactorings, but that’s s subjective attribution which may be right in most situations and wrong in others.

That said, I recommend you to read Sandi’s article. It’s a fast-paced read that’s clearly worth you attention.

The Only One Dependency You Need in JavaEE 7?

Adam Bien is a charismatic evangelist of JavaEE 7. He’s got something to say, and he always makes me think. But that doesn’t mean I always agree with him. In his latest blog post, he propagates to use a simple, single dependency to use JavaEE 7. All you have to use is to install a JavaEE 7 server, add this dependency to you application’s pom.xml, and you’re good to go.

You really are. And it’s tempting:

<dependency>
	<groupId>javax</groupId>
	<artifactId>javaee-api</artifactId>
	<version>7.0</version>
	<scope>provided</scope>
</dependency>

As cool as Adam’s recipe sounds… Well, Adam, I strongly disagree. In a way, you’re absolutely right. All you ever need to use JavaEE7 now is that single, simple dependency you mention in your post. But what about the future?

The two alternatives

Before I continue, let’s summarize the two alternatives quickly. Adam Bien’s suggestion works if you’re running your application on a JavaEE7 application server. That’s a pleasant experience. It’s made for JavaEE7, so it’s unlikely that you run into trouble like configuration mistakes or missing libraries. The drawback is that it’s hard to update anything. I know of at least one application server that makes updating almost impossible.

The alternative is to put every JavaEE dependency you need into your *.war file and deploy it on a Tomcat or Jetty. This approach means you’re responsible for configuring the libraries yourself. However, you can update them without having to care about the application server.
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. 🙂

Build Your Own Dependency Injection Framework!

Let’s bust a myth. There are very good reasons to use CDI or Spring, but dependency injection isn’t one of them. There are a lot of alternatives. And I’m not talking about Google Guice, although that’s a very fine DI framework indeed. Why don’t we write our own DI framework? Can’t be difficult, can it?

It’s true: today’s open source libraries make writing your own DI framework incredibly simple. But even without such a library writing a DI framework isn’t difficult (at least if you’re ready to learn something about class loaders). I’ll develop a sketchy DI framework in this article. In theory, you could finish my work to implement a full-blown DI container and put it into production. Even if you don’t, you’ll understand how CDI and Spring work after reading this article.

But first I’d like to present you an alternative you’re probably not aware of.
Continue reading

How to Run the Eclipse Formatter From the Command Line

Today I’ve dug out an Eclipse 3.2 article that’s seven years old and is still valid. Considering how much Eclipse has changed since 2007 that’s pretty astonishing. So, if you want to know how to format an entire Java Eclipse project in no time, you may ask Peter Friese. Of course you’re invited to read on instead and learn some additional hints.
Continue reading

Microservices – The New Silver Bullet?

Recently microservices are getting popular in the Java world. So I, too, have started to hype microservices as a clever way to manage the complexity of huge applications. The general idea is that our applications have become too complex. Better split them into smaller chunks, small enough to swallow for a small team or even an individual. They have “to be small enough to fit in your head”.

Actually, this idea is far from being new. When functions, classes, modules, portlets, SOA services and business processes were invented, people used pretty much the same words to advocate the new idea. Microservices add a new twist in that they optionally contain the GUI, and in that every microservice uses it’s own database or it’s own backend. The application is sliced vertically (as opposed to the horizontal slicing imposed by the MVC model).

The result is a small library that can be deployed independently from the other parts of the application. The application consists of a collection of largely independent microservices working together. This means you gain a lot of flexibility. Different parts of the application can be developed at different speeds. You also get the freedom to experiment. Individual microservices can be deployed and undeployed quickly, so you can afford to deploy a microservice features a new concept and see what happens. If it doesn’t work out, you simply replace it with the previous version.
Continue reading