Jake Scrugges – Metrics Based Refactoring: What To Do With Your Code Metrics

• Metric-Fu is a ruby metric bundle
• rake metrics:all
  => generates a master report of a bunch of metrics
• There are a lot of metrics, where do you start?
• Everyone wants to refactor, but where do you start?
• Flay
  • Analyzes code duplication
  • Finds violations of DRY
  • Solutions: Extract Method, Modules, etc.
  • Single Responsibility Principle
• Churn
  • Looks through your commits to see what stuff changes the most
  • Files that change the most are “God Objects” – stuff that does everything
  • Any time anything changes, the God Object has to change
  • Bad smell, should be smaller objects with greater focus
  • Tells you where your most volatile code is
• Rcov
  • Main reason metric-fu blows up
  • Problem is, metric-fu is mostly static analysis, but rcov is running the code
  • Rcov runs the test suite, which is sometimes hard to get working
  • Rcov makes sure your coverage is good where it needs to be (most complicated and volatile code)
  • Writing tests for the sake of coverage is harmful
  • Write tests when you are in the code and you understand it (not a week later, “let’s write some tests!”)
• Flog and Saikuro
  • Both are complexity management
  • Saikuro (pronounced cyclo as in cyclomatic complexity) measures cyclomatic complexity
  • Saikuro = number of paths through the code, and cyclomatic complexity is exponential in growth
  • Flow looks at branching, but uses ABC
  • Assignments
  • Branches
  • Calls
  • Flog generates a score based on ABC
  • < 20 is good, 20-40 is a grey area, 40-60 is a warning, 60+ is FIX IT!
  • How do you fix it?
  • Extract method
  • Missing object (need a new class to handle this behavior)
  • If that doesn’t work, re-architect
  • Seriously, you don’t need complicated methods in any app
  • Director method: calls a couple of sub methods, doesn’t do much actual work
  • Take care not to over-factor. If you are a guest in the code, just clean it
    as necessary. You don’t need to fully re-organize.
• Reek, Roodi, and RailsBestPractices
  • Reek: if it could possibly be a problem, I’ll tell you
  • Roodi: only if I’m really sure, I’ll tell you
  • RailsBestPractices: just rails stuff
  • All parse the code and look for design problems
  • Very ambitious! Code trying to understand what you’re trying to do
  • Awesome because you can look up the definition of the problem and see how to fix it.
  • Trouble because it’s a machine trying to identify human problems, which is difficult
• Continuous Integration
  • Metric-fu on your code
  • Most CI’s allow you to have artifacts for a build
  • J.S. runs his nightly at midnight
• Pay attention to trends over time
  • Is your refactoring making things better?
  • Did the last feature skyrocket flay scores?
  • How is the influx of new developers affecting the code quality
  • Did the highly paid consultants produce good work?
• Take metrics as advice (not law)
  • It is a tool, use it intelligently (like a GPS system)
  • Don’t let a manager get in charge of this
  • Up to you and your team to establish conventions and stick to them
• Coming soon
  • Fail the build on bad metrics
  • Resisted for a while because there may be false negatives
  • Failing a build is a serious incident, needs to mean something
  • Metrics are not as definitive as tests
• Coming later (and/or soonish)
  • Meta metrics
  • Imagine a report that flagged a method as having high churn, poor coverage, and high complexity
  • This method is trouble waiting to happen
  • No so easy to write this feature
  • J.S. needs help!
  • Need to re-architect the system to understand classes and methods, not just lines of code
• Questions
  • Can you use other source control?
  • I think so, check out the churn gem
  • How is the performance?
  • Not great, but you only have to run it once a day
  • If you don’t have test coverage, now what?
  • start w/ rehacktoring (refactoring w/o tests)
  • do that until you understand it enough to write tests
  • write tests!
  • What about front-end heavy stuff? Javascript?
  • No idea! These are all ruby tools. Maybe there are JS tools out there?
  • You should test your javascript. Sapphire is the “new hot thing”.

John McCaffrey – Analyzing and Improving the Performance of your Rails Application

• http://railsperformance.blogspot.com
• O(n) queries is bad
• Code he refactored went from 2811 to 17 queries per action
• Leverage: small amounts of work for large amounts of value
• Delay directly correlates w/ loss of revenue
  • Bing: 1s = 2.8% decrease, 2s = 4.3%
  • Google: users that had a delay for a short period of time, actually searched less even after the delay was removed.
  • Yahoo: added a 400ms delay and users bailed before the pages even loaded
  • Shopzilla: reduced delay from 6s to 1.2s.
  • Conversion rate rate up 7-12%
  • Saved infrastructure costs by 50%
  • Release cost decreased
• Fred Wilson (VC): Speed is #1 of the 10 golden principles of successful web apps
• So where to begin?
• Anti-patterns:
  • “Scalability can be sprinkled on later”
  • Guessing, not testing
  • Ad-hoc, unstructured
• “Premature optimization is the root of all evil” – Donald Knuth
• “If you can not measure it, you can not improve it” – Lord Kelvin
• Measure
• Repeatable tests
• Isolate your changes
• (Scientific method!)
• Visibility is important for working on a team
• Response time = latency
• Requests per second = throughput
• Load, utilization, scalability, throughput, concurrency, capacity
• Performance != Scalability
  • Performance = response time
  • Scalability = ability to grow to more requests
  • Adding more workers will not improve latency
• Twitter: dynamic html = 250ms, but 3369ms is static assets
  • Don’t waste your time on the 250ms, go for the big slow chunks
• Walmart: 3 redirects, 388ms dynamic, 4580ms static content
• Use YSlow
  • Do less work
  • Distribute content
  • Cache
  • Compress
  • Fight queued work
• Google page speed
  • similar to yslow
  • includes paint events
  • separates out ads and trackers from your site
  • “how fast it feels”
  • If the web is faster, they make more money
