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.

Google Speedreader

I’m an avid skimmer of Google Reader. On most days, I periodically login and use quick keys to flip through 100 or so items. I might read one or two of them, start another few items, publish one or two as shared items. The key is to use it as productive digression, not to get bogged down with it as an obligation or labor-intensive duty. When I miss a day or find the feeds creating an insurmountable backlog, it’s easy enough to mark all as read.

This morning I noticed Google Reader’s down-counting ticker kept hitching–stopping on a number and no longer counting down, no matter how many times I pressed ‘N’ext. For months I’ve had Helvetireader working through Greasemonkey in Firefox; figured that must be it. But even after I deactivated Greasemonkey, the ticker continued to act up, firing only for the first few items and then sticking. The ticker would stop on a number (e.g., 80), and the fed RSS items would continue skipping down the page, many of them reruns. The service wasn’t broken, exactly. But it was (and remains) up on the blocks. Somebody is tinkering with it.

I caught a few clues on Twitter during the day (Thurs., a day I usually spend at home, half fathering, half professing) speculating about whether Google had activated Pubsubhubbub, a nearer to real-time relay process for RSS deliveries. Then, a few minutes ago, both in Google Reader and via Will Richardson’s Twitter stream, I saw this entry from The Next Web, “Has Google Reader Just Gone Real Time?” Possibly: Google is adjusting Reader so it will turn around RSS-fed content momentarily. Until now, Google Reader-fed material was delayed, arriving anywhere from 30-90 minutes after the content was first published. Google’s demure response (cited in The Next Web piece) is unsurprising in light of reactions to Google Buzz. But an upgrade to Google Reader that nudges it toward the ever-unfolding now is an intriguing, promising development, nevertheless. Moving Reader toward the now may dislodge assumptions about its readerly orientation and help us come to terms with it differently as a writerly/receivable mechanism–a platform for collaborative filtering (like Delicious networks) and threaded conversational annotation (both of which take GR well beyond a flat consumption practice). I’m encouraged to see some new energy routed Google Reader’s way. In fact, while it’s much too early for me to be decided about Google Buzz, if it makes any appreciable impact on Google Reader, all the better.


I was at the front of the room–staring into the light from the projector
bulb–for most of this morning’s Writing Program TA orientation session on Quick
& Dirty Research.  What put the Q&D in today’s talk?  Aggregation and
RSS.  Everyone going along with it now has a fresh-fed Bloglines account
and 67 subscriptions.  For more, here’s
and the

accompanying screencast
.  I welcome any suggestions; the screencast is
a bit rough in spots (and longer than I’d like).

Basically, the talk hinged on these few thoughts:

  • Aggregation as Q&D (not slow and clean) is applicable for students
    working on projects and also for your work as a teacher, writer, scholar and
  • It leads with questions about the inventive and generative activity rather
    beginning with a hierarchy predicated upon licensed sources (credible if it’s from the library only, myth debunked).
  • It dislodges the material orthodoxy in composition (what materials are
    appropriate for composition, what counts as writing…it’s unbothered by
    intermittent junkiness in feeds).
  • It exonerates us from narrow or unnecessarily constrained reading habits. 
    Qualification: this isn’t meant to disparage book-reading.
  • It productively complicates (or steadies, if you’re into efficiencies) our
    information ecologies and personal knowledge management systems.

Continue reading →

Palm Caked Hard

Quick and Dirty research (really just wanted to see Q in drop caps).  I
accepted an invitation to participate in (talk/click)-ing through a few minutes
of a session for incoming TA’s on Q&D.  A few others will give brief
pitches, too, so I can’t hog the floor (not that I would).  Thinking for
now that I’ll emphasize the D–dirty, as in the perpetual grubbing aligned with
aggregation and a few other must-use sites.  The ‘Dirty’ in research not
only identifies with the hands-dirty dig-dump-sift set of metaphors, as was so
eloquently introduced to me by a memorable professor at my MA alma mater what,
six years ago; it also drops the point of a spade into composition’s material
orthodoxy.  Unsifted presumptions about the material suited to composition
research preserves the orthodoxy (straight phenomenological knowing), avoiding
the deep down griminess, and instead digging materials delicately, troweling
with too much propriety.  Worry-free and proven: Spray-n-Wash. Library
databases: Quick and Clean research–different work involved in plucking a
clean-authorized article (scrubbed by peer review), patching it into an essay.  

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>