Author Archives: Boone Gorges

Unexpected leadership: preliminary thoughts on One Week | One Tool

July 31, 2010 · 6 Replies

One Week | One Tool just finished, and it proved to be among the most challenging and most rewarding weeks of my professional life. I have a feeling that I’ll need a few go-rounds to really decompress – if for no other reason than that the tool we produced isn’t being announced until Tuesday, so I can’t talk details – but I thought it’d be worthwhile to jot down some thoughts while they’re still fresh.

There’s much to blog about regarding my experience at One Week, much of which I’ll be able to divulge more fully after the veil of secrecy has been officially lifted. (Yikes! So secretive.) One of the things I can talk about now is the workflow of the team over the course of the week, something Jana has already discussed nicely in her blog.

Whiteboard spoilers!

We arrived at CHNM with no idea what we were going to build over the course of the week. Monday was spent getting to know each other, hearing from the CHNMers about they develop and sustain open source software, and brainstorming ideas for our own project. By the end of the day Tuesday, the project had been decided and teams had been divided up. I didn’t sleep very well that night, both from excitement and from nerves: the tool we’d decided to build would rely on a set of technologies that would make me the de facto lead programmer.

And therein lies the first remarkable thing about the event. By many objective accounts – breadth and depth of knowledge and experience – I was, at best, the fifth or sixth most talented developer in the group. (Not trying to be overly humble here: one look at the One Week “People” page and you can see that the deck was stacked with incredible talent, folks with whom I’m happy to be in even the same ballpark.) Differently-focused projects require different kinds of talent, and it so happened that this very focused project required just the sort of skills that I possess. So the first lesson I take away from One Week is that leadership doesn’t necessarily follow, or require, the greatest technical skill or experience. It might be that the notion of “best leader” reduces to “best leader right now”, which is to say that “best” is highly relative to particular needs and circumstances. It’s a realization that highlights how leadership roles are not (or maybe should not) be merit badges gifted to those who have “earned” them, but instead are necessary aspects of a structure – like the One Week crew – aiming to acheive an independent goal.

My second One Week lesson is closely related to the first: leadership doesn’t work without humility and trust. The way we built our tool was like digging the Chunnel: developers at home with one part of the tool’s functionality (like the British on British soil!) tunnelled toward developers who were digging from the other direction. I was in charge of making sure that the several tunnels met in the middle to make for a navigable whole. But, as you’d expect, there’s no way that one person (even one as dashing and wonderful as I am) could really know what was happening in all parts of the project at the same time. There were simply too many technical details to keep track of. Making sure that the tunnel got built, and our code got merged, meant putting a good deal of trust in the diggers, and accepting – even embracing – those moments when their work was beyond my ability to understand technically.

All this is to say nothing of the equally crucial folks who were not writing code, but we doing what we called “user experience” and “outreach”. In those cases even more trust was required: the dev team trusts the outreach team not to write checks that the code can’t cash; the UX team trusts the dev team to remain true to the needs of the end user; and so forth. Here too, in a less technical but no less accurate way, we were digging a tunnel from opposite directions. The outreach and UX teams were developing an increasingly detailed vision of what the tool needed to do, and the dev team was cranking out code that would fulfill that vision. There was a magical moment when, on Thursday afternoon, Jason and Scott from the UX team – coders by trade who had found themselves in a non-coding position in our particular development project – merged in a totally organic way with the dev team to flesh out some of the UX that they’d been conceptualizing for the previous two days. That too demonstrated a kind of trust between One Weekers, where team boundaries were mutable when circumstances required it, and no one blinked an eye when two more people started committing code to the repo.

Much more to come, I’m sure.

Import From Ning now imports Ning content into BuddyPress

July 23, 2010 · 73 Replies

[IMPORTANT: I am no longer supporting this plugin. You may contact me for a list of consultants who may be interested in providing Ning import support.]

