I’ve been using vendor/rails and vendor/gems for a while to fix my dependencies to known versions of third-party code. It was easy to do, and the two main drawbacks didn’t bother me much:

1. Duplication of code in my project’s repository, making it bigger
2. Gems with native extensions don’t work (at least, I never bothered trying to make them work)

There is one huge advantage to duplicating this code, though: when the day comes that you hit a bug, you can modify the files in your project, commit them, and move on. With Bundler, it is not obvious how to accomplish this.

Thankfully, what had been missing for me when trying to understand day-to-day use of Bundler now exists: a rationale for why Bundler works the way it does and how to use it as intended. This answered almost all of my questions about how to use Bundler, and led me to a solution for the last one (how to make a local fix).

To make a local fix (for example, in Rails), what I’m now doing is pointing my Gemfile at a fork of the official repository:

gem 'rails', :git => 'http://git.lightyearsoftware.com/rails.git', :tag => '3.0-lys'

This repository contains a branch, 3.0-lys, in which I make my local modifications. It also contains a remote, “upstream”, which tracks the official Rails repository:

$ git remote add upstream git://github.com/rails/rails.git

3.0-lys was branched from v3.0.0, the tag for the official 3.0 release. Note that I didn’t branch it from upstream/3-0-stable because there are changes on this branch that will eventually be part of 3.0.1. When a new release is made of 3.0.x, I’ll merge from the tag into 3.0-lys, keeping it current. Bundler is smart about this, appending a tag to the version number of the “gem” it installs:

$ bundle show
...
  * rails (3.0.0 8b5ee93)
...

Bundler shows a lot of promise, and I’m happy to see the one area that was lacking (documentation) rapidly improving.

MacPorts, however, doesn’t include much of the contents of “contrib” in a standard install, including both of these extensions. This makes it a lot harder to develop code using them unless I want to set up a development database on my production server, something I am not eager to do.

Thankfully, there is a solution: disable auto-clean, and after installing the postgresql83 (or 84, depending on the version you want), you can install the extra “contrib” extensions by hand.

1. Edit /opt/local/etc/macports/macports.conf and set portautoclean to no.
2. Install PostgreSQL (sudo port install postgresql83) or, if you’ve already installed it, re-install it (sudo port upgrade --force postgresql83).
3. Change into MacPorts working directory: cd `port work postgresql83`/postgresql-8.3.11/contrib. Your specific version will differ from mine if you’re reading this more than a few months after I wrote it.
4. For each extension you want installed, cd into the directory, make all, then sudo make install. This compiles C code, if any, into a shared library, then copies the library and supporting SQL files (to create types, functions, etc., and also to drop them) to /opt/local/share/postgresql83/contrib.
5. Change into /opt/local/share/postgresql83/contrib and run the SQL files associated with the extensions you want. This probably needs to be done as the PostgreSQL super-user. For example, psql -U postgres dbname <cube.sql.
6. Enable auto-clean again by editing /opt/local/etc/macports/macports.conf and setting portautoclean back to yes.
7. Clean the postgresql83 port: sudo port clean postgresql83.

I stumbled on Daniel Jalkut’s post about automatically stamping the Subversion revision into Info.plist and thought that might be a good way to go. I also created a new key in Info.plist, LYSApplicationDisplayVersion, that I use as a human-friendly version string, which is where I get my preferred “1.0 b1″ form. CFBundleVersion now takes the form of major.minor.revision, where major and minor are the important parts of the human-friendly version (“1.0″) and revision is the Subversion revision number that produced the binary.

I like this method because it solves one problem raised by commenters on Daniel’s post. Because the Subversion revision is the third component, it doesn’t matter than r3999 is a mature 1.2 point release and r4000 is a risky pre-2.0 alpha for testers. Those versions end up 1.2.3999 and 2.0.4000 and it’s clear that they are from two different branches of development. For iPhone Ad Hoc distribution, iTunes also parses the version properly and knows that 1.0.100 is newer than 1.0.95.

Here is the script to paste into your custom script build phase:

# Xcode auto-versioning script for Subversion
# by Axel Andersson, modified by Daniel Jalkut to add
# "--revision HEAD" to the svn info line, which allows
# the latest revision to always be used.
 
use strict;
 
die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"};
 
# Get the current subversion revision number and use it to set the CFBundleVersion value
my $REV = `/usr/bin/svnversion -n ./`;
my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Info.plist";
 
my $version = $REV;
 
# (Match the last group of digits and optional letter M/S/P):
 
# ugly yet functional (barely) regex by Daniel Jalkut:
#$version =~ s/([\d]*:)(\d+[M|S]*).*/$2/;
 
# better yet still functional regex via Kevin "Regex Nerd" Ballard
($version =~ m/(\d+)([MSP]*)$/) && ($version = $1);
 
die "$0: No Subversion revision found" unless $version;
die "$0: Modified, switched or partial working copy, you sure about that?" if $2 && ($ENV{"BUILD_STYLE"} eq "Ad Hoc" || $ENV{"BUILD_STYLE"} eq "App Store");
 
open(FH, "plutil -convert xml1 \"$INFO\" -o - |") or die "$0: $INFO: $!";
my $info = join("", <FH>);
close(FH);
 
$info =~ s/([\t ]+<key>CFBundleVersion<\/key>\n[\t ]+<string>\d+\.\d+).*?(<\/string>)/$1.$version$2/;
 
open(FH, "| plutil -convert binary1 - -o \"$INFO\"") or die "$0: $INFO: $!";
print FH $info;
close(FH);

There are a couple of other changes to this script for Subversion 1.5 and later, and for iPhone OS targets.

