Ruby is one of the languages I use on a regular basis. Unfortunately, the proliferation of interpreters and gems can be hard to keep under control. One of my goals with the new system was to improve this process.

This posts documents the commands I executed, for future reference.

Mac OS X 10.7 Ruby Environment

Before we get started, let’s inspect the standard Ruby install that ships with Mac OS X 10.7.

$ which ruby
/usr/bin/ruby

$ gem environment
RubyGems Environment:
- RUBYGEMS VERSION: 1.3.6
- RUBY VERSION: 1.8.7 (2010-01-10 patchlevel 249) [universal-darwin11.0]
- INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8
- RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
- EXECUTABLE DIRECTORY: /usr/bin
- RUBYGEMS PLATFORMS:
- ruby
- universal-darwin-11
- GEM PATHS:
- /Library/Ruby/Gems/1.8
- /Users/jaredhanson/.gem/ruby/1.8
- /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://rubygems.org/


Install RVM: Ruby Version Manager

RVM is a tool that allows us to work with multiple Ruby environments, including different interpreter versions and sets of gems.

Install it just as the instructions recommend:

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)


The installation script will output useful messages, explaining exactly what it is doing and offering hints about what to do after installation is complete. The one critical thing to do is source the rvm script, so that the command is available in the shell. I keep this in my dotfiles, so it is always available. You can also source it temporarily in the current shell by executing:

$ source "$HOME/.rvm/scripts/rvm"


Install Ruby

Now that RVM is installed, we can proceed to install local versions of Ruby. To minimize differences, I first install the same version of Ruby shipped with the OS. RVM makes it easy to install and switch to newer version later.

$ rvm install 1.8.7
$ rvm use 1.8.7


Now, the version of Ruby in use is completely isolated from the system.

$ which ruby
/Users/jaredhanson/.rvm/rubies/ruby-1.8.7-p352/bin/ruby
$ which gem
/Users/jaredhanson/.rvm/rubies/ruby-1.8.7-p352/bin/gem


Rake is my most utilized Ruby-based utility, so that is first on my list to install.

$ gem install rake
/Users/jaredhanson/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/1.8/timeout.rb:60: [BUG] Segmentation fault
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-darwin11.0.1]

Abort trap: 6


Damn.

Install Ruby with GCC 4.2

Mac OS X 10.7 is using an LLVM-based compiler by default, which is causing trouble. Luckily, a solution can be found on Stack Overflow.

RVM makes it easy to remove the broken installation of Ruby:

$ rvm remove 1.8.7


Installing Ruby 1.8.7 with plain (non-LLVM) gcc fixes the issue:

CC=/usr/bin/gcc-4.2 rvm install 1.8.7


Gems can now be installed successfully:

$ gem install rake
Fetching: rake-0.9.2.gem (100%)
Successfully installed rake-0.9.2
1 gem installed
Installing ri documentation for rake-0.9.2...
Installing RDoc documentation for rake-0.9.2...

$ which rake
/Users/jaredhanson/.rvm/gems/ruby-1.8.7-p352/bin/rake


Conclusion

RVM is now installed, and can be used to manage multiple Ruby environments. Additionally, gemsets can be used to manage which sets of gems are available in each environment. This is a much cleaner and more flexible way to manage a Ruby development system.

Key to setting this up was using nvm, which stands for Node Version Manager. This let’s you run multiple versions of Node, each in an isolated environment. I currently have v0.2.6 and v0.4.0, and can easily switch between them. This makes it easy to update to the latest release, while still being able to fall back to the previous release when using modules that are not yet compatible with v0.4.0.

It’s worth noting that nave (Virtual Environments for Node), is an alternative to nvm. In fact, nave was recommended by Aaron Blohowiak at the last SF JavaScript Meetup I attended.

In comparing the two, one thing stood out to me. From nave’s credits:

Nvm is also really nice, but has to be sourced rather than being run, and thus is a little bit wonky for some use cases. But it doesn’t involve subshells, which makes it better for many others.

I’m comfortable sourcing things in my shell, and the concept of subshells didn’t quite sit well with me on first impression. So, I went the nvm route. It’s worth paying attention to both however, as neither is yet the de-facto Node version manager.

OK, let’s get into the details of installing and using nvm. First, we will install nvm using the recommended instructions. Clone the nvm repository into a .nvm directory.

$ git clone git://github.com/creationix/nvm.git ~/.nvm

nvm itself is just a shell function, which needs to be sourced in order to be available. To have it sourced in every terminal you open, put the following line in .bash_profile:

. ~/.nvm/nvm.sh

