Author Archives: Boone Gorges

Using Splice.vim as a git mergetool

I switched to using Vim full-time about nine months ago, but I haven’t yet cracked the nut that is vimdiff. As a result, I’ve been jumping around between various crummy GUIs for git mergetool. Until a few days ago, when I found the excellent Splice.vim (formerly Threesome.vim). Now I’m back in Vim wonderland.

I’ve found Splice to be pretty great for my (albeit limited) mergetool needs – once you figure out how to use it. Splice has pretty good vimdocs, but they’re more of a reference than a tutorial; and getting the necessary information out of the developer’s screencast walkthrough is a needle-haystack exercise. So here’s a quick guide to getting started.

  1. Install SpliceInstructions can be found here.
  2. Find yourself a conflict and invoke git mergetool – If you never have to manage merge conflicts, you are a better soul than me. I’ve set up a dopey example in the screenshot below.
    invoke

  3. Cycle through the layouts – I’ve got a widescreen monitor, so I like the side-by-side layout. Use -[space] to cycle. ([space] is a space character.)vertical-layouthoriz-layout
  4. Jump to your first conflict – Use -n to get to your first conflict.
  5. Choose your side, or resolve manually – If you need to resolve manually, do so on the middle screen. On the other hand, if you want to take either the left-hand change (1) or the right-hand change (2), you can do so using -u1 (or 2, as the case may be).
  6. Repeat – Go to the next conflict using -n. When you’re done with the file, -q saves all changes and quits all windows. Hit Enter to resolve conflicts in the next file, or if you’ve reached the end of your conflicts, go ahead and commit your changes.

Huge thanks to Steve Losh for developing and sharing such an awesome tool.

Doom and gloom upon the offing of Google Reader

This week, Google announced that it’s shutting down Reader. This is the first of Google’s “sunsets” that hits me personally – Reader has been a crucial part of my internet use for the better part of a decade. I happen to think, like Marco Arment, that in the long run the loss of Google Reader will probably be good for innovation in RSS readers and for RSS in general. Google’s hamstrung app has been just good enough for people like me, but non-approachable for non-geeks. A year from now, I’m hoping that there’ll be many more quality players. So, in the long run, I’m reasonably optimistic.

