Array with promises

First up, the problem: I needed to build an array of items based on multiple roles for a user in an Angular application. And the returning value had to be a promise. So first attempt was to build up the array with if-statements and Array.push, not very beautiful nor immutable, and then return it with $q.when(array).

So I figured that this could be done with multiple promises instead. So here’s what I came up with, fun with trolls and ogres.

 function creaturePromise(creature) {  
  function always() {  
   return $q.when([ "you", "are" ]);  
  }  
  function troll(creature) {  
   return $q(function(resolve) {  
    if (creature.isTroll()) {  
     resolve([ "troll" ]);  
    }  
    resolve([]);  
   });  
  }  
  function ogre(creature) {  
   return $q(function(resolve) {  
    if (creature.isOgre()) {  
     resolve([ "ogre" ]);  
    }  
    resolve([]);  
   });  
  }  
  return $q.all(always(), troll(creature), ogre(creature)).then(function(arr) {  
   return [].concat(...arr); // Flatten the array of arrays.  
  });  
 }  

Pretty self explaining, ey? Got a better way of doing it, please let us know :)

This blog post was authored by Micke Jönsson

Paradigm crisis

Ever since I took the Haskell 101 course I have gradually entered a state best described as a paradigm crisis. Prior to that course I happily hacked away in an object-oriented fashion, and I felt pretty confident in how to tackle problems when I faced them. I knew the most commonly used design patterns and how to look up the ones not that frequently used when needed.

Then came functional programming.

Admittedly I was not immediately convinced when I took my first steps in the Haskell 101 course, and I think the reason for that was that I did not quite see where these new functional tools would fit into my very object-oriented toolbox. Somewhere in that toolbox, along with factories and decorators, I had to find room for map, fold, filter and other functional concepts so I could easily find them.

It turned out that I actually needed a whole new compartment in my toolbox, as object-oriented programming and functional programming indeed are two very different paradigms.

It is true that we in the hybrid world of Java 8 can mix these two paradigms as we see fit, but when we are writing functional Java we leave the object oriented paradigm for a moment and become declarative and immutable, which is really cool. For me as (mainly) a Java programmer, the functional style of doing things are increasingly becoming my first-hand choice. I mean, what's the point of for-looping a list of elements when all I want to do is to grab some elements that matches a given predicate? The "old way" of doing this is way to error prone to be worth it. Moreover, when we leave out the "how" part when working with collections, the language can apply optimizations to the "how"-part. The declarative style of programming allows you to work on a higher level of abstraction and let the language worry about the specifics of "how".

Now, the leading paragraph of my blog post mentioned the word "crisis", which intentionally was a strong word to get your attention. ;) Although the new compartment in my toolbox have complicated my professional life a bit - especially at the time of writing when I am still a newcomer to the functional paradigm - I have noticed that I am starting to think about how to attack problems a bit differently than before. When in the object-oriented world, you would use all kinds of design patterns and language constructs to control mutability of objects in order to get a fair chance to understand and reason about what's really going on. In the functional world, you would instead work declaratively on immutable data structures, which means that we write code on a higher level of abstraction without the need to worry about mutable data.

And suddenly, the new functional toolbox compartment seems really compelling.

I have to admit that I may be a bit over enthusiastic right now, I usually behave like that when I try out new things that I like. But when listening to Martin Odersky in yet another course I'm enrolled in on functional programming I find it a bit sad that object-orientation turned out like it did in languages like Java. I mean, why is everything mutable by default? That doesn't make sense. And why did the programming courses I took at the university teach this mutable object-oriented way of programming? As far as I understand, imperative programming where everything is mutable has been a well-known problem for decades.

Time to sum up this blog post with a stupid quote coined by myself over a cup of coffe: functional programming is like sudoku! :)

This blog post was authored by Martin Moberg.

Event storming

Lately I've spent some time catching up on what's happening in the Domain-Driven Design (DDD) community through watching sessions recorded at the Domain-Driven Design Europe 2016 conference. The session I watched yesterday was about something called event storming - a concept that was new to me but so simple and seemingly powerful that it got me quite worked up. The purpose of this blog post is not to go into details of how event storming works, but rather to convey my initial thoughts of why the idea is worth thinking about.

When running an event storming workshop you only need a few basic things:

