I’m guilty of it. Many of you are likely guilty of it… and I know that several customers of our Rails Code Audit and Review service are guilty of it.

How many times have you realized (after a few months has passed) that your Copyright date/year on your web site was no longer current?

How many of you had the same problem last year? The year before?

Let me share some advice with you all… DRY (a)!

Don’t Repeat Yourself (again)!

This is really a simple problem to fix but when we’re busy tackling bigger problems… little things like this slip by. Don’t worry, you’re not the only one who was reminded by a colleague three months into the year that you forgot to update this.

On client projects, we have a handful of helpers that we drop into the application. We’re starting to extract more of these into plugins and will be releasing those as time permits. It just happened that I found myself looking at yet-another Rails code base this afternoon that was showing 2007 in the footer. An easily forgivable offense.. but if you’re going to go in there and change it (again), take a moment to do the right thing. ;-)

Our solution at Planet Argon on client projects is to create a basic view helper that renders the current year. This allows us to do the following.

Our team has been migrating towards using Git as our primary SCM. We have way too many Subversion-based projects and repositories to just do a clean switch over and not everybody on the team has had time to start playing with it. Baby-steps…

So, for those of us who want to use it day-to-day, we’re using git-svn.

Andy Delcambre has posted the first in a series of blog articles to help you pick up on using Git on Subversion-based projects. Check out his article, Git SVN workflow to get up to speed.

Also, if you’re on OSX and using Git… check out Justin Palmer’s new project, GitNub, which describes itself as, “a Gitk-like application written in RubyCocoa that looks like it belongs on a Mac.” This looks promising. :-)

Picture yourself and your laptop. It’s been over a day and you’re sitting on a train with a group of Rails developers with a view like this over your shoulder.

Hacking and reading on the train.

Enjoying the sceneary of the U.S.A.

Two years ago… a group of us went from Portland to Chicago for RailsConf 2006 on the Argon Express.

I know this is a tad late… but uf you haven’t purchased plane tickets to Portland yet for CabooseConf or RailsConf 2008 and would be interested in catching the train from somewhere the East Coast, email me and we’ll talk. I’m hoping to organize the Argon Express 2008 over next few weeks.

Our team has slowly been transitioning from IRC to Campfire (iPhone interface helped with this decision) for internal team discussions. Earlier today, I decided to setup Campfire to connect to Growl. There are a few scripts to do this, but I figured that I’d consolidate the steps here for my teammates and share with everyone else in the process.

Step 1: Get stuff installed

You’ll need to install the following programs on OSX.

• Growl (install and run it)
• Fluid.app (run a web site in it’s own

desktop app)
-   Follow instructions on their homepage (requires restart of
    Safari)

Step 2: Setup Campfire

Once you have everything installed, you can go ahead and create your Campfire Fluid application. You’ll need to provide your Campfire URL and a name for the application.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

Once you get it running, you should be able to run your Campfire application in it’s own window.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

Step 3: Install the Campfire Growl script for GreaseKit

Next, you’ll want to install this script, created by Tim Harper, on userscripts.org within your Campfire Fluid.app instance.

Under the Userscripts menu, you’ll see: Browse Userscripts.org.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

Find your way to the script (search for: “Campfire Growl”) to find and install the script.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

Once it installs, you’ll then need to activate it in the Fluid applications management interface. Within Campfire application, go to Userscripts > Manage Userscripts.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

Then activate it like so:

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

..and that’s it! When you’re not focused on Campfire… you should see Growl notifications when other people are talking in the active room.

A few weeks ago, I moved RubyURL from subversion to git. During that process, I decided to use my invite to GitHub and have decided to go ahead and open up the source code.

It’s currently a whopping 92 LOC with a 1:2.5 code to spec ratio. (I had a goal to keep is below 100 LOC)

• RubyURL on GitHub: http://github.com/robbyrussell/rubyurl
• Public Clone URL: <git://github.com/robbyrussell/rubyurl.git>

Feel free to grab it and help contribute. This has served almost 14 million redirects since August 2007 and is running on a Rails Boxcar.

To grab it with git.. run: git clone git://github.com/robbyrussell/rubyurl.git.

Feel free to submit tickets to the Rubyurl ticket system.

• http://planetargon.lighthouseapp.com/projects/4059-rubyurl

Enjoy!

UPDATE Ryan McGeary was kind enough to be the first person to help track down a bug and submit patches. :-)

I wanted to share something that I’ve been meaning to share on here.

When we began planning Rails Boxcar, we really want to reduce the amount of work that it took to setup and deploy a VPS for a Rails application. During this period, we began to look at the deployment process itself and began working on an interactive tool for developers for setting up their deployment environment on their Boxcar instances. So, we worked with few customers to develop an interactive Capistrano recipe.

The Goal? Spend less time configuring the server or editing recipe files.

During the initial setup, we can have the customer provide a few details from the safety of their Rails application directory by answering the following.

• What database server will you be using? (PostgreSQL or MySQL)
• What port does your database run on? (if different than the default

for your db server)

• What is your database username?
• What is your database user’s password?
• What port will your mongrel cluster start with?
• How many mongrel servers should your cluster run?

Great… setup the server and let’s deploy!

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

[Feel free to snag our interactive Capistrano2 recipe.]{.small}

We’re trying to take the pain out of deploying your Ruby on Rails applications with Boxcar.

On a side note, we’re in the process of expanding our team and recently hired Alex Malinovich. Do stay tuned as we’ll be posting important announcements about changes to our Rails hosting services in the next few weeks. (grin)

