ruby

Over time, technological progress makes it easier to write automated tests for familiar forms of technology.

Meanwhile, economic progress forces you to spend more time working with unfamiliar forms of technology.

Thus, the amount of hassle that automated testing causes you is constant.

My Goruco 2012 talk, "The Front-End Future", is now up. In it, I talk about thick-client development from a fairly macro point-of-view: Significant long-term benefits and drawbacks, the gains in fully embracing REST, etc.

I also talk a fair amount about the cultural issues facing Ruby and Rails programmers who may be spending more and more of their time in Javascript-land going forward. Programmers are people too: They have their own anxieties, desires, and values. Any look at this shift in web engineering has to treat programmers as people, not just as resources.

Francis Hwang - The Front-End Future from Gotham Ruby Conference on Vimeo.

As always, comments are welcome.

This isn't just the event New York Rubyists want. It's the event they deserve.

Thanks so much to all the co-organizers for pulling this off. Everybody else: See you next year, if not sooner.

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.

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

I wrote a little something about Goruco on the Goruco site:

Let me make a confession: Before we hosted the first GORUCO, I kind of didn’t want to be bothered. NYC.rb had been a successful Meetup for years, and people would occasionally say “you know, we could have a great regional conference here.” Which made sense in theory, but just thinking about the work involved gave me a headache. I usually smiled politely and tried to change the subject.

It's worth a read if you're not already convinced this year will be the best Goruco evar. And if you have yet to buy your ticket.

So, I'm speaking at Goruco this year. On The Front-End Future:

With the rise of Javascript MVC frameworks like Ember and Backbone, web programmers find themselves at a fork in the road. If they keep doing server-side web programming, they'll benefit from tried-and-true tools and techniques. If they jump into Javascript MVC, they may be able to offer a more responsive web experience, but at significant added development cost. Which should they choose?

This talk will address the strategic costs and benefits of using Javascript MVC today. I will touch on subjects such as development speed, usability, conceptual similarities with desktop and mobile applications, the decoupling of rendering and routing from server logic, and the state of the emerging Javascript MVC community. I will also discuss the impact of this seismic change on Ruby, Rails, and your career as a software engineer.

Nobody should confuse me with a Javascript expert, and that's not why I'm giving this talk. There are many talks you can see that focus on the specifics of implementation that are being hashed out today. With my talk, I will be drawing out the macro trends in our field that affect the products we build, and the careers we craft.

In particular, I feel like the move to thick-client web apps is giving the Ruby and Rails community a bit of existential paralysis--we should be talking about this far more, and meeting this change head-on. The future is uncertain, but it is also bright.

Goruco is on Saturday, June 23. This is our sixth year, and without giving away the rest of the speakers, I think this might quite possibly be our best program yet. If you want to join us, tickets are still available.

Developed for the good folks at HowAboutWe.

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.

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.

This is one of those Google-baiting posts that coders write for other coders in hopes of saving them hours of frustration. It's unlikely to be of interest to anybody else.

As we moved Profitably to Rails 3, we were having a strange problem upgrading PaperTrail. PaperTrail needs to be upgraded to 2.x for Rails 3, but as soon as we upgraded it, we couldn't even load the environment. The traceback we'd get looked like this:

$ ./script/rails runner "puts 'hello world'"
/Users/francis/.gem/gems/activerecord-3.0.7/lib/active_record/named_scope.rb:132:in `valid_scope_name?': private method `warn' called for nil:NilClass (NoMethodError)
  from /Users/francis/.gem/gems/activerecord-3.0.7/lib/active_record/named_scope.rb:102:in `scope'
  from /Users/francis/.gem/gems/paper_trail-2.5.0/lib/paper_trail/version.rb:18
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
  from /Users/francis/.gem/gems/paper_trail-2.5.0/lib/paper_trail.rb:7
  from /Users/francis/.gem/gems/bundler-1.0.15/lib/bundler/runtime.rb:68:in `require'
  ...

If you're seeing this error, you may also have Sinatra in your Rails app for some strange reason (our strange reason is explained below). If that's the case, then the fix is to tweak your Gemfile with a require option:

gem 'sinatra', '1.0', :require => 'sinatra/base'

If the fix is simple, the actual cause was pretty gnarly. PaperTrail comes packaged with an ActiveRecord model called Version, with a scope called after. In ActiveRecord, the scope method will log a line if it's overwriting an existing method, though in this case ActiveRecord.logger isn't even defined yet, so you get a traceback from trying to call nil#after.

Why is Version.after defined? Because we're using Sinatra in our full-stack tests. Profitably supports authentication from a few external sources, and we got to the point where we wanted to test an external authentication source in combination with our Javascript and our Rails code. The best way we found to do that was to create a secondary server in Sinatra that our capybara test would spin up, for the purpose of simulating a POST from somebody else's website.

Sinatra, by default, writes a bunch of global methods like get, put, post, etc, which makes perfect sense if you're writing a quick Sinatra app, so you can do stuff like:

get '/hi' do
  "Hello World!"
end

Only problem being, in our case, that it also defines after, which is then defined on every Ruby object, including PaperTrail's Version class. (Yes, defining a method globally will define it on every single Ruby object, which is why you don't want to do it that often.)

Anyway, you can configure Sinatra not to create those methods globally, which is what the above Gemfile change will get you.