Close and Go BackBack to Viget

Rails, Internationalization, and Tú

Clinton R. Nixon
Clinton R. Nixon, Development Director, July 02, 2009 2

Internationalization (or I18n if you’re hep) is a bear of a problem to deal with in software development. I’ve had to work with a multi-lingual site in PHP before. It wasn’t painful, but it was constantly annoying. I just got a chance to work with internationalization in Rails for the first time, and I was pretty excited to see how it’s been handled.

The good news that I found is that Rails’ I18n support is pretty great. The bad news is that it is overly integrated with the rest of Rails, making changing it in isolation difficult.

Continue reading "Rails, Internationalization, and Tú"

How (& Why) to Run Autotest on your Mac

David Eisinger
David Eisinger, Web Developer, June 19, 2009 5

If you aren’t using Autotest to develop your Ruby application, you’re missing out on effortless continuous testing. If you’d like to be using Autotest, but can’t get it running properly, I’ll show you how to set it up.

Autotest is a fantastic way to do TDD/BDD. Here’s a rundown of the benefits from the project homepage:

  • Improves feedback by running tests continuously.
  • Continually runs tests based on files you’ve changed.
  • Get feedback as soon as you save. Keeps you in your editor allowing you to get stuff done faster.
  • Focuses on running previous failures until you’ve fixed them.

Continue reading "How (& Why) to Run Autotest on your Mac"

Unfuddle User Feedback

David Eisinger
David Eisinger, Web Developer, June 02, 2009 0

Recently, we wanted a better system for managing feedback from SpeakerRate users. While we do receive some general site suggestions, most of the feedback we get involves discrete corrections to data (a speaker who has been entered into the system twice, for example). We started to create a simple admin interface for managing these requests, when we realized that the ticket tracking system we use internally, Unfuddle, already has all the features we need.

Continue reading "Unfuddle User Feedback"

Developer Day DC, Done!

Ben Scofield
Ben Scofield, Technology Director, June 01, 2009 0

Developer Day DC took place this weekend, and by all accounts everyone had a great time. Bookended by Jay Virdy’s story about the rise of Summize (and its sale to Twitter) and Russ Olsen’s survey of emerging languages, we had great presentations on a wide variety of topics. Keeping to our technology-agnosticism, we had JavaScript (twice!), Ruby, and Python on the schedule, as well as a more general session on testing and a mind-expanding demonstration of the Monome and other fringe technologies. (If you couldn’t make it, Peter Harkins posted his notes here.)

After conquering Durham and DC, we’ve decided to widen our range a bit, so if you’re eager for a fun, local, cheap conference of your very own, keep watching the Developer Day site. Next up: Boston!

Reusing Contexts in Shoulda with Context Macros

Justin Marney
Justin Marney, Web Developer, May 26, 2009 1

Last month David wrote up a good explanation of how to create shoulda macros with blocks. Recently, I needed to reuse context behavior across a few different tests as well. Out of curiosity, I went in search of a more idiomatic solution and was able to find this ticket and its associated conversation. From the discussion surrounding that ticket, I learned that you can use the merge_block method to create nestable context macros.

class Test::Unit::TestCase
  def self.context_with_an_object(&block)
    context "With an object" do
      setup do
        @object = {:rock => 'on'}
      end

      should "do something fantastic" do
        assert @object[:rock], 'on'
      end

      merge_block(&block) if block_given?
    end
  end
end

You can use the context macro in one of your tests and it will accept a block as well as respect context nesting.

class ModelTest < Test::Unit::TestCase
  context "A great and wonderous test" do
    setup do
      @thing = {:creature => 'lagoon', :rock => 'on'}
    end

    context_with_an_object do
      should "do something specific" do
        assert_equal @thing[:rock], @object[:rock]
      end

      context "And a friend" do
        setup do
          @friend = {:rock => 'on'}
        end

        should "respect some nested context insanity" do
          assert_equal @friend[:rock], @thing[:rock]
        end
      end
    end
  end
end

You can also create your context macros such that they accept arguments.

class Test::Unit::TestCase
  def self.context_with_a_modified_object(modifier, &block)
    context "with a modified object" do
      setup do
        @object = {:mod => modifier}
      end

      merge_block(&block) if block_given?
    end
  end
end

Modifying the context behavior via an argument allows you to test a handful of edge cases without having to duplicate context code.

class ModelTest < Test::Unit::TestCase
  context_with_a_modified_object("dance!") do
    should "be modified" do
      assert_equal @object[:mod], "dance!"
    end
  end
end

I recommend using this technique sparingly and only to remove unnecessary duplication among your tests. It is possible to hide too much context behavior behind these macros and end up with tests that are difficult to understand and maintain. For contexts that aren't reused outside of a single file consider defining them at the top of the test file.

We're the Developers

at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.

Recent Comments

For translating strings you can use Rails I18n backend instead of using inflectors.

The `typus_human_name` is a patch to fix a problem in `human_name` [1].

[1] https://rails.lighthouseapp.com/projects/8994/tickets/2120-humanize-and-human_name-dont-separate-words

Contact Us

Have any questions, comments, ideas, or secrets to share? Let us know.


Sorry, you need to have Javascript enabled to use this form. (Don't blame us, blame the spammers!) If you'd like to contact us, please visit our Contact page.