blog.onlysimpler.com

Slowing Down AJAX With AOP

Shane Bell — Thu, 30 Aug 2007 19:50:23 +0000

A web application I'm working on at the moment uses quite a lot of AJAX to make it more interactive and to add a little eye candy to the UI. A common feature of the application is to show a progress indicator when a page is waiting for a response from the server. It's a small rotating graphic that provides some visual feedback to the user so they know something is happening. A good example of this is Gmail's red "Loading..." message.

But one problem I kept running into during development was the fact that the server was responding too quickly. Because I was running the server locally on my development machine, the browser was receiving a response from the server almost immediately. There was barely any lag.

While this is usually a good thing, in my case it was proving to be a major pain. Before the page had time to show the progress indicator the server had already returned a response. This made it very difficult for me to test if the AJAX code for the progress indicator was working correctly. Also, I was unable to see the application as it would appear in the real world - with some lag.

My first reaction was to modify the server code to include something like this:

// take a nap for 1.5 seconds
try {
    Thread.sleep(1500);
catch (InterruptedException e) {
    // ignore any exceptions
}

But I soon got sick of adding that to every method I was trying to test. And worse than that, I kept committing this "temporary" code to version control by mistake! I needed a way to slow things down without having to constantly modify code.

Aspect orient programming was the answer. I've become a big fan of AOP over the last year or so. It's really come into the mainstream recently, mainly due to it's extensive usage in Spring and to a lesser extent EJB 3.

My project uses Spring which has some pretty comprehensive AOP support right out of the box so it didn't take long to knock together a solution to my problem.

First of all I created an advice that would sleep for a configurable period of time.

import org.aspectj.lang.ProceedingJoinPoint;

public class DelayAdvice {

    private long delayPeriod;

    public DelayAdvice() {
    }

    public void setDelayPeriod(long delayPeriod) {
        this.delayPeriod = delayPeriod;
    }

    public Object delay(ProceedingJoinPoint pjp) throws Throwable {
        try {
            Thread.sleep(delayPeriod);
        } catch (InterruptedException e) {
            // ignore
        }
        return pjp.proceed();
    }
}

Then it was simply a matter of configuring Spring with a pointcut on the services I wanted to slow down.

<aop:config>
    <aop:pointcut id="serviceLayerPointcut" expression="execution(public * com.onlysimpler.SomeService.*(..))"/>
    <aop:aspect ref="delayAdvice">
        <aop:around pointcut-ref="serviceLayerPointcut" method="delay"/>
    </aop:aspect>
</aop:config>

<bean id="delayAdvice" class="com.onlysimpler.DelayAdvice">
    <property name="delayPeriod" value="2000"/>
</bean>

Simple but effective.

Be Careful With DateFormat

Shane Bell — Wed, 01 Aug 2007 23:35:23 +0000

I think the best way to improve as a developer is to accept the fact that every line of code you've ever written could have been a whole lot better. Nobody writes perfect code, and the sooner you accept that, the sooner you'll start learning new ways you can improve.

Yesterday this blog post from the boys at Atlassian highlighted a little gem that I realised I've been guilty of on more than a few occasions.

It turns out that java.text.DateFormat isn't thread safe. Who would have guessed? Well, besides the fact that there's a huge disclaimer at the bottom of the Javadoc, who would have guessed? RTFM next time I suppose.

Anyway, the Atlassian blog post pretty much sums it up - DateFormat isn't thread safe, and more importantly, the most common symptom from thread contention is output that is perfectly valid, but also completely wrong! Chances are you'll get a nicely formatted date, it just wont be the date you were expecting. Needless to say, that's bad.

I wonder how many hair-pulling, late nights have been spent by developers around the world trying to figure that one out.

I was curious to see what the results would be if two threads fought over a single DateFormat so I put together some code to test it out.

public class TestDateFormat {

    public static void main(String[] args) {

        // a date format that two threads will contend for
        final DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");

        class DatePrinter extends Thread {

            private String dateString;

            public DatePrinter(String dateString) {
                this.dateString = dateString;
            }

            public void run() {
                while (true) {
                    try {
                        Date parsedDate = dateFormat.parse(dateString);
                        String parsedDateString = dateFormat.format(parsedDate);
                        if (! dateString.equals(parsedDateString)) {
                            System.err.println(dateString + " != " + parsedDateString);
                        }
                    } catch (Exception e) {
                        System.err.println(e);
                    }
                }
            }
        }        

        new DatePrinter("01/08/2007").start();
        new DatePrinter("14/03/1978").start();
    }
}

The code creates a single DateFormat instance and two threads that both attempt to use it simultaneously. The threads are constructed with a string representation of a date. Each thread simply loops around indefinitely, converting its date string into a date object, and then converting that date object back into a string again. If all goes well then the original string should equal the converted one. If not, then it prints a message to the console.

Running the program produces a flurry of output as the threads argue over who's turn it is to use the DateFormat. Here's a snippet of some of the output it produced when I ran it:

14/03/1978 != 12/01/1982
14/03/1978 != 14/03/1414
14/03/1978 != 01/08/1978
14/03/1978 != 01/08/2007
01/08/2007 != 01/08/20072007
14/03/1978 != 13/06/56933
01/08/2007 != 15/07/19781984
01/08/2007 != 17/10/56168
01/08/2007 != 01/08/0001
01/08/2007 != 01/08/0000
14/03/1978 != 28/08/1983

As well as the occasional (and very strange) exception:

java.lang.NumberFormatException: For input string: ".1401E.14012E2"
java.lang.ArrayIndexOutOfBoundsException: -343

As you can see, many of the dates that are produced are nicely formatted, but very, very wrong. The Atlassian post suggests a number of good solutions for fixing things to ensure you get the results you expect.

I have to admit, I'm guilty of using DateFormat in the past with absolutely no regard for thread safety whatsoever. I wonder how many nasty defects I've left in my wake as a result. My apologies to any past colleagues who ended up stuck in the office until 3am fixing a DateFormat related bug I left behind :)

