Excellent Presentation How To Treat New Committers

31. October, 2011

By Michael Meeks: Interacting with new Developers …

Four pages of wisdom.




27. October, 2011

I’ve been developing web applications for the past few years. Recently, we evaluated many of the web frameworks out there to select one for the next major release of our product.

We looked at Wicket, GWT, Vaadin, ZK, Roo and a couple of others.

Wicket was quickly dropped from the list. It’s a nice framework but it lacks one important feature: A library of reusable, cross browser components. Yeah, there are a couple but they are all very basic and building complex UIs with Wicket is done in HTML and that’s just painful.

Roo is too slow and immature and suffers from the same problems as Wicket. Maintaining cross-browser compatibility for a complex web application is something that a small team of developers can’t do anymore today.

GWT was dropped because Vaadin is based on it.

That left Vaadin and ZK.

Vaadin looks good, it’s free and based on GWT which is backed by Google. The main issue with Vaadin is that the technology is … unapproachable. There is a decent set of components but tweaking them is a pain. Plus the Java -> JavaScript compilation takes a lot of time. It’s better than most other frameworks but doesn’t compare to ZK.


ZK has a big set of well designed components with a huge documentation how to tweak them. The docs explain in detail how the components are built from HTML elements, which CSS styles are used and how you can override them. There is even a visual CSS editor that helps doing this.

When working with ZK, you often run into situations where something doesn’t work but so far, I’ve found a good solution within a short time. This might also be possible with Vaadin but it didn’t happen for me.

There are a lot of powerful layouts to arrange your UIs. You can cleanly mix ZUL (the UI descriptions) with Java code to get the best from both worlds: A clean UI description and compact code to attach listeners, publish events and connect components.

Also, ZK hides the request cycle. This is one of the biggest source of problems with developers. Yeah, the request/response cycle makes it easier to write web browsers and server frameworks but it’s a major pain for application developers. With ZK, you’re writing code that looks like a desktop application. It’s a bit like GWT in this respect but GWT feels … “proprietary”. In ZK, a lot of the API is public. In GWT, a lot of the API is hidden away in final static factory methods buried in calls between 50 classes.

You can use JavaScript but the JavaScript isn’t hidden in pseudo-native functions. That ZK5 is based on jQuery is an additional bonus if you really need to get your hands dirty.

The demo page contains lots of useful examples (instead of simply listing the available components like many other frameworks). There is a sandbox where you can modify small ZK projects online.

ZK does have its share of problems, too. Testing is a weak point. Selenium probably works well enough for mouse-driven apps but if you have components which can be controlled by keyboard alone, Selenium doesn’t cut.

The documentation on the web site could be better; for beginners, it’s especially confusing that the documentation for ZK3 and ZK5 is hard to tell apart.

But all in all, I’ve been faster to solve any problem I’ve had so far with ZK than with any other web framework.

Well done.

Using Maven to Patch Third Party Code

26. October, 2011

If you have the source for the dependency, patching the code is simple: Just create a small Maven project that compiles the source with your changes. Since your changes are probably small, you need only a few tests: What’s the point to test the code that you didn’t touch? Also the build will be simple (just compile the sources for your need, no fancy resource processing/filtering).

But what if you don’t have the sources? Jakub Holý has a solution: Hacking A Maven Dependency with Javassist to Fix It

One Step Closer to Levitation

20. October, 2011

Everyone has seen the floating-frozen-thingy-over-a-magnet, right?

There have been miniature train models running over simple or more complicated tracks.

This one is slightly different: The configuration allows to adjust the angle and height of the object:

(Source: WIN blog)

Stand up for your freedom to install free software!

19. October, 2011

Read the truth behind so-called “Secure Boot” and sign the statement.

Do You Know Your Limits?

17. October, 2011

This interesting talk by Dan Ariely – Are we in control of our own decisions? – got my thinking. Dan says:

We understand our limitations. And we build around it. But for some reason when it comes to the mental world, when we design things like healthcare and retirement and stockmarkets, we somehow forget the idea that we are limited. I think that if we understood our cognitive limitations in the same way that we understand our physical limitations, even though they don’t stare us in the face in the same way, we could design a better world.

(my italics)

I think that is a very important point. Software development is a purely mental process. We take ideas, translate them into code. We’re authors, our audience is a CPU. We write in RAM chips instead of on paper. But basically, we’re translators.

Most software developers know their tools but not their own mental limits. Ask yourself: How much brain power does it take to type on a keyboard? Got your number?

It’s about 30%. When you type yourself, you only have 70% of your brain left to think what you’re typing.

Software development is a craft but it’s not like smithery. We had anvils and fire pits at my school. When you work with yellow-hot glowing steel, a five-pound hammer and an anvil, you learn something with your first strike: This is dangerous, this is hard work, this isn’t as simple as it looks, and how fast you’re going to tire.

How do you do that? Because your brain is wired by millions of years of evolution to know such things. Your muscles are designed to give you feedback: Can I outrun my enemy or do I have to make a stand? Forging steel is built into us. The result will vary with clumsiness but every person in my class was able to hit the steel with a hammer. It takes a day to teach someone to write the most simple program in Java but it takes one sentence to teach them how to flatten iron: “Take one of those hammers and hit it here.”

If driving steel is so simple, why are we so bad at software development?

Well, it’s one of those tasks where one brain tries to achieve two conflicting goals: Write software and at the same time watch itself doing it right. It’s a dilemma. You have 70% tops unless you have trouble at home, worry for your job, are hungry or mad at the guy next door yelling in his telephone. How much of the 70% are you going to give to “write software” and how much to “do it right”?

That said, being a software developer, you’re male (98% chance). Males suck at doing two things at a time and you’re already doing at least two. How much good is adding control to the pile going to do?

Probably not much. So what can you do?

First: Don’t forget that you’re limited. Clear your brain. Heed your limits.

Second: Turn your limits into a foundation. Instead of struggling with them, accept them. Use techniques like Test Driven Development to do one thing at a time: Tests answer the “do it right?” part. When you have the test, you can forget about this and go the “write software” part.

Use you limits. They are tools just like everything else.

Dan Ariely on Our Buggy Moral Code

16. October, 2011

Another great TED talk: Dan Ariely on our buggy moral code

In a nutshell: What makes people cheat more/less? Key points:

  • Everyone cheats a little bit but there is a limit that they can’t overstep
  • More if other people around us or from the peer (same) group also cheat
  • Less if you had to think about moral code or a code of honor a short time ago (reciting the Ten Commandments or agreeing to a “MIT code of honor”)
  • More if you’re removed from the reward (think stock exchange, options, derivatives)
  • Some of these are counter-intuitive and we don’t like to test our intuition