So, given a fixed set of elements (e.g. navigation choices), there are multiple attributes of simplicity than can be addressed to varying degrees. The success or failure of a design is largely dependent on achieving the right balance among these attributes of simplicity. An infamous example of this was BMW's i-Drive controller, designed to operate a range of automotive systems from a single control. The resulting user experience was confusing and complex as BMW relied too much on mechanical simplicity (a single, clickable rotary control) at the cost of perceptual and cognitive simplicity.

It's an excellent article, go check it out.

Software developers have gotten away with being sloppy because of the abundance and rate of growth of compute cycles. However, the problems of large numbers start to intrude: just as power and heat become factors in the presence of tens of millions of transistors, power and heat become architectural considerations in the presence of teraflops of computation and petraflops of storage.

-- Grady Booch, Power As A Limiting Factor

* Garbo is Aussie slang for a garbage/rubbish/trash/waste collector

Naturally as I began playing with JRuby I wondered about object database options for it. One of the great things about the Java linkup is the wealth of available libraries and products and sure enough I found a number of open source OO database options. GOODS (which I have used with Smalltalk) is an option, but like some others it relies on a bytecode pre-processor, which makes me nervous given how JRuby plays with the bytecode.

Playing with db4o (which has both GPL and commercial licenses) has been pretty successful for the very little time I have invested.

Unsurprisingly I discovered that trying to store a pure Ruby object yielded an ObjectNotStorableException exception. In JRuby extending Java classes is easy. I haven't discovered how to properly extend the constructor, so I ended up with the following class:

require 'java'

class Song < java.lang.Object
  attr_writer :name, :artist, :duration
  
  def to_s
    "Song: #@name--#@artist (#@duration)"
  end
end

include_class 'com.db4o.Db4o'

db = Db4o.openFile("/tmp/test_db")

song = Song.new
song.name = "Bicylops"
song.artist = "Fleck"
song.duration = 260
puts song

db.set(song)

# make an unconstrained template object for QBE
song_proto = Song.new
song_proto.name = ""
song_proto.artist = ""
song_proto.duration = 0

results = db.get(song_proto)

results.each {|s| puts s}

(G) org.jruby.javasupport.proxy.gen.Object$Proxy0

Ruby has no concept of casting or blessing the object into a different class, so I suspect that I'll have to take care of that by wrapping the db4o api with some Java to do the casting.

I can confirm that something like the objects I'm storing are ending up in the database file with the venerable strings command. Surprisingly the database binary file contains strings that look exactly like that generated by to_s. Perhaps it stores a stringified version of each object? Or perhaps to_s is proffered by JRuby as a default serialisation method.

Anyway, as I said I haven't invested much time on this (too busy watching the Monaco F1 right now...) and getting it useable may be a bit of work.

One weird thing is that the first time I run code like the above for a particular database file I get an ObjectNotStorableException exception. The db file is created though, and further runs work as described above.

Whenever an engineer builds something that's over-complicated, that's the mark of an inferior design. Simple is always better.

—Jamie Hyneman, Mythbusters

While you can't really rate Mythbusters for statistical significance, I think Jamie's on the button with this quote.

Share the joy with Jeremy Stell-Smith.

There's a great discussion brewing over at Lars' blog about how to keep in a design frame of mind and not get bogged down in implementation details.

Some good ideas coming out, and some mediocre ones from me as well. Come and join in!

If you're looking for a different kind of beans with a different kind of camping, you might want to check out Big Jim's Camping Beans :)

I love what Thoughtworks Studios have done in Mingle, making it so easy to deploy by using an embedded java database (derby), JRuby and Ruby on Rails.

I also love the concepts why has used in Camping and I figured the three combined would be great for developing small (possibly embedded) websites.

Here's my somewhat ugly bullet point steps to the sample Camping Blog using NetBeans 6.0, JRuby and derby.

• Install NetBeans 6 - M9 is the latest version at the time of writing (caveat emptor - I already logged a few bugs)
  
  
• Unless you have Java 6, copy derbyclient.jar into {Net Beans}/ruby1/jruby-0.9.8/lib
  
  • If you're a Mac, you will find the {Net Beans} directory in "Show Package Contents"/Resources
    
  • You can get derbyclient.jar from your JDK directory if you did a full Java 5 installation, or you can get it in the full derby distribution from db.apache.org/derby
    
  
  
  
