Of all the new moving parts in Rails 3, the one I see the most grousing over is Bundler. This is not surprising, as its a big part of how your application works and it’s right up front in the process of porting or building Rails 3 apps.Bundler: As Simple as What You Did Before:
Bundler has a lot of advanced features, and it’s definitely possible to model fairly complex workflows. However, we designed the simple case to be extremely simple, and to usually be even less work than what you did before. The problem often comes when trying to handle a slightly off-the-path problem, and using a much more complex solution than you need to. This can make everything much more complicated than it needs to be.
I haven’t run into anything with Bundler that I couldn’t solve with a little critical thinking and maybe a little searching. On the other hand, Bundler has made getting dependencies straight amongst team members and deploying them to production servers far easier than it was before. I’m very glad that while it’s not strictly part of the scope of Rails, that Bundler is now part of it.
How to use Rails 3.0’s new notification system to inject custom log events. Ever wondered what the notification/subscription stuff in Rails 3 is? Wonder no more! I just used this to add performance logging around some Cassandra stuff in our Rails 3 app. Once you get the hang of it, this is really rad stuff.
Wherein new parts of Rails are explained
Of all the new and reimagined code in Rails 3, ActiveModel and ActiveRelation rank amongst what I find the most interesting. I’m excited that they potentially lower the bar to implementing one’s own data layer. If you’ve got some custom backend or datastore, writing a nice API around it has previously been quite the endeavor. To get it working is one thing; to make it as pleasant to use for application programmers is another thing entirely. ActiveModel and ActiveRelation have been extracted from ActiveRecord and make the task of building one’s own model layer far easier.
My presentation for RailsConf 2010 focused on what ActiveModel and ActiveRelation provide and how one can use it to write cleaner code in domain models, how to make your models feel more like ActiveRecord objects, and how to use ActiveRelation to build your own persistence layers.
I hope you find the slides educational. Further, I’ve posted the examples on GitHub so you can play along at home. If you’re particularly interested in ActiveRelation, I hope you’ll find the examples useful as a starting point to using that library.
Wherein David Hansson channels Mike Myers
Bringing Merb’s provides/display into Rails 3:
The symmetry relates to another point in API design that I’ve been interested in lately: progressive expansion. There should be a smooth path from the simple case to the complex case. It should be like an Ogre, it should have layers.
Wherein I encourage bigger ideas
Like I said, I think the market for simple applications is probably saturated and now is the time for Ruby and Rails to go up-market and tackle bigger problems. We’re well equipped to do that, having learned from what sorts of simplicity help reduce tricky problems to tractable problems.
In my RailsConf Europe 2008 presentation, I play the role of the messenger. I’m not bringing any new science that makes building more involved applications easier. Instead, I’m trying to tie it together into an understandable package. You take the gems described herein (money, acts_as_state_machine and acts_as_versioned) and a couple concepts (domain driven design and queueing) and you can build some really cool applications that solve pretty tricky problems. To me, that’s big fun.
You can check the presentation out on Slideshare or grab the PDF. Also, make sure to check out the code on GitHub. Enjoy!
Refactor my code is a neat site where you can post your code and watch others refactor it. I saw an interesting bit of code whiz past and thought I’d take a crack at it.
Removing conditionals from code is one of the little games I sometimes play while coding. Here, I’ve extracted the logic of the conditional into another class. The resulting class is _much more_ code than the original. So why do that?
Well, I say you get a few benefits:
* The logic is now far easier to test. It’s a standalone object now rather than a Rails functional test.
* The flow of what’s being done and tested is more decomposed and easier to follow.
* Most importantly, the code explains itself. No need for comments (which will undoubtedly go out of sync over time) here!
While I delight in deleting code and writing as little as possible, refactoring this to _more_ code seems the right way. What say you?
Wherein I use my powers for good/evil
For testing some bits inside of ActiveRecord proper.
o = Class.new do
Evil and fun. Uses `Class.new`, my favorite Ruby method.
Wherein I tell you how to get more Adam in your life
As hordes of Ruby and Rails folks begin the annual migration to Portland for RailsConf, I thought I’d let you know how to find me there this year:
* I’ll join my FiveRuns compatriots (and the epic Rich Kilmer) for Two Apps, Four Daemons and a Gazillion Clients, a panel on The Big Rewrite of FiveRuns Manage. Join us at 11:45 AM on Friday.
* There’s a book signing for all the contributors to Advanced Rails Recipes Friday at 12:35 PM in the Powell’s booth. Come meet me and the other folks who brought you the latest in Rails recipes.
* I’m interviewing the inimitable Geoffrey Grossenbach on Saturday at 3:40 PM in the Heroku booth. Stop by to enjoy the hijinks!
* Rounding everything off, my presentation, Oh, The Fail I’ve Known is at 11:45 AM on Sunday. Come learn from my considerable past mistakes.
That rounds out the conference activities. But I’d be remiss if I didn’t inform you that FiveRuns would like to buy you a drink or two Friday night at Jimmy Maks from 6 to 8 PM. Please to be joining me there!
What I am perhaps most excited about is the RailsEnvy videos that will premiere this weekend. You see, Jason and Gregg were kind enough to invite me to join them in making the funnies this year. Making them was a blast! I’ve seen the finished product and, in my completely biased opinion, I think you’re going to like it.
Of course, I’d love to chat with *you* (yes, you) at any point in the conference. So if you see me (and I will probably stand out), come say “Hi!” I’m hoping to have something interesting for those that do…
Wherein your versions are more ninja-like
Lazily Announcing version_fu – an update of Rick Olson’s acts_as_versioned that works with dirty attributes. Jordan McKible’s plugin is nascent, but since I have a soft spot in my heart for most things data versioning, I thought I’d point it out.
Wherein Rails testing gets slightly better
Rails Scenarios – a sane way to specify really complex fixtures in Rails. Lets you write classes to specify data and helpers to operate on that data. There’s a sane way to compose data and create relationships, as well as support for test/unit and RSpec. Personally, I’m currently in a not-unhappy place with YAML fixtures, but if you aren’t, this is worth a look.