Two days at the San Jose Tech Museum hearing about Ruby rejuvenated the old cranium. Just in time since I had spent the previous day doing about 14 hours of troubleshooting on some Enterprise software.

The conference had somewhere above 100 attendees (I didn’t count). It was all in one big hall on the first floor of the Tech. The chairs, well they were bad and know tables to drop a laptop. Still for about $250 for two days I can’t complain too much about the chairs.

The talks ranged from Ruby testing techniques and libraries to IDEs and even into a good bit of depth on VMs and compilers since there were talks on Rubinius and JRuby. At least 10 people in the room had open positions and if you’re a Ruby developer now there’s little chance you can’t find lots of work in Silicon Valley. A decent portion of the audience even had at least one patent.

As a manager dealing day to day with the Java world I felt in over my head as far as Ruby expertise, and it was great. When I go to more general software conferences or Java talks I often get less out of them because I have a lot of experience. Here I was in the bottom third of the class and it was nice. Everything is still shiny and new.

Since there was only one track you didn’t have to do any deciding and walk out of a session feeling like you made a mistake. Another nice part was most of the presenters were very focused and often finished ahead of there hour or so. Instead of sort of filling the time up they generally gave up the floor for lightning talks or answered questions. The self-organization was evident.

Coming down from Sacramento the drive was reasonable, and I just crashed at a $80 hotel room Saturday and headed home Sunday afternoon. Given a really long week at work I didn’t have as much energy as I usually do for socializing, but I did manage to spend some time talking to Cary Campbell of Codecraft. He was trying to get up to speed on Ruby on Rails since he’d spent a lot of time at IBM, 37 years, and the last 15 with embedded systems. He had a great story about setting up a lot of tests based on specs. It sounded like the tests were all written first and then the software was added until all the tests pass. Sort of big test design up front. They were going to use Rails so management could see web reports. Right now if you’re not starting with any legacy web baggage Rails is a great option.

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.