The presentation discusses the evolution of Ruby on Rails from simplicity to complexity, focusing on best practices for production, scaling, and bootstrapping in web development. Key recommendations include using PostgreSQL for databases, employing RESTful structure, utilizing tools like Better Errors for debugging, and employing Heroku and S3 for hosting. It highlights the importance of learning from past experiences, such as avoiding certain database-related gems to simplify management and enhance flexibility.

1. Ruby on Rails
From simplicity to complexity
07/03/2014 - Presentation for le Wagon

2. Ruby on Rails
From simplicity to complexity
Going to production
Scaling
Bootstrapping
If we were to start over with Copass,
what are the good choices we’d keep and the lessons we’d learn?

3. Bootstrapping

4. Bootstrapping
★ Database: PostgreSQL
★ Front-End: Bootstrap, jQuery
★ Precompiled languages: Haml,
Coffeescript, SASS, Markdown
★ Debugging: Better Errors
★ Authentication: Devise
★ Version Control: Git, Github (of course)
★ Support: Stackoverflow (of course)
★ REST structure
★ MVC structure
★ Ruby tricks
★ Don’t use DB-related gems
★ Multi-steps signup
★ Avoid front-end gems
★ Name things
LESSONS LEARNEDGOOD CHOICES

5. Markdown http://en.wikipedia.org/wiki/Markdown
❖ Markdown allows you to write using an easy-to-read, easy-to-write
plain text format, then convert it to structurally valid XHTML (or HTML).
❖ Allows to separate
content from logic !
Anyone can edit
markdown documents
❖ Used by Github,
Stackoverflow etc.
Markdown 3 steps

6. Better Errors gem https://github.com/charliesome/better_errors
❖ Best tool for debugging
❖ Displays a live console in your browser
❖ Allows you to:
+ see the content of variables
+ see the source code where
the bug occured
+ includes gem related code
Better error interface

7. REST Structure http://en.wikipedia.org/wiki/Representational_state_transfer
❖ Heard of those GET, POST, PUT, DELETE http methods?
❖ Respect the basics:
➢ GET : fetches one/many objects, doesn’t change any value (read only)
➢ POST : creates an object
➢ PUT : edit an object
➢ DELETE : delete an object
❖ Advantages:
➢ Use the convention among the team
➢ Keeps you router clean
➢ Prevents pages refresh from doing several tie the same action
➢ Good API design

8. Don’t use DB related gem
❖ We all use many gems to bootstrap faster
❖ Don’t use them when they are database related
❖ Eg. Friendships managed with Amistad
➢ Cool, I have a whole set of methods ready (add friend, remove friend, get
friends, get pending requests etc.)
➢ But I need to add a notification level on each friend
➢ And also some friend suggestions
➢ Errr…. you can’t because it is a gem
➢ Hence double data size, harder management etc.
If you really want this gem,
you can either copy paste
its code into your project,
or fork it straight away and
customize it as you need as
if it were your proper code!

9. Going to production

10. LESSONS LEARNED
Going to production
★ Hosting: Heroku + S3
★ Backups: PGBackups Archive
★ Deployment: Deploy Hooks
★ Spam prevention: Negative
Captcha
★ Maintenance: Exception
Notification, Dead Man Snitch
★ Use Paperclip as a service
★ Testing becomes necessary at
this step
GOOD CHOICES

11. Negative Captcha https://github.com/subwindow/negative-captcha
❖ In production, every public form is subject to spam
❖ But Captchas are boring, time consuming, as a user, you’d feel
frustrated, untrusted
❖ Someone invented negative captcha:
❖ Add a fake field that will be filled by robots
but not humans
❖ User experience is the same !
Name
Email
Form
Hidden fieldOk
Filled by Robots not
humans

12. Scaling

13. LESSONS LEARNED
Scaling
★ Web server: Phusion Passenger
★ CDN: Cloudfront
★ Background jobs: Delayed Job +
Workless
★ Database Indexes
★ Memory usage
★ To test: Dynosaur
GOOD CHOICES

14. Workless https://github.com/lostboy/workless
❖ Based on delayed jobs : sends tasks to the background by adding .
delay
➢ Eg.
❖ But for background jobs, you need a Heroku worker which costs
money
❖ The awesomeness of workless is that the worker is automatically
scaled up when there are tasks in the queue, and down when it is over
➢ No extra fees!
def generate_sizes_async(erase= false)
self.delay.generate_sizes(erase)
end

15. Next steps
❖ More front end logic
➢ Angular
❖ Going Mobile, how?
➢ Ruby Motion ( ), Responsive web design, native app with strong
API
Going mobile

16. Tips and reads
❖ Subscribe to RubyWeekly newsletter
❖ Very good articles:
➔ How to get More Bang for your Heroku Buck While Making Your Rails Site Super Snappy
➔ An Introduction To DOM Events
➔ A basic guide to when and how to deploy HTTPS
➔ What every web developer must know about URL encoding
➔ Ruby Styleguide
➔ Github flow

17. ?
Thanks !
Augustin Riedinger
augustin@copass.org

18. http://copass.org