Starboard is a web service for forming and tracking habits. It uses a variety of gamification techniques ("don't break the chain"-style cumulative rewards, variable-interval bonuses, experience points, check-in health, etc.) to get people "addicted" to performing self-specified tasks on a regular schedule, such as exercising, eating healthily, or performing daily chores. It also serves as a daily review in preventing bad habits such as smoking. Starboard has a whiteboxed version available for corporate use in employee self-rating and review, and also offers "program subscriptions," where users can work together through a set of tasks developed by a life coach or other third-party.

I created Starboard from the beginning to run on Heroku's cloud service, relying on the Redis NoSQL key-value datastore for all required persistence. Every action performed through the interface or the REST API is guaranteed to be atomic—this is important when accessing the service through the iOS client and web application in parallel.

The core of Starboard is a small Sinatra-based Ruby web application. It interfaces with a variety of other services: Starboard uses Recurly for recurring billing support; it makes use of the Dropbox API to allow users to provide "evidence" for some task-completions; and Disqus and Gravatar are used for some social features.

Starboard also has a native iOS application (currently in development) which allows users to provide instant evidence for task-completions using the camera, and which emphasizes the social features of the service: allowing users to cheer one-another on when they are struggling with a task, or to give them a thumbs-up (with attached bonus gifts) when they complete a long chain of tasks.

Persona is a social Q&A site in the style of StackOverflow, intended for writers as an aid in character design. Rather than each user of the site having a single identity, users create multiple personas—the equivalents of fictional characters from their stories—and take on their roles, developing the personalities and traits of their characters through their actions. A persona may answer user-submitted questions, converse with other personae, join and create groups, and participate in interviews or quizzes; personae also earn points and social rewards (“karma”) through their actions, which grant additional privileges to both them and their owner.

Persona characters, like members of a social network, each have a feed, populated by their actions and comments to others, and made available both through the website and through the RSS 2.0 and Atom feed protocols. The feed display on the website is customizable and theme-able, and the items appearing in it may be filtered to each user’s tastes, allowing users to set up a “blog” equivalent for each character. The feeds, personae, or entire users may be freely imported and exported from the Persona website as XML documents. Persona also allows external services and clients to perform Persona actions, or exchange Persona data using OAuth and a RESTful HTTP API.

Persona relies on OpenID integration for the entirety of the client life-cycle. As such, there is no registration step; users simply sign in, and find their name and details imported using OpenID SRE, user display icon imported from Gravatar, and a single persona already created with their preferred online pseudonym. Persona then uses a recommendation engine (an SVD collaborative-filtering approach; built using Amazon Elastic MapReduce and wukong) to match users with other users, match personae to other personae, and to find interesting groups for users to join and questions for personae to answer. Every user starts in guided character-development mode, where Persona will also make “reverse” recommendations, allowing the user to specify desired relationships between the personae under their control, to which Persona will suggest answers to personality questions for character pairs that will justify those relationships.

I designed and developed the initial prototype of Persona myself, using the Ruby on Rails web framework, and then put it online in an open beta-test. From user feedback, and usage information I gathered via Google Analytics and through A/B split-tests (conducted using the A/Bingo library), I then redesigned and polished many facets of the service, and introduced several new features (such as a recommendation system.) After four months of refinement, I declared Persona “stable” and released it to the public. It gained momentum and users, and after a while, I introduced Google AdSense ads. Persona is now self-supporting from its own ad revenue, and continues to gain new users every day.

SpiltWines is a social network to connect wine-tasters to a receptive audience, and to increase the reach of wine-reviewers. The social graph of the service represents both mutual friendships between users, and "follower" relationships between wine-reviewers and their readers. Reviews of wines can be voted on, affecting a reviewer's visibility level within the network's various public channels; users can send messages and make comments on wines and wineries; and wineries can publish PR stories on their own page.

