about me

i am currently an apprentice, working in R&D for SKOV A/S

during my apprenticeship i have, among other things:

• implemented several frontend applications currently used in production, as well as committing large refactors to the codebase with the aim of better leveraging typescript's typing

• implemented a system for retrieving important customer data off of a defunct, abandoned and undocumented internal site, saving my team several tens of thousands danish crowns in consultancy fees

• both leveraged existing-, and implemented new tools to systematically catalogue CVEs for all kinds of SKOV products

• researched and tinkered with existing performance quantifying tools in an effort to make them work for the constrained environments of SKOV products

• engaged of my own volition in pair programming with my apprenticeship peers, in an attempt to either help solve their predicament or help evolve their skills, or my skills

source code: github.com/camper0008/vc2-tools

a series of tools made for the virtual computer 2 architecture. includes a virtual machine, assembler, image-to-vc2-assembly tool, and a debugger/inspector building on top of the vm

all tools are implemented in rust, and i have made an effort to leverage rust typing and idiomatic code, primarily in using sensible abstractions for an unsafe api

source code: github.com/camper0008/projm

live demo: projm.tpho.dk

a dumb (as in 'simple', 'not smart') project manager, akin to trello, github projects, jira, etc. features include creating, editing, deleting boards, columns and tasks, marking tasks as complete, reordering columns and tasks featuring a simple, snappy dragging function and easy creation of subtasks

it has a focus on being as intuitive and simple to use as possible, and it accomplishes this by only focusing on the bare necessities for a project manager. it is also quite snappy and feels good to use, unlike (in my experience) github projects - having to use github projects is what inspired me to create projm

board state is implemented using a state machine, and saving board state is done by simply saving a list of actions, which it feeds to the state machine upon loading. avoiding state corruption and overwriting is accomplished by, when attempting to commit an action, first calculating a hash of what the board would look like had that action been committed, and then feeding that hash to the storage backend along with the action. the storage backend then does its own calculation with the action and its currently commited actions. if the hashes line up, then the frontend and backend states are the same, and the action is committed; otherwise, the commit is rejected

i have leveraged my experience in rust and knowledge of the typescript typings when implementing this project - the state machine was also originally written in rust, and then rewritten in typescript, because the existing solutions for generating bindings between deno and rust were not good enough for my requirements

the rust implementation can be viewed here: github.com/camper0008/projm/tree/7bca1cf96dbcf6089c4cd90f9449b46e0cd2eae8/boardsm

i would consider myself a pretty competent sysadmin - i self host all of my projects - and in addition to that, i daily drive linux. as such, i am more than comfortable with the commandline, and linux systems. i've tried a bit of everything, hosting wise, from ubuntu server to fedora server to nixos to debian, aswell as desktop wise, debian, ubuntu, fedora, nixos, archlinux. currently, i use (and recommend) debian for servers, and use (and recommend) archlinux for desktop environments

i also have some devops experience, i.e. leveraging docker and docker-compose, aswell as using existing- or writing my own- CI/CD solutions

source code: github.com/camper0008/school-example-projects

i've been teaching people programming on various internet forums since i started being capable myself, which was around when i was roughly 13-14; as such, i have been many people's intro to programming over the years

near the start of 2025, i was given the opportunity to help educate some of my classmates that have previously had trouble learning

so far, i've spearheaded teaching flutter api integration, aswell as the "gold standard" of flutter api management, using the `provider` library

alongside that, i've made a series of videos primarily attempting to communicate my thoughts as to both "how" i write backend software, and "why" i do what i do when i write backend software

these videos were made in response to a conversation i had with a classmate, that backend, for him, did not "click" like frontend development has for him did

i have plans to make more content in the future, and have asked my classmates to inquire if there are any other subjects they want me to cover, or feel like i did not cover adequately

i hope to produce much more content like it as the years progress, in addition to more physical styles of teaching, i.e. mob- or pair- programming, which i also quite enjoy

it is a fun, new, challenge to balance getting your peer closer to make the connection themselves, as opposed to giving them the answer. it also challenges some of my own notions of how i should write things, because i am constantly questioned as to "why" i do the things i do, which is also very interesting. watching your peers have something "click" for them that they've previously had a hard time of grasping, is also a very rewarding experience

i have some degree of interest in elixir, and i would like to develop my skills further. currently, i have solved a few days in the 2024 advent of code event. - viewable at github.com/camper0008/advent-of-code

the rest is available on my github, at github.com/camper0008