Wednesday, September 9, 2009

How to Build a Large Application with Rails

This is a really great presentation about how Thoughtworks built a large application with Ruby on Rails (RoR). Contains some really interesting statements:
* http://www.scribd.com/doc/15336842/Rails-in-the-Large-How-Were-Developing-the-Largest-Rails-Project-in-the-World

How team scaled:
* Started with (Oct 2006) Project Mgr, Business Analyst, Tech Lead, Developer (the latter two pair program).
* Jan 17, 2007 - inception - started with 2 pairs. Added a pair every 2 weeks. Had 8 or 9 pairs by July.
* At time of presentation - 11 pairs of devs, 8 business analysts, iteration mgr, 6 QA, project manager, client principle.

Some high-level/generic quotes:
* Technology isn't as important as responsiveness to business needs.
* Don't try to convince too early.
* Demonstration over arguments.
* Scale infrastructure opportunistically... but don't wait too long.
* Have fun.
* Invent stuff if you have to.
* Avoid anticipatory design.
* Gradually add complexity.
* Scaling is hard, no matter the technology.
* Software is more about communication than technology.
* Use information radiators.
* Co-location rocks.
* Pairing really rocks.
* Have fun.
* Automate everything.

Slightly more specific/more technical quotes:
* Spikes (throwaway tests) are your friends.
* Mac OS X rocks.
* Rails can scale.
* Unit tests don't hit the database. Mock everything.
* No mocking allowed in functional tests. Tests that hit the database are slooooow.
* Prefer factories over fixtures.
* Fight the battle to keep tests fast.
* Write smart tests.
* Scale development infrastructure just like production infrastructure.
* Play a song when a build breaks.
* Pairing stations: Adium, no email, internal Jabber server, chat rooms (devs, BAs, QAs, shared buddy list, automatically set pair name- adium, Mingle card (upon commit))
* 1-click deployment to any environment
* Rake commit (run all unit, functional tests, verification (language keys), commit)
* Monkey patches all live in extensions folder
* Don't use databases as message queues (for too long anyway).
* Upgrading (Rails) is hard.
* Back port fixes and improvements (to rails, ...).
* We did not replicate a freakin' type system.

Those aren't all of them. See the presentation!

No comments: