CST489: Module 5 (Week 90)

I worked on my capstone implementation.

Tooling setup completed:

• Installed and configured STM32 Extensions and drivers in VS code
• Registered a Qt student account and installed Qt dev tools
• Installed and configured QT C++ Extensions in VS code

Development (Code):

• Wrote a proof of concept firmware image that behaves like a two way pass-through/bridge. It takes frames received on either interface, and transmits them on the opposing interface.
• Successfully tested the PoC on my prototype board to make sure that basic buffer transfer works.
• Used Claude to build out the desktop application front end. It is just the front end and isn't hooked up to anything yet.

Notes:
I initially got a bit overwhelmed after hitting some of the challenges one might expect from choosing a hardware + firmware + application based Capstone project but thankfully I was able to sort that out. I now have traction.

I need to...

• think about how to test for timing disruptions and latency.
• report transmission errors.
• signal FIFO overflows in some other way besides the LED.
• implement a smarter buffer read mechanism instead of using a hard coded frame size.

CST438: Week 8 (Week 83)

 Placeholder.

CST438: Week 7 (Week 82)

One of the differences between Agile and Waterfall software development cycles is that the Agile is more flexible while Waterfall tends to be more rigid. Agile breaks delivery efforts into sprints and is more accommodating for shifting requirements. Waterfall moves in a sequence of steps. Requirements, design, implementation, testing, and release. A large project developed using agile would see looping progressions where a piece of functionality might go from requirements all the way to testing but loop back again due to changing requirements and specifications. Waterfall is linear and makes the most sense when the requirements for a project are expected to be well-defined and stable until release.

I have seen developers get the most benefit from Agile in external customer/user facing applications. In such cases, canary and beta testing feeds back into the development cycle and encourages updates. On the embedded side, though we also use agile, I see less cycling since the hardware design is usually stable and the APIs that we provide to other developers working on userspace applications usually require fewer divisions than for example a customer facing GUI.

CST438: Week 6 (Week 81)

One of my big takeaways from this week was the "cattle, not pets" approach to compute resources. It encourages using and configuring servers and containers as easily replaceable units. It aligns with the containerization of test infrastructure that I've seen in industry. Powerful hardware can run multiple instances of isolated containers to make good use of performance advancements. What struck me most is that this isn't just an infrastructure choice — it forces software itself to be written differently, avoiding local state and hardcoded dependencies so any instance can be killed and replaced without issue. I am still learning about docker and its uses but I expect that I'll get more exposure to serverless architectures. I also think the practical implications of scaling to zero are interesting. I'll be reading more about it.

CST438: Week 5 (Week 80)

 The biggest lesson for me this week was actually more like a reminder. We should lean into smaller, faster tests whenever we can, but we should thoughtfully layer in larger tests to validate realistic, end-to-end behavior. That way we acknowledge the lesson of the test pyramid and and avoid relying too heavily on either extreme to our own disadvantage. Like so many other things, there's a balance.

I imagine working at a startup with out the big budget of a huge legacy enterprise, or anything to fall back on. Deploying large tests without first working out a test coverage strategy could waste vital resources and delay delivery. Leaning too far in the opposite direction and focusing on the faster unit tests could create test escapes that only surface in end-to-end scenarios. Striking a balance between test methods makes absolute sense and should be a point of focus.

CST438: Week 4 (Week 79)

 I think the most interesting idea is Hyrum's Law. It says, "with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." All that to say that documentation and good intentions don't actually protect you. For example, if a hash table happens to iterate in a certain order, someone will eventually depend on that order whether it's promised or not. Then as an API owner, it means you can't reason your way to the conclusion that "nobody depends on this" for an interface. Having a robust CI system and canarying practice in place before touching anything widely used is a must, which ties right into the logic behind the Beyonce Rule. As an API consumer, it means treating undocumented behavior as unstable even when it's convenient. It's just a safer bet.
When you take them together these approaches shift the topic of maintainability from being a matter of following rules correctly to an ongoing negotiation with reality. I've been on both an API producer and consumer and the lesson in the text rings true.

CST438: Week 3 (Week 78)

 One of the best use cases for Git and other version control systems is on projects where multiple developers are working on a shared code base. Most projects solving non-trivial problems require collaboration. Git is a great way to keep code changes in sync with the remote repository as the single source of truth. Developers don't step on each other while working on their respective code changes.

Many years ago, I used a different system called CVS. One of the big improvements that Git has over CVS is that Git allows developers to work on their own local copy of the remote repository. Even if the network is down, an engineer can work on code changes and commit on their local copy then push those changes once network access is restored. This is a big deal for engineers who work while they travel.

One limitation of Git merge is an issue that I came across today. It's a line-for-line, syntax/text based solution. It doesn't understand context. In my case, since my last pull, another developer had changed the API and updated multiple function signatures. The merge worked, but compilation failed. All this to say that developers can't point to a successful merge operation as evidence that the combined code is valid. We still need plan and align our work as a team and make sure to build and test every time we modify the code.