↓ Twitter is updated more often, so read it! ↓

2010 in review: the year of travel

2010 will go down in my personal history as the year that I travelled. It will only be replaced as such should I travel even more in a subsequent year. Should such happen, I hope that it is of my own free will and benefit.

I spent not at home approximately 23 weeks of the 52 weeks of 2010. Much of that was spent in the Washington, D.C. area for work, while others were spent in Louisville, Houston, at my parents’ (oh, snowmageddon of February 2010), and single overnight stays in Orlando and Phildelphia. Most of this travel occurred in the later seven months of the year, beginning with a trip to DC in June and concluding with some time at my parents’ house for Christmas.

All the travel seriously hampered by ability to get things done. I still managed, though.

Writing

I didn’t write as much for ThinkComputers this year because of the travel, but I did manage to write a good article on travel technology, i.e. the things I take with me when traveling.

Blog-wise, I didn’t write a whole lot. I saw a year-over-year ~7.5% decrease in traffic. I attribute this to my lessened writing and bouncing from topic to topic. Also, my posts from summer 2009 regarding my stock purchases gave me a giant traffic burst I did not replicate this past year. My 2007 article on installing Roundcube Webmail on Ubuntu Feisty continued to be the #1 article on my blog (as it has been since its writing), followed by my 2008 article on using btnx for mouse control in Ubuntu Hardy.

However, I did have a few good articles from 2010. I worked from home a good bit this year, so I wrote some simple rules for working from home as a reminder to myself of “how” to work from home. My geekiest article by far was on addendum on updating the installation whenever there’s a new WordPress release.

In other news, I severed ties with BIOS LEVEL very early in 2010. It was time for me to move on.

Coding

My as-of-yet incomplete magnum opus of 2010 is the Pittco LAN Administration System. PLAS is a LAN party management tool in the vein of Autonomous LAN Party (ALP). Pittsburgh LAN Coalition (Pittco) has wanted to replace ALP with something better for several years now and after a few false starts, we’ve finally got something up and running. It’s still under heavy development and could use some good Ruby on Rails developers (I’m just a newb to RoR). I plan to spent much of my free time in January and February banging on it.

As for open source contributions, there were quite a few! I set up squid-deb-proxy for Ubuntu update bandwidth reduction and speed increases and suggested some default configuration changes in what mirrors are listed and permitting but not caching unspecified domains. I continued to contribute translations to Gwibber, Lernid, and more. I made a tiny patch to bzip2-ruby to fix compilation on Ubuntu Natty. I also fixed some Config -> RbConfig migration problems in gettext for ruby and cucumber, although neither have been accepted upsteam (I tried with cucumber, but couldn’t get the test harness working in the hour or so I wanted to devote to it so I gave up).

I released ttytter-libnotifyperl, a TTYtter extension which uses ayatana notification bubbles in Ubuntu for its notification of Twitter replies, DMs, and such. I don’t know how many people are using it, but I find it indispensable when working on Ubuntu.

Educationally, I learned how to use git in 2010. I avoided it for a few years because I used Subversion (svn) for work and preferred Bazaar (bzr) for home projects, most of which were related to Ubuntu. I still consider myself a newb, but I’ve taught at least one other person how to use git and counseled several others of approximately my experience level. At least I know I’m learning.

One of my larger projects was a for-profit job I took on early in the year. A friend needed a software for running Twitter contests. I doubt the software was ever actually used in production, as the person who was in charge of running the contest left the friend’s company shortly after I finished the product. I may adapt the product and make some kind of a SaaS thing around it if I ever get the time to do it.

My big work project went live at the end of December. I’m not sure what details I’m permitted to tell about it publicly, so ask me in private. I’ll just say that it’s a big public search portal for a government agency. I might update this story or post another entry about it if my superiors permit it.

Profyle.at, the personal profile directory site, kinda died down, but it’s not dead yet. Jon and I hope to revisit it at some point. Work got in the way for both of us, and not getting into Alphalab for the Spring 2010 session didn’t help.

Stocks

I basically slacked off on stocks this year. I made some money from SYMX, but lost a good bit from ONFI and INAR. I finally sold the rest of my holdings in SPNG, the stock which lost me $23,000 in 65 minutes in 2009. After the tax deduction, the rebate combined with my profits from 2009 sales will cause me to lose just under 3% on the whole deal, or around $90. Not too shabby for at one point having ~$30,000 wrapped up in that pump and dump scheme.

Why did I not pay attention as much? For one, @stockgod and the other Bulls on Wall Street crew stopped posting on Twitter as often because BoWS became profitable and it was more profitable for them to share their hints exclusively to BoWS subscribers. I don’t fault them for doing so at all. I didn’t have the time available to make the $75/mo worth it. @stockguy22 is still going strong, as are a few others, but I didn’t have and probably won’t ever regain the spare brain cycles I had in 2009.

I’m not out of the market — I still have ~$10k worth of stocks — but I’m not able to be a daytrader or even a week trader. I’m just sitting long for a while.

Life

Brigette and I are still dating, of course. She will in the coming month release an update to the web site for Glade Mill Sporting and Hound, the show dog kennel she, her sister, and mother operate under. She’s come a long way and just keeps getting better and better every time I see her new designs. I’m eager to see her build a portfolio site before the end of the year!

I think that’s it for this 2010 year in review.

SVN is so WordPress 2.0: Updating your git-controlled WordPress

A couple of months ago, I wrote an article entitled SVN is so WordPress 2.0: Using git to manage a WordPress 3.0 installation. This article explained how to migrate an existing WordPress installation to a git-managed installation, much like using Subversion to manage it.

That post detailed how to migrate and the instructions could very easily be adapted to create a new installation. This post details how to upgrade to the latest release of WordPress whenever it is released.

Unfortunately, I’ve found that the WordPress team, perhaps git-svn, doesn’t import svn tags, so we need to do some sleuthing to find out exactly which tag to use.

The first stop is finding out the last svn revision used for the tag. Use this command to do so. Replace the version number with the one applicable to the upgrade you wish to perform.

svn log -v -q --stop-on-copy http://svn.automattic.com/wordpress/tags/3.0.1/ | less

The output of that for me is this:

------------------------------------------------------------------------
r15479 | nacin | 2010-07-29 17:57:26 -0400 (Thu, 29 Jul 2010)
Changed paths:
   M /tags/3.0.1/wp-includes/capabilities.php
   M /tags/3.0.1/wp-includes/version.php
------------------------------------------------------------------------
r15477 | ryan | 2010-07-29 17:09:29 -0400 (Thu, 29 Jul 2010)
Changed paths:
   A /tags/3.0.1 (from /branches/3.0:15476)
------------------------------------------------------------------------

Looking at the revisions, I’m looking for a revision 15479 or shortly there after.

Next, I use the WordPress Codex entry for the release to find what date it was released. Version 3.0.1 was released July 29, 2010, so that gives me a pretty good approximate date for the last commit. The svn log above also shows this date, but I figured there might be some lag between the final commit and when the release came out. You could probably skip this step. Don’t judge me.

I then go to WordPress’s Github’s commit history on its master branch and look for a commit on the date above. There are two: 20812cf38b99a40a0e3c1d3dd5c2b3d20fb893b5 and 2f27661e1afffe16ecfbaf7a5b02db8f47e46482. Looking at the log for each, I see this line:

git-svn-id: http://core.svn.wordpress.org/trunk@15480 1a063a9b-81f0-0310-95a4-ce76da25c4cd

Revision 15480 is approximately right at the above, and looking at the changeset shows that this is probably what I want.

I do wish there was a commit which was right on, though.

So, now that I know the commit id, I can use it with git.

The rest is easy! Well, sorta. For the love of $deity, back up your blog, both the files and the database, before you do anything past here.

Once I’m in my git-versioned WordPress directory, I had a little bit of cleanup to do. I’d inadvertently added some files in wp-content/cache, so I had to manually remove them with git rm and also update my sitemap.xml and sitemap.xml.gz with git add sitemap.xml* and git commit.

Then, I could proceed.

git fetch gh
git merge 2f27661e1afffe16ecfbaf7a5b02db8f47e46482

Remember that you really only need to use enough of the commit id hash to uniquely identify the commit. If I recall correctly, seven characters is usually enough, and git will warn you if your choice is ambiguous. I used the full one because I copied and pasted.

Here’s my transcript from these commands so you know what it should look like:

[colin@convoy blog]$ git fetch gh
remote: Counting objects: 860, done.
remote: Compressing objects: 100% (591/591), done.
remote: Total 749 (delta 568), reused 202 (delta 155)
Receiving objects: 100% (749/749), 312.70 KiB, done.
Resolving deltas: 100% (568/568), completed with 104 local objects.
From git://github.com/wordpress/wordpress
   c39484b..6e44120  master     -> gh/master
