Posts on Christian Bull

Using Linear Programming to strategize for a climbing comp

Wed, 09 Sep 2026 00:00:00 +0000

I recently competed in a endurance climbing comp at my local gym - “Sufferfest”. The premise is simple, climb as many routes as you can in a 6 hour period, where each climb is awarded points based on it’s grade. With harder climbs giving more points. The winning team climbed an astonishing 142 routes with routes up to 5.12d totaling 130,850 points. While we only managed 67 routes at 48,450 points. Which still managed us 9th place overall out of 33 teams.

Strategy was a common topic before and during the competition. Some teams opted to climb harder routes for more points while others prioritized volume. While harder climbs do reward more points, they come at the cost of more effort expended. Based on the final standings, it’s clear that the teams that went for more volume ended up scoring more points. Consider the examples of 5.10c and 5.11d, a 5.10c climb rewards 500 points and 5.11d is 1000 points. Therefore 2 5.10cs are worth roughly a single 5.11d. If we attempted to assign an effort to grade ratio we could theoretically come up with the perfect strategy to maximize points. That’s what I’ve attempted to do in the below Linear Programming problem.

The concept of Linear Programming is simple, using a python package called Pulp we can convert problems like the above into linear or mixed integer programming models.

First we’ll create our problem

import pulp as p

Lp_prob = p.LpProblem('Climbing-comp', p.LpMaximize)

Next we need to create our decision variables using the below charts. In this problem, the decision variables are how many climbs of each grade you should complete. The points per climb chart is provided by the comp, but the climbs_hour chart is somewhat subjective to the individual and climb. Based on our efforts I’ve estimated what I believe is reasonable. Although even making minor adjustments to these values can sway the results of the model quite a bit.

# Points awarded for each climb grade.
climbs = {
 '5.10a': 300,
 '5.10b': 400,
 '5.10c': 500,
 '5.10d': 600,
 '5.11a': 750,
 '5.11b': 850,
 '5.11c': 950,
 '5.11d': 1000,
 '5.12a': 1250,
 '5.12b': 1350,
 '5.12c': 1450,
 '5.12d': 1550,
}

# Number of climbs of each grade that can be completed per hour.
climbs_hour = {
 '5.10a': 18,
 '5.10b': 15,
 '5.10c': 14,
 '5.10d': 12,
 '5.11a': 8,
 '5.11b': 6,
 '5.11c': 5,
 '5.11d': 3,
 '5.12a': 3,
 '5.12b': 2,
 '5.12c': 1,
 '5.12d': 1,
}

# Decision variables: number of climbs completed at each grade.
climb_count = p.LpVariable.dicts(
 'climb_count', climbs.keys(), lowBound=0, cat=p.LpInteger
)

Next we’ll create the objective function. I.e. what our goal is. For this problem, we’ll want to maximize the points obtained.

# Objective function: maximize total points.
Lp_prob += p.lpSum(climbs[grade] * climb_count[grade] for grade in climbs)

Without adding any constraints, the model will simply tell us to climb an infinite number of 5.12ds for infinite points. Let’s add in our constraints to help refine our model.

The last two constraints are again somewhat subjective. Capping it at 65 climbs is to help keep it reasonable. Another rule in the comp is that for each specific climb in the gym, you may only count it up to 3 times. So capping the total number of climbs at x grade at 30 is to simulate there only being but so many climbs of a certain grade in the gym.

# Constraint: Each climb takes 1 / climbs_hour[grade] hours.
total_hours = p.lpSum(
 climb_count[grade] / climbs_hour[grade] for grade in climbs
)

# Constraint: complete all climbs within 6 hours.
Lp_prob += total_hours <= 6, 'Time_limit'

# Constraint: complete no more than 65 climbs in total.
Lp_prob += p.lpSum(climb_count.values()) <= 65, 'Climb_limit'

# Constraint: complete no more than x climbs of each grade.
for grade, count in climb_count.items():
 Lp_prob += count <= 30, f'Grade_limit_{grade}'