More immediately, though, a couple of causes for concern:

  1. Finding an alternative to Reader. My RSS reading habits are too ingrained for me to abandon them, even for a short time. More than that: following RSS feeds is beyond mere habit, but is check on my intellectual honesty. I follow many blogs whose authors I frequently disagree with, or even dislike. (Contrast this with Twitter, where I’m pretty fickle about whom I follow, and how many tweets/links I pay attention to.) So RSS is, for me, a partial antidote to the echo chamber tendency. That means that I’ve got to find a new app, and migrate over, and I’ve got to do it quickly.

    There have been a number of posts over the last couple days listing Reader alternatives. A number of them are cloud/service based, and for practical reasons (such as, um, Google Reader) as well as philosophical reasons (see below), I’m only considering alternative tools that I can run either locally or on my own server. A couple that spring to mind:

    • Fever. I’m interested in this one because (a) the screenshots make it look nice, and (b) it comes highly recommended by people I respect, like D’Arcy Norman. I like that it’s self-hosted. I don’t like the fact that its sustainability model is to charge for downloads. It’s not that I don’t think the author shouldn’t be paid – I would be happy to pay $30 or $300 for a great RSS reader app. It’s that the success of the single-developer model is contingent on the willingness of that developer to keep working on the project (paid or otherwise). I’m far more comfortable with software that is community developed under a free license, ideally using a set of technologies that would allow me to modify or even adopt the project if the main devs were to abandon it.
    • Tiny Tiny RSS. tt-rss also comes recommended by someone I respect (Mika Epstein, in this case). And it’s community-developed, which I like. It doesn’t look as pretty as Fever, but aesthetics are about fourth or fifth on my list of requirements.
    • PressForward. As Aram describes, the PF team (of which I’m pleased to be a member) is working on a WordPress-based tool that, among other things, does RSS aggregation and provides some feed-reading capabilities. PressForward is really designed for a different kind of use case – where groups of editors work together to pare down large amounts of feed data into smaller publications – but it could be finagled to be a simple feed reader. Mobile support is a particular pain point, as 50% or more of my RSS intake is done on my phone, and PF has nothing in place to make this possible at the present time. So, PressForward may not be quite ready for primetime, but I do think that it has promise.
  2. Get the hell off of Google. We all know that Google is a company with shareholders and profit goals to meet. Yet we often act like Google is some sort of ambient benevolent force on the web. Since I started Project Reclaim, I’ve been working on extricating myself and my data from the clutches of Google (among other corporate entities). Reader’s demise is a wake-up call that the time for dilly-dallying is over.

    For my own part, I still use a few Google services besides Reader:

    • Gmail. I don’t use Gmail primarily anymore, though many people do still email me at my gmail.com address, so obviously I have it open and I check it frequently.
    • Picasa. I use the Picasa desktop app on OSX to export photos from my cameras and organize/tag them. I also use Picasa Web Albums as one of my many photo backup services. (Seriously – I back up my photos to no fewer than six different local and cloud services. Nothing is more important or irreplaceable than my family photos.)
    • Drive/Docs. Aside from the occasional one-off collaborations, I use Drive to maintain a number of spreadsheets and other documents that I share with members of my family, etc.
    • Calendar. I’m not a heavy calendar user, but when I do use a calendar, I like Google because of its integration with my Android phone.
    • Chromium. Not Chrome, but still largely Google-reliant, Chromium is not my main browser, but I use it daily for doing various sorts of development testing.
    • Android. This is maybe the one that steams me the most, because at the moment there are no truly free alternatives. (Firefox OS, please hurry up.)

    In some of these cases, there are easy ways to get off of the Google services. In others, it’ll be a challenge to find alternatives that provide the same functionality. In any case, the Reader slaughter is a harsh reminder that Project Reclaim has stagnated too long with respect to Google services.

    More than myself, I’m worried about others – those who aren’t as technically inclined as I am, or those who simply don’t care as much as I do. Google’s made it pretty clear (as is their right, I guess) that they’re not an ambient benevolence. Those who rely on Google then, especially for critical services like email, should take this warning very seriously. Please consider carefully what you’re doing when you make yourself wholly dependent on the whim’s of Google’s product managers, and consider options that are either free-as-in-speech, or services that you pay for in a traditional way.

Anthologize automated tests now run using WP’s unit test suite

Anthologize, I haven’t forgotten about you! I have some very cool stuff in the works, but for now, a quick update on the progress of the campaign-funded work.

Back in 2011, Patrick Murray-John added some unit tests to Anthologize, covering a number of public methods in the TeiApi class. A number of the major refactoring jobs I’m currently undertaking will require additional test coverage, but they are (unlike TeiApi) dependent on WordPress being initalized. So I’ve migrated Anthologize’s tests to use the WP test suite. I’ve used the scaffold provided by the dope and phatte wp-cli (incidentally, I hope that their scaffold becomes the de facto standard for WP plugin tests).

This change means that, in addition to requiring PHPUnit, you’ll also need to have the WP test suite installed. You can install it manually, but I recommend using wp-cli to get the job done in just a command or two. In brief:


$ wp core init-tests /path/to/wp-tests --dbname=wp_test --dbuser=root --dbpass=asd
$ mysql -u'root' -p'asd' -e 'CREATE DATABASE IF NOT EXISTS wp_test'

To run the tests,


$ cd /path/to/wp/wp-content/plugins/anthologize
$ WP_TESTS_DIR=~/path/to/wp-tests phpunit

You can define WP_TESTS_DIR in your .bashrc file for quicker use in the future.

This post is brought to you by Anthologize campaign supporter Demokratie & Dialog. D&D, a Major Sponsor of Anthologize (woo hoo!), is using WordPress and BuddyPress in amazing ways both to study the way that government policy affects youth and to get youth themselves involved in the development of said policy. I had a chance to get to know the very excellent Andreas Karsten of D&D at BuddyCamp Vancouver last year, and we have big plans to start a BuddyPress jazz band. Many thanks for your support of WP, BP, and Anthologize!

Selectively deprecating WordPress plugins from Dashboard > Plugins