Back when Ning announced that it’d be cutting off previously free accounts, I took a weekend and developed Import From Ning, a plugin that helped users pull their Ning user and profile data into a WordPress or BuddyPress installation. It was my own little BuddyPress-fanboyish way of helping all those Ningsters.

Several weeks ago, Ning released its Ning Network Archiver, which (finally) allowed network admins an easy way to take their content with them. On the heels of this release by Ning, today I am releasing version 2.0 of Import From Ning, which imports the content from a Ning Network Archive.

Read more about the updated plugin here. And to those Ningsters who are coming over to WordPress and BuddyPress: good on ya!

Honeymoon barbecue, part 2: the East

June 25, 2010 · 8 Replies

This post is the second of a two-part series about the barbecue my new wife and I ate on our honeymoon. For more explanation and more porky pix, see part 1: “The West”.

JUNE 14: Hudson’s Smokehouse, Columbia, SC

We’d just finished a stint in Eastern Tennessee, where we’d enjoyed some bodacious relaxation but no phenomenal barbecue. We knew we’d have to make up for it on this comparatively short stay in the Carolinas. Our first stop en route to Charleston was chosen largely for convenience’s sake: it was not too far off our course, and we’d be passing by around lunchtime (unlike some of the more well known SC barbecue joints), and they’d be open on a Monday afternoon (again, unlike some of the more traditional joints, which are often open Thurs-Sat only).

With these conditions in mind, a bit of internetting led us to Hudson’s Smokehouse, which had gotten favorable reviews on the sites I’d checked. They had a lunch buffet that looked pretty good, but the idea all-you-can-eat fullness in the 100-degree heat followed by a few hours in the car didn’t strike us as the wisest dining decision. So we ordered off the menu: we each got the pork platter, and I got green beans and baked beans while Rebecca got sweet potato fries and collards.

Hudson's Smokehouse

Here’s the thing: OMG. One small bite of the pork and I was rushed back to our previous barbecue vacation, when we ate our way across North Carolina, hickory smoke coursing through our veins, on a kind of high that can only be sustained with two or three different barbecue joints every day for a week. It’s not so much that Hudson’s was the best pork ever, but it had all the trappings of the great barbecue: the smoky aftertaste, the balance of cider vinegar and Texas Pete’s, the salty outside brown. It was awesome. And the sides were very, very good as well, though the sweet potato fries didn’t stand up to the rest. Evidence:

Hudson's, terminé

Nom nom nom.

June 15: Bessinger’s Barbecue, Charleston, SC

Charleston was blazing hot. Heat indices into the 110s. This is ideal weather for barbecue. Indeed, any weather is ideal weather for barbecue. We were in South Carolina, and we wanted some of the local stuff.

At Hudson’s the day before, the barbecue was Lexingtonesque, by which I mean that it was pork shoulder, served with a vinegar sauce that had just a bit of ketchup in it for color and sweetness. That’s how they do it in the western part of NC, centered around Lexington. When you talk about South Carolina barbecue, though, the mind usually goes to mustard sauce instead of ketchup. Charleston, from what I understand, is known for having a variety of native barbecue styles, but since we were in SC we wanted mustard, and my research told me to get it at Bessinger’s.

I got the pork plate, with baked beans and cole slaw. Bessinger’s is notable for throwing in an enormous onion ring with every meal as well. Let me tell you something about that onion ring: It was something else. Enormous and battered beyond recognition, it was hard to tell, even when looking closely, where the batter ended and the onion itself began. You know that problem you sometimes have where the onion and batter don’t stick to each other, and you end up pulling the whole (scorching hot) onion out on your first bite? At Bessinger’s, the onion and batter had truly become One. Was it the best onion ring I ever had? No. But I have to give them some real points for technique.

Bessinger's

