RailsConf 2011 notes, verbatim from back in... May 2011 (how time flies)

.gitignore

@@ -0,0 +1,2 @@
+.DS_Store
+*.sw[nop]

Confident Code.md

@@ -0,0 +1,42 @@
+Confident Code
+==============
+
+* Timid code
+  * Prone to digressions
+  * Second-guessing itself
+* Confident code
+  * Intention
+  * No provisos or digressions
+  * Narrative
+    * Gather input
+    * Perform work
+    * Deliver results
+    * Handle failure
+  * True duck typing is a confident style
+  * If in doubt, coerce
+  * to_a isn't in 1.9, use Array()
+
+
+    require 'delegate' # Ruby std lib
+
+    class WithPath < SimpleDelegator
+      def path
+        case 1
+        case 2
+        ...
+      end
+    end
+
+  * Reject unexpected values outright
+    * Assert your contract (no DbC framework needed)
+    # NOTE raise Exception, message, caller # sets context to caller
+  * Guard clause to short-circuit, avoids special cases later
+    * Or... the Special Case pattern
+    * NullObject pattern # Maybe()
+    * Hash#fetch to give back a symbol
+    * jQuery selectors are confident
+  * Instead of returning nil, consider returning a NullObject or other Special Case object
+
+  * Happy path first
+
+  * rescue idiom

Cutting Your Own Gems.md

@@ -0,0 +1,49 @@
+Cutting Your Own Gems
+---------------------
+
+https://twitter.com/#!/benjaminoakes/status/71270520879976448 #TODO
+
+* #TODO http://guides.rubygems.org/
+* Manuals are important
+* RubyGems is centralized, may change
+* .gem file:
+  * docs
+  * code
+  * gemspec
+* A gem is a tarball of tarballs
+  * metadata.gz: your gemspec, transformed to YAML
+  * RubyGems has a whole implmenetation of tar
+  * Needs to work on all platforms
+* Gem:
+  * It's your job to share/modularize code
+  * Super easy to release
+  * Don't call it:
+    * [rR].*
+    * rials
+    * cute names, etc
+  * Don't use capitals
+    * Use underscores
+    * Use dashes for extensions on something else (e.g. hedgeye and THEN hedgeye-client) #TODO
+  * push goes up to the server
+  * irb -rubygems
+  * gem list -r hola # lists remote gems
+
+  * bin for bins # TODO
+    * ruby -Ilib ./bin/hola
+      Hello world!
+    * ruby -Ilib ./bin/hola Baltimore
+      hello Baltimore!
+  * test
+    * http://test.rubygems.org/ #TODO
+
+  * http://twitter.com/rubygems #TODO
+  * doc-rails #TODO
+  * yard #TODO
+* Versioning
+  * Minor: when you add features
+  * Major: when you have backwards incompatible features
+
+  * twiddle-wakka
+    ~> 2.2 (more than or equal to 2.2, less than 3.0)
+
+  * http://semver.org/ #TODO

Getting Started with JavaScript Testing.md