But at least now I've learned something to make my code just that little bit better next time.

Watch your ABCs

Shane Bell — Tue, 31 Jul 2007 22:40:21 +0000

Through a process that can only be described as blatant generalisation, I've reached the following conclusion...

There is a direct correlation between bad spellers and bad developers (or is it the other way around?).

It seems that wherever I go I come across code that's riddled with spelling mistakes and typos. I'm not talking about comments (that would be bearable), I'm talking about important stuff - class names, methods, variables, config files etc.

Now I know what you're thinking. "Get over Shane, you whining bastard, what's the big deal about a typo". Well if you just calm down for a minute, I'll tell you what's wrong with them.

First of all, they waste people's time. The other day I spent about 10 minutes chasing down a problem that was all due to a stupid typo. Someone had mistyped the name of a class so it was almost what you'd expect it to be, but not quite. Instead of "LogoutController" it was called "LogoutContoller". This meant that a separate config file that was referencing the name of the class didn't quite align with the actual (and incorrect) name and hence the whole thing didn't work.

Sure, it only took 10 minutes to track down the problem. But because of all the fuss, by the time I fixed it I'd completely forgotten what I was originally trying to do. It took another 20 minutes for me to get back into the flow. What could have taken the original developer 30 seconds to fix ended up wasting half an hour of my day.

But the real problem lies deeper than that.

I can forgive the occasional spelling mistake. We're only human and people make mistakes. But some developers have a real knack for it and seem to do it all the time. It's not that they can't spell, or have difficulty typing. It's much simpler and more fundamental than that. Usually it boils down to one of two things - they're either too lazy to fix their own mistakes, or too stupid to notice they've made one. Either way, that's bad.

That's the real issue. If someone is too lazy to fix something as fundamental as a spelling mistake, what hope do you have of them fixing something that's actually important? And if they can't even see a spelling mistake then the chances of them spotting a real problem in the code are slim to none.

The lazy ones know there's a problem, and sometimes, for a brief moment, they even consider fixing it. But instead, they prefer to pretend they didn't see it and move on. As for the stupid ones, well they're even worse.

Bad spelling is a warning sign of two personality traits you really don't want in a developer - laziness and lack of attention to detail. Computers are precise. Code either works or it doesn't, and unfortunately, close enough isn't good enough when it comes to programming. You want to work with developers who get things right, not the ones who almost get things right, but only sometimes, and only if they can be bothered.

My wife says I'm too quick to judge, and perhaps she's right. How can I make such a blatant generalisation based on something so minor. Well, besides the fact this is my blog and I can say whatever I damn well please, there's something else...

The funny thing about generalisations is this - they're generally true.

So I'm sticking to my guns. As far as I'm concerned, bad speller = bad developer.

There is Always a Way

Shane Bell — Thu, 26 Jul 2007 19:45:13 +0000

The office where I'm currently working uses McAfee security products. Someone, somewhere in the organisation seems to believe that these will protect us from evil. Anyway, one of these products is McAfee VirusScan - and it's driving me nuts. It has a painfully annoying feature called On-Access Scan that basically scans every single file you access just in case it's a virus. Every single file! Needless to say, throughout the course of a day this can be a lot of files. Now it wouldn't be so bad if it was quick about it, but it takes forever! And sadly, due to the way it's been installed, there's no in between - it either scans every file, or none at all.

As you can imagine, this gets pretty annoying real fast. Something as simple as compiling some code ends up taking 5 times as long while McAfee checks your code for viruses. It's like one of those friends that everyone had at high school who was always hanging around even though nobody liked him. No matter where you went, he always seemed to show up.

Fortunately I'm lucky enough to have administrator privileges on my PC so I was able to get rid of the annoying friend whenever I pleased. Occasionally he'd show up again after a reboot, but I could always get rid of him with a few swift kicks, I mean clicks.