• http://www.showslow.com/ tracks your site (or competitors, will check every 24h)
• http://webpagetest.com/ runs page speed and yslow for you, and show progressive rendering
• http://gtmetrix.org
• http://zoompf.com
• http://loadimpact.com
• http://gomez.com
• See Greg Pollack’s Scaling Rails series
• Majority of the Alexa top 1,000 sites don’t do even the easiest things
  • 42% don’t gzip
  • 44% >2 css files
  • 56% serve css from a cookied domain
  • 62% don’t minify
• Gzip is the simplest and smartest thing you can do
• Minify js
  • jsmin, yuicompressor, sprockets
  • Asset packager
  • javascript_include_tag :cache => “cache/all”
• Sprited images
• Spriteme.org
• JqueryUI gives you sprited images
• Image optimization
  • Smush.it
• Expires and browser caching
• Set a far-future expire to tell the browser it can cache it
• Combined with a query string lets you version a file
• Rails Caching: make the static parts of your dynamic content cached
• railslab.newrelic.com
• request-log-analyzer
• Rack::Bug
• NewRelic
• Scout
• Get on the heroku mailing list / blog to learn about scaling issues
• Apache bench
• httperf
• jmeter
• Database issues
  • Bad queries
  • Not utilizing explain
  • Inadequate indexes
  • N+1 queries
  • Selecting more data than needed
  • Inconsistent queries for the same data
  • http://github.com/dsboulder/query_reviewer/
• http://github.com/eladmeidar/rails_indexes
  • rake tasks to find missing indexes
  • columns that need to be sorted
  • lookup fields
  • columns used in a group-by
• http://github.com/samdanavia/ambitions_query_indexer haven’t tried it yet, check it out
• http://github.com/sdsykes/slim_scrooge Instruments your code and looks for bad “select *”
• Aman Gupta
• Joe Damato
• http://timetobleed.com/
• http://memprof.com/
• yajl-ruby for C++ extension json parsing
• Ruby 1.9 for massive performance

Kevin Gisi – It’s time to repay your debt

• We’re leveraging an awesome framework and language, and it’s time to give back
• Releasing gems is easy
• (Showing some code to refactor out into a gem)
• Ruby community has an incredible (and overwhelming) amount of choice
• Choice is good and important
• There exist incomplete and unstable solutions
• You should release a “product”, not an incomplete solution
  • Aesthetics
  • Utility
• Agile: Do the bare minimum to get something delivered
  • (Nick: isn’t it to embrace change?)
• Delivered: coded, deployed, supported, tested, extensible, usable by the client
• Treat open source libraries and client deliverables
• The Lazy programmer’s manifesto
  • I want to write code once
  • I want to be able to read code w/o docs
  • I want to be able to rely on libraries
  • I wants to use adaptable solutions for numerous problems
  • I want to always be working on something new
• Idea filtering
  • To share
  • business value
  • practical use
  • To learn
  • no requirements
  • don’t post it publicly (community does not value your stupid web framework)
• Testing
  • We all say we do it (it’s time to start)
  • RSpec and Cucumber are easy to set up
  • Design verification tool
• (really turning into a rant at this point)
• Extensible
  • Write clean code (don’t post spikes)
  • Peer review
  • Follow the Unix philosophy: do one thing really well
  • Leverage other gems
• Documentation
  • Who’s looking at your code?
  • RDoc, YARD, etc
  • Getting Started
  • Blog post!
• Supported
  • If you can’t maintain your app, don’t post it
• Be Honest
  • Hand over the reigns if you can’t support it
  • Be a net positive
  • Don’t announce things that aren’t done
• If you have to
  • Put it in a limited venue
  • Add a disclaimer
• The internet doesn’t filter bad ideas very well
  • It does make things hard to do if they don’t work well
  • Having enough eyes
• “Ruby treats you like a grown up programmer” – Matz
• What happens when grown-ups have too much fun?
• How to be a good parent
  • Avoid sensory overload
  • Sometimes spoon feed
  • Remember you’re used to the status quo
  • Be a mentor http://railsmentors.org
  • Provide solutions to problems, not blocks of code
• (I wish this was a “how to do a good job” and not “you suck, stop sucking”. I think he wants to be the king of the rubygems app store)

Lightning Talks

Micah Martin – Limelight

• Tool to build GUIs in ruby
• Built a gui calculator in 5 minutes

Sean Scofield – The Awesome Power of Rails Engines

• Engines make it easy for frameworks to be built on top of rails
• Engine is a complete application that can provide the stuff rails apps provide
• app directory is auto loaded
• You can supply models, views, controllers in your engine
• You can override locale by dropping it in app
• Engines extending engines, for example Spree
• Bundler ties it all together

Mike Buselli – Brush::Pipeline

• Running external OS commands
• sys
  • lower level, more convenient for specific takss
  • chaining commands
• pipeline
  • better at chaining commands
  • pipeline ['head', 'README'], ['tail', '-n2']
  • Each part of the pipeline can run in different directories
  • stderr and stdout redirection
  • argv[0] renaming
  • restrict access to open files
  • Works great on POSIX including cygwin

Chris Hallendy and Nick Lewis – Realtime Apps

• Demo of node.js <-> Redis <-> Rails

Joe Fiorini (sp?) – Web Katas

• Problem: web developers don’t know http
• Rails is big and awesome, but it’s hard to troubleshoot
• It allows us to ignore how http works.
• Code Katas http://bit.ly/codekatas
• No-framework webapp development (Rack) to learn how http cookies work
• More Katas
  • Auth token
  • See Other response status
  • Move permanently
  • Session state handling
  • http://bit.ly/webkatas

Jim Remsik – Improv: Comedy to Coding

• Programming is a people problem
• You write code for other people
• We use ruby because it is expressive and easy for others to read and maintain
• Improv after-hours at hashrock
• Yes-and, drop your preconcieved notions at the door
• Support your team

Malcolm Arnold – Ruby Nuby