@@ -0,0 +1,74 @@
+Getting Started with JavaScript Testing
+=======================================
+
+* JS as a first class citizen -- it's real code
+
+* integration: AJAX, complicated DOM, etc
+  * Capybara is great for integration testing
+  * Simulates user behavior
+  * Switch seamlessly between drivers
+    * JS targeted:
+      * Selenium
+      * Akephalos (HTMLUnit based, slower)
+      * capybara-envjs (bad support)
+      * capybara-webkit (unproven
+
+      * can use rack-test to do non-JS
+
+      * gem 'capybara-enjs'
+
+        it 'does (with JS)', :js => true do
+          # ...
+        end
+
+      * Can do in Cucumber too
+
+      * Best Practices:
+        * Helper modules (e.g. for things like sign_in_as(name))
+        * Use selectors to get back in your domain language
+        * Assert on things you can see
+          * Not URLs
+          * Not cookies
+          * Not session
+          * Not application state
+          * This is less brittle, doesn't depend on underlying implementation
+        * Use field labels, not field names
+        * Use domain stuff, not implmenetation
+* Unit testing: standaolone logic
+  * Favorite: Jasmine
+  * Stable, full featured, general purpose
+  * Evergreen packages up Jasmine
+  * Evergreen: /evergreen
+  * Allows commandline testing
+  * Evergreen:
+    * Nice requires
+    * Templates (HTML snippets)
+    * toHaveElement (in spec_helper)
+    * Does CoffeeScript based on filename
+
+  * Suggestions
+    * Testable JS code
+    * Create abstractions
+    * Keep consistent feel to JS (functional or OO, pick one)
+    * Separate files (esp. with asset pipeline), not just application.js TODO
+    * *Mostly* test event bindings, maybe integration, still experiment
+    * Custom matchers are good
+    * Isolate AJAX to avoid brittleness
+    * Maybe mock AJAX
+    * Simplify your DOM
+
+* Qs
+  * JSTestDriver?
+  * Why have to click?
+
+
+Testing
+=======
+
+* OBJECTS
+* individual components key
+* Jasmine: Scenario, Given, When, Then
+* Act like a user
+* Unit tests: systemic (internal quality)
+* Can split into controllers, etc
+

Home.md

@@ -1 +1,24 @@
-Welcome to the railsconf2011 wiki!
+RailsConf 2011 Notes
+--------------------
+
+In the spirit of my open [RubyConf 2011 Notes][rubyconf2011], these are the notes I already had for RailsConf 2011 for use by others.
+
+  [rubyconf2011]: https://github.com/benjaminoakes/rubyconf2011/wiki
+
+### Talks
+
+These are just in alphabetical order:
+
+* [[Confident Code]]
+* [[Cutting Your Own Gems]]
+* [[Getting Started with JavaScript Testing]]
+* [[Home]]
+* [[Mining Rails]]
+* [[README]]
+* [[Rails 3 Refactoring]]
+* [[Rails on the Tracks]]
+* [[Securing Your Rails App]]
+* [[Splittin Yo App]]
+* [[Upgrading from Rails 2 to 3]]
+* [[When and How to Expose Services]]
+* [[Wooga]]

Mining Rails.md

@@ -0,0 +1,27 @@
+Mining Rails
+============
+
+* Not so much process, more about the product (code)
+
+Metrics
+-------
+
+* LOC not a good metric (normalize against the language, at least)
+* Cyclomatic Complexity (decision points), a little dated (only really whiles and ifs), but still indicative
+* Flog: weighting for complexity
+* But: we have history!
+* Universal truths?  Maybe not...
+* Queries against git logs
+* Social science (article about parole hearings)
+
+* Commits are patterned -- lots around 17:00
+* Beware noise
+* Can detect refacoring from method lifelines
+* Can learn more about you do, things you can act on
+
+http://github.com/michaelfeathers/repodepot-ruby
+
+* complexity from flog
+
+Q: Have you done any analysis to discover root causes for problems?
+

Rails 3 Refactoring.md

@@ -0,0 +1,70 @@
+Rails 3 Refactoring
+===================
+
+Robert C. Martin (Agile Software Devlopment): SOLID
+
+S: Single Resp Prin.
+--------------------
+
+* Rails 0.x: ActionView::Base had too many responsibilities (details, templates, context, etc)
+* Rails 1.0: Reduce responsibilities, separate classes out, (Template handlers (builder, rjs, haml, erb): single responsibility)
+* Rails 2.2: view paths extracted (multiple places for view templates, allows Rails Engines)
+* Rails 3.0: View paths split into 'view paths' and 'resolvers'
+  * Resolvers make it so views don't have to come from the filesystem (could be web service, database)
+  * Added lookup context too, so less back and forth between view and controller
+* Rails 3.1: AV::Renderer in from of ActionView -- only single responsibility per class
+  * Allows you to use something other than ActionView (e.g. Merb's views)
+  * Allows you to use the renderer in Sinatra
+
+  class BasicController <actionControlle::Base
+    include ActionView::Context
+    ...
+
+* Single reponsibilities: easier to separate out pieces and use them, and also replace them
+* Easier to understand each piece
+* Not as easy to take in the whole piece (top-down comprehension)
+
+
+O: Open/closed Prin.
+--------------------
+
+* Extend class behavior without modifying the class
+* Class open for etension, closed for modification
+  * Latter isn't enforced by Ruby
+
+* Don't break other people that depend on a library (e.g. modifying ActiveRecord::Base)
+  * Lots of poeple do --- makes it hard to run multiple rails apps on a single process
+
+D: Dependency Inversion Prin.
+-----------------------------
+
+"Depend on abstractions, not on concretions"
+
+* Duck typing, basically.  Depend on abstractions (e.g. what methods are available), rather than a single concrete class.
+
+    match '/foo', to: 'posts#index'
+    match '/foo', to: PostsController.action(:index) # Missed this last part, but it's a rack app!
+
+* Controllers have a middleware stack
+* Remove hard-coded dependencies (e.g. pass as an optional parameter)
+* Defining hooks (done in Railties)
+
+L: Liskov Subs Prin.
+--------------------
+
+"Derived classes must be substitutable for their base classes"
+
+* Need to respond to the same interface
+* What about a new version of Rails?
+* Static language: check to interface
+
+    include ActiveModel::Lint::Tests # kind of the same idea
+
+I: Interface Seg. Prin
+----------------------
+
+* Simplest protocol possible
+* How to ensure?
+  * When you test, odn't use the conrete class -- use a Mock that only implements what you're expecting!  (It's testing the 'concrete' interface, in a way)
+
+Modularity driven by principles

Rails on the Tracks.md

@@ -0,0 +1,64 @@
+On the Tracks
+=============
+
+Experience
+----------
+
+* 40 apps in the last 12 months
+* Wrote ActionMailer
+* Antipatterns
+
+Philosophy
+----------
+
+* Working vs Sexy
+  * Not just a green light
+  * Sexy can be a time waster
+  * If it's not necessary, don't worry about it
+* Maintainable
+  * Patterns are good, but don't always try to be a case study
+  * Trivial to understand == good code
+  * Budget matters: beautiful is ugly if it's too expensive/no one buys it
+* Trade-offs are life
+  * Don't go overboard on refactoring if rarely used
+* Not selling code, buying a solution (app)
+
+* DOCUMENT how to deploy (e.g. in README) TODO
+  * Heroku, Chef, Puppet, etc
+  * Bundler
+    * Be explicit in versioning
+    * Don't depend on git repositories you don't control
+      * Fork if you have to, making a branch for your app
+  * Make db/seeds.rb for what you nee
+    * Makes it easier to add a new developer (including you sometime down the road)
+  * No passwords in the app
+    * API keys included
+    * Hard to add a consultant, or if a dev leaves
+    * TODO 'app' gem
+    * TODO list what you need in terms of servers, access, etc.
+* Big Session == Slow Site
+  * Pushing to the browser isn't a bad idea; scalability!
+  * Turn off sessions for parts of your app where one isn't necessary
+* Opinions
+  * Work with the opinions, not against them
+  * Ruby has opinions too.  Don't be too verbose and work with Ruby.
+* Being smart can be stupid
+  * Filters are for state modification
+    * They inherit!  You'll run into problems
+    * Alternative to before in Rspec: make a method that's explicit
+  * Don't overdo metaprogramming
+  * Takeaway:  Writing Ruby and it's pissing you off?  You're doing it wrong!
+  * You don't need database agnostic code
+    * Rare
+  * SQL has its place (45 minutes vs 15 seconds)
+  * "Control flow is code smell"
+    * Extract methods if you have way to many cases/ifs outside the object
+
+* TODO get an inspection
+* Code review is important
+
+* Shared security
+  * Keep your YAML in the shared dir
+  * Or env vars for Heroku
+
+  * slides: http://speakerrate.com/talks/7575

Securing Your Rails App.md

@@ -0,0 +1,23 @@
+Securing Your Rails App
+=======================
+
+* Rails is a fairly safe framework
+* We normally provide features, not prohibiting something
+* #TODO http://guides.rubyonrails.org/security.html
+* #TODO http://www.owasp.org/index.php/File:Owasp-rails-security.pdf
+* Trust no one
+  * Don't trust the browser
+  * DB: user entered data
+* attr_accessible (whitelist), attr_protected (blacklist)
+* a lesson in timing attacks (codahale.com) #TODO
+* XSS so'ns
+  * Don't use raw, unless you have a good reason.
+  * Don't blacklist or try to correct suspicious code
+  * Rails: sanitize() helper, lets you give allowed tags
+* Look more at CanCan #TODO
+* Look more at FireSheep #TODO
+* SSL for more than login forms
+  * Secure cookies
+  * Strict-Transport-Security header (basically redirects to SSL), avoids a redirect that contains the cookie
+* Big takeaway: upgrading to Rails 3 includes lots of security changes
+* Security audit #TODO

Splittin Yo App.md

@@ -0,0 +1,13 @@
+Splittin' Yo' App
+=================
+
+* MVC vs MC (API)
+* Same Model logic
+  * Thin layer around your controller rather than two copies of the app
+* Flexible API
+  * http://github.com/seejohnrun/flexible_api
+  * Autogenerates API docs 
+  * Built on top of Sinatra
+  * TODO check out shotgun
+  * Constructor ... like ActiveResource?
+  * Does rate limiting