what_i_am.upto(2010)

The folks at Giraffesoft have decided to release some of the common code they’ve been using in their projects into plugins and gems on their brand-new company blog. In their own words:

At giraffesoft, we’re big believers in extracting functionality sooner rather than later. This practice has resulted in a ton of code that we use in all of our projects — nice and DRY.

Only problem is, we never get around to releasing this stuff. Starting a blog seemed like a good excuse to spend some time polishing up some code and, you know, writing READMEs.

So, starting today, we’ll be releasing an open source project every day this week. They’ll probably be mostly rails plugins. But, you never know. Something else might float in.

Actually, something else did float in right on the first day: Classy Resources for Sinatra, a gem allowing you to create restful web services that can be consumed by ActiveResource without manually defining all of the controller actions, but rather with a (very Railsish) configuration-style method:

define_resource :posts, :member => [:get, :put, :delete],
:collection => [:get, :post],
:formats => [:xml, :json, :yaml]

The thing is pretty customizable and even if it’s not exactly what you need, it still might be interesting to investigate the source code to see how to refactor common code into modules in Sinatra.

If you don’t know Sinatra yet, you really should go and check it out at Github and have a look at the Sinatra book.

Sinatra app template

Nick Plante has released a nice application template for Sinatra, with a reasonable initial directory structure and a Rackup script for easy use with Passenger. Haml, DataMapper, RSpec and such are also included, so this is pretty biased, but you’re free to fork it and adjust to your needs on github

I gave it a spin and had no problem to run it with Passenger by just pointing the Apache vhost configuration to the public folder of the app, so this is also great when you’d like to have an example on using Rack apps with Passenger.

Rails templates

Application templates seem to be up and coming currently, with the best thing obviously being the Rails templates feature in Edge Rails a.k.a. the upcoming Rails 2.3. Core member Pratik Naik posted a nice summary of the available methods in December, and Peter Cooper from Rails Inside posted more on the topic yesterday, with links to example scripts.

Basically this allows for scripting of the Rails application generator, giving you a DSL with methods to pull in plugins, executing rake tasks and so on. The template can be pulled in remotely, for example from a gist. Peter “Super Daring App Template” can be used with rails [whatever] -m http://gist.github.com/33337.txt, and you are free to fork it and roll your own.

Some kind of template database would be nice though, listing all public templates and their features, so you can pick your favorite and use it.

Zebra – One line tests for shoulda, context and matchy

I really like Shoulda. James Golick has released a gem that enhances it further, called Zebra.

The functionality can be summed up with this example from James’ initial post:

should "be editable by its author" do
  assert @post.editable_by?(@author)
end

becomes…

expect { @post.to be_editable_by(@author) }

Roll your own Pastebin with NavySnip

NavySnip is a pastie pastebin Rails application, but intended for localhost use. Check out the screenshot or have a look at the github repository.

Currently, it does not have syntax highlighting, but with a little help from Coderay or a similar Ruby gem, it should be easy to bring that into the app.

Free Lighthouse/Basecamp-inspired web app theme

Andrea Franz released a nice-looking web app theme that looks very familiar if you have been to sites like Lighthouse or Basecamp. Go check it out at Github and make a great app with it!

Little Known Ways to Ruby Mastery by Ryan Bates

To finish things up, there is a nice interview with Ryan Bates over at Rubylearning

As David A. Black states on his blog, there won’t be a RailsConf Europe this year:

Ruby Central and O’Reilly have decided to take a hiatus from producing RailsConf Europe this year, for the simple reason that it didn’t bring in enough revenue last year to justify doing it again, particularly given the tight economy and the need to err on the side of caution. RailsConf Europe has always been a really great event, and people who go to it really love it, but we need a year of retrenchment while we figure out how to get everyone else to realize how great it is! Plans for 2010 are not certain yet; we’re taking it one year at a time.

Quite disappointing, even though I was not in Berlin last year (but oddly enough in Portland, which makes for a travel distance of several thousand kilometers against 300). Maybe they should not have the conference hosted in super-exclusive downtown-hotels (like it was at the Maritim in Berlin), but rather just in some convention center.

In other news, David Heinemeier Hansson has announced the opening of registration for RailsConf 2009 in Las Vegas. The event is taking place from May 4th through 7th, in the Las Vegas Hilton. I really hope this does not mean RailsConf US won’t be happening in 2010 for not “bringing enough revenue”, as I can imagine the Las Vegas Hilton being more expensive to rent than the Oregon Convention Center in the last years.

They have early registration open until March 16th, so go and grab a seat and save 200 bucks!

You might also want to check out this years CabooseConf, the Ruby/Rails hacker event which will also be taking place at the Las Vegas Hilton during RailsConf, and can be entered for free with an exhibit hall only pass. You might be asked for a link to an open source submission you did, though.

