Hey, aoe is my daily driver at home and for work. That's 40+ hrs/wk I'm using it, no major issues beyond the occasional reflexive or agentic git-checkout of another branch within a given session confusing me.
I've usually got 8-12 sessions going across a couple projects. I make heavy use of `worktrunk` within aoe for squashing and merging.
Really a blast! Wish I could figure out what the sounds are supposed to mean, though. I think they're random?
Glad to hear it! oooh interesting, I've seen worktrunk but haven't explored it too deeply yet.
The sounds are sort of an easter egg: you can enable/disable them from the settings page (hit 's' in the TUI). You probably are experiencing them being random because the default is to select "random" sounds (see the settings TUI screen). I don't use the sounds much so I'm waiting for a contributor to suggest an improvement.
It's a mess in terms of code/filesystem organization, but it's nice to be able to text somebody "hey, create and deploy a branch of codebase X with feature Y" while I'm on the go. Not exactly magic, and probably not sustainable, but there's definitely something to it.
Also, attaching an LLM with my raindrop.io and Todoist credentials to cron is fun. Haven't got the kinks worked out, yet, but it's pretty incredible how much data-shifting I can do now. Saved me a lot of clicks.
Don't all younger Americans do this? Cutting food and pushing it onto the fork requires less dexterity than conveying it to one's mouth. I know Boomers who put down their knives after each cut (never using them to push) and swap their fork around before using it tines-down, and I think it's more comically affected than the tea–pinky thing.
You're not supposed to use the fork like a shovel, is the thing. The tines are to skewer the food, which is why tines-down makes sense. Otherwise, why not a spoon?
Also, the at-distance interaction between two tools requires much more dexterity than making your hand meet your mouth. The latter you should be able to do with your eyes closed.
If I were eating a stereotypical British meal – say: meat, potatoes, and peas – I would use the fork as a "shovel" for the peas: guide the peas onto the fork with a knife, then raise and eat from the fork.
I wouldn't switch from a fork to a spoon to eat the peas.
Well I don't personally mind, but this would be seen as poor form in the sense of the original article. You're 'supposed' to kind of spear them onto the end of the tines using the knife.
Also, with the scoop method, if the peas are hard enough, I would think they're at great risk of rolling around and off the fork. If I were going scoop style, I'd have to mash or at least flatten them a little first to prevent this.
The two sources of truth are for two disparate adapters. Neither the API nor the DB define the domain, but both must adapt the domain to their respective implementation concerns.
The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client.
I'd rather define my db domain in-code so I do not have to worry about writing the queries without type hinting.
Raw sql -> eh, I don't have the patience
Raw sql w type hints -> better, I at least get a compilation error when I do something wrong, and preferably a suggestion
ORM -> this usually introduces it's own abstraction that needs it's own maintenance, but at least it's more code-oriented.
Yes, SQL is an awesome solution to querying DB's, hence I prefer option 2
Well yeah, of course. Sorry, when I said "DB" what I should have said was "data-layer," and this can include: repositories, ORM models, query-builders, etc. All of these are type-hinted "db domain in-code" and, still, not one coupled to your API.
reply