Now you might think that turning off the virus scanner isn't the smartest move, but our internet access is so restricted in the office (thanks to our big brother proxy) that there's simply no chance of me finding a site that might have something sinister to offer. As for contracting a virus via email - well we use Lotus Notes and I don't think hackers can be bothered writing viruses for Notes!

Anyway, back to the annoying friend. So things were under control, I could get rid of the virus scanner any time I liked. But yesterday things changed....

When I arrived at work yesterday, my friend was back, snooping around my files. Weird. I hadn't rebooted recently, so why was he back? I didn't give it much thought at the time, I just disabled the scanner and got on with my day. But 20 minutes later he was back again. Hmmm.

I discovered that over night the system administrators had installed another annoying McAfee product - ePolicy Orchestrator. This tool lets you create a security policy that can be enforced over the network. Every 30 minutes, my PC was checking back with the policy server to make sure it was running everything it should be. Unfortunately, it noticed the virus scanner wasn't running and started it up again.

Bugger. The my friend was back and this time he wouldn't go away. Time for a new plan.

I could have tried un-installing the virus scanner, or the even whole suite of McAfee products. But I figured that probably wouldn't go down too well with the IT guys. So instead I wrote this little Ruby script that launches when I log in.

trap('INT') { exit }

while (true) do
  system 'net stop mcshield > NUL 2>&1'
  sleep 60
end

For now that seems to keep him away. I wonder what the sys admins will try next :)

Excellent Interview Question (Part 2)

Shane Bell — Mon, 18 Jun 2007 23:07:00 +0000

Just a quick follow up to my previous article on technical interview questions. It proved to be quite a popular post and I received lots of feedback and alternate solutions to the maze problem. Needless to say, many of the solutions were far superior to mine :)

Here are a couple of my favourites.

The first is from Joshua Paine. Joshua's solution is written in Javascript and wins the award for the simplest and most elegant solution.

var maze = [
      1, 0, 0, 0, 0,
      1, 0, 1, 1, 1,
      1, 0, 1, 0, 1,
      1, 0, 1, 0, 1,
      1, 1, 1, 0, 1 ];

function solvable(maze,w,h,x,y) {
  x || (x=0);
  y || (y=0);
  var i = y*w+x;
  if(x<0 || y<0 || x>=w || y>=h || !maze[i]) return false;
  if(x==(w-1) && y==(h-1)) return true;
  maze[i] = 0;
  return (solvable(maze,w,h,x,y+1) ||
          solvable(maze,w,h,x+1,y) ||
          solvable(maze,w,h,x,y-1) ||
          solvable(maze,w,h,x-1,y));
}

solvable(maze,5,5);

The second is from Aleksey Eschenko who wrote his solution in Ruby. Again, this solution is simple and to the point.

class Maze

  def initialize(array, width, heigth)
      @array, @width, @heigth = array, width, heigth
  end

  def routes
    calculate_routes([ [ [0, 0] ] ])
  end

  def [](x, y)
    if ( x >= @width || y >= @heigth || x < 0 || y < 0 ) then -1 else @array[y * @width + x] end
  end

  private

  def possible_steps(route)
    x, y = route.last
    [[x + 1, y], [x - 1, y], [x, y + 1], [x, y - 1]].select { |xy| !route.include?(xy) && self[*xy] == 1 }
  end

  def finished?(route)
    route.last == [@width - 1, @heigth - 1]
  end

  def calculate_routes(routes)
    return routes if routes.empty? || routes.select { |route| finished?(route) }.size == routes.size
    resultset = []
    routes.each do |route|
      if finished?(route)
        resultset << route
      else
        possible_steps(route).each { |xy| resultset << (route + [xy]) }
      end
    end
    calculate_routes(resultset)
  end

end

maze = Maze.new([ 1, 0, 1, 0,
                  1, 1, 1, 0,
                  1, 0, 1, 1,
                  1, 0, 0, 1], 4, 4)

puts !maze.routes.empty?

Excellent Interview Question

Shane Bell — Sat, 09 Jun 2007 12:19:00 +0000

I've always been a big believer in technical interviews that really test a candidate's knowledge. I don't believe you can get a good understanding of someone's technical abilities any other way.

Recently I had just such an interview where I was asked a fantastic technical question. Actually, it wasn't an interview as such, but a test. I went in, sat a written test and went home. I didn't even have the chance to speak to anyone until I had proven my technical ability on their test.

Personally I think that's a little harsh, but I guess it's effective. Why waste time interviewing someone unless you're sure they have the skills to do the job?

In fact, I've been in that situation before. I was interviewing a candidate who had a fantastic CV, but 10 minutes into the interview he'd already said enough stupid things to convince my colleague and I that he was clueless. But despite that, we still had to continue with the interview knowing full well that it was a complete waste of everyone's time.

