25 Real Life Tips In Ruby on Rails Development
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

25 Real Life Tips In Ruby on Rails Development

  • 12,419 views
Uploaded on

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

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).

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
12,419
On Slideshare
12,207
From Embeds
212
Number of Embeds
20

Actions

Shares
Downloads
189
Comments
0
Likes
19

Embeds 212

http://rubyrailsandwindows.blogspot.com 46
http://www.slideshare.net 33
https://twitter.com 29
http://mydeveloperdays.blogspot.com 27
http://fredbaa.com 17
http://192.168.6.184 14
http://drixenol.posterous.com 13
http://rubyrailsandwindows.blogspot.com.br 6
http://drixenol.tumblr.com 5
http://mydeveloperdays.blogspot.be 5
http://rubyrailsandwindows.blogspot.com.au 4
http://mydeveloperdays.blogspot.fr 3
http://teamco-anthill.blogspot.com 2
http://rubyrailsandwindows.blogspot.in 2
http://a0.twimg.com 1
http://posterous.com 1
http://rubyrailsandwindows.blogspot.ch 1
https://si0.twimg.com 1
http://rubyrailsandwindows.blogspot.no 1
http://drixenol.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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.