SOLID Design Principles
Agile Software Development - Bob Martin Book is based on developing in Java/C… some interpretation for ruby.
Single Responsibility Open Closed - open for extension … closed for modification Liskov Substition Interface Segregation Dependency Inversion
in rails 0.x ActionView::Base (tracking details, rendering templates, rendering context, etc. ) was monolithic. As rails has maturesd template handling was pulled out. In rails 2.2 view paths was pulled out (support for rails engines). Rails 3 view paths subdivided in to resolvers and view paths. The resolver allows you to put templates anywhere (e.g. database, or web service).
Could use these resolvers to make fixtures for your views.
Created Lookup context to handle the tracking of details… pulled out of ActionView::Base in rails 3. Mainly a code cleanliness item.
AV::Renderer now handles rendering templates
Top Down Comprehension worse Maintainabiliy better focuses comprehension much better extensibility possible
Dependency Inversion principle… depend on abstractions not on contretions. More appropriate for static languanges). In Java you end up using interfaces… in ruby we have duck typing
The following are the ways that rails achieves dependency inversion – define protocols – remove hardcoded dependencies – define hooks
Liskov Substition Principle - derived classes must be substitutable for their base classes. Harder in static languages. e.g. DataMapper vs ActiveRecord
ActiveModel specifies what models are going to be used by the controllers and view model_name persisted? valid? errors to_key to_param
How do we ensure sustitutability? ActiveModel::Lint::Tests
Interface Segregation - clients should depend on as narrow a protocol as possible. Ensure a narrow protocol
ActiveSupport 3 gem ruby facets is the precursor ActiveSupport::Configurable
Maintanable Code … has the right pattern applied, but not overly trying to be a case study
a product is only a product if it is exchanged – budget matters beautiful code is ugly if no one buys it – trade offs are life (code use) – you are not selling code (you are selling a solution running app are what counts)
Document your commit should be trivial and documented.
much easier to tell chef to rebuild postgres instead of trying to do it yourself
be explicit in your versions only lock to git repos that you own (fork it, and make a branch for that app)
Use common deployment methods
Make it easy for other developers (use seeds.rb) The other developer may be you.
Don’t store passwords inthe app Use some other datastore. Use the “app” gem for gathering data store.
update the readme document what access you need for what machines, e.g. where you need to add ssh keys
For existing apps
Fast Page == Happy Client
- page load times count combine javascript and css css sprites asset pipelining in rails 3.1
Caching Optimization Know and love rails view caching fragment cache action cache page cache
Big Session == Slow Site Session objects are a slippery slope to pain Store values not objects
Pick Your Fights don’ make a persisted session for every user
don’t use before after or around filters for object instantiation if it’s not authentication, authorization, or time zone settings then don’t do a filter filters are for state modification
Declare an expressive method such as given_a_logged_in_user and then call that in each block
what you leave iut is almost more important that what you put in
Refactor to API and CAS
This is probably the best talk I have seen yesterday
http://rubyx.com/services/inspect @raasdnil
http://speakerrate.com/talk/7575 flog and flail
DRY Principle - not Don’t Repeat Yourself, but a piece of knowledge must have a single unambiguous authoratative representation
weird in ruby because almost everything is an abstraction
level of abstraction
duplication is evil
change it in one of the necessary places.
train wrecks of multiple object calls
out of favor…
the rest