The barbecue was a bit disappointing. By itself, it had just a trace of smoky flavor, and not much of the salty fatness that would have to be present to make up for the relative lack of smoke. The mustard sauce on the table was too sweet for my liking, with none of the vinegary kick that, frankly, I expect even out of a bottle of Plochman’s. The cole slaw was a generic, mayonaissey, Midwestern affair. The beans were on the sweet side for my taste, but otherwise pretty well executed. Maybe I was coming off of a high from the day before and expecting too much, but with the exception of that exceptional onion ring, I walked away a bit disappointed.

For reasons related to heat and pork fatigue and the otherwise awesome food in Charleston, this was the last barbecue meal we had in South Carolina.

June 17: Skylight Inn, Ayden, NC

Unless you are on the way to the bustling burgs of Hookerton or Vanceboro, Ayden is not on the way to anything. After getting off of I-40 North 45 minutes north of Wilmington, we spent about an hour meandering the highways of the beautiful North Carolina countryside before we started seeing signs for the small town. And when I did see those signs, I felt the kind of excitement that an adult man, having outgrown birthdays and Easter baskets, doesn’t get to feel very often. For the second time in as many years, I was headed to the Skylight Inn.

Skylight Inn, capital of my heart

My first time at the Skylight was a very special day. We were near the beginning of our barbecue trip, and already I think we were doubting the wisdom of eating So Much Pork. We drove a long way for what we had described as the best barbecue there is, and we were a bit perplexed to find a shack with a faux rotunda and a huge billboard bragging about how Ayden was the barbecue capital of the world. The menu is three lines long: 1) Sandwich. 2) Platter (small, medium, large). 3) By the pound. The platter was a paper tray heaped with chopped pork and a bit of uninspiring slaw, and laid over the top was a slab of what I would describe as corn brick.

But: That pork.

That Pork, 2008

That first bite might have been the most delicious thing I ever tasted, either before or since. Fatty, smoky, and strewn with crispy little bits of skin – the cracklins. It was so good, I washed it down with a sandwich.

My return to the Skylight thus had a lot to live up to. And, as such things often turn out, it didn’t live up. Don’t get me wrong, the pork was good, but I think that our 3pm arrival meant that we got stuff that’d been sitting under the heat lamp a bit too long. Also, they’d gone a bit light on the salt. By the end of my sandwich this time around, I had figured out the amount of vinegar and salt that needed to be added to each bite to make it great. And then: I tasted a piece of the pound I’d gotten to go, to bring back to my brother in Brooklyn. It was better, like it’d been picked from a non-dried-out part of the pork pile.

Skylight Inn, 2010

Looking back now, I really want to go back to Skylight. Like, right this instant.

June 17: Bum’s Restaurant, Ayden, NC

Bum’s, like Skylight Inn, has no website. That’s the first good sign.

After leaving the Skylight, we headed downtown (about eight blocks) to Bum’s, a joint we’d missed on our previous pass through Ayden. It was awesome. Unlike the Skylight, there were multiple steam tables of various down-home sides. We got a couple of barbecue sandwiches, along with some butter beans, collards, and beef stew to share. Everything was excellent. The pork was arguably, on that day, better than Skylight’s, and was even better when topped with the stagnant-water-colored sauce kept in a repurposed glass ketchup bottle on our table. I remember that the collards in particular were outstanding, with a great balance of vinegar tang, smoked porkiness, and bitter greeniness.

Bum's

Bum’s was a great way to wrap up the barbecue-fueled portion of our honeymoon adventure. Now I’m just looking for another excuse to get myself to the Carolinas. Or, at least, to find some decent pork here in NYC.

Making Userthemes work on WordPress 3.0

June 23, 2010 · 5 Replies

Some friends of mine (Joe Ugoretz and Jim Groom) were chatting on Twitter yesterday about how Userthemes, the WPMU/MS plugin they rely on to allow user customizations of copied system themes, had broken with WordPress 3.0. I decided to take a look at it. After digging a little, I found the immediate cause, as well as a workaround.

Please note that this workaround is very much a hack. It shouldn’t cause any security issues (see explanation below), but it will break the next time you upgrade WP.

