Shane Bell

This blog has moved!

2007-05-30T13:56:00.000+01:00

This blog has moved to here.

The new rss feed can be found at blog.onlysimpler.com/rss.xml

SchemaSpy

2006-11-21T23:31:00.000Z

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

2006-10-23T18:45:00.000+01:00

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

2006-09-28T08:45:00.000+01:00

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 behaviour. 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

2006-09-27T13:32:00.000+01:00

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 c = new ArrayList();
    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

2006-08-25T13:26:00.000+01:00

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 ;)

I'm Back

2006-08-24T09:19:00.000+01:00

It's been a while, but I'm back.

No real excuse, other than the fact that I've been out enjoying the summer. But now that that's over you can expect to hear a bit more from me, hopefully regularly.

I've added a few new books to my ultimate reading list. You'll notice a couple of Ruby books have snuck in there. I'll go into that in a bit more detail in an upcoming post.

I've also added some more random technical things that I always seem to forget.

That's it for now, but I've got lots of new things in the pipeline so stay tuned.

Random Technical Stuff

2006-05-31T21:30:00.000+01:00

This post is just a collection of random technical stuff that I can never seem to remember. I find myself regularly wasting loads of time researching something that I did just a few months (or even weeks) ago. So I figured I'd put together my own collection of technical bits and pieces here so I can refer back to them as I need them.

It's also a place for me to collect all my templates for development (things like Ant scripts, Struts config files, etc).

I'll try and update this list regularly.

Java

Template Ant script

Template log4j properties file

More to come...

Oracle

To create an Oracle synonym...

create synonym <name> for <schema>.<object>

To select the next value in an Oracle sequence...

select <sequence_name>.nextval from dual

To find out the standard TNS details for a global database name run the NAMESCTL command and execute the following query at the prompt...

query <global_db_name> A.SMD

To add a constraint to a table...

alter table <schema_name>.<table_name> add (constraint <key_name> primary key (<columns>))

To run a sql script from sqlplus (and pass the parameter 123)...

SQLPLUS <username>/<password>@<dbname> @script.sql 123

SSH

More to come...

Oracle SQL Developer

2006-03-21T11:15:00.000Z

Oracle have just released a new visual SQL that is well worth a look. I'm big fan of Toad, but you have to pay for it because the free version stops working after 30 days. Oracle's new tool is free, and everybody likes free stuff.

It does a pretty good job of all the standard stuff you ever need to do when working with a database and it has some nice visual tools and wizards. It's one big downfall is that it only works on version 9.2.0.1 and up of their database, so if you're running an older version you'll have to use something else. But overall it's a pretty solid tool.

Take a look at Oracle SQL Developer for yourself.

Some more books

2006-03-16T09:25:00.000Z

Below is the my personal "ultimate reading list". All of them sit on my bookshelf either electronically or physically and are well worth the read.

These books are mainly concerned with software development at a conceptual level. However, there are a few hardcore technical books in there too. Basically these books got me where I am today, hopefully you'll find them useful too.

I'll add to this as I think of more, but this is a good start.

And here are a few links to some free online books...

Version Management with CVS

Java Language Specification

Practical Common Lisp

The Hacker's Diet

Bruce Eckel's Books

Designing Enterprise Applications with the J2EE Platform

A Note on Distributed Computing (PDF)

Version Control with Subversion

Monkeys and Fire Hoses

2006-03-09T14:03:00.000Z

A wise university lecturer once told me this story...

If you take 3 hungry monkeys and put them in a cage with some bananas in the corner they will undoubtedly head straight for the bananas to eat them. However, if you stand outside the cage with a fire hose and spray all the monkeys each time any of them try to eat the bananas, they will eventually learn to stay away. The key to this rather unfriendly experiment is that you must give all the monkeys a good hosing each time any of them try to eat the bananas.

Now and again one of the monkeys might decide to try his luck again with the bananas, but the other monkeys will beat him back, knowing that if he tries to eat the bananas they will get wet. Eventually the monkeys will learn the rules and stay away from the bananas. At this point you can get rid of the fire hose, the monkeys have learned their lesson.

