I’m an avid fan fiction reader, and one of my on-going projects is Fanonic.net - a fan fiction hosting site that provides helpful features for readers to find the kind of stories they are looking for more easily. If you haven’t heard of the term or come across fan fiction before, here’s the Wikipedia defintition from the fan fiction page:
Fan fiction (alternatively referred to as fanfiction, fanfic, FF, or fic) is a broadly-defined term for fan labor regarding stories about characters or settings written by fans of the original work, rather than by the original creator. Works of fan fiction are rarely commissioned or authorized by the original work’s owner, creator, or publisher; also, they are almost never professionally published. Because of this, many fan fictions written often contain a disclaimer stating that the creator of the work owns none of the characters. Fan fiction, therefore, is defined by being both related to its subject’s canonical fictional universe and simultaneously existing outside the canon of that universe.
Fanonic is free for both readers and authors. It’s main features, which I developed last year as part of its initial launch, are:
- the ability to search within the entire text of stories
- story tagging by users
- an activity stream that lets you see when your favorite authors add new stores or publish new chapters and when friends earn new achievement badges.
What’s Been Added
-
Avatars: Your profile automatically uses your Gravitar image if it’s set, and you can also upload an image as your Fanonic avatar.
-
Badges: A few new achievement badges have been added
-
Favorites: Stories can be favorited and show up on your list of favorites
-
Fanfiction.net import: Import your stories from fanfiction.net into your Fanonic story list
-
Lots of style improvements
What’s Coming Next
I’m using Haystack to provide story search. Fanonic is hosted on a single server and is using Whoosh to index the site’s story data, but my intention is to switch to another indexer/backend for Haystack to allow for future scalability. Elastic Search looks like the best direction to go right now because it looks easier to set up and administer than Solr and should be easier to scale to multiple search index servers than Whoosh or Xapian.
The site will be getting immediate notifications for each user’s activity stream and author’s story import status updates. I’ve set up a new repository on github for this subproject: django-tsuchi. I’m also looking into adding reader statistics for story authors, but I haven’t decided on specifics at this point. Support for importing stories from other fan fiction repositories will be added gradually as well.
I’m getting the word out about Fanonic, and getting in touch with some fanfic authors about bringing their stories to the site. I’m hoping to work with both fanfic creators and readers to build a better experience for everyone.
Technical Details
Django, nginx, uwsgi, redis, memcached, postgresql, celery
-
The new story importer uses Celery to import the content in the in a separate worker process so users can continue using the site while their content is loaded into Fanonic. I’m using redis to hold the queued tasks. Later on, I’m planning on using redis for some future features involving gathering reader statistics as well.
-
Django is a web framework written in Python that provides a lot of the basic funcionality that Fanonic builds upon. Django has a large and growing ecosystem of third-party pluggable apps. I’ve published one such app that is going to provide a new feature for the site, which I’m calling django-tsuchi.
-
nginx serves static content, such as Javascript and CSS files, and acts as a proxy to uwsgi.
-
uwsgi interfaces with the Fanonic Python code to handle incoming requests and return the app’s responses.
-
Fanonic’s database is PostgreSQL.
-
Fanonic uses memcached to cache content generated by the backend.
Puppet
Puppet is a tool that allows system administrators to define how the servers they administer are configured, which programs are installed, which services should be running, and what user accounts should be present on them. I’m using Puppet to manage both my local development system and the production server that Fanonic runs. Because both systems have identical setups, I don’t have to worry about differences in the server setup breaking the site - what works locally is much more likely to work on the production server.
-
I found some helpful Puppet modules on github:
-
example42 has quite a few Puppet modules on github. I’m using the redis module, and my fork of their nginx module. Many of their modules depend on puppi, which I’ve forked to handle some breakage because of the version of Puppet I’m using (2.7.17).
-
I’m using my fork of the memcached module from danakim to set up memcached.
-
I’m using the postgresql module from uggedal to set up PostgreSQL.
-
-
My local machine has a vagrant box running which automatically loads up the Puppet configuration when it boots.
Fabric
-
I’m using Fabric to handle code deployment
-
Right now I’m using Fabric to push the Puppet manifests to the server and run
puppet apply
on them, rather than having a puppetmaster. -
I’ve taken the common tasks for this kind of set up into a Python module of Fabric tasks.