Aussies = World Championship Whingers

We Aussies like to make a big deal about how well we do in the world sporting arena. Out media loves the line that we "punch above our weight".

Well, here's another world title Aussies, in particular our high-quality commercial media, can surely claim: World Championship Whingers!

As everyone is (or at least should be) aware, world oil prices have been at record highs lately. This is translating to record high prices at the petrol station. Of course, this is a bad thing for the average consumer and transport worker. But the way the media is bleating, it seems that the Australian government can actually do something about the problem. It's an easy way for them to show how much they're supporting the "Aussie battler".

But, in fact, they're just using this as a way to drum up patronage. They don't bother taking the time to explain the often complicated reasons for the price rise, as more serious media organisations attempt to do. For example:
"Who knows why oil prices are so high?" [BBC]

They also conveniently neglect to mention that Australians tend to pay less for petrol than many other industrialised nations:
Average gasoline prices around the world [Wikipedia]

For example (as at May 2008), Aussies pay on average US$1.48 per litre, while western Europeans pay between US$1.88 and US$2.74 per litre!

Given this is an Olympic year, I propose a new event: Whinging. The Australian media would surely give the Poms a run for their money in that category.

Mobile Phone Blues, Episodes 451 and 452

Last week, before recharging my mobile phone (A Sony Ericsson 310), I notice the battery had become rather swollen. Since the phone was getting on a bit (I got it in mid-2003) I decided to get a replacement battery and not to risk leaking, a fire or even an explosion.

This lead to a series of disappointments (not surprising since I've been generally disappointed by my phone, which I'll identify shortly). First, finding someone in Adelaide that sells replacement batteries for Sony Ericsson phones is not easy. Next, when I found a place stocking batteries for my phone, the price was $40! Each! Yes, I know there are places online that provide batteries for much less, but I'm a bricks-and-mortar kind of shopper when it comes to electronics.

Ok, did I want to spend $40 on a new battery for a phone I'm not overly happy with (Plan A)? Or should I buy a brand new phone (Plan B)?

Before discussing the options, I'll list the grievances I have with my current phone:
* Loooong startup time
* Silly joystick navigation
* Unresponsive user interface
* Battery compartment opens too easily when phone falls

I had hoped that getting a new phone would at least solve some of these issues. So Plan B looked like a goer, until I actually started shopping around. This triggered another series of disappointments ...
1. Mobile phone salespeople are pushy, and want to sell you things you don't want
2. There are so many models to choose from
3. Not all vendors stock all the models
4. Phones come with all sorts of stuff that I don't want: cameras, radios, GPS, younameit
5. Basic phones exist but are often tied to plans (which are confusing)
6. Generally buying phones outright is still too expensive
7. Most importantly, you don't get the opportunity to try out a phone's user interface before you buy it

The last point was the main source of disappointment with my current phone. Had I been able to use it beforehand I would probably have chosen another model.

Some people think all this choice is great for consumers. But I would argue that is not the case. Anyone who has read "The Paradox of Choice: Why More Is Less" by Barry Schwartz, will be well aware of the problems with too much choice. I've ranted about this before in "Too Much Choice Considered Harmful" and written about the book in another blog, so I won't repeat myself here.

Another nagging concern is that all this "choice" is illusory because vendors and telcos seem to select particular combinations of plans and models, making it difficult to compare. Looks like there are opportunities for cartel-like behaviour to me.

So, after pounding the concrete for a few days, and getting increasingly frustrated with the ordeal of buying a new phone, I decided to go for Plan A. I bought a replacement battery for my existing phone. I resented having to pay such an an exorbitant price, but at least ...
* I won't risk the "buyer's remorse" of getting something that fails to satisfy
* I won't have been responsible for the waste caused by manufacturing a brand new phone
* I save some money, at least in the short term

I'll probably get a new phone eventually, but at least I will have had time to prepare a little in advance. I can ask to try out the user interfaces of other people's phones. Technology can only improve (right?), and who knows, Apple may release an iPhone mini in Australia by then :)

Finally, some advice: Check your mobile phone battery often before you recharge it.

Too Much Choice Considered Harmful

... or: Why I Ditched Java and Switched to Ruby on Rails.

This post is a case study which supports the notion that too much choice is actually a Bad Thing. I've recently read a book that explores the topic in some detail, The Paradox of Choice: Why More Is Less by Barry Schwartz.

Some background to start with. I've been developing Java-based web applications since 1997. In 2000 I started dabbling with servlets and even wrote some introductory papers for my colleagues at work.

The first major web application I developed was for a startup called SupporterZone. At the time (early 2000) developers were basically left with the task of coding to the raw Java Servlet specification. To deal with some of the basic plumbing I wrote some classes to help abstract over the basic Servlet API. More competent people than myself were doing the same and Java "web frameworks" began to emerge to help make web development less painful.

In late 2000 when I was given the task of building web-based front-ends for database administration and reporting, I began investigating some of the emerging web frameworks. An Apache Jakarta open-source project, Struts, looked promising, and was getting favourable reviews on various mailing lists.

Struts served me well for the next few web applications I worked on from 2001 to 2003: extensions to SupporterZone, a brand new online classifieds site called Adengine, and a Management Programme Reporting tool for a State Government Department. But for most of 2003 and 2004 I worked on a popular State Government web application called PropertyAssist. The application dates back to the early days of Java Servlets. It sort of uses a Model 2 architecture, but by way of a homegrown web framework. So over this period I sort of lost touch with all the new Java web frameworks that were coming onto the scene.

