Find dead code in your Rack app by running Coverband in production #

Neat idea from Dan Mayer at Living Social: Coverband is a rack middleware which helps measure production code coverage.

Why would production code coverage data be useful? Because you can use it to find (and then purge) latent code paths in your app. How’d it go at Living Social? Dan says:

After running in production for 30 minutes, we were able very easily delete 2000 LOC after looking through the data. We expect to be able to clean up much more after it has collected more data.

Read more about Coverband on the Living Social Tech Blog.

Divergence turns subdomains into remote branches #

Switch branches as fast as you switch pages. Waiting for a deploy sucks. Allocating a staging server for each remote branch is costly. But nothing beats testing on a staging server with real production data. Divergence allows you to quickly test your remote branches simply by changing the subdomain.

If you’ve ever had the need for a second staging server for an early release of a feature that’s not ready to merge to master, Divergence from LayerVault could be what you’ve been waiting for.

Divergence sub-domain example

With Divergence you can easily view any branch from your repository on your staging server by using the branch name as the subdomain. Just use your branch name as the sub-domain and Divergence will magically find your branch and serve it up. You can even hook into a number of callbacks to automatically restart Passenger, run bundle install, or any other task if needed.

It’s a Rack application that acts as a HTTP proxy between you and your web application for rapid testing. Divergence was built with an Apache-Passenger stack in mind, so if you’re wanting to help develop the project further, checkout the contributing section of the readme.

Divergence is a work in progress, and labeled as a beta release. The folks at LayerVault could use a hand with:

  • Increased language support
  • More stacks supported, (e.g. nginx, Unicorn, etc.)
  • HTTPS support built-in

Sample config from the readme:

Divergence::Application.configure do |config|
  config.git_path = "/path/to/git_root"
  config.app_path = "/path/to/app_root"
  config.cache_path = "/path/to/cache_root"

  config.forward_host = 'localhost'
  config.forward_port = 80

  config.callbacks :after_swap do
    restart_passenger
  end

  config.callbacks :after_cache, :after_webhook do
    bundle_install :path => "vendor/bundle"
  end

  config.callbacks :on_branch_discover do |subdomain|
    case subdomain
    when "release-1"
      "test_branch"
    when "release-2"
      "other_branch"
    end
  end
end

Checkout the repo and readme for detailed instructions on installation and setup. If you’d like to see more stacks supported beyond an Apache-Passenger stack, fork it and help out.

Rack::CoreData – Automatically generate REST APIs for Core Data models #

An interesting project from Mattt to scaffold RESTful web services based on CoreData models using Rack.

require 'bundler'
Bundler.require

# Rack::CoreData requires a Sequel connection to a database  
DB = Sequel.connect(ENV['DATABASE_URL'] || "postgres://localhost:5432/coredata")

run Rack::CoreData('./Example.xcdatamodeld')

View the Source for this project on GitHub.

Weary, Ruby DSL for HTTP goes 1.0, now built on Rack #

Mark Wunsch, whose awesome Tumblr library you might already use, has spent the last few weeks refactoring his Weary project to be fully Rack compatible.

Weary has always sported a rather elegant DSL for wrapping Net::HTTP, but after the big rewrite, you can now use Rack middleware and your client is a Rack application:

# http://developer.github.com/v3/repos/
class GithubRepo < Weary::Client
  domain "https://api.github.com"

  use Rack::Lint

  get :list_user_repos, "/users/{user}/repos" do |resource|
    resource.optional :type
  end

  get :get, "/repos/{user}/{repo}"
end

client = GithubRepo.new
client.list_user_repos(:user => "mwunsch").perform do |response|
  puts response.body if response.success?
end

Check out Mark’s Gilt API wrapper for a complete example of building a wrapper with Weary or the project wiki for more info on how a Weary Request works. Mark has also recorded an introductory screencast that covers what’s new in 1.0:

OmniAuth goes 1.0 #

OmniAuth, everyone’s favorite multi authentication provider released version 1.0 this week. As Michael outlines in the official blog post, the biggest changes are:

  • Authentication strategies are no longer in OmniAuth core, but reside in their own gems. This means there is no gatekeeper for implementing a strategy for a given service.
  • A basic bare-bones identity strategy in the form of omniauth-identity
  • Improved dynamic strategies with support for custom forms.

Check out the wiki and blog post for more.

Renee – Sinatra-inspired Rack framework for über DRY routing #

Josh Hull knows Sinatra. As part of the Padrino, he also knows about creating new alternatives to popular frameworks. His latest effort is Renee, a web framework for Rack that aims to DRY up your routes.

We wondered though, as Sinatra fans, if we were to come up with a cleaner and more powerful DSL, what might that look like? Let’s consider an example from Sinatra to see where we can do better.

The result is a pivoted syntax that turns the routing DSL on its side:

path 'blog' do
  var do |id|
    @blog = Blog.get(id)
    get { halt @blog }
    put { @blog.update(request.params); halt :ok}
  end
