At the start of the summer, I mentioned I would be spending a lot of my summer writing a new website for the UC College of Engineering and Applied Science tour group I'm a member of - and last night I marked version v1.0.0! The website is live at https://ucceasambassadors.com.

A Summer's Work

When I took this on, I knew that the old website took about 4 months to write, and it was on top of boilerplate code! Not to mention, the author of the old site is an incredible coder. I was going to write the entire website from scratch - albeit probably with a more refined use case (it's my understanding the old site was to be used by multiple student groups which required more general logic). From the time I started writing requirements to the time I went to production, it was about 4 and a half months. As of version v1.0.0, there are 336 commits, 252 of which are mine and non-merge commits. With some back of the envelope math, and assuming 15 minutes per commit (which is probably a low average), it took 63 hours to complete my portions of version v1.0.0. I wish I had tracked my time working, because I suspect it would be even higher. For much of the summer, I would work for an hour and a half a day, and sometimes much more on the weekends, knowing I had a hard timeline to go to production. This doesn't even include the time that my other contributors gave, Jeet and Sean both of whom were immensely helpful picking up slack for me.

The Technical Parts

I want to write a little bit about the more interesting or difficult technical parts of the website, things that I spent a lot of time on, or I think are worth writing a little bit about. The source code for the site can be found here.

A Data Relationship

The core use case of the website is for members to sign up for tours, and to track how many tours members attend. The old website was written using MongoDB, and it copied event documents, in whole, to the member document once a member was confirmed an attendee of a tour. This meant that if an event was edited after a member had gone on the tour, it would not be reflected on their service totals. The clear, partial solution to this was switching to a relational database, and using a join table to track these relationships. This solved part of the problem - but a big part of the website is summing up the amount of time members have spent giving tours - which requires either summation every time that information is requested, or a column to be kept up to date as events change and attendance records are added. I chose the latter, and implemented it using Sequelize hooks rather than mysql triggers, given the complexity of the logic I felt more comfortable writing it in javascript and managing it via the website. Here's an example of what a hook looks like. I spent a lot of time tracking the lifecycle of Sequelize operations, and how hooks ran to make sure that records are updated correctly, in the correct order.

Architecture

I spent a lot of time, overall, on this project making sure that documentation, readability, and ease of understanding were priorities. Part of that was deciding on a clear architecture to use for the site. I eventually settled on something that for the most part is a model view controller architecture. I won't call it a perfect application of the concept - but I think what I did clearly compartmentalizes behavior from data definitions from ways that data is presented. I don't think that what I wrote varies a whole lot from a traditional express application, with a notable exception being that I chose to separate my route definitions from the route handlers.

Maintenance

A big part of this project was building something that can be maintained by future tech chairs, irregardless of their experience with the technologies used. I don't know if someone with no experience can work on the site, but my goal with heavy documentation has been to make that close to possible. To keep code readable and working, I've written 135 tests thus far, mostly integration tests, testing endpoints, database relationships, and node modules for breaking behavior. I've also enforced style linting through the use of Travis CI and Eslint, following Air BnB rules.

Javascript

To be honest, I'm just happy I managed to write this in javascript - my friends know that my complaints about the langauge have been many - and sometimes I question why I chose to write the website in javascript at all. I've been plagued by async issues, weird npm module behavior, and general unfamiliarity with language concepts. In the end though, this has been a fantastic learning experience for me, and I'm confident I've written something I can be proud of, and I look forward to continuing to improve the site, even as my term as tech chair draws to an end.