Articles

On Contributing to WordPress

WordPress 3.5 was the first release that I’ve had any meaningful involvement in as a contributor. Before this, I’d spent time lurking around in IRC and browsing around tickets in Trac, but with no real purpose or intention. With 3.5, I really wanted to try and see what I could contribute.

The result? Well, if you look real close in the screen below, you’ll see my name in the bright lights near the bottom. Seeing my name on this page was extremely exciting.

But then the guilt

Truthfully, although my name does magically appear on the credits page, I must confess that I did very close to nothing to help out with the development and release of WordPress 3.5. Very early on, I participated in some discussions on a new look for the Welcome screen, I very briefly popped in to talk about the “Page on front” workflow, I suggested that icons might be nice on the welcome panel, and I thought that a border might be nice under h2 tags in the Twenty Twelve theme. Like I said, in the scope of this thing, I contributed almost nothing.

Why didn’t I do more?

There are two main answers here:  A) I just didn’t. Simple as that. And, B) the technical reasons.

Before I say anything about B), I want to make it absolutely clear that I did not do all I could to overcome the technical hurdles I faced when trying to contribute. I didn’t read as much as I should have, I didn’t reach out enough when I ran into issues or got confused, I didn’t develop a deep enough understanding of Trac, I didn’t step up and claim ownership of issues I could actually help fix. I want to make that crystal clear that I personally did not do enough to overcome the issues I ran into. Ok, so onto B: the technical issues.

Technical Overhead

Contributing to WordPress comes with a lot of overhead. Knowing how to setup a local install of the latest version, keeping that up to date, creating patches, applying patches, and I haven’t even mentioned Trac yet. A lot of the issues I had have already been pointed out in the notes from the “Engaging/Retaining New Community Devs” at this year’s community summit, but I want to
specifically go through a few of the issues/questions I had here:

1. I use Git. Is that ok? Should I just learn svn already? Update: Scribu posted a great, concise how-to. Sounds like you’ll never need svn again.

2. Making patches. Helen very kindly walked me through the process of making a patch. Very soon after, however, with no practice, I’d forgotten the basic steps

3. Keeping my repo in sync. So, I clone WordPress from Github per Mark Jaquith’s instructions and start working on a ticket. As soon as touch a single line of code, my repo is out of step. What do I do now? I’m positive I’m not doing this right, but I don’t the right way to do it.

4. #Trac. How people can find and sort tickets to issues is just beyond me. I find Trac to be almost a complete mystery. How do I find open tickets? How can I get a list of tickets that I might be able to work on?

5. #wordpress-dev. The folks who inhabit #wordpress-dev on IRC are extremely knowledgeable and helpful. They’re also very busy and focused. This definitely isn’t the place for questions like “how do I make a patch” when we’re right in the middle of heavy development. But outside of there, I don’t really know where else to ask that question.

6. Foraging for resources. I wish there was one good, comprehensive guide to contributing that brought you through all the steps. Everything from cloning the repo, making changes and not ‘breaking’ the repo, searching Trac for a ticket, creating/applying a patch, etc, etc. There are a lot of great resources out there, but they’re scattered around and sometimes not easy to find.

A few ideas

I can’t just create a list of problems without suggesting some ideas to help fix them. Two things stand out for me as being potentially huge for new-comers like me:

1. Mentoring. The word mentoring is loaded, I know. It comes with connotations of a long, arduous and time-consuming process but it doesn’t need to be. My suggestion? Create a place where a mentor can help walk you through three tickets. That’s it. In the process of working through these three tickets, the mentor can teach the new person how to set up a local repo, create/apply patches, and give them the basics of Trac. I think three tickets would be more than enough to get someone started.

So…..the real question here is — where do we get these tickets?

2. Identifying/tagging ‘easy’ tickets. Early in the release development cycle, you see lots of “easy” tickets floating around Trac. I’ve seen some that require changing a single line of css! Tickets like this would make a perfect starting point for someone new. Here’s how it might work:  A ticket would be tagged as “easy” or “beginner” and a mentor would assign it to their new student. Tagging a ticket with “beginner” would mean that an experienced person should leave the ticket alone until a new person has had a crack at it.