Joe’s problem was that the plugin was only working for Super Admins. Administrators of single Sites could not copy new Userthemes, and they were redirected to the dreaded wp-admin/?c=1 when they tried to access the Edit Userthemes panel on the Dashboard. I figured it was a problem with permissions, and it was: all of those functions are triggered only for those users with the capability edit_themes, but for some reason only Super Admins, and not Administrators, were showing up as having that ability. (The weird thing – when I did a var_dump of WP Roles, I saw that Administrator *did* have edit_themes.) Maybe there’s some setting in WPMS that allows users to edit themes, but I couldn’t see it.

So the solution is to change the edit_themes check to something else. switch_themes seemed like an obvious choice to me, since anyone with the ability to switch themes on a given blog would also have had the ability to edit themes on that same blog. So there shouldn’t be a security problem – only blog admins should have the ability to make userthemes.

You’ll need to modify the plugin, as well as a few lines in the WordPress core.

Back up. I’m not responsible for anything that goes wrong!
Open the userthemes.php file. (I’d link to it, but I can’t find it anywhere on the web. When I’m at a better internet connection, maybe I’ll upload a version for you to edit. Maybe someone out there has a copy to share.) Search for all instances of ‘edit_themes’ and replace with ‘switch_themes’.
From your WP root directory, open wp-admin/theme-editor.php. On line 12, change ‘edit_themes’ to ‘switch_themes’.
From your WP root directory, open wp-admin/menu.php. On line 173, change ‘edit_themes’ to ‘switch_themes’.

This should restore the basic functionality of Userthemes (though Joe says that there’s still some bugginess – if you can’t access the Edit Userthemes from the main Dashboard page, try going to the Userthemes panel first). I must repeat that this is an ugly hack, and I’m hoping that someone smarter than me will step in and tell me why this is happening in the first place.

Honeymoon barbecue, part 1: the West

June 20, 2010 · 6 Replies

I got married a few weeks ago:

Afterwards I went on a honeymoon with my lovely bride through the southeastern US. Unlike a North Carolina vacation we took a few years ago, the focus of this trip was not barbecue. That said, we still had quite a few good barbecue meals. (I mean, it’d be a downright sin to go through North Carolina without stopping at some of the shacks.) Without any further ado, then, here is a retrospective of my wedding and honeymoon through the lens of smoked meats. Part 1, appearing here, deals with what I’ll call “the West” – or more specifically, barbecue in the style of the west-of-the-Appalachians, which dominated the first part of our trip. Part 2, “the East”, will come later in the week.

June 5, the wedding day: Dinosaur Bar B Que, Syracuse, NY

When Rebecca and I decided to tie the knot (and to celebrate with a real party instead of eloping), the first thing we decided was that we wanted to have extremely awesome food at the wedding reception. Since the in-laws live near Syracuse, the home of Dinosaur Bar B Que – a joint that we’ve enjoyed very much both in Syracuse and here in NYC – it seemed a perfect fit. Dinosaur brought out a smoker rig:

Smoker

The menu was ribs, pulled pork and chicken for the meats. For sides, we had baked beans, cole slaw, and macaroni salad. Unfortunately, I don’t have a lot of great pictures of the food – everyone seemed to be too anxious to eat it to be able to take good pictures, and I haven’t gotten the files from the photographer yet – but here are a few pictures I could scrounge up. My own take on Dinosaur, and this meal in particular, is that their ribs (the meaty St Louis cut) are really top-notch, the best I’ve had here in NYS. The sauce is a traditional KC-style tomato sauce. Dinosaur also provided a spicier sauce with a bit of mustardiness that went well with their unsauced pulled pork.

Dinosaur

I’ll leave it to some of my gentle readers who were in attendance to give more feedback on the quality of the food. IMO it was pretty effin good for wedding grub.

June 9: Ridgewood Barbecue, Bluff City, TN

