Dave Thomas & Jim Weirich: Metaprogramming
Class methods in Ruby are not class methods; they're singleton methods on class objects.
It's not syntax that defines the class method, it's execution.
Jim Weirich: "I avoid the @@ variables."
Lot of pressure to put it in
Hated it all along
For very good reasons
Every subclass gets their own copy
No real inheritance per se - copies, not navigating the tree (?)
Taking it out?
Key to metaprogramming: track the value of self
JW: When confused, treat classes as objects.
e.g.: module A # etc ; class Dave ; end ; Dave.extend A
There's an included, similar to extended
Xyz.send :include, Class == module Xyz ; include Class ; end
That send fails in 1.9!
Why? -> Code closer to domain
Coding close to the application domain = good
Show tests to client -> get buy-in -> "major loophole in testing philosophy"
Chad Fowler & Marcel Molina: Well-factored Rails
Quick & Dirty vs. Slow & Clean
not any more!
Making the same comments frequently
Leaky Abstractions everywhere
TCP/IP -> leaks because TCP enables guaranteed connectivity, but unplugging computer violates abstraction, so high-level code needs to address failures of the low-level code to genuinely represent its problem space
Unless you understand the SQL which Rails generates, your application will suck. Guaranteed.
Keep tail -f log open all the time; understand the SQL underneath; watch it happening.
Dave Thomas: h method is leakiest, most dangerous abstraction
Use Jamis Buck's ActiveRecord Logger trick - Rails core was toying with making it the default for Rails console
Chad mentions the problem of Rails n00bs who see the abstractions and don't realize there's anything underneath. They can build stuff very quickly but it invariably falls apart. I worked for a large, respectable company where this happened quite disastrously. A very smart MBA who wasn't a programmer but could code did exactly this, wrote something which used the abstractions well but without thinking about the underlying system, and the whole thing went kaboom.
Quick and Clean requires Zealotry
Constraints Are Liberating
MVC as a constraint
Don't put any code in the views; don't put any DB code in the controllers
Ruthlessly Kill Duplication
Marcel Molina: Thomas Aquinas' definition of beauty
Integrity (Form -> Function (crystal hammer not beautiful))
magazines/readers -> join table: subscription
"Everything you need to do to connect two objects is a CRUD operation."
"That might not pop out unless you were thinking in terms of resources."
"In the context of the controller, order and limit are leaky abstractions."
When adding DSLs or similar abstractions, package them as plugins, even when you have no plans to distribute them at all. Very preferable to /lib due to presence of testing. (Also I think this gets you past explicit requires in the environment file for free.)
implictly merges options hashes
allows you to expressively declare the semantics of SQL conditions without using SQL
imparts significance of a find to that find
nesting with_scope in a model gives you named keyword finds very easily
put SQL fragments in constants and then with_scope(Constant)
Mike Clark wrote that
it kicks ass
conditions gets merged seamlessly
(thanks to ugly stuff hidden deep inside Rails)
You can do the same thing with methods instead of Constants
Views can and will get bad - battling against the framework in Chad's opinion
Biggest failing of Rails (Chad says) is ERB
Use helpers to hide that stuff away
Hide the ugly stuff by pushing it down a level - at the end you find none of it is ugly
Additional benefit - recontextualizing the code during refactoring shows you your code from a new perspective - this makes you see improvements you can make
Alternatives to ERB: Seaside views!
"Talk to Giles Bowkett if you want to know more about this" - wait a minute, that's me!
Blocks make helpers more powerful
Finally, the best way to get good at programming Rails is to master Ruby. Forget about Rails, master Ruby.
Marcel Molina & Stuart Halloway: Presenters
Basecamp had a 500-line helper file
Helpers have no structure or organizing principles
Difficult to apply OO principles to helpers because it basically turns into PHP - just a crapload of functions in a big bag
Helpers are hard to test; creating presenters means you have objects, and it's easy to test an object.
I have a decent example of this, I should post it.
Oooh, this is cool. A method_missing on a presenter which checks if the template responds_to a given method.
Reference to Smalltalk Best Practice Patterns - Method Object pattern similar
Marcel presenting a nice abstract super class for presenters
It automatically links the view and model and has access to methods in each
Dave Thomas: "personal crusade against instance_eval."
BEST FOOD AT A CONFERENCE EVAR.
Seriously. Sushi. Mountains of vegetables. Bacon and eggs at breakfast. I avoid bacon and eggs (although I admit I had some bacon) but that's a huge win. Clobbers the 10.30am sugar crash of most conference breakfasts.
Ezra Zygmuntowicz (& Mike Clark) - Xen & Rails Deployment
I've read the slides for this presentation before. Very good stuff.
Zed Shaw turned over Mongrel dev to a team including Ezra.
Upcoming Mongrel changes will be opt-in. Essentially Mongrel development is stable.
Mutex lock in Rails is for thread safety.
Apache - kind of a resource hog.
Nginx. "Some of the best C code I've ever seen."
Apache 100MB RAM -> Nginx 6MB RAM
Lighttpd similar, but leaks memory under high load.
Nginx -> author very approachable, growing community, most stable part of the whole stack.
Comes with geographic load-balancing.
"You can slow down the robots."
Food coma. Food coma. Food coma. Liveblog activities ceasing. tail log/food.coma for more detail.