Reuven Lerner's presentation from Open Ruby Day in Herzliya, Israel on June 27th, 2010. I covered a few tools that are not part of Rails, but which help you with deployment,
2. You shipped!
• Your Web application works
• Everyone thinks that you’re a genius
• Your new application is revolutionary
• Too bad your parents still don’t know quite
what you do for a living
3. Just a few tasks remain
• Find bottlenecks and optimize code
• Find code problems (“smells”), and refactor
• Learn about (and fix) bugs ASAP
• Handle all of this without breaking a sweat
4. Rails can’t help you
• Rails helps you during development
• But it doesn’t try to solve all problems
• There are lots of add-ons that work with
Rails, which make life much easier
• This talk is about those tools
5. • Deployment tool for Rails applications
• Has been around for several years
• “capify” in the root Rails directory
• Creates small “Capfile” in root
• Creates config/deploy.rb
6. What does it do?
• Run “cap deploy” on development machine
• Capistrano:
• Gets latest version from Git/SVN/CVS
• Installs latest version in a new directory
on production server(s)
• Makes a “current” symlink to new dir
7. So what?
• Push to any number of servers
• Keep around old versions, just in case
• Always retrieve from version control
• Add new recipes for your own needs
• Adding/removing servers becomes trivial
10. A simple recipe
namespace :rake do
desc "Generate a sitemap on a remote server."
task :generate_sitemap do
run("cd #{deploy_to}/current; /usr/bin/rake
sitemap:generate RAILS_ENV=production")
end
end
11. My favorite feature
cap deploy:rollback
• It takes only a moment, because it’s just
rewriting a symlink
• Unnecessary if you never make mistakes
12. Check your errors
• “Exception notifier” plugin was popular for
many years
• Free plugin that sends e-mail on 500 errors
13. • You can try it at hoptoadapp.com
• Free version is good enough for many of
my needs
• Get e-mail exception information
• Also get a Web-based interface
• Mark bugs as having been resolved
14.
15.
16. Can’t you just use logs?
• Yes, but this is more convenient
• “Similar errors” functionality is useful
• Integration with GitHub, Lighthouse
• Reset bug counts when you deploy
• Besides, I like smiling frogs
17.
18. Check your code
• Your code can always use improvement
• Metacognition, reflection assist learning
• Pair programming is good for this
• Not appropriate for everyone
• Get it from a computer, if not a person
• At least you can turn the computer off
19. Code-checking tools
• Ruby has a large (and growing number) of
tools that examine your code
• Many of these are combined in the
metric_fu gem
• Gives you a good sense of the quality of
your code
• If you disagree, no one has to know!
20.
21. metric_fu includes
• Churn — which files were changed the most in version control
• Flay — looks for potential duplication across files
• Flog — measures code complexity
• Rcov — code coverage from your tests
• Reek — looks for “code smells”
• Roodi — looks for design issues
• Saikuro — looks at cyclomatic complexity
• Rails best practices — looks for common Rails problems
24. What if you disagree?
• Ignore Reek
• Or think about it again
• Or change the configuration
• Or e-mail Kevin Rutherford
• (Don’t just say, “What a stupid program.”)
26. Rails best practices
• New in metric_fu
• Based on a presentation at a Shanghai Ruby
discussion
• http://github.com/flyerhzm/
rails_best_practices
• Helps to keep bad practices in check
27. Typical suggestions
• Move code from view into controller
• Move code from controller into model
• Law of demeter (long.chain.of.method.calls)
• Use before_filter
• Add database index
• Move finder to named scope
29. Check your
performance
• Simple benchmarks can be put in code
• I put all sorts of comments in views, logs
• But that implies you know where to look!
• Quick, what are the 5 slowest methods in
your application?
• How many people are affected by them?
30. One option: RPM
• New Relic RPM monitors performance
• Your app sends info to it every so often
• New Relic makes aggregate data available
• Free version is often good enough
• Paid versions are worthwhile if your
business depends on the app!
31.
32.
33.
34.
35. Summary
• Rails is great for developing Web apps
• But there is a whole ecosystem of tools
that can help you to improve your apps
even further
• Many of them are free!
• New ones emerge every month