Next, you replace one of the original monkeys with a new monkey who doesn't know the rules. He will head straight for the bananas in the corner, only to be beaten up by the 2 banana fearing monkeys. Remember, they don't want him to go near the bananas for fear of getting hosed.

Eventually the new monkey will learn the rules of the cage and wont go near the bananas, if he does the others will beat him up. In fact, he will even learn to join in on the beatings every time another monkey goes near the bananas. He's not sure why, but those are the rules of the cage.

Remember, this new monkey has never been sprayed with the fire hose, he has learned the rules from the other 2 monkeys.

If you continue this process until all of the original monkeys have been replaced, you will end up with a cage full of monkeys all of which are too scared to go near the bananas in the corner. But none of them know why.

Too many people behave like this. They follow along in life never stopping to think and challenge the ideas presented to them. They do things because "that's they way they've always done them" or because "that's what everyone else is doing".

Well, we just saw what happens when you do that... you miss out on the bananas.

Think for yourself and question the norm once in a while.

Book of the Month

2006-03-08T10:38:00.000Z

I thought it might be fun to post the details of books that I'm currently reading. A "book of the month" sort of thing.

I tend to read more than one book at a time, especially thanks to my good friends over at Safari Bookshelf. But I also read books in dead tree form to keep me entertained on the way to work.

So here are two books I'm currently reading...

Joshua Bloch, the guy who wrote the book that every Java developer should own has a new book. Java Puzzlers is an excellent collection of quirks about the Java language. Arranged as a collection of puzzles that Josh has collected over the years, you are sure to learn a lot from this one.

If you're interested in starting your own software company, then this book will really get you thinking. Bob Walsh has his own successful ISV and has some great ideas on how to get started. And the foreword is written by someone with a pretty successful startup of his own.

Attachment Check

2006-03-07T15:14:00.000Z

How many times have you done this...

1. Compose email
2. Click 'Send'
3. Swear profusely
4. Add the attachment and resend it

I never learn. I've accepted that I'm destined to do this for the rest of life. But never fear, I have the answer. Well, assuming you use Outlook at least.

This snippet of VBA code should do the trick nicely.

I can't take credit for the code, thank Dan Evans for it. I just tweaked a few things and cleaned it up a little. Detailed instructions on how to install it into Outlook are posted on Dan's site.

Enjoy.

Incremental Find in Eclipse

2006-01-31T11:13:00.000Z

Those of you who use Firefox will be familar with it's fantastic incremental find feature. Just hit / and start typing your search term and Firefox will search for it as you type.

It's one of those features that after a while you just can't live without. On the rare occasions that I'm forced to use IE, I'm always disappointed when I have to revert to the old Ctrl-f find.

So you can imagine my joy when I discovered that Eclipse has this same feature. It's been there all along, I just never knew.

While you're editing a file, just hit Ctrl-j to enter the incremental find mode (you should see "Incremental Find" in the status bar if all is well). Then just type the text you're looking for and Eclipse will jump to the first instance of that text. Ctrl-k will find the next match, and Esc will get you out of incremental find mode.

Add that one to your bag of tricks and you'll save yourself 20 minutes a day :)

RSS

2006-01-11T14:38:00.000Z

The other day I made a passing comment about RSS to a group of colleagues only to be confronted with a series of blank looks saying "what's RSS?". I almost fell over!

I was amazed that a group of technology professionals didn't know what RSS was. And even worse is that they're missing out on such a useful tool.

For those who don't know (shame on you), RSS is basically a simple XML content feed that allows you to "subscribe" to information of interest to you. RSS, or it's cousin ATOM, is mostly used for news and blogs to save you the trouble of going to each of your favourite sites each day to see if there's anything new.