On large WordPress MS installations where site admins are allowed to manage their own plugins, the list of plugins tends to get crowded over time. Sometimes you introduce a plugin to the network and admins start using it, but some time down the road – a year or two later, even – you decide that you want to deprecate that plugin (maybe to replace it with another one, etc). However, migrating users of one plugin to another plugin is a logistical and technical tangle, and sometimes the best medium-term strategy is to allow existing users of the plugin to keep using it, but to prevent admins from activating it in the future.

Here’s how we’re doing it on the CUNY Academic Commons. In the gist below, $disabled_plugins are the plugins that we don’t want people to activate in the future. In most cases, however, we do want people to be able to deactivate the plugins, so by default, we don’t filter plugins if they’re active. However, we also have an array of $undeactivatable_plugins, which cannot be activated or deactivated.

Props to dev team member Dominic Giglio for writing part of this.

BuddyPress Docs 1.3, featuring theme compatibility on BP 1.7

I’ve just released version 1.3 of BuddyPress Docs, my WordPress plugin that powers collaborative document editing on a BuddyPress site. The main feature of Docs 1.3 is theme compatibility, which means that top-level Docs templates (archives, single docs, and the Create screen) are no longer necessarily top-level. Using the theme compat feature of BuddyPress 1.7 (currently in beta), this top-level content is put directly into the content area of your theme’s page.php template, ensuring that Docs pages will keep your header, footer, sidebar, and other global elements.

The theme compatibility feature only kicks in if you’re running BP 1.7. Existing installations of Docs on BP < 1.7 will continue to work as before.

Are you a BP Docs user? Are you already testing BuddyPress 1.7? I'd be glad to get your feedback on Docs 1.3. Report any problems on the issue tracker.

Dynamically add items to a wp_nav_menu() list

WordPress’s wp_nav_menu() fetches a custom menu, as built using the Menus GUI, for display in a theme. I had a project where I needed to add some items to this menu dynamically – the links would be different for each user, and wouldn’t appear for logged-out users, so they couldn’t really be added using the GUI. After a bit of futzing, I was able to insert my menu items, tricking WP into thinking that they were native.

Details: For logged-in users, I needed to add three subnav items underneath the top-level ‘Activity’ item, if it was present. So at the beginning of the function, you’ll see that I’m doing some BuddyPress-specific stuff, to find the Activity menu. If you need to use a menu_item_parent like I did, you’ll have to supply your own method for finding it (or just hardcode it). The heavy lifting is done in the second foreach loop, where I build stdClass objects just robust enough that WordPress will interpret them as true nav menu items.

 

Safely delete spam comments across a large WP network

I’m currently working on a university WordPress network that’s been running for four or five years (an MU veteran!) and has almost 5000 blogs, most of which are defunct (because they’re from previous semesters). Akismet is activated across the network, so there’s not much of a public spam problem. However, even spam comments are stored in the database, and some of the blogs have tens of thousands of spam comments sitting in their tables. I’m going to implement a couple of tricks to keep this from happening in the future (a lightweight honeypot for non-logged-in users, tell Akismet to auto-delete spam comments on old posts). But for now, I’ve got to clean up this mess, because the very large comment and commentmeta tables are causing resource issues.

I wrote a simple script that gradually cycles through all the blogs on the network and deletes comments that have been marked as spam by Akismet. Here it is, with some comments afterward:

Notes:

  • The number of blogs is hardcoded (4980)
  • The ‘qw_delete_in_progress’ key is a throttle, ensuring that only one of these routines is running at a time. You might call this the poor man’s poor man’s cron.
  • I’ve limited it to 10 comments per pageload, but you could change that if you wanted
  • Put it in an mu-plugins file. When it’s finished running (check the ‘qw_delete_next_blog’ flag in the wp_sitemeta table – it’s done if it’s greater than the total number of blogs on the system), be sure to remove it, or at least comment out the register_shutdown_function line.

Use at your own risk – I’m posting here primarily for my own records 🙂

Anthologize 0.7

Anthologize 0.7 is here. Get it while the gettin’s good!

Version 0.7 includes a number of important, under-the-hood improvements. Some highlights:

  • The way Anthologize loads itself has been largely rewritten, which means that it fires up more reliably – and using fewer resources – than ever before.
  • Some validation issues with epub exportsr have been cleared up
  • In previous version of Anthologize, PDF exports sometimes failed because Anthologize could not copy inline images to the necessary temporary directory. This process has been rewritten so that our PDF library uses WordPress’s standard upload locations, avoiding permissions errors
  • A Spanish translation is now available
  • Full compatibility with PHP 5.4 and WordPress 3.5

