ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
the problem
the context* the solution
and the consequences
Dragonflight is a yearly gamer con held in August in Bellevue
Con draws in about 500 people across a diverse demographic
Non-profit volunteer organization
It all started with an innocent question in 2011....
"Why can't I sign up for games using my phone?"
Dragonflight's Web footprint was pretty ancient
Online registration system built pre-2000
A bad mix of PHP and classic ASP, storing to an Access back-end
Database barely qualified as first-normal form
Lots of "Copy of login.asp" and "Copy of login (2).asp" lying around
Registration system online frequently timed out or crashed
During the con, game signup was done via printed forms put out onto tables
Pre-reg signup was handled manually
Goal for v1: Replicate what they had, but using modern tools/tech
Features:
Register for the con
Volunteers can host an event
Attendees can sign up for an event (with restrictions)
Hidden goals: Do nothing that would work against ultimate goals
Mobile apps
"Push" notifications
Other, smaller, features introduced over time
"It's just a CRUD app, right?"
Some interesting little side-notes
Requirements sort of evolved out of meetings
"Pre-reg limits": only 75% of an event's signup slots can be filled prior
"Pre-reg limits" end 24 hours before each event starts
Certain events are age-restricted (Cards Against Humanity)
Privacy requirements were a "best guess" kind of discussion
No volunteers to beta test the UI
Driven basically out of my own experience as attendee...
... and conversations with event hosts (friends)
Volunteer non-profit organization
meaning, "let's keep costs as close to 'free' as possible"
Did NOT want to change hosts if possible
"let's try to minimize disruption"
Existing system developer/owner basically kept in the dark about the change
2-part architecture
EventBrite for event registration
AngularJS app for events, storing data over REST to Mongolab
No server-side processing: All browser-based logic + REST to database
2-part architecture
EventBrite took care of several important things
Con admin staff could control tickets, prices, discounts, everything
EventBrite did Amazon-style event suggestions (SEO!)
EventBrite handled all the money, including PayPal and credit cards
EB made it easy to reach out to attendees for updates (email)
EB also provided demographic info about attendees
2-part architecture
AngularJS provided in-browser UI updates/changes/etc
Reduced round trips back to the server
Once loaded, would hold data in-memory, saving round trips
Convenient way to do certain MVC effects
Fallout from the 2-part architecture
"Dual logins": EventBrite and DragonFlight
"Dual databases": Some data held at EventBrite (but not much)
This does mean we need to make API calls to EB for some data, though
Three main stages of "rolling" release
Opening up convention registration (Eventbrite)
Opening up event hosting
Opening up event signups
Start of the convention
Three main stages of "rolling" release
Opening up convention registration (Eventbrite)
Went off without a hitch (for the most part)
Opening up event hosting
Went off with only minor issues, most of which were fixed quickly
Opening up event signups
Some issues, mostly fixed pretty quickly
Biggest issue: Hosting site was entirely unreliable
Emergency cutover to Heroku for hosting
Start of the convention
BOOM!
The con started at noon on Friday
By 7:30pm, we pulled the plug on on-site event signups and went to paper
The existing site was still up, and database accessible
But we hit several problems that conspired to kill its continued use
The conspiring factors
Bandwidth was terrible
Hotel was in the middle of a hotel-wide WiFi upgrade
Hotel WiFi didn't reach into all of the con meeting rooms
Our attempt at a backup approach also met with epic fail
Doing in-person registration using EventBrite took forever
Hardware failure
We brought three laptops for local use
Couldn't get any of them to work reliably on the wired network
User failure
"WTF is this?!? When did the con decide to do this?!?"
The final factor:
EventBrite institutes a 1000/24hr API call limit
We reached it at 7:00pm
Dragonflight succeeded sort of
It was at least a partial win
We were able to pre-register people and check them in
We were able to allow event signups ahead of the con
Con admin staff were able to reach attendees prior to the event (email)
It was also a partial fail
On-site event signup fell down badly
On-site connectivity failed
Eventbrite API call limits
But, "the con went on" with minimal disruption
And the con admin staff are fully committed to getting "v2" ready for 2015
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Co-founder, Solidify US
http://www.solidify.dev
Principal -- Neward & Associates
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)
See http://www.newardassociates.com