Came across Ruby few years back.. Read a bit but was too busy (as usual) to dwell on it further.

Came across Ruby on Monday and was quite wow-ed. (Apple guys really think different huh? Never really came across a HOW-TO documentation in MOV format! Sweet!). I showed them to some of my J2EE colleagues and based on their scoffing replies, I perhaps should've better showed them this as well.

I've been thinking about process inheritance (or service inheritance, in terms SOA) but also procastinated on reading a white paper on it. When I see Rail's scaffold at work [].. , "hey.. this is it isn't it?"

The process is already written. Pages core to the functionalities already provided. Define your data and specify the process: I'll need to work on the "posts" data, and I need the usual CRUD pages... Viola! List page, edit page, create page.., clicks, SQLs.. all written and all working and all bug free - else, just debug the super-class ya?.. oops I meant super-process. I've now inherited the CRUD process, implemented using my data store, extended with my own customised pages.

So, is process inheritance afterall just defining a base set of navigation framework, and allowing template customisation? To have true hierarchy.. this new process, extended from the base CRUD process, must be allowed to be extended by the platform its written on. I like that.

Perhaps really soon now, we can really have vending machine dispensing processes for anyone to extend - Coins in here, tap tap here.. tap tap there.. -PLONK!- a cdrom falls into the chute below and the programmer happily goes to work..