This process would really get to the root of my issues pretty fast. Having three easily solvable issues assigned to me, with the support of an experienced mentor would be huge.

A brief afterword

As I hope I’ve already made perfectly clear, many of the issues I encountered in the past few months could have been solved by simply trying harder and persisting more. That said, there really is a lot to learn, and the biggest part for me was finding something small and “easy” to learn with. As you would expect, as soon as a simple ticket shows up, someone has a patch created in a few minutes. I really think that leaving some of these easier issues in reserve for new-comers, and actually assigning them, would be extremely helpful. While I recognize that this would slow down development, I think it would really be worthwhile, at least early in the cycle, to have new-comers get their feet wet with actual tickets.

December 10, 2012 Folded neatly in:

The Mess of Web Hosting

Web hosting is an absolute mess. Still.

Even with a swath of new, so-called “good” shared hosts, an endless number of “rock solid” VPS providers, many brand new niche Platform as a Service (PaaS) providers, and several managed and dedicated options, the world of web hosting is still a disaster.

The Trouble with Choice

Of course it isn’t the same disaster as it used to be—price—no, it’s a brand new disaster now—choice. There’s just so much choice on the market these days, with everyone innovating around the same core prodcts: offer more RAM in your base VPS, wrap a better interface around EC2, offer unlimited subdomains on shared hosting at 13cents per month. It’s all the same products over and over again.

Hosting for me

If I had any clue how to even go about setting up a hosting company, I’d start by targeting people like me: freelancers who host low-traffic sites for a dozen or so clients at any particular time. At the moment, I’m moving (again) from a shared host to a VPS. I host about 10 personal sites (development sites, a recipe organizing site, a site for collecting photos, a site for storing my bookmarks, etc), and somewhere around 10 client sites. Not a single one of these gets anything close to high traffic. Some of my personal ones get a few hundred hits a month, while some of the bigger ones get less than 10,000. We’re talking very minor traffic. But they’re all important. My bookmark manager is just as important to me as my clients’ sites are. The problem is that the market doesn’t think they’re important. The market thinks that I’m happy enough to house my low-traffic sites on a shared host until my numbers start to grow. But of course that just isn’t the case.

Wants and Needs

I’ve covered the needs part already— I need a host that can serve my low-traffic sites dependably. That’s not asking a lot. My list of wants isn’t long either:

— I want one login: I don’t want 4 welcome emails with different logins to different ala shared hosting. I don’t want billing to be separate from my support, separate from my cPanel, etc….which brings up my next point
— I loathe cPanel. It’s massive and almost completely unnecessary. I want a simple interface for adding new sites and subdomains. Simple as that.
— Git: I thought this would be standard nowadays. It isn’t.
— Affordable pricing—I know that there’s great, dedicated and niche-specific hosts out there. But, as good as I’m sure they are, I’m really not going to spend $99 per month to host my clients’ sites. That’s simply too much money to serve up less than 30,000 pageviews, no matter how fast the support response is, or how much uptime you guarantee.

Why doesn’t this exist yet?

That’s the part I’m not sure about. It seems like there’s a huge market of people like me out there, who would happily turn over $30 a month to get a nice, simple interface for managing our low-traffic client sites. But there isn’t. I really, really hope a talented entrepreneur stumbles past this post and gets inspired to start a new kind of hosting company.

Note: I feel very-well qualified to write about this topic. To date, I have tried GoDaddy (*shudder*, I know), Host Gator, Bluehost, Dreamhost, Linode, Mac Highway, Media Temple, EC2, Pagodabox, Open Shift, Appfog, A Small Orange, and Lithium. My best results have been with Mac Highway and Linode where my stuff is currently housed. Despite trying 13 (thirteen) hosts, I’m still unsatisfied. 

December 4, 2012 Folded neatly in:

Chrome Shortcuts

I love shortcuts. I love Google Chrome. Here’s a few of my favourites:

  1. Goto Address Bar: cmd+L
  2. Duplicate current tab: cmd+L to select the address bar, then cmd+return to duplicate
  3. Move between tabs: cmd+opt+left/right
  4. Back/Forward buttons: cmd+up/down
  5. Open last closed tab: cmd+shift+t

