Z.gg came from a twofold need. The first of the folds was speed. Most similar applications to zgg are sluggish to use. Z.gg was created with the intent to be only one thing, and as such it does it well.

All zgg does is provide a combo box to select one of the 100 something champions in the video game League of Legends, and it will display their ability descriptions and their cooldowns without ability haste. Z.gg is always up to date, and even remembers what champion you had up last time you visited!

This is a site I use on a regular basis, and if you just want a simple place to get overviews of champions without any of the fluff of more complex sites, feel free to use Z.gg!

Previously when looking for a toolkit to start building out my static portfolio site, I had originally landed on Jekyll, and entirely because it had a native integration to github pages. This worked, and provided the basis of what I wanted, a simple static site generator with flexible templates and markdown.

The reason I moved away from Jekyll is nearly as simple as why I chose it to begin with, I don’t really know ruby. I also didn’t appreciate the templating syntax. I weighed two specific alternatives Hugo and Astro. I landed on Astro because it is almost entirely javascript, or an extended html syntax, no weird {{ .Templates }}.

Largely this site is a practice of brutalism. Almost this entire site is javascriptless, and is also entirely statically generated. This is of course with one exception, the p5 Sketches. I made a concession in regards to the sites lack of JS entirely to remove the glass window between the code you see and the visualizations you see. As such all of the animations that I made not only are running live in your browser, but also all of them are clickable and link directly to their actual source code.

Working on a team of 4 software engineers, this project is a prototype frontend storefront, capable of displaying products, taking user submitted questions and answers, as well as user submitted reviews with dynamic product specific feature ratings.

The main thing this project taught me was how to develop within a team, and how to reduce code duplication across multiple team members. There were a lot of components that needed to be used across multiple features, which required constant team communication, as well as regular meetings regarding style cohesion and progress updates.

While remaining a single page application, the core concepts gained in working on this project has provided the foundation of my CSS skills, and has given me the confidence to handle CSS like a pro.

If I were to go back to this I would probably make it a multipage app, and make it properly responsive to being rescaled.

After being exposed to the frontend of this website, I got to experience the… tragedy that was the backend api. It was horrendously slow, would randomly error out, and overall wasn’t suitable for production use.

So what followed was an invitation to fix the aforementioned awful backend. This was a reasonable system design problem. What me and my team landed on was a microservice architecture, breaking the backend in 3 core components. The Q&A api, the products API, and the reviews API. My responsibility was the Products API.

Step one was getting the data into a database. I went with postgres due to it both being an industry standard as well as my preferred solution for using a Relational Database. The primary reason I went with a RDBMS as opposed to a NoSQL solution like Mongo was the fact that the data was already conveniently stored in CSV files with id based key relationships. I also had to do some mild data cleanup as there were duplicate keys and invalid CSV data in my original dataset.

Step two was creating the Database queries. I wanted to stray away from using an ORM like Sequalize so that i could familiarize myself with a language agnostic solution to interacting with SQL databases. As such I had to write my JSON aggregate functions by hand. If you want to see the resulting SQL queries you can look here. And for a view of the form of the API you can find the repository here. This not only shows you how to create an instance of this api, but also contains the API documentation.

Lastly was the problem of deployment. I started by creating a single AWS EC2 image containing a fully installed and ready to start version of the products microservice. I also set up a separate EC2 machine running postgres. I wanted to keep the DB image separate early in prep for running multiple instances of the products microservice. Lastly I setup an nginx server as middle man to handle requests from the internet, and direct them to each individual instance of the products microservice. This setup works great and was able to handle thousands of requests per second whilst remaining entirely on t.2micro AWS machines. If I were take another crack at the deployment architecture, I would probably have dockerized the microservice and handled it via kubernetes.

This project was an exercise in working in larger groups than I had previously. With our team of 9 engineers we were charged in making a prototype for a leetcode style social media site.

My role in this project was almost exclusively devops. I did a small amount of coding by setting up a structure for an express based api, but the large majority of this project was setting up the project itself. I hand wrote the webpack file, giving use the flexibility to use path aliases and simplifying imports. I chose and set up a jest and react-testing-library based testing environment allowing us to unit test our components, and I set up a fully automated and gating CI integration using github actions, ensuring pull requests always passed our predefined standard before it ever gets a chance to be merged into the main branch.

All of this had to be researched, planned, and communicated to the fairly large team to help mold and shape those plans to best fit everyone’s needs.

Overall this was a fun project with a lot of great engineers, and I am grateful to have been given to opportunity to act as the grease for their gears.