• post-it notes with different colors
• a lot of space to place the post-it notes on (e.g. a large whiteboard or a paper roll)
• the right people

The right people are key in event storming and should involve a moderator, developers, domain experts and other people involved that can contribute when storming away at the problem at hand.

Domain events

With all these smart people gathered in a room, you start with identifying a few core domain events. A domain event is formulated as something important that happened in the domain under analysis, e.g. "ticket purchased" or "seat reserved". As you can see, domain events are always expressed in past tense. Each domain event is written down on a post-it note with a specific color - the resources I've found online so far suggests orange stickers by convention - and placed on the whiteboard from left to right in order of occurrence in the business process we are analysing. This means that we get a visual representation of the business process flow to see when the various domain events occur.

Commands

During the identification of domain events we also need to ask ourselves how they are triggered. For instance, the domain event "ticket purchased" might be a consequence of a user placing an order via a web application. The act of placing an order is, in event storming terms, a command. A command is something that generate domain events which we express through blue post-it stickies. Commands are formulated in present tense, e.g. "purchase ticket", and placed on the whiteboard just before the domain event(s) that are generated as a result of the command. For example, a "purchase ticket" command should probably be placed just before the "ticket purchased" domain event to signal that they belong together.

The flow of the workshop

With the two core concepts of commands and domain events, the participants of the workshop keep exploring the problem area to gradually refine and expand it. As the notion of event storminig stems from DDD, we take extra care to capture the "ubiquitous language", i.e. we want to make sure we are naming things so that it makes sense for the business problem we are trying to solve. Participants in the workshop are encouraged to question things, no matter how trivial they may sound. Is "ticket" really the correct word? Is it to general?

It is during the ongoing discussion, with post-its being replaced and moved around, we hope to nail the complexity of the domain problem. Suddenly, a domain expert states that there should be a way to reserve tickets. And by the way, you should be able to get a refund if you cancel your ticket purchase within a given amount of time. The complexity of the problem gradually reveals itself, captured in a process time flow and grouped by commands and domain events on a whiteboard covered with colored post-it stickies.

What do we get out of this?

It should be noted once again that I've not actually tried this workshop format, but in my mind it really makes sense. The idea is super simple and the potential outcome of it is interesting in several ways. First and foremost, we can express the components of a problem we are trying to solve (and how they relate to each other) with terminology that comes directly from the domain experts. Another neat thing is that commands and domain events map really well to implementation. They are a natural fit for CQRS and event sourcing, but when you think about it, commands and domain events can be mapped pretty well to any kind implementation technique. Something triggers an action (command) that produces some kind of result (domain event).

Final notes

Event storming include more stickies for e.g. highlighting actors, UIs and domain models. Moreover, as we are in the DDD world, we can map related commands and events to a particular aggregate and express that directly on the whiteboard by simply grouping them together. The same goes for bounded contexts; to group aggregates into a bounded context you just draw a line around the involves post-it stickers with a whiteboard marker.

For those of you versed in DDD, we can start drawing a context map from here, but that's the topic of a blog post for a later time.

This blog post was authored by Martin Moberg.

Hackathon: Trash Friend

Last week me and some colleagues took part in a hackathon here in Växjö. This hackathon was one of many events that took place during something called Digitala veckan, an entire week packed with IT-related events around the Linneaus university region. For those of you new to the concept, a hackathon is basically a competition in which programmers hacks away at a problem in a limited amount of time. In this particular hackathon, the challenge was to combine open data sources on the web and produce something useful for making our environment better. While HRM had two teams enlisted in the competition, this blog post is about our contribution. Say hello to Trash Friend.

The rationale for Trash Friend came to us while struggling hard figuring out what to do. We had been provided a list of example open data sources in-line with the overall environmental theme, but the data sources were admittedly not all that great and not always up to date. Moreover, our friends in the other HRM team were hacking away like crazy right from the start with a pretty neat idea, which made at least me feel a bit stressed out. We did come up with a few kick ass ideas right from the start too, but the open data sources were not fitting in nicely in any of those. What to do?

Figuring out what to do

After some headache we finally settled on an idea that were nicely motivated by another colleague of ours during a coffee break. One of the provided open data sources contain information about cars entering one of the recycling stations in Norremark, Växjö, and while brainstorming he said something like:

"They should have a webcam over at that recycling station. The queues can be terrible over there and you never know until you actually get there."