I just discovered #2 and #4 this week! Love’em already.

December 4, 2012 Folded neatly in:

A recipe for happiness and success

Hard to add or subtract anything from Dustin Curtis’ recipe:

Do.

Wake up early. Show up. Learn how to think. Be genuine, but appear nice. Use envy for motivation instead of destruction. Do what you say you’re going to do. Ensure balance in every area of your life. Confront repressed thoughts immediately. Surround yourself with people who are better than you (but remember the thing about envy). Work out every day. Be good at what you do. Make money doing what you love. Have good friends. Never settle.

This is my personal recipe for happiness and success.

The part in the middle is particularly good, so make sure you don’t miss a single word of it:

Wake up early. Show up. Learn how to think. Be genuine, but appear nice. Use envy for motivation instead of destruction. Do what you say you’re going to do. Ensure balance in every area of your life. Confront repressed thoughts immediately. Surround yourself with people who are better than you (but remember the thing about envy). Work out every day. Be good at what you do. Make money doing what you love. Have good friends. Never settle.

And the first part is essential too:

Do

Be sure to read it in its natural environment, and have a look around while you’re there.

Which template — an essential theme development function

So you’re developing a theme for a new project that you’re working on. It has lots of queries, a few different content types, a custom taxonomy or two, etc… It can often be difficult to determine what template is generating the page you’re looking at on the screen. Is this page using page.php, page-{slug}.php, single.php, taxonomy-{taxonomy}-{slug}.php ? You get the idea.

I use this function on every single site I develop, but don’t often see it being used out there in the wild. Just pop this function into your functions.php file and it will output the current template file being used to the bottom of your page:

/**
 * Print out the current template file to the footer.
 * Remove before launch. 
 *
 */

function waterstreetgm_which_template() {
	if ( is_super_admin() ) {
		global $template;
		echo '<strong>Template file:</strong>';
		print_r( $template );
	}
}
add_action( 'wp_footer', 'waterstreetgm_which_template' );
October 10, 2012 Folded neatly in:

Bones and Underscores— a WordPress theme head-to-head

I have a big week coming up. I’m starting two brand new projects and I’m pitting two top WordPress starter themes against each other in a battle royale:

Underscores

First up, we have Underscores from the Theme Team at Automattic. It is very clean and stripped down, and truly satisfies the ‘starter theme’ criteria. It comes with the barest of necessities, but leaves nothing out at the same time. For you old-schoolers out there, you might notice that a lot of Underscores looks very similar to Toolbox, it’s predecessor. In short: Toolbox was a good starting point for developing themes and Underscores is a great one. Let’s have some pros and cons:

Pros:

  • Underscores is familiar. This is really only important to me, but it still matters. I used Toolbox on a lot of projects, and still use my fork of it—Victoria Park—for lots of things today. I used Underscores a few times in the past few months and it really feels like an updated version of what I already like.
  • Underscores uses the get_template_part pattern for abstracting template files. I really like this way of thinking about templates.
  • Aesthetics matter and the website for the project is great.

Cons:

  • Doesn’t use LESS or SASS. This is such an easy issue to fix (rename style.css > style.less and have LiveReload watch the folder) that it hardly warrants a bullet point, but it’s an important distinction from the direction Bones has chosen to take.
  • The name. I’ve never really liked the name ‘_s‘, which is an extremely unimportant detail until you go to start a project and have to find and replace all instances of ‘_s’ with ‘my_project_name’. Again, it’s absolutely not a huge deal, but it was a bit of a pain. The pain is now pretty-well completely alleviated by the project’s website—you can now just enter the name of the project and all the finding and replacing will be cleverly done for you.
  • Not responsive. I know, I know. You shouldn’t let a project’s boilerplate dictate your media query breakpoints, etc etc…and its something you can (should?) easily add yourself, but I still wish there were a few breakpoints baked in.
  • Eric Meyer’s style reset. This one would have been so insignificant a few years ago, but really drives me crazy now. If you’ve ever inspected a single element in Chrome dev tools or Firebug, you’ll know why. Meyer’s style reset, fills your inspector window thusly every time you click on an element:

    This clutter will show up for every single element you inspect. It’s not a huge deal, and you can remove the style reset and roll your own, but I still wish it wasn’t there to begin with.
  • Too spartan out of the box. I’ve always found Toolbox and Underscores to be way too spartan from the outset:
    While I understand that this is meant to be just a starting point, I still don’t find it warm and cosy when I start a new project.