Since I was previously using v0.2.6 as my primary version of Node, I wanted to ensure that I also had that version available under nvm. The install process is as simple as stating which version is wanted.

$ nvm install v0.2.6

In my initial attempt, I got the following error: -bash: wget: command not found. Wget isn’t available by default on Mac OS X, and for some reason I hadn’t previously installed it. It’s a standard utility, however, and easy to install. Download wget-1.9.1.tar.gz and execute the following:

$ tar xvzf wget-1.9.1.tar.gz
$ cd wget-1.9.1
$ ./configure
$ make
$ sudo make install

With that problem resolved, we can reattempt installation of v0.2.6.

$ nvm install v0.2.6
$ which node
/Users/jaredhanson/.nvm/v0.2.6/bin/node

As you can see, nvm installed v0.2.6 into the .nvm directory it manages. You can also see the structure it sets up to allow for simultaneous installation of multiple versions. This is what we want.

This is like a fresh installation of Node, so we also need to reinstall npm and any additional modules we are using. This is done in the usual manner.

$ curl http://npmjs.org/install.sh | sh
$ which npm
/Users/jaredhanson/.nvm/v0.2.6/bin/npm

$ npm install connect

When modules are installed under an nvm environment, they are installed only for the version in use. You can see them by listing the contents of the version’s lib directory.

$ ls ~/.nvm/v0.2.6/lib/node
connect       npm        qs       wafadmin
connect@0.5.9 npm@0.2.18 qs@0.0.5

Now that we have recreated the v0.2.6 environment, including necessary modules, it is time to install v0.4.0.

$ nvm install v0.4.0

Easy. We can list the versions of Node we have installed using nvm ls.

$ nvm ls
v0.2.6
v0.4.0 *

With nvm use, we can switch between versions.

$ nvm use v0.2.6
Now using node v0.2.6
$ nvm use v0.4.0
Now using node v0.4.0

With v0.4.0 freshly installed, you’re probably eager to execute your application and see what happens. This eagerness will bite you though, resulting in something that looks like the following.

$ node main.js
...
Error: Cannot find module 'connect'
...

Remember, each version of Node managed by nvm maintains its modules separately from other versions. Each time you install a new version, you’ll also have to repeat the process of installing the modules you need using the usual npm install command.

$ npm install connect

This may seem like unnecessary bookkeeping, but it is in fact a good thing. New versions of Node introduce API and ABI changes that can break compatibility with existing modules. With modules associated with specific versions of Node, development is easier because compatibility issues are easier to isolate.

The numbers give you a sense of the enormous impact technology has on the world.

Technology’s most obvious impact has been on the way we communicate. Take a look at the numbers pertaining to email, blogging, and tweeting.

• 107 trillion emails were sent last year
• 152 million blogs are active today
• 50,000 blogs get created every single day
• 25 billion tweets were broadcast last year
• 150 million people use Twitter

Technology companies, harnessing network effects, have reached the size of the largest governments and economies in the world. This will have profound impacts on society, and only now are we confronting these issues.

• The combined market capitalazation of IBM, HP, Microsoft, Apple, and Google is $1 trillion
• 14 countries have a GDP more than $1 trillion
• 190 countries have a GDP less than $1 trillion

• If Facebook was a country, it would be the 3rd largest in the world
• 650 million people have accounts on Facebook
• Facebook is projected to reach 1 billion accounts later this year

While people are increasing connected to the network, machines are as well. Data collected from sensors is increasing at an enormous rate.

• The Large Hadron Collider collects 1TB of data per second

At the same time these numbers are increasing, the time it takes to adopt new technology is decreasing.

• Radio took 38 years to reach 50 million people
• TV took 13 years to reach 50 million people
• The Internet took 4 years to reach 50 million people

The video is full of interesting statistics. Imagine what the statistics will be in 5 or 10 years.

/via O’Reilly Radar

It’s an extra step, but it’s one that significantly improves the security of your Google Account because it requires the powerful combination of both something you know—your username and password—and something that only you should have—your phone. A hacker would need access to both of these factors to gain access to your account.

That important security enhancement is garnering a lot of attention. What I find interesting is the point that only got a sentence’s mention.

You can also set up one-time application-specific passwords to sign in to your account from non-browser based applications that are designed to only ask for a password, and cannot prompt for the code.

This sounds an awful lot like PAuth, which Don Park suggested as an alternative to OAuth over two years ago. I’ve always wondered why that didn’t get more attention.

