Jan Willem Tulp’s blog

Last week 2 colleagues of mine and myself gave a Scala workshop at Logica. One of the participants was asking whether getDate was a function or not. His question led to an email discussion today about what functions are, and how they relate to the Command Query Seperation (CQS) principle. The definitions coined in Eric Evans book about Domain Driven Design were helpful in defining the definitions.

After several exchanging several emails, we finally came to the following definitions:

• Query Functions: functions that retrieve information about the system. They are not pure functions, because applying these kinds of functions to its arguments may result in different values. GetDate() would be a Query Function, because everytime it is applied, a different value is returned.
• Command Functions: functions that alter the state of the system. They should not return a value (void in Java, or Unit in Scala). setName(String name) in Java would be example of a Command Function. Command functions therefore have side-effects.
• Pure Functions: functions that always return the exact same value for the exact same input. These are mathematical functions and don’t have side-effects. In Scala the following function is a Pure Function: def inc(x: Int) : Int = x + 1. For the input 4, this function will always return 5, no matter how many times you invoke it, and it doesn’t change the state of the system.

  What’s your opinion about these definitions?

  • 

Great infographic on Cloud Computing from http://mozy.com/blog/:

Here is a list (in random order) of 9 organizations I consider to be really cool:

• Tableau Software
• Google
• 37 Signals
• MIT Media Lab
• Apple
• Media Lab Prado
• Stamen Design
• Duarte Design
• Human Computer Interaction Lab (University of Maryland)

Now what makes these organizations cool? I think they have the following in common:

• they have a very clear focus on certain products, services or projects
• they are trend-setters
• they value intuitive user experience
• they turn complexity into something that is easy to understand
• they create things that are pleasing for they eye
• beautiful design is a means to create emotionally appealing products
• they are creative and innovative
• they use sophisticated technology
• they create products that touch people or help people getting insight
• thought leaders and the best in the field work at these organizations

What organizations do you find inspirational and why?

I am about to go on a vacation to Norway, and my girlfriend and I haven’t figured out yet whether we will travel up to Kirstshals in 1 day by car, or maybe 2 days, but then, where do we stop, Hamburg, or Kiel? And will we visit Arhus in Denmark or not? Anyway, I thought maybe creating some small infographic can at least make clear how the distances and traveltime compare to each other.

Well… I’m off to Norway now!

Most Java developers know static code analysers like Checkstyle, Findbugs, or FXCop for the .Netters amongst us. And these tools are extremely helpful for pointing out the spots in your code that may need some improvement.

However, people must be motived to use such tools, and in real-life this is not always the case. After all, quite often people are not really interested in code quality. Especially since for most non-programmers code quality is something that happens ‘behind the scenes’. “We will worry about code quality when we have time for it… now we’ve just got to get our app up and running, right?”. Wrong!

Quality matters, it will make you a happier programmer both in the short run and in the long run. You will spend less time working on high quality code than on low quality code. It makes your application more durable. Software that lasts, that is easy to understand, flexible to use. But not everybody has this high quality bling-bling mindset. So, how do you motivate people to care about quality?

The answer is: let emotion kick in!

The lessons that can be learned from good presentations, enjoyable movies, and successful marketing strategies is that emotion makes people care. Remember your greatest movie. Isn’t it true that you can really identify with the main characters? Didn’t you forget the time when you were watching that great presentation? Read for example Made To Stick to learn about 6 elements of why some ideas survive and others die.

So, how to make code quality emotional? Should we all be crying? Laughing? Perhaps… but there are more options…

One of the things that works extremely well on the project I am currently working on is using competition. We use Hudson as our continuous integration server. Hudson allows you to use plugins to enhance the capabilities of Hudson. One of these plugins we use is the “Continuous Integration Game plugin“. This plugin gives you positive scores for successful builds, passing unit tests, fixing problems, etc., and it awards you negative points for breaking the build, failing unit tests, introducing warnings etc.

Since we have been using this plugin all team members want to win! They want to get the highest scores, so everybody is looking for opportunities to improve the code, to fix that warning before checking in, or get rid of that duplicate code. And of course, getting the highest score may seem to be the goal for some people, at least a very positive side-effect of this emotional involvement is that code quality does actually get better and better! It is also very good for the team spirit, believe me, lots of laughs!! And you may be wondering, how is this emotional? Well, since all team members get personally involved and are praised personally for high scores, people are emotionally involved.

So my advice: try to use some emotional aspects like a competition in your team so that people really do get motivated to work for example on quality. And even though people may be far more interested in the score, you still have the side-effects of lots of fun and producing high code quality in your team.

Yet another design for the GUI. Your feedback is more than welcome!

I am working on a software application for time-tracking / project management / data visualization and analysis (of your projects). I am going to build this application in Scala and Liftweb. I am switching between developing, working out ideas, GUI design, and everything else I like to be doing to get this application off the ground.

Currently I am working on a screen design for a dashboard (see below). It is just a work in progress, but since I am a proponent of iterative and evolutionary development, I’d like to present you this screen design of a dashboard. It is not finished yet, and should just give an impression of the direction I am going. There are some questions that are unanswered for now, like: should I create multiple dashboards, or just one you can filter? Anyway, here is the design:

Your feedback is more than welcome!

Hellmann’s - It’s Time for Real from CRUSH on Vimeo.

Today I read an article in an online ICT magazine that a Dutch hospital has chosen some web-based BI platform, of which I won’t mention its name, to measure performance. And even though I do support the hospital’s decision for a product that allows for visual performance analysis, I do regret however the fact the the visualizations that the platform offers are not always the most intuitive.

Currently I am reading the book “Now You See It: Simple Visualization Techniques for Quantitative Analysis” by Stephen Few, a guru on data visualization. This book is all about the fundamental principles and practices of quantitative data analysis. It explains why some data visualizations work better than others.

Looking at the visualizations the platform offers that the hospital has chosen, I believe there is some room for more intuitive visualizations. An example: the platform allows for 3D pie chart visualizations.

First of all, 3D is most of the times harder to comprehend than 2D, because the illusion of depth makes it harder to interpret the diagram (also, in 3D bar charts, the bars often hide bars that are in the background, so the may be hidden completely, causing you to overlook some potential vital information for your analysis).

Now for the pie chart, consider the following image, just randomly picked from the Internet:

The purpose of a pie chart is usually to compare data. Looking at this pie chart there are 2 things one can compare: angles and surfaces. But because of the shapes of the pieces of the pie, humans naturally have some difficulties evaluating the differences in size. You can see that the red area is probably a little bigger than the green area, but it is hard to determine how much exactly.

Most of the time when comparison is your purpose, consider using bar charts. Look at the image below (also picked randomly from the Internet), comparing bars is much easier. Especially if the bars are ordered by size, and not alphabetically by the name of their labels.

As for the hospital, I generally feel that the user interface of the product they’ve chosen is too busy, too distracting from the actual visualizations. I really hope that they are able to get the ‘aha’-moments they seek with this product.