Last week, for example, I wanted to speed up our builds by upgrading Bundler to 1.0.10 and RubyGems to 1.5.2. Because of the new partial caching of the dependency graph, the upgrades shaved two whole minutes off the build locally, and I wanted to get that on CI.

Trouble is, once I did the upgrades, I got this upon restarting CC.rb:

It turns out that older versions of Rails 2.3 aren’t compatible with the new version of RubyGems. To fix this, I added the following to CC.rb’s config/environment.rb, between the definition of ABSOLUTE_RAILS_ROOT and the Rails::Initializer block.

Both the 1.8 and 1.9 builds are now about 2 minutes faster which is awesome. Highly recommend the upgrades.

I managed to pass the JLPT level 3 a few years ago, so in Japan last month, I was decent at ordering food and navigating the subway. But I quickly discovered that I couldn’t really talk to another programmer. None of my classes even taught me how to say “programmer,” let alone “code,” “object,” “method,” “development environment”…

@sarahmei, @t_wada, @sakuro (photo by Lee Lundrigan)

Dictionaries would normally be my next recourse, but it’s pretty hard to look this stuff up. As in the US, programmer culture in Japan has its own slang. But I had a chance to pair with some Japanese devs at the Pair Programming Cultural Exchange that @t_wada and I ran at RubyKaigi (see left), so I picked up a little bit. And since I’ve been back, I’ve been translating technical articles for fun. (What else would you do on a 12-hour flight?)

As a result, a lot of this list comes from my notes. I also added words I found in the RubyKaigi Twitter stream, Sarah Allen’s blog, and Mightyverse’s pair programming phrases, among other locations. Any errors are, of course, my own.

The list is short – there are many more things I’d like to know how to say. And I guessed at the right katakana for some of the loan words. So: please send additions and corrections[*], kkthx! I’ll add anything vaguely technical to the list.

I hope it provokes more cross-language Ruby discussion.

[*] ありがとう:

• @threedaymonk for a correction to multibyte digit.
• Nobuyoshi Nakada for corrections to variable and multibyte character/digit, and addition of full-width character/digit.
• @boblet and karmag for a correction to development environment.

Why not, indeed? (photo by Lee Lundrigan)

I wasn’t sure what to expect. Would it be all men in button-down dress shirts and pleated pants? Would I give my talk to a room full of blank looks? Would I be the one with the blank look when I went to a talk in Japanese? WOULD THERE BE FAN SERVICE??

No, no, no, and no. Thank goodness. It was one of the best conferences I’ve ever attended. Most of the talks were in Japanese, but they all had simultaneous translation in IRC (and IRC was projected onto screens at the side of the stage). My talk was translated into Japanese in IRC as I gave it, and the video was up the next day.

And people were interested in Jasmine and JavaScript testing (the subject of my talk), beyond just politeness. I helped Kohei Matsuoka (@machu), one of the contributors to tdiary, get going with Jasmine testing for their JavaScript. tdiary (also on github) is an open-source Ruby blogging system built on CGI.rb. It is OLD SKOOL. They are just now formulating a testing strategy (it’s in a branch of tdiary/tdiary-core, to be merged in soon according to @hsbt). It’ll be fun to watch it shake out.

Lightly crushed

The extra-curriculars were also fun. I clumsily made an origami ruby, with much help and encouragement from the instructor, who could clearly do more complex pieces. One of the Asakusa.rb guys gave me a fan from last year’s Ruby Kaigi that has an illustration from _why on it. I think it’s my favorite souvenir. I drank a lot, and went to a matsuri (street fair) where I saw weird dancing robots. I ate a lot of food that I probably would have refused had I known what it was. Most of it was great, though I did manage to go to the TGIFriday’s of Japanese food one night.

Oh – and there were other talks. They were great! I particularly enjoyed Yasuko Ohba’s talk on writing DSLs in Ruby. You can get the full set of videos – most of them are quite good. There were quite a few talks on scientific computing and numeric libraries in Ruby. I’m glad I don’t have to work with them, but I’m glad someone’s doing them.

Geek culture

I saw a lot of threadless tshirts and baggy jeans – geeks the world over dress the same. That goddamned “#shirt” shirt was everywhere too. I saw at least one Ruby committer packing his own (large) bottle of sake. I did a pair programming subevent, and was able to pair with a couple of Japanese programmers. It pretty much felt like pairing at Pivotal (that’s a good thing). Smart people, it seems, can communicate with each other even when there’s a language barrier. Particularly when there’s a common (formal) language.

I am already making plans to attend RubyKaigi next year. Thank you very much to Masayoshi Takahashi and Shintaro Kakutani, and all the other organizers and volunteers. Fabulous event.

