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
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.
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.