fhwang.net

rails

Event Sourcing with Rails: A Case Study

In December I gave a talk at NYC.rb on Event Sourcing with Rails. Hakka Labs was there to take video, which is now up:

Event Sourced Record, the gem I mentioned in that talk, is now up. Check it out and let me know what you think.

EasyMailPreview

The folks at HowAboutWe do a decent amount of HTML email, as you might expect for any site where people can send each other messages. Dissatisified with the tools for developing HTML email, I wrote EasyMailPreview, a Ruby gem that makes it very easy to see the results of an HTML email in development mode. It auto-discovers mail methods and method arguments, and lets you write them on the fly with in an admin-ish screen.

EasyMailPreview screenshot

I've been using it for a while, and I find it eases the pain of developing HTML emails. Somewhat.

How to simulate a POST request body in a Rails 3 functional test

This was surprisingly underdocumented out in the world. If you've got a Rails controller that ever uses request.body.read, you can set that in a functional test like so:

class ArticlesControllerTest < ActionController::TestCase
  test "creates a new article" do
    attributes = {
      :subject => "10 ways to get traffic by writing blog posts about arcane Rails tips",
      :body => "Just kidding, it's totally impossible"
    }
    @request.env['RAW_POST_DATA'] = attributes.to_json
    post(:create)
    assert Article.last
  end
end

@request is a local variable defined inside of ActionController::TestCase, and used when you make a test request by calling post, get, etc.

Rake tasks for running spec files that match a pattern

Developed for the good folks at HowAboutWe.

Moar Rubyists: Boston's experiences

We've been dealing with the same problem [of a lack of Ruby programmers] for a couple of years in Boston. We've iterated through a bunch of potential solutions so I figured I'd share those with you here in case there's some lessons learned you can apply.

Dan Croak of Thoughtbot kindly shares his experiences with trying to get more Ruby programmers in Boston. It's a detailed and thoughtful post, and definitely worth a read.

I found this especially interesting:

1) Convert Java/Perl/.NET/Python developers from big companies into Rubyists

Our main effort here was a VC-sponsored workshop ... I would not classify it as successful. I think the two reasons why were:

  • the class wasn't 100% subsidized. It was still priced at $600.
  • it's difficult to find this cohort in any significant numbers. You can't contact HR at Fidelity and say, "hey, I'd like to poach 50 of your developers, can I send an email to your mailing list?"

My guess would be that if you're going to try to convert engineers at big companies, that effort will be more top-down than bottom-up. Those programmers are generally more risk-averse and unlikely to devote a lot of time and money to a skill that might possibly help them change jobs.

But, there are definitely larger companies that are trying to make the switch internally, and they're having a tough time of it. (Ten months ago I wrote about a large company that was living this pain, and from what I hear, they're still having a hard time hiring.) I really do wonder what would happen if companies like Thoughtbot or Pragmatic Studio were to sell dedicated group classes directly to companies. Of course, then you're dealing with an enterprise sales cycle. Which pretty much everyone avoids if they can.

That $2800 Rails class

You know, the one that sparked all that discussion on NYC.rb*? If you feel like reading the whole thread you can start here**.

Some thoughts:

  1. People learn in different ways. Some people can teach themselves Rails by locking themselves in a room with nothing but a laptop and the internet. Other need structure and individual attention. Accordingly, it's not that useful to say things like "I learned skill X by spending only $Y, so therefore if you try to teach other people skill X by charging them a dollar more than $Y, you're a fraud and a thief."

  2. Thousands of dollars isn't unheard-of for Rails classes or other sorts of software courses. If this is something you do for a living and are going to keep doing for years, then spending $2800 on the right sort of knowledge can pay you back very quickly.

  3. Have you heard me say before that New York needs more Ruby and Rails programmers? Oh, only like a thousand fucking times? Yeah, that's about how massive and chronic the problem is. Local Rails classes can only help, overpriced or not.

  4. I don't believe I've met Dimitri, but I know Daniel from around and he seems like a sharp and conscientious guy. The two of them probably teach a decent Rails course.

  5. Of course, a great programmer can be a terrible teacher, and vice versa. There's always a high degree of risk that the educational experience you get may not be what you were expecting, which is why people pay premiums for classes offered by organizations or instructors with a known track record, whether that's Harvard or Edward Tufte or Pragmatic Studio. I think it's safe to say that this course lacks such an imprimatur, and if I were a cost-conscious aspiring Rails coder (which I'm not in, like, a dozen ways) I'd expect this course to be priced a bit down accordingly.

  6. And when you compare it to the PragStud Rails classes, it does seem a bit expensive. The local class is $2,800 for 24 hours, or $116.67/hour. The PragStud classes—which are considered by many to be the gold standard in Rails classes—are $2295 for 23 hours, or $99.78/hour.

  7. No, nobody actually says "PragStud". It's more stupid than clever, I suppose.

  8. On the other hand! The PragStuds never ever come to New York City so you have to take that into account. There's a significant premium you can charge for a service that is the exact same as somewhere else, only you don't have to leave New York City. My beloved Gotham Ruby Conference being one example. Because New Yorkers don't like the rest of the country. It scares and confuses us.

  9. But after all that maybe you still think they're charging too much. If that's the case, the way to prove that point would be to offer your own local Rails course that is just as good and noticeably cheaper. Hell, it might even be as easy as nagging the PragStuds to try doing a course in NYC. I think there are many people who'd love to see more offerings of local techie courses, if only for what we'd learn about the local education marketplace in the context of a possibly bubblicious 2012.

