Yaro's blog

Biking to Utah lake

2024-11-10T00:00:00+00:00

It wasn't long ago I found out that the Jordan River Parkway Trail</a> in Utah is the longest paved urban trail in the United States (the bold "urban" was not a mistake; there are longer trails in the US that aren't urban 😂).

Some websites say it's 45+ miles. Some say it 60+. I wonder what the discrepancy is there? Anyway, you can go from Utah Lake all the way to the Great Salt Lake in about in a 58 mile stretch of it. I would love to make that trek someday on my bike, but I decided I would first make an attempt to bike from my house in east Sandy to Utah Lake and back.

Part of the journey would just be heading straight west until I reached the JRT, about 6 miles, and the remainder 21 miles would be on the beautiful meandering trail that's fully away from car traffic, aside from a few crossing on the way.

I had planned to take a bus or Frontrunner (our commuter rail system) part of the way back in case I didn't feel like biking the entire length, but due to poor planning and the lack of service on Sunday, I missed both the last train and bus.

I want to say I was up for the challenge, but by the time I got to Utah lake, the sun was already setting and it started to get really cold, really fast, which I was also unprepared for.

I did have my bike lights with me, which helped illuminate the trail and made for a really awesome and different experience on the way back. But man, was I cold.

I did make it back home safely, covering just over 54 miles in 5 hours and 20 minutes. The journey on the way back was undoubtedly the slowest; partly due to trying to reduce the wind chill, and partly because JRT to my house is mostly just hill climb.

Unfortunately, the cold caused a pretty bad flare of dermatitis all over my ears and scalp... but I still think that the trip was worth it! How else would I have been able to get this awesome picture?

Why I love observability

2024-08-10T00:00:00+00:00

Why I love observability</h2>
_{And why I think operational excellence is the most important pillar of the well architected framework}

The 5 pillars of the well architected framework</h3>
Here are 4 of the pillars:

Make sure it's performant.</li>
Build it with cost optimization in mind.</li>
Make sure it's reliable.</li>
Make it secure.</li> </ul>
The foundation for all the other pillars of the Well Architected Framework is observability, which is part of the 5th operational excellence pillar. You can't quantify your success in any of these other categories without having some baseline; some starting point to show how much you've improved.
Let's revisit the other pillars:

Make sure it's performant. How performant?</li>
Build it with cost optimization in mind. Where can we save costs?</li>
Make sure it's reliable. What's our current uptime?</li>
Make it secure. How do we know when and if there is an attack?</li> </ul>
Collect metrics from the very beginning</h3>
We all need to build software that solves real business problems and we needed it yesterday. I get it. The last thing anyone wants to do is spend time writing code just collect metrics about the real code that's solving real problems. And let me tell you, metrics are a real business problem, and it's up to you to convince stakeholders that this effort is not for naught.
The wonderful thing is that it's a lot easier to add telemetry collecting capabilities to your project than you probably think. Through the widely adopted and supported OpenTelemetry framework, there is likely a package out there for your language of choice that adds auto-instrumentation capabilities to many of the dependencies that you're using.
The only initial startup cost might be to figure out where you are going to be dumping all the telemetry data. Lucky for us, many telemetry collectors are adopting the OpenTelemetry specification (OTel).
While working at my last job, our cloud provider of choice was Azure. All we had to do was install OpenTelemetry instrumentation libraries, which would hook into and collected various signals from logging, http client, Azure SDK, and other libraries, and the Azure Monitor Open Telemetry exporter</a> to get it in Application Insights/Diagnostics logs for querying and visualization.
Not in the cloud? Well you can dump OpenTelemetry data into Grafana, or a number of other destinations as well.
Is every scenario this easy? Well no. You might find that you want to instrument some code you wrote, or some 3rd party library yourself. Or even some code that runs in a unique environment (we did it for instrumenting Databricks python workflows!). For that, there is the Open Telemetry SDK. But more than likely, you can get started instrumenting libraries that are already supported and reap huge benefits.
Correlate your data</h3>
Collecting metrics from various pieces in your architecture is useful on it's own. But chances are those pieces are talking to each other and you want to see how they all tie together in the bigger picture. Maybe you have a complex workflow that start a service A and ends at service Z. Did a failure happen somewhere in the middle and you have no idea where it is? You need Context Propagation</a>, which will start the tracing context at one end, and capture everything in between to the end, so long as the same Trace Parent (trace id and parent span id) is passed along between each service boundary.
In the end, you should be able to query all the signals that were collected, using a single trace id.
An analog for your architecture</h3>
Once we had all of infrastructure instrumented and the data was landing in a centralized location, we were able to visualize all the components, and how they were connected in Azure Monitor.
All of our logs, metrics, etc. became the analog for our infrastructure. We could start pinpointing where bottlenecks were happening, where exceptions were being thrown, and drill down to the exact lines of code with all the context that came before it.
At the point, building alerts on top of these signals is easy. And you can start monitoring the performance, cost, reliability, and security of your system over time, and focus your engineering teams to tackle known problems backed by real data.
How to get started</h3> With the observability primer</a>.