• Brand new social movement dedicated to teaching ruby on rails to disadvantaged youths
• Maximize social good by spreading ruby

Praveen Alavilli – Monetizing your apps

• “chase your dream, money will follow”
• Still a mystery to a lot of people how the money follows
• Indirect
  • advertising
  • offers
  • referalls
• Direct
  • e/m-commerce
  • freemium
  • causium (donate money to a cause)
  • pay as you use
  • free to use pay for service
  • premium content
  • digital goods
  • virtual currency
  • subscriptions
• Challenge: apply these models to your use cases
• Gateway (i.e. Payflow, Authorize.net)
• Checkout (Google, PayPal, Amazon)
• Platform (PayPal, Amazon)
• Also services on top (Chargify, Spreedly, Freshbooks)
• Choose one that works the best
• Your users need to be able to pay somehow, should not be hard to pay
• PCI compliance for charging directly
• secure and privacy enabling
• Adaptive Payments API

Ryan Singer – Weaving Design and Development

• UI Design and Programming, working together
• (telling a story about working with a startup and doing design for them)
• Designer says “let’s change this button” while pairing with dev, dev makes the change instantly
• XP is focused on delivery
• In XP, feedback loops are not as important
• Feedback can be difficult if you are purely focused on delivery
• Shared code base, code runs on designers computers
• Avoid the designer w/ folders full of PSDs and static content
  • Becomes a spec, then the dev has to implement it
• Static files are like spikes, for exploration and experimentation
• Actual changes need to keep up with the codebase
• At 37Signals, no sync problem, because the designers are working in the code base
• HAML and Mustache are out, because designers can’t deal with them
• Templates with logic
• Avoid helpers writing HTML and presenters writing html
• Start together, don’t bring the designers in late, or the developers in late
• Architecture before design leaves UX to too late in the process
• Designers starting everything before programmers start, it may be impossible or impractical to code
• P&D decide on domain language and basic model
• P stub models, controllers, routes, and templates
• D few days lead on designing and building templates
• Simultaneous
  • P design and build models, controllers, routes, helpers, dynamic templates
  • D design and build templates and helpers
  • Repeat this process continuously
• Share the codebase
• All views are in templates w/ logic (ERB or similar, not HAML)
• Start together for domain language and models for communication
• constantly committing to the same codebase
• Train designers in git and ruby and other things
• Designers are motivated to learn so they can make changes directly: it gives them more power

Nick Gauthier – Grease your Suite

Les Hill and Jim Remsik – Sustainably Awesome

• Comfortable and productive environment is crucial
• sustainable pace is important. 40h weeks.
• cargo culting
• Pet friendly
• The point is not to do what we do, but to recognize our goals. Don’t cargo cult these tips!
• Casual
• No Micromanagement
• Don’t penny pinch
• Keep a budget and spend it wisely
• $400 per week grocery budget
• No death marches
• No meetings (except daily standup and project standup and monthly company status meeting)
• No hierarchy
• No future-proofing (software and organizational practices)
• What do you do when a developer rm -rfs?
  • No sudo for devs?
  • 3 manager approval before running a script?
  • Develop a backup solution and a common machine image?
• “Process is an embedded reaction to prior stupidity” – Clay Shirky
• A project came along that needed work done ASAP
• Crafted an MVP and built it without changing their process
• The MVP did not overlap with their mockups and specs
• Started with story cards and team boards
• Moved to pivotal tracker
• Tim Pope had a suggestion about how to work stories in pivotal that worked really well
• Always open to try new things and experiment with new processes
• Enjoy your work
• Don’t hire people you don’t like, or without passion
• Hire smart people that get things done
• Must be a great cultural fit
• Hiring
  • phone screening
  • week long “test drive”
  • gems you use are important
  • editors you use are important
  • test driven (and test-first) style
  • hang out after hours to check for a cultural fit
• “If I’m not saying ‘hell yeah!’ about something, then I say no” – Derek Sivers
• Firing: due to lack of communication or mistake, probably on both sides
• Fire fast, but with compassion
• Approach building a team the same way you build software

Yehuda Katz – Rails 3

• Rails core family is getting bigger
• Rails 2 was very intertwined
• Broke things up cleanly
• Instead of Railties being a big glue layer w/ initialization stack, it became a small part or Rails 3 and specifies the framework for applications and engines
• Engines are special plugins now that inherit from Railties
• Applications inherit from Engines
• Railtie lets you add features to rails
• Railties provide a series of Hooks
• Inheriting from Railtie doesn’t do anything, but it has lots of functionality
• Railtie lets you configure the application, such as pull in generators
• Rake Tasks are another Railtie Hook
  • Extra stuff you want to have happen in rake, and not on boot
    rake_tasks do
    load “my_stuff/my_tasks.rake”
    end
• before_configuration hook = right inside Rails::Application, before user stuff happens, but you know about rails root and stuff.
• config.to_prepare : in dev, run every time, in production, run once (i.e. compass template compilation)
• Framework loading: ActiveSupport.on_load = i.e. when action mailer loads, monkey patch in some code. Then you don’t have to try to detect ActionMailer, you just say, when it loads do stuff.
• Don’t do if(defined) because it depends on order
• Decouple via Instrumentation
• ActiveSupport::Notifications.instrument(“receive.action_mailer”) do |payload|; #callback; end
• Worth Noting: we worked really hard making things mostly backwards compatible
• The old way may appear to work, even if it doesn’t
• AbstractController is decoupled from ActionController
• ActionDispatch = Rack++
• ActiveModel lets other persistence engines connect to ActionController. Only need to support ~5 methods
• Tight Integration without Coupling
• Integration first, decouple later
• Migrating:
  1. Install Rails 2.3.9.
  2. bundler
  3. rails_xss
  4. Deprecations – get the count to 0
  5. Upgrade
  6. Deprecations again!
