DEV Community: Kyle Buzby

2022 Year in Review

Kyle Buzby — Sat, 24 Dec 2022 01:34:34 +0000

Reflecting

The last time I wrote something looking at what I’ve done and what I plan to do as I go forward was in March of 2021. At that time I was 3 months into a new position, and more specifically just started as a new team lead. I was working with some peers and in a team of 5 including myself, and with such a small team I was still doing 50-75% coding and learning a lot about our products.

I entered into this new company and position with the mentality that I was going to succeed by asking questions, whether that's to fully understand what I’m working on or a question to advocate for change in the company or even just for myself. In other words, don’t let things just be told to me or just happen to me. I am happy to look back and recognize that I continued to hold this mentality to the current day and that it has continued to benefit me. I also recognize that it requires a ton of psychological safety and a healthy environment to take those risks, and I’m super lucky to have that where I work now.

Among the things I advocated for, one that I’m particularly proud of is when I pitched a new role in our development group to focus purely on internal tools and infrastructure so that we can help keep things running smoothly on the inside. Both my VP of Engineering (now CTO) and CTO at the time gave me their support to post the position, and we had a perfect candidate apply within just a few weeks. Since then he has proven countless times the amount of value this position provides to our development group by introducing new automated integration testing, troubleshooting and improving the reliability of our build servers, and even overhauling a lot of our onboarding documentation.

A little before that my team had suddenly grown from 5 to 9 within the span of a few short weeks. At that point, I was no longer able to code not only due to the number of people, but the scope of my team was continuing to expand. I honestly didn’t have much time to even consider it, but reflecting on that time I was nervous about stepping away from daily coding. I still have this concern sometimes, but I’m also getting more confident in my skills as a leader and manager.

As I’ve already said before, I’m thankful to be in a supportive company, but it has also shown in that I think all of the things I’ve recognized in myself over the last year and a half, have also been recognized by the folks that I work with. One thing I had identified early on was that we have tech stack-centered teams (e.g. an API team, a UI team, and basically an “everything else” team), and as we grow it was showing that it was not an efficient structure to deliver on real features. A little bit ago my CTO approached me and said he thought it was time to make that kind of change, and that he wanted me to lead the restructured team. He totally acknowledged that I don’t have the track record to prove that I have done that job already, but that he believed that I could do it. That confidence and chance taken on me is an incredible feeling, and I’m very excited to start the new year as a Director of Engineering leading a development group that is more than double the size of the team I led the last year and a half.

This has been a very career-focused year for me, and I am ok with that, but I also recognize that I need to improve on making my life more balanced with personal enriching activities. Despite that, this year did have a lot of great things too. I found a new outdoor hobby in paddle boarding! Despite Wisconsin having basically 6 months of winter, the other 6 months are pretty great for outdoors and there are tons of lakes in the area. Finding a way to get on the water has been an enjoyable way to enjoy the outdoors in the midwest.

By far, the best personal life event from the past year has been developing a new friendship that has given me a new best friend. Not only has it been great to have another person so close in my life, but our friendship has been able to develop into a (growing) chosen family.

Looking ahead

I’m really excited to see what comes this year, both at work and personally. Obviously, at work, I have a huge amount of growth ahead of me as I learn how to lead managers instead of a direct team and lead a larger scope. But even within that, I have a couple of major goals and a few more general ones.
The biggest thing I want to see with this new team is that it gives the developers on the team more ownership and accountability for the actual product that we ship as a company. I plan to make sure that they are involved in refining requirements, which will require a greater product understanding and expertise. We’ll also be able to have more ownership and focus on getting feedback from our stakeholders throughout the project. I’ve loved doing this as a developer in the past (even if not in the moment), and I hope that it helps bring the developers on our teams closer to the people that they are solving problems for. In addition to the individual developers, I hope that I can work with the leads, several of which are leading a small team for the first time, in order to help them feel comfortable leading and able to feel an even greater sense of ownership for the areas their teams cover.

