analysis 102

Guava's Collections...

2011-08-26T01:31:00.000-07:00

Oh the names developers come up with...

Guava is the new name for the amalgamated set of lightweight java libraries google has produced. It includes what used be google collections.

In a nutshell, guava's collections are commons collections built with 1.5 language features. Generics and other syntactic sugar.

If you're a java developer and haven't seen them or are not using them, then you're wasting a lot of time.

Especially in testing.

You need to create a small list, of say, 3 elements to pass into a SIT.

Typical solution:

List list = Arrays.asList(new Object[]{"1", "2", "3"});

Solution when using guava:

Lists.newArrayList("1", "2", "3");

Eminently more readable, succinct and to the point.

The other useful commons collections features are also supported... e.g. filtering.

One example I'll supply is a filter which submits to the generic type:

example...

public Iterable getSquares() {
return Iterables.filter(shapes, Square.class);
}

With a more ordinary filter, the return type of the filter would have to be the same as the type that is passed in (in this case the shapes collection). Not with this funky mechanism. Unfortunately, guava does not have the same feature when working with sets and lists. I guess you could just wrap this Iterable in a set, but that would mean having to iterate over the collection up front.

Maven... for uninitiated

2011-06-07T12:43:00.000-07:00

Having been around the java landscape for a while, I couldn't help but run into the tool known as maven. It is fairly accurate to say that maven is ubuiquitous. Having tried maven briefly in the past and given up I decided to bite the bullet and get down and learn maven.

I had help in the form of the book, Maven, a Definitive guide which eased my passage into maven.

A few weeks ago I thought I'd give maven a try. I tried it out, hit a few problems and then gave up. That I refer to as my firstcoming to maven. Then after another few weeks I thought I'd give maven a second chance, this time I was a lot more successful. So having been using maven for more than a few weeks now, and especially having had two bites of the cherry, it is safe to say that although I am not a fan boy and a maven evangelist, I am a convert in the sense that I would want to use it on the applications I build. Let me say that this opinion can change as I mature in my thinking on maven as I extend into more areas of maven's capability.

Firstly, Why use Maven?

