In order to set the context, here’s an old news flash: The date implementation in Java is a piece of crap.

The Java community has ranted about this madness since JDK 1.0. Java doesn’t distinguish between date and time, and manipulating dates is cumbersome and error-prone. The solution, introduced in JDK 1.1, was not to rewrite Date, but in order to ensure backward compatibility, simply wrap a Calendar around the Date object. Calendar itself introduced several more serious problems and consequently – even more frustration. There is simply no concept of points in time, intervals, or durations. Even calculating the days between two dates is not trivial. It should be. Not the least, Calendar forces you into a random integer jungle when manipulating dates. Take your pick, you have lots to choose from: HOUR_OF_DAY, HOUR, DAY_OF_MONTH, DATE, DAY_OF_WEEK, DAY_OF_WEEK_IN_MONTH.

If that is not enough, the guilty parties responsible for designing the calendar has taken Edsger W. Dijkstra perhaps a little too literally.

cal.set(Calendar.MONTH, 0)

…yields January. Yep, Calendar refers to months using a zero-based index. A long time ago, Dijkstra told all programmers to count from zero. While this is both true and important for counting and holding track of your internal indexing, it’s NOT for every single concept imaginable holding a number. The numeric representation of January is 1, and not 0. What internal index Calendar stores January at is not relevant. The offered solution is priceless. Let’s just provide yet MORE constants to choose from: cal.set(Calendar.MONTH, Calendar.JANUARY). The int possibilities are endless. This sums up to:
cal.add/set/roll(Calendar.WELCOME_TO_THE_INT_JUNGLE, Calendar.WELCOME_TO_YET_ANOTHER_INT_JUNGLE);

To make matters even worse, Calendar has proved broken as well. For instance:

• Calendar is not thread safe or immutable.
• Leap seconds can change the date represented by a serialized object
• Calendar method after doesn’t complain if you pass it a Date (or any other object…) This bug report is related to how before() and after() is broken. The bug is interesting enough, but the pure gold is found in the rejecting answer: “It’s hard to change the implementation at this point.“.

What about the Date object? We are looking at a class having 4 out of its 6 constructors, and 20 of its 28 methods deprecated. Consequently, Date should be regarded as a deprecated class. The fact that it’s not, and to some extent still necessary is a clear indication that something is horribly wrong in the date handling department. Ok, I guess I could go on and on about ranting about this. Do a quick search on java+calendar+date+broken, and you’ll have enough reading material to keep busy for a while.

Along comes Joda Time. An early bug report from 2000 asks for a replacement, but is rejected by Sun. The replacement the bug reporter asks for is Joda Time. Originating from Google SITA ATS Ltd (thanks, Ben!), Joda Time seeks to solve all challenges related to date manipulation encountered with the infamous Date and Calendar constructs. Whereas there has been some criticism of Joda Time being too complicated, introducing around 100 new classes with several levels of inheritance and so on, Joda Time has matured into a date and time API that forms the basis for JSR-310.

At JavaOne 2008, JSR-310 was presented in detail. Although no commitments about inclusion was made, JSR-310 was suggested to be included in Java 7. JSR-310 continues several of the same concepts introduced by Joda Time, instants, durations and intervals. In addition, the JSR-310 lead, Stephen Colebourne, is obviously the right man for the job. His previous project was, you guessed it – JodaTime. Everything is not in its right place, however. In December 2008, Colebourne announces a delay. But Java 7 is delayed as well, and at Devoxx 2009, Sun announced the delay of Java 7 until Q4 2010 at the earliest. Stephen Colebourne noted November 30, 2009 that this delay could be the last opportunity for getting JSR-310 into Java 7.

Someone should pay this guy to get this done. Right now, the future of date handling in Java 7 is dependent on Colebourne’s development in evenings and weekends. But everybody can help out – read more here.

JSR-310 is a specification request worth fighting for.

You can either get these tools by following the links below yourself, or as a single zipfile right here. Enjoy!

The zipfile is identical to the one Jan-Erik and I handed out on a stick during the end of our lightning talk at the wonderful Smidig2009 conference earlier today. Thanks for a great conference!

Now, for the contents. Divided into categories, the bag of candy consists of the following:

Category 0: Bread & Butter
Bread & Butter is basically the stuff you need to get around. We didn’t originally intend to include any bread & butter in the bag of candy, as much of the infrastructure essentials such as continuous integration (we would have chosen Hudson) and version control (we would probably have chosen Subversion, or GIT ) is already given in our project. However, we decided to include some of the smaller utils that, albeit not being candy, should be part of every productive programmers toolkit.

