A single installation of the Diaspora software is called a pod. The Diaspora distributed network is made up of hundreds of these pods, each with a set of users – sometimes just one on an individual pod, sometimes tens of thousands on a community pod. Each pod is run by a different person or organization. But no matter what pod you sign up on, you can connect with users on any other pod.

When you have friends on different pods, your stream seamlessly mixes updates from remote friends with updates from friends on your pod. In this way Diaspora is a distributed social network that resembles, from the user’s perspective, a centralized social network.

But how do these users find each other? In a centralized system, all servers access the same database, so when you search for a friend, there’s only one place to look. But in the Diaspora ecosystem, each pod has its own database, inaccessible to the other pods. So how does pod A figure out who’s on pod B, or for that matter, pod C that’s never been heard from before?

It all starts with searching. Let’s say you’re setting up your own pod. Once you’ve downloaded the Diaspora source and gotten it running on a server accessible to the internet, you open it up, log in…and are faced with the vast emptiness of splendid isolation.

Let’s get you some friends

There is no central server that keeps a list of existing pods or existing users. Instead, Diaspora depends on an emerging-standard protocol called webfinger to discover users on remote pods. This all kicks off when you search for someone’s Diaspora ID in your pod’s search box.

Aside: A Diaspora ID is made up of a username, followed by an @ sign, followed by the pod url. It looks a lot like an email address. But just like with Jabber IDs which also look like email addresses, you can’t send email to it. It’s just a unique identifier within the Diaspora ecosystem.

So you’ve talked to a friend who’s on a (fictional) pod called otherpod.com, and you’ve gotten her Diaspora ID – sarah@otherpod.com. You want to connect, so you put sarah@otherpod.com into the search box on your pod and hit go. A few seconds later, you see her information on the search page with a nice “Add to Aspect” button alongside.

Magic!

I’d love to claim that, but sadly ponycorns are in short supply around here. Here’s how it goes down behind the scenes. A detailed explanation follows the diagram.

How a Diaspora pod finds a user on a different pod

When it gets a search request for a Diaspora ID, the first thing your pod does is look in its local database to see if it already knows about this person. This is the grey diamond in the diagram. If it can skip all this drama and just show you the information, it does so. But because you’re on a brand new pod, the only user it knows about is you. So it prepares to retrieve the information you requested from the remote pod.

From here the process is:

1. Figure out where to search
2. Search
3. Retrieve detailed information
4. Cache data locally
5. Profit!

I suppose the last one is optional.

1. Find out where to search

Your pod extracts the pod URL from the Diaspora ID (sarah@otherpod.com becomes otherpod.com) and appends a standard location called “the host-meta route” to get this URL:

http://otherpod.com/.well-known/host-meta

This route is part of the webfinger standard. It’s the basic way you ask a server whether or not it supports webfinger.

Your pod then accesses this location and gets back a piece of XML in a format called XRD. Basically, accessing the host-meta route is the same as asking the pod, “How should I send you inquiries about users?” The XRD document that it returns tells your pod how to construct the query for the particular user you’re interested in. Here’s what it looks like:

The “template” on line 4 is the key. It tells your pod to query for the user by substituting their Diaspora ID for {uri}. So to search for your friend, your pod needs to construct need a URL like this:

https://otherpod.com/webfinger?q=sarah@otherpod.com

Aside: All Diaspora pods accept user queries at the same location, so this step might seem redundant. But Diaspora pods also inter-operate with other, non-Diaspora social systems, and those may have different locations for querying for a user. In other words, when we get a Diaspora ID, we don’t actually know whether the pod is a Diaspora pod or something else. So we ask for the search route each time.

2. Search

Having figured out the right way to ask, your pod now queries for the user it wants. It accesses the query URL:

https://otherpod.com/webfinger?q=sarah@otherpod.com

This returns us another piece of XML – another XRD document – that gives us some basic information about the user, but mostly just tells us where to go to find more detailed info. Here’s what it looks like:

Aside: The webfinger XRD document is supposed to be just links to information elsewhere. However, as you can see, Diaspora embeds some actual information, such as the person’s public key, in the document. We implemented this before we fully understood how XRD was supposed to work. We should at some point move that information to the hcard (see next section).

3. Retrieve profile

To fill out profile details, the pod extracts the “hcard location” from the webfinger XRD document. An hcard is a standard, structured way to represent profile data in HTML. The hcard location is on line 5 of the document above, with URL:

https://otherpod.com/hcard/users/4cec1e372c174347b90000ad

Your pod accesses the hcard location, and gets back a piece of HTML with additional profile details for the remote user, such as name. Here’s an excerpt of that hcard – it’s quite long.

It goes on, but I think you get the idea.

4. Cache data locally

Finally, having searched for the user and then retrieved her hcard, your pod extracts the profile details and saves them in its local database. sarah@otherpod.com now shows up in searches you do on your pod.

