Here’s supercommits.php, a quick and slightly hack-ish script to find them. It can be run from any SVN working copy directory.

There should be a complete absence of the annoyance and irritation caused by the necessity of searching for lost balls.

Allister MacKenzie, The Spirit of St. Andrews

I’ve been playing lots of golf lately and it’s reinforced my long-held opinion that the design of most golf courses is just awful. That got me to thinking: what would go into my ideal golf course?

Easy first hole

The first tee is no time to ask a player to hit a great tee shot. No one is really warmed up at that point and the point of golf is to be fun — the way to make a round fun is not to require a 270 bomb with the first swing. That hole has its place, but it’s later in the round once you’re in a rhythm. Making a hole difficult because it’s first is like making it difficult by shouting during someone’s backswing; it’s certain to add strokes, but mostly unrelated to skill or quality of execution.

The first hole should be playable with a fairway wood or long iron from the tee and it shouldn’t have any water hazards. It should also be a par 4. Par 3′s will slow down play too much at the beginning of the round and should also require more accurate distance control than can be expected on the first hole. Par 5′s easy enough to qualify for a good first hole are just a waste of a potentially fun birdie hole later in the round.

No fescue (or other pseudo-hazards)

Three foot tall fescue looks great in the photo gallery on a golf course’s website, but is absolutely useless almost every time it’s planted on a golf course. Fescue is the worst kind of pseudo-hazard because you’re very likely to lose your ball in it and the rules of golf afford you only one solution: re-hit. Fescue tends to come into play in two places: not-so-great shots and really awful shots. Both are bad uses.

The “not-so-great shot” fescue is usually 5-10 yards off the fairway, after a relatively narrow line of normal rough. In this case you’ve hit a bad drive, but not one that would give you any trouble in approaching the green or at least laying up on most other holes. But the architect decided to drop some knee-high grass here, so now you’re searching for a lost ball after being 10 yards from a perfect approach. The “really awful shot” fescue is usually on parts of the coure that don’t even seem like they should be in play, those spots where it’s just filling the gap between the border of the property and the designed hole. In this case you’re usually in pretty bad shape and don’t have any shot to the green, so I’m not sure what the point is of punishing you with fescue here.

The result is that fescue usually feels like random punishment — maybe you’ll find it, maybe you won’t. that’s bad, lazy design.

Creative punishments

My first two points shouldn’t imply that I want to put bumpers on any hazardous part of a golf course. I am all for punishing bad shots, but yet-another-hazard is not the only way to do it. Instead of filling courses with ponds and fairway bunkers (and fescue) to combat any wayward shot, architects should use more interesting tactics. One of my favorites is slopes and blocked views. Give me a side hill lie to a hidden green when I hit a bad shot. It makes the course just as difficult if you’d plopped down another fairway bunker, but much more interesting.

Fewer tee boxes

When I started playing golf every course I knew of had the same three options for tees: blue, white, and red. Then came gold tees. Now choosing a tee box to play from can feel like shopping for laundry detergent. Fix or six tee boxes on a course is no longer uncommon, and it results in far too much artificial development. Building that many tee boxes means often half a hole is unnaturally-manufactured, and the rest of the hole is dulled down to accomodate shots from every conceivable distance. Three tee boxes means minimal disruption of the hole, and if a couple people play from tees that are slightly longer or shorter than they’re used to the game will be that much more interesting.

Mark every sprinkler head

There are few things more frustrating than walking in circles trying to find a marker when your ball is right in the middle of the fairway. Doubly so when you come across many unmarked sprinklers on the way. It baffles me when this happens because markings on the course are so useful and so easy to produce that the only thing that makes sense is marking everything out there.

This extends to sprinklers that are over 200 yards, by the way. I once saw a sprinkler marked “Don’t even think about it”. While this was cute and did make me laugh, it was still annoying because even distances I can’t reach are useful to measure. No one’s going for the green from 300 yards away, but knowing that it’s 300 and not 350 means I will hit a different club to layup. Measuring the distance costs almost nothing, so just do it and make it easy to find for the people playing your course.

“Good” places to miss

