Software Engineer, September 2014 - December 2014
I had an awesome time working at Vidyard. It was the first time I did lots of heavy lifting on the back-end. I started my term by doing some backbone fixes - I was poking around the app and found that the tagging interface was really buggy. After asking about it, I got a triage of bugs assigned to me for it. It started with some small front-end UI changes but when that wasn't enough, it grew into removing one tagging library and replacing it with an internally-written one.
However, the changes didn't end there. The tags were rendered in a bunch of different ways - some sending a PUT request every time you pressed space after a word, others via a form. Some requests were limiting the number of tags that could be called in one view, when more could be called in another! I rewrote the GET and PUT tag API endpoints and changed all the features that accessed them so they would be consistent. There were lots of different features using tags inside Vidyard's app, and I made so that there were only two endpoints despite having numerous routes.
Another feature I worked on was automatically creating sitemaps for Vidyard's hub subdomains. That involved using Nokogiri, the XML generator. I made it so that every time a feature was added to a hub, a new sitemap was generated. The alternative was to parse the existing sitemap and find the exact line that needed to be edited or added. However, writing it this way can potentially lead to lots of bugs with many lines of code. It becomes desirable when hubs have > 500 pieces of content that need to be generated into an XML document, but for the majority of Vidyard's users, regenerating the sitemap each time (or redirecting to the existing sitemap on AWS, if it hasn't been recently updated) is sufficient.