Tomas Varsavsky

Brittle Selenium test suites are a common problem for projects with a significant number of acceptance tests. In the past, Selenese made it really hard to write well factored Selenium tests. The best one could do was write Selenium tests in JSPs and use JSP includes to avoid repetition of command chains (e.g. include Login.jsp).

Selenium RC gives us the ability to leverage the richness of the language to write well factored tests. One pattern that can help here is Page Models. These are essentially an abstraction of the pages in the application using classes. Taking Google as a sample application, we could write simple page models for the home and search results pages.

The page models provide access to page elements and are linked through navigation actions. We can use the page models to write tests that are more intentional and don’t interact with Selenium directly.

For more than one test class we would probably go a bit further and move the setUp and tearDown methods to a common parent or utility class. We could even make the page models reference the Selenium object directly rather than passing it around all the time.

With this approach the application and page models can be changed freely without having an impact on individual tests.

This article on InfoQ summarises the way I feel about code reuse.

I’ve worked for a few organisations that have fallen for the code reuse trap. It goes something like this. A smart bunch of well meaning developers write an application. Along their travels, they realise that some of the code they are writing is generic enough to be of use to other projects and thus the common.jar is born (or worse yet, framework.jar). The package ends up being a bucket for common services (e.g. EmailService, AuthenticationService), base classes (e.g. AbstractDomainObject, BaseHibernateDAO), utility classes (e.g. StringUtils, FileUtils) and configuration (e.g. log4j.properties). The project finishes and everyone is happy about having created some reusable code.

Sometime later, along comes another bunch of developers to work on the next great killer application. They notice all the great work done by the first bunch and go about importing common.jar into their project. However, they soon realise that EmailService is missing some features that they need, AbstractHibernateDAO doesn’t work with the new version of Hibernate, etc. So they go about enhancing and adding to common.jar, while carefully managing the dependencies on the first application to make sure they haven’t accientally broken it.

Several months, years and projects later common.jar has grown out of control. There are now 10 projects dependent on it. Making any change to it is a bit of a nightmare, requiring regression testing and sometimes changes to the dependent projects. If projects are running in parallel, common.jar becomes the battleground of merge conflicts. Fear grows and each project now starts avoiding changes to common.jar, which can lead to interesting hacks and workarounds.

Analysis at this point would probably show that any one of the 10 projects only uses about 10% of the capabilities provided by common.jar so the value of the reusable component has been diluted and the pain of managing the dependencies far outweigh any benefit provided by reuse.

So, be wary of code reuse. The cost of building several EmailServices pales into insignificance when compared to inefficiencies introduced by having to manage complex dependencies.

A few weeks ago I did some work for a client that is about to re-platform a public facing website written in Forte 4GL to Java. Forte itself is not the problem, as far as I can tell the technology is sound. Forte is a legacy platform that is no longer supported by Sun. The client is finding it impossible to hire people that have the required skills and want to work on Forte applications. The business wants to make some significant upgrades to the application. Sensibly, the client does not want to invest any more money into a legacy platform so they have kicked off the effort to re-platform it to Java at a considerable cost.

So far, this is an all too common story. There are legacy platforms and applications everywhere. What really surprised me is that the current application is only 4-5 years old, which tells me that Forte went from mainstream to legacy in an amazingly short time.

All this is interesting background in the context of what’s happening with Ruby at the moment. The popularity of Ruby is increasing all the time and we’re finding that corporate clients are starting to choose Ruby over Java more and more. Is this a gamble? Does anyone know where Ruby will be in 5 years time? 10 years? Will the current mob of smart people gathered around Ruby have moved on to the Next Great New Language? I can understand why CIOs are cautious of Ruby, I would be too.

One important consideration is the part played by the open source and Ruby communities. Vendor support is something that corporates traditionally appreciate, it gives them a warm fuzzy reassuring feeling. But in this case Sun bought out Forte and essentially killed it to neutralise a rival to J2EE. Thanks vendor! Ruby is not owned by anyone so the risk of it being exterminated is minimised. If Ruby dies it will be due to natural causes.

