The last installment was not really finished but I just published it anyway. I lost track of doing this blog as I advanced in the project. Last time I talked a bit about the testing. Since then I've implemented the very first real behavior and checks. I also did a lot of work on the build system so that it can do partial rebuilds instead of recalculating all the certificates for each build.
Using Rust
The act of learning rust at the same time has proven to be a hurdle at times. It's going quite well, and the language's compiler is very helpful here, but there's still a bunch I don't know and I keep making mistakes that are difficult to resolve. I do really like the language so far, but if this was hard-engineered product I wouldn't have chosen Rust because I don't know enough about it. I'm stumbling around until stuff works and though I'm basing this on the documentation and I'm picking up the reasons why things are broken--it's just impossible to anticipate how long stuff is going to take me and the end product is not going to have the sort of confidence that is necessary for tightly regulated software development.
I do feel I can do a good enough job with this though so I'm not worried about that here. I understand the sorts of problems that come up in languages like Rust that are close to the machine and the compiler for this language really is very helpful. I'm also confident that I'm picking up what I need to so that I will understand better soon. It's like C++ but it's also very different. The patterns it encourages are patterns I've used in C++ but are more difficult/complicated there. Traits are similar to "policies" in Alexandrescu's "Policy Based Design" constructs in his "Modern C++" book, for example. There's much more freedom with Traits though.
Messing up rigor
I moved past the step of "simple configuration" and accepted that as "done" before I should have. It still panics if you don't supply a file name. Still panics if there are parse errors I'm sure but I don't know because I haven't tested that.
This step isn't a complete feature. The actual format of the configuration file is mostly irrelevant and is going to change significantly. How it's provided to the program isn't completely set either and may change. I was tempted by these facts, the desire to learn more and get more designed, and the desire to make more progress sooner. This is instant technical debt though and is just damn sloppy. Even though I'm just sort of throwing this together to have a base, that base needs to be more solid than this. Yes, I need to waste my time making sure errors are handled that are just going to be impossible later. Yes, I need to waste my time testing to make sure those errors are handled.
You're not doing actual incremental development if you are postponing "finish" work for later. To adhere to agile principles in order to call this task "done" I need to make sure it follows the requirements of the system and one of those is that it handles errors correctly. Each feature should be "done" before it is said it is "done" even if "done" isn't anything like what it will be when everything is "done". The reason is simple: if you don't then this stuff slips through the cracks to production.
If you do have some item that maybe can't be completed in this way or would be too expensive to or whatever then the exception needs to be made in the forefront. I did not plan it that way. If you do then you'll have the finishing of this created as a future item already. Or perhaps you call this a scaffold and it doesn't even label anything as completed in the plan but is instead part of the feature item it's needed by.
At any rate, you don't do what I did. Don't approve items that haven't been really reviewed and don't approve items as 'done' if they fail to meet that definition. So I'll be going back to fix this before I continue with what I was going to do next: the "authentication" scheme.
CMake meta build
I got tired of having every image basically have to be rebuilt because the CA test keys got built every time. I wanted to have a system that knows dependencies and can do incremental builds. I picked CMake because I'm fairly familiar with it and it does everything I need it to.
This area I feel I got pretty good but I have yet to see it tested by someone else or on systems that aren't basically my own setup. The combination of nix, docker, pytest, and cmake form a develop and test bench that should be pretty close to turn-key. I have a few kinks to work out I think but it's dialing in. You should be able to follow the README.md file to get a build and run the tests and there's only a couple base dependencies and commands you need to run.
Moving forward
This blog is probably going to continue to suffer. This project isn't going to so much serve as an example of how to do this but more a practice bench for myself to hone my processes. Then I can document those and maybe convert that into teaching material.