We spent a few days in Washington, DC near the beginning of the honeymoon, and from there we traveled to eastern Tennessee and the foothills of the Smoky Mountains. Knowing we’d be traversing the whole diagonal of Virginia, I pinged my SW VA pal Jeremy for a recommendation. Before he had the time to respond, my research had led to the same recommendation that he ended up delivering: Ridgewood Barbecue, just inside of Tennessee. We knew we had entered the South when a fellow in the parking lot gave us the unsolicited advice to try the beef, even if we normally preferred pork barbecue.

Ridgewood

This is an appropriate place for me to step back and make some commentary on barbecue snobbishness. I grew up in northeastern Wisconsin, an area that might excel in venison summer sausage and fried cheese curds but has little in the way of local barbecue. As a result, I haven’t been raised with any deep prejudices about the nature of barbecue: that it must be pork, that it must be smoked over hickory, that it must not have tomato in the sauce, what have you. While I can’t out-and-out claim that I’m glad I grew up not eating barbecue, I can say that a pleasant side effect of my barbecueless youth is that I’m willing to take it on its own terms. (As an aside, I think I enjoy a similar position with respect to pizza, though living in Brooklyn for the better part of a decade has probably warped me a bit.) This is in stark contrast to other barbecue fanatics whose rantings I have so often come across on the web, whose hearts and hatches are closed to a large portion of the wonders that the world of smoked meats has to offer. I feel sad for them.

And I feel glad that I was able to take the gentleman’s advice seriously, and order both beef and pork barbecue sandwiches at the Ridgewood. That’s because, while the pork (unusual in that it’s sliced ham, rather than chopped or pulled shoulder) was really delicious, it was a bit overwhelmed by the amount and the character of the sauce on the sandwich. The sauce is a weird mix of a couple of different styles: far more tomatoey body and sweetness than a Carolina sauce, far more vinegary tang than a Western sauce. Really good, but too much for the relatively delicate pork. (Order it on the side, if you can.) The beef, however, was really something to behold. A huge beefiness and a punch of smoke flavor punched through the sauce. It was awesome. And the sides were pretty great too, especially the baked beans: with more onion and peppers than you expect in barbecue beans, these were possibly the best baked beans I ever had. Perfect balance of sweetness and spice. Worth the trip in themselves, really.

Ridgewood beef

The second clue that we were really in the South was when the waitress, without asking, brought enormous styrofoam cups of soda to the table as we were finishing our food – “refills to go”, she said. Wowza.

June 10: Bennett’s BBQ, Pigeon Forge, TN

As I said above, the honeymoon was not intended to focus on barbecue. If it had been, we wouldn’t have travelled to eastern TN, which is not to the best of my knowledge particularly well known for its barbecue. That said, we did drive past a number of places bragging about their ribs (pandering to northern tourists, maybe?), so we decided to succumb. A bit of research showed that Bennett’s was perhaps the most reliable in the area.

Rebecca got the baby-back rib meal, and I got a platter with brisket, pulled pork, and ribs. I was not expecting much from the mini-chain and its Applebeeesque decor, but I was pleasantly surprised. The St Louis ribs, which were sauced with a mercifully light hand, had enough meat on them to see (and taste!) the smoke ring. The pulled pork (again, unsauced – thank you!) was even better: after the initial sweetness of the pork fat, a very nice smokiness took over. And they weren’t stingy with the burnt ends (or outside brown, or whatever you want to call the brown stuff on the outside of the shoulder). You can see a strip of it in the picture below:

Bennett's

The brisket was disappointing, especially coming from the incredible beef experience we’d had the previous day at the Ridgewood. The fat was gristly, the meat was underseasoned, and there wasn’t much in the way of smoke flavor. As for sides: as at the Ridgewood, the standout was the dish of baked beans. The beans were very straightforward and traditional, but really nicely executed, with a bit of smoke, a bit of sweet, and beans that didn’t have the texture cooked out of them.

