HN user

RSZC

249 karma
Posts1
Comments60
View on HN

A very small % of total work.

That seems valid in today's world. Right now it's expensive, slow, and accurate. I imagine in the fairly near future it will be cheap, slow, and accurate, and that'll be a great opportunity to let it run on anything time-insensitive.

Re current use-cases: in addition to planning, there's also some tasks which Opus just can't complete but Fable can. Multiple times I've spent hours in combination w/ Opus trying to debug some particularly nasty nondeterministic issue, only to have Fable nail it in 20mins while I walk the dog.

The savings can be a lot more than 20% - last month I had a roundtrip ticket of $2000 brought down to $1300 (and got there faster!) via the switching airlines approach. It did come with some additional stress - needed additional visas and was worried about missing flights.

If things go wrong with Kiwi, they're likely to go very wrong, yes...but on the other hand, if I can keep saving $700 per trip, I can afford for them to go very wrong sometimes and still come out ahead.

Used to do this job once upon a time - can't overstate the importance of just being knee-deep in the data all day long.

If you outsource that to somebody else, you'll miss out on all the pattern-matching eureka moments, and will never know the answers to questions you never think to ask.

The Reddits 2 years ago

The controversy around this one was always wild to me.

Mods editing comments was the most standard behavior on every phpbb/vb board I grew up on.

His edits were clearly edited, clearly jokes, and TBH I found them pretty funny. And people were *outraged* that he had the capacity and the temerity to edit their sacrosanct posts...

I took it as a sign of the changing times

For lots of companies, 'increasing their margin' refers to increasing their margin from < 0 to > 0.

That would be my charitable reading of parent post, and does anybody believe that Bandcamp was profitable?

That's the point. In a distributed world, the domain registrar doesn't get to determine who gets a domain and who doesn't. If one registrar doesn't want to work with you, you can work with another.

This isn't some hypothetical, unrealistic utopia - this is *how the web worked*. We gave that away by giving registrars sole control over tlds.

It's easy to say 'well nobody really cares about .dev domains anyway' - but why will it just be .dev moving forward? Is it so hard to imagine a world where .com is no longer the default, and companies/individuals have to pay exorbitant monopoly prices to some gatekeeper?

I've never been an activist in this regard. It just feels really shitty to see something that used to belong to us all, everyone, equally, get divvied up and sold off.

You're working under an inaccurate mental model of the web...or at least how the web used to be.

The OG model here is one of decentralization. In this model, the registrar (Google) isn't the owner of the domain. They're just a business that deals with the annoying details around registering a domain on your behalf, and you pay them a small fee to do so. Once again, the registrar can't sell or rent you anything, because they don't own anything to sell you. The registrar only sells the service of acting on your behalf.

Premium domains were originally seen as a shitty thing to do, because it put the domain registrars in the business of acting against their customers. Instead of registering a domain on behalf of their customers, they instead would buy the domains for themself, so they could then sell them at huge markup to their customers. Some registrars then took things further and pre-register domains their customers searched for, even if they never had any interest in buying the domain originally. Extra shitty.

The current .dev (or similar) situation once again feels really dirty to people thinking of the web under this traditional mental model. Domains aren't supposed to be just GIVEN to a single company to then charge whatever price they want. The web is supposed to be decentralized, and instead...we're here.

The WebSub spec recommends this approach, and I've implemented it, and I really would recommend against doing this.

It adds a tremendous amount of complexity to all of your services, where now all of your services will need to maintain the ability to answer the question 'what was your state at this point in time.'

It makes it extremely difficult to support new webhooks, and honestly in my experience nobody actually ever queries for the historical data anyway. My opinion is that webhooks just aren't the correct approach to take for anything absolutely critical. They're a great addition for stuff outside the critical path where delivery is not essential, and as long as you stick to that paradigm you can dodge these issues entirely.

Re 'thin webhooks' which require hydration:

- subject to either complexity to support historical state (e.g. what was the state at the point in time when the webhook was issued) or race conditions (two things happened, but your API only gets current state)

- honestly none of your consumers want this - they're gonna be like 'why do i have to also query an API why can't you just hydrate the payload in the webhook body'. Guaranteed.

- still probably the correct solution if the data is super private and you want to be extremely cautious about issuing webhooks for it

source: worked exclusively on webhooks and similar eventing stuffs at place you've heard of for a few years

Disclaimer - used to work at Twitch.

The policy may make Twitch look stupid, but it's for a pretty good reason - people would get banned, and then just play multiplayer (with voice or even video chat) with their friends who were also streaming. This effectively allowed them to continue to stream and interact with their audience despite their 'ban.'

Agreed that people often get banned on purpose as a way of keeping their name in the news.

