Mobile coding

Photo by Remo

I love my Droid X phone. I was a little nervous when I switched from my BlackBerry in July, due to the Droid’s shorter battery life (but giant screen!), largess (but giant screen!), and lack of a physical keyboard (but giant screen!). Clearly, I feel the beautiful, giant screen makes up for this. Not to mention a second battery as a backup.

One thing that always seems to amaze me is how powerful these devices are becoming. I seamlessly transition between devices all day long, and it also allows me to carry my laptop less and leave my desk more without having that unsettling ‘untethered’ feeling.

With that, here’s a cool process story from a few weeks ago. Daniel Bachhuber sent me a message asking why HTML was being filtered on a WordPress import, even though he was disabling the filtering system. (Read his roundup.) I checked his code and it looked fine, so I was stumped and didn’t know what to tell him. Fast forward to that evening, I was in the Metro with Aaron Jorbin on the way to the monthly DC PHP meetup, and in mid-conversation (which was entirely unrelated) it suddenly it dawned on me I was pretty sure that on multisite, we enforced filtering on import even for super administrators. 1

I fired off a quick email with my suspicions. Moments later I opened my Android browser and was browsing the WordPress source (I have it bookmarked, of course), and found the line. Success.

It didn’t stop there. After the meetup, I joined John Bloch 2 and a few others at the bar around the corner. While there, I received a reply from Daniel, and he wasn’t exactly happy that the only way around this was a core hack. I agreed, so I sent a Skype message (again, still from the phone) to Ryan Boren asking about perhaps adding a filter. He liked the idea, so I opened a new browser tab 3 and created a Trac ticket.

Of course, I had to keep going. So I fired up my SSH client, navigated to a checked out Subversion repository on my server, updated to trunk, opened the right files in Vim, and made the changes. After a sanity check from John, I was able to then commit a filter. All from my phone, having not opened my laptop all evening. Fun times.

Development while on the go is something I’ve wanted to attempt for a while — if only just once. Clearly only so much testing can go into it, and it’s certainly not something that will become a habit. Nonetheless, it was a quirky and fun experience, and it’s a testament to how powerful these mini-computers have evolved.

Notes:

  1. This does make sense, considering that super admins are often running imports of untrusted content when setting up sites for users. The fact that it was impossible to disable, though, was kind of lame.
  2. John also posted a good roundup of the meetup here.
  3. I can’t even live without tabs on my phone. What did I do before tabbed browsing on the desktop?

My WordPress bash functions

Since my MacBook Pro arrived less than three weeks ago, there are a few applications I’ve yet to close: a browser (Chrome primary, Firefox secondary), an editor (TextMate, and some TextWrangler), and Terminal. I’ve found that as a developer, Terminal is where it’s at.

Here’s a quick rundown of my bash functions file so far. Some of these functions were borrowed from or inspired by fellow core developers Peter Westwood and Ryan Boren, and others just came out of a need or a shortcut. They’re all relatively simplistic, but they’re a window into how I work.

In particular, the way I interact with patches has evolved quite a bit when I switched over to Mac. To think I believed the CLI would slow me down after dealing with TortiseSVN! (Thankfully, I haven’t had to merge too many patches that no longer apply cleanly.)

Downloading and Applying Patches from Trac

# Apply a Trac patch.
trac_patch() {
	curl "$1?format=raw" | patch -p0
}
# Apply a Trac patch on a clean repo.
clean_patch() {
	svn cleanup
	svn revert -R *
	svn up
	curl "$1?format=raw" | patch -p0
}
alias tp=trac_patch
alias ctp=clean_patch
# usage
tp http://core.trac.wordpress.org/attachment/ticket/13237/alot.patch

I don’t use the clean_patch command much, mainly because I have a good idea of the status of my repository when I’m applying a patch. This one in particular was actually inspired by Automattic’s Barry Abrahamson, who warned me at WordCamp SF that Jane Wells can break anything.

(Necessary backstory: Jane was set up with a local WordPress install on her new MacBook Pro, and thus a simple command that cleans up a mess and applies a patch is exactly what she would need. No more commit-it-and-let’s-see-how-it-looks come 3.1.)

trac_patch came from Peter, here. Of course, trac_patch on steroids would be this python script from Nikolay.

SVN: Files Modified

mod(){
	svn stat --ignore-externals | grep '^[^?X]'
}

This one gives me a quick look at core files I’ve modified. svn diff sometimes produces too much output for me to easily ensure I’m not about to commit cruft in another file, so this is a nifty sanity check.

