7 YEARS OF RUBY & RAILS WITH
THE SAME WEB SITE
ZEV
BLUT
KEVIN
GRIFFIN
&
RUBYKAIGI2014
Slide 2
Slide 2 text
RUBYKAIGI2014
What is iKnow!?
About Cerego
Slide 3
Slide 3 text
RUBYKAIGI2014
Online English
Language Learning
Platform
Slide 4
Slide 4 text
RUBYKAIGI2014
Super SRS
(spaced repetition software)
Slide 5
Slide 5 text
RUBYKAIGI2014
History of Cerego
2007 2008 2009 2011 2013
iknow.co.jp Ruby Kaigi!
smart.fm
iknow.jp Cerego English cerego.com
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
RUBYKAIGI2014
Slide 10
Slide 10 text
RUBYKAIGI2014
3 Lessons Learned
Slide 11
Slide 11 text
RUBYKAIGI2014
3 Lessons Learned
1. Sharing code is hard
2. Custom solutions require effort
3. People change
Slide 12
Slide 12 text
RUBYKAIGI2014
1. Sharing Code is Hard
Slide 13
Slide 13 text
RUBYKAIGI2014
Code Organization
Web App Web API
Shared Core
Slide 14
Slide 14 text
RUBYKAIGI2014
`rake stats` LOC
0
25000
50000
75000
100000
web app api core
Code LOC Test LOC
Slide 15
Slide 15 text
RUBYKAIGI2014
Strategies for Sharing
• git submodule in vendor/plugins
• rails engine
• gem
Slide 16
Slide 16 text
RUBYKAIGI2014
Submodule Challenges
• Bundler doesn’t work well
• Editors and tools can’t deal with submodules
• Deployment and Jenkins builds are complex
Slide 17
Slide 17 text
RUBYKAIGI2014
3 Sites Forked from
the Same Code Base
Web API
Core
Web API
Core
Web API
Core
Slide 18
Slide 18 text
RUBYKAIGI2014
Failures with Forks
• Features get out of sync
• Rails upgrades are harder
• Differing systems requirements for each
• (Ruby versions, RubyGems, C-extensions)
Slide 19
Slide 19 text
RUBYKAIGI2014
Successes with Forks
• Starting a new site is fast
• Known codebase (everyone knows how it works)
• Room for divergent changes
Slide 20
Slide 20 text
RUBYKAIGI2014
Other Ways to Share
• `git cherry-pick`
• Gems
• Engines
Slide 21
Slide 21 text
RUBYKAIGI2014
2. Custom Solutions Require Effort
Slide 22
Slide 22 text
RUBYKAIGI2014
We Used Lots of Custom Code
• Gem Management
• Asset Management
• Access Control
• Serialization
• Natural Language Parser
• Mobile Push Notifications
Slide 23
Slide 23 text
RUBYKAIGI2014
“WTF?”
• “Why aren’t we using this common tool?”
• Bundler
• Rails Asset Pipeline
• Jbuilder
• CanCan
• Rails Russian doll caching
• etc…
Slide 24
Slide 24 text
RUBYKAIGI2014
Too Many Patches
• Not sure what is native Ruby/Rails versus custom
• Difficult to maintain when upgrading Rails
• But we keep it all in a specific directory
•vendor/patches
Slide 25
Slide 25 text
RUBYKAIGI2014
When to be custom?
• Concepts that haven’t made their way into Rails
• Owning the core code: performant and specific
• Domain-specific code
Slide 26
Slide 26 text
RUBYKAIGI2014
When to move on?
• Things break, Rails and Ruby change
• Too much code builds around private APIs
• Authors leave the project
Slide 27
Slide 27 text
RUBYKAIGI2014
Use Standard Tools
• Helps people get up to speed faster
• Better documentation
• Can share experiences with the world
Slide 28
Slide 28 text
RUBYKAIGI2014
Open Source Custom Stuff
Slide 29
Slide 29 text
RUBYKAIGI2014
Attack on
Customization
ਐܸͷΧελϜ
Slide 30
Slide 30 text
RUBYKAIGI2014
Rails 2.x to 3.x
{
“SELECT `users`.* from `users` WHERE
`users`.`id` = 42 LIMIT 1;”
=> {“id"=>42,“name”=>"Zev"}
}
User.find(42)
#
Slide 31
Slide 31 text
RUBYKAIGI2014
Rails 2.x to 3.x
def close
@target.close if @target.respond_to?(:close)
ensure
ActiveRecord::Base.connection.clear_query_cache
Slide 32
Slide 32 text
RUBYKAIGI2014
3. People Change
Slide 33
Slide 33 text
RUBYKAIGI2014
~60 Developers
Slide 34
Slide 34 text
RUBYKAIGI2014
Migrations > 1,400
Slide 35
Slide 35 text
RUBYKAIGI2014
What happens when
people leave?
• Knowledge gets lost
• Tests lose meaning
• Well-designed code goes bad
Slide 36
Slide 36 text
RUBYKAIGI2014
Knowledge Gets Lost
• Workarounds are lost
• Data structure meaning is lost
• Dead code piles up
Slide 37
Slide 37 text
RUBYKAIGI2014
Tests Lose Meaning
• Test helpers are forgotten
• Tests check values, not intention
• Fixtures rot
Slide 38
Slide 38 text
RUBYKAIGI2014
Well-designed Code Goes Bad
• Intention isn’t maintained
• Lots of small hacks build up
• Code duplication
Slide 39
Slide 39 text
RUBYKAIGI2014
What Can We Do?
• Delete dead code
• Keep everything up-to-date
• Bootstrap new developers
Slide 40
Slide 40 text
RUBYKAIGI2014
DELETE CODE
Slide 41
Slide 41 text
RUBYKAIGI2014
5,751,894
LOC added
3,332,234
LOC deleted !!
!
ŝŦᴸ ƅ㱼ƅ)ᴸ!
!
( ꒪⌓꒪)
Slide 42
Slide 42 text
RUBYKAIGI2014
Delete Dead Code
• Reduces mental overhead
• Speeds up tests
• Makes upgrading easier
• Don’t fear the code
Slide 43
Slide 43 text
RUBYKAIGI2014
Keep Everything
Up-to-date
Slide 44
Slide 44 text
RUBYKAIGI2014
Developer Bootstrap
Make it easy to get started on a fresh computer
Slide 45
Slide 45 text
RUBYKAIGI2014
Good for Everyone
Slide 46
Slide 46 text
RUBYKAIGI2014
3 Lessons Learned
1. Sharing code is hard
2. Custom solutions require effort
3. People change
Slide 47
Slide 47 text
RUBYKAIGI2014
Code Changes
People Change
Maintain code, intention, and knowledge!
Slide 48
Slide 48 text
RUBYKAIGI2014
Questions?
• We are hiring (we love new members!)
!
iKnow! Coupon Code:
RubyKaigi2014