Tyler Hunt

Recently, I have been spending a lot of time working on a daemon written in Ruby. I’m using the Daemons gem as a starting point as it does a nice job of taking care of the nitty-gritty details of spawning threads, dealing with PID files, and providing a simple interface for starting and stopping the daemon. The stopping part, however, has been somewhat problematic for me as the daemon sometimes continues to run. Somewhere along the line the exception being raised is eaten up, never to fulfill its destiny as the mortal messenger that it is.

There’s also the case where you may want certain code to finish executing before the daemon exits. It would be nice to have a little more control over the shutdown process rather than just aborting it mid-stride.

I have found a solution that solves both of these issues. Let’s start by looking at a barebones daemon that will just sit quietly in the background until told to do otherwise.

Daemons.run_proc('sleeper, { :log_output => true }') do
  puts 'Started'

  loop do
    puts 'Sleeping'
    sleep 1
  end

  puts 'Stopped'
end

In this case there shouldn’t be a problem stopping this daemon, but it really doesn’t give us much control over the process. Here’s what the output looks if we start it up and let it run for three seconds:

Started
Sleeping
Sleeping
Sleeping

You’ll notice that “Stopped” is never output, but the daemon is abruptly terminated right inside the loop. To get around this, we can use trap to catch the TERM signal and handle it a little more gracefully.

Daemons.run_proc('sleeper', { :log_output => true }) do
  puts 'Started'

  run = true
  trap 'TERM', lambda { run = false }

  while run
    puts 'Sleeping'
    sleep 1
  end

  puts 'Stopped'
end

Now our output looks just as it should.

Started
Sleeping
Sleeping
Sleeping
Stopped

This allows us to cleanly finish up whatever we’re doing and make a graceful exit.

Daniel and I have been passionately working on TallyHoh for a while now. It’s an online feed reader at its core, but it has big aspirations to be much more than that. You can “tally” and “folly” items from your feeds to cast votes for them in either a positive or negative light. The votes are use to promote the greatest or most controversial topics of the moment.

For those not familiar with the concept, “feeds” basically provide a way to keep tabs on your favorite sites so you don’t have to visit them everyday to find out if they’ve been updated. Using a feed reader you can then subscribe to multiple feeds at once so you can read all of your blogs and news in one place.

We also made one big opinionated decision when we developed TallyHoh: we’re using OpenID exclusively. If you haven’t heard of OpenID, it’s a technological solution to the problem of user account overload. It lets you use a single account to access all of the sites that you visit. While it hasn’t seen mass adoption yet, it’s gaining a lot of momentum, and we feel confident enough in it to put our full weight behind it.

There’s still a lot to come, but we think TallyHoh has value as it stands today so we’re opening it up to let everyone try it out for themselves. We like the fact that our feeds are always online, and TallyHoh does a good job of keeping track of the things that you’ve read so you won’t see the same content twice.

Try it out, and let us know what you think.

I’ve been working with JavaScript for some number of years now, but today was the first day that I truly made use of closures in an intentional way. I’m in the midst of building a dynamic product finder right now, and one of the requirements is to have a table with rows that are sortable. The problem was, once the rows are sorted, their alternating row colors were no longer alternating, but all mixed up according to the sort order.

The table rows needed to be assigned new, alternating class names. Ruby on Rails has a nice little helper built in called cycle that was written just for this very purpose. It takes an array as an argument, and each time it’s called it returns the next value from the array. I decided that it would be nice to have that functionality in JavaScript for use on the client side, so here’s what I came up with:

var Cycle = Class.create({
  initialize: function (values) {
    this.index = 0;
    this.values = values;
  },

  next: function () {
    if (this.index == this.values.size()) this.index = 0;
    return this.values[this.index++];
  }
});

This ends up looking like this in use:

var rowClasses = new Cycle(['row1', 'row2']);
rowClasses.next(); // 'row1'
rowClasses.next(); // 'row2'
rowClasses.next(); // 'row1'

That works, but it seems like overkill. Closures to the rescue!

var Cycle = function (values) {
  index = 0;

  return function () {
    if (index == values.size()) index = 0;
    return values[index++];
  };
};

