I was pounding my head against the keyboard. Rspec with rcov was crashing whenever it felt like it. I was getting all kinds of errors like:

/opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/matchers/be.rb:92: [BUG] rb_gc_mark(): unknown data type 0×0(0×489ffc8) non object ruby 1.8.6 (2007-09-24) [i686-darwin9.3.0]

opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.11/lib/spec/example/example_group_methods.rb:344: [BUG] Segmentation fault ruby 1.8.6 (2007-09-24) [i686-darwin9.3.0]

not to mention a bus error or two as well.

Then I found this article with this solution:

$ gem sources -a http://gems.github.com (you only have to do this once) $ sudo gem install mergulhao-rcov

from this guy.

Then the world was right again.

Recently I had a need to implement an on-demand payment model with a payment processor (Cybersource). I use the Active Merchant plugin for transaction operations almost exclusively, and nobody had added support for Cybersource subscriptions or on demand payments. So I implemented it myself over the last couple days, and published the code on github .

Currently it supports creating subscriptions, updating subscriptions (which is also how you cancel), and preforming a purchase (auth+capture) via subscription. I’m willing to implement other things like credits, straight auths and captures if there’s a community need. There’s not much in the way of docs yet (like most of Active Merchant), but it’s working for me. I’d also be willing to write a post on using the features I added, just drop a not in the comments if you would like to see that.

I’ll be submitting a patch soon, and hopefully this will get pulled into the official ActiveMerchant repository. This is the first real open source contribution we’ve made at ELEVATION (most things we need we find are already done), and it feels good to give back. You should try it.

I’ve been hesitant to explore git since subversion was (I thought) really handling all my needs just fine. Why waste time learning another version control workflow?

Over time, I started to realize there were things about git that would be really nice, like nice branching and merging in particular, but I thought, that’s for some day when I have time to learn it, or my pain becomes too great with branches (which I don’t use that often in svn).

Just a couple days ago I needed to extend some code that was hosted on github, so I forked it, cloned it, and just started to work. In that process I’m discovering things that are just making git start to click. Whoops, didn’t mean to commit that yet: git-reset. I need to pull in some other changes, but can’t yet because I have uncommitted changes: git-stash.

Combined with the git bundle for textmate, I’m actually having fun learning git.

Moral: Try new stuff (in a real-life scenario), it’s fun and can make your life better.

The U.S. Court of Appeals for the Federal Circuit ruled that licenses used for OpenSource projects can be enforceable under copyright law.

Here are some excerpts from the summary document published by the Court:

... Open Source software projects invite computer programmers from around the world to view software code and make changes and improvements to it. Through such collaboration, software programs can often be written and debugged faster and at lower cost than if the copyright holder were required to do all of the work independently. In exchange and in consideration for this collaborative work, the copyright holder permits users to copy, modify and distribute the software code subject to conditions that serve to protect downstream users and to keep the code accessible ...

... Traditionally, copyright owners sold their copyrighted material in exchange for money. The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties. For example, program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. Improvement to a product can come rapidly and free of charge from an expert not even known to the copyright holder ...

... Generally, a copyright owner who grants a nonexclusive license to use his copyrighted material waives his right to sue the licensee for copyright infringement and can sue only for breach of contract. If, however, a license is limited in scope and the licensee acts outside the scope, the licensor can bring an action for copyright infringement ...

Source: Jacobsen v. Katzer Appeals Summary

Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material. A copyright holder can grant the right to make certain modifications, yet retain his right to prevent other modifications.

This decision is important because it reduces the legal uncertainty regarding OpenSource rights and will make it a more attractive option for software development and OpenSource distribution models.

Elevation continues to support the OpenSource ideology. Litigation about OpenSource is rare so it's good to have this legal precedent on the books. August 2008 will likely be looked back on as the start of the next wave of OpenSource collaboration.

Today, I got bit by ActiveRecord race condition related to validates_uniqueness_of. Sometimes I just blindly trust that Rails is going to take care of things, and so it surprised me when I ended up with duplicate records in my database. A few people have written about this, and apparently it’s in the API Docs now, but I just hadn’t thought about it before.

The solution looks to be enforcing unique constraints at the database level.

By default I include the rails t.timestamps in my create table migrations. Always nice to know when a model has been created or updated, right? And what could it hurt?

Well, when they are in a join table for a habtm relationship they cause the associated records to be marked as readonly. This is because rails can’t save those extra timestamp attributes.

If timestamps or any other extra join information is needed, then use a join model instead with has_many :through.

more info

Yesterday I was investigating why exception_notifier wasn’t, well, notifying me of exceptions.

I checked out the log, and I was getting an error like this:

ActionView::TemplateError (protected method `filter_parameters' called for #<Admin::ProductsController:0x2aaaaeccd6b0>)

Turns out Rails 2.1 breaks the version of exception notifier you get by running script/plugin install exception_notifier. To get the correct version, you have to run script/plugin install git://github.com/rails/exception_notification.git

Pretty lame, they really should update that.

I ran into a situation this week where I had a single partial containing form fields being rendered for different models. Inside that partial, one of the fields was a text_field_with_autocomplete, which presented a problem, since form_builder doesn’t know anything about text_field_with auto_complete, and the text field certainly needed to know what model we were working with here. After a little digging, turns out form_builder exposes a getter called object_name:

<%= text_field_with_auto_complete f.object_name, :city_name, ... %>

Easy.

A big topic at railsconf this year was hosting , deployment and scaling of apps. Talks and sessions on these topics were everywhere, not to mention Engine Yard getting pimped left and right (No, I won’t wear your tshirt). I found it extremely ironic then, when Michael Koziarski said in the closing keynote (paraphrased):

Deployment is a word you shouldn’t have to know.

I couldn’t agree more. I want to be as removed from the details of how to deploy and scale an application as possible. I want to focus on writing software that meets my customer’s needs, and the rest is details.

I think mod_rails is a big step in that direction. I think those guys are awesome, but I’m certainly not interested in writing improvements to garbage collectors to make ruby faster. It’s just not my bag. The more time I have to spend worrying about and managing deployment, the less time I’m spending “investing in myself” as DHH put it, and solving problems for my customers. It’s good to know that there are smart people out there working on how to scale applications, but I just don’t want to have to concern myself with it. Most of the apps I write are pretty small anyway, and when I meet the need to seriously scale, I’ll pay someone else to do it. Software like mod_rails is allowing me to survive even longer on a VPS (we use slicehost) so I can spend my time doing what I do best.

I moved my first VPS hosted slice over to phusion passenger (aka mod_rails) last night and was pleased so see the memory usage on my slice immediately drop about 15%. However, this morning I had lots of cryptic error messages about ruby_inline as follows:

Permission denied – /var/www/apps/serveday.org/releases/20080528201859/tmp/.ruby_inline/Inline_ImageScience_aa58.c /usr/lib/ruby/gems/1.8/gems/RubyInline-3.6.7/lib/inline.rb:731:in `initialize’

I had already dealt with this issue when first setting up imagescience, and this looked related, but slightly different.

What I didn’t forsee was that previously, my mongrels were started with sudo – therefore running as root. When running with passenger, the user www-data was now the one that needed write access to the tmp directory, where rubyinline is doing its thing.

A quick permission change, then a restart with touch tmp/restart.txt and everything was green.

Overall, I’m really happy with the ease of setup and performance of passenger so far.

Hot on the heels of RailsConf, I’ve decided to do something I’ve been meaning to do for a while, which is start a blog centered around rails, software, and business issues related to each of those and the rails community.

I’m going to start with some impressions and opinions I came away with at rails conf, coming up next . . .