I attempted to install memcached via MacPorts earlier today, and ran into a problem with the MD5 and SHA1 hashes.

$ sudo port install memcached
-->  Fetching memcached
--->  Attempting to fetch memcached-1.2.6.tar.gz from http://www.danga.com/memcached/dist/
--->  Verifying checksum(s) for memcached
Error: Checksum (md5) mismatch for memcached-1.2.6.tar.gz
Error: Checksum (sha1) mismatch for memcached-1.2.6.tar.gz
Error: Target org.macports.checksum returned: Unable to verify file checksums
Error: Status 1 encountered during processing.

After pulling down the file directly from the memcached web site, I discovered that tar wouldn’t extract it.

$ tar zxvf memcached-1.2.6.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error exit delayed from previous errors

No matter; we’ll do it the hard way. These are the steps I followed to install memcached on my Mac. The only assumptions I’m consciously making are that you use MacPorts and git.

1. Install libevent through MacPorts:

$ sudo port install libevent

2. Clone the memcached git repository:

$ git clone http://consoleninja.net/code/memcached/memcached.git/

3. Configure memcached:

$ cd memcached
$ ./autogen.sh
$ ./configure --prefix=/usr/local --with-libevent=/opt/local

4. Make and install:

$ make
$ sudo make install

If everything went according to plan, you’re good to go. Start it up:

$ memcached -vv

That last line starts up a memcached server running on the default port 11211. The -vv option tells memcached to use its most verbose output. You should have seen output similar to the following:

slab class   1: chunk size     88 perslab 11915
slab class   2: chunk size    112 perslab  9362
slab class   3: chunk size    144 perslab  7281
slab class   4: chunk size    184 perslab  5698
slab class   5: chunk size    232 perslab  4519
slab class   6: chunk size    296 perslab  3542
slab class   7: chunk size    376 perslab  2788
slab class   8: chunk size    472 perslab  2221
slab class   9: chunk size    592 perslab  1771
slab class  10: chunk size    744 perslab  1409
slab class  11: chunk size    936 perslab  1120
slab class  12: chunk size   1176 perslab   891
slab class  13: chunk size   1472 perslab   712
slab class  14: chunk size   1840 perslab   569
slab class  15: chunk size   2304 perslab   455
slab class  16: chunk size   2880 perslab   364
slab class  17: chunk size   3600 perslab   291
slab class  18: chunk size   4504 perslab   232
slab class  19: chunk size   5632 perslab   186
slab class  20: chunk size   7040 perslab   148
slab class  21: chunk size   8800 perslab   119
slab class  22: chunk size  11000 perslab    95
slab class  23: chunk size  13752 perslab    76
slab class  24: chunk size  17192 perslab    60
slab class  25: chunk size  21496 perslab    48
slab class  26: chunk size  26872 perslab    39
slab class  27: chunk size  33592 perslab    31
slab class  28: chunk size  41992 perslab    24
slab class  29: chunk size  52496 perslab    19
slab class  30: chunk size  65624 perslab    15
slab class  31: chunk size  82032 perslab    12
slab class  32: chunk size 102544 perslab    10
slab class  33: chunk size 128184 perslab     8
slab class  34: chunk size 160232 perslab     6
slab class  35: chunk size 200296 perslab     5
slab class  36: chunk size 250376 perslab     4
slab class  37: chunk size 312976 perslab     3
slab class  38: chunk size 391224 perslab     2
slab class  39: chunk size 489032 perslab     2
<4 server listening
<5 server listening
<6 send buffer was 9216, now 7456540
<6 server listening (udp)

We can easily test that it’s working. Leave memcached running in the Terminal, and open a new tab. Then telnet in like so:

$ telnet 127.0.0.1 11211

If you see the following, you’re in:

Trying ::1...
Connected to localhost.
Escape character is '^]'.

If we switch back to memcached, we see:

<7 new client connection

In the future, you can launch memcached with the -d option for it to run as a daemon. If you’d like memcached to start up automatically, you can set up a launchd plist for the purpose. The following is a slightly modified version of this example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>memcached</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/memcached</string>
        <string>-l</string>
        <string>127.0.0.1</string>
        <string>-u</string>
        <string>nobody</string>
        <string>-d</string>
        <string>-m</string>
        <string>64</string>
        <string>-p</string>
        <string>11211</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/dev/null</string>
    <key>StandardErrorPath</key>
    <string>/dev/null</string>
</dict>
</plist>

This file is saved in ~/Library/LaunchAgents/memcached.plist, and will tell Leopard to launch memcached on startup. It will run as a daemon listening to 127.0.0.1 on port 11211 with a maximum memory size of 64MB. This is exactly the same as running the following command line:

$ memcached -l 127.0.0.1 -u nobody -d -m 64 -p 11211

I’ve long had an interest in Vim, but learning a new text editor is a major endeavor for any developer.  We spend the overwhelming majority of time working in text editors, and like anything else choosing the right tool is important.  After a certain amount of time the tool fades into the background, and using it becomes completely second nature.  I moved away from the Eclipse IDE to TextMate when I got into Ruby, and it has seen me through many a project.  With the right bundles installed TextMate is a fantastic tool.

So why use Vim, or more specifically, MacVim?  At this point, I still can’t say.  It’ll take some time after I’m used to its paradigm and have built up enough muscle memory for me to be able to say whether or not it’s better for me.  That being said, I knew that there were a few tools I’d absolutely need it to have for it to have a chance at competing with TextMate.  Thankfully, Vim has a robust plugin system and a huge user-generated library from which to choose.

