taylorbarstow.com

As hokey as it might seem, I am a fan of New Years resolutions. This may be something about me, or it may be something that everyone experiences (perhaps because we have been conditioned to think this way), but I have generally been able to accomplish quite a bit around this time of year:

• Quitting smoking (some eight years ago now)
• Becoming vegetarian (a change which lasted 4 years, though I did eat fish)
• Beginning an exercise regimen

My first resolution for this year is to eat more locally. Although I will make some exceptions (garlic, nuts, and coffee, for example) I will do my best to buy locally produced food. This includes vegetables, meats, and dairy products. This means I will also be eating more seasonally; if I can’t find local broccoli, I will do without it.

Of course, living more locally goes beyond food—I will also do my best to buy local beer, and to support local merchants rather than regional or national (or multinational!) chains.

This might sound easy to the casual reader, but it really isn’t. When I went vegetable shopping last night, I ended up with some squash from Massachusetts, a huge parsnip from Vermont, some garlic, and (luckily) some local lettuce grown in a greenhouse. Of course the store had all kinds of vegetables—carrots, celery, fennel, broccoli, you name it—but most of it was from California.

You might ask why I am motivated to put myself through this. I have a few reasons, but two are chief among them:

1. I want to do everything I can to reduce my dependence on fossil fuels—did you know that the average food item in the average American meal has traveled 1500 miles from its source to your plate?
2. I want to gain a greater understanding and appreciation of where my food comes from, rather than ignoring all that and blindly buying whatever I feel like eating. As I see it, the first step is to buy food that is grown around me. No strawberries in New England in the winter—it just doesn’t make sense.

Anyway, that’s my newest journey. If you’re interested, I hope you will check back later for updates on how it goes. And if you are trying to do something similar, how’s it going and where do you live?

Over at unbiasd, we use a couple of daemons to keep our web interface snappy. Rather than letting our mongrels sit around and handle long running tasks (such as outbound web requests), we offload these responsibilities using the delayed_job plugin. Currently we’re using collectiveidea’s branch because it includes a nifty script to run delayed jobs in a daemon environment using the daemon generator plugin.

The bad news? The daemon crashes all the time. Sure, I could write a monitor daemon to restart it when it crashes (daemon generator even includes a prepackaged one of these). But that seems somehow wrong—what if my monitor starts crashing? Write another monitor? What if that starts crashing? In programming I believe in finding and solving the real problem rather than ignoring it and programming around it. The former is akin to an elegant solution, the latter to brute force.

So how do I proceed? Step 1 is clearly to remove all third party code—or at least to become intimately familiar with it. Ideally I’d like to keep using delayed_job, so I’m going to whittle away at the other third party code first. This means getting rid of my daemon generator crutch. This has some obvious advantages:

1. I can use tobi’s delayed_job, which is clearly more up to date than collectiveidea’s
2. I can learn the ins and outs of writing daemons in Ruby
3. Hopefully I can write a good daemon and submit it back to tobi (with the magic of github)

So this is an introductory post—a prelude to a journey. More to come.

Sweet Potato Pizza
with carmelized onions, rosemary, walnuts, ricotta, and parmigianno reggiano

Seared Kale
with garlic and lemon

That’s the plan, anyway.  Or maybe I’ll put the kale on the pizza (??) Full experience coming to The Fresh Dish on Thursday.

Over at unbiasd, we have URL canonicalization problem. You see, unbiasd brings together a bunch of news feeds from various websites and publishes selected articles from these feeds on the homepage. For each recently published article, we use Ice Rocket to search for back links to the article. This is how we power our “blog reactions” feature.

This works great—except for one problem. The article URLs given in feeds are not always the same URLs that bloggers would be linking to. FeedBurner is an obvious example of this. While some bloggers might mistakenly link to a FeedBurner URL, they probably meant to link to the actual article’s permalink instead.

The solution (in my mind) was simple: do a HEAD request on each URL before doing a search for blog reactions. If the HEAD responds with a Location header, then use the referenced URL rather than the original.

This works great for FeedBurner URLs, but there is a problem that I just discovered yesterday. Some sites (including The New York Times) will sometimes redirect you to a login/registration URL before allowing you to view an article. This obviously throws a little hitch into my giddy up: my HEAD request responds with a Location header pointing to a login page, so I go ahead and do a blog search using the login URL. Sweet.

The more that I deal with real-world web content, the more I realize that it is the wild west of data. Pretty much nothing is normalized. Wild hacks are the norm, because sometimes they are the only thing that work. If nothing else, at least this will force me to be seriously pragmatic in my day to day coding.