Cat Stevens has a great song called “Rubylove”. I play it from my laptop when some of the guys from the office come in.
Although I dislike mishmashed syntax, I’ve played with OCAML and Scheme over the past few days and have come to the conclusion that Ruby is the best of a bad bunch when it comes to lexical cruft.
Yes, Scheme can start to feel like XML with the brace crazy source, but havn’t scanner techniques come some way since Lisp and 1958? And WTF is “car” and “cdr” supposed to mean (I know it’s from an IBM instruction set but WTF is it doing in a high level language?! “Just write a macro, Josh” I hear you functionoids cry. Bah humbug.)
Unless Jim pairs with me, I’ve decided NOT to do one of our internal exercises in Scheme. Life is too short.
Anyway I’m on a quest to lose the bet Richard Mc and I have against Jon and Roy that in 5 years time 10% of enterprise apps written in Ruby. Time.freeze
Last weekend a group of antipodean ThoughtWorks blokes (plus Suzie) crashed our Melbourne office for the inaugural Service Oriented Systems Practice workshop.
We had a Saturday full of learning and discussion, the morning sessions being mostly introductory technological concerns, and the afternoon tended towards business problems and commercial practicalities.
I myself (as opposed to you myself) gave a spiel on WS-* for Security, which was basically a cut-down rehash of a lecture I gave at Macquarie University a couple of weeks ago to some luckless post-grads.
One of the “pub discussions” that we haven’t had yet was “YAGNI versus SOA”.
If “you ain’t gonna need it” then why would I be doing the extra work to expose functionality for clients I probably don’t know about and probably never will? When they’ve come to understand that SOA isn’t slapping an EAI/ESB into the mix, organisations seem to suddenly become more reluctant about composable applications and lego-like automated business processes. For them, Tomorrow Never Comes, and Pay Now Or Pay More Later is Someone Else’s Problem.
Fortunately, it looks like I’ll able to explore the realities with a client looking to be truly innovative and really take strategic competitive advantage, so we’ll be able to discover whether there really is a trade-off in doing things a bit smarter now for future adaptability – beyond our well-established simple, easily changed code.
Check out this fantastic new book that’ll help drag physical data modelling into the agile arena…
Refactoring Databases: Evolutionary Database Design by Scott Ambler and Pramod Sadalage, my fellow ThoughtWorker.
No secret that I reckon it’s the best book out at the moment, not just because I got a mention in the acknowledgements 