• Helpers should call partials, not generate html
• Rails 3.1: We’re not burned out!
  • Engines
  • @drogus did all the engine work
  • Engine Migrations
  • Static assets (w/o copying). Leave it in the engine, and Rack::Static will find it
  • Self-contained engine
  • Built-in http caching, to get away from filesystem caching
  • fresh_when? calculates an etag from the post and returns 304 if not fresh
  • caching at the browser layer
  • etag can be based on an AR object
  • If you have Varnish, you can turn off Rack::Cache and fresh_when will be built in
  • This also means that when you turn on Akamai, you already have all the code that makes it work well
  • Enables Edge-Cached SCSS
  • Rack::Cache is like Memcache, but uses HTTP semantics
  • Assets
  • ERB == SCSS (I have content that needs to be processed before it hits the browser)
  • Solution: build in compilation pipeline
  • app.css.scss (like app.html.erb)
  • posts/index.css.scss
  • Treats CSS the same as HTML for templating
  • SCSS template handler => http response => rack::cache
  • It just works w/ varnish and the like
  • Spriting
  • Compass and lemonade are merging w/ a new sprite api
  • Put all your images in images/sprites/ 1, 2, 3, 4, .png
  • Lets you include all the images as a sprite
  • Gives you a bunch of css classes to use the sprites
  • SCSS can take CSS, and then add stuff in
  • You don’t need imagemagick, there is a pure ruby PNG spriting library
  • AutoFlush – it’s cool, read his blog, running out of time
  • flush content to the browser as it is rendering
  • Tradeoffs you have to deal with, like exceptions
  • Browser can be working on your CSS while you are doing SQL queries
  • Keep content_for at the top of the template
  • Exceptron
  • Stolen from merb
  • ExceptionsController to render and take actions when exceptions happen
  • Performance
  • We did pretty well in 3.0, definitely some trouble spots
  • More mechanisms for performance
  • Big Arel rewrite for 3.1
  • Possible to get to 2x faster over 3.0

Day One (Nuby Hoedown)

David A. Black – The Well-Grounded Nuby

• Seven key points, with code examples
• Every expression evaluates to an object
• if statements and class definitions return objects
• operations are messages (==, +, etc)
• methods are messages (to_s)
• a[2] is equivalent to a.
• case is really if, elsif, etc, which is really x1.===(x0), x2.===(x0), etc.
• String === String is false! Classes define === as meaning “is the argument an instance of me”
• Objects have lookup paths they use to find the method among their associated modules and classes
• Super means keep searching for the next method up. Not necessarily the super class, could just be
  in a module that was included the most recently.
• instance.extend(module) will include the module into that instance, not the entire class
• every object has a singleton class that represents the instance. So the above in actually including
  the module into the instance’s singleton class.
• there is always a “self”. defaults to main:Object

Kevin W. Gisi – Dynamic Ruby for Nubies

• DSLs help bridge the gap between an idea and code, as a layer of abstraction
• I got lost :-(

Lunch

• Om nom nom

Nick Gauthier – The Six Ws of Testing

• I think it went well. Very low on technical content but many Nubies came to talk to me afterward and said they enjoyed it. I’m sure I bored the technical folks to tears. But hey, it’s the Nuby Hoedown!

Matt Yoho – Gem Authoring and Deployment

• “require” loads code once, it is smart
• “load” loads the code without doing any checks
• You should not “require ‘rubygems’” it should already be on the load path
• Don’t use jeweler, use a real gemspec

  http://yehudakatz.com/2010/04/02/using-gemspecs-as-intended/

  Unsure about this, maybe the gemspec has enough automation you don’t have to do this any more?

• Aruba lets you write cuke specs within cuke specs. Helps with command line applications

Hack Session of DOOM

• Two features and one bug on hydra!

Scott Chacon – Getting Git

• http://gitref.org
• http://progit.org
• schacon@gmail.com (put conf name in subj when emailing questions)
• tree -a for nice tree list of a directory
• check out his slides for example of cool showoff styling and layout

  http://github.com/schacon/showoff-wrangling-git

• Email him to ask what he uses for his diagrams and highlights (backgrounds)
• Would be really cool to allow a [dot] keyword in showoff to interpret the following graphviz code as a diagram
• git log branchA ^branchB
  show commits reachable by A but not by B
  for example, I’m working on branch my-feature
  git log my-feature ^master
  is the stuff I’ve done that’s not in master yet
• git branch –merged
  show me all branches that have been merged (safe to delete)
• git branch –no-merged
  show me all branches that have not been merged

Day Two

Bryan Liles – Coding in Anger (or is that Desperation?)

• Bryan Liles sings country
• “run through the problem, take no prisoners” … “and undoubtedly do some bad things”
• “we build straw houses”
• “if you do it the wrong way just to get it done, you’ll get hit in the future”
• Cargo Cult: “we’re all guilty of it” and “it’s bad”
  • Copy-pasting other people’s code without understanding it
  • “Copying code is not bad”
  • “It might do the right thing, but it might not be doing the right thing”
  • Read the code first
  • Respect the copyright
  • Understand what you copy
  • Don’t “copy and paste”
  • UNDERSTAND WHAT YOU COPY
• “It takes a big man to understand humility”
• Break a task down and constantly refine task estimates
• A desperate coder is a bad coder

bonus lightning talk: You are your own sales person

• you are the product
• you are the salesperson

Justin Love – You already use Closure

• Block based programming
• containment: f = File.read vs File.open do |f| …; end
• You can call a proc with []
  proc.call(a,b) is equivalent to proc[a,b]
• duwanis in IRC: “rack of lambda”

Nick Gauthier – Grease your Suite

Matthew Bass – A/B Testing for Developers

• Choose a metric
• Do some experiments
• Compare the metrics
• Vanity for rails A/B testing

Yossef Mendelssohn – The Perpetual Novice

• Dryfus skill acquisition model
• Novice level: follow the rules, do what you’re told
• Adv. Beginner: limited ability to perceive different aspects of the situation
• Competence: multitasking, handle more information, see how actions are related to goals
• Proficiency: higher level view of the task, prioritize, adapt
• Expert: no longer relying on rules and guidelines, deep & tacit understanding, intuition
• be mindful of your scenario: other people (or yourself) need to deal with the work you’ve done
• unconscious incompetence: you don’t know what you’re doing and you don’t know that you don’t know it
• conscious incompetence: you don’t know what you’re doing, but you know that you don’t know what you’re doing
• conscious competence: you can do it and you understand it, but you have to think about it
• unconscious competence: it is second nature to you. You know what you’re doing and you don’t have to try
• Dunning-krueger effect:
  • when you don’t know what you don’t know, you don’t appreciate the skill itself, and are therefore very confident of yourself.
  • If you understand the skills, the more competent people think they are not very competent
• You need to practice, outside your main work
• Focus on getting better, the entire time
• low level people working together can be dangerous
• a skilled person working with a lower level person need to work at the lower person’s level
• Shuhari
  • Shu: learning fundamental techique, rules and guidelines (acceptance)
  • Ha: detach, digress, and break from tradition. think for yourself
  • Ri: transcendence: moved past rules and guidelines (no form)
• Shoshyu: beginner’s mind. In the beginner’s mind there are many possibilities. In an expert’s mind, there are few.
  • Experts have a tendency to stop asking questions
  • Beginners always ask questions
• Something doesn’t suck just because it’s old

Starcraft interlude

• Nick Gauthier vs Bryan Liles and Saxon

Ben Scofield – Keynote

• Practice is important for mastery
• Practice is not fun
• mastery is know how to do things, not just knowing what was done
• mastery is not required
• as a company, deciding what not to do is as important (or more) as deciding what to do
• Pick out what is most important to succeed, and outsource the rest
• errbit : open source alternative to hoptoad
• as a company, focus on the most important stuff
• live intentionally: think about what you’re spending your time on.
• Embrace adequacy (and mediocrity)

Day Three

Family friendly ruby conf in disney world. $189/night @ contemporary. Free conference.

http://magic-ruby.com

Michael Jackson – Parsing Expressions in Ruby

• Different school of thought alternative to regular expressions
• Regexes are great but complicated ones get really gross, even after 10 or 12 characters
• parsing expressions are:
  • declarative
  • recursive
  • readable
  • easy to maintain
  • not ambiguous
  • slow :-) (in ruby)