Right after starting this blog, I already have the first topic to post about that implies both things I’m focusing on – Ruby and Ubuntu: As Peter Cooper announced on Ruby Inside, Phusion (of Passenger fame) have released a new service called DebGem. What this thing basically does is let you install all RubyForge and Github gems on Debian / Ubuntu machines via apt-get, which many people (me included) prefer over the duplicate handling which the original gem command requires, while still having access to latest as well as older versions (as opposed to the official repositories, which only hold outdated libs), plus it will install required lib dependencies for native builds, say imagemagick for rmagick. They also have a search set up so you can easily find the exact package name you have to type in when installing.

As Peter states though, there are two “catches”:

1. Native gems requiring a build are currently only available for Ubuntu 8.04 LTS (you might also want to check out the info on supported distros over at their starting page)
2. The service is only free during beta. Phusions clear explanation to that can be found in the FAQ

Thankfully, I’m still on Ubuntu 8.04 on my laptop, so I was able to try it out. After getting through the config steps (basically just another repository in /etc/apt/sources.list with the catch that you have to raise apt’s cache limit due to the huge amount of packages in the repo – Rubyforge without github already gives about 25000 packages) and doing an apt-get update, I was able to get nice datamapper <tab> auto-complete results:

colszowka@colszowka-laptop:~$ sudo apt-get install libdatamapper
libdatamapper0.1.1-ruby1.8  libdatamapper0.3.2-ruby1.8  libdatamapper-all-ruby1.8   libdatamapper-ruby1.8
libdatamapper0.2.5-ruby1.8  libdatamapper0.9.8-ruby1.8  libdatamapper-ruby

The naming and version availablity scheme is explained in the FAQ as well. I won’t copy and paste all of it, but basically when you install libdatamapper-ruby1.8, it will install all versions listed above.

This is because RubyGems supports parallel version installs. For example, RubyGems allows having both Rails 2.1.2 and 2.2.2 installed at the same time. Applications and libraries can depend on a specific version of a gem.

Dpkg does not have a direct equivalent of this feature. So as a compromise, and in order to ensure that everything works out-of-the-box, we install latest versions of the minor version.

Unfortunately, even when I specified a certain version, say libdatamapper0.9.8-ruby1.8, to be installed, the gem dependencies would not get resolved properly, with DebGem requiring me to install a plethora of versions of the gems datamapper depends upon:

  dm-cli-all-ruby1.8 dm-cli-ruby1.8 dm-cli0.9.8-ruby1.8 hoe-all-ruby1.8 hoe-ruby1.8 hoe1.0.5-ruby1.8 hoe1.1.7-ruby1.8 hoe1.2.2-ruby1.8 hoe1.3.0-ruby1.8 hoe1.4.0-ruby1.8
  hoe1.5.3-ruby1.8 hoe1.6.0-ruby1.8 hoe1.7.0-ruby1.8 hoe1.8.2-ruby1.8 launchy-all-ruby1.8 launchy-ruby1.8 launchy0.1.2-ruby1.8 launchy0.2.1-ruby1.8 launchy0.3.2-ruby1.8
  libaddressable-all-ruby1.8 libaddressable-ruby1.8 libaddressable0.1.2-ruby1.8 libaddressable1.0.4-ruby1.8 libaddressable2.0.1-ruby1.8 libdata-objects-all-ruby1.8
  libdata-objects-ruby1.8 libdata-objects0.2.0-ruby1.8 libdata-objects0.9.9-ruby1.8 libdatamapper0.9.8-ruby1.8 libdm-aggregates-all-ruby1.8 libdm-aggregates-ruby1.8
  libdm-aggregates0.9.8-ruby1.8 libdm-core-all-ruby1.8 libdm-core-ruby1.8 libdm-core0.9.8-ruby1.8 libdm-is-tree-all-ruby1.8 libdm-is-tree-ruby1.8 libdm-is-tree0.9.8-ruby1.8
  libdm-migrations-all-ruby1.8 libdm-migrations-ruby1.8 libdm-migrations0.9.8-ruby1.8 libdm-observer-all-ruby1.8 libdm-observer-ruby1.8 libdm-observer0.9.8-ruby1.8
  libdm-serializer-all-ruby1.8 libdm-serializer-ruby1.8 libdm-serializer0.9.8-ruby1.8 libdm-timestamps-all-ruby1.8 libdm-timestamps-ruby1.8 libdm-timestamps0.9.8-ruby1.8
  libdm-types-all-ruby1.8 libdm-types-ruby1.8 libdm-types0.9.8-ruby1.8 libdm-validations-all-ruby1.8 libdm-validations-ruby1.8 libdm-validations0.9.8-ruby1.8
  libextlib-all-ruby1.8 libextlib-ruby1.8 libextlib0.9.9-ruby1.8 rake-all-ruby1.8 rake-ruby1.8 rake0.8.3-ruby1.8 rspec-all-ruby1.8 rspec-ruby1.8 rspec0.9.4-ruby1.8
  rspec1.0.8-ruby1.8 rspec1.1.11-ruby1.8 rubyforge-all-ruby1.8 rubyforge-ruby1.8 rubyforge0.4.5-ruby1.8 rubyforge1.0.1-ruby1.8