went out for groceries, found this.

Asakusa is the neighborhood in Tokyo where we were staying. It was a fortuitous choice.

The first night we were there, my friend Iku and I walked to a sento – and old-style Japanese bath. (Note: bathhouses in Japan don’t have the same connotation that they do in the U.S.) It was incredibly relaxing, after 12 hours on the plane, to wash and sit in the hot water. According to Iku, who’s Japanese, traditional sentos are hard to find in Japan these days. Asakusa is evidently one of the few places in Tokyo you still can.

So I liked it a lot. The rest of Tokyo sometimes felt like an entire city made out of Times Square. Asakusa, on the other hand, is wonderful mix of residential zones, old-style buildings, and modern-ADD-blinky commercial areas.

The second afternoon we were there, I went out to find a grocery store and randomly stumbled across this gigantic gate, called the Kaminarimon. I did also eventually find the grocery store with its $5-a-piece peaches.

I posted the picture to Twitter, and Shintaro Kakutani saw it, recognized it, and invited me to their meetup. So Sarah and I took the subway a few stops down on Tuesday night. I brought my laptop, prepared to hack, but the schedule was more oriented towards the “meet” part of meetup.

• 19:45 Introductions
• 20:15 Drinking

Here’s the aftermath:

Akira Matsuda & Shintaro Kakutani BEER BEER BEER MEAT BEER

You guessed it... MOAR BEER

It was fantastic. I am told there is usually more hacking, but beer is a great social lubricant. I’m incredibly self-conscious about speaking Japanese, because I know I’m not very good. But somehow, when I have beer, I don’t care as much.

Aaron Patterson, in his RubyKaigi talk, said that people are interpreters with very forgiving parsers. As it turns out, he’s right! So even though I speak horrible Japanese, my meaning got through most of the time.

I’m eternally grateful to all the Asakusa.rb folks for not outright laughing at me whenever I opened my mouth and said something inappropriate or totally nonsensical. Which I’m sure I did often.

Sarah and I had such a good time, there and at RubyKaigi later in the week, that we decided to ask Asakusa.rb to be officially friendly with SF Ruby. Akira sort of had to say yes. After all, we gave him Ghiradelli chocolate.

CHOCO

So now we are sister meetups, and Sarah and I are official members of Asakusa.rb (we’re even on their twitter list). Next time: hacking and beer together. Hopefully in New Orleans.

Until then, ありがとうございます Asakusa.rb, for making me feel so welcome in a place that otherwise felt a little alien. Geek culture really does transcend the language barrier.

How do you start, and how do you know you’re finished? What do you test, and where? These questions can be answered hundreds of different ways, but here’s my way.

The first code I write: a feature

As a developer, rather than a designer, I’m always tempted to start with unit tests and work out towards a cucumber feature (“inside-out” testing). But that approach gets me into no end of trouble. I usually end up writing and testing stuff on the model that I don’t ultimately need. Plus once I’m down in the weeds coding, I lose track of the big picture.

So I like to do outside-in testing instead. I start each story I get from tracker with a cucumber feature that expresses how the PM will be able to accept it when I’m done. The feature helps me frame the problem properly, and focus on doing exactly what I need to make it work. Since I come back to it periodically while I’m coding, I keep focused on the higher-level goal. And finally – if I write it first, I can’t skip writing it once I’m done.

Before we get going…

There are certain types of tests I don’t write in this example (and in some cases, at all). Let’s get those out of the way so you don’t have to come up with a scathing comment at the bottom of the post.

• Model tests. In this example, my model doesn’t do anything other than default ActiveRecord behavior, so it doesn’t need any tests. Don’t test rails internals. Once my model has custom behavior, it will have specs, too.
• View tests. I have no tests that verify that my markup is what I expect. That’s because they’re a waste of time. Yes, even with complex views. Verify behavior with cucumber tests, unit-test Javascript with jasmine, and leave the rest to the humans. You’ll waste more developer time maintaining them than it would take humans to verify them. Verifiers are a whole lot cheaper than developers.
• Error case tests. In this example, there are no error cases. The model has no validations, and the table has no constraints. Once there are error cases, I generally put those in the model if I can, in the controller when I have to, and never in the cucumber tests. The latter is mostly a suite-speed consideration – cucumber tests run much more slowly than rspec. Cucumber’s great for for happy path tests; I leave the rest to rspec.

Let’s get going!

The first feature

Say I’m doing a library app and the first story is “User can enter a new book into the system.” Before I write any other code, I write this feature:

