HTML over the wire

Yes please!

DHH is on to something with his recent post on HTML over the wire. It's high time that we start tearing down this gigantic mount of complexity that we've built the last two decades and get back to application development that developers can actually understand and excell with!

YAML vs XML

Remember how everybody used to complain about "programming in XML", for instance in Spring bean definition files? Luckily we've moved beyond that and are now in the brave new world of "programming in YAML", where we can spend (waste) hours in the cloud writing Kubernetes YAML manifests, Terraform YAML templates, and so on.

• Even less readable!
• No more syntax checks with proper schemas!
• Go crazy fixing stupid indentation mistakes!
• ...

Oh the joys! Sigh...

Software maturity

While reading a news article on Domain Driven Design over at InfoQ, I came across an interesting metaphor attributed to Eric Evans (i.e. the father of DDD):

A new metaphor Evans introduced was comparing a large software system to a community garden. Looking past the obvious bounded contexts of people sharing space in the garden, he sees positive analogies to legacy systems, looking at the "abundance of maturity." Gardens are most valuable in late summer, when they are most productive. However, that is long past the stage when you can easily make changes to the garden, in early spring. Similarly, the most malleable phase for software is not when it is the most productive.

This puts an interesting perspective on something I've noticed in my own career. Just like all developers, I love getting started on a new greenfield project: things are new and exciting and together with the team you're constantly inventing new ways of tackling problems and (re)factoring the system accordingly.

Some time after the first go-live, which typically comes with a host of teething problems, the application stabilizes and slowly evolves into a mature system over the next several releases. You can no longer reinvent the wheel at this time: you're building on the foundations you established earlier.
I've found that I also get a great deal of satisfaction from this phase: shepherding a system to maturity, seeing it come to fruition and hopefully realizing it's full potential! It as this time users are most happy with what has been delivered: the software is well understood and quality is still high, making changes predictable and quick.

Over time quality slowly deteriorates and accidental complexity grows. Changes become more difficult and risky, with more regressions slipping in. Ultimately the system is replaced with something new and better, bringing everything full circle, just like in a garden.

Git and Command Line Productivity for Windows

If you're stuck on Windows (which I have to admit is not that bad nowadays), and want an easy and productive way to work with Git on the command line, I highly recommend Cmder!

Cmder doesn't need administrative privileges to be installed: you can simply unzip it and of you go! This makes it ideal for use on highly locked down machines you might find at some clients, typically large companies with strict computer policies. If you download the "full" version, it even comes with Git for Windows built in, along with a host of Unix utilities (grep, find, ...) giving you a very powerful and configurable tabbed command line experience.

Really an excellent piece of software that I highly recommend!

The Benefits of Building on Multiple Platforms

Organizational policy at a client of mine recently saw me switching my development setup from an Ubuntu Linux based machine to Windows 7 Enterprise. Before this switch everything was Linux based: development was done in Linux, continuous integration ran on Linux, and we were ultimately also deploying to Linux, albeit another distribution.

Making the switch to Windows unearthed a few subtle coding errors, mainly related to resource management. It's no secret Windows is a lot stricter when it comes to file manipulation. For instance, consider the following:

File f = new File("test.tmp");
try (FileOutputStream fout = new FileOutputStream(f)) {
 fout.write("foo".getBytes());
 fout.flush();
 Files.move(f.toPath(), new File("test.txt").toPath());
}

Using Java 8, this runs fine on Linux. However, on Windows you get an error:

java.nio.file.FileSystemException: test.tmp -> test.txt: The process cannot access the file because it is being used by another process.

Looking at the code again you can see that the file is being moved inside the try-with-resources block. In other words, we're attempting to move the file before we've closed the output stream!

In general I would advise different developers in your development team to use different platforms. That will highlight these kind of subtle errors early and will generally improve the quality of your system. It of course comes as little surprise that Juergen Hoeller (of Spring fame) told me on several occasions that he's still developing on Windows for exactly this reason! :-)

Ubuntu 15.04 on Lenovo X1 Carbon 3rd Generation

Following up on my previous post, where I talked about installing Ubuntu 14.10 on my Lenovo X1 Carbon 3rd generation, I've now gone ahead and reinstalled the machine from scratch using the recently released Ubuntu 15.04.

