Readit NewsDevops Engineer with a software quality focus. Well rounded in AWS. Jenkins and Github Actions CI/CD. Ansible, Terraform infrastructure as code. Large scale Apache Airflow installations. Experienced Python dev for scripting, web applications, and FaaS. Well versed in QA: test strategy, automated testing, automated infrastructure sandboxes.
https://www.nytimes.com/2023/09/22/magazine/hank-asher-data....
Here are some options/things to look at in making your decision:
https://www.dau.edu/tools/Documents/SAM/resources/RTM_Risk_R...
https://www.perforce.com/blog/alm/what-traceability
https://www.jamasoftware.com/requirements-management-guide/r...
https://www.inflectra.com/Ideas/Topic/Requirements-Traceabil...
Yahoo initially began as a links directory, and I thought that was a nice idea, so I made Yayhoo: https://bmsauer.github.io/yayhoo/
I like it a lot. I probably need to update it because I haven't done so in a while.
I often feel the same way, especially with tech. For those of us that remember before the internet was ubiquitous, the optimism and promise of the "information super highway" seems in stark contrast with what we see today. I try to keep in mind a few things:
First, we are living in a time that will be regarded as one of the most consequential in history. We're only ~20 years of nearly every person in the planet having access to all human information, instantly. Think of what people will say about this time period in 200 years. We are currently feeling the effects of growing pains.
Second, everything that embodies that early optimism is still there, its just harder to find. Which is related to my next point:
We are seeing diminishing returns in the benefits of constant consumption of media, energy, food, etc. There is so much choice out there, and the margins are so thin, that you need to consume more to be "satisfied". I often reflect on how many more full TV series we have all seen compared to a few generations ago. Or how much text we all read daily in the form of news, tweets, and forums, compared to the daily paper. Are we better for it? I think a lot of people don't feel better.
So that leads to the optimistic conclusions of this post. Generally speaking, we have more choice than ever before in history, across the board. But we have the burden of the responsibility of moderation and curation.
I find that when I feel this way, I try to shift my "consumption" mental state to "construction". We live in an amazing time to make things and distribute them. And because there's so much noise to compete with, you have to do it friend to friend, neighbor to neighbor. Its a glimpse of how the best parts of the "new world" can provide the best parts of the "old world".
It's not for everyone.
Specifically, because Nix's 'costs' are upfront (for likely future benefit), nix isn't well suited to just-get-it-done pragmatic attitudes. -- e.g. if you'd prefer to just launch VMs from the web console, over using a tool like Terraform, then Nix isn't going to be for you.
Nix isn't too difficult to use. I'd say it's 95% wonderful, 5% huge pain to deal with. (Writing new nix code can be very hard).
As to why it's worth learning:
> What makes it stand out?
Nix provides very expressive control over packages of software.
e.g. With nix, it's easy to have multiple versions of the same software running on the same system. Whereas, with package managers, if you upgrade, you aren't able to easily also keep the old version around.
Some of the use cases Nix allows are pretty neat:
- You can declare a set of development tools to be made available. So, when you load up the project, you don't have to copy-paste "apt-get install...". This is especially useful for side projects you might not touch all the time.
- There's a "nix run" command, which can act a bit like "docker, without containers": it will download the package, and run it on the host.
- NixOS makes use of Nix so that the system configuration is all declared starting from a single file. Rolling back changes to system configuration is easy, in case you accidentally misconfigure the system. -- This can be used to build container images or VM images.
- Nix can be used to declare what packages you want installed for your user, and declare the configurations for these files. This allows ensuring you have a familiar setup quickly on a new computer.
All sorts of programming involves dealing with packages.
To clarify a bit on the details: nix declares packages in a pure way, using all of its inputs (source code, compiler, library dependencies; which are themselves declared with nix), and builds these in an isolated/non-global directories. Packages are 'installed' by symlinking to where the package is placed.
proc mkFooBarRecord {foo bar} {
# Keep index #0 for a "type" for easier debugging
return [list "fooBarRecord" $foo $bar]
}
proc getFoo {fooBarRecord} {
if {[lindex $fooBarRecord 0] ne "fooBarRecord"} {error "not fooBarRecord"}
return [lindex $fooBarRecord 1]
}
Devops Engineer with a software quality focus. Well rounded in AWS. Jenkins and Github Actions CI/CD. Ansible, Terraform infrastructure as code. Large scale Apache Airflow installations. Experienced Python dev for scripting, web applications, and FaaS. Well versed in QA: test strategy, automated testing, automated infrastructure sandboxes.
Resume: https://sauertek.net/resume.xhtml