I worked with the SpiltWines team to develop their back-end throughout 2011. Development was split into two main phases. During the first phase, I collected core requirements, including that the code would be re-deployed to a variety of commodity *nix machines without having to install any particular packages. I proposed that the simplest route would be to design the back-end web service as a standard LAMP (Linux, Apache, PHP, and MySQL) application. I then drafted an API specification proposal and iterated it with the team until we were both satisfied everything was covered. I developed the core of the application—including user messaging, contacts, wall posting, reviewing, moderation, administration, user-lifecycle, and backend-testing functionality—and wrote a set of prototype HTML views for the application to deliver, which could later be replaced by the team's front-end developer.

In the second phase of development, new requirements were generated based on user-experience surveys using the initial prototype. With a larger userbase, it was hard to find good reviews, so I designed and implemented a ranking algorithm based on user-voting input for reviews. There were also problems with users posting defamatory comments and stories, so I created a global moderation queue that new posts had to go through for approval. Additionally, wineries were given the ability to manage the mentions of their own wines: for a fee, they could have their product highlighted, where mentions of their wine would link to their wine's page in the network.

Nodepad is a document editor I developed in C#, which was designed around the Snowflake Method workflow for fiction writing. Nodepad works with a hierarchical structure of named text blocks, called nodes. Users start with a root node—an empty document—and then write in the Content Editor pane (which is auto-saved) until they feel that whatever they have written has grown too large, and needs to be broken down. They then select the part of their text which has a repetitive structure, and node it; the structure is automatically detected, and each item is extracted into a new node, which appears as a child of the current node in the Node Explorer pane. The user can then repeat the workflow on each child node, recursively, until the document is complete.

I built Nodepad to obey the Unix philosophy. I avoided creating any complex document format for storing nodes; instead, I relied entirely on the filesystem for data serialization and storage. Each “node” is a folder—and, conversely, any folder can be opened as a node—and the content of each node is simply the content of an RTF content file in the folder. Thus, any tool that understands the filesystem—such as Git, Dropbox, or Windows Search—can treat a Nodepad node tree as if it were any other hierarchy of files and folders, enabling simple support for search, remote mirroring, and revision-control, which would otherwise have to be built-in. Each node has an optional XML hooks file, allowing individual nodes to react to events upon them, or their children, by triggering scripts written in Lua. Premade Lua scripts are provided for integration with the SVN and Git revision-control systems. Nodepad also natively understands NTFS features such as reparse points and aliases, so, with a few simple drag-and-drop movements, nodes may be made to “live” in multiple sections of the tree at once (with Nodepad at the ready to prevent directory-graph cycles).

Mergechan is software for running a semi-anonymous, image-sharing-centered conversation forum (usually known as an imageboard), similar in concept to the Futaba BBS Script and its spiritual successor Wakaba. Mergechan is written in Python, and runs on Google App Engine. I wrote Mergechan in response to two common problems encountered with other imageboard software:

• On imageboards that allow anonymous posting, it is difficult to prevent off-topic posts, or posts that contain illegal materials or violate the site’s TOS. Unless carefully moderated, such sites will inevitably become filled with spam. It is difficult to punish this behavior, because anonymous posters have not provided any identifiable information that may be used to block or ban them from returning.
• A given conversation thread on an imageboard will usually be of interest to only some of the website’s community. Most imageboard-hosting websites solve this problem by dividing the discussion between multiple copies of the imageboard software. This works in some cases, but more often than not a conversation thread will actually belong under more than one of the categories the site has defined, or transition from one category to another during the discussion.

I solved the spam problem by giving posts on Mergechan a dual identity. Before being allowed to post, users must first sign into the service using a reputable identity—in this case, a Google Accounts account (usually a Gmail address.) This gives the moderators a name and an email address to use in contacting the user, and a company (Google) to file complaints with if the user posts illegal materials. This also makes users more reluctant to spam, since Google does a good job of preventing users from registering large numbers of accounts.

When a user posts, their account is recorded in the post data, but is not displayed to other users, only to moderators. Instead, a second identity—a temporary pseudonym of the user’s choice—is displayed, preserving user-to-user anonymity. However, beside every post, a visual hash of the combination of the user’s account ID and the thread ID also appears, generated using the Python Imaging Library. This allows users to visually identify when the same user is speaking within a thread, while still allowing users to participate in different threads without leaking their identity between them.

