This value defaults to localhost:3000, which works, but then Gitea
renders "http://localhost:3000/wpcarro/briefcase" as the URL to clone my
briefcase repository.
In //website, I have the following directories about habits:
- days-of-week-habits
- habitgarden
- habits
Without READMEs in each of these directories, visitors (and myself) can
easily get confused.
When I started working on //clojure, which I also deleted, I wanted to
learn more about how to package Java projects using Nix. This was a part
of that study.
As I mentioned in the previous commit, I now use vterm.el as my primary
terminal. I wrote most of this Elisp when I first started using Emacs. I
know longer need it.
Before I switched to vterm.el, I used alacritty as my primary terminal.
I could not install alacritty on gLinux, so I switched to terminator.
When I was ricing my machine, I wanted my Emacs theme to change my
terminator theme. I never finished that project, and it is quite dusty
now.
I create //deploy when I first deployed a few applications that I
packaged with Nix. This was before I setup socrates as my "cloud". Now I
deploy all of my services using NixOS. The name "deploy" is a bit stale.
I'm renaming it //nix_gcr because it documents how I can deploy
Nix-packaged projects on Google Cloud Run.
In Nix, rec mean "recursive" and for attribute sets, this allows
attributes to refer to other attributes in the same attribute set. This
is useful, but I'm not using it here, so I'm removing it.
Gitea's announcement notes explain some of the benefits of Gitea over
Gogs:
https://blog.gitea.io/2016/12/welcome-to-gitea/
Also, I never configured Gogs such that I could use it, so the cost of
switching from Gogs to Gitea was basically zero.
When I run `nix-env -f '<briefcase>' -iA emacs`, Nix builds a derivation of
wpcarros-emacs using the path to the Emacs derivation. This doesn't work well on
glinux and causes strange behavior. For instance, Chrome crashes when it tries
to browse for files. Building with `nix-env -iA emacs.glinux` fixes this and
other problems.
Miscellaneous other changes:
- Remove unnecessary fix-point recursion
- Drop support for unused dottime.el
- Remove unused overrideEmacs
- Remove unused withLocalConfig
- Support emacs.glinux and emacs.nixos alternative derivations
TL;DR:
- Prune unused themes
- Prefer "JetBrainsMono" font for all themes
- Remove TODOs that I've either supported or that I'm uninterested in supporting
I'm working off of my laptop but I'm using my 4k monitor. The expression that
sets `fonts/size` could be more sophisticated and detect this, but for now, I'm
just bumping up the size.
When I first switched to EXWM, I wrote a lot of Elisp. I think I was mostly
excited about having a monorepo and, as I had a backlog of ideas that I wanted
to implement, I ended up writing many halfly baked ideas in Elisp. These are
mostly sketches.
I've been trying to read 15 minutes in the mornings. I also recently purchased
some house plants that I have been watering daily before I do my yoga routine.
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.
While the idea of managing the hosts at a per-user level appeals much more to me
that running this as root and managing /etc/hosts, I haven't been able to get it
to work.