A sufficiently-hard golf hole should often give you very difficult shots. That’s great as long as you give me an option to hit an easier shot in exchange for lost (portions of) strokes. Your green tucked behind a row of bunkers is just lazy if you don’t give me a bailout area to aim for when I can’t make the approach, maybe because I’m in the rough.

Usually when this is done it’s right in front of the green, where the fairway extends right up to the fringe. That’s boring and often pointless, as architects try to squeeze that area as much as possible between the green-side hazards. A great bailout area can still require a carry over hazards, but give me a more forgiving place to land to the side of the green. A very underused design feature is bailout areas behind greens, which I wish I saw more of. These make the player commit to going long and not missing short to be safe. Whatever you decide, just give the player more than one way to play the hole.

Obvious targets

Every time I stand on a tee and wonder where I’m supposed to hit it, a golf course architect has failed miserably. There are so many ways to give players a visual clue about where to play, that not doing it is unforgivable. The boring way to do it is the classic barber pole in the fairway on your target line. More creative architects use natural features of the land — a large tree in the distance, a boulder, a bunker you have to carry, etc. On any tee shot you should be able to tell me in a few words what to aim at so that I don’t have to wonder. I can’t count the number of times I’ve stood on a tee, unsure, hit it exactly where I was aiming and though, “I hope that’s good”. If you can’t give me an indication of where to hit it, you’re not allowed to make tee shots with obstructed views.

We’re making it less random to make it feel more random.

Steve Jobs, on the iPod “shuffle” feature

iPod customers complained that the shuffle feature wasn’t random. Noticing repeats in artists, albums, or genres, users concluded that the shuffle wasn’t properly shuffling. In response, Apple made the shuffle non-random by preventing repeats of similar songs in close proximity.

I had to invent integral and differential calculus to figure it out.

Issac Newtown, on explaining elliptical orbits

Technology companies go through constant analysis of build versus buy. Almost every part of a technology company’s product and tools can be built or bought; it’s something I think about pretty often.

I just came across this incredible interview with Neil deGrasse Tyson where he tells a “build versus buy” story about Issac Newton, of all people. Tyson is asked by a young kid, “How do you figure all of this out?” Meaning, I guess, how do you become one of the most influential physicists in the world. A great question, though probably one the kid wasn’t really expecting an answer to. Tyson, as usual, delivers. He talks about applying tools to problems, and how the very smartest people can make their own tools to solve their own problems.

Issac Newtown wanted to explain why planets orbit the sun in ellipses rather than circles. To do it, first he invented calculus.

It’s pretty common for WordCamps to have multiple tracks, and when it happens it’s almost always split by types of people — developers and users, and sometimes designers. I won’t go through the many, many examples, but there are more than enough just recently to make the point, like: this, this, this, and this. To a lesser extent, the same thing is common at WordPress meetups. I think this strategy is misguided. Conferences’ and meetups’ greatest values to me are the chances to learn something. Describing tracks by who you are (a proxy for what you already know) instead of what you want to learn misses those values.

I’ve recently started co-organizing the San Francisco WordPress meetup, which is a pretty big and diverse group. Big and diverse is great, but part of the territory is that no matter what you do, someone will tell you that you should have done something else. Try a technical-focused presentation and you’ll hear, “It was too hard to follow for non-programmers”. Try a publisher-focused presentation and you’ll hear, “This doesn’t relate to my freelance web development business”. That’s not meant to be a knock on attendees, because those are both completely reasonable responses.  As an interested WordCamp attendee and new meetup organizer, these things have been on my mind a lot.

Even if segmenting an audience by its characteristics made sense, it probably doesn’t work. Audiences cannot be so clearly compartmentalized. Does a “Developer” and a “User” track imply that developers aren’t users? I hope not. Developer is a vague term; at what point does a power user that opens up functions.php or starts a child theme become a developer? How many blog posts does a developer have to write before they qualify as a user? Neither developer nor designer nor user is a mutually exclusive characteristic; what’s the point in segmenting people by population when they often won’t fit into your segments?