• SysInternalsSuite - a Swiss Army Knife that lets you manage, troubleshoot and diagnose your Windows systems and applications
• WinSCP - the best SCP and SFTP client for Windows. Works well with Putty.
• SyncToy - Synching content between folders just got easy
• Notepad++ – Just a decent, free text editor.
• FSCapture - Powerful, simple util for creating screen captures in a snap

Category 1: Structure your thoughts

• FreeMind - A great mind mapping tool. Is better aligned with the brain than a traditional todo-list

Category 2: Effective launching and indexing

• Launchy - A lot of competitors here, but Launchy is a nice one. A document or wiki page is no longer than a few keystrokes away.

Category 3: Stay in the zone

• Tweak UI- should have been included by default in Windows, but isn’t. No more annoying balloon tips!
• Command window here- another MS Powertoy that does pretty much what it says on the tin. Adds an option to the explorer context menu: Open Command Prompt Here.
• ClipX - Unlimited clipboard and a visual representation of both text and images. Tip: Change the paste shortcut to Alt+v (Mac-like!)
• Instant Boss – A neat timeboxing tool
• Manic Time – Monitor what you actually spend your time on
• Ghoster - focuses the active window and dims everything else.

Category 4: Automate what you do often

• AutoHotKey - a great all purpose tool for writing powerful macros real easy
• Cygwin - Almost bread and butter, a Linux like environment to Windows.
• Selenium IDE – Firefox plugin that provides an integrated development environment for Selenium tests.

Category 5: Effective developer tools

• Firebug - A FireFox plugin that lets you inspect CSS, DOM, javascript and more
• JADClipse - A Eclipse plugin that decompiles class files, seamlessly integrated in Eclipse
• Mousefeed - Theres a keyboard shortcut for everything in Eclipse. Mousefeed forces you to learn and use them.
• JDiff - Ever needed to compare two versions of an API? JDiff presents the diff in a Javadoc-ish style
• Apache Chainsaw – A GUI based log viewer – gives structure to that gigantic logfile, and live logging too!

The slides from Smidig2009
Bare in mind, these are in Norwegian!

Therefore, we are calling out for help with assembling a candy bag for productive programmers, using Eclipse on Windows XP. So far, we have this list:

Productive programmers out there: Present your weapons of choice

I mean, JavaZone is always great, but this year there was just something special to it. It was the high quality of the presentations, with a mix of world famous and home grown speakers. It was the wave of optimism that rolled across the conference, despite the crappy 2009 economy. It was the amount of beer floating around at night. It was seeing all those really great people again that I meet far too seldom. Luckily, JavaZone is this gap in between all things. So, once again, thanks!

There are different places on the net to go look for JavaZone material. Tandberg recorded most of the presentations, and made them available here . The foil sets of the Capgemini presentations can be found here and here (Anders has written some follow ups at his blog on the latter).

Oh, and we have summarized some of the presentations at the Capgemini technology blog as well!

The motivation for AOP

The application I’m working on shares many of the characteristics of a traditionally designed object oriented system. When designing such a system, an early, crucial step is to decompose that system into smaller components. The motivation for this decomposition is to separate concerns, encapsulating and modulating the design, as well as identify the layers of the application. Our application has a typical outcome of that process: A presentation layer, a business logic layer (where the domain model resides) and a data access / data base layer.

Back to the challenge: If the code for handling logging the average response time for every service call is to be included in all components executing service calls, the logging code will typically be tangled with other code in those components. Such a logging mechanism cannot be decomposed to a single object or component – it is a concern that cannot be separated. Logging is a typical cross-cutting concern, a concern that span multiple objects or components in different layers. Other examples of cross cutting concerns include transaction management and performance profiling. All of which are possible to do in the object oriented programming paradigm, albeit not straight forward. And not to forget, in the traditional OOP way of thinking, we are looking at a significant amount of work writing that ugly code. Wouldn’t it be neat if there was possible to modularize those cross-cutting concerns?

As it turns out, it is. Everybody stand back, aspects to the rescue! Aspect Oriented Programming (AOP) is designed to do just that – letting you modularize cross cutting concerns and weave them into the application at a later point, either compile-time or run-time. Compile time weaving is perhaps the most powerful of the two approaches. This approach manipulates the byte-code, meaning in effect that what you see in your files is not exactly what you get. Your compiled class file is a slightly altered version of your java source file, because the aspect are weaved with your code when compiled. Because compile time weaving alters the compile process, the run-time weaving approach has emerged as a desirable alternative. This will not alter the compile process, but instead put a proxy before the code that is to be advised runtime.

