Tonight, I found the need to provide a way for our members to list their social networks should they choose to do so. The obvious way was to add a list of anchor tags. I found this to be rather distasteful. I mean, we are dealing with Ruby here, right? So, I started by considering what I wanted the UI code to look like. Would do I want to have to work with on a weekly basis. I came up with the following:

This would allow me to add as many usernames and networks as I desired. Perfect! So I began to work on the code that would make this function as intended. I came up with the following:

So, basically, I list all of the networks I want to use. This list not only includes the URL (and a place holder for the username), but any prefix or suffix for the displayed username for which I might find a need (i.e.: Twitter's "@" in "@slant") Next, the script iterates through my list, catching each network as it does so. Each time the script reaches a network, it proceeds through each username in the list, building an appropriate anchor tag for each one.

In the end, you have a beautiful categorized list of usernames, each linking to their respective page.

Luckily, I walked out of the installation process unscathed for the most part with only a few minor issues to deal with.  One example would be that Phusion Passenger was no longer working – but mongrel was – so that was livable.  Realizing that I'd not yet setup a decent database for development since getting my new MacBook Pro, I set to work on basically reinstalling the entire Rails stack to ensure that everything would be ready to roll when I get back to work on Monday.

I found a few fantastic resources to guide me through the majority of what I was looking to do including Hivelogic's guide on Compiling Ruby, RubyGems, and Rails on Snow Leopard as well as another guide on Compiling Git on Snow Leopard.  I also found some great information on installing PostgreSQL on Snow Leopard. Lastly, I discovered a very short guide on compiling the PostgreSQL RubyGem for use on Snow Leopard (enabling 64bit compatibility).

Equipped with these guides, I successfully got everything upgraded and am now waiting for all of the other 10.6 bugs to pop up!

edit: A definitive guide in deed. I just found a guide for those of you who want to install things like MySQL and SQLite as well.

During the presentation, we each explained our frameworks on a surface level followed by a brief demonstration of how each framework accomplished a few of the things that our applications did.

Jay's presentation can be found here and his Django application here.

My presentation can be found here and my Rails application here.

Overall, I absolutely believed this presentation to be a success!  I'd like to see other frameworks and languages go head to head like this in the future.  I feel like the ability to see two frameworks side by side was a real benefit, allowing a clearer look at how each works with respect to the other.

I needed to iterate through the values of a Hash. So I called .values on the Hash in question. What was interesting about this had nothing to do with the results of calling this method, but instead what it was actually doing to the Hash.

>> myhash = { :first => "one", :second => "two", :third => "three" }
=> {:second=>"two", :first=>"one", :third=>"three"}

The myhash how has a class of Hash, which is to be expected, since that's what I gave it.

>> myhash.class
=> Hash

When .values is called, it returns all of the values in the Hash.

>> myhash.values
=> ["one", "two", "three"]

You may have noticed this in that last example, but when .values was called on that Hash, the class of the result changed altogether. Let's examine the class of this Hash while we are calling .values on it.

>> myhash.values.class
=> Array

So calling .values on the Hash literally built an Array with the values from the preceding Hash!

Read more about Hash#values in the Ruby Documentation.

Another solution does exist. This one is internal to git itself. Due to that fact, the two main benefits are a shorter load time when starting a new shell (since you're not dealing with alias entries in your .profile script) and easier git-centric configuration.

Simply add the following to ~/.gitconfig:

[alias]
  co = checkout
  st = status
  br = branch
  ba = branch -a

Now instead of typing git checkout branch you only need to type git co branch. You can customized these as much as you'd like, adding other commands as well, as long as the command after the equals sign is a valid git command.

The obvious down side to this method is that you have to type git before these aliases. Using the other method, you do not.