An event organizer is an entertainer. They put together a program that they think will give their audience the greatest value, which probably means a combination of education, networking, and fun. The whole concept of an event is about the audience, and its of little benefit to the audience to divide itself based on who they are. I don’t think anyone goes to events to meet people who are just like them. I hope people go to learn something and meet people who are interesting and informative — even moreso, I hope WordCamps and meetups aim to inform and interest attendees by introducing them to new people and ideas. The tracks should be organized in a way that makes finding interesting, informative content as easy as possible. For me, that means organizing sessions by what the content will be, not who the audience should be. If I’m a blogger that wants to learn how to write plugins, should I go to the developer track? For that matter, am I even allowed to go to the developer track? It’s not entirely clear from the name, and while I know anyone who wants to attend any session is welcome, we shouldn’t assume everyone does. Nor should we assume everyone will want to attend sessions just because other people like them are there.

The more granular you make the audience distinctions, the less useful they become. If there are five tracks and I fit into four of them, my choice of what to attend is really a choice of which part of myself I…I don’t even know. Is it which part I like the most? Which part I want to improve the most? Which part I feel the most confident in? There is very little context when asked to self-categorize like this. On the other hand, if the choice is which type of content I’m most interested in, there’s a lot more context for prioritizing my options and less opportunity to fear expected or allowed.

The naive reaction to this is to try to reduce the complaints by (dis)satisfying everyone equally — one common approach is alternating the focus of each meetup between however many groups you’re trying to cater to. The more-likely-to-succeed approach is to optimize happiness by communicating your goals to your audience. Maybe that’s to be focused on raising the technical bar, or developing a crop of great writers, or making everyone a multi-talented WordPress user (see, “user” is a vague term, too). Any of those are fine goals as long as everyone has the same expectations. What won’t work, especially in a city as big as San Francisco, is to be everything to everyone by making enough granularly-focused tracks to hit all the requirements.

My ideal event would focus on being as valuable as possible to its audience by doing two things.

1. Communicate your goals clearly. Let me decide if your goals match mine, but don’t try to force it.
2. Give me the information I need to get the most out of your event. Start with what I can learn and where. Let me figure out who I want to spend the time with, whether it’s people like me or not.

I met with one of the other organizers of the San Francisco WordPress meetup last week and we talked about this challenge. We both agreed that it was nigh on impossible to give everybody what they want, but the solutions are a bit scary. We certainly don’t want to alienate a large portion of our audience to focus on something that turns out not to work. But we agreed that straddling the fence wasn’t a viable solution. We have some things we’re going to experiment with, but nothing certain.

In the meantime I’m going to keep thinking about how to make events more useful for audiences. You have a bunch of people who share a common interest and came to the same place (physical or not) to talk about the same topics — I just can’t believe that separating them on specs is the best first step.

I have a big shoulder turn — actually quite a bit too big according to the Golftec target data — and part of that is because I also have a big hip turn. Combined, that makes for a long swing which makes it harder to get back to impact well. Here’s a quick before swing.

My hips get very closed and with a bit turn on top of that my shoulders are actually past 110 degrees closed at the top of my backswing. What actually creates most of the power in a golf swing is the difference between your hip and shoulder turn. We worked on maintaining that difference but getting both numbers lower. The goal was to make my swing shorter overall but keep the big coil in my backswing and keep the club in a good place without getting too far across the line at the top.

After a few drills to keep my lower body quieter the results were pretty obvious. My swing is clearly much shorter, and I hit almost every ball dead center which was clear feedback to me that as my swing gets longer I have a really hard time keeping everything in line through impact. You can actually see one of the drills in the “after” swing in this video. My instructor held a club between my knees so that I couldn’t rotate (much) against it. This felt awkward, but again, the feedback was pretty clear that I hit it great with the more compact move.

• Linode 512 MB
• Debian 6 32-bit
• PHP-FPM
• APC (for opcode and object cache)
• nginx
• WordPress Multisite
• Batcache

I documented my setup and after testing it with another friend (it worked!) and mentioning it to a couple others, decided to post it here. I’m going to assume you’re familiar with the basics of administering a VPS, especially SSH.

Linode

I did this on Linode, but it will probably work fine on pretty much any VPS (or dedicated server). It won’t work on a shared host because it depends on installing specific software that requires root access. My server needs are not very extravagant so I chose Linode’s cheapest plan, a 512 MB VPS. You’ll need to choose a location for your server, and since I have no idea what the practical differences are, I went with Dallas based on a recommendation. For the purposes of this tutorial, it doesn’t matter which one you choose.

