Articles by ryan

While talking to a colleague of mine he had mentioned something called Uptime Kuma, which is an open source alternative to Uptime Robot. This was interesting for me because I have Uptime Robot checking a couple of my websites and I thought, "Hey, maybe I can use Uptime Kuma as a replacement for Uptime Robot."

I dove into the docs a bit and discovered that there was a Docker image for it, which was nice.

I then used Claude to take the docker run command

docker run -d \
    --restart=always \
    -p 3001:3001 \
    -v uptime-kuma:/app/data \
    --name uptime-kuma louislam/uptime-kuma:1

and turn it into a compose file, which gave me this

version: '3'

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma:/app/data

volumes:
  uptime-kuma:

Next, I took the output of that compose file and asked Claude to also generate a caddy configuration for me and it gave me this

monitor.yourdomain.com {
    # Enable compression
    encode gzip zstd

    # Add security headers
    header {
        # Enable HSTS
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        # Prevent content-type sniffing
        X-Content-Type-Options "nosniff"
        # Referrer policy
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    # Reverse proxy to Uptime Kuma
    reverse_proxy localhost:3001
}

I then SSH'd into one of my servers using Shellfish ¹.

I updated the docker-compose.yml file and my Caddyfile to include what Claude had output.

I restarted my docker containers and didn't get my new container running.

So I took the whole Docker Compose file from my server and I put that into Claude and said,

Hey, is there anything wrong with my Docker Compose file?

It indicated that there were some issues and provided updates for. I made those changes and did the same thing with the Caddyfile. Again, Claude offered up some changes. I applied the recommended changes for the docker-compose.yml file and the Caddyfile stopped and started my docker containers.

I suddenly had an instance of Uptime Kuma. All in all, it took about a half hour from start to finish while I was watching a hockey game ... from my iPad.

I didn't really have to do anything other than a couple of tweaks here and there on the Docker Compose file and a couple of tweaks here and there on the Caddyfile. and I suddenly have this tool that allows me to monitor the uptime of various websites that I'm interested in.

As I wrapped up it hit me ... holy crap, this is an amazing time to live². You have an idea, Claude (or whatever AI tool you want to use) outputs a thing, and then you're up and running. This really reduces that barrier to entry to just try new things.

Is the Docker Compose file the most performant? I don't know. Is the Caddyfile the most secured lockdown thing? I don't know.

But for these small projects that are just me, I don't know how much it really matters.

1. this is an amazing app on the iPad, highly recommend ↩︎
2. Yes, there's also some truly horrific shit going on too ↩︎

Posted by ryan on Thu 08 May 2025

The Origin of Systems

When thinking about systems it's easy to think that they have always been there, or been that way. This isn't true of course. The systems that are in place were put there, by people. People that made decisions. Decisions are what I want to focus on here.

In general when making a decision about the implementation of a system you would want to engage with the stakeholders of that system. This of course implies that you can identify at least some of those stakeholders.

But sometimes there aren't any key stakeholders other than regulations, or best practice, or some other nebulous thing that needs to be met. These are the decisions I really want to focus on.

The Illusion of Success

Take a security system for instance. The basic tenets of the security system are that it keeps 'something' safe. If the thing to be kept safe is still safe after the implementation of the security system then the people that implemented the system can claim success. They can look at the evidence that since the security system was put into place the thing has been kept safe.

Of course, it's entirely possible that the thing was never in danger, and that the previous system was doing just fine. In fact, it could be that the security system is actually making it harder to keep the thing safe. It's just harder to see because all you're looking at are potentially meaningless metrics like. Questions like is the thing safe after implementation of the security system don't take into account if the thing was 'unsafe' before? This can lead you to think that the new security system must be responsible for the safety of the thing.

Something else that can be happening is that the security system has caused the people responsible for keeping the thing safe to work more hours, hire more people,who are oftentimes keeping the security system running.

Questioning Purpose

The more we look into a system like this, the more we might ask, "Why is it there?"

There can be a couple of reasons, but I'll focus on one in particular. The person ultimately responsible for keeping the thing safe can show with some kind of metrics that the thing is safe with the new security system, whereas they couldn't under the previous system. There weren't any reports or metrics that showed what was going on, which is why the system was implemented in the first place.

OK ... so that's how some systems can be put in place.

User-Hostile Systems

What about systems that are hard to use, or maybe actively hostile to their users? How do those get put into place? I would argue that the reason we see many user hostile systems in place is because they are decided upon not by their users, but by their ability to meet regulations, AND their ability to maintain by a support system. The consideration of the user is secondary, or maybe not even thought about.

Think about any Enterprise software you've ever encountered. Would you say that it was a joy to use? Would you say that onboarding was simple, and that new employees loved to use it? My guess would be no.

Why Bad Systems Persist

So if the users don't like it, why is it in place? Two reasons:

1. It meets some kind of regulation (this could be a government regulation, but it could also be a regulation of a guild, or union, or something else)
2. It's easy to maintain by the support system

For any software that meets these criteria you are likely to have users that don't like the software, because they are always an afterthought. The primary responsibility of the software developers of these types of systems is always the regulators, and the support infrastructure.

The first because they have to keep producing software that is compliant in order to be sold with a specific rating or seal of approval.

The second because if the support team can't easily support it, they're going to find an alternative solution that they can support.

Conclusion

It's a simple decision of maximizing for the people that enforce the rules (regulators) and that make the decisions (support). The users of the software don't matter. At all.

This is why you will see software for widget processing that could benefit from bulk operations, keyboard shortcuts, or being browser agnostic and they just aren't. The only considerations are: Does it meet the regulations? Is it easy to support? If the answers are yes then the users tend to lose out. They don't matter. If the answer is no, then find a competitor that does and move over to them, even if the current system is loved by your users.

Posted by ryan on Mon 31 March 2025

In every organization, three critical elements determine success: People, Processes, and Priorities. While all are essential, their ranking matters profoundly. Based on my experience across several organizations, I've found that Processes must come first, followed by People, with Priorities anchored firmly at the foundation.

This deliberate ordering—Processes at the top, People in the middle, and Priorities as bedrock—creates the most stable and effective organizational structure. When Processes guide how People work and how Priorities are determined, organizations can avoid the chaos of constant priority shifts, reduce dependency on specific individuals, and create consistent frameworks for decision-making.

Defining Terms

Let's define what each of these mean from an organizational perspective:

1. Processes - How to solve the problems
2. People - Who will solve the problems
3. Priorities - The order in which to solve the problems

Process

In my experience ranking Priorities first leads to lots of changes to Priorities. This week it's shipping a new feature to make all of the buttons cornflower blue ... next week it's adding AI to the application. The week after that it's to mine bitcoin. Priorities shift, and that's OK, but priority driven organizations seem to not have a true defining north star to help guide them, which in my experience that leads to chaos.

Ranking People first sounds like a good idea. I mean, who doesn't want to put People first? I have found however that when People are prioritized first bad things can happen. Cliques can form. Only Sally can do thing X and they're out for the next three weeks and no, there isn't any documentation on how to do that. Management can be lax because that's just Bob being Bob and can lead to toxic work environments.

I think that putting Process first helps to mitigate, though not outright eliminate, these concerns.

Processes help to determine how we do thing X. If Sally is out, that's OK because we have a Process and documentation to help us through it. Will we get it done as quickly as Sally would have gotten it done? No, but we will get it done before they come back.

Processes also help implement things like Codes of Conduct. Again, that won't prevent cliques from forming, and no it won't keep Bob from being a jerk, but it creates a framework to help deal with Bob being a jerk and potentially removing them from the situation entirely.

Processes can also help with prioritization. Having a Process that helps to guide HOW you prioritize can be very helpful. This doesn't prevent you from switching up your Priorities, but it does help to keep you focused on something long enough to complete it. And when you need to change a priority it's a lot easier (and healthier) to be able to point to the Process that drove the deicsion to change versus a statement like, "I don't know, the CEO saw something on Bloomberg and now we're doing this."

Setting up Processes is hard. And in a small environments it can seem like it's not worth it. For example, asking "Why do we have a 17 page document that talks about how Priorities are chosen if it's just a handful of People?" Yes, that IS hard. And it might not seem like it's worth it. But you don't need a big long document to determine a Process on how to change Priorities. It can be as simple as

We are small and acknowledge that change is required. We will only change when a consensus of 60% of the team agree with the change OR if the CEO and CFO agree on the change.

More complicated Processes can come later. But at least now when a change is needed you know HOW you're going to talk about that change!

People

What comes second? I find that People should be next. It's the People that are going to help make everything happen. It's the People that are going to help get you over the finish line of the projects that are driven by your Processes. It's People that will work the Processes.

Once you have good Processes and good People, then you can really start to set Priorities that EVERYONE will understand.

An Example

My least favorite answer to the question, "Why do we do it this way?" is "I don't know."

In my opinion this points to a broken culture. It could be that when you started you did ask questions, but you were shot down so many time for asking that you just stopped asking. It could be that you're not very curious and someone just told you and didn't provide a reason and you just accepted it as gospel that this is the way that it needs to be done.

The reason why this is a toxic trait is that you can have a situation like this occur

While working on a report a requester indicated that the margins weren't quite right and it was VERY important that they be 'just so'. I met with the requester and asked them about the Process and it went something like this:

When I drew out the flow and asked the requester why, they said, "I don't know, that's just how Tim trained me"

I was fortunate that Tim was still at the company, so I called him and asked about the Process.

He laughed and said something to the effect of, "They're still doing that? I only had that in place because of an issue with a fax machine 8 years ago but IT fixed it. Why are they still doing it that way?"

"Because that's how they were trained"

🤦🏻‍♂️

Always understand why you're doing a thing. Always. This points to the need for Process, and why I place it first. Process matters and it helps to inform the People what they need to do.

Priorities

Why are Priorities last? How can something as important as Priorities be last?

I would argue that Priorities should be the bedrock of you organization and they should be HARD to change. Constantly shifting Priorities leads to dissatisfaction, and burnout. It can also lead People to wonder if what they do actually matters. If it's always changing, why should I care about what I'm working on right now if it's just going to be different later today, tomorrow, or next week.

The interplay between Processes, People, and Priorities forms the backbone of any effective organization. By putting Processes first, we create the infrastructure that enables People to thrive and Priorities to remain stable. Good Processes provide clarity, continuity, and a framework for decision-making that transcends individual preferences or momentary urgencies.

When organizations understand that Priorities should be difficult to change—and that a clear Process should govern how and when they change—they protect their teams from the whiplash of constant redirection. This stability doesn't mean rigidity; rather, it ensures that when change does occur, it happens deliberately, transparently, and with organizational buy-in.

Whether you're leading a startup of five People or managing departments within a large corporation, begin by examining your Processes. Are they documented? Do People understand not just what to do, but why? Is there a clear Process for establishing and modifying Priorities? If you can answer "yes" to these questions, you've laid the groundwork for an organization where People can contribute meaningfully to Priorities that truly matter.

Remember: Process first, People second, and Priorities as the bedrock. Get this order right, and you'll build an organization that can handle change without losing its way.

Posted by ryan on Sun 09 March 2025

I went out of town to watch the Firebirds play today and it was a great time. The 2+ hour trip down was mostly uneventful, but we did have to avoid some traffic going through some backroads that none of us had ever taken before. I think one of the best things about going out of town to a city is being able to park my car at the hotel and then NEVER have to drive it again until we leave.

The arena was close enough that we were able to use a combination of public transit and walking, which made the whole experience just so nice.

I have to say that the Pechanga Arena is a really nice place to watch a hockey game.

Something that I've noticed is that Acrisure is really cold when compared to other arenas¹. I've been to two other arenas and in both of them I felt over dressed and was a bit warm.

Anyway, the game was much closer than it needed to be, but the Firebirds were victorious 6-5 and ended a 7-game win streak for the Gulls.

All in all a very nice way to spend an evening.

1. Toyota Arena in Ontario, Pechange Arena in San Diego ↩︎

Posted by ryan on Fri 28 February 2025

I'm super excited to see that Hynek is doing a series on his YouTube channel about Python projects and uv in production. It's set to be a three part series, and the first episode My 2025 uv-based Python Project Layout for Production Apps dropped a few days ago.

I finally had a chance to watch it, and wow ... I'm just so excited to see how it goes. Based on his workflow and workload it might be some time before he's completed, but honestly it's going to be worth the wait.

The approach he's taking is to use uv, but only after manually going through the why's and how's of a Python project so you can have a better sense of what exactly uv is offering you, and when, or why you might want to change it to be different.

I'll likely watch it at least one more time and follow along to get a better sense of what he's working toward.

Can't wait for the next one!

Posted by ryan on Thu 27 February 2025

I have THREE raspberry pi's that I bought 7+ years ago now. And they still work as well today as they did then. They really are amazing little machines.

Over their lifetimes their uses have evolved, but I wanted to just write down some quick thoughts on what I do with them now. Let's call them, in no particular order:

1. ITFBD!
2. Exit Node
3. Extra one

ITFDB¹!

This raspberry pi sits above the TV in my living room. It reads the MLB API to tell when when a Dodgers game is about to start. It runs a message across a PiHat Sense 8x8 grid and gives the details of the game, i.e. start time, opponent, and record of each team playing. It does this starting 10 minutes before game time every minute until game time. It used to also have a recoding of the legendary Vin Scull saying, "It's Time for Dodger Baseball!" but an update did something to the ability for it to play sound and I've not had the time to resolve it

Exit Node

I'm a big fan of Tailscale thanks to Jeff Triplett. They have a concept of an 'Exit Node' that allows you to look like you're coming from a different location that you actually are. Now, why would anyone want to do this? I have no eartly idea, but sometimes it's fun to pretend that I'm in an area other than Souther California. This typically happens between March and October. But yeah, there's not really a good reason to do this, and I have no idea why one would.

Extra One

The last one mostly just sits around looking sad. It wants to be a thing, but I haven't quite figured out what it can be. At one point it lived as a motion capture camera above a humming bird feeder. It would take snap shots when it saw motion and then at the end of the day it would compile them into a movie and automatically upload them to YouTube. Why? No good reason other than I thought it would be fun to do. I've written a surprising number of posts on this

Raspberry Pi are fun. I highly recommend getting even one to just kind of play around with it.

1. It's time for Dodger Baseball ↩︎

Posted by ryan on Wed 26 February 2025

Today on Mastodon Eric Matthes posted about his library django-simple-deploy and a plugin for it to be able to deploy to Digital Ocean and I am so pumped for this!

I said as much and Eric asked why.

My answer:

all of my Django apps are deployed to Digital Ocean. I have a “good enough” workflow for deployment, but every time I need to make a new server for a new project I’m mostly looking through a ton of stuff to try and figure out what I did last time. This mostly works in that after a few hours I have what I need, but having something simpler would be very nice … especially if/when I want to help someone with their own deployment to DO

The number of times I have wanted to help automate and/or make deployment easier to Digital Ocean is numerous. It would have been extremely helpful for me when I moved off Heroku and onto Digital Ocean as I had no idea how to do the server setup, or deployment or anything remotely related.

A few years later and I still don't feel 100% comfortable with it all of the time, and I'm a "web professional"

Eric's tool is going to make this so much easier and I'm so here for that!

Posted by ryan on Tue 25 February 2025

After a week long hiatus from swimming I got back to it today. I only swam 1550 yards but it was a good swim. I kind of felt the need to take it a bit easy today given the week long break, and I needed to be at the office a bit early to get ready to help onboard a new employee. While it wasn't a great distance, or a great time (2'45" 100 yd pace) it still felt really good to be back in the pool.

I am again back to feeling 'pretty sleepy' early in the evening which I'm hoping will rid me of the insomnia from last week.

One of the best / weirdest parts of the swim is the honking from the geese. About 25 minutes into my swim they seem to wake up and just start honking at each other ... or maybe at me ... or maybe at the people walking around. Not really sure.

It is slightly off putting. They are very loud, but it also makes me giggle ... so that's something.

Posted by ryan on Mon 24 February 2025

Over the last 2 seasons the Coachella Valley Firebirds were 15-1 against the San Jose Barracuda. The one loss over those 2 seasons was a 5-3 loss at home that was a bit closer than then score showed. Coming into this season I really didn't have any reason to think anything other than we'd be on the same trajectory of beating the Cuda more often than not.

I was wrong.

Coming into tonight's game the Firebirds were 0-4-0-2 against the Cuda with 2 of those loses by only 1 goal ... the hardest being the Teddy Bear Toss in San Jose where the Cuda won 1-0. It was brutal to watch.

Coming into tonight's game I didn't have super high expectations. I texted a friend of mine

OK, in the previous 2 seasons the Firebirds are 15-1 against the Cuda. This year, they're 0-4-0-2. and 4 of those losses are 1 by 1 goal. What's even wilder is that 5 of Stezka's losses are against the Cuda. I think we'll be getting Grubauer today since Stezka is up with Seattle. I'm still a little unsettled about playing them, but maybe this time it will be different?

He replied

It will be different, let's get it!

He was correct. The Firebirds finally got a W against the Cuda ... although the 5-3 score was closer than I would have liked it to be ... and there were plenty of chances for the Cuda to tie it up in the last 90 seconds. But finally, the first win.

For the 2024-25 season we're now 1-4-0-2.

Hopefully we can keep up the winning ways!

Posted by ryan on Sun 23 February 2025

I've had a bit of an earache for a while and last weekend I finally got around to going to Immediate Care to have a doctor look at it.

They prescribed some antibiotics and because I think the earache may have been caused by the amount of swimming / time in the pool I have been doing I decided to opt out of swimming last week.

This then also resulted in my opting out of going to the gym at all, and for reasons that I'm still not sure of, I also didn't even bother to go for a walk before work, at lunch, or after work.

Something else that has happened is that 3 of the last 6 nights I have woken up between 2am and 3am and not been able to go back to sleep no matter how hard I tried.

I realized this morning that these two things could be related. I have been swimming a little more than 1 mile 3 days a week for the last 3 or 4 months, and I've been going to the gym for at least 30 minutes 2 days a week.

These activities did a great job of tiring me out, but without them, my body is suddenly like, OK dude, we've got some extra energy to burn off. No need so sleep!

Thankfully my ear is better, and I'll be taking the last of my antibiotic tonight so next week I'll be back at swimming and the gym and hopefully also back to getting a full night's sleep 🤞🏻

Posted by ryan on Sat 22 February 2025