Err the Blog, revisited

Before there was GitHub, there was Err the Blog. Chris Wanstrath and PJ Hyett wrote one of the essential Rails blogs of early Rails era. Therein, many of the idioms and ideas we use to build Rails apps today were documented or born.

I’d figured this site was offline, as are most things from the mid-2000s. ‘Lo and behold, it’s still online in its pink-and-black glory. Lots of nostalgia on my part here.

There was a Big Moment here, in my career and Ruby/Rails, where an abnormal density of smart people were together in a moment (if not a community) and the basis of my career took shape. It was good times, even if we didn’t yet have smartphones or doom-scrolling.

Allow me to reflect on what I found as I went through the archives.

How we built things back then

Rails circa 2.x was a quite unfamiliar game to the modern developer. REST conventions for CRUD controllers had just taken hold, and were not yet the canonical way to structure Rails code. There was a lot of experimentation and many of the solutions we take for granted today (namely, dependencies) were extremely unsolved back then.

DRY Your Controllers — err.the_blog – ideas about CRUD controllers before CRUD controllers were the thing in Rails (2.0 I think?). That said, if you were to write this now… I’d have issues with that. 😆

My Rails Toolbox — err.the_blog – this probably represented the state of the art for building Rails in its time… 17 years ago. 👴

Vendor Everything — err.the_blog – I followed this approach on my first Rails app. It was a pretty good way to keep things going for one, enthusiastic developer at the time. But RubyGems, Bundler, etc. are far better than vendor’ing these days. And, one of the crucial leverage points for working in the Rails space.

How we built things back now

Some things stay the same. For example, the need to fill in the gaps between Rails’ conventions for organizing your app, enhancing Ruby via ActiveSupport, and the lack of a suitable approach to view templates that satisfies writing code, testing code, and building front-ends.

Organize Your Models — err.the_blog – early memories of attempting to organize files in a Rails 1.2 app despite numerous headwinds presented by Rails itself. (IMO, organizing a Rails app by folder+namespace has really only started to work after Rails 6.0).

Rails Rubyisms Advent — err.the_blog – a love letter to ActiveSupport’s extensions to the Ruby language. Many of these are in the Ruby language now, thankfully! ActiveSupport (still) rubs some folks the wrong way, but it remains one of my favorite things about Rails.

View Testing 2.0 — err.the_blog – amazingly, there’s still no good story here. It’s all shell games; write e2e tests instead of unit tests, use object-like intermediaries instead of ERB templates, etc.

How we stopped building things that way

Rails has always had flawed ideas that need re-shaping or removing over time. Mostly in making ActiveRecord as good of an ecosystem participant as it is a query-generation API.

with_scope with scope — err.the_blog – ActiveRecord scopes are way better now! I think with_scope remains, at least in spirit, in the Rails router API.

ActiveRecord Variance — err.the_blog – wherein our heroes discover inconsistencies in AR’s find* APIs and patch their way to more predictable operation thereof.

How I was even more excited about Ruby

Err the Blog was not first on the Rails hype wave of the mid-2000’s. But, it was consistently one of the best. Every time a new post was published, I knew it was worthwhile to make time to read the latest post. I learned a lot about my favorite things about Ruby from Err: writing little languages and Enumerable.

Pennin’ a DSL — err.the_blog – I could not read enough posts on building DSLs in my early Ruby days. It was the feature I was excited about in Ruby. Thankfully, it’s a lot easier to do ‘macro magic’ in Ruby these days. And, hooking into the idiomatic ways to write Rails-style declarative bits is much better now.

Select a Reject — err.the_blog, Allow Me to Inject — err.the_blog – love letters to Enumerable, my favorite thing about Ruby. And Full of Ambition — err.the_blog – fan fiction about Enumerable and ActiveRecord finally uniting in a loving relationship.

We have to go back

If you liked this, you may also enjoy revisiting:

has_many :through – Josh Susser’s blog was one of the first to explain how Rails works and how to leverage it
Red Handed – _why the lucky stiff’s blog
Envy Labs – a Rails blog from the Rails Envy folks, Gregg Pollack and Jason Seifer
Caboose – part community, part collective, an early nexus of Rails talent

And so, I come to the end of my nostalgia. Now, I must go forward.

Bundler, not as bad as they say

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.

Using Rails 3.0's notification system

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.

Rails' Next Top Model

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.

Rails' Next Top Modelhttp://static.slidesharecdn.com/swf/ssplayer2.swf?doc=railsnexttopmodel-100611151635-phpapp02&stripped_title=rails-next-top-model

View more presentations from Adam Keys.

Ogres and APIs

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.

I Heart Complexity

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!

Refactoring to more code

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?

Update: Make sure you check out Marcel Molina’s refactoring. Its probably better than mine ;)

Fake Rails environment

For testing some bits inside of ActiveRecord proper.

module Rails
  def self.env
    o = Class.new do
      def production?
        true
      end
    end
    o.new
  end
end

Evil and fun. Uses `Class.new`, my favorite Ruby method.

Muahahaha.

See me at RailsConf '08

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…

More fu in your versions

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.