Jay Fields' Thoughts

It's no secret that I think plugins are unnecessary. Unfortunately, they are also popular, largely due to to how easy it is to create a plugin and put it in your Rails project.

It's also easy to create a new gem. In 2006 Dr. Nic released the newgem gem. This was a great step in 2006, but it's 2008 now and it doesn't feel like we've moved much in the way of shared ruby code.

We're all to blame.

The vast majority of Ruby work is working with Rails. I do believe the next step for RubyGems is to play seamlessly with Rails. Since RubyGems are great for any Ruby code, it doesn't make sense to add Rails specifics to RubyGems. However, RubyGems could be more opinionated about how gems are structured. Right now, RubyGems library code can be structured in almost any way that you'd like. If the structure followed a stricter convention then auto gem loading code could be written for Rails.

I like newgem, but I think the features provided by newgem should actually be part of RubyGems itself. If the gem command could create a project skeleton it could be opinionated about the file structure without creating a larger barrier to entry.

There is another change that needs to happen. Everyone knows that you should vendor everything for your Rails projects. But, there's no single step to go from uninstalled gem to vendored gem. The path is generally to install it locally and them unpack it in whatever folder you've created that gets autoloaded.

I'm pretty sure a remote unpack is fairly simple, which is why we are all to blame. RubyGems is an open source project. Anyone can contribute patches to make it better.

Lastly, if gems become the standard way to share Ruby/Rails code then we'll need a few rake tasks added to Rails. For example, who wouldn't want a rake command to upgrade to a later version of a gem.

I'm hoping 2008 is the year that shared ruby code becomes synonymous with RubyGems and the year Rails Plugins become unnecessary.

Labels: gems, rails, ruby

I've often shown examples similar to the following snippet.

functional_tests do
  test "given no name, when validated, then error is in the objects error collection" do
    instance = Klass.new
    instance.valid?
    assert_equal "can't be empty", instance.errors.on(:name)
  end
end

Forgetting the body of the test, the interesting thing about the snippet is that it's a grouping of tests that contains a single test. I prefer this syntax to defining a class that inherits from Test::Unit::TestCase and then defining tests by creating methods that start with "test_". All of the projects that I'm a part of use this syntax and I've yet to hear anyone say that they prefer the classic Test::Unit syntax.

Adding this to your project just got a bit easier. I extracted the core methods and created a new gem: Dust.

Dust gives you unit_tests, functional_tests, and test methods that can be used for defining tests. Dust also includes additional methods that can help enforce design decisions. For example, if you subscribe to the theory that setup and helper methods should be removed if possible, the Test::Unit::TestCase.disallow_setup! and Test::Unit::TestCase.disallow_helpers! should interest you.

Labels: dust, gems, ruby