I can’t get enough of these.

This goes to the HR dept. of Apple: Hire these peeps, I say.

Oh, and while we’re at it, go grab yourself a free copy of iClip.

Digg the future

This is not a post about Actions, but bare with me.

So…

Actions. There’s always a point in the life of a project which makes use of some sort of Action Based web framework when you come face to face with that dreaded Action that has to populate an odd one million parameters to be rendered into an HTML template, objects that need to be retrieved from one million different entities residing all over the codebase, hopefully well confined in the domain space and becoming available to the action through some well thought out Service interface. You know the one. It’s the one whose execute() method is more than 10 lines long. The one whose unit test has a mocked out Service (if some decent design is anywhere to be seen, that is) with a silly number of expectations set for.

Things become even more hairy when you want to test different parts of the Action’s execution outcome, such as passing the correct values that it gets from each Service call. This involves setting the same expectations on the same ol’ mock numerous times, almost the same every time, just different enough to disallow some sort of common abstraction, diverting the attention from the intent of each particular test. I used to blame the fact that the execute() method is an Action’s sole point of activity, the main weak point of the whole Action abstraction in my opinion.

Until today.

A few hours ago, Paul Ingles came up with a suggestion so obvious, that I deserve to be shot for not having thought of it all this time. Being worried about the ugliness and size of some unit tests dealing with a situation similar to the one I just described above, I passed on my great theory about how Actions suck because you have to do everything in execute(). Well, no maan, you don’t.

If you’re lucky enough to be using Webwork, you’re probably used to the convenient way in which your getters and setters magically populate/get populated with request parameters. Of course, the standard way of doing that is the StandardJavaWay, which means one private attribute and two public methods, to set or return it.

The breakthrough suggestion was: Why don’t we put the specific service calls inside each getter? (It was a ‘View’ type of Action, by the way). In code, please, Jack:

public Thing[] getThings() {
	if (thingsHasNotYetBeenSet()) {
		//Just in case the getter is called more than once
		this.things = thingService.getThings();
	}
	return this.things;
}

We suddenly have a lean, decomposed action, and nice, concrete unit tests that state their intent clearly and test one as opposed to fifty different things at the same time.

But THIS POST ISN’T ABOUT ACTIONS

What I find really alarming with this whole story is how tightly bound inside a tiny Java box our mind is sometimes. I was so used to seeing and writing those anemic getters and setters that it never crossed my mind that they could do something useful for a change in the context of the above problem. And I deserve even more blame, because it’s been a long time now since I started complaining about declaring private fields with public getters and setters.

Another thing that drives me nuts is how we can’t get away from the getter and setter nonsense even if we want to, because the most useful tools in our armory (call me Hibernate, Webwork, etc…) are build around them. I don’t remember how we came up with the whole JavaBean concept, I don’t even want to think about how we all fell for it, but the sheer fact that everyone’s still using it is beyond my kern.

What is even more interesting, Paul, the guy whose suggestion inspired this post, in case you forgot, is primarily a .Net dude. So, .Net devs can be clever, too. Sometimes…. Heheh….

Digg the box

rbtestdox is no longer supported or existent. Sorry for the inconvenience.

rbtestdox is a Ruby port of Chris Stevenson’s TestDox. It is a command line utility for generating documentation based on unit test naming conventions. Feel free to download rbtestdox, we’d be very interested to know if anyone finds it useful, or if there are any ways it could improve upon.

