Rails in the Large - Neal Ford
Upcoming SlideShare
Loading in...5
×
 

Rails in the Large - Neal Ford

on

  • 691 views

Neal Ford - Agile East 2011

Neal Ford - Agile East 2011

Statistics

Views

Total Views
691
Views on SlideShare
691
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Rails in the Large - Neal Ford Rails in the Large - Neal Ford Presentation Transcript

    • 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.compgross@thoughtworks.com 3003 Summit Boulevard, Atlanta, GA 30319200 E. Randolph St, 25th Floor, Chicago, IL 60601-6501 www.nealford.compgross@thoughtworks.com www.thoughtworks.comwww.pgrs.net blog: memeagora.blogspot.comwww.thoughtworks.com twitter: neal4d
    • coming RSN
    • metrics feedback loops automation time & space demonstrationcommunication non- intuitivity
    • what OVE.com does
    • the pursuitGo for the one that’ll beat theone that’ll beat the one youlast did
    • .NET Rails
    • quick start: october 2006Project manager Business Analyst Tech Lead Developer
    • inception: Jan 17, 2007Started with 2 pairsAdded one pair every 2 weeks 8 or 9 pairs by July
    • now 11 pairs of developers 8 business analysts iteration manager client principle6 quality assurance project manager
    • lessons learnedtechnology isn’t as important as responsivenessto business needsdon’t try to convince too earlyspikes are your friends!demonstration over arguments
    • infrastructure Rock is for Rookies: males have a tendency to lead with Rock on their opening throw
    • physical infrastructure BA standalone QA integrated QApairing workstations UAT (sneak peak)XServe (Selenium Grid)
    • deployment stack 10 web boxes 2 image servers 4 database serversbackground server memcache
    • technical statsfeedback loops
    • environment
    • lessons learnedscale infrastructure opportunistically......but don’t wait too longMac OS X rockshave fun
    • testing Scissors on First: play scissors as your opening move against amore experienced player
    • disconnected unit testsUnitRecord and the evolution of unit tests that don’t hit the database http://github.com/dan-manges/unit-record
    • unit tests
    • the rule:unit tests don’t hit the database mock everything
    • functional tests
    • no mocking allowed in functional teststests that hit the database are slooooow
    • feedback loops DeepTest http://github.com/qxjit/deep-test
    • metricsautomation time & space DistributedDeepTest demonstration non- intuitivity
    • Selenium grid time & space
    • lessons learnedfight the battle to keep tests fastinvent stuff if you have towrite smart testsscale development infrastructure just likeproduction infrastructure
    • knowledge transferPaper is the least obvious of opening moves.
    • project Mingle on the wall
    • cc_boardhttp://github.com/qxjit/cc_board/
    • play a song when a build breaks communication play theme song upon successful checkin
    • jukebox.rb currently in alphahttp://subversion.hammersforge.com/ jukebox.rb/trunk/
    • pairing stations adium no email
    • internal Jabber server chat rooms devs BAs QAs shared buddy list
    • automatically set pair name adiumMingle card (upon commit)
    • feedback lessons learned loopssoftware is more about communication thantechnologyuse information radiatorsco-location rocks communicationpairing really rockshave fun
    • automateeverything When playing with someone who is notexperienced at the RPS,look out for double runs or, in other words, the same throw twice.
    • 1-click deploy to any environmentusing cc.rb as easy deployment tool
    • rake commitrun all unit testsrun all functional testsverification (language keys)commithttp://github.com/pgr0ss/rake_commit_tasks
    • canonical pairing station maintenance cap pairing_stations
    • radmindhttp://rsug.itd.umich.edu/software/radmind/
    • strict rules foradvancedlanguagefeaturesTell your opponentwhat you are going tothrow and then actuallythrow what you said.
    • Try playing the throw that would have lost to your opponents last throwbackground processing
    • evolution of asynchronous messaging
    • progress bars & async upload backgrounDrb http://backgroundrb.rubyforge.org/
    • 3 kinds
    • use backgroundrb forsimple message queue backed by database
    • (Starling) switch to a real messaging queue
    • don’t know what we don’t know “buy the fanciest one we can” (just in case)project time
    • technical debt when you when you add it start using itproject time
    • 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 justifyproject time
    • trying to predict thefuture leads to over- engineering
    • lessons learnedavoid anticipatory designgradually add complexitydon’t use databases as message queues (for toolong anyway)DBA’s can sometimes get grumpy
    • performance & optimizationWhen all else fails, go with paper: Statistically, in competition play, it has been observed that scissors is thrown the least often.
    • not that many page views......really complex pages!
    • daily web trends
    • monthly web trends
    • why all therochambeau stuff?
    • view builds are fragile =>separate cc.rb build =>view builds are slow =>1 pair assigned as view masters
    • worst...job...ever
    • today’s view master assigned by yesterday’s... ...or play RPS
    • http://www.worldrps.com/
    • 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.compgross@thoughtworks.com 3003 Summit Boulevard, Atlanta, GA 30319200 E. Randolph St, 25th Floor, Chicago, IL 60601-6501 www.nealford.compgross@thoughtworks.com www.thoughtworks.comwww.pgrs.net blog: memeagora.blogspot.comwww.thoughtworks.com twitter: neal4d
    • metrics feedback loops automation time & space demonstrationcommunication non- intuitivity