RailsConf 2014 having wrapped up a few weeks ago, now seems like a good time to try and unpack what I saw, heard, and talked to others about. Bear in mind I skipped RailsConf 2013 (but I’ve been to all the others), so I may construe something as new that I simply missed last year.
I’m going to break it down, as is my puzzle-solving wont, by technology and people.
Lots of people are excited about a few central topics.
Service-oriented Architecture. I went to talks about extracting services, designing services, implementing authentication/authorization across services, and how to write the client side of your various services. The talks felt like they were past the “look at this novel thing!” phase and into the “well here’s the nitty gritty” phase. I didn’t happen upon any sessions of the “here’s how this thing punched me in the face!” sort, which is the kind of thing I, personally, want to learn about right now.
Getting outside of Rails. Beyond SOA, some folks are going off the golden path and finding some success. I attended one good talk on adopting ideas from Domain Driven Design and hexagonal architecture. I found Ernie Miller’s ideas about how he’s worked with Rails’ flaws interesting, even though I often didn’t agree.
The conference started with David’s keynote throwing barbs at the attitude some people display towards TDD (an ambiguous acryonym to start with). Many speakers opened with, in my opinion vapid, jokes about this. Other people seemed to take personal offense that TDD might not be everything. These reactions were, I found, not particularly interesting. The more interesting ones were those who found it as a challenge to consider how they build applications, either through taste and intuition or through reasoning and engineering.
There’s always, at least in conversations I find myself in, some question of where Rails is now. Relative to other technologies, is it a leader, a follower, a player, a has-been? Every year, it’s more of a safe assumption that Rails is a given, that it’s not going to up and disappear. Still, there’s a desire to keep it fresh, avoid stagnation, and above all avoid becoming the demons (J2EE, .NET, PHP, etc.) that people used before Rails. A lot of this discussion seems to be happening around the size and frameworkness of Rails. There has always been pockets of interest around things that are smaller than Rails (like Sinatra, ROM, etc.) More interesting, there is some defense of largeness now, especially in the context of Ember. This is the most interesting, and at times tedious, debate, for me personally.
The attendance of RailsConf continues to grow more diverse. The inclusiveness efforts of the organizers and community at large seem to be bearing fruit. I saw more ladies and more minorities than I have at any conference of this size. Further, the crowd felt less startup-centric than years past. Plenty of folks from startups, sure, but also people at different kinds of businesses: small, big, hardware, software, commerce, marketing, non-profit, etc. What’s more, it was easier than ever to find myself in a conversation with people not entirely like myself. That’s a quite good thing.
Lots of people are concerned about Rails, its community, and such. There’s a vibe, not unlike 2008 or 2009 when some were seeking other ways to build Ruby web apps, that perhaps the framework, the community, and the leaders thereof don’t have all the answers. That may sound damning, but it’s a pretty healthy attitude. The problems developers face and the way we build our programs are, as ever, changing as we’re building them. The tension is out there, but having been through most of a technology hype cycle with Rails, I’m not worried that the community won’t find the resolution of that tension.