Hi there, I'm Michael. I'm a software engineer with a deep interest in user-focused, technology and engineering. I enjoy building tools to assist myself, and others, with my other hobbies and interests.
This site is a place for me to share projects I'm working on, write about technologies I 'm learning, and put into practice my learnings .
This is my personal kubernetes cluster. It is a setup of 5 Raspberry Pi 5's, using K3s to create a 'simple' kubernetes cluster. This has been a big learning driver for me, as I've not had much experience with setting up deployment environments, managing compute resources, or setting up scalable software.
The core use cases for this is hosting my own projects, with cross-platform ones taking priority. In fact, this very website is hosted on it at this moment! the gym log book back and front end is hosted on here as well, as its current evolution requires a central server, although it is not set up to be the most scalable service in the world.
There are other project being hosted on this. one is a kind of service provisioner, a kind of kubernetes, but only for deploying docker based services, this runs on the control plane Pi, as it currently hosts a Minecraft server for myself.
Gym Log Book is a full native Android app I built to help log my strength training progress. It features structured navigation, local data persistence, with plans to display graphs and support more exercise types.
When I started at the gym, I wanted a way of logging my progress. Whist I found lots of apps that could help with this, I found most of them to have complex functionality or had lacking UX. So I decided to create my own app.
After starting with some Apple shortcuts, I got the basic idea of what I wanted to include. Settings for free weights, or machines; Auto complete for sets; a list and possibly graphs for progress. All of which expanded my knowledge of Android app development.
My portfolio site is a place for my thoughts, side projects, and a sandbox for testing new things. Whilst this is a testing ground, i have a few rules that i try to follow.
Firstly, this website will not be using javascript frameworks. This is due to wanting as pure as possible kotlin backend and frontend. Some sections and projects might feature other languages, but they will be imported from CDNs (most likely github) and loaded, using prewritten 'static' scripts as a kind of bootstrap. This allows the strucutre and majority content to stay as structured, static HTML.
Now the HTML is generated within the server using Kotlin, Ktor, and Ktor-html, a library for generating HTMl as a DSL from Ktor. This means i can get the best of reusable components, without using a specialised templating engine.
Secondly, design is not my strong suit. Especially with using CSS to style HTML. for this reason, I've imposed some guides for writing pages. HTML features semantic tags. Things like section, article, main, and nav. These all serve specific purposes in a web page. So i've designed my pages to utilise these for content structure. sections hold articles, articles contain paragraphs, and so on.
With the page defined using these tags, defining styles fits around the semantic meaning of the tags, rather than arbitrary classes. for now, there is only paragraph containing articles, but there could be a class of article than has an image. this links a tag, with a "class" of said tag, preserving semantic meaning.
Finally, This site shall have its deployments be fully automated. This is so i can properly learn how to make and host full kubernetes applications. Whilst also being an example for other projects. It won't be perfect, but it will be a good start to making my life easier.
kotlin is my primary programming language. This is due to its flexibility between working on backend, frontend, and native applications. Whilst i have experience using industry standard frameworks, such as spring boot, i prefer to use Ktor and kotlin multiplatform.
Ktor is a client and server http toolset for kotlin. it is written in kotlin almost entirely, with native parts to match platform specifics. This means i can have a kotlin backend, with a compose and Ktor website, desktop, and native frontends.
I am a fairly big proponent of the mono-repo. One repo with code, config, tooling and CI/CD. Ktor allows me to achieve this. In fact this website is written using Ktor. It has a familioar functional api like express, allowing easy extensibility, and readibility
Kotlin multiplatform is the base for end-to-end kotlin applications. I use it for almost all my applications, when i need a native application. When combined with Ktor and Kotlin compose, it provides the most complete toolset for building full stack applications. An example of this is my gym log book app, where the fromtend is a desktop and a web application combined into one.
Rust is my current go to for projects that have well defined states. This is because of a number of it's features that focus on provable correctness.
As a systems language, it is fast. Rust compiles to machine code directly. So when compiled with optimisations, it is faster than the JVM, python or other virtual machine languages. This also means that a lot of memory management is also 'manual', but can be automatic when explicitly chosen. So it doesnt try to hide the inner workings of operations.
As rust has a focus on correctness it has an algebraic type system. This allows application states to be defined in such a way where invalid states can be entirely removed. For example in kotlin, you have sealed classes, which is a way of defining x i find to be the best for describing application state. allowing me to eliminate invalid states for my work, whilst forcing states from other frameworks to be reasoned into valid states for my use. Finally, The compiler (in general) is able to pinpoint where an error is, and often provides fixes where possible. This along with tools like clippy, allows correct and clean code (not the OOP clean).
I dont use this language as much as i would like. However, i did want to mention it for some of the principals Entities.it follows.
First, let it crash. most programming is done defensively, try statements, if guard blocks, etc. Elixir discards this mentality. The principal is, fail early, log the issue, reset the state to a fresh slate. This allows errors to be flagged quicker, and program state to be saved. this combined with the second principal allows errors to be discovered quicker.
The second principal follows from the usage of "processes". these are green threads, and Erlang / Elixir uses them everywhere. the second principal is supervise and recover. a supervisor is a process that monitors child processes. When a child process dies, the supervisor is notified and decides what to do next. This provides the 'let it crash' its ability to not take down the entire program.
Entities.Because of these principals, and the Elixir language itself, i think it's a good mention. As its philosophy, whilst not makking perfectly onto kotlin or rust, can be used to make decisions.