P.S. Just before writing this post, I belatedly googled for Ruby TestDox implementations. It appears Chad Fowler has written his version of it sometime ago (http://wiki.rubygarden.org/Ruby/page/show/TestDox)… It doesn’t seem like it’s doing exactly the same thing - rbtestdox generates HTML documentation, but lesson learned: Never forget that someone has most probably already written what you’re planning to write. Wise words…

In an ideal world, a software development team will have six members. Two devs pairing on functionality, two devs pairing on the functional and acceptance testing infrastructure, one sys-admin that knows Linux/Unix inside out and a designer that is so good that nobody in the team ever complains about how awfully browsers interpret and implement CSS and HTML. All six members will be actively involved in the system’s architecture at all times.

Meetings will never be longer than twenty minutes and real problems, solutions and design will be identified when they really occur, whilst coding.

Common, repetitive coding tasks will be spotted early on and code generators will be written to accommodate them. Doing so will result to things delivered fast and attention will be switched to more important areas, such as the architecture, good code, UI usability and the overall quality of the product.

Development will be carried out on MacOSX and the team will not have to cater for Win32 and IE inadequacies.

In an ideal world, you’ll be allowed to code in your Megadeth t-shirt, not in smart-casual attire, because chinos and blazers justify some people’s notion that a cover is the most important part of a book, but Megadeth t-shirts actually make you smarter.

Sweet rock guitar tone will pour out of the stereo speakers all day long, because sweet rock guitar tone actually makes you code better.

The code generators will be configured through really human readable text files - not XML - and that will eventually result in a flexible Domain Specific Language that can be understood by eleven year old kids, non technical peeps and developers alike. By the later stages of the project, it will be possible for someone to write an essay in English to feed to the code generators, in order to add extra functionality to the product. And implementing this in any other language will only take the devs sitting down with their other-language-speaking-friend half a day to replicate/translate the DSL interpretations.

By then, Yahoo will have woken up to the news and will offer to buy the code, the team and their dogs for One Million Dollars. But the team will stick to their Open Source convictions and will tell Yahoo to go buy something else, because Open Source is not something you do until you become famous enough for Yahoo (and all the others) to turn your product into a Big Mac.

When the team decides they want to embark on another, more interesting adventure, they will pass the code to the community to maintain and develop.

Fast forward to the real world, when this fails miserably, the team will regret telling Yahoo to stick their money and start struggling to get venture capitalists to support their new, not so hot idea and will remember that you only get one shot, do not miss your chance to blow, cos opportunity comes once in a lifetime.

Digg some wishful thinking

Be it because we were too busy complaining about Java, or spending most of our free time exploring Ruby and Ruby On Rails, there has not been enough fanfare to follow the introduction of the new features that came packed with Java 1.5, such as varargs, autoboxing and static imports. And that’s a darn shame, if you ask me, as the possibilities for flexibility previously undreamt of are there to be explored.

Let’s consider the following piece of code:

package com.nutrun.tiger;

public abstract class Utility {

    public static void repeat(int times, Callback callback,
            Object… arguments) {
        for (int i = 0; i <= times; i++) {
            callback.yield(arguments);
        }
    }

    interface Callback {
        void yield(Object… arguments);
    }
}

Nothing special here, except one thing: Object... arguments is of course a varargs parameter, which already makes the repeat method incredibly powerful, as the yield method in the Callback interface can take 0 to n arguments. How’s that for flexible and generic and dynamic?

Let’s look at a potential use for this, to make things a bit clearer.

import static com.nutrun.tiger.Utility.*;

public class Showcase {

    public static void main(String[] args) {

        repeat(3, new Callback() {
            public void yield(Object …arguments) {
                for (Object argument : arguments)
                    System.out.println(”argument = ” + argument);
            }
        }, “rock”, “metal”, “blues”);

    }
}

Notable here is the use of the import static com.nutrun.tiger.Utility.* static import and the use of the for (Object argument : arguments) loop for extra compact code that reads nice. Not so a bad a piece of hackery, huh?

On for the home-run, then:

import static com.nutrun.tiger.Utility.*;

public class Showcase {

    public static void main(String[] args) {

	   //…

        repeat(5, new Callback() {

            int number = 0;

            public void yield(Object… arguments) {
                for (Object argument : arguments) {
                    number += (Integer) argument;
                    System.out.println(”number = ” + number);
                }
            }

        }, 3, 4, 5);

    }
}

Adding a little bit of autoboxing magic to the recipe, we end up with behavior reminiscent of dynamic languages. And that’s a great win, in my opinion, as we end up with (nearly) the best of both worlds. After all, ...arguments can carry a strongly typed Collection, reinforced by Generics…

One possible drawback I notice with the code presented above is the somehow inelegant syntax. I think the possibility to support code blocks without curly braces and semi-colons would be a nice feature that I’d really like to see introduced in future releases of Java.

Could this kind of approach be what that marketing joke, Beyond Java, should have been all about?

By now I have used Spring in a significant number of projects, in fact I’d go as far as to say that Spring has become as indispensable to ‘Enterprise’ projects as an application server. Well, at least to me and most of the people I know and work with. The most used Spring feature by far, if not the only one in most cases, is Spring IoC, AKA Dependency Injection.

I’ve seen a working attempt to programmatically configure Spring (XML configuration files have been the uncool kid in the post-Rails Java world as you might have noticed). Cool as this might sound, it didn’t really work if you ask me. It was too much work and we ended up with a castrated version of Spring IoC in which you could only use name based constructor Dependency Injection and that was about it - do correct me if I’m wrong, Ashok, Nick, Simon and co. Spring was built to be configured through XML files and moving away from that is not a trivial task. We all know the nightmares of maintaining numerous huge XML configuration files, which brings us to the main point of this post…

The most common mistake I’ve seen developers who have just been introduced to Dependency Injection do - including myself, more than once - is overusing it. The advantages that come out of it cannot be ignored. The loose coupling between objects is fantastic. The code looks much cleaner. Unit testing distinct class responsibilities in isolation suddenly becomes a breeze. Just mock or stub an external dependency, pass it through the constructor or a setter method and you don’t have to worry about its behavior in relation to the class you’re testing any more. Devs fall in love with this aspect of IoC so much that many a time I have actually seen classes, as opposed to interfaces, being injected. Which of course breaks the whole concept of IoC.

It is this addiction to injecting everything (what I like to call the Nikki Sixx anti-pattern…) that ultimately leads to huge xml configuration files and introduces a number of other code smells along the way. See, in my opinion, it’s not XML configuration’s fault at all. It is just lazy, bad, something-stinks-in-here design. It leads to the Impl smell, you know the one, where every single class has a corresponding interface. This is not what interfaces are about. Interfaces, in my opinion, are by definition, points of access through which a bunch of collaborating classes communicate with the rest of the world.

I seriously dislike adding extra code to classes only to accommodate unit tests. For the same reason, I think IoC should be really carefully thought out and avoided until the design has been considered more thoroughly and actually makes sense. If I’m having trouble testing a class in isolation from its collaborators, I much prefer stubbing them out by extending them in a private class inside the unit test and make them behave as I would expect to, instead of extracting an interface and injecting it. If I’m injecting more than two dependencies to a class, there has got to be something I’m doing wrong. Time to revise my design. I push myself hard to use interfaces and IoC only at package level. One of the greatest features of IoC is seamless component exchange without affecting anything that’s depending on the component’s behavior. The key to this is dedicating a bit more consideration as to what qualifies as a component and how clear the component is about its responsibilities.

If only components are wired with IoC, then the XML file will not only be seriously leaner and easy to manage, it will also be a great way to document and understand the manner in which the different parts of the application are communicating and interoperating. Not to mention we will end up with a seriously better designed application the best of us would be proud of. As a 70’s ex rock star who’s managed to stay alive to this day would probably tell their kids today: Go out, have your fun, but don’t go too far, because I’ve seen it happen and it’s nasty.

Digg some recreational fun in Java

One of the most popular entries in the You are not a ‘real’ Java developer until… post (that was mostly meant to be funny, by the way) was the one about the amount of lines of code required to read a file in Java.

Many people stated the obvious: All it takes is writing your own utility class, or library and reuse that. Fair enough. However, spending effort on implementing my own solution of a language feature as basic as file I/O is a major drawback in productivity. Or creativity for the matter, because it drives the focus away from more important issues that need to be addressed, like the actual business logic my application is supposed to express. Someone mentioned that there’s a basic principle that applies to all programming languages: DRY. Absolutely. So how much DRY was applied to a language that requires you to wrap its File I/O routines in a utility class after all these years?

People mentioned that a programming language’s potency should not be measured in lines of code. Could not be more correct, plus I don’t think anyone claimed this ever being a valid measure. Any ideas what it should be measured in? A popular notion was the supposed flexibility offered by Java against dynamically typed languages. Hmm… If “flexibility” is what we’re aiming at, we might as well code in C/C++. Or, in fact, Assembly. All these languages rock, by the way. I can’t imagine having to use them to write a web application for a client that needs things to be delivered on schedule, though.

Or maybe someone out there was disappointed when Collections were introduced in Java? Who needs them, when you can implement LinkedList yourself?

Back to DRY in relation to writing your own libraries. Sounds like a bit of an oxymoron has slipped in there… It’s like choosing to get a screwdriver and parts to make your own blender in order to make milkshake. I can obviously see the fun and challenge in this, but it’s not exactly what I’d like to be doing in a dynamic environment when the quality and stealth of delivery play a very important role, and this sounds much more likely to be the state of the environment most of us have to work in every day.

Trying to pinpoint what makes a language better than another is too abstract a subject for anyone to come up with any concrete suggestions anyway. However, the choice is highly dependent on the problem we’re trying to solve, and for a significant number of problems out there at the moment, there are better tools for the job than Java. And I do believe what makes a good mechanic is his judgement in terms of the choice of tools.

I guess what I’m trying to say is that it might pay off to try something new out before we dismiss it just because we feel threatened that it might take over something we already know and are comfortable with. And then decide whether it might be the way forward or not. It’s called evolution and it’s a Good Thing. That’s exactly what happened to me the first time I did import java.net.* (I still really like networking in Java, by the way).

Oh, and lighten up a little bit. It’s supposed to be fun.

This blog is, among other things, a ThoughtBlog and I would like to clarify a few of the things that I mentioned in my post on Lean Software Development as a possible evolution to Agile, that might have given the wrong impression about TW’s state and stand on Agile at the moment.

It has been rightfully pointed out to me that some of the things that I’ve said might be misinterpreted as saying that “internally, TW leaders are talking about their projects failing because of the methods they use, and they are giving up on Agile”. This, of course, is not the case. From what I see every day, I’d like to believe we are practicing Agile in a way that is rewarding both to our clients and our teams. We also cherish our status as innovators, spotting trends early - hence Lean as a possible evolution to Agile - and constantly aim to enhance our practices and methodologies for the benefit of everyone involved with TW, either as a client or as an employee.

Having read numerous recent posts on the Blogosphere suggesting potential inadequacies in Agile project management, certain comments from last night’s TW Road Show hosted by Trevor Mather and Roy Singham appear to be fueling the idea that Agile has entered a declining state.

The most obvious - to me - reason for Agile gradually falling short in some projects these days should be the fact that a growing number of companies have adopted Agile, jumping the Agile buzzword wagon mainly targeting increase in sales, without a thorough understanding of the fundamental practices and patterns involved. This results in Agile projects that fail to deliver, unsatisfied customers and ultimately a bad reputation. And let’s face it, business is very much a reputation driven world. Agile is mainly a project management process, so if there aren’t any projects to manage, Agile will have little chances of survival.

It sounds like the next step and natural evolution to Agile, according to last night’s conversations, could be Lean Software Development, as documented in Lean Software Development, the book by Mary and Tom Poppendieck. Lean is not a new concept, as it draws inspiration from systems that have existed for a long time, like the Toyota Production System, Just-In-Time and Lean Manufacturing

According to the authors, the main elements of Lean are: Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People and Optimize the Whole.

On a high level, Lean sounds much similar to Agile, maybe a bit more pragmatic and focused, but I need to do some homework, since it is a new concept to me.

The main question is: Do I, as a developer, care? The answer is quite simple, really. As long as I’m allowed to focus on writing better software, I don’t. I like Agile because it lets me pair program and practice TDD, etc, whilst working as a member of focused teams consisting of people whose primary goal is creating great software. Ideally, the project environment will accommodate this, or introduce practices that aim to aid me concentrate on what I like doing. Agile is good at these things, as far as I’m concerned, and if Lean is a step forward from Agile, then bring it on…

Lest we forget, when marketing and buzzwords have all come and gone, great products and services are still the real source of business value.

Digg this story

You had to use JDK 1.3 on a real project. In 2006.

You had to use JDK 1.3 on a real project because you had to use some ancient version of WebSphere. In 2006. And you were already wondering who might ever want to use WebSphere back when JDK 1.3 was bleeding edge…

You wanted to kill Java because it makes you do Thread.currentThread().getContextClassLoader().
getResourceAsStream(). And half of the time it doesn’t work.

Over time, you’ve used 15+ different ways to read-in a file from the context path. And most of the time you had to spend half a day to make it work.

You missed Generics with a passion after you had to work with a JDK < 1.5 for a while.

You have your own start up just because you want to use Ruby instead of Java.

You feel better for yourself when you hear that many people still use Struts.

You try not to think that every single other programming language around these days opens, reads, and closes a file handle in three lines of code.

You feel old when you consider that a native method that gets the free disk space on your hard drive has been requested eight years ago and it’s almost here now…

You have over-enginered Java code a dozen times to create functionality that resembles Ruby Code Blocks and Mix-ins.

You have to come up with an interesting use for Annotations, like it wasn’t bad enough already…

Feel free to add your own…

Digg some grumpy Java development