Let’s solve it!

# Solve problem
Lp_prob.solve(p.PULP_CBC_CMD(msg=False))

Results:

5.10c: 18 climbs
5.10d: 28 climbs
5.11a: 19 climbs
Total points: 40,050
Total hours: 5.99
Total climbs: 65.00

Unsurprisingly the optimal strategy given the inputs and constraints is volume at the upper 5.10 range. If we adopted this strategy in the competition, we would have totaled 80,100 points getting us 4th overall (2nd in our category).

As I said before, the results can vary depending on the adjustments made to the climbs_hour chart above. But I think the overall takeaway is that climbing volume at a grade you can safely repeat is the best strategy.

Soil Moisture Sensor ft. Embedded Systems

Wed, 02 Sep 2026 00:00:00 +0000

This was the final project for my Embedded Systems class. It utilized Capacitive Soil Moisture Sensors connected to a raspberry pi to monitor the soil moisture for indoor plants. With the variable weather and humidity here in the front range of Colorado, caring for fickle house plants can be a challenge at times. Utilizing soil moisture sensors to track data and set reminders when and how much to water certain house plants sounded like a fun challenge that utilized a lot of the topics and technologies we covered in the content of the class.

This set of classes was about embedded linux development. We wrote a lot of C code and learned about tooling used to create embedded systems (ex. Buildroot and Yocto). The final class in this specialization included a final project which allowed us to chose any topic or project that utilized the topics and technologies in the course. I had been wanting to diy a soil moisture sensor for a while so this was the perfect opportunity to. Although made a bit more challenging given the context of the course.

The components required for this project:

Raspberry pi 4b (or any SBC)
ADS1115
Capacitive Soil Moisture Sensor (TL555)

To connect the soil moisture sensor to the Pi, we’ll need the ADS1115 analog-to-digital converter, wired as shown above.

If this weren’t an embedded systems class, I could’ve installed the necessary drivers required onto my pi and written a few lines of python code to output sensor data in an afternoon. But of course we’ll have to do this the hard way. The end goal is to create a root filesystem, a Linux kernel image and a bootloader for our Pi to automatically spin up everything required for our project and sensor. To do this we’ll use a tool called buildroot. Which will help us automate the necessary components for our system. We’ll start out with a base linux system and include everything required to run our sensor and associated programs.

We’ll start out with a base linux system and include everything required to run our sensor and associated programs. I won’t cover all the steps involved but we’ll hit a few of the main ones.

Our repository - (repo link) structure will look something like this:

├── base_external
│   ├── board
│   ├── Config.in
│   ├── configs
│   ├── external.desc
│   ├── external.mk
│   ├── package
│ │   └── soil-moisture-sensor
│   └── rootfs_overlay
├── buildroot
├── build.sh
├── notes.md
├── README.md
├── save-config.sh
└── shared.sh

buildroot is configured as a git submodule containing the buildroot code
base_external contains all the additional configuration required
configs contains the config which has basically all the custom requirements for our specific build. It also sets up a few of the additional directories or files needed for our build.
package/soil-moisture-sensor sets up our custom programs (noted below)
rootfs_overlay anything that’s needed on the root filesystem at startup
build.sh is our build script which runs buildroot and outputs our iso file, which we then flash on our raspberry pi.

Turns out enabling all the required programs and drivers to support i2c devices on a raspberry pi via buildroot is not a common use case. There’s very little documentation online and what is there is only somewhat accurate. Buildroot offers a variety of ways to add custom configurations to your package.

The best way is via the config:

BR2_PACKAGE_I2C_TOOLS=y

Another way is through rootfs overlays:

base_external/rootfs_overlay/etc/init.d/S01i2cmodules

#!/bin/sh
# Load I2C kernel modules early at boot

echo "[S01i2cmodules] Loading I2C modules..."
modprobe i2c-bcm2835
modprobe i2c-dev