Now, this behaves differently than the Rails version, but direct duplication wasn’t the intent. Here’s how it works:

var nextRowClass = new Cycle(['row1', 'row2']);
nextRowClass(); // 'row1'
nextRowClass(); // 'row2'
nextRowClass(); // 'row1'

As you can see, the function returned from Cycle gets bound to Cycle’s scope—and thus the value of index—maintaining state between each execution.

A problem arises, though, when we create more than one Cycle: each Cycle ends up sharing the same index. I’ve found that the simplest workaround for this is to define the index as another argument to the function.

var Cycle = function (values, index) {
  return function () {
    index = index || 0;
    if (index == values.size()) index = 0;
    return values[index++];
  };
};

Now we can create as many Cycles as we want, and each will have it’s own unique index. If you know of a better way to do this, please let me know.

Dr Math meets Captain Obvious.

— Jeremy Kemper (aka bitsweat)

Changeset 7798 in the Active Record repository.

After releasing Relax into the open arms of those at BarCampOrlando, I decided it was about time I put together a buildfile for the project. Now, I’ve used Rake plenty as a user over the past few years, but I’ve never spent a lot of time looking into how it actually works. My first goal for a buildfile was to create a gem for Relax. This turned out to be incredibly easy, thanks to the built-in gempackagetask. Here’s pretty much the extent of what’s required to create a working buildfile for packaging gems:

require 'rake/gempackagetask'

spec = Gem::Specification.new do |spec|
  spec.name = 'relax'
  spec.version = '0.0.1'
  spec.summary = 'A simple library for creating REST consumers.'
  spec.author = 'Tyler Hunt'
  spec.email = ''
  spec.homepage = 'http://protoh.com/'
  spec.platform = Gem::Platform::RUBY
  spec.files = FileList['{bin,lib}/**/*'].to_a
  spec.require_path = 'lib'
  spec.autorequire = 'relax'
  spec.test_files = FileList['{spec}/**/*spec.rb'].to_a
  spec.has_rdoc = true
  spec.extra_rdoc_files = ['README', 'LICENSE']
  spec.add_dependency('hpricot', '>= 0.5')
end

Rake::GemPackageTask.new(spec) do |package|
  package.need_tar = true
end

Now, a simple rake gem will scour the source files and bundle everything up into a nice, neat gem.

Since then, I’ve been attempting to hurry the project along to a state more typical of most other Ruby packages, and that means writing RDocs. I’ve read lots of code with RDocs, but I don’t recall ever having written any before. It turns out I really like working with the format, and it seems much cleaner than Javadocs. (I’ll leave the details for another post.)

So, I’ve expanded the Rakefile for Relax slightly to add a task for generating my Rdocs:

Rake::RDocTask.new do |rdoc|
  rdoc.title = 'Relax Documentation'
  rdoc.main = 'README'
  rdoc.rdoc_files.include('README', 'LICENSE', 'lib/**/*.rb')
end

Again, a very straightforward task. The full documentation for Relax is now available on the Relax site.

So that’s where Relax development has been focused for the past few days. One of these days I’ll try to put together a high level overview of the progress accomplished last weekend, and the features included in the first release.

Somewhat coincidentally, I’ll be giving a short talk on Rake as part of the Build Tool Shoot Out at the Adogo meeting on Tuesday.

I took (a small) part in BarCampOrlando this past weekend. It was a great deal of fun, and all who attended owe Gregg Pollack et al a debt of gratitude for putting their hearts and souls into this project. The event went largely without a hitch, and could safely be called a roaring success.

Going into the day, I was still undecided as to whether I was going to present. I ended up getting a lot of work done during the afternoon, and threw together a few slides and some examples in order to give a short talk. I spoke during the very last 20 minute time slot in the back room on “Consuming REST Services with Ruby,” which was really just a front for showing off the new library I’ve been writing: Relax. I’m going to try to get some more information and some example code up there soon, but for now you can download the gem and play around with it.

I’m looking forward to the next BarCampOrlando event, and there are some rumors going around that we might see one again in the spring. Doing this semiannually will go a long way towards vitalizing Orlando’s tech community.

