Jake Scruggs

My talk (Using MetricFu to make your Rails code better) went well. I'd say there were 200ish people in the crowd and they all seemed to enjoy it. There were a bunch of questions and some verbal commitments to contribute to MetricFu.


Rails in the Large: How We're Developing the Largest (Enterprise) Rails Project in the World Neal Ford (ThoughtWorks), Paul Gross

Full disclosure: Paul and Neal are friends of mine from my ThoughtWorks days.

The talked about the trials and tribulations of developing a very large Rails project over a few years. The project is called Online Vehicle Exchange (OVE) and it's a sort of EBay for car dealers (it isn't open to the public).

The have 11 dev pairs (22 devs). And started out with mac minis but later switched to mac pros -- they probably should have switched over earlier.

Testing:
Fully disconnected unit tests. They use UnitRecord (which reads your schema.rb file to). If you accidentally hit the db then UnitRecord fails the test

They run 9000 unit tests in 41 seconds.

The run 4000 functional tests in 248 seconds. There is no mocking the db in functional tests. Now tests that hit the db are slow so they had to invent some strategies for

They use Deep Test (open sourced) to parallelize your test suites. 8 cores on a mac pro -- so 8 parallel test runners. They also used Distributed Deep test (also open sourced) - to run the tests on another computer. They had 3 linux boxes in the corner that just ran tests from developer mac minis.

Selenium grid (more open source) was used to spilt selenium across multiple cores and machines. As many boxes as you want to parallelize out the tests.

Always fight the battle to keep tests fast.

They used a projector to throw Mingle up on the wall so they can keep an eye on the cards and the progress of the iteration.

They wrote cc_board -- an open source project that aggregates multiple cc.rb instances to give an overall view.

jukebox.rb -- plays a song when the build breaks and random music other times.

No email installed on the pairing stations -- giant time sink.

Software is more about communication than technology.
Co-location Rocks (war room style programming)
Pairing is vital to this large project so that everyone has some idea of what's going on.

One click deployment to any environment. Rake commit to check in (runs all tests then commits for you).

They used radmind to keep all of their mac's software identical to each other.

Monkey patches for the project live in a specific folder and are modularized.

It took 1 pair 6 weeks to upgrade from Rails 1.2.3 to 2.2 -- Large projects can be tough to upgrade.



Interfaces are Dumb (and that's a Very Good Thing) Erik Kastner (Wine Library / Meta | ateM)

Electricity -- has a dead simple interface. Plug it in and it works.

Your APIs should be the same way.

Why expose an API? You are not as smart as the collective intelligence of all your users.

Twitter and Flickr both have really easy to use APIs. It's probably responsible for some of their explosive growth.

GitHub has a webhook that will post every time someone pushes to a repo.

Keep in mind that the map is not the territory. A developers mental map often does not match the users mental map. This leads to API confusion. Make pains to keep your API simple and solicit lots of outside feedback when people start using it.


Time for Uncle Bob's Keynote now...