end

I can see how powerful this could be for creating complex REST APIs. Check out the nicely designed web site for more.

Deployinator – Deploy with Style, by Etsy #

I am super excited to make this post.

One of my favorite engineering blogs is Code as Craft. Etsy is one of my favorite startups, they’ve got cool people working there, they help people make and sell neat things, and contribute a lot back to the community.

A while ago, they mentioned that they had an in-house, custom deployment tool. And they were thinking about open sourcing it. I’m really fascinated by what (by now) is being hailed as “DevOps,” and so I was really interested to see what they were building.

And then I waited.

And now, they’ve released it. From their GitHub, it’s just a little Sinatra app that you can run. It has the concept of ‘stacks,’ so you can roll things out in waves if you’d like. They give an example of having a ‘search’ stack and a ‘web’ stack. Each stack can have environments, so you have ‘search staging’ and ‘search production,’ for example.

It’s a bit light on documentation at the moment, and since it came out under an hour ago, I have yet to try it out for myself. But I’m super excited to, and wanted to share. Bust out those fork buttons!

Check out the source on GitHub.

pow: Zero-configuration Rack server for Mac OS X #

I’ve been a long-time Passenger user to switch between multiple Ruby web apps during development without needing to crank up rails s for each. When I began using RVM to switch back and forth between multiple Ruby versions, Passenger no longer solved my problem. That’s why I’m excited to try out Pow from 37 Signals. Pow aims to be “a zero-config Rack server for Mac OS X.”

To install, run the install script

curl get.pow.cx | sh

To add apps, just symlink them to your ~/.pow folder:

$ cd ~/.pow
$ ln -s /path/to/myapp

… and browse to http://myapp.dev/.

[Source on GitHub] [Annotated Source]

rack-pagespeed: Rack middleware for page speed optimization #

Thanks to work by Google and Yahoo, we’re all better informed about how to speed up our web pages. For those on Apache, Google has made it easier to implement these ideas at the Apache Module level. For those running on Ruby web frameworks, Julio Cesar offers up the same goodness as Rack middleware.

Rack Pagespeed offers some HTML output filters to help you implement page optimization best practices with minimal effort. To get started, install the gem:

gem install rack-pagespeed

For Sinatra, Rack, or Padrino apps, configure Rack Pagespeed in your config.ru Rackup file:

require 'rack/pagespeed'
require 'myapp'
use Rack::PageSpeed, :public => "/app/public/dir" do
  store :disk => Dir.tmpdir # require 'tmpdir'
  inline_javascript :max_size => 4000
  inline_css
  combine_javascripts
end
run Sinatra::Application

For those Rails, create a rack_pagespeed.rb initializer with:

require 'rack/pagespeed' # somewhere
class Application < Rails::Application
  config.middleware.use Rack::PageSpeed, :public => Rails.public_path do
    store :disk => Dir.tmpdir # require 'tmpdir'
    inline_javascript :max_size => 4000
    inline_css
    combine_javascripts
  end
  # ...

Filters

Out of the box, Rack Pagespeed supports filters to:

  • Inline JavaScript under 2kb
  • Inline CSS under 2kb
  • Bundle JavaScript files
  • Minify JavaScript files
  • Bundle CSS files
  • Inline images using data-uri

You can even roll your own filters.

Storage

Rack Pagespeed currently supports two storage options: disk and memcached. See the well designed docs for advanced options.

[Source on GitHub] [Web site]

rack-modernizr: Ruby Rack middleware for Modernizr on the server #

A couple of weeks ago we covered modernizr-server, a nifty PHP project that lets you tap into the power Modernizr on the server. Modernizr, of course, is the JavaScript feature detection library that allows you to check browser support for HTML5 and other advanced features.

Inspired by modernizr-server, Marshall Yount brings Modernizr to your Ruby web projects via some slick Rack middleware. The first time a user visits your site, rack-modernizr adds the Modernizr library to your page automatically and stuffs all that Modernizr info into a cookie that you can check on subsequent requests on the server side.

To install, grab the gem:

gem install rack-modernizr

To use in your Rack app, just require it in your rackup file:

# config.ru

require ::File.expand_path('../config/environment',  __FILE__)
require 'modernizr'
use Rack::Modernizr

run MyApp::Application

In Rails, add the gem to your Gemfile and configure the middleware in your application.rb

module MyApp
  class Application < Rails::Application

  config.middleware.use Rack::Modernizr

end

[Source on GitHub]

multitrack: Rack app to track multiple traffic sources for your web signups #

If you’ve found tracking return on your marketing dollars a challenge for your web application, take a look at Multitrack from Shopify founder Tobias Lütke. Multitrack is a Rack app that lets you store multiple traffic sources for your application signups.

To use Multitrack, deploy the Rack app to your own server on your server stack of choice, configure the database info, and add the following to your signup page:

<script src="http://<yourserver.com>/track.js"></script>

[Source on GitHub]