For example, this blog has an ATOM feed here that you can subscribe to. By using an RSS reader (there's loads of them out there) or a website that does the job for you like Bloglines you'll be notified of anything new automatically. It saves you a ton of time and means you're always the first to know what's going on.

I have a number of feeds that I read to keep me up to date on what's going on in the world of Java and technology in general. Here are a few of my favourites...

My tool of choice for RSS feeds is Mozilla Thunderbird. Mainly because I already use it for my personal email, but also because it works really well and gives you a great email-esque feel to your feeds which I think makes a lot of sense for most feeds.

So don't be one of the uninformed, go and subscribe to some feeds and be one of the people who know what's going on in the world.

Maven 2.0

2006-01-05T22:22:00.000Z

When I first heard people talking about Maven I thought to myself "Why do we need another build tool? Ant does a fine job thank you very much". But then curiosity got the better of me and I went and had a play with Maven anyway. But at that point in time the project was still in its infancy and the documentation was a little sparse. So after fumbling around for a while I decided that Maven demanded more time and effort to learn that I cared to spend and I gave up, convinced that I was better off with Ant anway.

But then a couple of months ago, Maven 2.0 was released and I decided it was time to give it another go. And I must say that things are a whole lot better now. However, I don't think I'll be saying goodbye to Ant just yet.

The underlying concepts behind Maven are its strongest feature. Maven encourages you to do things in certain ways - to follow best practises. And by doing so it makes the world a better place for everyone. Most developers have a standard Ant script they carry around with them from project to project that does most of the things they need. When a new project starts, they dig it out, tweak a few things here and there and they're up and building. But the thing is, everyone's script does essentially the same thing. They all compile, test, package, deploy etc. It took Maven to realise this and decide that if everyone structured their projects in much the same way then we could do away with all this boilerplate and just start building. And that's exactly what it does. So long as you adhere to the Maven standards, it will happily build your project for you with very little config. It's "configuration by exception" which has become the norm these days with most tools, Hibernate and EJB 3.0 are two popular examples that come to mind.

However, there's quite a difference between getting a simple example working and using Maven in a real project. It took quite a bit of effort to get a side project of mine up and running with Maven. It's a real shift of mindset moving from Ant to Maven. There were moments when the documentation let me down and I had to spend a little longer than I would have liked to figure things out, but in general things were pretty good. I'm pretty happy with my experience so far and will definitely continue to use it.

The tool support for Maven 2.0 is moving pretty quickly. There are already plugins available, and development is progressing rapidly on others.

The one thing I do love about Maven is it's site building capabilities. Have you noticed that the home pages of all the Apache projects look remarkably similar these days? Well that's because most of them use Maven to build the site. It's simple and easy to use and produces a really slick looking site. In fact, even if you don't use Maven to build your project, it's worth using it just for the site building tools!

Delicious

2005-12-29T00:57:00.000Z

If you haven't already discovered Delicious then you're missing out! I've been using it for a while now but have only recently reached the point where it's become a standard part of my day.

Basically Delicious manages your bookmarks for you and allows you to tag your links so you can easily find them later. But it also links you to a whole community of bookmarkers allowing you to share your bookmarks with others and have them share theirs with you. For example, here's my list of bookmarks.

The UI is very slick and easy to use. And there are extensions and browser buttons that make managing your bookmarks a breeze.

Go and check it out it's very cool.

JavaServer Faces

2005-12-28T22:55:00.000Z

Over the last couple of weeks I've been busy writing a small portlet application for a client. As luck would have it, I had some spare time on my hands to try out some new technology so I decided to give JavaServer Faces a whirl. And so far I'm very impressed!

JSF is Sun's attempt to include a web development framework into the Java EE spec to fill what until now has been a gaping hole. Until JSF came along, if you wanted to write a web application in Java the first step was choosing a framework. Fortunately there are plenty of options like Struts or Tapestry that do the job very well. However, they aren't standard, and these days it seems like there's a new framework being released every week! So Sun decided it would be a good idea to fill the void and include a standardised web framework as part of the spec. The great thing about this is that it becomes part of the stack and each vendor can provide their own implementation of the API.

So, what's so great about JSF I hear you ask. Well, for starters it's simple. Frameworks like Struts have a pretty steep learning curve with all those actions and forms and horribly complicated mapping files. But JSF keeps things pretty simple. Instead, you write backing beans that handle forms and listen for events. The JSF event driven programming model is simple and intuitive and eliminates much of the boilerplate code that other frameworks force you to deal with. And yes, you can test your beans with ease. Yay!

The other great feature of JSF is the set of reusable UI components that it provides. Want a table that iterates through a collection of objects? No worries. Want a form with lots of great validation and event driven actions? No problem. And the best thing is that you get a wonderfully rich UI without having to write all the fiddly Javascript that goes with it. JSF generates all that for you (don't worry, you can still call custom Javascript if you like). So all this means that you can get on with your job of writing an application rather than fighting with stupid UI problems and dealing with the tedium of forms and validation.

All in all, my little project went very well. The learning curve of JSF was small and the outcome was pretty good if I do say so myself. As I said at the start of this article, I used JSF to write a fairly simple portlet application for a client. JSF slotted in with the portlet framework nicely and didn't cause me too much grief at all. The process was essentially the same as writing a standard web application (and so it should be). I'll definitely be using JSF again for future web applications. In fact I'm already using it on another project.

If you're looking for a book to get started on JSF I can recommend this one. I must admit that didn't sit down and read the whole thing cover to cover (mainly because I used Safari to read it), but I found it to be a great reference with plenty of examples and sample code to get you up and going quickly.

So go and give JSF a try, I think you'll like it.

Oh yeah, one more thing. Apache have an open source version of JSF called MyFaces that seems pretty rock solid to me. In fact, JBoss are bundling the MyFaces libraries with the latest version of their application server.

PMD

2005-12-08T18:05:00.000Z

I've recently discovered PMD, an open source static code analysis tool for Java, and so far I'm very impressed! Basically, PMD trawls through your Java code looking for potential problems and violations of common best practises (like unused local variables, or an empty catch block) and reports on them. There's a great plugin for Eclipse (and most other popular IDEs) and from what I've seen so far, it seems like a pretty solid product.

There is a huge number of rules that it can check for you, and it's easy to customise to your liking if there are particular rules you don't necessarily agree with.

Well worth checking out.

EJB 3.0 - Part 1

2005-11-28T18:28:00.000Z

The sound of the letters E-J-B make many developers cringe. These three little letters bring back painful memories of home interfaces, deployment descriptors, java.rmi.RemoteException and of course, most painful or all... entity beans.

But there's good news on the horizon. The final release of the EJB 3 spec is just around the corner and thankfully much of the pain is now a thing of the past. I'm not saying it's perfect, but it's a huge improvement over the current disaster of EJB 2.1. Ok, perhaps "disaster" is a little harsh, but I think you'd have a hard time finding a developer who likes to program EJBs in their current state.

So what's new in the 3.0 release. Well a quite a lot actually. Here is a list of the more interesting changes...

Everything's a POJO. At last, no more "extends EJBHome" or "implements SessionBean". The new spec allows any plain old java object to be enterprise beans. This is a welcome change for those of us who like to unit test our EJBs and don't like the messy test frameworks that the current spec forces us to use.
Annotations are the new deployment descriptor. One of the more controversial new features in Java 5.0 is annotations. Love them or hate them they're here to stay. And the new EJB spec has embraced them with open arms and made them an integral part of the framework. Now you can do away with those ugly xml deployment descriptors and use annotations instead. However, if you want to continue to use deployment descriptors then that's fine too. In fact, you can even use a combination of the two.
Configuration by exception. Another welcome change. No longer do you need to configure every last option of every piece of your application. Sensible defaults are available for most things and you need only define what you want to change.
Dependency Injection. EJB has jumped on the dependency injection bandwagon and now provides some basic injection functionality. You can have JNDI resources and other beans injected for you at runtime, saving you the trouble of looking them up or creating them yourself.
No more home interface. I don't think anyone will miss them.
Simplified Persistence. Those nasty entity beans aren't so nasty anymore. For starters they can be POJOs now, and you can map them using simple annotations. Entity beans are much nicer in general really. But don't get too excited, Hibernate is still better.
AOP support (sort of). With the introduction of interceptors, EJB now lets you do some very basic aspect oriented programming. It's not fantastic, but it works and it's better than not having it all. Basically you can specify that a method on an interceptor class be called whenever a business method is called on your EJB. However, it is somewhat restricive in the way it works. It would be useful for generic stuff like logging or audit information, but it would be a little clumsy for anything too complex.
Callbacks. You can now define methods on your EJBs that will be notified of lifecycle events. By simply annotating a method as a callback method it will be notified of various events (there are several, depending on the type of bean).
Fewer checked exceptions. The question of checked vs unchecked exceptions can quickly become a heated debate. But I think it's a great idea. It removes those unecessary try/catch blocks and throws clauses and makes code so much cleaner. There's not much you can do with a checked exception at that level anyway. But if you feel you need to catch them then you still can.
Interoperability. The good news is that your old EJBs have not been rendered useless. You can still use them in conjuction with the EJB 3.0 framework. So if you have old legacy EJBs that you just can't live without, never fear, you don't have to re-write them just yet.

As you can see, there's lots of new stuff. Over the next few weeks I'll discuss all of these new features in all their gory detail. In the next article I'll discuss the changes that have been made to our good friend - the session bean.

EJB 3.0

2005-11-21T21:29:00.000Z

EJB 3.0 has been gaining momentum recently. JBoss have a working EJB 3 plugin for JBoss Application Server and recently published this customer testimonial about it working in a production environment. Oracle have an early release available too.

The spec hasn't been finalised just yet, but it's getting close and shouldn't be far away. So to prepare you for the release date, I'll be writing a series of articles on the new spec over the coming weeks explaining how the face of EJB has changed.

Stay tuned.

You Get What You Pay For

2005-11-19T13:13:00.000Z

Something I've been thinking about recently is the difference in the way most companies buy software, and the way they buy services.

When it comes to buying software, most companies think about what it is they need and carefully compare the features of each potential product. Most will consider other factors such as the product's market share, support costs and the general reputation of the product. And then, once they've narrowed down the candidates, price is typically the deciding factor.

In contrast, when a company makes a decision on who they employ to provide a services they typically consider one thing... price.

It's not just companies that think this way, consumers make decisions like this every day. When looking for a new MP3 player or a TV, people shop around and compare features before deciding on the product that suits them best. And we'll happily pay a little more for a superior product. But when looking for an accountant or someone to build an extension on the house we tend to ignore all other factors and cut straight to the case... how much will it cost?

Thinking this way is crazy! It assumes that all services are provided with the same level of quality and produce the same result in the end. And this couldn't be more wrong! Choose the cheapest accountant you can find and you could end up in jail for tax avoidance. Or choose the wrong builder and that new extension to the living room might not make it through the next storm.

When companies recruit staff they interview all the candidates and and choose the most skilled and experienced candidate for the job. They don't just ask each candidate how much they want to be paid and then choose the cheapest. And yet when choosing a service provider this is exactly what they do. They ask a handful of providers to submit a proposal and then choose the cheapest option. And sadly this often ends up being a company in India who charge $80 a day for a developer.

The problem with this approach is that not all service providers are created equal. Some provide an excellent service and produce quality results. Others take all your money and deliver very little. But as a service provider how do you make this clear to potential customers and differentiate yourself from the crowd.

To be honest, I haven't quite figured that one out just yet. But when I do, I'll be sure to let you know.

Seam

2005-11-13T12:41:00.000Z

JBoss have some excellent technology available, and one of their latest offerings that is well worth a look is a framework called Seam. Gavin King (the guy behind Hibernate) has played an integral role in its conception and recently published this blog entry about it.

Basically, Seam is an application framework that stitches together (hence the name) the pieces you need to build web applications. It is based around JSF and EJB 3.0, although you can also use Hibernate for persistence, or plug in the standalone EJB3 container from JBoss.

It's well worth investigating if you're looking for a framework to build your next web application. The only problem you may face is the fact that it needs Java 5.0 to run, so you're a bit limited in your choice of application servers. And if you want to use EJB 3.0 then you're even more limited. But there's nothing proprietary in there that locks you into JBoss, the framework is based around standard Java EE technology.

Just don't hold your breath waiting for the big boys to release a Java 5.0, EJB3 compliant app server any time soon.

Public Speaking 101

2005-11-07T18:01:00.000Z

I've been to a few presentations over the last week and I'm still amazed at how bad some people are at it! Here are my top 10 tips for better presentations. Nothing groundbreaking, just common sense. It's not rocket surgery as they say.

Be prepared. Those boy scouts are smart kids you know. Take some advice from them and prepare before your presentation. Make sure you have everything you need. Does the room have a projector? And does your laptop work with the projector? Do you have a backup of your slides? Do you have another backup of the backup? And is it in a format that someone else's laptop can read if Murphy turns up and your machine suddenly stops working? Do you have a hard copy so that if technology stops working that day at least you can hand out photocopies.

Tell us what you are there to talk about. Don't just launch into it, give some background first and if necessary, give a brief overview of the subject to get everyone up to speed. And provide some context as to how your subject fits into the real world.

Keep it simple. Try to explain things in a way that everyone will understand. Obviously this depends on your audience, the more technical they are, the more technical you can be. But try to consider the lowest common denominator and explain things in a way that everyone will understand.

Keep it short. Long presentations are boring. People lose interest very quickly, so try to keep your presentation to a sensible length. Again, this depends on the audience, but after 45 mins most people's minds will begin to wander and start thinking about what's on TV tonight.

Know your subject. Don't give a presentation on something you don't know a lot about. People are there to learn and they will expect that you know what you're on about. And if you don't, people will be able to tell very quickly. After the second question you answer with "Um, I'm not sure about that one", your audience will start leaving the room pretending they're late for a meeting.

Practise. No matter how experienced you are, practise your presentation a few times to get to know it. If all you do is read out each line of your PowerPoint presentation as you go your audience will very quickly lose patience with you and start throwing things.

Give people access to your presentation. Nobody likes frantically taking notes while trying to listen to what you have to say. Let people know that they can get a copy of your presentation when you are done so they can go back over it later at their leisure. That way they can focus on listening rather than trying to write everything down.

Summarise your presentation. When writing an essay there's a saying that says - "tell us what your about to tell us, then tell us, then tell us what you told us". The same thing applies to giving a speech. People have short memories and if you want to get your point across you need to make sure you reiterate it a few times so it sinks in.

Leave time for questions. People will want to ask questions and discuss your ideas. Make sure you give them time to do so. Running overtime indicates that you can't keep to time and that you don't really care about what your audience has to say.

Make it interesting. So many people give incredibly boring presentations that leaves the audience fighting to stay awake. Don't be one of those people. I've sat through too many boring presentations recently to face another one.

The Java Posse

2005-10-26T09:15:00.000+01:00

Just a quick one to tell you all about a great podcast that is well worth a listen.

The Java Posse consists of Tor Norbye from Sun Microsystems, Carl Quinn from Google, and Dick Wall from NewEnergy Associates. All very knowledgeable guys in the Java world.

The original Java podcast, The JavaCast, was very successful but lasted for only a few episodes. It died after a conflict of priorities between the founders Dick Wall and Brandon Werner. Fortunately Dick had the dedication to keep it alive so he joined forces with Tor and Carl and the Java Posse was born.

Most episodes go for about 30 minutes (about a commute's worth of listening) and cover a wide range of topics relating to Java. They also interview prominent industry figures. Most recently they spoke with Joshua Bloch - author of Effective Java, and a major contributor to the JDK. They also have an interview lined up with Jonathan Schwartz in the coming weeks!

You can subscribe through iTunes or download the episodes direct from the website.

Size matters

2005-10-25T20:32:00.000+01:00

The old saying goes "it doesn't matter how big it is, it's how you use it that counts". In the software world, this couldn’t be more applicable.

The big software companies like IBM and Microsoft have so many people hacking away at their products that they just can't seem to produce any decent software any more. Microsoft has been working on Longhorn, or Vista as it's now known, for years, and they're still a long way from delivering anything. Meanwhile, IBM products have become so complex and bloated, you need a super computer to run them on.

I recently wasted an afternoon (and about 3GB of disk space) attempting to install IBM's WebSphere Portal. The install consists of countless CDs, and installs about 11 other products while it's at it. Why does it need to be so complicated? JBoss Portal is a 9MB binary download that you install on top of JBoss Application Server (a mere 47 MB download) and can be installed and configured in under 15 minutes.

Why? IBM is a huge software company with years of experience in writing software. JBoss is an open source product developed by a handful of developers. Sure, JBoss products can be a bit rough around the edges and don't come with all the bells and whistles, but they work! They just work! JBoss is probably the most configurable and scalable Java EE application server in the market today. And they're the only vendor who releases products in a timely manner. It will be years before we see EJB 3 in WebSphere.

So why can't companies the size of IBM build better products? It's because they're so big. Size has a huge impact on productivity. With more people you have more meetings, and more disagreements, and more politics. If you can get a small team of highly skilled and motivated people together you can achieve amazing things.

A fine example of this is a company called 37 Signals. They produce a number of online services including the very successful BaseCamp and BackPack. At the time of writing this article, they employ a total of 7 people! But with those 7 people they build excellent products and often share press with the likes of Google for their innovative and amazingly simple applications. They're just a bunch of very intelligent and dedicated individuals who are passionate about building excellent products. And because they're small they can.

Physics says that a body in motion tends to stay in motion, but the same is true for software companies. Big vendors are so big and bulky that it takes them forever to react to the demands of the market. Meanwhile the little guy can decide to change today and have a beta release out by next week. Why? Because they can make quick decisions and implement them without having to run the idea past legal, marketing, the architecture group, etc...

Size matters. Stay lean and you can be quick on your feet and build software that works. You'll be able to make regular releases and fix bugs quickly. And most importantly, you can react quickly to the needs of your users and build a product that people actually want.

So don't be worried if the software company next door is bigger than yours... it's what you do with it that counts.

Don't be lazy

2005-10-10T19:31:00.000+01:00

If there's one thing that drives me mad, it's lazy developers. Unfortunately, most developers are lazy. I think one of the key attributes of an excellent developer is the fact they take the time to do things right instead of just hacking away at a problem until it seems to work.

Sometimes it seems that you just don't have time to do it right. When the deadline is fast approaching and your boss is breathing down your neck it's tempting to just get the damn thing working and out the door. "I'll clean it up later" you say. Yeah right, as if that's gonna happen. The problem with writing sloppy code is that it never gets cleaned up. People just keep adding to the pile making it progressively worse as time goes by. And by the time someone finally decides to make the effort to clean things up, they realise it's probably quicker and easier to just start over.

So what started off as a lazy bit of code has turned into a sloppy production application that is a nightmare to maintain and support. If only someone had taken the time to do it right the first time you wouldn't be in this mess. And here's the thing. Taking the time to do it right from the start is negligble. Taking the time to do it at the end is substantial.

But how do you avoid this situation that we all too often find ourselves in? Here is a list of things you can do to improve the way you write applications and stop yourself from getting into the mess in the first place.

Write a spec
Do you actually know what it is you're building? If you don't have a destination in mind, how do you know when you get there? Don't start coding without some kind of basic specification. It doesn't need to be long or fancy. It just needs to tell you what it is your building. Even if it's only a paragraph or two. If it clearly defines what you're setting out to do then that's fine.

Agree on the design
Didn't we just go though this? No, a design is different from a spec. A spec says what you're going to build. A design says how you're going to build it. Again, it doesn't need to be a fancy document with UML diagrams all over the place. It just needs to provide a high level overview of how you're going to write your code. It can be a single diagram, or a page of text or even a working framework. Whatever it is, just make sure that everone understands it and adheres to it.

Use Source control
Do you have source control? If the answer is no, then stop everything immediately. You cannot build applications without source control. Period.

Write unit tests
Write unit tests first. Why? Because it makes you think. And that's something that many developers neglect to do before they start writing. Not only will it force you to think, but you have the added benefit that once you've written your unit test, it's always there to test your code for you.

Use a build script
You should be able to build and deploy your application in one step. And one step doesn't mean following an 8 page document explaining the step by step process to follow. One step means clicking a button or executing a script. A good build process will check out the latest copy of your code from source control, compile everything from scratch, run all your unit tests, build a distributable file (eg: an .ear file) and deploy the application to the appropriate environment. Getting all this up and running can be tricky, but make the effort, it's worth it. Not only will it make your life easier but it will make you much more productive.

Don't be lazy
This is the most important of all, don't be a lazy programmer. Take the time to do things right...

Write comments. Code is only written once, but you come back to read it time and time again. And when you do, it's helpful if there's a comment or two to explain what's going on. You're not going to remember what a program does in 6 months time when a bug crops up, so save yourself the time and effort and write comments now.

Don't hard code things that belong in properties files or in a database. It might be quicker for now, but what happens when that same program has to run in a development, test and production environment with different settings for each environment.

Write code that people can read. Compilers will optimize your code for you. There's no need to try and and be clever, especially when it makes your code difficult to read. And take a bit of pride in what you write. Don't leave auto generated comments lying around all over the place that say things like "To change this generated comment edit the template variable...". And don't leave print statements all over the place saying "##### Got to here - 17".

Refactor when needed. If you find yourself calling a method over and over again, perhaps it belongs in a utility class or in a super class that you can extend. Take the time to fix it. Don't just keep on avoiding the problem, hoping it will go away. My rule of thumb is that if I find myself calling or writing the same section of code twice, I seriously consider refactoring it. 3 times, and I definitely refactor it.

I could go on and on, but I think you get the idea. The most important aspect of all this is that it's not hard and it doesn't take much extra time or effort. In fact, you'll soon realise that it saves you time in the long run. But the benefits you'll gain from making these changes are huge. You'll be more productive, you'll be happier, and most importantly - you'll bulid a better end product.

So next time you fire up the editor to start coding, take a few minutes to think about what you're doing and find the best way to go about it. Don't just start hacking away, do it right the first time.

Lorem ipsum dolor sit amet

2005-10-07T17:20:00.000+01:00

I realised today at work that very few people have seen Lorem Ipsum before so I figured I'd share it with you.

"Lorem Ipsum" is a grouping of nonsense words used a lot by publishing and graphic design folk when presenting mock-ups of their designs. For example, if you're designing a new web site (as I was doing today) but the content for a particular page is not quite ready yet, then you can fill the blanks with something like this...

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

The theory is that it resembles real text, but doesn't distract you with real words which you might be tempted to read when you're actually supposed to be looking at the design. In practise this often doesn't quite work. If someone hasn't seen Lorem Ipsum used before then chances are they'll start reading the text trying to decipher some hidden meaning, thus completely distracting them from the design.

Alas, it can still be useful. It's better than filling in blanks with some dribble like this...

Text goes here...blah, blah, blah. Blah, blah, blah.

There are some great web pages that will generate pages of Lorem Ipsum text for you next time you need some.

Random thoughts on random things...

2005-10-04T20:22:00.000+01:00

I have decided to start putting down my ideas on this blog for a number of reasons.

First, it's a good way to get me writing, something I want to improve and do more regularly. Also, it gives me a way to keep track of the random thoughts that float around my head from day to day. I read all kinds of weird and wonderful articles and books, so I figure if I write down my thoughts then I will digest them a little better.

Ultimately, I want to start writing articles for industry publications and websites and hopefully one day write a book or two. But baby steps first.

So what can you expect to read about here. Well, I'm a Java developer with ambitions to start my own business. So I'll be writing on anything that's even remotely related to that.

Stay tuned.