Rails? Access? Isn't that confusing the cutting edge with the office drones?
No, actually - it's not.
Up until Rails, Microsoft Access had been my preferred tool for creating applications centered on a relational database. The first time I got to work with Access, in 1994, I was overwhelmed and amazed.
If I needed to add a table, I could do it, easily. If I needed to modify a table, I could do it, easily. Access supported lots of different kinds of joins, letting me set it and forget it, unless I got something wrong. And while the interfaces generated by the wizards weren't entirely attractive, they were a useful base to start from, tweakable in infinite directions.
All these years later, Rails offers very similar functionality: tweakable database structures, interface generation, validation rules under the hood, and a similarly iterative design process. Rails uses the Web rather than Windows as its primary interface, and it certainly offers more flexibility and power than anyone gave Access credit for - but the problem domain is similar, and the solutions aren't that incredibly different.
In a lot of ways, I look at Rails as what Access might have been had Microsoft told its Access team to migrate to the Web. Unthinkable, I know. But in lots of ways, both are frameworks with databases at their core, building out toward interfaces. Rails learned more about loose coupling, multiuser support, behaving like a service, and certainly scaling - all things I dreamed of long ago, but never got.
So why isn't there more talk about the similarities?
The barriers between the groups are pretty clear. The Rails community seems reliably uninterested in Windows for the most part, and the Access community has always been trapped in Windows, as Microsoft never released it for other platforms. I can find some talk on the Web about transitioning, but not very much. The costs of shifting from VB to Ruby aren't small, and there's a lot of culture shock to be had all around.
The other barrier, though, reflects the one place where I think Access has an advantage, even after a decade of slow change. While Access does visible and invisible code generation much like Rails, exposing that code as VB and declarative properties, it does as much as possible through the comfort of a GUI. The general practice set by Access's creators from the beginning was to do as much as possible through visual interfaces rather than through code. In that, perhaps more than anything else, they struck a balance that made Access approachable while still letting it be powerful.
Rails culture runs the other direction. GUIs are the end product, but the code is pretty much all plain text. There are some tools for creating Rails forms out there, but an amazing number of developers work through text editors. Even Heroku Garden's web-based development environment basically provides a text editor and command line through a web interface. The command line is ubiquitous and largely unavoidable, and practically all Rails documentation assumes you are using it.
Those barriers leave me stuck dreaming. I'm now as comfortable working in Rails as I ever was in Access, but there aren't a lot of direct paths from here to there. I'd love to see someone write an interface for Rails interface development that feels like Access, but there's no question it would be a difficult challenge.
Despite all that, though, I think Rails may have a bright future, eventually, among the same kinds of people who've built Access databases over time. There are an almost infinite number of data-centric projects that are too big for a spreadsheet, need to involve multiple people, and accumulate data over time. Hopefully more of those folks will - over time - find Rails a comfortable place to work. Rails can address ordinary tasks elegantly.