Development Blog: Post

Justin Marney, Web Developer, June 17, 2008 2

The conventional approach to testing helpers in Rails has, until recently, always been relatively subjective. I have come across different strategies including generators, plugins and hand-hacked setups depending on where I looked. In sharp contrast, the controller testing convention has been DRY'd up and moved into the framework in the form of the ActionController::TestCase class. Fortunately, Brian has been working on some helper testing tools and recently stumbled across the ActionView::TestCase class. If you have been looking for a convenient, framework supported way to test your helpers, look no further. This class provides the same conventions as ActionController::TestCase and makes testing helpers a breeze.

Test Your Helpers Using ActionView::TestCase
Here is an example that shows how to use ActionView::TestCase along with Brian's assert_tag_in. First, create a test named HelperNameTest and inherit from ActionView::TestCase. Then just call your helper methods from your tests, it's that easy.

module ApplicationHelper
  def special_header()
    content_tag :div do
      link_to('Edit Profile', edit_account_path)
    end
  end
end

class ApplicationHelperTest < ActionView::TestCase
  def test_special_header_should_render_edit_link
    tag = special_header(:edit_profile => true)
    assert_tag_in(tag, :a, :attributes => {:href => edit_account_path})
  end
end

Worth noting here is the ability to test methods that rely on url_for without needing to create a temporary controller in your own testing code. I also want to point out that Chu Yeow did cover using ActionView::TestCase in his Living on the Edge series, but it totally slipped past me :)

Update

ActionView::TestCase is not loaded automatically. Be sure to require 'action_view/test_case' in your test_helper.

David Eisinger, Web Developer, May 23, 2008 2

As an end-to-end web production company, we have a vested interest in making Rails applications easier to deploy for both development and production purposes. We’ve developed Tyrant, a Rails app for running Rails apps, and we’re eagerly watching as new solutions are created and refined.

But it’s a new market, and current solutions are not without their share of obstacles. In working with both Tyrant and Phusion Passenger, we’ve encountered difficulties running applications that use RubyInline to embed C into Ruby code (e.g., ImageScience, my image processing library of choice). Try to start up an app that uses RubyInline code in a shared environment, and you might encounter the following error:

/Library/Ruby/Gems/1.8/gems/RubyInline-3.6.7/lib/inline.rb:325:in `mkdir':
Permission denied - /home/users/www-data/.ruby_inline (Errno::EACCES)

RubyInline uses the home directory of the user who started the server to compile the inline code; problems occur when the current process is owned by a different user. “Simple,” you think. “I’ll just open that directory up to everybody.” Not so fast, hotshot. Try to start the app again, and you get the following:

/home/users/www-data/.ruby_inline is insecure (40777). It may not be group or world writable. Exiting.

Curses! Fortunately, VigetExtend is here to help. Drop this into your environment-specific config file:

temp = Tempfile.new('ruby_inline', '/tmp')
dir = temp.path
temp.delete
Dir.mkdir(dir, 0755)
ENV['INLINEDIR'] = dir

We use the Tempfile library to generate a guaranteed-unique filename in the /tmp directory, prepended with “ruby_inline.” After storing the filename, we delete the tempfile and create a directory with the proper permissions in its place. We then store the directory path in the INLINEDIR environment variable, so that RubyInline knows to use it to compile.

Matt Swasey, Web Developer, May 21, 2008 3

A couple of co-workers and I have been tossing around the idea of having a Ruby Hack Night in the DC metropolitan area for the past few weeks.  We are going to start out small, and have a very informal gathering at Murky Coffee in downtown Arlington on the night of June 18th, the third Wednesday of the month.  If you would like to join us, we will be there starting at 7pm.  Murky Coffee does not take space reservations, so we don’t have a set aside meeting location.  I am going to try and get the back room which holds about ten people comfortably.  If we have a larger crowed that than, we can migrate to the upstairs.  So, we’d love to see you there if you are a Ruby hacker wanting to get together with other DC Ruby hackers and work on various projects (of your choice).

We will ask everyone there what they are going to work on, and what they would like help with if anyone is interested.  So, if you have a project, bring that, if you don’t have a project, but would like to help someone else with theirs, that would be awesome.

Hope to see you there!

Patrick Reagan, Development Director, April 15, 2008 0

A little more than a year ago, we started something unprecedented in my career here at Viget: We made the decision to make some of our code freely available to the public.  The software was Tyrant, and while we haven’t put together an “official” release, this first effort was enough to spark an interest in releasing more of our work to the larger developer community.

A few months later, we reconvened to discuss ideas for Rails plugins that would be useful to other developers.  After a lively discussion and some good ideas, we left the meeting feeling invigorated with plans for a new VPS to host both a Trac installation and a public-facing Subversion repository.

Some of those original ideas died out, but others live on as active projects, and even more have been created as we encounter new challenges.  This is all part of the life-cycle of a healthy open source ecosystem, where new approaches to problems and changes in technology give way to better solutions. 

Continue reading "Open Source, Take Two."

Ben Scofield, Development Director, March 12, 2008 3

Some of us around the Lab have been using GitHub for a while now, and we love it. (It’s currently in beta, but we’ve got some invitations if you’re interested in checking it out - just leave a comment here.) Unlike at least one of the alternatives, however, GH won’t be entirely free once it launches. Finally, we have some details on their pricing plans.

All in all, I’d say it looks very reasonable - 100 MB of space for the free account is plenty given git’s efficiency, unless you’re storing media in your repository. I also love the focus on open source projects and public repositories, which are always unlimited. I think GitHub’s clearly on the right track, and I’m looking forward to seeing how it grows.