Anyway, back to the interview question...

The task was to write a program (on paper) to solve a maze. Given a representation of a maze, the program simply had to return a boolean value indicating whether the maze could be solved.

Consider the following diagram. The starting point of the maze is the top left-hand corner and the goal is to travel through the maze, square by square, to the bottom right-hand corner. You can only move to squares that contain a 1, and you can only move up, down, left and right (diagonal is not allowed).

1	0	0	0	0
1	1	0	0	0
0	1	1	0	0
0	0	1	0	0
0	0	1	1	1

The highlighted path in the maze above is the valid path through the maze.

Note that a maze would typically have a number of dead ends making it more difficult to solve, and could potentially have more than one valid path to the finish. A more typical maze is shown below.

1	0	1	1	1
1	0	0	0	1
1	1	1	1	1
1	0	1	0	1
1	0	1	0	1

From the program's point of view, the maze was represented as an array of integers, as well as the width and height of the maze. For example:

int[] maze = { 1, 0, 0, 1, 1, 0, 1, 1, 1 };
int width = 3;
int height = 3;

Represents the following maze:

1	0	0
1	1	0
1	1	1

Assuming a basic x, y coordinate system with (0, 0) being the top-left hand corner and (2, 2) being the bottom right-hand corner, finding the value at a given position in the maze can be determined as follows:

int value = maze[(y*width)+x];

So that's it! You have a pen and paper, and one hour - go write a program that accepts those parameters and determines whether the maze is solvable.

Believe me, with only a pen and paper this is HARD!

NOTE: If you want to have a go at this yourself then I suggest you stop reading now and come back when you're done.

Here's the solution I came up with. I've cleaned things up a little, but the program is essentially the same as the one I frantically scrawled on paper in my interview. My solution had to be written in Java.

First of all, here's the basic algorithm I came up with.

"Starting at position (0,0) in the maze, find all adjacent squares containing a 1 that have not already been moved to. For each of these square, attempt to recursively solve the maze from that position."

My first class was a simple utility class to represent a coordinate within the maze. Nothing too exciting here:

public class Coordinate {

    private int x;
    private int y;

    public Coordinate(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }

    public boolean equals(Object other) {

        if (!(other instanceof Coordinate)) {
            return false;
        }

        Coordinate c = (Coordinate) other;
        return (c.x == this.x && c.y == this.y);
    }
}

Next up was the class to actually solve the maze. The comments pretty much explain everything.

public class Solver {

    // the details of the maze
    private int[] maze;
    private int width;
    private int height;

    // a list of visited coordinates
    private List<Coordinate> visited = new ArrayList<Coordinate>();

    /**
     * Create a new maze solver.
     * 
     * @param maze the maze to be solved.
     * @param width the width of the maze.
     * @param height the height of the maze.
     */
    public Solver(int[] maze, int width, int height) {

        // is the maze valid?
        if (maze.length != (width * height)) {
            throw new IllegalArgumentException("Illegal maze arguments.");
        }

        this.maze = maze;
        this.width = width;
        this.height = height;
    }

    /**
     * Determine whether the maze can be solved.
     * 
     * @return a boolean indicating whether the maze can be solved.
     */
    public boolean canSolve() {

        // start solving recursively from the start position
        return canSolve(new Coordinate(0, 0));
    }

    /**
     * Given a position, determine whether the maze can be solved from there.
     * 
     * @param position the current position in the maze.
     * @return a boolean indicating whether the maze can be solved.
     */
    private boolean canSolve(Coordinate position) {

        visited.add(position);

        // have we reached the end of the maze?
        if ((position.getX() == width-1) && (position.getY() == height-1)) {
            return true;
        }

        // recurse for each adjacent coordinate
        List<Coordinate> adjacent = getAdjacent(position);
        for (Coordinate coordinate : adjacent) {
            if(canSolve(coordinate)) {
                return true;
            }
        }

        // if we make it to here then the maze is unsolvable :(
        return false;
    }

    /**
     * Get a list of all adjacent coordinates in the maze that can be moved to
     * from the given coordinate. An adjacent coordinate can only be moved to
     * if it contains a '1' and if it is above, below, left or right of the
     * given coordinate and hasn't yet been visited yet.
     * 
     * @param position the position in the maze.
     * @return a list of adjacent coordinates that can be moved to.
     */
    private List<Coordinate> getAdjacent(Coordinate position) {

        List<Coordinate> adjacent = new ArrayList<Coordinate>();

        int x = position.getX();
        int y = position.getY();

        // create a list of potential adjacent coordinates
        Coordinate[] potentialCoordinates = {
            new Coordinate(x-1, y), // left
            new Coordinate(x+1, y), // right
            new Coordinate(x, y-1), // above
            new Coordinate(x, y+1)  // below
        };

        // only return unvisited adjacent coordinates containing a '1'
        for (int i = 0; i < potentialCoordinates.length; i++) {
            Coordinate c = potentialCoordinates[i];
            if (!visited.contains(c) && getValueAt(c) == 1) {
                adjacent.add(c);
            }
        }
        return adjacent;
    }

