I've been developing software since 2014, but I began coding for fun long before that. My career has allowed me to explore different aspects of the industry, and I have years of experience in many different languages and frameworks, both frontend and backend. I even worked in DevOps for several years, developing and maintaining infrastructure used by multiple teams.
These are all projects that I have built and developed on my own. All of the underlying infrastructure is deployed using Terraform, and launched into Google Cloud Platform. New releases are automatically tested and deployed using GitHub Actions.
Technologies
While GCP has monitoring and alerting systems built in, they don't automatically integrate with the tools I wanted to use. So I decided to set up some basic infrastructure on top of GCP Alerts to send messages to a Discord webhook.
Each project has it's own "alerts" Cloud Function, tied to a PubSub topic, which is fed into by Google Cloud Alerts. I've configured all of these elements to be set up automatically in Terraform with every new project I launch. The GCP Alerts themselves are manually created, primarily to allow for greater flexibility than if they were coded into the Terraform definitions directly.
Observability is a key feature of any project I maintain. Even with small projects like these, knowing when there is a problem and being able to trace it to its source is important.
This is a new version of a service I wrote back in college for a final project. My goal was to make scheduling classes less irritating, since UNM's interface was not friendly at the time. The original source code was lost to time (it was built in AngularJS and Java Spring), so I recreated it using Elixir and React.
The database for this service is kept up-to-date automatically via a daily script that extracts data from a public-facing XML file containing scheduling information. This file is made available by UNM specifically for projects like this.
I wanted to make something that could take greater advantage of the BEAM architecture than a simple database-driven application. So I made a multiplayer game framework in Elixir.
Each game creates a "server" process. This process manages game state, and is what all the players connect to. When the game state changes, it sends messages to each player (either individually or in batches) via Phoenix PubSub to tell their LiveView socket processes how to update that players view.
The only game I've made available so far is Minesweeper, which is notably a single-player game. However, I've incorporated multiplayer elements - the player who started the game is the "active" player, and everyone else is an "audience member". The active player can click on things, while the audience gets a live-updated view of the ongoing game.
The underlying game framework is flexible enough to handle all sorts of games, (I briefly tested an incomplete version of Light Cycles to see if real-time games were feasible - they are) and I will be adding more in the future.
I have other projects in the works! Any public-facing projects will be posted here.
