SQS FIFO has exactly-once processing
That's not what the parent post was referring to. If SQS (or your ability to talk to it) is down and your database isn't, what do you do?
Readit Newsvp8989 commented on PostgreSQL is enough gist.github.com/cpursley/... · Posted by u/cpursley
>always been about power and ego.
No, it's about CRE investments. Pre-'rona, CRE was viewed as an extremely stable asset class. There are lots of interests (including a lot of 401Ks I bet) that don't wanna see the asset class fail.
Can you elaborate? To my knowledge, 401k target date funds sometimes have small allocations to REITs (like 3-5%) or REIT indices that might be comprised of a mix of commercial and residential. Maybe there is some exposure to CRE mortgage backed securities through the bond indices?
vp8989 commented on Copilot key will eventually be required in new PC keyboards arstechnica.com/gadgets/2... · Posted by u/kens
Terrible advice. This is like telling people not to use an IDE because auto-complete isn't always right. Or not to use document templates because they aren't finished.
Github Copilot can - in some domains - make me 30% more productive. Once it becomes commonplace and the legal issues are sorted, luddites who refuse to use it will be left in the dust.
Focus on high value work that can't be automated is terrible advice?
vp8989 commented on How Australia’s ‘Bluey’ conquered children’s entertainment ft.com/content/0a3c9806-8... · Posted by u/propter_hoc
vp8989 commented on Hyper – A fast and correct HTTP implementation for Rust crates.io/crates/hyper... · Posted by u/belter
It's a good question with an unsatisfying answer. Networking is kind of difficult.
Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be:
* RFCs are often ambiguous, I've seen teams implement a protocol in a way that certainly seems to follow the RFC but won't be widely interoperable.
* RFCs are often incomplete, many protocols are specified across a lot of different RFCs, and by different authors, so it's easy to miss important details or even whole RFCs exacerbating the above point.
* RFCs are regularly released as protocols evolve and invalidate older versions of the protocol (or early experimental versions of the protocol, etc) often. Sometimes the newest RFC does a lot of work to disambiguate what would be allowed by older versions see for example this recent RFC https://httpwg.org/specs/rfc9110.html
* Independent of what the RFC says, there's what Cisco does (or MS or Google or other large influential imlementors).
* A lot of protocol implementations don't implement the full protocol (that is various extensions or rarely used features).
* A lot of protocol implementations implement what the RFC says in the most commonly aggreed on way, plus a compatibility options for other commonly used implementations, plus some oddball interpretations of the RFC that the authors like.
* There's vendor-specific extensions.
* There's common but unspecified behaviors that implementations tend to converge on, but which aren't easy to intuit.
* There's implementations that handle mixtures of versions (e.g. implementations of http 1.1 that handle 1.0 or 0.9 just fine are common).
And so on. So to answer the question "is 'it's correct' worth mentioning?" - yes, something along these lines tends to be important.
Of course "what does correct mean" is a giant can of worms....
In the case of hyper I think it means: an attempt to be extremely precise in what is allowed (and as close to the disambiguated RFCs as possible), and strict as well - not being particularly loose in what it accepts as input. That's my interpretation anway.
"Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be"
I learned this for myself when I tried coding an IRC server for fun. Quickly found that I made more progress, faster by just using Wireshark to see what an established server was doing and copying that.
vp8989 commented on Ask HN: It's 2023, how do you choose between MySQL and Postgres? · Posted by u/debo_
If you are using .NET then Postgres might be better choice. (much better support for drivers and default ORM).
If you need replication go with MySQL.
https://mysqlconnector.net/ is very good.
Dapper and ^ that works very well IME.
Agreed about replication.
Deleted Comment
1) "Web application development" doesn't happen in a vacuum. Often it happens in contexts where the "backend" is also consumed by various non-web applications. In those contexts, collapsing the frontend and backend back into 1 component is less of the slam dunk than it's made out to be in this post.
2) The missing piece is how you can achieve this "collapsing" back of functionality into single SSR deployable(s) while still preserving the ability to scale out a large web application across many teams. Microfrontends + microservices could be collapsed into SSR "microapplications" that are embedded into their hosting app using iframes?
vp8989 commented on Rules of thumb for software development estimations vadimkravcenko.com/shorts... · Posted by u/bndr
That's only true if there's a fixed set of work to get done. But that's rarely the case. Often, management has N different things they could have done, and enough people and time to do M of them, for M < N. Which ones should they do? Well, whatever maximizes profits. So they (management) estimate income from each thing that could be done, and ask engineering (hopefully) to estimate how much it will cost to implement (or how long it will take, which equates to cost). Then they make a (hopefully) more informed decision than they otherwise could have made.
Look, there's lots of ways this gets done badly. I get that. But the idea itself is not nonsense.
At the team level, keeping M to 1-2 works really well in my experience. Of course M is never really 1 or 2 because you're always wrapping up small details from $previous, looking ahead at $next or just doing $maintenance. A reasonably sized team will be kept busy enough with "just" an M of 1 or 2.
The constraint helps to ruthlessly focus on the most impactful work. The maximalists want to get cute and try to bin pack but it just doesn't work, unfortunately.
vp8989 commented on Rules of thumb for software development estimations vadimkravcenko.com/shorts... · Posted by u/bndr
Anecdotally, I've observed across my ~12 year career so far that an emphasis on estimates and estimating is negatively correlated to productivity, lead time, velocity, impact, positive outcomes etc...
I suspect the reason is because management is trying to use numbers to justify bin packing more work to an already oversubscribed team. What never shows up in those project management spreadsheets is the very real and predictable cost of context switching and the increase in mistakes from dealing with a larger amount of in-flight work.