March 10 2010

Highlight 1.1.0 is out

After getting some attention for the Highlight plugin after the mention at EnvyLab’s Ruby5, I decided to give the plugin some care.

Just now, I released Highlight 1.1.0. Besides some refactoring and cleanup, this release adds support for Trevor Turk’s pygments web API if no local installation of pygments can be found. Of course this makes syntax highlighting slower but allows to use the plugin in virtually any environment, especially in such where you just are not allowed to install pygments.

March 9 2010

March 8 2010

February 1 2010

January 19 2010

January 8 2010

Melbourne 1.0.0

I just released version 1.0.0 of the Melbourne gem. Melbourne is an extraction of the Melbourne parser from theRubinius project and lets you generate an abstract syntax tree from arbitrary Ruby code.

See the README and the RDocs for more information.

Thanks to Evan Phoenix and the Rubinius team for the great work!

January 7 2010

December 19 2009

random Rails tips Vol. 2

My series of random Rails tips that started a month ago continues with some tips on how to use wycats’ bundler gem. What bundler does is basically maintaining and resolving a project’s gem dependencies (and the dependencies of these gems) and bundling all required gems in vendor/gems. This is what Rails’ gems:x tasks where intended to do, but never really did sufficiently. Where the rake tasks would frequently fail since the environment that the tasks themselves needed to execute could not be set up because it depended on the gems the tasks where intended to install, bundler is completely independent (only rubygems and the bundler gem itself are needed of course).

Setting it up

To set up bundler for your project, you first need to create a Gemfile in that you specify all dependencies your application has. You can specify versions, the libs to include (if they could not be resolved from the gem name) and also require certain gems only in certain environments. A sample gem file for a Rails app using DataMapper (expect more on using DataMapper with Rails in a future post of my random Rails tips series) might look like this:

In the first line, the path is specified where bundler holds the *.gem files, the extracted gem sources etc. The second line disables the system’s gems so that any gems that might be installed on your machine but are not bundled with the application will not be loaded. This is pretty important to be sure that the application is actually self contained and you didn’t forget to specify a dependency which didn’t lead to errors because the missing gem was installed on your machine.

The last block in the gem file specifies gems that are needed everywhere except for the production environment. While you need gems like rspec, rspec-rails or excellent in the test and possibly also in the development environment, you certainly don’t need these gems to be installed on your production machine(s).

Using bundler

Of course you need to make sure that the bundled gems will actually be used (Rails 3 will support bundler out of the box, however Rails 2.3 doesn’t; see qrush’s commit to the gemcutter.org source). Therefore you have to add a preinitializer.rb in your app’s config directory:

Yehuda describes a different solution in his blog post but that doesn’t work with Passenger under certain conditions. You also have to edit your boot.rb to include the following block right at the end:

When everything is set up, you can run gem bundle from your app’s root and bundler will install all the required gems:

You now have all gems your app requires bundled in vendor/gems and are ready to run ./script/server/.

Deployment with the bundler gem

Deploying you app with the help of bundler is a breeze. It’s as easy as adding two tasks to your deploy.rb (assuming you’re using Capistrano; thanks jerryvos for pointing that out):

This will keep all your app’s gems in shared/vendor/gems and make sure that whenever a new gem is required and not bundled on the server (or a new version is available and you’re not requiring exact versions), it is installed.

Using the bundler gem makes your life a lot easier, works pretty good already and there really is no reason to wait for Rails 3 to use it. So everybody go ahead: gem install bundler!

My Code to Test ratio won’t stop increasing…

1:2.8!

December 14 2009

December 10 2009

November 27 2009

random Rails tips Vol. 1

Some random tips for your next Ruby on Rails project:

• If you have to monkey patch gems or plugins (only monkey patch anything if you really have to, it can make finding errors a giant pain), make a Rails.root/lib/patches directory in which you keep all the (monkey) patches you need and include them in your environment.rb:

  This way you at least structure your monkey patching stuff better and know of the one place where strange behavior might originate.

• Also if you monkey patch, don’t do any fancy (and often unneccessary) class_eval as long as it’s not possible to get the same result by simply reopening the class (or module) body. It’s by far more readable! Also see Yehuda Katz’s great blog post about this topic.

• If you have to specify class names on associations that could not be automagically inferred from the associations’s name, always use the actual class and convert it to String instead of specifying a String directly.

  When you specify the class name as a String directly and change the class’s name, it will fail late, as opposed to when you convert the actual class to String will fail early (namely on startup) since you’ll be referencing a class that does not exist.

There are probably more random tips to come in the future so stay tuned.

November 26 2009

November 23 2009

…