I haven't updated this list since I was living in Dargow, Germany over the
summer. Now that I've settled down, and I'm situated in the London Bridge area,
I'm updating the list.
In the spirit of Marie Kondo, I'm tidying up!
TL;DR:
- Prefer .envrc `use_nix` and delete all dir-locals.nix files
- Remove ~all references to <nixpkgs>, <unstable>, <depot> and prefer
referencing each with briefcase.third_party.{pkgs,unstable,depot}
- Delete nixBufferFromShell function since I was only using that in
dir-locals.nix files
Unforeseen problem: `buildkite-agent` runs its builds in a separate directory,
so if I want the `nix-build` command to build the newly checked out code, I need
to set <briefcase> to the CWD.
Per the assignment's instructions, the `Shift n` operation should treat
the *entire keyboard* like a cycle and shift that. I was erroneously
treating *each row* like a cycle and shifting those one-by-one.
This change fixes that. In addition, it also:
- Updates README.md with expected inputs and outputs
- Updates test suite
- Adds `split` dependency to {default,shell}.nix
TL;DR:
- include a default.nix to allow users to build an named executable
- emphasize in the README that the user needs Nix to build this project
- pin nixpkgs to a specific commit and fetch it from GitHub
Per my take-home assignment's reviewer's comments, with which for the record I
agree, I should generate the character->coordinate table from my existing qwerty
keyboard definition.
The best part is: by doing this I found a bug: Notice how the original '0'
character was mapped to the Coordinate (0,0)... thus every subsequent digit
key (i.e. the first row) is off-by-one.
Using Haskell's Text.ParserCombinators.ReadP library for the first time, and I
enjoyed it thoroughly! It's nice avoiding a third-party library like MegaParsec.
Before starting my take-home assignment, the instructions advised me to create a
"Hello, world" program in the language of my choice. Since I'm choosing Haskell,
I created this example as my starter boilerplate.
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.
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) }
```
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".
I'm writing a function that returns the total number of ways a cashier can make
change given the `amount` of change that the customer needs and an array of
`coins` from which to create the change.
My solution conceptually works but it actually does not return the results I am
expecting because I cannot create a Set of Map<A, B> in JavaScript. I'm also
somewhat sure that InterviewCake is expecting a less computationally expensive
answer.
While the "Dynamic programming and recursion" section hosts this problem, the
optimal solution does not use recursion. Many cite the Fibonacci problem as a
quintessential dynamic programming question. I assume these people expect an
answer like:
```python
def fib(n):
cache = {0: 0, 1: 1}
def do_fib(n):
if n in cache:
return cache[n]
else:
cache[n - 1] = do_fib(n - 1)
cache[n - 2] = do_fib(n - 2)
return cache[n - 1] + cache[n - 2]
return do_fib(n)
```
The cache turns the runtime of the classic Fibonacci solution...
```python
def fib(n):
if n in {0, 1}:
return n
return fib(n - 1) + fib(n - 2)
```
... from O(2^n) to a O(n). But both the cache itself and the additional stacks
that the runtime allocates for each recursive call create an O(n) space
complexity.
InterviewCake wants the answer to be solved in O(n) time with O(1)
space. To achieve this, instead of solving fib(n) from the top-down, we solve it
from the bottom-up.
I found this problem to be satisfying to solve.
Problem:
Prettier was not running when I saved Emacs buffers.
Why?
- prettier-js-mode needs needs node; lorri exposes node to direnv; direnv
exposes node to Emacs; lorri was not working as expected.
Solution:
Now that I'm using nix-buffer, I can properly expose node (and other
dependencies) to my Emacs buffers. Now Prettier is working.
Commentary:
Since prettier hadn't worked for so long, I stopped thinking about it. As such,
I did not include it as a dependency in boilerplate/typescript. I added it
now. I retroactively ran prettier across a few of my frontend projects to unify
the code styling.
I may need to run...
```shell
$ cd ~/briefcase
$ nix-shell
$ npx prettier --list-different "**/*.{js,ts,jsx,tsx,html,css,json}"
```
...to see which files I should have formatted.
Lorri does not cleanly integrate with my corporate device, which cannot run
NixOS. To expose dependencies to Emacs buffers, I will use nix-buffer.el, which
reads its values from dir-locals.nix. To easily expose dependencies from my
existing shell.nix files into dir-locals.nix, I wrote a Nix utility function.
Write a function to find a duplicate item in a list of numbers. The values are
in the range [1, n]; the length of the list is n + 1. The solution should run in
linear time and consume constant space.
The solution is to construct a graph from the list. Each graph will have a cycle
where the last element in the cycle is a duplicate value.
See the solution for specific techniques on how to compute the length the cycle
without infinitely looping.
Write a function that returns the shortest path between nodes A and B in an
unweighted graph.
I know two algorithms for finding the shortest path in a *weighted* graph:
- Use a heap as a priority queue instead of the regular queue that you would use
when doing a BFT. This is called Dijkstra's algorithm. You can also use
Dijkstra's algorithm in an unweight graph by imaginging that all of the
weights on the edges are the same value (e.g. 1).
- Map the weighted graph into an unweighted graph by inserting N nodes between
each node, X and Y, where N is equal to the weight of the edge between X and
Y. After you map the weighted graph into an unweighted graph, perform a BFT
from A to B. A BFT will always find the shortest path between nodes A and B in
an unweighted graph.
I had forgotten that a BFT in an unweighted graph will always return the
shortest path between two nodes. I learned two things from InterviewCake.com's
solution:
1. I remembered that a BFT in an unweighted graph will return the shortest
path (if one exists).
2. I learned to use a dictionary to store the edge information and then
back-tracking to reconstruct the shortest path.
