Technology
This website is built on a wide variety of open source software. Most of them are listed below in alphabetical order, along with a brief description of how I've used them and my general level of experience with each. TL/DR, this website is a Django site.
One of my first projects with Linux involved building Apache and PHP from source. Since then, I’ve gained a solid understanding of Apache configuration across various distributions and regularly use its log files for troubleshooting. For this site, I implemented SSL and configured basic virtual hosts.
Bash was used extensively during the troubleshooting and implementation of the website—everything from simple file system commands, redirection and pipe operators, permissions and authorization, shell scripting, and more. Long live the CLI.
Around 2017, I built a fully mobile-compatible website using Bootstrap’s grid system and have relied on it ever since. I regularly use the framework for form styling, UI components, and responsive typography. Through ongoing use, I’ve also gained experience transitioning projects from Bootstrap 3 to Bootstrap 5.
After a fairly negative experience with a different MVC ORM around 2009, I was hesitant to try another. Fast forward several years, and I was tasked with the creation of a web app that needed a dozen or so models (not this one), each with identical CRUD requirements. As a result, I decided to take a second look at these technologies. That search eventually led me to Django. This framework's strict adherence to the DRY principle, its built-in administration interface, templating engine and open source nature were all very appealing and I became a convert. This ORM definitely lives up to the hype.
The use of Django for a variety of personal and professional web application projects eventually led me to the framework's Achilles heel: deploying it. Having previously worked with PHP and MySQL a fair bit, I naïvely thought I would merely copy my Django application code to a web server and, at most, enable a Python module in Apache or something simple like that. Anyone familiar with Django deployment is probably laughing right now. Needless to say, deploying Django is actually quite challenging.
While I was somewhat successful in getting mod_wsgi working, a friend suggested I give docker a try. I did - and it worked very well. In fact, this application is being served by a docker container right now. Along the way, I learned the nuances involved in multi-container management via docker compose, implementing a multi-stage build, container logging, volumes, various types of docker networking, and general troubleshooting of my containers. The docker rabbit hole is pretty deep and I certainly don't claim to be a DevOps engineer, however, learning the basics of this powerful technology has given me a much greater appreciation for that field. More importantly, I can now reliably deploy my Django applications to virtually any hosting environment. A locally installed docker registry is used to store the latest few build images for the project.
Git is used for source control. I have previously used both Github and GitLab at various times in the past but for this project I ended up installing Gitea locally in order to support my particular CI/CD workflow.
Throughout my career, I've used a wide variety of Linux based operating systems. While I enjoy them all, I find I am most at home on the Debian variants.
Most of my practical experience with Python has come through working with Django. This has given me a solid grasp of Python’s syntax and core constructs, including data structures like arrays and lists, conditionals, loops, and implementing basic object-oriented class structures.
This application currently uses SQLite as its backend, with the option to migrate to PostgreSQL if deployed on GCP. One of the Django models includes a models.JSONField, which introduced some unique challenges when this type moved between the database, Python, and JavaScript. The Django user model was lightly extended to add custom fields, though overall data requirements remain minimal. While SQLite is sometimes viewed as unsuitable for production, its simplicity and reliability make it an ideal fit for a small-scale application supporting a niche sport like trick water skiing.
A few other notable mentions include JavaScript which I learned a great deal about thanks in part to a former colleague who was kind enough to review my code. Javascript is used extensively on this site to ensure the majority of the logic for entering a trick run is done on the client side for performance reasons. I also improved my understanding of modern HTML and CSS, SSL, and the JSON and YAML formats.
CI/CD
In my CI/CD workflow, Drone CI handles automated builds and test execution, after which completed images are uploaded to a private docker registry. A running Watchtower process then automatically detects and deploys the new application version. Although I was new to these technologies and getting the complete CI/CD workflow running smoothly took a fairly significant effort, I persevered and now relish the fact that a simple git push is all that's required to deploy application changes.
A brief note about Kubernetes: I wanted to learn that software and use it for my deployment pipeline, however, I was shocked by its resource requirements. That's what led me to Watchtower instead. It's less powerful for sure, but its footprint is a tiny fraction of what Kubernetes requires.