Author Archives: Boone Gorges

No email, no cry

In the spirit of a recent post by my friend Evan Solomon, I thought I’d write briefly about a decision I made this summer: No more email on my mobile devices. A few months ago, I removed the Email shortcut from my home screen; today, I switched to a new phone, and I don’t plan to configure the email app at all.

The reasoning behind this decision is similar to Evan’s. Very rarely do I get an email whose subject is truly urgent, in the sense that it requires immediate action. Those few that I do receive are almost always related to work – someone’s production site has gone down, say. But, in nearly all cases, it’s a problem I can only solve if I’m at a regular computer. And if I’m using my phone, it’s likely that I’m not currently at a computer, and I probably can’t be at one immediately. So there’s little to be gained from getting the message while I’m on the go. Urgent messages that are not work-related – such as family emergencies – wouldn’t come through email anyway, so I’m not missing anything in that case either.

Like Evan, I find myself able to concentrate better on the people around me when I’m not thinking about the device in my pocket. This is doubly true because of the nature of the non-urgent email I usually get. Many emails are bug reports, and reading about bug reports when I’m not in a position to do anything about them is both highly distracting (mental debugging!) and usually frustrating. Some emails are requests: for favors, for work proposals, etc. This kind of email too is distracting in an unpleasant way, as I find myself silently drafting a response on the spot. Even the few emails I receive that are genuinely pleasant take me out of the moment, and again, don’t really admit of a proper response while I’m on the go (I refuse to write anything longer than a text or a tweet on a phone).

Weaning myself from the mother’s milk of mobile mail was a quick and painless process. A day or two in, and already I could see that I was more engaged with the things around me. When I’m at the playground with my kid, I’m paying attention to him. When I’m on the train, I’m reading a book. And when I’m standing in line or in some other kind of situation where email typically fills the void, I’m often just feeling bored. And feeling bored is a very welcome change from a head clouded by frustration and software bugs.

So, think about it. What value do you get from reading email on your phone? And what does it cost?

Grilling pizza for fun and leftover disposal

This summer, my family and I rented a lake house for a few weeks. We were excited to have a grill, and at first, we took serious advantage: burgers, chicken, kebobs, barbecue, etc. But we soon ran up against two problems: meat fatigue and a fridge full of leftovers. Between the two of us, my wife and I have a number of standby techniques for disposing of miscellaneous leftovers, but most (like frittatas and stir fry) require making the house even hotter with a hot stove.

Pizza to the rescue! We got the idea early in our trip to try making pizza on the grill. It turned out so well that we ended up doing it a number of times. Not only was it a good way to get rid of just about any grilled leftovers, but it was legitimately good pizza in its own right – even when some of the ingredients we used were kinda cheap.

Arriving at the best technique was the biggest challenge. I’ve described the process below. We had a propane grill, which was helpful for heat control, but you could do it with charcoal and it’d probably taste better.

Get a dough – We got our doughs from the local pizza joint. You could make it yourself, but it’s a pain to make pizza dough, and so cheap to buy it. I’ve bought doughs from at least a half dozen pizzerias, and I’ve never paid more than $4 for a large one. As long as it’s a non-chain joint that does reasonable business, you know the dough will be fresh, and prepared with more expertise than if you’d done it yourself. (Some grocery stores sell pizza doughs. I’ve never bought one, so I can’t vouch – but I have noticed that they’re generally pretty small. Also, you can buy premade crusts, but is lame, as it takes away the biggest advantage of the grill, namely that it gets hot enough to cook a crust properly.)

Dough

Get a large dough from a local pizzeria. Price: $2-4.