Among all the things required for me to learn how to manage with a layer of indirection, I’m nervous but also excited to learn how to lead a team where I no longer know how the majority of the code works at a low level. I’ve preached since day one of being a team lead that leads should not be expected to know everything about the code in their area, and it's often a mistake to try and do so, but I still found myself trying to do this in the past year and a half - however, with 200% or more code that falls into my scope, it is unreasonable for me to think I can do this at all at this point.

There are tons of little goals that I have for work this coming year, but most importantly in the coming year, I want to really focus on continuing to make time for non-work related interests. Reflecting and remembering the interest I developed in paddle boarding this past year has me excited to continue that activity as soon as the weather allows. Until that happens, I hope to get into a routine with yoga again in the coming year - since the pandemic started I’ve had routines continue to get messed up as we would go in and out of quarantine, but now that things are more “stable” I want to get back into it. That being said I’m nervous about trying to establish a new routine right at the start of the year when I know I’m also going to be getting major surgery right away in March that will inevitably reset that routine all over again.

I’ll close this out with a cliché that I hope to continue writing more. In the past, I wanted to write because I thought it was just a good idea, and potentially wanted some attention, but now I would like to get more practice writing to improve my effectiveness as a communicator so that I can harness my influence as a leader in my new role.

Setting up a wildcard SSL with Let's Encrypt and Nginx

Kyle Buzby — Sat, 29 May 2021 00:00:00 +0000

Let's Encrypt has been a fantastic resource for any independent developer trying to stand up
a website on their own with the smallest amount of hassle. Some years ago SSL wasn't the default
choice and the process was expensive, tricky, and generally reserved for the companies who could
devote time and resources to actually figuring it out. Let's Encrypt along with its CLI tool,
certbot allow for the simple method of obtaining and retrieving a SSL site for your website.

The default instructions are aimed at setting up SSL for specific sites that you manage. However,
if you have multiple sites all under the same domain, and running on or proxied through the same
server, it can save a lot of time to have a wildcard certificate. This means that the SSL cert will
apply to any subdomain of your overall domain without having to update the certificate.

Unfortunately, certbot is unable to handle automagically configuring your webserver to apply
the certificates because you have to prove you have ownership of the domain through some DNS
challenge entries. Since domains are managed in a number of ways and require an additional layer
of authentication it's a manual process to update these certificates, which has to be done every
90 days.

Generating Certificates

The first step to setting up wildcard certs is installing certbot.
This can be done be following the instructions on certbot's site.

The software choice does not really matter because we'll be using a manual challenge method as opposed to
the automatic methods that can be used with those specific web server options.

Once certbot is installed the method of generating certs is:

sudo certbot certonly --manual --preferred-challenges=dns --server https://acme-v02.api.letsencrypt.org/directory -d \*.buzby.dev -d buzby.dev

For your own server, you'll want to replace the *.buzby.dev and buzby.dev with your own domain.

During this process certbot will pause to allow you to add TXT records to your domain with a specified key.
There will be two - one for each of the domain options specified. One thing to note is that the name of the
TXT records will be your domain in both cases. This is ok because DNS allows you to configure multiple records
with the same name by design.

Ensuring these have a short TTL (time-to-live) will help to make sure they get created / updated quickly
for the certbot authorization process.

Once this process is complete there will be new certificate files located in
/etc/letsencrypt/live/<your domain>/ ready to use!

Configuring Web Server

Now, since we had to run certbot in a manual process we have to configure the web server.
Nginx is one of the most popular, and one that I've been using for the last few years.

For your server blocks in Nginx sites you'll need four new fields to configure the site
with SSL.

server {

        listen 443 ssl; # Make sure the 'ssl' is added here as well

        ssl_certificate /etc/letsencrypt/live/buzby.dev/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/buzby.dev/privkey.pem;
        include /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

        ...

}

(again replacing buzby.dev with your own domain)

If you additionally want to force redirect the server's HTTP port 80 traffic you can configure
a second server to redirect to the HTTPS server.

server {
        listen 80;

        server_name kyle.buzby.dev;

        if ($host = kyle.buzby.dev) {
                return 301 https://$host$request_uri;
        }
}