I otherwise haven’t come up with anything else to shorten svn commands. They’re pretty short as it is (and baked into the back of my eyes).

Grepping through Core

jsgrep() { # search development scripts
find . \( -name "*.dev.js" -print \)  | xargs grep -n "$1"
}
cssgrep() { # search development css files
find . \( -name "*.dev.css" -print \)  | xargs grep -n "$1"
}
phpgrep() { # search php files
find . \( -name "*.php" -print \)  | xargs grep -n "$1"
}
wpgrep() { # search php files and development scripts/styles
find . \( -name "*.php" -print -or -name "*.dev.js" -or -name "*.dev.css" -print \)  | xargs grep -n "$1"
}
# usage
wpgrep 'function the_content'

Also inspired by Peter, these commands are quite awesome for finding what you need when you need it.

Script Compression

min() {
java -jar ~/downloads/scripts/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar -v --type $1 -o wp-admin/$1/$2.$1 wp-admin/$1/$2.dev.$1
}
# usage (I've run these two more than I care to count)
min js nav-menu
min css nav-menu

We use the YUI Compressor for scripts and styles. After toying with a few variations, I came up with the above. Originally inspired by Ryan in a comment on Trac, I traded off some functionality for less paths to traverse. I still have a variation that allows me to specify any two files, however, for the rare instance when I’m not compressing core scripts.

Opening Files Fast

o(){
open $1 -a textmate.app
}
# usage
o wp-config.php

Since I find myself in Terminal so often, I often find I want to open files from there. My o command operates exactly like TextMate’s mate command, but o is shorter, and I can also change it to another application if I move to another one.

That command helps, but I’m not sure what I’d do without these commands:

# Shortcuts for opening WP files insanely fast.
wpinc(){
	o wp-includes/$1.php
}
wpa(){
	o wp-admin/$1.php
}
wpai(){
	o wp-admin/includes/$1.php
}
wpcss(){
	o wp-admin/css/$1.dev.css
}
wpjs(){
	o wp-admin/js/$1.dev.js
}
wptt(){
	o wp-content/themes/twentyten/$1.*
}

Usage:

wpi post # wp-includes/post.php
wpai schema # wp-admin/includes/schema.php
wptt style # wp-content/themes/twentyten/style.css
wptt functions # wp-content/themes/twentyten/functions.php
wpjs nav-menu # wp-admin/css/nav-menu.dev.js

These evolved from a weakness of the o command — it was slow for traversing the same paths over and over. I knew what the file was called and where it existed, and I just wanted to open the file now.

So there you have it. Are there any functions you use that can speed up a WordPress or web development workflow?

Visualizing the WordPress 3.0 contributors

After noting that I wanted to start congratulating new WordPress contributors on Twitter, Ozh Richard suggested I make a word cloud, as had been done in some previous releases.

So, based on a Trac report I made for demetris so he can compile the list of contributors, I generated these word clouds. These are based on changesets 12456 to 14319 (thus, as of this morning). Of 1864 commits, 677 of them had props given, for a total of 720 props (some commits had more than one). Patches were contributed by 170 people so far, the most ever (or so I’m told).

It was embarrassingly easy. I did a tab-delimited export of the report, grepped out what I didn’t want, and manually scanned the list for misspellings. Took me maybe 15 minutes on the flight to WordCamp San Francisco (I’m also in the air while posting this). Then I used Wordle for the cool visualization, and TagCrowd for the more functional one. (TagCrowd is also what Peter Westwood used in one of the clouds linked above.)

Frumph asked how a contributor is defined in this context, so let me do that. When the core team commits code, we mention the authors of the patch in the commit message by awarding “props,” such as “props nacin.” (You know, like giving “kudos.” Same deal.) We don’t give them to ourselves, but if there’s no props listed, then you can assume we wrote the code (or forgot the prop).

A disclaimer: These may not be accurate, with the reasons ranging from oddly formatted commit messages all the way to issues with my compiling.

Another disclaimer: Yes, I’m sorry my name is so big. I really am. I contributed a lot of code before becoming a committer, and this does actually exclude commits by the core team, including my own. (We made more than 1,000 commits on our own.) So my name is about six weeks from late December to early February. In 3.1, my name will be much smaller. 🙂

I’d hope this goes without saying, but props are not why I contribute to WordPress. I don’t keep a tally. This is just a cool visualization that shows the sheer breadth of the number of contributors, plus who some of the larger contributors are. Also, quantity does not equal quality.

Without further ado, the pretty Wordle:

And from TagCrowd (click for a much larger size):