Get the rest of your ingredients – You’ll need:

  • Sauce – We used cheap jarred sauce. Plain crushed tomatoes would probably be even better. Once we made a pie with leftover pulled pork, and I used a thin layer of barbecue sauce instead.
  • Cheese – We had our best results with Polly-O mozzarella, either grated large or cut into very thin strips/slices. The pre-shredded stuff is a big question mark – could be fine, but could be pretty dry (that is, too dry – good pizza cheese should be a bit dried). You can use another cheese as an accent, like a bit of goat cheese.
  • Toppings – Whatever you have laying around. Once we made something pretty fancy (some chi-chi salami), but usually it was whatever meat and veggies we’d grilled the day before. If it’s a bit limp after sitting in the fridge, give it a quick sauté before using. Fresh herbs are nice too.
  • Oil – We used olive oil at a couple different points in the process, as described below.

Get your mise en place together – I’m typically cavalier about getting stuff in place before cooking, but with grilled pizza it’s crucial. The steps below can be fast and furious, and you won’t have time to stumble drunkenly to the fridge to get ingredients.

Mise en place

Get it together. High Life optional but recommended

Preheat, clean, and oil the grill – Turn it up as high as it goes. The reason why you’re able to make decent pizza on the grill, but not in your oven, is because the grill gets a few hundred degrees hotter. Give it at least 15 minutes to get blazing hot (or more, depending on how your grill works). Make sure it’s clean and well-oiled, or your crust will stick and break.

Stretch the dough – There are lots of ways to turn a ball of dough into something resembling a pizza. My preferred technique is to stretch it to a disc, then hold it vertically by the edge, letting the dough fall downward while stretching the cornicione a little bit. Keep turning and stretching, allowing gravity do most of the work but helping to keep a pretty uniform thickness. Basically, make the crust as big and thin as you can without breaking and without being too big for your grill.

Almost ready to flip

Almost ready to flip

First grilling – It’s time to give a quick sear to what will end up being the top of the pizza. Lay the stretched dough on the grill. (It’s flexible, so now’s the time to make that circularish dough into a rectangularish shape, if that’s how your grill is shaped.) Brush the exposed side of the dough with olive oil. Then close the lid. Let it cook for maybe a minute, then check the upskirt. Once it’s charred to your liking, turn the burners all the way down – this’ll be important in a second. Use a big long spatula to make sure the whole crust is loose from the grill, and then use that same spatula (along with some tongs, or your hands) to flip the crust over.

Upskirt

Upskirt (that’s a technical term)

Post-flip

Post-flip

Top the pizza – You’ve turned the burners way down, but the grates are still very hot. You’ll want to top the pizza as quickly as possible, so you can get the lid closed and the cheese melted before the bottom has a chance to burn. Brush the pie with oil. Then sauce and cheese – if you put the cheese down first, it melts a little better, but it’s harder to then spread the sauce, so experiment to your liking. Then the toppings. It’s helpful to have two people working here, one doing the oil, the other following right behind with sauce, and so on.

Topped

Topped and ready for the second cooking

Let it cook – Close the lid and crank the heat up all the way again. Because the grill cooled a lot while you had it open to flip and top (when the heat was turned down), this second cooking will take a bit longer than the first. Check the pizza after two or three minutes. You’re looking for two things: the cheese should be adequately melted, and the bottom of the crust should look adequately done. If it seems like the crust is cooking too fast, turn down the heat.

Voilà

Voilà

Remove and dress – Get a platter, and use your big spatula to get the pizza off of the grill. Depending on size and thickness of crust, it should be pretty firm and easy to handle. This is when I like to dress with basil and a drizzling of oil. Some Parmasean or Romano cheese would also be good.

Here are a few of the pies we made over the course of our stay:

Unless you’ve got a special oven made for cooking pizza in your kitchen, the technique described above is likely to get you the best home-cooked pizza you can make. It’s a cheap and delicious way to put leftovers to good use. Hop to it, before grilling season is over!

New WP plugin: WP DPLA

Last week, I attended THATCamp CHNM, and I entered (and somehow managed to win) the Maker Challenge with a WP plugin that pulls related items from the DPLA API and displays them on your posts. I’ve just added the plugin to the wordpress.org repository: http://wordpress.org/plugins/wp-dpla.

