I believe RIO stands for: "ReaderT <something-something> IO", which is a nod to
the top-level application data type:
```haskell
-- This is a simplification
newtype RIO env a = RIO { runRIO :: ReaderT env a () }
```
I read about RIO from an FP-Complete blog post a few months ago, and now I'm
excited to try it out for a real project. Bon voyage!
As the previous commit mentions, I'm attempting to build and deploy this project
with `nix-shell` and `nix-build` instead of `cabal` and `stack`.
I'm in the Hamburg airport right now, and my internet connection isn't stable
enough to test this, so I'm committing it until I can more robustly test it.
I'd like to see if I can avoid using `cabal` and `stack` and build and deploy
this application using `nix-shell` and `nix-build` only. Let's see how that
goes.
The JWT should match "accounts.google.com" or "https://accounts.google.com". If
it doesn't, we produce a validation error.
TL;DR:
- Group all failed stringOrURI function calls as StringOrURIParseFailure errors
I'm attempting to be an obedient boy and implement this and future features
using TDD.
TL;DR:
- Defined a few tests
- Defined an empty GoogleSignIn module
- Defined a Fixtures module to quickly create JWTs to test
TL;DR:
- Add common dependencies like Servant, Aeson, Warp, Cors
- Define a POST /verify endpoint for our client to hit
- POST to /verify client-side onSignIn
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...
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.
Now that I have a deployed an MVP of my app, I am tidying things up to support
the next phase of development.
TL;DR:
- Moved application Model-related code into State module
- Moved each View into its own module
- Deleted unused ChordInspector component
- Deleted unused Msg's, {Increase,Decrease}Tempo
- Deleted misc unused code
The elm2nix expression builds my code as Main.min.js. As such, I changed my
index.html to require Main.min.js instead of elm.js. When I run elm-live now, I
make sure that I output Main.min.js as well. I need to gitignore this to exclude
it from my repository though.
After a few failed attempts at deploying my Elm application on NixOS, I'm trying
elm2nix, which some NixOS and Elm users created to attempt to solve some of the
issues that I ran into earlier today.
Elm tries to write to $HOME, which NixOS doesn't like. I typically prefer to
avoid things like cabal2nix, elm2nix, node2nix because I don't like the workflow
that they suggest, but I'm so eager to deploy this application, that I'm trying
it.
Thankfully @tazjin builds Gemma (an Elm project) with Nix, so I could reference
Gemma's default.nix to help me with mine. Elm problematically attempts to
HTTP-fetch a list of packages to verify my project's dependencies. Because Nix
builds derivations in a sandbox without network access, I need to use some
escape hatches (i.e. NIX_REDIRECTS, LD_PRELOAD,
SYSTEM_CERTIFICATE_PATH). Welp... it's packaged now...
I'm also pointing learnpianochords.app to this project's index.html. It will be
live soon! :)
TODO(wpcarro): Rename "Chord Drill Sergeant" -> "Learn Piano Chords" (KISS)
I'd like to deploy an MVP version of this application today, so I'm dropping
support for a few features to focus my efforts. I may bring these features
back.
TL;DR:
- Temporarily drop support for "Fine Tune" tab of preferences
- Sort keys by the Circle of Fifths
For now since I'm the only customer and I'm primarily making this for myself,
I'm styling the app specifically for my Google Pixel 4. If I find this app
useful, I will consider supporting other devices.
I'm using the Icons that I bought when I purchased the "Refactoring UI" book.
Other news:
- I bought the domain learnpianochords.app!
What's left:
- Style the "fine tune" tab of the preferences view
- Better support non-mobile devices like the browser and tablet devices
- Deploy the application to learnpianochords.app
- Redesign the "key" tab of the preferences view to sort the keys according to
the circle of fifths
- Dogfood
- Simplify until I cannot simplify anymore
Start styling the Chord Drill Sergeant for mobile devices because that is that
device on which I will primarily use CDS.
I'm also deleting the debugger related code. I would like to support a debugger,
but I'm not currently using this one, so I am going to remove it to keep things
slender.
- Introduce TailwindCSS, which also introduced elm-live, index.html, index.css
- Add mobile-first styling for the preferences modal
- Remove unused code
Generate chords for a given key.
I believe my Theory.allChords function is taking a long time to generate all of
the chord possibilities. I would like to profile this to verify this
assumption. I think I can create a "staging area" for changes and only
regenerate chords when "committing" the options from the "staging area". This
should stress the application less.
TODO: Profile application to find bottleneck.
For the past two to three days, I've been searching for the name for the concept
of "C" or "A". From what I read, notes are specific things like C0 or C4, but I
wanted the name of the concept of a C. Thankfully today I discovered that this
is called a pitch class.