Now, we did not have access to a webcam or any live data, but we did have access to the data set I just mentioned, which contained statistics over the course of a few months. It included data such as the time of visitors entering the station, the length of the cars (!) and the speed of the cars passing through the sensor. The latter two were not that useful for us, but the time of entry had some potential. Although there were no information about when cars left the recycling station, you could take a wild guess and say that the average time for a visitor staying at the recycling station is, say, fifteen minutes. Not that we actually had any coverage for that estimation, but for a hackathon such as this that estimation was perfectly fine.

With the time of entry and an estimation of how long visitors were hanging out at the recycling station, we could take a particular point in time, for example at three o'clock Friday afternoon, and calculate the expected number of visitors at that time. The algorithm we used to calculate that approximation was to historically look at the visitors to the station at that time on that particular weekday. From all of these occurrences we simply came up with an average to make the approximation somewhat reliable, that is, taking all Friday afternoons at three o'clock into account.

The idea

So, the idea we had was to make recycling easier for citizens and to relieve them from long queues at the recycling station. Such a tool has the potential to be beneficial in several ways:

• Avoid a high load of visitors; if a citizen has a way to find out that the queue to the recycling station is long s/he can decide to wait before deciding to pay a visit.
• Reduce the emission level at the station; cars in queue means that there will be more emissions, which leads to our next point.
• Improve the work environment for employees at the station; less emissions and less visitors at peak hours.

There are probably more points to such a list, but let us settle for those and head over to implementation details.

Implementation

With the algorithm in place for calculating the number of visitors at the recycling station at a given point in time, we had one more crucial nut to crack - the information had to be super-easy to get a hold of. Would a web site do? For some cases yes, but remembering the URL of that particular site you tend to visit occasionally would not cut it. We wanted something that was just there when you needed it. Perhaps a notification could pop up in your smart phone when things are looking okay at the recycling station? Notifications are nice and all, but how could we possibly know when the citizen wants to recycle their trash? No, we needed something accessible that the citizen could consult when needed. And for this purpose a widget felt just right.

We finally settled on an architecture that involved three central components, described in more detail below.

RESTful web service

As the recycling central station data was encoded in a csv-file, we decided to crunch it and expose it in a format more suitable for our needs (i.e. JSON) via a simple RESTful web service. The technologies we chose for these tasks were Java and Spring Boot. With Spring Boot we had a RESTful web service up and running in no time, which was perfect for the time pressure we had during the hackathon. Aside from the recycling station data, service we build also included weather data. The weather data was fetched from an open weather data API and adjusted to the needs of the widget to inform the citizen about the weather conditions at the station. I mean, it is no fun to recycle your trash when it is raining.

Trash Friend Widget

The widget was developed for Android using Android Studio. This was the first time for me developing a widget, but after a while I got a hang of it and the result came out quite okay for a UI novice like me. As seen in the screenshot below, the widget presents a colored cycle to the far left. This icon indicates the status on the recycling station with one of the three colors red, yellow and green. A red circle tells you that you should wait your visit to the station for a later time, a yellow circle means that you probably will be in queue for a little while and, finally, a green circle means thumbs up, you should stop what you are doing and head over there right away.

The Trash Friend Widget

For a more concrete approximation (if there is such a thing) the text to the far right tells you the approximated number of visitors at the station at the present time. Finally, the weather icon show the weather conditions over at the station at the present moment. The information in the widget is updated every 30 minutes, which in my mind is acceptable as we are not dealing with live data (at least regarding visitor data).

But what if the queues are terrible right now? When should I go? To answer this question, the user simply taps the widget to launch the Trash Friend web application.

Trash Friend web application

The purpose of the Trash Friend web application is to answer questions just like the ones asked in the closing sentences of the previous section. When the widget is tapped, the default browser in your mobile phone fires up with an overview of the expected load of visitors at specific times throughout the current day (see figure below).

The Trash Friend web application

One can easily switch to a weekly overview by tapping the button "Veckoöversikt" in order to see how the situation at the recycling station is expected to be later on during the week. This web application was developed using the Ionic Framework to make it mobile friendly right from the start.

Summing up

