Recomendados
Más contenido relacionado
Similar a Building the Biggest Rails Application
Similar a Building the Biggest Rails Application (20)
Más de Kmanthei
Último
Último (20)
Building the Biggest Rails Application
- 1. ThoughtWorks Rails in the Large: Building the Biggest (Enterprise) Rails Application in the World PAUL GROSS software developer / consultant NEAL FORD software architect / meme wrangler ThoughtWorks ThoughtWorks nford@thoughtworks.com pgross@thoughtworks.com 3003 Summit Boulevard, Atlanta, GA 30319 200 E. Randolph St, 25th Floor, Chicago, IL 60601-6501 www.nealford.com pgross@thoughtworks.com www.thoughtworks.com www.pgrs.net blog: memeagora.blogspot.com www.thoughtworks.com twitter: neal4d
- 2. coming RSN
- 3. metrics feedback loops automation time & space demonstration communication non- intuitivity
- 7. the pursuit Go for the one that’ll beat the one that’ll beat the one you last did
- 8. .NET Rails
- 10. quick start: october 2006 Project manager Business Analyst Tech Lead Developer
- 11. inception: Jan 17, 2007 Started with 2 pairs Added one pair every 2 weeks 8 or 9 pairs by July
- 12. now 11 pairs of developers 8 business analysts iteration manager client principle 6 quality assurance project manager
- 13. lessons learned technology isn’t as important as responsiveness to business needs don’t try to convince too early spikes are your friends! demonstration over arguments
- 14. infrastructure Rock is for Rookies: males have a tendency to lead with Rock on their opening throw
- 15. physical infrastructure BA standalone QA integrated QA pairing workstations UAT (sneak peak) XServe (Selenium Grid)
- 16. deployment stack 10 web boxes 2 image servers 4 database servers background server memcache
- 18. environment
- 20. lessons learned scale infrastructure opportunistically... ...but don’t wait too long Mac OS X rocks have fun
- 21. testing Scissors on First: play scissors as your opening move against a more experienced player
- 22. disconnected unit tests UnitRecord and the evolution of unit tests that don’t hit the database http://github.com/dan-manges/unit-record
- 23. unit tests
- 24. the rule: unit tests don’t hit the database mock everything
- 25. functional tests
- 26. no mocking allowed in functional tests tests that hit the database are slooooow
- 27. feedback loops DeepTest http://github.com/qxjit/deep-test
- 29. metrics automation time & space DistributedDeepTest demonstration non- intuitivity
- 30. Selenium grid time & space
- 31. lessons learned fight the battle to keep tests fast invent stuff if you have to write smart tests scale development infrastructure just like production infrastructure
- 32. knowledge transfer Paper is the least obvious of opening moves.
- 33. project Mingle on the wall
- 35. play a song when a build breaks communication play theme song upon successful checkin
- 36. jukebox.rb currently in alpha http://subversion.hammersforge.com/ jukebox.rb/trunk/
- 37. pairing stations adium no email
- 38. internal Jabber server chat rooms devs BAs QAs shared buddy list
- 39. automatically set pair name adium Mingle card (upon commit)
- 40. feedback lessons learned loops software is more about communication than technology use information radiators co-location rocks communication pairing really rocks have fun
- 41. automate everything When playing with someone who is not experienced at the RPS, look out for double runs or, in other words, the same throw twice.
- 42. 1-click deploy to any environment using cc.rb as easy deployment tool
- 43. rake commit run all unit tests run all functional tests verification (language keys) commit http://github.com/pgr0ss/rake_commit_tasks
- 44. canonical pairing station maintenance cap pairing_stations
- 46. strict rules for advanced language features Tell your opponent what you are going to throw and then actually throw what you said.
- 47. Try playing the throw that would have lost to your opponents last throw background processing
- 48. evolution of asynchronous messaging
- 49. progress bars & async upload backgrounDrb http://backgroundrb.rubyforge.org/
- 50. 3 kinds
- 51. use backgroundrb for simple message queue backed by database
- 52. (Starling) switch to a real messaging queue
- 53. don’t know what we don’t know “buy the fanciest one we can” (just in case) project time
- 54. technical debt when you when you add it start using it project time
- 55. don’t know what we don’t know “buy the fanciest one we can” (just in case) pay $$$ for technical debt… …that you may never justify project time
- 56. trying to predict the future leads to over- engineering
- 57. lessons learned avoid anticipatory design gradually add complexity don’t use databases as message queues (for too long anyway) DBA’s can sometimes get grumpy
- 58. performance & optimization When all else fails, go with paper: Statistically, in competition play, it has been observed that scissors is thrown the least often.
- 59. not that many page views... ...really complex pages!
- 60. daily web trends
- 62. why all the rochambeau stuff?
- 63. view builds are fragile => separate cc.rb build => view builds are slow => 1 pair assigned as view masters
- 65. today’s view master assigned by yesterday’s... ...or play RPS
- 67. ThoughtWorks ?’s This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. http://creativecommons.org/licenses/by-sa/3.0/us/ PAUL GROSS software developer / consultant NEAL FORD software architect / meme wrangler ThoughtWorks ThoughtWorks nford@thoughtworks.com pgross@thoughtworks.com 3003 Summit Boulevard, Atlanta, GA 30319 200 E. Randolph St, 25th Floor, Chicago, IL 60601-6501 www.nealford.com pgross@thoughtworks.com www.thoughtworks.com www.pgrs.net blog: memeagora.blogspot.com www.thoughtworks.com twitter: neal4d
- 68. metrics feedback loops automation time & space demonstration communication non- intuitivity