I’m a big open-source fan. Therefore, I open-source as much of my code as I can. Feel free to look around on my sourcehut, GitHub, and GitLab. Below you can view some of my favorite projects! They are listed in reverse-chronological order (newest first).
I have written many Codam projects. These are some of the biggest projects I worked on:
ft_select was about creating a TUI-option selection menu. It
would allow you to select multiple options from a list using your keyboard from
within a shell. It would then communicate the selected options to the parent
process using stdout.
The catch of this project was that we weren’t allowed to use ncurses. That would make it to easy. Instead, we needed to use termcap directly. libtermcap is an ancient library before terminal emulators existed and before every terminal emulator used the vt100 control codes.
I have written
ft_select so that it makes no assumptions about the
capabilities of the terminal. In fact, it is fully functional even when it can’t
find information about the terminal1 and it therefor isn’t allowed to send
escape sequences. (Although it won’t look as nice.)
minishell is a project where we needed to implement a small subset of a
POSIX shell. Later Codam projects will elaborate on this where we need to create
increasingly complex shells. I wrote this project together with Devanando
Kroeke. It was a nice project where we learned quite a bit about shell
We focused a lot on the code quality and commit quality of minishell. Especially with commits I tried my best to make small, self contained, and context-filling commits. Some examples would be commit ba57be4e and cff93e34.
This project required us to create our own implementation of
ls in C. I wrote
this project together with Devanando Kroeke. He is a great teammate who valued
good workflows as much as I do.
ft_ls was harder to test
ft_printf because of the sheer amount of system calls that are
required. We decided to focus on making the untestable code as small and
obviously correct as possible, usually just copying system call results to
structs. Then giving these structs to the testable code to handle. This allowed
us to write unit tests for almost all of the complex logic on
ft_ls (there is
more then you would expect!)
We based our implementation on the POSIX ls standard. Quit a few details of
which surprised us. Did you know that
ls sym_link_to_dir lists the
dir contents, while
ls -l sym_link_to_dir lists the symlink itself?
The goal of this project was to reimplement the C
printf function using only
free system calls and the four stdarg(3)
functions. All other library functions (e.g.
reimplemented in my libft project.
ft_printf together with Emily Martins. She was a pleasure to work
with and taught me quite a bit about vim. We focused on modularity,
testability and standard compliance. The
printf section of the C17 standard
(7.21.6 “Formatted input/output functions”) is a surprisingly well written and
easy to understand standard describing most of the edge cases one needs to know
about when implementing
I am using our
ft_printf for all Codam projects now and I had to
make very little changes to it since handing in the project.
For my school’s profielwerkstuk, Joppe Koers and I made a robot that you can pay using Ethereum (an alternative for Bitcoin).
We also submitted our profielwerkstuk to the 3i Award. The 3i Award hands out a price to the best profielwerkstuk (in the Netherlands) with a computer science component. On the 18th of April, 2018, we got 1st place for best HAVO profielwerkstuk! It was an amazing experience that I will never forget.
You can view the full document at noahloomans.com/pws.pdf.
Metis Rooster (2016-9-4 to present)
I created a schedule page for my school out of frustration. The old schedule page was incredibly difficult to use, especially on mobile! I started this project on the 4th of September, 2016. On the 8th of October, my school decided to use my improved schedule page instead of their old one.
This project receives a few updates a year now. I am still maintaining the server hosting this, but it has been fully automated and I only need to login to the server a couple of times a year. Security patches are automatically installed from canonicals security update repositories, and I have DigitalOcean backups in case something goes wrong (never needed to use them yet.) The NodeJS applications itself is shipped using Docker, allowing me to be confident that the same packages are installed on the server as on my local machine.