This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: My Agile DSL Development in Ruby Presentation at InfoQ Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

My presentation from JAOO last year in the neat InfoQ format, which shows a small video window above the actual slides from the talk. Lots of practical information about authoring DSL-ish code in Ruby, as well as actual project real-life experience reports that led to the concept of Business Natural Languages.

My favorite part of this presentation is when I describe how to exploit executable code in the database to do an end-around restrictive IT deployment rules.

Another way that you can use this technique is not simply by reading in files and executing them in a sandbox, you can store them in a database, which is what we ended up doing with that client... they had many, many different partners. The funny thing is that, essentially what they brought us in to do was, to override the fact that internally they had imposed such strict deployment restrictions. So they could only release new code once a month. And that release had to go through a battery of 2 to 3 weeks of acceptance and integration tests and things like that, but the bank is rolling on sometimes 5, 10, 20 partners a month. So, as you can imagine, it's actually very difficult to make that work! They said "we need a more flexible system."

Well, the code I showed you before (representing the contract) is executable code, but it's stored in the database, so it's funny cause I actually had mixed feelings about this at times... It's a loophole that you're exploiting! To the IT people that don't want you releasing code "it's data"... [chuckle] You get what I'm saying? We put it through quality assurance at the application level by having approval workflows and things like that, but after we were done, rolling out new application code to the production system, was a matter of the finance guy, as an approver clicking a link to say "yes, this goes in the monthly run."

Now that's executable code stored in the database that is actually part of the production run. We've circumvented, done an end-around some of those IT restrictions that were hurting their business!

Ideally, we know that in situations like the one I describe above, the business and IT managers could put their heads together and figure out a non-technical solution to the problem. But sometimes, those two parts of the company are so at odds with each other that reaching compromises is impossible. Disfunctional, yes... but then again that's one reason that I got so disenchanted with enterprise projects -- too much bullshit policies and stupid politics.