First things first, you’ll need to have a GitHub account, associated with your SSH public key for authentication. I had done that previously, according to GitHub’s helpful instructions. In fact, GitHub has done a terrific job of documentation, and I highly recommend reading through Help.GitHub if your are new to either Git or GitHub.

With that out of the way, we can get on with the business of forking a project. Each project on GitHub has a Fork button. Clicking it will create a forked repository in your account.

Now that we have a forked repository, we can begin developing.

First, clone the repository to your development system.

$ git clone git@github.com:jaredhanson/Locker.git
$ cd Locker

Let’s examine the clone a bit.

$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master

$ git remote -v
origin git@github.com:jaredhanson/Locker.git (fetch)
origin git@github.com:jaredhanson/Locker.git (push)

You can see from this that we have a local master branch, and a remote master branch. The remote branch is aliased to origin, and its location is your account’s repository.

We are going to want to track changes from the original project, so lets add it as a remote repository, aliased to upstream, and fetch it.

$ git remote add upstream git://github.com/quartzjer/Locker.git
$ git fetch upstream

At the time I first forked the project, there were bugs, some of which were fixed by Philip Harrison in his fork. So, we are going to add that fork as a remote repository, fetch it, and merge the changes in.

$ git remote add harrison-github git://github.com/Harrison/Locker.git
$ git fetch harrison-github

Before merging the changes, however, we are going to make a local branch in which to do our work. This branch allows us to isolate our modifications, eliminating any worry about making the master branch unstable. This is typical in Git workflows, because branches are cheap to create and easy to merge. We will call our branch session-secret, which is descriptive of the work we will be doing on it.

$ git branch session-secret
$ git checkout session-secret

Now that we have switched to a new branch, we will merge in the changes.

$ git merge harrison-github/connect_secret
Auto-merging Ops/Dashboard/dashboard.js
Auto-merging locker.js
Merge made by recursive.
Ops/Dashboard/dashboard.js | 2 +-
locker.js | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

We can see that changes to two files were merged into the branch. However, there are some more session secret-related bugs that I know about, so I’m going to go ahead and fix those myself. Once I’ve completed that work, I can check the status of the repository to see what has been modified.

$ git status
# On branch session-secret
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: Apps/HelloWorld/hello.js
# modified: Apps/MergedContacts/contacts.js
# modified: Connectors/AmazonHistory/server.js
# modified: Connectors/ChromeHistory/client.js
# modified: Connectors/Facebook/client.js
# modified: Connectors/Flickr/client.js
# modified: Connectors/IMAP/demo.js
# modified: Connectors/Twitter/client.js
# modified: Connectors/Twitter/pull_contacts.js
# modified: Connectors/foursquare/client.js
# modified: Contexts/facebook.js
#
no changes added to commit (use "git add" and/or "git commit -a")

I’ve modified some files with bug fixes, which I’ll add and commit.

$ git add -u
$ git commit -m “Add session secret, which is now required by Connect."

With all the fixes applied to the branch, we can now push the branch to GitHub. Once the branch is available there, GitHub provides tools to submit pull requests, allowing the maintainer to bring changes from our fork into the upstream repository.

$ git push origin session-secret

Our work on that branch is complete. We’ve tested it and are satisfied that the changes are stable, so let’s merge them into the master branch.

$ git checkout master
$ git merge session-secret

Now let’s do a quick review of the changes between our development system and our GitHub repository.

$ git diff origin/master

The changes look OK, so let’s push the master branch up to the origin repository.

$ git push origin master

With everything up-to-date, our work is a wrap.

Since Friday, development on the upstream repository has continued. My changes have been pulled in, and changes from other developers have been committed.

Let’s fetch the upstream repository and review the changes.

$ git fetch upstream
$ git diff upstream/master

The changes pass our review, so we will merge them straight into our master branch.

$ git merge upstream/master

Now, let’s examine the status of our local clone. Since we just pulled in changes from the upstream repository, our forked repository on GitHub is now out-of-date.

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

It’s our goal to track changes as closely as possible, keeping all repositories up-to-date, so let’s go ahead and push the new changes into our repository.

$ git push origin master

Since we are tidying up, we will also delete our session-secret branch from both the local and remote repository. The changes it contained have been merged into the upstream repository, so the branch is no longer needed.

$ git branch -d session-secret
$ git push origin :session-secret

Habits die hard with me, especially when a certain amount of nostalgia is involved, so I’m still using Firefox as my primary browser. However, I’m deeply impressed with Chrome, both as a user and as a developer, and have been meaning to make the switch for a while.

I’m feeling the a sense of urgency to do so now, if only to wrap my mind around what is occuring with Chrome OS and Chrome Web Store. Both of these projects raise a lot of questions, and cause a lot of confusion, because they represent some fundamental shifts in how we experience the web.