    /**
     * Get the value at the given coordinate in the maze.
     * 
     * @param c the cordinate to get the value at.
     * @return the value at the given position, or -1 if the position is invalid.
     */
    private int getValueAt(Coordinate c) {

        int x = c.getX();
        int y = c.getY();

        // only return the value from the maze if the given position is valid
        if (x >= 0 && y >= 0 && x < width && y < height) {
            return maze[(y*width)+x];
        } else {
            return -1;
        }
    }
}

And that's it really. Calling it is pretty straight forward.

int[] maze = { 
        1, 0, 0, 0, 0,
        1, 0, 1, 1, 1,
        1, 0, 1, 0, 1,
        1, 0, 1, 0, 1,
        1, 1, 1, 0, 1
}; 

Solver solver = new Solver(maze, 5, 5);
System.out.println(solver.canSolve());

I'm sure there's a much more elegant way to solve this using some fancy matrix mathematics, but I was pretty happy with this solution. The complete source code is available here

Send me an email if you have a better solution.

Readable Code

Shane Bell — Wed, 30 May 2007 11:13:00 +0000

Why do so many developer's insist on writing horribly unreadable code? I think it's because they're just plain lazy!

Ok, perhaps that's a little harsh. Maybe it's more correct to say that most developers write unreadable, messy code because they don't see the point in doing any different.

"It's only going to be read by a computer right? And a computer can read code no matter how messy it is so why bother?". Sure, a computer might be able to read it, but people wont!

One of my favorite quotes from this book is - "programs must be written for people to read, and only incidentally for machines to execute". I couldn't agree more.

How many times have you written code that worked first time and never had to be changed again? Probably not very often. The bulk of a piece of code is typically written in one sitting. But it's re-visited over and over again. Every time a defect is found or an improvement is made, some poor sucker has to read the code and figure out what it's supposed to do. And here's the thing... at some point that sucker is going to be you!

Even if you were the original author, chances are you're not going to remember what it does or how it does it. So that leaves you with one option - read it and figure it out.

Here's where things get interesting. If the author bothered to take the time to do things right and write clean, clear, commented code then this can be a simple and pleasant experience. However, if he just cobbled it together because he had to go home and was running late for his train, it can be far from pleasant. What should have taken you a couple of minutes to read and understand can end up wasting an entire afternoon and do terrible things to your blood pressure in the process.

So what do I mean when I say "readable" code? I don't want to get into religious debates on tabs vs spaces or whether to put braces at the end of a line or on the next. That's really not that important. What is important is to write code that is easy for others to read and understand. Here are a few things to consider...

Don't try to be clever and make things more complicated than they need to be. Keep it simple and to the point. You might think it's cool to use a bitwise left shift instead of just multiplying by 2, but believe me it's not!
Don't try to optimise your code. First of all you probably don't need to (at least not yet), and second, no offence, but chances are the compiler will do a better job of optimising your code than you can anyway!
Be consistent. Decide on a coding standard and stick to it, don't just make it up as you go along.
Be clear about what you're trying to do. If it's not clear, write a comment. But don't waste space with obvious and redundant comments like "iterate through the array".
Use sensible names. If you choose a poor or misleading name for a class or variable it can make the code incredibly difficult to understand. People will make assumptions based on these names, so take a few minutes to think of names that actually make sense.
Think before you write. Two minutes of thinking time now could save you hours of pain later.
Keep it clean. If something isn't used, get rid of it. Don't comment it out, delete it! You can always go back to your source control if you need it.
Remember that there's no such thing as temporary code. Despite what you might think, the code you're writing right now will probably have a much longer life that you think. So take the time to do it right the first time.
Finally, as I've said before... don't be lazy!

Basically it all comes down to taking a little pride in your code. You should be able to look back at code you've written and be proud of it. Not only will it make your life easier when you need to re-visit the code, but it will benefit the whole team. If you spend the time doing things right in your code, pretty soon you'll see the external effects of a more solid, reliable and bug-free piece of software.

What Kind Of Developer Are You?

Shane Bell — Mon, 19 Mar 2007 19:55:43 +0000

I've worked with lots of different developers. Some good, some bad, and some really, really bad. But everyone is pretty easy to categorize...

Political correctness note: The following paragraphs refer to developers as being male. This is simply to make the article a little easier to read and because I don't have the patience to type (s)he or his/hers everywhere. So don't make a big deal out of it.

Tongue In Cheek Note: Also be aware that this should be taken with a grain of salt, try not to take it too seriously. However, we all know there's a little bit of truth in every joke.

