Anyone got a pencil?

I'm not normally one for posting web sites on here, but I like this...

Pencil Carvings
(especially this one, very mechanical. I likey)

A fine example of what you can do with a bit of talent, an idea and a lot of patience!

BobaPhotoBlog

Picasa and Hello are now well and truly installed on my machine, increasing the amount of free software yet again. Picasa is pretty cool and I reckon I'm going to get used to having that installed pretty quickly. But more importantly, Hello means that I can pretty easily put photos onto a blog. So bring on BobaPhotoBlog... it'll get the odd photo put up every now and again as I see fit. I may get round to putting some text on camera settings up, but more likely I'll just forget!

I'll be testing out its integration with Gmail soon enough...

Technorati Tags: picasa, hello, photography, blog, gmail

DBA or not DBA

For some reason this industry seems to be confused about the role of the DBA.
It has always been my opinion, and the opinion of every Oracle based software house I've worked at that the DBA's roles are simple to define.

The DBA is responsible for:

• Ensuring the continued running of all databases under their supervision.


• Minimising the impact / time of any maintenance induced downtime of those databases.


• Minimising the risk of databases becoming unavailable for unplanned reasons.


• Minimising the impact / time of any unplanned downtime.

You may notice that I don't include in that list anything to do with development.

The DBA is not, and should not be regarded as a developer. That's not to say that any given DBA would not make a great developer. Many DBAs I've met would make great developers. Rather it's that the two roles are intrinsically different. You'll notice that my definition of the DBA roles are very similar to those of a second or third-line support team member. Most organisations involved in software that are large enough to have a dedicated support team would split the roles of support and development for everything other than the database. So why should the DBA and development roles be treated any differently?

Make a DBA a developer and you'll cost yourself development time whilst that DBA fixes issues on live systems that simply can't wait...

Technorati Tags: Oracle, DBA, software+development

Sentence of the day

Overheard in the kitchen:

The only thing that hasn't changed is that things are changing

Back to Oracle

Category: UpgradingOracleDatabases

In Extreme Programming Explained (2nd edition), Kent Beck references Pramod Sadalage's elegant incremental design strategy:

• Start with an empty database.


• Add all the tables and columns with automated scripts that also migrate any existing data as necessary.


• Sequentially number the scripts so a database at any earlier stage can be brought up to any later stage by running the scripts.

This idea is extremely (pun intended) similar to my own thoughts on the same problem, though I think it misses a couple of points. I'd prefer to see it written more like:

• Start with an empty database.


• Add all the tables and columns you need for the current piece of work with automated scripts that also migrate any existing data as necessary.


• Surround each script in tests that cover the pre and post conditions. The pre conditions cover your assumptions about the database required for the script to run, the post conditions cover the requirements for regarding the script as 'complete'


• Sequentially number the scripts so a database at any earlier stage can be brought up to any later stage by running the scripts.


• Make sure a failure in any script (including its pre or post) stops the rest of the patches from running


• Make sure you can run all the patches from a single command

If the system you're developing sits on top of a legacy system then your build will start with an import of a set of live data into an empty schema, the upgrade as covered above and then the tests for the rest of the application can run against a system that closely mirrors the target environment.
If the live data is so huge it takes to long to do the upgrade as part of the regular build you've got three options:

• Tune the upgrade so that it is quick enough


• Reduce the set of data you import so you have the right texture of data on a smaller scale


• Run the full import and upgrade in a less frequent build

Ok, ok, so it might not be so elegant as Pramod's way of putting it, but it's complete...

Aside: If you've not read XP Explained, read it NOW. If you've read the first edition, but not the second, read the second edition NOW. If you've read both, think about reading them both again!

Technorati Tags: oracle, extreme+programming, Kent+Beck, Pramod+Sadalage