Keeping Rails on the Tracks
•Télécharger en tant que KEY, PDF•
3 j'aime•2,677 vues
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...
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Keeping Rails on the Tracks
Similaire à Keeping Rails on the Tracks (20)
Dernier
Dernier (20)
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/
- 4. Experience
- 6. Sexy Code?
- 8. A Product is Only a Product if it is Exchanged
- 9. Budget Matters Beautiful code is ugly if no one buys it
- 10. Trade-Offs are Life Decide 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 Setup Use Chef / Puppet / whatever Repeatable Configuration
- 14. Use Bundler Removes Deployment Pain Be explicit with versions Only 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 Security Don’t store passwords in the app Use some other data store
- 18. Using “app” Gem
- 19. Document It Update 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 table Removed sessions for non customers Appdex went from 10% => 98%
- 25. Opinions Matter
- 27. Use the idioms
- 29. Being Smart can be Stupid
- 30. Explicit Methods Don’t use before, after and around filters for object instantiation Filters are for state modification
- 31. Keep Tests Simple Computers are good at nesting Humans less so
- 33. Use Helpers Instead before & after should only maintain the test environment Keep tests “wet”
- 34. Hard to read
- 35. Easy to Read
- 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
- 38. Reinvention is Over Rated
- 41. Use the right tool for the job
- 42. Cucumber is not Unit Testing
- 43. You too can refactor
- 44. You too can refactor
- 45. Read Ruby Docs Go and read the standard Ruby documentation online
- 46. Databases have feelings too
- 47. You don’t need database agnostic code Make use of your database features Out of 50 apps, one is migrating DB
- 48. Instantiation is Slow Report run in ruby: 45 minutes Equivalent SQL query: 15 seconds
- 49. Use the DB tools you have Migrate legacy data with Active Record: 150 hours PostgreSQL COPY with generated CSV: 74 mins
- 50. Don’t Share the DB 12 rails apps against one BIG database 12 places for migration files Refactor to API calls and CAS for auth
- 52. Beware the Train Wreck
- 53. Control flow is code smell DEMO (control_flow_demo.rb) 85 line 10 if else statement method
- 54. How to stay on track?
- 55. Get an Inspection Many consultancies do this Ask for a sample rubyx Inspect Service rubyx.com/services/inspect
- 57. Questions? Mikel Lindsaar @raasdnil rubyx.com rubyx.com/services/inspect speakerrate.com/talks/7575
Notes de l'éditeur
- \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