About Daniel Bachhuber

Code Wranger for WordPress.com VIP

Alyeska, day one

Today, Miles and I skiied Alyeska for the first time. Alyeska is a resort about 40 miles south of Anchorage, Alaska. If you’ve ever seen a Warren Miller or Matchstick Productions Film, you probably are aware of Chugach Mountain Guides which operate out of the same area.

The snow is pretty much the best I’ve skiied in my entire life. The mountain received 34 inches on Monday, 30 inches on Tuesday, and then about 6 inches per day since. That is a lot of snow.

We did 25.5k feet of vertical in 20 runs all over the mountain — and had fresh tracks most of the day. Tomorrow, the goal is to ski from 10:30 am to 9 pm and break 40k feet of vertical.

What makes a good commit message

There’s a useful conversation happening in an internal Automattic P2 I thought I’d take the liberty to share.

From Mike:

Consider the audience when you write a commit message. What is that audience? It’s at least two groups of people:

  • Your coworkers: You’re telling everyone else what you did. Commit messages are one to many, asynchronous and textual. Sounds like email, so write the commit message like an email. The first line should be a descriptive subject. The next line should be blank (as a separator). Then comes the body of the message. Write everything as if you’re describing it to Nikolay.
  • Your future self: Think back on the times you were fixing something and needed to understand why an old commit was made. How often was the commit message useful? How often was it your own useless commit message? The commit message should say what the problem was (repro steps?), how you fixed it (briefly – the code itself gives more details), and why you changed what you did. That way the shiny pants people of the future have the information they need to decide if they can safely change your code.

From Matt:

I think as a company we need better commit messages. Very often in our messages we say what is happening but not the why, and most importantly the context of the change. I’m going to pick on this changeset, but you could really pick almost anything:

[link to changeset]

4 lines changed, with the message:

“Fixing incorrect $blogid variable, should be $blog_id.
Check if $current_blog is === false before trying to reset it.”

First a good thing: it’s a multi-line message, which is nice. Commit messages can use as many lines as you like, and be as verbose as you like.

However if I were to come across this changeset 3 years from now, say if I were debugging a similar area in the code, I’d have no idea why this change happened. The message might as well be blank, since it doesn’t really say anything I couldn’t tell in 2 seconds from looking at the diff. Some useful context would be:

  • What bug did this code cause? (This is most important.) Why change it?
  • Is there a relevant discussion, either on a P2 or in Trac?
  • Who was involved in the fix, IE who else would have context for this change either because they reported the bug or reviewed the fix.

From Lance:

Good commit messages are my gospel. The actual syntax should vary by context, though. For theme commits, for example, we always start with the theme name up front.

But, the goal of giving context and pointing to related items is key.

I personally don’t think long commit messages are better. Instead, point to a Trac ticket or P2 post with all the gory details.

Alex Payne on the process cults

Quote

When I look around the world, the businesses that dominate don’t seem to be the ones that formed around process as a rallying cry. Rather, they adapted processes to bolster world-changing, market-creating ideas. The world doesn’t need a lean startup, or a developed customer, or a REWORK’d business; it needs solutions to problems, magic where previously there was darkness. How that magic happens is interesting and maybe even useful as a basis for other people running businesses to compare to, but it’s not a recipe for success.

Alex Payne — On Business Madness

Run up Timberline Road

Ran up Timberline road tonight because I skied down to Mazama lodge and left my car in the climber’s parking lot. Government Camp is at about 4,000 feet. Timberline Lodge is at 6,000. The road is a snaky, sometimes steep 5 or so miles. I did it in just over 50 minutes… had to take one walk break.

It’s 28 degrees out and I’m frozen solid. The wind is most brutal when all you’re wearing is long johns.

Upcoming talks: WordCamp Phoenix, PDXWP, and CMA NYC

Over the next couple of months, I’m looking forward to speaking at a few different events.

At WordCamp Phoenix on February 25th, I’m presenting “Mastering WordPress Development.” The title lends itself to a number of discussion topics, possibly including coding standards, how to perform migrations, writing bin scripts to manipulate lots of data, participating in open source projects, how to review your code, common mistakes we see at WordPress.com VIP, etc. If you have opinions as to what I should cover, I’d love to hear them in the comments.

On February 27th, Mike Bijon and I will be taking the Portland WordPress Users Group through using Git (and SVN) for version control and working within a team.

At CMA NYC March 18th through 20th, I’ll be leading three sessions (one per day):

  • “I Want To Learn WordPress – An Introduction To Key Concepts” – All of the basics you need to get started, including the WordPress interface and key concepts like themes, plugins, PHP and MySQL, and how to choose a good web host and design for your site.
  • “Hacking WordPress In The Newsroom” – How to take your WordPress development to the next level. We’ll review version control, coding standards, performance and optimization, debugging, and other best practices.
  • “Making The Switch To WordPress” – Everything you need to know about switching to WordPress from CMS X. Well, most everything.

Shaun, Erica, and I will also be hosting a mini-Happiness Bar for a few hours on Monday to help attendees with all of their WordPress questions.

Sweet!

Include posts by matching authors in your search results

Out of the box, WordPress’ search isn’t that great. It only returns posts based on a LIKE query against the post title or post content. Often, you’ll want it to match against other data associated with your post, possibly including the author, tags, post meta fields, etc. These queries can get complex to perform on the fly, however.

The following code snippet allows you to include posts by matching authors in your search results. We’re modifying any search queries to also include all posts whose author display name or user login matches the query. You can change this to be the author’s first name, last name, or other fields.

/**
 * Include posts from authors in the search results where
 * either their display name or user login matches the query string
 *
 * @author danielbachhuber
 */
add_filter( 'posts_search', 'db_filter_authors_search' );
function db_filter_authors_search( $posts_search ) {

	// Don't modify the query at all if we're not on the search template
	// or if the LIKE is empty
	if ( !is_search() || empty( $posts_search ) )
		return $posts_search;

	global $wpdb;
	// Get all of the users of the blog and see if the search query matches either
	// the display name or the user login
	$all_users = get_users();
	$matching_users = array();
	foreach( $all_users as $blog_user ) {
		if ( false !== stripos( $blog_user->display_name, get_query_var('s') ) || false !== stripos( $blog_user->user_login, get_query_var('s') ) )
			$matching_users[] = $blog_user->ID;
	}
	// Don't modify the query if there aren't any matching users
	if ( empty( $matching_users ) )
		return $posts_search;
	// Take a slightly different approach than core where we want all of the posts from these authors
	$posts_search = rtrim( $posts_search, ') ' );
	$posts_search .= ")) OR ( {$wpdb->posts}.post_author IN (" . implode( ',', array_map( 'absint', $matching_users ) ) . ")";
	return $posts_search . '))';
}

Dave Winer on what it means to have Tumblr hiring reporters

Quote

The function of a newsroom in the future is to coordinate the voices of the world to produce a coherent news product. That job will be done in very much the model that Tumblr is doing it. You could have started with a blogging community or you could have started with a news organization, but they’re both heading to the same place.

The Times of course has the best newsroom. So why don’t they evolve a blogging platform like Tumblr’s? They should have. I’ve been begging them to do it since the mid-90s. There’s still time to gather some of the leftover energy in the web, and to be prepared to catch some of the deserters when Facebook, Tumblr, Twitter et al stumble at growing into the space formerly occupied exclusively by the Times, Wash Post, etc.

But less time remains all the time.

Dave Winer — NYT growing the wrong way.