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.

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.

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

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

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!

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 . '))';
}

Today’s view of upper Heather… heavenly.

Highlights from the week include:

• Great conversations with everyone on the team. Our support workflow is really hitting its stride, and I think we have a much better sense now of where we want to take our internal tools.
• Relaunching LIFE Magazine on WordPress.com Tuesday night at the steak house. When I pulled my laptop out at the dinner table, I thought the waiter was going to ask me to close it. Instead, he offered a wifi connection.
• Figuring out how to “fix” rewrite rules for VIPs. Now, to finish and test the implementation…
• Sunset boat ride through the Miami harbor. Ultimate chill out session.
• Lots of great food: Cuban, steak, sushi. I took a semi-break from veganism and allowed myself to eat meat one meal a day.
• Awesome daily runs along the South Beach boardwalk, with a seven miler on Thursday.

All photos, except for the group shot on the boat, were taken with my fancy new Canon S100.

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.