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.

First of all, Happy New Year!

The other day I received an email from a friend where she asked me if I thought that having excellent math skills were important in a programmers career. I’ve heard this question asked before and while I thought that might have been the case when I was a lot younger (when I had zero plans to go into the IT world)… I’ve not seen this to be true. My response to her was that it really depended on the types of programming work that one might want to go into. There are definitely programming jobs that require extremely advanced mathematical skills, but I’d guess that many, if not most, don’t really have that sort of prerequisite.

So, as I was saying. I think it really depends. It depends on what sort of programming you’re interested in pursuing. In general, when we’re looking to hire someone at Planet Argon, we’re looking for people with good research and problem solving skills. Programming languages are tools to help solve problems and build things. So, while math skills are useful, they aren’t likely going to make or break a developer.

Like any career, it should be something that you’re passionate about.

I’m curious. As programmers… how would you respond to the following question?

“Should an advanced knowledge of mathematics be a prerequisite in pursuing a career in programming?”

I can only answer the question from my own perspective and would like to share some others. Thanks!

Are you using PostgreSQL (the world’s most awesome open-source database server) with Ruby on Rails Do you have any interesting experiences that you might want to share with an audience? Well, you might consider submitting a talk proposal for PGCon 2008, which is taking place in Ottawa, Canada.

Details follow…

PGCon 2008

PGCon 2008 will be held 22-23 May 2008, in Ottawa at the University of
Ottawa. It will be preceded by two days of tutorials on 20-21 May
2008.

We are now requesting proposals for presentations.

If you are doing something interesting with PostgreSQL, please submit
a proposal. You might be one of the backend hackers or work on a
PostgreSQL related project and want to share your know-how with
others. You might be developing an interesting system using
PostgreSQL as the foundation. Perhaps you migrated from another
database to PostgreSQL and would like to share details. These, and
other stories are welcome. Both users and developers are encouraged
to share their experiences.

Here are a few ideas to jump start your proposal process:

• novel, unique or complex ways in which PostgreSQL are used
• migration of production systems to PostgreSQL
• data warehousing with PostgreSQL
• tuning PostgreSQL for different work loads
• replicating data on top of PostgreSQL

Both users and developers are encouraged to share their experiences.

The schedule is:

• 19 Dec 2007 Proposal acceptance begins
• 19 Jan 2008 Proposal acceptance ends
• 19 Feb 2008 Confirmation of accepted proposals
• 19 Apr 2008 Final papers/slides must arrive no later than this date

See also http://www.pgcon.org/2008/papers.php

Instructions for submitting a proposal to PGCon 2008 are available
from: http://www.pgcon.org/2008/submissions.php

This