Category Archives: architecture

Angular Takes the Sting out of Writing Components

It’s astonishing how simple writing web components is with Angular. In a way, this shouldn’t be a surprise: components are the building blocks of every Angular application. However, last week we wrote a component I already knew to be difficult to implement in merely an hour or two. That was really a surprise.

Our choice was a multi-choice select box. There are plenty finished components out there. However, Angular 2+ is still young, so there are few (if any) native Angular multiple-choice boxes we can use. Integrating a component based on other technologies like jQuery is possible, but usually, it takes some time and it’s always a compromise. So I reluctantly agreed when my co-worker suggested to quickly write our own component. “It’s simple”, he said. “It ain’t much work”. It’s true. It wasn’t.

Key to success: template language

The key to success is the clever template language of Angular. More often than not, I’m unhappy with template languages because they always feel clumsy. Angular’s template language doesn’t. Of course, that’s simple because it doesn’t aim to be a general-purpose language. It’s been written specifically for a single purpose, and it serves this purpose well.

I don’t have the source code at hand, so let me sketch our source code from memory. The multiple-choice combobox consists of an input field, which is always visible, and a pane containing the options. The pane is hidden most of the time. So the HTML code (or rather: pseudocode) looks like so:

<input [(ngModel)]="selectedValues" 
       (onfocus)="optionsVisible=true"
       (onblur)="optionsVisible=false">
<div [attrs.visible]="optionsVisible">
  <div class="checkbox" *ngFor="let option in options">
    <label>
      <input type="checkbox" [(ngModel)]="option.selected"
             onchange="updateResult()"> 
      {{option.value}}
    </label>
  </div>
</div>

This little snippet reads and writes like plain vanilla code. But in reality, it’s revolutionary. It takes a lot more code in Java to write an equivalent JSF component. I also compared this code to my AngularPrime/Dart framework I wrote a couple of years ago. Dart is a fine language, but it took much more time and effort to write a simple component.

The component class

Of course, the HTML code is useless without the TypeScript glue code. But again, this code is fairly straight-forward. The sketchy pseudocode looks like this:

export class Option {
  label: string
  selected: boolean = false
}

@Component({
  selector: "multiple-choice",
  templateUrl: "multple-choice.html"})
export class MultipleChoice {
  @Input() options: Options[]

  @Output() result = new EventEmitter(string)

  optionsVisible: boolean = false

  updateResult(): void {
    let result = options.filter(option => option.selected).
             reduce((option, previous) => previous + "," + option.label, "")
    result.emit(result)
  }
}

Another key to success: @Input and @Output

We’re almost there! All we need to add is a little CSS file to arrange the panel properly below the input field. Everything else is handled by Angular: we can pass the list of options to the component using the @Input decorator, and @Output sends the result to the outer component:

<multiple-choice [options]="colors" 
                 (result)="setSelectedColors($event)">
</multiple-choice>

Wrapping it up

Of course, I’ve omitted some details to keep things simple, and I’ve shown only pseudocode. But even the real source code is surprisingly simple. Angular focuses on writing components. Therefore, it makes writing components as simple as possible without sacrificing power. I had the opportunity to compare different approaches, and I’m astonished by the ease of use of Angular.

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

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. 🙂

Model-View-Whatever

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