Feature: User manages books
  Scenario: User adds a new book
    Given I go to the new book page
    And I fill in "Name" with "War & Peace"
    And I fill in "Description" with "Long Russian novel"
    When I press "Create"
    Then I should be on the book list page
    And I should see "War & Peace"

Starting the fail-fix cycle

I run it using cucumber features, and it fails on the first line – Given I go to the new book page – because cucumber doesn’t know where the “new book page” is. So I add that to the cucumber paths helper.

    when /the new book page/
      new_book_path

Now when I run cucumber, it fails because it can’t find new_book_path. So I add that to routes.rb:

  map.resources :books,  nly => [:new]

Now when I run cucumber, it complains that it can’t find the BooksController. That means it’s time to dive down to rspec controller tests.

My first spec experience

I create books_controller_spec.rb in spec/controllers, and add a test for the new method:

require File.expand_path(File.join(File.dirname(__FILE__), '..', 'spec_helper.rb'))
describe BooksController do
  describe "#new" do
    it "should be successful" do
      get :new
      response.should be_success
    end
  end
end

When I run this spec, it complains that there is no BooksController. Fixed:

class BooksController < ApplicationController
end

I re-run the spec and get "no action responded to new." So I add the new method.

class BooksController < ApplicationController
  def new
  end
end

Now the spec passes! Time to check back with cucumber.

Getting past the first line

I read through my cucumber feature again:

Feature: User manages books
  Scenario: User adds a new book
    Given I go to the new book page
    And I fill in "Name" with "War & Peace"
    And I fill in "Description" with "Long Russian novel"
    When I press "Create"
    Then I should be on the book list page
    And I should see "War & Peace"

Last time I ran it, it failed on the first line because it couldn't find the BooksController. This time, same location, but it says it can't find the view. So whiny! To placate it, I create an empty view called new.html.erb and run it again.

Now cucumber gets past line 1 (huzzah!!) and fails on line 2 (And I fill in "Name" with "War & Peace") with the message that it can't find a field called Name to fill in. So I add a standard rails form to the view.

<%- form_for @book do |f| -%>
    <%= f.label :name %>
    <%= f.text_field :name %>
    <%= f.label :description %>
    <%= f.text_area :description %>
    <%= f.submit "Create" %>
<%- end -%>

Uh oh. Cucumber is mad at me because there is no @book object. Back to rspec for me!

rspec: The Return

In my controller's new method, I need to create a book object that the form will use. I first add a test for that in the controller spec:

require File.expand_path(File.join(File.dirname(__FILE__), '..', 'spec_helper.rb'))
describe BooksController do
  describe "#new" do
    before do
      get :new
    end
    it "should be successful" do
      response.should be_success
    end
    it "should create a book object" do
      assigns(:book).should_not be_nil
    end
  end
end

This fails the right way - it says assigns(:book) is nil. So then I add the creation of the book object to the controller.

class BooksController < ApplicationController
  def new
    @book = Book.new
  end
end

Now the spec fails, saying it can't find the Book class. It has a point - I haven't created the model yet. Fixed:

class Book < ActiveRecord::Base
end

Now it fails saying it can't find the books table. So I write a migration that creates that.

class CreateBooksTable < ActiveRecord::Migration
  def self.up
    create_table :books do |t|
      t.string :name
      t.text :description
    end
  end
  def self.down
    drop_table :books
  end
end

Once I do rake db:migrate and rake db:test:prepare, I re-run my controller spec....and it passes! Back to the cucumber feature!

Cucumber...again.

In our last episode, cucumber was visibly annoyed because there was no @book object for the form to operate on. I run it again to see if it's still sulking.

Yep. This time it tells me that it can't find books_path. form_for tries to submit to the create path by default, which I haven't added yet. I add it to the routes.

  map.resources :books,  nly => [:new, :create]

This time, when I run cucumber, it gets through the first three lines (woo hoo!) and fails on the 4th, saying no action responded to create. Back to the rspec-cave, batman!

rspec: The Sequel to The Return

I add a controller spec for the create method.

  describe "#create" do
    it "should create a new book" do
      post :create, "book" => {"name" => "Jane Eyre", "description" => "Something Victorian"}
      assigns(:book).should_not be_nil
      assigns(:book).name.should == "Jane Eyre"
    end
  end

When I run it, I get the same message as in cucumber: no action responded to create. So I create the create:

class BooksController < ApplicationController
  def new
    @book = Book.new
  end
  def create
  end
end

Now when I re-run the spec, it fails saying that assigns(:book) is nil, which makes sense. I put in the guts of create to make that pass.

  def create
    @book = Book.new(params[:book])
    @book.save
  end

