Announcing OmniAuth BrowserID

I’ve been following the progress of Mozilla’s BrowserID for some time now, and I’m a big fan. Having dove much deeper than most into the quagmire of fragmented authentication I’ve reached the same conclusion that Mozilla has: ultimately, authentication is a function that should belong to the user agent.

What is BrowserID?

BrowserID is a Single Sign-on service for the web, much like you can implement using OpenID or even Facebook or Twitter. However, BrowserID is fantastic for its simplicity: as an implementation of a simple “verified email” protocol, it is simply a way to be able to obtain the email of a user (and know that it’s verified).

For now, this works via a Javascript authentication flow on a website that Mozilla is maintaining. However, the future of this technology is that you would verify your email directly within your browser and would then be able to sign in to supported websites using your browser itself.

But, you ask, why do we want authentication in the browser? Browsers are called User Agents for a reason: they are simply tools that help connect you to the content of the internet that interests you. And a lot of that content right now requires you to manage dozens of different passwords and store sensitive login information with a third party. BrowserID doesn’t entirely solve this problem in its nascent web-based form, but once it is integrated into the browser itself BrowserID becomes a single, secure way to access content on the internet.

BrowserID + OmniAuth

I want BrowserID to succeed, and it will only succeed if people start using it. To that end, I’ve created OmniAuth BrowserID, a simple OmniAuth strategy that works with the BrowserID protocol. You can use it in your application like this:

# in Gemfile
gem 'omniauth-browserid'

# in application
use OmniAuth::Builder do
  provider :browser_id
end

That’s it! Now send your users to /auth/browser_id and they will be able to sign in using the BrowserID service. Of course you may prefer to implement your own Javascript flow. That’s fine, too, just take a look at the project README for more information about customizing the flow.

BrowserID is an important idea and whether Mozilla’s implementation is ultimately the one that gets adopted it’s high time we started moving authentication to where it belongs: in the user agent.

Implementing DRY Magic Methods in Ruby

As a new developer to Ruby you might wonder how certain methods seem to be magically available without being strictly defined. Rails’s dynamic finders (e.g. find_by_name) are one example of this kind of magic. It’s very simple to implement magic such as this in Ruby, but it’s also easy to implement things in a way that doesn’t entirely mesh with standard Ruby object expectations.

Your Friend method_missing

The way that many magic methods are implemented is by overriding method_missing. This special method in Ruby is automatically called by the interpreter whenever a method is called that cannot be found. The default behavior of method_missing is to raise a NoMethodError letting the user know that the method that was called does not exist. However, by overriding this behavior we can allow the user to call methods that aren’t strictly defined but rather programatically determined at runtime. Let’s look at a simple example:

class Nullifier
  def method_missing(*args)
    nil
  end
end

nullifier = Nullifier.new
nullifier.some_method     # => nil
nullifier.foo(:bar, :baz) # => nil

Here we simply told method_missing to immediately return nil, regardless of the method name or arguments passed. This essentially means that, for this class, any method call that is not defined on Object (the default superclass for new classes) will return nil.

While this example is certainly interesting, it doesn’t necessarily give us more use in the real world. Let’s take another example that actually does something useful. Let’s make a hash that allows us to access its keys by making method calls:

class SuperHash < Hash
  def method_missing(method_name, *args)
    if key?(method_name.to_s)
      self[method_name].to_s
    else
      super
    end
  end
end

h = SuperHash.new
h['abc'] = 'def'
h.abc            # => 'def'
h.something_else # => NoMethodError

This behavior gives us something pretty simple yet powerful: we have manipulated the foundation of the class to give us runtime methods. There’s a problem, though: using method_missing alone is only half the story.

Quack Check With respond_to?

In Ruby, you can call respond_to? with a symbol method name on any object and it should tell you whether or not that method exists on the object in question. This is part of what makes Ruby’s duck-typing work so well. So in our example, we also want to be able to know if a method is there using respond_to?. So let’s add a new override for the respond_to? method of our example above:

class SuperHash < Hash
  def respond_to?(symbol, include_private=false)
    return true if key?(symbol.to_s)
    super
  end
end

Well, that was easy enough. Now our SuperHash will return hash keys based on method_missing and even tell you if the method is there with respond_to?. But there’s still one more thing we can do to clean things up a bit: notice how we have repeated functionality in that we check key? in both methods? Now that we have a respond_to? we can use that as a guard for method_missing to make it more confident:

class SuperHash < Hash
  def method_missing(method_name, *args)
    return super unless respond_to?(method_name)
    self[method_name].to_s
  end
end

Wait, that can’t be right, can it? Can we just assume that we can call the key like that? Of course! We already know that no existing method was called if method_missing is activated. That means that if respond_to? is true but no existing method was called, there must be a key in our hash that caused respond_to? to return true. Therefore we can confidently assume that the key exists and simply return it, removing the conditional and cleaning up the method_missing substantially.

Now that you know how method_missing and respond_to? can work together to add functionality to an object at runtime, you have a powerful new tool in your metaprogramming arsenal. Enjoy it!

OmniAuth 1.0: Auth for All