Go through the Linode setup, choose the Debian 6 32-bit distribution, get your ssh information, and login to your new server. If you use a larger VPS you might want the 64-bit distribution, but on a 512 MB server that’s going to cause problems.

Linux

Linode has a very good tutorial on the first few things you’ll want to setup with your new Linux install. Once you’re logged in you can skip to the security section in Linode’s “Getting Started” tutorial. That will walk you through:

• Updating your package installer
• Setting your server’s hostname
• Setting the timezone

Your settings here can be unique to you. In my case I like to name computing devices after Yankees players (see my external hard drive named Mattingly) so I called my Linode server dimaggio. I like to use my local time, which is America/Los_Angeles in the Linux world. Some people like to use UTC, which we do at Automattic. Pick your poison.

Before you go any further, you should install sudo because you’ll need it soon and your server won’t have it by default. You can do it with this one liner:

apt-get install sudo

Now that you have the basics setup, it’s time to move onto the real stuff — users, permissions, firewalls, and software. Slicehost has two great tutorials on this: Debian part 1, and Debian part 2. We’ll go through these now.

You don’t want to be logged in as root any longer than you absolutely have to. The first thing Slicehost will walk you through doing is creating a new user account. They use the username demo but you’ll probably want to use your first name. In my case I skipped the additional group management steps; I don’t plan on managing a large number of users and it’s easier to have fewer moving parts. If you don’t assign your user to a group, it will be automatically put in a group with its own name — my user is in a group called evan. Slicehost will walk you through the details, but I’ll add one suggestion: do not log out of your root SSH session until you’ve successfully logged into your user account and confirmed that your sudo access works. Otherwise you’ll need to reset your whole server and start from the beginning. Once you’re setup, move onto part 2.

Part 2 mainly covers Bash and the Aptitude package installer. I am pretty particular about my bash prompt. You can grab the key parts of mine here. This does a few things:

• Shorten long directory names by replacing the middle with an ellipse
• Add the git branch name to the prompt (if you’re in a git repo)
• Use up and down arrows to search your bash history using whatever you’ve already entered as a search prefix
• Make tab cycle through available commands instead of listing them
• Add tab-completion for git commands

The git pieces rely on this git auto-complete script.

Once you’ve got your .bashrc setup and your package repositories updated, it’s time to move onto the the next step: nginx.

The stack: PHP-FPM

Debian’s default package repository has an outdated version of PHP-FPM, so first we’re going to add a new repository to our list. Aptitude’s repository list is kept in /etc/apt/sources.list and we want to add a new line with this repo: deb http://packages.dotdeb.org stable all. You’ll need to use sudo to edit this file and save it. When you’re finished, it should look something like this. Now go back to your home directory and setup your new repository.

cd ~
wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | sudo apt-key add -
rm dotdeb.gpg
sudo apt-get update
sudo apt-get upgrade

Now we can install PHP and its siblings:

sudo apt-get install php5 php5-fpm php-pear php5-common php5-mcrypt php5-mysql php5-cli php5-gd php5-apc

We’ll be using PHP-FPM to handle all of the PHP requests that come in through nginx. To do that, we’ll need to update the PHP-FPM config at /etc/php5/fpm/pool.d/www.conf. We will set PHP-FPM to decide how many processes it will run and how it will listen for requests from nginx. My config file is here. It will set PHP-FPM to spawn a reasonable number of children and servers for 512 MB VPS and configure it to listen over a Unix socket instead of a TCP port. These settings may not be perfect for you, but they should get you started.

Restart PHP to make sure your new settings are in effect.

sudo /etc/init.d/php5-fpm restart

The stack: nginx

We’re going to use nginx as our web server, so first we’ll install it.

sudo apt-get install nginx

Now we’ll setup our nginx config at /etc/nginx/nginx.conf to tell nginx how to server our data. This file is pretty straightforward, but it does assume you’re using the 512 Linode server (or another one like it). You can grab mine here.

Once you have your config in place, restart nginx to use the new settings.

sudo /etc/init.d/nginx restart

The stack: MySQL

The last part of your stack is MySQL, which we will install now:

sudo apt-get install mysql-server php5-mysql

