Lessons from the "Real World"

Dirk Elmendorf, Cofounder of Rackspace

This presentation was a bit basic but I think that it is a great description of how to get a team of “normal” developers working in rails. It strikes me that a lot of things that they do “aren’t the rails way” but it seems to work for them.

Twitter faces capacity scaling. Not easy, but not interesting to him.

He does internal apps. Growth limited by size of company.

Building a Rails Team

• Having an anchor is important. They didn’t have enough, so they cheated and hired ThoughtWorks
• Buy the book , read the book, learn it as a team. Gives some shared experience. Rails is a DSL for web apps. Since you’re already a developer learn Rails first, then dive into mastering Ruby as you go along.
• Introduce advanced topics over time. KNow your team and its limitations. Don’t throw metaprogramming at newbies.
• Names are important, things have a place (convention over configuration) spend a bunch of time teaching the team this. Make sure they get this.

First App Safelist was built for the Red Cross to provide a place for them to organize the 10,000 Katrina evacuees in San Antonio. Time was short. People were on buses on their way to San Antonio. Only one person knew Rails at that point. The situation was special, because they were reuniting families and such. But the lessons weren’t special. The same patterns have repeated for other apps.

Building the App

We all think about our apps as our babies and we want to get to the finish line. Finish lines are only for consultants and demos. All successful apps evolve. If you screw around you end up with an app that is a nightmare. Changes have consequences. Downtime is important to avoid. Testing is the tool that helps to alleviate that pressure. Tests are a safety net that answer the question: Does it still work?

They support a number of apps and don’t work on all of them all the time. Tests help you get back into an app after a layoff. Tests are interactive documentation. Tests enable change. By having that net they show problems that pop up in another place and gives yo a chance to fix it and fix it before anyone even knows.

rcov is a coverage tool that will show you how good your test coverage is. They’ve learned that if your coverage is < 75% then you really need to do manual testing. If your coverage is perfect you still need to test.

Supporting IE. Use Selenium to test the UI in the browser. See my notes on the first morning session. Delay selenium usage until the UI design has stabalized because selenium tests are very closely coupled to the app.

Another App: Sensei. Performance evaluation tool. Two weeks to build it to avoid another year of paper process. Had to work and be secure because private information that. How do you verify that? Testing. Roled the app out right before RailsConf last year. Changed the app a lot over the last year. Added collaboration so that multiple people can review employees and made sure that they could still audit the security.

Playing with others

Cardinal rule of enterprise: no app is an island. Integrate early. Sometimes things seem easy that aren’t.

• SOAP wasn’t seamless when connecting to Java CRM. They had to get the head of the SVN trunk for Ruby SOAP. This proved to be a hard thing to track down.
• LDAP Authentication - They built out a custom LDAP plugin. That way all their apps can use it and it allows for really clean code sharing. By segmenting from the app, it removes the temptation to code to the app.

Testing with integration is hard. This is where you do mocking and stubbing. They use both flexmock and mocha. They will arm wrestle to choose at the end of the conf.

• XMLRPC with a python app. Blew up on mongrel. Content length was being sent twice. They monkey patched the bug so it would work after submitting it to the Mongrel project. You want to standardize the location fo this type of change. Make sure that something nonstandard like this is really clear. They created a dir called app/core_ext
• WS is just a function call across a network. so it really isn’t anything like a function call. They aren’t reliable. They added a bunch of code to handle edge cases. They’re setting up a message bus. ActiveMessaging on top of ActiveMQ??

Final App: IP Space Commander Manage > 200,000 IPs and many multiples of that of private IPs. Obsessed with IP blocks. Doesn’t do anything else. Has to integrate with CRM, Ticketing, provisioning, authentication, etc. They are buildig a collection of apps where they have to integrate smoothly. They go with a message bus.