In addition, a Credits page has been added to the Anthologize menu. This new page includes shout-outs to all those supporters of my fundraising campaign. If you donated (and opted not to remain anonymous), check out the Credits page to see your name in lights! And if I’ve made a spelling error, or linked to the wrong URL, please let me know.

This round of development was brought to you by Cyri Jones. Cyri is an educator and technologist doing amazing things with WordPress and BuddyPress in lovely British Columbia, including his ZEN Portfolios platform for student portfolios, and private social networks for a number of local school districts. I’ve had the good fortune to do some work for Cyri’s projects, and I think that the work he’s doing with these free software platforms points toward a very interesting model for putting social learning technologies in the hands of those who can use them. Cyri was also the brains (and brawn) behind the very first BuddyCamp, held last October in Vancouver. Rock on, Cyri!

Make Github issue numbers appear in browser tabs

#70. Yippee!

#70. Yippee!

I use Github Issues as a bugtracker for a number of my projects. My workflow usually includes having the ticket open in one browser tab, and a local WordPress installation open in another browser tab (to test the bugfixes themselves). When I write commit messages, I want to reference the issue number, but by default, it’s buried deep in the <title> element, and thus not visible on a smallish browser tab.

So I wrote a short userscript that reproduces the issue number at the beginning of the <title>, so I can see it at a glance. It’s structured as a userscript for Greasemonkey/Firefox, though I imagine you could easily repackage it for Chrome or whatever.

[code language=javascript]
// ==UserScript==
// @name github issue number in tab
// @namespace https://boone.gorg.es
// @description github issue number in tab
// @include https://github.com/*/*/issues/*
// @version 1
// @grant none
// ==/UserScript==

var t, ttext, issueno;

t = document.getElementsByTagName( ‘title’ );
ttext = t[0].innerHTML;
ino = ttext.match(/Issue #([0-9]+)/);
console.log(“#” + ino[1] + ” ” + ttext);
t[0].innerHTML = “#” + ino[1] + ” ” + ttext;
[/code]

2012: Don’t let the door hit you

I told my wife that this blog post was going to consist of one sentence: “2012: good riddance to bad rubbish”.

For posterity’s sake, I’ll spell it out a little more. The last half of 2012 has been particularly trying. I traveled too much and worked too much. I moved to a new apartment in a new borough. I had too many deadlines on top of each other. And my amazing wife has somehow been even busier than I’ve been, which has made ours a hectic home. So, while there’ve been some really wonderful parts of 2012 (especially watching my son turn from a baby into a toddler), I’m happy to bid it farewell – and good riddance.

In lieu of a roundup in the style of the last few years, here are a couple of thoughts I’d like to keep in mind during the upcoming year.

  • Don’t get too comfortable professionally. In 2012, I fine-tuned my professional work to be more highly focused and purpose-driven. (See this post for some related thoughts and strategy.) This process has been a success by just about every metric: I’m making better money, and I’m doing work that has a broader impact. But I’ve got to be careful not to fall too deeply into the niche I’ve chosen. As I become more and more of an expert, I find myself supervising others rather than building myself; and when I do find myself building, it’s rarely something really new and interesting. Expertise is good for your career, but, almost by definition, being an expert means being bored more of the time. I’ve got to remind myself to keep doing new things, even if (or especially if) it means leaving my comfort zone.
  • I can’t do everything. 2012 was the first year where I really felt that I was reaching the limit of how much work I can realistically do. Another side effect of expertise is that you start to think that you have an infinite capacity for taking on new projects, but the truth is that everything suffers if you allow yourself to be overextended. I’ve got to start saying no more often, and being more realistic when I schedule myself.
  • Turn it off sometimes. My schedule in 2012 has lulled me into thinking that it’s OK to check my email all the time, or to work every evening, or to work every weekend. For me, these things are decidedly not OK, and I should start acting accordingly. If it means that I’ve got to start taking on fewer professional projects, so be it.

Here’s to a bright and sane 2013!