• Citrus gem

John Willis – Configuration Management in the Cloud with Chef

• infrastructure as code
• need to be able to share with teammates
• can’t have “the deploy guy”
• Chef is a library for configuration management
• Chef client runs on the system (to accept commands and configuration)
• Chef server is a RESTful API
• Each system you configure is a Node
• Attributes are searchable
• Knife is the tool you use to interact with the API
• Nodes have Roles, which describe what a Node should be
• Nodes have a Run List
  • What Roles or Recipes to apply in Order
• A Resource is a Package or a Service
• E.G. Package “sudo” “1.6.8p12″ and it figures out what package manager to use
• Services support actions (e.g. apache supports “restart” and “status”)
• Resources take action through providers
• Data bags store arbitrary data
  • E.G. put a user w/ their ssh key in a data bag, so you can add them as a user on the server
• Cookbooks are shareable
• “Open source for infrastructure”
• Open training
• Cloud service independence (swap from slicehost to rackspace just by adding credentials)
• http://www.opscode.com
  • 5 chef servers for free
• @opscode @botchagalupe
• Chef beats puppet on cloud support (more vendors)

Backchannel notes

• Whiskydisk for deploy

Alex Sharp – Refactoring in Practice

• Shantytown application: you want to bulldoze it, but people live there
• testing in crucial for refactoring
• avoid the EPIC refactor
• changing the implementation without changing its behavior
• deprecate action
  • for example, hoptoad a deprecation warning on old calls to actions
  • helpful when there are ajax calls you are not sure about
• take out small chunks and get them under test
• lack of framework knowledge – often using existing solutions is an easy refactor
• Domain driven development & domain modeling
• Document the smells
• delete code that you aren’t using

Brian Hogan – There’s a Wheel for that Already

• “I don’t want to use that because I don’t like how it looks”
• How often is “better” really just an opinion
• Forwardable – delegate a method to another class
• Rails.root.join(‘config’, ‘x.yml’)
• dir, base = path.split
• open-uri wraps net/http, net/https, net/ftp
• Tempfile (like tmpdir, but just for one file)
• x = Tempfile.new(‘hydra.yml’)
• OpenStruct.new(Yaml.load(‘config.yml’))
• Observer
  @@@ ruby
  def initialize
  add_observer MyObserver.new
  end
  … later
  call: “changed” !
• bash alias for serving static files via webrick
  I wasn’t able to write it down quick enough.
• PStore for storing data
• CSV is great if it doesn’t need to be faster
• Home Run for datetime speedup via C extension
• Oh no, I had to catch my flight and I missed the rest of this awesome talk!

Glenn Vanderburg – Keynote

• Wasn’t there. See notes from Lone Star Ruby Conf. It was probably the same talk

Day one

Adam Keys – Rails’ Next Top Model: Using ActiveModel and ActiveRelation

• Rails 3 – ActiveSupport::Concern
• Accessors + Concern cleans up code
• New encryption classes for secure keys and encrypted data transfer
• ActiveModel::Validator for non AR validations
• validates_with MyValidator
• ActiveModel::Serialization for hydra?
• serialization: require ‘attributes’ and ‘attributes=’
• serializable_hash => to_json, to_xml, from_json, from_xml
• ActiveRelation (AREL)

Jesse Crouch – Building fast, lightweight data-driven apps using the Infochimps API

Infochimps API to create linkedin’ 2nd degree network with twitter data. Check it out at http://trst.me

Aman Gupta – Debugging Ruby: Understanding and Troubleshooting the VM and your Application

Slides: http://dl.dropbox.com/u/635/debugging_ruby-lsrc.pdf