The Cobbler: The cobbler doesn't really like coding, he just does it to pay the bills. As a result, he as absolutely no interest in doing anything properly. He just beats away at the code, cobbling it into shape until the unit tests pass. Once he gets that elusive green bar, he checks it in and moves onto the next task. No time is wasted on comments or writing code that someone else may actually be able to read one day, that stuff just slows him down. If the tests pass then that's good enough. Cobblers tend to slow the entire team down as other developers often have to clean up the mess that they have left behind.

The Academic: The academic never actually gets anything done. He spends all day reading up on the latest design patterns and architectural best practices and running performance metrics against the code. Academics are typically very intelligent, and tend to write pretty good code. The problem is they rarely get around to actually writing any code. If they could just put down that whitepaper and get coding they might be able to get some work done! Academics are sometimes called "Mirror Men" as they are always looking into things.

The Modeler: The modeler is a close cousin of the academic, and gets about the same amount of work done. Typically a modeler has just completed his masters and thinks the real world is just like a university assignment. As a result, he spends much of his time drawing fancy diagrams that nobody either understands or cares about.

The Wannabe: The wannabe wrote some Pascal at high school and thinks that writing Excel macros qualifies a programming. His CV consists mostly of acronyms and he is convinced he's experienced in every programming language ever invented. Unfortunately, wannabes are typically clueless and cause more harm than good. Put them on a side project with the academics and the modelers to keep them away from your real code.

The Hardware Guy: The hardware guy is actually very useful to have around. He can build you a load balanced Linux cluster running RAID 5 in an afternoon with his eyes shut. In his spare time, he likes to dabble in programming. Unfortunately, he couldn't code his way out of a wet paper bag. But so long as you keep him busy building hardware, and keep him as far away from an IDE as possible you'll be ok.

The Architect: There are two kinds of architect - those that were once (and often still are) excellent developers and understand how software development works, and those that became architects because they sucked at programming. If you're unfortunate enough to work with the latter then you might have to sprinkle a little fairy dust throughout your code now and again to get their impossible ideas to work.

The Hacker: Hackers are usually far more interested in writing Linux device drivers for their cell phone than those boring projects thrust upon them by their real jobs. The good news is that they are often exceptional developers and if you treat them right, you might actually convince them to do some real work for you now and again.

The Old Timer: These guys are old enough to have worked with Von Neumann back in the day. Buy an old timer a few beers and he might just tell you a few stories about "the good old days" of programming with punch cards and lab coats. Old timers tend to fall into two camps. There are those who kept up with technology and know absolutely everything there is to know about computers. Be nice to these guys and maybe you'll learn a thing or two. Then there are the old timers who didn't quite manage to keep up. They often struggle to use a mouse and don't quite understand what this "internet" thing is all about.

The Consultant: The consultant works for one of those big clueless consulting companies that charges way too much for developers that deliver far too little. Consultant programmers often have arts degrees and don't know the first thing about programming. But with their snappy suits and a bit of charm, somehow they manage to sneak through anyway.

The Historian: Historians like to party like it's 1981. Their tool box consists of vi and the command line. They tried an IDE once upon a time, but didn't care for it, so went back to their pre-historic development practices. If you ever need to know how to write a vi macro then the historian is your man. However, if you need some code written any time soon, ask someone who uses an IDE.

The Genius: The genius is a rare beast. He writes readable, maintainable, well designed, stable, bug free code. Basically he just "gets it" and does things right. Not only does he get the job done, but he takes the time to do it properly. If you manage to find one of these rare developers, do anything you can to keep them happy. I mean it, anything.

Generic Methods in Java

Shane Bell — Wed, 07 Feb 2007 10:04:00 +0000

Here's something interesting I only just discovered about generics in Java.

You're probably well aware that you can write a generic method like this:

public static <T> Collection<T> commonElements(Collection<T> c1, Collection<T> c2) {
    Collection<T> results = new ArrayList<T>();
    for (T t : c1) {
        if (c2.contains(t)) {
            results.add(t);
        }
    }
    return results;
}

This is a simple method that returns a list of elements that are common between two collections. This compiler automatically determines the type of the returned collection based on the type of the input parameters c1 and c2.

Here's an example of how it might be used (assume the commonElements() method is in a class called Example)

Collection<Integer> c1 = Arrays.asList( new Integer[] { 1, 2, 3});
Collection<Integer> c2 = Arrays.asList( new Integer[] { 2, 3, 4});
Collection<Integer> common = Example.commonElements(c1, c2);

Ok, nothing new so far.

So here's what I only just discovered. You can also write generic methods that determine the return type based on what you're assigning the result to. For example:

public static <T> List<T> createEmptyList() {
    return new ArrayList<T>(); 
}

This method will create an empty list of whatever type you assign it to. So you could call the method like this:

List<Integer> listOfIntegers = Example.createEmptyList();

So long as the compiler can determine the type of variable that you're assigning to, then all is well. There is one interesting edge case where this doesn't quite work. In the example below, the compiler can't determine the type and will complain with a "type mismatch" error.