Now all the configuration is set - restart the server and you'll have a wildcard SSL certificate
active on your server!

sudo service nginx restart

Compiling Rust programs for Synology DS418j

Kyle Buzby — Tue, 20 Apr 2021 00:00:00 +0000

Rust is a great tool because it allows compiling native code.
This means you do not need to have a runtime installed on a target machine,
but it does mean that you need to compile the program targeted for the hardware
you expect it to run on ahead of time.
Given the strength of not needing a runtime, I wanted to use
Rust to compile some small executables for my Synology DS418j.

Determining the Target

Rust has a good set of tools already to cross compile programs for a number of platforms.
Assuming that you use rustup command (which is the recommended way), the default target
installed when you install Rust is the one that matches your platform. You can see a list
of already built targets by running rustup target list.

The first step towards figuring out what I needed to target was determining the architecture that my NAS is running. I have the DS418j, which I know
is one that doesn't have one of the fancy Intel processors, and is likely a cheaper ARM processor.
After ssh'ing into the machine I was able to get this info by running uname -a on the NAS to get the following output:

Linux potabo 4.4.59+ #25556 SMP Thu Mar 4 17:52:53 CST 2021 aarch64 GNU/Linux synology_rtd1296_ds418j

The notable piece of information for me was the aarch64.

Looking at the list of targets available from rustup, the one
that most closely matches is aarch64-unknown-linux-gnu.
The breakdown of these targets is <architecture>-<vendor>-<system>-<abi>.

Compiling a Project

If you don't already have a project to compile then running cargo new <executable name> will scaffold out the folder for you.

Installing toolchain dependencies

We need to install some dependencies first in order to compile.

First, we need to get the base rust crates to compile our project against. This is done with rustup:

$ rustup target add aarch64-unknown-linux-gnu

This installs the crates into your dev environment allowing you to use this as a target across any project.

Second, we'll need to install the gcc tools to be able to have a linker that will link our binaries to the ones we expect to be on the target system. The real simple way to do this is installing all gcc-aarch64 tools with the following:

$ sudo apt-get install gcc-aarch64*

Now, the environment is all prepped.

Configuring the project

The Rust project still needs a bit more information in order to find the right linker to use for the given target.
This is done through a cargo config file.
From the root of the Rust project you can create a .cargo folder, and a config file within it.

In the config file the following block needs to be added to tell cargo to use the specified linker when compiling for the given target:

[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

Compiling!

Finally, the project is ready to compile

$ cargo build --target=aarch64-unknown-linux-gnu

After building you can copy the created binary from the target/aarch64-unknown-linux-gnu/debug folder to the target machine and run it to verify it works!

Reflecting and looking forward

Kyle Buzby — Sat, 27 Mar 2021 18:59:29 +0000

2020 was a year of significant growth for me - I had started with a set of goals, some quite lofty, and some that I could just not prioritize at this time. Ultimately, I feel like I ended in a place where I was more confident in myself and put myself into a place that has given me a chance to sky rocket my growth at the start of this year.

2020

At the start of last year I was working at Epic Systems, 6 months into my official role as a "Software Developer". I worked incredibly hard while working to get the experience and qualifications necessary to reach that level, with the support of my partner and my team lead at the time.

My work leading up to that transfer led me to be trusted with some deep technical projects on our team, and previous experience as a Software Test Engineer put me in a strong position to help out with performance. The projects were hard, but not just technically or in terms of functionally, but in terms of timelines imposed by project leads and expectations. This wasn't just my team but across the company - it also didn't feel like it was out of the norm.

On top of this since I was new to the role I felt like I was constantly fighting to "prove" myself. I was told that I shouldn't, but my base personality just can't help but feel competitive and making sure that I'm doing "good enough". This was compounded by the fact that I was only paid at the starting salary of a new developer (who are commonly hired directly out of college). My team leads tried to assure me I had to "room to grow" and I had nothing to prove, as I was already a high performer - but why wasn't I paid like one?

Ultimately, I did not feel this was right and found a new job by the end of the year. I was extremely down by no longer feeling supported where I previously was, and had wanted to give so much time back to.

Despite ending on a bitter note I was extremely proud of where I was. I learned how to value myself, the value of my time, and am starting to value my knowledge beyond the level of a "new developer". I had experiences with team leads who were actually not as supportive as the ones I've had in the past, and taught me how to ask more for what I need for guidance in order to grow.

2021

At the start of 2021, I begin the first workday at a new company, one much much smaller than I had spent the last 5 years in. It was refreshing. The proceses are flexible, the culture is more relaxed, people have more ownership. It took me no time to get up to speed on the technologies that I was not familiar with (largely Docker), and I was quickly able to contribute - the best part was that I felt like I was doing a normal amount of work, but it was called out as pleasant surprise. I now knew I was not as junior as I was made to feel at Epic.

I asked a ton of questions in my first few weeks. I wanted to know the company, why things were the way they are, and to see what can change and be made better. Despite ending a bit bitter, I learned a lot at Epic, and I feel motivated to carry some of those ideals forward, or to learn and do the things I didn't like better. I believe this has helped me to stand out among my peers. I'm used to listening more than asking questions, but I feel like I have a stronger foundation to justify the questions I'm now asking... and it's empowering.

Several weeks into the job, I asked about the potential move to being a team lead within a time frame and when everyone felt I was up to speed enough of the base workings. Our team was technically very large, too large for our current team lead to manage effectively. To my surprise this opportunity presented itself sooner than I ever expected, and now I'm currently acting as lead for my team, which is a truly exciting place to be in. I get to work on code frequently, but I now can help drive a product forward more actively, and work to give my team the best environment to grow how they need.

Looking forward

Having reached my goal from the previous year of being a team lead, but doing it a new company, I have a whole new set of things to work. This isn't the end of writing code for me - being on a small team I will still frequently get to excercise those bits of my job, and hope to continue to grow technically and to carry forward my previous experience to be a resource for my team and company as a technical leader.

But now with my new responsibilities, I hope to learn how to guide and mentor younger developers, and support and help more senior developers still get what they need out of their work. I hope to grow my skills in project planning and estimation and help increase the output by my team, without putting them through death marches. I truly want my team to be healthy, and strong, and enjoy what they do. I know I'm likely being a wide-eyed naive baby team lead, and I'm going to make mistakes, but that's ok.

Most of all I don't want to lose the curiosity I've grown from being a devloper, in fact, I hope to continue become even more curious about what I can do next.

Setting up GitHub as Mirror

Kyle Buzby — Mon, 28 Dec 2020 00:00:00 +0000

Background

A common interest of mine is to own as much of my own data as possible, which largely means hosting a lot of the services that we all know and love. This one is about git, or simply put, source control for my personal projects.
Source code is something I have less of any issue being in the public domain or on someone else's server (definitely not against open source), but over the years I've seen my GitHub profile become inundated with these small side project repos that are never touched after a few commits. So in order to keep that a little more groomed I've maintained my own git repo on my local Synology NAS device.

All that being said there is only so much you can do with git on a local NAS, and if you want to do more like CI/CD you'll be rolling your own or setting up a bunch more services.
One feature I wanted was automated deploys of my website - I had some simple bash scripts running for a while and even involved a second server, but it was more than I wanted to maintain and became clunky after I started letting the second server sleep. What I really wanted was something like GitHub actions

Enter mirroring.

Setting up GitHub to mirror

The first step to setting up a GitHub mirror is to create your repo normally, but make sure to leave it empty / bare, otherwise you'll have to be a little --forceful to make things work.

A simple option would be to set a second remote in your working copy in order to commit there as well, but that would involve remembering to set it up each time you (or someone else) checks out the repo as well as intentionally add commits there.
This is a sure-fire way to make sure the mirror gets out of sync.

So, we'll want to have the private remote repo commit directly to the mirror. On the private remote repo add the GitHub repo as a remote using the same command as you would in a working copy where github-mirror is the name I chose to represent that remote URL.

git add remote github-mirror <github git URL>

Mirroring your commits

Traditionally mirroring is a full clone of a repository - including all branches, tags, etc. This is done with the --mirror option when performing a clone / push. This flag creates / updates a cloned repository to be a "mirror" of the remote as opposed to a standard "working copy". GitHub has some official mirrors, but there is no built in support to handle this for you.

If you want GitHub to be a full mirror then you can simply use the --mirror flag in a push command such as

git push --mirror github-mirror

This will push all branches from your remote repo to the mirror, so if you're like me and want to restrict this to only the main branch then you can push specific refs.

The command to push commits from only one branch on a remote to another branch on a second remote is:

git push github-mirror main:refs/heads/main

Dissecting this command we have the first two pieces, git push, which is the standard command for pushing commits to a remote.

The third piece is github-mirror which is the name of the remote created above. This can also directly be a URL if you do not have a remote set up.

The fourth piece, main:refs/heads/main, is actually two in one, separated by the colon.
The first half is the name of the local branch we are pushing commits from - or in git terms, the "source".
The second piece is the destination, if it's omitted then git will try to use a branch of the same name. If one doesn't exist then it will be created.
Specifying the refs/* starting piece means that we are specifically trying to send a specific type of object to a specific location in the remote, expanding it to refs/heads/* means that we want to only send commit objects, which is applicable here since this is simple a mirror to take advantage of GitHub actions.
Finally the full refs/heads/main is specifying the precise location to update from our local main.

If you specify a destination, but not its namespace and git will try to to find the best location - most likely under refs/heads, but specificity is probably good in this case since we're moving in an direction where we automatically mirror.

Note: this will only push commits from a single branch - if you want tags as well, then you should use the --tags option to push all tags from your local tags to the remote.

As with most git commands there are a number of other flags / options / flavors of arguments that you can pass to git push. If this doesn't cover what you need exactly - then definitely check out the documentation

Automating commits to mirror

Now, that we have a command to run, we can automate updating the mirror when pushing to the private repo.

The first step will be to make sure you have SSH keys set up for GitHub repo from your remote server so you can push without interactive authentication.

Second we'll make use of server-side git hooks in order to execute this when a new commit is received - specifically the post-receive-hook, which will run once the commits have been successfully received.
Without going into too much detail, a hook is essentially a named script that is placed in the .git/hooks directory of your repo and executed at the defined time.
There are examples of all these hooks in git repos - removing the .example suffix will allow git to execute them.

Now we're ready to create a shell script to run and execute our push to the github-mirror. For my purposes, since I'm only pushing one branch - I only want to push to the mirror when commits on that same branch are received. This done with the arguments that are passed to the script when executed by git.
In order these arguments are oldRevision, newRevision, and ref.

So, with that knowledge and the example script already provided we can make a post-receive script that looks like this:

#!/bin/sh

while read oldrev newrev ref
do
if [[ $ref =~ .*/main$ ]]; # when committing to main branch
    then
        echo "Main ref received. Mirroring to GitHub"
        git push github-mirror main:refs/heads/main
    else
        echo "Ref $ref successfully received. Doing nothing: only the main branch may be deployed on this server."