Once you complete the MySQL installer you can head over to Linode’s low memory settings tutorial to configure some settings for MySQL geared toward low memory servers (which a 512 MB VPS is). I followed their guidelines in my config, so I won’t copy it here. The last two items won’t be in your default my.cnf file, so you can add them at the bottom.

Email

One last thing you’ll want to install here, even though it’s not a part of the traditional L(A|E)MP stack, is an email server. Again, Linode has a great send-only mail server tutorial. If you want to configure a mail server to actually receive email, that’s outside the scope of this post. In my case my server’s only interaction with mail is to send it — for example, when you need to reset your WordPress password.

WordPress

There are lots of ways to get WordPress installed. In my case, I had a few requirements that guided my choices:

• I’m using WordPress multisite
• I’m using the multisite domain mapping plugin
• WordPress will manage my whole site
• My site will be version controlled with git

After experimenting with lots of different options, I decided on this setup:

• My public directory will just be a copy of my git repository
• WordPress will be installed in my git repository as an svn export
• Local development will use Mark Jaquith’s local config setup

At this point, you’ll want to install git on your server so that you can pull in your repository. Again, a one-liner will do it for you:

sudo apt-get install git-core

I setup my git repository and exported WordPress trunk, then setup my local-config.php per Mark’s instructions. Next I setup my .gitignore file to make sure I didn’t accidentally commit any of the local-specific data.

.DS_Store
/local-config.php
/.htaccess
/wp-content/uploads/
/wp-content/blogs.dir/
/wp-content/plugins/hello.php

I won’t walk through the WordPress multisite installation. If you need help with that, there’s a great Codex article that covers it. The only part specific to this tutorial is that you won’t want to use the .htaccess file (notice how I .gitignore‘d it?) because we aren’t using Apache. Instead, you’ll use a nginx config file to handle this. In my case, I put a file called .nginx-config into the root of my git repo and symlink it to nginx’s sites-enabled directory. You can grab my config file here — obviously you’ll want to replace domain.com with your actual domain. I have a couple other rewrite rules specific to my site, but this should cover the basics.

Again, that config goes into your git repo, which means nginx has no idea it exists yet. Once you’ve pulled your git repo onto your server, you can symlink it to the place nginx will look (/etc/nginx/sites-enabled). In my case my web sites are being served from /srv/www/domain.com/public, so that’s where my git repo will be pulled. This directory won’t exist by default, so you’ll need to create it as well as /srv/www/domain.com/log, which is where nginx will store your access and error logs. You can put your website content in another directory if you want, but you’ll need to change the nginx config file to make it work. Now you can symlink your config by running:

sudo ln -s /srv/www/domain.com/public/.nginx-conf /etc/nginx/sites-enabled/domain.com

This will take care of copying your rules to nginx, and it will also block nginx from serving that file publicly because it starts with a dot.

Restart nginx to make sure it uses your new virtual host.

sudo /etc/init.d/nginx restart

Batcache

Last, you’ll want to setup caching for WordPress. I’m using Batcache, which uses the WordPress object cache for all of its page caching. We use it on WordPress.com and it’s super-configurable, but I’m using it with the out-of-the-box settings for now. Batcache requires a persistent object cache backend, which Mark Jaquith’s APC plugin is perfect for on a one-server setup. If you’re running multiple servers you should use Ryan’s Memcached plugin (and you should also have stopped reading this a while ago). We already installed php5-apc (along with the rest of PHP) so there’s no server config needed here.

The Batcache installation is pretty straightforward. You will put Batcache’s batcache.php into /wp-content/mu-plugins (which you’ll probably need to create). Then you’ll put Batcache’s advanced-cache.php into /wp-content. Finally, you’ll put APC’s object-cache.php into /wp-content (the same place as advanced-cache.php). You’re almost there, you just need one line in your wp-config.php to tell WordPress to use the cache:

define( 'WP_CACHE', true );

Finale

That’s it. You should be good to go with a very fast and easy (relatively speaking) WordPress setup. There is some other house keeping you might want to do, like hardening WordPress, but I’ll skip that for now because there is plenty of good information about it on the Codex. You’ll also need to setup your DNS, both within Linode and in your domain registrar. This is no different than any other setup so I’ll skip that as well. Finally, you may want to configure other server-specific settings, like rotating logs. You should check out Linode’s tutorials on those.