Now rspec passes! Back to cucumber.

So...cucumber. We meet again.

When I re-run the feature, it says I'm missing a template for create, which is correct. However, in this case, I don't want to make a template for create - I want to redirect to the book list page. So once again, I'm back with rspec.

rspec: Back so soon?

I add that expectation to the controller spec for create.

    it "should redirect to the book list page" do
      response.should redirect_to books_path
    end

It fails saying there's no redirect. So to make it pass, I add a redirect to the controller code.

  def create
    @book = Book.new(params[:book])
    if @book.save
      redirect_to books_path
    end
  end

Now my controller specs pass. Cucumber, I'm coming for you!

Oh, you again.

Last time, we got through the first 3 lines of the feature and failed on line 4 (When I press "Create"). When I run it this time, it gets through the same 3 lines and then fails in the same place again, saying that no action responded to index. I add index to the routes.

  map.resources :books,  nly => [:new, :create, :index]

I re-run the feature and get the same error message. WTF, cucumber?! It turns out that rails' implementation of REST uses the same path helper for create and index, so the path helper for index already exists, even though the method does not. A little strange, I know. But we need an index method, so it's back to rspec.

rspec: For the first time, for the last time...

I write a spec for the index method.

  describe "#index" do
    it "should be successful" do
      get :index
      response.should be_success
    end
  end

I still get no action responded to index. So l add the method in BooksController, empty to start.

  def index
  end

Specs pass, back to cucumber!

How can I miss you if you won't go away?

Cucumber tells me there's no template for index. So I create an empty one, and re-run. This run, for the first time, I pass line 4 (yaaaaay) but then it fails on line 5 (Then I should be on the book list page) because it can't figure out what I mean by "the book list page." That goes in the cucumber path helper.

    when /the book list page/
      books_path

OMG five out of six steps pass! Now cucumber says it can't find "War & Peace" on the page, so let's make the index view list the existing books. Back to rspec...

Don't go away mad...just go away.

I add the following it block to the spec for index.

    it "should assign a list of existing books" do
      Book.create!(:name => "Endymion", :description => "weird")
      get :index
      assigns(:books).should_not be_nil
      assigns(:books).length.should == 1
    end

It fails because I'm not creating @books in the controller, so I fix that.

  def index
    @books = Book.all
  end

Now the specs pass - back to cucumber.

We really have to stop seeing each other like this.

Cucumber still says it can't find War & Peace, because I haven't added printing out the books to the index view. I'll fix that.

<%- @books.each do |book| -%>
    <%= h book.name %>
    <%= h book.description %>
<%- end -%>

Re-run cucumber and ... ta-da! The feature passes! I've done everything I need to call the story done. I have the minimum amount of code I need, because all the code I wrote was driven by the feature. Story: delivered!

You’re welcome to bring any sort of Ruby-related project! The theme for the evening is Javascript testing, following on this month’s monthly meetup. But I won’t make you write any Javascript if you don’t want to.

The peninsula has all kinds of neat hack events like SuperHappyDevHouse and various Hacker Dojo events. But I hate driving all the way down there just to hang out with hackers and get something done on a project. There are plenty of hackers in San Francisco. There might even be more of the type of hackers I want to hang out with.

So I’ve decided to host a monthly hack night, to be held on the Tuesday following the monthly SF Ruby meetup. My employer, Pivotal Labs, has graciously volunteered their space. Since tonight is the SF Ruby meetup, the next hack night is next Tuesday, April 27th, from 7-9:30 (ish).

RSVP now! See you next Tuesday.

• Shoes – a simple way to create desktop applications in Ruby. Cross-platform, pure awesome. (code on github)
• Hackety Hack – built on Shoes, this is a toolkit specifically for learning how to program.
• Small Ruby – learn to program for the smaller set – think turtle drawing. Coming soon.
• PDF version of the slides (exactly the same as slides below)

LEARN ME

…is now open for registration. Last year Sarah Allen and I did three workshops for women and this year we’re going for four. So, if you’d like to learn Rails and can come BOTH Friday, February 26th in the evening AND Saturday, February 27th during the day, go sign up! There are only a few spots left.

And yep, still free.

We’re also seeking Rails developers (of any gender) to assist as TAs. Tell us about that here. Past TAs and teachers have found it quite rewarding. Plus you get a drink ticket for the afterparty.

And finally, some logistics: it’ll be in an office space in downtown San Francisco, near transit. Next week we’ll send out the exact address. We’ll have informal childcare and space for pumping or nursing – please tell us if you think you’ll be using those services when you register.

See you there!