Both are valid strategies and depend on the use case. In general the more specific something is less likely you’ll be able to enable it via the config.

Finding out which method worked for my use case was a tedious task of trial and error. Eventually I was able to enable everything I needed via the config, rootfs overlays, and post build scripts.

Next up I wanted to install a few custom programs to make use of my sensors. To do this I setup package/soil-moisture-sensor that points to another git repository that contains code for my custom programs.

SOIL_MOISTURE_SENSOR_VERSION = 54e97305299831c2e53dd2559a5711a20d88050d
SOIL_MOISTURE_SENSOR_SITE = git@github.com:Christian-Bull/soil-moisture-server.git
SOIL_MOISTURE_SENSOR_SITE_METHOD = git
SOIL_MOISTURE_SENSOR_GIT_SUBMODULES = YES

define SOIL_MOISTURE_SENSOR_BUILD_CMDS
 $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D)/sensor-scraper all

 cd $(@D)/server && \
 $(TARGET_MAKE_ENV) \
 GOOS=linux GOARCH=arm64 CGO_ENABLED=0 \
 $(HOST_DIR)/bin/go build \
 -buildvcs=false \
 -trimpath \
 -ldflags "-s -w" \
 -o $(@D)/sensor-server \
 sensor-server.go
endef

define SOIL_MOISTURE_SENSOR_INSTALL_TARGET_CMDS
 cp -r $(@D)/sensor-scraper/* $(TARGET_DIR)/bin/

 $(INSTALL) -D -m 0755 $(@D)/sensor-server $(TARGET_DIR)/usr/bin/sensor-server

 $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/init.d/
 $(INSTALL) -D -m 0755 $(@D)/server/start-server.sh $(TARGET_DIR)/etc/init.d/S87sensorserver
endef

$(eval $(generic-package))

Sensor-scraper - C program that reads the sensor and outputs the current values to a file
Sensor-server - Go program that sets up a webserver to handle requests for sensor data

After all the above work I now have a pre-built image that contains everything I need to construct and boot up my pi. Starting fresh, I could assemble the Pi as noted above, install my custom iso, and have my custom programs startup on boot.

Final result - it’s worth noting tracking the soil moisture for the humble snake plant is a tad overkill. But it’s the plant I had on my desk at the time :)

Revamping this site

Tue, 01 Sep 2026 00:00:00 +0000

Shortly after creating this site I quickly pivoted to working with other tech outside of work and mostly forgot about it. I definitely missed a few good opportunities for blog posts about the topics I was pursuing. Nevertheless I figured it was time to get this site up again.

Surprisingly not much has changed with Hugo, the static site generator I used. A few config updates and a theme update and I was back underway.

On the other hand a lot has changed regarding the deployment side from 2021 to 2026. I originally had access to a k8s cluster that I deployed this to, unfortunately that project isn’t in service anymore. While it’d be fun setting up another cluster I don’t think I can justify it just to host a tiny ~25MB static website.

A simply approach using s3 and cloudfront while suffice. Apparently AWS Amplify is a “recommended” tool for this use case but comes with a higher price tag and more features that are un-needed.

Terraform made a questionable decision regarding licensing and subsequently handled the response to that quite poorly. So we’ll be using OpenTofu, an open-source fork of terraform for our infra needs.

In short, the important bits are:

resource "aws_s3_bucket" "site" {
 bucket = var.bucket_name

 tags = {
 Name = var.bucket_name
 }

...

extra resources to control the s3 bucket
...

resource "aws_cloudfront_distribution" "site" {
 enabled = true
 ...
 default_root_object = "index.html"
 ...

 origin {
 domain_name = aws_s3_bucket.site.bucket_regional_domain_name
 origin_id = "s3-${aws_s3_bucket.site.id}"
 origin_access_control_id = aws_cloudfront_origin_access_control.site.id
 }

...

various resources related to CDN controls
...

}

This deploys all the required resources on the AWS side.

Now lets setup some automation to build and deploy my site when I make changes.

One thing that’s changed in the last 5 years is the unfortunate fall of github. Which was almost inevitable given Microsoft’s purchase of it in 2018. Anyways Gitlab has been a reliable alternative for years and their CI/CD offering is pretty good.

stages:
 - build
 - deploy

# only run when changes are made to site/
workflow:
 rules:
 - if: '$CI_PIPELINE_SOURCE == "schedule"'
 - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH'
 changes:
 - site/**/*
 - when: never
