-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME
157 lines (111 loc) · 3.29 KB
/
README
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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
=== Windy City Rails ===
Metrics based refactoring
=========================
metric_fu - Jake Scruggs
http://github.com/jscruggs/metric_fu
* Flog - code complexity
** http://ruby.sadi.st/Flog.html
* Saikuro - cyclomatic complexity
** http://saikuro.rubyforge.org
* Reek - bad design detector
** http://github.com/kevinrutherford/reek
Rails 3.1
=========
* Rails 2.3.9 - deprecation notices for upgrading
* Engines
** http://piotrsarnacki.com/2010/09/14/mountable-engines/
** Namespacing
** Engine specific routes
** Migrations
Various WCR Notes
=================
* In many web applications, dynamic generation takes factors of less time than static pull of content, and so going nuts over optimizing the first part of the pull will only effect that small factor
* Open source community is a marketplace
===== Railsconf ======
How to work with legacy code
============================
Tests really help allowing you to make change
This is not every place in your codebase
Test around your hotspots
Look at your commit history
Do bug fixes cause more bug fixes?
3 Experiments
Find the most executed paths of your code
These should be cleanest and tested
Play Open / Closed Whack-a-mole
Good code is open to extension but closed to modification
Run dojo experiments
take the same piece of code and throw it at 30 developers
run again - how do they change the code
how do we react when confronted with code
how does the way we structure frame how people react
Yehuda After Hours
==================
Hey you - you're overriding behavior incorrectly
------------------------------------------------
class Person
def say(thing)
puts thing
end
end
Person.new.say('hello')
class Person
alias old_say say
def say(thing)
old_say thing.upcase
end
end
### easier way ###
module Speaker
def say(thing)
puts thing
end
end
class Person
include Speaker
end
Person.new.say('hello')
module Yeller
def say(thing)
super(thing.upcase)
end
end
class Person
include Yeller
end
Person.new.say('hello')
ActiveSupport::Concern
----------------------
ActiveSupport::Concern # instead of doing self.included
# will pull in ClassMethods automagically
module MyFeature
extend ActiveSupport::Concern
included do
end
end
Deep and dirty in Rails
=======================
Things to know when trying to share state w/ threads
----------------------------------------------------
threading - 3 tips - don't - do not share state - do not share mutable state
operator assignment is not atomic
+=
||=
gem install atomic # an Atomic class that guarantees atomic updates to its contained value
my_atomic = Atomic.new(0)
my_atomic.update {|v| v + 1}
begin
my_atomic.try_update {|v| v + 1}
rescue Atomic::ConcurrentUpdateError => cue
# deal with it (retry, propagate, etc)
end
no thread safe string, array, or hash
do not use mutating operation
define_method
blocks carry carry around too much state
GC hidden cost of object-heavy languages
do not create so many objects # fewer objects == better performance
Side Note that I liked
----------------------
Tests are tests - the red part of red, green, refactor
if it doesn't turn red - your tests aren't testing anything