I'm happy to tell you installation is now a complete breeze:

• No more USB startup disk problems.
• The brightness function keys work out-of-the-box.
• The trackpoint buttons work out-of-the-box.
• No more graphics glitches (mainly text rendering) in Unity.

It even seems that the default font sizes are better suited for a WQHD display, although I can't actually confirm anything has changed here compared to 14.10. In the end, the only things I did was setting the "Scale for menu and title bars" to 1,25 in the display settings and changing the "Page zoom" to 125% in Google Chrome.

In summary: Ubuntu 15.10 just works on the 3rd generation Lenovo X1 Carbon. No tweaking required really. I highly recommend this combination for those looking for a new Linux based laptop!

Ubuntu 14.10 on Lenovo X1 Carbon 3rd Generation

I just switched my main laptop from an Asus Zenbook Prime UX31A to a Lenovo X1 Carbon 3rd generation (the 2015 model). Since I always run Ubuntu, I got started wiping the hard disk and installing Ubuntu 14.10 as the main operating system.

Although installing Linux on brand new hardware like the Lenovo X1 Carbon can be a hairy adventure, it turned out to be a pretty smooth ride. I thought I'd share what I had to do to get to an (almost) fully functional system.

• The first snag I hit was trying to boot the Ubuntu 14.10 startup USB disk. I was greeted with a somewhat unnerving "gfxboot.c32: not a COM32R image" message and a "boot:" prompt. A quick search brought me to Ask Ubuntu: simply type "live" at the prompt and hit enter. You'll boot into the Live CD where you can start the installation.
  I haven't seen other people running Ubuntu 14.10 on their X1 Carbon complain about this, so I'm not sure why I ran into this problem.
• The next issue I faced was the brightness function keys not working. Some more web searching revealed an Arch Linux thread compiling a number of issues people had encountered trying to run Linux on the 3rd generation X1 Carbon. Fixing the function key problem was again easy: just force the thinkpad_acpi module to load:

  echo thinkpad_acpi > /etc/modules-load.d/thinkpad_acpi.conf
  echo "options thinkpad_acpi force_load=1" > /etc/modprobe.d/thinkpad_acpi.conf 
  

• My laptop sports a fancy 2560 x 1440 WQHD display ("1440p"). That's great and all but with the default Ubuntu fonts text gets really tiny. Working around that involved installing the unity-tweak-tool and setting the Text scaling factor to "1,20" (explained here). I also set the default "Page zoom" to 125% in Google Chrome.

And that's about it as far as I'm concerned. There are a few more things not working properly, like the track-point buttons or fingerprint reader, but these are things I never use so I didn't bother fixing those.

So far the system has been really sweet! The hardware seems up-to-par with my previous ThinkPad which I owned many years ago (a real IBM ThinkPad X40): really rugged feel and a superb keyboard. Combine this with good Linux support and you've got a winning combination!

Good code and good wine

I've discussed the "What is good code?" question before. This is such a broad topic that people come up with all kinds of interesting analogies to describe beneficial traits of good code. For instance, Uncle Bob often compares good code to a good book: it's important to have a good story (design/architecture), introduce key characters (concepts) at appropriate times and so on. Another interesting analogy that I've heard is that good code is like a leather glove: over time it becomes more flexible in areas where it needs to be flexible and more rigid in places that need more rigidity, exactly the way good code should behave and evolve (I'm not sure where I first heard this analogy and who I should credit for it).

