Brian Cardarella's Blog

Clean up trailing whitespace

Tue, 09 Aug 2011 03:16:00 -0400

One line command to clean up the trailing whitespace for a given project:

find . -name "*.rb" -type f -print0 | xargs -0 sed -i '' "s/[[:space:]]*$//"

This command will search for any files with the “rb” extension (Ruby files) and remove all trailing whitespace. This works in OSX, the command syntax might be different in Linux. Run this command from your project’s root.

The State Open Source Development

Sun, 24 Jul 2011 14:25:00 -0400

My thoughts on the subtext of dealing with some open source project maintainers

Every pub and cafe should have free wifi and power.

Wed, 29 Jun 2011 10:17:00 -0400

Getting a cable connection and sharing over wifi with your customers is a great way to not only have customers all day long but repeat customers. But the real reason why every pub and cafe should today install free wifi is because in a few years they won’t need it and they need to learn how to sell to the customers who can “work from anywhere”.

Tethering is awesome

With my Android I tether my MacbookPro over 3G. Most of the time the connection is crap and slow and I’m afraid of data usage but for the most part it gives me the freedom I want. 10 years from now I fully expect my MacbookPro Air (please?) to have a multi-mode network card that does wifi and Wimax or LTE (or something better). With a national subscription plan I could connect anywhere I want in a similar fashion to my iPhone. But we don’t even have to wait 10 years for the speed. 4G phones are here. Batteries and power consumption is getting better. On a single charge my MacbookPro can get 4 - 5 hours doing just software development. Being able to plug in is nice but becoming less necessary. (but still necessary today)

Pubs and cafes need to learn how to deal with remote workers

So now that the world is almost my office I will be able to pick and choose which pub or cafe I want to work at. I’ll no longer be limited to Starbucks and Panera bread. I’m going to choose the place that has the food I like, the beer I prefer or the working environment I’m most productive in. If pubs and cafes were smart they would learn how best to accomodate this class of worker today by providing free wifi. A small investment today would go a long way to getting ahead of everybody else tomorrow.

Panera Bread (I’m assuming most people are familiar) recently put restrictions on their free wifi. During peak hours it is limited. Someone might use this to claim that free wifi actually harms business. The reasoning is that most of the people there just hang out all day, some might actually bring their own food. Well, if you were in the desert wouldn’t you expect everybody to be hanging around the oasis? If there was more access at more locations everybody would be more spread out. Businesses should be competing for those potential customers not looking at them as moochers. Getting people to just walk through the door is difficult. Keeping them there for hours is impossible. The business that can figure out how best to sell to these remote workers is going to do very well in the years to come.

ClientSideValidations for Rails 3.1 and 2.3.x backport

Mon, 20 Jun 2011 17:17:00 -0400

Today I’ve made two new releases: ClientSideValidations v3.1 for Rails 3.1 and a backport of ClientSideValidations for Rais 2

ClientSideValidations v3.1

ClientSideValidaitons for Rails 3.1 adds the javascript file to the asset pipeline. So you no longer need to run the install generator for each update. Just serve up rails.validaitons.js in your application.js file:

//= require rails.validations

And that’s it! Other updates:

Rails 3.0 support will continue in the 3.1 version of ClientSideValidations. But for legacy support the 3-0-stable branch will also be maintained.
Formtastic 2 support. If you want Formtastic 1.x support please use ClientSideValidations 3.0.x. Formtastic 2 is required when using Rails 3.1

ClientSideValidations-Rails2

This is a new gem that provides some validation reflection to ActiveRecord 2.x models. It will use the ClientSideValidations 3.0.x series gem.

ValidAttribute 1.0

Sun, 12 Jun 2011 13:46:00 -0400

I just released ValidAttribute 1.0 So what is ValidAttribute and why should you be using it?
See the README for installation information.

I grew frustrated with how I was writing the specs for my models. Very often I found myself doing this:

describe User do
  it { should validate_presence_of :name }
  it { should validate_length_of :name, :is => 5 }
end

This felt wrong. I was duplicating the effort of writing the validations in the spec, the implementation of how these validations worked was now tied to the spec. My specs shouldn’t care about what validations my model is using. The only thing my specs should care about is if a given value is valid or invalid under certain circumstances. So I wrote out a simple DSL of how I wanted this to work:

describe User do
  it { should have_valid(:name).when('Brian') }
  it { should_not have_valid(:name).when(nil, '', 'Ed') }
end

