92 karma · joined January 29, 2021
Also, for email sending I use smtp2go free tier - primarily because I use random emails on my own domains to see who's leaking, and I don't want to set them up separately proton-side.
In that setup, proton itself is kinda unnecessary - I keep that path mostly as an insurance, just in case of acatastrophic homelab failure.
> capacity to reason about it (during critical downtime) and communicate it
That's one of the things that's put into limelight in that talk.
I personally think that most of "Web Scale" software is inconsequential (inconsequential for its creators, not for users) - as there are no consequences for bugs and outages at all. A data breach -> slap on a wrist. Reputational damage because on an outage/data loss amidst general public? - almost impossible (clownstrike, anyone?)
The funny thing is that web scale software that's consequential is often in an ethically grey zone - but at least you won't be surrounded by colleagues who don't give a shit.
The question is where the "enough confidence" border lies - and in the worse case the only way to do some reliable investigatios would be printf debugging or its alikes.
With or without AI - doesn't matter. Only at that point you gain understanding of the limitations both of LLMs and of dynamic languages.
edit: Forgot about "Nightmare" difficulty - try enjoying dynamic languages and LLMs when your legacy codebase is earning tens of thousands $ per second.
"will never be awesome" is missing some quantifier about US-centricity.
I personally use wl-kbptr, and the problem above is the only one that can't be solved without explicit support from the compositor.
Certificate signing was done by a separate SSH service, which you connected too with enabled SSH agent forwarding, pass 2FA challenge, and get a signed cert injected into your agent.
- Everything is managed by build system that is able to track dependencies
- Inputs from financial institutions are kept in the repo as is
- Those inputs are converted by your scripts to .csv files that are readable by PTA import engine
- There are rules files that describe how to convert .csv lines to PTA entries
- Generated files are included from per-year PTA journals (and you can put any manual transactions in here also)
The benefit is that you can change any part of this pipeline, and just re-generate the changed parts:
- improve the program that converts to .csv - raw data immediately gets better across the whole repo
- add/customize import rules - better classification is immediately applied to all of the past data
And with this approach you can start small (like, a single month of data from your primary bank), and refine the thing in steps, like adding more historical data or adding more data sources (examples being not only bank statements, but even things like itemized Amazon orders and Paypal slips).
claude-code rendering pipeline often goes awry, and start scrolling back and forward very fast, causing insane flickering. They have some explanation in https://github.com/anthropics/claude-code/issues/769#issueco... describing that they've made that tradeoff in the name of native terminal experience (instead of learning per-program shortcuts/etc).
Funnily enough, before reading their reasoning, I thought that the whole rendering pipeline was badly vibe-coded.