Read more about the plugin at my THATCamp post: http://chnm2013.thatcamp.org/06/08/maker-challenge-wordpress-plugin-for-displaying-related-items-from-the-dpla/

BuddyPress Docs 1.4 and attachment support

I’ve just released version 1.4 of BuddyPress Docs, my collaborative editing plugin for BuddyPress. The big new feature is the one that users have been asking for since the plugin was first released: file attachments. I’m using a nifty trick (involving the autogeneration of .htaccess files) to ensure that Doc privacy levels are extended to their attachments. I think it’s going to be useful to a lot of people.

In the future, I plan to write a tool to migrate content created by the abandoned BP Group Documents to this new system. Stay tuned.

This round of development was generously sponsored by the Center for Applied Research and Environmental Systems at the University of Missouri. They are long-time users of BuddyPress, and they were pleased to support the development of this feature for the community. Special thanks to David Cavins, who set up the connection between me and CARES, and also contributed huge amounts of technical, conceptual, and design help to Docs 1.4. (He also builds beautiful guitars.) Thanks to CARES and to David!

A recursive sorta-version of wp_parse_args()

WordPress trick: wp_parse_args() is a helpful function for taking configuration arrays passed to a function and combining them intelligently with the default arguments for the function. I needed a recursive version, for use with multi-dimensional arrays of arbitrary depth, so I wrote the little ditty below. As I note in the docs, there are fundamental ambiguities in the process of rectifying multi-d arrays, and the technique I’ve chosen is specific to my implementation. Use at your own risk.

Get your Boone fix

Mostly for my own records, here are a few recent Boone-related videos and interviews from around the web:

  • Code Poet interview – April 18, 2013. In which I speak at length (ramble?) about BuddyPress, the university, and the value of free software
  • WordSesh panel – April 13, 2013. A livestreamed discussion about BuddyPress with John, Paul, Ray, and Tammie.
  • BuddyCamp Miami presentation – April 5, 2013. A brief talk where I talk about how to use BuddyPress’s Group Extension API to add BP features to a WordPress plugin. The slides are at blo.so/bcmia.
  • WPNYC presentation – January 15, 2013. A talk I gave on the big new features in BuddyPress 1.7

Using a hosts file for easy management of dev, staging, and production WordPress sites

This recent article at Smashing Magazine discussed trends and challenges in deploying WordPress sites. The biggest issue cited by the article and the lengthy comments that follow is the issue of the database: because WordPress stores strings in the database that contain the site domain (including configuration options and asset paths), it’s hard to migrate content and config between dev, staging, and production environments. A bunch of possible solutions were offered up, including interconnectit/Search-Replace-DB, which I use fairly often and really like.

I was surprised, however, that no one talked about my preferred strategy, which is, in a way, the simplest: Dev, staging, and production should all have the same domain names. When you remove the need to change the domain, you make it much easier to deploy specific pieces of content, spin up new instances, etc.

Since all versions of a site have the same domain name – say, booneisthebomb.com – I use my local hosts file (/etc/hosts on *nix systems) to switch between instances. So I may have the following lines in /etc/hosts:

[code]
# Local development
# 127.0.0.1 booneisthebomb.com

# Staging site
# 123.456.789.0 booneisthebomb.com
[/code]

With these two lines commented out, going to booneisthebomb.com in a browser will use DNS for the lookup, which is to say it’ll go to the production site. Uncommenting one of the lines allows me to work on the local or staging site.

The biggest pitfall of this technique is that now there is no obvious way to tell your environments apart (and you definitely don’t want to mistake your production site for a dev site). My solution for this is to drop this file into wp-content/mu-plugins/. Then, in my environment file (which contains env-specific config, such as database connection info), I put a line like this:

[code language=”php”]
define( ‘ENV_TYPE’, ‘staging’ );
[/code]

Now, when I load up the staging site, it shows booneisthebomb.com in the URL bar, and the following box appears at the bottom of every page:

env-type-flag

WordPress developers: Write to the filesystem the right way

Many WordPress plugins and themes need to write to the filesystem, to cache data, create a debug log, download libraries that for one reason or another aren’t distributed with the main package, etc. And many of these plugins do it wrong, by writing (or attempting to write) to their own plugin/theme directories. This is a bad idea for a couple of reasons:

  • If you use version control to deploy/manage a site, you probably have configured your repo to ignore the content of dynamic directories like wp-content/uploads. Obviously, you don’t want to ignore plugin and theme directories. When Git etc detects your newly created files, it wreaks all sorts of havoc with workflow and, depending on the content of the files and the carelessness of the deployment manager, poses the risk of losing user content or endangering sensitive data.
  • Some people have their file permissions set very conservatively, so that the webserver user doesn’t have write access to wp-content/plugins or wp-content/themes. So plugins that attempt to write to those directories often break altogether.

The good news is that every properly-configured WordPress installation will have at least one location where the webserver can write, and which is highly likely to be ignored by all version control setups: the upload directory wp-content/uploads. The situation is more complicated on Multisite, where each site has its own subdirectory of wp-content/blogs.dir. Happily, there’s an easy way to concatenate an upload path that’ll work across installations:

[code language=”php”]
$uploads = wp_upload_dir();
$my_upload_dir = $uploads[‘basedir’] . ‘/yourplugindir’;
[/code]

WordPress has a very slick filesystem class that’ll help you if you really do need to write to a plugin or theme directory. But 99% of the time, you don’t. Please keep your stuff out of the codebase.

GPL and free software language for government contracts

This weekend at BuddyCamp Miami (which ruled btw) I chatted with a number of folks about putting GPL clauses into client contracts. It can be especially challenging when working with universities or other bureaucracies that have hardcore, work-for-hire-ish intellectual property clauses already built into their consultant contract boilerplate. On a number of occasions, my clients and I have worked with the legal departments at universities to develop new language that fits the spirit and law of GPL software. In my opinion, this kind of work is among the most important work I’ve done since I started in this business, even more important than most of the software I’ve written. By having the discussions with legal, and by getting free-software-friendly boilerplate on their books, we take steps toward legitimatizing free software in the university, and making it part of the culture.

Anyway, I was asked privately to share some of this contract language, and I figured it would be more useful to do it in a blog post than in an email. So here are a few examples that have been approved by the legal departments at large universities. (Side note: We should come up with a system for sharing these kinds of strategy docs in a more organized way.)

  1. This clause replaced one university’s extremely restrictive IP boilerplate:

    Foundation acknowledges and agrees that enhancements, bug fixes and other custom developments produced under the scope of this agreement will be subject to release under the GNU Public License v2, or another compatible and relevant open-source license.

  2. The following clause is added as a footnote to the existing language about IP:

    Section VIII (1-3) shall not apply when work is being performed in the public domain. Consultant agrees to comply with the GNU General Public License version 2, as set out in the Attachment #2, when work is being performed in the public domain.

    A few notes about the language in this second example (which their lawyers wrote, not me). First, “Attachment #2” is a copy of the GPLv2. Second, I think there is a little bit of confusion here about “public domain”, because strictly speaking, “public domain” means that no one owns the copyright, while the GPL is dependent on copyright. I think the spirit of the phrase “performed in the public domain” is supposed to be something like “written for public consumption”. But a literal reading of this clause probably means that I must relinquish copyright over the work done under this contract into the public domain. In this specific case, the end goal is for me to extend one of my existing GPL-licensed WordPress plugins; so I will then be integrating this newly-created public-domain code into the plugin, and then distributing the whole thing under the GPL, with a note that the newly added library is in the public domain. This is not ideal, but it’s OK for this case where I’m building a standalone add-on for my own work – good enough not to continue negotiations 🙂

If I can dig up others, I’ll post them here. If you have real-life examples, please share in the comments.