1. Dependency management - what a pleasure it has been to simply right click (since I'm using m2eclipse) on my project, select add dependency, type in a few letters of the dependency, and select the dependency and it is automatically downloaded and available. No more trawling the internet for that lost dependency... it's right there when you need it.

2. It provides a platform for adding value. This sounds a little nebulous, I understand, but once you've created all the maven infrastructure you can easily build on top of that through plugins. My test case was a back end app offering a bunch of services exposed through REST. I discovered the jetty plugin for maven - with this plugin, I simply checkout the code, run the maven build and then execute the plugin. Maven starts jetty and deploys my application to it. A very simple way for other developers who need to call into my web app to get access to it. A few command line intructions and my app is running

Some important considerations when starting the journey:

1. Take it slow. Maven, is complicated. It's not good rushing into it, trying a few things, getting frustrated and then backing out. That was the mistake I made initially dived head long into maven, and hit my head more than a few times. There are a number of irritations which should not actually be there, which put me off. These irritations had work arounds which I have since found, but at the same I found them very irritating.

2. Use a local repository - a lot of the irritations of using maven can be resolved if you run a local repository. One of the major changes in thinking when coming the ant or the IDE build world is that with maven _all_ dependencies are imported, no dependencies are placed with the source code _at all_. So if you need to just quickly add this dependency to your build... don't go there. Maven coerces you to put that dependency into a repository and then reference it from elsewhere. Yes, you can install it to your local repo but the command to do this is clunky. Rather just install it on your local repository.

3. Don't try and do it the non maven way - maven is _very_ opinionated. It expects your code to be arranged in a very particular way. Do not try and fight with this. Resistance is futile. Standards are good and work well because they are used by all, not necessarily because they are the best way of doing things. You might think you know better than maven, that's fine - try and be different and you'll soon hit a wall.

A few of the problems I had, and will still need to deal with:

1. I think one of the problems with maven is that not all the code libraries int he world are available via maven repositories. If this were the case, chances are there would be a lot less pain. In my first coming to maven I quickly hit a problem when I added log4j as a dependency. Log4j supports jms based connectors etc and since these libraries have a more restrictive license they are not available from the primary maven repository. So when you add log4j as a dependency, the build simply fails. One work around is to download these artifacts manually and install them - something I wasn't willing to do as what's the point of using maven if I have to download dependencies manually right? At my second coming to maven I discovered that you can configure your dependencies to not include certain transitive dependencies. I excluded these unavailable via maven repository dependencies and my frustration was removed.

2. Handling third party dependencies - I had to make a connection to a mysql database. The mysql jdbc jar is obviously not available in a maven repository. This is where the local repository, artifactory or nexus come in. I figured out how to deploy this jar to this repository and no more problems. I was now doing things the maven way.

In summary, for now I am using maven. It has filled a big gap in my arsenal. A replacement for maven would have very big shoes to fill that I'm not sure I will go back.

But we will see...

New Things Ahead

2011-02-24T01:35:00.000-08:00

Hi Everyone...

As you know I have not posted in a very long time. The primary reason for this is that I have not really been doing anything particularly interesting over the last year. This is about to change, as of next week, I will be joining a new startup development company that specialises in mobile and internet applications... This promises to be fertile ground for more posts.

I will also be looking at redesigning this blog - giving blogger.com's templates a run around.

Headless Build, who needs it?

2010-03-08T00:48:00.000-08:00

Yes, who would need a build that does not have a Head? That sounds like it's out of a horror story.

What I mean however is a build which does not require an IDE and is not invoked by the IDE, so is thus probably ant though it could potentially be maven, or a shell script or an msbuild invocation - you can do headless builds with something other than ant.

To my mind having a headless build is a no brainer, but you'd be surprised how many development contexts do not have this. So why is a headless build so important and why do some context not have one?

1. Headless builds do not require the IDE

Why is this important? It's probably more an architectural/soft advantage. I mean why would you spend time replicating offline what you can do in an IDE. The primary advantage here is that it means that it allows a whole slew of other tweaks, so this is not valuable in and of itself but it is what allows other advantages.

2. Headless builds are repeatable - this is the no brainer reason why you want headless build - so that you can have repeatable builds. The problem with building from the IDE is that you never actually know what code the developer had in his workspace when he made the build. If you don't know what code is in a build you don't know where to go to fix the problems. Maybe the problem stems from that random code the developer was working on when he made the build. I would go so far as to say that a build made from a developers workstation is about as much use as old chewing gum.
3. Headless builds do not require a developer - the last thing I want as a developer is to be keep getting queries saying, please come and do a build for us. I don't think the downstream entities (testers, deployment people) want to do this, but in a context with no headless build they are forced into doing this. What is more is these people cannot do more than click a "build" link to make a build. They certainly cannot start the IDE, check the code out, select the project, select build all, then do an export etc. They certainly, since they are not developers, cannot use an IDE to make their own build.
4. Headless builds are automated - once you have headless build infrastructure in place, be it ant, msbuild or shell scripting, you can build on that basis by adding things like tagging of the code, tagging of the generated artifact. Maybe even include in the built artifact some mechanism to show the tester the version tag. No uncertainty as far as which version of the code you're running.

You might be saying, surely in some cases, in some small cases that it is not necessary to do the work of creating a headless build mechanism. I'm not so sure. Yes, developers could be disciplined and make sure whenever they build that the code has no changes, but even with that, it is still not clear what version of the code is deployed. On a recent project we did not have a headless build and there was always a degree of uncertainty as to what version of the code was deployed, what version of the code is running. I regret not being allocated enough time to implement a headless build for that context. It caused us pain, even if the project was really small. If it is automated by a script it will happen _every_ time and it can be trusted. I cannot trust a developer to always follow the steps they're supposed to - not because they're not trustworthy, but because the developer cannot prove to me after the fact that they did all the steps they were supposed to.

Annotations or XML

2009-09-29T01:13:00.000-07:00

I just commented on a post at stackoverflow asking for suggestions of criteria which should be used to compare the annotation or xml approach when configuring classes for hibernate or spring. Saying then that a decision will be reached on which one is "better".

I responded to the post and you can see it here.

While an interesting academic exercise, I don't foresee it having any real value. The decision on whether to go annotations or xml is made solely on a case by case basis.

But then I asked myself, what are the conditions under which xml/annotations are used with reference to configuring spring beans.

I was on a project where we had hundreds of beans - we were working under Java 1.4 so could not use annotations. We went so far as to use xdoclet where you add the annotation information as javadoc tags in an attempt to account for this constraint. It wasn't ideal as you have to generate the xml from the source code and thus the xml can easily be out of sync - don't have to do that when using annotations.

So in that context, annotations won, and to my mind, for many "workhorse" beans it's a no brainer. Maintaining the xml for hundreds of beans where no custom configuration is required, annotations is definitely better. Annotations handle refactoring, method name changes, classname changes, even certain structural changes require no adjustment to the annotations.

So is xml now defunct, have annotations killed the xml star?

No - there are two contexts where I am essentially forced to use xml.

1. Where I want to customise configuration.

So I want to be able to specify different values for beans, or if I want to change the bean I'm injecting into another bean. I want to be able change property values. Doing this with annotations though possible would be too unwieldy. While it's possible to run Windows Vista, that doesn't make it a good idea.

2. Where I don't have access to the source code of the classes I want to create as beans i.e. where I want to re-use classes from other libraries.

Because I don't have access to the source code and/or I want to potentially create more than one bean from the same class, xml is the preferred approach here. The key difference between xml and annotations it that when using annotations I do not have to specify the details of the class, i.e. I do not have to contextualise the information I'm adding, it is already contextualised because it is connected with a class, field or method. With xml I always have to add this contextualising information.

In my current project I have a small xml file which has all the beans created from re-usable components in it, and that's all. Everything else is done via annotations.

That's how it should be?

2009-09-21T10:58:00.001-07:00

If I had R10 or a dollar, for the amount of times developers assume something because they say it "should" be like that, I would be rich.

I must admit, I find it a bit weird that they assume things because it is how it "should" be as if the computer is morally obliged to be like that. We say things like "It should rain tomorrow" or "You should not steal"... implying either that there is some uncertainty to the statement or that it is a recommended thing to do.

Notice that with the use of "should" there is NO certainty - why I find it strange that developers even use the word "should" with reference to code. Developers should only be talking in absolutes when talking about code behaviour, and until they can talk in absolutes they should keep their mouth shut.

After all, they have the code in front of them; they can look at it - if it's a spec they're looking at, yes, the behaviour specified in the spec "should" (correct use) be what the code does. That is how things are setup, but if you have the code in front of you, I don't want to hear "should". Why take the risk of the "should".

Just today this is what happened. A method was taking a string and the string was called "status". Now there is also an Enum called "status", and the developer figured well, that "status" and the enum status should both have the same "toString". iow, the toString of the enum should map to the valid strings that the method understands... a big should. If that is the case then why does the method not take an enum.

Now, yes, it should be like that, but is it? In this context I'm not interested in should. This shouldn't cause a bug is just not good enough.

A cursory glance at the code should, oh sorry, can, often lead to the resolution of the doubt, and in this case, the assumption was proved wrong, causing a time wasting bug.

So in a development environment when one is asking how is the code behaving, one should never hear "should".

Urgent or Important?

2009-09-08T15:03:00.000-07:00

Recently I had spent some time working at a new client (old client for my company, new client for me). I spent 3 weeks there getting familiar with the environment and am now working off site.

I was struck by how "busy" the place was. There were people on the phone constantly, thousands of mails flying around, the project is way behind schedule, the environment is a little mad, maybe chaotic would be a bit strong to say, but it is on its way there.

It just does not seem as if a lot of though and critical, deep and creative thinking has been brought to bear on the project. People are just going from one crisis to the next, doing what is urgent all the time and failing to address what is important. Either they don't have time, or they deem what is urgent to be important and can't really tell the difference!

What is interesting however, is that from the client's perspective, lots of things are happening. People are doing things, working hard, appearing very busy - but not necessarily getting things done.

Contrast that with an environment that is calm, smooth and running as planned. How would that look? A little boring in comparison. People would not appear busy at all. They'll be sitting at their desks working, not talking to much on the phone, not be stressed, and have everything under control. The client may interpret this as being lazy and not working, because we certainly don't appear so busy.

Netbeans - a first really serious look

2009-08-20T10:15:00.000-07:00

I have just started seriously using Netbeans for the first time - I've been forced to because it's what the client uses.

And I have to admit, that having used Eclipse up till now, I am definitely not enamoured with netbeans at all. In fact it has done nothing to recommend it. I constantly find myself going... oh, I wish I was using Eclipse.

Netbeans fans might be crying foul right now... and they have a right to, let me record some of my initial frustrations...

1. No inline variable
2. No inline method (though there is an extract method, called introduce method).
3. When you use the template short cuts (for, create field etc) the tab does not leave you where you want it to
4. It hides a lot - we're doing web service development - all the ant xml files which are used to compile and build, you don't see.
5. No call hierarchy
6. Search facility is nowhere near Eclipse
7. No Quick diff comparing repo version with local version (via the ruler)

A good way to explain netbeans is to say it is opinionated software (I remember someone describing ruby on rails like that) - iow, it's great, if you obey the rules and if you want to stay within the confines of what it wants. I don't like the ant scripts it generates and uses to build - I want to roll my own, as eclipse will let me and thus customise them the way I want to.

So what do I like about Netbeans?

It has very strong integration with glassfish - tells you a lot about the running glassfish server you're using to deploy to. I also wish I could use the collaboration stuff, because I've seen that it is very good.

I'm going to have to continue using netbeans so I'll see if my opinion changes... I'll wait and see.

Why don't people understand the computer?

2009-08-19T11:02:00.000-07:00

I am always fascinated when I observe people using a computer's user interface, even when using the user interface of the popular video game, guitar hero.

I have played guitar hero with a lot of "normal" (non computer) people and have found it interesting to observe their interactions with it. This process has enlightened something else I have been spending a lot of time thinking about, and that is why people cannot understand/use a computer.

And Guitar Hero is a good example. Even something as (I think) simple as the user interface of guitar hero causes people to go... I don't know what's going on, I can't use this. From my point of view, it could not be simpler, everything is self explanatory and right before you. It gives you all the feed back and guidance you need to quickly navigate around - and I therefore cannot at all, understand why they find it so difficult - I just can't get into their head and understand.

Until now when I finally understand why they find it so difficult.

For these people, the user interface of guitar hero might as well be Chinese - that would be just as comprehensible to them! I understand the language of the computer - they don't, and it is a question of language. They don't speak "computer", or should I say "read computer" since the "computer" language is only a read language. You can definitely get different abilities in this "computer" language - the people I'm referring to here though have no clue. And so it makes sense that people can be "computer literate", able to read computer - it's a very appropriate label for someone who knows their way around the computer.

The conclusion to all this is that whereas before I could not understand why people cannot understand the simplest of interfaces, and these people are not uneducated, now I fully understand why they cannot operate the interface. They need to understand the language it's communicating in.

Development On a VM - who needs a desktop?

2009-08-17T04:32:00.000-07:00

Recently, in our dev shop, we have taken delivery of a rather high end server class machine. We installed linux on it and VMWare. It is, needless to say, way faster than any of our desktops.

We created a VM, installed ubuntu on it and then added that as a hudson slave. With that VM, the time for the simple compile job is down to 13 seconds from 45 seconds (gives you an idea of how fast it is).

We created another VM with ubuntu and I started tinkering around on that VM. I installed eclipse on there and started using it for my development by exporting the desktop to my workstation. The remote desktop equivalent in VMWare is very good - more than adequate responsiveness etc. My personal laptop/desktop is now just being used as a dumb terminal...

The advantages of developing this way:

Hardware upgrade costs are significantly reduced - don't upgrade your developers hardware when next upgrade cycle starts - let them keep their current hardware (and use it as a terminal) and give them a VM to develop on.
Maximum value is extracted from available hardware - I reckon we could put about 4/5 developers on our new server, depending on size of applications being worked on. This will mean that the server hardware will be very well exercised, a lot less wasted CPU cycles
Configuration and down time are almost non existent - new developer arrives, just provision a new VM from the image and he's up and running. Developer's image gets corrupted, same solution.
Significant cost reduction - because economies of scale can be leveraged, and hardware is better utilised, hardware costs are significantly reduced.

The only disadvantage of this solution is the lack of mobility - you need to be within a fairly fast network of your beefy server for this to work, let's hope that line speeds can be made fast enough to handle this.

For dev shops which issue laptops is less of a solution, but if you have a location full of desktops, don't upgrade them, just use them as dumb terminals and virtualise their requirements.

Evolving an Architecture

2009-07-27T08:52:00.000-07:00

So, when last did someone ask you about apiece of architecture, they asked, how are we doing to do this? And at stage you, the architect, or involved in the architecture, weren't quite sure. Not because you're a bad architect, but because you don't have enough of an idea of what is required at that stage, and because right now, that issue is not front and centre. In other words, it hasn't had the full treatment. You're currently sorting another issue and will get to that. Right now, the solution employed in the area asked about is "good enough". Probably not going to go into production like that, i.e. it needs work, but for the rest of the project to continue, it's adequate.

I don't know how many times I've found myself defending an architectural construct in this manner. Yes, I'm aware of the issue and will address it. Furthermore I am forever finding myself changing the way things are.

An architecture of a system must be a fluid thing. It is something which evolves. As the designer you should always be willing to modify something because it has not met it's requirements and/or you, or somebody else has come up with something better. One of the characteristics of a good architect is that they are willing to take risks, change something for the better even though it might negatively affect the application in the short term. Developers for example, might not like what you've done, but if you've done it for the right reason's they will see those reasonsand buy into the change.

You will not get everything right at the start, accept that, choose what is important to get right now, defer the rest, but make sure you get to the rest. When developers ask you about the "rest", let them know why it is that way, and that you're going to get to that issue. Often I've felt indignant at these kind of question, that ask about the "holes"... but I shouldn't be, it gives me an opportunity to give them a greater understanding of the system, and an opportunity to gain an ally. I suppose however, the ultimate is for developers to see where those defferred issues are and to know intuitively that they will be addressed.

A good design is mandatory if you want good performance.

2009-06-22T08:23:00.000-07:00

Now, I know that there has already been much ink spilt over premature optimisation and I thought I'd add my thoughts, mainly because it is still so relevant. I still see people not listening to Michael. A. Jackson's classic law:

“The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.”

Michael A. Jackson

I think the problem stems from a question of value. Developers still see code that runs fast as somehow better than code that runs slow - so they will prefer a solution for example, that creates less objects because they see that solution as slow.

The "fast" version could be 10 times slower than the slow version, and 10 times sounds like a lot. Wow, you achieved a 10 times speed increase, that's got to be good right?

Not if the fast version takes 1 milli-second right? The slow version will take 10 ms. I challenge anyone to notice a 9 ms difference.

I've never heard anyone complain about some process taking 9 ms longer to complete. 9 ms!

To give you an example...

Consider the code:

long p = System.currentTimeMillis();
Agent[] objects = new Agent[1];
for (int i = 0; i <>
objects[i] = new za.co.sepia.ucc.core.model.Agent();
objects[i].setAgentId("hello");
}
System.out.println(System.currentTimeMillis()-p);

This code takes less then 1 ms to execute (printed difference is ZERO)... on my fairly powerful laptop with Java 6.

If I up the array size to 1000, it takes 31 ms...

I had to up the array size to 1000 to up the time taken to 31 ms. An array size of 1 is faster than an array size of 1000, it is in fact 30 times faster! Wow, I got a 30x speed improvement by reducing the array size. However, even with such an enormous factorial diference, the slow version still only takes 31 ms... That is 31 thousandths of a second.

Alright, granted, if you're doing hundreds, maybe thousands of these kind of operations then speed would start to be a factor. How often do you, in your daily software programming do you encounter situations where you're doing the same operation 10000 times...?

What I would like to see is developers change their priorities, and change their priorities in accordance with the third rule of optimisation, which I would like to add, and that is...

A well designed system is better than a badly designed system which runs 1% faster.

Why is it so important to had a well designed system with respect to performance?

Picture the following... at the end of your project you now want to increase performance. You have not optimised prematurely, but you do, unfortunately find that you now have a performance problem.

You run a profiler on your application and pin point the problem to be a particular component. Because your system is loosely coupled with good encapsulation you're able to rewrite that component quickly and easily, test it on its own to validate that the performance problem is no longer there, plug it back in and run the tests to validate your change.

But imagine if your system was badly designed...

While you would be able to pin point the source of the problem, chances are there's loads of dependencies on that component such that a simple rewrite will prove difficult. Furthermore, you would not be able to unplug it easily and rewrite it because there is tight coupling and little encapsulation. The bits of slow code are scattered all over the show. Maybe when you were designing you prioritised "performance"... funnily enough though, where you expected performance problems, none materialised.

I will always prefer a well designed system over one which is "fast".

In my experience, if you prioritise good design over performance, you will get a performing system in any case.

Is Java Dead?

2009-06-10T01:29:00.000-07:00

Recently, on a local Java User Group the question was asked, should Java be my platform of choice. I was fairly surprised by the discussion that ensued. It was largely negative.

And why shouldn't it be, a language that is more than 10 years old, still hampered by its legacy, competing with cutting edge dynamic/scripting languages which seemed to have stolen a great deal of java's positivity. Java was debunked for being inelegant, hard to understand, unpredictable and old fashioned. While languages like Python were praised for their elegance, obviously better than java, far easier to learn and use.

So the question is, is Java that bad?

One or two examples were presented singling out auto boxing as a disaster, concurrency unpredictability and that perennial source of mirth, the try/catch/finally what exception is thrown? Personally, those "what happens in the above piece of code that you'll never write yourself?" are a waste of time. People single out the handful of confusing scenarios that you'll just not get in every day coding (unless you go looking).

The question is, what made java so attractive in the first place? and can those properties carry it forward? It had built in OO (yes, not _everything_ is an object I know, but close enough), it was simple, had none of the superfluous syntactic sugar of C++ and hit the ground running with a useful API, both for gui and other development and it was cross platform (ran on a VM).

The factor that is very often underestimated in proclaiming java's looming demise in face of more modern, dynamic and scripting languages is that only a small minority of developers actually keep up to date. Some have said, it's in the region of 20%, in my experience, it's probably about 15%. Those are the ones that don't teach themselves new technologies unless forced to. Also, I doubt those individuals see the pitfalls of java - the so called inelegance, is to my mind, significantly overblown. Yes, autoboxing has problems, but I've already seen the benefits of it, which outweigh the problems.

It would be remiss of me not to indicate that without the java platform, java would not be as viable as it is. In fact, some would say that without that java would be on the wain, and possibly "dead". One thing is for sure, that this is what makes java so viable and the only choice for any project of significant size and scale.

Personally, I cannot see java fading away or even losing it's dominant position in the market in the next 10 years. In ten years time, things will largely be the same as they are now. The new kids on the block however, will grow and will start to cut into java's domination, especially on the web and on the desktop, though I do think that google is going to keep java strong on the web (gwt and google app engine). Java will lose in these areas, but in it's mainstay, on the enterprise, it's not going anywhere.

Depency Injection/Inversion of Control - are they the same?

2009-06-01T06:31:00.000-07:00

On the weekend I spoke to a friend and we were talking about the SOLID principles. We talked at lengh about Inversion of Control/Dependency Injection and how they are not the same thing. Trumpi was saying that you use dependency injection to achieve inversion of control, and that made sense to me. Then I consulted with another colleague about it and this colleague pointed that in order to achieve inversion of control then you will necessarily be doing some form of dependency injection. You will need to "inject" the dependency because the component requiring the dependency will only depend on an abstraction.

So in effect, they are the same thing. The different phrases describe the mechanism from different point of views, the one describes the behaviour (dependency injection), the other the structure (Inversion of Control).

What I also discovered as I opened the book, Agile Software Development, which I think, first explained the SOLID principles, presents the 'I' of SOLID as "Dependency Inversion", i.e. a combination of inversion of control and dependency injection. Which to my mind, is a better moniker as it describes the mechanism more accurately.

Mockito is first mock framework you should consider

2009-05-28T01:33:00.000-07:00

Having been stuck on jdk 1.4 for the last 3 years it came as something akin to a coming of age to step into modern java; and a most satisfying revelation has been mockito.

If you have used easy mock in the past you will be very pleased and probably quite excited when you encounter and start using mockito. It is totally awesome.

It is simple, intuitive, terse and has some very powerful features. It will gracefully handle almost all of your mocking needs. For example, it is possible to stub out selected methods on a live object.

To give you an example of mockito in action, to whet your appetite, here is a code snippet.

ConfigParams params = Mockito.mock(ConfigParams.class);
when(params.getInt(ConfigParamKey.AGENT_MATCH_TIMEOUT)).thenReturn(99);

So, it's fairly self explanatory, when the method getInt is called with the parameter ConfigParamKey.AGENT_MATCH_TIMEOUT then the mock should return 99.

In case you were wondering how this all happens, generics are playing an important role - thus the reason why it is only available on jdk5+

As in EasyMock and JMock you can verify that the method was called.

It is probably worth pointing out that Mockito tries to be less strict with its mocking than other mock frameworks. For example, the default mock you get will accept any call - and unless you specifically verify (which you can do), not calling the method will not cause a test failure.call

See the web site for more information, downloads and demos.

Best Practices are for people who don't know what they're doing

2009-05-12T08:00:00.000-07:00

On my last project, I can remember occasionally reading through "best practices" of the various technologies we were using. Spring and hibernate spring to mind.

I can remember noting that we were not following a large number of the best practices. In fact, what is more interesting is that we had made those decisions without considering the so called "best practices".

However we did not make those decisions without considering all the variables. In each instance where we diverted from the best practice we did so for good reason and with our eyes open. In other words, we did not deviate from best practices because we were rebellious but because we knew what we were doing. In all cases we had a ready defense for not using the best practice.

I realised in doing this that the point of best practices is to protect the person who does not quite understand what they're doing, to make sure they don't really shoot themselves in the foot. For those people who understand the situation, best practices are useful because they provide a base to work from. If you deviate from best practices make sure you can defend your deviance.

Furthermore, I'd also like to add, that very often a so called best practice is someone's opinion. A few months ago I wrote on what I thought were hibernate "best practices". These are based on my experience and my opinion, they are my best practices not necessarily industry tried and tested best practices. So the label "best practice" is often a fairly loose term.

Best practices are for people who don't know what they're doing, but for people that do, the tried and tested ones are a good and worthy starting point that should only be deviated from for good reason.

Spring with annotations - in 2 minutes

2009-05-08T09:47:00.000-07:00

I have just recently, today, had my first look at spring with annotations. Up until now I have always had to use spring on VM 1.4 so was unable to take advantage of annotations.

Suffice to say, it is awesome!

Now I know for a lot of you, this might be old news, but it wasn't for me.

So you remember the old xml based spring configuration...

<bean id="serviceLayer" class="za.co.bbd.ct.ServiceLayer">
<property name="businessObject" ref="businessObject">
<property name="xmlConfigured" ref="xmlConfiguredX">
</property>

When using annotations, no nasty xml is required.

@Component
public class ServiceLayer {

private IBusinessObject businessObject;
private IXmlConfigured xmlConfigured;

@Resource(name = "businessObject")
public void setBusinessObject(IBusinessObject businessObject) {
this.businessObject = businessObject;
}

@Resource(name = "xmlConfiguredX")
public void setXmlConfigured(IXmlConfigured xmlConfigured) {
this.xmlConfigured = xmlConfigured;
}
}

Then in your spring xml file the following is required. The good thing is that you can mix annotation and xml based configurations seamlessly.

<context:annotation-config />


<context:component-scan base-package="za.co.bbd.ct" />

The default name for the bean is the class name without the package name in camel case, iow that "businessObject" class has this as its annotation:

@Component
public class BusinessObject implements IBusinessObject {

}

And if you'd rather not specify the name of the reference and just match by type:

@Autowired

public void setBusinessObject(IBusinessObject businessObject) {

this.businessObject = businessObject;

}

You can mix xml and annotation based configurations. The definition for xmlConfiguredX is also in the xml...

On a project I was on we used xdoclet to circumvent the lack of annotations (project was on 1.4). We had 100K's worth of generated xml spring configuration files. Annotations would have been so much better!

You don't know what you don't know...

2009-05-05T05:33:00.000-07:00

When I started on my last project, a very large enterprise application I did not know too much. I had not done enterprise programming before, I had not used web services nor had I used hibernate, all of which were used to the fullest on the project.

When I arrived, we spent six weeks finding out what challenges lay ahead, where we would have problems and on their solutions...

Turned out that zero of what we did during that time was useful.

Problem was, we did not know what we did not know. Sounds like a redundant statement but it's not. IOW we did not know where the holes in our knowledge was. We did not know web services enough to realise that we were going to have problems interfacing via web services between dotnet and Websphere. We did not know hibernate enough to know that using inheritance and putting sub types into collection was going to be problematic. We did not know that we would have to work very hard figuring out the issues with JNDI and session beans.

We wasted a lot of time because of this. We should have got someone in, not to help us with the problems, but simply to tell us where the problems were going to be. We had the ability to solve the problems, we proved that as we solved them, what we didn't have was the knowledge to know where the problems were going to be.

twitter is cool...

2009-04-28T05:56:00.001-07:00

So if you haven't figured out twitter I'll try and help...

Twitter is technically a "micro blogging service"... but that does not really do it justice.

To describe twitter simply, it would go something like this. Twitter is a mechanism for people to distribute short pieces of text (140 chars) to people who have elected to be on their list.

Text communiques are known as "tweets" and people who receive them are "followers".

So then, what is the big deal?

The key difference is that for me to follow someone I do not require their permission. Unlike facebook where in order to receive status updates from people both sides need to agree.

So I could therefore follow Oprah Winfrey or Ashton Kutcher, or even Hugh Jackman.

So if you want to know what your hero is doing/thinking/wanting to tell the world... then why don't you look them up on twitter and follow them. You'll not only know what they're thinking about what you're interested in, you'll also probably know when they come back from a cycle.

Oh and btw, you can find me on twitter.

Unit Testing, what do I need to get it right?

2009-04-16T10:14:00.000-07:00

So you want to do Unit Testing... it's a noble goal and good goal that every development shop or environment should have.

And it is a goal that we had at the beginning of our project.

It didn't happen, or certainly not as I would have liked.

So then, what did I learn from our so called failure, what are the mandatory requirements for making unit testing a sucess...

Infrastructure to automatically run unit tests. In order to make unit testing work, you must have some facility to run the unit tests regularly. Preferably these should run fast and should be run on every checkin. It is not enough to rely on the developer to run the unit tests before they checkin their changes.
A univeral commitment to quality. Your whole development team needs to be fully and categorically commited to quality, and a working unit testing system is a necessary requirement to get there. For a unit testing system to work it means that if tests fail, developers need to care - as soon as one unit test fails, your system is immediately less effective. The unit test frameworks do not work when even one test is failing. You can't have just one developer, say the lead developer, telling developers to fix their unit tests.
Mangement buy in. The problem we had with unit tests and getting unit tests fixed is that developers always made some excuse about how they could fix it now, they just had this bug to fix or this use case to finish, so management need to realise that a reason for the use case being delayed is because I had unit tests to fix is as good a reason as, there was a power failure and I couldn't use my PC.

The benefits of unit tests are proven, but I can't prove those benefits to you, here. You have to do it, 100%, pay the cost - and it's true, there is a cost, but the pay off from paying that price worth it, you'll probably gain 3 times as much you put in. But don't bother, unless you've ticked the 3 boxes outlined above.

Commit comments... more is more

2009-04-14T09:23:00.000-07:00

First off I must say that it has been a long time since I last posted - I have just been swamped with work on www.sanlamconnect.co.za.

The other day the issue of what is a good commit comment came up... and there are a number of approaches to this issue.

The big question is, Should it stand alone? IOW should it make sense by itself, or should it be taken in conjunction with diff. If you apply the former then the comment will repeat what the developer can ascertain from the diff and typically add more information. If you apply the latter then the developer is required to look at the diff to make sense of what is going on.

So the other day a fellow developer accused me of being too terse in my commit comment, and I was a little indignant at his criticism because I regarded my commit comments as being adequate. I felt why must I rehash what the user can see from the diff. The comment as far as I remember was "fixing bug"...

I reasoned, if the user has any sense they can look at the diff and they can figure out what the bug was and what I did to fix it.

But would it have killed me to just put down maybe another 10 words to indicate more details, like "fixed bug in execute target, the file extension was placed incorrectly". Is that too much to ask? Another 10 words that would have taken me another second to write that is going to save the next person at least the time it takes to open the diff, notwithstanding the time it's going to take them to make sense of it.

So, the conclusion is, write detailed commit comments. Definitely a paragraph is not necessary, but at least 10 words is a good start.

What about those developers that would have taken another minute to write those 10 words because they can't touch type... to them I say, tough, it's time you learnt.

The Double Importance of Unit Testing when more than one developer is involved

2009-04-08T03:08:00.000-07:00

So now, you have a team of 10 developers working on a project, I know it's a lot, but some projects have that number...

And so a solution is required to a problem and both developers require a solution to the problem. For any number of reasons, both developers end up solving the problem, not in exactly the same way mind you.

The result is that you have two solutions to the same problem.

Now what? You have 2 options...

1. You could leave the code as it is. This is surprisingly enough, a viable option, since it's done often enough! But it's clearly not ideal as it leaves you with duplicate code and duplicate functionality. And if you consistently apply this approach then before long you'll have many many instances where this occurs. Maybe inside that duplicate code there is another facility that is required and thus duplicated. And if you consider that with 10 developers involved, you can have many many instances where developers are unfamiliar with what other developers have done, so you have exponentially more instances where functionality is duplicated. The more developers you have, the more duplication. Each time a developer is added, the potential for duplication is exponentially higher based on the number of connections. With 2 developers, only 1 piece of communication is requried per piece of work, with 3, 2 pieces etc... each time you add another developer, the probability of duplication is significantly increased. So you inevitable end up with multiple ways of solving the same problem with code that differs in its quality (different developers wrote each one)

2. You could however, refactor, such that both parties use the same functionality. A more appropriate solution; but easier said than done right? It sounds good in theory but it is not practiced. Why not? What if it doesn't work? What if there was one little consideration the one version used and depended on that the other version didn't have or do? Then the implementations are not exactly the same and thus cannot simply be amalgamated. How do I know the implementation that now depends on new code is going to work. Unless you have some facility to validate the changed process you don't really know. You could of course start up the application and exercise the functionality from both points of view to validate they both work. A clunky and time consuming process that will hold you back from making the change in the first place. That's where unit tests come in.

Unit tests let you remove duplication and refactor with confidence allowing you to improve quality, conciseness, readability and delivery times.

Open source software is self service software...

2009-01-24T13:04:00.000-08:00

Jeff Attwood at Coding Horror makes an interesting point about open source software being "self service" software. That immediately struck a chord with me as a I saw his point straight away.

But he didn't quite mean what I expected him to say. What he meant was that participating on software projects is a self service enterprise and thus leaders of open source projects need to make their projects as easy as possible to serve yourself on. There are particular issues that go with any kind of self service.

But the same rings true for _users_ of open source software, and those users are exactly that, self service users. With open source software the users help themselves, they fix their own bugs, get their own help and basically make their own way. They do not rely on a commercially driven entity in order gain value from the software they are using.

And I think companies thus need to take this into account when they're considering whether so use open source software. At cinema's in South Africa they have self service kiosks for buying movie tickets (I don't know if they have them elsewhere in the world) - and I really appreciate these. I do not have to wait in the queue, I also get to have my pick of where I want to sit.

However, it is only particular people that are able to use these kiosks. They are not everyone's cup of tea. You need to be technologically savy, and need to be willing and able to back yourself. iow, to try new things and have the confidence and where withall to see it through.

But let me say that not all open source is as self service as "self service". Some open source initiatives are supported by commercial entities, and some open source applications look and behave like the closed source equivalents - OpenOffice and Apache Web server being two simple examples.

In general though, using open source is analogous to using the self service option, when presented, and seeing things in that light help to shed light on some the challenges and value adds of open source software.

Hibernate: What does update actually mean?

2009-01-09T10:16:00.000-08:00

I work on a large enterprise application that uses hibernate for it's persistence.

I regularly in the code base find the equivalent of...

Person person = personDao.loadById(id);
person.setLastname("newlastname");
person.setFirstname("newFirstname");
personDao.update(person);

The update call in the above code snippet is unncessary and useless.

Even after being on the project for more than 2 years I still find developers not understanding the purpose of update and I think I understand why. The obvious thought process is, I've changed a stored object, I now need to call update to save the change; sounds reasonable enough? That however, is not the purpose of update.
This particular use of update belies a misunderstanding of the nature of hibernate, and that is that it is a "transparent" persistence framework. What that means is that persistence is made to be transparent to the developer. You should not have to worry about the persistence issues. You load objects from data store, you change the objects, and the changes are saved, without any explicit save instructions. Imagine for a minute, if you had to call update whenever you made a change the complexity upgrade would be significant as it would mean having to track all the objects you do in fact change.

So then, if update is not for that, then what is it for?

The update method could have been named "attachAndPersistChanges" - that is a more accurate name, but probably a little unwieldy. It could also be described by the sentence "update this object in the data store". In other words, update is designed for objects that are not currently persistent.

The update method makes objects that are not persistent, persistent and updates the persistent object with any changes present in the not persistent (detached) object. The object must not already be available in the level one (session bound) cache otherwise an exception will be thrown (for this situation, use merge).

It does nothing for objects that are already persistent. I do not know if there is a performance penalty with running update on an already persistent object, if there is, it's probably minimal. It does clutter up the code with needless lines however.

Then when should I use it?

My current project is a large enterprise system with java on the back end, .net on the front end and web services in between. The front end is fairly light and thus does not know about the data model. For that reason the front end does not operate directly on the data objects. If it did, there might be a case for using update. i.e. I've received an object from the front end with changes that were made by the user. and I need to persist those changes so I call update on the object. The pattern we follow however is the one outlined in the code snippet. Load an object from store, make changes to it based on data received from front end - changes are automatically persisted, no update call.

But there is one case that I've encountered where we do need to use update and it illustrates an important thing to remember about hibernate...

Consider the code...

transactionController.startTransaction();
Person person personDao.loadPersonById(personId);
person.setLastName("newLastname");
person.setFirstName("newFirstname");
transactionController.endTransaction();

transactionController.startTransacton();
person.setLastName("secondLastname");
transactionController.endTransaction();

I know it's a silly piece of code and you wouldn't find it like this in reality, but it illustrates the case simply. It is setting up a case where there are two transactions and one transaction is interacting with an object which another transaction touched.

What will the value of person.getLastname on the database? Believe it or not, the value will be unaffected by the second setLastname operation. It will be "newLastname". Why, what's going on?

The thing to remember here is that as far as hibernate is concerned, from the perspective of the second transaction, that person object is transient. The session that it was connected to is now closed and any change that is made to it is made as if it's a normal pojo with no knowledge of the persistence store even though a new transaction has been started. That object does not know about the new transaction.

And that is where update comes in. An update needs to be called on the person object in the second transaction to persist the change to lastname. This as we explained earlier, will attach the object to the new session and apply any required updates.

transactionController.startTransacton();
person.setLastName("secondLastname");
personDao.update(person);
transactionController.endTransaction();

On our project, that is the only legitimate context where update is appropriate and necessary.

When to inherit, when to compose?

2008-11-07T08:24:00.001-08:00

I suppose if you're reading this you've read some of the material out there on when to inherit, when to compose. You've also probably familiar with the "is-a", "has-a" principles...

My brother Peter, who is a dotNet programmer commented on the issue and came up with a useful principle...

Don't do it.

Or more politely... When you think you need to inherit, you pobably don't.

That is probably a good best practice approach - I need to post about best practices and why I say it's a good best practice approach. The problem is that inheritance is abused and the naive rule of "is-a", "has-a" is responsible for to many situations where inheritance is not the answer - composition would have been more than adequate and without the constraints and complexity that inheritance introduces.

It's a little like threading. If you can do it in one thread, then do it in one thread - you don't want the concurrency problems.

Developers do what they see...

2008-10-22T09:01:00.001-07:00

This is probably the first really big project that I have been on and I have learnt a lot. One of the key lessons I have learnt is that the average developer is a sheep. He (or she) will do what they see and very seldom will they go against that.

In fact, even if it's wrong, they will do what they see.

It is has been quite remarkable.

So changing habits is not easy, especially if you're on a complex enterprise project which has been going for 18 months with a very fast development cycle. There are _many_ different ways of doing almost anything in the code so the poor developer has no idea what approach to follow.

It also means that changing habits is not easy, is has thus been quite encouraging to see some habits changing - I introduced commons collections into the code base, used it in my code, and showed a few dev's what it offers - and I'm now finding it is used more and more.

The other good thing about the way developers do what they see is that if what they see is good and right, those habits are persisted. I guess the opposite also applies, if what they see is low quality, they will extend that low quality.

Hibernate best practices...

2008-10-16T07:36:00.000-07:00

I have been on a very large enterprise project using hibernate for the persistence. Our data model is upwards of 200 objects. It is a clustered web application and thus requires high performance so we've implemented caching and have all our objects and relationship set to lazy load. The typical database interaction is lots of reads and few rights. The data of one user does not affect the data of another.

Here are some of my best practices which I would have loved to have had in place from the beginning. They would have saved a lot of time and reduced bugs...

Use id based Equality
This is contrary to a lot of the typical recommendations but I don't see a problem with it. It means that you have a working equality method without any further effort. Furthermore, you have a guaranteed equality, the same equality that the database uses. There are some issues with this when it comes to one-to-one relationships, but those can be resolved by adjusting the equals method. The other issue is that there are instances where there is no business based unique key.

Don't use auto generated Keys
So in your model classes set the id. This will mean you need another field as a persistence marker. The fundamental reason for this, coupled with the fact that you're using the id for equals, is that you have immediate equality, both prior to persisting the object and in your tests. By using auto generated keys you you have to wait until the object is persisted before its equals method works. You cannot thus use it in a set prior to persistence, and when you run tests you have to manually set the id every time you create the object.

Use instrumentation
Hibernate has an issue (a big issue IMHO) that if you execute the following code (Person is set to be Lazy loaded).

          Person p = session.load(Person.class, id);
      ContactDetails cd = p.getContactDetails();

And on the database that particular object (contact details) is actually a subclass of ContactDetails called AddressDetails, the real type of the variable cd will be ContactDetails and _not_ Address Details as you would have expected. In order to get the real type you have to do first ask hibernate for the real type of the object and then call load again with that real type. So in order for the variable cd to be the correct type you would require the following code:

          Person p = session.load(Person.class, id);

      ContactDetails cd = p.getContactDetails();
      cd = (ContactDetails)load(id, Hibernate.getClass(cd));

An extra line is required.

Instrumentation however injects code into the compiled class of ContactDetails and intercepts the call to getContactDetails to add the bit to load the real type. It's a small little ant job that runs within the context of our IDE and sorts it all out.

Use Field access over method access
Unfortunately, I only discovered that hibernate had the ability to directly act on the fields rather than go via methods too late to make use of this ability. It would have enabled me to setup some nice validation and/or side effects on the setting of a value in a hibernate managed object. I'm sorry I didn't do it earlier. This is a practice which I have thus not been able to test, it does sound like a good idea but maybe there are other issues I do not know about.

Think hard about your Cascades
Hibernate is not good at saving a whole object tree in one go. The problem is that as soon as any sql is executed on the database, the sql is validated against the state of the database. So any constraint violations are immediately raised. If you think hard on the cascades the ability so save whole trees is significantly improved though it is not totally enabled. One obvious practice is that if it has a not-null constraint the cascade must be set. If this is not set unless you save the foreign object before the local one you will get a constraint violation. The objects go together (thus the not-null) so the cascade should be on.

The above recommendations are fairly generic to any project that uses hibernate in the real world. There's a few that I've learnt on this project that are specific to a high performance and high concurrency web application...

Prefer trawling the object model over running queries
The kind of application we have is one where a user would login and probably send on average 10 - 20 minutes on the web site. Thus we would typically have a lot of the objects they require in cache already. Thus when you need to find some data for the person concerned it is a lot better to simply trawl the objects rather than use a hibernate query. The reason for this is twofold..

Querying in hibernate always causes a flush. Data is therefore written to the database at a time when it shouldn't necessarily be. Even though you know the query does not touch any of the pending writes, the flush will still happen.
A data connection is made. On our application we gained significant performance concurrency improvements by removing queries - the objects were already in the cache in any case. Where we had deadlocks we simply removed the query from the equation (changed to trawling the model) and the deadlocks were significantly reduced.

Make everying lazy
On our application where isn't a single relationship which is not lazy. We can't think of a case where having lazy off would be useful to us. Yes, I understand that it means the first read will be slow, but after that it'll be in the cache so it will be fast. If lazy is off even if the object is in the cache it will still load that object from the cache

In other words, if you have an object A which has a reference to object B and the reference is specified as non lazy. When you load A it will _always_ load B even if you don't go near B. Even if B is in the cache it will still load B from the cache. On our application we have a lot of static data. This static data was initially set to be lazy disabled (prefetching). Then we would preload all this static data. We found that the preload was very slow - even though it was coming from the cache - because it would have to load the root object plus all the non lazy relationship stemming from that object.

What Every Development Shop cannot do without!

2008-10-09T11:28:00.001-07:00

For those of you who have not heard of hudson, where have you been. It is the new kid on the block in the Continuous Integration space, and it (IMO) stands head and shoulders above the competition.

It has added an incalculable amount of value to our development environment, enough that we depend on it as much as we depend on our IDE. Furthermore, it has single handedly raised the quality of the code such that I am so disappointed we did not have it in since the beginning of our project.

Why do I say all of that?

To my mind, the killer feature that hudson has is that it supports plugins. This is a feature what sets it apart.

And the killer plugin, which has contributed to the code quality is a fairly simple plugin which allows the results of various code quality metrics to be summarised and tracked in hudson.

We now have continuous metrics for the following...

Checkstyle - this is a tool which examines source code against a number of rules. It checks for instance, the formatting is correct, cyclomatic complexity and npath as well as simple class/method lenghts. It flags as a warning if the rule goes outside of the allowable scope.
FindBugs - this is a class level code checking tool. It can find things like equals being executed against different types
Cpd (Copy-Paste) - a cool plugin that checks for where code is the same and thus probably was copied and pasted.
Pmd - another class level checker

Now I could have run these code checking tools without hudson. Hudson however, allows me to track changes over time and to know when new violations have been added etc. And the running of these tools has already avoided many potential bugs.

So if you haven't checked out Hudson and its Plugins, it's never too late. The longer you leave it the worse your code is going to get.

If you want to know more, then let me know.

JDK 1.4 is being retired...

2008-10-07T01:09:00.000-07:00

RIP ... JDK 1.4

If you haven't heard, JDK 1.4 is to officially entier End of Service Life. Over at dzone, Alex Miller comments about and what I find most interesting is that the fact that it's going to be retired is not going to make much difference to the software community. They are going to happily continue using it. If they're still using 1.4 now, I doubt whether it reaching end of Service is going to push them over the edge.

For one thing, software shops which use Websphere are typically still on 1.4 - this is because the big bear IBM is controlling the VM version of those shops and it's going to be a long time before WPS on Java 5 sees the light of day - so though WebSphere 6.1 supports Java 5, Websphere Process Server 6.0 does not. So spare a though for people like us who are still stuck on Java 1.4 and the news that it is going to be retired will be a non even in our lives.

Testng is Cool but flawed

2008-10-02T12:20:00.001-07:00

A few months ago we took a closer look at our testing strategy. We assessed testng and noticed it had a number of features we thought we'd find useful. e.g. data driven testing, ability to run only the tests the failed, configurable testing in xml based on annotations and/or xdoclet tags.

Based on the features and a little prototyping we decided to use testng as a standard test framework. We setup the tests to run on our CI server (hudson) and we were good to go...

And things moved a long smoothly, we used a lot of the extra features of testng and also found that having an xml file that indicated what was a test was quite useful.

But then issues started to surface...

1. Testng cannot run each test on a different VM. The makers of testng do not give you the option to run your tests in a totally new VM so you can potentially run into issues when doing integration like tests requiring the hibernate session factory and database. In junit I have the option of runnning each test case in a totally new VM.

2. Testng doesn't really work with 1.4 xdoclet annotations. Unfortunately we are still on 1.4 and thus had to use the xdoclet annotation mechanism for tagging a test. This was problematic almost all the time. I wouldn't be surprised if the issues we had with testng would be a lot less if we were able to use class annotations.

3. Testng tries to skip tests when the setup fails, i.e. it doesn't fail fase.This was the major issue. The problem was that when a test's setup does fail and thus the test is skipped, testng struggles to identify how many tests were supposed to run. Thus in our CI server we found that the number of tests kept on changing. Permanently. Thus it because very difficult to get predictable results and a good idea of what is going on in the tests.

4. The Eclipse plugin for testng is not as good as junit's. The developers in my shop were unhappy partly because of this. When I announced that we were moving back to junit they were happy. Some of them had continued to subclass TestCase because they felt the assertions provided were a lot richer when this is done (and they are). With Testng, because it is not required that you subclass when creating a test, you generally use the java keyword "assert".

So now we are moving off testng back onto the old faithful, junit. There are however tests which are built with the data provider and/or parameter subsystems which testng offers and these will stay testng tests. We have no plans to move these off testng. And if our developers really need the extra functionality provided by testng, they can use it, within reason - our testng CI run has not totally gone away.

The approach now is, if the tests only requires the basic features which junit3 has, then use junit. If you need testng functionality, get permission for it before you use it.

The Developments at SpringSource

2008-09-30T01:22:00.001-07:00

The blogosphere has been abuzz with the news that SpringSource is going to be charging for support, and for maintenance releases. SpringSource is becoming a more traditional, more mainstream enterprise. Rod Johnson, one of the progenitor's of Spring has seen Spring become like hibernate in that though it is not a standard it might as well be.

Now they SpringSource, the entity which focuses on Spring development are looking at ways to extract value out of that popularity, but also, I think, take Spring to the next level.

And the developments are not unusual, or should not have been totally unexpected. How many other open source applications have gone the similar route. Redhat linux, JBoss, to a lesser extent hibernate... What other way do you monetize and open source application apart from selling support etc...

From all that I've read, the change to the release system is that "official" releases will only be available to non paying customers for three months after an official release. So 2.6.2 will only be made freely available if it is released in the 3 month period after version 2.6.

The bug fixes that go into any release will still be put into the source code and the licensing of the source code has not changed. So, then, why can't some developer checkout the source code, build it, and then make that freely available for all the other developers. I guess the only draw back is that it's not an "official" release. It's like a new car is only a new car if you drive it off the show room floor.

Personally, I don't have a major issue with where Spring is going. I think it's an acceptable way to build a viable business model out of their operation. Though it may serve to alienate purists, it might also cause people on the fringes to be brought in.

Programming is Hard

2008-09-25T02:28:00.001-07:00

I can remember my brother once remarking that "Programming is Hard", and I'm not sure he realised the importance and relevance of what he was saying.

On our large project - about 20 Java devs - I monitor the checkins and do some basic QA on them. The developers in this environment, who are apparently fairly good, still make school boy errors.

Fortunately we have hudson setup to do all the checks possible - checkstyle, pmd, findbugs and cpd - and so I can find most of the basic mistakes, like copy and pasted code for instance. But then often I find more complex issues, just bad design for example, and I've often thought about this issue.

I also maintain that computer programming is engineering. There is debate about this, but I think there are enough similiarities with "classic" engineering for it to be labelled engineering (I think it helps quality if you call it that).

Why then does computer programming not have the same aura that classic engineering has, and also the same obsession about quality...

Two reasons...

The first one is safety. When building a computer programming you're not building a bridge and thus you do not have to worry about people dieing if it fails. A "bug" in a bridge could prove very costly, not only in terms of money, but more importantly in terms of people's lives. There have been many instances when bridges have failed and their failure is put down the human error. Something that would have been called a "bug" in a computer program.

The second one is that the programming world is abstract. The result of this is that the world is a lot less limited. You're not limited by something physical when building a computer program. The result of this is that the barrier to entry is a lot lower, it's much easier to get into and also that it makes programming "easier" than other engineering. Easier in quotes because I think the problem we have with quality when building computing systems is because people think it is easier.

Programming with Quality is IMHO every bit as hard as building a bridge successfully or desigining and building an alarm system. If we want to produce quality we need to put as much effort into it as an qualified and certified engineer would put into building a bridge. We cannot think that our often mediocre, slap-dash efforts measure up.

Problem is, if you're reading this, you probably do see yourself as on a par with an Engineer.

Spring and JEE

2008-08-14T02:08:00.001-07:00

A helpful article I found on the value add of Spring...

Why do J2EE applications need Spring? The core of Spring explained...

It says most of the things I would say and doesn't "get ahead of itself".

I would strongly agree with points 1 and 2. Point 3, though it is a feature, is not something that I think, is used as much as people think. The reason I say that is how often do you actually have two implementations of the same interface, and switch between them? In our application we have loads of DAO objects, loads of service interfaces and yet we without fail have a one to one mapping between the interface and its implementation. The interfaces, IMO are useless fuzz. What I would prefer in fact would be for them all to be accessed directly (no interface) and then if and interface is required, then I can quickly and easily with the tools we have today, extract an interface and it's now abstracted. I only have the fuzz where it is absolutely necessary.

Though I must admit that we do use this feature and it does add value. I just don't think it is is the killer feature of the Spring Framework.

One of these days I think I should write a "why I like Spring Article..."

JEE take up could be better...

2008-08-11T09:27:00.001-07:00

I work on a fairly large Jave Enterprise Edition application, deployed onto Websphere. The company is a large corporate and the application is a publicly available web site, involving a .net front end, java back end and a database.

The application runs on websphere and is deployed by a team of people who manage the server environment. There are lots of similar applications which they manage.

We have our own "dev" application servers - these are little more than developer spec boxes running linux. They are used for basic testing and to validate the application before it gets promoted. And, because we manage these environments, have carte blanche access.

The amazing thing is that the application always works just fine in this environment, but when promoted, it suddenly no longer works. And it is no coincidence that the application does not work in environments we have no access to.

Now, when the application does not work, we get blamed. The onus always falls on us, the developers to fix the problem even though we have little to no access to their environments the application is deployed on. The fact that the applications work in the environments we do manage means that the problem lies in the fact that we cannot configure these environments ourselves.

What does this cause?

It causes us developers to build our applications in such a way as they have as little depedency as possible on the environment they're running in. Thus we use as little of the JEE spec as possible because those are the bits that need to be configured on the running application server.

I am convinced that if we had better access to the test servers, we would be more inclined to use the rich functionality provided by the JEE specification.

Setting Coding Practices

2008-06-04T23:48:00.001-07:00

Let's face it, anyone that has worked in development for any length of time will know that there is always change, and the "quality" of the code is a key area where this change is seen.

When you start on a project, you're not too familiar with the technology, you're not familiar with the problem space and you have a lot to learn. So you code in a certain way, and you use particular techniques to achieve your goals in code. Over time you learn better techniques, but the problem is you don't retrofit your old code to use the new techniques.

Recently I had to work on code that was written right at the beginning of my current project. Wow! Was it legacy.

This change and development is a good thing in the sense that it is a sign that things are improving, however it presents a challenge in that developers are very good copy cats. They will typically do things the way they see them done (even if that way is wrong) and don't as a rule go against that. In a sense that is also a good thing because we don't want a group of cowboys all doing their own thing.

The challenge is how do we accept this change and improvement, allow for it and even encourage it, and at the same time communicate the best practice approach to doing things. Furthermore, at some point we need to limit improvements (there's always trade offs), because any change that is made, needs to be tested. In our code base we still have all the various ways that things have been done from the beginning until now. When you have a project that has been going for two years, this is inevitable.

The Continuous Integration Game!

2008-06-03T08:56:00.001-07:00

If you use hudson, then you really should take a look at the CI game plugin. It's actually hilarious!

It stems from an idea originally (I think) by Daren Cummins described here.

The way the game works in hudson is that you get points according to your build activity. Plus points if you do something positive, like check in on a successful builds and minus points if you do something negative, like checkin to break a build.

Other examples of ways to score (or not) are if you change test failure/success, add or remove code checking violations (checkstyle, pmd etc).

It's been a great source of humour and a little bit or rivalry amongst our devs. Obviously you can't read too much into it, because it's easy to game, but it has added some value.

The plugin home page is here.

Firefox 3 Rocks!

2008-06-03T08:47:00.001-07:00

If you haven't downloading and are using firefox 3 you are missing out BIG time.

It is unbelievably fast - the whole browsing experience is super fast, and the javascript engine is about about 5 - 10 X faster. Even faster than Opera's.

The memory leak issues have also been fixed. With 17 tabs open, Task manager reports 237 Megs Used. I don't think I could have functioned with 17 tabs with firefox 2.

An Improved Skill level indicator

2008-04-25T02:35:00.001-07:00

With reference to my previous post on skill level indicators, I have come up with a new version... which I think is better...

It works in terms of "problems", since when employers ask for skill what they're really asking is, how useful are you to me with this technology?

1 -> Problems, what problems? (iow, I haven't had any problems because I haven't used it enough)
2 -> Somebody else solves my problems
3 -> I solve my problems but have to sometime ask someone else to help
4 -> I solve other people's problems, sometimes someone comes with a new problem
5 -> I solve other people's problems and there is never a problem that I don't know how to solve immediately

A working definition of the skills scale

2008-04-19T14:51:00.001-07:00

Have you ever done a "skills matrix"?

It entails writing down all your "skills", i.e. API's, technologies, languages, whatever might be relevant and putting a number from 1 to 5 next to them, and maybe a time length in years of your experience on the topic.

It is to get a prospective employer and idea of how valuable you could be.

The problem however, has always been, what does "1 to 5" mean. What is the reference point? You might regard yourself as an expert in Swing because you've built some funky table structure where you can edit the cells and render the cells according to their contents, you might put down 4, maybe if you're brave 5. But then what if one of the interviewers is a contributer to the swing API? In comparison to them you're only a 2...

I have thus always been skeptical of someone who puts down 4's and 5's. I'm going to make sure they're backing that up with something real. In fact, I'd love to interview someone who puts 4 or 5 for hibernate, it could be fun to show up their lack of skills.

Now what about if we come up with a more absolute definition of what the numbers 1 to 5 actually mean. So they're more than just mere numbers. Here is my stab at it...

1 – only read about and played a little with. I have indirect knowledge or experience (was on a project where they used it but I was not involved).

2 – shallow understanding, worked with by duplicating other work.

3 – becoming familiar, able to work with and beginning to understand what is going on. Extensive experience programming with.

4 – Understand the inner workings of the technology. Thus can solve problems where they appear. Extensive deep experience in working with.

5 – Extensive understanding of the whole technology. Totally knowledgeable and experienced with everything about the technology. Possibly spotted and fixed bugs in the API if applicable.

Is this helpful, or relevant? If you apply this grading system to some of the technologies you know would that change your score? I don't think any ranking method would be perfect, maybe people can comment on how it can be improved. Maybe there's a totally different solution.

Technorati Tags: employment, grading

Open Source and the cost you don't see

2008-04-17T10:59:00.001-07:00

The story on the register about Sun moving towards charging customers for certain enterprise features included the following quote from research house "The Standish Group"

"Open Source software is raising havoc throughout the software market. It is the ultimate in disruptive technology, and while it is only 6 per cent of estimated trillion dollars IT budgeted annually, it represents a real loss of $60bn in annual revenues to software companies."®

The full report is available here.

This supports something I've been saying for a long time and that is that companies who use open source should not, in fact, see it as a free ride. They are getting a significant amount of value out of the open source software they use, $60bn worth. Personally, I think that is under what the real value is - think how many versions of apache are running out there (compare the price of an IIS license and its features).

I'm not demanding however, that companies start paying for the open source software they use - that would be like the good guy (open source) becoming the bad guy, just not on the outside. The open source community is not in it for the money.

Companies should give back to the open source community, they could donate cash if they so wish, but a better idea is for them to let their developers work on open source projects, on company time. Those very companies are using the open source software and will thus benefit from the work their developers do on it, because the developers will work on features that they require, and on bugs they have found.

The company at large will not see money going out to open source projects, even though value is being added to the open source project. There will thus be no nominal effect on the "bottom line". They will have a happier developer (what developer does not want to work on an open source project), they will gain a lot more street cred and the open source software they use, will be improved.

It's a win-win situation.

Programming: where Humility is a genuine virtue

2008-04-08T08:02:00.001-07:00

You often hear of Sports players as being arrogant, and typically, it is not a compliment. The phrase is "He's an arrogant, good sports player". You do not hear the line, "He is not good sports player, pity he is not arrogant."

The point I'm getting to, is that the sports players arrogance or lack thereof, does not make a material difference to his performance on the pitch. Compare two top football (soccer) players. Thierry Henry and Christiano Ronaldo. Both artists on a football pitch, the one, Ronaldo, supremely arrogant (IMO) and the other the picture of sophistication, humility and just plain decency (he's got that thing that only Frenchman can have).

But, the arrogance or lack thereof does not make a material difference to their performance. No one ever said about Henry that he needed to be more arrogant in order to improve his performance on the soccer field.

However, it is not like that in software development.

In software development, humility is a virtue that can make a good programmer into a great one.

The other day I had to make some changes to improve performance on the application I work on, and then once those changes were made I deployed them to the clustered WAS server to test them. Quite an involved process this is. I figured, it's okay, there won't be errors in them so I didn't bother to test them on my own development machine.

Well, turns out, after many tries and many days of pain when only after I got the code onto the clustered server did I discover that it did in fact have bugs, that I finally got the code to run.

So my time saver at the beginning in not testing locally turned out to be much more time wasted in the long process of getting the buggy code onto the clustered environment to test it.

I was arrogant to assume that my code changes would be bug free. I thus lost more than a day because of this. If I had been humble then I would have checked myself before deploying to the server and thus saved a lot of time.

So unlike in sports where arrogance does not make a difference to performance, in software development, being arrogant is a liability. In a sense, it's counter intuitive. Even the best make mistakes (they've said as much).

Technorati Tags: software, humility

Is Software Art?

2008-04-08T00:39:00.001-07:00

I was reading a post the other day, can't quite remember where the issue was "is software Art?".

Probably the typical response to that is no, computer software is utilitarian and thus cannot be construed as Art. But that approach belies a limited view of Art and what constitutes Art. To say something is functional and thus not art is to limit the world of Art significantly, but also to limit the potential and possibilities of the functional world.

Let me explain... take a knife. You can create a knife the "cuts", i.e. is fulfills its function. However, you can also get a knife which _really_ performs its functions. i.e. it is well balanced, has a sharp true blade, has a firm easy to use handle and is aesthetically pleasing. Now, this better knife was not produced only by an engineer using his "engineering" faculties but possibly by an artist type person as well (could have been the same person). Thus artistic elements were introduced. Furthermore, on use, though the simple knife that "cuts" would also fulfill its function - as does the more "arty" knife, anyone who uses both knives would admit the latter knife is better, and not necessarily for a reason that can be defined in merely utilitarian terms - they both "cut".

And to my mind, a similar dynamic occurs in Software.

Have you ever presented your end product to the client and been frustrated that they don't truly appreciate the elegance of the application. Why not? They are simply looking at the software from a functional point of view, i.e. the non art point of view. However, you know that the software is a lot more than just utilitarian. It has an elegance that is hard to explain to people that don't "get it".

The question is, is that elegance non functional? If a picture is beautiful, it does not have any functional value, however, what is interesting about computer software is that elegance follows function. That elegance may not be leveraged now, but in the future, the good design decisions that were taken earlier can easily lend to better functionality later. When I look at a good program, I respond to it the same way as I'd respond to art. It activates the same receptacles. Furthermore, there is truth in that the way to write good software is to study good software, similar to the way to paint well or write good poetry.

Very often I have struggled to sell the benefits of a particular approach to non techies. For instance, the benefits of refactoring to your manager. When your manager looks at your application they just see a bunch of brush strokes, when you look you see a Rembrandt.

Dynamic Languages, Wow!

2008-02-12T13:34:00.000-08:00

The other day I went to a presentation on Dynamic languages. The case studies were python, ruby and groovy.

Well, it was nothing short of Wow. The potential for dynamic languages is _huge_ . I was blown away by what you can do when you take away the compile step. An application that can _change_ itself, at will. An application that can write itself.

An already built application that you don't like bits of, you can change.

Not having a clue whether your program runs, until you run it. i.e. all the pre-run step can really do is check your basic syntax is correct! There is of course, no compile time checking.

It was also interesting to realise how much we actually depend on the compiler when using static languages.

I think it would be like being a child again were I to start using dynamic languages as there is just so much you can do. You can of course shoot yourself in the foot much more effectively as well. It's a context where unit tests and test driven development is just a non-negotiable.

Certification, Is it any good?

2008-01-03T15:09:00.001-08:00

Recently a discussion has sprung up on the local java user group here in Cape Town (CTJUG) as to the value of certification.

A number of the members have expressed disappointment that though they have certification they still struggle to find work, and thus they ask on the forum for help in this regard. They've noticed that most software companies are looking for tertiary qualification rather than certifications and because of this they get despondent, and I can fully understand why.

The issues are numerous around this. If you search on the net you'll find much discussion on this very subject.

Certification does have value, but typically, depending on the context, more or less value.

Personel/Human resource people tend to value it highly, as this could be all they have to go on. In other words, because they don't understand the context they will put more value on certifications which probably means that in larger companies where human resources are involved in hiring, you'll find your certification more valuable.

However, in my experience, I don't find them valuable, unless it's all you have.

The fundamental issue here is that if a company hires me only because I have the certification then they are hiring as a mercenary just to do a particular job. To be honest, I'd rather not work in that environment because they have not understood the true value that I can add. I'm only speaking for myself here but I think you'll get an idea why I say this fairly soon. The value that I add is problem solving, research into new technologies, finding new ways of doing things, putting in new applications etc... I'm not a person who sits on his hands and waits for someone to tell him what to do. A person who punts his certification, IMO is. A person who punts his certification also does not understand that the real value in developers come from adding values in techs they do _not_ know. Because the industry is moving all the time (I'd rather say moving than changing), developers need to move with it. If you don't have developers that can move with it then you're going to be left behind and certifications tend to be dated. I'm certified for Java 1.4 you might boast, well what happens when java 1.5 comes along. How does the company know you'll be able to handle what 1.5 throws at you. Generics, for instance, which are not elementary.

And furthermore, I did a project for a large retail company where I had to "finish off" a program written by another developer who was certified! in Java on the Web. The application he wrote was _crap_, of the smelliest most disgusting kind. I'm afraid from then on I've been skeptical. Besides, a company is never going to take you only on the basis of your certification.

In closing however, I would like to point out that the certification is important from one perspective and that makes them infinitely valuable. If you do not have a lot of experience, say < 2 years and you haven't some formal tertiary qualification like a degree of diploma then a certification might be the difference between getting the interview and not getting the interview, and for that reason it could be _very_ important.

Coding Style is more important than you think!

2007-11-13T07:37:00.001-08:00

Recently I read a post about the important qualities in a developer. One of the points that was made is that the developer needs to subscribe to the coding style of the project, even if they don't agree with it.

I thought, that's interesting, and it's not something that I'd want to do. I mean, I like my coding style, it works for me and it has advantages.

Upon further reflection, especially after looking at the deleterious effects of having different coding styles on a project, I now think that having, and enforcing a uniform coding style is very important.

But before I continue, let me first explain what I mean by coding style.

Coding style goes past code formatting and what is commonly known as coding standards, though I think coding standards should include, where possible, coding styles as well.

Elements that fall under coding style include

whether to have multiple return statements from a method
Whether to always use an iterator when iterating over a random access collection (List).

Coding style goes further than that, especially if you factor in more API specific elements. e.g How to initialise a collection in hibernate for instance.

The advantage of having a uniform coding style is a similar advantage to that which you get from utilising patterns. If you use a uniform coding style, then pieces of code become easily recognisable and familiar. Comprehensibility is significantly enhanced, largely because I'm seeing patterns recurring in the code, analogous to what occurs when I use patterns in design. I am familiar with that pattern so I know what the code is doing at that point. Furthermore, if a lot of though has gone into the coding style, it will probably enforce the most readable/most efficient and just plain best way of doing things. A naive example is when iterating over a list, always use an iterator. That is a good practice because it allows the collection implementation to change to set or some other collection without causing syntax errors.

But then is the win worth it. What if I do not like the coding style. One of the team leaders at my company legislated that on his project you cannot use "iterator" or "iter" as a variable name. You have to have a more descriptive name. I did not agree with that and probably would not have subscribed to that requirement had a I worked on a project with him. That would have been a counter productive approach however. There is no technical reason for using "iter" or "iterator" as variable names so for the sake of code uniformity I should have subscribed to his request. Rather have uniform code than keep the team ecstatic about what you're doing.

The value of information

2007-10-08T03:49:00.001-07:00

Fellow developers have jokingly labeled me a book addict, and I can see where they are coming from. I think if it wasn't for the negative connotations attached to being an "addict" of anything, I would accept the moniker.

Every 3 months I get withdrawal since I haven't bought a book in 3 months! So I go trawling Amazon looking for my next purchase.

There are currently a total of 10 books on my shelf here on my desk. Looking at them I mentally total up how much money is sitting there, at an average of $30 a book, that makes for about R2500 in total!

But every cent is worth it.

So what about the contention that there is already enough information available for free on the net. People that say that are patently not aware of how different "pay per view" information is. It is just soooo much better, and for a number of reasons, the most obvious of which is that with information that you buy, the better the quality, the more people will buy. Since free information is by definition, freely available, quality is not put at a premium because the author does not stand to gain from producing quality information.

That's not to say it's all bad. Both the spring online reference and the hibernate
online reference are very good. But as their name suggests they are more of the reference type of document. Bought information, as long as it's pitched at the right level, is usually a lot more comprehensive in it's treatment of the subject matter such that even for newbies it's comprehensible then free information.

Furthermore, because I have gained so much value from the books that I've bought, when it comes to hiring decisions people should take very seriously the candidate's attitude to books and such like.

Without the books I have on my shelf, I'd be nowhere near where I am today, and while I don't have a book on a particular subject, I feel there's a hole that must be filled.

Technorati Tags: books

The major advantage Open Source has...

2007-10-08T03:32:00.001-07:00

Open source software has been around a long time and it has traditionally played second fiddle to closed source software. The differentiation here is betweeen software that is free where you get the source and can make modifications to it and software that is not free, you have to buy it and you don't have access to the source.

Because open source software is freely available and thus does not require money being spent to acquire, what tends to happen in a development shop is that developers recognise a need they have and immediately go trawling around looking for an open source solution to meet that need. If they find one, even if it does not do all of what they want, the download it and use it. the key issue here is that there is no need for approval for the use of this kind of software because the software is free. Clearly it is fulfilling a need otherwise it would not have been sought in the first place.

It empowers the developers to find and use the tools they require.

If a tool is closed source, then you always have to weigh up the value it might add over the cost to purchase. It also needs to go through an approval process which might be fairly onerous, and then the final decision is often made by a non developer. Does it add enough value to warrant the cost. Personally, companies need to be a lot more eager to spend money on closed source tools because they've probably saved money because they're using some open source tools, Eclipse and NetBeans for example. What is more, as someone here pointed out, getting $20 cleared is just as difficult as getting $1000 cleared. So the cost is really not the issue. It is the _fact_ the money is required.

So come on open source, build us developers, more tools so we can use them.

Hudson Unleashed...

2007-07-30T10:32:00.001-07:00

It has been more than a month now since I started using hudson and I thought I'd give an update on the progress and on what I've found...

Let me say to kick things off that Hudson has handled everything I've thrown at it. There are now upwards of 50 projects being built by Hudson and hudson shows no sign of falling over or being thrashed too much. Furthermore, the front end is still as responsive and quick as ever.

It has a particularly active development community with the primary developer being active in the forums and also active in terms of working on the project. A new version is released about twice a week.

Hudson supports dependent builds iow, a build can be kicked off by the completion of another build. So what I've done is setup each one of our projects in Hudson. Hudson monitors the repo for changes to those projects and then builds them. If there are dependent projects, those projects are also built. Because of this I can make the polling interval and "wait time" very short. Developers know within a minute or two whether a checkin broke the build (compile errors). Sometimes unfortunately there is a false positive because of ordering issues, but that is acceptable.

Furthermore, because of this facility I can always have an EAR ready to be deployed. I get to re-use the result from one build in another build. The primary mechanism I used to do this was for the build to copy the generated jar to some shared location on the drive. It would be better to use a tool such as ivy to publish the jar because then I can leverage hudson ability to distribute builds to other machines (v. nice).

I've since discovered however, that if I publish the jar with hudson, then I can use hudson to distribute the jars. This is because hudson publishes the jar to a static url and I can get the jar via the static url. It's great - a lot lighter than putting ivy in.

Furthermore something very funky, is that you can fingerprint jars. If you tell hudson to fingerprint jars then it can tell you which builds used those jars. You need to fingerprint the jar both in the source project and in the dependent project for this to work. The key issue here is that you do not have to rename the jar every time. So if there is a build error with a downsteam build and you suspect it's caused by an upstream project, you can tell exactly which upstream build number the downstream build is using.

Hudson is just done well, and often it is in the small things that this comes through. One other example of this is hudson's ability to run arbitrary batch/shell commands. The command that you specify is not simply dumped to the console and run, but rather the command is dumped to a batch file and then that batch file is run. Very nice little consideration because with one sweep you allow multiple commands to be run! Very useful. I was able to create a hudson task to restart jboss for instance.

It's a great application, and if you haven't got a Continuous Integration server running in your environment, do yourself a favour and set it up, if you do, and it's not hudson, do yourself a favour, and set it up!

Hudson is cool...

2007-06-20T08:44:00.000-07:00

We were using continuum in our environment and eventually instability just go too much for me. It would kick off a build and then half way through the build would fail. It was very irritating. Which is why when I stumbled on hudson I was very glad, glad also because it is very very good. Occasionally an open source product comes along that is so good, so feature rich and just works that you can't believe it is open source.

Some highlights of its features.

Handled everything I threw at it, including simultaneous test and compile builds
Ubiquitous AJAX, responsive and intuitive interface.
Detailed rendering of the changes included in each build
Detailed “blame”. In fact will send special emails to the people that actually checked in code before a broken build.
Funky test reporting and result tracking - tracks the change in test result state between builds. Also tracks how long a test has been failing for
JIRA plugin available (very funky).
Still more features which I’m not using.

Today I experimented with its distributed build mechanism, and went "Wow!".

Would like to hear from any fellow hudson users.

btw, if you want me to compare it with continuum, I'll tell you with all due respect that continuum is notepad and hudson is eclipse/intelliJ/netbeans.

Hello World Spring

2007-05-21T00:50:00.000-07:00

For those programmers that only think a spring is something that can contract and expand, you're missing out on a particularly useful and more and more essential, programming framework.

It is the first time in my 6 year programming life cycle that I have used spring on a project and I must say, there is no going back. Its benefits are incalculable. Regardless of the size of the application the Spring Application framework adds enormous value.

What exactly is Spring then, or more accurately, what is the Spring Framework?

Spring is a framework which enables the efficient development and maintenance of high quality applications. It is an infrastructure which handles many of the every day which developers would otherwise have to do. It has many facets, with the various components both tightly integrated and complementary. But the biggest win with “spring-core” at it is affectionately known is that gives the application “Inversion of Control” or otherwise known as Dependency Injection.

Let's do this by example...

Consider the following piece of code...

public class BusinessObject() {

WindowsMailService mailService = new WindowsMailService();

public void sendMail(String recipientAddress, String message) {

validateRecipientAddress(recipientAddress);

try {

mailService.dispatchMail(recipientAddress, message);

catch (Exception e) {

LOG.error(“send failed”, e);

}

In the above example, if you have read Robert Martin's brilliant “Agile Software Development” you'd already be pointing out that you're violating the Dependency Inversion principle, and that is that dependencies should go “down” and not “up”. In this case if I wished to use a different mechanism to send the mail, maybe a LinuxMailService or even change the mode of transport it would cause a change to this class. i.e. The “higher” class would require a change if a changed the “lower class”. So in other words, changing details, i.e. Nuts and bolts of the mail send mechanism would cause a change in the higher level business logic of the application. This is something we want to avoid. By the way, it's also violating the open-closed principle.

It would be a lot better to abstract the message dispatch mechanism via an interface and then remove the dependency between the business logic and the message dispatch mechanism.

You may now be asking, so where does spring fit in. Well, even if we abstracted via an interface, we would still need to get at the service to send the mail somehow. This is where spring comes in. If I were to use spring to construct the above infrastructure I would first add a property to our business object above which takes a IMesssageDispatchService interface and then create a file which defined the infrastructure.

This file of xml is provided to a spring definition loader which would load the file in and create a context. The context would create the beans defined in the file, business.logic and service.mail and make then available via a getBean(String) method. It would instantiate them as the class specified and with any properties specified. In the above example it would call the “setMessageService” method on the BusinessObject with an instance of the MailService class. Thus the creation of the infrastructure has now been abstracted out into this file. Plugging in another message dispatch service would mean coding the service and then changing the xml definition file. No change to the calling context or any of its code, necessary.

So to show you...

IBusinessObject business = (IBusinessObject)context.getBean(“business.logic”);

You've probably already noticed tha changing the mechanism used to send the mail is as simple as changing the definition file. As long as the service.mail bean implements the ImessageDispatchService interface it can point to any class.

So then to give you a whirlwind summary of the advantages from my own experience, here goes.

Abstraction of the details

Spring lends itself to a system where the high level components do not have dependency on the low level components
Management of Dependencies

When you create a spring managed bean you can easily specify the dependencies (i.e. Other beans) which that bean depends on. Spring will then go and build those various dependencies for you and you end up with a fully built up bean. Those beans should also be managed by spring. You don't have to code the plumbing.
Simplifying and Enabling a good design

One of the problems I've often found when designing an application is working out the relationships between the objects and keeping those relationships clean. I've often found myself simply making a singleton out of my service objects and thereby making them available wherever they are required. I've often felt uneasy about this because I allow any object to have access to any other object and the relationships are not explicit. i.e. Because it is a singleton it can be referenced anywhere without limitations. Using spring allows those relationships to be controlled and explicitly defined (in an xml file) but at the same time it provides a mechanism to provide easy access to the services. The spring developers do not recommend that you do to much of the context.getBean calls illustrated above. This should only be done for the “root” of your infrastructure.
Flexibility

Spring uses an xml file to define the infrastructure. For this reason changing the infrastructure is as simple as changing an xml file, and spring provides quite a few efficiencies in how you can change this xml file, via a property file for example. In our project for instance, we can change from container managed transactions to hibernate managed transactions as simply as changing a value in a properties file.

I think the key issue with spring is that it is a framework. It is a framework for building an application. It's analogous to a building. Spring is the framework while the application is the bricks. Because you already have a framework, adding aop for instance, is simple, the framework enables it. It does a lot of the “heavy lifting” of management and infrastructure, leaving the developer free to work on the interesting bits.

An Example of spring in action...

In our project we have junit test which test at the service level and these tests test locally (outside the container and not via web services). Now because the service level is what is presented to the outside world, this is the level which is exposed by web services, and there is thus a one to one mapping between the service level and the wsdl's. Now for this reason I felt it was possible to switch those junit tests to test against a running remote application server, and I achieved this switch by adding a bit of spring infrastructure definitions and I only had to change one line in the test code!

Spring has become as essential in my day to day life as a programmer as an IDE. I would not consider not using it in any application, no matter what the size.

When I came on the project I had never used it, but then I had not been involved in developing an enterprise application and now I cannot be without it.

Reflective Revolution...

2007-03-05T05:08:00.001-08:00

It has been interesting to see the evolution of the use of reflection. I think, though I may be wrong that it was java that was the first platform to fully support reflection. At that stage I'm not sure the developers of java realised what it would become. The birth and subsequent development of a technology often follows this pattern. It starts off as a feature which might be used in one or two rare situations, as it gains traction and support, and most important performance, it moves into more mainstream applications.

In recent times, probably the last 5 or 6 years, reflection has become central to so many applications. One of the original uses of reflection was java serialization, The poster boy of reflection is probably Struts. Translating an http form submission and populating the relevant java form would not be possible without reflection.

Many more applications were found for reflection to add value for instance, it significantly simplifies runtime enacted AOP and makes is essential component in the development of rich object relational mapping tools available on the java platform.

I can hear the reader asking about performance... let me acknowledge that yes, certainly historically that has been a factor, but I think the java brains trust have expended much resources improving this situation. Each edition of the java runtime has seen significant improvements in performance of reflection such that in 1.6 the performance penalty is negligible. In 1.3 it was slow, in 1.4 is was adequate, 1.5 brought it up to reasonable pace and 1.6 has further improved on this. It is slower than direct method calls whichever VM is used, but the value that it adds more than makes up for the performance penalty. The old adage that says, design first, and then optimise later applies. Because the performance penalty introduced with reflection is constant, in reality it will probably not be the biggest culprit.

Reflection probably has an even greater contribution to make to modern programming. It is probably fair to say that developers do not consider using it. Performance will probably play a role here, but also a loss of explicitness. The code is not as self explanatory, errors may only appear at runtime for instance. There are applications where this loss of explicitness is not as much of a factor.

For instance, on our project we require the ability to copy between context, from dto's to model objects. Reflection is a useful tool in this case. When needing to update a data managed object with a dto object. Another useful non invasive use of reflection is to compare two objects for testing purposes. There are probably a number of factors to look at when considering using reflection...

1.Does the solution to the problem require much repetitive “dog work” code.
Copying values from one object to another is the bread and butter of reflection. The bean utils library is a useful addition to a developers arsenal in this respect.
2.Will the reflective element be executed many times
One of relection's biggest value adds is that can replace hand written functionality and modularise it. If you can solve a task with reflection you can reduce the amount of hand written code required and thus increase the quality. The more hand written code there is, the more bugs there will be.

What is interesting about the current situation in the project is that speed of development has become the driving force behind everything. We have got to speed up the process. Reflection is a particularly useful arrow in the quiver in this regard.

The story so far...

2007-01-30T23:29:00.000-08:00

Apologies to those who have been watching this space and seeing no updates. In my defence I have been particularly busy...

So I have some catching up to do.

I have a number of things on my mind, I think I'll start with a little bit of a report back on the goings on on the project for the last few months.

When we started on the project, a websphere/RAD based enterprise development with web services and session beans we eschewed the default RAD/WAS approach of hand coding the wsdl's. They were deemed to complex, and to be honest, there is some truth in that. However, like a fellow esteemed developer pointed out (web services duplication language) there is a lot of duplication in a wsdl so once the basic wsdl has been coded it is merely a case of copy paste. Furthermore, if the best practice approach of having one request object which encapsulates all the objects, once the methods have been setup (in the wsdl's) and the xsd are outside of that file, then changing the parmaeters of the method does not require editing of the wsdl. In fact it is very seldom that I find myself editing the wsdl file.

Thus the first round was via a a simplified wsdl where the xml containing the parameters was passed as a string. This string contained the method to be called as well as the parameters of the method. This approach was quite convenient because it meant only one ejb session bean and one web service (wsdl file), thus adding functionality at this level did not necessitate a new ejb/wsdl. Quite nice, but it is not particularly explicit (the outside does not know what is available), and furthermore it was an off standard approach.

Thus effort was made to beak the back of the IBM websphere wsdl generation and web service “topology”. It wasn't as difficult as initially thought. There were a number of teething problems brought on by the fact that the calling context was dotnet and thus had different requirements. Time was spent refining the process and today we have an automated object generation from the wsdl's. What is ironic and should not be surprising is that the whole wsdl to java generation sub-system has nothing to do with RAD, it only has dependencies on WAS. The generation and wsdl tooling of RAD is for want of a better word, crap.

This approach worked well for us. We have ant scripts to generate the dto's from the wsdl and it is nicely integrated into eclipse (notice the emphasis even though we're actually using RAD).

All very well, but the whole time RAD was holding us back in terms of productivity efficiency. The pressure from the business in terms of time frames etc increases all the time, and we found we were just losing too much time due to the idiosyncrasies of RAD.

To give you an example, my RAD platform can no longer refactor! You might ask, what? Yes, when I try and refactor it throws an exception, some yarn about JSF! Wt_? You might ask, what have you done? And I would answer by challenging you to tell me exactly what I could possibly have done. Put it this way, I did not delve into the class files of RAD and change them to specifically make it stop refactoring (there is about 6 gigs of RAD on my hard drive), for what else could I have done to make it stop refactoring? The second question I would ask is how can software possibly let you disable some functionality in some way. It's like driving a car, when you drive a car and it breaks down suddenly you don't exactly ask what did you do to cause it to break down? So it is the wrong question. The very fact that I can cause my IDE to break down in some way is ridiculous.

So this week we embarked on a mission to use Jboss in development. We will still be deploying onto WAS (our build server) that the front end people will use to test against but the DEV will be on eclipse/JBoss. This transition has gone better than I think you'd expect. Jboss is a quality product.

It is hundreds of times faster, more efficient, more light weight – not that it can't mix it with the “big boys”. It is not a monkey and WAS the elephant, it is in fact as nimble as the monkey and as strong as the elephant.

There has been minor differences between WAS and JBoss, this is to be expected. We had a minor issue today with the JAX-RPC mapping differences. I do not foresee a show stopper in this endeavour.

That is an update from my side in terms of what's been going on. See my other post for a programming specific ideas.

The role of the wiki in the dev team...

2007-01-30T22:52:00.000-08:00

When I arrived on my current project one of the first statements that was made is that we need a wiki. I hadn't used one in the past so was a little intrigued by the concept and what it would mean. I felt they were the flavour of the week and felt they would add value a wiki was setup.

It quickly became apparent that a wiki is an essential part of the efficient operation of any software dev team and I think for a number of reasons.

The wiki plays an important role in the collection, storage, categorisation and dissemination of information (mostly technical) related to the project. For any software team to run efficiently information is required that can be shared by the team, and a wiki is probably the most efficient mechanism to do this.

I'm not sure exactly how the word wiki is defined or what makes a wiki a wiki, and not being online right now, I cannot look it up. So I'll give my take on the essential elements of a wiki.

A wiki is an application which serves information efficiently, allows information to be related and structured and allows for easy editing of the information in the same context as it is viewed. Typically they run in a web architecture though it is not fundamentally necessary.

The question then is how has the wiki added value to team and how to you optimise that value.

I think the simple way to show the value of the wiki to a dev team is to look at what would happen if the wiki was removed.

When I compare a previous large project that I was on, which did not have a wiki, with the current project that does, the previous project would not have the problem that they do not have adequate documentation. The documentation they do have is either out of date, fragmented, duplicated in a number of places or irrelevant. The wiki would have removed all those weaknesses. It would have...

Provided a centralised location for all documentation
Provided a tool to categorise and relate various pieces of information together
Allowed for the quick and easy updating of information, keeping it relevant.

Furthermore, in the past, people would often say “Where should I put that information?” - the default answer now is “on the wiki”. It is surprising how often this word comes up in every day conversation.

Once you have been using a wiki for a few months it becomes indispensable.

However, there are number of challenges...

Keeping things relevant – at the beginning of the project a lot of information is placed on the wiki. The rate of discovery of new information is high so the wiki grows quickly. This information has relevance for that time, and because the rate of change in modern IT projects is quite high, information can quickly become dated. Because that information is no longer relevant the motivation to maintain it is low. Take our project for example, there is now a lot of information on the wiki which is irrelevant!
Wiki structure – this is arguably the biggest challenge and I think potentially the most difficult, especially when things change – but getting it right can add a lot of value. The reason I say this is that if the information is appropriately structured, then it can be found more easily, and if it can be found more easily, then people are more willing to use the wiki and thus information is better disseminated.

But I think one of the key issues to remember is that there is no silver bullet to improving quality. A wiki is one of the tools at the developer's disposal. It can't make people record pertinent, nor can is make people read pertinent information. One of the problems with information is that in order for information to be useful it has to be read. It is no use if the only person who benefits from the wiki is the person who originally wrote the information. Having said that, at least the information is now in two places (the developer's head and on the wiki), so the risk involved with that information is reduced.

All the wiki and other development tools can do is make things easier for the developer. They can improve quality if used appropriately and the wiki is an important, I would even say essential tool for improving quality and efficiency in a dev team.

What is interesting is that I do feel that the large corporates have largely missed the boat as far as the software for wiki's is concerned. I do feel that although the quality and maturity of wiki is high, I do think there is still some space for improvement in that space – it's going to interesting to see what kind of innovations materialise.

Trumpi raised the issue on his blog: How does one make wikis work?

C++ Inventor on Modern Software

2006-11-30T09:44:00.000-08:00

For those of you who regularly peruse sites like dzone you've probably already come across this article, but I thought I'd highlight it anyway.

Over at Technology Review there is an interview with Bjarne Stroustrup, the inventor of C++. Makes for some very interesting reading, he talks amongst other things, about software quality and why it is generally so poor. Well worth the read. It's a well balanced view and I'm sure for us developers there will be ring of truth about it.

In one section he starts by saying how there is some very good software out there, citing examples like the Mars Rover, Google and the Human Genome Project and points out that 15 years most people, even most experts would have pronounced these examples impossible. He also says that modern civilization depends on software so if software really was that bad, we'd probably all be dead by now.

He then turns his attention to the "average" piece of code and has the following to say...

I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

The rest of the article talks about a lot of other interesting things surrounding C++ and programming and how there are two kinds of programming languages in the world, ones which every complains about, and ones which nobody uses.

Google - the new internet

2006-11-27T07:57:00.001-08:00

In my day job as a programmer there are a number of sites a frequent fairly often, namely amongst others, the hibernate site and the xdoclet site. What is interesting is that I have found myself using the handy google search box in firefox to find these sites rather than a. use the bookmark or b. type a url into the address bar. It is a pity therefore that the google search box does not allow for a "I feel lucky" invocation as more often than not that is just the site I am looking for.

It's quite interesting to note as if I am only using google to access the internet and always using the I feel lucky selection then whose network am I really browsing. It is as if I'm operating on google's "internal internet!".

And I would be quite happy to do this. Typing in a search term into a google search is far more intuitive than typing www.hibernate.org/reference or what ever the appropriate url is, I don't know as I just type "hibernate" into the google box and select search.

Welcome to this new funky blogging tool...

2006-11-15T07:25:00.001-08:00

Wow, I am lank impressed with this new blogging tool. I do not even have to go near the blogger.com site in order to publish something, how awesome is that!

Why I hate frameworks...

2006-10-31T01:49:00.000-08:00

If you haven't seen this link, then go and take a look. It's hilarious, because it's so true to life.

why I Hate Frameworks

It's brilliant.

And having been exposed to spring in a big way recently, I can see there is always a danger of that occurring. I guess the rule of thumb is to a. be pragmatic, and b. not be a servant of the framework. Keep the end in mind.

How to do web services?

2006-09-26T00:29:00.000-07:00

The project that I am currently on has been my first real exposure to enterprise grade, mission critical web services and I must say it's a real challenge.

What makes it even more challenging is that the project has a dotNet front end and a java back end, so we have to make the web service inter operable.

Let me start by just pointing out that we are using IBM's Rational Application Developer Platform version 6 to do the development, this does have a significant impact on your modus operandi, not only because of IBM's how can I say, blindness but also because of the current nature of web services development

When we stated out we were going the route everyone starts with, generating the WSDL and the web service plumbing from a java class, be that a session bean of a POJO. This as you may or may not know is not the best practice approach, and that shows when using RAD. In fact, IBM might as well remove the ability to generate wsdl's from java code RAD does it so badly. I know why it is not recommended.

Because of the fact that RAD is so poor at doing this and because none of the team knew how to hand code wsdl's, a notoriously complex job, we went a generic route where we have one web service which receives two strings, one for the details of the method to be called and another for the arguments. The translation between xml and objects is therefore our responsibility, and not dealt with by the application server and generated code.

We selected castor to handle this for us.

I then went on a mission to educate myself about wsdl's, and the surefire way to do this is to buy a book, which I did, Web Services Essentials (O'Reilly XML). That sure helped break the back. I was very chuffed when I successfully hand coded my first wsdl file that not only successfully validated with RAD but RAD also did an efficient job of generating java skeleton code from it. First I started with a hello world wsdl and then built one where an xsd file was referenced to provide the communication protocol.

I must say, it was not as difficult as I thought it might be - I also realised that most of that complexity is necessary. This is often the case, things are perceived to be complex because they are not understood.

One thing is for sure however, and that is that RAD's wsdl editor is a load of crap!

So to continue on my journey, generating java skeleton code from a wsdl is a painless process in RAD, whether you generate to a session bean or to a pojo.

The problem is, and this what I'd like to focus on, is that the web services runtime for Websphere (other web service run times as well), generate java source code for the communication objects from the schema. Now it is absolutely necessary that you use schema's (xsd's) to define the protocol in order that the client and server can understand what each other is saying, but the problem is this generated code.

Typically, in the schema you're going to have objects defined by the schema which are already defined in your code and if you've already built these objects, then you're going to have two versions. One generated and one hand coded, and you're probably not going to like the one that is generated.

Before continuing I'd just like to look at why it is done this way because there are technologies which allow you to take already existing java classes and map them to a schema (castor, jibx, et al). I think the builders of web service runtimes have taken the route to generate classes from a schema, the pojo as well as some kind of helper that knows how to marshal and unmarshal the pojo, because that way they can guarantee that the marshaled xml conforms to the schema. If they leave it in the hands of the developer to provide the mapping between the already built pojo and the schema, they cannot guarantee that this mapping is correct. I wonder if annotations and generics (which we cannot use because IBM is slow), could annotate already existent classes and save us this trouble.

Typically, generated code is not preferred. Developers like the code to be the way they like it.

You have another problem however, how do you copy between the dto objects and your value objects? Manually - are you kidding... If you have to do it manually then I'd rather re-use my value objects. If on the other hand you can in fact use reflection, fast becoming pervasive in computing environments, then it will in fact be a pleasure.

Watch this space for more lessons learned on the enterprise project.

.net first impressions...

2006-09-07T04:04:00.000-07:00

I have always been a java developer and since joining my current company, which does java and .net development, I have looked forward to the day when I would get exposure to how the .net platform works...

The project I am currently on has both .net and java elements and I have thus been able to dip tentatively into the world of dotNet.

The first thing I've discovered is that my learning the dotNet environment requires my learning a whole new IDE, and this, given the complexities and capabilities of modern IDE is a "double difficulty". Not only do I have to learn a new IDE but I also have to learn a new language. It is debatable which is more difficult.

If you consider that now only do I know java well but I also know eclipse (a java IDE) well and it would take me a long time to learn another java IDE, and it's not something I would find easy. Thus discovering the dotNet environment becomes doubly as difficult because I have to learn an IDE as well.

Now I must be careful of not making the mistake that I throw the book at the C# guys for doing, and that is condemning the platform because of the IDE. I can understand their thinking because for them there is only one IDE, thus the platform is the IDE.

Fortunately, in the java world, this connection is not so strong because there are a number of different java IDE's and thus you can choose the one that best suits your needs.

I think the point I'm trying to make is that learning a new platform is not simply learning the language and the intricacies of the platform, but also learning the IDE that goes with it. This is probably a bigger task than the language itself.

But then you may ask, so what are your first impressions...

I am not ready to comment on c# as a language as I do not know enough about it, but I can make some comments on Visual Studio... Do not see this as a comparison between c# and java, but merely as a comparison of two IDE's, regardless of what language they are for.

I think the first thing that must be said is that VS is unbelievably responsive! It is like waiting right outside the door to give you what you need. It is like the waiter who does not let your glass even get half full before he is on hand to fill it up. The java IDE's in general (possibly because of the non native nature of the gui), are more like the waiter who comes round every 5 minutes or so to make sure your glasses is full. Still gets the job done but just not so quick.

I must point out however, that it is probably not much more than a "nice to have". A lot of the facilities I've come to depend on in Eclipse just aren't there in VS. When I say facilities, I mean "micro facilities". It is also very difficult to assess an IDE objectively, first impressions are always clouded by the "I can do this in eclipse, why can't I do this in VS?".

I'll continue to report on my progress through the .net environment, as and when progress occurs.

Podcasts!

2006-07-31T01:03:00.000-07:00

Recently I have been assigned to a project at a company about 50 minutes from where I live. I therefore find myself spending a lot of time in traffic. It is less than ideal.

I can remember a friend telling me how he used to use his traveling time to think and make notes etc, possibly on some kind of voice recorder or something. He was making the most of the time spent commuting - it was even more than the time I currently spend commuting.

I felt that I needed to leverage the time spent commuting. In this regard I discovered podcasts. Now I would concede that in more "advanced" societies, i.e. the First World, there is more familiarity with these kinds of concepts, and better access so I am a little behind the times. Nevertheless they have enriched my commuting experience substantially.

I can now spend the time that I otherwise wasted keeping abreast of the latest developments in the tech world - the podcasts are all tech podcasts.

And for those people that think podcasts are much the same as reading the content - they are not, they are far more entertaining and interesting as you can have dialogue between for instance, a protagonist and an antagonist. Besides, I can't read and drive simultaneously.

The regular podcast I listen to:

zdnet's podcasts podcast.zdnet.com and specifically the "Dan and David Show". http://blogs.zdnet.com/BTL/wp-rss2.php?cat=12 - this is the one I listen to regularly. It is a very entertaining and informative podcast for keeping up with the latest trends in the tech world.

I tried the "Mike Tech Show" but it was far too simple.

If you have any podcasts which I should try, then pass them on.

Google Chat - how do they do that?

2006-06-02T04:26:00.000-07:00

Okay, so we know how to submit from the client asynchronously...

The question is, how does google chat do it? For those people that haven't used google chat, it is a web based chat client which behaves just like a normal one.

In other words, if I'm in a chat session with someone I get messages like "Bob is typing", and when Bob finishes typing, then bobs messages comes through. It appears as if the server is initiating communication with the browser! How do they do that?

The exercise started off by wanting to look at how AJAX apps built with google web toolkit submit data to the server - for this I installed a very funky plugin called "firebug". I was looking for something that would enable me to view the xml http requests submitted by the browser and this is exactly what firebug offers, along with a whole bunch of other stuff.

I used firebug on one of my simple gwt apps, and it showed me what I was looking for, then I thought I'd try it on google mail. It wasn't long before I realised how google's chat works.

Very simple to be honest. Nothing profound at all! When you initiate a chat with someone and click enter, it sends that chat message, but also submits another one. This one does not return immediately, but only returns when the user you're chatting with writes something! If it times out, as far as I know, timeout is 90 seconds, then it will receive a "nothing happened" message and then submit another "if you have anything to say put in this bucket" message. In fact, multiple buckets can be submitted in order that there is always one available.

It shouldn't surprise you that this mechanism has also been given a name and it is called "Comet".

Google Web Toolkit - some experience now...

2006-05-31T11:06:00.000-07:00

It was with relish that I embarked on putting the google web toolkit through it's paces. In fact, for the first time in long time, I coded for fun on the weekend. The recent addition of a laptop helped in this regard however...

For a long time I have wanted to build a simple database app to help out a local church. It's a simple app to manage a list of people, their particulars and other properties. Now I thought that would be an ideal test bed for the new google web toolkit - how cool would it be to make it a AJAX rich client app that runs in a browser. A familiar "link" would be all that is required. Because it will run in an intranet environment speed was not a consideration.

All in all, I was able to reach a fairly advanced stage, quite quickly. The API is very simple and easy to use. The "hosted" mode helps a lot. There were a couple of anomalies in the compilation of the javascript - you can't go wild with anonymous inner classes, the parser doesn't handle those very well, and there seems to be some conditions on your package names.

All in all, however, for an application of this nature, the google web toolkit is ideal.

I will have to do some work on the back end to get the data to persist, probably going to use flat files and an xml based serialization mechanism. It's very easy however to use stubs for those back end calls - funny how they're termed back end calls, whereas in actual fact they're simple request to an http server. With AJAX and DHTML the client is no longer dumb!

I had something else that I wanted to throw google web toolkit at (I call it "goowit" for short)...

Recently I built a Sudoku puzzle solver in java - complete with funky swing user interface and all - you enter the numbers, click go and it solves it. I was very keen to see if this would port to java script via gwt so that it can be deployed easily on the net. It took me a while to remove all the non gwt supported stuff - there were a lot of dependencies on java API classes not supported by gwt. I thought at one stage that it in fact would not work. In the end, it did, and I was very impressed.

So it was with great excitement that I finally got rid of all the "cannot import" messages on the hosted mode console - be aware that if an import fails it means that that the class has not been successfully translated, probably because it contains unsupported content. Once this was done, I entered my numbers and clicked go. In an instant it solved the puzzle.

Now for the final test, compile to javascript and see how it runs on the browser. This was where my heart sank, it was unacceptably slow. In fact, it probably would have taken about a day to solve one puzzle! The browser's "A script is taking too long" came up even before the first cell was picked!

Something which ran fine in hosted mode (java compiled mode) was far too slow in javascript mode. Now I'm not 100% sure exactly why - is it because the generated code is inefficient or just because job is too big for an interpreted language. I can't say. I think the rule of thumb here and it sounds obvious is to avoid doing heavy duty, complicated and long running processing with javascript. Not only because it may be slow but also because javascript is a single threaded environment and you need that one thread for keeping the gui snappy. Whilst a javascript process is running, the browser is totally non-responsive.

More exciting discoveries await...

Google Web Toolkit… a first look

2006-05-29T02:04:00.000-07:00

When I was first exposed to the AJAX technology and how it works at the Sun Tech Days, I thought to myself, why then can't you code in java and get a tool which allows you to "press button for thick client", or "press button for thin client". It would have to be some kind of a cut down version of java because you wouldn't be able to do everything on a thin client than you can do on a thick client.

In a nutshell, this is what Google has done with their google toolkit. It is, like a friend first said to me, "a way to write AJAX applications with standard java code".

They have solved a lot of the problems and what they've come up with is something far more amazing than I was thinking at the Sun Tech Days. especially since, having seen google's solution, the number of issues that I was just plain not aware of are vast.

Let me mention however, that they have not solved the "deploy to thick client" - though in a sense their "hosted" mode is exactly that. I think because that need is in fact not required in any case. There are already API's available for building thick client gui's and besides, practically speaking thick and thin clients are so different that you would not be able to seemlessly deploy to whichever you choose.

Google's Web Toolkit - Summary of usage…

They have built their own set of gui controls - the functionality of which can be realised in html. If you start using them, and you are familiar with html you will soon see this. They are "wrappers" onto the features of the html controls. They also have some of the familiar layout managers - DockLayout (BorderLayout), FlowLayout, TableLayout and others.
They "translate" java code into javascript code. This, to be honest, is probably the biggest achievement of the google web toolkit. It is not therefore an AJAX toolkit as such. It is far more than an AJAX toolkit. This feature by itself is amazing. I have a sudoku puzzle solver that I built with a swing gui. I am very keen to see if it will translate into javascript so I can run it on the client (no AJAX). There are some limitations to what can be done, since java is not javascript. They also have a little bit more work to do on the parsing side - if you find that your code is not translating properly then you need to adjust the source code a little (it parses the java source code). The prospect of porting my sudoku solver to javascript by hand is not something I would dream of doing, this way I can see it in javascript, painlessly.
Handle AJAX calls with standard RPC infrastructure but with additions to make it asynchronous. For someone who's done RPC in any context, a lot of the concepts involved will be familiar.

Build the remote interface, build the remote implementation of the interface
Build the Asynchronous remote interface - contains every method in the synchronous interface but with call back reference added to each call.
The process of calling is…

Instantiate the remote interface (on the client).
Specify the location of the "server" - in this case it is a servlet which you call.
Make the call - when making the call provide an implementation of the AsyncCallBack interface. AJAX familiar people will recognise this concept.

It didn't take me long to write a simple web application in google web toolkit which takes two numbers as input and multiplies them or adds them according to the button that is pushed. When I get a site I can place this kind of content on (zip files) I will put it there so that people can acquire it. For now, if you're interested, email me and I'll pass it on.

I'm using eclipse and created two run configurations for GWT compile and GWT run. When they mean compile however, what is interesting is that they're converting the java code into javascript code. Going from one language to another! Believe me, making sense of the compiled stuff is impossible - they've obfuscated it quite a lot and rightly so.

The payload can be fairly big - a fairly simple app I'm busy with comes to 82K. It might sound like a lot, but when you consider that there is absolutely no library code on the platform on which it is running it puts it into perspective. There is no big JVM required, the client only needs a browser.

All in all, it is an amazing tool. I'm not sure if it is ready to write business applications on - but I do think that day will come.

Google and AJAX - Wow!

2006-05-23T09:57:00.000-07:00

A friend pointed out to me that google has recently released a toolkit for ajax, and how you can simply code in java and the toolkit will do the work of web enabling it. That looks absolutely amazing! I can't wait to try it out.

Thanks Trevor.

Build Ajax apps in the java language

Eclipse and Netbeans... which is it going to be?

2006-05-09T03:03:00.000-07:00

Having attended the Sun tech days last week I was exposed for the first time to netbeans. Now it is my bad that I haven't investigated the merits of this very impressive IDE before, for from what I saw there, it is very impressive.

In fact, I would say that it is so good, that it is insane to give it away for free. Some of the industrial strength you-typically-only-get-them-if-you-pay-for-them features that it has are an awesome profiler as well as a collaboration suite that is just amazing. That suite along with some VOIP installation and you never have to get up and go to the other developers PC! In fact, you can probably do remote pair programming.

But what are the differences between Eclipse and Netbeans and why so much bad love between the two camps.

I think the initial bad love started when IBM decided to eschew swing and build their own gui API. Swing was slow and just not "nice". IBM's perspective was that having a GUI look and feel that resembled the OS's native gui API was preferable, and I can see there point of view. Swing, with all it's progress that has most definitely made, does not look as "nice" as the native gui API's (windows and GTK).

So I set about giving netbeans run with gusto. It wasn't long however, before my initial enthusiasm was repressed. Having been used to eclipse's rich set of refactoring and code productivity tools I frequently found myself frustrated that a samilar level of functionality is not available in nebeans. For instance, Netbeans does not have the following quick fixes: "create class" and "create interface".

Another one of Sun's gripes on Eclipse is that they use a non standard compiler. Sun wants them to use "javac" which they don't. I now understand why. The java builder (eclipse speak) is a much more powerful tool as it is far more "on the fly" than the java one. This is because it holds dependency graphs so that whenever a change is made all the files which depend on that change are also recompiled. In netbeans the appearance of an error is not immediate. The javac uses very basic "is the source file newer than the class file" to ascertain the need for a recompile.

I could continue... the debugger, is also not half as fully functional as the netbeans debugger.

In conclusion - I would agree that netbeans is a worthy competitor, the profiler, gui builder and collaborative tools are world class. However, developers spend far more time actually doing the work of editing and compiling, and this is where netbeans runs a distant second to eclipse.

Sun Tech Days...

2006-05-08T04:30:00.000-07:00

I had the privilege, last week, of attending the Sun Tech Days. It was the first time tech days were held in South Africa, and it was worth the wait. It was two days jam packed with great ideas, great collaboration, lots of learning, lots of sharing, lots of excitement, lots of great food (The food was particularly good) and lots of free stuff (managed to score 2 t-shirts, a bouncy ball, a java mascot as well as a sun tog bag and id tag in addition to the netbeans book I won for answering a question!).

Over the next few days I shall be blogging on some of the details on the conference. For now I'll provide short synopsis.

The first day opened with a keynote from James Gosling. I must admit, it was great to see the so called "Father of Java" in the flesh! Nice to know these people are actually flesh and blood like you and me. His opening key note was not amazing but did provide a number of pointers as to Sun's thinking on java.

The day continued with tech sessions on various technologies and infrastructures, some of the key technologies touted at the convention were AJAX, BPEL (business process execution language), Netbeans - a world class IDE and EJB3.

Sun has a lot of experience running these days and I must admit, it showed. The days were well organised and ran smoothly, the speakers were interesting and for the most part excited about what they were talking about. There were exceptions to this, though these speakers were without exception, non sun people.

The sessions were generally, very tech oriented - one techie talking to another techie - (no marketing blurb) and though they were at times a little basic, necessarily so, they had enough content to keep the familiar parties, such as myself, happy. I'm sure if I was totally unfamiliar with the technology I would have found the basics to be very interesting.

Johannesburg is an amazing place - Sandton must have the largest concentration of head offices anywhere in the country.

All in all, the conference was a success. I'm very glad that I was able to go, thanks to my company for sponsoring the trip. Though the value they gained out of it was far more than the money they put in.

Too many classes?

2006-03-20T01:53:00.000-08:00

This is a post which was originally posted last year, under my other blog thoughts for life. I'm reposting it here because this is where it actually belongs.

I can remember, when I was in under grad, my brother said to me that when you're stuck on a programming problem then just add another class (the word class in this article is used to refer to interfaces and abstract classes as well as concrete classes).

At the time I don't think he or I understood how profound that statement is. How often does one come to code and found just two classes that do too many things, and then scratch ones head trying to figure out what's going on.

That statement is borne out of the notion that having lots of classes is a good thing.

Let's take an example from real life...

Analogy from the Real World
Imagine your motor car's engine was made up of 5 parts. When the starter motor breaks you have to remove the water pump as well because they're both from the same part. So you introduce potential for problems. Maybe the mechanic does not re-install the water pump properly, and so a problem that was just the starter motor now takes longer, with more risk because you cannot just remove the starter motor.

Transferring the analogy into the software design arena and you soon realise that the problems are far worse. A class which does many things which requires one change, there is an even larger risk factor than the engine analogy, because of the potential complexity software component.

Example
To give you an example, a certain component of an application was particularly inefficient and for want of a better word, was just plain bad. I was tasked with upgrading (rewriting) it. When I was finished, the number of classes was about 4 - 5 times higher then in the previous version.

Why
Here are some advantages of having many classes...

Isolation of Bugs: In a system with many small classes, you have many relatively independent sub-systems all working together. If there is a problem, or a bug, chances are the bug will be isolated to one class, and only that class will have to change.
Flexible to Change: I can remember times when I've had to make changes to an already built system and I spend a good part of the time figuring out how the current system works because the current system is comprised of very few classes. If the system were comprised of many small classes, then I would only have to understand many simple, small pieces of code. I may even find that the piece of functionality where the change applies is wrapped in one class already, and that class may even be named appropriately.
Ease of Comprehension: Having many classes means you need less documentation. If you have one method which is rather large and you break it down into maybe two/three methods, and you name the methods appropriately then the method names describe what they do and the play the role that code comments would play in the larger method. The same is true when you break a system down into many classes.
Potential for Good Design. I have found that when a system consists of many classes, chances are, the design is good. The number of classes would however, have to be relevant to the complexity involved, and this relationship is often an exponential one. As the complexity increases, so the number of classes increases even more. It is only by experience that one gets a feel for how many classes are appropriate to perform a particular job, but by and large, if the complexity is high and the number of classes is low, then the design is poor. If the number of classes is high this does not necessarily mean the design is good, but it is one of the indications.

I've heard rumours that in the past people were reluctant to have many classes with many methods because of the overheads of method calls and class intanstiation. The rationale for this consideration has been removed by efficiencies in modern compilers, virtual machines and the speed of hardware. Yes, you do incur an overhead when calling a method and instantiating a class, but, in general practice, I have found this to be negligible. Time and time again, design well, and then optimise rings true.

Real World Example
Why does this work? Well, it won't work if you just divide your large class into smaller classes in a naive way. If you were to divide a class into smaller pieces but still achieve the same degree of coupling between the classes as was previously the case, then you haven't achieved much. It is far more valuable if when dividing the class into smaller ones, the coupling level between the created classes is fairly low. In other words, the various classes do have a semblance of meaning outside of their context.

Take for example the problem that says

Read in a file
Count the number of words in the file

A naive approach would put all the functionality into one class which will read the file in and then count the words by counting the number of spaces. This would require one class.

A far more funky approach would be to separate the reading of the file from the counting, and if this is done with a low degree of coupling (via an interface) then changing the source location from a file to a string would be a simple process. If the counting is also done in its own class, then you could also change that algorithm to count say the letter 'a' without affecting the way it sources the file.

The classes that would be requried would be

Interface to communicate with the data source
Interface/abstract class to communiate with the counter
Concrete implementation of the file sourcer to retrieve it from a file
Concrete implementation of the counter to count spaces/white space
Controller to hook the two up

We've gone from 1 class to 5 classes in a very short space of time.

Conclusion
So when you code, do not be afraid to make many classes.

And when you're stuck, just add another class.

Get Perpendicular!

2006-03-10T00:37:00.000-08:00

This is most hilarious...

Slashdot reports that "Hitachi has recently announced perpendicular recording with their harddrives".

That is good news because it means hard drives can get even smaller.

That is not the funny bit however, they've also developed a "music video" to go with it....

Absolutely hilarious!

For more information on perpendicular recording see the wikipedia article on it.

EJB JDO, what's going on

2006-03-07T18:30:00.000-08:00

I've read with interest the discussion on the go between the JDO camp and EJB camp.

If you're not familiar with it, I'll give you a brief background.

EJB, more specifically "entity beans" is a persistence framework. JDO (java data objects) is also a persistence framework. The Entity beans framework is part of the broader EJB spec, currently in version 3.0. JDO is a "stand alone" specification in a similar vein to EJB in that Sun publishes the specification and a vendor then implements that specification and sells it on the market. JDO can be used in a desktop app, a web app or in an application server. Entity beans requires an application server to work and comes with significant overhead because of this.

I have used JDO extensively and have recently started looking at EJB in its version 2 guise. To be honest, the learning curve for Entity Beans is huge! It would take a developer twice if not three times as long to be useful under Entity beans than under JDO. I know because I was new to JDO at one stage and can remember how long it took me to learn. The developer would need to learn a lot of not specificaly persistence related stuff like session beans and local/remote interfaces.

There have been a number of discussions on the pros and cons of JDO against EJB. What makes the discussion even more interesting is that the latest EJB 3.0 spec, from what I've read, is unashamedly Hibernate! There are a number of conspiracy theories floating around as to why the EJB expert group went that way. The plot thickens when you consider that the JDO 2.0 specification is still in the process of being ratified - it has been rejected once already.

One of the loudest shouts in the community has been "We don't want two persistence frameworks!". My response to that is "why not?". It gives the user choice, it increases quality via increasing competition, it promotes flexibility. I say bring on alternatives.

This is the rationale behind the push on EJB 3.0. It seems that somehow this specification has won the day and that JDO has been abandoned. The primary reason for this I think is that because of the fact that Entity beans require an application server to work, the large vendors, Oracle, BEA, IBM, JBoss (who own hibernate btw), have supported the EJB specification because that way they protect their market.

To utilise JDO you do not need a heavyweight, complex and expensive application server.

The other apparent reason for the support of hibernate via EJB 3.0 entity beans is that hibernate uses standard sql as its query language. This not only locks the user into the underlying database but apparently affords the developer a seamless cross-over. I do not see how this can be seamless when the developer has to learn about all the overhead that comes with running on an application server.

I had to learn the JDO QL (JDO Query Language), and the syntax is a lot cleaner than SQL. JDOQL is far closer to object space than SQL is. It is just a more obvious and better fit when it comes to the object space. The key here is that it is far easier for an OO programmer to learn JDOQL than it is for an OO programmer to learn SQL. Which is why I do not buy the "they'll have to learn a new query language" rhetoric.

Furthermore, there is no reason why you can't use JDO with an application server. Again, surprise surprise, you have choice.

Reading various articles on the subject might indicate that JDO is dead, well, I was pleasantly surprised to note that the final round of voting on the JDO 2 spec is imminent. See jcp 243.
I'm holding thumbs for its adoption.

It probably won't be ratified however; based on the voting up till now a betting man would not put money on it.

Ultimately, I think that Apache opinion is correct and the most democratic and "broad based". They have always maintained "Let The Market Decide!". The specification is good enough, the implementations are of sufficient quality that the computing industry will use it. Proof of this is that a number of companies have already implemented the JDO 2.0 specification without it's ratification! JDO fulfills important requirements quite efficiently. In my work place we have used it for two web applications so far, and have seen no reason to go the Application server route.

Let's hear it one more time, Let the Market Decide!

btw, if you have an opinion, then tell me what you think...

Java on the up...

2006-01-20T00:04:00.000-08:00

Recently, anecdotal evidence has suggested to me that java's influence has been on the wane... Especially given the view in Cape Town, South Africa - South Africa has traditionally been a microsoft land, while in other countries (mostly first world), microsoft is not so strong.

However, according to Tiobe Programming Commity Index, java is the most popular programming language on the internet, not only that, but java also won the TIOBE Programming Language of 2005 award. Go Java!

Based on more anecdotal evidence is done seem as if microsoft is stronger in the developing world than in the non developing world. I do not think that the battle is between microsoft and java but between closed source proprietary and open source public domain. Open source thrives in environments where you have a high number of educated people as well as a high number of people who have the time to devote to developing open source applications. It stands to reason that if you have a high number of people developing open source applications in their spare time, those same people are going to push the adoption of open source in their day jobs, thereby increasing the popularity of open source, and thus java. It might also be true that open source requires a sufficiently large programming population in order to develop, another reason why java is probably more popular in first world countries.

You may be asking why open source does not fit with VB and C# - the answer is simple. You can't run an open source operating system and code in C#/VB. Okay, before you argue that there are IDE's where this is possible, they are not in the main stream developer market.

Eclipse RCP - have got to see this...

2006-01-09T01:07:00.000-08:00

Before I point you to the merits of the Eclipse RCP I'll just digress for a moment and say Happy New Year to all those who deem the new year to be on first of January. I hope 2006 brings many epiphanies for you.

But like I was saying, the RCP is a stunning platform to develop on top of. Every piece of your application is packaged as a plugin so modularising your app is simple. On top of that, you get advanced update and management capability out of the box.

If you need a quick demonstration of its power, then take a look at EclipseZone - Why You Should Use Eclipse RCP (In 10 Minutes).

It'll prove to you the merits of developing on the eclipse RCP platform better than any words could.

btw, the link embeds a short movie clip to walk you through the process of creating a RCP app with eclipse. Unfortunately, it does not work in firefox. However, there is a plugin which with one click allows you to open a site in IE. It changes the current tab to an IE tab. Seemless IE integration! A very useful ie plugin.

What is an object supposed to know?

2005-12-20T06:42:00.000-08:00

I must apologies for the long deley between posts, unfortunately, I have just battled to come up with anything interesting to write. Hopefully this post will change this.

I have recently started investigating Enterprise Java Beans. It has been both interesting and frustrating. Entity beans I find to be hugely complex, all the local/remote/home/bean concepts are to my mind, having used JDO extensively, rather complex and difficult to grasp. Let's hope EJB 3.0 is all I'm hoping it will be...

Anyway, back to the matter in hand.

I was reminded of the relationship between what an object does and what an object knows. These two concepts are inextricably linked and should be carefully considered. To take an example from the real world - there are often times when knowledge is specific to the role of that person/entity. The classic - need to know basis. As an employee of a company I am given enough information to perform my set tasks, and no more. There is certain pieces of information which I should not be provided with, because they involve knowledge that is outside of the ambit of my responsibility.

The other scenario where knowledge is important is when I need to find out something. I should immediately be able to deduce the person or entity which possesses that knowledge. The knowledge required should be congruent with the person or entity who possesses that knowledge. It would be inappropriate for the cleaning staff to know the bank account details of the company for instance.

Now let's bring out thoughts into the object space. Like I was saying, I've recently started looking at J2ee and Enterprise Java beans. I'm using the Eclipse Web tools project to do the development. When you request an enterprise bean you have to do a JNDI lookup in order to locate that bean - you provide it with a name, and it returns a bean. When eclipse sets up a bean for you it creates a Util class which knows how to lookup the bean (one util class per bean). Thus this util class not only has the behaviour to lookup the bean but also the knowledge.

Personally, I do not believe a class that uses a bean should be required to know the location of the bean. The reason for this is that a class that uses a bean has a functional job. Imagine you create a class to lookup employee details. This class calls an EJB to achieve this end. The directory information require to locate the bean has little to do with the job which the class is assigned. Thus that knowledge of where the bean is should not be stored in the bean. The class kinda thinks, all I want is a hook onto this bean, I don't want to know where it is, why do I care?

The thing to remember is that a class is defined by its behaviour as well as its knowledge. In other words, looking at the data which a class contains, be it static or dynamic, is a valid and important mechanism for determining what the class does. If a class contains the database connection url, then it clearly must be responsible for connecting to the database. Thus it could easily have two responsibilities (bad idea), some other responsibility which requires a database connection.

One of the advantages of providing classes with data on a strictly need to know basis is that duplication is reduced. If I have a class whose sole responsibility is to acquire a handle onto an EJB, if I wish to change the lookup information for that bean I only have to change it in one place. This is because only one class "knows" that information. The other classes are not privy to that information, why should they be?

In light of this there should probably be more objects in our code, with potentially more static methods as well. On the one project I worked on I implement a help system. I created a class with a number of static methods which contained the code for hooking and displaying the help. I effectively created a help "service". The class was full of static methods - changing the help system was as easy as changing this class.

Google and advertising...

2005-11-22T10:01:00.000-08:00

When google made their first steps into advertising they took the view hitherto not taken too seriously. While the rest of the industry was using flash based animated adds, popups and even rather intrusive "pop-backs" (popups which appear when you close your browser windows), they eschewed those and went for POTA's (plain old text adds).

Their text based entry into advertising is discussed at How Google tamed ads on the wild, wild Web.

The article makes the point that while they were entering the market and sticking to text adds, some of the other advertisers were convinced that they would have to move to animated, flash based adverts eventually.

However, I would like to suggest that by going the text based route, restricting the text to a specific length, and make the adds context sensitive, google has succeeded in taking web advertising from a necessary evil, something you put up with, to a valuable and relevant part of an everyday web experience.

It is not suprise therefore that google is the only company which is making a lot of money from web based advertising. They saw the good in amongst the bad, they knew there was money to be made in web advertising, only if it's done right.

I find myself going to a web site now and getting severely irritated by "flash" (excuse the pun). A collection of horrible animated adverts that just plain make me mad. Those are the ones I want to turn off, they are the ones that distract me and make my browsing experience particularly unpleasant.

I much prefer going to a page which does not have animated or even picture based adverts.

Personally, I feel that google has been so successful at making text based ads fashionable that the consumer will start demanding that they are the only kind of ads that they see.

Geek and Beautiful do go together...

2005-11-21T00:19:00.000-08:00

I stumbled on this site via slash dot I think, and I thought it was just too cool.

Check out The Geek Gorgeous Calendar featuring Women in Technology

"The calendar showcases young ladies who are not only beautiful and stylish, but can also fix your computer, normalize your databases, discuss the advantages of polymorphism, and beat you at Doom."

I think it's a great idea. Besides, who says you can't have both?

Best of What's new 2005

2005-11-09T23:54:00.000-08:00

Check out popular science's Best of what's new 2005

Those pesky Gui Designers...

2005-10-28T11:20:00.000-07:00

My first introduction to a heavy weight java IDE was JBuilder. I have to admit, I do not remember those days with an fondness.

The application was in a nutshell, a data maintenance gui. I can remember rolling up my sleeves and fighting with the clumsy and just plain irritating gui designer.

Nowadays I have an intense disliking for the concept of automated gui design. I feel that coding it manually is a far more efficient and liberating approach to gui design. As an aside, I did experiment a little with gui design on the SWT API and saw an awful lot of potential there for a gui designer that I might be persuaded to use.

I think my eschewing of gui designers is both because of the lack of control and because I disliked the code that gui designers produced. Which is why a salute Charles Petzold and his article Does Visual Studio Rot the Mind?

He fully endorse everything he says on the subject and highly recommend that you read his words on automated gui design.

I'm also sure all the java programmers out there, will have a quite chuckle to themselves when they read about Microsoft plans with Avalon about how they're going to introduce layout managers (sic).

Object Oriented Design?

2005-09-16T09:54:00.000-07:00

When Object oriented design first came on the scene there was a great deal of excitement. One of the early mantra's was that with the OO programming paradigm you can create complex data types which not only contains data but also the behaviour associated with that data.

The most obvious example of this is in the case of the Vector data structure. The standard vector consists of three scalars, x, y and z, and as my ever persistent matric science teacher was at pains to point out, "has magnitude and direction".

With OO you can create a data structure which contains the 3 scalars and a collection of methods in the same context as the scalars to allow the vector interact with other vectors. Addition, multiplication and dot product etc.

However, I'm not so sure if this is the key to the success of OO, nor that this paradigm should be ubiquitously applied.

It's probably fair to say that the majority of data types that are built in modern programming do not have such a tight coupling between their behaviour and their data and therefore this encapsulation should, in most circumstances, not take place.

In the case of the vector, it is in fact defined by its behaviour; the vector is an entity which has this set of data and behaves in this way. The same cannot be said about a Person object for instance.

Let's change tack for a second and look at what would happen if we do enapsulate the behaviour of an object with its data.

Consider a person object, it contains the name, surname, birthday etc of a Person. If we place behaviour for the person object into the person object it becomes prohibitively difficult to reuse that behaviour, for a different person object for instance. If we wish to use that behaviour we have go via the Person object itself. It also means that we cannot change the behaviour without affecting the data.

It is therefore better to create a data object which only contains the data associated with the Person and then another object which contains the behaviour associated with the person.

So then you might be asking, doesn't that make the data object little more than a struct, a concept which was part of the procedural programming paradigm? You would be right, but then that begs the question, why is the OO paradigm better?

The key to the OO paradigm is not that data can be associated with it's behaviour but that behaviour can be treated as a variable. The strength of a variable is that it is exactly that, it can change, it can be assigned and it can therefore be moved around. Now with the OO model we can pass behaviour around like a variable is passed around. With the introduction of objects, which have behaviour (methods), we can now treat behaviour like we would treat a string for example. We can pass it in as a parameter for a method, we can change the behaviour as easily as changing a variables value.

How is this achieved? It is achieved by something that was formally introduced in Java, the "interface". C++ fully supported interfaces in their "abstract classes with no implemented methods" guise, java however, created a new class type. Interfaces are exactly that, abstract classes with no implemented methods. In java, though it does not have multiple inheritance, there is no limit on the number of interfaces a class can implement.

If you write an object which contains functionality associated with a Person object then you would create an interface with which this behaviour would know how to talk. Your person object would then implement that interface, and by so doing, would be able to be acted upon by the functionality you have created.

Whether to separate behaviour from data is a decision that should always be looked at. Conjoining behaviour with data should only be done when the behaviour and data are tightly coupled. Making behaviour mobile is arguably the key advantage of the OO approach, and one that should be leveraged as much as possible.

Only do it once...

2005-09-01T19:08:00.000-07:00

When it comes to programming, one of my most recent mantras is to "only do it once".

Whenever I solve a problem, whatever that problem might be, I must only solve the problem once and then re-use that solution in future. By doing this you programs become many mini programs.

I can remember one of the first things I learnt, even when I still at school, about computer programs is that it's input, process, output. By employing this approach you are configuring alreaday written components, supplying them with input data and then firing them off.

A naive example would be, you have a square root to solve, you write a square route method, make it statically available (it is a stateless algorithm) and you never have to solve the square route problem again.

It has input - the input parameter you want to find the square root, it has processing, calculate the square root and it has result, the calculated square root.

Now on my current project, we receive data from a back end stored in a Map. We have to move that data into a data object. The populate mechanism for doing this would be to write something like...

vo.setStartDate((String)map.get("START_DATE"));
vo.setAmount((String)map.get("AMOUNT"));
vo.setDuration((String)map.get("DURATION"));
vo.setElecTransID((String)map.get("ELEC_TRANS_ID"));
vo.setInitialSequence((String)map.get("INITIAL_SUB_SEQ"));
vo.setNodeName((String)map.get("NODE_NAME"));
vo.setProviderID((String)map.get("PROVIDER_ID"));
vo.setRechargeMethod((String)map.get("RECHARGE_METHOD"));
vo.setTransactionID((String)map.get("TRANSACTION_ID"));
vo.setValueAddedInformation((String)map.get("VALUE_ADD_INFO"));
vo.setVoucherBatchNumber((String)map.get("VOUCHER_BATCH_NO"));
vo.setVoucherEndDate((String)map.get("VOUNCHER_END_DATE"));
vo.setVoucherNumber((String)map.get("VOUCHER_NO"));
vo.setVoucherPin((String)map.get("VOUCHER_PIN"));

Now, as you can see, for every different data object I receive from the back end, I have to do something similar to this.

However, that means I have to solve the same problem many times. If I apply the "only do it once, input process output" paradigm then I write a re-usable utility that will do the work for me. I supply it input parameters and configuration parameters, and it does the work of copying the data from the map to the data object.

In this case the input parameter is the map. The configuration parameter (this is a kind of input parameter) is the mapping between the key names in the map and the property names in the data object. The other input parameter would be the data object.

funkyMechanism(map, <ObjecToMapMapper> , dataObject)

So map to data object would contain...
START_DATE = startDate
AMOUNT = amount
etc...

In order to solve this problem in this way, reflection was used. There are ways to solve it using a similar input processing output paradigm, they're just not as elegant.

When programming try your best to only ever solve a problem once, and then re-use that solution. Think of instances where you can encapsulate a solution into input - processing - output. You'll find you code a lot less, your programs will be more robust and will have more of a Wow factor!

Swing and the client...

2005-08-19T18:18:00.000-07:00

For the last week and a half I have been on a java gui project... I had to wipe away the cob webs entangled in my swing knowledge.

I read somewhere months ago about how Java's uptake ont he client was not as much as could be expected. I cannot remember the answer to this question. Having spent the last week and half building java guis, I'm pretty sure I know why.

Fundamental to building a gui is the laying out of gui components. Java eschews the absolute positioning and sizing of a gui in favour of the concept of a layout manager. This is a laudable goal, and I understand why they went this route. I agree with it to be honest. In a multi platform environment you do not know how an absolute size location on one platform will appear on another. What about when the user wishes to resize? What happens then when using the abolute system. What if you want to let the user resize? Proof of this is evident in that there is no XYLayout provided in java!

However, laying out components with the managers provided is a black art. To get the gui to look exactly the way you want it takes a lot of hair pulling. Just to get a component to move to the left by 5 points can sometimes take up to 2 hours. Just to get a gui to resize in the way you desire could take half a day.

I start building a simple gui, using one of the simpler layout managers. Eventually, the gui just won't work, and I have to use GridBagLayout. As far as I'm concerned, this is overkill, but I don't have any choice. I'd rather _not_ use it, but what can you do?

It does not have to be this way.

I have used the SWT Formlayout and find it GREAT! I wish that someone would be so kind as to port the SWT Formlayout to Swing. I have taken a short look at the java FormLayout (jGoodies). I will consider that manager and the Table Layout manager. Maybe they will work better.

Workers and Intellectuals

2005-07-05T00:00:00.000-07:00

The commonly held belief is that in any company you need workers (people who do the work) and people who decide what to do. In other words, you need not so bright people who are happy to plug away at their keyboards, the "workers" and you need the intellectuals, people who guide the workers and leverage their value. That is the common view, probably wins the day mostly because you can't find enough "intellectuals", and you can't afford to pay a bunch of intellectuals their full value.

Look up http://www.thoughtworks.com. Started by someone who said no, and created a company of _only_ intellectuals.

But I digress. My Father has always talked about the difference between a manager and supervisor. He's said a _manager_ is an agent of change and a supervisor maintains status quo. Most of the managers in even our top companies are in fact super-visors. This is especially true in middle management. Pnp was a good example of this kind of manager. He has recently been mulling over the idea that leadership and management are not the same thing. This he says is what the cognscenti have recently been coming up with. And he has a point. A leader is someone who inspires, they have vision and drive. Just by sheer circumstantial evidence it is obvious that a manager is not necessarily a leader. I have found that a leader is more effective when they're perceived to be on the same level as the people they're leading. Kinda like the way you have NCO's in the army. They are some of the most important people in the army because they're on the ground. The infantry feel far more loyalty to the NCO's than the officers.

The other thing I wanted to say is that the difference between a manager/leader and worker is not intellectual or in ability. It is in _attitude_. Managers need to have the "can do" attitude. That attitude that says "cool, let's do it", instead of the "why do that?, that's a silly idea". It's question of how big is your world.

What would I do without Cygwin...

2005-06-13T14:21:00.000-07:00

I have recently moved from a linux desktop onto a windows desktop. When I first started on the linux desktop I missed the familiar functionality in the "dir /s" command. There was no direct equivalent in linux.

I subsequently overcame this so called difficiency by utilising "find . | grep xxx". I also got used to using tail and less as well as vi.

Now that I am on the windows desktop a minor adjustment was required. Fortunately, and this is a big one, cygwin came to my rescue and provided me with all those familiar commands available in my now beloved bash.

It boggles my mind to think how any self respecting software developer committed to excellence can suffer a desktop without something as simple as tail. What is your windows alternative? Notepad! Heaven forbid. There is no out of the box viewer on a windows platform which can monitor a file for changes and render those changes when they happen. Do the microsoft developers deem the facility useful enough? In linux (and cygwin) you have two options; 'tail' for monitoring a file and 'less' for doing both viewing and monitoring (the best of both worlds).

Those guys at Cygwin make my life on a windows platform bearable.

I salute them.

bureaucracy

2005-06-08T09:03:00.000-07:00

The other day I went to the bank in order to have my garage card linked to my debit card instead of to my credit card. Considering I have had a credit card and a garage card for more then 3 years, to any plain man you would think it would simply be the case of, unlink from credit card, link with debit card.

In other words, they would simple cancel the garage card linked with the credit card and issue me with a garage card linked with the debit card...

Why then is it, that in order to acquire a garage card linked to my debit card I did in fact have to apply for a new garage card from scratch! Go figure...

Friends of mine had a similiar issue. They wanted to apply for something at the bank, I can't remember what, and the bank requested that they supply them with bank statements from the last year. To which the obvious reply is, you've got all the records, look it up and approve the application.

No, this is not the manner in which it would be done. Eventually they had to march home, get all the paper work in order and take it down to the bank.

Why is it that when you go to the bank it always seems as if you have to start from the beginning with everything.

The answer lies in usability. Take an average bank employee, the kind who deals with the public. Both the tellers and consultants. They are the "infantry" of the bank. They're the worker bees of the bank, and, just like the rest of the population, they can't even program a VCR. How could you then expect them to understand all the conditions and different ways of applying for a garage card. If the client has an account already then do this... For the sake of the "worker bees", everything is kept simple. If things were more complex, then the average bank employee would be swamped with paper work and would not understand any of the processes. Remember, most of the people in the world do not understand what they're doing, or critical evaluate _why_ they're doing it. They do it because they're told to do it. You average bank consultant is no different.

So the next time you get irritated with bureaucracy, spare a thought for the workers implementing the processes. They have to be simple enough for them to operate.

intro to the fork...

2005-06-07T16:52:00.000-07:00

well, as I mentioned on my other blog (thoughts for life), quite a few weeks ago, that I was going to "fork" the blog. That day has finally arrived, thus we have analysis 102. Okay, okay, cool name you might say, well, obviously, because someone has already acquired the analysis 101 name. Hopefully, being a more advanced subject (102), the analysis may be more advanced.

This blog will be for well, thoughts on practical issues, business, computing etc. Hopefully the content will be interesting for anyone who thinks about the way things are and the way to make things better.