coacheating

A bit about coaching, a bit about cheating this time.

A colleague asks me for help with some random problem about random technology.

I might say: “push here, run that, do this…”

Or I’d say: “I don’t know. What do you think? Hang on… I bet this tool should allow doing something like that. Let’s pair on this for a moment…”

A geek like me tend to enjoy showing off with how much he knows. Sometimes it’s really hard to shut up and pretend I don’t know. There is a reward, though. It’s when we finally work out the solution together and I feel we both made a little step ahead to be better software engineers.

One wants to get things done. One aims for fabulous architecture. Many times I seem to have quite different agenda. I’d rather make someone learn stuff. So I might say “I don’t know” even if it means things are not done as quickly or the design ends up imperfect. Is it clever or just… unethical?

Whoa, deep blogging. I bet it’s this Christmas time inspiration. This blog post is sponsored by Mariah C. (All I want for Christmas is… closure in java?).

build systems @ devoxx

I couldn’t attend to the session on gradle because there was a Mockito session at the same time. For some unknown reasons I chose Mockito…

About gradle. Later on, Hans Dockter (AKA the gradle guy) was kind enough to help me writing a build.gradle for Mockito. Also, we played with multi-project builds and brand new gradle jetty plugin.

Then I went to Jason Van Zyl’s session, mostly on maven3. Third time lucky, right? Let’s not mention M1 or M2 here because I would have to use words gentlemen don’t use. Maven3 looks quite promising and I wonder what’s gonna be my first choice build system in mid-2009: gradle, maven3, or maybe something else? Felix made a wild experiment and cut an interesting, object-oriented java build system.

Oups, did I just call maven a build system? Oh, I know it is “not just a build tool” but 94.72% of developers use it to build projects so pardon me for taking this mental shortcut.

After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature. Then the natural fit for the build system is some scripting language. Quick reminder: xml is not a scripting language. Fully declarative build system like maven makes me eventually hit the boundary – it’s when the stuff that can be declared or configured is not good enough. Then I need a painless way of “specialising” my build, for example by scripting. Mind that I’m not nearly a build architect so don’t take my rambling too seriously.

I didn’t meant to complain about maven – there are many really good ideas in it. However, allow me to have my favorite build system different from maven. Good luck with your maven builds. You’ll never know when they stop building…

more of devoxx, more on interfaces

I gave my talk at devoxx and hopefully those who attended were not offended by my weird sense of humor :) Guys, we need to have more fun in IT…

Shortly after I gave the talk I had an interesting discussion about the coding style some folks call “coding to interfaces”. It started when I was asked if Mockito is able to mock concrete classes? The answer is yes, Mockito doesn’t care if you mock an interface or a class. Mockito can do it thanks to primordial voodoo magic only ancient shamans understand these days (you guessed right – it’s the cglib library).

Here starts the controversy. Should Mockito allow to mock only interfaces and hence promote “coding to interfaces”? Dan North, a respected IT guru and Mockito friend, said between the lines of one of his articles:

it allows me to mock concrete classes which I think is a retrograde step – remember kids, mock roles, not objects

What about the guy who approached me after the Mockito session told me a story about the codebase deeply proliferated with interfaces? Interfaces were introduced by developers not because they wanted to mock roles, not objects but because the mocking framework they used “promoted” coding to interfaces. This codebase was not very friendly.

To me, interface frenzy makes the codebase hard to browse, for example due to extra effort required to find implementation. Also, too many interfaces dilute the actual meaning of those interfaces that are really important. Therefore sometimes I mock classes, sometimes I mock interfaces and Mockito deals with it transparently. There are situations where I always use interfaces but let’s not bring it here.

I remember some old-school java book I read years ago. It read: “every java class should have an interface“. Don’t believe everything you read and the best example would be this blog, wouldn’t it?.

Use the coding style that works best for you. Drink mockitos only with interfaces if you like it this way.

devoxx 2008

I’m now at Antwerp, attending to devoxx 2008 conference, watching a session about REST. In few hours I’m giving a session called ‘Mockito in Action‘. Wish me luck because I have a tight schedule and there are many point of failures when writing code ‘live’ during the session :)

So far devoxx is quite impressive – I love the idea of using cinema rooms for conference sessions!