The estimated additional disk usage for libdatamapper0.9.8-ruby1.8 from DebGem was noted as 28.1 MB. Quite a bit, but I can only recommend not to try this out with apt-get install rails (which oddly enough does not fall into the libXYZ-ruby1.8 scheme) – 484 MB!

Though installation went well, unfortunately I was unable to access the newly installed gem, even though it should have registered with my current rubygems installation:

All DebGem packages register themselves as Ruby gems, thereby providing full compatibility with Ruby software that expect gems.

colszowka@colszowka-laptop:~$ gem list --local | grep 'datamapper'
colszowka@colszowka-laptop:~$ irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'dm-core'
LoadError: no such file to load -- dm-core

Obviously the reason for this is that I do have a manual Rubygems install, rather than the one from the (way outdated) Ubuntu repositories. Since I did not want to mess up my whole gems install, I decided to not go further and rather check this out in a virtual machine on a fresh install as soon as possible, so until then I can only tell that the installed libraries ended up in /var/lib/gems/1.8/gems/ on my machine, which is the default gem install path for the Ubuntu Rubygems package. Obviously the DebGem repositories supply updates for Rubygems, so it might become unneccessary to have manual installs of Rubygems in order to get latest versions. I will try this the next days and keep you updated.

Until then, I can only say that this project is very promising, but obviously still far from maturity. On the other hand, just think of setting up the whole Rails stack on a vanilla Ubuntu/Debian machine through a custom .deb package containing your projects dependencies (ruby1.8, rubygems1.8, rails, passenger, apache2 and so on). The Brightbox passenger debs and DebGem might get us there in no time!

Update, January 7th: The Phusion guys have updated the datamapper (which after a version update also is libdatamapper0.9.9-ruby1.8) debgem, so now it won’t install all these gems I listed above anymore. I am currently testing the whole thing in a vanilla Ubuntu VM, so stay tuned for a future post on that!

Two weeks after the official announcement has been made by David, I finally managed to catch up on my Google Reader, and get to know these exciting news probably as the completely last person on earth: Merb is going to be merged into Rails to become the single greatest piece of software ever created!

If anyone apart of me also missed out on this (I really hope I am actually not the only one who enjoyed holidays away from the screen), be sure to also check out the announcements and opinions posted by new Rails core member Yehuda Katz (who gets into detail on how the merger can be accomplished), Merb founder Ezra Zygmuntowicz as well as Merb developer and Engine Yard employee Carl Lerche, which I actually found the most interesting read because it shows the uniqueness of the whole event of two distinct projects, each fighting for their own goals and having fundamental disagreements on the requirements of a kick-ass framework, putting their differences aside and rather joining forces to build something amazing that benefits from the advantages of both.

I’ve been following the development and achievements of Merb for quite a while, even though I never managed to really get into it and create a project based upon it. Actually what distracted me the most was that I had to relearn some things, which were done differently in Rails, while plenty of stuff could be accomplished the same way. I always liked Merb’s aim to achieve a better structure though, for instance the highest-possible level of decoupling of the individual parts of the framework (I am thinking of the possibility to use something different than ActiveRecord in particular) as well as their work on speedup and early embrace of Rack.

The announced enhancements of Rails performance based upon Merb code have already started to take place, as Mike Gunderloy wrote in his most recent “This Week in Edge Rails“:

In some of the first fruits of the Rails-Merb team merger, Yehuda Katz took a look at the respond_to method, which is of course heavily used in many Rails applications to allow your controller to format results differently based on the MIME type of the incoming request. After eliminating a call to method_missing and some profiling and tweaking, he reports an 8% improvement in the number of requests per second served with a simple respond_to that switches between three formats. The best part? No change at all required to the code of your application to take advantage of this speedup

This whole thing is gonna be huge for Rails as well as the whole Ruby community! With the cute parts of Merb integrated into Rails and other great stuff like Rails Metal coming up, I am already looking forward to David’s keynote at this years RailsConf, in which hopefully he will introduce the greatness of Rails 3 to us, though I don’t believe they will have a beta wrapped-up by then (which he is hoping for in the mentioned post).

In more recent news, the “new evangelism team” mentioned by David in the post linked above has been introduced on the official Rails blog today:

Bringing Rails and Merb together is about more than just merging the respective code. We’re also picking up the best ideas from both communities beyond the code. Following on Merb’s success in offering a strong evangelism effort, we’re pleased to announce the creation of the Rails activists:

The mission of the Rails activists is to empower and support the worldwide network of Ruby on Rails users. We do this by publicizing Rails, making adoption easier, and enhancing developer support.

I can only repeat myself: Great stuff coming up!