So there you have it. In just a couple of hours we went from frustrated to pretty satisfied with what we had produced. And while we did not win the hackathon (due to stiff competition of course ;)) we pulled through and produced something that, if polished a bit, at least in my mind would be a valuable tool for citizens living near this large recycling station. If all recycling stations in Växjö would start to gather entry data it would be quite easy to improve the design to let citizens select their station to track in their widget. In Android, the way to configure widgets is to flip them over and adjust its settings. Imagine if available stations were available in a list in which you could select the station to track? A tap on the widget would then, naturally, direct the browser to the statistics at that particular station.

That's all for this time, keep hacking! :) By the way, the code we wrote is MIT licensed and available on GitHub.

This blog post was authored by Martin Moberg.

Strings behind the scene

What’s really happening behind the scenes with the strings you create?

I will try to show what’s happening and what to think of when generating a string. And to visualize it I will use log messages.

Often I see log messages where the whole message is created as it should be logged. This is a pretty bad idea in performance perspective, since it always have to generate the string no matter what, even if the log message is discarded. So I will show you what the Java compiler actually does with the string messages you create.

But this will not be another performance comparison blog post. I will just try to show what’s happening behind the scenes with some byte code, then you will have to make your own assumptions. Of course I will tell you my point of view :)

Let’s start with a more or less common examples.

public void logWithConcatInLoop(List<String> values) {
    String logStr = "My values :";
    for (String value : values) {
        logStr += value;
    }

    log.debug(logStr);
}

The interesting part of the byte code is what’s happening within the loop:

NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
ALOAD 2
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 4
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
ASTORE 2

It creates a new StringBuilder in each iteration and appends the logStr (ALOAD 2) and then appends the variable value. ASTORE 2 simply means that it stores the toString value to logStr. You don’t have to understand the byte code, the important thing is that it creates a _StringBuilder in each iteration and makes an extra append-call, simply unnecessary and might be a performance issue in larger systems.

Let’s take another example with the string + operator.

public void logWithConcat(String t1, String t2, String t3) {
    log.debug("My values : " + t1 + " " + t2 + " " + t3);
}

This is a very common approach of creating log messages. The compiler simply creates a StringBuilder and each plus-operator is basically translated to an append-call.

NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
LDC "My values : "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 1
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
LDC " "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 2
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
LDC " "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 3
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
INVOKEINTERFACE org/slf4j/Logger.debug (Ljava/lang/String;)V

Pretty neat, huh? The Java compiler is not that stupid after all. You might have heard someone say "don’t use + when working with strings", that was true, back in Java 1.4, but now the compiler is a bit smarter :)

So lets see what happens if we use a StringBuilder directly, instead.

public void logWithStringBuilder(String t1, String t2, String t3) {
    StringBuilder sb = new StringBuilder();
    sb.append("My values : ").append(t1).append(" ").append(t2).append(" ").append(t3).append(" ");
    log.debug(sb.toString());
}

And the byte code:

NEW java/lang/StringBuilder
DUP
INVOKESPECIAL java/lang/StringBuilder.<init> ()V
ASTORE 4
L1
LINENUMBER 78 L1
ALOAD 4
LDC "My values : "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 1
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
LDC " "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 2
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
LDC " "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
ALOAD 3
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
LDC " "
INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
POP
L2
LINENUMBER 79 L2
GETSTATIC se/hrmsoftware/BehindLogging.log : Lorg/slf4j/Logger;
ALOAD 4
INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;

Not much to say. Almost identical to logWithConcat. Just some more line number changes.

So lets look at something else, a log message using parameters instead.

public void logWithFormat(String t1, String t2, String t3) {
    log.debug("My values: {} {} {}", t1, t2, t3);
}

So this is compiled to creation of an array and then just a method invocation. In other words, this is probably the fastest solution in my examples.

GETSTATIC se/hrmsoftware/BehindLogging.log : Lorg/slf4j/Logger;
LDC "My values: {} {} {}"
ICONST_3
ANEWARRAY java/lang/Object
DUP
ICONST_0
ALOAD 1
AASTORE
DUP
ICONST_1
ALOAD 2
AASTORE
DUP
ICONST_2
ALOAD 3
AASTORE
INVOKEINTERFACE org/slf4j/Logger.debug (Ljava/lang/String;[Ljava/lang/Object;)V

So what do I want to tell you with this? As you can see the Java compiler always uses the StringBuilder (stop using StringBuffer!!) when it creates the strings for you.

Of course it’s not totally free to generate the string with a StringBuilder. That’s why all (good) logging frameworks also has the solution with the string format pattern. That will not produce anything else than one method call and possibly an array creation, but that’s pretty fast. Some frameworks also defines methods that actually takes two arguments instead of an array to speed up those logging messages that only takes two arguments, then no array is created. Some might even have more than that.

And then, of course, some logging frameworks has been adding support for Java 8 suppliers and lambdas, that is probably the sweetest solution :)

