HappyGastropod.com

Lessons From Highfive Tuesdays

2011-08-01T00:00:00-04:00

For those of you unaware, at InMotion Hosting we had a month of Highfive Tuesdays. This was a weekly competition to see who could highfive the most people. I wrote a Rails application to keep track of who highfived who, and their corresponding “highfive points”. At the end of the day, the winners received lame prizes (like palm tree shaped water bottles, and pez dispensers). It was a lot of fun.

This idea was born out of the awkward growing phase InMotion had gone through. We had turned into a middle school lunch room, where each department knew nothing of the people outside of itself. It was bad. We wanted to get people to leave their little bubbles, and meet their co-workers. Highfiving them seemed to do the trick. It worked.

Interestingly, the overall productivity of our support team and our system admin team increased during these tuesdays. My hypothesis here is quite basic (and possibly obvious). Highfive Tuesdays made people happy. When people are happy, they are able to work better.

Overall, the experiment was a success. Together, over 1,000 highfives were dished out, we banished the awkward avoidance tactics in the breakroom, we demonstrated a basic concept (happy people = good workers), and we had some fun along the way.

If you would like to give Highfive Tuesdays a try at your office, I have open sourced the code, which you can grab on my github. And if you need a hand deploying it, just hit me up on twitter and I’ll be glad to help.

July CVREG Meetup

2011-07-10T00:00:00-04:00

Last night was the July CVREG meetup, and the 757rb regulars decided to take a road trip to visit the Legend Brewery, and talk Ruby with our Richmond friends. The theme of the evening was Ruby’s role in doing freelance/contract work. They had a panel of four self-employed Rubyists who answered some questions about working with Ruby as a one-man-shop.

One of the interesting questions that came up was “Is it difficult to ‘sell’ Ruby to clients?” All of the members of the panel had experienced at least one client who was scared off by the fact that they were using Ruby. It goes to show that despite the hard work put in by so many in the Ruby community, and the so blatantly obvious golden beacons that show Ruby does scale (Github, Gowalla, all 37signals products, etc.), a few strategic “RUBY IS SLOW” statements have seriously devastated the public understanding of the language.

Demonstrating that it works, providing benchmarks that smack down PHP, and showing that we can develop applications faster with Ruby don’t matter. The fact that Ruby is “weird” and “slow” make it a non-starter for so many. So what can we do to make Ruby more accepted?

A Centralized Boom Server Using Redis

2011-03-25T00:00:00-04:00

So, I’ve been thinking how cool it would be to setup a collaborative Boom database. With its recent support for Redis and MongoDB, I figured it was a good time to give this crazy idea a whirl. So, let’s run through the basic requirements to set this up. Fending off the baddies from deleting your beautiful lists is up to you, I must warn. What I’m going to explain in this example is how to do the following:

Install Redis on a centralized server
Install Boom
Configure Boom to use the centralized server

Install Redis

Installing Redis is really easy. At the time of writing, the latest version of Redis is 2.2.2. Redis is under somewhat heavy development, so you may want to check to see if there’s a newer version. To install 2.2.2, run the following in your teminal:

$ wget http://redis.googlecode.com/files/redis-2.2.2.tar.gz
$ tar xvzf redis-2.2.2.tar.gz
$ cd redis-2.2.2
$ make && make install

Now that Redis is installed, you can fire up the server with, strangely enough, redis-server. By default, it’s going to run the server on port 6379. If you’re running a firewall on the server you’re installing this on (you are running a firewall, aren’t you?), you will need to open up this port.

To test that everything’s working, you can use the always handy telnet. In your command line, you can do the following:

$ telnet <hostname> 6379
> SET hello thar
> GET hello

You should get responses back from the Redis server showing that the value was stored during the SET, and return your “thar” when you GET. Redis is pretty cool, huh?

Installing BOOM

Onto installing boom on your local machine. I’m going to assume you have ruby and rubygems already installed and setup. Boom, itself, has one dependency: yajl-ruby. If you don’t already have this, go ahead and install it with gem install yajl-ruby. Once you’ve got yajl, a simple gem install boom will get you rolling with Boom. Now that you’ve got boom installed, run boom in your terminal to initialize your configuration file and your default .boom json file. Go ahead and give it a stab, and get a feel for how to use it. boom help will get you started. Once you’re comfortable with its amazing powers of organization, let’s move forward and configure it to use Redis.

