Anthony Panozzo's Blog

I run the continuous integration server Jenkins on my local development machine to work as a better cron. I actually run the Jenkins LTS (long term support) version since it is designed to be more stable than the developer release line.

From the Jenkins LTS docs:

Jenkins produces a new release weekly to deliver bug fixes and new features rapidly to users and plugin developers who need them. But for more conservative users, it's preferable to stick to a release line which changes less often and only for important bug fixes, even if such a release line lags behind in terms of features.

I'd rather have stability than blazing edge features for something that is just supporting infrastructure. Since I am using a Mac, it would be nice to install this using Homebrew. The homebrew-versions keg has a version of this, so you can install it from there with:

$ brew tap homebrew/versions
$ brew install jenkins-lts

Then you can run it with the commands listed at brew info jenkins-lts. By default, jenkins-lts will have a plist to control startup and teardown of the Jenkins process at ~/Library/LaunchAgents/homebrew.mxcl.jenkins-lts.plist:

This blog used to run on WordPress, but I was not entirely happy with it. I changed it to use Octopress (an extension of Jekyll) and I enjoy the writing workflow better now.

WordPress is a content management system, and as such, it does a whole lot of stuff. WordPress has a ton of built-in functionality and is well-tested. With plugins, you can add many things: from shopping carts to calendars to image slide shows. Other plugins can give you detailed permission models and auditing for posting or other complex functionality.

Advantages

I didn't like WordPress for blogging for a few reasons (many of them very specific to my workflow.)

I prefer writing with Vim, and no WordPress functionality was going to easily replace this tool. This alone would probably be enough to get me to switch. Typically what I would do would be to compose a post in Vim, and then copy that into WordPress, do a little previewing to make sure everything looked good, then schedule the post for some future date.

Using a static site generator like Octopress or Jekyll enables me to use git. Git tracks detailed version changes across the entire blog (not just the posts). It also lets me work locally and then easily deploy when I am back online or finished. With WordPress I would have to connect to the server to be able to write. I can now even preview locally, something I could never do without an internet connection. Further, I can set it up so that preview updating happens whenever I save the file, so I can see how changes look in near-real time.

I've been doing a fair amount of flying in the last year, and Southwest is currently my favorite airline. In this post I will list reasons why Southwest is the best (in order of importance) and one thing I'd like to see improved.

Biggest Benefits

Liberal reschedule policy

Probably the biggest benefit to me has been Southwest's liberal flight rescheduling or cancellation policy. On many other airlines, changing or cancelling your flight reservation (whether it is days or months away), will cost you hundreds of dollars. Have something come up at the last minute? Well, you're out a hundred bucks to change your flight by an hour or two. You can pay much more for a refundable ticket as well.

Southwest does not have this restriction, so even if you pay a little more for your ticket, if you use this option one time, you are going to come out ahead. Worst case, if you cancel, you get a credit to apply to future Southwest flights.

I tried a new tool with Kyle Shipley recently, and it has proven to be interesting and useful.

Floobits is a recently-created remote pairing solution. Imagine wanting to pair with someone and they are across town or in another state.

I enjoy pairing remotely, as it lets multiple people work together even when they are not colocated. I think that pairing is a great way to share knowledge on a team and reduce defects by promoting accountability and quick feedback. Further, I think that remote worker morale increases when talking and working with teammates.

Kyle and I used Floobits to pair on a random coding project, and I found the entire experience compelling enough to get past the set up and some early wrinkles. With Floobits, you create a shared workspace that other people can view (public or invite-only). You install a plugin to your editor and maybe a custom build of the editor. Then when you make changes to the file, diffs of the code are sent up to a server, which then propagates to anyone connected.

Existing solutions

There are some solid existing solutions out there like sharing tmux or screen sessions.

Today's short idea is: before you hardcode a value or comment something out for debugging purposes, write a test that ensures that you change it back. This way you break the build if you commit the change.

The thought here is that if the functionality is actually important, there should probably be a test for it.