I solved the content categorization problem by removing categorization altogether. Mergechan instead operates on a tagging and filtering model: every post in a Mergechan conversation thread has a set of tags attached to it, first by its author, and then by any readers of the thread. The union of these all these sets of tags, weighted by their number of appearances, becomes the set of tags for the thread itself. Users then filter the list of conversation threads by tags they do, or do not, want to appear in the resulting threads.

Wikirei is wiki software I wrote with Sinatra in Ruby. I designed it with a top-down focus on making a Wikirei site appear to be a static, polished, and minimal product until you log in. In this way, it is similar to a Content Management System (CMS), with different users holding different roles in the content-publishing process—but once you do log in (with OpenID), it becomes very clear that Wikirei is a wiki.

Wikirei follows a moderation-queuing approach, allowing every user the ability to suggest changes, but only a subset of users—the moderators—the ability to accept changes. This works very well as a model for a site that is co-owned by a corporation and a community: anyone in the community may contribute to the wiki, but the corporate users get the final say of what appears on the rendered website, without the ability to censor the community (as unpublished revisions remain in the revision stream, and may still be linked to or shared.)

Wikirei allows entries to be nested, tagged, and for each revision to hold arbitrary metadata and file attachments. Wikirei articles may be written using MediaWiki markup (parsed using Marker), or Haml, allowing Wikirei to store its own templates and special sections as wiki articles (which, like all other articles, go through the moderation queue—preventing XSS and site-defacement attacks.)

Sponge is a to-do list manager I developed in C#, in the style of David Allen’s GTD (Getting Things Done) principles. Sponge was designed to remove the need for any operation other than entering new items, searching for things to be done, and checking off done items. There is no categorization system to hide to-do items from oneself; there is no way to rearrange one’s items or to annotate them with excessive detail. Instead, a visual tagging system and a full-text search are used to filter the single to-do list stream, so one may find the items they can currently accomplish.

The only way to interact with the to-do list stream is through the entry box at the bottom of the Sponge window. In it, you may enter freeform text (which will appear as your to-do list item), prepend a parenthetical list of words, either space- or comma-separated (which will appear as tags), or prepend a tilde (~) character, which will cause the item to appear as done. This is also Sponge’s storage format; a “Sponge document” is a plaintext list, and may be edited just as easily in Notepad as in Sponge.

Everyone’s monitor resolution is slightly different, but everyone wants wallpaper that fits their screen exactly, with no stretching or blurring. Although the designers and illustrators who produce wallpaper may re-render their product in each of eighteen different resolutions, frequently, you’ll only be able to find a copy at one of those resolutions—the wrong one. Even more frequently, what you’ll find is a screenshot of someone’s desktop, with the wallpaper perhaps hidden underneath what they were actually trying to demonstrate—and you’ll be left wondering “but where can I get that wallpaper?”

Wallchives are a “clever hack” to solve these problems. A wallchive is “actually” a JPEG file—or, it could be equivalently said, “actually” a ZIP archive. These two file formats work together in such a way that they may simply be concatenated—glued together—and the result will function as both. If you open a wallchive with an image viewer, you will see a picture; if you open it with an archive extractor, you’ll get files.

I created Wallchive Creator to exploit this congruity, to allow people to show off their desktops while pre-empting any requests for the wallpaper underneath it. The Wallchive Creator is a simple wizard, written in C#; first, it loads a set of wallpaper, in as many resolutions as you have available; then, you provide it with a place to save the result; and finally, you activate it, and it minimizes itself, temporarily sets your desktop to display a wallpaper from the set, and takes a screenshot. The wallpaper set is archived (using the SharpZipLib library), the screenshot attached, and the result saved as a wallchive.

You may then post the result online—to a forum discussion, your Flickr account, etc.—and it will appear to any image-parsing software to be a picture: it will allow thumbnail generation, EXIF access, and so on. Mention in the description, though, that it is as large as it is for a reason!