Configuring Boom For Redis

To use Boom with our new Redis server, you’ll need to install the Redis gem: gem install redis. Next, you’ll need to crack open your newly created ~/.boom.conf file in your favorite text-editor, and edit it to look like this:

{
  "backend": "redis",
  "redis": {
    "port": "6379",
    "host": "your-host-name.com"
  }
}

You’ll obviously be swapping out the cleverly named “your-host-name.com” to whatever your hostname actually is. Once that bit of configuration is done, boom will be using your centralized redis database to store its contents. Neat! You and your friends or co-workers can now share this, and get into all sorts of mischief! Enjoy it.

Where To Go From Here

This is obviously not an ideal setup. It’s open to anyone with an internet connection, so you may want to do IP-based verification, some kind of authentication scheme, etc. Your server is just running in your SSH session, if you stop with where I left you. You’ll likely want to setup an rc.d / init.d script to fire up the redis server for you on startup. You also will probably want some kind of data persistence, since Redis stores all data in memory (although it will periodically dump to disk).

In all, this is a pretty neat concept. I’m not sure how well it will work with co-workers or friends, since everyone has full read/write access to everything. But for compiling lists of funny image urls, command line one-liners, canned e-mail responses, etc., you may just find that this comes in handy if everyone is cooperative.

Pianobar On Mac OS X

2011-01-25T00:00:00-05:00

Recently, my friend Brandon wrote about using Pianobar on Linux (specifically on Debian based systems). In every attempt to steal his thunder, I’m copying him, and posting about how to get the same thing working on Mac OS X with similar functionality.

For those unfamiliar, Pianobar is a command line interface to Pandora, which is more gentle on your memory footprint (no Adobe anything!), and is easier to tuck away in the background. We’re going to do a few things in this brief tutorial:

Setup homebrew if you have not already
Install Pianobar
Install growlnotify
Configure Pianobar
Setup Growl notification for Pianobar

Installing Homebrew

Frankly, you should be ashamed of yourself if you haven’t installed homebrew yet on your mac. To put it plainly, it’s the bee’s knees. Alright, now that you’re convinced, let’s get started.

Installation is really difficult, so be prepared for some heartache and pain. First, run this in your terminal:

curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C /usr/local

AND THAT’S IT. Difficult, eh?

Installing Pianobar

So now that we’ve made it through that grueling task, we can move forward and install pianobar using our favorite package manager (in case you’ve forgotten already that’s homebrew. We just installed it. Pay attention.) Run this whiz-bang command in your terminal:

brew install pianobar

BANG! You’re ready to listen to some Pandora through your terminal. You can go ahead and try it out by typing pianobar in your terminal. Go ahead. I’ll wait.

Install Growl Notify

This probably doesn’t even merit its own step. But let’s go ahead anyways.

brew install growlnotify

Configure Pianobar

We’re getting there. I’m proud of you for making it this far. Well done.

So Pianobar has a few things that you can set in a config file so that you don’t have to set these each time you load the application. These are things like your Pandora username, your password, and something else we’ll be talking about in the next section, the event_command. It sounds pretty complicated, but we’ll get through it. I promise.

So, open up your favorite text editor (unless it’s TextEdit, in which case, please just leave my site), and edit ~/.config/pianobar/config. You’ll enter in the following lines:

user = you@youraddress.com
password = hopefullyNot123456

Go ahead. Give Pianobar another whirl. It should log you in automatically. Pretty fancy, huh? Onward!

Setup Growl Notification

You can obviously skip this part if you find Growl obnoxious or annoying. I happen to like it. It’s like a good friend who keeps you informed when exciting events are happening. I call him Ralph.

So, don’t get angry, but remember that pianobar configuration file? Yea? Ok, we’re going to edit that once again. So open it up again in anything but TextEdit, and we’re going to add this line to the bottom:

event_command = /Users/yourusername/bin/pianobar-notify.rb

