Six Word Stories

Developers tend to start with a very simple “Hello, World” program to make sure their development environment is wired up correctly. If you cannot get this simple example program to run, something is wrong.

But after that program runs, I always seem to start with the same project when I’m trying out any new language or web framework: Six Word Stories. It’s a simple application that covers a lot of basics, such as database relationships, authorization, and familiar UI concepts.

I haven’t started a new version of this project in a while, so I started thinking, “What would a 2019 version look like?” Would I use Elixir and Phoenix, try porting an old Express.js version to TypeScript, or would it be a serverless application?

It wasn’t always about being a test bed for frameworks, though. The first iteration was a simple Wordpress site.

2007 A Warm-up Blog

As a journalism student, I started writing and publishing six-word stories and haiku poems to get in the groove of writing. This version only included my stories. I experimented with Wordpress theme development, but it was really all about writing content for me. AdWords were also added to the pages, but I didn’t get any meaningful traffic to make the ads worth including.

2008 The First Project

I wanted to allow anyone to post stories, so I started a basic vanilla PHP project. There was no authentication, and visitors could post anonymously under any author name they wanted. I used Recaptcha to stop any spam bots from posting stories.

2009 “A Literary Twitter Client and Viewer”

By this time, I was working as a professional developer and had experience working on a Ruby on Rails project. Peep Code had released a screencast called “Meet Sinatra,” and after watching it, I wanted to experiment with Sinata.

This was the first unpublished iteration. This version would show tweets that were tagged #sixwordstory on Twitter. You could post new stories from the website, and they were automatically tagged and tweeted if you signed in with your Twitter account.

2010 Inspiring Stories

I was still thinking of Six Word Stories as a project and not a technology test bed at this time. I iterated on the previous Sinatra version, but it now included a database. Twitter was now just for authentication and outreach (but automatic tweeting of the story was now optional).

The compelling feature for this version included pulling in photos from Flickr that had a Creative Commons license with the idea that people would create a story based on the photo. However, I started to get hung up on the edge cases like, “What should it do if the Flickr user deletes the picture? Should I download and cache the photo?”

This version, like the previous, never shipped. I was also starting to wish I had started with a more batteries-included framework like Rails instead of Sinatra, which put the project on hold.

2011 Relaunched with CodeIgniter

In 2011, I had just started a job working on a PHP-powered application (I don’t remember it using a framework, just some internal conventions), and I wanted to try CodeIgniter (version 2) as a PHP alternative to Rails.

This began with Six Word Stories being a simple tech demo. I striped it back to the basics of just tables for stories and categories and anonymous publishing guarded by Recaptcha.

This version was published, but it would be the last published version.

Side note: before this version, the project was hosted at 6ws.org, but one day I was just checking if sixworstories.com was available. It was, so I registered it and launched it under a new domain.

2012 Return to Ruby

I wrote a version with Rails 3 that had the same basic functionality as the CodeIgniter version. There wasn’t anything fancy here. I was just trying to get up to speed on what is new in Rails.

Next was a Rails 4 version that I wrote as a portfolio piece. It was developed following test-driven development and featured an Ember 1.0 front-end.

2014 JavaScript All the Things

While the Rails 4 version never shipped, it included a JSON API, which led to some front-end experiments. I made a UI using React as well as a UI using Angular 1.

Around this time, there was also a meteor.js version of the front-end and back-end. Since I had a React version that was decoupled from the back-end, I thought I’d write a back-end using Express.js with MongoDB.

Later, I would write an iOS version of the UI that would hit the Express.js back-end. And later GraphQL was added to it, and the React client was changed to used Apollo to connect to it.

The Express.js version ended up being a Frankenstein of code with no code quality whatsoever. Just a bunch of “Wouldn’t it be cool if…” tech experiments.

2016 Return to Rails

At Keyring (where I worked around this time), we were preparing to upgrade our back-end from Rails 3 through to version 4 and finally version 5. I pulled out the old Rails 3 version and want to see how painful the upgrade to Rails 5 might be for a simple app. Upgrading such a small codebase wasn’t really comparable, but it did give me some insights for our back-end upgrade.

The Future

I think I want to focus less on the tech and more on the other components of a published project that require nurturing to be successful.

The allure of the new and shiny is strong but also less challenging. Solving the technical problems in a project is way easier and less exposed than trying to work through user engagement and growth problems.

So instead of the new and shiny, I’m going to start with technology that works for me in my day job and focus on the product and not the tech.