Age | Commit message (Collapse) | Author | Files | Lines |
|
More technical interviews
|
|
To make things easier for testing, I setup the /verify endpoint as a GET, so
that I could email myself clickable URLs. With POST /verify, my options are:
- send email with an HTML button and form that POSTs to /verify
- email myself the curl instruction
I'm preferring the latter for now...
|
|
git-subtree-dir: assessments/tt
git-subtree-mainline: 67e0f93b3bbc386421a276cbd5675f5ac51625ae
git-subtree-split: ee8e75231cd9d3d4aa3ffbbfa0e3b8511712e1ee
|
|
Since the `default.nix` file is specific to my tooling, I'm ignoring it.
|
|
Also delete redundant `README` from `server` directory.
|
|
Creating a simple HTTP RESTful API for exposing our `Server.semiprime`
function. It supports some help messages, primitive parsing and error handling,
and singular vs. batch processing of arguments.
For more sophisticated parsing and error-checking, I prefer to use Haskell's
Servant library.
|
|
This can be useful downstream for diagnostics.
|
|
I think it's more readable this way.
|
|
Calling `assert` within the `Enum.map` makes the errors more usable.
|
|
- Clear the boilerplate that `mix` generated
- Consume `Math.factor` to test which inputs are semiprimes
- Cache all inputs that are semiprimes as soon as we discover that they are
- semiprimes
I considered a couple things related to the Cache:
- Could save space by storing all semiprime factors in a tree. This would make
the lookups more expensive. Also because the tree's depth would never exceed
two (because all semiprimes only have two factors), the tree would be quite
broad, and we may not be saving enough space for the trade to be worthwhile. I
might be wrong about that though.
- We could consider pre-computing all semiprimes when we start the app, but
without running some tests firsts, I'm not sure whether or not it's worth the
trouble.
|
|
Since I'm often using `iex` for interactive development, these functions are
useful.
|
|
Define a simple in-memory key-value store for our cache.
TL;DR:
- Define `Cache` as a simple state-keeping `Agent`
- Define `Sup`, which starts our Cache process
- Define `App`, which starts our Supervisor process
- Whitelist `App` in `mix.exs`, so that it starts after calling `iex -S mix`
|
|
9 out of 10 doctors agree that every module needs a doc. Ask your doctor if
moduledocs are right for you!
|
|
In case I want to package this project with Nix. For now, it's useful to store
this at the project root because it help my Emacs's `project-find-file`
function.
|
|
Support `Math.factor` and cover it with tests.
|
|
I'll use as the host for utility functions needed to extend the stdlib.
|
|
Starting fresh with...
```shell
mix new server
```
|
|
This is an exciting take-home assignment because I get to write a service in
Elixir!
|
|
Where it belongs...
|
|
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.
|
|
I should have done this from the start.
|
|
I've been doing a few take-home assessment recently, all of which I've attempted
to solve using Haskell. I'm having a good time, and I'm noticing strong and weak
points with my Haskell programming. I always attempt to apply any feedback a
reviewer gives me, and I'm storing my first drafts, second attempts, and
feedback here for now.
This recently attempt was for a role at Jane Street.
|