Bones

Bones is a hot new theme from Eddie Machado. It’s much more opinionated than Underscores and comes with a few more things under the hood. Before we weigh out the benefits, I need to disclaim up front that I’ve not yet used Bones for a project, so all of the opinions below are just wild speculation. But let’s do it anyway:

Pros:

  • Responsive. Bones has a responsive grid baked right in
  • Looks good from the get-go Bones isn’t spartan from the start. It has a basic layout ready for you, and overall feels a little better than Underscores does. Sure, you’re still going to undo all of these starting points (the pink headings, etc) but it still feels better to me to start with something out of the box:
  • Normalize.css. If you’ve never used Normalize.css from Nicolas Gallagher and Jonathan Neal it’s worth a look. It does the job of resetting quite well, without cluttering up your inspector window.
  • LESS/SASS from the start. Here’s where the opinionated part comes in. I love that Bones insists that you should be using a CSS pre-processor (and you should) and makes the two most common options available to you
  • Verbose documentation. Some might find this level of documentation to be overkill, but I think it’s going to be helpful to leave it in for at least the first few projects. Machado crams a lot of WordPress know-how into each and every line.

Cons

This is the part where the comparision goes off the rails a bit. Given that this is really a setup post and not a followup, and that I’ve not actually used Bones yet, I can only list a few cons that come to mind when poking through the project’s files and folders

  • Modernizr. I don’t use modernizer. At the moment, it feels like this will add unneeded overhead for me. I have no idea. I might use Modernizr for every project henceforth, but for now it feels like it might get in the way
  • No get_template_part. Bones doesn’t use the get_template_part pattern, instead loading a lot of functionality into index.php. This doesn’t mean that I can’t do things the way I like, but is still not ideal for me.
  • Bones is opinionated. I’m not actually sure yet if this is a pro or a con. Opinionated code is great for beginners and people who have the same ingrained opinions. It will be interesting to see if my Machado and I do things the same way. It will be very interesting to see if I come around to his way of thinking if we don’t!

So there we have it. Underscores and Bones in a tête-à-tête. Results to follow!

Why I keep books

My wife gives me a hard time about keeping books I’ve already read or are unlikely to read. Maybe she doesn’t give me that hard a time, but she always questions why I keep these books around. Though I didn’t realize it until now, I keep books around for the same reason Seth Godin does:

I used to have 3,000 books in my old office. When I moved to my new office, I gave away 2,500 of them and I miss them every day—not because I opened them, but because looking at them reminded me of what was inside.

And that seems like reason enough for me, too.

On Programming

Programming is much closer to a craft than a science or engineering discipline. It’s a combination of skill and experience expressed through tools. The craftsman chooses specific tools (and sometimes makes their own) and learns to use them to create.

—From John Graham Cumming.

This is the best description of programming that I’ve ever read. It’s never felt like an art or a science to me, and it hasn’t gotten easier with more time, reading, or research. The only modest strides I’ve made in the past few years with becoming a better programmer have involved building actual things, solving actual problems.

My brother, a craftsman — an industrial electrician— spends his days fixing million dollar undersea pumps, huge diesel generators,  and motors of all shapes and sizes. In the past few years, I’ve noticed a trend in how he talks about the things that he works on — he compares them. This pump works like that pump, but has this kind of motor in it, for example. Things like that. Every problem he runs into is thought of in the context of a similar problem that he’s already encountered.

As I’ve learned more and more these past few years about PHP and Javascript, I’m finding myself do the same. I first look at a problem not in terms of exactly how I get started or what steps are involved, but instead I try and find a previous solution to compare it to. I’m sure as time goes on this will become automatic and not conscious, but it’s really become my first step now.

Thinking about this as a craft — a combination of skill and experience — instead of just as a pure you-have-it-or-you-don’t skill has been extremely helpful to me.