-
Notifications
You must be signed in to change notification settings - Fork 1
/
keeping_rails_on_tracks.txt
49 lines (45 loc) · 2.16 KB
/
keeping_rails_on_tracks.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Keeping Rails on Tracks presentation
slides: http://speakerrate.com/talks/7575
What does on th Tracks mean?
* working code?
* sexy code?
* maintainable code? (can other people read it?)
* a product is only a product when it is delivered. What is the product?
* budget matters - don't waste time on code if it won't be a product, and spend time wisely
* trade-offs are part of life - not all ugly code needs refactoring
* you are not selling code - you sell a solution
* deployment is a first class citizen
* document how to do this in README
* server setup needs to have a repeatable configuration
* use bundler
* be explicit in versions
* only lock to git repos you own. Fork the ones you don't own, make a branch, and then depend on your branch of your fork.
* repeatable deployment - use common deployment methods
* make a db/seeds.rb file
* link in security - no passwords stored in source control
* document:
* steps to deploy
* are SSH keys necessary
* db seeding and setup
* fast page == happy client
* minify js and css; use css sprites
* use rails caching: fragment cache, action cache, page cache
* big session == slow site
* session values, not session objects
* store only strings or numbers
* don't create a session for every visitor, only do it for visitors that become customers
* less code == less bugs
* being smart can be stupid
* keep tests simple
* use test helpers to keep blocks of code from getting too big to read
* simple is better than complex - what you leave out is almost more important than what you put in
* good code is easy to read - The harder it is to read, the more likely it will have to be rewritten
* reinvention is overrated
* use the write tool for the job
* databases have feelings too - you don't need database agnostic code if db isn't going to change
* raw SQL is OK to use if it drastically saves time
* don't share the db - refactor into API calls
How to stay on track?
* apps that work, are easy to maintain, and bug-free
* MAKE RAILS CODE MAINTAINABLE
* get your code inspected. many consultants do it. ask for a sample.