Any regrets about the namespacing or things you’d do differently with it now looking back?
214 karma · joined May 4, 2017
My current SaaS project is https://kopi.cloud, it lets you keep your email address private via email forwarding / mail-to-rss functionality.
There's your answer right there, no need to ask.
Without human advice and a metric shit-tonne of guidance (either pre or post) - anything that requires active consideration of future maintenance burden will cost you 2x-10x of the time you think "saved" over a medium-term time-frame.
The alternative is to spend at least 50% (or sometimes up to %100) of the "saved" time in active review and iterative improvement of the solution design.
Yeah, no corporate bias here whatsoever
Sooo.... "be more professional in your writing"?
Why does this person owe you "professional writing" on their personal comment?
The version of postgres you think you're specifying isn't exactly the community postgres, it's an AWS maintained fork and this is an example of where they were seeing an error message from a future version of postgres that had been back-ported in the fork (or maybe AWS contributed to PG and it landed in a later version).
---
I guess I knew this - it's obviously not the exact same version, when you stop to think about it (pretty sure the doco tells you this explicitly too).
But I've never personally observed a difference, so I never really gave it a thought.
> "I think we've become so negative about hints that we rarely have a rational discussion about them... I also don't enjoy telling a customer 'hey, I know this query started misbehaving in the middle of the night on Christmas, but hints are bad... you can just have your web site be down for the next 20 years while we try to improve the optimizer.'"
https://www.mail-archive.com/pgsql-hackers@lists.postgresql....
Above quote is from the author of pg_plan_advice itself, from a few years ago.
So given his proposal isn't just band-aiding query hints into PG, is from a committer instead of being a drive-by patch, and might be even more generally useful/applicable than "add query hints" - maybe we could see some movement here.
[1] - I say this as a daily user of claude-code, paying $200USD/mth, of my own money, BTW.
If you're building a brand new, multi-language, multi-platform system that uses advanced open-api features - you will get bitten by lack of support in 3.1 versions of tooling for features that already existed and work fine right now in 3.0 tool versions. Especially if you're using a schema-first workflow (which you should be). For example, $ref's to files across windows/linux/macos across multiple different language tools - java, .net, typescript, etc.
If you need (or just want) maximum compatibility across tools, platforms and languages - open-api 3.1 is still not viable, and isn't looking like it will be anytime soon.
That's some serious forward thinking you've got going on with your date format there. I like it, I will be formatting all my years to 5 digits from now on.
OTOH, if it was just a typo - keep it to yourself, I don't wanna know. I'm all in - 5 digit years is a thing now.
This stack, plus claude-code, with the whole project fully automated (i.e. claude-code run all the parts easily) - is a literal productivity super-power. You can crank out entire complicated LoB apps, 10 - 30 pages of distinct, medium-complicated functionality in about a week, if not less - instead of weeks or months. Fully tested, production-ready codebase, not prototype-tier/vibe-code.
The problem with bad stand-ups is usually that they're just "personal status updates" by another name. They're abused as a way for team lead/project manager to "get a feel" for what individuals on the team are doing. Bad managers do this, because they're bad at their jobs. It's literally their job to know what people are doing, where they're at in their various tasks, what's going on with the project. They should be doing that all day, every day - when they're not "managing up". Gathering info in a 15 minute standup is both too short a feedback cycle and too long and nowhere near high enough bandwidth. It's also one of the major reasons stand-ups frequently go off the rails and end up taking so long, in badly run projects. Stopping those derailments is actually supposed to be one of their jobs and should be one of their main priorities during the stand up.
If you're stand-up involves going around the team, one person at a time asking "what did you do yesterday, what are you doing today" - that's a bad stand-up.
Stand-ups should be run from the sprint board - you run through all open tickets for the sprint, asking whoever is assigned to that ticket "what's up with that?" Once you've gong the through the tickets, you're done. No looking forward to next sprint - that's for backlog grooming and planning sessions. No looking backward, that's for retros.
Don't get to talk during the stand-up? Then WTF are you even working on, and why isn't a story in the sprint? That's a question the manager should be asking and resolving - privately, outside of the standup.
Stand-ups are for "visibility of the team, for the team". Not for managers or other wanna be management.
Stand-ups are for telling your teammates "i unstuck this ticket this way, if that's an issue or there's a better way, hit me up after the standup" or "I'm going to be working on X and I don't know anything about that; anyone who can help me, hit me up after the standup".
If your stand-ups aren't like that they're bad stand-ups. Because your manager sucks. Don't worry - most managers suck. Deal with it, get over it; and stop blaming your tools.
But a naive increase will punish the majority of customers who aren't yet using a similar efficiency mechanism.
My guess, if this approach becomes popular - we'll see a whole new layer of complexity added to Lambda pricing making it even harder to estimate lambda costs ahead of time.
AWS have already calculated the pricing model of lambda to take advantage of this massive inefficiency of their lambda product, they charge multiple customers simulatnaeously to use for the same hardware for the compute that would otherwise be sitting idle 95% of the time due to Lambda's basic design.
If large numbers of customers start using this model to reduce AWS' ability to double-dip, it's going to severely affect the profitability of Lambda, I wonder how AWS will respond?
Far from it.
For my personal stuff, I don't opt out of training for this very reason. What's more, I resent Stack Overflow and Reddit etc. trying to gate-keep the content that I wanted to give to the community and charge rent for it.
I used to intentionally post question-answer style posts where I would both ask the question,wait for a while, then answer the question on both Reddit and Stack Overflow. I don't do that anymore because I'm not giving them free money if they're not passing some of the benefit on to the community
Turns out: nope, Claude Sonnet regressed and got significantly dumber. The internet, obviously, assumed dastardly intent from Antrhopic. But they reckon "nope, we messed up - sorry about that, but hey - stuff happens".
It's kind of scary how Anthropic makes a change that makes the model dumber and my knee-jerk reaction is "What am I doing wrong? Am I getting dumber?".
And their response doesn't exactly inspire confidence either.
Initially I thought AWS were guaranteeing this wouldn't cost you money, but:
> What happens if I exceed the free usage limits of always-free services? > > If you exceed the free usage limits, your account will begin incurring charges
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2...
Not sure what you were intending to say, but here's what I parsed when reading that post:
"There should be no context change from <changing the context>".
Moving "only" to any other spot in this sentence is grammatically correct and changes the meaning.
As for "rules", well, welcome to English: the rules are made up and the points don't matter.
I don't use BlueSky so I'm not sure - just interested. Especially if it's already going the route of Twitter/Facebook, etc. - which I expect it to long-term.