Sessionify is a web application used to allow conference attendees to view all of the sessions for an upcoming conference & manage their own individual schedule for the event.
I have attended at least two tech conferences each year for the past 5 years. Each year, I find myself scrambling with my printed paper schedule, cross checking the terrible table layout for the current session block & checking the highlighted session information to figure out which room I need to rush to next.
These conferences are full of incredibly smart software developers, many of which develop awesome projects in their free time. I found myself asking, "Why don't we have a better way to manage the session schedules for individual attendees?"
I decided I would take matters into my own hands before attending NDC Minnesota & build my own service to manage schedules for the event.
I had a couple of basic requirements, as well as some stretch goals about what I thought would be useful when attending.
I wanted to see a list of all the sessions from a conference including details about the speaker, description, room number, & starting times.
I needed to have the session list presented in a way that sessions were grouped into time slots to be sure that I don't double book a specific time period.
I wanted to be able to select the sessions I wanted to attend & see a filtered view of just the selected sessions.
There wasn't much of a deliberation about which programming language to use. I am a .NET developer by trade, so I opted to build all of Sessionify in .NET Core 2.3.
For hosting I wanted to be sure that I was able to scale as much as necessary (you never know when you will have a surprise success) while also not going broke. This screamed "serverless" & I settled on using Azure Functions over AWS Lambda. While Lambda is cheaper overall, using Azure is a much easier experience from my CI/CD platform of choice: Azure DevOps.
Side Note: If you haven't ever used it, Azure DevOps is 100% for teams of up to 5 people with unlimited private repos, builds, & deployment pipelines. It is definitely work checking out.
There are a couple of different pieces of data that needed to be stored for this application, each with different structures & needs. The main categories of data that needed to be stored were; user account data, conference sessions, & user selected sessions.
Ultimately, everything I was planning to store was relational in nature & fit perfectly fine in SQL Server.
I started importing sessions manually. It was a long, boring process of going to the conference website & manually typing in the data into some pages I built.
After the first couple of conferences, I opted for writing an import process using Azure Functions to
For the user interface I stuck with what I know & used ASP.NET Razor pages. Using that technology ensured I would stay productive on adding value to the application instead of trying to learn a new technology, such as Angular or React, while also building a new product.
The styling was done via Bootstrap using the default theme.
There were cases where I would need to be able to communicate with the end users about various things like; sending password reset links or alerting them about their next sessions details. Email seemed like the most logical solution for both of these to start with the expectation of piggybacking Twitter DMs for a push notification like feature later on.
I already had a SendGrid account sitting idle from previous projects, so I just generated a new set of API keys & used their SDK.
This diagram is meant to show the Sessionify application with context about what the different pieces are used for & how they interact.
All in all the project worked pretty well. I used it for the conference but, I wouldn't consider it a life changing application.
I spent a little money on Google Adwords to see if there was any interest from the public to use it. There was very little, so ultimately, I shut the project down at the end of 2019.