The Guardian of Aloons - 3

My #fridayflash entry is now available, a weekly fictional webserial set in the world of Ghyll:

The Guardian of Aloons - 3:
There I was, buried under the burning beams, notebooks, and bird carcasses of my destroyed office, sleeping it off like a building’s beating was just another day. When I awoke, I found that someone had pulled me from the rubble and laid me on the street out front. I sat up coughing and marveled at how the last five years of my working life could so tidily be reduced to a smoldering mound of ash. A few pachyderms, called in from the nearby city, were spraying water on the remains.

Read the rest and rip it apart, fiends.

The Clock Without a Face

A real-life treasure hunt takes off:

That’s right; throughout this fine land, twelve handcrafted, one-of-a-kind, gem-encrusted numbers lie buried in the soil. If you can find them, they’re yours to keep. But where are they? The only path lies in solving the riddles in McSweeney’s newest title, "The Clock Without a Face." Get a head start on the hunt.

Not every hunter is making the journey to find treasure. Some seem content to strenuously debate the book’s riddles on the Internet, never leaving the comfort of their armchairs. Kevin Hemenway, a.k.a. Morbus Iff, set up an extensive wiki dedicated to a chapter-by-chapter analysis of possible clues. Iff declined a phone interview -- "I’m not a big fan of the human voice ;)" -- but wrote in an email that he has no plans to go on a dig personally. "I don’t travel much," he said. "I’m in it just to puzzle solve, and tell other people where they might dig."

The Guardian of Aloons - 2


The Guardian of Aloons - 2:
I laid on the soft earth behind my office for a few seconds trying to grasp what was going on. Hastily penned and blown-out notes in my left hand, a smoking bird’s leg in my right, my naked legs and scrunched undergarments a wee bit lower, and ol’ cranky Gurptshonis standing over me with flames and smoke blocking out the sky behind her head. I will admit that this image haunted my dreams for weeks to come.

Read the rest and rip it apart, fiends.

The Guardian of Aloons - 1

My #fridayflash debut is now available, a weekly fictional webserial set in the world of Ghyll:

The Guardian of Aloons - 1:
When I came to, I was kissing the gravel. She was gone. I tried to raise myself up, and that’s when I noticed a few of the rarer things in life: getting clocked by a six-inch heel feels much like a jab from a two-bit thug, and this was the third time my pants were missing. You’d think that I’d be getting used it by now. The beatings, not the pants.

Read the rest and rip it apart, fiends.


To sequel some of my other "soul-searching" posts (a series which really needs to end), I'm starting to think that having my "own" wiki is a good idea. I don't mean a mindmapping application like DEVONthink, which seems to trade "information overload" with "UI overload" but, rather, just a "collection" of "finished" data. I'm familiar with running my own wikis, my first being the interactive hypertext of Ghyll back in 2004. Since then I've started about five or six other wikis, only two of which actually became public. That's far too many wikis, and the cause is evident from my earlier writings:


[Wikis don't] require six months of planning for the next "feature" or the next "version" - it just requires little trickles, each week, applying continuous torture to the rocks that line its shores. You never notice a rock being rounded - you only appreciate the patience it took to get there. I'd much rather be trickling at creation than treading water with maintenance.

The above mentality left me with lots of little wikis sprinkled all over my hard drive, all nicely done but all devoid of a respectable amount of content. I tried to make them "sites" versus "collections", a distinction which sbp recently highlighted in "Organizing Hypertexts":

A site is something which is organised to be a collection of strongly related material. I have sites, for example, about Strange Lights, Samuel Taylor Coleridge, and Emily Dickinson. A collection on the other hand is a heterogenous assortment of materials, such as a weblog.

The article, still a draft at this time, is nicely done. Funnily, I hadn't known about it before a conversation between sbp and I last night, in which the lamentations of the haters of technology concluded that I should merge all my efforts into a single wiki all about "me", called initially "The Morbipedia" and then finally "Disobiki". Naturally, I couldn't make it that "easy", and I spent a fair amount of time complaining about all the "problems" inherent in such a plan. This post is primarily to recognize them for historical effect.

Audience vs. Self

This is primarily a distilled version of the "project" problem: it seems that I require "proof" that I put forth effort into something (I find myself consciously NOT playing a game that does NOT have achievements) and this effort then needs to have an "audience" of some sort. This seems to be the root of why I try to make things "projects": a single site or section containing all the effort I put forth into one particular subject matter increases the chances of gathering a like-minded audience, which then "rewards" the effort I'm putting forth. Again, this has gotten me to where I am today (which is a good place), but I think it's actively harming the modern day Morbus in the modern day Internet.

Unbeknownst to me, sbp addresses this in his "Organizing Hypertexts":

The main problem with my articles is that I used to keep coming up with new sites, but the sites didn't last as long as the content. Instead of thinking about sites, it would be better to think about the enthusiasms themselves ... When you find an interesting weblog entry, do you often browse the directory index? In practice, when I find something it's usually because I'm interested in that specific thing, and only very rarely do I want to see other things written by the same author ... Rather than indices, then, one should strive if possible to follow the Wikipedia method of indexing. We should simply weave together the content as closely as possible.

I can't speak for anyone else, but the only sites I visit every day are services (Facebook, Twitter, etc.) - there's no one community, no one subject matter expert, that is visited more than once a week. When I find a result in a search, I bookmark the result for reading later, but rarely do I have any dedication to the parent site or author. One might occasionally get added to my feed reader, but there it loses all identity and becomes just another bit of scannable content.

I need to recognize that my enthusiasms are wide, varied, and too time-consuming for me to be an expert in any of them. Only boring people or specialized experts should be making new site subjects nowadays. Everyone else should be making collections of who they are and entwining their fascinations together, instead of forcing them alone into a corner.

Moments Vs. Revisions

If a weblog is a collection, then why should one need a wiki? I see the difference as moments vs. revisions: weblogs are not structured or finessed data but, rather, moments of raw time, emotion, and thought. Most folks treat their blog as a journal or diary, never revising previous entries (though occasionally ripping out pages). Wikis are all about revisions: write fast, edit often, and let time improve the coherence, all metrics which tend to encourage wikis to be about transferring facts. As a researcher and obsessive about his hobbies, with a compulsive desire to organize and learn everything there is to know, I've created wiki "sites" in the past, but I need instead to focus on a wiki "collection": letting all of "me" and my data swim in the same soup. I'm just interested in too many things to have a site for each of them. I don't have a room in my house for each interest, and every few years, the shelves and nooks of my office are reorganized with the latest lovey lovey kiss kiss. The front page of a wiki collection can function the same way.

In the initial draft of this post, this was labeled "Creativity Vs. Data", but I've used wikis in the past for creative writing and world building: the retention of previous revisions and ease of diffing, and the ability to quickly link things together, is important to how I tend to work. Most wikis allow you to link to things that don't exist and, more importantly, see all the other pages that link to that non-existence. That's a nice feature when it comes to linking plot lines together, remembering where you last mentioned "the crazy old lady", and so forth: it allows mind mapping without the interruption of the current thought.

Technology Vs. Soup

I'm (or was) a Drupal rockstar, so it seems obvious that I would use Drupal for this mind dump of my interests. With Drupal 7's built-in Field API, I can strictly define fields for all the content types I'd ever need (pulps, trading cards, films, comics, books, characters, etc.), and then enable revisions on them. I can define custom sidebars based on what you're looking at, code my own views and custom functionality, and use any of a zillion modules to make things awesome!

Or not: it all seems like too much work, and the argument becomes: should I use technology to tightly define what I'm doing (where the smallest bit of data becomes a single column in a massive relational database) or should I swim in the primordial soup, where all the data is in a single column, and what it means, how it's searched, and how it looks is handled as loosely as possible?

I don't have a clean answer for this, save that a wiki "feels" better than Drupal. Both Drupal and MediaWiki share the same feature set at a basic level: whereas Drupal defines database columns for new fields, MediaWiki "fields" can be defined as parameters in the Template: namespace. This same namespace handles the display of these parameters, just like Drupal's node--CONTENT_TYPE.tpl.php. MediaWiki Templates also double as a rough equivalent to Drupal's blocks. For all the complexity and power of Drupal's third party Views module, there's MediaWiki's third party DynamicPageList extension. In both apps, you can define what blocks or templates appear on a page. Fundamentally, they both can do the same things, but MediaWiki seems "looser": unless you install an extension, everything worth doing is done via a single textarea. This both reduces (no need to edit external theme files, no tabbing between multiple fields) and increases (crazy ass Template syntax, small differences in formatting) its complexity.

If MediaWiki is loosely coupled, then Drupal must be tightly coupled. This means that software or API changes create a barrier to maintenance: every Drupal upgrade I've ever performed (from version 4.5 onward) required revised or new custom code, and I often had to wait on third party maintainers to upgrade. Every MediaWiki upgrade I've ever performed (from 1.2) has taken fifteen minutes and no code changes. Since all the data is in a single unstructured bucket, there's not a lot that can harm it.

I'm not hating on Drupal: I still code with it every day, and it's still my tool of choice for applications that require custom functionality or perform more on a "service" level. For my raw data needs, for when I'm building a resource where appearance or permissions isn't an issue, MediaWiki seems stronger, faster, and more collaborative.

The Gameplan

The end result is that I think a personal wiki is a way forward for me. It solves my obsessive need to organize and notate my hobbies, satisfies a general desire to share my random effort publicly, and is loose enough that it doesn't seem overbearing or like "work". It is, in essence, a modern day version of my detergent directory which, as far back as 1997, was my collection of "experiments", "unknown ideas", and "one shots", before changing to just a file listing in late 2002.

I'll probably merge all the existing Detergent stuff into this new wiki, along with Video Underbelly and the other unpublished wikis on my drive. I think the greatest aspect is that there's no longer anything for me to "prove", which'll probably mean the wiki will end up being a great mass of chaos with barely a hint of quality. You know, like the Internet.


Drupal 7: Assigning vocabularies with Field API

This took me far too long to figure out, but here's how you create a vocabulary, and then a taxonomy field and instance, all through an .install file (or anywhere else you really care to put it). Took a bunch of debugging before I hit on the right magical combination. This is part of a demo I'm working on for the Drupal 7 and FRBR mental model I published last night.

  $libdb_vocabulary_endeavorers = (object) array(
    'name'          => 'Endeavorers',
    'machine_name'  => 'libdb_endeavorers',
    'description'   => t('FRBR Group 2 entities: Persons and Corporate Bodies.'),
    'help'          => t('Enter a comma-separated list of persons or corporations.'),

  $vocabularies = taxonomy_vocabulary_get_names();

  $libdb_m_group2_field = array(
    'field_name'  => 'libdb_m_authors',
    'type'        => 'taxonomy_term',
    'settings' => array(
      'allowed_values' => array(
          'vid'     => $vocabularies['libdb_endeavorers']->vid,
          'parent'  => 0,
  $libdb_m_group2_instance = array(
    'field_name'  => 'libdb_m_authors',
    'object_type' => 'node',
    'label'       => 'Authors',
    'bundle'      => 'libdb_book',
    'required'    => TRUE,
    'description' => t('Enter a comma-separated list of persons or corporations.'),
    'widget' => array(
      'type' => 'taxonomy_autocomplete',


Drupal 7 and FRBR: A Mental Model

I have long been interested in librarian technology and cataloguing, even though I'm far from any sort of expert in the matter. When I started my "real" research into the subject, I jumped on the Functional Requirements for Bibliographic Records (FRBR) bandwagon, as it was a "new" and "great" leap forward in regards to describing and cataloguing the work that makes up a creative effort. Back in 2004, I started coding a Perl implementation of FRBR entitled LibDB, then eventually moved it to a (now unpublished) Drupal module and wrote up a relational database schema for it. The relational schema was the only decent output of both attempts, and it still lives on in the Drupal code repository. But, as things go, the attempt died, though I never stopped thinking about it.

General discontent with much-loved Delicious Library kept the desire to roll-my-own, but the time never arrived, nor do I see it coming anytime soon. After being extolled the wonders of CouchDB in 2009, I figured my first experiment should be with FRBR, and I even started a thread on the mailing list about it. General "eh"-ness with CouchDB, however, had me moving on before anything progressed.

Drupal 7 is "nearing" release and I'm once again thinking about FRBR. 7 now has the ability to add custom fields to its content types, functionality that previously required the contributed module CCK. While CCK, as a framework, had tons of additional third-party modules that mocked up different types of fields, Drupal 7 doesn't, solely because it isn't in the wild yet. I don't consider this bad news, really, because I've always been of the opinion that most of the contributed modules available to Drupal are crap. They scratch itches, certainly, but very few of them are what I'd consider quality productions. So, for me, thinking about Drupal 7 and FRBR is thus constrained to "core" and "my own custom code". Primarily, I'm interested to see just how much of FRBR could be modeled without custom code at all, so I've made some odd decisions to accentuate this. One could even accuse me of "just" making a boring old cataloguing system: regardless, I'm doing it with FRBR's model fully in mind.

The following serves mostly to jot down my notes and experiments.

Group 1 Entities

Like many who sit down to work with FRBR, one of the biggest stumbling blocks is exactly how to define the Work and Expression entities (the WE of WEMI). For my purposes, I'd only focus on Manifestations and Items (the MI of WEMI). You can always tack on WE on top of MI, but you could never implement FRBR without MI. As smallest building blocks go, MI is the place to start.

This leads to the first odd decision I've been leaning toward: Manifestations would be a Drupal content type, but Items would not. To back up even further, there'd be no single content type called Manifestation: instead, I'd implement a content type for Books, another content type for Movies, and so forth. This saves me from complicating the UI with an extra step and extra code: a single Manifestation content type with selectable sub-types would involve complicated form and UI custom code to pull off effectively. Individual content types allow me to define (and share, as necessary) Drupal 7 fields specific to the Book or Movie without custom code based on sub-type selection.

Each of these content types would be a form of Manifestation (an Album manifestation, a Comic Book manifestation, etc.). According to WEMI, the form of these creative endeavors is specified in the Work entity. Since I'm not modeling WE, putting them in Manifestation is good enough - if WE is ever added, the Work would happily inherit the type from M (since a W book could only contain Es, Ms, and Is that were also books, implied or otherwise).

Back to Items. One of the CCK field types that did not make it into Drupal 7 core was node reference: a field to relate the current node to another existing node. Its absence makes some sense from a usability level, as there's never been a clean solution to creating a new node within a reference field itself. Say you create a Book node, and one of the node reference fields is labeled "Author". You dutifully type in "Stephen King", but since you've never defined the Stephen King node previously, it just won't work - you'd be forced to stop what you actually wanted to do and go create "Stephen King" first. There have been a few attempts in CCK-land to solve this problem, but none that are entirely elegant or perfect enough for core.

So, for Items, I can't think of any other way than custom code: a simple relational table keyed to user ID and node ID, with a few fields for location, condition, and notes. There might be an "Add an Item" section on the Manifestation's view page (or even as a second form after the initial node submit), but even this isn't a huge requirement for a first version, since one could assume that if you're adding a Manifestation to your collection, that you also have custodianship over a matching Item. Either way, I don't see the necessary custom code as being anything but rote. I am sure, though willing to be convinced otherwise, that Items should not be nodes: I can't find any compelling use for a node's feature set, and I'd be aghast at 100,000 teenage girls creating 125,000 nodes detailing Twilight Book 1's location on their Favorite Books shelf (with some divining their autographed versions too). Similarly, in a single-user environment, the mental hurdles a non-librarian would have to leap through to justify two nodes for "the single book I bought today" is not cleanly solvable without more custom code than the non-node alternative.

Group 2 Entities

FRBR encourages relationships between entities: if there's a relationship called "Author", then a "Person" is related to a "Book" with relationship type "Author". This allows an unlimited number of relationship types to be created, but also allows relationships to tie any entity to any other entity: this "Work" is related to another "Work" with relationship type "Sequel", this "Corporate Body" is related to this "Expression" with relationship type "Special Effects", and so forth. Drupal 7 has no relationship API built in, so to accomplish the above generic relations, we'd need custom code.

In striving to satisfy the "as much as core as possible" mentality, the Person and Corporate Body of FRBR become another odd decision. For the same reason as Items, Persons and Corporate Bodies aren't nodes either: this time, they're taxonomy terms in a single vocabulary. I have no qualms about this: I am interested in endeavors, not the endeavorers. I have no intention of blurbing each particular entity, or defining their birthdate or address or website, or any such. In Drupal 7, being a taxonomy term doesn't preclude this if someone else wanted to do it (and FRBR does define fields for each of these entities, so it wouldn't be unheard of).

There are two important changes to taxonomies in Drupal 7: one, terms can be modified with fields just like content types (you could add a radio for Person or Corporate Body, a text field for birthdate or website, etc.) and two, a single vocabulary can be applied to the same content type as many times as you deem necessary. This allows us to fake up a hardcoded relationship system.

My mental model asserts a single vocabulary called "Endeavorers" (which sorely needs a better name; "Responsibility" sucks too) which contains terms for both Persons and Corporate Bodies. If distinguishing between the two is a must, we could define and maintain the radio field suggested above. This "Endeavorers" vocabulary is then associated as many times as necessary with a particular content type: once each for "Author", "Illustrator", "Editor", and "Publisher" for Books, once each for "Director", "Producer", "Distributor" for Movies, and so forth. Each field would be an "unlimited" "autocomplete term widget (tagging)"... in other words, you could create as many new entities, or autocomplete existing entities, as needed per field.

This nicely solves the UI problem described above for Items and Stephen King, and has a few additional extras thrown in. We use a single vocabulary for both entities so that a single "Producer" field could contain "J. R. Bookwalter" (a Person) and "Tempe Video" (a Corporate Body). If one were to head to a particular term's URL (ex. taxonomy/term/13), we would see all nodes associated with them, regardless if they were an Author here, an Editor there, or a Gaffer elsewhere. On the other hand, if we ONLY wanted to show nodes where the term was used solely in the Director field, that'd require custom code or, likely, Views. I don't think that sort of filtering would be necessary for the first few versions, nor do I think it's difficult to implement.

Group 3 Entities

Group 3 Entities are handled just like Group 2 entities: a single vocabulary called "Subjects" that would be added to a Manifestation's content type four times: once for "Concept", "Object", "Event", and "Place". This allows a single term to be used in multiple ways: "Shangri-La" might be a concept in this book, but a place in that movie. Browsing to the "Shangri-La" term would show matches for both Book and Movie. I find this particular approach necessary as I just don't trust myself to remember how I categorized the "Shangri-La" in a particular character's drug-induced hallucination from a book I read 12 years ago. Again, filtering down to particular types would come at a later date.

And that completes my current mental map on Drupal 7 and FRBR. Nothing has been implemented, but I'd lean toward a full-fledged module than an installation profile (which could setup all the above, but would suffer from the inability to upgrade existing installs) (see comments). I'm also envisioning another data exchange layer on top of the above, where one would put in an identifier (ISBN, ISSN, UPC, ASIN, etc.) and click a button to prefill the fields. The lack of fieldsets for custom fields in Drupal 7 would cause the above forms to look ungrouped and ugly, but a module could fix that up as well. I might end up actually implementing all the above in a demo site the next time I have a few hours to kill: if anyone is interested in seeing such a demo, don't hesitate to email

There are a few gaps in what this overall approach can do: it doesn't handle collections or serials nicely (i.e. a book with chapters, or a magazine with articles, written by different people, etc.) and if I were to go down that path, I probably would end up making a second "class" of content type, with a node reference, and there'd be a specific sub-content type per form (Sequence for Comics, Article for Magazines, Chapter/Section for Book, Short Film for movie anthologies, etc.). Also, Persons or Bodies with the same name could be solved the IMDb way ("Stephen King (I)", "Stephen King (II)") or the traditional way (birthdate on taxonomy term, autocomplete tweak to show "Stephen King, 1947-", etc.). And I'm sure I'll find more as I devote more mental slices to it.

For the three people who know what I'm on about: thoughts?

Link Dumpage for 2009-10-27

Notable links enjoyed today:

  • "Public Domain Super Heroes is a collaborative website about comic book characters in the Public Domain ... This is intended to be an online encyclopedia of these characters, providing pertinent information to fans who want to learn about their history, as well as creators who may want to use them. Unless otherwise noted, all images and information are believed to be in the Public Domain. The information and images presented are intended to give a brief overview of the characters and provide a visual reference."
  • "He has written six books of puzzles, five of which center on the work of a mathematical detective by the name of Jacob Ecco, a biography about great computer scientists (coauthored by freelance journalist Cathy Lazere), and technical books relating to his various areas of research. In his non-academic writings, perhaps his greatest invention is the notion of omniheuristics, a kind of super-heuristics concerned with the ability to solve any and all manner of puzzles, conundrums, enigmas, and dilimmas. Owing their decidedly curious character, he has given particular note to puzzles that start off easy, but have apparently innocent variants that are particularly perplexing; he calls them 'upstarts'."
  • "Intertextuality is the shaping of texts' meanings by other texts. It can refer to an author’s borrowing and transformation of a prior text or to a reader’s referencing of one text in reading another. The term “intertextuality” has, itself, been borrowed and transformed many times since it was coined by poststructuralist Julia Kristeva in 1966. As critic William Irwin says, the term “has come to have almost as many meanings as users, from those faithful to Kristeva’s original vision to those who simply use it as a stylish way of talking about allusion and influence”."
  • Delicious tags: riffs dialogue mst3k wikipedia
    "MSTing is a method of mocking a show in the style of the television series Mystery Science Theater 3000 (MST3K) and, in particular, is a form of fan fiction in which writers mock other works by inserting humorous comments, called "riffs", into the flow of dialogue and events ... MSTing began in the early 1990s, as fans of the show, many of whom were involved in Usenet discussions in groups such as popular MST3K newsgroup, began adding amusing or critical remarks to others' posts, attributing them to the show's characters."
  • "The Urantia Book ... is a spiritual and philosophical book that discusses God, Jesus, science, cosmology, religion, history and destiny ... The Urantia Book is 2,097 pages long, and consists of an introductory statement followed by 196 "papers" divided into four parts ... The exact circumstances of the origin of The Urantia Book are unknown. The book and its publishers do not name a human author, instead it is written as if directly presented by numerous celestial beings appointed to the task of providing an "epochal" spiritual revelation to humankind. For each paper, either a name, or an order of celestial being, or a group of beings is credited as its author."


Link Dumpage for 2009-10-23

Notable links enjoyed today:

  • "Here, 100ft down and hidden from public view, lies an astonishing secret - one that has drawn comparisons with the fabled city of Atlantis and has been dubbed 'the Eighth Wonder of the World' by the Italian government. For weaving their way underneath the hillside are nine ornate temples, on five levels, whose scale and opulence take the breath away. Constructed like a three-dimensional book, narrating the history of humanity, they are linked by hundreds of metres of richly decorated tunnels and occupy almost 300,000 cubic feet - Big Ben is 15,000 cubic feet."
  • "Submerged stone structures lying just below the waters off Yonaguni Jima are actually the ruins of a Japanese Atlantis—an ancient city sunk by an earthquake about 2,000 years ago ... Some experts believe that the structures could be all that's left of Mu, a fabled Pacific civilization rumored to have vanished beneath the waves."
  • "When a carpenter ant is infected by a fungus known as Ophiocordyceps unilateralis, the victim remains alive for a short time. The fungus, however, is firmly in the driver's seat. It compels the ant to climb from its nest high in the forest canopy down into small plants and saplings in the understory vegetation. The ant then climbs out onto the underside of a low-hanging leaf where it clamps down with its mandibles just before it dies. There it remains, stuck fast for weeks. After the ant dies, the fungus continues to grow inside the body. After a few days, a stroma—the fungus's fruiting body—sprouts from the back of the ant's head. After a week or two, the stroma starts raining down spores to the forest floor below. Each spore has the potential to infect another unfortunate passerby."
  • "One of Aesop's fables may have been based on fact, scientists report.
    In the tale, written more than 2,000 years ago, a crow uses stones to raise the water level in a pitcher so it can reach the liquid to quench its thirst. Now a study published in Current Biology reveals that rooks, a relative of crows, do jut the same when presented with a similar situation ... Footage of the experiments shows the rooks first assessing the water level by peering at the tube from above and from the side, before picking up and dropping the stones into the water. The birds were extremely accurate, using the exact number of stones needed to raise the worm to a height where they could reach it."
  • "A team of archaeologists has found a sanctuary in central Bulgaria where the nymph cult used to be celebrated in ancient times. The sanctuary was found by archaeologists in the vicinity of the Nicopolis ad Istrum ancient site, located near the town of Veliko Tarnovo in central Bulgaria ... Nymph worshiping, according to the archaeologists, can be traced back to Ancient Greece, where the mythical female creatures were usually part of the retinue of a god, such as Zeus, Hera and Aphrodite."
  • Delicious tags: games achievements collecting
    “People work for intangible rewards all the time ... Money and love, for example. A paycheck may seem ‘solid,’ but it represents an abstraction. And what’s more abstract than earning an ‘A’ in philosophy?... Small things can be quite rewarding. A smile from a cute girl may be a small thing, but it can make a teenage boy’s week.”
  • "A hidden metapuzzle threads through the pages [the May] issue of Wired magazine, which is built around the theme of magic and mystery ... Below the surface of the May issue lurk 15 puzzles, all of which combine into a giant metapuzzle ... The metapuzzle was designed to be completely invisible to the casual reader."
  • Delicious tags: youtube horror lovecraft music
    Innsmouth: The Musical. Carol of the Old Ones. Shoggoth, Shoggoth, Shoggoth. If I Were A Deep One. I Saw My Mommy Kissing Yog-Sothoth. Away In A Madhouse. Freddy the Red Brained Mi-Go. I'm Dreaming of a Dead City. Awake Ye Scary Great Old Ones. The Cultist Song. Byakhee, Byakhee. Bonus Feature: Shoggoth on the Roof - A Play Performed with puppets.


This week at Textploitation (July 20th, 2009)

Today, we start something called Textploitation which is, by design, nothing truly exciting. There is no innovation here, no special come’uppance, no inherited feelings of elitism. The site serves the singular purpose of getting us, myself and long-time friend and project-partner John Treacy, to finish a small bit of fiction every Monday. We have no illusions that what we’ll write will be awesome or the gift of greatness to America: it is solely practice. Some releases will be final, others will be serialized week to week. If it turns out that our combined output is of some quality, great; if not, we’ll keep at it, realizing that our goal all along was to do so until it is.

You're more than welcome to comment on any of the stories or pages by using the "Discussion" tabs.

This week’s releases are The Shame (page 1) by John Treacy, wherein a small-town sheriff has the lurid details of his off-duty activities exposed, and Morbus Iff’s Untitled 1 (page 1), wherein a single bubble leads to fleeing sisters and an exasperated mother.



Subscribe to RSS