Refreshing your browser page does not count as one.
That’s an old-time word for ‘noob’, youngster.
The task I’ve been working on for the last two weeks got an official “green build” today. I had some last changes I wanted to test, so I kicked that off when I went home.
When I walk in tomorrow, I should know whether or not I can merge.
Those changes are actually present earlier in the
git history, but I reverted
them to ease testing when I thought they might have been part of the culprit.
Now that I know things work, I can put them back in. They constitute
backgrounding two build steps so that they run in parallel rather than
series–I’m hoping to get a speed increase out of this.
One point mentioned was that these kinds of tests condition developers to assume “green is good,” meaning my code is perfect and didn’t break anything.
Well, firstly, these aren’t unit tests, they’re actually integration and regression tests, but we’ll ignore that. I did get a little ego boost when I saw that green light–and now it’s worrying. Did I really do everything right?
Fortunately, most of my changes were (small) shell-script refactorings. They had to preserve all side-effects (much like compiler optimizations), so as long as the end result is the same things should be fine. In fact, I hardly changed the “real” code; I mostly split off functions and used data structures and bash-isms where appropriate to write code with clearer intent.
I also have this habit when I’m working on shell code of writing little
throwaway scripts (usually named
some.sh) that I can run harmlessly. I’ve used
this technique with fake
Makefiles before as well. Effectively, it lets me
test code structures or external tooling to make sure the results are what I
expect, or fix it if they’re not.
So, I’m fairly confident about the correctness–“fairly” as in “justly.”
I also spent a chunk of time playing with python and json. I learned some quirks about both of their syntaxes today. They will be of great benefit as I continue to design and implement my change-and-make-based artifact-caching system (code name: cake).
I still have to investigate how
__future__ imports affect code in a module,
and code in modules importing that module.
Lastly, it is always important to acknowledge that the life of a software developer, engineer, or writer (after your preference) is highly tied to reading documentation and self-educating.
Today, this meant more posts about git internals, python, and vim. If my tools aren’t sharp, then I can’t cut anything with them.
But if I’m not sharp, how do I know what to cut?