I like to use email-style quotes when I write:
In your email, you said
> Boone, you suck
You were totally wrong about that.
I wanted to be able to do the same thing on my blog (or in my blog comments) and have the quote rendered as an html <blockquote> element. So I wrote a little filter.
Martha Burtis, instructional technologist extraordinnaire at University of Mary Washington, wrote earlier today about some WordPress development workshops she’ll be leading at Universidad del Sagrado Corazón in the upcoming days. She’s responding to my prodding, and in the process, demonstrates with aplomb a few of my central points:
On the overlap between web development and education:
I got into Web design/development years ago because I loved how it allowed me to architect experiences. I got into higher education at the same time because I really do believe that education is one of our society’s highest callings. Blending my passion for education with my passion to craft experiences is basically what drives me […] I believe strongly that the fundamental nature of the code we work with speaks to the values we’re trying to embrace in the practices that our code enables. I love WordPress because it affords me possibilities. It affords me possibilities because it is open.
On how she plans to frame the technical parts of the workshop:
People are always amazed when they find out I studied English as an undergrad. I never quite understand why. Don’t they know that code is poetry? Seriously, I’m going to talk a bit about the relationship between code and poetry — a relationship that I’ve always found fascinating. I’m also going to talk about code as a tool for building experience. Finally, I’m going to talk about the way our values and politics (small “p”) inhabit the code we work with.
Martha illustrates the value that WPedu can bring to the broader free software project. People working with WordPress inside of the university approach their development (design, etc) with a focus on the user, and the benefits that the open nature of the software bring to the user experience. And people from academic backgrounds are trained to reflect critically on the way that software mediates our relationships with the world and with each other. This is a breath of fresh air in what can sometimes be an overcommercialized and results-focused community. Rock on, Martha!
There’s a huge, amorphous community of people using WordPress in education. Let’s call it WPedu. There’s another huge community of people involved in the WordPress free software community. Let’s call it WPorg.
WPedu, meet WPorg. WPorg, meet WPedu.
I’d like WPorg to know that WPedu is kicking some serious ass. Take DS106 as an example. DS106 is a distributed course on the topic of Digital Storytelling (that’s the “DS”), where students all over the world – some of whom are enrolled in credit-bearing DS courses at their colleges, some of whom are just tagging along for the ride – use their blogs to complete assignments of various sorts. WordPress, FeedWordPress, BuddyPress, and a bunch of custom hacks are used to aggregate content from hundreds of participants into a single stream. The whole thing is built around the idea of openness: existing, open standards like RSS are being used to federate standalone instances of WordPress (alongside any other system that outputs RSS).
People working on free software – like you, WPorg! – should be flipping out over how awesome that is.
Similarly impressive innovations can be found all over the WPedu world. The innovation is motivated by the love of the work, and by principles: education should be open, individuals should control their data and their online identities, software should be free as in speech. These are the very same principles that are close to the hearts of free software enthusiasts.
People involved in the WPorg community should be spending more effort reaching out to WPedu people. The software developers, instructional technologists, faculty members, and other people working in WPedu are a huge, largely untapped resource for the free software project. People working in K-12 and universities, especially those working in public institutions, often have an incentive (even an imperative) to be sharing their work out to the larger community. (Contrast this with the fact that for-profit WP devs actually have a disincentive to contribute, an issue I wrote about recently.) People in WPedu are experts at piecing systems together, at writing documentation, at community moderation, and so on. They often enjoy flexible job descriptions and fairly loose oversight, and they’re less beholden to financial issues than people working in the private sector. Thus, for many WPedu people, it’d be quite concievable to shoehorn some free software work into their workweek. Most of all, WPedu people are totally awesome people – you have to be pretty awesome to put up with the lackluster pay and ridiculous bureaucracies that education folk have to deal with. Start talking to these awesome people. They have incredible ideas about where WP should go, and they have the resources to help get there.
On the flip side: WPedu, you are doing some cool shit, and deep in your heart, you know it. So don’t be afraid to talk about it. It’s true, ome of you are blogging, and that’s great. These blogs are usually addressed (understandably enough) to fellow WPedu people – “here’s a cool new way to use WordPress in a university”, etc. But you should stop qualifying yourselves: Lots of the stuff you’re doing is legitimately a cool new way to use WordPress, period, and you should be proud of that. Own your excellence and innovation.
I come from WPedu, so I say this from experience: there’s too much modesty, bordering on mousyness, among WPedu innovators. Many – most? – of you were never formally trained in software development (or design, or support, or documentation, or whatever). I know I never was. And being embedded in institutions founded on the very notion of Expertise – you can’t spell University without PhD – makes you too unsure of your own skills to reach out and get involved. Here’s a secret: Most of the people in the WPorg community came from non-technical backgrounds, too. (IMO, that’s one of the things that has made WordPress successful, but that’s a topic for another post.) You deserve to be involved, just as much as any of the current community contributors. Three-quarters of expertise is having the confidence to get involved.
If that’s not enough persuasion, here are some practical considerations.
I shouldn’t make it sound like there’s no overlap between WPedu and WPorg. There is. But it’s much smaller than it should be, given the direct parallels between the ideological goals of the free software project and the ideological goals of the educational enterprise
I’m working on a couple ideas that I think will help to bridge some of the gaps between WPedu and WPorg. I’ll share more about them when they become more well-formed. In the meantime, I’d love to hear your thoughts about how to move these mutually beneficial connections from the realm of the practical to the actual.
This blog has gone unloved as of late. I’ve been working too much, and not taking the time to sit back and think about the work I’m doing, and I think that’s a bad thing. Reading Alan Levine’s call-out the other day reinforced the feeling that I should devote more attention to reflecting in this space, if only for my own sanity.
So, as a starting place, I made a new theme – my first revamp since I started this blog in late 2008. I ripped off Mark Jaquith’s idea and used Twenty Twelve – the new default theme that will ship with WordPress 3.5 – as my parent theme. It’s much easier on the eyes than my old theme, and its responsive nature allowed me to uninstall WP Touch. (WP Touch, you served valiantly lo these many years. RIP.) If you’re interested, I’ve made my (very modest) child theme available on Github.
My slides from Wordcamp NYC, on using Git for WordPress development, can be found after the jump. Feel free to borrow from my design brilliance.
I am not a programmer.
Spend a few minutes in a place where software users interact with software developers – support forums, dev trackers, face-to-face team meetings – and you’re bound to hear this phrase used (or one of its relatives: I am not [a geek|a developer|a coder|tech-savvy], etc). It’s a statement of fact, and a useful statement at that, since the kind of help offered to a “programmer” is obviously quite different from what’s offered to someone who’s not.
But The Phrase is so much more than that. It’s a strategic move in a social game. Its uses fall into roughly two categories: a cry for empathy, and a deflection of responsibility.
I am not a programmer often means Go easy on me. Ask yourself: Why would someone go out of their way to ask for empathy in this way?
Sometimes it’s a way for a n00b to test the waters. Newcomers to a software community don’t always know the community conventions for asking for help. Labeling oneself as “not a programmer” is a gentle way of gauging how others react to new folks.
More frequently, in my experience, I am not a programmer is used by people who have been burned in the past. Maybe the user once asked a question and got an answer that was over her head. Maybe the discussion turned sour when the developers looked down their noses at someone who couldn’t understand a few lines of code. When this happens, I am not a programmer is a shield, a preemptive attempt to guard against the abuse that the asker rightly or wrongly expects to receive.
I wrote a post a while back on how this looks from the developer’s point of view. The gist, so far as this use of The Phrase is concerned, is that developers should be as empathetic as possible in these situations. For one thing, treating people with kindness is just the right thing to do. Beyond that, it’s important to the future of the community to extend a hand to potential contributors.
The other common use of I am not a programmer is something like: I’m not technical, so don’t even try to get me to crack the hood, which often amounts to I refuse to make an honest attempt. Do it for me.
This phenomenon is, in part, a side effect of the fact that I work with WordPress. WP is unusual among free software projects in that “ease of use” has always been central to its development strategy. The Dashboard, the inline updater, the plugin installer, the five-minute install – all are the result of a conscious effort by WP devs to make the barrier for entry as low as possible. And it’s worked. Without touching so much as a semi-colon of code, you can set up a beautiful and powerful website using WP and the some of the thousands of readily available plugins and themes.
On balance, this is a Very Good Thing. But it also sets up, in the mind of the average user, a certain (incorrect) understanding and set of (unreasonable) expectations about how free software works. In the world of commercial software, the development process is deliberately shrouded from end users. Apple (to take an example) has support forums. But the solutions offered here are always “click here” and “type this”, never “change this code” or “hack this” – if for no other reason than that the software is designed to be un-hack-friendly. In the case of open source software, the source code is available. Thus there is no enforced distinction between those who write the code and those who use it. For users of free software who are accustomed to the proprietary model, it’s hard to get your head around the idea that you can – and should! – be hacking it as part of the troubleshooting process.
Moreover, people who are accustomed to paying for software are used to getting a minimal level of functionality and support in exchange for their license fees. Free software has no license fees. But there persists a sense, in the minds of some users, of “How could you release something that is not 100% working?”. They approach support as a consumer transaction; the idea that troubleshooting could be a collaborative endeavor between users and devs, and that this troubleshooting is part of a larger arc of software development, is totally foreign to them. This seems especially true in the case of WordPress, which is so easy to use that it sets user expectations very high.
It’s perfectly understandable that the move from proprietary to free software would be jarring for users. But it’s not OK for these users to attempt to force their commercial expectations on a non-commercial community. The blurring of the line between user and developer, where users occasionally take a deep breath and crack open the hood, is a crucial part of the way free software is developed. It’s how bugs get fixed, and it’s how new devs emerge from the larger community. I am not a programmer, when it means I refuse to step outside my comfort zone, does active harm to the software project. It’s not that everyone has to become a “programmer” – it’s perfectly fine if you have no desire to get technical. But to deflect the issue altogether – especially with incredulity or anger, as if it’s totally unbelievable that you may be asked to do something technical – is a violation of the free software ethos.
So, next time you see a support request prefaced with “I am not a programmer…”, show a little empathy – but not too much 🙂
Many contributors to free software projects fall roughly into one of two categories:
In some ways, these two categories represent the extremes of a spectrum: the first group contributes because it’s their job while the latter contributes because they love it. These motivations are by no means mutually exclusive; I’d hope that most people who are paid to work on free software also love to do it. But this short list does describe what I would call the two “pure” drivers of contribution.
Between the two extremes lies a considerable gray area, where the two varieties of motivation – love and money – may coexist in the same person, yet point in different directions. Take me. I am a freelancer, specializing in development and consulting on WordPress and related technologies. On the one hand, I’m an ideological advocate for free software, and I love contributing. On the other hand, the dynamics of the freelancer’s situation often discourage contribution. There are only so many hours in my day, and when the work hours are spent doing client work for WordPress, I hardly want to devote my limited free time to working on WordPress for free. And clients have a bunch of perfectly understandable reasons for not wanting to share the work that they’re paying for: they don’t want to spend more money than necessary to get their site working, they want the competitive edge that may come from secrecy, and so on. The two “pure” motivations for contributing are in conflict with each other.
To combat the conflict, so that I can contribute more, I’ve moved increasingly toward what I think of as a “patronage” model. Broadly, the idea is that clients fund the process of turning the custom-developed features (that they were already going to pay for) into something that can be contributed back to the free software community; in exchange, they get certain benefits, like prestige and publicity. For me, the strategy has come down to a couple of key rules.
I’ve been freelancing full time for about two years. During that time, I’ve managed to take on a growing number of increasingly large projects. Through the same period, due to the patronage model, I’ve largely maintained – or even increased – the amount of time spent contributing to free software projects (even as my free time has been dominated by marriage and fatherhood!). More money in my pocket, and more free software for community use. Truly a win-win.
Not everyone will have my good fortune to be able to stick to such a strategy. I’m lucky to be offered far more work than I could possibly accept, which means I can turn down the stuff I don’t want, in accordance with the rules listed above. And I’m fortunate to be well known and well respected in my field. But it should be noted that my good fortune is not a coincidence. The more of your time you can devote to public work in free software – whether that work is as a hobbyist or as a patron-sponsored freelancer – the more well known you’ll become in the community, which will result in more job offers and more leverage with potential clients. It’s a virtuous circle that takes some courage to break into, but ends up being beneficial to everyone if you’re successful at it.
Just as important as the benefits that the patronage model has brought to my own career is what it says about the future of free software development. Software like WordPress will never be commercially supported like Windows, where development is funded by the license fees of millions of users. For major development on free software projects, it’ll always be incumbent on a few generous patrons to provide resources. But there are dangers in overcentralized patronage: if, say, Automattic decided to abandon its committment to the WordPress project, a huge percentage of dev resources would suddenly dry up. The contractor-patronage model I’ve described here is a way of increasing the number of patrons, while lowering the financial bar for patronage – organizations can contribute in a meaningful way with just a few thousand dollars. Adopted widely, this promises to be a more secure foundation for ongoing free software development.
TimThumb is popular PHP script for dymanic image resizing, and is often included in WordPress themes and plugins. It caches its processed images for performance reasons; its default cache directory is called cache, one directory level up from the script itself. TimThumb itself helpfully allows users to define a custom cache directory with a constant (FILE_CACHE_DIRECTORY) as well as a mechanism for loading this custom configuration (an optional timthumb-config.php file).
This setup provides plenty of flexibility when you’re using TimThumb on a one-off site for a client. But when TimThumb is packaged with a theme or plugin, this method of configuring TT not very helpful. Take the case of WooThemes, which uses TimThumb in all of its themes. We use a number of these themes on the CUNY Academic Commons, where I keep tight reins on file permissions. Our Apache user can’t write to the subdirectories of wp-content/themes/, which means that the versions of TimThumb in this directory can’t use the default cache location.
The problem is that there’s no easy way to fix this in a global way. Creating a /cache/ subdirectory in each of these theme directories and chmodding them to something more lax is out of the question in my scenario. After all, I already have a directory where Apache can write files: the WP uploads directories (wp-content/uploads and wp-content/blogs.dir).
But configuring TimThumb to put its cache in one of these places is difficult to accomplish globally. The obvious solution is to create appropriate timthumb-config.php file in each of the theme directories in question. This stinks, though, because it means that my modifications will have to be reapplied each time I upgrade the themes. In fact, what I’ve actually done for the moment is a variation on this: I created a centralized timthumb-config.php file, in a centralized location (wp-content, in my case), containing a single line:
[code language=’php’]
[/code]
I wrote a short script that crawled over every one of my WP themes, and if it found an offender (in my case, any theme with ‘WooThemes’ in the Author tag), create a symlink to the global config. I’ll be including this script as part of my more general deployment scripts.
Of course, this is all extremely inelegant. There are a few things that the theme developers could have done to account for my sort of situation:
Stop putting a copy of your shared utilities (the “framework”) in every theme directory. I understand why the theme shop might make this architectural decision – I’m sure that the vast majority of their theme sales are to people running the theme on a non-networked, single site. But it causes a lot of problems for Multisite networks that offer many themes to their users: a single change in the framework means updating all themes, which becomes a real pain if the theme dev’s autoupdater also isn’t working properly. Allow your framework to be installed as a network-activated plugin, or at least dropped into the wp-content directory. Better still: You can continue to ship the framework files with the themes, but only load them if the pluginified version is not found. That gives you the best of both worlds.
Now in the case of TimThumb, this schema wouldn’t have solved the problem. But it would have meant hacking a single file, rather than 50 different files spread out through my installation.
Put a wrapper around TimThumb, to allow more flexible placement of the config file. For instance, create a file called mytheme-thumb.php, which looks like this:
[code language=’php’]
[/code]
Then point all of your TimThumb-generated src attributes to mytheme-thumb.php, instead of directly at TimThumb. This way, if a global config is found, it’s loaded first, otherwise it falls back on a local timthumb-config.php file, as specified by TT itself.
Pluginify TimThumb before using it In a perfect world, you would have the flexibility of WordPress behind TimThumb: the ability to store your cache location to the database, for example, or to filter the location using apply_filters(). I did a bit of testing to see just how much overhead this would add. In my tests, TimThumb used about 700KB to load a simple picture. To load WordPress using the SHORTINIT constant (which loads just enough of WP to get things like get_option() and apply_filters()) takes about 2800KB. So loading WP SHORTINIT + TimThumb would take about 3500KB, or about 5x what it takes to load the same image using TimThumb alone. This wouldn’t be so bad with aggressive caching, but it’s probably too much sacrifice for a script that may get called several times on every single page load.
So here’s another idea: Just drop in wp-includes/plugins.php. I once heard someone say that a great way to improve any PHP package is to include this file, and I think they’re right. plugins.php is self-contained (it doesn’t require the rest of WP), and it only adds another 50-100KB of overhead. Let’s take our mytheme-thumb.php file again, but add some plugins.php goodness:
[code language=’php’]
[/code]
Now in this example, thumb.php wouldn’t have to be an out-of-the-box TimThumb instance. It could be filled with wonderful do_action() and apply_filters() goodness. And your global-timthumb-config.php or timthumb-config.php file wouldn’t just define constants – you could have full-fledged PHP functions, using WP’s hook infrastructure.
This means maintaining a fork of TimThumb, but it could be a great resource for WP theme developers.
This is a pretty common form format:
(Imagine that the textbox was next to the word ‘Other’ – wpautop() or something is being a stupid craphead and inserting a line break.)
It’s not really possible with BuddyPress’s xprofile fields. Today I dove into the codebase to see how hard it would be to add such a feature natively. The answer: Too.
So I wrote a hackish plugin instead, which you can get from this gist. (Note that it’s not in a plugin wrapper. Put it in your bp-custom.php.) To use: (1) On the Admin screen for a profile field, select ‘Yes’ under “Other Field”. (Note: it only works for checkbox fields!!) (2) ??? (3) Profit.
One of my WP/BP projects experiences a perpetual problem, where every few weeks a handful of users is demoted on one of their blogs – they go mysteriously from Editor to Subscriber, or something like that. This sort of thing is a beast to troubleshoot, because it’s not readily reproducible.
So I wrote a small utility plugin that will help site administrators keep tabs on every role-change through the entire installation. Put the plugin into mu-plugins and the run the installation script, and it’ll fire up every time a user’s `wp_x_capabilities` meta key changes, and record some helpful information about it in a custom database table (user id, logged in user id, blog id, BP group id, stuff like that).
For more on the plugin, and to download it, visit its page on Github.