fi
done

Note: it's a good idea to echo a response - the output of this script and anything it runs will be output to your local terminal when pushing to the private repo and will let you know the hook is running.

Saving that file and making sure it's named post-receive is then all you need to do to have this start running on every commit to your private repo!

Synology CardDAV Setup

Kyle Buzby — Sun, 20 Dec 2020 00:00:00 +0000

What is CardDAV

CardDAV is a simple protocol that operates over HTTP/HTTPS - in fact, it's built on top of the generic WebDAV protocol that is itself built on HTTP/HTTPS.

It allows you to have a web server implementing the protocol to provide vCard contact info a standardized format. Having a centralized server of course means that you can sync that data elsewhere.
The standard was first proposed and made popular by Apple with iOS7, from there it was adopted or supported by more services making it a fairly ubiquitous service.

Why do this?

I personally have a desire to own as much of my own data as possible, sometimes that's not easy (like running an email server), but this seemed relatively doable due to pre-built support and the network infrastructure I already have set up.

If I wanted to avoid going through the trouble of running my own server I could make use of the fact that Apple's contact management is already built on CardDAV and could sync my contacts through that account.

Setting up CardDAV on Synology Server

Synology has a great package ecosystem for their devices, so this step was extremely simple - just open the package manager on the device and install the CardDAV Server package.