This felt much better. Now my specs do not care what validations I have declared on my model just as long as the values I provide are valid or not. I have been using this simple matcher for a few months and have found it provides a nicer BDD process than Shoulda or Remarkable. In fact, it is all I use to test my models now. (I won’t get into why specing your relationships in models is a waste of time)

So what about other validations like uniqueness and confirmation. It is pretty simple:

describe User do
  context '#email' do
    before { Factory(:user, :email => 'test@test.com' }
    it { should have_valid(:email).when('brian@test.com') }
    it { shoud_not have_valid(:email).when(nil, '', 'abc', 'test@test.com') }
  end

  context '#password' do
    before { subject.password_confirmation = 'password' }
    it { should have_valid(:password).when('password') }
    it { should_not have_valid(:password).when(nil, '', 'badpassword') }
  end
end

ValidAttribute also works with Test::Unit. You need to be using thoughtbot’s shoulda-context:

class UserTest < Test::Unit::TestCase
  should have_valid(:name).when('Brian')
  should_not have_valid(:name).when(nil, '', 'Ed')

  context '#password' do
    subject { User.new(:password_confirmation => 'password') }
    should have_valid(:password).when('password')
    should_not have_valid(:password).when(nil, '', 'badpassword')
  end
end

ValidAttribute is compatible with any ActiveModel based model. It also supports ActiveRecord 2.x and Datamapper. In fact, as long as your model responds to #valid? and #errors you can use ValidAttribute. See the README for more information.

ValidAttribute Vs Shoulda’s #allow_value

Shoulda has a method its matchers depend upon called #allow_value which provides something similar to ValueAttribute. Here is the difference:

describe User do

  # ValidAttribute Syntax
  context '#email' do
    before { Factory(:user, :email => 'test@test.com' }
    it { should have_valid(:email).when('brian@test.com', 'brian+blog@test.com') }
    it { shoud_not have_valid(:email).when(nil, '', 'abc', 'test@test.com') }
  end

  # Shoulda's #allow_value Syntax
  context '#email' do
    before { Factory(:user, :email => 'test@test.com' }
    %w{brian@test.com brian+blog@test.com}.each do |email|
      it { should allow_value(email).for(:email) }
    end
    [nil, '', 'abc', 'test@test.com'].each do |email|
      it { should_not allow_value(email).for(:email) }
    end
  end
end

#allow_value only takes one value, and the wording feels backwards.

To accomplish the same task #allow_value needs to iterate over a collection of values and inject each into the matcher. ValidAttribute can take any number of values. Clean code is very important to me.

Here is another example:

describe User do

  # ValidAttribute Syntax
  context '#email' do
    before { Factory(:user, :email => 'test@test.com' }
    it { should have_valid(:email).when('brian@test.com', 'brian+blog@test.com') }
    it { shoud_not have_valid(:email).when(nil, '', 'abc', 'test@test.com') }
  end

  # Shoulda's #allow_value Syntax
  context '#email' do
    before { Factory(:user, :email => 'test@test.com' }
    it 'should have valid email' do
      %w{brian@test.com brian+blog@test.com}.each do |email|
        subject.should allow_value(email).for(:email)
      end
    end
    it 'should not have valid email' do
      [nil, '', 'abc', 'test@test.com'].each do |email|
        should_not allow_value(email).for(:email)
      end
    end
  end
end

In this 2nd example the iterators for #allow_value are inside of an ‘it’ block. If the validators have not been implemented yet ValidAttribute will give you a failure message containing all the values that caused a failure. Shoulda will stop on the first value.

The Github Follower Problem

Wed, 01 Jun 2011 12:47:00 -0400

Github is awesome. I think most people agree. They have proven the concept of “social coding”. The big flaw in this plan is Github’s relationship system.

Following people on Github is easy. I see somebody interesting, I click follow. The problem is that now my news feed will get every single commit, message, etc… this person does. After following a few active people my feed turns into noise and becomes useless. I used to follow up to 100 people on Github, and over 200 projects. I have since unfollowed all but a handful and only follow maybe 5 projects. I’m very interested in knowing what is happening in Rails core so my news feed is now very useful.

So the way I see it there is very little incentive to follow people on Github. In fact, because of the news feed issue I feel almost penalized for following somebody. In return I’m sure others feel the same way. This would not be a problem if it weren’t for Github search.

Github is becoming a great place to find new talent. If you are a contract developer being found easily if very important. So if I search for all Ruby developers in Boston, MA I get a result that is ordered by number of followers descending.

Ah ha! Now the number of followers I have becomes very important.

I’m not suggesting people start gaming Github. But it would be nice if there was more incentive to following people than just cluttering your news feed.

Searching by the exact city match is also not very useful. A good number of Ruby devs live in Cambridge, MA but I can’t search for “Cambridge, MA” only “Cambridge” which also returns “Cambridge, UK”. It would be nice if I could search for Boston, MA and Github did a proximity search. Maybe 5 miles?

Update: Apparently if you search by “Cambridge_MA” you’ll get what you want. Strange.

We choose not to go back to the moon...

Tue, 31 May 2011 16:26:00 -0400

We choose not to go back to the moon. We choose not to go back to the moon in this lifetime and not do the other things, not because they are hard, but because they are expensive, because our goals are now self-serving, because the challenge is one that we are unwilling to afford, one that we are willing to postpone, and one which we intend to ignore.

Sad, but true…

Exploring Rails 3.1 - ActiveModel::SecurePassword

Sat, 16 Apr 2011 16:46:00 -0400

Rails 3.1 will have password encryption baked in via ActiveModel::SecurePassword. Any ActiveModel based model will get this functionality. (ActiveRecord, Mongoid)

Your model will need a field called password_digest and then you’ll need to activate secure password:

class User < ActiveRecord::Base
   has_secure_password
end

You get a few things from this

attr_accessor :password
confirmation validator on password
presence validator on password_digest
when password is set password_digest is encrypted using bcrypt-ruby
#authenticate takes one argument of an unencrypted password. The unencrypted password will be encrypted and compared to the password_digest. If the two match self is returned. If the match fails false is returned.

You don’t get any validators on the password accessor. While there is an indirect validator with the presence validator on password_digest this won’t work for your forms. You may want to add one:

class User < ActiveRecord::Base
  has_secure_password
  validates :password, :presence => { :on => :create }
end

Now you can authenticate in your controllers like so:

class ApplicationController
  helper_method :current_user, :user_signed_in?, :user_signed_out?

  def current_user
    if session[:user_id]
      @current_user ||= User.find(session[:user_id])
    end
    @current_user
  end

  def user_signed_in?
    !!current_user
  end

  def user_signed_out?
    !user_signed_in?
  end
end

class SessionController < ApplicationController
  before_filter :user_signed_in?, :only => [:delete]

  def create
    if user = User.find_by_email(params[:user][:email]).try(:authenticate, params[:user][:password])
      session[:user_id] = user.id
      redirect_to root_path # Or whatever you want i.e. redirect_to user
    else
      render :new, :flash => { :error => "bad email/password combination" }
    end
  end

  def delete
    session.delete(:user_id)
  end
end

Setting cookies in the new Capybara

Tue, 12 Apr 2011 17:31:47 -0400

Getting access to the cookie_jar is different for the new Capybara (the one that will have the acceptance test DSL)

You’ll want to add a helper to spec/acceptance/support/cookie_helper.rb

def cookie_jar
   Capybara.current_session.driver.browser.current_session.instance_variable_get(:@rack_mock_session).cookie_jar
end

Now you can access the cookies at any time:

#in some scenario
cookie_jar[:remember_token] = 'testtoken'

Why I love Rails and Github

Sun, 10 Apr 2011 19:37:00 -0400

Today a pull request to r\Ruby on Rails was opened. In short, it added a few methods that allowed an alternative use of Array#include? I happened to notice that Jose Valim commented on it in my Github news feed, so I checked it out. I weighed in as I questioned the necessity for the added methods. Others began to weigh in too, and in short time we had a good conversation going.

Other language or framework communities might dismiss this type of conversation as a waste of time. The culture of Ruby, and more so Rails, demand it. And Github allows the community as a whole to participate in it. Days like today are days that I’m happy to be a Ruby developer.

valid_attribute

Mon, 04 Apr 2011 22:02:00 -0400

valid_attribute on Github

I’ve been writing model tests for years. Like most I started out with Shoulda which was great. As I moved over to RSpec thankfully Shoulda moved over as well.

After a while I began to hit some walls with Shoulda, specifically when I wanted to use some of the matchers for non-ActiveRecord models. I previously wrote a gem called remarkable_mongoid that provided relation and validation matchers for Mongoid. I originally wanted to use Shoulda as it was my library of choice but the ActiveModel validators were part of the Shoulda ActiveRecord set. So I refactored Shoulda to separate the ActiveModel validator matchers from the ActiveRecord validator matchers. Unfortunately it never got any attention. (I’ve since deleted my local repo) I decided to go with Remarkable which had the validators properly separated.

My views on model testing have shifted since I wrote remarkable_mongoid. Specifically I think relation matchers are crap. At the time I thought the same of validation matchers. My problem with validation matchers wasn’t with the necessity of them but how they were being implemented. Shoulda and Remarkable had similar APIs for how their matchers worked. Their validation matchers feel too tightly coupled with the implementation of the validations themselves. I would find myself writing a spec and a model like this:

I don’t know about you, but this feels like a unnecessary duplication of effort. And this morning I just about had it. So I spiked some code and came up with valid_attribute The same validations from above would work like this:

Now when comparing these two examples it might not be immediately obvious on the advantage of valid_attribute. But lets look at it from developing with BDD.

I want to create a Company model, and I’m going to test first. I’ll start by describing valid and invalid criteria. Then add the necessary validations to make the tests pass.

But now I need to add some more validations to the password attribute.

So we don’t add any more matchers, only update the acceptable values. When I am testing my models I care about asserting that certain data is valid and other data is invalid. valid_attribute makes this dead simple to do just that.

I also do not think having a #.not_with method on the matcher makes any sense. RSpec already has should_not. And it should be used rather than passing false values to a matcher that expects to return true.

Client Side Validations 3.0

Wed, 30 Mar 2011 13:02:00 -0400

client_side_validations on Github

The README and the Wiki are very detailed. Please check them out as well!

Client Side Validations 3.0 is out! Adding client side validations to an existing Rails 3 project is as simple as: (assuming you are already using jQuery >= 1.4.1)

requiring the gem…

  # Your Gemfile
  gem 'client_side_validations'

running the install generator…

rails g client_side_validations:install

adding the rails.validations.js javascript file to your layout
activating in a given form

And it works! Wait… you don’t see anything?

Okay, so by default ActionView::Base.field_error_proc will wrap invalid fields with a ‘field_with_error’ class div. We need to extend this to also show the error message. The generator added config/initializers/client_side_validations.rb You need to uncomment the ActionView::Base.field_error_proc override. Now restart your rails app and presto-changeo you’ve got client side validations!

If you’re using an alternate FormBuilder like like SimpleForm or Formtastic you won’t need to uncomment anything. The error messages will render inline automatically.

Let’s take a step back and look at the goals of this gem:

Project Goals

Follow the best practices for client side validations developed by Luke Wroblewski
Automatically extract and apply validation rules defined on the server to the client.
In the cases where a server-side validation rule would not work on the client (i.e. conditional callbacks like :if, :unless) then do not attempt client side validations. Fall back to the server side validation.
The client side validation error rendering should be indistinguishable from the server side validation error rendering.
Wide browser compliancy. I’ve tested with IE8, seems to work OK.
Work with any ActiveModel::Validations based model
Validate nested fields
Support custom validations
Support custom FormBuilders like SimpleForm and Formtastic
Client side validation callbacks

Breaking these down…

Follow the best practices for client side validations developed by Luke Wroblewski

As Luke points out in his blog post Live Validations (or client side validations) are great for increasing conversion rates. He details how validating after a user exits a field yields the highest conversion rates (as well as the least confusion). Client Side Validations follows this philiosophy.

Automatically extract and apply validation rules defined on the server to the client

ActiveModel in Rails 3 allows us to reflect upon a given model’s validations. Client Side Validations takes advantage of this to package the rules and i18n messages for use on the client.

In the cases where a server-side validation rule would not work on the client (i.e. conditional callbacks like :if, :unless) then do not attempt client side validations. Fall back to the server side validation

Some validations don’t make sense to attempt on the client. Instead of trying to get around this ClientSideValidations ignores these cases with the assumption the server will always be able to handle it better.

The client side validation error rendering should be indistinguishable from the server side validation error rendering

Considering that we’re allowing some validations to pass to the server we need to ensure that how the errors render on a server side must match exactly how the errors render on the client side. To this end Client Side Validations uses the power of jQuery to properly render the error for a given FormBuilder.

Wide browser compliancy. I’ve tested with IE8, seems to work OK

Pretty self-explanatory.

Work with any ActiveModel::Validations based model

As long as your model is using ActiveModel::Validations it should work. This includes ActiveRecord 3, Mongoid 2.0. MongoMapper is in the process of adopting ActiveModel.

Validate nested fields

If your forms have nested fields via field_for all validations should apply without any issue.

Support custom validations

If you write your own validations they are fully supported with just a small amount of code. The Wiki has a detailed guide on how to add custom validator support

Support custom FormBuilders like SimpleForm and Formtastic

Client Side Validations support SimpleForm and Formtastic. Most of the customization options should also be supported. Your own custom FormBuilder can be supported too, look out for a guide on the wiki soon.

Client side validation callbacks

Control the behavior of how the error messages appear or how a form handles failing validation with callbacks. The Wiki has a detailed guide on the callbacks

I hope people enjoy using this library. The re-write has taken a few months of my time and I’m happy to share the work with everybody. If you have any issues at all please don’t hesitate to open an Issue on Github or contact me with any questions!

Convert Prawn generated PDFs to an image with RMagick

Wed, 10 Nov 2010 08:48:00 -0500

You’ll see some complaining from RMagick about how the Prawn generated PDF is not 100% up to Adobe standards but that can be ignored.

pdf = Prawn::Document.new { text 'This is only a test.' } base64 = Base64.encode64(pdf.render) image = Magick::Image.read_inline(base64_pdf).first image.write('test.png')

Rails Camp New England #3

Tue, 27 Jul 2010 09:45:00 -0400

Registration is open!

When: Sept 10 - Sept 13
Where: Stowe, Vt Ski-Adventure Lodge http://ski-adventure.com/
How much: $140 (+ eventbrite fees)
Why: Hacking and fun

Join your other New England Rubyists for the 3rd Rails Camp New England!

http://rcne3.eventbrite.com

More information Rails Camp

remarkable_mongoid

Sat, 10 Jul 2010 17:43:00 -0400

I just released remarkable_mongoid. A set of Association and Validation RSpec matchers to use with Mongoid.

Check out the README for instructions.

Please note that this gem requires the 2.0 beta of Mongoid and installs the 4.0 alpha of Remarkable/ActiveModel. Despite their beta/alpha statuses I’ve been using both for over 2 weeks now and they feel very stable.

Rails Camp New England # 3

Thu, 01 Jul 2010 09:30:00 -0400

The time has come to start planning for another Rails Camp NE. Here are my thoughts on the next camp:

Where: Vermont
When: Sometime After Labor Day (dependent upon scheduling a venue and other conflicting Ruby events)

While our last venue was fantastic it maybe have been too big for the size group that we attract. So I’d like to find a venue similar to the first RCNE (basically a large party house). Any help searching for a venue that people can give is much appreciated. Ideally I’d also like the prices to come back towards the $120/head that the first RCNE was instead of the ~$150/head. The best way to offset this is with sponsorship.

I think the max size we’ll target is about 30 people. So if anybody plans on helping find a venue please keep that number in mind.

Hopefully we can have a venue locked down pretty soon.

Custom Subdomains in Rails 3

Sat, 19 Jun 2010 23:13:00 -0400

Rails 3 supports subdomains out of the box, which is great. But did you know that the constraints in the Router can actually match patterns too? This means instead of hardcoding each subdomain into your routes you can allow your customers to decide their own subdomains.

However, we have to be careful with pattern matching on the subdomain. There are obvious subdomains we don’t want to match. Like ‘www’, ”, nil, and others that we may reserve. In this case using a pattern match might not be best.

Thankfully the Rails 3 Router constraints can also take objects. As long as the object responds to Object.matches?. The request is passed to the method and you can act on it in any way. The following is the solution that I’ve found works for me.

I created a ‘lib/sub_domain.rb’ with the following code:

# lib/sub_domain.rb
class SubDomain
  def self.matches?(request)
    case request.subdomain
    when 'www', '', nil
      false
    else
      true
    end
  end
end

In my routes.rb file I can now wrap all routes I want under a custom subdomain

# config/routes.rb
TestApp::Application.routes.draw do |map|
  constraints(SubDomain) do
    root :to => "customers#index"
  end
  
  root :to => "home#index"
end

Finally, I create a SubDomainController from which all controllers under the subdomain constraint can inherit from

# app/controllers/sub_domain_controller.rb
class SubDomainController < ApplicationController
  before_filter :get_customer_from_subdomain
  
  private
  
  def get_customer_from_subdomain
    @customer = Customer.find_by_subdomain!(request.subdomain)
  end
end

# app/controllers/customers_controller.rb
class CustomersController < SubDomainController
  def index
    ...
  end
end

Having the SubDomainController is a nice way for me to encapsulate behavior that I want every subdomain to have. One such idea would be customer specific layouts. (or themes)

Check out Phil McClure’s post on localhost subdomains if you want to use this functionality in your development and test environments.

Update

To link to your dynamic subdomains you can completely overwrite the :host option in the url helper:

root_url(nil, {:host => "subdomain.somedomain.com"})

This is not ideal. It constrains us to this particular domain. What we need is to be able to pass a :subdomain option to the url helper. (btw, you need to use the url helpers for linking to subdomains and not the path helpers)

So I quickly wrote up this code. Just add it to your ApplicationController and it will be available to your entire app:

class ApplicationController < ActionController::Base
  ...

  private
  
  # To write subdomains on the url helpers:
  # root_url(nil, {:subdomain => "subdomain"})
  def url_for(options = nil)
    case options
    when Hash
      if subdomain = options.delete(:subdomain)
        if request.subdomain.empty?
          options[:host] = "#{subdomain}.#{request.host_with_port}"
        else
          options[:host] = request.host_with_port.sub(request.subdomain, subdomain)
        end
      end
    end
    super
  end
end

So now you can do:

root_url(nil, {:subdomain => "subdomain"})

RVM Gemsets + Bundler == Awesome

Mon, 14 Jun 2010 23:02:00 -0400

So I’m going to assume that you’re already familiar with RVM, Gemsets and Bundler. If you don’t know about them please follow the links and read up.

Mixing RMV Gemsets and Bundler together is a kickass way to maintain environment isolation for your projects. First you want to create a .rvmrc file in your project’s root directory. RVM will traverse up the directory structure until it finds a .rvmrc file and will use that.

I usually just put the following into the file:

rvm default@project_name

This will change to my default ruby and set the gemset to ‘project_name’. Then I create a Gemfile and put all of my library dependencies in there. Then run:

> bundle install

Now I have a nice and isolated development environment. I can switch between multiple projects and always know that I won’t run into any versioning issues with the installed gems.

One slight problem with this is if I’m including my .rvmrc file in my projects. Someone switches to it and get’s an error from RVM saying that the gemset doesn’t exist. Not that big a deal, they can go and create it. But it would be sweet if we could tell rvm to create the gemset if it doesn’t already exist.

I pinged Wayne Seguin (the guy that wrote RVM) about this and he suggested the following solution:

rvm --create use default@project_name

tldr; RVM Gemsets + Bundler == Awesome (and they kick ass)

Update:
That last .rvmrc will keep printing out the ruby@gemset being used after every directory change. Kind of annoying. So just suppress the output:

rvm --create use default@project_name > /dev/null

A cry for standardized versioning in Ruby (pretty please?)

Mon, 24 May 2010 15:39:08 -0400

Yesterday Rails 2.3.6 was released, today 2.3.7 was released. This morning the team I am on attempted to update our Rails 2.3.5 apps (we have several) to 2.3.7. It’s been several hours and we’re still not updated yet.

When I see a version update of 2.3.5 to 2.3.6 as a developer I should be able to assume that the update is fairly marginal. In fact, in almost every case it should be a drop-in replacement. Historically hasn’t been the case with Rails.

From a versioning point of view the significance in changes between 2.3.5 -> 2.3.6 and 2.3.6 -> 2.3.7 should be roughly equal. But as you can see here and here this is not the case. However, what I do know is that 2.3.5 was released on Nov 30, 2009. 2.3.6 was released on May 23, 2010. 2.3.7 was released on May 24, 2010. Perhaps time is the best metric? In that case would it make sense to adopt something similar to the Ubuntu versioning scheme? (Year.Month.Day.patch)

Rails aside, poor version management is systemic in the Ruby community. Despite pushing for code perfection in every other sense the Ruby community as a whole has entirely ignored proper versioning. If we are to be taken seriously by the development community at large our versioned releases must have meaning behind them.

Semantic Versioning seems to be the most logical approach to me. It would be nice to see a community movement towards this, or some versioning standard. Rails 3.0 would be a great starting point to push for a versioning standard in the Ruby community.

Moved from Blogspot to Tumblr

Sun, 09 May 2010 11:43:18 -0400

The move was incredibly easy thanks to this tool:

http://terrymhung.com/jtran/tumblr/import-blogger-to-tumblr.php