Jon Smajda

Updates

I’ve had dry spells in the past on this blog, but this has been the longest. A lot has happened.

In December, I completed, and successfully defended, my PhD in sociology! Finally! It’s been a huge relief to be done and have that part of my life behind me. While I applied for some academic jobs this past Fall, nothing has panned out and I’m mostly out of the academic world these days. Not entirely though: I’m still working with The Society Pages and Contexts, keeping the servers running in the engine room for both sites and doing some podcasting and editorial work for TSP.

As a grad student I got interested in studying the culture of open source software, and I’ve now officially gone native: working as a web developer full-time for BOLD. Most of my time there is now spent working with Python and Django, which I greatly enjoy: both are elegant, powerful, and fun. We’ve been working on a particularly large Django project for the past year now that has been a great learning experience. If I ever get around to posting here again, there’ll likely be some Python and Django-related posts sharing what I’ve learned.

After spending nearly a decade pursuing a PhD in sociology, it’s been a bit of a mental adjustment to get used to the idea that this is now my career, not sociology. On most days, however, I’m happy with how this has turned out. There’s an ideal vision of what life in academia is like that I know I would love, but the reality is often pretty far off from that. Plus, I’m pretty pessimistic about the direction higher education is heading in this country.

More concretely though, I think there are several aspects of my personality that are just better suited to what I’m doing these days. For instance: I don’t have the right kind of long-term patience for academia. For example, my advisor and I have an article scheduled to be published this Fall. It was accepted by the journal last Fall. We finished writing the article last Spring. It’s based on research I did in 2004. So in academia, in other words, you’ve got to be in it for the long haul. Compare this to what I just said about about web development: in the time it’s taken this paper to go just from acceptance to publication—nevermind the actual time spent doing the research and writing!—I’ve learned an entire new programming language and web development framework. And I’m sure there will be others in the next few years. Software development is a fast-moving field. Sociology is not.

Let’s see…what else is new?

• Last year, while I was scrambling to finish my dissertation and also get a new career started, I re-discovered running as the ultimate stress-reliever. A few months back, I started tracking my runs on Runkeeper. I keep going back and forth on whether I actually want to start entering races. The competitor in me thinks I should, but a big part of the appeal of running for me is getting away from other stressors in my life so I’m hesitant to introduce any extra stress into running. For now, it’s just for fun.
• Chloe is now five years old. She starts Kindergarten in the Fall. She’s amazing.

That’s about it for now. Hopefully it won’t be another 10 months before I post again!

— Sunday, May 13, 2012

WordPress and Git

A few years back, I wrote a post on managing WordPress. For the most part, it’s still valid but I’ve been using git to manage code for quite awhile now, so I thought I’d give a little update.

Thanks to Mark Jaquith, there’s now a reliable, complete git mirror of WordPress. I’ve been using git to manage my WordPress sites for awhile now, but the actual updating of WordPress has always been weird to force into the git loop. My practice has been to keep a stock WordPress git repository that is also a subversion repository (just add *.svn to your .gitignore). I svn switch to a new tagged release, commit the result in git, and then this repository is set up as a remote on all my active WordPress sites, so I ssh into these sites and merge each with this stock WordPress branch.

Now that there’s a good Wordpress mirror on github, the way to take advantage of this may seem obvious: just clone this mirror and then merge from it. However, that has a couple downsides. First, you get messy history: all of the commits you’ve made locally for your site get drowned in WordPress core commits. Second, unless you’re actively developing WordPress core, you only care about official releases (and possibly beta releases). In other words, you want to merge with tags only and you don’t want messy history. So here’s how to get that: instead of cloning Jaquith’s mirror, just add it as a remote and squash the commits.

Step-by-step:

If you’re starting from scratch, create an empty git repo with git init and create an initial commit with something — maybe a local-readme.txt file explaining what you’re doing. (“Squash commit into empty head not supported yet”.) Anway, add the remote:

git remote add wp git://github.com/markjaquith/WordPress.git
git fetch -t wp

The first adds the github mirror as a remote named “wp”. The fetch -t will make sure you get all the tags. (Run git tags afterwards to see the list of available tags.)

Next, merge with the latest tag (here, 3.2.1):

git merge --squash --no-commit -s recursive -X theirs tags/3.2.1

The --squash means it takes the hundreds (thousands?) of ancestor commits for that tag and compresses it into a single commit. The -s recursive -X theirs tells git that if there are conflicts, use the new version. (Remember, all you’re doing here is creating a simple local WordPress mirror to merge your actual WordPress sites with.)

The --no-commit tells git to merge but stop just short of actually making the commit. So make sure everything looks good. For example, you can’t squash binary files so you may get conflicts about that. If this happens, just git checkout the latest version explicitly. For example, going from 3.2 to 3.2.1 I had to do the following: git checkout tags/3.2.1 -- wp-admin/images/wp-logo.png

