Some one liners from what I thought were the most relevant, most novel, and most provocative talks at railsconf 2012.

Progress – David Heinemeier Hansson @dhh

• Progress is good, but not always at first. e.g. OSX scrolling direction.
• What is our attitude towards change: Curious or Suspicious?
• “A conservative is a liberal who got mugged”
• “Cutting edge is great until one gets cut”
• “Loss aversion is the pillar of conservatism”
• Don’t limit learning. Don’t do “for dummies.” Cognitively reframe the approach to knowing you are learning and are going to be good at it soon.
• “Great products are made by people who use them or care about them.”
• “Rails 4 will change things and break things”
• “Stay young, stay curious, stay hippie. Don’t fight change or progress”

Using Backbone.js – Sarah Mei @sarahmei

• Frontend frameworks (ember, backbone, handlebars) promote convention.
• Don’t do a full rewrite. Incrementally rewrite.
bit.ly/JQjXCX

Machine Learning – Andrew Cantino @tectonic, Ryan Stout @ryanstout

• Methods: Decision Tree, Support Vector Machine (SVM). Naïve Bays, Neural Nets
• Curse of Dimensionality: there is an exponential relation between the number of functions one has to the amount of data required.
• Overfitting: don’t memorize, generalize. Don’t test on training data, split and cross.
• Sentiment classification: build training data, extract features, use dictionary to generate word vector, classify, evaluate, improve.
• Resources: Stanford Machine Learning class
• Tools: Weka, libsvm, liblinear, vowelpal, wabbit, recommendify
blog.andrewcantino.com/blog/2012/04/22/machine-learning-project-ideas/

Rails Engines Patterns – Andy Maleh @andymaleh

• What: gem + MVC stack elements extracting common logic
• Goal of pattern: keep engine code agnostic of app customization, prevent bidirectional dependency, prevent app specific logic.
• Solves: need for multiple apps to share basic crud for a given model, common association, common logic
• Costs: overhead in new gem, about 30 minutes, constantly switch between app/engine when developing some features, upgrade gemfile refs every commit.
• Benefits: makes tests faster, code reuse across all apps at all layers, maintainable in independent project code bases with clearly defined boundaries.
• Engines VS services: engines are better for domain dependent MVC reuse in an environment where the consumer is inside the organization, services are much more expensive and better when reusing large MVC components that depend on domain data, could potentially need to scale independently of the db, and are consumed by outside organizations.
• *Talking afterwords: Andy has moved organizations from tightly coupled legacy systems, such as a single Java app, into a decoupled rails architecture by TDDing a new system, piece-by-piece, engine-by-engine, app-by-app, using ActiveModel mapped to the legacy db. The end result was a new system with less bugs, thanks to TDD, that was easier to maintain and faster to develop new features on.
bit.ly/IJgqTL

The Future of Sass – Hampton Catlin @hcatlin

• 3.2 new: placeholder selector, mixin content/blocks for mixins, @media crazy, load paths
• Depreciated: & foo, use @extends
• Scss not Sass
• libsass (SassC), but whatevs, ruby’s got it already

Faster rails apps – Ilya Grigorik @igrigorik – Google

• Measure all things.
• Histogram all things. Averages are misleading.
• Know what to measure.
• Measure perceived latency, nothing else matters.
• Optimize from the user’s perspective.
• Mobile web is x1.5 slower
bit.ly/faster-rails

Sustainable productivity – Xavier Shay @xshay – Square

• It’s easy to start, hard to maintain.
• When code doesn’t look consistent, productivity goes down.
• Reify: make code more concrete or real.
• Class documentation – describe the bigger picture.
• Questions make me less productive.
• Smart people mess up.
• Error rates multiply.
• Be on your guard, even when fixing critical bugs.
• Don’t make the code more complex.
• Anything that can be checked by machine, it should be. Catch the rest with pairing and code review. Tool: cane.
• Tools aren’t perfect. Conform anyway. There is tremendous value in 0 errors from a tool.
• Do not depend on code you cannot change. Shim it. Define the relationship in your terms.
• Group and access aggregates via root. Bi-directional associations are a symptom of ignoring aggregate roots.
• Reading: Domain Driven Design, Clean Code, A Guide to Testing Rails Applications, Growing OO Software, Guided by Tests, destroyallsoftware.com
• Tests Redefined: Integration, Functional, Unit. Unit tests do not touch the db, network or file system. VS Acceptance, Integration, Unit. Does the whole system work, does code work against code we can’t change, do methods do the right thing/are they convenient?
• *Talking afterwords: The hardest part of dealing with legacy systems is figuring out how to split them up into manageable, replaceable chunks. Put shims in between the old and new. Aim for a service/rails engine oriented architecture. Hide the ugly. Identify and utilize a single data source for everything. Use ActiveRelation to get data from anywhere.
youtube.com/watch?v=84ewfGEojsw

Zero Downtime Deploy – Pedro Belo @ped

• No MySQL + isam. Doesn’t work as rails expects.
• InnoDB is O(n) on add/remove/update columns and add/remove indexes.
• Postgres for the win: O(n) on column updates, constant on everything else if careful.
• github.com/freels/table_migrator for data, but requires acts_as_paranoid and is too old, so just use it as a reference.
• At least 2 processes, watch capacity.
• Cycle the webserver gracefully.
pedro.herokuapp.com/past/2012/4/24/zero_downtime_deploys_for_rails_apps_slides

Rails: The next 5 years – Yehuda Katz @wycats

• Conventions are good.
• Conventions are part of a bigger solution to help the developer.
• Conventions hide solved problems when working on another problem.
• Conventions help developers develop similar looking code.
• Good architecture enables future features.
• Features Now + Features Later ÷ (Cost Now + Maintenance)
• Any convention is better than no convention.
• Trivial choices are the enemy.
• Active Model Serializers standardize/bring convention to JSON APIs.
• A note on node: insert Paul Graham quote – the web lets us pick the best tool/language for the job. Is javascript the best server side language? Just b/c it won on the client, doesn’t mean it should win on the server.
• Rails developers are interested in working on startupy apps, not enterprise apps. What enables this?
dl.dropbox.com/u/2285145/The%20Next%20Five%20Years.pdf