• lsof -nPp : get open files for a specific pid
• strace: observe functions being called. Can see reads and writes between processes, like rails hitting mysql
• compile ruby w/ –enable-pthreads (not by default in debian or in rvm)
• See http://rvm.beginrescueend.com/rubies/installing/ end of page for how to do this via RVM
• tcpdump for networking
• google perftools for ruby profiling
• pprof ruby => graphical output
• home_run for C based time parsing
• perftools.rb for ruby diagrams of usage time
• gdb.rb to executive ruby from gdb, when running ruby via gdb
• bleak house: ruby memory leak detector
• rack-perftools: rack middleware for perftools.rb
• google perftools for forking

Caleb Clausen – What every Ruby programmer should know about threads

• Thread safe objects: mutex, queue, sizequeue, condition variable
• Semaphores to signal between threads
• Mutex to lock and unlock resources

Jesse Wolgamott – Battle of NoSQL stars: Amazon’s SDB vs Mongoid vs CouchDB vs RavenDB

• CouchDB is ACID, has great replication
• Mongo has great rails support

Day two

James Edward Gray II – Ruby in the Wild

• Logarithmic graphs!
• Rubyists like to do a lot of stuff from scratch
• “I’ve always been a fan of sqlite” – wha?
• For fun, scatch an itch, try something new
• “I try to make it a fun place [to work]“
• Greg Brown wearing a Boh hat for his interview
• Core of rake written in 30 mins
• Rake file list in place of Dir.glob for hydra? (FileList ?)
• File matching to compare input (source) and output (binary). Maybe for Sauron?

Chat with Scott Bellware

I had a great chat with Scott Bellware about Agile, Lean, and his own style of OO integration testing. He recommended this book:

The Principles of Product Development Flow: Second Generation Lean Product Development

Also, he sent me a link to how he does his OO testing scenarios:

http://github.com/sbellware/preview-signup

I flew back after lunch on day two, so I’ll have to catch the rest in the videos!

BohConf 2010

After an exhilarating week of hosting the Rails community in Baltimore for RailsConf, I thought it’d be helpful to share the lessons that we learned organizing BohConf.

Community Code Drives Rock!

We had a strong showing of open source authors including Wayne Seguin, Gregory Brown, Aslak Hellesøy, Chris Eppstein, Nick Gauthier and various members of Thoughtbot crew. Wayne (rvm) and Greg (prawn) in particular raved about the contributions they were able to make to their projects. Hey, I even got a new release of Timecop out thanks to a patch from Larry Marburger. Other well known OSS authors that dropped by included Rick Olson, Patrick Peak, and Josh Nichols. If you were there and we missed you, please drop us a line in the comments!

Employ Signage Everywhere

The Vim session at Monday's BarCamp (photo courtesy of Nick Gauthier)

One problem that we had was that people entering BohConf did not have a sense of what was actually taking place. Despite having a schedule posted online, it was often not clear what was underway. During the community code drives, we should have had signs next to each table pointing out which OSS authors were there to work on which projects. During the BarCamps, we could have similarly posted signs that indicated which discussions were happening at which tables.

Publish Live Updates to the Website

The thing about being internet (nerd) famous is that that doesn’t necessarily mean that anyone knows what you look like. It would have been cool to post photos on the website of the OSS authors who were currently working the Community Code Drive. Similarly we could have posted the current BarCamp sessions on the website. A countdown to the start and end of the programming contest would have been cool too.

Programming Contests Rock!

Give a bunch of nerds a dataset, a deadline, and no rules, and you get some pretty awesome efforts. Our client SpotCrime made available a dataset of crimes in Maryland in the past couple of months. Tim Johnson submitted a processing.rb time lapse visualization, Aaron Scruggs submitted a super cool and clever gource visualization, and Greg Brown and several members of his crew (Jia, Jordan and Chenoa) showed a lot of creativity with their submission of Spot the Baddy, a simple but fun interactive game where you can catch the bad guy!

Advertise the Programming Contest Better

While we were very happy with the submissions that we received for the programming contest, we felt that not nearly enough people were aware that it was taking place. Which also means that nobody knew we were giving out a $100 visa card to the best submission.

A Schedule is Important

When running an unconf for three days, you cannot simply throw out all semblance of organization and expect a success. With various people responsible for different aspects of BohConf, it was very helpful to be able to refer to the schedule when explaining what was happening at BohConf. Furthermore, it allowed us to communicate specifics well ahead of time via Twitter to those who wished to participate.

Code Retreats Rock!

Matt Scilipoti running the Code Retreat (photo courtesy of James Duncan Davidson)

…but perhaps it wasn’t the best choice to displace another BarCamp session. After a wildly successful BarCamp Monday afternoon, many folks returned Tuesday looking for another. Though the code retreat was clearly appreciated by the dozen or so folks that participated, there seemed to be a lot more interest in the BarCamp.

Momentum Slowed

Considering that Monday was tutorial day, it was unrealistic to expect us to maintain the same level of participation Tuesday and Wednesday. Not only was there a big dropoff from Monday to Tuesday, but there was another one from Tuesday to Wednesday. BarCamp Wednesday afternoon was less successful than Monday’s, the discussion groups dissipated before we even got to the last session. It’s also worth noting that those of us running BohConf were running on fumes by that point which likely contributed to the loss of momentum.

We Didn’t Market SmartLogic Well Enough

While SmartLogic is instrumental to the B’more on Rails community (as a sponsor and organizer), BohConf was actually undertaken entirely by our team at SmartLogic. We felt that we missed a big opportunity to establish our company and individuals as more visible members of the Rails community. Our team members should have all had shirts, and we should have given away stickers and buttons to all attending BohConf.

Encourage Conversation

A group discussion at BohConf (photo courtesy of Nick Gauthier)