Chrome OS is the most nebulous of these projects. What does it mean for the browser blur the lines into OS and window manager? How does it relate to Android? Even Google seems a bit hazy with its answers to these questions, so I’m willing leaving them open until the air clears.

Chrome Web Store is a reality today, however, so I’ve been trying to understand what impact it may have. What I’m most struck by the tension between the web and apps.

As content has moved into the cloud, interaction has moved into the browser, and applications have become hosted remotely. Google is a primary beneficiary of this trend, and they’ve been leading the way in adopting Ajax technologies (combining HTML, CSS, and JavaScript), and encouraging others to do so as well.

Apple, with iOS and the App Store, offers a platform that reverses the trend in some ways. Content often remains in the cloud, but applications are installed locally and interaction moves to the device. Development, using Objective-C and Cocoa frameworks, follows a more traditional approach from the desktop era, but carried forward into the mobile future.

I think much of this tension is created by the use of technologies with such traditionally different uses. Desktop development has always been application-centric, whereas web development has historically been document-centric. HTML5, continuing the trend started by Ajax, brings a full-fledged application framework to the browser.

Yet, in many cases, we are still struggling cleanly categorize these technologies based on past notions. For example, read this explanation Google offers when defining the concept of apps in the Chrome Web Store documentation:

An installable web app can be a normal website with a bit of extra metadata; this type of app is called a hosted app. Alternatively, an installable web app can bundle all its content into an archive that users download when they install the app; this is a packaged app. Both hosted and packaged apps have icons in Chrome’s New Tab page, and most users shouldn’t be able to tell the difference between them without looking at the address bar.

Note the need to explicitly define the difference between a local (packaged) app and a remote (hosted) app.

The nature of the web is rapidly changing. Constant connectivity means we, as developers, get to shift content storage and data processing between the server and client in any number of ways. A broad continuum exists that will defy efforts at categorization. Instead, we should strive to understand the nuances of each approach and balance them according to application requirements.

This train of thought was sparked by an article on TechCrunch in which John Biggs points out the confusion between sites, apps, widgets, and whatnot. He closes with this advice:

What needs to happen is this: folks like Netflix need to build XBox and Roku-like apps for Chrome and Chrome OS. This will allow users to browse, select, and watch movies from their browsers.

Let’s remind ourselves that people don’t know what a browser is, and that specific technologies don’t matter. The web encompasses everything, and it is very much alive.

The pair shared power at Apple until Jobs was forced to resign after losing a power struggle. Apple’s struggles after that time brought it to the brink of its existence, until Jobs returned in 1997 and revitalized the company he founded. Regarding the timing, Scully remarks:

I’m actually convinced that if Steve hadn’t come back when he did — if they had waited another six months — Apple would have been history. It would have been gone, absolutely gone.

What did he do? He turned it right back to where it was — as though he never left. He went all the way back.

As evidence of that, this video (via Jason Kottke) highlights one of Jobs’ first tasks after taking back the helm: getting Apple on track with their branding.

Jobs goes all the way back to Apple’s core value, which he defines:

We believe that people with passion can change the world for the better.

From there, he uses his brilliant marketing talents and introduces the memorable “Think different.” campaign.

Think different honors those people who have changed the world.

The commercial is inspiring. I’m capturing it here, because it is worth reflecting on.

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes.

The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them.

About the only thing you can’t do is ignore them. Because they change things. They push the human race forward.

And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.

Many businesses tout themselves as radical and disruptive. This is especially true in places like the Bay Area, where small startups with fast-paced, development-driven cultures are trying to develop the next innovative technology.

Building a startup into a successful company requires growth in many areas, including employees and customers. This growth brings with it significant challenges, which often require a difficult transition in how the company operates. As leadership and management functions evolve in an organization, it’s important to retain the same culture of innovation.

The questions asked by MIX are intended to be thought-provoking, as they aim to reinvent management for the 21st century. Indeed, I found them interesting enough that I decided to collect them here.

What if…

we were led by values rather than controlled by bosses?

your company felt less like a bureaucracy and more like a community?

you could offer a dissenting opinion without jeopardizing your job?

we didn’t go to work for a company but dedicated ourselves to a cause?

we spoke the language of honor, truth, love, justice, and, beauty inside our organizations?

the short-term didn’t always trump the long-term and the urgent never displaced the important?

our organizations were truly open to the world?

decision-making reflected more collective wisdom and less politics?

power flowed to those who add value and away from those who don’t?

