Save 37% off PRO during our Black Friday Sale! »

gogobot-works.pdf

B7d890bed68fa564c18ff00dfd8207cd?s=47 Avi Tzurel
February 28, 2012
4.2k

 gogobot-works.pdf

B7d890bed68fa564c18ff00dfd8207cd?s=128

Avi Tzurel

February 28, 2012
Tweet

Transcript

  1. 1 How Gogobot works Avi Tzurel Senior software engineer

  2. 2 v  http://www.kensodev.com v  http://he.kensodev.com v  http://twitter.com/kensodev v  http://facebook.com/kensodev v 

    http://github.com/kensodev v  http://geeklist.com/kensodev v  PayPal => avi.kenso@gmail.com ME ME ME ME
  3. 3 v  Plan a perfect trip in minutes, not days

    v  Never waste another vacation v  Personalized recommendations v  Get you to the right information faster Social Recommendations for Travel
  4. • One-size-fits- all solution • Waste hours looking Reason: People’s Tastes Vary

    Dramatically 4
  5. The future of the internet is personal 5

  6. 6

  7. 7

  8. 8

  9. Gogobot Passport: Sharing with Friends 9

  10. 10 WINNER 2010 BEST WEBSITES 2011

  11. 11 Architecture

  12. 12 v  Fully hosted on Amazon (All around the stack)

    v  About 50-100 instances running v  .5TB of cache in the cluster when warm v  2.5-10K operation per second on cache v  About 150K tasks in the workers daily v  Over 2TB of data stored in Redis v  AVG response time in search is 20ms (about 15million items in search) Architecture
  13. 13 v  Database has about 200G of data v  Some

    tables have 25G of index (Sharding needed soon) v  Full replication on master/slave with Round Robin algorithm between the servers v  Using a special version of octopus gem Architecture
  14. 14 v  Grew amazingly fast over the last year v 

    Scaled from 3 full stack engineers to around 7 (Engineering team is about 10 now) v  Split the team to Mobile/Site Growth
  15. Surging Growth: 2.5MM Places Shared 15 0 500 1000 1500

    2000 2500
  16. 16 v  Big data – over 250MM users’ data v 

    Real-time updates from Facebook and Foursquare – matching to our POI DB v  Each page is personalized – scaling and performance v  Real-time notifications to clients v  Scoring system – personal score for each user / place Technical Challenges
  17. 17 Cache Items

  18. 18 Cache ops per second (10:50 PM PST)

  19. 19 How we get shit done

  20. 20 v  CTO v  4 Full stack engineers v  3

    Front End Engineers 2 of them are also designers v  3 Mobile v  1 Chief Scientist v  1 Robot Engineering Team
  21. 21 v  Up until about 2 months ago, we were

    3 full stack engineers, only recruited after B round v  Most of what you see on Gogobot was done with a MUCH smaller team Not so long ago…
  22. 22 v  No junior engineers v  No power points between

    engineers v  Flat hierarchy in the company, no hierarchy in the engineering team v  Everyone can commit, anyone can deploy (even designers) Structure
  23. 23 v  Sustainable working hours, sustainable pace v  Even when

    we were a smaller team Work day
  24. 24 v  Story time (new engineer) Work day

  25. 25 Work day

  26. 26 v  1 Daily standup (10 minutes) v  One weekly

    planning meeting (plan only a week ahead) (1 hour) v  One all hands meeting (20-30 minutes) v  You do your shit, we get out of your way v  What do you need? v  Done! Work Methodology
  27. 27 v  Full TDD v  Rspec v  Jasmine to test

    JS v  Chrome Driver for integration testing v  Webkit headless on the CI v  NO QA v  No PSD v  No Mockups Work Methodology
  28. 28 v  No deadlines v  Work in weekly sprints v 

    If something comes in something comes out v  No one sits on top of your head v  Ship as fast and best you can v  Work when you want v  Work from home when you want Work Methodology
  29. 29 Work Methodology

  30. 30 v  Full ownership on a bug or a feature,

    from end to front (in that order) v  Need designer? Have him in your pull request, but the feature is yours Work Methodology
  31. 31 v  Communication is async v  No meetings during the

    week v  No conversation between engineers that interrupt v  All work is being done inside a chat room. v  You can ask a question there, if someone can, you will get an answer, if not, move on, you’ll get an answer later Work Methodology
  32. 32 Work Methodology

  33. 33 Work Methodology

  34. 34 Work Methodology

  35. 35 Work Methodology

  36. 36 Work Methodology

  37. 37 v  Don’t pull me out of the zone v 

    Work async v  No interruptions v  No meetings v  NO CODE REVIEW! (sec… wait) Advantages in the chat
  38. 38 v  No one pushes code to master v  Master

    is always deployable v  When you finish your work, you open a pull request and move on, don’t shout! v  Anyone can review any pull request v  Simple branch name + description for the branch v  Get ready to rumble…!!! Pull requests
  39. 39 Pull requests

  40. 40 Pull requests v  Some examples v  Pull 1 v 

    Pull 2
  41. 41 Pull requests v  Advantages v  Async (did we mention

    the zone) v  Anyone can participate v  Full history (you can drop in a month later) v  Saves your ASS!! v  If you fuck up, it’s not only you J
  42. 42 Pull requests v  NOTHING IS URGENT BUT LOGIN /

    REGISTER BUGS v  You know this… v  Email: There’s a bug in the site… from the CEO v  You hack on it 2am, push it v  Production FAILS!
  43. 43 Branching v  KISSYSMF v  Feature/ v  Bug/ v  Hotfix/

    v  {username}/ v  From there to pull to master v  No deploy branch v  CI can test any branch
  44. 44 CI + Deploy v  CI can run any branch

    v  CI deploys v  CI on the big screen with the culprits
  45. 45 CI + Deploy

  46. 46 CI + Deploy v  Deploy 1-10 times a day

    v  Deploy every day v  Choose deploy often to see changes v  As small the change is the better, this way you can see real impact v  Twitter driven deployment v  Each deployment triggers QA for IE
  47. 47 CI + Deploy v  Deploy is done to all

    the servers on the LB’s at once v  No downtime on deploy v  Users are being switched over when the serves are ready to get them v  It’s probably complicated to deploy right?
  48. 48 Work Methodology

  49. 49 CI + Deploy v  It’s that easy to rollback

    as well, so rollback at will.
  50. 50 Monitoring v  We monitor the shit out of everything

    v  Not only when something is down v  Statistics based monitoring v  How fast? v  How fast was yesterday? v  Number of items shared? v  Number of signups?
  51. 51 Monitoring v  We get emails + sms + phone

    calls when something happens v  if it can wait, tomorrow is fine
  52. 52 Monitoring

  53. 53 Monitoring

  54. 54 Monitoring

  55. 55 Questions?