I recently needed to burn some video files (h.264 MKV) to DVD such that the disc would work in a standalone player. After an hour googling for a set of commands to pass to ffmpeg to convert my files, I then started looking for batch scripts. It occurred to me shortly thereafter that Ruby could help. I had found a command that worked beautifully with a single file, so all that was necessary was to automate it.

It only took one line to accomplish the task:

It’d be a cinch to generalize for input video format.

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.

I had a rather rough week, and that means I have an urge to write.  I sat down to design this blog yesterday afternoon, and have worked pretty much nonstop to get it to where it is at this very moment.  Things are shaping up nicely.

Settling on a blog engine proved somewhat difficult.  The Rubyist in me wanted to stick with a tool built in that language.  If it happened to be a Rails or Merb app, all the better.  The first part of the effort was spent installing Typo and Mephisto, and skinning both of them.  Having converted to Haml for my Ruby templating needs, Mephisto’s use of Liquid was off-putting.  That isn’t a knock against Liquid so much as it means props for Hampton Catlin’s awesome work. The Mephisto admin was clean and efficient, but compared to WordPress it was clear which was more advanced.  Typo didn’t prove much better.

My needs for this blog were fairly simple, and WordPress has been doing just this sort of thing longer than just about anybody.  The tool is fast, elegant, easy to use, and well-maintained.  The only real knock I have for WordPress is having to deal with straight-up PHP templates for skinning.  This is probably exacerbated by the exceptionally poor indentation used in the default templates.  Haml markup is indentation-based, so outputted HTML is perfectly indented.  This makes debugging rendering issues easier.

That being said, this is a blog, and now that it’s skinned I won’t need to deal with many templates.  That makes it easy to settle back into the interface itself, which is outstanding.  WordPress just smacks of people sweating the details, and that’s great to see regardless of language.

There are times when the right tool for the job is in a language or on a platform that you don’t like.  That’s WordPress for me.  PHP isn’t my forté and it leaves a bitter taste in my mouth, but this tool is so good it absolutely puts to rest any argument that any one thing is fundamentally superior to another.  I’m a Ruby developer through and through, but as much as I love the tools and the language there simply isn’t a single Ruby blog application with this level of polish.  My needs for a blog weren’t terribly specific, and I didn’t need to plug into any backend systems.  The only thing that would have held me back is my own bias, and that would be silly.

If something better than WordPress happens to come along, and it happens to be written in Ruby, I’ll take a look.  Until that time, WordPress looks like it’s the right tool for the job.  That should’ve been a no-brainer.