The Terraform Knows What It Should Provision At All Times.
the terraform knows what it should provision at all times. it knows this because it knows what it hasn’t provisioned.
by subtracting what is from what ought to be (or what ought to be from what is, depending on provider drift), it obtains a plan, or diff.
the planning subsystem uses diffs to generate imperative operations to drive the infrastructure from a state that is, to a state that isn’t, and in arriving at a state that wasn’t, it now is.
Read more...The Client/Server Architecture
In the client/server architecture, a server manages access to a centralized resource, fulfilling coherent requests on behalf of a client.
Tail Latency Amplification
Tail Latency Amplification: A request in a distributed system is only as fast as its slowest dependency.
Napkin Math 2: Applying It to Computers
In this post, I will be explaining the technique of estimating performance from first principles. It’s based heavily on the following talk: https://www.youtube.com/watch?v=IxkSlnrRFqc.
To recap, the purpose of napkin math is to provide a quick approximation to within an order of magnitude of the real answer, for the purposes of quickly testing the feasibility of the design of a system. Last time, we talked about Fermi estimation, which is (according to my definition) just napkin math where you’re primarily multiplying, and isn’t necessarily focus on computers.
Read more...Napkin Math 1: Fermi Estimation
Napkin math - also known as back-of-the-envelope calculation - is a powerful technique for quickly estimating answers to complex problems using simplifying assumptions and rules of thumb. This approach is particularly valuable in systems design, where quick approximations often need to be made about performance, capacity, and resource requirements. In programming specifically, these calculations help establish upper and lower bounds, typically aiming to be within an order of magnitude of the actual answer.
Read more...Type A and Type B Productivity
In the month of December 2024, I started messing around on the piano a bit. I started practicing every day, and the habit actually started to stick a little. I did it for about 10 days, practicing on single scales exercise in C major for about 10 minutes per day, and it was small enough that it was actually sustainable. Plus, it was just spaced out just enough that I could see improvement in about a week.
Read more...New Year's Resolutions 2025
I feel the urge to Paul Graham this one – really break down New Year’s Resolutions, talk about why they work, why they don’t work, what constitutes a good New Year’s resolution, and the like. But then I stand the risk of becoming a little too meta. The goal of this post is not to write about New Year’s resolutions, but rather to make the resolutions themselves.
It seems best if I start, though, by talking about what constitutes a good New Year’s resolution, and what constitutes a good habit, more generally.
Read more...Examples of Non-functional Requirements
The common refrain when determining functional and nonfunctional requirements is that “functional requirements describe what the application does, and nonfunctional requirements describe how it does it.”
Here are some examples of nonfunctional requirements:
- Performance
- Latency of various actions (page loads, content loading, server processing)
- Availability
- Uptime requirements (which may vary from system to system)
- Scalability
- Number of users
- Expected growth in users in 3 months, 6 months, a year, etc.
- Throughput
- Read vs Write heaviness (how many users read a post for each time it is written? 10:1? 50:1?)
- Observability
- How easy it is to tell what is going on (or going wrong) with your application
- Reliability
- Technology Stack
- Security requirements
- Authentication
- Authorization
- Maintainability
- Compliance
- GDPR, COPPA, HIPAA, etc.
Adopting Hugo
I am changing from raw html to the static site generator Hugo. As I plan to put more writing on my blog, writing in markdown instead of plain HTML will become more important. Stay tuned for overviews of system design concepts (as I prepare to find more permanent employment), as well as security and statistics.
Get excited.
Spock: A Spoken Programming Language
In December 2023, I came up with the idea of a programming language you would be able to speak out loud, into your phone or computer, hands-free. I thought it was an interesting idea for a couple of reasons:
- It would allow you to program on the go without a laptop, while still approaching threshold efficiency (130wpm output1). Also, reducing the time from thought → action seemed like a powerful way to increase productivity.
- It would be an interesting experiment to see how voice programming would change software: Would being able to speak algorithms increase fluency with them? Would programming languages naturally become more terse and expressive, mirroring natural language? Would voice-written software libraries become spaghetti, or would the necessity of fitting the entire problem domain in your brain at once lead to more elegant solutions?
- There are many voice assistants which run code on your behalf, but none that are Turing complete. A language that allows you to communicate any task that a computer can conceivably do would be the ultimate in power and flexibility.
At the time, I couldn’t really pursue the idea due to other projects, nor had I really done any work in programming languages since second year, so I was forced to give up on the idea. Nonetheless, I briefly reviewed my course notes and kept the idea on the back burner.
Read more...I’m a software engineer who completed my Bachelor of Computer Science at the University of Waterloo in December 2023. While I was there, I also did a minor in pure mathematics and participated in the a cappella club.
Due to my (sometimes excessively) broad interest, I have a penchant for starting Too Many Side Projects™. Working on narrowing in on the flagships.