Oversimplifying, but an unsubscribe link is a legal requirement under many different laws (CAN-SPAM, GDPR, CASL) for this sort of email. It's 2022, unsubscribe links are a solved problem, I'm not going to assume good intentions for somebody who is purposefully breaking the law in order to spam me.

Huh, I didn't expect to come across something I have such direct knowledge of.

I used to work with this data directly - I worked with MACPAC to prepare reports for the CBO on the efficacy of pay-per-performance programs, especially as it pertained to the possibility of switching Medicaid from a fee-for-service model to a pay-for-performance model. (6-9 years ago)

I just wanted to chime in on this one quote:

We have all the data we need to know what the outcomes should be for a provider over the course of a year.

The data here is exceedingly low quality, especially for Medicaid. Medicare is in a better state due to being centrally administered. We do *not* have all the data we need to make pay-for-performance more than an extremely rudimentary approach. Is that rudimentary approach still better than fee-for-service? Maybe - that's a complicated question I let the public health PHDs write very long reports on.

Afterpay has been a godsend for my girlfriend's (brick-and-mortar) business, which is in niche luxury items (keeping it vague).

Customers love using Afterpay, they search on Afterpay for products they want, and are redirected to her store. Online sales went from being essentially no part of her business to being 75% of her sales, and are probably the only reason her business survived the pandemic.

She has no problem with the fact that she needs to pay commission fees to Afterpay - it's a tiny fraction of the (unprofitable) amount that she would have to spend on advertising to achieve the same amount of sales.

That's an unusual definition of first hand...

Here's Merriam-Webster's:

obtained by, coming from, or being direct personal observation or experience

These lessons are not from the OP's direct personal observation or experience.

Having done it both ways this would not be my recommendation unless it's necessary - I think it adds a fair amount of complexity.

Some considerations: you'll need some sort of storage mechanism for these flags - is that a centralized configuration service for all your services? Maybe just a table in your database? But database / network calls are expensive to be adding to every single time your code executes the path in question - maybe it makes sense for your service to cache these values locally...but then doesn't that lose part of the purpose of 'fast rollbacks'? Maybe instead of a local cache you spin up a redis instance - but what if this goes down? Will all your instances default to the same value? Etc, etc, etc.

I'm not saying this approach is bad, only that it has complexity, and I find I generally can get away without it.

Previously worked at a Node company - at one point in an effort to improve code quality we ran statistics on errors we'd seen over the past [period - forget exactly]. Type errors were our most common source of error both by number of total errors and number of distinct errors.

I'd love to see any data or case studies that claim the opposite if you have any.

It's important to keep in mind that efficiency isn't usually particularly important for a startup. I'm sure they knew when they initially set up this system that it wasn't performant...but it was nice and quick and easy and gets the feature out the door. Why should they worry about $100k or whatever when they're funded for > $350M? Their bottleneck is engineer hours, not dollars.

Instead the rational thing to do is build something quick and dirty and optimize later, and that's exactly what they've done.

Hmmm...former skydiver here, not sure your point is accurate. I don't understand why increasing your forward momentum from tracking would decrease your fall rate.

I think your assumption that drag will slow you to 120mph is inaccurate - for example, if you fall heads-down your terminal velocity is instead up to ~180mph. Similarly, I'd expect that if you track in a direction your velocity could increase above 120mph while not lowering the speed at which you approach the ground.

Apologies - my physics knowledge and terminology is very limited, but do have some practical experience in the area :)

  OpenAI Five is the first AI to beat the world champions in an esports game, having won two back-to-back games versus the world champion Dota 2 team, OG, at Finals this weekend.
That's their opening sentence, and it's actively misleading.

There's a line between puff-up marketing and being actively misleading and OpenAI continually crosses it.

With only 25 heroes allowed (of > 100) they were unable to get >5k MMR...nowhere near pro level. What are they at with the full hero pool? 3k?

I'm not trying to cast aspersions on their AI work - it's obviously an incredibly hard problem. But instead of admitting that they failed to make a competitive team, they instead play a stripped down game that's easy for their bots' limited strategies, and then publish triumphant marketing releases claiming mission accomplished.

Sorry, should've been more specific - looking for the same sort of 'provide a container and we take care of everything else' experience, but ideally for a cheaper price. I know I could get a micro instance and set up ECS on it, but it just seems like such a royal PITA...

Also like how my deploy script is basically 'build image; push image; aws ecs update-service'.

With my side projects that are running on a droplet, it feels like there's an incredible amount of additional setup that I need to do every time I add an additional project. Add the new site to the reverse proxy, setup a git server I can push to, set up post-receive hooks for the server, etc., etc.