Well, we upped the ante and have decided to give away a total of FOUR free tickets. We received a total of 40 submissions and were really encouraged by all of the enthusiastic responses. Without further ado:

1. Brian Sierakowski – @bsierakowski – Managing Editor of Baltimore’s [StartupDigest]2, founder of CahootsApp and eCommunications & Office Manager at Greater Baltimore Tech Council.
2. Paul Kauders – @pkauders – founder of SplitGear, a Baltimore-based company hoping “to make community based sharing of equipment the norm.”
3. Leela S. – a student at Towson University. Leela has “never won anything before, so this would be a real treat.” Well, there you go.
4. Eric Oestrich – @EricOestrich and oestrich on github – a student at Towson University that participated in the debut of the Baltimore Hackathon.

We’ll contact the winners shortly.

If you didn’t win: buy a ticket – or – stay tuned! More announcements to follow.

Thanks to everyone that helped us spread the word. If you’re interested in hearing what else we’re up to then please follow us on twitter.

So, I figured with a little capybara and a little therubyracer, I could test my javascript with real route calls. Let’s check it out.

The Javascript I want to test:

var dataObject = {};
var getRemoteData = function() {
  $.getJSON('/remote_path.json', function(data) {
    dataObject = $.parseJSON(data);
  });
}

We will pretend that hitting /remote_path.json returns the following response in JSON:

{ "my_information": "my response data" }

I want to test:

1. That /remote_path.json is accessible and returns information
2. That dataObject is populated with a Javascript Object containing the params I pass down

Here is my commented testing code:

  test 'get some information via ajax' do
    # Create a new JS Context. :with => self means that
    # the global namespace is the current context
    js = V8::Context.new(:with => self)
 
    # Load up our JS file
    js.load(File.join(Rails.root, 'public', 'javascripts', 'application.js'))
 
    # Define a mock method for getting JSON data
    def getJSON(url, callback)
      # When the JS wants some data, get it for real w/ capybara
      visit url
      # And call the JS function passed in (ruby => js)
      callback.call(page.body)
    end
 
    js.eval %{
      /* Mock out jQuery */
      var $ = {};
 
      /* Setup the mock in the right place (JS => ruby) */
      $.getJSON = getJSON; 
 
      /* Mock out jquery parseJSON to call ruby JSON.parse
         Since the args are the same, it is plug and play!
         (JS => ruby) */
      $.parseJSON = JSON.parse;
 
      /* Trigger our JS */
      getRemoteData();
 
      /* Assert what we expect (JS => ruby) */
      assert_equal(" ", dataObject.access_key);
    }
  end

This is not an example of an incredibly useful test, but I found the ability to bind back and forth easily between ruby and javascript to be mind-blowingly incredible. I mean, look at that last line, where I call assert and pass a javascript object to it!

Huge thanks to Charles Lowell (cowboyd) for his hard work on therubyracer.

Enjoy the weekend!

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!


$> ls -l ~/projects/timecop/lib
drwxr-xr-x 5 john staff 170 Jan 14 20:31 timecop
-rw-r--r-- 1 john staff 82 Jan 14 20:31 timecop.rb


The reason for this is related to how RubyGems hijacks Ruby’s require method. When a gem is activated its lib/ folder is added to the load path. This means that anything inside that directory is now accessible via the require method. In order to avoid file naming collisions across gems, you must name these exactly the same as your gem. (see slides for I Don’t Trust Your Code for a more complete discussions of this)

However, this is slightly different with rack gems. The convention for naming rack middleware is by using a dash, e.g. rack-rewrite. The convention for requiring rack middleware though is to replace that dash with a slash, e.g. require 'rack/rewrite'.

The convention I’ve adopted for structuring rack middleware within a gem is to include a file by the same name as the gem and a rack directory in lib/, and then to include the second part of the middleware name as a subdirectory under that.


~/projects/rack-rewrite (master) $> ls -l lib/
total 8
drwxr-xr-x 4 john staff 136 Apr 17 18:02 rack
-rw-r--r--@ 1 john staff 22 Apr 17 18:02 rack-rewrite.rb

~/projects/rack-rewrite (master) $> ls -l lib/rack
total 8
drwxr-xr-x 3 john staff 102 May 13 11:09 rewrite
-rw-r--r--@ 1 john staff 827 Apr 17 18:02 rewrite.rb


This allows my users to use either require 'rack-rewrite' or require 'rack/rewrite'.

Rack::Rewrite is a web-server agnostic rack middleware for defining and applying rewrite rules. In many cases you can get away with Rack::Rewrite instead of writing Apache mod_rewrite rules.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Fix rack 1.1.0 / rails3 compatibility by eliminating reliance on REQUEST_URI env param. Paths are now constructed with PATH_INFO and QUERY_STRING
• Follow rack directory/require convention: require ‘rack/rewrite’ instead of ‘rack-rewrite’
• Include an HTML anchor tag linked to where the URL being redirected to in the body of 301′s and 302′s

But the answers are spread out and distributed randomly. Plus, I can only see “The program ‘______’ is currently not installed. You can install it by typing: sudo apt-get install ______” so many times before I lose interest and put off the task.

So, to prevent future headaches and help all of us out, I put together a how-to that can take a new Rails system from zero to code in a few minutes (depending on network speed) instead of half a day. With no further ado,

