Simple Chatter

RubyConf 2008

2008-11-20T03:11:00Z

I was lucky enough to attend RubyConf 2008. I really enjoyed last year's conference, and I felt this year was better.

There was lots of great content, and more than handful of time slots where I wanted to attend both. I'm eagerly waiting for Confreaks to post all the talks so I could watch the ones I missed, as well as re-watch the ones I attended.

Among all the talks I attended, there were three talks that really enjoyed.

Ruby Heavy-Lifting: Lazy load it, Event it, Defer it, and then Optimize it

This was given by Ilya Grigorik of AideRSS, and was my favorite talk of the weekend. Ilya went over their experiences developing PostRank and main optimization techniques they used with Ruby.

Primarily:

Message Queues
EventMachine
Process Forking
Custom C Extensions

Ilya didn't just gloss over each point in a tutorial fashion, but instead described how they used each item and the resulting effects.

It was very refreshing to hear someone speak of their roadblocks and creative solutions to work around them. Hearing that PostRank is making around 5 million requests per day, and is spread over 100 servers is pretty inspiring.

What Every Rubyist Should Know About Threads

Jim Weirich from EdgeCase gave this talk. Now I've been interested in fairly interested in concurrency this year. Especially as we see hardware trends stalling out on speed and moving towards multiple cores. I really appreciated this talk for two reasons.

First, it shamed me. Yup, I'll admit it. As snobby as I acted about concurrency, and as much as I touted I understood deadlocking and thread safety code, Jim's talk exposed me to my ignorance, and for that I'm very grateful.

This talk may not appeal to others the same way it did to me, however for those interested in threading basics as well as virtual machine quicks this was worthwhile.

Dramatis: Actors for Ruby

Steven Parks gave a great talk about his Actor-based Concurrency library for both Ruby and Python Dramatis. Now Dramatis is rather young, but has a lot of potential. Not to mention Steven's presentation and conversation afterwards indicates he has been working in this particular field a while.

Earlier this year I played with Erlang quite a bit, and despite the syntax annoyances, the actor model was very interesting. Steven mentioned explicit vs implicit receiving, which happens to be one of the bold stances this API takes. Erlang is an explicit receive model. Which means the code has to explicitly request the next message.

An explicit receive example with Ruby:

while message = receive
  # do something with the message and then re-loop
end

An implicit receive example:

def some_method
  # this will get called when a message is sent
end

The second example doesn't look too foreign, and that's because it's not. The entire class becomes an API, and the messaging framework calls the appropriate method. When I worked with Erlang, I liked the Actor model, but I didn't like the boilerplate code that was copy-pasted for every Actor.

I don't expect everyone to prefer this type of messaging, but for me it makes the concurrency model more transparent, and the actors easier to read as well as easier to test.

That's a lot of concurrency

As you can tell all my favorite talks all had some connection with concurrency and scale. That's because I've been very interested in scaling Ruby applications. Not because I'm some outside developer who is evaluating Ruby as a language and concerned about FUD. It's because I am a Ruby developer, and I've been writing in Ruby for the past couple years, but I have rarely heard talks addressing scaling.

There were many other great talks at the conference. For those on the fence on whether to attend next year, I definitely recommend it.

Using Cucumber to test Generators

2008-11-15T06:01:00Z

I've been developing in Ruby (and Rails) for the past 2.5 years. Over time, I've molded my own flavor of CRUD controllers and resulting specs. Unfortunately, it's so different than the Rails and RSpec generated code that it takes me as long to alter the code as it does to create it from scratch. However, in laziness, I've pushed off writing my own generators. Until yesterday.

The Issue

Now I'm not a big fan of generated code. However I do agree that the templates fit the basic CRUD functionality nicely. Despite their usefulness, one of the things that irks me about generators is making changes and not being confident if the code generated is valid. Parse errors, invalid logic, and variable misspellings are easy examples to get tripped up on. So I wanted these generators to be tested. Sounds odd doesn't it?

Enter Cucumber

Cucumber is a recent project released that replaces the RSpec Stories Framework. You use it very similarly to the older Stories, but since Cucumber is written with Treetop it provides a lot more niceties. I won't give a tutorial of Cucumber here (perhaps in another post), but I do want to illustrate the flexibility of the testing framework.