boolean condition = true;
List<String> listOfStrings = (condition ? Example.createEmptyList() : null);

To fix it, you need to prefix the method call with the type like so:

boolean condition = true;
List<String> listOfStrings = (condition ? Example.<String>createEmptyList() : null);

I only learned about this feature of generics when I accidentally discovered that Java 5 introduced a new static method to the java.util.Collections class called emptyList(). It serves a similar purpose to the old EMPTY_LIST field, but caters for generic collections.

EclEmma

Shane Bell — Mon, 05 Feb 2007 16:21:51 +0000

An excellent (and free) Eclipse plugin called EclEmma was recently released that is well worth having a look at.

EclEmma is a code coverage tool that measures exactly how much of your codebase is being executed when you run your application. Typically, you'd use it to measure how much coverage your unit tests are getting, but it's not limited to just tests. You could just as easily use it to perform usability testing for a GUI application to find areas of your application that aren't being used.

The integration with Eclipse is very nice. You can select exactly which code you want to cover (although there are few limitations around this) and the end result is a nice navigable list of source files showing percentage covered for each method. It highlights your source code too so you can see exactly which lines are (and probably more importantly those that are not) being executed.

Behind the scenes, EclEmma is based on the popular open source code coverage tool Emma (although you probably already guessed that from the name) which has been around for quite some time and is rock solid. Emma is also the tool of choice for the new code coverage functionality in version 6 of IntelliJ IDEA.

One of the unfortunate side-effects of code coverage is that it can be extremely frustrating! It's all too tempting to keep hammering away at your unit tests to try and reach that elusive 100% coverage. A word of advice... don't bother! You can waste many an hour doing that, time that's better spent writing real code :)

Schema Spy

Shane Bell — Tue, 21 Nov 2006 21:48:00 +0000

If you're working on a project that uses a relational database (I don't think I've ever worked on one that didn't) then you really need to check out SchemaSpy. It's a great tool that automatically produces a complete overview of your schema - diagrams and all.

Here's a sample of what it can produce.

It's very useful for navigating around the tables and seeing relationships between them. It even does some analysis of your schema to identify any potential problems.

One thing to note is that it takes a static "snapshot" of your schema. The information is not produced in real time, so you'll need to re-run the program now and again to keep it up to date.

The application itself is a single jar file that you can execute from a command line. You'll also need a JDBC driver so it can talk to your database.

Finally, in order to produce all the fancy diagrams, you'll need the "dot" executable from Graphviz. Check the docs for more info on that.

And best of all - it's free (as in beer).

Subversion - The 30 Second Guide

Shane Bell — Mon, 23 Oct 2006 22:13:00 +0000

Setting up a Subversion repository is one of those things that I can never seem to remember how to do. I guess that's because you tend to do it once at the start of a project and it might be 6 months before you need to do it again. And by that time you've forgotten how to do it and need to go search through the docs.

So here is a very quick guide to setting up a new repository.

Create a new repository.
```
$ svnadmin create path_to_repository
```
Modify the svnserve.conf and passwd files.

Create new project directory.

$ svn mkdir svn://path/to/repo/myproject

Create a sub-directory for the trunk (you can create branches and tags later if necessary).
```
$ svn mkdir svn://path/to/repo/myproject/trunk
```

Checkout the project and start working.

$ svn checkout svn://localhost/repository/project/trunk

Synchronized Collections in Java

Shane Bell — Thu, 28 Sep 2006 08:45:17 +0000

This is just a quick word of advice to anyone out there writing threaded code with collections. I recently had to fix an old neglected web application that was having some serious threading issues and came across this little gem.

Creating a synchronized collection is as easy. All you need to do is...

List<Long> myList = Collections.synchronizedList(new ArrayList<Long>());

However, be careful when iterating over the collection. You still need to manually synchronize code that iterates over it, even though the collection itself is synchronized. Standard operations like adding or removing elements from the collection are thread-safe and will behave as expected in a multi-threaded environment. But iterating is not as simple.

If you want to iterate over a collection that will potentially be accessed by other threads simultaneously, always synchronize on the list itself. ie:

List<Long> myList = Collections.synchronizedList(new ArrayList<Long>());

// thread safe code
synchronized(myList) {
    for (Long l : myList) {
        // do something with l here
    }
}

Failure to synchronize on the collection can cause all kinds of unexpected behavior. Typically you'll get a ConcurrentModificationException if the collection is modified while you're iterating over it, but there are no guarantees. And that's the problem. An application that falls over and dies is bad, but at least you know it's broken. An application that continues on merrily despite being broken is a very bad thing!

Closures in Java

Shane Bell — Wed, 27 Sep 2006 08:45:13 +0000