Adding HTTPS by default

I have a .dev domain so everything must use HTTPS since that is a requirement set by Google as owner of the TLD, so updating this was as simple as checking the box in the Synology config to redirect all HTTP traffic to the HTTPS port.

Updating proxy config

My home network and all the services running on it are set up on my .dev domain.
Now isn't the time for details, but the gist is that I have a nginx web server sitting in front of all my services in order to access things by a clean URI (no ports). This also allows me to keep my SSL setup on one machine.

Since the CardDAV server is running on its own port on the Synology that will require setting it up as its own virtual host - paths are technically possible, but far too often services don't handle rewritten URL paths and won't function properly.

Adding the following (and replacing things in angle brackets with real endpoints) as a new enabled host, and restarting the server does the trick:

# Handle redirects to HTTPS coming through the web server
# Synology would also do this, but better to do it earlier in the stream
server {
        listen 80;
        listen [::]:80;

        server_name <new server name>;

        if ($host = <new server name>) {
                return 301 https://$host$request_uri;
        }
}

# Set up the proxy virtual host
server {
        listen 443 ssl;
        listen [::]:443 ssl;

        include <path to shared SSL config>;

        server_name <new server name>;

        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass https://<IP address of synology>:<HTTPS port of CardDAV server>/;
                proxy_redirect https://<IP address of synology>:<HTTPS port of CardDAV server> https://<new server name>;
        }
}

The last two steps to making this work are to make it accessible by the new host name on my internal network by adding a host record to my pihole (pointing it at the web server), and also a host record to the DNS config of my domain provider. I'm leaving this service open to the internet because the Synology has built in password security around accessing the service, and I want to make sure my contacts will sync up when I'm not on home wifi.

Syncing to other devices

Now that the server is setup we'll want to make use of it to get the same contact list every where!

iPhone

Since Apple's contact management is already built on top of vCards and CardDAV servers, it's a relatively simple process to point your phone to a personal server.

First step is to add the CardDAV account by going to Settings > Contacts > Add Account. From there you can fill out your server, user name, and password - if not going through standard HTTP/HTTPS ports like configured on the Synology device by default you can configure that under the advanced settings. You don't want to fill out the account URL because that will be populated by querying the server.

Second, since I've had my phone for a few years all of my contacts were stored locally, so I had to find a way to get them uploaded. To do this I made sure my contacts were synced to my iCloud account - then, once they were all uploaded exported the full list as a csv file. From there I was able to take the csv and upload it directly into the synology interface.

Next I set the default contact account on my phone as the account added by step 1 - and now everything should be synced through the personal server!

Outlook

Outlook was a bit trickier to set up because it does not have built in support for CardDAV (Exchange is the most popularly connected service to outlook which manages contacts through ActiveSync protocols).
That being said, it's easy to get add ins that enabled syncing for CardDAV and CalDAV servers. I personally used Open Protocols Connector as that just happened to be what turned up when searching for add-ins. But there are certainly more out there.
The Open Protocols Connector allows free use, but the product still requires registration by getting a registration code from the site.

The add in adds a Server ribbon tab to the workspace, which has the 'Connection' button to configure server info.

I was unfortunately not able to directly set up the server as simply as the iPhone because it was not recognizing the root server as a CardDAV resource.
It turns out it wasn't asking for the generic server as the iPhone does in order to query for the account URL - it needs the actual account URL directly.
Since i had the iPhone setup already done, I was able to pull the account URL from those settings and copy that over the computer in order to get things synced up.

After getting that last piece setup, I saw my contacts start to flow in, and then tested creating a new one to make sure it was working in both directions. Voila! Shared contacts between my two primary locations for sending / receiving email!