When first picking up Cucumber, the immediate use that comes to mind is Rails Integration testing (which it is very useful for). However it can also be applied to domains outside of Rails and even web development. When writing these generators I mainly wanted to know: "when I use a generator, is all the code valid, and do all the tests pass?".

Here's an example of using Cucumber to describe my intentions:

Feature: Generating Controller Templates In order to generate standard CRUD controllers A Developer Should be able to generate a CRUD controller and the resulting specs

 Scenario: Generating Rails CRUD
   Given I'm using a Rails 2.2 code base
   When I generate 'my_controller customer'
   Then 'app/controllers/customers_controller.rb' should be created
   And 'spec/controllers/customers_controller_spec.rb' should be created
   And all the tests should pass

And here's the backing steps to accomplish the feature:

Given(/^I'm using a (.*) code base$/) do |key|
  key = key.downcase.gsub(" ", "")
  available_codebases = { "rails2.2" => File.join(codebases_path, "2.2") }
  available_codebases.keys.should include(key)

  blast_and_create_tmp!
  extract_codebase!(key)
  @current_codebase = File.join(tmp_path, key)
end

When /^I generate '(.*)'$/ do |command|
  `#{@current_codebase}/script/generate #{command}`
end

Then /^'(.*)' should be created$/ do |file_path|
  File.exist?(File.join(@current_codebase, file_path)).should be_true
end

Then /^all the tests should pass$/ do
  output = `cd #{@current_codebase} && rake spec`
  output.should_not match(/\s0 examples/i)
  output.should match(/0 failures/i)
  $?.exitstatus.should == 0
end

I have all the code in github if you want to see the working example of code.

Pretty straightforward and sexy.

Public Stream of Consciousness

2008-11-13T01:30:00Z

I've heard a few people on Twitter not sure about the etiquette on following others. Particularly:

If you are following me, is it rude if I don't follow you?

Twitter makes this difficult for two reasons

Twitter is slightly more personal than other social networking applications
Everyone uses Twitter in a different manner

I use Twitter as my Public Stream of Consciousness

This means about approximately 93.76% of my posts are dismissible. I have a very scientific process for analyzing my tweets that involves starting with "9", and choosing three digits at random.

See? That's a perfect example of the type of garbage that I flood the internet with.

However, unlike other people, I am perfectly ok with others not following me. I won't be insulted if others don't want to subject themselves to my endless stream of rants. If I do get upset, that's my issue to deal with or adjust my behavior to suit.

So if Twitter is becoming less fun for you because I'm flooding your fire hose, but you feel I'll think less of you if you don't follow me back; don't worry about it at all.

Not many recent postings

2008-09-13T22:23:00Z

I've been pretty quiet on this blog for the past few months. Mostly due to being extremely busy, but I'm sure a part of it is the "Blogger Neglect" that most new writers encounter.

However I did want to mention that we at Elevator Up have been sending out a newsletter. They really aren't company updates, but rather about ideas, business philosophies, and sometimes our experience playing with new applications. Up to now we've only sent them to a subscriber mailing list. Just recently, we've decided to cross post them on a company blog.

Some of my favorite recent articles:

Custom Textmate Commands

2008-04-01T19:31:00Z

Textmate is a pretty decent editor for OSX. I'm not in love with it, but we use it frequently at Elevator Up.

There is a plethora of plugins for Textmate to ease editing in different contexts, but sometimes you want to hack you're own commands.

For small scripting tasks, I tend to continue to use ruby. So I enjoy it when I can continue using it for the commands.

You can typically use this shell for a ruby command, and your printed output gets replaced within Textmate:

#!/usr/bin/env ruby
$: << ENV['TM_SUPPORT_PATH'] + '/lib'
input_from_tm = STDIN.read
puts "hello world!"

Here is an example of code block toggling for Markdown.

#!/usr/bin/env ruby
$: << ENV['TM_SUPPORT_PATH'] + '/lib'

s = STDIN.read
ends_with_newline = s != s.chomp
lines = s.split("\n")
lines.each_with_index do |s, index|
  s =~ /^(\t)?(.*)/

  if $1
    print "#{$2}"
  else
    print "\t#{$2}"
  end

  print "\n" if index != lines.size - 1
end

print "\n" if ends_with_newline

And a screenshot to include the Textmate command options:

Using Capistrano 1.4 with 2.x

2008-03-31T14:48:00Z

At Elevator Up we typically use Capistrano for deploying our applications. Though I do have a bookmark to investigate Vlad when I get some time.

We've been a bit slow to upgrade to Capistrano 2.x, and have a lot of existing applications that depend upon Capistrano 1.4 for deployment.

One tactic we've taken is to write a custom script to explicitly use 1.4 in conjunction with 2.x. A minor hack from the original, and we have:

#!/usr/bin/env ruby

begin
  require 'rubygems'
  gem 'capistrano', '<= 1.4.1'
rescue LoadError
  # no rubygems to load, so we fail silently
end

require 'capistrano/cli'

Capistrano::CLI.execute!

I threw this into a script called cap1.4 in /usr/local and can now do:

illian:~ zach$ cap1.4 -V
Capistrano v1.4.1
illian:~ zach$ cap -V
Capistrano v2.1.0

Obviously, a better approach would be to freeze in the capistrano gems per project, and access them via RAILS_ROOT/script/cap, but that too has been time sensitive. Notice a trend here?

Commonly overlooked usage of named routes

2008-03-30T18:06:00Z

Given a route :

ActionController::Routing::Routes.draw do |map|
  map.foo "foo/:first/:second", :controller => "foo", :action => "something"
end

Obviously you can pass in :first and :second via:

foo_path(:first => "the first param", :second => "the second param")

However, for a more concise call, you can accomplish the same via:

foo_path("the first param", "the second param")

It's not explicitly documented, but you end up doing the same thing with nested resource paths

Watch Star Wars via Telnet

2008-03-30T06:05:00Z

I love stuff like this. You can watch Star Wars via telnet.

I know it's old, but still fun.

One of the best HTML / CSS theme songs

2008-03-30T03:03:00Z

I don't normally repost from other sites, but this was too good.

Stolen from Janson, with thanks to Implodr.

Testing content_for

2008-03-29T16:57:00Z

After we started writing view specs we came across views similar to this:

<p>Stuff in the main content area</p>

<% content_for "secondary_content" do %>
  <p>Stuff that will go in an side panel in the view </p>
<% end %>

Obviously when rendering the view inside the spec, only the blurb about main content area will be in the response.body. For instance the second spec written will fail:

describe "/path/to/view" do
  def do_render
    render "/path/to/view"
  end

  it "should have blurb about main content" do
    do_render
    response.should have_text(/main content/i)
  end

  ##
  # This won't pass.
  ##
  it "should have blub about side panel" do
    do_render
    response.should have_text(/side panel/i)
  end
end

However, you can shove something in your spec_helpers.rb to test items inside the content_for blocks.

def content_for(section)
  template.send(:instance_variable_get, "@content_for_#{section}") || ""
end

And rewrite your spec like this:

describe "/path/to/view" do
  def do_render
    render "/path/to/view"
  end

  it "should have blurb about main content" do
    do_render
    response.should have_text(/main content/i)
  end

  ##
  # This will now pass
  ##
  it "should have blub about side panel" do
    do_render
    content_for("secondary_content").should match(/side panel/i)
  end
end

The have_text() matcher won't work, but you can use the have_tag().

If you haven't toyed with content_for, I suggest looking into it. It will help clean and organize your views and layout(s).

Education vs Justification

2008-03-24T00:22:00Z

Aaron, Janson and I were at Applebees a month ago discussing an estimate for a client. We started talking about a particular part of the estimate that would require us to take more time than usual. We worked on their project previously, and used a few testing practices that we've stopped since. I wanted the estimate to include the refactoring of the code, but not publicize the fact. Aaron wanted to communicate with the client our exact intent.

Now keep in mind, I have no qualms about transparency with clients. And I don't go to great lengths to keep clients in the dark, as some of my previous work environments have. My point was that refactoring the code and the tests was a necessary step of development. I didn't want to publicize those specific intentions because I didn't want to come across that they were optional. In other words, I didn't want our client to think that the one of our values, quality software in this case, was negotiable.

Now, I know I may be coming across rather harshly. And I may appear as the developer with blinders, who tells everyone "Just trust me, you won't get screwed." This was exactly how I portrayed my perspective to Aaron and Janson, who more or less disagreed with me for those exact reasons. We debated for a bit longer, while eating our lunch, and I finally had the Eureka moment.

Our job is a technical one. Not only does it involve many hours of learning, but it takes the obsessive-like passion to stay current. It is rather rare for clients to possess the technical knowledge, or the experience involved in constructing quality software. However they know their domain intimately, and for a developer to play the "trust me" card in a bit arrogant. As a developer, I often forget that.

Help educate them

I was feeling as if I had to justify our development practices to the client. It made me upset that I needed to have them approve my reasoning in deciding to refactor older code. Yet as I was getting worked up, it dawned on me, the client hadn't even seen the estimate. I was already prepping counter arguments, as well as previous experiences to sell my decisions which required more work.

Listening to Aaron and Janson, I realized the client didn't need justification. They weren't bringing my decisions into the light in order to criticize my knowledge as a developer. They merely wanted to match the impact of my decisions with what they knew. They sought to understand the reasoning behind my decisions.

As I've thought more about that conversation I've come to an important resolution in my career. I should never justify myself to a client, however I should always try to educate our clients. I should spend the effort to tell them the impact of taking alternate routes. I should find better ways to articulate myself and speak their language rather than swamp them with intimidating geek-speak.

Justification isn't evil

While my client's aren't developers, I am, and so is the rest of my team. This brought up the second big question and resolution "How do I know my decision is right?", which led me to: Always justify my decisions to myself, and to my team. I believe a key ingredient in improving ourselves is constant introspection. If I make a decision, and I can't debate myself or a team member on the end result, then it's probably heavily influenced by preference, or even fear.

I should always justify to myself why we test, and the rigorousness of our tests. I should always justify why we should use agile approaches to planning. I should evaluate the reasoning behind using git over svn and whether programming in ruby makes more sense than developing in java.

I've found that it's very easy to surround yourself with a community who evangelizes tools or practices, while not sincerely asking the honest questions. I've also seen a similar pitfalls in ignoring new technologies and trends, because a lack of self-justification.

ALIVE and Treetop

2008-02-23T08:29:00Z

A sweet project

I’m proud to say really fun mini-project went live today. OKWU Alive for Oklahoma Wesleyan University, a very forward thinking college. They wanted a site that is mainly updated by twitter messages.

We used a combination of Radiant, Twitter4R, and an upcoming library Treetop that I heard about a RubyConf 2007. Ever since attending Nathan Sobo’s presentation I’ve wanted to put it to use, but kept putting it off.

The “challenge”

To give some context to the site, OKWU wanted to parse direct twitter messages and add them to the site. The thing that made this interesting, is that they wanted to be able to tag each message. Most messages take on the form of:


  tag : message

Now I could obviously use regular expressions to parse out both the tag and the message, but what fun is that?

Treetop to the rescue

Treetop is structured to take a grammar file, that can be brought into ruby code. Here is the grammar we used to define the twitter message:


  grammar Twitter
    rule status
      tag delimiter message
    end

    rule tag
      [a-zA-Z_0-9-]+
    end

    rule message
      .*
    end

    rule delimiter
      space* ':' space*
    end

    rule space
      ' '
    end
  end

If you haven’t worked with grammar specifications before, don’t feel overwhelmed. What this essentially says is “a twitter status (another definition of a message from twitter) is composed of a tag followed by a delimiter followed by a message.” With each part, you can find a more specific definition. For example, a tag can only take the form of alphanumerical characters, underscores and dashes.

“Ok, that’s neat, but how is it useful?”

The coolness comes in with the consumption of the grammar. Here’s the code that uses Treetop:


  require "treetop" 
  Treetop.load "twitter" 

  parser = TwitterParser.new
  parsed_results = parser.parse("awesomified : you won't believe it's that easy")

  tag = parsed_results.get_tag
  message = parsed_results.get_message
  puts "message: #{message} classified under: #{tag}"

As you can see, Treetop loaded in the grammar and immediately gave me a TwitterParser. From there I parsed an example twitter message, and with the results I retrieved the tag and message.

“Wait, how did you get the tag and message?”

Well, I didn’t exactly show the entire grammar. Here’s the final one:


  grammar Twitter
    rule status
      tag delimiter message {
        def get_tag
          tag.text_value
        end

        def get_message
          message.text_value
        end
      }
    end

    rule tag
      [a-zA-Z_0-9-]+
    end

    rule message
      .*
    end

    rule delimiter
      space* ':' space*
    end

    rule space
      ' '
    end
  end

Almost identical to the above except…it has friggin’ ruby code attached! That means when given a status, I can call #get_tag and #get_message to return the items. Pretty doggone easy.

“Impressive, but how is this better than just using regular expressions”

So I will not deny the same thing could be accomplished with a single regex, but this looks sexy. And it has additional benefits. Lets say in the future they want to:

Allow multiple tags
Allow spaces, and commas to be valid tag delimiters
Allow the tags to be optional

Here’s a grammar modified with those exact requests:


  grammar Twitter
    rule status
      (tags delimiter)? text {
        def get_tags
          if self.class.method_defined? "tags" 
            tags.get_tags
          else
            []
          end
        end

        def get_message
          text.text_value
        end
      }
    end

    rule tags
      tag optional_tags:(optional_tag*) {
        def get_tags
          [tag.get_tag] + optional_tags.elements.map { |e| e.get_tag }
        end
      }
    end

    rule optional_tag
      tag_delimiter tag {
        def get_tag
          tag.text_value
        end
      }
    end

    rule tag
      [a-zA-Z_0-9-]+ {
        def get_tag
          text_value
        end
      }
    end

    rule text
      .*
    end

    rule delimiter
      space* ':' space*
    end

    rule space
      ' '
    end

    rule tag_delimiter
      space* ',' space* / space+
    end
  end

Some examples and their output:


  results = parser.parse("tag1 : the message")
  results.get_tags      # => ["tag1"]
  results.get_message   # => "the message" 

  results = parser.parse("tag1 tag2, tag3 : the message")
  results.get_tags      # => ["tag1", "tag2", "tag3"]
  results.get_message   # => "the message" 

  results = parser.parse("the message")
  results.get_tags      # => []
  results.get_message   # => "the message" 

  results = parser.parse(": the message")
  results.get_tags      # => []
  results.get_message   # => ": the message" 

  # Yea, well not bad for only 15 min, lets chalk the last one up to user-error.

I want to thank Nathan Sobo for putting together such a useful and intuitive library. For more information about Treetop, you can check out the site as well as the mailing list.

Combined PGP Keys Into One

2008-02-19T04:18:00Z

After finding out today that pgp keys can have multiple email addresses, I revoked all but public key and combined all emails into one key.

How

Edit a key in the terminal:


> gpg --edit-key KEY_ID
Command> adduid

Add name and email address. Then remember to set a primary uid:


Command> uid NUMBER_IN_PARENTHS_TO_SELECT
Command> primary
Command> save

Should be all good. Remember to revoke the old keys and re-export the public key.

Additional Tip

You can share your public key with others easier by uploading it to a key server like MIT

Git Stash is Sweet

2008-02-16T23:37:00Z

Earlier I mentioned a method of storing away changes in a patch, rebasing and then applying the patch so you don’t have to commit beforehand.

Yesterday Janson found git-stash, and it is sweet.

type “git stash”
do your changes
type “git stash apply”
profit!

Ascribe - A Case Study on View Specs

2008-02-16T23:00:00Z

Background

When we started development on Ascribe about 3 months ago, I had a hankering to try out RSpec. We used a lot of similar concept on a test/unit side such as small readable tests and mock testing, but we hadn’t given view specs a try. To be fair, I had been pretty critical of view specs prior to the project; not really seeing the benefits. This is a write up on our experiences. There will be a lot of verbiage like “felt”, “thought” and not a lot hard numbers.

Expectations

As I said, I had been pretty critical about using view specs. I had seen them used together in functional tests, and I strongly disliked the “cluttered” look of controller assertions intermixed with the view assertions. My main concerns using them were:

A significant amount of time to initially create the spec
The additional rigidity of changing views
Brittleness in comparison to other tests we value (unit, controller, and integration)
The added technical hurdle for allowing designers or html developers to contribute

In practice

“A significant amount of time to write the specs”

We were actually quite surprised to find that writing the view specs were the easiest among all of our tests. Essentially, all that is asserted is the presence of text. When in comparison to testing object interaction, or algorithms, this felt brain-dead simple. Further reinforcement is that there shouldn’t be a lot of code in the views. If you noticed your view or spec getting complicated, it generally helped to pull out code (helpers, additional model behaviors). Of course we found testing pitfalls, and became more judicious in what we would assert.

Examples of what we would test:

Presence of html controls like text fields, text areas, select, etc.
Presence of labels
Important attributes for html controls (names, ids, and sometimes classes¹)
Form actions, and alternate http methods (delete, put)
Partial renders
Custom helper calls
Iterators and If/Else controls
Anchors

Examples of what we would not test:

HTML Containment. We would only assert this if it was required for RJS
Exact text. More often than not, we wold assert a portion of the text with case insensitive regular expressions
Common helpers like h()
HTML classes not used for client javascript or rjs. We found this hindered css from an html developers point of view, and did not provide a lot of value.

“Additional rigidity for changing views”

To discuss this, it may help to lend insight to our team. There was Janson and me, both developers who wrote and maintained ruby, all specs, and html / css. We also had Aaron who is not a developer, but is really knowledgeable about html / css. One of our concerns was every time Aaron would want to make a change to the design, either we would have to be there with him, or we would have to teach him how to run, fix, and create view specs.

We ended up opting for a completely different approach. We told him to ignore the specs in all regards save one. If he was going to add rhtml calls (typically anything with <%= %>) we asked if he would open up the spec for the view and create a pending statement.


    it "should have a link to the dashboard"

That way we would be able to return later and flesh out the stubbed specs. Although this isn’t exactly promoting TDD, it allowed him to keep running, as well as placing a bookmark in the code for us. We never felt as if we were getting bombarded with pending statements, and quickly writing them and moving on didn’t feel time consuming.

“Brittleness in comparison to other tests we value (unit, controller, and integration)”

With Aaron working on the html, we were even more concerned with the brittleness of our tests than if the entire team were ruby developers. At Elevator Up it is very common that we have non-developers contributing to the html / css, so obviously I was apprehensive of being overwhelmed by constantly breaking specs. No developer likes to consistently fix other developers broken tests. And it wasn’t exactly like we could yell at Aaron for not doing his job. This is one expectation that played out in the course of development, but in a different light.

When Aaron would make a commit it was pretty common for him to break tests. In fact I believe his record was 38, and without any numbers, my guess was he averaged around 5 – 10 breaks per commit. What we didn’t anticipate was that fixing 30+ tests took no more than 15 minutes. That was a huge shocker to me. A non-developer would rip out the code we were asserting, make additional calls that weren’t stubbed, and it only took us 15 minutes to fix them all.

We found that the biggest breakages were due to calling mocked helpers in a valid, but unexpected manner. Since all other spec relied on a valid render, they would break as well. In some cases, fixing one line, would fix 10-20 assertions. There were also a few instances where the specs actually broke for the right reasons. For example, a link_to was modified and the href wasn’t pointing to the right location.

“The added technical hurdle for allowing designers or html developers to contribute”

With only having Aaron add pending statements on code additions, he didn’t feel uncomfortable, or feel like he had to learn how to program just to make visual changes. This felt like a huge win for us. While it would be nice to have all html / css developers understand and maintain ruby, this isn’t realistic at Elevator Up.

Other Surprises

Up to now I’ve only talked how our expectations matched up to our experiences, however I haven’t mentioned any benefits of view testing. Talking about the benefits of testing views is just as difficult as talking about the benefits of unit testing, or using mocks. You can’t convince another developer with anecdotes alone. Using them in practice normally speaks volumes in a much more articulate way.

That being said, as we worked on Ascribe, I kept a list of successes that I felt the view specs were the prime contributer to².

Checking label “for” mispellings
Ensuring all input fields are present
Asserting non “sunny day” code paths (if/then)
Using fields that could potentially be nil
Ensuring links are pointing to the correct places
Ensuring forms are posting to the right places
Ensuring forms are posting with the right method
Incorrect usage of named routes
Renaming / Refactoring Routes
Ensuring render partials have correct locals
Better confidence in refactoring views into partials / or helpers
Ensuring correct usage of helpers link_to, link_to_remote, form_for
Better testing-as-documentation for RJS
Using pending tasks as view centric TODOs

Summary

A realization that sparked while we were at the end of the project, was that compared to unit, controller, and integration tests, view tests are cheap. Their creation and maintenance are very low, and for their small amount of effort, noticeable benefits arise. It feels comparable to investing pennies and earning $200. We were very pleased we went out on a limb and gave them a shot. Elevator Up has made it a point to add view specs to our development routine.

¹ We found this useful since we use dashed ids instead of underscored. Also we found on more than one occasion, we were using rails tags incorrectly. One of the biggest culprits was setting ids and classes on select tags.

² I’m not saying that these are unique to view specs, and can’t be achieved with other testing techniques.