brown bag: oo design

• dependency inversion: depend on abstractions, don’t depend on concretions.
• Liskov substitution: don’t violate superclass by using is_kind_of; they should return the same type

Test

• does it have one responsibility?
• it is DRY?
• does everything in it changes at the same rate?
• is it open for extension but not for modification?
• does it depend on things that change less often than it does?

select rows with a column that occurs more than once

SELECT lname FROM Celebrities 
  GROUP BY lname HAVING COUNT (lname) >1

after_commit

http://inductor.induktiv.at/blog/2010/09/01/after-commit-callbacks/

http://rails-bestpractices.com/posts/695-use-after_commit

http://stackoverflow.com/questions/2220788/rails-after-commit

helper and auto_increment in DB

Methods in helpers are always available in the views, and can be included in controllers.

Auto_increment for some column like id is global. So when you do transaction and you set id=4, and then it is failed; the next available id will be 5, not 4.

Ruby 1.9 changes

To read and make notes http://blog.grayproductions.net/articles/getting_code_ready_for_ruby_19

CSV is built into Ruby 1.9

In Ruby 1.9, fasterCSV has been made the implementation of the stdlib
CSV, so we remove the rubygems (which btw, is also
included by default in 1.9) and just make require 'csv' and CSV
instead of FasterCSV.

http://ruby-doc.org/stdlib/libdoc/csv/rdoc/index.html

the return of JSON parse is not string

require ‘json’

>> a={“use”=>false}
=> {“use”=>false}
>> b=a.to_json
=> “{\”use\”:false}”
>> c=JSON.parse b
=> {“use”=>false}
>> if not c[“use”]
>> puts “json parse gives true and false boolean values”
>> end
json parse gives true and false boolean values
=> nil