[colin@convoy blog]$ git status
# On branch master
nothing to commit (working directory clean)
[colin@convoy blog]$ git merge 2f27661e1afffe16ecfbaf7a5b02db8f47e46482
Auto-merged readme.html
Merge made by recursive.
 readme.html                                        |    2 +-
 wp-activate.php                                    |    2 +-
 wp-admin/admin-ajax.php                            |   22 +-
 wp-admin/admin.php                                 |   12 +-
 wp-admin/edit-attachment-rows.php                  |    4 +-
 wp-admin/edit-tags.php                             |    7 +
 wp-admin/edit.php                                  |   11 +-
 wp-admin/export.php                                |   12 +-
 wp-admin/import.php                                |    2 +-
 wp-admin/includes/bookmark.php                     |    4 +-
 wp-admin/includes/class-wp-importer.php            |    5 +-
 wp-admin/includes/class-wp-upgrader.php            |   33 ++-
 wp-admin/includes/dashboard.php                    |    4 +-
 wp-admin/includes/deprecated.php                   |   10 +-
 wp-admin/includes/export.php                       |    2 +-
 wp-admin/includes/media.php                        |    2 +-
 wp-admin/includes/meta-boxes.php                   |    4 +-
 wp-admin/includes/ms.php                           |   48 ++--
 wp-admin/includes/nav-menu.php                     |    2 +-
 wp-admin/includes/plugin-install.php               |   13 +-
 wp-admin/includes/plugin.php                       |    3 +-
 wp-admin/includes/post.php                         |   20 +-
 wp-admin/includes/schema.php                       |    9 +-
 wp-admin/includes/template.php                     |  288 ++++++++---------
 wp-admin/includes/theme.php                        |    6 +-
 wp-admin/includes/update.php                       |    6 +-
 wp-admin/includes/upgrade.php                      |   12 +-
 wp-admin/includes/user.php                         |    8 +-
 wp-admin/install-helper.php                        |   10 +-
 wp-admin/install.php                               |    2 +-
 wp-admin/menu.php                                  |    4 +-
 wp-admin/ms-edit.php                               |   13 +-
 wp-admin/ms-sites.php                              |    5 +-
 wp-admin/nav-menus.php                             |   15 +-
 wp-admin/options-discussion.php                    |    2 +-
 wp-admin/options-permalink.php                     |   51 +---
 wp-admin/plugins.php                               |   23 +-
 wp-admin/press-this.php                            |    2 +-
 wp-admin/update-core.php                           |    4 +-
 wp-admin/user-new.php                              |    4 +-
 wp-app.php                                         |    2 +-
 wp-content/themes/twentyten/attachment.php         |   12 +-
 wp-content/themes/twentyten/editor-style.css       |    8 +-
 wp-content/themes/twentyten/functions.php          |   58 ----
 wp-content/themes/twentyten/header.php             |   16 +-
 .../themes/twentyten/languages/twentyten.pot       |  123 ++++----
 wp-content/themes/twentyten/loop.php               |   33 +-
 wp-content/themes/twentyten/page.php               |    8 +-
 wp-content/themes/twentyten/style.css              |  340 +++++++++-----------
 wp-includes/canonical.php                          |   14 +-
 wp-includes/capabilities.php                       |   12 +-
 wp-includes/category-template.php                  |    4 +-
 wp-includes/class-http.php                         |   54 ++--
 wp-includes/classes.php                            |    2 +-
 wp-includes/comment-template.php                   |   46 +++-
 wp-includes/cron.php                               |    8 +-
 wp-includes/default-filters.php                    |    2 +-
 wp-includes/default-widgets.php                    |    2 +
 wp-includes/deprecated.php                         |   19 +-
 wp-includes/feed.php                               |    2 +-
 wp-includes/formatting.php                         |   14 +-
 wp-includes/functions.php                          |   15 +-
 wp-includes/general-template.php                   |   11 +-
 wp-includes/kses.php                               |    4 +-
 wp-includes/link-template.php                      |    6 +-
 wp-includes/media.php                              |    2 +-
 wp-includes/meta.php                               |    2 +-
 wp-includes/ms-blogs.php                           |   20 +-
 wp-includes/ms-deprecated.php                      |   14 +-
 wp-includes/ms-functions.php                       |   27 +-
 wp-includes/ms-load.php                            |    7 +-
 wp-includes/nav-menu-template.php                  |   35 ++-
 wp-includes/nav-menu.php                           |   17 +
 wp-includes/post-thumbnail-template.php            |    2 +-
 wp-includes/post.php                               |   26 +-
 wp-includes/query.php                              |    3 +-
 wp-includes/taxonomy.php                           |   34 +-
 wp-includes/theme.php                              |    4 +-
 wp-includes/update.php                             |   47 ++--
 wp-includes/user.php                               |    4 +-
 wp-includes/version.php                            |    4 +-
 wp-includes/wp-db.php                              |    9 +-
 wp-signup.php                                      |    5 +-
 xmlrpc.php                                         |   10 +-
 84 files changed, 903 insertions(+), 872 deletions(-)
