1,115 karma · joined March 14, 2018
I used it regularly for almost a year, eventually got off because of some UI bugs that came up and because the Safari dev tools feel so clunky/need relearning compared to Chrome & FF.
The main caveat as someone who works on mostly average web CRUD apps, is that "Use PG/SQLite for everything" usually falls flat when the tools I use day to day don't support that use case super well or have rougher edges.
If your framework/ORM/whatever of choice doesn't support the full feature set of that driver compared to Redis/ES/Whatever you're replacing, you'll find yourself going down rabbit holes doing workarounds instead of staying with the "happy path" and just using separate tech for what it's specialised in.
If you already are doing most of these sorts of features by yourself instead of with frameworks, maybe it's fine, but this does start to feel like a time-to-release hindrance if you don't want to fiddle with the minutia.
Yes, that's exactly what I want. I want to know what is done with a high level why, NOT a paragraph explaining each line of code modified.
A frequent tweak I've made on coding work with Claude in the last month is asking it to restrict its comment length to 1 line/sentence max. I just want `// This happens because XYZ upstream`, not `// Historically from ticket blahblah there was some dummy code where we discovered ancient runes and that led us to looking into your birth records and then triangulated an issue in XYZ upstream that we compensate for here`.
The model's "most information dense representation" is very similar to how we compress data in the first place: most of it is redundant or unnecessary for the purposes of storage. I'll "decompress" the 1-liner context myself when I read it again in 6 months. But I can't stand reading just so much slop commentary when we're all writing more code at once and having to review more than ever.
There's competition in the other TCGs, and of course a 2-sided marketplace is one of the hardest things to seed. So this is mostly just a project that I can put any fresh ideas into that I wouldn't be able to at my dayjob.
I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".
Lo and behold, the EXACT person I had in mind when making the rule, moaned about it.
Works as intended.
Maybe my attention span is truly stuffed, but I really can't stand it when a video essay is the most succinct source on a topic - waiting for someone to express their thoughts in speech, with sometimes slow cadences or their own waffling, combined with sponsor segments (yes I use SponsorBlock, but sometimes or on other devices ads get through), etc.
So I use AI summary for a lot of informational videos now unless I actually am watching it for the entertainment and production value. I don't need 10 minutes on "this will change the way we look at XYZ" that has only 1 minute of real information in it.
If nothing else, using the smart model for planning to hand off to the previous gen for implementation still seems like a useful pattern.
My plan is to make hay while the sun shines: get some planning in over the next week or so, and just let Opus take care of it when I get to actual implementation.
So much of our lives is now digital. Important accounts of all kinds, banking, etc.
Waiting on several giant corps to grant your loved ones access after they go through the bureaucratic hole of documentation is... rough.
Putting my master password in my will feels the same as just writing it on a note on my desk. Putting it in a note in a safety deposit box is high effort and cost.
Anyone got a better alternative way to set this up if self-hosting and not going with Vaultwarden?
You shouldn't be looking at just various kinds of earplugs as options for this. You can get custom made earplugs for your ears for differing use cases (sleep, concerts) at an ENT.
Fair enough, that buys a little bit of time to not break deployments I supose.
> When the build process completes, it tears down the overlayfs
Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine.
Thanks for the info!
"Builds" are the same as deploys, so when working with server(s) instead of larger scale deployments, I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios.
But I have seen this in action, which is why I'm wondering if I'm missing something.
The clearer benefit to me seems to be in this scenario to use it as a fast environment provisioning tool.
> disk, i/o exhaustion
This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case.
I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deploying by definition also contains my source code because I'm not deploying anything compiled.
How? What I'm describing is using Docker less.
> The build process can exhaust resources on the host
Maybe, but I've yet to have a host where that's the case for usual CRUD fare.
> The advantage is simplicity, and it's often worth the risk.
That's basically what I'm evaluating for here.
For bog standard LAMP or similar stack applications, I've not understood the advantage of going through the build-image-then-pull-on-host rigmarole. There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects.
But I have seen that done fairly often, hence was wondering what the point was.
Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP?
I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes more like Ansible for me - the tool I use to build the environment, not the entire app.
For the purpose of my question, let's assume I'm building normal CRUD services that can go a little tall or a little wide on servers without caring about hyper scale.
There is no truly good, independent, feature complete browser out there right now if you want to avoid Chrome and have something that a) works and b) isn't hostile to the userbase.
Brave at the very least said they'd keep supporting Manifest v2 extensions, though not sure how you'd acquire them anymore unless Chrome web store has kept the listings up.
LinkedIn has also been especially hard to find a good blocker for to remove the sponsored/suggested posts from the timeline (it's just full of garbage engagement bait hot takes).
I just vibecoded a tampermonkey script to block scrolling on Instagram and also block reels. I also had it redirect from the `/reels/` URL to `/reel` which is just the single video view (for when friends link me memes), but it seems they removed that.
And of course, OpenClaw is built to be a very generalist agent with a chat interface - same effective outcome as remotely controlling an AI harness, but not exactly what everyone wants.
We only found out for my family member after the 3rd neurologist's opinion after ~2 years of this.
Not everyone does their professional due diligence - cue endless anecdata about the healthcare industry. It's good to just be aware.
Left untreated for a very long time (decade+), it spreads to the brain and causes dementia among other things. Older generations with stigmas, taboos, or from lower educational backgrounds seem (to me) less likely to get tested, so it seems plausible.
Source: Have recently discovered this myself with a family member from their neurologist.