Setting up an Ubuntu box for Rails Development (including virtual machines)

Update everything

$ sudo aptitude update && sudo aptitude dist-upgrade

Install necessary packages

$ sudo aptitude install build-essential vim \
  vim-runtime git-core subversion libsqlite3-dev

We have projects in git (the newer ones) and svn, so we have to be able to switch fluidly between the two.

And I’m not trying to start a flame war, but Vim is the first choice for Rails development. You don’t have to take my word for it; Jamis Buck, Tim Pope, and Adam Lowe all say the same. I recommend the NERDTree, FuzzyFinderTextMate, BufExplorer, and rails.vim plugins if nothing else.

Install ruby

$ sudo aptitude install ruby1.8 ruby rdoc ruby1.8-dev \
  libpgsql-ruby1.8 libmysql-ruby1.8 irb libopenssl-ruby

Get rubygems from source. http://docs.rubygems.org/

$ wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz

$ tar xzvf rubygems-1.3.5.tgz

$ cd rubygems-1.3.5

$ sudo ruby setup.rb

$ sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

$ sudo gem update --system

Update ~/.gemrc (at least the :sources: chunk)

---
gem: --no-ri --no-rdoc
:benchmark: false
:verbose: true
:backtrace: false
:update_sources: true
:sources:
- http://gemcutter.org
- http://gems.rubyforge.org/
- http://gems.github.com

Install and setup Passenger (optional)

$ sudo apt-get install apache2-prefork-dev

$ sudo gem install passenger

$ sudo passenger-install-apache2-module

and follow the instructions passenger gives you. Most folks in the office run some form of an Apache-Passenger stack for development purposes. I can explain how that setup works in a future post.

Install geminstaller

$ sudo gem install geminstaller

Almost all of our legacy projects use geminstaller to manage gem dependencies. In the future, new projects will be moving to Bundler, but legacy projects matter and upgrading subsystems is not always justified.

“If it ain’t broke, don’t fix it” and the corollary: “because you probably won’t be able to bill it to the client” both apply.

Install common packages (optional, may be required by projects)

$ sudo aptitude install imagemagick

$ sudo gem install utility_belt open_gem redgreen

The first (imagemagick) is used by the Paperclip gem to manage files attached to Rails models. The second are tools that make Rails development more manageable on the command line. I highly recommend them. Besides, I’ve been sneaking redgreen in as a test dependency on our projects, so if you’re a developer here you’ll have to install it anyways.

Create an ssh key (follow instructions)

$ ssh-keygen

EXAMPLE PROJECT

All the stuff above won’t let you test-code-deploy without hassles, so here’s a sample run through of what the last mile of project-specific setup looks like.

Get the project. SVN, Git, whatever. Go to it.

$ svn co rails-project

$ cd rails-project

Run geminstaller

$ sudo geminstaller                                 # normal

$ sudo geminstaller -c config/test/geminstaller.yml # test env

Install necessary aptitude packages

$ sudo aptitude install texlive-latex-base

Don’t ask.

Create the test database

Mysql:

$ rake RAILS_ENV=test db:create

Postgres (using your username or DB username in place of “username”):

$ sudo -u postgres psql

postgres=# CREATE USER username SUPERUSER;

postgres=# CREATE DATABASE username OWNER username;

If you get an error regarding PGconn.quote_ident (Rails 2.3.x on Ubuntu 8.04) patch activerecord-2.3.4/lib/active_record/connection_adapters/postgresql_adapter.rb and add the following:

def PGconn.quote_ident(name)
  %("#{name}")
end

immediately after the “class PGresult” definition at the top of the file. Once that’s all done, the following:

$ rake RAILS_ENV=test db:create

$ rake RAILS_ENV=test db:schema:load

$ rake RAILS_ENV=test test

should work.

go have fun, write code, blow our minds

So that’s how we roll. Awkward requirements will still crop up as we pick up new projects (or very old projects) so you’ll always need a bit of apt/gem fu to get you through the day. Leave questions here or drop me a line at adam@smartlogicsolutions.com or http://twitter.com/abachman.

Rack::Rewrite is a web-server agnostic rack middleware for defining and applying rewrite rules. In many cases you can get away with Rack::Rewrite instead of writing Apache mod_rewrite rules.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Implement $& substitution pattern (thanks to Ben Brinckerhoff)

Maintenance

• Ignore empty captures instead of failing during subsitution (thanks to Ben Brinckerhoff)
• Play nice with Rack::Test requests which only set PATH_INFO and not REQUEST_URI (thanks to @docunext)
• Use QUERY_STRING instead of QUERYSTRING as per Rack spec. Closes Issue #1.

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

Maintenance

• Fix various timezone-related issues. Notably, when traveling to a DateTime
  instance specified in a non-local timezone, convert provided DateTime
  instance to a local instance and return that from DateTime.now.
  Code contributed by Michaël Witrant [piglop]
• Fix bug that would not allow Timecop to be used when Ruby’s ‘date’
  library had not been previously loaded.
  Code contributed by Tuomas Kareinen [tuomas]
• Fix bug when traveling to a DateTime across a DST boundary that
  resulted in DateTime’s being off by an hour.
• Migrate argument parsing into Timecop::TimeStackItem to reduce the
  responsibility of the Timecop class.