What is a hydrometer and how do we build one?

2022-10-02T00:00:00+00:00

What is a hydrometer?</h2>
A hydrometer is a device that measures the relative density of liquids. In beer brewing, a brewer takes a reading before fermentation to find out how much sugar was extracted from the malt into water, and then another reading after fermentation when the yeast has converted much of the sugar into alcohol and CO2. The difference between these two measurements gives you a fairly accurate alcohol content reading for the beer.
Because relative density is defined as the ratio of the densities of two different liquids, non-fermented beer, or wort, and water in our case, water is taken to be 1.000. When a hydrometer reads 1.050, this means the density of the wort is 1.050 times that of water.
A hydrometer can look like many things, but a very common one would look like this:

Isaac Hopkins (Q106121459), Public domain, via Wikimedia Commons
This one is a glass tube, with a ballast at the bottom to give it upward stability when placed in water. Inside the glass tube is a paper scale that reads the relative density of the liquid when aligned with the surface of the liquid. The scale usually indicates at what temperature the scale was calibrated to. It is recommended that measurements are also taken at that same temperature but there various calculators out there that can adjust for temperature differences.
Questions thus far:

Does atmospheric pressure affect relative density readings?</li>
What is the relationship of density and temperature, and how do we account for that in our readings?</li> </ul>
A hydrometer can also have many names, such as an Alcoholometer, Lactometer, Saccharometer etc. They all have varying scales and units depending on what industry they're applicable to, but all operate on the same principle: Archimedes' Principle:
A body at rest in a fluid is acted upon by a force pushing upward called the buoyant force, which is equal to the weight of the fluid that the body displaces. If the body is completely submerged, the volume of fluid displaced is equal to the volume of the body. If the body is only partially submerged, the volume of the fluid displaced is equal to the volume of the part of the body that is submerged. Britannica</a> </blockquote>
How do we build an IOT enabled hydrometer?</h2>
While the hydrometer pictured above operates on vertical displacement and manual eye-seeing measurement, a tool I already own works by taking the tilt or incline of the device suspended in the liquid Tilt Hydrometer</a>.
The goal of this project is to build a similar device.
The benefits of this device include:

We can drop it into the fermenter and leave it in there. This enables us to monitor the health of our fermentation at any interval we choose, and know when fermentation is done.</li>
We limit the exposure of oxygen and unwanted microbes to our beer compared to taking manual samples.</li> </ul>
How can we get relative gravity using inclination?</h3>
Applying Archimedes' principle, we know that if we drop an object with known mass/density in water (assuming it doesn't completely submerge), it will sink less in liquid that has higher density. I.e. the volume of the submerged portion of the object will be less.
From observation of dropping things into water, we've seen that some objects do not float completely vertically, or horizontally. An object might float with some inclination. Likely because the object is top-heavy.
The assumption, or hypothesis, is that for this non-uniform object, it's inclination will be greater in denser liquids as less of it's volume is submerged under the liquid, and it's center of mass acts to tip it over.
What device can we use to measure inclination?</h3> Accelerometers are cheap and very useful sensors for measuring inclination. Here is a resource I found that seems very well written: Analog, Accelerometer application</a>
Required math and physics concepts</h3>
From some quick online searching, the study of hydrostatics seems applicable:
Branch of physics that deals with the characteristics of fluids at rest, particularly with the pressure in a fluid or exerted by a fluid (gas or liquid) on an immersed body. Britannica</a> </blockquote>
Glossing over some of the concepts from various searches, all of these seem to apply:

Center of mass</li>
Moments of inertia</li>
Buoyancy</li> </ul>
It's been a while since I've seen these concepts, but I found some textbook sources that should help out (All on libretext.org!):

Classical Mechanics, Tatum</a>