Today I’m happy to announce that OmniAuth version 1.0.0 has been released into the wild. The result of more than a month of heavy development, the newest version of OmniAuth brings along with it a slate of new features, a whole new structure, and the tools to let OmniAuth be your only authentication library. The one thing that hasn’t changed is OmniAuth’s mission: to assume nothing about how your app works and what you want to do with authentication.

Breaking up the Band

OmniAuth was first written to abstract the common parts of authentication to external service providers like Twitter and Facebook. It launched as a small collection of gems that each contained many strategies (for instance, the oa-oauth gem contained Twitter and LinkedIn strategies). As OmniAuth’s popularity grew five strategies became fifty-five. Releases became fewer and further between because of the overhead of managing pull requests and issues for dozens of strategies.

No more. Starting with OmniAuth 1.0, each and every OmniAuth strategy will live in its own gem. The downside of this for end users is that you will have a few more lines to declare in your Gemfiles. The upsides, however, are numerous:

1. There is no longer a gatekeeper to releasing an OmniAuth strategy. Just build a gem, release it, and link it from the new strategy list wiki page.
2. Individual strategies are free to make releases as often as they’d like. Users don’t have to wait for a massive OmniAuth patch or minor release to pick up fixes for changing APIs or other improvements.
3. With a lean, focused core OmniAuth itself will be able to release more frequently and adapt itself to the needs of strategy authors.

As a final note about structural gem changes, OmniAuth 1.0 marks the beginning of strict semantic versioning for the project. For end users, this doesn’t mean much. For strategy authors, that means that you can safely declare your dependency on ~> 1.0.

Identity for OmniAuth

As I began using OmniAuth in my day-to-day coding, I began to crave the flexibility of OmniAuth in even traditional authentication scenarios. I wanted a way to leverage the same unassuming, simple authentication structure even when my users logged in via username and password. Today, I’m happy to announce the first official release of omniauth-identity, an OmniAuth strategy that bridges the gap between traditional auth and OmniAuth.

With omniauth-identity you can quickly and easily set up internal identity management for your app that behaves exactly like other OmniAuth strategies. The library is simple but its implications are powerful: you can now treat internal and external authentication exactly the same in your application.

OmniAuth now ships with a Developer strategy that is essentially “fake authentication” you can use as a placeholder until you determine your app’s real authentication strategies. Combined with the potential of Identity, authentication no longer has to be that annoying “first thing” you have to do before you can get down to the real business of building your app. Just drop in OmniAuth, use the Developer strategy, and implement other strategies down the road when it works for the timeline of your app. This is how I’ll be building all my apps from now on, and since OmniAuth is just Rack middleware even Sinatra and other non-Rails apps can use the same techniques.

For more information on how to use omniauth-identity, see the README on GitHub.

Strategy Builders: Better Docs, Better Tools

For the 1.0 release in addition to all of the new features and structure I also tried to significantly improve the documentation for the project, especially for those who are interested in building a strategy. You can see the results of those efforts on the OmniAuth wiki which is the official repository of all documentation for OmniAuth.

Along with better documentation for developers OmniAuth 1.0 also brings along a more declarative DSL for building strategies. The new strategy API gives developers clear ways to implement consistent functionality and makes everything cleaner across the board. For more information on the tools available for strategy developers, take a look at the Strategy Contribution Guide.

App Developers: Consistency, Dynamic Strategies

While many of the improvements in OmniAuth are structural and made for strategy developers, there’s also some great stuff available for everyday users of OmniAuth! Here’s some highlights of new features that work across all strategies:

