DigitalHobbit

The distributed Git version control system has been gaining a lot of traction lately. In contrast to traditional, centralized version control systems like CVS or Subversion, Git enables developers to easily fork each other’s repositories, pull patches from each other, etc. Even though I have not had a chance to use Git beyond pulling down some open source projects (such as Merb), it is clear that this enables much richer collaboration and development dynamics.

In particular, github seems to have quickly become a favorite service for hosting Ruby projects. github is still in invite-only beta, but it already looks very impressive. For example, forking an existing repository that is hosted on github only takes a single mouse click, and sending a pull request to the master repository or other forks is just as easy. Each repository has an RSS feed and a wiki, which turns github into a full project hosting service as opposed to just a version control service. In fact, github has been described as a social network for hackers. In addition, github offers convenient features such as tarball downloads.

The developers had announced that public open source projects would always remain free. Today, github unveiled the detailed pricing plans. Overall, the plans seem very reasonable. Each plan includes unlimited public repositories and public collaborators, but a limited disk space and number of private repositories and private collaborators (depending on the plan). Personally, I would have hoped for the smallest commercial plan (Micro, which includes 5 private repositories and a single private collaborator) to cost less than $7, perhaps $3 – $5. Many developers that work on non-open-source projects in their spare time would presumably be interested in such a plan, but $7 seems slightly steep, given that you can get a Dreamhost hosting plan for $10 per month, which supports Subversion, website hosting, shell access, and, with some effort, even Git hosting. Obviously the $7 github plan offers a significantly better user experience, but I am not sure if I could justify the expense as a small developer working on non (or not yet, anyways) profitable projects in their spare time.

But ultimately github’s main focus is clearly on open source projects, and it sure is great to have a modern alternative to Subversion based project repositories like SourceForge or RubyForge. In fact I went ahead and created my own forks of the various Merb sub-projects, in case I want to play with some Merb changes or submit additional patches. I also have some ideas (or even unfinished code) for other projects that I might end up moving to github as open source projects.

I believe that one of the smaller commercial plans would also be an excellent alternative for a small startup that wants to avoid the hardware and IT headaches of dealing with their own setup in the initial phases. In fact, by combining github with a hosted issue tracking service like Lighthouse, a VPS hosting service like SliceHost, and Google Apps for email, calendaring, document collaboration, and now also Google Sites for a wiki or intranet, it should make it much easier to bootstrap a new company without a massive IT investment.

I have a few github invites, so leave a comment if you’d like one.

Merb 0.9.0 was released 5 days ago. It looks like the download instructions on the homepage have also been updated for 0.9.0. You can now install it as a gem or from source, by checking out the code from the Merb Git repository.

Aside from a more modular design, Merb 0.9 also introduces a more flexible application layout. Previously, the layout was essentially the same as for a Rails app. This is still the default, but if you create your app using merb-gen my_app --very-flat or --flat, you get a significantly smaller layout that might be better suited for small applications.

In fact, a --very-flat application consists of a single file with the following contents:

Merb::Router.prepare do |r|
  r.match('/').to(:controller => 'my_app', :action =>'index')
end

class MyApp < Merb::Controller
  def index
    "hi"
  end
end

Merb::Config.use { |c|
  c[:framework]           = {},
  c[:session_store]       = 'none',
  c[:exception_details]   = true
}

That’s not quite as tight as a true micro framework like Sinatra, but it’s pretty close. For very small applications, I have occasionally used Ruby’s built-in WEBrick server, but a very flat Merb app seems quite a bit simpler, as well as more future-proof, as this can be easily transformed into a full app with a more sophisticated layout if the app grows beyond its initial minimal scope.

Oh, by the way: I have contributed my first (admittedly tiny) patch to Merb (part 1, part 2), which adds support for dynamic layouts by allowing you to write something like layout :determine_layout in your controller to specify a method that is used to dynamically determine the layout to use, rather than hardcoding it on the controller level or having to pass it in each render call (yes, this works just like in Rails).