Particularly chapters 1 (Centers of Mass), 2 (Moments of Inertia), and 16 (Hydrostatics).</li>
Chapter 16 even has an example problem explaining the tendency for logs to fill up with water, and start to right themselves vertically as their density approaches that of water. Sounds very similar to the problem we're trying to solve!</li> </ul> </li>
Here is a chapter from a calculus book that covers density, mass, and center of mass: Active Calculus, using definite integrals for density, mass, and center of mass</a></li>
And another book to cross-study calculus: Calculus, Gilbert Strang & Edwin Herman</a></li> </ul>
Summary</h3>
There is quite a bit to learn in what was just outlined here. If you're not comfortable with all the concepts like me, take some time to learn from the materials or find some alternatives! My next post(s) will be summarizing some of the learnings, determining if the assumptions made were correct, and answering the questions above. Later posts will dive into some code, microcontrollers, and the sensors that will be used for the project.

Bridging the gap: Building an IOT Hydrometer

2022-09-27T00:00:00+00:00



Bridging the gap between tutorial following and making fully featured projects</h2>
The most frustrating thing about programming, and engineering in general, is that there is a load of resources on the two far ends of this spectrum: basic tutorials and amazing projects that others have built.
The bridge in the middle is no doubt the hardest, and most time consuming part of the process: knowledge and problem solving.
What motivated this guide are three things:

Bridging the gap for myself in the microcontroller, low-level programming, and applied mathematics space, and</li>
Helping others bridge the gap (like a coding tutorial that you're used to, but with a heavy emphasis on a tutorial to learning and applying those learnings</li>
I like to brew beer, and devices like the Tilt Hydrometer</a> really inspired me</li> </ol>
Since I started thinking about this project a week ago, I've tried really hard to keep myself from searching "diy iot hydrometer", or "building a hydrometer using an accelerometer". I think that discipline is important; remember we are trying to arrive at the solution ourselves, no matter the struggle. The goal is to build the intuition and skills required for bridging the gap.
I encourage you to do the same, and read from the start to the end of this series without peeking. Try solving the problems yourself, try messing with the code, math, etc.
I only have a vague idea of how to solve this problem. It's a multifaceted problem and one that motivates me. This might not be the same for you, but hopefully my approach can lead you to solve a problem you might be interested in.
I am not a beginner in the software space, but my background is mostly in .net APIs, Angular front-end development, Azure stack of cloud development and deployments, and some Powershell scripting thrown in there.
Where I lack and what I intend it learn is:

C/C++ and low-level programming in general</li>
Arduino, microcontrollers and interfacing with the wide variety of sensors out there and their protocols</li>
A deep understanding of mathematics, and the application of (i.e Applied Mathematics</a>)</li> </ul>
So hopefully this guide is one that comes from experience, but more importantly inexperience so that you may feel like we are in the same shoes trying to bridge the gap. There are many concepts I don't know, so you will see many explanations and all the resources from which they were derived. I intend to use all open source, or freely and easily accessible resources.
Let's begin.

Cargo workspace dependency woes

2021-12-31T00:00:00+00:00

They said learning rust would feel like a constant battle with the compiler. They were right. Most of the time it's because of user error with a nice little message telling you how to fix the error. Nice. Easy. When it's cargo yelling at you, it's because of some dependency conflict that is the fault of one of the many libraries in your dependency tree. Fun...
In this case I was working on adding the second GUI to my minesweeper-rs project</a>, this time with the implementation using the Bevy game engine. I structured my project using cargo workspaces</a> so I wouldn't have to recompile the shared minesweeper-logic library for every GUI that I would build, and possibly other libraries that would be shared between Nannou, Bevy etc.
This is the error I ran into right as I added the minesweeper-bevy binary project to the workspace: 
Nannou depends on wgpu 0.11.0

Which has "loose" dependency on wasm-bindgen ^0.2.76 (>= 0.2.76 and < 0.3.0)</li> </ul>
Bevy depends on wgpu 0.7.0

Which has a "strict" dependency on wasm-bindgen =0.2.69 (has to be 0.2.69)</li> </ul>
Cargo will attempt to pick a package that solves both of the requirements for wasm-bindgen, but not if they are constrained in the same compatibility range. In other words, cargo will pick only one version 0.2.* that will satisfy the minor SemVer for both. But since wgpu 0.7.0 has a strict dependency on a specific patch version, it goes with that one. This leaves wgpu 0.11.0 requirements unsatisfied.
For more, see semver compatibility</a>.
Theoretically, wgpu 0.7.0 shouldn't have such strict dependency on a patched version, as patches usually only include bug fixes and the like, and shouldn't break existing features with future patches. That's the definition of SemVer. O'well 🤷‍♂️.
To get around this, I think i'll just get rid of the cargo workspace.

Rust's Drop trait and drop function

2021-07-25T00:00:00+00:00

Rust has been on my mind for the last couple of weeks and I wanted to get back into it (after wanting to get into it over a year ago). This blog has also been on my mind lately (and also left on the back burner over a year ago)... So let's get to it. This is just a simple note for myself that I can refer to later and solidify the concept.
The purpose of the Drop trait is to relinquish memory on the heap that the implementor instance owns. For example, if your object references any file, network, or database connection. The trait only has one method, drop, and is called automatically when the object goes out of scope.
Similarly, there is a drop function in the std::mem crate which has a super simple implementation:
// std::mem::drop pub fn drop<T>(_x: T) { } </code></pre> An empty function body, that's literally it. Since the variable is moved into the drop function into a new scope { }, the variable is deallocated immediately after the function is called. This function can be used to deallocate memory on the heap manually rather than automatically when it goes out of scope. Here is a quick scope example/reminder from "Rust by Example": // raii.rs fn create_box() { // Allocate an integer on the heap let _box1 = Box::new(3i32); // `_box1` is destroyed here, and memory gets freed } fn main() { // Allocate an integer on the heap let _box2 = Box::new(5i32); // A nested scope: { // Allocate an integer on the heap let _box3 = Box::new(4i32); // `_box3` is destroyed here, and memory gets freed } // Creating lots of boxes just for fun // There's no need to manually free memory! for _ in 0u32..1_000 { create_box(); } // `_box2` is destroyed here, and memory gets freed } </code></pre> Notice how we boxed the integer instead of creating an integer on the stack. The Drop trait only applies to memory allocated on the heap, and cannot be implemented by anything that implements the Copy trait (integers and other scalar types).
Setting up a simple team project workflow on github 2020-07-19T00:00:00+00:00 Before I started working as developer full-time there were many things that were not obvious to me. One of those things is how to structure a workflow for a project. Sure, simple projects where I was the only person touching the code may seem overkill for some of the things listed in this blog post. But I promise it will be worth your time upfront and save time for your future self. These guidelines will be even more important for team projects. At the very minimum</h2> 1. Branch policies</h3> If you're working on a team project, can you commit changes and push directly to master/main? If the answer is yes, this is a huge problem and should be the first thing to fix. Generally, any changes to code should be made by branching off of the master/main or feature branch, and then creating a pull request to merge those changes back into the target branch. This ensures that someone other than yourself reviewed the code before changes were merged in. Humans make mistakes all the time. At the very least your fellow team members should be able to read the new code being checked in and understand what it does. Team members should take this opportunity to point out any mistakes or ways to improve the code before it is merged in. Check "Require pull request reviews before merging" We will also be checking "Require status checks to pass before merging" in 2. Build Checks</a> below. 2. Build checks</h3> You should always be checking in working code. Can't tell you how many times I've seen compilation errors in a project after pulling down the latest changes. This slows down other teams members either by 1. you have to go and fix it, or 2. you have to remind someone to go and fix it. Don't @ me bro. Luckily we have a simple solution: build the code when a pull request is created, and setup a policy where pull requests can only succeed if the build succeeds. For this we will use Github workflows/actions</a>. Setting up a basic workflow to build the project is fairly straightforward with the plentiful example workflows. At this point you should already have some code in your master/main branch, so the only thing left to do is click Actions on your repo's main page. Github is smart and will make a recommendation on what example workflow to setup based on the primary language used for the project. Go ahead and select the recommendation or start from scratch. I won't go into the heavy details of how actions work here; just know that most of what you probably need is already on the marketplace, workflows are written in yaml, and every action on the marketplace should have good example to get you started. Below I will outline a workflow that could apply to almost any project. The only thing that will differ will probably be the action and it's configuration (build a C# project version build a node project). on: pull_request: jobs: build: runs-on: ubuntu-latest steps: - name: 'Checkout' uses: actions/checkout@master - name: "Setup node" uses: actions/setup-node@v1 with: node-version: '12' - run: npm install - run: npm build </code></pre> This should read almost like plain english: On a pull request, run the build job with these steps: use the checkout action to checkout our code, use the setup-node action to setup node.js, run npm install and then npm build. After setting up the build.yml (or whatever you choose to name it), you can go set the "Require status checks to pass before merging" under branch protection rules from above, and select the name of the build to be used (build.yml in this case). 3. Test checks</h3> You should probably have some unit tests for your code. If you don't, I would highly recommended adding them as they serve us as our guardian angels 👼. Luckily adding test checks is only one line of code! Simply append - run: npm test under - run: npm build and you are good to go. Not only are we checking if the code compiles now, but we are also making sure that our merged changes don't break any existing tests 🤜🤛. Bonus points:</h2> Deploy your code</h3> We went through the effort to build our code and test it. Once the pull request completes and everything is merged into master/main, why not deploy our built code automatically so the rest of our team can see the changes without having to pull and run changes locally? This is super easy for frontend web apps, as Github has the capability to host it for you via Github pages</a>. Here is the action to do just that: deploy-to-github-pages</a> Do you have a more complex app with a private server you would like to deploy to? There are many options for that as well: Deploy as an Azure WebApp</a></li> Deploy to Firebase</a></li> Deploy to Heroku</a></li> </ul> We can even just copy our build files to a target server using SCP/SSH like I did for this blog: build.yml</a> From the build_and_deploy job: build_and_deploy: runs-on: ubuntu-latest if: github.ref == 'refs/heads/master' steps: - name: 'Checkout' uses: actions/checkout@master - name: "Setup node" uses: actions/setup-node@v1 with: node-version: '12' - run: npm install - name: 'Build with zola' uses: shalzz/zola-deploy-action@master env: BUILD_DIR: . TOKEN: ${{ secrets.TOKEN }} BUILD_ONLY: true - name: copy files to target server via ssh uses: appleboy/scp-action@master with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} port: ${{ secrets.PORT }} key: ${{ secrets.KEY }} source: "./public/*" target: "/var/www/blog" overwrite: true </code></pre> The secrets pipeline variables can be easily configured by going to your project's settings and clicking the Secrets tab. Some action require setting up a personal access token</a> with github. The action's documentation should tell you what minimal scopes/permissions it needs to run. Summary</h2> That about covers the most basic scenario. The sky is the limit from here, but setting up a basic workflow to build code and validate our pull requests will save a lot of time and headaches for your team. Also, it's pretty dang fun watching the logs as our build pipelines progress 🤓. Welcome to my blog 2020-07-07T00:00:00+00:00 Welcome</h1> Hello world and thanks for stopping by. This blog is dedicated as a self-reference for the things I learn and don't want to forget (and if I do, easy to lookup 🕵️‍♀️). A few things to expect from this blog:</h2> Rust</a> learnings</li> Some C#/Asp.net core, Angular</li> Linux</li> Vim</li> Design patterns</li> Cool things I find</li> Ramblings</li> </ul> Also:</h2> There is an RSS</a> feed! “Paper is to write things down that we need to remember. Our brains are used to think.” - Albert Einstein </blockquote>

How to get started</h3> With the observability primer</a>.</p>

Also:</h2>
There is an RSS</a> feed!</p>

“Paper is to write things down that we need to remember. Our brains are used to think.” - Albert Einstein</p> </blockquote>

Yaro's blog

Biking to Utah lake

Why I love observability

Why I love observability</h2>
_{And why I think operational excellence is the most important pillar of the well architected framework</sub></p>}

What is a hydrometer and how do we build one?

Bridging the gap: Building an IOT Hydrometer

Cargo workspace dependency woes

Rust's Drop trait and drop function

Setting up a simple team project workflow on github

Welcome to my blog

Welcome</h1>
Hello world</strong> and thanks for stopping by. This blog is dedicated as a self-reference for the things I learn and don't want to forget (and if I do, easy to lookup 🕵️‍♀️).</p>

Yaro's blog

Biking to Utah lake

Why I love observability

Why I love observability</h2> And why I think operational excellence is the most important pillar of the well architected framework</sub></p>

The 5 pillars of the well architected framework</h3> Here are 4 of the pillars:</p>

What is a hydrometer and how do we build one?

Bridging the gap: Building an IOT Hydrometer

Cargo workspace dependency woes

Rust's Drop trait and drop function

Setting up a simple team project workflow on github

Welcome to my blog

Welcome</h1> Hello world</strong> and thanks for stopping by. This blog is dedicated as a self-reference for the things I learn and don't want to forget (and if I do, easy to lookup 🕵️‍♀️).</p>

Why I love observability</h2>
_{And why I think operational excellence is the most important pillar of the well architected framework</sub></p>}

Welcome</h1>
Hello world</strong> and thanks for stopping by. This blog is dedicated as a self-reference for the things I learn and don't want to forget (and if I do, easy to lookup 🕵️‍♀️).</p>