Disorganized

Readmill Closes

A few days ago, Readmill—by far the best ebook reading experience I have used to date—announced that they are shutting down after being acquired by Dropbox.

Although I used it for the impeccable typography and attention to detail in the reading experience, I also came to love the idea of a service backing my reading. I didn’t care about the social features, but two touches stood out for me: estimated reading time remaining, and having a record of the books I’ve read. The last item is especially important for things as ephemeral as ebooks, since we don’t have physical items on a shelf to serve as markers of things we’ve read.

It’s almost enough to make me want to learn iOS programming to make my ideal ebook reader that won’t be subject to the whims of business models and acquisitions.

Standard
Disorganized

Subversion Project Switches to Git

Yesterday, the Subversion project announced that they were moving development of Subversion itself to Git. It was, unsurprisingly, an April Fool’s prank, but the level of detail in the ticket’s comments was pretty convincing—I definitely fell for it.

But really, the joke’s on them, since it’s so eminently plausible to want to switch to Git from Subversion. Nobody uses Subversion because they want to: they’re prisoners of legacy systems. And anyone who actually claims to love Subversion must have Stockholm Syndrome.

I see this at Automattic, where we use Subversion. There’s a lot of agitation for a move to Git, but Etsy’s Git migration shows that this can be a huge project. Still, I’m seeing a lot of people internally move outside of the standard Subversion workflow, embracing either a “work in Git, deploy to SVN” workflow, or even fully embracing GitHub as the primary development platform, like Jetpack.1

Although some people find Git confusing at first, that’s usually because they’re looking at it through Subversion-tinted glasses. We have one internal project using GitHub that many of our designers are collaborating on, and they got up and running with a branch and merge workflow almost painlessly. It’s been fantastic for collaboration on a fast-moving project that would have been basically impossible if we hadn’t been using Git.


  1. Although they still have to sync back and forth with WordPress.com’s SVN setup. 
Standard
Plugins

Retiring Markdown on Save Improved

Last night I released v2.5 of Markdown on Save Improved, which will be the last release of my most popular plugin. I’m retiring it because MoSI v3 is essentially the Markdown module in Jetpack, which I also wrote.

MoSI v2.5 includes a conversion utility to migrate all of your Markdown posts to work with the format that Jetpack’s Markdown module expects. Nothing would have broken, this just lets you keep previous unconverted Markdown revisions. Speaking of which, here’s some of the additional goodness Jetpack’s Markdown module will bring you compared to MoSI:

  • Plays nicely with revisions
  • Always on: MoSI merely defaulted to enabled on a per-post basis. Now you just turn it on for the whole blog.
  • Enhanced GitHub Flavored Markdown-inspired syntax additions (including fenced code blocks)
  • Markdown for comments (separate setting)
  • Better compatibility with shortcodes
  • And, maybe most importantly, responsive support and bug fixes!
Standard
WordPress

Why You Should Develop Plugins With wp-cli

I started work on a new plugin this week1 and I quickly started running into those little things that add up to a lot of wasted time while developing. So far that’s three things:

  1. Flushing a cache of data I retrieved from an API. (In this case, I process that data before caching it, so changes require a cache flush.)
  2. Saving setting data for the plugin.
  3. Getting the current setting data from the plugin.

In the past, I’ve done all kinds of silly things for these. For #1, I’ve hacked together one-off shell scripts, but usually just threw a delete_transient call in the plugin file and hit refresh. Fun times when you forget to remove that!

For #2, I’ve often hacked together a prototype of the eventual UI, and set up all the various save handlers (because that’s fun in WordPress!) just so that I could get data into the plugin. Oh, and then I change the data structure in mid-development and now I have to change the UI just to get that new data in.2 Fun! Or, when that approach grew tiresome, I’d take a cure from my #1 approach, and maybe hardcode an update_option call, or maybe override the getter function to return hardcoded data.

And #3 just comes in handy as a sanity check to see if the current data is what’s expected. Good for debugging. I won’t detail the hodgepodge of ways I’ve done this, you’re getting the idea.

This time, I started with a simple command: wp sekritplugin flush-cache. Then the curtain was drawn back, and I realized that three common tasks I’ve done in the past could be:

wp sekritplugin flush-cache
wp sekritplugin set --format=json < dummy.json
wp sekritplugin get

The great part about this is that in order to expose this functionality to wp-cli, I have to have it in my plugin, and I'm forced to make cleaner plugin API design decisions.

And here's a familiar scenario: I'm working on the backend of the plugin, while my teammate is working on the frontend UI. I realize there's deficiency in the data structure, and push a change. Previously, this wreaked havoc (been there). But now, I just pop a dummy.json file in our repo that replicates dummy content for the new data structure. My teammate runs:

wp sekritplugin set --format=json < dummy.json

…and is back up and running, no fuss, no muss. They can also look at the changset for the dummy.json file to get a quick sense of how the data structure changed.

Another great thing is that I can leave all of the data saving and validation tasks right until the end, when the data structure is finalized. No wasted time changing things in a rapidly changing plugin.

I'm sure I'll come up with more use cases as I move along, I'm only three days into this particular project.

So, tl;dr: adding wp-cli commands to your plugin is great for:

  1. Encouraging good API design
  2. Collaborating amidst a changing data structure
  3. Efficiency
  4. Better debugging

Commands are easy to write, so what's stopping you?


  1. Actually a ground-up rewrite, so new-ish. 
  2. If the data structure changes didn't break the UI prototype, which they probably did. 
Standard

20131119-145255.jpg

Running in the snow has an eerie quality to it.

Disorganized

Winter Running

Image