5. Profit!

Once you start following your friend, you’ll get her updates as though she were a user local to your pod. If she also follows you, she’ll get your updates in her stream too. From there…who knows what could happen.

This walkthrough covered just searching and basic user discovery, which is a tiny part of how Diaspora pods interoperate. Once you get into federation of posts and other content between pods, it’s a whole different ballgame. Stay tuned for that in an upcoming installment.

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.

When I first started poking around the codebase a few months ago, they’d just started writing a few cucumber selenium integration tests – which of course I want to encourage! – but they weren’t running them on their continuous integration box. And if you aren’t running them on CI, you can’t really call them tests…

It’s not that the developers were lazy; it’s just that Diaspora’s CI box is an ubuntu server instance that doesn’t even have xwindows. There’s no way to attach a display, and without a display, a browser won’t run. So how can you run selenium features that have to actually open a browser window and click on stuff?

I’m glad you asked!

You set up a virtual framebuffer – essentially a simulated display – and run your features in there. Here’s how I got this going.

Step 1: Install Crap

Yeah, you need xwindows, and a bunch of other stuff. I’m not a frequent linux user, so I was surprised that a lot of these commands appeared to fail, with extremely lengthy output about how such-and-such dependency could not be installed, or compiled, or resolved, or kafloozled, or whatever. But then when I ran the programs that supposedly weren’t installed, they worked fine. …thanks, ubuntu?

sudo aptitude install xubuntu-desktop
sudo aptitude install exaile
sudo aptitude install gconf2
sudo aptitude install xvfb
sudo aptitude install firefox

Step 2: Verify Your Virtual Framebuffer

I like the phrase “virtual framebuffer.” It’s very computer science, and using it makes me feel smart. But really, it’s just a display that gets rendered in memory, but not output to any monitor. Programs that require the ability to create windows, such as Firefox, need a display to run in – but they’ll take any old display. If you give Firefox a virtual framebuffer, it’s perfectly happy and treats it like any other display, even though no one can see it.

So let’s verify we have everything set up to run one. This magic incantation starts one on display port :99.

 Xvfb :99 -ac -screen 0 1024x768x16

In another shell, run this one, which opens Firefox to example.org inside the virtual display you’re running in the original shell.

DISPLAY=:99.0 firefox http://example.org

Firefox is now open to example.org, the world’s most boring webpage. Really! Let’s prove it by taking a screenshot in a third shell.

xwd -root -display :99.0 -out xwdout

Your screenshot is now in a file called xwdout. Sadly, this is not an image format that normal image viewers can see, so let’s convert it to a jpeg.

convert xwdout screenshot.jpg

Using your favorite sftp program, retrieve screenshot.jpg and have a look at it. It should look something like this:

That boxy UI, those icons from 1995...it could only be linux.

Ta-da! You have evidence of this so-called “virtual” framebuffer. Now all we have to do is set it up so to start before we run the tests, and stop once the tests are done.

Step 3: Adventures in Shell Scripting

This goes in your /etc/init.d, and will give you ULTIMATE POWER, if ultimate means you can start and stop a virtual framebuffer on display port :99.

Now you just need a rake task that starts the display, passes the port info to the tests, and then stops it.

And just in case you have to get this running with rvm, here’s the shell script that cc.rb calls to kick off a Diaspora build on ruby 1.8.7.

I’ve had to set this up twice, now, but there are a lot of moving parts. If you try this and notice something I forgot, please let me know.

Enjoy your headless cucumbers…

(I wonder what kind of google search results that will get me.)

A few weeks ago I made a slightly more controversial change.

The “gender” field in a person’s profile was originally a dropdown menu, with three choices: blank, male, and female. My change made it an optional text field that was blank to start. A wide open frontier! Enter anything you want.

For a while, only a few people noticed.

But now that Diaspora is in private alpha, more people have started noticing – on twitter, in the bug tracker, and in GetSatisfaction, among other places. Some folks have asked why it’s not a dropdown with two options like everywhere else. So here’s why.

…what else is there?

Four years ago, at my first rails job, I worked at a company with a mostly-lesbian customer base. It turns out, in that context, knowing if someone is “male” or “female” gives you almost no useful information. The lesbian community has other widely-accepted categories of gender, but the company’s internal order tracking software — a well-known package from a national vendor — offered only male or female.

As a result, the company didn’t even bother to ask for gender when users created accounts.

That was my first real-life experience with the limitations of the gender binary. It was certainly interesting, but it was essentially academic. Not long after I left that job, though, one of my closest family members told me that he’s transgender. That made the whole subject way more immediate.

Now it’s personal

So in the last few years I’ve tried really hard to understand what being transgender means. I’ve done a lot of reading and talking and thinking about how we construct a gender identity, and how we perceive others’ gender. I’m certainly no expert, having not lived it myself. But I have discovered that my own gender identity is a bit more fluid than I thought. And perhaps most importantly, I’ve gotten comfortable with the idea of gender as an n-dimensional space, with two big clusters and a hell of a lot of outliers.

