Keeping Rails on the Tracks         Mikel Lindsaar           @raasdnil          lindsaar.net
Working in Rails & Ruby for 5+ Years         http://lindsaar.net/        http://stillalive.com/         http://rubyx.com/
On the Rails?
Experience
Working Code?
Sexy Code?
Maintainable Code?
A Product is Only a  Product if it is    Exchanged
Budget MattersBeautiful code is ugly if no one buys it
Trade-Offs are LifeDecide how much refactoring needed        based on code use
You are not selling code     You are selling a solution    Running app are what counts
Deployment is a First   Class Citizen
Server SetupUse Chef / Puppet / whatever Repeatable Configuration
Use Bundler  Removes Deployment Pain   Be explicit with versionsOnly lock to git repos you own
Repeatable Deployment      Get the staging server up  Use common deployment methods
Make a db/seeds.rb file  Make it easy for other Developers  The “other developer” may be you!
Link in SecurityDon’t store passwords in the app   Use some other data store
Using “app” Gem
Document ItUpdate that README file!
Fast Page == Happy Client
Page Load Times Count      Combine Javascript and CSS               CSS Sprites       Asset Pipelining in Rails 3.1  Befor...
Caching Optimisation  Know and love Rails view caching:          Fragment Cache           Action Cache            Page Cac...
Big Session == Slow Site Session objects are a slippery slope to pain           Store values, not objects             10k ...
Pick Your Fights  Don’t make a persisted session     “cart” for every visitor   500,000 rows in sessions tableRemoved sess...
Opinions Matter
Use Pluralization
Use the idioms
Remove Useless Code
Being Smart can be Stupid
Explicit MethodsDon’t use before, after and around filters        for object instantiation    Filters are for state modifica...
Keep Tests SimpleComputers are good at nesting       Humans less so
Use Helpers Insteadbefore & after should only maintain the test environment                   Keep tests “wet”
Hard to read
Easy to Read
Simple is better than     Complex   What you leave out is almost more    important than what you put inMeta Programming ha...
Good Code is Easy to Read  Good code might be non trivial to implement      But should be trivial to understand.         T...
Reinvention is Over Rated
Reinventing Controllers
Reinventing Controllers
Use the right tool   for the job
Cucumber is not  Unit Testing
You too can refactor
You too can refactor
Read Ruby DocsGo and read the standard Ruby    documentation online
Databases have feelings too
You don’t needdatabase agnostic code  Make use of your database features  Out of 50 apps, one is migrating DB
Instantiation is Slow  Report run in ruby: 45 minutes Equivalent SQL query: 15 seconds
Use the DB tools you haveMigrate legacy data with Active Record: 150 hours PostgreSQL COPY with generated CSV: 74 mins
Don’t Share the DB12 rails apps against one BIG database     12 places for migration filesRefactor to API calls and CAS for...
Code hasresponsibilities
Beware the Train Wreck
Control flow is   code smell                DEMO      (control_flow_demo.rb)85 line 10 if else statement method
How to stay on track?
Get an Inspection  Many consultancies do this      Ask for a sample    rubyx Inspect Service  rubyx.com/services/inspect
Maintainable Code
Questions?      Mikel Lindsaar        @raasdnil       rubyx.comrubyx.com/services/inspect
Keeping Rails on the Tracks
Keeping Rails on the Tracks
Upcoming SlideShare
Loading in …5
×

Keeping Rails on the Tracks

5,080 views

Published on

