The little local project I’ve been working on is DCTN. It’s a list of upcoming live music in Washington, DC.
DCTN lives a little outside that dynamic. I’ve been in the “DC Music Scene” for years, as part of Teen Mom and other bands. But I don’t go to shows all the time, or follow news outlets like Brightest Young Things. And the potential is limited: after all, DC is just one city, and the $8-12 indie band show market is barely staying afloat.
Incredibly local things are fascinating: in college, I built the Swem Signal, a way to share your location in the dungeon-like Swem library. It’s a crude PHP hack, built before Foursquare or Twitter were popular. But it still works, and students still use it. I’d like to think that it’s making nerds like me a little happier because they can tell their friends where to find them and to talk a little, before getting shushed.
Which connects to the other thing: time. Having worked on a lot of technology projects and observed the tech industry for years, it’s shocking how the usage curves vary - projects can maintain a flat curve of dedicated users for decades, and others can skyrocket to hundreds of thousands and then vanish into obscurity or shutdown. Different sorts of enjoyment, in both production and consumption.
DCTN is a React application. The Facebook-developed framework is pleasant to work with: its approach to building pages is not too many steps away from building in d3, but feels like it minimizes boilerplate. Each view can be written as a separate file and stitched together with browserify.
I have my gripes with React: building a touch application requires some sketchy
hacking of the React source code to include a pre-release plugin. This will
surely sort itself out, but wasn’t very obvious in documentation or code.
React’s JSX is
surprisingly nice - I’ll trade templates for source transforms any day of the week,
especially when the JSX transform has decent error reporting. Unfortunately,
JSHint doesn’t play nice with JSX, so I need to use a pre-release version
and lots of
jshint:ignore tags to avoid error noise in vim.
There’s plenty more to say about React, but I’ll leave that for a separate article.
DCTN has a server component. The core data - listings of concert times and details - comes directly from venue websites by the concerted work of scrapers. Each scraper is written in node.js and cheerio, and is a module with unit tests.
The server component is not client facing: it pushes data on a schedule to S3, which is then consumed by a static website. DCTN.org is hosted on Github Pages and requests data from an Amazon S3 endpoint. That data gets there by a server process, but never does a client request require anything new from the server.
The scraper framework,
is written as a node.js web app, running both an http server for status checks
and a cron-like process that does the scraping. It also contains some
simple metadata for each venue
tonight-sources currently scrapes:
There are plenty of other ones in the works and various stages of completion. Scrapers for U Hall & 9:30 Club are complete, but the venues apparently block my server.
Despite the cheerio module module, this isn’t node.js’s brightest area:
Dokku means that when DCTN has more components, they can be packaged and run
separately, as separate services. This is how I run
which is the twitter bot that runs @dctnght. The
twitter client is a separate node app
that runs in a separate virtual server on the same machine. So, if one crashes,
the other doesn’t, and I can update them individually. Since the datastore is
separate - it’s S3 - they can be totally decoupled.
DCTN is an ongoing project: it’s something that I’m building for myself, for friends, and for people in DC. Right now, it has a tiny handful of users, orders of magnitude less than ‘popular’ projects or established blogs. I Hope it’ll grow. Unlike other DC music outlets, it’s entirely automated, so day-to-day accuracy doesn’t rely on my assistance.
I’d love help - this project lives in my limited free-time and has lots of unexplored potential.