Eventum: An Event-Driven CMS

Published on July 16, 2014.

Late April, 2014. I’m clicking through the public Google Calendar for ADI, Columbia’s tech club. I’m editing the details of one our last events for the year, and I’m pissed. I was particiating in a coordinated attack on our website’s performance, and I was doing so willingly.

The Problem

At the time, the ADI website was loading the details for upcoming workshops and tech talks using the Google Calendar API in JavaScript. Every time someone visited adicu.com, their browser requested the last month’s worth of events from Google Calendar, and then painstakingly parsed them into HTML. What’s worse is that we needed to hold separate resources, short description, and long description all in the description field of the Google Calendar event. Gross. To accomplish this, said description had to be formatted as follows:

Short Description
<em>---</em>
Long Description
<em>---</em>
slides --&gt; <em>http://link-to-slides.com/this_event</em>
code samples --&gt; <em>http://github.com/adicu/this_event</em>
...

It was painful. The JavaScript (which I dug up directly from our old site) says it all:

var parts = event.description.split("---");
event.description = parts[0];

if (parts.length == 3) {
    event.longDescription = parts[1];
    var resources = parts[2];
    resources = resources.split("-->");
    event.resources = {};

    for (var x = 0; x < resources.length; x += 2) {
      event.resources[resources[x].toLowerCase().trim()] = resources[x+1];
    }
}

This string parsing is extremely expensive when it’s being done on every event we pulled in, every time our front page loaded. I knew we could do better.

But, with our website running in Jekyll on GitHub Pages, we couldn’t run any server code that would cache our Events, because Jekyll only serves static files. If we were to solve this problem, then we’d need to run adicu.com on a real web server.

The Idea

This is when I came up with the idea for Eventum, an event-driven content management system (CMS) that syncs with Google Apps.

The idea behind Eventum is that on sites like ADI’s, creating events is just as important as creating blog posts. Technologies like Jekyll were great for ADI as we were starting out, because we could advertise new events or share a cool hackathon project just by writing a Markdown file. (Jekyll converts a folder full of Markdown files into a static blog site. It’s really cool!) As we grew however, we wanted a more full-featured solution for our events, and we couldn’t find one.

As I began to mock up the early versions of Eventum, I laid some basic features that our new events system would need. First: Markdown editing. Markdown is simple to learn, extremely portable, and sufficiently powerful; plus, it’s what ADI used for writing blog posts and event announcements. Second: Sync with Google Calendar. ADI members rely very heavily on our Google Calendar as the definitive state of what events we a running and when, and I couldn’t just take that away. And finally: Support for our two-calendar system. We use a private calendar for tentative events, and a public calendar for announced events. Eventum would need to manage events across both calendars in order to fit in with ADI’s workflow.

The Implementation

Fast forward to today, the first version of Eventum powers ADI’s new website(which, incidentally, has recently gotten a face-lift). It’s far from perfect, but being able to edit events through a webapp rather than in the Google Calendar description field is a definite plus.

Eventum is built in Python and Flask, and blog posts and events use EpicEditorfor in-browser Markdown editing. Also, Eventum supports ADI’s two-calendar system: when you publish an event, it is flipped from our tentative calendar to our public calendar.

Events and posts can be edited in Markdown.

The “Home” page shows this weeks events and the most recent blog posts on the site.

The “Events” page gives an overview of this week and next week’s events.

Eventum also has a permission system that allows administrators to limit what different users can do on Eventum (generate content, publish it, or manage user accounts), and an interface to manage images uploaded to the page.

This first version of Eventum covers the basic needs that I enumerated at the start of the summer, but it’s far from finished. I’m still building out new features and resolving bugs. The Eventum codebase is currently intertwined with the ADI website, and I’m hoping to separate the two soon. In doing so, it could at some point become a plug-and-play CMS.

I’ve already had some help from ADI board members to brainstorm new features and layout a roadmap for development. Moreover, members of the newly-formed ADI Labs program (including myself) will be adding new features to Eventum and making it even better. Hey, maybe one day I’ll actually have test coverage.