There's been some talk recently about adding closures to the Java language. I've spent quite a bit of time writing Ruby code recently, and it's amazing how useful closures and code blocks can be. They're one of those things - once you know how to use them, you start noticing all kinds of places in your code that could be solved using closures. It's like when you learn a definition of a new word and suddenly you start hearing it in conversations everywhere.

It will be interesting to see how the proposal turns out, but unfortunately we'll have to wait until Java 7 to use them. Considering how many people still haven't made the move to Java 5, this could be a while for some. In the meantime, there are a number of hacks that you can use to provide similar functionality to a closure. In fact, Apache Commons Collections even has some built in classes that provide closure-like functionality.

But if you need something quick and dirty, this should do the trick.

First, define a simple interface to represent a closure:

public interface Closure {
    public void execute(Object o);
}

The next step is to create a method that calls the execute method of the closure. The following example iterates over a collection and calls the execute method on every object.

public static void execOnEach(Collection<?> collection, Closure closure) {
    for (Object o : collection) {
        closure.execute(o);
    }
}

Finally, we write some code that uses the closure interface to execute a block of code on every object in a collection. We do this by creating an anonymous instance of the closure.

This example uses a collection of StringBuffer objects. The first call to execOnEach() converts each buffer to upper case, while the second call reverses the contents of the buffers.

public static void main(String[] args) {

    Collection<StringBuffer> c = new ArrayList<StringBuffer>();
    c.add(new StringBuffer("abcdefg"));
    c.add(new StringBuffer("hijklmn"));
    System.out.println("c = " + c);

    // capitalise everything
    execOnEach(c, new Closure() {
        public void execute(Object o) {
            StringBuffer buffer = (StringBuffer) o;
            buffer.replace(0, buffer.length(), buffer.toString().toUpperCase());
        }
    });

    System.out.println("c = " + c);

    // reverse the strings
    execOnEach(c, new Closure() {
        public void execute(Object o) {
            StringBuffer buffer = (StringBuffer) o;
            buffer.reverse();
        }
    }); 

    System.out.println("c = " + c);
}

This is a pretty trivial example, but you get the idea.

Exposing Your Privates

Shane Bell — Fri, 25 Aug 2006 13:26:55 +0000

If you've ever written any serious unit tests for your code then you'll know that testing private methods can be a bit tricky. The only class that has access to a private method is the class that defines it. So how are you supposed to test it from another class that doesn't have visibility of the method?

One solution would be to NOT declare it as private. This would work, but it's not much of a solution. Methods are made private for good reason and you can't just go around changing their access to suit your testing needs. That's just wrong.

Purists would say that you should test private methods via the public methods that expose their functionality. Purist say a lot of crap.

Seriously though, sometimes you need to test a private method, and there just no way around it. Fortunately there's easy solution to the problem. A bit of reflection should do the trick.

/**
 * Invokes a private method on a class or object. This method
 * can invoke static methods on classes, and instance methods
 * on objects.
 * 
 * When invoking an instance method, the instance of the object
 * must be passed as the first parameter. For static methods,
 * this parameter can be null.
 * 
 * @param object the object to invoke the method on (this is
 *        only applicable for instance methods, can be null
 *        for static methods).
 * @param clazz the class of object.
 * @param methodName the name of the method to invoke.
 * @param parameters parameters passed to the method.
 * @return result from the method or null if method returns void.
 */
public static Object invokePrivateMethod(Object object,
                                         Class clazz,
                                         String methodName,
                                         Object... parameters) {

    // build an array of parameter types
    Class[] params = new Class[parameters.length];
    for (int i = 0; i < parameters.length; i++) {
        params[i] = parameters[i].getClass();
    }

    Object result = null;

    // try to execute the method
    try {
        Method method = clazz.getDeclaredMethod(methodName, params);
        method.setAccessible(true);

        // are we invoking a static method or an instance method?
        if (object != null) {
            result = method.invoke(object, parameters);
        } else {
            result = method.invoke(clazz, parameters);
        }
    } catch (Exception e) {
        e.printStackTrace();
    }

    return result;
}

The javadoc comment pretty much explains it, but here's a quick example that you shows how to use it.

Let's assume we have a class called Greeter that looks like this.

public class Greeter {

    // a private instance member
    private String name;

    // public constructor
    public Greeter(String name) {
        this.name = name;
    }

    // static method that responds with a cheery greeting
    private static String sayHello(String name) {
        return "Hello " + name;
    }

    // instance method that responds with a cheery greeting
    private String sayHello() {
        return "Hello " + this.name;
    }
}

Notice it has two private methods. One is a static method, the other is an instance method. Using invokePrivateMethod() that we defined earlier we can invoke these methods as follows.

// invoke a static method
invokePrivateMethod(null, Greeter.class, "sayHello", "Shane");

// invoke an instance method
Greeter greeter = new Greeter("Shane");
invokePrivateMethod(greeter, greeter.getClass(), "sayHello");

Now you really have no excuse for not writing unit tests ;)