As I’ve been developing my Amazon FPS API, I’ve had to make some decisions along the way about how the code should be structured. Right now I’m taking the approach of a central API class that has a method for each action provided by the service. Each action, then, has its own request object, which is used to pass parameters into the API call, and its own response object, which is used to pass back the XML response from Amazon as a Ruby object. This approach sometimes seems more akin to a Java API than a Ruby API, so I’m planning to spend some time down the road figuring out a more Ruby-esque means of interacting with the API.

I’ve also been unsure along the way of whether it really makes sense to use such a heavyweight API. I suppose one alternative would be to make use of some magic to simply generate the request from a hash passed to the API. This seems kludgey to me, and having worked with some APIs in the past that operated this way, I feel that the extra effort to duplicate much of the REST service as Ruby code make a lot of sense. One of my biggest gripes with these sorts of APIs is the usage of action and parameter names from the service directly, as they often don’t follow the typical Ruby naming conventions. This alone is enough to warrant a heavier API for me.

Timely enough, Chad Fowler posted an entry on his blog yesterday about “Writing APIs to Wrap APIs.” His philosophy on the matter seems to mirror mine in a lot of ways, and his point about a wrapper API being less brittle especially resounded with me. It’s always nice to receive validation on your efforts, and even more so when it comes from someone you respect.

That being said, progress has slowed a bit as I’ve been taking some time to extract out some of the layers of the API into a library of their own. Ultimately, this will provide anyone writing a REST consumer API with a simple base from which to start, including the logic to handle the HTTP requests, build URLs with query parameters, and parse XML responses. I’m hoping to have enough of this wrapped up in time for BarCampOrlando to be able to give a short presentation on it.

For the Amazon FPS API I’m working on right now, I’ve decided to try out the BDD approach to things and write behaviors instead of tests.

Let me first say that I’m not an expert on testing by any means, and while I have a pretty good grasp on the how and the why behind it, I’ve been somewhat slack in the practical application of the philosophy. Case in point: I wrote the majority of the code for the API before writing a single line of tests (other than a script I used to test things out manually).

That being said, I installed the RSpec gem earlier this week and began playing around with some tests for a new class I was working on. The class is used to represent a URL query, and is basically just a simplified hash with a special #to_s.

Here’s an excerpt from the spec:

describe 'A query' do 
  before(:each) do
    @url = 'http://example.com/'
    @query = Amazon::FPS::Query.new
  end 

  it 'should be accessible as an array' do
    @query[:amount] = 10
    @query[:amount].should == 10
  end 

  it 'should convert keys to symbols' do
    @query['symbol'] = 'aleph'
    @query[:symbol].should == 'aleph'
  end
end

It should be pretty clear what’s happening here. We’re defining a set of behaviors for “a query”, and we want to make sure that “a query should be accessible as an array,” and a “a query should convert keys to symbols.” The before block gets execute before :each behavior, just as setup would with your tests. While there’s truly a beauty to the DSL at work here, even it doesn’t compare to the beauty of being able to generate a specifications list from your behaviors:

A query
- should be accessible as an array
- should convert keys to symbols
- should convert to a query string
- should convert parameters to strings
- should sort its parameters
- should encode its parameter values
- should be instantiable with a hash

There’s also a very nice output in HTML.

Overall I’ve been fairly impressed with the ease of use of RSpec. It provides a very simple structure to allow you to clearly define the expected behavior of your application, and makes verifying that behavior a trivial endeavor. I haven’t had a chance to explore all of its matchers yet, but there defeinitely seems to be a lot of power and flexibility to be garnered there.

Also, for those of you in the Orlando area looking to learn more about BDD and RSpec, come check out the next ORUG meeting where Gregg will be giving a talk entitled “How I Learned to Love Testing.”

The Amazon Flexible Payments Service (FPS) looks like a great addition to the payment services arena, and if it’s anywhere near as popular as their other services have been then this one will surely be a huge success. I’m planning on using it for Monoh as the rates are significantly less than those of both PayPal and Google Checkout, and their API looks like it offers more functionality through a cleaner interface.