It’d be a few more days before we traversed the Great Smokies and managed another barbecue meal. But that’s a subject for another post.

New BuddyPress plugin: BP External Activity

May 25, 2010

On the CUNY Academic Commons we have a MediaWiki installation running parallel to our WordPress/BuddyPress installation. In the past I had hacked together an inelegant and constantly breaking solution for importing wiki edit notifications into the BP activity stream. I’ve just written a small plugin called BP External Activity which solves the problem by using the BP activity API and RSS.

The plugin can be used to pull items from any RSS feed and add them to your BP activity stream, with customizable text. It’s feature-light right now (and requires some hand-coding to work) but it’s still pretty much the coolest thing ever. I will update it to be better when I get around to it.

Get BP External Activity here.

BuddyPress plugins running on the CUNY Academic Commons

May 25, 2010 · 8 Replies

Cross-posted on the CUNY Academic Commons dev blog

A few people have asked recently for a list of the plugins installed on the CUNY Academic Commons. In the spirit of Joe’s post, here I thought I’d make it public. I’m going to limit myself to the BuddyPress plugins here, for the sake of simplicity. (I’d like to write a series of posts on the anatomy of the CUNY Academic Commons; maybe this will be the first in that series.) Here they are, in no particular order other than the order in which they appear on my plugin list.

BP TinyMCE. This plugin is messed up, and I have part of it switched off, but I still use the filters that allow additional tags through, in case people want to write some raw HTML in their forum posts, etc.
BP Groupblog. Allows blogs to be associated with groups, displaying posts on that group’s activity feed and automatically credentialing group members on the blog. I did some custom modifications to the way the plugin works so that clicking on the Blog tab in a group leads you to subdomain address rather than the Groupblog custom address (thereby also ensuring that visitors see the intended blog theme rather than the BP-ish theme).
BP MPO Activity Filter. This plugin works along with More Privacy Options to ensure that the new privacy settings are understood by Buddypress and that blog-related activity items are displayed to the appropriate people.
BuddyPress Group Documents. This one is crucial to our members, who often use the plugin to share collaborative docs.
BP Include Non-Member Comments makes sure that blog comments from non-members are included on the sitewide activity feed.
BP External Activity – an as-yet unreleased plugin I wrote that brings in items from an external RSS feed and adds them to the sitewide activity feed. We’re using it for MediaWiki edits.
BP Group Management lets admins add people to groups. Very handy for putting together a group quickly, without having to wait for invites.
BP System Report. We’re using this one to keep track of some data in our system and report it back to members and administrators.
BuddyPress Group Email Subscription allows users to subscribe to immediate or digest email notification of group activity. Right now we’re running it on a trial basis with a handful of members, in order to test it. (Here’s how to run it with a whitelist of users, if you want)
BuddyPress Terms of Service Agreement, another as-yet-unreleased plugin (this one by CAC Dev Team member Chris Stein) that requires new members to check TOS acceptance box before being allowed to register.
Custom Profile Filters for BuddyPress allows users to customize the way that their profile interests become links
Enhanced BuddyPress Widgets. Lets the admin decide the default state of BP widgets on the front page.
Forum Attachments for BuddyPress. Another of our most important BP plugins, this one allows users to share files via the group forums.
Group Forum Subscription for BuddyPress. This is our legacy email notification system, which is going to be in place until I get back from my honeymoon and can replace it 🙂
Invite Anyone lets our users invite new members to the community and makes it easier to populate groups.

Questions about any of these plugins or how they work with BuddyPress? Ask in the comments.

A distributed, multi-client courseware

May 23, 2010 · 4 Replies

