Portfolio

COS

COS is a hobby operating system that I've been on and off developing for a few years heavily inspired by the structure of Unix-like kernels and Windows NT. It is still very much in the works, but the project has taught me a lot about the world of low-level development. It is hard to get real-world experience with embedded systems as a hobbyist, but the traditional x86 architecture is an incredibly complex system with many specialized chips that have to be accounted for that is very well suited for learning about the world of embedded engineering. Having to write drivers for chips such as the Intel 82077AA or Intel 8042 by reading the datasheet is a pretty good teaching experience that prepared me for my first internship where I had to work with chips that I before knew nothing about.

KDHC

I created a DHCPv4 client using the C programming language for use on Linux-based platforms. Typically, packages such as dhclient or dhcpcd are used to handle this, as, at least in the case of the former, it ties in nicely to utilities such as ifup and ifdown. The DHCP standard dictates that when an IP address has not yet been assigned, IP datagrams must have a source address of 0.0.0.0, and there is no interface to do this normally through the kernel. As a result, this forces us to format raw Ethernet frames, IP headers, and UDP headers. Luckily, since packets are returned to the leased address, it's possible to use UDP sockets to easily parse the returning data.

This project taught me a lot about systems programming. I had never really delved into reading standards for implementation before, but for this project I tried referencing only standards for how DHCP packets should be formatted, rather than reading secondary sources and reference code. My main sources for logically implementing this were RFCs 2131 (Dynamic Host Configuration Protocol) and 2132 (DHCP Options and BOOTP Vendor Extensions). In addition, I was also required to consult RFCs 791 (IP) and 768 (UDP) to help with manually formatting the headers and calculating the checksums.

I now know just about everything about DHCP (which is more complex than you might first think; it's not just a file sitting on a router that counts up), but this project gave me a very well-rounded problem to solve. Wireshark was an incredibly helpful tool to use and has countless uses. In addition, whenever writing code dealing directly with the system, you run into a lot of kernel-specific problems. Naturally, debugging low-level Linux issues was a required skill to hone throughout this project.

KeebSocial

KeebSocial, by the name, is a social media platform written by myself. It involves a full tech stack for which I was the sole architect. Utilizing both frontend and backend technologies, I created a containerized, scalable application. While the frontend is not finished, I created a fully working backend API, usable both by the frontend and is extensible for use by third parties.

The frontend was written entirely in HTML, CSS, and JavaScript, with the backend mostly written in PHP. While PHP is not the most favored choice for writing new backend infrastructure today, it still deployed very widely and is absolutely a relevant skill. Today, a language such as Python would be used to respond to API queries.

On the backend, I was able to containerize my application into different components in order to standardize its runtime environment and in order to increase its potential scalability. For example, MongoDB, the database used for the project, is run in its own Docker container, with a standard interface allowing it to be horizontally scaled by deploying additional cluster nodes, with the help of technologies such as Kubernetes. In addition, running NGINX, a web server, in its own container allows for swapping this live content server for perhaps a load-balancing caching web server in the future

This project was instrumental in teaching me about building scalable applications, and making them portable for use in vastly different environments.

KeebSocial isnt quite done yet! I still have to implement some polishing, such as adding a like button. However, the base functionality is there. You can check it out at https://social.brendanjconnelly.com/. After the like button, I want to standardize API return codes, and switch any async await instances to Promise callbacks, and I think I will consider the project finished.

FRC Programming

Much of my Java experience comes from FRC — the First Robotics Competition. Every year, this organization FIRST puts out a robotics challenge, where high school students have 8 weeks to build a robot that meets specific criteria, and then compete in national competitions. Software engineering is clearly a huge deal, and I happened to be the only member of my team that knew how to code during my time. When I was handed the position as a freshman, I made use of C++, but later transitioned to Java in an attempt to lure in some extra programmers with a friendlier language.

The final software that is produced for competition use is very complex; in 2024, our robot had six distinct subsystems. I tried to strive for precision in each different aspect of the robot; for example, our arm weighed about 20 pounds and was over 2 feet long, yet I had it calibrated such that we could control it within a quarter of a degree. Similarly, we were able to spin the flywheels to within 50 RPM of a setpoint. In addition to controls engineering, our robot made use of three different cameras which tracked positions on the field using a library built on top of OpenCV such that we could completely eliminate the need to aim the thing. I built this piece of software so well that it won multiple awards at competitions (South Florida Regional + New York Finger Lakes).

brendanjconnelly.com

I like to try to create a technical setup that isn't just quickly thrown together — I try to think out each component and plan to build up from where I begin. That's what I believe I've done with my website. It's really made up of two parts, which I divide into a "production" side and a "lab" side. There are actually two websites running off of this server; this website, and robert-sims.com.

My web infrasturcture comprises of a web server and a proxy server. Both of these servers are VMs which are running in an open-source hypervisor called Proxmox. Traffic from both of these servers is to the web server. While the proxy server may at first seem redunant, there are other HTTPS services which I would like to access over port 80 and port 443, such as node and router remote management, which have their own proxy stubs.

Proxmox allows for easy management of firewall rules by the use of AWS-style "security groups", which can be applied to a whole cluster down to an individual VM. These consist of firewall rules that fit into iptables-style chains:

The web server VM makes use of NGINX to serve static webpages (such as this one), and doubles as serving as a development server. Webpages are located in /var/web/domain.com/static/, with both sites (my own and robert-sims.com) having a respective user, so that sites can be edited without having sudo privileges. Development is primarily done over a VS Code SSH server, using ed25519 keys to ensure the security of the system.

These servers are physically stored at my house, serving content through my ISP's network. The server content is remotely synced nightly using rsync to a computer which I have running in my dorm room up at Clarkson, such that I have an off-site backup.

One of my goals is to eventually run my own mail servers! SMTP is incredibly complex, and while I've had it fully running before, with valid DKIM, SPF, and DMARC, because I'm running off a dynamic IP block none of my emails get accepted by any relevant email provider. One of my friends Luc previously ran an SMTP server which we attempted to configure as my relay, but we got stuck somewhere along the way trying to make Postfix happy. If I get the chance in the future, I will definitely try to get this set up.