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.
I incorrectly modelled all of the G-sharps in my application as belonging to the
G pitchClass, which resulted in a strange bug where vieChord printed "G minor
Root position", but the Piano highlit a G minor.
I checked the other accidentals, and it looks like everything is properly
classified.
I'm sure this app contains more unused code. I would like to find some Elm tools
for detecting and deleting dead code, but this isn't my current priority.
My current priority is dogfooding this app until I find it genuinely useful for
myself.
This is a temporary solution. Ideally I would like to handle this with the
following:
- Show the flashcard for a chord shortly after beginning a practice session
- Display a small 3...2...1... countdown timer immediately after beginning a
practice session
I need to dig more deeply into Elm's Time module and subscriptions to better
understand how to properly solve this problem. In the meantime, please tolerate
this short-term solution.
My much anticipated feature: first prompt the user for a name of a chord, then
show the user that chord.
Cascading changes:
I changed the "Tap to practice" overlayButton's opacity from 30% to 100% because
pausing when showFlashCard is True causes the two piece
TIL:
You can batch Elm Subscriptions using the Sub.batch function.
What I haven't learned yet:
How to best handle rotating screens for mobile devices (i.e. portrait
vs. landscape modes). In time...
What's left?
- Support sound
- Support a fine-tune section of the preferences
- Support tablet and web browser variants
- Ask users for the "I chord" instead of asking "C major Root position"
- More styling (of course)
Moving the UI.tw function into Tailwind.use. Creating and consuming some
functions like Tailwind.if_ and Tailwind.when to make it easier to conditionally
style some of my components.
Now the "Tap to practice" button fully covers the screen.
- Dropped support for a Piano direction (for now)
- Using w-full and w-1/2 for piano key "length"
TL;DR: scale down UI for non-mobile devices.
I pulled the screen resolution for my phone, the Google Pixel 4, off of the
internet. I created a device profile in Chrome to develop this application
specifically for my phone. To my surprise, when I opened the app on my phone,
many of elements that looked good in Google Chrome, looked askew on my phone. I
needed to troubleshoot.
Here's how I did that:
I used Tailwind to responsively color the bg for each breakpoint to see if my
device was sm, md, lg, xl (according to Tailwind's breakpoint
terminology). After reading Tailwind's documentation and comparing their
breakpoints with my Pixel 4's width (i.e. 1080px), I figured that my device
would be lg. It's not; it's md, which I confirmed by using ngrok to load
localhost:8000 on my phone and see that the background-color was
"md:bg-green-600".
I'm still unsure why my device is not lg, but knowing that my device was md
was enough to fix many of the styling issues. My current theory is that while
my screen's resolution is 1080 wide, the pixel density affects the media query
for the breakpoint.
Refactor the Piano component to highlight the root note of each chord. If this
makes things too easy, I can support this as a preference.
Also:
- Reduced the number of keys that the piano displays and increased the key
thickness to reclaim the space
- Preferred using Tailwind selectors instead of inline styling where applicable
- Call List.reverse on the keys to ensure that the top-most note is a lower note
than the bottom-most note
TODO:
- Support showing only the name of the chord and not just the notes that
comprise that chord
- Rewrite the function that generates the chords for a given range of notes
- Consider supporting a dark mode
Since I've published this, I should include an Overview page to orient potential
users. This Overview could be better -- as could many things with this app --
but it's a start, and I'm seeking small wins.
Observed problem: Tapping "C major, A minor" key, which LPC sets by default,
does not unset it.
Bug: handleClick passed the relativeMinor Key but the default value in
State.Model is the C Major key. We would toggled b/w [Cmajor] ->
[Cmajor,Aminor], and because toggled checked if either Cmajor or Aminor was
present, it was always true.
Solution: Check relativeMajor to set toggled.
