OSCON 2006 Day 4

The keynotes were better this morning, especially Robert Lefkowitz (always entertaining) and Stephen O'Grady (of RedMonk).

First session of the day for me was How Database Engines Work by D. Richard Hipp who developed SQLite. I'd hoped for some ideas to improve Suneido's database, but it was pretty basic. Actually, one of the more interesting aspects of the session was that there were developers from MySQL and PostgreSQL in the audience who contributed. In fact, the only idea for an improvement came from a question from the audience. It sounds like SQLite's query optimization is fairly basic, Suneido seemed to compare quite well - it does everything that was talked about. It did make me think that I should probably document the query optimization that Suneido does.

Next I went to Building Successful Commercial Open Source Projects by Jorg Janke of Compiere - an open source ERP system. Like my company's vertical software, Compiere has integrated accounting. Also like our software, they support only a single version, requiring users to update if they want fixes and improvements. Unlike Compiere, we haven't open sourced our software (only Suneido, the underlying development tools). I had to laugh/groan when he recommended staying away from risky, regulated areas like payroll. (We have payroll, since our customers want it, but it is scary and a hassle.)

After lunch I went to Building Domain-specific Languages in Ruby by Neal Ford of Thoughtworks. I really admire Martin Fowler's work and he's with Thoughworks so I decided to check out this session. It was ok, but nothing really new to me. One nice thing about using Ruby for DSL's is that it doesn't require parenthesis around function call arguments. e.g. you can write "print 123" instead of having to write "print(123)". I wonder how hard it would be to allow this in Suneido? We normally do DSL's in Suneido as object constants or class constants but the drawback to this is that it doesn't allow variables or control structures. Ruby's approach of using executable expressions is more flexible in this respect.

My next choice was User Experience, Pain Free by Amy Hoy, a pretty good talk. One of her recommendations, which I hadn't heard before, was to avoid saying "this will let the user do ..." and instead say "this will help the user do ...". At first this seemed like nit-picking, but the more I thought about it, the more it made sense. When we add a feature that "lets" the user do something it's like we're doing them a favor, and whatever we give them they better appreciate it. On the other hand, if we say we're going to "help" them do something, then suddenly it's up to us to do a good job or else we've failed.

I was tempted to go to Amy's next talk on user interface design but I decided to aim for variety (it's the spice of life, after all!) and went to Concurrency Control in Relational Databases by Arjen Lentz of MySQL. The actual material didn't contain much new to me, but it was interesting to hear how different databases (MySQL, PostgreSQL, Oracle, etc.) handle concurrency. Again, I think Suneido compares quite well with the big guys. It always shocks me to hear that most databases default to an isolation level of read commited or repeatable read - levels 2 and 3 (out of 4). The bottom line is that transactions are only partly isolated (you only get some problems!). The reason given for this is performance. But isn't this premature optimization? Is it really too slow otherwise? Wouldn't it be better to default to the highest level and then if it turns out to be too slow, then you could consider "compromises"? Suneido is always level 4 - serializable i.e. totally isolated. So far, for our uses, this isn't "too slow". After all, as the saying goes, if it doesn't have to be "correct", you can make it as fast as you want!