There has got to be any easier way.

require 'rubygems'
require 'tzinfo'
require 'active_support'
require 'active_support/values/time_zone'

time_zone_names = [ 'Eastern Time (US & Canada)', 'Central Time (US & Canada)', 'Paris' ]
abbrev_to_zone = time_zone_names.inject({}) do |map, name|
  map[ActiveSupport::TimeZone.find_tzinfo(name).current_period.abbreviation.to_s] = name; map
end

p Time.now.zone
p abbrev_to_zone[Time.now.zone]
p abbrev_to_zone['CET']

Ow.

In Rails 3.0, the default ActiveSupport::JSON backend is YAML.

In Rails 3.1, it’s YAJL.

They deserialize JSON times differently. In 3.0 . . .

ruby-1.9.2-p290 :001 > ActiveSupport::JSON.decode( '{"at": "2011-10-13T12:00:00+00:00"}' )
 => {"at"=>2011-10-13 07:00:00 -0500} 

See the lack of quotation marks around what “at” points to? It’s not a String. YAML converts the value to an actual DateTime. (There a DATE_REGEX defined in ActiveSupport::JSON that does the matching.

But in 3.1:

ruby-1.9.2-p290 :001 > ActiveSupport::JSON.decode( '{"at": "2011-10-13T12:00:00+00:00"}' )
 => {"at"=>"2011-10-13T12:00:00+00:00"} 

We had the yajl-ruby gem installed for development, so were getting the the Strings. Then on our staging server, we were getting the already-parsed time value, and were getting errors.

This strikes me as a substantive change. I’m not sure I’d call it a bug, but it was unexpected.

So here’s a good one. We had a spec that looked something like this:

require 'time'

class SomeModel
  def self.all
    @all ||= []
  end
  def self.create!(time)
   all << new
  end
end

describe "surprise" do
  subject { SomeModel }
  let!(:now) { Time.now }
  ['9 AM', '10 AM', '11 AM'].each do |hour|
    let!(:time) { Time.mktime(now.year, now.month, now.day, Time.parse(hour).hour) }
    let!(:some_model) { SomeModel.create!(time) }
  end
  its(:all) { should have(3).items }
end

(In the original code, rather than check that the .all method returned a enumeration with 3 items, we were describing the behavior of a different object to see if it could do something when three collaborating objects had already been created via factories.)

The spec told us this:

     Failure/Error: its(:all) { should have(3).items }
       expected 3 items, got 1

That’s funny. How come we don’t have three items? Let’s try a bit of puts debugging. We’ll dump the value of hour just inside the block passed to #each. And we get:

hour: 9 AM
hour: 10 AM
hour: 11 AM

Well that’s expected. Gee, maybe our collaborator is buggy (and maybe we should be mocking it anyway, but let that pass). Let’s show the hour inside of what the let defines:

  ['9 AM', '10 AM', '11 AM'].each do |hour|
    puts "hour: #{hour}"
    let!(:time) { puts "hour inside time: #{hour}"; Time.mktime(now.year, now.month, now.day, Time.parse(hour).hour) }
    let!(:some_model) { SomeModel.create!(time) }
  end

What do we get?

hour: 9 AM
hour: 10 AM
hour: 11 AM
hour inside time: 11 AM
F

Interesting.

The problem is that we hadn’t internalized properly the documentation for the RSpec let (and let!) helper. The documentation says: “Use let to define a memoized helper method. The value will be cached across multiple calls in the same example but not across examples. Note that let is lazy-evaluated: it is not evaluated until the first time the method it defines is invoked. You can use let! to force the method’s invocation before each example” (https://www.relishapp.com/rspec/rspec-core/docs/helper-methods/let-and-let).

The key phrase is “define a . . . method.” So what our code is doing above is simply redefining the #time and #some_model methods over and over. Then, since the execution is deferred, we would get the #time method returning ‘11 AM’ and the #some_model method instantiating only one SomeModel.

Before we touch on one way to fix this, let’s look at some of the implications of what let does. For one thing, let’s remember that the method will only be executed once (since it’s memoized). For example:

describe "no surprise" do
  let(:x) { puts "x defined to return 'a'"; "a" }
  let(:x) { puts "x defined to return 'b'"; "b" }
  it "should have the expected setup value" do
    x.should == "b"
    x.should == "b"
  end
end

When this spec is run, we are going to see “x defined to return ‘b’” once. We don’t see “x defined to return ‘a’” because the execution is deferred, and the second let(:x) wipes out the first. Since the result is memoized, we only see “x defined to return ‘b’” get printed out once:

$ rspec spec/example2_spec.rb
x defined to return 'b'
.

Finished in 0.00034 seconds
1 example, 0 failures

Additionally, since let defines methods, and since execution of the methods is deferred until after they have all been defined, you can have earlier methods depend on later methods:

describe "no surprise" do
  let(:x) { y + 1 }
  let(:y) { 1 }
  it "should not matter in what order these methods are defined" do
    x.should == 2
  end
end

So why the confusion? I think there are a couple of reasons. The main thing is that word “let.” It sounds as though we are assigning a value to a key. It is not uncommon to see sequences of lets like so:

let!(:last) { Factory(:user, last_name: 'zzz', first_name: 'aaa') }
let!(:center) { Factory(:user, last_name: 'aaa', first_name: 'abc') }
let!(:first) { Factory(:user, last_name: 'aaa', first_name: 'aabc') }

So let looks something like an assignment. Why is it called let? I don’t know. Maybe it’s supposed to feel a bit like Common Lisp where let is a stand-in for lambda. Maybe the thought was that if “assigns” or “set” was used, it would be ambiguous given how these terms are used elsewhere in Ruby and Rails.

If you ask me, a name such as “dm” (for define_method) would have been more appropriate. Then noobs (like me — I’ve always used Test::Unit) would wonder what it stands for, look it up in the documentation, and get some insight. “let” is just too abstract.

The original problem? If we must use let, perhaps define an Array with the let:

describe "surprise" do
  subject { SomeModel }
  let!(:now) { Time.now }
  let!(:some_models) do
    ['9 AM', '10 AM', '11 AM'].map do |hour|
      SomeModel.create!(Time.mktime(now.year, now.month, now.day, Time.parse(hour).hour))
    end
  end
  its(:all) { should have(3).items }
end

One last thing. Discussions in books are a bit misleading, or don’t tell the truth soon enough. For instance, in Noel Rappin’s book Rails Test Prescriptions (which is not only excellent but actually funny), he introduces let by saying: “Using let(), you can make a variable available within the current example group[.] . . . The symbol can then be called as if it was a local variable” (p. 193). Well, this is true, but by saying that “you can make a variable available,” it sounds like variable assignment — which it just isn’t. Among other things, just saying that makes one thing that the order of the let’s is important in terms of the values that will eventually be assigned. Thankfully he says just a wee bit later, “a let() call is syntactic sugar for defining a method and memoizing the the result.” Yes. But this is one of those cases where easing into the truth can be harmful.

The RSpec Book (Chelimsky, et al.) does a similar thing, rhetorically: “When the code in a before block is only creating instance variables and assigning them values, which is most of the time, we can use RSpec’s let() method instead” (p. 55). Again, this is a bit slippery. It’s not like creating instance variables at all. It’s like calling a method. Which, of course, Chelimsky immediately explains.

The upshot:

1. Don’t put your calls to let inside of loops! (If you must, have the calls to let define different symbols.)
2. Don’t assume that the methods will run in the order of the lets.

Let’s say that we have a Ruby object with some class methods. In my case, we want to be able to inject a driver at the class level that all instances will use:

class Mod::Thingy
  def self.driver
  end
  def self.driver=(d)
  end
end

And let’s say that .driver has a default value. So the class looks more like this:

class Mod::Thingy
  def self.driver
    @driver || DefaultDriver
  end
  def self.driver=(d)
    @driver = d
  end
end

Now here’s the dealio. Let’s say that we test for the default value first. So we check Mod::Thingy.driver == DefaultDriver. Then we test the setter. We do Mod::Thingy.driver = OtherDriver, and then check the return value of Mod::Thingy.driver. Fair enough.

But what if we ran the examples in reverse? Now we do Mod::Thingy.driver = OtherDriver first, check it; but now in our second test, we can’t test the default value, because the state of Mod::Thingy has been changed.

Strategies:

1. We might use RSpec’s around feature to save the state of Mod::Thingy.driver and restore it afterwards. What I don’t like about this is that now the around method has to know all about all of the setters at the class level. Meanwhile, it is possible to imagine objects that are difficult to set back to their default state: Perhaps the class methods have order dependencies themselves. This would make the test need to know a lot about the inner state of the object.
2. We might provide a .reset! method on the object. But this seems a bit nutty: Add a method just to make testing easier?
3. What about this in an RSpec before(:each) block:

   
       Mod.send(:remove_const, 'Thingy')
       load "#{PROJECT_ROOT}/lib/mod/thingy.rb"
   

   Now we’re getting a nice clean class. To me, (3) is more parallel to the testing convention of new’ing up an object instance for the test.

Thoughts?

I’ve heard two people complain that they can’t see OAuth HTTP behavior and get unexpected 401s. If you want to see what’s going on at the transport level, here’s a monkeypatch (depends on ActiveSupport for the alias_method_chain) just for you:

class Net::HTTP

  def initialize_with_debug(*args, &block)
    initialize_without_debug(*args, &block)
    set_debug_output $stderr
  end

  alias_method_chain :initialize, :debug
end

If Ruby’s Hash#default= returned the Hash instead of the default object, you could write:

TRANSLATION = { 'hello' => 'bonjour' }.default=('unknown')

I’m not religious about the old or new Ruby Hash syntax, but it is interesting that if you inspect a Hash in 1.9, you get the old syntax:

ruby-1.9.2-p180 :001 > { foo: 'bar' }
 => {:foo=>"bar"} 

If the new syntax is so ding-dang good, then I think inspect should use it, when it can.

So I’m reading Chad Pytel and Tammer Saleh’s book Rails AntiPatterns: Best Practice Ruby on Rails Refactoring, and it’s a good one. Oops, but I got the title wrong: It’s Rails^TM AntiPatterns: Best Practice Ruby on Rails^TM Refactoring. (I don’t want to get sued for leaving out those TMs.)

I’ve been writing Rails^TM code for a long time, and this book is embarrassing to read. Honestly, after reading a couple of chapters I cranked up my editor and made some tweaks to my code. Whew. Truly, this book has the goods on any number of things you’re doing wrong with your Rails^TM app, and I would advise you to take seriously their advice.

There are chapters that teach things you should already know (on Models, Views, and Controllers), but also chapters that go beyond (those on using third-party code and services), and some where I think these guys know more than just about anyone (the chapter on testing). I kinda wish the testing chapter didn’t use Shoulda, but I guess it’s OK, since they invented it.

It’s hard to find things to gripe about. One oddity is that they recommend HTTP 401 for application-level (i.e., controller) authorization errors (p. 205): But I thought 401 was reserved for specifically HTTP-related auth (e.g., basic or digest – see the RFC). I guess you can use it like this. They also talk about denormalization, and replacing joins with column constants (pp. 79-82). I guess so. (To be sure, they say that if there’s going to be a UI, you do want the table.) I think increasingly we need to look at our schemas as though a non-Rails application will be using it, sooner rather than later: In which case, such constants really do need to be in a separate table, even if there is no UI. So I would advocate sucking in a table with the right codes, putting the key values into the table, and just leaving out the association if you want to avoid the joins. Also in this area, they put their constant values into an Array (p. 81). Dudes, use a Set. Please.

These manufactured gripes aside, it’s a lovely book. Now let me get back to my editor and my Rails^TM app so I can remove some more embarrassments. Sheesh, Law of Demeter AGAIN!?

Russ Olsen has just come out with a wonderful book on Ruby called Eloquent Ruby. If you’re a Rubyist, you should get it. What’s great about it is that it combines a breezy, even sometimes funny, style that is “teacherly” but also accurate in matter of detail.

There are a couple of things that really make the book work. First, there’s a nice little Document class that Olsen bends this way and that, using it as the vehicle for explaining subclassing, modules, mixins, and metaprogramming. My first impression was that it was a little lame, but by the end of the book I was very impressed with the range of examples. Indeed, the use of a Document class reminded me of some of the class examples from the Gang of Four book.

A second fine feature is that there are many sections devoted to a particular topic “In the Wild.” We have needed this in Ruby books for a long time — a coupling between Ruby as we know it in a textbook, and Ruby in the real world. These are really quite different “Rubies,” but Olsen is adept at showing through sometimes-simplified examples that the occasionally imponderable real-world Ruby really does share an idea of code with what learners start with.

I also like the chapter near the end of the book on the various Ruby interpreters, and how you can get something out of reading the code, be it in C, Java, or Ruby.

Now, about teaching Ruby.

Ruby is a tough teach. Students plateau at an average level of competence quickly, but the real power of Ruby comes after a stiff hike up the mountain to enlightenment.

I used to think that one could use the Programming Ruby book alone, and this would do the job. But it’s long, and in its new edition somewhat hobbled by not discussing Ruby 1.8.x. In a number of places there is discussion that seems aimed at Java developers (see how easy it is in Ruby!) that feels out-of-date to me now.

But having read Olsen’s book, I’m now thinking that a better sequence is to pair Cooper’s Beginning Ruby with Eloquent Ruby, supplemented, perhaps, with the Flanagan/Matz The Ruby Programming Language. This way, you get to be effective and productive quickly (via Cooper), wade into the depths and improve your style (Olsen), and get the final word on syntax and semantics (Flanagan/Matz). A place where I think Programming Ruby may still have the edge is in some of the metaprogramming discussion, but here I think the best resource out there is Thomas’s video series.

So my 8-year-old daughter has been increasingly interested in what computers can do, and how to make them do things. We’ve done some Scratch (http://scratch.mit.edu/) together, and we’ve done some Lego/software integration with MIT’s kit (not Mindstorms — we used the earlier kit MIT made that doesn’t have Lego branding and so forth). That was pretty fun.

But what she really wanted was a multiplication drill-and-practice program. I said to her: “Are you sure?” (because I personally find drill-and-practice dead boring). Well that’s what she wanted. So we did it.

We did it in Ruby for my convenience. I decided that the hassles would be worth it. For instance, we talked a lot about what it means to convert a string typed by the human into an integer for the computer’s math. I wrote the code, and explained each and every line to her. The program would show a random multiplication (e.g., “7 x 8 = “), and she would have to type in the answer.

Here are the iterations we went through, and my observations regarding kids’ games based on this single case:

1. Report the number correct in a row. She likes the idea of breaking her longest streak of correct answers. Kids like self-created goals. I had introduced the idea of a variable to her earlier, but now we talked about it at greater length, since the counter had to be updated only under certain conditions.
2. Every 5 correct in a row, pop up a funny image. We used some lolcat images from icanhascheezburger.com. My observation here is that kids like frequent rewards. But not too frequent! We allowed that launching the browser to show an image would just be “magic.”
3. She got interested in the basic stats: Number correct, number wrong, percent correct. We talked a lot about percentages, which is a bit ahead of where she is in math. I noticed shortly afterwards that she could correctly predict that if she got the next one right, she’d have 75% correct. To me, this suggests that there are a lot of possibilities for passive learning; she started to “get” percentages without a lot of direction from me. Some of this coding I just did without a lot of explanation: In particular, rounding for the percentages seemed to be too hard for her at this point.
4. As she was doing this, she told me that her goal was to get 100 in a row. At 90, she got one “wrong” because she just pressed return instead of entering a number (a case we hadn’t thought of). We had to stop the program to fix it, but that broke her streak. She suggested that there be some means to go backwards. So we introduced a cheat: If she types “cheat” the most recent answer would be forgotten. This suggests to me that kids love to “win” but at the same time they can become very unhappy if there is a glitch that seems “wrong” to them. Providing a means to get past a “mistake” seems to be very appealing. I am not sure that the availability of “cheats” is a good lesson to teach; it might set up the wrong expectations about the real world. On the other hand, it’s called a “cheat” for good reason, so I encouraged her to feel guilty about using the cheat. We decided to report on the number of cheats used over the course of a game. That way, if she never uses a cheat, she can brag about it (”I got 20 in a row, and didn’t use a cheat!”).
5. Finally, she wanted a bigger payoff at the end. She asked if she could enter her goal (20 in a row), and, if achieved, get a big fat message. So we did that. Now when you get to your goal, it prints out “You Win!” with a lot of asterisks around it. To a kid, a “big” reward is something that is different from the rest of game flow (there are no asterisks elsewhere in the experience).

So that was fun. The quality of the technology — the bells and whistles for the platform — seemed to matter a lot less than iterating through the game design, and thinking about the right rewards and punishments to encourage sticking to the activity.