Pages

Thursday, March 29, 2012

RESTful Bundling - An #sfrails meetup followup

It's been awhile since I've been able to get out to a San Francisco Rails Group meetup, so I'm happy to be out tonight at Plum District, the company who is hosting what looks to be a very full and standing room only group (glad I got here a little early :) ). Not to be outdone, we even had a emergency alarm system go off during introductions. talk about a warm welcome!


Tonight's two talks were focused around Bundler and developing RESTful clients. Andre Arko (@indirect) led off the evening by discussing Bundler and where it came from, why it's here and where it is going. For those familiar with Ruby (and those who are not) libraries and compiled code modules are available through an  interface referred to as Ruby "Gems". Trying to keep track of all of the gems needed, making sure that the exceptions didn't derail your progress, and trying to figure out which gems your code actually uses.


Before bundler, there were various ways to try to solve this problem, some of which were quite painful and frustrating (lots of "gem install" in script files, etc.). Bundler solves this  problem by making sure that gems and their ordering are handled automatically, so that you are able to make sure you are running what you think you are running.


Today, Andre talked about Bunder 1.1 and some of the new features it has, such as github specific gemfiles (kinda cool :) ). You can now easily check to see if your gems are outdated. You can clean up old gems and remove the ones you are no longer using. Bundler 1.1 now supports subshell without bundler, and bundler now shows the absolute path to every gem in your bundle if you want to search for them. The big question, though, is "IS IT FASTER?!" The answer is "yes", by about a factor of four, but don't take my word for it, download it, install it, and check it out for yourself :).


Bunder 1.1 is a lot better, and they want Bundler 1.2 to be even better than that. To do that, the goal is shorter release cycles, creating ruby version check systems, and checking out local gems if set up to do so. One of the big goals is to get rid of "bundle exec". Overall, this looks cool and I'm interested in seing what we'll be offered down the road.


The second talk was focused on developing ReSTful clients, and explaining how everything fits together. Jack Lawson from Plum District talked about some of the chalenges he faced while implementing an API to build out a client, any client. These areas work for websites, mobile apps, tablets, etc. I have to admit, much of this is still fairly esoteric to me, but since I've worked through Learn Ruby the Hard Way, a lot of these conversations make a lot more sense now. I still have some holes to fill in, but they feel much less massive than in previous meetups I've attended. Building the API is just the first half of the battle. Actually getting everything to play nice is the other half. Backbone, CoffeeScript, and Mustache / Hogan.js were demonstrated so that we could see the steps necessary to progressively grow the client application. Pretty cool all told, though still a bit over my head in spots.

I'd be remiss to not say a hearty thanks to everyone who puts on these Meetups at regular intervals. We comment often that you can't swing an umbrella in San Francisco without hitting some kind of meetup. There's a wealth of talent and opportunity here. I need to remember to  not take such things for granted.

No comments:

Post a Comment