Then I met Sarah Dopp at She’s Geeky, and we talked about dropdown menus, and it all fell into place.

tl;dr

I made this change to Diaspora so that I won’t alienate anyone I love before they finish signing up.

I made this change because gender is a beautiful and multifaceted thing that can’t be contained by a list.

I know a lot of people aren’t there with me yet. So I also made this change to give them one momentary chance to consider other possibilities.

I made it to start a conversation.

I made it because I can.

And, of course, I made it so you can be a smartass.

a selection of the gender self-descriptions of my contacts on diaspora

Go out and have fun with it.

Diaspora is an open-source social network that puts you in control of your information. As of today, November 27th, we’ve been live less than a week. Here’s a quick overview of the project, and if you want more news, our blog. Thanks for visiting!

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.

In practice, I’ve discovered, it’s another story entirely. After spending the better part of ten days, recently, integrating Facebook into another website, I have new rules for how I use Facebook. I realize they sound a little tin-foil-hat-style crazy, so after the rules I’ll explain a bit about why I adopted them.

Image by CycleDog

Rule 0: I’m not closing my Facebook account. I know a few people who have gotten off Facebook entirely, recently, but Facebook is the only place I’m in touch with my cousins who live out of state, my best friends from elementary school who are scattered to the wind, and my husband’s family who live on the east coast. These people aren’t going to get on Twitter, and I do want to hear about their lives.

Rule 1: I always browse Facebook in a separate browser. If I’m doing my random web browsing in Firefox, then I open Facebook in Chrome (or less frequently, Safari). It’s not sufficient to open Facebook in a different window of the same browser, or a different tab of the same browser. It has to be a different browser. (If you only have one browser right now, you can install Firefox here, or Chrome over here.)

Rule 2: I make sure my non-Facebook browser has no residual FB cookies. I used to just leave a Facebook tab open while I browsed random web sites in other tabs, but that’s incredibly dangerous. If I am logged in to FB, any of those third-party sites could be silently collecting my Facebook information without notifying me. Once I decided to separate my browsing, I deleted all cookies in my non-Facebook browser. As long as I don’t log in to FB again in that browser, other sites won’t be able to access my Facebook information.

Rule 3: I never browse anywhere else in the Facebook browser. I use Chrome for Facebook, so I don’t use Chrome for anything else. Any external links I want to click on from Facebook, I open in Firefox. This can be a pain in the ass because links on FB usually redirect you through another FB page. So in FB, I right click the link, select “Copy link location”, switch to Firefox, paste the link in, edit it to remove the Facebook prefix, and then hit return to go there.

In practice, I do use Chrome for other stuff, but I log out of Facebook and clear all my cookies first. Which leads to…

Rule 4: I always log out of Facebook. They’ve hidden the log out option; it’s at the top right, the last option under “Account.” It’s not sufficient to close the Facebook window, or even to quit the browser you’re using for Facebook. In either case you leave behind a set of “logged in” FB cookies that other sites can read. I always explicitly log out of FB when I’m done.

Rule 5: There is no rule 5.

Rule 6: I never use Facebook to log in to another web site. Any web site can use Facebook as their log in system, instead of (or in addition to) letting visitors create accounts. Most of these sites are not officially affiliated with Facebook. It’s convenient to use FB for this, sometimes, instead of creating yet another username and password to remember.

But it’s also dangerous. When I authorize a site to use Facebook to log me in, that site can then access my name, my email address, all the schools I went to, all my employers past and present, my interests and hobbies, my pictures, my wall, my messages, and my friends. Among other things. And the site may hold on to that data, so even if I change it or hide it in Facebook, it’ll be in their database in perpetuity. Since the site isn’t affiliated with Facebook, it’s not bound by their privacy policy, so who knows what it will do with the information? It’s way better to just set up another account with a throw-away username and password.

Feeling crazy yet?

I am. Or maybe “paranoid” is a better word. Before I started working with the Facebook API, I had no idea how much information was available to third-party web sites. Things I don’t think of as public – including my email address – are available by default.

There are, of course, terms of service that those sites have agreed to, but nobody checks or audits them. It’s trivially easy to sign up for a developer account, create a Facebook application, stick some Javascript on a site, and start collecting the data of unwary FB members who visit you.

The public/private dilemma

Honestly, most of the information I have on Facebook is public knowledge anyway, including my email address. But it doesn’t sit well with me that FB lets third-party sites access information that non-friends can’t see. What else might they decide to share someday – the links I’ve clicked on? The groups I’ve visited but not joined? The exes I’ve searched for?

By keeping Facebook quarantined, I hope to contain the fallout of any future “experience enhancements.”

And now, if you’ll excuse me, I need to go use my hat to make dinner.

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!