Most of a kitchen in a hatchback.
Most of a kitchen in a hatchback.
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.
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.
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:
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:
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:
Commands are easy to write, so what's stopping you?