Auth Hash. Some small tweaks have been made to the omniauth.auth hash that is returned after authentication completes. For one, you can now access keys using method accessors (e.g. env['omniauth.auth'].info.name. The user_info key has also been renamed simply to info. The schema can be considered a stable part of the public API and any breaking changes will trigger a major version release (you can rely on OmniAuth 1.9 to support the same schema as 1.0).

Options Everywhere. As of OmniAuth 1.0, strategy authors are encouraged to make all strategy configuration happen through the options hash that is passed in on initialization. You will still have strategies that have additional arguments (such as consumer keys and secrets) for convenience, but even those can be configured instead by passing in a single options hash. This means that every configurable aspect of the strategy is handled at runtime, which brings us to the next improvement.

Better Dynamic Strategies. OmniAuth 1.0 makes it easy to dynamically alter strategies for each request using the new, universally available setup phase. Simply set the :setup option to a Rack endpoint and you can modify the strategy or anything else about the environment before passing it along to OmniAuth for normal operation.

Skip Info. Some strategies will be able to determine the UID without making additional API calls. You can pass true, false, or a lambda that takes a UID and returns true or false as to whether additional info is required. This gives you the ability to make fewer API calls for cases where you already have a user in your system, for instance.

Custom Forms. If you are utilizing an OmniAuth strategy that displays the standard OmniAuth form, you can now pass in :form => (true || false || lambda) to the strategy to instead render a custom form that conforms better to your application. This replaces the previous poorly conceived method of requiring /auth/:provider to return a 404 in order for OmniAuth to trigger.

Calling All Companies

Now that each strategy for OmniAuth is its own gem, I’m putting a public call out to any and all companies with APIs, but especially companies that are already on a Ruby stack. I would like to get companies on board for maintaining their own “official” OmniAuth strategies. This gives developers using your API the simplest possible means of authenticating to your service and will only help you get more developer traction and experimentation.

I’m also happy to announce that our first “official” strategy maintainers are none other than GitHub! You can say hello to the official GitHub OmniAuth strategy and be sure that any changes to the GitHub API will be safely transitioned into the gem immediately. My hope is that going forward many more companies will join the official strategy ranks. If you’re interested in maintaining an official strategy, you don’t need my permission but I’d love to hear about it so shoot me a message on GitHub.

Where’s That Strategy?

Because of the structural changes to OmniAuth not all existing strategies are available at launch. I fully expect that in the coming weeks the strategy count will regain lost ground and even surpass the count as of the last 0.x release, but if your favorite strategy is missing from the official list here’s what you can do about it:

1. Find the source code for your strategy in the 0-3-stable branch
2. Clone omniauth-contrib and add the strategy there
3. Follow the strategy adaption guide to update the strategy for 1.0
4. Submit a pull request!

The omniauth-contrib repository is a temporary repository for strategies that have been written but aren’t robust and supported enough to have their own gem yet. This repository is not going to be maintained as an actual RubyGem and the strategies contained inside are meant to eventually be adopted by developers to become their own gems.

One More Thing

One last thing that I wanted to do for 1.0 is create a kind of living example that the community could update to have a simple example of as many strategies as possible. You can now visit omniauth.org and try out a number of authentication strategies that OmniAuth has to offer. The code is all open so you can see how simple it is to add and use OmniAuth in your applications today!

Welcome to 1.0

OmniAuth 1.0 marks an important milestone for the project and I’m looking forward to a new, leaner trajectory that lets us make changes more nimbly (and keeps the outstanding issue count low to zero). While the changes for 1.0 were mostly written by me, OmniAuth has been an outstanding community effort and it couldn’t have gotten to where it is today without the efforts of @sferik and countless other contributors. I hope you enjoy the new release and look forward to hearing your feedback!

Hire a Guard for Your Project

Of all of the new tools that I’ve picked up using for development in the past six months, there is one that has come to stand above the others for its nearly universal utility. That tool is Guard.

Guard is a RubyGem but don’t let that fool you into thinking it’s only useful for Ruby projects. Guard is essentially an autotest for everything. It provides a general purpose set of tools for watching when files are changed in your project and taking action based on it. You can use it to do just about anything, but common uses will include:

• Re-running automated tests after a file changes.
• Automatically compiling scripts or assets for a project (e.g. minification).
• Installing new dependencies that may be added to the project.

With a little creativity and a slight bit of Ruby coding, though, you can make your entire project’s workflow run smoother and faster. It’s like having a telepathic robot buddy who just goes around doing whatever you were about to do next without having to be told (except the first time).

Getting Started With Guard

Guard requires a basic Ruby setup. Once you have Ruby and RubyGems installed, simply run:

gem install guard

This will get you started. If you want to make it easier for others to run your guards as well, you should also install Bundler to encapsulate the different guard gems you’ll be using:

gem install bundler

Once you have these installed, in the root of your project run:

guard init

This will initialize a Guardfile in the project root that will be telling Guard what to do going forward. From here, you will want to install some of the Guard extension gems that let you quickly create automation for your project. Some of my favorites:

• guard-rspec: Automatically run RSpec tests based on easy-to-customize patterns. I use this on almost every Ruby project these days.
• guard-coffeescript: Compile Coffeescript into Javascript lickety-split. Even though Coffeescript has its own automatic build command with the -w option, I prefer Guard because it lets you define the configuration once and, in addition, run a single process for all of your project’s automation.
• guard-process: This is the guard for anything they haven’t made a guard for yet. Using this you can quickly and easily run shell commands as soon as files change, giving you the ability to do almost anything.
• guard-sass: Never write vanilla CSS again. Using Guard SASS you can automatically compile SASS giving you the full power of mixins, variables, and more for all your styles.

There’s a full list of guards that include all kinds of magic (there’s even guard-livereload that can automatically refresh your browser whenever you make a change to a project), and it’s dead simple to create new Guard libraries if what you want isn’t available (or you can just use guard-process).

Standing Guard

For any of the Guard gems you install, you can add them to your Guardfile by running:

guard init guardname

Where guardname might be rspec or coffeescript, etc. That will fill your Guardfile with a basic implementation of the given guard and is usually enough for you to tweak the settings to your liking without further documentation.

There’s a great example of using Guard for a big Rails project, but I’m not just using it for Ruby. I’ve used Guard on jQuery plugins, Node.js projects, even static websites that I’ve been building (more on that a little later).

To make it easier for others to jump into your project with Guard, it also helps to use Bundler to maintain a Gemfile that points to the various guards you’re using for the specific project. Just run bundle init to get Bundler up and running then edit the file to look something like this:

source 'http://rubygems.org'

gem 'guard'
gem 'guard-coffeescript'
gem 'guard-process'

Then run bundle install. Once your gems are installed and you’ve set up your Guardfile, just run:

bundle exec guard

Guard will start up right away and your project now has some smooth automation action. Guard will even reload itself if you modify the Guardfile, so feel free to tweak as you go!

Guard in the Real World

I’m going to post just a couple examples of Guardfiles I’ve been using in my projects recently to give you an idea of its versatility.

Guarding a jQuery Plugin

Here’s the Guardfile for Sketch.js, a jQuery plugin that I just released:

# Automatically build the source Coffeescript into the lib directory
guard 'coffeescript', :input => 'src', :output => 'lib', :bare => true
# Also automatically build the test Coffeescripts
guard 'coffeescript', :input => 'test', :output => 'test', :bare => true

# Run Docco 
guard 'process', :name => 'Docco', :command => 'docco src/sketch.coffee' do
  watch %r{src/.+\.coffee}
end

# Copy the newly created lib file for minification.
guard 'process', :name => 'Copy to min', :command => 'cp lib/sketch.js lib/sketch.min.js' do
  watch %r{lib/sketch.js}
end

# Use uglify.js to minify the Javascript for maximum smallness
guard 'uglify', :destination_file => "lib/sketch.min.js" do
  watch (%r{lib/sketch.min.js})
end

This enabled my workflow to be instantaneous: I could immediately look at my work whether it was in my examples, my tests, or my documentation. Everything was immediately built and I never had to slow myself down with run and refresh cycles.

Guarding a Node.js Project

I’ve probably only scratched the surface here, but a simple Node.js project that I’m currently working on has this for a Guardfile:

guard 'coffeescript', :input => 'src', :output => '.', :bare => true

guard 'process', :name => 'NPM', :command => 'npm install' do
  watch %r{package.json}
end

Notice that using guard-process I’m automatically installing new dependencies that may arise when the package.json file is altered.

Guarding a Static Website

I’ve come to really appreciate both Coffeescript and SASS as worthwhile abstractions, so even if I’m building something that’s vanilla HTML I might have a Guardfile like this:

guard 'sass', :input => 'sass', :output => 'css'
guard 'coffeescript', :input => 'coffeescripts', :output => 'javascripts'

These are all basic examples, but that (to me) is the point: Guard is so simple to use and basic that you can drop it in every project you build. I’ve yet to run into something that I don’t want to use Guard on.

Tip of the Iceberg

I’ve been expanding my usage of Guard into, well, everything that I’m working on. Thus far it’s included Ruby, Javascript, and static HTML projects, but if I move on to other things Guard will be coming with me. For instance, I’d love to build a Guard to automatically recompile and run an Android application whenever the XML views change. The possibilities are limitless.

If you’re not using Guard, give it a try on one of your current projects. I think you’ll quickly find immense satisfaction in being able to simply cd into the project directory, run guard, and know that you are completely ready to roll. I’d like to see a Guardfile in every open source project I fork, every client project I clone…Guard is so useful that I simply want to be using it all the time. And that is the mark of a great tool.

Sketch.js: HTML5 Canvas Sketchpads for Whyday

Last Friday I decided to celebrate _whyday by taking a departure from my normal open source path and writing some Javascript (well, technically Coffeescript). So today we’re announcing Sketch.js, a simple jQuery library to enable HTML5 Canvas “sketchpads” for any web application.

Quick and Easy Doodling

Sketch.js allows you to initialize a canvas element as a sketchpad as well as draw with different colors, stroke sizes, and tools (currently only a marker and an eraser). These tools can be accessed programatically or using special links with data attributes. Here’s a basic example:

<canvas id='mysketch' width='400' height='300'></canvas>

<script type='text/javascript'>
  $('#mysketch').sketch();
</script>

That’s all there is to it! The canvas will now be drawable by your users and, thanks to a relatively straightforward API, you can customize it to your heart’s content.

The HTML5 Canvas element is extremely powerful but it can be a bit daunting to get started. I took this as an opportuntiy both to learn it some myself and to provide a drop-in tool for others. Hopefully you find it useful!

Learning on Whyday

I set out on Whyday with the intent of learning a few new tricks. Here’s some new things I tried out:

1. Sketch.js is coded in Coffeescript. I had used Coffeescript before but never its class system or more advanced features. I like it!
2. It’s documented using Docco which has been one of the most straightforward and pleasant documentation experiences I’ve ever had. It also, as an annotated source engine, encourages clean source code.
3. I set up an awesome instant build environment that uses Guard to compile Coffeescript, generate docs with Docco, and minify the JS into a build directory. The workflow worked really well.
4. I tried to do a very little bit of unit testing using QUnit, which was my first major foray into Javascript testing. Unfortunately, with how much I was learning about Canvas at the same time, I didn’t keep at the testing as much as I would have liked.

All in all it was a great chance to sharpen my skills on something that I hadn’t had a ton of experience with. You can see the docs (and live examples) on its GitHub pages or visit the code on GitHub. Enjoy!

What’s Wrong With Patents? It’s Obvious.

Patents are in the news in the tech circle more and more these days. As trolls lurk under bridges and the portfolio cold war gets hotter and hotter, everyone is talking about the fact that something is wrong. What exactly that something is, however, is up for debate. Should the patent system be abolished? What about just software patents? Is the term too long? I don’t know, maybe. But one of the primary issues, from my view as a web startup developer, is that what’s obvious isn’t really so obvious anymore.

Patents were established as part of a way to codify the Constitution’s Copyright Clause attempting to promote science and the “useful arts.” They grant a limited term of exclusivity for inventors in exchange for publishing the means to reproduce the invention. In theory, this is a win-win: the inventor gets to make money off of their invention and the public gets to know how it’s made. Other individuals or companies can even license the right to reproduce the invention before the patent has expired so it may reach even more people than it would otherwise.

I’m not going to get into arguments about whether or not the patent system as a whole encourages innovation in modern times. However, one of the requirements of getting a patent is that it not be obvious to “a person having ordinary skill in the art.” I believe that this requirement is no longer adequately strict for patent issuance due to three fundamental differences between the establishment of the system and today’s field of “inventors”: population, communication, and specialization.

Matters of Population

There are more than 300 million people in America, more than 100 times as many as when the country was founded. That means that for any given “art” there’s a great number more people in any particular field than there used to be. So how does this affect obviousness?

If eight people out of ten couldn’t figure out how to do something, maybe it’s reasonable to let the one out of two that figured it out first get a patent on it. That incentivizes the two that can figure it out to figure it out because there’s a real chance that they’ll break ground first and make some money off of it.

So let’s increase the field’s population a bit. Now let’s apply the same ratio to an invention but there’s 1,000 people in the field. That means that 800 out of 1000 would find it non-obvious, but 200 out of 1000 would. A person of “ordinary skill in the art” still would allow the patent to be issued, but now we’re talking about 200 separate people who would find it obvious. This isn’t inherently a problem if all inventions existed in a vacuum, but most often patented ideas (especially in software) represent only part of a larger vision or system. That means that because one out of 200 people happened to register for a patent first, their larger system is in the clear while 199 others that could be solving totally different problems but using the same invention as a part of their larger vision are now in jeopardy of owing licensing fees or being barred from pursuing matters entirely.

In modern America any given field will have tens of thousands of people all working, collaborating, and inventing. To posit that the standard by which exclusive, multi-year rights to something should be given to something that’s non-obvious to the average person doesn’t ring true. It should be something unique and groundbreaking enough to be non-obvious to the vast majority of people in the field. To merit exclusivity, it should be something so beneficial that the inventor would fight tooth and nail to keep it secret were the advantages of patents unavailable. Instead, hundreds of patents are issued for mundane, completely foreseeable advancements in the art. Just because something is non-obvious to most people doesn’t make it a breakthrough invention.

Proliferances of Communication

Can you even imagine how things must have worked back in the late 18th century? What would it have been like to be a scientist, a researcher, an inventor? Compared to the always-on global communications networks that researchers, engineers and inventors have today it’s an entirely different world. Lots has been written about how the world is “shrinking” as both travel and communication between disparate places becomes easier and easier, and the same goes for the inventive communities who are churning out patents.

This readily available communication has the effect of making all participants in a field effectively smarter than they would be otherwise: if I don’t know how to do something, I can just Google it and now I do. This has implications again for the consideration of the “obviousness” of patents. Are many of the things patented today non-obvious to a person of average skill in the art with access to the internet? I’m not so sure.

Especially Specialized

Over the course of our society’s development we have gone from an agrarian society to an industrial one and now to an informational one. The level of specialization found in the modern creative force makes it pretty difficult to tell exactly who should be considered a person with “average skill in the art.” As a disclaimer, I’m not actually sure how the courts currently make such decisions, but it surely is a more complicated question than it used to be. Where do we draw lines of separation for the “arts”?

Is the peer group for a new mobile device patent other mobile device engineers? Is it other device engineers? All electrical engineers? I’m not honestly sure how you would draw that distinction and where you draw the line will drastically effect the determination of average skill in the art.

Abandoning IP

So what is to be done about the patent problem? Well, my guess is that the growing tsunami of patent litigation is going to lead to some kind of change in the law. The current situation is pretty untenable, and I think it’s only going to become more so. Something big will break loose in the next few years and I think the landscape is going to change dramatically.

There are multiple fronts on which the current patent system seems to be at odds with proper innovation, and one of the biggest problems in my eyes is that it is only larger, heavily established and heavily funded companies that are even trying to get patents. You don’t see garage startups wasting their time trying to eke out software patents: they’re too busy building. It’s not until a company is big enough that it can afford to split its focus and hire patent attorneys and do what is necessary to start “protecting” its IP. That bothers me, because it’s propping up a system of innovation where only the big established players have a chance to exclusivity on their “inventions,” and in my mind those are the people who need protection the least.

Technology moves orders of magnitude faster than it did in “the old days” and I’m not even sure where patents fit anymore. 18 years is several lifetimes by current standards of advancement, and to lock up a technology for that long is equivalent to locking it up for the entire span of its usefulness.

Coming from an open source software advocacy background, patents seem like a greedy, antiquated version of what thousands do every day for free: sharing their technology with the world for the benefit of everyone (the creator included). In a world where everything can change in a matter of months, I think it’s time to stop worrying about protecting IP and time to focus solely on creating things of lasting value. Don’t keep your competitors from using your innovations, just make newer and better innovations that outpace them.

Ruby Thankful

A lot has been made in the talkosphere recently about the brewing “multi-Ruby version manager” war, namely RVM vs newcomer rbenv. I’m not here to discuss the relative merits of either software solution, mostly because I take things pretty simple and straightforward in command-line world and I’ve never run into problems with RVM. What I do think this little fracas displays, though, is a common thread in the Ruby community of having big, blown-up controversies when new things come along. In some ways, I think that such drama is one of the unique features of the Ruby community that make it so vibrant. It’s also a feature of the community that can lead to community casualties.

RVM vs. rbenv, Test::Unit vs. RSpec, HAML vs. ERB, Rails vs. Merb, Coffeescript vs. Javascript, Mongrel vs. Thin vs. Passenger vs. Unicorn, Cucumber vs. Steak, and the list goes on. It seems like the Ruby community has a habit of drawing battle lines every month or so. Why do these “fights” come up so frequently in our community? More importantly, what do they mean for the overall health of the community?

Today we’re launching a little site called RubyThankful. It’s barebones at the moment and open source, but what it represents is hopefully a way to find some positivity in the Ruby community.

Background: Passionate Programmers

I would argue that controversy breaks out on a regular basis in the Ruby community because, more than any other community in which I’ve participated, Rubyists are singularly driven to use not just good-enough tools but ideal tools. Ruby is a community of chaotic reinvention, a community that will jump off a cliff just to try out a new brand of parachute. It’s that passion that draws me to the community, that makes me feel like the things that I do matter. It’s also that passion that can cut to the bone.

People are inevitably going to form opinions about what they think is the best in a field of competing libraries/tools/products. This competition in the commercial marketplace is what drives high quality and low prices, and in the open source world it’s what drives reinvention and continual progress. If a library isn’t pushing its users forward, those users can and will seek out a different library that better meets their needs. This is natural and generally beneficial.

What isn’t maybe so beneficial is the “what have you done for me lately” attitude that can come with our pursuit of the perfect development process. It’s altogether too easy to write about reasons why “Y is better than X” while forgetting about the fact that before that, X was so much better than nothing at all.

Casualties of Harsh Reality

As I began to write this post I saw Steve Klabnik’s We Forget That Open Source is Made of People. It’ll be hard not to re-iterate many of his well-reasoned thoughts here, so I want to give him credit for making a point that needs to be made. I was also amazed to come against this controversy just one day after I wrote a post that included the sentence “Harsh words can sometimes be enough to completely dissolve the creator’s interest in continuing the project.” We’ve lost amazing members of this community because rather than respecting their contributions we tear them down when something marginally better comes along. This is the dark side of passion.

I like some tools better than others. I’ve even written blog posts debating the merits of one approach over another and declaring one superior for my purposes. I’ve been guilty of jumping onto new technologies and giving nary a thought to the old way of doing things. I don’t think it’s possible to stop this community from being obsessed with the new and different, and I don’t think that’s what needs to happen. What needs to happen is that our community needs to get better at raising our voice in something other than protest. We need to temper our enthusiasm for the new enough to at least be civil to the hard-working people who created the tools we used until oh-so-recently.

I’m as guilty as anyone of this. Short of trying to say “thanks” in person to the creators and maintainers of the tools I use every day when I see them at conferences, I don’t take much time to thank people for the amazing things they’ve done to make this community what it is. This all sounds sappy and somewhat inefficient, but I think it’s a vital piece of maintaining a healthy community.

Ruby Thankful

I almost wrote this just as a blog post to say “hey, let’s be more positive and thankful.” I was just about to post it when I realized I could do at least a little bit more than that. So I built an almost-nothing-to-it site that can serve as a public forum for the Ruby community’s gratitude for those who work hard to make it what it is. Just tweet something with the #rubythankful hashtag and it’ll get picked up. Maybe it’s someone you’re thanking for a library, or their blog post or tutorial that helped you out, maybe it’s something else. If you’re thankful for the Ruby community and the members of it, let’s put some voice out there!

This community has given me a lot in the last four years, and I’ve done my best to give back. But I haven’t always been thankful enough to the individuals who create the things that I use every day. Hopefully RubyThankful is a small way to encourage that to change.

10 Tips For Open Source Citizens

This post is part of a series called Open Source Citizenry in which we discuss ways to eliminate the barriers that developers and companies face to fully participating in the open source community.

You might think there’s not really anything to being a good user of open source. Install the library, use it how you need it, and move on. And honestly, for the most part that’s a fine thing to do. But if you want to be more than one of the silent users, if you want to help the projects you use just by using them, there are lots of ways to do it. You could become a vital part of pushing forward your favorite open source projects without ever altering a single line of code.

1. Get Involved. This is the obvious first step: participation. Start building a presence on the mailing list, bug tracker or other community resources for your favorite open source projects.
2. Respect the Gift. Remember that even when an open source library is causing you frustration that this is something that someone else built and released, free of charge, to try to help developers like you. Do your best to always stay civil and keep your comments constructive. Nothing takes the wind out of an open source project’s sails faster than harsh criticism. Harsh words can sometimes be enough to completely dissolve the creator’s interest in continuing the project.
3. Respect the Resources. By and large open source developers aren’t getting paid to maintain libraries full time. If you feel like a project is too slow-moving, maybe there’s a way that you could help free up the creator’s time to get more done on the project (see tips 5-9).
4. Respect the Chaos. If messages get lost in the shuffle, if an issue goes ignored for too long, bring it up again but do so cordially. There are often far more moving parts to popular open source libraries than anyone can perfectly keep track of at all times. Open source is, to some extent, a system of organized chaos, and you can’t reap the benefits without also sometimes experiencing the drawbacks.
5. Become Community Support. If you’re a long-time user of a library and you know the ins and outs, it can be life-saving to project maintainers to have someone else answering basic questions on mailing lists and bug trackers. One of the hardest things about maintaining an open source project is keeping up with the sheer volume of communication that has to take place, and if you can ease that burden the project owners can focus more on code and less on support.
6. Add Documentation. Many projects will have some kind of community documentation or wiki that can be modified straight from the browser. If you just did something interesting with the library or ran into a gotcha, document it on the wiki! If you know how to use a relatively obscure part of the libary, write it up! Every time someone can be pointed to a page on the wiki (or find it themselves) instead of asking the maintainer gives the project more time for development.
7. Write Blog Posts. Even if a library doesn’t have a wiki, you can still blog about your interesting applications or a quick-start guide for various scenarios. These articles are often great teaching resources for people new to the project and can help immensely. If you do blog about a library make sure to let people involved with the project know either by a friendly message to the mailing list or by adding it to a wiki/community documentation system.
8. Moral Support. Open source developers are people too, and one of the best ways to motivate them to keep going is to let them know that their work is appreciated. If a library saves you hours of work, send the project maintainers a note letting them know how much it helped. Knowing that a project is useful to others is a big motivator towards continued development.
9. Thorough Issue Reporting. You will, of course, sometimes run into problems with an open source library. When you do, try to make the bug report you submit as detailed as possible, including stack traces and code snippets wherever possible. The fewer back-and-forth conversations you need to have for the maintainers to understand your issue the faster they will be able to find a solution.
10. Become a Contributor. Of course one of the best ways to be a user of an open source project is to become a contributor to that project! Open source should be a vital piece of the professional experience of any software developer. Contributing patches to libraries you use every day is a win-win for all involved and not nearly as hard or scary as it might seem.

Ultimately, being a good open source citizen is about respecting what open source is, how it’s made, and how you can help. Open source software is made by many; that’s its beauty and its curse. If you can help bring more order to the naturally chaotic development process by adding documentation, fielding support requests or even just encouraging maintainers to keep going, you are becoming a vital part of the open source ecosystem and helping it to grow.

Setting Up a Ruby Development Machine From Scratch With OS X Lion

Every so often I like to completely wipe out my computer and start it over from scratch. This isn’t because I particularly enjoy the pain of setting up a system from scratch, but it does come with some advantages:

• You get rid of the stuff you didn’t need.
• You have a chance to try things that came out since you last reinstalled.
• You have a clean install that isn’t choking from years of cruft.

I took it upon myself to perform this task when I upgraded to OS X Lion and thought it would also be a great chance to write one of those “how to get a Ruby development machine going from scratch” posts since that’s what I’d be doing anyway. So here’s the process of how I got my machine set back up to work the way I want it to on Apple’s latest.

Application Avalanche

	Google Chrome has been my browser of choice for the past year or so. I never would have thought I could give up Firebug, but the speed difference was enough for me to learn to love the Web Inspector.
	iTerm2 is new to my roster. I don’t know too much about it other than that it can do split-pane views which is something I love in all of my apps.
	XCode is a big huge download, and while I don’t use the IDE I need the build tools for just about everything else in my dev toolchain.
	Adium is my universal IM client of choice. It’s simple, customizable, and always there when I need it. I roll with the AdiumIcon icon set, the Mnmlsm message style, and the Leopard Sidebar contact list style.
	Mailplane gives me exactly what I want in an email client: the GMail web interface but in its own dedicated application. While the benefits over something like a Fluid window for GMail aren’t necessarily enormous, email is core enough to my daily routine that it was worth a little cash for a little better experience.
	MacVim is my editor of choice although I don’t pretend to be a “real” Vim user. I switched to Vim *solely* because it allows me to edit with split pane windows, and I still treat it more like Textmate than I’d normally like to admit in public. Note: If you’re planning to use ZSH you’ll want to install a snapshot release of MacVim, otherwise it will occasionally hang.
	Growl is an obvious must-have for any Mac user, developer or not.
	Presently and HipChat are my desktop coworker communication tools and I’d be lost without them.
	Alfred is another new addition to my roster, replacing the Google Quick Search Box. I haven’t used it much yet, but I had heard good things so I’m going to give it a go.
	VLC has a well-deserved reputation for being able to play just about everything. If I could remove Quicktime entirely and replace it with VLC, I would.
	Spotify is what I’ve been using the last week or two. I’ve tried both it and Rdio and I’m honestly pretty torn as to which I like more. But let’s be honest, my primary listening point for music recently has been Turntable.fm.
	The Official Twitter App is the client I’ve used since its release. I’m not a power user (and all of the searches that I care about I handle via Twilert so it works well enough.
	Cloud is an extremely useful little app to have for quickly sharing screenshots and files. I use Skitch as well when I need to be able to annotate the shots quickly.
	Adobe CS5 gives me the tools that I need for putting together logos and design assets. I was going to say “and mocking up sites” but since CSS3 I don’t really use Photoshop for mockups that often these days, I just go straight for the markup.

Command Line Commando

Once I had gotten the easy stuff out of the way, it was time to actually set up all of the development tools that I would need to get my machine up and running the way I needed it.

First up is installing Homebrew. Homebrew is without a doubt the simplest and most “it just works” package manager that I’ve used for OS X. Installing it is as easy as:

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

Once Homebrew is installed, we can go on a mad tear of package installation. Here are some of the tools that I set up right away:

brew install wget git redis node imagemagick
brew install postgresql
brew install mongodb

Another new entry for this round, I thought I’d take my coworkers advice and switch to ZSH with Oh My ZSH. Installed like so:

wget --no-check-certificate https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

Next up we’ll install RVM so that we can manage multiple Rubies with ease. I’ll also be installing the Rubies that I use on a regular basis and setting the default Ruby to be 1.9.2 since that’s what I’m using 90% of the time.

bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
rvm install 1.9.2
rvm install jruby
rvm use 1.9.2 --default

After that I needed to follow the instructions printed out by RVM to make sure it was working in my shell. Magnificent! Now we’re almost all done with our basic development stack. We need something to run our web apps, and Pow is definitely my favorite nowadays. We’ll also install the powder gem to make it super simple to manage our Pow links.

curl get.pow.cx | sh
gem install powder

Now I’ve got my development tools up and running, but I still need a little bit more out of my editor. Like I said, I’m a training wheels Vim user, so I like to install Yehuda/Carl’s janus to get a good set of Vim plugins that make Rails development super easy in MacVim.

curl https://raw.github.com/carlhuda/janus/master/bootstrap.sh -o - | sh

We’re getting quite close now. The only thing to do before enjoying my new setup is to make it so that I can clone my repositories off of the various services I use. So I followed the GitHub, Unfuddle, and Heroku setup instructions and I was up and running.

Summary

So that’s pretty much it! Everything went pretty much as expected once I actually got a fresh-drive install of Lion working. The biggest pain was waiting for multi-gigabyte downloads like XCode, but leaving them overnight worked well enough to solve that. So for those who are curious, Ruby development is alive and working on Mac OS X Lion. Is there anything in my setup that you’d do differently? Let me know in the comments!

What if Rails Isn’t For Beginners Anymore?

There’s been a lot of controversy surrounding the changes to Rails 3.1. It started with an epic GitHub commit thread and the discussion exploded again in the past few days after What the Hell is Hapenning to Rails and Yehuda’s response thereto. I’m going to address the issue from a perspective that honestly hadn’t even occurred to me until I just said it while in a conversation with some Kansas City Ruby folks after the last meetup: “What if Rails isn’t for beginners anymore?”

Rails gained its popularity on the strength of its simplicity. The 15-minute blog was a shockingly powerful demonstration of what the framework could do, and from there it has gained thousands upon thousands of dedicated developers. But that’s just the thing: now it has thousands of dedicated developers. And these developers are building some of the most powerful and advanced web apps anywhere on the internet. It’s only natural that as the needs of the community grow so too does the framework. What we may be seeing is a point where Rails is becoming the tool for Ruby web experts instead of Ruby web novices. But if that’s true, is it necessarily a bad thing?

I built RailsWizard as part of the Rails Rumble last year and I thought it would be a tool that would serve two purposes: help me quickly spin up new apps I’m working on and also serve as a step-by-step guide for novice developers who need to get started building a Rails app. However, two rewrites later RailsWizard is a tool that is incredibly fast for my purposes but almost incomprehensible to anyone who doesn’t know what they’re doing. The tool evolved to focus on power for experts rather than friendliness for novices. Ultimately that’s the decision that has to be made for any tool or website: how much tradeoff are you going to give between making something easy to pick up and efficient for experts?

Since my livelihood depends on being able to rapidly build advanced web applications using Rails, you won’t see me beating the drum to take away power from Rails for the sake of novice ease-of-use. In fact, I’m beginning to wonder if Rails is the wrong place to get people started with Ruby web development anyway. There’s always been the problem of people who are Rails but not Ruby developers because ActiveSupport and the facilities Rails give you can make it hard to know what’s stdlib and what isn’t. If people learned Sinatra first, or if the community rallied around a “slightly more than Sinatra” framework like Padrino for newcomers and built up the requisite tutorials and documentations for 15-minute blogs and other things, then the novices who cut their teeth on those tools can come to Rails when they actually understand the power that Rails gives them as developers. They will understand Rails better because they have begun to stretch the limits of the lightweight frameworks and they need more. Maybe a system like that would make for better Ruby and Rails developers.

I’m not saying that any of this is necessarily true, but I think it’s another facet of the debate that hasn’t been explored yet. Personally I love the changes that have been coming to Rails. The asset pipeline may be the most important addition to Rails since even before 3.0: it is a game-changing piece of technology that has been a long time coming. I think the Rails core team has done an incredible job of pushing the envelope and refusing to remain complacent. And I think that’s important, probably more important even than beginner friendliness. Because if Rails gets complacent, if the core team stops pushing out into the weird and uncomfortable, then five years from now nobody will be using it because something better will have come along. And I like Rails.