How to install the Go programming language on OSX Snow Leopard

Assumptions

Before you follow these steps, you should have XTools installed. You should also be running Snow Leopard as your OS.

These instructions should also work for Leopard, although you may have to use GOARCH=386.

All of these steps will be performed in Terminal

Step 1 - Directories and Environment Variables

Google Go has a number of environment variables that are required when running: $GOROOT, $GOOS, $GOARCH and $GOBIN. You can find out more about these variables at by reading Go’s general installation document.

For our purposes, we are going to use the following settings:

GOROOT=$HOME/Go<br /> GOOS=darwin<br /> GOARCH=amd64<br /> GOBIN=$HOME/bin<br /> You can use the following command to automatically place them at the end of your ~/.bashrc file:

cat >> ~/.bashrc <<EOF

export GOROOT=\$HOME/Go
export GOOS=darwin
export GOARCH=amd64
export GOBIN=\$HOME/bin
EOF

Now use the source command to apply those changes to your current session:

source ~/.bashrc

Also, we have to create the bin directory and add it to your system paths:

mkdir -p $HOME/bin
echo "$HOME/bin" > go
sudo mv go /etc/paths.d/
eval `/usr/libexec/path_helper -s`

For more information on the /etc/paths.d/ setup in Leopard, you can read this blog post on paths.

Step 2 - Getting The Source

Google is using Mercurial to handle the source code. If you don’t already have it installed, you can install it quickly and easily with the following command:

sudo easy_install mercurial

This will automatically install the mercurial package on your system. Once that is done, you can run the hg command to checkout Go’s source:

hg clone -r release https://go.googlecode.com/hg/ $GOROOT

The source code will be checked out to the $GOROOT that we specified in the .bashrc settings.

Step 3 - Installation

From this point on, you’ve done the custom OSX bits. The following are essentially the same instructions as Go’s official installation document.

Head over to the $GOROOT src directory and then run all.bash, the installation script:

cd $GOROOT/src
./all.bash

Once the installation is done, you should see the following output at the end:

--- cd ../test
N known bugs; 0 unexpected bugs

This means you’re ready to start writing and compiling Go. Congratulations!

Optional Step 4 - Quick compile and linking script

I created a very simple bash script called go that compiles and links the file in one step. You’re welcome to add this as an addition to your commands. Just run the following command to set it up:

cat >> $GOBIN/go <<EOF
#! /bin/bash
if [ ! \$1 ]; then
  echo "Usage: go name_of_file (without the .go)"
  exit
fi
6g \$1.go
6l \$1.6
EOF
chmod +x $GOBIN/go

Now you can compile and link in one go ( *snicker* ). If your filename is hello.go, you can use it like this:

go hello

Nice ‘n easy. :)

I was having a heck of a time with .to_json in Merb. Turns out, it was because Merb’s to_json implementation doesn’t work the same as ActiveRecords.

In order to get it working, I had to disable the Merb one by placing the following code at the top of my init.rb file:

Merb.disable :json

Just thought I’d share. :)

I host all of my Git repositories on a box that has a different port than normal SSH connections use, which causes git checkouts to be a bit of a pain in the butt.

So, in order to deal with this, any computer I plan on continually using for Git access, I add to the git user’s authorized_keys list. Here is the step by step I use to make it easy.

All of these commands are performed on the computer I want to grant permission to.

First, make sure I have a public ssh key.

cat .ssh/id_rsa.pub

Now, lets copy that public key to the Git server.

scp -P 8888 .ssh/id_rsa.pub git@YOUR_SERVER_ADDRESS:~

Using a remote SSH command, lets append our id_rsa.pub file to the authorized keys list, and then delete the file since we won’t be using it anymore.

ssh -p 8888 git@YOUR_SERVER_ADDRESS "cat id_rsa.pub >> .ssh/authorized_keys; rm id_rsa.pub"

Test the connection to make sure we can connect without a password. Just ssh and then exit immediately if it worked.

ssh git@YOUR_SERVER_ADDRESS -p 8888

Alright, so once that works, you have permission… but it still doesn’t deal with the port problem. To do that, we will create a .ssh host in the config file.

vi .ssh/config

You want to add something that looks like this:

host myserver
hostname YOUR_SERVER_ADDRESS
user git
port 8888

Once you’ve done that, save the file and exit.

Now, you should be able to clone your git repo without any problems. No more passwords, no more long git urls. Just beautiful simplicity.

git clone myserver:commentize.git

So, after totally falling in love with ModRails (Phusion Passenger) a few months back, I was looking at their “Enterprise Edition” and began wondering how much they had made so far with their free software…

Luckily, I had Ruby and Hpricot handy. I opened up IRB and ran the following code:

require 'hpricot'
require 'open-uri'
doc = Hpricot(open('http://www.modrails.com/enterprise.html'))
(doc/"tr/td").collect { |td| td.inner_html.scan('USD').empty? ? nil : td.inner_html.sub('USD ','').to_i }.compact.inject { |s,n| s + n }

To date, they have made $20,700 in donations! Not bad for two guys and some “free” software.

The language of the land

Just hangin around

I made dinner for some of my friends in Mexico CIty last night and while I was plating everything one of them asked me why I started cooking. My standard response was that it’s a great way to get my head off of writing code and that it’s so much different than what I do every day.

Later that night, while cleaning up, I thought about it some more and it really isn’t that much different. The thing that I think I like about it is that it’s a finished product every time. Other than that, it’s actually quite similar to what I do for work.

1) Project Planning

* What will I be cooking? (Overall Concept)
* Who am I cooking for? (Intended audience)
* Does anyone have allergies I should know of? (Accessibility concerns)
* What time is everyone arriving? (Scheduling)
* What if something doesn’t turn out right? (Contingencies)

2) Actual Cooking

When you’re actually cooking, you can find better ways to make something just like when you’re coding. You can re-use dishes and combine ingredients to make a custom result. You really have a lot of flexibility within a semi-constrained set of guidelines (flavor).

On top of that, you have things to consider:

* What order do things need to be cooked in? (Planning)
* Do I have all the tools I need? (Resource Allocation)
* Do I know how to cook everything? (Skills Requirements)

3) Plating and Setup

Inevitably, if you’re cooking a big meal, the kitchen is in a bit of chaos at this stage. Now comes the decoration. This is what your guests are actually going to see. You plan out your presentation, set the plates up and lay everything out so that it is well accepted by your guests.

No matter how messy the process was, if the plating looks good and the food tastes great you’ve done well. Just like with any project though, you can have ugly presentation for great food or great presentation on crappy food. Finding the best of both worlds is tricky, but very rewarding.

3) Cleanup

This is where you take away all the mess caused by the cooking process. Get rid of the excess, wash the pots to give them a break and get them ready for the next time you need them, and get your working space back in order.

The end result is that you have an entire project from concept to completion done in one day. I think that it’s important for people to feel a sense of accomplishment and completion. In my industry, projects range from a few week to a few months, and others seem like they never end. Cooking provides that feeling for me.

Now that’s a well designed car

sudo mongrel_rails cluster::restart -C /etc/mongrel_cluster/file.conf