JavaZone: Domain specific languages in Java

For me, one of the most inspiring talks at JavaZone this year was by Robert C. Martin. He talked about refactoring at method level, and one of the ideas he brought was that you should be able to read down a class like a book and immediately understand what was going on.

To achieve this, he said, you have to make methods that do one thing, and you have to make them short. When you give those methods meaningful names, it seems like reading a description of what the class does, and the function calls become a domain specific language. Guess I've never thought about it that way before. I used to think Domain Specific Languages was something you could do in Ruby and Groovy because of their slack syntax rules.

I've now rewritten a class that used to be about 1500 mLOC (messy Lines Of Code, that is). It is now about 500 LOC, does one thing (supports a JSF page) and delegates the rest to a nice little well tested class that also does just one thing. All this was accomplished while adding a much needed feature.

Guess it goes without saying: Martins Book: "Clean Code" is on my wish list.

Why I would never choose perforce

I know two kinds of people who like perforce: People who have never tried a modern version control system, and Roall.

Perforce has one major weakness: It is very obtrusive, forcing you to "open" every file you want "for edit" every time you want to do any change to it. This basically means that perforce is very hard to use without tool support, compared to svn or git. Add to this that when eclipse europa arrived, it took 6 months before perforce released an updated plugin. The result was many crashes with lost workspace as result.

In my opinion there is one reason why anyone would choose perforce, and that is because thy are stuck with a big repository saved with perforce.

Obviously you should not take my word for this, so add a pinch of salt to my opinion, and also try some version control systems before you decide for your next project. I've liked both subversion and git (the only two other version control systemes I've used btw.) And if you like perforce, please write a post explaining why you like it, and add a comment, or you could send me a mail at erik . itland at gmail . com, cause I am stuck with perforce. (And yes, I have already tried once to find an answer.)

So, you're stuck with <insert not so cool technology here>

This is a work in progress. Don't be surprised if this post changes over the coming weeks. This post is about small things you can do, even if you're stuck with whatever uncool technology.

Do something cool while commuting

I personally have spent a almost all my commuting time the last twelve months programming symfony. First a billing system for small businesses and then a web app for organizing work parties. The last one was for a non profit. Not paid of course. But it helps a lot to to something cool for 45 minutes in the morning before you start wrestling obtrusive frameworks that don't even respect basic things like url's. I also believe, out of personal experience, that I arrive at work more fit for work after 45 minutes of doing something cool and relevant, than after sleeping for 45 minutes more.

Update: Abhijit Nadgouda wrote about the same topic a couple of days ago.

Use test driven development to save time

When I arrive at work, I can just forget about the comfort of making changes, alt-tabbing to firefox and refreshing to see the changes. There are some smart ways of avoiding server restarts, but the most important trick I've learned so far is to do use tests as far as possible before I deploy to the server and do the final testing. This way I save time, and I avoid sitting and waiting for that server, just to loose the patience and start looking at dzone for something useful. Oh, and then you also have the usual benefits of having a test suite to help you when you find out that you have to refactor that stuff.

Update (2008-10-31): Learn mockito. It is wonderful to just write someComplicatedClass = mock(SomeComplicated.class) instead generating a mock manually.

Refactor that stuff

I've recently read Michael Feathers "Working Effectively with Legacy Code", and it contains a lot of useful hints about how to get your code testable and how to add features in a safe way, but it was first at Robert C. Martin's speech at JavaZone this year that I became really inspired to make existing code more readable. If you've time, watch that presentation. It is available here. He recently published the book "clean code". Guess I'm going to buy the book. Just watching his presentation about functions was enough to go back to work and turn a 1200 line monster class into a much more readable class of less than 500 LOC. And I'm not finished with it yet.

Find some uninterrupted time, any uninterrupted time

(I don't do this anymore. But it worked 2 years ago, before I got married.) Sometimes I've found it better to trade in a couple of hours of sleep for a couple of calm hours. If your day is filled with interruptions, and you don't have a family to take care of, try sleeping a couple of hours (not more) in the afternoon. By the time the interruptions are going to sleep, you are (hopefully) wide awake and ready to get some real work done. Uninterrupted. And since you're not paid for it, you decide what to prioritize. In the morning, you might find it useful to sleep a couple of hours again, just so you can stay awake the rest of the day.

Update: Learn The Pomodoro Technique

(2008-10-31)I have just started learning "The Pomodoro Technique" and, so far, it has been a very interesting experience. Basically it helps you staying focused and avoid internal and external distractions. Add to that that you could learn the basics in less than one hour, and that you don't have to convert your whole team to increase your own productivity.

Update: Get a headset

Headsets serve two purposes:

• Inform coworkers that you're trying avoid beeing interrupted
• "Mask" conversations to avoid beeing distracted.

You found out something useful? Blog about it

How many times have you searched for something just to find the answer at someones blog? If you've had a hard time finding out something, chances are that someone else on this planet is wondering about the same. An example: I recently had a lot of work to remove a trojan until I did a search on google for information updated last 30 days about tdsserv. It turned out to be a very new trojan, first observed around 15. of september, as far as I understood the information. I posted the solution to my blog, hoping that someone else might find it useful, too. Last time I checked, I had three results coming in from search engines, related to that post, so obviously, I was not alone. It won't get me rich, but at least I'm sharing back.