A large format session at an event like RailsConf scales pretty well. As far as you can project a speakers image (in time and space), that’s how many people you can reach. Open space events like BohConf scale less well because the effects are personal. The benefit of attending this kind of event is a lot more subjective, because each person’s experience is different. This means it’s vital that you give plenty of opportunities for people to start conversations. The BarCamp format isn’t about presentation topics as ending points, they’re conversation starters. The folks who got the most out of the event seemed to be the ones most open to meeting new people and sharing their story.

A fantastic way to get people involved is to simply encourage them to ask, “What are you working on?” Follow up with, “tell me about that” and most geeks, passionate about their craft and otherwise quiet, will talk for an hour.

Don’t Be Shy about Asking for Help Promoting

Though we had about 100 followers prior to the start of BohConf, we failed to reach a large segment of the RailsConf attendees before the conference started. Attendee after attendee that I spoke to were hearing about BohConf for the very first time. We should have reached out to Chad, DHH and others to talk about BohConf in the weeks leading up to it. Even a few tweets would’ve given the event a nice bump.

Get a Bigger Room Next Time

Despite the waning momentum as the days went on, we were still overpacked in the conference room that we had available. Luckily on Monday we were able to hijack the adjacent media room for our use. Otherwise we would have had to turn away to half of the 80+ folks hanging out during the peak.

Finally

We had an absolute blast organizing BohConf for the community. Practically all feedback we received was overwhelmingly positive. And there are rumors that we’ll be asked to put it on again next year. Whether or not we’re the ones to undertake it, we hope that these notes will aid those embarking on similar endeavors.

An extra special thanks to Adam Bachman, Nick Gauthier, Ryan DeStefano and Matt Scilipoti for their efforts in helping to run BohConf.

If you have any comments or critiques of BohConf, please leave a comment below. Thanks to all those who attended!

Ignite NYC

Web 2.0 Expo kicked off with Ignite NYC on Monday (11/16) night. We’re a big fan of Ignite talks (having created the websites for Ignites in Baltimore, DC, Annapolis and RailsConf) so it was exciting to check out Ignite in the Big Apple. The Ignite NYC website lists the speakers but doesn’t mention what they spoke about (we’d be happy to host your website). Unfortunately I didn’t take notes at this event and I’m not going to go through all the youtube videos right now, so I don’t have much to share.

Web 2.0 Sessions

NoSQL: The Shift to a Non-relational World

This talk, given by Dwight Merriman, was about non-relational databases, which is a different paradigm from traditional databases like MySQL, Oracle, MS Access, MS SQL Server, etc. Non-relational databases are interesting to me as I think they might be applicable to some of our client projects. My notes:

• No joins
• Uses map reduce instead
• When considering scaling out – think about “CAP” – you can pick any two of the following but you can never achieve 100% of all three:
  • Consistency: ensuring that data on multiple database servers are consistent
  • Available: you want the database to be available when you need it
  • Partition-tolerant: partitioning the database to run across multiple servers
• CAP constraints are most relevant when writing to the database. If you’re only reading from the database, it’s easy to have all three.

The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products

This talk was given by Eric Ries (@ericries), who blogs at Lessons Learned. He is someone with whom many tech entrepreneurs are smitten, and I must say I myself was impressed. My notes:

• Continuous Deployment
• Devs can check code in, gets deployed everywhere within 20 minutes
• Cluster will detect bad changes to the code, revert them, email everyone
• The example Eric gave was that if someone messes up the UI of the checkout
  screen, e.g. changes the "pay now" button such that users can’t see it
  and this causes the company not to receive payments, the system will automatically
  revert itself after 20 minutes or so.
• Lean Startups
• Commodity Technology Stack
• Customer Development
• Agile Product Development
• Agile Product Development
• Principles from Lean Manufacturing, Agile, and TPS
• Unit of Progress: A line of Working Code (as opposed to advancing the plan in waterfall).  Problem: known, Solution: unknown.
• Product Development at Lean Startup
• Unit or Progress: Validated Learning About Customers ($$$)
• Problem, Solution: unknown.
• Hypotheses, Experiments, Insights feed into XP, which feeds Data, Feedback, Insights back into Problem Definition / Customer Development cycle
• Problem team: (formerly sales, marketing, product development) – cross functional team
• Solution team: (formerly engineering, ops) – but should also include marketing – cross functional team
• Pivot: one turn through this feedback loop
• Ideas – build – code – measure – data – learn – back to ideas
• Minimize total time through the loop
• AAA’s of metrics:
• Actionable
• Accessible – must make sense to anyone, and must be accessible by anybody in the company (everyone should be able to pull the report)
• Most useful thing is to kill pet projects and help people see that pet projects are bad ideas.
• Auditable – "metrics are people too" – reports come from tangibles
  – when someone sees a report, they must be believable and must stand up
  to any questions.  People must be able to audit them because initial
  human reaction is to doubt and deny, etc.
• Measure the Macro
• Always look at cohort-based metrics over time
• Split-test the small, measure the large
• Five Why’s
• A technique for continuous improvement of company process.
• Theory: behind every technical problem is a human problem
• Example: imagine a server crashes.  Why?  Code got deployed
  that used some obscure API that caused it to crash.  Why?  Person
  that wrote the code was a noob engineer and didn’t know better and wasn’t
  trained.  Why?  Manager
  doesn’t believe in training.  Started with a server problem ended
  up with a management problem.
• Ask "why" five times when something unexpected happens.
• Make proportional investments in prevention at all
  five levels of the hierarchy.
• Behind every supposed technical problem is usually a human problem.  Fix
  the cause, not just the symptom.
• Helps us identify that we’re too busy to find out why we’re too busy
  or something
• Acts as a natural speed regulator.  If we’re spending too much time
  fire-fighting – we’ll have to slow down to address problem, etc.  Regulates
  our speed.
• Minimum Viable Product
• What’s the absolute least amount of product we can build to engage the
  visionaries?
• Instead of asking customers what they want (which they don’t usually
  know), we’re going to take our theory, put it out there, and TEST.
