[bphogan]

It's nice that Steve and others want to make Ruby on Rails applications better and faster.

But this post should have been the original blog post. You can't get frustrated by your audience "not getting it" if you use terrible examples or if you're lying to simplify.

This was a good explanation on the way to use presenters. The original one was not. I still don't plan to run out and use presenters everywhere because the payoff simply isn't there for most of the apps I write.

My bigger concern is that, like with most things in Ruby, a certain percentage of folks are going to just run wild with an idea, and even the simplest application is going to have a bunch of presenters in it just because someone said it was "the right way".

It's good to explain the real "why" with these concepts. What are the benefits, the drawbacks, and what will I be able to do that I couldn't do before? So I think this followup does a great job of that.

[raganwald]

Your points are cogent, however blogs are more like conversations than books. With a book, you iterate a few times with your editor(s), you pass drafts around, and hopefully discover which examples aren’t clear before you publish. Everything else must wait for the second edition.

With a blog post, you can revise the original based on feedback, but the odds are that none of the people who read it the first time will see the revision. A follow-up post is the best way to expand/expound/correct yourself.

I agree that the first post could have been even better, but given the first post being what it was, putting out a second post seems like the right thing to do.

[dasil003]

The trouble is that no one's reading books anymore :(

[tannerburson]

I agree, the original piece was a decent explanation of how to refactor some helper type code into a more Presenter like model. But he completely skipped out on the question of why it's a useful thing, and when it's a good fit. If that post had been by DHH or another Rails core member, we'd see it instantly picked up into the current cargo-cult trend of the month.

That said, I do appreciate Steve's work on finding ways outside of "the one true path" to simplify Ruby code, and hope he'll continue writing these sorts of things going forward. If nothing else, the discussion surrounding the technique and it's alternatives is extremely worthwhile.