Well, you get the point. Happy string creation.

The quest for time, in plain old words!

The idea was born discussing different projects at work. One of my colleagues told me about a clock called Qlock2, it is a clock that tells time in words. The first thought that ran through my head after seeing it in action was

"Oh my, I have to have me one of those, and wouldn't the best way to get hold of one be to build one?!"

So the first task was to just try to figure out where to start. For you to get an idea on how this clock looks and perhaps get a notion about which kind of problems that needed to be figured out in order to build it your selves look at this:

The time is shown in five minute intervals, notice though the corners, each LED in the corners represent a minute within the interval. Thus when the time is 07:57 the clock will say "IT IS TEN TO EIGHT" and two corners are lit.

Starting up.

The first thing that struck me was the need for the word matrix, and what would be cooler than getting it cut out in steel? Nothing! Thus I got hold of a friend of mine that I knew had access to a laser that was able to cut steel. And voilá the words were born:

The first stumbling steps.

Well, now I had the steel plate with all the words. What would be the next logical step? Of course figuring out how to light up each individual letter on it's own. Given that we have 11 rows and 10 columns we have 110 points that need to be individually addressed. The initial feeling is

WAT!

What kind of micro controller has 110 outputs? Let alone what kind of light source would one use? Short cuts could be made by "cheating", which would mean that instead of individually light up each point on the matrix, one could have a single control for each word instead, but how cool would that be? So that was actually never an option for this project. Getting back to the great questions about which light source to choose it turned out that the answer was right above my head. When building my man cave (yes, of course I have one!) I used LED-strip as overhead light source, this strip can be cut every three LED. The length of a cut strip fits very well for the letters on the steel plate. Thus began the work of creating the LED-strips for each letter on the board. First of all, creation of the strips. Cut, solder, repeat...

A lot of soldering later the boards points were completed, great success! But while that this was well and good, the problem of individually controlling these LEDs was still not figured out. Since I have done some work previously with the great Arduino board, it would be a good idea to use that one as the controller for the clock. Problem is that the basic Arduino board only has 14 outputs, and I must control 114 (there are the corner LEDs as well!). Furthermore the LEDs of choice or at least those I bought from China to a very good price operates at 12V, the Arduino operates and outputs only 5V. Also all these LEDs (342 of them in total, remember three for each letter) would require quite a lot of current as well in order to light up properly. Attacking the problem head on I decided to address the fact with the limited number of outputs from the micro controller. In order to extend the number of outputs I found a small chip called 74HC595. Three of these setup in a daisy chain (no that is not a bracelet) made me access the power of 24 outputs directly by only using 3 on the Arduino board. Of course you are now wondering why on earth settle with only 24 outputs? Well in fact I really do not need that many, I only need 21, 10 for the rows and 11 for the columns, let's investigate that a little further. What I use is a technique called multiplexing.

Multiplexing bonanza