Finally, git commit -m "3.2.1"

Now, as I said above, what I like to do is this: do not use this as your starting point for an actual WordPress instance. Instead you add this repo as a remote (just like we did above) to your site and then you can just do a git pull wp (or whatever you call it) there. That way you only have to do the little dance above once for each release if you’re responsible for multiple WordPress instances.

Quick aside: Why don’t I just put mine on github? I could. But here’s the problem: the reason Jaquith’s mirror is such a big deal is because he’s a WordPress core developer. Others have done this, but they’ve all had shortcomings: the ones I knew about didn’t include tags, or they were really slow to update, or they simply got abandoned. I’m not blaming any of them. Sure, I could put a “simplified WordPress repo” on github, but I don’t want to commit to updating it instantly every WordPress update forever. And what works for me may not work for you. The process I described above is not difficult and shows how you can take the comprehensive mirror and merge with it to make your life easier in your own way that suites your needs.

Plugins

What about plugins? There’s no git mirror of the WordPress Plugins Directory that I know of, so I usually revert to my subversion hack described above: svn co http://svn.wp-plugins.org/plugin-name/trunk/ . into a directory for the plugin and then commit the results into git. Alternatively, you can use WordPress' backend plugin updater, which can work just fine, but I inevitably end up having to modify certain plugins and that process simply overwrites the files and you lose your modifications, whereas at least svn up will alert you to conflicts and let you merge your changes into the new version. (Makes me wonder how many out-of-date plugins would be updated if the WordPress Plugin Directory worked more like github — where anyone could fork your plugin and fix it if you won’t…)

Beta Testing

If you want to test beta releases locally before installing them, you can just create a “testing” branch of your WordPress repository (git checkout -b testing) and then instead of merging with a release tag, just merge with whatever branch the development for the next version is happening on. Make sure if you’re going to switch back and forth to backup your database though!

Merging into an existing site

This may sound great for setting up new sites, but what about merging into an existing wordpress site? You’ll get conflicts because git won’t have a common ancestor commit to merge from. So fake one: create a graft file file linking your most recent commit where you updated WordPress (if you’re using git for the first time, just use your first commit) and the SHA1 of the commit for the version you’re currently running in your base WordPress repo. After creating this file, you should see both branches reflected in your git log and when you try to merge to the current commit in your remote branch, it should merge cleanly, as if you’d been merging with it all along.

— Sunday, July 17, 2011

Dvorak Follow-up

About a year-and-a-half ago, I wrote about how I was learning Dvorak. I was still very much in the learning phase at the time and I’ve been meaning to revisit the post for awhile now. Here’s a quick update:

• I’m still typing Dvorak.
• My hands rarely hurt anymore. This was the main motivation for trying Dvorak, so I’d call it a success. The decreased motion required with Dvorak seems to have made a difference. One qualification: I’ve also learned to be more conscious about how hard I type, so that may be making a difference as well.
• I have no idea if I’m faster than with QWERTY. This wasn’t a factor in learning Dvorak for me and I haven’t done any speed tests.
• I wanted to be able to switch between QWERTY and Dvorak. This has not been so easy. I can type QWERTY, but I’m slow and have to think extra hard about it and/or look at the keyboard the whole time. This is doubly bad because about the only time I have to type QWERTY is when I’m at someone else’s computer, usually with them watching while I’m trying to talk at the same time. So, already not an ideal environment for good typing. I could probably make the effort to get better at QWERTY and practice switching layouts more often, but it’s just not been that big of a problem yet.
• If you type a lot of English and your hands hurt, I’d recommend trying Dvorak. Beyond that specific situation, I’m not sure how heavily I’d recommend it if you’re already a good QWERTY typist.

That last point is worth expanding on. The people who seem interested when I tell them I use Dvorak are programmers. Programming alone, however, is a pretty poor reason to switch. First, you don’t actually type that much when you’re programming. Second, all the special keys (brackets, braces, colon, semicolon, etc.) that you type a lot when you’re programming have moved, and not necessarily to more ergonomic locations. In fact, they’ve been moved to less ergonomic locations to make room for regular letters non-programmers use more frequently. You also have to relearn keyboard shortcuts, and keyboard shortcuts often have been chosen for ergonomic convenience. If you’re a vim user like myself, you have to relearn your vim muscle memory.

However, Dvorak is more easy to recommend to people who just type a lot of English: writing papers, dissertations, emails, blogging, etc. This group of people, however, tend to just think I’m crazy when I tell them I use Dvorak. They’ve often never heard of it and assume it’s something hard-core programmers might do, when, in fact, it makes more sense for them than the programmers who are intrigued by the idea. Of course, there’s an overlap between “people who program” and “people who spend a lot of non-programming time typing on a computer”, but it’s interesting to me that there’s a disconnect between those interested in Dvorak and those who could most benefit from it.

— Sunday, May 15, 2011