Adding a dummy, top-level secrets.json file using `git-secret`. It might be nice
to have a mono-secrets file in json because then I can use it with `jq` like:
```shell
$ jq '.secret' --join-output < ~/briefcase/secrets.json
```
This morning I'm attempting to secure my monorepo. How?
- `git secret`: DONE: To version-control sensitive data
- `git secrets`: TODO: Lint code for sensitive data
I will probably update the CI to call `git secrets --scan` or some similar
command to fail when that exists non-zero. I have much to learn, but doing is
the best way to learn it.
Optimizing is difficult: I like flat hierarchies because I don't like
directory-hopping, but I also would like a cleaner root for my mono-repo. Bombs
away!
Well it's that time again, folks: spring cleaning!
Here I am musing about a few things that bother me:
- Should I use kebab-case or snake_case?
- It feels ~confusing to have //tools and //utils. What a //projects? Isn't
everything a project? *sigh*
After some toil, I finally support basic ReasonML starter code.
I'm adding it to the nut-score directory because I would like to make a simple
webpage that render some nutritional facts about nuts with respect to the
ketogenic diet.
I'm not sure if I should include or exclude te .bs.js files.
See the README.md for more information.
Instead of creating my own static website generator, I'm trying Hugo. Huge is a
newer alternative to Jekyll. So far, I like what I see.
- Ignoring /blog/public since this is where `huge -D` generates the static
assets.
- Using a TailwindCSS theme.
- Creating a dumby post about Emacs to test deployments.
- Deleting all Common Lisp and Nix code that powered my previous, half-baked
blog.
I was a bit weaker than I expected to be in my most recent interview using
TypeScript. To improve, I think I'd like to attempt solving some of the
InterviewCake.com questions using TypeScript.
If you've read the previous commits, the inspiration for `run` arose because I
need to call `npx ts-code <file>`, which is easy enough to remember, but I'd
still rather just call `run <file>`.
I'm writing sensitive data here, so I'd like to ignore it instead of encrypting
it and publishing it. Perhaps later on, I can extend the key-value store to
handle encryption and decryption but that feels like overkill for now.
Define transaction structs for both Monzo and YNAB. Each package has a `main`
function that runs some shallow but preliminary round-trip tests for the
serializers and decoders.
The fixtures.json file that each of them is referencing has been ignored in case
either contains confidential data of which I'm unaware.
Manually merging:
- README.md: I added the description from universe/README.md into the heading of
dotfiles/README.md.
- .envrc: dotfiles/.envrc was a superset of universe/.envrc
- .gitignore: Adding some of the ignored patterns from universe/.gitignore to
dotfiles/.gitignore
Everything else here should be a simple rename.
I'm not actually sure if this is sensitive information, but I'm erring on the
side of caution and ignoring it in case it is.
squash! Ignore .gnupg/random_seed
Removing more files that clutter my `gst`
This time I ran...
```bash
git rm -r --cached .
```
...which is supposed to help ignore files that `git` already tracks. This may be
the missing piece I've been looking for.
This repo's history seems to reflect my difficult wrestling with
Git, GitHub, gitignore files. I'm still not sure I understand
everything that's going on.