At yesterday’s THATCamp I attended a session, facilitated by Steve Ramsay, entitled “All Courseware Sucks”. You can read the blog post that served as the inspiration for the session at the THATCamp blog. Steve started the session by framing the issue in a way that ended up being quite helpful: he had us list the features of courseware that we’d used, and then to talk about whether they were all crucial. The problem is that almost all of them were crucial to at least someone in the room. Moreover, some of the items that certain individuals found the most useful (say, a gradebook where students could track their progress) seemed the most expendable to others. Listening to that discussion, I thought to myself: This must be what happens in Blackboard focus groups. Gödel’s Second Theorem of LMSes: Any learning management system with a vocabulary rich enough to do interesting work can be shown to be bloatware.

If it’s not the functionality of courseware that we dislike, then, what is it? Well, the basic complaint seems to be that the interface is terrible. And not just terrible in an aesthetic way, though certainly most courseware is absolutely devoid of whimsy. The deeper problem is that software design decisions about how courseware conceives of a course – its hierarchy, its ontology, the vocabulary used to describe its objects, its workflow, its presentation – constrain the instructional design decisions that the professor can make about how the course will be taught.

How do you design a courseware interface that jibes with the aesthetic and instructional predilictions of instructors from math, biology, French Lit, and everywhere between? Answer: You don’t. There are dozens and dozens of well-developed, general purpose content management systems out there. Each has an interface that its users are comfortable with. Why not take advantage of this fact? If students sometimes prefer Blackboard because at least with Bb they know what they’re getting into, why not just let them use whatever they’re already comfortable with?

The idea in a nutshell: Abstract the content from the platform, so that individual students and professors can use whatever platform they’d like as an interface. Existing CMSes like Blackboard, Moodle, WordPress, Drupal, Joomla, and so forth become clients that sync with a central data repository hosted by the school or by a third party.

There are about a trillion details that need to be filled in to make this viable. But here’s a very rough-n-ready explanation of how it might work in a particular case. Let’s imagine that Jack is the professor, using Drupal as client software, and Sally is the student, using WordPress as her preferred client. Jack is going to assign a blog post, and Sally’s going to complete it.

Jack logs into his Drupal installation. This could be on his own server or on a centralized installation hosted by his school. On this installation there will be a module that creates a number of new content types in addition to the default Story and Page. Let’s imagine the content type is called Assignment, which contains fields for content, subject, due date, and whatever other metadata you might like.
Jack writes the assignment and saves it. It saves to the Drupal database as a native Drupal item.
After the save, a hook is triggered by a Bridge module. Bridges are client-specific translators that send and fetch information to and from the central repository. The Bridge module translates the Drupal content type into an XML or JSON document that is formatted according to the agreed-upon standard data format for Assignments.
The Bridge module sends the document to the central Server. The Server can be connected to the student information and registrar systems in much the way that Blackboard is. The Server recognizes Jack’s signature on the document, and furthermore knows that the file is associated with Jack’s particular course. The document is translated into a Server database object and saved, keyed by Jack’s user id, the course id, etc. The Server could be set up to send out email notifications to students at this time, alerting them of a new assignment.
The next time Sally logs into her WordPress installation, her WP Bridge plugin (another piece of translating software, this one WP-specific) pings the Server. The Server knows that Sally is in Jack’s class, so it looks through the database to see if any new assignments have been posted in that class since Sally last logged in. It finds the blog assignment that Jack posted, translates it to a JSON or XML doc, and sends it to Sally’s WordPress installation. The Bridge then parses the document and saves it as a WordPress-native item in the database of Sally’s WordPress installation, perhaps as an instance of a custom post type or something like that.
Sally visits the course page in her WP installation. This could be an admin panel on the Dashboard, or a front-end page. It shows the new assignment, to write a new blog post.
Sally writes a new blog post using the native blog functionality of WP (different content types that aren’t so WP-friendly would need a bit of interface or theme work. Discussion forums, for instance, could easily be stored as custom post types and skinned to look like a traditional forum thread). She might indicate, using a certain tag or category or postmeta checkbox, that this blog post belongs to a particular class, or is a response to a particular assignment. The post is saved to the WP database, and, as above, the Bridge plugin then kicks in, translates the post, and sends it back to the Server, where the process will repeat the next time that Jack logs into his installation.