My current project relies on Spring, and luckily for us (and me!), Spring has a built in AOP infrastructure out of the box.

Spring AOP

Like all Spring things, it is very well documented. Most of the following content can be found in this documentation. As just stated, Spring AOP takes the run-time weaving approach to AOP. Like most Spring things, it is pretty easy to set up, but remember, what happens under the hood is that Spring generates some kind of proxy for you runtime. (As already mentioned, transaction management is a typical example of a cross-cutting concern. If your application is using the transaction management offered by Spring your application will in fact already be using dynamic AOP proxies behind the scenes.)

The proxy generated by Spring is either a dynamic Java proxy or a CGLib proxy.  So what’s the difference? The dynamic Java Proxy approach is the default choice. The proxy generated run time by Spring implements the same interface that the advised service implements. This approach is listed by Spring as the preferred one, because it encourages coding against interfaces. But that implies that there is only possible to advise the methods defined in the interface implemented by the service.

What if you want to intercept a method that is not listed in this interface, or even worse, what if your class doesn’t implement an interface at all? Not to worry though, just tell Spring to unleash it’s CGLib abilities!
Just set the proxy-target-class="true" to true in the aop config, and you’re ready to go. Spring will in this case create a proxy that is an extension of your advised class, NOT an implementation of the same interface that your service implements. In effect, all methods, including those methods not defined in any interface to be intercepted.

Either way, Spring AOP will behave along the lines I have sketched here:

In the sketch, I have a instance of FooService somewhere, called fooService. When I invoke foo() on that instance, I expect foo behaviour from FooService. Which, fortunately, I will get also in the Spring AOP world, albeit not straight away; Spring will create a proxy of the FooService at runtime, so that when I invoke foo on fooService, the bean loaded is actually a proxy. The Spring generated proxy provides hooks for the advice. Pretty neat. The most general advice to create in Spring AOP is an around advice, allowing for doing something both before and after proceeding. Yet there exists several others, and for the record, the Spring team recommends to use the least powerful advice type that solves your task.

But back to the challenge: The around advice fits like a glove for monitoring the average time of service calls! Before proceeding with the foo() call, just grab the current timestamp. And after foo() has completed, take yet another timestamp, and log the difference between the two timestamps.

Limitations of the proxy-based approach?

At this time, Spring AOP looked like a proper silver bullet to target all our cross cutting concerns. Then another challenge emerged: Let’s monitor the execution time of every method! This seemed trivial at first, being able to solve the challenge of logging response time for service calls.

It turned out to be quite a big difference between the two however – they differ in how the advised methods are invoked. In the first challenge, the advised methods are always called from an external caller, so that a proxy could be placed ahead of the advised method. In the second challenge, the advised method could be called internally. Consult the sketch, and imagine that we wanted to monitor the execution of a method bar() that is called from foo():

The fooService instance holds a reference to a FooService proxy. The call fooService.foo() will be intercepted by the advice, but when the target object, the real FooService, is reached, any further method calls cannot be intercepted. The reason is that these calls are not invoked on the proxy, but on the this reference. In short, calls to self cannot be intercepted by a proxy.

Spring AOP offers another AOP syntax – @AspectJ annotations. This allows for more options for advising, but because Spring is still in charge of things, the weaving is still not done compile-time, but run-time. Meaning, we are still dealing with proxies. Meaning, we still cannot monitor such internal method invocations.

The only solution I’ve found to this challenge is to introduce an aspect weaver that can weave compile time. But AspectJ is a stranger to me and the rest of the project, and the project is not to happy about taking the risk of introducing something that alters the compile process. Do you have a solution for for advising class internal method calls without introducing an compile-time aspect weaver such as AspectJ?

Please let me know!

Golden hammers and silver bullets

I have noted some amusing challenges with our metaphors, however. The first comes to play is when there exists two almost identical metaphors that describe almost the same problem. For example, we talk about golden hammers and silver bullets, two metaphors that are frequently used to describe the same scenario: There is a problem. Do we have already have a technology/tool that we know and love, and looks pretty suitable to solved this problem? Or what about this new, cool technology/tool that probably can solve all such problems? The latter question maps to the silver bullet metaphor. It’s used to describe the expectation of a technology/tool to solve all problems related to a long, prevailing problem domain. The first question maps to the golden hammer metaphor – it’s used to the describe the overuse of an already known technology/tool to solve problems the tool was not designed to solve. Or quoting Abraham Harold Maslow from his book The Psychology of Science: “When the only tool you have is a hammer, it is tempting to treat everything as if it were a nail”. The difference between the two is not hard to spot when compared this way, but in real life, these metaphors are often mixed together. I even heard about a silver hammer once.

