Portfolio

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, referring to 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 had a hard drive which was running my Linux server fail this December, so the source code to the original KDHC is unfortunately gone. I was using a locally hosted Git instance to store the code. I am going to try to recreate the code within the coming weeks.

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 popular choice in 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.

Metrics APIs

I can't go all that much into detail on this project, because the project still at this point has not yet went public, but I was asked to built the backend support for the metrics gathering for the tooling used by a development company that is currently leading development on an app with over 40,000 reviews on the App Store. The portion of code which I wrote is used to manage social media sponsorships and endorsements as a way of promoting products or services. It is built to collect and aggregate engagement data by leveraging a combination Meta/Instagram and TikTok APIs, in addition to custom API built to allow the extension of the metrics service to user-created metrics, such as an in-app purchase. This way, companies using the platform to promote their product are able to easily pull data to analyze which particular sponsorships are the most profitable to use.

I needed to make use of multiple technologies and frameworks which were new to me in order to write this piece of software. These technologies include next.js, inngest, and Prisma. This was a very fast-paced environment to work in, challenging my abilities to keep my features up to date in a rapidly changing codebase, as is common in many modern applications, requiring me to rebase my features to the upstream nearly every day.

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 Pomara 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.