Rust

Way back when, before nice graphical user interfaces, all we had was the terminal. I won’t waste time with a trip down memory lane. Suffice to say there were many cool terminal-based interfaces, and some of us still use terminals (or terminal emulators more likely). And there are still nice terminal-based user interfaces used by many of us, even if that’s just vim or emacs. As I continue my journey learning Rust, I thought I’d take a stab at writing a terminal user-interface (AKA TUI). In this case I will leverage a Rust crate called ratatui. Ratatui provides UI widgets for building a TUI — things like laying out your UI, tabs, tables, scrollbars, and the like. Ratatui focuses on the UI aspects, and leverages other crates for the low level terminal interaction. Several are supported, but the one I chose (and the most common?) is called Crossterm. I am going to focus here more on Ratatui then Crossterm, except as needed. ...

This is another blog in my fledgling series on Rust as I learn the language. In this blog I touch on a few cool crates that can improve your error handling in Rust. It follows nicely from my prior post on logging in Rust. As with that post, this is just an introductory look at error handling. There is a lot more one can learn about error handling (in Rust or otherwise) than I will cover here. Here I will just touch on a few crates that can get you started. Maybe in future posts I will get into more detail on other topics, but there are also good blogs out there already (e.g. this). ...

This blog post is part of a series I’m developing documenting my evolution as a Rust developer. Currently I’m a newbie, but I’m making progress. As a newbie, please feel free in the comments to elaborate on what I might be doing wrong, could do better or is not “canonical” Rust. Logging is obviously a key aspect of a production-ready application. While one could use println! or dbg! or similar Rust macros to achieve something similar, they are not really a replacement for a real logging framework. In fact, particularly for (long running) “services” as opposed to CLIs, many architecture/coding standards prohibit use of the equivalent to println! in whatever language you’re using. I myself have set such standards on projects I’ve lead. ...

How would you define “regression testing”? According to Wikipedia, Regression testing (rarely non-regression testing[1]) is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. In the modern age of test automation and continuous integration, tests are run (or should be) automatically by the build system. Whether testing functional or non-functional features, there really are only three categories of tests to run: Unit tests Integration tests System tests Let’s discuss each in turn. ...