RSS
 

Archive for the ‘rails’ Category

How to Land Your First Rails Patch (Screencast)

14 Feb

Last week I posted How to land your first patch in Rails.

The post was well-received, but one commenter asked if I might put together more-detailed steps on how to make your first docpatch. Well, I’ve done just that, and the result is the screencast below.

It’s only 4 minutes, but contains everything you need to know to get your name on the Rails Contributors list. Check it out!

Update: in the screencast, I mention that you need to message lifo for commit access to docrails. However, as Xavier noted below, docrails now has public write access for everyone, so need to perform that step.

By the way, if you liked the video, you should check out my other screencasts for Rails programmers.

 
1 Comment

Posted in rails, ruby

 

How to land your first patch in Rails

07 Feb

If you’re looking for a way to contribute back to Rails, the quickest way to get your first patch in is by improving its documentation.

Some people don’t find patching documentation as sexy as slinging code, but I’ve come to love the humble doc patch. Here’s why they’re so great:

It’s easy to get started. Your first patch can be as simple as fixing a typo in a Rails Guide. Later, when you’re feeling more at ease with the process, you can improve the documentation for a class or method right in the code. Find an undocumented class, dig into its guts, and write a good summary. Ever read the examples for a method and think they could be improved? Don’t grimace and move on; fix it!

Your patch will be merged in quickly. All patches to Rails’ documentation go into the docrails repository. This repo has an OPEN COMMIT POLICY: you simply message lifo on github and he’ll give you commit rights. You can make your patches at will, and the repo is regularly merged with the official Rails repository (here’s the most recent example of that happening). There’s no lengthy signoff process, so your commits will never languish while waiting for “+1s” or attention from a core member.

Most people don’t want to do it. It’s actually pretty tough to find bugs in Rails to fix. There are so many Rubyists crawling all over it that there’s just not that much low-hanging fruit to patch. However, most developers don’t really like writing prose, so there’s a lot of easily-improved or outright missing documentation out there.

Your commits count toward the Rails contributors leader board. If you’re into that sort of ladder-climbing, you can break into a top 200 spot with just 8 commits. With just a bit of effort I reached 267th, which gets me laid all the time.

It feels damn good to give back to projects you use every day, and seeing your name in the commit logs is a real trip at first. If you’ve been looking to start making some open-source contributions, you could do a lot worse than improving documentation used by thousands.

If I’ve inspired you, you should start here: the Contributing to Rails Guide has a section specifically for working on documentation. Good luck!

 
1 Comment

Posted in general, rails

 

A handy ruby trick: Class.new

01 Feb

Today I learned that you can pass a block to Class.new, like so:

klass = Class.new do
  def self.speak
    "hi!"
  end
end

>> klass.speak
=> "hi!

This is a handy for creating one-off classes; the kind you’ll throw away quickly.

It’s likely that you’d do this during tests. Here’s a test in active_support that uses this technique:

class ClassAttributeAccessorTest < Test::Unit::TestCase
  def setup
    @class = Class.new do
      cattr_accessor :foo
      cattr_accessor :bar,  :instance_writer => false
      cattr_reader   :shaq, :instance_reader => false
    end

    # Now grab an instance of our new class
    @object = @class.new
  end
 
  # Elided: tests that make sure the cattr_accessor method behaves

end

Another thing I picked up at the same time: you can pass a constant to Class.new and it will set that as the superclass:

>> klass = Class.new(String)
=> #<Class:0x105604658>
>> klass.superclass
=> String

Here’s another test from Rails. This one makes use of both tricks I just showed you:

  test "configuration is crystalizeable" do
    parent = Class.new { include ActiveSupport::Configurable }
    child  = Class.new(parent)

    # ...
  end
 
No Comments

Posted in rails, ruby

 
« Older Entries
Newer Entries »