25 REAL LIFE TIPS IN
RUBY ON RAILS DEVELOPMENT
         Nicolas Jacobeus
            @jacobeus
THE F*CK IS THIS?


• Real   life ideas from real life apps

• Aim: elegant, secure, maintainable      apps

• Production ...
LET’S START

 25 24 23 22 21
 20 19 18 17 16
 15 14 13 12 11
   10 9 8 7 6
    54321
a x
nt
sy



           1. CROSS THE CHANNEL


 • Only    code in english

 • Pay    attention to the speling, but also to...
x
               2. AVOID AWKWARD
   a
nt
sy




                     SILENCES
 • Forbid   trailing whitespaces

 • Forbid...
3. {{SOME STUPID WORD
ch
ar




               PLAY ON REST}}

 • Use   REST everywhere, by default

 • Only   difficult in...
ch
ar



          4. ORGANIZE YOUR APP


 • Don’t  be afraid to enhance the Rails
   directory structure

 • Tellrails ab...
ch
ar



                   5. KICK RJS OUT


 • RJS   = Javascript written in Ruby and sent asynchronously

 • XMLHttpReq...
6. CONSIDER PRESENTERS
  ch
ar




           AND CONDUCTORS
 • Presenter

   • layer   between the controller and the vie...
ls
          7. UNDERSTAND MODEL
   e
od
m




                 HOOKS

    • before_validation: forprocessing user-submitt...
els
od
m



     8. ORGANIZE YOUR MODELS
    • Keep    consistent in the way you code your models

    • I’m   used to thi...
els
od
m



              9. OBSERVE BY ASPECT

    • Observers    can manage multiple models

    • Make    one observer ...
s
          10. DON’T CALL THE DB
 w
vie




             FROM YOUR VIEWS
 • MVC     : no call to the model layer from vie...
s
 w
vie



        11. CONSIDER HAML/SASS


 • More   concise than vanilla
      HTML/CSS

 • Prevents    you from invali...
s
   er
   lp
he



                12. HELP YOUR VIEWS

  • Use     helpers for

        • repeated   chunks of view code...
s
   er
            13. USE THE BEST
   lp
