I created a server to manage my access and refresh tokens. This server exposes a
larger API than it needs to at the moment, but that should change. The goal is
to expose a GET at /token to retrieve a valid access token. The server should
take care of refreshing tokens before they expire and getting entirely new
tokens, should they become so stale that I need to re-authorize my application.
A lot of my development of this project has been clumsy. I'm new to Go; I didn't
understand OAuth2.0; I'm learning concurrent programming (outside of the context
of comfortable Elixir/Erlang).
My habits for writing programs in compiled languages feels amateurish. I find
myself dropping log.Println's all over the source code when I should be using
proper debugging tools like Delve and properly logging with things like
httputil.Dump{Request,Response}.
The application right now is in a transitional state. There is still plenty of
code in main.go that belongs in tokens.go. For instance, the client
authorization code belongs in the tokens server.
Another question I haven't answered is where is the monzo client that I can use
to make function calls like `monzo.Transactions` or `monzo.Accounts`?
The benefit of having a tokens server is that it allows me to maintain state of
the tokens while I'm developing. This way, I can stop and start main.go without
disturbing the state of the access tokens. Of course this isn't the primary
benefit, which is to abstract over the OAuth details and expose an API
that gives me an access token whenever I request one.
The first benefit that I listed could and perhaps should be solved by
introducing some simple persistence. I'd like to write the access tokens to disk
when I shutdown the tokens server and read them from disk when I start the
tokens server. This will come. I could have done this before introducing the
tokens server, and it would have saved me a few hours I think.
Where has my time gone? Mostly I've been re-authorizing my client
unnecessarily. This process is expensive because it opens a web browser, asks me
to enter my email address, sends me an email, I then click the link in that
email. Overall this takes maybe 1-3 minutes in total. Before my tokens server
existed, however, I was doing this about 10-20 times per hour. It's a little
disappointing that I didn't rectify this earlier. I'd like to remain vigilant
and avoid making similar workflow mistakes as I move ahead.
I enjoyed using term-switcher so much that I ended up adopting vterm as my
primary terminal. After reaching for vterm as often as I did, I realized that I
would enjoy supporting cycling through instances, creating new instances,
deleting existing instances, renaming instances. Thus spawned vterm-mgt.el.
I'm particularly excited about the KBD to toggle between vterm instances and
source code buffers.
Supporting these functions was a little tricky. For example, how should we
handle calling cycle/remove on the item that is currently focused? After
attempting to be clever, I decided to just set the value to nil and let the
consumer decide what is best for them. I can always support a more opinionated
version that fallsback to previous-index if previous-index is set. But until I
have a better idea of how I'm going to consume this, I think nil is the best
option.
This post is a draft, i.e. not linked from the index. It's not a
secret, but if you do find it through this commit before its
publication please don't share it too widely yet.
Posts with either `draft = true;` or `listed = false;` will no longer
be included in index generation and will have a warning callout
inserted at the top of the page urging people not to share the links
to them.
This change makes cgit pass the current repo and vpath inside of the
repo on to the about cmd, which makes it possible for it to correctly
render `tree`, `log` and other links to the same vpath.
Deleting this code feels strange. This project has been around for a
decade, and despite occasionally needing a bunch of tweaks it had aged
well and worked fine for a very long time.
I've reached a strange point where I don't really feel like using
Haskell anymore, and every interaction with this project in recent
years has been fighting dependency management tooling for Haskell, or
dealing with strange build problems.
The simple fact is that the service never really did anything other
than render Markdown dynamically, and at this point I can do that much
better with //tools/cheddar instead.
So, tazblog-hs, it's time to say goodbye. Rest in peace!
Factor out a new EntityAttributes type from some of the methods of the
Entity class, to avoid the proliferation of 1-argument boolean methods
on the entity class that always have to be forwarded through the Entity
instance for SomeEntity if they have defaults (forgetting to do which
has wasted tons of my time up to this point). Currently blocksVision,
blocksObject, and collision are all in there.
This is not yet fully functional, but going in the right direction.
Some concepts are introduced:
* There is a light theme (used for blog entry pages) and a dark
theme (used for the homepage itself)
* Entries can be either blog posts, projects or miscellaneous things
that I want to link people to (possibly with a comment)
It might be interesting to add pages that filter to specific types, or
some such, which should be relatively easy to do.
Note that the layouts of entries are not actually done yet.
Prevent closing doors when there's a gormlak or other entity with the
blocksObject attribute set to true on the same tile. There's a message
sent here which is grammatically incorrect - it says "The a gormlak
blocks the door" - should fix that later.
Add predicate for determining if a cycle contains items.
Updated cycle/{new,from-list} to support setting current-index to nil when a
consumer calls it with an empty list.