As I’m writing this, I realize that it seems really simple and obvious, and I’m sure that there are a hundred reasons why something like this would be hard to actually implement. But it’s worth exploration, as this model enjoys the huge advantage of letting the user choose whichever of a number of interfaces suits their fancy.

A few complications to mull over, off the top of my head:

Certain content is likely not to translate very well between platforms, especially content whose visual presentation is central to its effect. In those instances, the content could be rendered using the client software of the author and linked to in addition to/instead of being transcoded.
File storage. Where do you store images, zip files, etc? On the author’s client installation, on the Server, or both?
Security. How do you ensure that only Jack is able to download assignments for his course? What prot

The meat of Facebook

May 16, 2010 · 4 Replies

danah boyd wrote a blog post arguing that Facebook ought to be regulated like a utility. What exactly it means to be a utility, and why utilities ought to be regulated in general, is not the main focus of her piece, and she adds in an addendum that the issue is not so much that FB is a utility as that it is trying to be one. But, in any case, I want to push against the utility analogy with one of my own.

I take it that the reason why utilities ought to be regulated is that they are monopolies, and in a single-provider market, people can’t realistically use the threat of leaving for a competitor as leverage for bargaining with the monopolistic company. To claim this is the case for Facebook is surely an overstatement: people can and do opt out of using Facebook, and certainly there are enough other social options out there to block the analogy between them and “people who are building cabins in the woods” (an analogy suggested by boyd). Even if Facebook is dominant, it’s not a monopoly in the way that utility companies are, so the same arguments for regulation don’t really work.

The government sees fit to regulate in other sorts of cases, though. Take the meat industry. The government regulates certain aspects of the meat industry (however lax or ill-conceived USDA oversight might be). The justification here is not that the meat industry is monopolistic (though I’m sure it is mostly controlled by a couple conglomerates, and insofar as this is true it should be additionally regulated as a monopoly). Instead, the justification seems to be: 1) this kind of industry has the potential to do great harm if left to its own devices (E. coli and stuff like that), and 2) it is unlikely that many (or any) consumers of this industry’s goods are in a position to verify independently the claims of the industry (not many have access to labs where they can test for bacteria, etc). The government is justified in protecting its citizens at their most vulnerable (you might even say this is the primary reason for government). So they’re justified in regulating the meat industry.

The case of Facebook is parallel. 1) Because people keep a lot of their most important stuff in Facebook, a large amount of harm could be done if Zuck decided to start selling it to advertisers or something more nefarious still. 2) It’s difficult, if not impossible, for most people to verify the claims of FB with respect to how FB claims to store and use data. For one thing, the “privacy” settings are arcane to the point of incomprehensibility. And even if you figure out the settings, without access to FB’s software and servers, you can’t really know whether they’re living up to their word. Thus, government regulation might be justified.

Someone needs to write The Jungle, Part II: Zuckerpunched.

New BuddyPress plugin: BuddyPress Group Email Subscription

May 12, 2010 · 1 Reply

Email Options on settings page

I’m quite happy to announce the release of a more-or-less stable (we hope!) version of BuddyPress Group Email Subscription, a BuddyPress plugin that allows for fine-grained, user-controllable email subscription to group content in BuddyPress.

This plugin is different from some of my others in that it was truly a group endeavor. The base of the plugin was written by David Cartwright, with a little bit of code from me. A nearly complete rewrite of the front-end and most of the guts of the plugin was undertaken by Deryk Wenaus. I wrote the daily and weekly digest functionality, along with some of the settings pages and various bugfixes throughout. The current codebase of the plugin is probably 60% Deryk, 30% me, and 10% David.

It was my first time working on a truly collaborative software development project like this, and it was a real pleasure working with both of these gentlemen. Thanks, guys.

Get BuddyPress Group Email Subscription here.

Teleogistic

Which is not to say that ‘logistics’ is the ‘telos’