Please feel free to comment if you’d like to add a link to the list.

From Day 1:

Rubinius : Use Ruby™
odrk-http-client/perf/bm.rb at master · asakusarb/odrk-http-client
Ruby HTTP clients features 2012nahi/httpclient
MagLev
Refinements in Ruby — Timeless
Librato Metrics
Home | Metrics
Operational Intelligence, Log Management, Application Management, Enterprise Security and Compliance | Splunk
amatsuda/rspec-refinements · GitHub
eric/metriks
Code Climate. Hosted static analysis for Ruby source code.
RubySpec: The Standard You Trust™
Jesse Storimer

From Day 2:

The Pragmatic Bookshelf | The dRuby Book
tenderlove/tusk
Improve your Code Quality at RubyConf 2012
Celluloid: Actor-based Concurrent Objects for Ruby
Ruby, Rails, DCI and OOP. Don’t just make abstractions, write clean, intention-revealing Ruby. Clean Ruby by Jim Gay teaches about OOP, DCI, and more!
Ruby Under a Microscope – Pat Shaughnessy
Unlimited Novelty
37signals/sub
tdiary (tDiary)
T by sferik
Schneems • UT on Rails
Resque Triage
josephwilk/creative-machine
burtlo/metro

From Day 3:

Videos – WindyCityRails
Gosu, 2D game development library
Sikuli Script – Home
tenderlove/racc

Reach out on Twitter @ericoestrich if you’d like to catch up at RubyConf, or ask a question about any of these links.

The post RubyConf 2012: Links to Follow Up On appeared first on Web Development Advice and Tips.

Here’s three things I’m particularly excited about, besides being dry:

1. Learning About the Wonderful World of Ruby from Matz: This one’s a no-brainer. I’m pumped to hear from the creator of Ruby, and maybe get a sneak peek of what’s coming with Ruby 2.0.
2. Focusing on Ruby in Sessions: When I went to RailsConf, it was all Rails sessions, with nothing focusing just on Ruby. I’m excited to focus exclusively on Ruby, with, of course, some Rails and other web stuff sprinkled in. There’s one about dRuby (distributed Ruby) that I’m particularly interested in.
3. Hearing about Scalable Web Architectures: There’s two sessions related to scalable web architectures that I’m looking forward to, because I’m working with apps using scalable web architectures every day. First, I hope Chris Hunt from Square, who’s covering Service Oriented Architecture (SOA) at Square, mentions rspec_api_documentation when he covers API documentation! But really, I’m also interested to hear his perspective on Square’s approach to SOA. Second, I am interested in learning more about Cross Origin Resource Sharing (CORS) from Michael Bleigh, co-founder of Divshot. This isn’t directly related to what I’m doing at work right now, but I’m looking forward to bringing takeaways home to our team.

Are you headed to RubyConf? What are you looking forward to? Comment below, or tweet me @ericoestrich.

The post RubyConf 2012: 3 Things I’m Looking Forward To appeared first on Web Development Advice and Tips.

Pick your poison: public, private, or SOA

Each one has its own considerations and needs.

Several issues come into play when deciding what type of API you need. How much control do you want over your brand? How many people are going to be using the API? What’s your current plan for authentication? Are you helping services interact with each other, or connecting a back-end to a front-end? There are lots of different approaches, and they all yield different products.

Public APIs are generally used as platforms, opening up your data and software to outside use. For example, Facebook, Twitter, and WordPress all have public APIs open to developers. Private APIs, on the other hand, are never seen by the consumer. For example, most mobile applications are built using APIs.

Then there’s SOAs (service oriented architecture)—which some include in the API category and some keep separate. Unlike a basic API, SOAs help backend services work together. Most SOAs are kept private.

Document or die

Documentation is extremely important for APIs because you could have a team of developers who weren’t involved in building the API taking it and running with it. We handle this through a tool we built to combine testing with automatic documentation generation. We’ve published it so you can use it too: check it out in our post “Curlin’ for Docs.”

REST, don’t nap

No matter what type of API you’re building, your design should be RESTful (REpresentational State Transfer). Ruby on Rails makes RESTful APIs simple to create. In turn, RESTful design makes APIs simpler to design, version, and use.

Who is the audience?

Is your API for internal use, or will it be publicly available? Will it be a platform that people outside your organization will rely on?

