Lance Armstrong was not a man, he was an idea; an American myth like Honest Abe and Johnny Appleseed. He was the little engine, brutalized by illness and then savaged by opponents, who could anyway, somebody who shrugged off hate and always took the high road.
I’ve known for a while that you shouldn’t commit to your master branch in Git. I’ve seen random tweets about it, read a blog post or two when someone talked through their workflow, but it never really clicked why you wouldn’t want to commit to master all the time. Until yesterday.
The scenario: So, I was working on a website that has been live for a few months now. I’ve been regularly pushing fixes and new features by just committing to the master branch and pushing that: Add some new footer info, change a few css styles, add a few lines of jQuery, etc. No sweat. I’d just make the changes, commit and push them, and then they were live. The trouble reared its head yesterday as I was working on a fairly large new feature. The changes spanned about 5 different files, and nothing was ready to go live yet. My coworker messaged me saying—”I just added a table to a page, but it’s completely unstyled. Do you need to add some css?”
Here I was, with a ton of changes made to a pile of different files, my local master is about 10 commits ahead of my live master, and I need to push about 5 lines of css.
What did I do? In the end, I was able to use Github’s app to select and commit only the lines I needed in my css file, and run
git push origin XXXXXXXXXX:master with the latest commit id. The problem was that I ended up doing that all day. Pushing individual commits to the live server all day is really, really stupid.
What I should have done: A month ago, when I started working on that new big feature, I should have created a new branch for it. If I’d done this, pushing those table styles yesterday would have been really painless. Basically, I would have had three branches yesterday:
I would have worked in the
table_styles branch, writing all my css there, and then merged the changes into
master before pushing it live. When I was done merging, all I needed to do was delete the
table_styles branch, and I’m all set to continue working in
The takeaway advice: (Clearly) I’m no Git expert, but next time you commit to
master, ask yourself if what you’re working on shouldn’t be happening in a new branch, and get merged into
master when you’re done. My new practice is creating a new branch for every new thing I work on. This way, master will always be ready for quick hotfixes and minor changes.
I’m a complete noob, I know! Maybe I didn’t know before, or maybe it was just laziness, but yesterday was literally my first a-ha moment with this. If you’re just starting with Git, you should really get into the habit of using branches. The official guide will do a great job of showing you how to use branches, and I hope I’ve just done an ok job at showing you why you should.
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.
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.
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.
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.
I love shortcuts. I love Google Chrome. Here’s a few of my favourites:
- Goto Address Bar:
- Duplicate current tab:
cmd+Lto select the address bar, then
- Move between tabs:
- Back/Forward buttons:
- Open last closed tab:
I just discovered #2 and #4 this week! Love’em already.