It's not what you code, it's how you code it. In this talk, I'll take you through real world examples of code drawn from the 40+ production Rails applications we have developed and maintained during the last 12 months and highlight anti patterns and examples of technical code debt in them. You do what you can do to avoid these, making your future lives simpler. Your future you will thank you...

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,080
On SlideShare
0
From Embeds
0
Number of Embeds
48
Actions
Shares
0
Downloads
63
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • What do I mean by on the rails?\nApps that work and are easy to maintain & bug free\n
  • helped write, rewrite, support or review 40 production rails last 12 months\nreleased a non trivial gem - mail\nmaintained a non trivial gem - tmail\nmade many patches to Rails itself, in the top 20 committers\n
  • This is the one end of the pragmatic scale\nDevs that are paid to “make it work”\ntake the “green light, red light approach” too far.\nIs it running? Yes, therefore it is working - leads to messy code\n\n
  • This is the other end of the pragmatic scale\nDevs that get upset if something doesn’t look right or is not super neat\nTime wasters on large scale projects\nSexy code is nice to have, but often a waste of money\n
  • This is probably the middle ground\nCode that works\nCode that is neat and tidy, but not sacrificing budget for that\nCode that can be maintained\n
  • This is pretty critical to all Rails developers. \n\n
  • \n
  • Touched once a year, or once a month. Refactor the latter\n
  • Internal or External client doesn’t matter\n
  • This has been said by many people - not the first\nNeed to be able to deploy - make it a trivial and repeatable one liner\n\n
  • Much easier to run a chef recipe that you know will work at 3am than remember how to install postgres\n
  • Not specifying versions in the Gemfile leads to future pain\nAt least limit using the ~> control\nLock to your own github fork, and at least specify branch or sha1\nNever “lock” to open versions\nEdge rails in bundler, seriously!?\n
  • capistrano, or ey deploy, or heroku git deploy\n
  • In 6 months you will have no idea what you need to get it working\n
  • \n
  • \n
  • Should be able to open the readme and deploy your app\nInclude authorisation needed (ssh keys on server or whatever)\n
  • \n
  • Trivial in Rails 3.1\nRails 3 and lower, Jammit and other tools\n
  • \n
  • \n
  • row session database store... no fun.\nFile system is just asking for trouble - not scalable\nIf follow previous two advices then overhead is minimal and very scalable\n
  • \n
  • Breaks conventions - hard to code and remember\nSimple fix using inflectors\n
  • \n
  • Less code written == less bugs\n
  • \n
  • Valid uses of filters: timezones, authorization, authentication et al.\nReasons: filters inherit, easy to get lost.\nUse explicit helpers\n
  • We need to see context, as close to content as possible\n
  • \n
  • Don’t use before and after for app related activities\n
  • Especially 2 pages down, where you can’t see the before block\n
  • Easy to read no matter where you are in the test, also less context switching\n
  • Long writing methods better than dynamic if you can get away with it\nMeta programming has it’s place, that place is not\n\n\n
  • \n
  • \n
  • Becomes code smell because you need to relearn simple idioms\n
  • \n
  • \n
  • Making cucumber specs that should be unit tests\n
  • 5 level nested ternary INSIDE A STRING - 343 characters, one line\nGood t-shirt print\n
  • \n
  • Array, String, Hash, Ennumerator\n
  • \n
  • Use migrations\nGood for development and testing\nBad for production, get into the SQL and make the DB sing\n
  • Object instantiation is slow\n
  • \n
  • \n
  • \n
  • Trivial example, but valid, train wrecks also can blow up your database\n
  • You can ALWAYS refactor control flow into object messages\nCleaner code, easier to read\nAgain, be pragmatic, and pick your fights\n
  • What do I mean by on the rails?\nApps that work and are easy to maintain & bug free\n
  • \n
  • This is probably the middle ground\nCode that works\nCode that is neat and tidy, but not sacrificing budget for that\nCode that can be maintained\n
  • \n
  • \n
  • Keeping Rails on the Tracks

    1. Keeping Rails on the Tracks Mikel Lindsaar @raasdnil lindsaar.net
    2. Working in Rails & Ruby for 5+ Years http://lindsaar.net/ http://stillalive.com/ http://rubyx.com/
    3. On the Rails?
    4. Experience
    5. Working Code?
    6. Sexy Code?
    7. Maintainable Code?
    8. A Product is Only a Product if it is Exchanged
    9. Budget MattersBeautiful code is ugly if no one buys it
    10. Trade-Offs are LifeDecide how much refactoring needed based on code use
    11. You are not selling code You are selling a solution Running app are what counts
    12. Deployment is a First Class Citizen
    13. Server SetupUse Chef / Puppet / whatever Repeatable Configuration
    14. Use Bundler Removes Deployment Pain Be explicit with versionsOnly lock to git repos you own
    15. Repeatable Deployment Get the staging server up Use common deployment methods
    16. Make a db/seeds.rb file Make it easy for other Developers The “other developer” may be you!
    17. Link in SecurityDon’t store passwords in the app Use some other data store
    18. Using “app” Gem
    19. Document ItUpdate that README file!
    20. Fast Page == Happy Client
    21. Page Load Times Count Combine Javascript and CSS CSS Sprites Asset Pipelining in Rails 3.1 Before combination: 40 asset requests After combination: 5 asset requests
    22. Caching Optimisation Know and love Rails view caching: Fragment Cache Action Cache Page Cache Before fragment cache: 2480ms After fragment caching: 120ms
    23. Big Session == Slow Site Session objects are a slippery slope to pain Store values, not objects 10k session record 5,000 new sessions per month 500mb session table in DB
    24. Pick Your Fights Don’t make a persisted session “cart” for every visitor 500,000 rows in sessions tableRemoved sessions for non customers Appdex went from 10% => 98%
    25. Opinions Matter
    26. Use Pluralization
    27. Use the idioms
    28. Remove Useless Code
    29. Being Smart can be Stupid
    30. Explicit MethodsDon’t use before, after and around filters for object instantiation Filters are for state modification
    31. Keep Tests SimpleComputers are good at nesting Humans less so
    32. Use Helpers Insteadbefore & after should only maintain the test environment Keep tests “wet”
    33. Hard to read
    34. Easy to Read
    35. Simple is better than Complex What you leave out is almost more important than what you put inMeta Programming has its place, that place is probably not in your Rails App
    36. Good Code is Easy to Read Good code might be non trivial to implement But should be trivial to understand. The more bad code you have, the closer you are to a rewrite
    37. Reinvention is Over Rated
    38. Reinventing Controllers
    39. Reinventing Controllers
    40. Use the right tool for the job
    41. Cucumber is not Unit Testing
    42. You too can refactor
    43. You too can refactor
    44. Read Ruby DocsGo and read the standard Ruby documentation online
    45. Databases have feelings too
    46. You don’t needdatabase agnostic code Make use of your database features Out of 50 apps, one is migrating DB
    47. Instantiation is Slow Report run in ruby: 45 minutes Equivalent SQL query: 15 seconds
    48. Use the DB tools you haveMigrate legacy data with Active Record: 150 hours PostgreSQL COPY with generated CSV: 74 mins
    49. Don’t Share the DB12 rails apps against one BIG database 12 places for migration filesRefactor to API calls and CAS for auth
    50. Code hasresponsibilities
    51. Beware the Train Wreck
    52. Control flow is code smell DEMO (control_flow_demo.rb)85 line 10 if else statement method
    53. How to stay on track?
    54. Get an Inspection Many consultancies do this Ask for a sample rubyx Inspect Service rubyx.com/services/inspect
    55. Maintainable Code
    56. Questions? Mikel Lindsaar @raasdnil rubyx.comrubyx.com/services/inspect

    ×