In early 2005 I started working for a new client. They were developing a greenfields web application to manage their customer information system. I was one of several contractors in the newly-formed team. There was obviously some discussion about the architecture of the new system, in particular which Java frameworks would be used in the 3-tier application. We needed a data persistence API, and the choice came down to Hibernate or Enterprise Java Beans (EJB), with Hibernate selected. For the service layer, Spring seemed like a logical choice since it can play nicely with everything else. However the web layer proved much more contentious. Tapestry, another Apache Jakarta open-source project, was chosen. I had a brief look at Tapestry and found it quite strange. It had a reputation for a very steep learning curve, mainly due to its attempt to replace the standard request/response approach to web apps with a component model, similar to desktop Java Apps written using Swing. I had a look at some articles comparing the various web frameworks, and while Tapestry had a devoted following, it was nowhere near as widely used as Struts. However the other contractors had a lot of experience with Java Swing (a GUI API) and they liked Tapestry. They were able to quickly demonstrate a basic sample application that used the proposed frameworks. I considered demonstrating a sample application using Struts, but decided against it because Struts would have been dismissed as too "old-school" by the other contractors. I also briefly thought about trying some of the other web frameworks: Java Server Faces (JSF), WebWork, Spring MVC, Cocoon etc. But to be frank I did not have the time to devote to the task (I was only a part-timer, with responsibilities outside of work preventing extra-curricular activities). There are just too many Java web frameworks to look at, and not enough time. Just reading about all the frameworks made my head spin. It looks like I'm not alone in my disillusionment with the situation:

• What Web Application framework should you use?
  "Not excited about any Java web application framework these days? Join the club."
• RE: What Web Application framework should you use?
• Why are there so many Java frameworks for Web development?
  

In mid 2005 left that job when I got the opportunity to return to working on PropertyAssist. I enjoyed not having to think too much about what web framework to use, and could focus on just doing the work.

However the issue of choosing a web framework reared its ugly head again a few months ago when I was asked to develop a new web-based application for a private company. Time was of the essence, and I simply did not have the luxury of evaluating all the open-source Java frameworks. So I did a semi-courageous thing: I eliminated Java as the language technology for delivering the application. Another option was to use PHP, and in fact there had been an attempt to build a PHP-based application internally within the organisation. But when I looked for web frameworks in the PHP world I found the same problem: too much choice! (e.g. look at this list of PHP MVC Frameworks). Therefore PHP was ruled out too.

The only other contenders that I considered were my two favourite scripting languages de jour: Python and Ruby. Last year I had written some Python scripts to manage my web site, and I liked the language. But unfortunately I hadn't worked with any of the Python web frameworks, of which there are a few. Ruby is the other scripting language I've been following in the last few years. And I've been tracking the buzz around Rails, a web framework for the Ruby language. Now, I've been in the software development game for a while: 9 years professionally and since 1984 as a hobbyist. There's a lot of hype in the industry, and I know there is No Silver Bullet, so I approached Ruby on Rails with cautious optimism. My previous Ruby experience is only writing a handful of simple scripts, so writing a reasonably-sized web application from scratch in Ruby would be a big step up. Initial experimentation writing a basic sample application proved promising, both in ease of development and in the capabilities of the technology. So I felt confident enough to propose developing the new system using Ruby on Rails. Fortunately the client was willing to use any technology, providing I delivered. Let me say this: it was probably the most couragious decision I've ever made regarding technology selection on a professional project, and I have absolutely no regrets. In about 100 hours I built a web application managing over 30 database tables, some of which were quite complex. Remember also that I was learning both Ruby and Rails while I was working on the project. And I actually enjoyed myself. Ruby is a wonderfully-expressive language. I wouldn't say it's "the best", but I've used quite a few and it's right up there. And Rails is the Real Deal when it comes to building web front-ends for databases. The framework lets you focus on the problem being solved, allowing time to be spent on the "bells and whistles" that make the customer smile. Admittedly I was able to design the database tables from scratch (albeit modelled on the Access database tables the new system would replace). But legacy support in Rails is being constantly improved so that criticism is becoming less relevant.

So, in conclusion, if you're a jaded Java web developer and need to develop a web app real fast, consider Ruby on Rails. I'm not suggesting that it's a Silver Bullet. Nor am I saying that it is suitable for all web applications. But it does represent the state of the art for developing database-backed web applications. It might just open your eyes.

Expensive Big Screen TVs - Why bother?

Like a lot of people, I watch TV. And I enjoy watching movies on DVD. But I don't see how I could justify spending over $1000 on a television set, let alone the multiple thousands that the latest whiz-bang, plasma/LCD/rear-projection big-screen sets sell for.

I hate to sound self-righteous, but if I need a new set, I'd rather spend under $1000 on a modest, "old-fashioned" tube set, than fork out upwards of $8000 on the latest and greatest. I could spend the money saved on a brand-new Apple PowerBook, and have more than enough money left over to buy a 60GB iPod. At least I could use the PowerBook to exercise my creativity, and even earn money.

It reminds me of the observation that people spend lots of money that they don't have, on things they don't need, to impress people they don't like.