With an API the public uses, you can’t just wander off the map; you have to design with your users in mind. A private API, on the other hand, is essentially like making sure that your handwriting is legible on your kitchen’s whiteboard: it can look like Sanskrit as long as everyone in the house can read it. If the objective is only a communication tool for your team, you have more leeway in designing for you and the team, not developers all over the world.

Thus, your API’s budget and construction will be totally different depending on your ideal use cases.

How’s your budget looking?

If the goal is a private API for internal use, your pockets don’t need to be as deep as a public API project. As explained above, a private API has a focused set of uses and doesn’t need to interface as widely, so building one isn’t as cost intensive.

What’s the lifespan of your API?

In almost all API cases, it makes sense to plan ahead as much as possible, which means designing it right the first time. Especially if your API is used as a platform. When you version your API, it’s extremely important to make each upgrade consistent, reliable, and basically adherent to best practices standards. People who use your API will expect as much, and it makes your life easier down the road.

How will you handle authentication?

In a world of spam and hacking, it’s extremely important to keep your users’ trust. Use OAuth authentication for your API so that external developers don’t have direct access to information like usernames and passwords.

That’s a quick flyby of some things to consider before you get your API on.

Check out @smartlogic on Twitter or like us on Facebook for more like this!

The post API Planning and Proceeding: Tell Me What You’re Working With appeared first on Web Development Advice and Tips.

Let me tell you why I still think you should write controller tests:

• They are very easy to write
• They are mostly the same
• Because they are mostly the same, we can refactor and make them even easier to write

We all refactor our code, but it’s just as important to refactor our tests. The goal of refactoring is to facilitate reuse and increase clarity. Refactoring let’s us develop new abstractions upon which we can build complex logic. Our controllers are so lean and mean because they are benefitting from a very convenient abstraction: RESTful web services.

Chances are most of the controllers in your app have a lot of shared behaviors. They find, create, and update your models, set flash messages, redirect or render templates, and set status codes. Let’s take advantage of the shared behaviors to refactor our tests.

Put the following file into spec/support/controller_helpers.rb

module ControllerHelpers
  extend ActiveSupport::Concern

  module ClassMethods
    def self.define_action(action)
      define_method action do |*args, &block|
        options = args.extract_options!
        options[:http_method] = action
        options[:controller_method] = args[0]
        args[0] = [action.to_s.upcase, "#" + options[:controller_method].to_s].join(" ")
        args << options
        context(*args, &block)
      end
    end

    define_action :get
    define_action :post
    define_action :put
    define_action :delete
    define_action :head
    define_action :options

    def it_should_flash(type, message)
      it "should set the flash" do
        do_request
        flash[type].should eq(message)
      end
    end

    def it_should_redirect_to(&block)
      it "should redirect" do
        url = instance_eval(&block)
        do_request
        response.should redirect_to(url)
      end
    end

    def it_should_render_template(template)
      it "should render the #{template} template" do
        do_request
        response.should render_template(template)
      end
    end
  end

  def do_request
    params = if respond_to?(:params) then send(:params) else nil end # of story
    send(example.metadata[:http_method], example.metadata[:controller_method], params)
  end
end

RSpec.configure do |config|
  config.include ControllerHelpers, :type => :controller
end

Now we can write our controller specs easily. For example:

require "spec_helper"

describe FoosController do
  get :new do
    it_should_render_template :new
  end

  post :create do
    let(:params) { "foo" => { "bar" => "baz" } }
    let(:foo) { stub }

    before { Foo.stub!(:new).with("bar" => "baz").and_return(foo) }

    context "successful create" do
      before { foo.stub!(:save).and_return(true) }

      it_should_set_flash :success, "Created foo."
      it_should_redirect_to { foos_url }
    end

    context "failed create" do
      before { foo.stub!(:save).and_return(false) }

      it_should_render_template :new
    end
  end
end

Enjoy!

The post Using RSpec Macros and Metadata appeared first on Web Development Advice and Tips.

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.

The post Announcing Winners of Free Tickets for Intro to Ruby Course appeared first on Web Development Advice and Tips.

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!

The post Testing AJAX with Test::Unit appeared first on Web Development Advice and Tips.

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

The post Nick’s Highlights from Windy City Rails appeared first on Web Development Advice and Tips.

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

The post Nick’s Highlights from Ruby Hoedown appeared first on Web Development Advice and Tips.

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!

The post Nick’s Highlights from Lone Star Ruby Conf appeared first on Web Development Advice and Tips.


$> 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'.

The post Directory Conventions for Rack Middleware RubyGems appeared first on Web Development Advice and Tips.