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 though, 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.
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 ads worth the include.
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. Authorization for writing with provided by Recaptcha to stop any spam bots.
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” (which is still available on the web, though now at PluralSight), 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, and after you have authorized with Twitter, you could post new stories with which were automatically tagged and tweeted.
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 auth and for outreach (but automatic tweeting of the story was optional now).
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?”
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.
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 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.
I wrote a version with Rails 3 which had the same basic functionality of the CodeIgniter version (it even used the same tables and data). There wasn’t anything fancy here. I was just trying to get up to speed on what’s new in Rails.
Next was a Rails 4 version that I wrote as a portfolio piece. It was developed following TDD and featured an Ember 1.0 beta front-end.
While the Rails 4 version never shipped, it included a JSON API which lead to some front-end experiments. I made a react version of the UI as well as an Angular 1 version.
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 though 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 the express version 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 what so ever. Just a bunch of “Wouldn’t be cool if…” tech experiments.
At work we were prepping an upgrade our back-end from Rails 3 to 4 to 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. It wasn’t that bad for such a small code-based, but it did give me some insights for our back-end upgrade.
I think I want to focus less on the tech and more on the other components of a published project that requires 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 exposing 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.