Recently, I worked on implementing a build system in Bazel for a complex NodeJS application managed by Yarn. Although it seemed to be fairly simple in the beginning, it quickly spun off into a headache. While the superficial reason was due to the peculiar internal structure of the repository (e.g. symlink farms, local file deps, etc.) and the relative lack of support for NodeJS in Bazel, I realized that there was a fundamental issue in the integration - the gap in the objectives of two different build systems.

In my small project of implementing a minimal DNS lookup utility in Go, I was trying to come up with a simplified logic of parsing the query response into a DNSPacket struct, which had the following structure: type DNSPacket struct { Header *DNSHeader Questions *[]DNSQuestion Answers *[]DNSRecord Authorities *[]DNSRecord Additionals *[]DNSRecord } // initialize from Reader func (dr *DNSQuestion) FromBytes(reader *bytes.Reader) error { //... } func (dr *DNSRecord) FromBytes(reader *bytes.Reader) error { //.

In my previous post, I covered how I built a basic partition-tolerant broadcast system. While it did manage to perform correctly, it was not exactly performant. There was plenty of room for performance optimizations that could be done - this post covers them. Efficiency Metrics Maelstrom, the underlying testbench for the challenge, provided a lot of metrics and charts that could be used to analyze the performance of my algorithm. Here are some of the key metrics:

Recently, I ran into an instresting challenge on distributed systems provided by Fly.io. After going through a laborious semester trying to get in touch with my inner Ninja of theory and implementation, I thought that it would be a good chance to check my understanding of the field. Check out my repo for the actual implementation in Go! Part 1, 2: Echo / Unique ID Generation These parts were really about familiarizing oneself with the Maelstrom testbench, which the challenge utilizes to abstract basic node-level operations (send, sync/async rpc, etc.

There are a plethora of different ways to setup a C++ development environment in Neovim. Here’s one possible way that I landed on after a number of (unsuccessful) attempts on Linux, integrated as a part of my dotfiles. Mason and Lsp-Zero (optional) mason.nvim is a package manager for Neovim that enables the installation of different utilities (mainly LSP/DAP servers and linter/formatters). lsp-zero.nvim provides a sweet spot between an out-of-the-box experience and configurability for setting up language-specific functionalities.