• Visionary customers can fill in the gaps on missing features – if the
  product solves a real problem.
• Fears:
• False negative: customers would have liked the full product, but the
  MVP sucks, so we abandoned the vision
• Too busy to learn: it would be faster to just build it right, all this
  measuring distracts from delighting customers
• Must have an agreement with the team to iterate – just because clients
  don’t like the first version doesn’t mean they’re not going to continue
  to iterate.

Eric mentioned a book he’s publishing: Startup Lessons Leaned (book) – still in “beta.” He also recommended The Four Steps to Epiphany.

Sketchboards & Prototyping – Method for Rapid Design

This talk, given by Todd Zaki Warfel (@zakiwarfel), described a process his company uses for prototyping ideas for applications. It was my favorite talk from the conference. Todd’s website is at http://zakiwarfel.com/. My notes:

1. Prototyping is a process
2. People often say "I think I get it but I’m gonna have to see it" -
   need to see prototypes
3. Todd’s company doesn’t do wireframes.  Their wireframes are their
   prototypes.  Wireframes
   might be sketched out on paper.  Click-through wireframes are their
   prototypes (XHTML/CSS).  They do production-level prototypes, not recommended
   for anybody else.
4. Two main reasons for sketching / prototyping in the process
1. Sketches are a great communication tool – don’t write notes – sketch
   them out
2. Pics have less room for interpretation than text
3. Lo-fi is cheaper, generally speaking, than doing AI, etc.
5. No written requirements – just visual requirements
6. "Agile Conference" – 1500 – 1600 people show up. Todd’s group
   made some app in two days, for charity, and raised a few thousand bucks with
   the app.
7. Design Studio Method
1. Industrial design / architecture method
2. A methodology where you build something, sketch something – create an
   idea – and then show it to people, let them critique it and tell you what’s
   good and bad about it.  Then iterate.  Take an idea, put it out
   in front of people, rip it to shreds, etc.  But you get to do that
   to their designs as well.
3. They’ll do the Design Studio Method sessions with their clients and get
   paid for it.
4. Write down a few keywords to describe the product today
5. Write down a few keywords to describe the product 6-9 months from now
   – print this out, put it in big words in the room
6. –> allows them to see their goals –> see what it is now, and
   what they’re targetting
7. Personas – people that are going to 
8. Inspirational printouts – stuff that looks aesthetically good or stuff
   that has good interaction – stuff to aspire to include in the next version
   of the product
9. Break into teams
1. One BA
2. One speaks to dev
3. One designer
4. One sales or marketing person
5. Represent all the different viewpoints
6. Give them a design challenge and have them sketch out – generate -
   their ideas
1. Building blocks of design: square, circle, triangle, line
2. Generate ideas and pitch them: 3 minutes to present them, 2 minutes
   to critique.  Say 2 things that are strong about the idea and 
7. Process:
1. Sketch -> present -> critique
2. -> prototypes
3. -> and again: sketch -> present -> critique
4. -> validate
5. -> iterate
10. Get started ASAP
11. Messy is okay
12. Quantity then quality –> generate lots of ideas and then refine
1. Peer review then pitch -> critique process
13. Templates that they use:
1. The 685 – an "8 up template" – can put 8 sketches in there.
1. First round you do by yourself – then critique (use red and green
   marker to denote what’s good and what’s not)
2. Second round your sketches are up on the wall
3. 5 minutes to draw 6-8 sketches
4. Can also be used as a storyboard
5. One or two rounds with 8 ups – sketching, critiquing, etc.
2. Then a 1 up
14. Three rules:
1. Know your audience and intent (are you going to give sketches to a
   CEO?)
2. Plan a little.  Prototype the rest.  This guy does about
   70% in sketches / planned out, then starts prototyping.
3. Set expectations – to combat questions like "why is this B&W" or "what
   about the admin" etc.
15. Closing thoughts:
1. You can sketch.  No BS, anybody can sketch.  Anybody can
   sketch, good enough to put their idea down on paper.
2. It’s [sketches] not the mona lisa.  Just needs to be good enough.  Not
   going to live forever in Moma or the Louvre, etc.
3. If you can’t make it then fake it.  E.g. if you can’t get it to
   work in Javascript, use Keynote.
4. Prototype only what you need.  Prototype the unique parts, not
   the entire system.
5. Reduce risk.  Prototype early and often.  Do about 2 weeks
   of design studio sessions with their clients.  Then they jump right
   into prototyping.  Then they do weekly releases.  Whole agile
   argument – small and rapid iterations.

"You can fix it now on the drafting board with an eraser or you can fix
it later on the construction site with a sledge hammer." – Frank Lloyd
Wright

Todd was promoting his new book: Prototyping – A Practioner’s Guide – by
Todd Zaki Warfel, which I’ve added to my wishlist at Amazon. He mentioned that it has 6 tutorial chapters, a bit on how to sell prototyping, and some other interesting stuff.

Freeing and Visualizing Financial Data

This talk was given by Toby Segaran (@kiwitobes) and Jesper Andersen (@jandersen). They put the slides from the presentation up on slideshare. My notes:

1. Why visualize?
1. To form a hypothesis
2. To tell a story
2. Single variable – shows you that a variable is moving but doesn’t tell you why
3. Data Sources
1. XBRL – put forth by SEC – to put all corporate-filed reports into the open domain in an XML readable format
1. Capital IQ – data vendor
2. Requirement – in 3 years everything will have to be encoded in XML
2. BSYM – Bloomberg Open Symbology
1. Unique keys of finance -> links symbologies in finance.  Problem is that different data vendors have different keys and it’s a mess.
2. Competing standard is CUSIP – very expensive – but they own the data standard
3. Yahoo! Finance data – downloadable via CSV – data goes back
4. Amazon Web Services -> Category: Economics -> lots of data feeds
5. "Trader Work Station" – some Java thing
4. Freerisk – site they created