I’ve been playing around with a new browser called Cruz. Based on webkit, it manages to feel faster than Safari, and it has some unique features. I recommend taking a look at the screencasts.

However, I wanted to see if Cruz could be made to work with a nightly webkit build. My objectives for doing so were:

1. to have a browser that passes Acid3. Just for fun, I suppose.
2. to give Cruz the much nicer inspector and JS debugger that is a part of the nightlies
3. to allow images to scale along with text when I up the font size (the Webkit nightly is capable of this with a hidden preference)

Of course, the third one failed, since Cruz doesn’t tell the Webkit framework to use its full-page-zoom, and it was the Webkit binary that was reading the hidden preference, not the framework itself. Oh well.

That being said, Cruz now passes Acid3, and has the refreshed Inspector with a full JS Debugger. I’m rather happy.

Process

1. Download the Webkit nightly
2. Show package contents for both Cruz and the Webkit nightly
3. Copy the contents of Contents/Frameworks in the Webkit nightly to Cruz’s Contents/Frameworks
4. Rename Contents/MacOS/Cruz to TrueCruz
5. Create a text file at Contents/MacOS/Cruz and paste the following script into it (also be sure to make the script executable)
6. All done.

#!/usr/bin/perl -w

# Perl script for launching Cruz using the frameworks in the
# /Content/Frameworks directory of the application bundle.
#
# Adapted from the Multi-Safar script
# <http://www.michelf.com/weblog/2005/multi-safari/>

#
# Get path to current file so that we can set a find
# path for frameworks and launch the true Cruz binary.
#
$here = __FILE__;
$here =~ s{^(.*)/.*?$}{$1};

#
# Make frameworks load from "Cruz.app/Content/Frameworks"
# by using a relative path.
#
$ENV{DYLD_FRAMEWORK_PATH} = $here."/../Frameworks";

#
# Launch the true Cruz binary.
#
exec "\"$here/TrueCruz\"" or die;

Update: All problems described here have been resolved.

Recent versions of merb can now use the provided thor tasks to bundle merb, mongrel, and other gems with the source of the application, with the intent of making deployment easier. Merbunity has a nice introduction to this.

However, I’ve run into a couple of issues with this, and thought I’d document my experiences (I’m actually hoping that this post will be invalid a week from now, that all of these will have been fixed).

English

Update: The 0.3.1 gem installs just fine.

First, at some point this morning the english gem was updated to 0.3.0, and this version is broken. I always see the following error when attempting to install it, both globally and as part of a bundle:

ERROR:  Error installing english:
english requires facets >=2.0.0
(>= 0, runtime)

Of course, I have facets 2.4.4 installed.

Solution

Run this before bundling merb using thor:

bin/thor merb:gems:install english --version='0.2.0'

Gems Cache

Update: This has been resolved. As of commit 7e2ce280621a0b712ee36b22520576d8905038bd, the merb-gen in merb-more does not place gems/cache/* in your .gitignore.

This is a more minor issue. When deploying to a different architecture, you want to run bin/thor merb:gems:redeploy. This requires the gems/cache directory to be present, but the .gitignore file provided by merb-gen ignores all the caches.

Solution

Simply remove the gems/cache/* line from your .gitignore file if present (and if you’re using git).

Shebang

Update: This has been resolved by the merb team. Running thor merb:tasks:update will give you a merb.thor that uses /usr/bin/env ruby in the shebang line.

The shebang line placed in bin/thor, bin/merb, etc., is system-specific. In my case, the ruby path generated on my dev machine is completely non-existent on my server. This makes it impossible to execute bin/thor on the server, making it rather difficult to redeploy the gems (redeploying regenerates all the binary wrappers, so this is really only problematic on bin/thor).

Solution

There are two options here:

1. Have thor installed on your server and don’t use bin/thor until after you run a redeploy
2. Modify #!#{Gem.ruby} in merb.thor (in executable_wrapper) to #!/usr/bin/env ruby . This one only works if all of your systems are unix-based, of course.

This is the most frightening line of code I’ve seen in my lifetime:

@model = eval(params[:item_type].classify)

This was in a Rails controller.

For any of you not horrified by the above code, allow me to explain. This would allow an attacker to put arbitrary ruby code into a url query parameter, and have it be executed with the full permissions of your rails application.

Now, since it seems this needs some repeating:

Never use eval on user inputs. Especially un-sanitized user inputs.

So, I’ve finally gotten around to starting up a blog. Whether I’ll have anything interesting to say in here is up for debate. We shall see.

For the curious, this blog uses a minimal CMS that I’m working on (the back-end is currently far too ugly for me to show it to anyone though), and the design is my own creation as well (the first design of mine that isn’t plain ugly. At least, I think this one’s not ugly), with some help in Photoshop training and color selection from Erin Shine.

The dog in the header is Qiqi, a Siberian Husky/Alaskan Malamute mix that is still recovering from her hip replacements.