When I first started looking into using FPS with Ruby, I downloaded Amazon’s sample code, but was quickly discouraged by the complexity of their sample. My disappointment basically boils down to a deap-seated hatred for SOAP, and when you throw encryption with X.509 into the mix, it just becomes way too verbose for my liking, and doesn’t really fit in with the Rubyist philosophy.

Then I discovered that there’s a REST version of the API available, and offers nearly all of the functionality of the SOAP API. I don’t know why they seem to be hiding the REST capabilities, especially after talking to Brian LeGros and hearing from him that the majority of applications consuming Amazon services are using REST. Every sample they’re provided for FPS uses SOAP, except for a single REST example done with Java of all languages.

So I’ve begun working on a Ruby API for FPS over REST, and things are progressing fairly nice now that I’ve gotten over a silly snag that I had early on in the development. I’ve come up with a clean way to implement each action in the API and still keep things pretty DRY. I’m planning on releasing the API once I get the core of the API wrapped up, and I’ll try to post more about the development process as it progresses.

I’ve recently been enjoying a series of articles by Dave Hyatt on the Surfin’ Safari blog about the underpinnings of WebCore rendering. I’ve trudged through his detailed description and accompanying header files (not something I’ve come across since my C days) in the hopes of garnering some insight into rendering technology that might help me as a web developer. This week’s article on positioning has provided just such insight, with its detailed descriptions of each of the position modes available: static, relative, fixed, and absolute. While I’m somewhat familiar with each of these, seeing them drafted out in near-specification form has helped to clarify their differences and intricacies. The first five parts are already up, so I would encourage you to at the very least skim over them. The knowledge gained might just give you an “ah ha” moment of your own.

Capistrano 2.0 is on its way. There are several new features to be looking forward to with this release: namespaces, deployment strategies, and a new capify script to help deal with the overhauled configuration system.

Read the rest of this entry

I followed the directions at Hivelogic on how to build RMagick on Mac OS X, and while everything in those instructions executed properly, the end result did not. I tried a few different remedies after googling for solutions, including installing GraphicsMagick instead of ImageMagick, but alas, nothing seemed to work and I was still left with a broken Rails console:

Loading development environment.
/usr/local/lib/ruby/gems/1.8/gems/rmagick-1.13.0/lib/RMagick.bundle: [BUG] Bus Error
ruby 1.8.4 (2005-12-24) [powerpc-darwin8.6.0]

Abort trap

Then I came across a post on the comp.lang.ruby mailing list that discussed the problem, and a hack to get things working until a more permanent solution comes along:

The quick-fix is to just disable the assignment to $0 in irb.rb – the first line of IRB.start.

So with that tip in hand, I took to the irb source and quickly resolved my “bus error.” It’s too bad it’s not a proper solution, but I’m glad to be able to move on and continue my Rails development efforts.

You can’t easily edit a log message with Subversion after a commit. The Subversion FAQ entry on the topic explains that this is because “changes to revision properties (of which svn:log is one) cause the property’s previous value to be permanently discarded, and Subversion tries to prevent you from doing this accidentally.”

In an effort to make this process simpler, I wrote a short shell script to automate the process.

Read the rest of this entry

I’ve initialized a new PostgreSQL database cluster dozens of times, but then always had to go through the pain of configuring the pg_hba.conf file to work with password authentication. While setting up a new database today, I happened to look in the manual and came across a couple of options that make this process much easier:

initdb -D /var/lib/pgsql/data -W -A md5

The -W option will prompt for a superuser password, and the -A md5 option will default the authentication method to md5 instead of trust, thus completely obviating the need for manual configuration. See the documentation for the details.

I’ve been a little very reluctant to work with other people on my personal projects, mostly because I have selfishly wanted to keep any potential profits for myself. Up until now I had passed this off as logical by working under the assumption that if I were to ever make any money, it wouldn’t be enough to split two or more ways, so I’m better off keeping my ideas to myself.

I’m slowly beginning to step away from this thought pattern. I had the opportunity to have Kirby do some usability testing on my current project, and without even expecting it, ended up making some fairly significant improvements to the application within a very short amount of time. Makes me wonder what would happen working full time with someone else. Maybe the profits would be split two ways, but if we could actually get something done and out the door in half the time, then there’s really no loss in that, is there?