Since understanding the context is so important when designing interfaces, I wanted to point out one of those things that caused me to shake my head at.

When logging into our Basecamp account this afternoon (via openid)… I was presented the following helpful notice.

::: thumbnail
[Uploaded with plasq’s Skitch!]{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

What’s amusing in this scenario… is that I’m sure that Basecamp knows that I’m logged in via openid and it is, in fact, displaying the OpenBar across the top of the page. Yet, it’s making this helpful recommendation that I’m obviously already aware of.

What harm is there? Well, in this scenario, I caught it and thought, “wow, this isn’t helpful or informative.” Over time, it’s these short-lived experiences that affect our overall perceptions of the product.

When we’re designing and developing applications, we must be very consistent with how we communicate with our audience. We don’t need to provide them information that isn’t relevant to them.

I’m not picking on Basecamp here, I’m sure that they have great intentions with this, but as a developer, I know that it doesn’t take a whole lot of extra work to avoid small problems like this, which could lead your people to feel like you’re not being respectful of their time.

Saving customers 15-30 seconds is something that we can quantify.

• 100 customers = 25-50 minutes
• 1,000 customers = ~4-8 hours
• 10,000 customers = 40-80 hours
• etc…

Just a little reminder that it’s easy for us to overlook things like that can make a difference.

Over the past few years, I’ve helped you walk through the process of getting Ruby on Rails up and running on Mac OS X. The last version has been getting a lot of comments related to issues with the new Apple Leopard, so I’m going this post will expand on previous installation guides with what’s working for me as of January 2008.

The following guide is how our development team at Planet Argon prefers to setup our development workstations

::: warning [WARNING]{.caps}: This post contains some outdated instructions. Please read Installing Ruby on Rails, Passenger, PostgreSQL, MySQL, Oh My Zsh on Snow Leopard, Fourth Edition , which is focused on Installing Ruby on Rails on Snow Leopard. :::

During this installation, we’ll have what we feel is the optimal development stack for building Ruby on Rails applications with our favorite database server, PostgreSQL.

Ready? Let’s get started…

Just when you think that you’re sneaking through Fall/Winter without getting sick… it hits you. Been sick the last week and am finally coming up for air. :-)

Anyhow, I’m going to be traveling a few times over the coming weeks/months and wanted to reach out…

Dear Londoners,

A few of us from the Planet Argon team, (Andy, Paige, and myself) are heading to London in just over a week to visit one of our big clients. We’ll also be staying for a few more days to explore. If you’re interested in grabbing a few pints and/or interested in meeting up, drop me an email we’ll try to coordinate something when we’re over there. =)

Earlier today, Vincent Foley was kind enough to hand over maitenance of the the ShortURL project on RubyForge to me. He first released it back in 2005, which I blogged about as RubyURL was the first shortening service that it supported (and is the default). Unfortunately, the release of RubyURL 2.0 broke backwards compatibility and Vincent wasn’t maintaining it anymore. So, earlier, I decided to patch this and got a new version released that now works with the current RubyURL site.

While working on the code, I decided to extend the compatible services to include moourl and urlTea.

These updates are available in ShortURL version 0.8.4.

Install the ShortURL gem

Installation is a snap… (like 99.7% of rubygems…)

When Chris Griffin saw this post, he wanted to do the same with RubyURL. Since the ShortURL gem was broken, I didn’t get a chance to dive into it. However, with the shorturl command now working again with RubyURL, we get QuickSilver and RubyURL working together really quickly.

First, you’ll need a recent version of the ShortURL gem installed.

sudo gem install shorturl

Then you will want to add the following to ~/Library/Scripts/rubyurl.scpt. You will need to create this file.

Today, I thought that I’d give FogBugz a quick trial. A few of our Rails consulting clients use it and I’m hearing that others are as well.

Along the way, I’m bringing one of my favorite tools so that I can share some things thoughts (visually) along the way.

Signing up for a free trial

My first impression of FogBugz was, “nice homepage design… but what is that screenshot of?”

::: thumbnail
Uploaded with Skitch!{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

I’m not a designer, but the interface in the screenshot isn’t jumping out to me as something that you’d expect to see in a modern web application. While I appreciate the default browser colors for links (this is really important)… I think they could have found a better way to distinguish which bug links you’ve previously viewed. It’s very likely that you’ll most bugs many times, so having the color be different might not make sense in the same way it would when reading content on a web site. Again, I’m not a designer and I’d be curious to hear from a designer on this. Just something that I initially thought.

::: thumbnail
Uploaded with Skitch!{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

Okay, this sign up form seems really easy to start with. I’m used to free trials being really simple to get going. So, I enter in my sub-domain selection and provide my email address on the following page so that they can confirm that I’m legit.

(several minutes later…)

Okay, this process required me to jump from my browser to my email to my browser back to my email and then back again to my browser. It’s really frustrating for an application to force me to go back and forth between my browser and email client. I think the initial email is something I can cope with, but I found it a bit silly to have to wait for another email to receive a link to login to my new account, especially considering I already knew the URL as that was the first thing that I provided. The application could have provided the link (or redirected me) to the following form, which I had a few things to comment on.

::: thumbnail
Uploaded with Skitch!{style=”font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080”} :::

At first glance, this might not seem like much… but I’m becoming more and more disappointed by the choice of language that we’re using in applications. First of all, this is the first time that I’ve seen this page. I’m not changing my password… what you’re really asking me to do is, “Create (or set) a password.” There are other verbs that you could use here, but change really isn’t appropriate. Also, choose doesn’t work here either.