In order not to have a single output setup for each point on the clock we can use the fact that the human brain in combination with its sensor called "eye" is somewhat of a slow mover. In fact we are so slow, in comparison with how fast a little micro controller can operate (at a lightning fast 16MHZ), that if we were to switch a light bulb on and off really really fast, I mean insanely fast, our slow sensors would never understand that the bulb in fact turned off. This phenomenon is called [persistence of vision(https://en.wikipedia.org/wiki/Persistence_of_vision). So in order to be the evil master mind and fool all tear stained eyes beholding the clock, the words are individually lit up by turning each row and column on and off really fast. See pictures below for a mesmerizing explanation.

Courtesy of instructables

Picture above taken from a project on Instructables.

We need to prepare the LEDs and set them up in columns and rows:

Place the led strips.

Make room for wiring.

Rows and columns my folks, just rows and columns...

Finished, with power on all LEDs.

As you can see we can now power up all the LEDs.

Voltage, WATT about it. 

But wait there is still trouble in clock land. Even though all the dots of the matrix now are interconnected in order to support the multiplexing, the Arduino still stubbornly only provides 5 volts while the LEDs screams for more than twice that. A really cool invention, for which the Nobel prize actually has been awarded (1956), all though to the wrong people as the committee missed the fact that there had been patents given as early as 1923 for the awesomeness called transistors.

A transistor can be used as an amplifier, a switch or as a voltage regulator among other things. It works sort of like a tap water crane where you use one force (your arm) to control another force (the water flow). Thus applying and differentiating a base voltage a higher voltage can be controlled through the transistor. That is exactly what is needed in order to get the clock dots light up!

Each column need to be grounded at certain points in time (oh, no they are not misbehaving, i.e. it is not house arrest we are talking about here). We need to connect them to the electrical ground when we want current to flow through the LEDs. This is called low side switching and can be achieved by using a NPN-transistor, which in fact is the most common one.

This little critter will open the gates of electrons if a certain voltage is applied to the base of the transistor. See below schematics.

A small current controlling the BIG current..

So, ok we are now able to use the 74HC595 to switch the transistors on the low side on and off on demand. Hurray! So if we apply 12V at each row we can now individually turn each column on and off using the switching, which means that we ground each row at the columns.

That is only half the solution though. We must also be able to individually switch on and of the 12V feed on the rows. The PNP transistor is then what we need. It however operates a little bit differently from that of the NPN. It will only turn off if we apply the same voltage on the base as what we are trying to control. But wait, and hold all the horses, didn't I just mention that a transistor use one voltage on the base and another as the flow? Yes, indeed I did, but the PNP does not. It is possible to use another NPN transistor and connect that one to the base of the PNP and thus be able to turn it on and off using only 5V. Another hurray! The schematics can look something like this

NPN to rule a PNP, thus controlling the high side!

Off to the soldering iron once again, to make the schematics happen. This can look something like this:

Testing some multiplex circuits, great fun!

Making some  circuit boards.

Aahw, would you just look at all those beautiful wires!

Let there be light!

Minutes, what about them?

To show which current minute within the five minute span the time is, a diode is lit up on the corner, one for every minute past five minutes. A type of LED mostly suitable for the job is the neo pixel for this, a chainable addressable little smart LED that runs on 5 volts. A plus side is also that they are RGB, that is we can have any color we want!

The code, another fun part. 

All hail to the hardware, but what about the software? We badly need it in order to control all this magnificent hardware. For instance we need to translate a certain point in time into the words on the clock. We also need do the heavy duty switching of the transistors so that we get a steady light.

Coding stuff for the Arduino is just as easy as writing some C++ code. What that actually means is that it can be extremely difficult and tedious as we don't get to know anything about what might have broken the program, just because we try to write stuff into an array and don't stick to its size etc.

However the program that we need for this little clock is not that advanced, as I said before we just need to figure out a way to translate a timestamp into which words that need to be lit up on the clock. Since we know which intervals we have to work with we just divide the current time with 5, and look, what we get is an index that we can use to fetch the definition from a predefined list. If the division doesn't add up it just means that we are in between two intervals, and "the rest" can be used to figure out which minute LED (that is corners) that need to be lit.

If you are not that familiar with programming it might sound like magic what you have just read. And that my friend is because it is pure magic :-). I will write more about the solution in later blog posts.

A picture is nothing without a frame.

Using simple wooden 90 degree angled pieces and some ninja moves with a hand saw the base frame of the clock was set together. Well, there was also a pneumatic nail gun and some glue involved to be honest.

Glue and stuff.

Power and control buttons.

Adjusting the board.

Look it fits!

Are we there yet? 

After applying the steel sheet on the frame one could but only be unsatisfied with the result! Without a diffusing barrier between the letter in the steel plate and the actual light source things sort of look kind of non coherent and well to be honest not anything to be proud of. The outcome can be viewed in the video which also quite well displays the code in action!

The great shop of Biltema could perhaps help with this predicament of mine? It turns out, well indeed they have plastic sheets that are diffused. Happy having found the material to realize the idea of diffusing the light source I headed home and did some preliminary tests. This is what it looked like.

Now at last are we actually finished? Could I place this on the wall of my living room and each night gaze upon the creation in wonder with a feeling of that I could not have done any better? Well, of course not. Looking at it, there are a number of flaws in the design. The biggest being the light intensity, mainly this is due to the refresh rate of the multiplexing. So how can we do better? ... this will be continued in blogpost #2 about the dazzling quest for time where the hero will face the Neopixel grid, a lot of milling, spray painting, code and of course the need for serious soldering kung fu......

Your hero for today and author of this blog post is Henrik Grankvist!

Security through domain modeling

At the time of writing this I am sitting on the train home after attending the jDays 2016, a two-day conference packed with talks about Java and related technologies. Me and two of my fellow colleagues had a really nice time there and right now I feel quite stuffed with information that will need some time to sink in. One of the keynote speakers actually pointed out that sleeping and resting are important ingredients for accommodating what you are trying to learn, and fortunately those ingredients are perfectly in line with what my mind is signaling right now.

But prior to resting there is one thing that I need to put down in words right away. Being a fan of Domain-Driven Design (DDD) for quite some years now I am glad that I attended a talk about the concept of Domain-Driven Security (DDS) with the irresistible name "Arm yourself with Domain Driven Security. It's time to slay some security trolls..." by Daniel Deogun and Dan Bergh Johnsson. In the next couple of paragraphs I will attempt to pass on my understanding of the concept. If the notion of DDD is new to you then I warmly recommend you to read up on it. For me I found DDD to be an eye opener to say the least.

Now, the overall idea behind DDS is that we can use DDD as a way tackle various security challenges that we all have to deal with in some way or another, for example input validation, cross-site scripting or SQL injections. And the really nice part of this is that there is no technical wizardry or mysterious frameworks here - it all comes down to modeling the domain properly. Let me describe this with an injection attack example inspired from the talk I refereed to earlier. Here we go.

In a simple on-line registration page for a cat owner community there is an input field where you are asked to fill in the name of your favorite cat. Everything works fine and the community site is coming along nicely with an ever-growing user base, but then one day a terrible thing happened. Someone had injected JavaScript code in the cat name input field which made the browser redirect to a dog owner community page whenever the cat name was supposed to be displayed on the screen. Under the hood, the value in the cat name input field had been persisted as is, and when retrieved from the database to be displayed the JavaScript code executed, redirecting the browser.

The cat owner community was not pleased.

If the cat owner community instead had designed the application according to the DDS they would most probably not have ended up in this situation. A cat name is a domain concept in its own that clearly differ from a string in that it cannot contain weird characters such as "<" or ">". And if you think about it, does the concept of a "string" really have any meaning in the domain of cat owners? Probably not. Moreover, numbers are probably not be something that the should allow in a cat name. With such business rules in place, we can define a class - for instance CatName - within the domain model that enforces all of these rules in its constructor.

We now repeat the injection attack described above with our new domain model construct CatName in place. The attacker enters the terrible script into the input field and submits the form. The string containing the JavaScript code, including the "<" and ">" characters, are passed on down towards the domain model, eventually to be mapped to the domain model concept CatName. Depending on how the cat naming rule is enforced, an exception could be thrown or any characters that aren't letters are filtered away from the string. In any case, we can be sure that a CatName instance will never, ever contain malicious JavaScript code.

What I just tried to explain is just one example of security challenges that DDS aims to tackle. And the great thing is that much of DDS really comes for free if you just do DDD properly. Just think about the example above - the injection attack was avoided as a consequence of thorough domain modeling work a la DDD. The restrictions and rules enforced by the domain model saved the day for many cat owners.

For me, the talk about DDS was yet another piece of evidence that DDD is worth the extra modeling work up front. Through exploiting the ideas in DDD we can take a proactive stance to fight security challenges by simply doing our domain modeling work properly.

If you want to have a look at this particular talk it will be available on the jDays 2016 site in a couple of weeks. I strongly recommend watching it!

This blog post was authored by Martin Moberg.

Preconditions in Google Guava

While the Guava project (https://code.google.com/p/guava-libraries) from Google comes packed with goodies for Java developers there is one thing in particular that I tend to use over, over and over again. Actually there used to be two of those, but since Java 8 comes with their own implementation of Optional (https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html) I have shifted over towards that implementation instead. Anyway, the topic of this short text is Preconditions in Google Guava (https://github.com/google/guava/wiki/PreconditionsExplained).

You can think of preconditions in Guava (as the word suggests) as a way to express and enforce preconditions that must be true in order for the execution to continue. A natural fit for these would be at the beginning of a method or a constructor, acting as guard statements (http://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html) of sorts that throw exceptions when violated.

To make things a bit more concrete we turn to code. First off we take a look at the "normal" way to achieve precondition-like functionality without relying on Guava:

public class SomeClass {  
   private final String aString;  
   private final String anotherString;  
   private final int anInteger;  
   public SomeClass(String aString, String anotherString, int anInteger) {  
     if (aString == null) {  
       throw new NullPointerException("aString was null");  
     }  
     if (anotherString == null) {  
       throw new NullPointerException("anotherString was null");  
     }  
     if (anInteger <= 0) {  
       throw new IllegalArgumentException(  
           String.format("Expected anInteger to be > 0, got %s", anInteger));  
     }  
     this.aString = aString;  
     this.anotherString = anotherString;  
     this.anInteger = anInteger;  
   }  
   // more code here..  
 }  

In the SomeClass constructor we want to a) enforce that the strings passed as arguments are not null and that the integer argument is greater than zero and b) assign the arguments to their respective class member variable. Throughout the 16 lines of code in the constructor body we spend 12 lines of code just enforcing the correctness of the supplied arguments. One word that comes to my mind is verbose.

Another thing to note is that in each of the if-statements we check if the argument has a value that we do not accept. In plain english we can say "if aString is null, then throw an exception" or "if anInteger is equal to or lower than zero, throw an exception".

We now turn to preconditions in Guava. An implementation of the constructor with the same functionality would then look as follows:

import static com.google.common.base.Preconditions.checkArgument;
import static com.google.common.base.Preconditions.checkNotNull;

public class SomeClass {  
   private final String aString;  
   private final String anotherString;  
   private final int anInteger;  
   public SomeClass(String aString, String anotherString, int anInteger) {  
     checkArgument(anInteger > 0, "Expected anInteger to be > 0, got %s", anInteger);  
     this.anInteger = anInteger;  
     this.aString = checkNotNull(aString);  
     this.anotherString = checkNotNull(anotherString);  
   }  
   // more code here..  
 }  

In this version of the class constructor we make use of two static methods in the Preconditions class, namely checkArgument and checkNotNull. In order to make the code more readable these two methods have been statically imported, as seen above the class definition. Let's walk through the lines in the constructor one by one.

The first line calls the checkArgument precondition to check that anInteger is greater than zero, otherwise an IllegalArgumentException will be thrown. A second and third argument can be supplied to the method - this is optional as the method is overloaded - that provides the exact same functionality as the String.format method used in the former version of the constructor. The most important thing to note on this line is that we check if the argument has a value that we accept. This is the complete opposite to what we did in the former version of the constructor, where we checked if the argument had a value we did not accept. In plain english we can now say "anInteger must be greater than 0 or an exception will be thrown".

The second line in the constructor is just an assignment, nothing more to say about that. The fourth and the fifth lines are however much more interesting. Here we use a precondition on each line to check that the string is not null, otherwise a NullPointerException will be thrown. If the precondition is enforced successfully, the argument supplied to the checkNotNull method is assigned to its member variable. In plain english we can now say "aString cannot be null or an exception will be thrown". Again, the way we express this is completely inverted from the former version of the constructor, where we say "if aStirng is null, then throw an exception".

Aside from making the code more compact - we have now effectively reduced the code from 16 lines down to 5 - it is also in my strong opinion that the latter version of our constructor is easier to understand. With preconditions in Guava we have the ability to state how things must be rather than how things must not be in order to proceed with the execution. This might seem like a trivial improvement to code readability, but with each small improvement to readability we add to our code base we also make it more maintainable.

After all, code is a form of communication, and code that communicates well is easier to understand and maintain (http://www.casualsemantics.se/koden-ska-kommunicera-bra).

P.S. An alternative to the Preconditions.checkNotNull method is the Objects.requireNonNull method available in Java 7.

This blog post was authored by Martin Moberg.

Welcome to the HRM Developer Blog!

Welcome to our brand new developer blog!
At HRM we are very passionate about system development, writing code and doing fun technical stuff :-) In this blog we will share cool things we do in our product, our thoughts, experiments and other things that we are interested in.

Stay tuned for updates!