That app is Phat #

We all know the Rails Can’t Scale line to be bunk, but that doesn’t mean we stop looking for ways to speed up Rails apps.

Mike Perham says his apps are Phat, and yours can be, too. Phat is a Rails app pattern that employs a single Thread, multiple Fiber model in Ruby 1.9 to async-ify an otherwise vanilla Rails app behind Thin.

Phat uses rack-fiber_pool, Mike’s Rack Middleware to execute each request in a Fiber. Phat also configures Fiber-enabled async libraries including em_postgresql, memcache-client, and em-resolv-replace to achieve some impressive scalability:

# Asynchronous DNS lookup
require 'em-resolv-replace'
require 'rack/fiber_pool'
# Pull in the evented memcache-client.
# You'll need to configure config.cache_store as normal.
require 'memcache/event_machine'

Rails::Initializer.run do |config|
  config.cache_store = :mem_cache_store
  # Run each request in a Fiber
  config.middleware.use Rack::FiberPool
  # Get rid of Rack::Lock so we don't kill our concurrency
  config.threadsafe!
end

[Source on GitHub] [Mike’s Blog Post]

Faye – dirt simple pub/sub for Rack and Node.js #

Two way communication in the browser isn’t easy. James Coglan brings aims to change that with Faye:

Faye is an implementation of the Bayeux prototcol, a publish-subscribe messaging protocol designed primarily to allow client-side JavaScript programs to send messages to each other with low latency over HTTP.

Essentially, Bayeux lets applications publish and subscribe to data in named channels, both in the browser and the server:

fayeClient.subscribe('/path/to/channel', function(message) {
  // process received message object
});

fayeClient.publish('/some/other/channel', {foo: 'bar'});

Faye supports long polling and callback polling, depending on if you would like to keep a persistent HTTP connection open in the browser or use a JSONP callback.

The really cool part is that Faye ships with functionally identical server implementations for both Rack and Node.js.

We just might have to try this out to enhance Tail.

Source on GitHub James Coglan on Twitter

toto – Close-to-the-metal blogging on top of Rack #

Take a look around the small site web landscape and it’s clear we’re not in Kansas anymore. It’s no longer a foregone conclusion that a new blog or brochure site should be built on a CMS or even web framework. Toto is the latest in a rising breed of static page generators.

Toto dumps the database and stores its content in plain text files. Its built on top of Rack and is Heroku & Varnish friendly so that your site will scream on even a free single dyno.

From the README, here’s how Toto works:

  • content is entirely managed through git; you get full fledged version control for free.
  • articles are stored as .txt files, with embeded metadata (in yaml format).
  • articles are processed through a markdown converter (rdiscount) by default.
  • templating is done through ERB.
  • toto is built right on top of Rack.
  • toto was built to take advantage of HTTP caching.
  • toto was built with heroku in mind.
  • comments are handled by disqus
  • individual articles can be accessed through urls such as /2009/11/21/blogging-with-toto
  • the archives can be accessed by year, month or day, wih the same format as above.
  • arbitrary metadata can be included in articles files, and accessed from the templates.
  • summaries are generated intelligently by toto, following the :max setting you give it.
  • you can also define how long your summary is, by adding ~ at the end of it (:delim).

To get started quickly, clone the default template Dorothy and deploy to Heroku in a snap.

[Source on GitHub]

Wackamole: Reporting on the gathered Rackamole data #

This is a companion rails app for the Rackamole framework which provides for recording interactions with your rack applications. Wackamole allows you to view, filter and drilldown on the collected moled information, hence allowing you to observe your applications live in the wild.

Wackamole gives you pragmatic information on whether to tackle new features, take a look at performance or fix bugs on your next iteration.

[code on GitHub]

Rackamole: Track user interactions with your web site #

Rackamole is a rack application that tracks user’s interactions with your web site. This is not about page hits. Rackamole captures the very essence of a user’s activity by recording various elements of a request that occurs within your application.

Using Rackamole you are able to see which feature is a hit or a bust. As an added bonus, you can also track performance and exceptions that might have escaped your test suites or alpha env.

[code on GitHub]

WebROaR: Ruby/Rack/Rails Application Server #

WebROaR aims to make the deployment of Ruby on Rails applications more easier, and provide an integrated solution to monitor the performance of the application and track its exceptions. This is made possible by a simple and easy to use admin panel of the server.

It also is the best performing server as per the developers benchmarks. Although, they do encourage you to perform your own tests and arrive at the same conclusion.

Features:

  • Simplified deployment with maximum performance
  • Runs Ruby on Rails as well as other Rack compliant applications
  • Run multiple applications simultaneously
  • Intelligent load balancing
  • Dynamically reap stuck Ruby processing instances
  • Provides run time performance data for the deployed applications
  • Generates notifications in case exceptions occur in any of the deployed applications

Hat tip: @igrigorikhttp://twitter.com/igrigorik/status/6143783082

[code at GitHub] [homepage] [documentation]