Copass + Ruby on Rails = <3 - From Simplicity to Complexity
Upcoming SlideShare
Loading in...5

Copass + Ruby on Rails = <3 - From Simplicity to Complexity



Presentation made at le Wagon ( to give tips and learnings from the experience of building Copass ( with Ruby on Rails. ...

Presentation made at le Wagon ( to give tips and learnings from the experience of building Copass ( with Ruby on Rails.
Interesting gems, dangerous ones, tips and readings, to get started with good practices on Rails at 3 steps of a project:
- Bootstrapping
- Going on production
- Scaling



Total Views
Views on SlideShare
Embed Views



4 Embeds 38 16 15
http://localhost 5 2



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.

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

Copass + Ruby on Rails = <3 - From Simplicity to Complexity Copass + Ruby on Rails = <3 - From Simplicity to Complexity Presentation Transcript

  • Ruby on Rails From simplicity to complexity 07/03/2014 - Presentation for le Wagon
  • 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?
  • Bootstrapping
  • 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
  • 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
  • Better Errors gem ❖ 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
  • REST Structure ❖ 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
  • 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!
  • Going to production
  • 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
  • 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
  • Scaling
  • LESSONS LEARNED Scaling ★ Web server: Phusion Passenger ★ CDN: Cloudfront ★ Background jobs: Delayed Job + Workless ★ Database Indexes ★ Memory usage ★ To test: Dynosaur GOOD CHOICES
  • 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
  • Next steps ❖ More front end logic ➢ Angular ❖ Going Mobile, how? ➢ Ruby Motion ( ), Responsive web design, native app with strong API Going mobile
  • 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
  • ? Thanks ! Augustin Riedinger