The first is that the regular expression allows for a trailing P in the Subversion revision. This signals a working copy from a sparse checkout, which I never use and therefore may be a problem. I have the script fail if any letter is appended to the revision when the BUILD_STYLE is “Ad Hoc” or “App Store”, which are two new configurations, cloned from Release, that I use for Ad Hoc and App Store distribution, respectively. Especially for modified working copies: I never want to accidentally hand out a build made from a modified working copy. Should the day come that I really do, I can comment this line out, make the build, and uncomment it again.

The second is that iPhone projects convert Info.plist to the binary plist format in the application bundle. In order to extract the existing CFBundleVersion key, it must be converted back to XML. When writing the plist back out, it is again converted to binary. Both of these steps use plutil, which is part of the Developer Tools.

Ruby threads cannot be used in RubyCocoa without patches to the Ruby interpreter

It is caused by a plug-in or gem requiring osx/cocoa, frequently attachment_fu. AttachmentFu can use CoreImage as an image processor instead of calling out to an image manipulation library such as ImageMagick or GD2.

The warning is harmless, but it can be very noisy. To disable it, you can simply remove CoreImage from AttachmentFu’s list of image processors by creating a new file in config/initializers. Its contents should be this one line:

Technoweenie::AttachmentFu.default_processors.delete('CoreImage')

Image resize operations will now use one of the other image processors, which you can install from MacPorts. I never deploy to a Mac OS X server for production, and I prefer to run as much of the same code as possible in development, so this isn’t a problem for me.

There is a work-around, though it does mean storing your user and password in plaintext in your device’s bookmarks. HTTP allows you to supply authentication credentials as part of the URL, in the form http://username:password@example.com/.

In the last few days, I’ve considered building a form-based login for one of my sites, just so I can do basic management from my iPad. I’m comfortable that since the device rarely leaves the house, and the data on this site is not sensitive, that leaving the password in plaintext in the bookmark is an acceptable trade-off.

You can use content_for to capture some markup, but have it emitted into the page from somewhere else.

Two places this is immediately useful: adding additional tags inside <head> and placing in-line Javascript near </body>, while keeping the code itself right next to the DOM elements it works upon.

content_for works by capturing whatever appears inside the block and storing it for later use. You emit whatever is stored using yield. What’s more, content_for doesn’t clobber the previous captured text if you use it more than once with the same key.

Say you have a fancy Javascript control that replaces a standard <select> element in forms. You can do this in your partials:

<select ...>
  <option>...</option>
  <option>...</option>
  ...
</select>
<% content_for :body_close do %>
  <script type="text/javascript">
    // code that does something with that <select>
  </script>
<% end >

And then in your layout, just before the </body>:

<%= yield :body_close %>

Because most browsers will run in-line Javascript upon encountering it, this would delay the execution of the code until all of the page content was loaded, making your page appear to load faster.

What’s more, if that fancy Javascript control also requires a CSS file, but you don’t want to require the browser to fetch it on all of the other pages that don’t need it, you can conditionally add it to <head> by defining another content_for key that accumulates additional markup to go there:

<% content_for :head do %>
  <%= stylesheet_link_tag 'fancy_control' %>
<% end %>

And in your layout:

<head>
  ...
  <%= yield :head %>
</head>

This is also useful for keeping per-page markup like <title> and meta tags in the template and out of your controller.

<%= javascript_include_tag 'first', 'second', 'third', :cache => true %>

There’s a gotcha hiding here that you may not find until you deploy to production and visit your site in IE.

Admittedly, this is a bug, but if you happen to have a second javascript_include_tag with the :cache argument in the same page, IE will choke on lots of the script, telling you “object doesn’t support this property or method,” among other things.

The problem is that Rails can’t resolve multiple tags using the same value for :cache, and it emits two <script> tags referencing the same Javascript file. IE gets confused by the second one (perhaps loading it twice?). Every other browser I’ve used handles it fine.

The solution: either don’t use :cache more than once or make sure you use explicit, unique bundle names instead of just true.

The second is code completion for language constructs such as if statements. Xcode wants to do this:

if (condition) {
}

While I used this style a long time ago, today I want the opening brace on its own line:

if (condition)
{
}

No amount of digging in the preferences will provide a way to change these behaviors, however there is a lot of customizability hidden in the Xcode User Defaults. My two issues are solved quite easily:

$ defaults write com.apple.Xcode XCShowUndoPastSaveWarning NO
$ defaults write com.apple.Xcode XCCodeSenseFormattingOptions -dict BlockSeparator "\n"

Programming, either as a hobby or a career, has only been around for a little less than 70 years. (The first was the Colossus, built and used by the British during World War II to read encrypted German messages.) This is very young when compared to other scientific fields: agriculture, construction, various engineering disciplines, etc.

I won’t disagree that building the very fundamental parts of a new application from scratch can be very enjoyable. Perhaps not printf(3), but certainly other parts. The problem is bug rates, though: any seasoned software developer knows that writing less code means less bugs. If high-quality libraries are available that provide 80% of the functionality of your new application, you will likely end up with a better product, in less time, than if you chose to write the entire thing yourself.

Consider the sorry state we’d be in if:

All farmers experimented with their own methods of weed and pest control (organic or not), instead of using techniques proven to work in the past. Our agriculture industry probably couldn’t meet the population’s demand for food.

Architects and builders “winged it” when building new homes and office buildings. Bugs in that industry would likely mean structural failure. Who would want to live in those houses?

How about automakers? It’s one thing to build a kit car as a hobby, it’s quite another to tinker with your designs when you’re producing cars on a massive scale for general use (just ask Toyota).

It may not be as glamorous, but if our collective bug count goes down and the software industry ships better products that don’t require constant patching, I can’t help but consider this a very good thing.