...
...

build:
 stage: build
 ...
 script:
 - hugo --source site --destination "${CI_PROJECT_DIR}/public" --gc --minify
 artifacts:
 expire_in: 1 week
 paths:
 - public/

deploy:
 stage: deploy
 ...
 script:
 - SITE_DIR=public ./deploy.sh
 environment:
 name: production
 url: https://cbull.dev
 rules:
 - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

This builds my hugo site and exports it as an artifact, which the deploy job will upload to s3 then create an invalidation on the CDN.

Additionally I created a scheduled job in the Gitlab UI to run this once a week. While for this context it’s likely overkill, but it’s somewhat good practice to not let things get too stale if you’re working with external packages.

I also had to transfer my domain from squarespace to Route 53. Which was the unfortunate result of google getting rid of google domains and transferring all domains to squarespace.

CI/CD with Github Actions and Argo CD

Sun, 19 Dec 2021 00:00:00 +0000

Now that we’ve built and deployed our site. Lets setup some simple CI/CD to help speed up development and content creation (i.e. blog posts).

Github Actions

Since this is a small personal project with minimal dependencies, Github Actions is a great choice and takes advantage of free compute.

First lets setup a simple buildAndPush job that triggers off our main and develop branches. It also includes the option to manually trigger for other branches if needed.

name: buildAndPush

on:
 push:
 branches:
 - develop
 - main
 paths-ignore:
 - '**/readme.md'

 # allows manual dispatch
 workflow_dispatch:

jobs:
 build:
 runs-on: ubuntu-latest
 ...

Our job needs to:

generate build
provision docker (buildx, login to registry)
build image
push image

First some boilerplate to setup our environment.

 steps:
 - name: set env vars
 run: |
 echo "SHA=${GITHUB_SHA}" >> $GITHUB_ENV
 echo "GITHUB_REF_NAME=${GITHUB_REF_NAME}" >> $GITHUB_ENV
 - name: Checkout
 uses: actions/checkout@v2

Install Hugo and generate our build.

 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: '0.90.1'

 - name: Build
 run: cd site && hugo --minify

Setup buildx for multi-arch images.

 - name: Set up QEMU
 uses: docker/setup-qemu-action@v1.2.0
 with:
 platforms: all
 - name: Set up Docker Buildx
 id: buildx
 uses: docker/setup-buildx-action@v1.6.0
 with:
 version: latest

Lastly, a simple build and push task using the github envs we setup earlier.

 - name: Build and push
 uses: docker/build-push-action@v2
 with:
 context: .
 file: ./Dockerfile
 platforms: linux/amd64,linux/arm64,linux/arm/v6
 tags: |
 csbull55/cbull-dev:${{ env.GITHUB_REF_NAME }}-latest
 csbull55/cbull-dev:${{ env.GITHUB_REF_NAME }}-${{ env.SHA }}
 push: true

Now whenever we push/merge code to the develop or main branch, this job will build and push a docker image to our remote repository for the respective branch.

Argo CD

Next we’ll use Argo CD to sync new builds with the state on the cluster.

From Argo’s site:

What is Argo CD?

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.

Argo CD works by monitoring running applications in the cluster and compares them with the target state you’ve defined in git. When it detects it’s out of sync (i.e. you’ve pushed updated manifests), Argo automatically syncs the app on the cluster to match that target.

Let’s setup a simple Argo CD app and register it. I typically use the UI and grab the outputted yaml spec to throw in git.

