Coding Style is more important than you think!

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.

Powered by ScribeFire.

The value of information

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

Powered by ScribeFire.

The major advantage Open Source has...

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.

Powered by ScribeFire.

Hudson Unleashed...

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!

Powered by ScribeFire.

Hudson is cool...

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

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

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

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

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

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

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.

powered by performancing firefox

Welcome to this new funky blogging tool...

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!

powered by performancing firefox

Why I hate frameworks...

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?

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

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!

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?

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

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

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.
1. Build the remote interface, build the remote implementation of the interface
2. Build the Asynchronous remote interface - contains every method in the synchronous interface but with call back reference added to each call.
3. The process of calling is…
1. Instantiate the remote interface (on the client).
2. Specify the location of the "server" - in this case it is a servlet which you call.
3. 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!

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