In Dribs and Drabs

And the old blog gets another new entry. It runs, though much is stuck. Garage floor rag for gas cap, as if there was fuel to from sloshing. Comments work, somewhere under the hood chewing and taking one helluva long time to post. Human-check captcha device broke, left behind versions ago. Latest comments widget broken. On this day, broken. Wordcount javascript whatever that was, broken. These among the irreparable few. And the last touch to get things going again involved replacing the script-assigned permissions upon publishing, for folders dropping 0777 to 0775 and for files flipping from 0666 to 0664. Eleven replacements and file overwrites in all so that host and republished entries and archives were harmonious again. It’s not sustainable, or rather, not long-sustainable. Sustainable only ever meant for-now-sustainable, anyway.

Last entry made it to IFTT->Twitter. But atom/RSS never seems to have fired, even though XML structure should be hospitable. As such, this amounts to another turn of the key, making sure exhaust reaches exhaust pipe for predictablish circulation.


An old blog breaks down. Stops working. Fails to grant access to even the control panel, not that anyone remembers the username and pissword, anyway. There’s bondo in the basement, duct tape in a kitchen junk drawer (no, the other junk drawer; the junkier drunk drawer). And then there’s some crappy old untended website with versions galore of Movable Type. Yeah, that same Movable Type from over a decade ago. It’s still wheezing around on the internet. Right here! Version 5.2.13. I had to delete a bunch of tags to get it running. Much of it probably doesn’t work. Comments? They probably return errors. When a blog is rattling around with fewer effs to give than ever before, well, whatever there is, work with it. It was always enough before. Why not now?

And if this shows up online? Breaktest passed.

Coding the UWC

I’m not the nimblest programmer, and because I can count my successes with PHP on one hand, I feel compelled to document them, to extend and preserve them through self-congratulatory accounts like this one.

I am working this semester as a faculty consultant to the University Writing Center. I probably mentioned that before. Basically, my charge is to get online consulting systems up and running at EMU, provide a few months of support and training, and spread the word. The main piece here is asynchronous consulting via email. Much like what we built at Syracuse, this process relies on a form. The student fills it out, uploads an attachment, submits it. The submission calls a PHP script, which in turn displays a You did it! message, a readout of the form data fed to the screen (for saving, for verification), and an email message that routes the form data and the attachment to a listserv. The listserv consists of a handful of subscribers who will comment and send back the uploadeds in turn, in time.

The system works reasonably well, but managing the queue can become a headache. Whose turn is it? At Syracuse, the queue was filled in with four or five rotations, and then as form-fed drafts arrived, consultants would access a shared Google Spreadsheet and manually enter a few vital details: name, email address, time received, time returned, and turnaround (time returned minus time received). These few crumbs of data were helpful, but many of the trackable-sortable pieces of the form were not otherwise captured systematically.

Until Zend Gdata. With this installed, it’s now possible to run a second PHP process that will push all of the form data into a shared Google Spreadsheet automatically. I puzzled over this on Friday, figured it out on Saturday. My initial stumble was that I was trying to integrate the new PHP code into the script that turned out the email and screen readout. Didn’t work. But then I figured out that I could instead route the form to a relay file (I doubt this is what programmers would call it, but I don’t have the vocabulary to name it anything else). The relay file was something like simple.php.

Simple.php is a script with a couple of lines: include formemail.php and include formtospreadsheet.php. Now, when the form gets submitted, both scripts run. The email routes the document like it should, and the Google Spreadsheet (queue) grabs a new line of data. The only element requiring manual entry is the time the consultant returned the commented draft. The shared spreadsheet does everything else: calls the list of consultant names from another page, calculates the turnaround, and records a comprehensive record of who is using the service, the classes they come from, etc. Over time, the comprehensive record will allow us to sort by different classes, different faculty, different colleges, which will help us identify patterns that might prove insightful for how writing is assigned and taught across the curriculum.

I should add that our recent launch of the service limits it to four targeted programs. This is necessary because we are not currently staffed to handle a deluge of submissions, and while we do want the service to get solidly off the ground this semester, we want foremost to extend it to a segment of the 17,000 students who are enrolled in some sort of online class.


We’re experimenting in the WC this semester with consultation by
discontinuous email
. Students can upload up to five pages of whatever they
are working on, the draft then zigs and zags (taking two lefts and then a
right?) through the internet to a listserv account where five always-on
consultants take turns commenting and returning drafts, usually within 24 hours
after the draft is sent. The system seemed to be working fine until recently
when we realized a flaw in the design of the upload form. Basically, the
form allows students to 1.) upload a file or 2.) copy and paste a chunk of text
into the form. ‘Submit’ The form then calls up a PHP script, which, when
there is an uploaded file, puts the file in a temporary directory, builds the
email message to the listserv, attaches the file, sends the email to the
listserv, and finally clears the file from the temporary directory. That much
seemed to be working fine for, oh, ten weeks, and we have 45 such consultations
to show for it. But:

Continue reading →

Et Alia

Several days immersed in lines upon lines of works cited entries may
cause you to wonder at some of the lesser noticed codes that rustle around at
the ends of scholarly articles. A paradox of citation is that the works
cited–a roster of references–flattens out the dimension of each
reference and orders the list arbitrarily according to the alphabet while also
downplaying a surprisingly uneven terrain of mismatched details more pocked than the
face of the moon. This contradiction is forcing me into decisions I hadn’t
expected to be so difficult.

The et al. is one example. It allows the keeper of the works to abbreviate,
to shorten a list of authors so that any source with more than three authors can
be listed alphabetically by the last name of the lead author followed by et al.
It is a note of inclusive omission. And I suppose it made greater sense in an era
when works citeds, rife with formulaic peculiarity, were typed on a typewriter.
The et al. conserves characters; it shortens the list of names, leaving off
everyone but the primary author. It is no coincidence that et al. rhymes with economic al. So what is the big deal?

Continue reading →

Trouble Shot

Even if the following fixes are only useful to one or two people, posting
them to the blog makes them differently available for searching and bookmarking.
Since I installed MT3.34, I ran across a couple of small snags. Nothing
too off-putting, really. Just bumps along the up-gradual way.

First, the new tagging features in MT3.3+ are, as I’ve said before, really
slick. But I was having trouble with the interface that allows me to merge
tags. Say I have two tags I want to merge, like "method" and "methods."
Okay? I click on one or the other and I the tag becomes editable. After I
apply changes, I can select "Rename," in which case it will summon the database
to see if the new tag already exists. If it does exist, a java popup asks
whether I want to proceed with the merge. If the revised tag doesn’t
exist, it goes ahead and applies the change. The other option, "cancel,"
does just that. Simple, eh?

Continue reading →

Up- or Down- A Grade is a Slope

It was upgrade weekend for the blog, meaning I had my eyes turned under the
hood and my fingers in the blog code Friday into Saturday (today, all reading,
responding, and figuring grades).

I was running MT3.2, growing every day more envious of those who were putting
to use the tagging features built into 3.3+. The upgrade was a cinch.
Just FTPed the files into place and logged in. The config file didn’t need
any changes. Well, it didn’t require any changes, that is, until I also
converted the database from MySQL4 to MySQL5. For that, I had to add a
DBSocket line to the config file. I had not a clue about it at the time,
but the support folks at are remarkably good.

That’s a hearty new cumulus tagcloud over at the left. There’s a lot to
be said for MT’s tagging features built into the latest versions. Now I can merge
tags across the entire weblog, sort by tags (for editing or adding new companion
tags), and grade the tags with a max="x" setting. That’s the statement I use
to come up with ten levels for the tag cloud. And I’ve set the CSS to
display:none for the bottom five (#6-10). That way only the top five levels show
up, and the cloud isn’t the size of Lake Michigan.

Continue reading →


I’m mucking around all morning with MT RSS tags.  I was using a chunk of
javascript to pull in delicious bookmarks before, but I wanted a bit more
flexibility. Figured MT RSS would deliver. So I read around the net–mostly old
entries from the 2.+ days–and came up with a few plugins I thought would do the
trick: MT RSS and MT List.  Quasi-teaching-aims motivating me; been
plugging away at a syllabus, rest of the pre-term drill. It’s a course in
critical research; we’re going to aggregate like mad.

Now the plugins are running fine.  Together, they pull the feeds through
a db cache on my server so as not to drain the site of origin site with each
visit to EWM. But I can’t figure out how to grab the date tag from the XML. 
The dates are nested in Dublin Core tags.  I can’t figure out how to tell
the plugin to draw the date into the entry you see here (lower right). So I’m
stuck.  Gonna quit before I overheat (or make this brand new nagging cold/s.throat worse).  Here’s the code, culprit in
bold, just for the helluvit:

 <MTList name="feeds">
<MTListLoop name="feeds">
<div class="sidetitle"><a href="<$MTRSSFeedLink$>" target="blank"><$MTRSSFeedTitle$></a></div>
<div class="squish" align="center">Reassembled <lastBuildDate><$MTDate
format="%B %d, %Y %I:%M %p"$></lastBuildDate><br/></div>
<ul><MTRSSFeedItems lastn="7">
<li><$MTRSSFeedItemElement name="date"$>: <a href="<$MTRSSFeedItemLink$>"
target="blank"><MTFirstNWords n="4"><$MTRSSFeedItemTitle$></MTFirstNWords></a>:
<MTFirstNWords n="7"…><MTRSSFeedItemDescription></MTFirstNWords></li>