project: default
source:
 repoURL: 'https://github.com/Christian-Bull/cbull-dev-infra.git'
 path: manifests
 targetRevision: main
destination:
 server: 'https://kubernetes.default.svc'
 namespace: cbull-dev
syncPolicy:
 automated:
 prune: true
 selfHeal: true
 syncOptions:
 - CreateNamespace=true

This sets up our source repo and defines the path and branch to watch for changes on.

Once created, lets ensure it’s healthy.

➜ ~ argocd app get cbull-dev
Name: cbull-dev
Project: default
Server: https://kubernetes.default.svc
Namespace: cbull-dev
URL: http://localhost:8080/applications/cbull-dev
Repo: https://github.com/Christian-Bull/cbull-dev-infra.git
Target: main
Path: manifests
SyncWindow: Sync Allowed
Sync Policy: Automated (Prune)
Sync Status: Synced to main (3982373)
Health Status: Healthy

GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
 Service cbull-dev cbull-dev Synced Healthy service/cbull-dev unchanged
apps Deployment cbull-dev cbull-dev Synced Healthy deployment.apps/cbull-dev configured
extensions Ingress cbull-dev cbull-dev Synced Healthy ingress.extensions/cbull-dev unchanged

Finishing up

Now that we’ve switched to defining the state of our manifests in git, we need to find a way to update the image reference when we release updates.

While there may be a more elegant way to achieve this, I made a simple deployment template with a filler value in the image reference and use sed to generate the final deployment spec.

 containers:
 - name: cbull-dev
 image: csbull55/cbull-dev:SED_imageName

Let’s add a quick deployment job on the app repository to generate the manifest and commit it to our infra repo.

name: deploy

on:
 workflow_run:
 workflows: ["buildAndPush"]
 branches: [main]
 types:
 - completed

jobs:
 on-success:
 runs-on: ubuntu-latest
 if: ${{ github.event.workflow_run.conclusion == 'success' }}
 steps:

 - name: Checkout
 uses: actions/checkout@v2
 with:
 repository: Christian-Bull/cbull-dev-infra
 token: ${{ secrets.CBULL_PAT }}

 - name: set env vars
 run: |
 echo "SHA=${GITHUB_SHA}" >> $GITHUB_ENV
 echo "GITHUB_REF_NAME=${GITHUB_REF_NAME}" >> $GITHUB_ENV
 
 - name: update deployment spec
 run: sed 's/SED_imageName/${{ env.GITHUB_REF_NAME }}-${{ env.SHA }}/g' manifests/.templates/deployment.yml > manifests/deployment.yml

 - name: Create Pull Request
 uses: EndBug/add-and-commit@v7
 with:
 branch: main

Deploying a static site on Kubernetes

Thu, 16 Dec 2021 00:00:00 +0000

Alright now that we’ve gotten the boring first-blog-here’s-how-I-created-my-website-post post out of the way, I can actually talk about something cool.

Deploying a static website on Kubernetes (k3s in this case) is rather easy. A few benefits of running a static site are the minimal dependencies and no frills deployment. Which in turn results in extremely simple manifests.

Create a minimal nginx:alpine based docker image.

FROM nginx:alpine
COPY site/public /usr/share/nginx/html

Build and push that image to a remote registry.

Namespace spec.

apiVersion: v1
kind: Namespace
metadata:
 name: cbull

Create a basic deployment spec.

apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: cbull-dev
 name: cbull-dev
 labels:
 app: cbull-dev
spec:
 selector:
 matchLabels:
 app: cbull-dev
 template:
 metadata:
 labels:
 app: cbull-dev
 spec:
 containers:
 - name: cbull-dev
 image: csbull55/cbull-dev:main-latest

Create a service to expose it as a ClusterIP. Note the selector on both the deployment and service spec. Our nginx base image exposes port 80 by default and the targetPort defaults to whatever the port is set to, but might as well make it explicit.