Java is an interesting case study because it managed to strike a nice balance between vendor support and a strong community. In the initial stages Sun invested a lot of effort developing, promoting and selling Java despite it’s well documented shortcomings. Sometime in the late 90’s the community around Java really took over and was responsible for making Java mainstream. Java is now owned by the community, just like Ruby.

The case for Ruby in the enterprise could certainly benefit from some vendor support. Efforts to deploy Ruby applications on accepted enterprise platforms will also be key (e.g. JRuby, IronRuby).

My wife and I are expecting a baby in January. As part of the preparation and research we’ve come across far too much information and we’re trying to distil the important stuff from the noise. Something that has come totally out of left field is the choice on want to do with the cord blood during and after the birth. Cord blood is valuable because it is very rich in the best kind of stem cells.

Putting aside the whole stem cell research controversy (which relates more to acquiring stem cells from a destruction of a human embryo and/or therapeutic cloning), we have a real practical choice to make. The options are:

• Do nothing - The cord blood will be discarded as medical waste.
• Donate it to a public cord blood bank - The cord blood may be used for transplants, we would have no control over it.
• Store it in a private cord blood bank - There are private companies that for about AU$3000-5000 will store the cord blood for our own exclusive use.

There seems to be a great deal of conflicting information about. Private cord blood banks are in the business of selling storage and, not surprisingly, their brochures prey on our natural fear of the unknown to sell a kind of insurance. From the information they give it’s very hard to tell exactly in what situation the cord blood would be life saving. Everyone knows that stem cell research is hot right now so they rely on unidentified future medical advances to clinch the deal.

The public cord blood bank has a different view:

“It is the opinion of the public cord blood banks that there may not be a role for this method of storage as the cord blood is unlikely to be used for transplantation for leukaemias, cancer and bone marrow failure. The stored cord blood cannot be used to treat genetic disease, as the cord blood would also be affected. The most common reason for transplantation in childhood is for leukaemia. Even if the donor developed leukaemia and required a transplant would their cord blood be used to treat themselves? The answer is ‘no’. The least successful form of transplant is from the patient’s own cord blood or bone marrow. If the leukaemia develops in early childhood, the cord blood may well contain the propensity to develop leukaemia. The most appropriate source of stem cells is from another person whether it is another family member or an anonymous stem cell donor. The chance of finding a match within your family is about 30%, the chance of finding a suitable unrelated cord blood donor is over 80%.”

— From AusCord brochure

Of course, the two parties are putting their spin on their conflicting interests. Who’s right?

I’m starting a blog.

*deep breath*

I’m not sure why exactly. Do I have anything of importance to say? Will anyone read it? Does it matter?

From a personal point of view, I have one loose goal. I think about a lot of stuff, all the time. These thoughts seldom seem to reach any kind of meaningful conclusion mostly due to my short attention span and total inability to focus on anything that doesn’t have a hard target associated with it. I’m a very goal driven kind of person. Give me a deadline and I’ll deliver every time. Give me an open road and I’ll fluff about, getting nowhere. I’m hoping that the pressure of having to write stuff down and publishing it to the world for scrutiny will give me the motivation I need to drive some of my thoughts to meaningful conclusions.

On the other side of the coin, I have no desire to author one of ‘those blogs’. You know, the kind where people write random thoughts about random meaningless stuff. I’m sure no one cares what movie I saw on the weekend and what I thought of it. I’ll try to keep that kind of post to a minimum. Also, I won’t let the pressure of a blog that hasn’t had an update for a while push me into writing dribble. If it’s quiet for a while it’s because I have nothing significant to say. Let me know if this turns into one of ‘those blogs’, I’ll pull the pin immediately.

So, a little about myself. I’m a software engineer. I work for an IT consultancy called ThoughtWorks in Melbourne, Australia. They call me a consultant, but just between you and me, I prefer to think of myself as an engineer. My daily work is mostly around scoping and building business applications for clients which means that I get to see how a lot of different organisations go about building their software. I’m really interested in agile (not Agile) software development principles and practices. I think of myself as a generalist and have worked with many technologies but if you pin me down I’ll admit to being a specialist in Java.

Ok, that’s the formalities done. Let’s get this show on the road an and see where it gets us.

Oh, by the way, I saw Transformers last week. Best movie ever. 5 stars. Oops… damn!