I spent some time using TextMate, taking note of which of its facilities I used most often.  What emerged was something of a blueprint for what I’d need Vim to either replicate or replace.  The following plugins did the trick:

1. NERDTree – A Project Drawer-like file browser
   
2. FuzzyFinder – A fuzzy-search based file navigation mechanism
   
3. FuzzyFinder TextMate (Blog) – Provides ⌘-T functionality via FuzzyFinder
4. Rails.vim – The Vim equivalent of the Ruby on Rails TextMate bundle
   
5. snippetsEmu – Provides tab triggers and other nifty TextMate-like snippet functionality
   

There’s clearly a pattern here.  At one point I stopped and asked myself why exactly I was trying to reimplement TextMate in Vim.  The reality is that these tools have a very strong connection with the way I work, and most of them aren’t particularly unique to TextMate.  The fuzzy-file-search mechanism is something that appears all over the place.  We use it all the time in tools like LaunchBar and QuickSilver.  Rails.vim brings Rails awareness to Vim; all good text editors support extensions like this.  The only thing up there that’s unique to TextMate is the tab-trigger snippets.  I’ve got no excuse for that one.  It’s a really great feature in TextMate, and I think all text editors should have it.

I had some difficulty getting FuzzyFinder TextMate working until I discovered that Jamis had stopped working on it.  It had fallen out of sync with FuzzyFinder, on which it depends.  Tracking down the latest version of FuzzyFinder that was known to work solved the problem.  It looks like there’s a fork on GitHub that’s been brought up to date, but I haven’t yet tested it.

My configuration is on GitHub.  If you find any mistakes or have any suggestions for improvement, please feel free to fork it and send a pull request.  I’m still a Vim noob, but I’m impressed so far.

In an rare bit of jackassery, I passed out on the couch when I got home today. As a result, I’m behind on my writing.  Luckily, I stumbled into co-authoring an article over at the Mighty Interactive blog. My colleague Eric and I continued a conversation we started a month ago.  If you’re looking for something interesting to read, start at the beginning and work your way up.

Also: I had to debate whether or not to link to something I’d written on my employer’s blog.

This is my personal blog, and nothing here should be construed as representative of the views or positions of my employer, colleagues, or clients.

I’m 26 years old and have been happily partnered for just over six years.  My partner and I live a largely bachelor lifestyle, which means we have a lot of technology in the house.  We use Mac OS X, we play video games, and we love Blu-ray.¹  We’ve been iPod owners since the first generation.  In short, we’re used to having some cool toys.

It has been immensely pleasing to watch these products mature.  Today’s iPod touch bears very little resemblance to the original hard-disk, Firewire- and Mac-only iPod.  Today’s PlayStation makes the original look as dated as the Ultra Nintendo 64 made the SNES.

What’s made the journey so fun is the software.  We’ve gone from 8-bit sprites to full-frame, high-framerate imagery.  We flick and tap our phones to use our applications and access our data.  The advancement in user interfaces has been nothing short of extraordinary, and this is just the beginning.

And then we have this fucker:  The Scientific Atlanta Explorer 8300 HD DVR (II Turbo Remix HD Alpha 1). This is the standard HD DVR provided by Cox to its subscribers in the Phoenix metro area.  I’ve used Comcast cable boxes, DirecTV DVRs, and TiVo HD, and this one really takes the cake.  It is pure, unadulterated shit.^2 3

I can’t count the number of times this box has paused in the middle of a program for no discernible reason.  It is indeed very good at recording your programs as scheduled.  Except when it doesn’t.  That’s usually when you realize that it’s 12:15 am, Jon Stewart has been on for 15 minutes, and you’re going to have to wait a day to get your Daily dose.

Then there are the times when it forgets how to prune old programming.  Inevitably the box will begin to whine about “DISK SPACE LOW.”  In our house this means drop everything you’re doing and start deleting old shows immediately.  Waiting isn’t an option, because if you let it go too long you won’t be able to delete anything… because you have no disk space.  Functional issues aside, the UI itself is painfully antiquated.  The text rendering would have looked right at home on the original Nintendo.  The device’s only “advanced” feature is access to Cox’s On Demand programming.  Accessing the service requires the box to go into a special mode where it seems to gain some abilities.  Unfortunately, reliably streaming HD programming isn’t one of them.

Many have had a similar experience, and it’s no surprise that the culprits regularly come from large companies with municipal monopolies.  A robust competitive environment is what leads to things like iPhones and PS3s.  Remove competition and you end up with the Scientific Atlanta cable box Cox deems good enough to serve me content for which I pay exorbitantly so I can access roughly six channels regularly.⁴

We need some competition in this space, and we need it badly.  Otherwise we’ll be stuck with these crappy UIs for a long time to come.  We deserve better.

1. DRM sucks, but right now there is no other practical way to get uncompressed 1080p video. ↩
2. I went back to the Scientific Atlanta because Cox’s CableCARDS wouldn’t maintain their authorizations.  This required me to call Cox, and wait a few days so they could send one of their minions to shove a new PCMCIA card in the TiVo – a process I could’ve done when I was five.  After going through this several times, I gave up. ↩
3. I realize this is only my second post on this blog, but get used to cursing.  I’m an unabashed George Carlin Wannabe. ↩
4. CNN, NBC, HBO, Showtime, Comedy Central, and Bravo ↩