For a bit of fun, you can run Apache’s benchmark test to see how many requests your server can (in theory) serve per second. First you’ll want to install Apache’s dev tools. Once you do that, from your server, we can throw a bunch of traffic at WordPress:

sudo apt-get install apache2-dev
ab -n 10000 -c 1000 -H 'Host: domain.com' http://127.0.0.1/

The output will include a “Requests per second” line, and in my experience you should be able to hit the mid-6000′s.

Edit: I really do want to clarify this is mostly for fun, and not a useful metric of how much traffic you’ll be able to handle. The one place this is actually useful is comparing your new server to an old server, purely on a relative basis. For example, my old site running Apache with mod_php came in around 200-300 requests per second. So I can get a sense of how much faster the new server is, but it does not mean I’ll be able to serve 500m page views per day from one VPS.

Again, I owe many thanks to Pete Mall and Mark Jaquith for helping me figure this out.

“Twitter’s simplicity is brilliant, they stuck to the 140 character rule and that made it so easy,” they’ll say. Then you go to twitter.com and, if you’re me, end up clicking almost blindly at an endless array of mouseovers, pop-outs and hover-state jumbled calamities.

“Square Card Case is amazing, just give them your name and get a receipt emailed to you,” someone tells me. Then I download and install Card Case and am taken through the most confusing setup process I’ve ever seen where my goal is only go give someone my credit card number — in fact, that’s not just my goal but the only thing I can do to make the app usable.

I was reminded of this misconception about what’s easy last week when my parents were visiting. They were trying to find the way to walk back to their hotel when I pointed out that it’s only about a mile away and my dad was carrying a shiny iPhone 4, complete with GPS and directions. “I don’t know how to use that,” he said. Assuming he meant he just didn’t know the hotel’s address or how to search for it, I took his phone, opened Google Maps, typed in the hotel name and asked for walking directions. Shockingly, iOS alerted me that the Maps application wanted to use my (his) location. “Hmm, what’s odd,” I thought to myself. That thought lingered for a moment until I realized what it meant. He was joking, he really didn’t know how to use the maps or GPS on his phone, a remarkable fact evidenced by the even more stunning realization that he’d actually never used the app. Accordingly, he had never granted it permission to use his location. “I searched for ‘GPS’ once, but nothing came up, so I assumed it wasn’t there,” he told me upon further questioning.

I confirmed the prompt, got their directions, and sent them on their way. But it was an enlightening reminder to me that even the iPhone, which I think most people agree is simple and easy and fun and so amazing it will shoot rainbows out of the unicorns it embeds in your eyeballs…can fail so miserably at helping someone find the thing they want, even when it’s right there on the home screen, staring them on the face.

This icon is covert.

The point is not that Twitter or Square is confusing, or that the iPhone is poorly-designed, or that my dad shouldn’t have been able to figure out where the damned Maps app was — I mean, it’s right there on the home screen and it has a picture of a map! The point is that it’s easy to say Something Else™ is easy. You don’t see the support requests for Something Else™, you don’t get alerts about the tickets for the bugs you haven’t fixed in Something Else™, and if the media likes Something Else™ it’s convenient to agree and move on. Worse, it’s convenient to copy the parts that seem like good ideas. There are products that are genuinely brilliant, and even the ones that aren’t probably have at least one thing you can learn from, but I’m frustrated by how commonly it seems people are not learning, but rather spectating and assuming.

The emperor probably isn’t wearing any clothes here, and the guy making Something Else™ may well be looking at the parts of your product that you know are broken and remarking, “Look how easy it is…”

His word means everything to him, even when his words mean nothing.

William Saletan, The Conversion

William Saletan writes an extraordinarily well-researched article for Slate on the history of Mitt Romney’s public stance(s) on abortion. Regardless of politics, I wish this level of detail in journalism was more common — or for that matter, common at all. Slate deserves a lot of credit for publishing this, rather than 25 articles at a fraction of the cost that probably would have generated many times more pageviews.

After she learned Python, Trigger then had to complete a Django tutorial in order to bring the Python online — she used Heroku to push stuff to a webserver.

Alexia Tsotsis