Obviously, you’ll want to swap out “yourusername” for your actual username. If you don’t know what it is, you can use the whoami command. You’re welcome.

Now the exciting part. We’re going to write a simple little program (in Ruby) to let us know some info about new songs that are being played through Pianobar. Ok, it’s not really THAT exciting, but still pretty cool. Let’s open up our text editors for one final edit. This time we’re opening the /Users/yourusername/bin/pianobar-notify.rb file. Ok, now that you’ve got your file open (welcome back, by the way), you’re going to type (or you can copy/paste if you really want to) this:

#!/usr/bin/ruby

trigger = ARGV.shift

if trigger == 'songstart'
  songinfo = {}

  STDIN.each_line { |line| songinfo.store(*line.chomp.split('=', 2))}
  `growlnotify -t "Now Playing" -m "#{songinfo['title']}\nby #{songinfo['artist']}"`
end

Save the file, and you’re done. You can now listen to your favorite tunes through the command line, see who’s playing when new songs start, and you’re now up to speed with the latest in package management fashion for the Mac platform.

Testing Nested Resources In Rails 3

2010-10-21T00:00:00-04:00

I recently ran into some problems when trying to run my functional tests while using nested resources in the new Rails 3. My routing was setup for nested resources, Foo has many Bars.

resources :foos do
  resources :bars
end

I used a rather contrived test to get started.

test "that I can GET the index" do
  get :index
  assert_response :success
end

The first error that I received, when using this fairly basic test was:

NoMethodError: undefined method `recycle!` for #<Bar:0x1033f09e0>

This error is easily corrected by renaming the fixture instance variable youre likely declaring in your setup. In my case, the Bar resource name needed to be updated.

setup do
# @bar = bars(:one) Change to:
  @my_bar = bars(:one) 
end

ActionController has its own set of instance variables named after the controller. In the commented out case above, you are squashing Rails instance variable, which causes this error.

After correcting this issue, I was still having problems.

ActionController::RoutingError: No route matches {:controller=>"bar"}

This was another really basic fix that took me longer than I care to admit to resolve. To fix this, you simply need to fix your test case to provide the parent resource id.

test "that I can GET the index" do
  get :index, :foo_id => @my_foo.id
  assert_response :success
end

Note that youll also need to declare a @my_foo variable in your setup for this to work. Otherwise, you can just use any number to get the routing to work. Happy testing!

Jacobi Iteration With Ruby

2010-04-28T00:00:00-04:00

When solving linear algebraic systems, it is often beneficial to use iterative methods. Iterative solvers are particularly useful when a matrix is diagonally dominant. One such iterative method that is particularly useful is Jacobi Iteration.

Given a matrix A, you first decompose it into 3 separate matrices: L, D, and U. These are the lower, diagonal, and upper sections of the matrix, respectively.

For example, let’s assume we’ve been given this matrix A:

We will then zero-out everything above and including the diagonal entries. This will give us our new L matrix.

Likewise, we’ll remove all entries below, and including the diagonal from matrix A to give us our matrix U.

Finally, we’ll zero-out all non-diagonal entries, to yield our new matrix D.

As stated previously, since A=L+D+U, we can deduce that Ax=Dx+(L+U)x. And since Ax=b, we can conclude that Dx=b-(L+U)x, which is the basis of Jacobi’s Method.

Given an estimate vector (x) (which is generally initialized to 0 if no educated guess can be provided), the next estimate is found by:

And since D is a diagonal matrix, the above equation can be rewritten in terms of the components of A and b.

So now that we understand how Jacobi Iteration works, we can write a program to do it for us! Ruby is not necessarily the best language to do this in, as these systems can often times be quite large. Compiled languages such as C++ are going to converge much faster.

To start out, we’re going to write a method that takes in our Matrix A, our right hand size b, the number of times we’d like to iterate, and our initial guess.

def jacobi_iteration(A, b, iterations, guess |= 0)

From here, we will need to fire up our estimate vector x. We’ll initialize its first element to be the initial “guess,” and the remaining entries to be 0.

  # Initialize
  x = Array.new(A.size)
  x[0] = guess
  1.upto(A.size) do |i|
    x[i] = 0
  end