Another analogy I (? -- I've never heard it before so I'll be so bold as to take credit myself) came up with recently is comparing good code with good wine. An important characteristic of good wine, maybe even the most important one, is that it tastes good. Likewise, good code needs to function properly and deliver the required functionality. However, as wine aficionados will tell you, tasting good is not the only important trait of a good wine: great wine also has things like an interesting texture, a complex taste palette and so on (not being a wine connaisseur myself, I won't dwell on it). Similarly, having a functional program doesn't imply good source code. Good code needs to exhibit extra characteristics such as flexibility, testability, adhering to the principle of least astonishment and so on.

I'd love to hear about more analogies used to describe good code!

JDK8 and the future of JVM based languages

Last week at Devoxx 2011 I attended a number of sessions covering new JVM based programming languages such as Kotlin and Ceylon. Of course there were also a number of sessions talking about the usual suspects: Groovy, Scala and JRuby.

There were also a considerable amount of talks covering JDK8 and how that's shaping up. I got the strong impression that Oracle certainly doesn't want to see JDK8 turn into another multi-year debacle. Progress on JDK8 (vitual extension functions, closures, ...) seems impressive and I got a real sense of direction and focus from those involved.

I've been following the whole other languages on the JVM movement that has been going on the last couple of years with interest, but mostly as a by-stander: I'm not a hard-core, opinionated programming language expert like some. However, if I look at the input I gathered at Devoxx I can't help but make a few observations:

• Although some of the new JVM languages have interesting ideas and are definately a step up from Java, they didn't trigger that aha-erlebnis I had when I first started using Java 1.02 after having used C.
• The infectuation with dynamic typing seems to be largely over: everybody is back in agreement that strong static typing is the way to go.
• Scale can't get any love and seems destined to remain an interesting language experiment.
• Oracle is on somewhat of a mission to deliver JDK8 sooner rather than later.

All of this makes me wonder if Java's successor will actually be Java itself, but in it's 8th incarnation, and whether or not Java 8 will effectively blow all new contenders out of the water? I'm looking forward to seeing how this unfolds!

Tech support interference

It's a well known fact that developers and tech support people typically don't get along. The developers want freedom to do as they like with their machines, while the tech support guys want to close everything down, mainly for security reasons.

Sometimes this can get quite ridiculous. I recently heard a story about a development team building a web app that required Firefox compatibility, yet they were not allowed to install Firefox on their machines! Another typical example which recently came up at TSS, is developers going to great lengths to disable virus scanning software because it makes their IDEs unbearably slow.

As always, solving this conflict requires a middle-of-the-road solution. I agree that giving developers unlimited privileges on machines that are connected to production networks is an unwanted security violation. Similarly it's unacceptable to bog down a development machine to the point where the developer can no longer properly do his job. One of the better solutions I have encountered is a separate development network. This development network is an isolated sandbox where the developers reign supreme without putting other parts of the network or organization at risk.

What is good code?

As a project tech lead I do a lot of code review, so the "What is good code?" question comes up a lot. Of course there are many things that factor into the "good code" equation such as efficiency, correctness and elegance. For me the most important property of good code is that it should adhere to the principle of least astonishment. In other words: good code is code that does what you expect it to do in the way you expect it to be done.

Following this principle has important benefits when it comes to reading, understanding and maintaining a piece of code. It also typically improves the correctness of the code: you tend to get code that obviously has no deficiencies, in stead of no obvious deficiencies (as Tony Hoare said).

I was happy to learn that I'm in good company when it comes to attributing the principle of least astonishment to good code. Both Uncle Bob (in his excellent Clean Code book) and Peter Seibel (in his very interesting Coders at Work) ask several famous programmers about good code. A lot of the interviewees directly or indirectly mention the principle of least astonishment (for instance Ward Cunningham, Joe Armstrong and Simon Peyton Jones).

Mac Fanboys in Java Land

Could somebody explain to me why lots of Java (and Ruby, Phyton, ...) programmers seem to think Macs are the best thing since sliced bread? I'll be the first to admit that Apple hardware is excellent and that they have a UI flair that is unrivaled by any other company in the IT industry today.

However, as a programmer I don't care too much about dumbing it all down to a level where my grandmother can use it. I tried the Mac thing and sure it's great for some casual usage, but a number of things just annoy me when I try to get real work done:

• First of all: why does Apple treat Java as a second grade citizen?
• Why can't I resize my windows on the left side?
• Why can't Apple just use a standard PC AZERTY keyboard layout (used in Belgium where I live)? If they did, I would at least be able to find my curly braces and square brackets, and pipe symbol for that matter!
• Why does OS X need to deviate from pretty much every common Unix convention like the FHS, making things like the hosts file end up in /private/etc/hosts.
• Why is it that I need to copy the entire Eclipse installation just to be able to run two workspaces at the same time?
• Why is Apple incapable of putting a standard DVI or VGA adaptor on a MacBook?

And the list goes on! (For those wondering: I currently run Ubuntu on a Dell XPS laptop: no installation or configuration hassles, and usage freedom to boot!)