• Install the camping gem (NetBeans Tools menu->Ruby Gems->Install New...)
  
  
• Start the derby server in NetBeans (Tools menu->Java DB->Start)
  
  
• Make a new "Ruby Application" project (be sure to call the main file blog.rb instead of main.rb)
  
  
• Paste why's example blog.rb into your blog.rb
  
  
• after the line that says require 'camping/session' add:
  
  gem 'ActiveRecord-JDBC'
  require 'active_record/connection_adapters/jdbc_adapter'
  
  
• Create a file in your home directory called .campingrc with the following:
  
  database:
  adapter: jdbc
  driver: org.apache.derby.jdbc.ClientDriver
  url: jdbc:derby://localhost:1527/sample
  username: app
  password: app
  
  
• In Project Properties->Run, add a configuration called camping, and add the path to the camping startup script into the ruby options field. I added:
  "/Developer/NetBeans 6.0 M9.app/Contents/Resources/NetBeans 6.0 M9/ruby1/jruby-0.9.8/bin/camping", I haven't been able to simplify it with environment variables unfortunately.
  
  
• Click the Run button (or use the Run menu)
  
  
• Point your browser to http://localhost:3301/

And that's all there is to it! Note that instead of bothering to make a new database, I used one of the sample derby databases, but you can administer the derby databases in the Runtime window/tab of NetBeans.

Sources:

JRuby Tutorial - Going Camping
The curse of camping

But the jaw-droppingly cool thing is ... wait for it ... the OS X version is distributed as a shar archive!

If you don't know what a shar archive is, then I you probably weren't a Unix/Internet nerd in the 80s/early 90s (which is probably for the best).

This is a hilarious Saturday Night Live sketch around the whole liquids on planes thing :)

Found via Pensieri di un lunatico minore.

Being native code based on the KDE libraries it's much faster than Java tools (like Argo UML), but that also makes it less portable. I've never seen a workable installation of Umbrello on Windows. There are some partial attempts using KDE 4, and apparently it's possible with Cygwin.

It's pretty easy to install on Mac OS X, as long as you don't mind a bit of commandline work.

First you need Apple's developer tools and X11.app. Then you need an installation of MacPorts which will do most of the hard work for you. There's no port for Umbrello, but it will install the myriad required libraries. Simply run:

and let it do the hard work.The whole process could take a few hours depending on your Mac model.

Now to install Umbrello itself. Download the latest version from http://uml.sourceforge.net/download.php and follow the "Source Code" instructions on http://uml.sourceforge.net/install.php. You will need to specify the qt and jpeg directories and turn off aRts support. If that makes no sense to you, the instructions boil down to:

It shouldn't be too long before we can have a native Umbrello.app. Trolltech has released a MacOS native Qt and it's certainly something that the KDE people are looking at.

Update: Umbrello 1.5.7 is now released - update your download accordingly.

Leopard Update: A kind anonymous poster gives this ./configure line for building in Leopard, but I haven't tried it yet:

But if what you want to do is store and retrieve objects, then an OO database is, at least in some cases, the most appropriate tool. We all love garbage collection in ram (well - I do anyway!), why not let it take care of your persisted objects? And who would say no to the database automatically upgrading accessed objects when your class gets new or different instance variables?

While it's not quite with the theme of the intended use patter of GOODS, I'm going to play with Pogo - a Perl API for GOODS. Unfortunately I don't yet have it compiling on Mac OS X but it compiles fine on my Linux box.

One of the problems with mapping a Perl or Ruby class to an OO database is that we can't reliably introspect the instance variables (let alone their type). I'm not quite sure how to handle that yet - whether there should be an API to make promises about your object. Another problem is that variable types aren't fixed. The biggest of this class of problem is that, especially in Perl, it's not uncommon to be able to use an object or a primitive (string etc.) interchangably eg. you might provide an URL object that can be used like a string in string context, but in reality it's a reference to an object - ideally we'd like the whole object to be stored.

Being more Smalltalk like Ruby may be better suited, but unfortunately there's no Ruby bindings for GOODS and I don't have the time or the in-depth understanding of the Ruby object internals to pull that off right now. There are a few references to a (now defunct) source forge project ruby-goods, but sourceforge's CVS archive shows no files.

I'll keep you posted!

Their product selection is of a similar vein to Top 3 by design (for my Australian readers). Check it out: GENERATE.

In the 2007 netosphere it doesn't get much more good than Joost and guess who is giving away invites?

Well done! Maybe May should feature a "best of TramTown" series :)

They have kept remarkably true to their initial post:

This is a blog where Semi and DB are going to put pointers to things that interest them and may interest others. We expect a bias towards our town, Melbourne, Australia. We expect to see posts about: theatre, audio, politics, motor racing and any other thing that tickles our respective fancies.

That's what's good about aiming low.