There was no obvious cause for this, the install was a fresh one on a newly set up machine.   I reinstalled the JDK, and still the same error.  A bit of reading suggested there may be issues with an ini file related to eclipse.  I found the CAWADesktopClient.ini file and had a look.  The file looked a bit messed up, with lines being broken in odd places.

After making it look like this…

…everything is working as it should be.

Hope this helps someone.

I’ll update once I’ve decided, but feel free to offer your favourites from the Anagram server, here and here.

It’s cheap both in dollars (free) and time (less than 15 minutes if you’re quick).

You can view the current PD at http://www.transurban.com.au/532.htm.  I haven’t had time to update it (it was created prior to me starting here), but I think it’s  a reasonable statement of the technologies involved.  If you do have any questions before applying, feel free to contact me via the ‘About’ page on this site.

I can’t believe it’s been as long as it has since I last posted.  This has mostly been because I’ve been busy preparing to become a dad.  I’m a dad as of two weeks ago, and have a new job, so as things settle down I hope to get through my backlog of posts, mostly on technical topics and tools.

I found Alister’s approach solutions interesting, because as my automation usually models business/user goals and/or domain features/concepts,  I don’t often have my own page abstraction.  See http://gojko.net/2009/10/06/putting-selenium-in-the-right-place/ for an example of the approach I’m thinking of.

At the top level might be something like:


google=Google.new
google.search(search_phrase)


At the next level down, I potentially want to be independent of the user interface, so it doesn’t make sense to organise around page components.  I might have something like:


def search(search_phrase)
enter_search(search_phrase)
submit_search
....
end


When we get to the third (task) level, this is still at a user or business activity level, so the page model still doesn’t make sense for me.  I’ll just use the browser driver directly (or my own driver abstraction):


def submit_search
Driver.button(:value, => "Google Search").click
end


Yes, I could have another level here such as:


def submit_search
GoogleHomepage.search_button.click
end


In most cases though, the task-level UI element has a single purpose, so there’s not much of an issue with violating DRY. I also try to keep the automation stack as small as possible, so can tolerate a little bit of duplication. Regardless, it’s easily factored out into a new method if duplication becomes an issue because methods are common to the domain.

I’ve seen some frameworks that have a really abstract UI driver at the next level (so that they could drive a rich client app, a mobile app and a web app all using the same methods), but I’ve never needed to do that.

I favour a business/domain oriented approach because at the business level, the goals and activities don’t change that much (and I tend to let the automation lag behind my understanding of the problem).  It also encourages me to pay attention to the things that matter and be less implementation-focused.

In that spirit, take the time to read about my favourite related bug story at snopes.com. From some relatively recent experience, I’m pretty sure similar bugs are still being creating around the world in new traffic systems.

class Sequel::Dataset
  alias :size :count
end

This adds the necessary ’size’ method to Sequel’s dataset and everything’s happy.