* I'm no longer an NYC.rb organizer and I don't speak for NYC.rb on this or any other subject. As if I ever did.

** I'd link to the entire thread on the NYC.rb email list, instead of just the first message, if it weren't for the fact that Meetup.com's mailing list functionality is a giant steaming pile of shit. That's social media for you: You get what you pay for.

admin_assistant 2

This is actually a few weeks old, but I’m bad at announcing things: admin_assistant 2 is now out. The big changes in it are support for Rails 3, and jQuery.

I’ve also updated the doc site, including retaining the old API for v1: Check it out here..

Happy 4th!

admin_assistant: Rails 3 support in pre-release

admin_assistant 2 is now in pre-release, and if you’re using it, your early testing is appreciated:

gem install admin_assistant --pre

This is a pretty significant upgrade for admin_assistant: It now supports Rails 3 and jQuery. However, the core philosophy is unchanged: It is still a plugin for building admin controllers with really great hooks and aggressive full-stack testing. Please try out the pre-release and let me know if you see any issues.

On fixtures and first-time testers

Over on Josh Susser’s blog, DHH seems to be upset that I called the selling of fixtures to Rails newcomers a lie. Reply below:

Basically, you can lie to someone with the best of intentions, and you can even lie to someone without meaning to. I think this is always a pitfall when you try to simplify, and when you try to sell something.

I’m not disputing the good intentions. DHH and the rest of the Rails-core folks deserve tremendous credit for smoothing the learning curve for web programmers. Over the years I’ve personally seen a number of computer programmers “grow up with Rails”, so to speak, and I think it helped that Rails put a tremendous amount of energy into simplifying the path for newcomers, and then marketing that simplicity effectively.

But there’s a difference between accidental complexity and essential complexity. Some things are hard because people make them hard, but some things are hard because they’re hard. As I’ve argued before—this was a big part of my RubyConf talk last year—I think that testing is an essentially hard task. There’s no silver bullet. We don’t do it because it’s easy. We do it because it’s worth the time, and because we’re professionals.

I don’t want to minimize the difficulty that Rails faces in educating less-experience programmers. I know there are a lot of people coming to Rails that have never done serious OO and never done testing, and if testing is made to sound too scary or difficult, they’ll just keep putting it off.

But what I’ve never understood is why fixtures are actually easier for a noob than just creating the model in Ruby. Why is this:

david:
  id: 1
  login: david

... simpler than this?

@david = User.new :login => 'david'

If anything I’d argue that the 2nd form is far far simpler, because it uses Ruby, a syntax that you’re already using to write the app itself. Fixtures, on the other hand, use YAML, which some percent of Rails newcomers have never used. So, great, one more syntax to learn, as if a web programmer doesn’t have enough on her mind, between SQL and Ruby and Rails and HTML and Javascript and CSS. (In general, I’d say I’m not a big fan of using YAML when you’re also using Ruby, which is already a very elegant way to write a configuration file.)

In fact, I wonder if fixtures are detrimental as a teaching tool because they seem to imply there’s something special about creating or modifying test data. I’ve had a few conversations with people who never tested before Rails, and I say “why don’t you just save the model in your test setup, using Ruby”, and they have this look on their face like that never occurred to them. It’s as if fixtures somehow mystify the process a bit.

Of all the people I know who have been doing Rails development for some time, and who have reasonably well-tested code, almost none of them use fixtures. Those that do use fixtures use them in extremely precise ways, often mixing them with other test setup techniques, usually either RSpec-style mocking, or just straight-up creating records in the test DB. In contrast, more than once I have had a conversation with somebody who’s relatively new to Rails that includes them saying “yeah, once I stopped using fixtures all those problems went away.”

If anything, the people I know who are using fixtures do so for the performance optimization, since fixtures do a good job of hooking into transactions in the underlying DB. But if that’s the primary argument for fixtures, then why are they the default? Isn’t that a premature optimization? Shouldn’t we first encourage Rails noobs to test the testing waters with very simple data creation in Ruby form? And then when they start to be unhappy about how slowly their tests run, we can introduce different optimizations, such as fixtures or RSpec mocking or whatnot. That seems like the right order to me.