This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: Silicon Valley Ruby Conference Highlights 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?)

(Non-blogger) ThoughtWorker Kent Spillner sent a recap of the Silicon Valley Ruby Conference today to one of our internal lists. A couple of items caught my attention as being of interest to my blog readers, so here they are...

Jason Hoffman (CTO of Joyent, the TextDrive people) spoke about scaling Rails. The short answer: you don't scale software, you scale infrastructure. And if you want to talk about scaling software, how about "scaling down," because you can always scale up with more hardware and more bandwidth? Will your app run on a cell phone? That's the fastest growing segment of internet usage, so why don't more people focusing on catering to those needs?

Jason's talk kicked so much ass I can't even begin to summarize it; if you're interested in scaling Rails, or Rails deployment in general, just check out his slides: http://www.scalewithrails.com

Rich Kilmer spoke about a DARPA research project he rescued with the help of Ruby and his ActionStep project (NextStep clone built on top of Flash) -- the mid-air refueling simulation, for those who have seen him give this presentation before. He single-handedly replaced a ~70k line Java "prototype" that had taken three developers eight months to build with ~1.2k lines of Ruby in 2.5 man-weeks (spread out over the course of three months due to other work obligations). [NOTE: Those were the only hard-and-fast numbers from his talk, and are by no means scientific, so please don't jump to any hasty conclusions.]

His main points were that Ruby's dynamism and flexibility allowed him to focus directly on the problem, and not get side-tracked working around the constraints of his tools (right tool for the job, etc.), that Ruby is a great tool for building DSLs, and that a good DSL facilitates rapid delivery and feedback by enabling direct collaboration with domain experts (he spent the first day on the project pairing with the domain expert, writing everything they said in Ruby assuming the DSL already existed, and then spent the remainder of the project back-filling what was needed to make the DSL work and building the UI*). Nothing earthshattering for those of you who think about or work with DSLs, I'm sure, but he backed everything up with concrete examples that helped the audience really get it.

*This is exactly the technique that we're using at my current client and the way that I've been telling people to approach the use of DSLs in Ruby/Rails programming on their own projects. Just capture the requirements for the system in *fake* Ruby code, knowing that it doesn't work *yet* -- your main goal is just to make the code capture the specification of the system in executable form. Then go ahead and implement the underlying code to make your script actually work.