October 2003 Archives

The outsourcing discussion continues. The subject came up on the ChAD mailing list.

Initially it looked like a cakewalk to get ColdFusion MX to work with the Oracle thin JDBC driver. Macromedia even has a technote that tells you how to do it. All went smoothly until I tried to update a value in the database. That caused it to hang.

Thus started a search through the web for similar tales. Many places suggest doing a stack trace using kill -3 (or kill -QUIT, which is the same thing). This did not produce the expected stack trace . Maybe JRun disables that feature.

Next step was to try the sledgehammer. kill -BUS on the process hogging nearly 100% of CPU. This resulted in log file being written (hs_err_pid11111.log) with lots of information but no stack trace. All I could see was the class where it was hanging: coldfusion.sql.Executive.getRowSet. Damn!

A bit of thought led me to wonder if there might be a newer version of the Oracle driver. I was using the 8.1.7 driver, good old classes12.zip. According to Oracle, this is intended for version 1.2. In other words it's ancient. ColdFusion MX 6.1 runs on 1.4.2, in other words something pretty current. A bit of investigation on Oracle's Java Center turned up Oracle9i Release 2 JDBC drivers. A quick look at the release notes told me they are intended for 1.4.

After a download, an upload and a copy, I had ojdbc14.jar in the class path and I restarted the server. Hey presto, everything was working again.

ColdFusion MX Standard Edition doesn't support Oracle directly. It is, however, somewhere between $3,500 and $4,000 cheaper than the the Enterprise Edition, which does.

One of the great practices of agile programming is the use of unit tests, especially as a scaffold upon which solid code can be written. Laurent Bossavit has written about how life was before: we used to spend much more time in the debugger.

On my latest project, I've been working on a web site written in ColdFusion. First, let me mention the advantages of ColdFusion over something like J2EE.

1. It is easy to learn, even for people with minimal programming experience. (The HTML-like syntax seems designed to appeal to people who are more comfortable with tags than with traditional code.
2. It takes takes fewer hours, billable or otherwise, to produce a working web site

ColdFusion is very page centric. Typically, you'll find a mixture of code, HTML and SQL all in one place, on every page. There is no separation of view, model and controller. There are no units that can meaningfully be tested on their own.

More recent versions of ColdFusion do have support for a more object-oriented approach. Macromedia touts CFCs. There is at least one reasonably sophisticated framework based on CFCs. However, that's not the way most existing ColdFusion code is written.

Does it make sense to try to use automated testing at all? Rod Johnson's J2EE Design and Development (an book I've mentioned before and don't mind recommending again) has some relevant thoughts. He recommends the HttpUnit class library as an excellent, intuitive way of implementing web-tier acceptance tests using JUnit.

The HttpUnit approach is essentially white-box acceptance testing. It has the advantage that we test our application exactly as it will be deployed in production, running on the production server. It's also easy and intuitive to write test cases. The drawback is that screen scraping can be vulnerable to changes in an application's look and feel that don't reflect changes in functionality (a frequent occurence).

HttpUnit does do a lot of the donkey work. It a imitates a web browser fairly well: it supports cookies, frames and even (to a limited extent) JavaScript. Another project, jWebUnit, builds on top of HttpUnit. To quote from the site, The simple navigation methods and ready-to-use assertions allow for more rapid test creation than using only JUnit and HttpUnit. In other words, jWebUnit lets you write the same tests using fewer lines of code.

I can use jWebUnit to write tests for the site. I can run the tests in an automated fashion. I can even write a launch-and-forget ant script. Now I need to see how effective a practice this is and what I learn as a result.

A discussion on the Chicago Agile Developers' mailing list on the subject of installers turned to configuration and how often it is needed.

After a fairly long summer hiatus, ChAD finally had a meeting; the subject was "Comparing RUP, XP, and Scrum: Mixing a Process Cocktail for Your Team". Our guest speaker was Dan Rawsthorne.