Technical debt interpretation 1

The other challenge becomes apparent when one metaphor describes two different things. A famous metaphor is developed by Ward Cunningham and called “Technical debt”. When talking about technical debt, most people talk about the cost associated with choosing a quick and dirty solution over a cleaner one. In my current project, for example, something must frequently be added to, or fixed in the application. Let’s say there are two ways to do it: The first lets us solve the problem quick, but we must cut some corners here and there. The second results in a better, cleaner design, but takes a bit longer. Which one to choose?

Of course, the latter is the better way, but in real life, it all depends. The first way is for instance reasonable if our team is struggling to meet an important deadline. However, quick and dirty comes with a price called technical debt. It’s like borrowing money – there are interests attached to it. The longer we wait before we pay our debt, the more effort is required because we must pay interest. In the technical debt metaphor, the effort grows over time because the quick and dirty design choice makes further changes harder, and until we take the cost of refactoring (and pay that debt), we will continue to pay interest.

When the debt increases, the velocity of the team will decrease until we’ll be using most of our time paying interests, instead of developing that new, cool functionality. The problem is not to raise technical debt – as there are situations where it is sensible to borrow money, there are situations where it is sensible to cut corners as well. The problem is to ignore what we are doing.

Technical debt interpretation 2

However, this interpretation of the technical debt metaphor was not exactly what Ward Cunningham intended, as he explains in the YouTube video – he never meant that technical debt occurs as a consequence of choosing quick and dirty. Not to worry too much, even Martin Fowler seems to have misinterpreted it to some extent

What I interpret as Ward Cunningham’s intention behind the technical debt metaphor, is this: Technical debt increase over time quite naturally if not frequently refactored. The premise is that our code model something, and that something will change over time. If the code is not adapted accordingly to the changes, the code will diverge from the problem domain and fail to meet the (now changed) requirements. As a consequence, the fact that the code once modeled the problem domain perfectly doesn’t mean it can’t get you into some serious technical debt over time. As Fredrik Kalseth notes in his excellent blog, paying back technical debt is really about keeping your code clean.

Note that the first interpretations of the debt metaphor is only a simplification of the latter. Choosing quick and dirty will certainly get you into technical debt, but so will clean code that isn’t refactored to align with its requirements over time. Despite what the technical debt metaphor was originally intended to depict, interpretation variations such as these makes the information technology specific vocabulary both confusing and amusing at the same time!

Metaphors are all around

Metaphors are not as accurate as Latin, but they are probably more fun. And, as Lakoff and Johnson suggest in their famous book “Metaphors we live by”, metaphors are present everywhere, giving structure to our perception and understanding. I haven’t read the whole book, but the first four chapters can be found here. Good reading, highly recommended!

Lets write something….

…that outputs nicely on the Squeezebox!

I’m no expert at shell scripting, and I’m sure there is several more elegant way of achieving the same result. Do you know of another way? I resorted to some dirty piping. Note the sleep 1 there… I also needed (I think!) to do some substitution in order to get the whitespaces right, and sed helped me out. Here goes.


#!/bin/sh
#
MSG=$1
if [ $# -lt 1 ] ; then
echo Skriv en melding
read MSG
fi
MSG=$(echo $MSG|sed 's/ /%20/g')
(
echo show line2:$MSG font:huge centered:1
sleep 1
echo exit
) | telnet 127.0.0.1 9090
clear
exit


The text is centered and huge, and placed on line2 (the main line). More documentation on CLI is available from the SqueezeCenter web interface. It is somewhat hidden, but it’s there. Have fun!

Despite this – my very own shiny new blog. Oh, the irony. I feel I have to justify this by writing a meta post on the matter. The motivation for invalidating my criticism for blogging by blogging is threefold. First, I have always enjoyed writing. At some point, I stopped to write. No reason. I recently realized that I want to start writing again. Second,  the need to consolidate. I have bits and pieces floating around the net. This could be a good place to gather them.

Third, I’m inspired by my good friend, Are, who frequently writes stuff that proves useful or amusing for other people.  My shiny, new blog will therefore be written in English – the potential for a text being useful for someone, somewhere (quoting Are)  is probably bigger when written in English than in Norwegian.

So there you have it. I hope you will enjoy my upcoming posts!