apiVersion: v1
kind: Service
metadata:
 name: cbull-dev
 namespace: cbull-dev
 labels:
 app: cbull-dev
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 selector:
 app: cbull-dev
 sessionAffinity: None
 type: ClusterIP

Create an ingress with our service as our backend target.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: cbull-dev
 namespace: cbull-dev
 labels:
 app: cbull-dev
 annotations:
 acme.cert-manager.io/http01-ingress-class: external
 cert-manager.io/cluster-issuer: letsencrypt-prod
 traefik.ingress.kubernetes.io/redirect-entry-point: https
spec:
 ingressClassName: external
 rules:
 - host: cbull.dev
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 serviceName: cbull-dev
 servicePort: 80
 tls:
 - hosts:
 - cbull.dev
 secretName: cbull-dev-acme-certificate

Lastly make a dns entry with my domain provider that points cbull.dev to the external ingress controller I’ve selected in the ingress spec.

Sit back and relax as cert-manager handles the entire interaction of requesting a cert with letsencrypt. It even sets up a temp response pod to answer the domain verification challenge. On re-deployments it checks if the cert secret exists and is valid, and requests another if that’s not the case. Although manually deleting the secret resource can force another request.

It’s worth noting that letsencrypt does have rate limits on their production instance - https://letsencrypt.org/docs/rate-limits/. So I’d recommend using their staging environment when testing. Once ready, simply adjust the annotation and delete the secret to request another.

Creating this site

Wed, 15 Dec 2021 00:00:00 +0000

I’ve been floating around the idea of creating a personal site ever since I got started in tech. The issue being I created an unrealistic goal of writing it from scratch with whatever web framework I was using at the time. I’d spend a few hours setting up the backend then stall out when it came time to build out the frontend. Even at the start, I had zero aspirations of doing web development for any duration of time. So honestly I have no idea why I got this thought in my head.

Fast forward to now, where I’m rather far removed from web development which allows me to disregard current trends. When researching a tool I had a general idea of what I wanted but had little idea what was out there. I quickly came across static site generators and that seemed to fit the bill.

A few requirements:

simple design
pages/blogs editable in markdown
no javascript

A rather quick search led me to Hugo, an open-source static site generator written in Go. With a simple content management model and a large library of themes to choose from, this seemed like the best choice. Plus, another tool written in Go is always welcome.

Following their quick start guide I was up and running in a matter of minutes. Now I’ll skip over the hours I spent testing out themes and say I ended up going with etch. It fit all my requirements above and seemed to fit my use case.

While developing, hugo comes with it’s own webserver with live reloading enabled.

✗ hugo server

Hugo uses a simple toml/yaml config file for configurations.

baseURL = 'https://cbull.dev/'
languageCode = 'en-us'
title = 'Christian Bull'
theme = "etch"

[params]
 copyright = "Copyright © 2021 Christian Bull"
 dark = "on"
 highlight = true

[menu]
 [[menu.main]]
 identifier = "about"
 name = "about"
 title = "about"
 url = "/about/"
 weight = 10
...

[permalinks]
 posts = "/:title/"

[markup.goldmark.renderer]
 # Allow HTML in Markdown
 unsafe = true

Custom pages go in the root on the content folder. Blog posts get their own file in the posts directory.

content
┣ posts
┃ ┗ creating-this-site.md
┣ _index.md
┣ about.md
┣ contact.md
┗ posts.md

Outputs the final site to the public folder.

✗ hugo --minify

Throw it into a simple docker configuration.

FROM nginx:alpine
COPY site/public /usr/share/nginx/html

✗ docker build -t csbull55/cbull-dev:test .
✗ docker images csbull55/cbull-dev:test
REPOSITORY TAG IMAGE ID CREATED SIZE
csbull55/cbull-dev test 52c1460df6ba 3 seconds ago 26.1MB

Outputs a tiny ~25MB image. Although I’m sure that could be reduced further but that’s not a priority right now.

✗ docker run -p 8080:80 csbull55/cbull-dev:test