Back when I owned an iPhone -- before I switched (mistakenly and thus
temporarily) to Android -- I had a note for each year's newly learned words. As
I am condensing as many of my documents as possible into my briefcase, I decided
it is time for including a dictionary.
I can still record words on my phone, and then I can transfer them to this
document.
In the beginning there existed only a generic //org directory... This directory
was generic enough to include any .org file regardless of its purpose, but
specific enough to disallow membership of other worthy files of the Markdown
ilk.
Then came the //playbooks directory, which robbed //org of most of its
inhabitants...
In the interim various .md and .org TODO lists existed scattered across the
landscape of the monorepo... some existed in far-away, exotic lands like
"travel-histlist"... These fractious tribes shared much in common with their
distant relatives, but the superficial differences granted the simple-minded,
draconian filesystem license to prevent them from mingling.
Then one day the monorepo had a new visitor: //todo-lists.
//todo-lists restored order to the monorepo, uniting all of the fractious
documents under one roof.
.md and .org files held hands and sang Kumbaya around a blazing fire for the
first time in history. All was well, and all were happy.
I'm particularly excited about this idea. As I was reading Graham's "Erase your
darlings" blog post, I had an idea: I should have playbooks at the root of my
monorepo.
I can have playbooks for the following:
- How to install NixOS
- How to build GCR images from Nix expressions
- A collection of miscellaneous shell commands (e.g. "how to kill a process by name")
- What series of steps should I follow when I receive a paycheck
I already keep README's at the root of each package, which I think is where many
of these instructions belong. Other tutorials that I write for myself that do
not belong to any package can go in //playbooks. I also will host my personal
habits in //playbooks since habits are a bit like playbooks for life. Let's see
how this idea ages as the caffeine wears off...
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*
Inconveniently, I do not have the cipher code that I wrote from a previous
chapter, and I'm not eager to reimplement it.
TODO
- Implement encrypt
- Implement decrypt
- Read all characters from STDIN
I was instructed to benchmark these functions, but I couldn't get the
benchmarking library to run using Nix -- although I'm *sure* it's
possible. Unfortunately the book recommends using `stack`, which I couldn't
reproduce.
I believe there are two exercises sets in the "Composing Types" chapter. Here
are *some* of my answers so far...
I'm having trouble implementing Foldable for Compose. I was able to implement a
version of it by adding the (Functor f) constraint to the instance signature,
but I think I cheated.
I will revisit these problems as well as the earlier exercises later.
Because revs afa9ca, dc80d7 aren't in the "default" (typically "master") branch
of NixOS/nixpkgs-channels, I need to specify the ref (aka branch) in order for
fetchGit to resolve the rev.
After growing frustrated with doom-modeline's compatibility with my EXWM setup,
I decided to borrow @tazjin's setup, which I find to be much more appealing.
Ensure that $NIX_PATH is empty using a .envrc file. nix.dev considers references
to <nixpkgs>, <briefcase>, <depot>, <unstable> to be an anti-pattern because it
hinders reproducibility by introducing an implicit environment.
This repository is chock-full of references to
<{nixpkgs,unstable,briefcase,depot}>, so right now everything is broken.
Refactor the caching policy for the Memo by evicting the elements that have been
the least-recently-accessed.
Python's heapq module default to a min-heap. By storing our heap elements
as (UnixTime, a), we can guarantee that when we call heappop, we will get the
element with the lowest UnixTime value in heap (i.e. the oldest). When we call
heappush, we use (time.time(), key) and these values -- by having the largest
UnixTime, will propogate to the bottom of the min-heap.
Bound the size of the memo by creating a BoundedQueue. Whenever we add elements
to the BoundedQueue, we remove the oldest elements. We use the BoundedQueue to
control the size of our dictionary that we're using to store our key-value pairs.
After hearing from a Jane Street recruiter, I decided to dust off some of the
DS&As knowledge. I found this article online, which outlines an example problem
called "Memo":
https://blog.janestreet.com/what-a-jane-street-dev-interview-is-like/
Here's part 1 of the solution in Python.
It's beautiful how State is just Reader that returns a tuple of (a, r) instead
of just a, allowing you to modify the environment (i.e. state).
```haskell
newtype Reader r a = Reader { runReader :: r -> a }
newtype State s a = State { runState :: s -> (a, s) }
```
Setting `authMode = "Registered"` prevents me from running the `register
<password>` command from inside of `bitlbee`, which I *believe* I need to
run...
I'm having trouble getting PAM auth to work, so I'm temporarily disabling it.
TIL that I can use the following to verify that PAM is properly setup for a
program (e.g. `bitlbee`).
```
pamtester -v bitlbee $(whoami) authenticate
```
...but despite this succeeding, I still cannot use the `identify` command in
`bitlbee` to successfully authenticate. It just tells me "Incorrect password"
even though I'm providing it the same password that I type when doing the
`pamtester` command from above.
Computers!
I'm still not entirely sure what bitlbee does, but I know this: I want as many
messengers in the same place as possible: IRC, Slack, Telegram. @tazjin tells me
that Bitlbee will help me get to the promised land. This is hopefully one step
of many in that direction.
From "Haskell Programming from First Principles"...
I have completed all of the exercises in the book thus far, but I only recently
dedicated a Haskell module for each chapter. Previously I created ad hoc modules
per exercise, per chapter... it was chaotic.
I'm creating Haskell modules to host my attempts and solutions for the exercises
defined in each chapter of "Haskell Programming From First Principles".
Problem: My SSH is behaving strangely.
Reason: I'm not sure. What I do know, however, is that Google handles SSH
differently. So I think that's enough for me to know I should keep my hands off
and not wrestle with it.
My current understanding of how computers deal with time:
- Modelling time is easy: use the number of seconds that have elapsed since the
Unix epoch.
- Display time is complicated. Which timezone should we use? Which format
string?
Lately I was toiling while writing a ClojureScript client. This made me crave
Elm. I'm going to rewrite the ClojureScript client using Elm, but along the way,
I'm stopping off here and recording my starter boilerplate.
