b47ca8b876
From what I currently understand, lorri is a tool (sponsored by Target) that uses nix and direnv to build and switch between environments quickly and easily. When you run `lorri init` inside of a directory, lorri creates a shell.nix and an .envrc file. The .envrc file calls `eval "$(lorri direnv)"` and the shell.nix calls `<nixpkgs>.mkShell`, which creates a shell environment exposing dependencies on $PATH and environment variables. lorri uses direnv to ensure that $PATH and the environment variables are available depending on your CWD. lorri becomes especially powerful because of Emacs's `direnv-mode`, which ensures that Emacs buffers can access anything exposed by direnv as well. I still need to learn more about how lorri works and how it will affect my workflow, but I'm enjoying what I've seen thus far, and I'm optimistic about the road ahead. |
||
---|---|---|
.. | ||
.envrc | ||
default.nix | ||
main.go | ||
monzo.go | ||
README.md | ||
shell.nix | ||
utils.go |
monzo_ynab
Exporting Monzo transactions to my YouNeedABudget.com (i.e. YNAB) account. YNAB unfortunately doesn't currently offer an Monzo integration. As a workaround and a practical excuse to learn Go, I decided to write one myself.
This job is going to run N times per 24 hours. Monzo offers webhooks for reacting to certain types of events. I don't expect I'll need realtime data for my YNAB integration. That may change, however, so it's worth noting.
Installation
Like many other packages in this repository, monzo_ynab
is packaged using
Nix. To install and use, you have two options:
You can install using nix-build
and then run the resulting
./result/bin/monzo_ynab
.
> nix-build . && ./result/bin/monzo_ynab
Or you can install using nix-env
if you'd like to create the monzo_ynab
symlink.
> nix-env -f ~/briefcase/monzo_ynab -i
Deployment
While this project is currently not deployed, my plan is to host it on Google Cloud and run it as a Cloud Run application. What I don't yet know is whether or not this is feasible or a good idea. One complication that I foresee is that the OAuth 2.0 login flow requires a web browser until the access token and refresh tokens are acquired. I'm unsure how to workaround this at the moment.
For more information about the general packaging and deployment strategies I'm currently using, refer to the deployments writeup.