Personal opinion on software development in general, development methodologies, tools and best practices in particular

I was stunned when I discovered the existence of the calc method in CSS. Finally a way to express relative widths!

Instead of tackling the issue of ‘define width as 100% minus some amount of pixels’ by implementing some ugly hacks (javascript or wrapping everything into several divs, also called ‘divitis’) I could finally implement it in a clean way!

By using the calc function in CSS you can write something like calc(100% – 18px).

I added that to my LESS file and LESS seemed to ignore it because it can also handle expressions itself. So the CSS output was calc(82%) 😦

That disappointed but didn’t demotivate me so I continued my quest and I could also fix that – thanks to Google – by finding a way to escape stuff with LESS. Writing calc(~“100% – 18px”) should result in calc(100% – 18px) in CSS.

Uhu, SHOULD indeed! The LESS to CSS compiler from twitter – recess – we use here ignores the escaping (for the record, lessc doesn’t seem to)… Bummer!

And then again – Google to the rescue – I found the solution to my final problem! A patch for recess. I hope they’ll fix it in a future version of recess but for now the patch satisfies my needs.

I suggest you to patch recess too! How? Well uhm,…

  • First try to find where recess is installed. If it’s installed via npm it should be installed in C:\Users\<username>\AppData\Roaming\npm\node_modules\recess\lib (<username> = your username on your pc). 
  • Then open the file core.js in an editor.
  • Next, find the comment with the typo: // iterate over defintions and compress them (join with new lines)
  • The line below should be: css = (def) { 
  • Replace this by css = this.parsed ? : (def) {
  • Save your file and yup you fixed it!

Though most developers know the importance of testing, it seems that a lot of them still aren’t testing enough. And if they write tests, they test just test wrong.

Unit tests

If some tests are written in applications, most of them will be unit tests. It’s easy to test a utility class by just calling all utility methods, passing some values and checking if the expected result is returned.

A first mistake arises here. Most people don’t think out of the box, or not enough. You can test that 1 + 1 =2 , that 2 + 1 = 3 and that 3 + 1 = 4. But what’s the benefit of doing almost the same test 3 times? It’s better to test the boundary cases. Are the arguments of the sum( ) method primitive types or Objects? If they are Objects, what happens if you pass null values? If an exception is thrown, is that the expected one? Does it clearly tell what the problem is?


If for example the service layer is unit tested, all other components like the DAO layer should be mocked. In many cases this is done manually. That’s a second mistake.

By mocking stuff manually your mocks are thightly coupled to the implementation. It’s much better to use mocking frameworks. They are made for it. Just trust that they will create the mocks the way you want. Some mocking frameworks are capable of doing more than others, some are easier to use than others. My favourite mocking framework is Mockito because of its power and simplicity. EasyMock is by far the best known but imo a bit too complex to use. What was the sequence again? Expect, replay, assert, or …?

So it’s not only a matter of choosing a mocking framework. It’s also a matter of choosing the right one.

Integration tests

Integration tests are tests over different integrated parts of an application while unit tests only tests a LUW (logical unit of work). The best known type of integration tests are   tests of the DAO layer. In these tests, multiple things are validated: the input parameters, the use of the ORM tool, the correctness of the generated query (functional), if the DB can be accessed, the fact that the query is working and the fact that the correct ResultSet is returned.

A third mistake that is made often is that developers provide test data in a dbUnit XML dataset. This data is most of the time no representation of live data. The best way to handle this is to make functional people provide and maintain this test data. Because you don’t want to make them struggle with a specific XML format, it’s a good practice to use the XlsDataSet format. Data can be provided in an Excel sheet. The name of the tab is the table, in the first row, each column contains the name of the column and in all other rows, effective data is added. Insertion into the DB will be done tab per tab, from left to right. Deletion is done the other way around.

Functional tests

Functional test are forgotten too often because the perception is that they are difficult and costly to maintain. It’s true that you’ll have to tweak them to make them maintainable but executing all the same tests manually over and over again will cost much more. Also when functionality is tested and automated by means of continuous integration, there’s no need for stress for screens/functionality that will be broken in the next release.

Selenium is a great framework that is able to record functionality in the browser. A fourth mistake is made here. Most people will just record and replay the tests the way they are. Selenium keeps tracks of HTML components by their HTML id. If you don’t specify id’s in your HTML code, they can easily change if a page is updated. This will break the tests immediately even when functionality still works.

A fifth mistake is made by just pasting the recorded test in a JUnit test. Common functionality like login and logout, the time to wait for a response, … should be added to a higher level. For example, a login can be done before each test, afterwards a logout is done. This way, if something changes in login or logout functionality, tests won’t break.

A sixth mistake is the absence of testing logical flows. It’s perfectly possible that an insert, a search, an update, and a delete work on their own but that the complete flow from the creation, search, update until delete of the same entry won’t work. TestSuites are a great way to group multiple tests and run them in sequence all together.


Mistake nr seven: most of the tests are technical tests instead of functional tests. It’s much more important to test logical behaviour than to test if the things work technically. That can be done by means of Behavior Driven Design.
Given some things, when an event occurs, then what should be the outcome? Mockito has some great stuff to easily write tests in a BDD way.

Recently I was wondering how the web, technology market, gadgets, … should look like if there were no big innovators the last few years. I thought it was worth it to share my thoughts with you.

What if there was no Google?

We would probably still combine all kind of search engine’s suboptimal search results to find what we need on the web. Maybe there would exist some portal which combines these results but they wouldn’t be good at all and you would still be able to get high rankings by putting some words a thousand times in the meta data of your HTML source.

We would probably still write our documents offline, use crappy mail programs where conversations don’t exist and we always had to search for related mails if a new reply was sent. Navigation, maps-software would always lead you to the wrong place and web app interfaces would be ugly, bloated and absolutely not user friendly.

Probably for all the software, good or bad, user friendly or not, we should pay, wait months for bug fixes and new features and had to renew our license every year.

Google just has a great business model. They just improve the web instead of just selling software or licenses and that’s what I like about that company!

What if there no good alternatives for IE?

WEB 2.0 would probably not exist because there was no innovation in the browser world. Developers and web designers would get angry because of all the incompatibilities and the lack of following standards.

Due to Opera, Safari, Mozilla Firefox and Chrome, HTML5 and CSS3 will be adopted, the web will be richer and you can create a site that just works fine without ugly hacks for every new browser version.

I’m glad Microsoft finally phases out IE6 and has set up a campaign to discourage people to use IE6. I’m also glad about the way Microsoft changed, due to competition. IE9 doesn’t support CSS3 and HTML5 very well but at least it supports the new W3C standards instead of using custom CSS styles… And soon there will be IE10 which will support CSS3 and HTML5 much better. If they don’t, IE will just lose a lot of market share.

What if there was no Apple?

We would still use ugly, not user friendly mp3 players that look like an USB stick with a small screen. Tablets and smartphones maybe wouldn’t exist or at least they would be less popular. 1 problem I have with Apple is that it’s all about the hype and that their products are expensive, but they are innovative and of great quality.

Conclusion: innovation drives IT and the rest of the world. Stagnation means decline…

A couple of weeks ago I heard about Ceylon for the first time. Ceylon is a new language which will run on the JVM, influenced by Java and Scala, and has many similarities with Java and C#.  The name comes from the island Sri Lanka, also called Ceylon, and from the Ceylon tea, so the link with Java is very obvious.
A compiler release is planned for late 2011.

Ceylon’s design goals include:

  • to be easy to learn and understand for Java and C# developers,
  • to eliminate some of Java’s verbosity, while retaining its readability,
  • to improve upon Java’s typesafety,
  • to provide a declarative syntax for expressing hierarchical information like user interface definition, externalized data, and system configuration, thereby eliminating Java’s dependence upon XML,
  • to support and encourage a more functional style of programming with immutable objects and higher-order functions, and
  • to provide built-in modularity.
The authors of Ceylon -Gavin King, inventor of Hibernate, is the lead of the Ceylon project- really like Java but it doesn’t evolve a lot anymore as a language which means that the suboptimalities won’t ever get fixed. C# has some solutions for these suboptimalities, it has delegates and Java still doesn’t have clojures, getters and setters are obsolete while Java still has them, … But on the other hand C# also has some suboptimalities that Java doesn’t have…
So the guys behind Ceylon wanted to create a language which combines the best of breeds.

No static methods

Ceylon doesn’t have Java-style static methods, but you can think of toplevel methods as filling the same role. The problem with static methods is that they break the block structure of the language. Ceylon has a very strict block structure — a nested block always has access to declarations in all containing blocks. This isn’t the case with Java’s static methods.

Method annotations

Ceylon has some annotations which can be used to describe a method. The doc annotation contains documentation that is included in the output of the Ceylon documentation compiler. The documentation compiler will support several other annotations, including by, for specifying the author of a program element, see, for referring to related code elements, and throws, for alerting the user to exception types thrown by an executable program element.


doc "The classic Hello World program" by "Gavin" see (goodbye) throws (IOException) void hello() { writeLine("Hello, World!"); }

There’s also a deprecated annotation for marking program elements that will be removed in a future version of the module.

Note that annotations like docbysee, and deprecated aren’t keywords. They’re just ordinary identifiers. The same is true for annotations which are part of the language definition: abstractvariableshared,formalactual, and friends. On the other hand, void is a keyword.

String template

There are two nice things about strings in Ceylon. The first is that we can split a string across multiple lines. That’s especially useful when we’re writing documentation in a doc annotation. The second is that we can interpolate expressions inside a string literal. Technically, a string with expressions in it isn’t really a literal anymore — it’s considered a string template.

An example of a  string template:

doc "The Hello World program ... version 1.1!" void hello() { writeLine("Hello, this is Ceylon " process.languageVersion " running on Java " process.javaVersion "!"); }

The only requirement is that the string template starts and ends with a string literal.

Dealing with objects that aren’t there

In Java we’re used to the fact that command line arguments only can be retrieved via the main method’s String array parameter. In Ceylon we can retrieve command line arguments via the process object which has an attribute named arguments, which holds a Sequence of the program’s command line arguments.

An example of an improved version of the original Hello World program:

doc "Print a personalized greeting" void hello() { String? name = process.arguments.first; String greeting; if (exists name) { greeting = "Hello, " name "!"; } else { greeting = "Hello, World!"; } writeLine(greeting); 

The local name is initialized with the first of these arguments, if any. This local is declared to have type String?, to indicate that it may contain a null value. Then the if (exists ...) control structure is used to initialize the value of the non-null local named greeting, interpolating the value of name into the message string whenever name is not null. Finally, the message is printed to the console.

Unlike Java, locals, parameters, and attributes that may contain null values must be explicitly declared as being of optional type. And unlike other languages with typesafe null value handling, an optional type in Ceylon is not an algebraic datatype that wraps the definite value. Instead, Ceylon uses an ad-hoc union type. The syntax T|S represents the union type of T and S, a type which may contain a value of type T or of type S. An optional type is any type of form Nothing|X where X is the type of the definite value. Fortunately, Ceylon lets us abbreviate the union type Nothing|X to X?.

To avoid non-null checks, default values can  be specified as a method parameter. Below you can find an example.

void hello(String name="World") { writeLine("Hello, " name "!"); }

There’s an even easier way to define greeting (cfr example above), using the ? operator. It’s just a little extra syntax sugar to save some keystrokes.

String greeting = "Hello, " + name?"World" + "!";

The ? operator returns its first argument if the first argument is not null, or its second argument otherwise. Its a more convenient way to handle null values in simple cases. It can even be chained:

String greeting = "Hello, " + nickName?name?"World" + "!";

The related ?. operator lets us call operations on optional types, always returning an optional type:

String shoutedGreeting = "HELLO, " + name?.uppercase?"WORLD" + "!";

Hiding implementation details

In Java and C#, a class controls the accessibility of its members using visibility modifier annotations, allowing the class to hide its internal implementation from other code. The visibility modifiers select between pre-defined, definite visibility levels like publicprotected, package private, and private. Ceylon provides just one annotation for access control. The key difference is that Ceylon’s shared annotation does not represent a single definite scope. Rather, its meaning is contextual, relative to the program element at which it appears. The shared annotation is in some cases more flexible, in certain cases less flexible, but almost always simpler and easier to use than the approach taken by Java and C#. And it’s a far better fit to a language like Ceylon with a regular, recursive block structure.

Members of a class are hidden from code outside the body of the class by default — only members explicitly annotated shared are visible to other toplevel types or methods, other compilation units, other packages, or other modules. A shared member is visible to any code to which the class itself is visible.

And, of course, a class itself may be hidden from other code. By default, a toplevel class is hidden from code outside the package in which the class is defined — only toplevel classes explicitly annotated shared are visible to other packages or modules. A shared toplevel class is visible to any code to which the package containing the class is visible.

Finally, a package may be hidden from packages in other modules. In fact, packages are hidden from code outside the module to which the package belongs by default — only explicitly shared packages are visible to other modules.

It’s not possible to create a shared toplevel class with package-private members. Members of a shared toplevel class must be either shared — in which case they’re visible outside the package containing the class, or un-shared — in which case they’re only visible to the class itself. Package-private functionality must be defined in un-shared (package-private) toplevel classes or interfaces. Likewise, a shared package can’t contain a module-private toplevel class. Module-private toplevel classes must belong to unshared (module-private) packages.

Ceylon doesn’t have anything like Java’s protected. The purpose of visibility rules and access control is to limit dependencies between code that is developed by different teams, maintained by different developers, or has different release cycles. From a software engineering point of view, any code element exposed to a different package or module is a dependency that must be managed. And a dependency is a dependency. It’s not any less of a dependency if the code to which the program element is exposed is in a subclass of the type which contains the program element!

Instantiating classes and overloading their initializer parameters

doc "Print a personalized greeting" void hello() { Hello(process.args.first).say(process.output); }

The rewritten hello() method above just creates a new instance of Hello, and invokes say(). Ceylon doesn’t need a new keyword to know when you’re instantiating a class.

I suppose you’re worried that if Ceylon classes don’t have constructors, then they also can’t have multiple constructors. Does that mean we can’t overload the initialization parameter list of a class?

I guess now’s as good a time as any to break some more bad news: Ceylon doesn’t support method overloading either! But, actually, this isn’t as bad as it sounds. The sad truth is that overloading is the source of various problems in Java, especially when generics come into play. And in Ceylon, we can emulate most non-evil uses of constructor or method overloading using:

  • defaulted parameters, to emulate the effect of overloading a method or class by arity (the number of parameters),
  • sequenced parameters, i.e. varargs, and
  • union types or enumerated type constraints, to emulate the effect of overloading a method or class by parameter type.

We’re not going to get into all the details of these workarounds right now, but here’s a quick example of each of the three techniques:

//defaulted parameter void print(String string = "\n") { writeLine(string); }
//sequenced parameter void print(String... strings) { for (String string in strings) { writeLine(string); } }
//union type void print(String|Named printable) { String string; switch (printable) case (is String) { string = printable; } case (is Named) { string =; } writeLine(string); }

Don’t worry if you don’t completely understand the third example just yet. Just think of it as a completely typesafe version of how you would write an overloaded operation in a dynamic language like Smalltalk, Python, or Ruby.

To be completely honest, there are some circumstances where this approach ends up slightly more awkward than Java-style overloading. But that’s a small price to pay for a language with clearer semantics, without nasty corner cases, that is ultimately more powerful.

Let’s overload Hello, and its say() method, using defaulted parameters:

doc "A command line greeting" class Hello(String? name = process.args.first) { ... doc "Print the greeting" shared void say(OutputStream stream = process.output) { stream.writeLine(greeting); } }

Our hello() method is now looking really simple:

doc "Print a personalized greeting" void hello() { Hello().say(); 


Ceylon looks like a great language which has a lot of similarities with Java and C#, so easy to learn. It tries to solve the suboptimalities of both languages, to remove overhead and to set good defaults. Though at this moment I don’t know if it will be a Java killer. But I’ll keep you informed guys! Stay tuned!

Since Oracle took over Sun a lot of Java community members feared the future of their favourite programming language. And their worst nightmare came true. Oracle started lawsuits against different companies, they postponed the implementation of new language features requested through JSR’s, OpenSolaris is no longer really open source, the JDK based on JRockit is paid, … What’s next? IDE’s that will be paid? …

A lot of Java lovers, me included, hope that a new player will stand up, a new Sun, a company that has at least the same mindset as Sun (open source, community driven, …). In my opinion, Google is the ideal candidate to become the new Sun.

Active in the Java World

First of all Google is already very active in the Java world. They have Google Web Toolkit- a framework to create Rich Internet Applications in pure Java -, Google Collections – a Java library which makes it easier to manipulate collections in a type-safe way -, Google App Engine – a set of services which can be used to deploy your own java based web app on Google’s infrastructure for free, a Google Plugin for Eclipse, Google Project Hosting – supports multiple languages, Java included, Google Java Developer Tools, …

Next to that they have created Android, the most used and fastest growing OS for smartphones and tablets which has an SDK and code syntax that have many similarities with Java.

Mindset, quality and usability

Google’s mindset is very clear, a lot of Apps are available through the Android Market, some of them are paid, some of them are free. You’re free to develop your own Android app and to distribute it on the Android Market. Thanks to the great technology and usability, a lot of smartphones are equipped with Android and the number is still growing!

Google has a lot of products which can be used for free, which are of great quality, have great usability and really add value. It all started with the Search Engine, then GMail was introduced, a complete new way of managing e-mail. A lot of people use Google Adsense, Analytics and/or Adwords for their website. One can create a site easily with Google Sites, make translations with Google Translate, chat with Google talk, browse the internet with Google Chrome, create and edit documents online with Google Docs, easily find files, mails, docs and start programs on your pc with Google Desktop, manage your photo’s with Picasa and find a location with Google Maps… and then I probably forgot a lot of products…

The company culture at Google stimulates innovation and it doesn’t just deliver good products and technology but there’s also a bunch of Google lovers which is very important if you want to have an active community as a company.

Great People

Google doesn’t hire anyone, they look for great people with great minds that fit in their organization.

Google is chock full of ex-Sunites (= ex-Sun employees) like Ron Ten-Hove, Frank Kieviet, Igor Minar, Tor Norbye, Tim Bray, Alex Ruiz, Amanda Waite, Bill Sommerfeld, Ari Shamash, Eric Schmidt, Ken Russell, Chet Haase and Java founder: James Gosling!

Now that James Gosling joined Google, it’s probable that a new Java-like language will arise!

Lawsuits from Oracle

No word yet on what James will be working on, but I wouldn’t be surprised if this job offering is connected to Oracle’s lawsuit against Android. However, I’m sure a vast number of companies were planning on courting Gosling to join their ranks. It’s probably not a coincidence that Gosling has been taking the last year off. It’s possible that he was under a 1-year non-compete contract with Oracle.

Although Oracle likely owns everything that Gosling ever developed at Sun, there may be a way that he can help Google out of its legal wrangling with Oracle. One of his patents (RE38,104) is part of Oracle’s current patent infringement suit. Of course, I’m not saying that Google didn’t also want Gosling’s vast programming expertise and creative mind. I’m sure Google understands that they need to use him as more than just a patent shield – and there’s no guarantee that he could actually deflect any of Oracle’s infringement claims.


Oracle’s CEO Larry Ellison tried to maintain control of OpenOffice by kicking supporters of LibreOffice off the OO Community Council. He was defeated, though, when most of the remaining developers quit the OO project. Losing cash, Oracle decided to give in and free OpenOffice.

More info:

When you want to introduce Scrum in a fixed price project, the majority of people you’re talking to about this idea will immediately say that it’s impossible to use Scrum in a fixed price project.  Do they know that for sure? Did they ever try it? The answer to both questions is ‘NO’, no doubt about that. So why does everyone accepts that this combination is impossible?

Well, the answer is quite simple in fact. When people think about fixed price, they implicitly think about fixed budget, fixed time and fixed scope. And yes it’s true that a fixed scope and Scrum can’t go together. That’s quite obvious because one of the base principles of Scrum is that scope just can’t be fixed. That’s the idea behind the product backlog: at the beginning of a sprint, the team commits themselves to implement the most valuable stories at that moment before the end of the sprint. But the sequence of stories and even the content of the product backlog -except the stories the team is committed to-itself can change at any time.

But fixed time and fixed budget are absolutely no problem with Scrum. An argument I hear a lot is that you can’t set a deadline at the beginning of the project because you don’t know what will be delivered in the end. Because you don’t know what will be delivered in the end, you don’t know when it will be finished and you don’t know what will be the total cost of the product.
Well in my opninion, in a traditional waterfall project when people negotiate about what will be delivered, when and how much it will cost in the end, they also don’t know how long it will take and what it will cost. That’s why most sales people and project managers multiply the initial estimations with a factor 3. And even then, when the deadline is reached, still a lot of issues need to be fixed and the customer will have to pay a lot for that.

Another fact is that the customer can’t predict the future. It’s stupid to think that a person can know all features he wants in a year. Of course his mind will change! Of course he will change his mind when he tests the product! And that’s what most consultancy companies know. So they can make a lot of money by implementing change requests. So the fact that you can’t predict the price of a product on beforehand is just true. But there’s no difference between waterfall and Scrum projects…

The problem is that people want to use the same practices in the offering phase with Scrum as they are used to use with waterfall and that’s a wrong mindset. You can already create a general coarse grained product backlog at that time. Based on that backlog, a minimum set of functionalities can be defined and budget and deadline can be defined.
One can make use of the principles ‘money for nothing’ and ‘change for free’.

Change for free means that the customer can replace stories from the backlog with other stories with the same amount of storypoints at any time without any extra cost. This guarantees that in the end, a customer will get the product he wants and won’t pay more for it than initially estimated.

Money for nothing means that the customer can say that he has enough functionality delivered at any time he wants, even when not all functionalities from the initial set are delivered. The customer will have to pay a fee to the consultancy company but in the end the price per functionlity will be cheaper than what they agreed upon.

So to conclude: a better name for fixed price would be fixed budget. And fixed budget and even fixed time can go hand in hand with Scrum. The best Scrum contract model is called ‘Variable scope and cost ceiling’.

2010 in review

The stats helper monkeys at mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 9,100 times in 2010. That’s about 22 full 747s.


In 2010, there were 8 new posts, not bad for the first year! There were 39 pictures uploaded, taking up a total of 2mb. That’s about 3 pictures per month.

The busiest day of the year was May 10th with 592 views. The most popular post that day was How to make Scrum fail.

Where did they come from?

The top referring sites in 2010 were,,,, and Google Reader.

Some visitors came searching, mostly for scrum, vaadin, vaadin maven, code review wtf, and jsf lifecycle.

Attractions in 2010

These are the posts and pages that got the most views in 2010.


How to make Scrum fail May 2010


Vaadin: what’s new September 2010


Vaadin, Maven and Spring June 2010


Why webapps? March 2010


Standards: Pros and cons February 2010