Finally, we implement the equation above as nested loops to iteratively try to converge to a solution.

  0.upto(iterations-1) do |its|
    0.upto(A.size) do |i|
      sum = 0
      0.upto(A.size) do |j|
        unless j==i
          sum = A[i][j] * x[j]
        end
      end
      x[i] = 1.0/A[i][i] * (b[i] - sum)
    end
  end
end

And there you have it! If you're doing this on large matrices, I would definitely suggest using a different language, such as C++ to handle this, since Ruby can not only be a bit slower, but it's also quite a memory hog when dealing with so many objects.

NGINX Config: http to https

2010-04-18T00:00:00-04:00

I’ve recently installed a self-signed certificate on my server just for the login areas for my own peace of mind. After having a rough time trying to handle the redirection from Rack itself, I opted to do this through NGINX, which turned out to be quite a bit easier. Below is a snippet of the virtual host I used:

server {
            listen   80;
            server_name happygastropod.com;
            rewrite ^/admin https://happygastropod.com/admin permanent;
}

It’s pretty self explanatory. Takes a regular expression of the path you’d like to redirect, and simply redirect it off to the https alternative. Enjoy.

C++ Virtual Class Inheritance

2010-03-11T00:00:00-05:00

Virtual Class Inheritance is something many people (myself included) have a difficult time wrapping their heads around initially. It can be a useful tool, so I’m going to try to explain it a little bit here.

Let’s suppose we have a Garden with different kinds of plants growing in it (how original.) We can start out by creating a very general class called Plant. With generalization in mind, we can only specify attributes and functions that all plants share.

class Plant
{
public:
  virtual ~Plant();
  virtual Plant* clone() const = 0;
	
  string getColor() const
  {
    return color;
  }
	
  int getHeight() const
  {
    return height;
  }
	
  void grow(int n)
  {
    height = height + n;
  }
	
  virtual bool isRipe() const = 0;

protected:
  string color;
  int height; //inches
};

You’ll notice that the isRipe() function has the keyword “virtual” next to it, and it’s set to equal 0. This defines a virtual function that is not defined in the base class. There is no way of knowing whether a plant is ripe without knowing what kind of plant it is. So we will define this function in the sub-classes.

You should also notice that the destructor is virtual. This is because there may be additional private members in the sub classes that this base class doesn’t know about. Not declaring the destructor as virtual would likely lead to memory leaks.

We can now start coming up with plants we’d like to put in our garden. For this example, I’ve created Carrot, Potato, and Eggplant classes. Each of these classes has a unique implementation of the isRipe() function.

class Carrot : public Plant
{
public:
  Carrot()
  {
    color = "Orange";
    height = 0;
  }
	
  virtual bool isRipe() const
  {
    return height >= 10;
  }
};
 
class Potato : public Plant
{
  Potato()
  {
    color = "Brown";
    height = 0;
  }
	
  virtual bool isRipe() const
  {
    return height >= 7;
  }
};
 
class Eggplant : public Plant
{
  Eggplant()
  {
    color = "Purple";
    height = 0;
  }
	
  virtual bool isRipe() const
  {
    return height >= 13;
  }
};

Nothing too fancy here, but you can see that each class has a different (albeit simple) way of checking if the plant is ripe.

Moving forward, we can implement our Garden class. The Garden class is essentially a collection of plants. We’re going to store our plants in a vector. Well, really we’re storing pointers to our plants in a vector. Since there is no way of knowing how much memory each plant will use, we cannot store plants directly. We must store pointers to the plants, which could be of type potato, eggplant, or carrot.

class Garden
{
public:
  Garden();
  addPlant(Plant* p)
  {
    plants.push_back(p)
  }
	
  harvest()
  {
    for(int i=0; i<fplants.size(); i++)
    {
      if(plants[i]->isRipe())
      {
        plants.delete(plants.begin() + i) //Remove ripe plants from garden
      }
    }
  }
 
private:
  vector<*Plant> plants;
};

And there you have it. We have a very simple, and fairly useless e-garden. I’ll leave it up to you to code the army of slugs and snails to destroy it. Oh, and be sure to make a virtual class gastropod.