he




        LANGUAGE FOR EACH TASK


  • Generate    HTML in HTML (or Haml ;...
s
   er
   lp
he



                 14. HELP BY ASPECT

  • Rails   generate by default one helper per controller

  • Er...
s
   er
   lp
he



    15. USE CLEVER LINK HELPERS

  • You     often have presentation logic which depends on the
      ...
rs
     lle
       16. MINIMIZE INTERACTIONS
  ro
nt
co




            BETWEEN C AND M

     • Only call a model once in ...
rs
     lle
  ro
nt
co



                  17. SKINNY C, FAT M


     • Put   all business logic in your model

     • Th...
rs
     lle
                18. KEEP CONSISTENT
  ro
nt
co




                    CONTROLLERS


     • Try   to keep the ...
e
   as
                19. AVOID DATA IN
 abt
da




                    MIGRATIONS


  • There’s   a rake db:seed task f...
e
   as
          20. PAY ATTENTION TO
 abt
da




            RDBMS DATATYPES


  • Length    of fields

  • Varchar   vs....
y
  rit
                 21. XSS-PROTECT
  cu
se




                YOUR TEXT FIELDS

  • XSS   = cross-site scripting

 ...
y
  rit
         22. PROTECT YOUR FIELDS
  cu
se




         FROM MASS-ASSIGNMENT

  • @user.update_attributes(params[:us...
y
  rit
  cu
se



             23. SCOPE BY DEFAULT

  • In   your controllers, scope every request to the current user

...
y
   plo

          24. DEPLOY WITH GREAT
de




                  TOOLS


  • What   works well for us (for the moment!):...
isc
m



                        25. USE RUBY

• In   case you didn’t know, Rails is based on it.

• Embrace      function...
THANKS


This is the last slide, ‘cause my talk is over.
Upcoming SlideShare
Loading in …5
×

25 Real Life Tips In Ruby on Rails Development

14,002 views

Published on

This is a collection of small tips and tricks related to developing web applications using the Ruby on Rails framework.

These tips are gathered from my personal experience of 4 years working with the framework, including more than 2 years of professional work at Belighted.

The talk was given in the Ruby on Rails Developer Room at Fosdem 2010 (www.fosdem.org).

Published in: Technology

25 Real Life Tips In Ruby on Rails Development

  1. 25 REAL LIFE TIPS IN RUBY ON RAILS DEVELOPMENT Nicolas Jacobeus @jacobeus
  2. THE F*CK IS THIS? • Real life ideas from real life apps • Aim: elegant, secure, maintainable apps • Production code • Tips, not rules
  3. LET’S START 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 54321
  4. a x nt sy 1. CROSS THE CHANNEL • Only code in english • Pay attention to the speling, but also to the meaning • IT = information technology
  5. x 2. AVOID AWKWARD a nt sy SILENCES • Forbid trailing whitespaces • Forbid useless empty lines • Forbid space/tabs mixes • Why: • There are people who care • Nobody likes useless/noisy diff files
  6. 3. {{SOME STUPID WORD ch ar PLAY ON REST}} • Use REST everywhere, by default • Only difficult in some cases • Links from email (always GET) • Interaction without other tools (payment gateways, etc.)
  7. ch ar 4. ORGANIZE YOUR APP • Don’t be afraid to enhance the Rails directory structure • Tellrails about it in config/environment.rb
  8. ch ar 5. KICK RJS OUT • RJS = Javascript written in Ruby and sent asynchronously • XMLHttpRequest (XHR) is for sending data asynchronously • Keep the behaviour in your behaviour (JS) files
  9. 6. CONSIDER PRESENTERS ch ar AND CONDUCTORS • Presenter • layer between the controller and the view • holds all the presentation stuff related to your model (formatted currency/dates, etc.) • Conductor • layer between the model and the controller • handles multi-model forms
  10. ls 7. UNDERSTAND MODEL e od m HOOKS • before_validation: forprocessing user-submitted data before validating it (ex.: lowercase domain name etc.) • before_save: for saving computed stuff in the model (like timestamps, hashes, ...) • after_save: for updating related models • Never call save/update in a hook!
  11. els od m 8. ORGANIZE YOUR MODELS • Keep consistent in the way you code your models • I’m used to this order: • behavior-related stuff (usually from plugins like acts_as_...) • relationships (belongs_to/has_many) and named_scopes • validations • hooks • attributes-related stuff • methods grouped by aspect (authentication, messaging, ...)
  12. els od m 9. OBSERVE BY ASPECT • Observers can manage multiple models • Make one observer per purpose, for example • notification observer • mail observer • referral observer
  13. s 10. DON’T CALL THE DB w vie FROM YOUR VIEWS • MVC : no call to the model layer from views • All dynamic data should be defined in controller variables @users_count vs. @users.count • Why: • Separation of concerns / loose coupling • Unit testing
  14. s w vie 11. CONSIDER HAML/SASS • More concise than vanilla HTML/CSS • Prevents you from invalid markup • HTML5-compatible
  15. s er lp he 12. HELP YOUR VIEWS • Use helpers for • repeated chunks of view code (will DRY your views) • presentation logic like first_tab_is_active? (will make your code more readable) • You can also use helper_method if you need the logic in controllers as well
  16. s er 13. USE THE BEST lp he LANGUAGE FOR EACH TASK • Generate HTML in HTML (or Haml ;-)) • Avoid content_tags in helpers, rather call partials • Easier for html slicers to understand
  17. s er lp he 14. HELP BY ASPECT • Rails generate by default one helper per controller • Erase them all and use aspect-oriented helpers • links_helper • menu_helper • avatar_helper
  18. s er lp he 15. USE CLEVER LINK HELPERS • You often have presentation logic which depends on the context • Example: a link to a profile page in a social network • is it you ? / one of your friends ? / someone else ? • create link_to_user which will point to the good controller
  19. rs lle 16. MINIMIZE INTERACTIONS ro nt co BETWEEN C AND M • Only call a model once in each controller method (besides save/update) • Why: • Separation of concerns (prevents inconsistency if several controllers deal with the same models) • Keep all the logic related to the model in one place
  20. rs lle ro nt co 17. SKINNY C, FAT M • Put all business logic in your model • The role of the controller layer is to • get user input and send it to the model layer • send the answer back to the user
  21. rs lle 18. KEEP CONSISTENT ro nt co CONTROLLERS • Try to keep the same order in your REST methods • I’mused to INCSEUD (typical workflow) index / new / create / show / edit / update / destroy
  22. e as 19. AVOID DATA IN abt da MIGRATIONS • There’s a rake db:seed task for your “kickstart” data • For demo/dev data, create your own rake tasks • Exception: refactoring-related migrations sometimes need data
  23. e as 20. PAY ATTENTION TO abt da RDBMS DATATYPES • Length of fields • Varchar vs. char vs. text • Integer rather than float for currency
  24. y rit 21. XSS-PROTECT cu se YOUR TEXT FIELDS • XSS = cross-site scripting • Protect all your text fields which are manipulated by the user • xss_terminate plugin • Don’t protect serialized fields
  25. y rit 22. PROTECT YOUR FIELDS cu se FROM MASS-ASSIGNMENT • @user.update_attributes(params[:user]) # { :admin => true } • Users can forge form submission (with cURL, etc.) • Put an empty attr_accessible clause in each model upon creation, and add “safe” fields one by one
  26. y rit cu se 23. SCOPE BY DEFAULT • In your controllers, scope every request to the current user • current_user.messages.find(params[:id]) • current_user.messages.build(params[:message]) • Even in methods where it’s not necessary (like new), for consistency
  27. y plo 24. DEPLOY WITH GREAT de TOOLS • What works well for us (for the moment!): • Ruby Enterprise Edition + nginx + Capistrano + GitHub • Heroku
  28. isc m 25. USE RUBY • In case you didn’t know, Rails is based on it. • Embrace functional programming thing.select {|t| t.valid?}.map {|t| t.stuff}.flatten.uniq • Don’t be afraid of meta-programming, it can help you! • Create domain-specific languages for your app • Generate groups of similar methods at once
  29. THANKS This is the last slide, ‘cause my talk is over.

×