Josh Susser gave a pointed talk on how you can contribute to Rails, or really any other open source project for that matter.

Why Contribute?

Maybe there’s the guilt associated with the freeloader effect that drives you to contribute. Guilt is never the strongest motivation though. Better motivations include getting some measure of control over a piece of software. You can fix your own bugs and contribute patches. Finally, the cool reason–cred. With credibility people start listening to you and eventually you get things like book offers and job offers.

Where to Start

• Start with the Trac site for rails.
• Follow the rails core discussion list.
• Documentation is a great place to start.
• Tests, more tests are always needed.
• You can write a test around a bug and submit it. Maybe someone else will write the code to fix it.

• Then you can always write code.

• New code is glamourous, but not the best starting point.
• Better to start with bug fixes.
• Move on to plugins, generators, tasks, etc.
• Maybe then an enhancement.

The How

Start with setting up a rails development environment. Then pull down rails from the trunk:

$ svn co "http://svn.rubyonrails.org/rails/trunk" rails

Next setup the test database for ActiveRecord and possibly others and read RUNNING_UNIT_TESTS. Run tests before any changes. Then run tests after every change. Start writing tests first. The tests in rails could do with a lot of refactoring, and Josh mentioned there was a good opportunity for contribution there. Remember to follow the Rails style guidelines. Then document what you do with RDoc and inline comments. Again, tests must pass and docs must build.

The Patch

• Generate the patch file

$ svn diff > well_named_patch.diff

• Look at the diff file in TextMate or some IDE. There should probably be a lot more test code and documentation then actual application code in the diff file.
• Open a ticket on the trac site.
• Start the summary with [PATCH].
• Upload the diff file, don’t paste it.
• Describe problem and solution, show usage.

• Use Keywords: doc, test, tiny

• doc – patches that are just documentation
• test – patches that are just test

• tiny – small changes, probably only one file

• Then practice being patient.
• Lots of patches are sitting in Rails Trac for a long time.
• Smaller changes are easier to get accepted.
• Use tiny keyword.
• If you have a big patch, discuss on rails-core list first. Try out patch as plug-n it makes it easy to check the stability.

Other Things You Can Do

• Room for lots of different types of contributions. Can do some grooming on the wiki.
• Respond to updates to your ticket.
• Check the rails irc channel at #rubyonrails at irc.freenode.net
• Keep a blog. Everyone who contributes has a blog of some sort.
• Look at open bugs if you don’t have anything you want to change in rails right now.

The talk finished up with some questions. One attendee mentioned that in their shop they have new developers just cruise through rails and contribute patches for the first month or two before they really put them on projects, so they can get really familiar with rails and help out at the same time. And Josh explained that PDI (Please Do Investigate) is not a brush off from the core team. Instead it’s a small compliment that someone thinks it’s interesting, and please go make it happen.

Someone asked me if Twitter was TCP or UDP. UDP, it’s definately UDP. I can’t talk about the numbers, but UDP.

– Blaine Cook

Scaling Twitter talk at 2nd Annual Silicon Valley Ruby Conference

Blaine talked about dealing with traffic on the busiest Rails based site. His comment was related to their use of DRB and Rinda, a distributed object system for ruby, basically RMI. Apparently Twitter has been getting so much traffic at times that there’s no way it’s going to catch up, so the solution was to just drop the queue when it got too big since it wasn’t going to catch up anyway. A purely pragmatic approach for a very popular site experiencing growing pains.

(The conference was pretty great and I’ll probably be culling posts from my notes for the next week or so. The slides from Blaine Cook’s talk can be found on Slideshare.)

Alex Chafee and Brian Takita of Pivotal Labs mix regular rails tests including fixtures with Selenium tests for a full stack test in one. They kicked off the 2nd Annual Silicon Valley Ruby Conference in style with a focus on testing. Few thought it odd to be talking about testing early in the morning. Rails of course bakes testing in and you almost have to work to avoid it. Selenium isn’t drop dead obvious though especially since you can so easily test a lot of the web tier through functional and integration tests in rails controllers. When Alex Chafee asked for a show of hands a good number of the 100 or so attendees had used it, but very few were using it at work.

The approach is pretty simple:

• You need to test your view layer partially because of all the AJAX going on their and partially because it doesn’t really work unless it works in an end users version of IE.
• Since you have access to rails and you can write the Selenium tests in Ruby, just go ahead and mix the two.
• You can use fixtures for Selenium tests.
• You can almost produce a DSL with the Selium tests for the customer.
• Since many of the tests will take a while you should hook them up to your continuous build boxes. (They run Mac minis with Parallels and Windows and Linux installed so they can test three platforms at once.)

They had some lessons learned to pass on:

• It helps to check the page title on every page to ensure you’re actually navigating somewhere.
• To handle AJAX you probably need to resort to polling. They use a default timeout of 20 seconds.
• Remember to refactor out common code to create sort of a DSL.
• Tests are more legible if you use literal strings for many of the parameters.
• Long test methods are good in Selenium because you want to touch large swaths of the code.
• Rarely use Selenium IDE for doing any recording.
• You probably need to disable transactional fixtures for Selenium tests.

And finally they should have some rake integration code around this available soon as open source.

My clearest memory of how powerful transparency can be was in a discussion years ago with a Fortune 500 E-commerce VP. We’d successfully done a few million dollars of e-commerce work for them over the period of about a year and he was asking if we could develop about 15 sub-sites localized for places like Iceland or the Philippines on the cheap. They were hoping to get each of the sites done for $10k to $15k. My answer was simple:

While we’d love the work, we just aren’t setup for doing these small sites and you’d be better off going with someone else for developing small market sites.

At this point I was worried. You really don’t want to say no to a customer, in this case probably our second largest customer. The VP answered succinctly:

Thanks, Ed, we really appreciate your honesty.

They did end up doing the sites through someone else, but they kept our relationship intact and we ended up doing even more work for them that played to our strengths.

I replay this memory when I get hammered for pushing transparency over leaving someone out of the loop or only presenting the positive side to an approach.

Mock frameworks can generate an ‘aha’ moment if you introduce them at the right moment. The evolution looks like this:

1. Introduce unit testing as a concept.
2. Walk through the basics of an xUnit framework.
3. Introduce test driven development.
4. Introduce fake objects or hand rolled stubs to substitute for things like DAOs.
5. Use specialized mock object libraries like Shale mock JSF framework to build fake FacesContexts.
6. Spring EasyMock or JMock on them to handle some nasty edge cases.

We choose EasyMock. Introducing it right up front would have been cognitive overload. Getting TDD installed is really more a journey than a simple prescriptive plan. TDD is about changing a core developer behavior in how they write code. So I saved the mock framework explanation for that moment where it elegantly solved the problem at hand.