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...
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 table
Removed sessions for non customers
Appdex went from 10% => 98%
36. Simple is better than
Complex
What you leave out is almost more
important than what you put in
Meta Programming has its place, that place
is probably not in your Rails App
37. 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
57. Questions?
Mikel Lindsaar
@raasdnil
rubyx.com
rubyx.com/services/inspect
speakerrate.com/talks/7575
Editor's Notes
\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