making a difference was just as important as making the numbers?

our management systems were designed to amplify imagination and unleash contribution?

work felt like play?

the only way to win was to figure out a way for everybody to win?

our companies were as human as the human beings inside them?

people spent a lot less time cutting red tape and a lot more time inventing the future?

you didn’t need permission to try something new?

management education was designed to enlighten and ennoble as much as to promote?

our organizations were highly adaptable, endlessly inventive, and truly inspiring?

management values matched up to management behaviors?

direction came from the bottom-up and the outside-in as much as from the top-down?

organizations grew without losing human scale?

we had such a compelling sense of purpose it would spell the end of micromanaging?

your company’s measurement systems captured the things that really create value?

every leader in your company was someone actually worth following?

our organizations actually deserved the very best that every employee can give?

more people in your company challenged the status quo than defended it?

big ideas were never squashed by little minds?

your company had no secrets from you, its customers, the world?

leaders placed as much emphasis on experimentation as on planning?

authority and influence had nothing to do with your hierarchical postion and everything to do with your ability to lead?

innovation was something that happened because of the system, rather than in spite of it?

every company was great at discovering great ideas and contributions from beyond its borders?

leaders dropped “command and control” for “motivate and mentor”?

our work answered the question, “What’s worth my life?”

people inside companies were freed by trust instead of ruled by fear?

we valued diversity, disagreement, and divergence highly as conformance, consensus, and cohesion?

As I was reading the questions, I couldn’t help recalling the ideas of Umair Haque, whose articles on strategy seem designed as answers to many of the questions asked. That’s no surprise, as Gary Hamel, who Haque cites as a mentor, is one of the people behind MIX.

There are some real gems in there. Let me know your favorites in the comments.

The Rails community is still catching up to the recently released Rails 3. RSpec, which the tutorial recommends for testing, is no exception. RSpec 2 is the latest version, and the first to bring compatibility with Rails 3. However, I’m finding that there are still a few kinks that need to be worked out.

Most of the issues I’ve encountered have been easy to solve. However, I encountered a particularly frustrating problem dealing with the interrelation between rspec-rails and webrat, which is described in this issue. It is a known problem that has been variously fixed and re-broken by commits to the two libraries in question.

When executing an integration test using the following code:

describe "LayoutLinks" do
  describe "GET /" do
    it "should have a Home page at '/'" do
      get '/'
      response.should have_selector('title', :content => "Home")
    end
  end
end


A failure is reported:

Failures:
  1) LayoutLinks GET / should have a Home page at '/'
     Failure/Error: response.should have_selector('title', :content => "Home")
     stack level too deep
     # ./spec/requests/layout_links_spec.rb:8


I haven’t traced down the exact issue, but it appears to be caused by webrat 0.7.2, and its interaction with both rspec-rails 2.0.1 and 2.1.0. I attempted upgrading to webrat 0.7.2.beta.2, but that did not resolve the issue. However, downgrading to webrat 0.7.1 did.

Simply specify the following in your Gemfile:

group :test do
  gem "webrat", "0.7.1"
end


Execute bundle install to use webrat 0.7.1 and the error will be resolved.

Developers can register for an invitation to the SkypeKit Beta Program beginning on July 23.

So, let me get this straight. You’re announcing that I can sign up for a future announcement. Gee, thanks!

Despite the fact that this behavior disillusions me, I understand the pragmatic reasons why people in Skype’s management and marketing department would be motivated to do this.

Skype’s announcement coincides with the imminent release of iPhone 4. In the past few years, Apple has dramatically changed the communications landscape with the iPhone. The latest device includes the biggest revolution since the original iPhone: FaceTime, which allows iPhone-to-iPhone video calling. Incidentally, FaceTime also represents the biggest threat Skype has ever encountered.

FaceTime is set to catapult VoIP straight into mainstream mobile devices, using IETF-approved open standards SIP and RTP. Apple has promised to make their extensions open as well. When that happens, FaceTime will proliferate on applications and devices other than the iPhone. Skype, meanwhile, has let innovation stagnate around an entrenched, but proprietary protocol. The leverage they hold in the protocol is about to be eliminated.

They know it too. Let’s look at the initial statements given in response given to the “open” question:

Is SkypeKit ‘open’? What will you restrict?
The topic of openness is often debated and its definition can mean different things to different people. For starters, we believe in an open Internet and open standards.

Next time, just answer “no.” If you believe in open standards, back it up by providing protocol specifications. At this point, it’s tough for me to look at what Skype is offering and see it as the future of communications. Open standards have marched forward, while Skype has stood still.