[colin@convoy blog]$ git status
# On branch master
nothing to commit (working directory clean)

The last thing to do is go to /wp-admin/upgrade.php in your browser. You’ll likely be redirected there when you hit the admin panel anyway, so it’s likely easier simply to do that.

Is managing the installation with git easier than managing it with svn? So far, not really. Subversion’s svn switch and WordPress’s use of SVN tags makes using git with it a little frustrating. If WordPress were ever to switch to git for real, then they’d likely use tags and all this searching would be moot. One could just switch branches and be done with it.

Got an easier way? Tell me in the comments.

SVN is so WordPress 2.0: Using git to manage a WordPress 3.0 installation

Using Subversion to manage my WordPress installation was convenient and mindless. Whenever there was a new release of the blog software, I could hop to a terminal, back up my filesystem and database, and run svn sw http://svn.automattic.com/wordpress/tags/(new.version.number).

This worked great all through WordPress 2.x. However, when I tried to switch from 2.9.2 to 3.0, things broke. As in, “white screen with PHP failure message” broken. I hit the dreaded is_multisite error because something didn’t come in right or I’d accidentally modified something or maybe even the tag was out of date.

Regardless, I decided that in order to fix the problem, I needed to wipe out every file or directory which began with wp in my /blog directory and copy over from a fresh download of the package.

I mindlessly did this, then realized: “Oh crap, now I can’t upgrade with Subversion any more.”

I queried Twitter, asking So I went and deleted all of the .svn directories in my wp install. Is there a way I can put it back on svn without having to recopy stuff?. @steveklabnik quickly replied, jokingly, @colindean yeah, you just run ‘git init .’ ;) .

A troubleshooting conversation ensued, and then I found that WordPress maintains a GitHub repository.

Then it hit me: maintaining my WordPress installation with Subversion is so…WordPress 2.0. I’m on WordPress 3.0 now, it’s time to embrace modern distributed version control systems and use Git!

Steve, being an intrepid Rubyist friend and Git user, suggested how I could version my existing blog directory and add a git remote, then fetch and rebase, thereby syncronizing my local installation with an easy to use versioning system!

However, because it’s a development repository without any “tags”, I’ll have to remember to look for a specific commit whenever I upgrade.

I changed things up a bit and corrected order of things. Here’s what I did to get it working. Note that I’m a git newb and very open to suggestions if there’s a more succinct or overall better way to do this.

Note that I used git protocol for the repository (Github’s HTTP git seems to have problems completing transfers to my server).

Initialize the local repo and add what you have already:

git init
git add .
git commit

Add the remote, fetch and rebase:

git remote add gh git://github.com/wordpress/wordpress.git
git fetch gh
git rebase gh/master

At this point, I was informed that I had some files in wp-content/cache which needed to be deleted/updated. A quick git status showed that I’d versioned these cache files. Oops! You’ll have to do git rm <filename> for each of those, or just do git rm wp-content/cache.

Next, I added a few directories to .gitignore using my text editor of choice:

wp-content/cache/*
wp-content/uploads/*
wp-content/plugins/*
wp-content/themes/*

Then, I needed to merge in the 3.0 commit.

git merge 7cee95b6bba8bc867023ae0831e7538a8419a9f5

There were a few conflicts, but all were easily resolved. Use git add on each file needing resolved, then git commmit to finalize your changes. Once you commit, you’ll be up-to-date and merged with that version.

I’ll update this post or make another when the next release of WordPress is out to report how well the actual upgrade goes.