Hacker News new | past | comments | ask | show | jobs | submit | thezilch's comments login

That's ... not what most people are doing. People send _application_ errors on HTTP 200 response codes, because HTTP response codes are for HTTP and not applications. Most "REST" libraries and webdev get this wrong, building ever more fragile web services.


Applications using status codes is useful because it can tell browsers and load balancers to not cache the page in a uniform way.


I don't think the distinction is as clear-cut as you're making it out to be.

For example, HTTP 409 Conflict generally means an application-level conflict (e.g. an optimistic concurrency mechanism detected a conflict).

HTTP 422 Unprocessable Entity is also usually an application-level error (e.g. hash validation failure, or identifier not recognized by the server).


Task failed successfully


Why should internal tools not have these things? That kind of argument smells of, internal tools can be slow. No.

Seems we should lift up Dear ImGui -- contribute, donate, feedback (document, gather requirements, etc), etc -- as opposed to suggest we not use it.


Dear ImGui is lacking good and focused code contributors, I'm stretching myself quite thin already and unfortunately pragmatically it currently wouldn't be wise for me to attempt working on accessibility features :( Right now the state of things is that a majority of even the simplest PR are poor quality, so I'm not too hopeful that such a complex feature would magically start getting good contributions. I am personally just accepting that things are going to take years to move forward. I'd rather have them more slow and stay sane. Dear ImGui is intentionally gated and made fugly for those reasons as well.

But any effort to document, specs, clarify etc would be helpful and not just to Dear ImGui.

Accessibility is a whole world that is hard to grasp when you are not a end-user, API are large, confusing, poorly documented, and I presume that there are a large variety of tools and use cases and it's even hard to gauge what are the low-hanging fruits that would be the best to implement/bind.

Given how obfuscated Web stacks are nowadays (since they do try to prevent unauthorized scrapping and automation), I'm honestly also a little bit surprised that nowadays screen readers aren't relying on OCR more?


I appreciate the work you do and I think what you're saying is completely fair and understandable.


I don't think they shouldn’t on principle, but they might not need to have them. For example, if there's a limited number of people who are going to work with the tools, and you know that none of them need such features, it could be entirely reasonable not to worry about them.


That's making a bet that you'll have absolutely no need to hire someone for that team nor that any of the existing members of the team will develop the need for accessibility features.


Google Domains made Google the equivalent of $0 and would teach them nothing about operating their core businesses.


As pointed out multiple times previously, Amazon and Microsoft provide domain registration services even if it's a solved problem. It's not that Google needs to be the best domain registration platform, but providing a normal domain registration service is miles better than not providing one at all (for example simplified billing and administration for smaller businesses, and automation for bigger ones).


And it's not being shut down, it's being sold off. There's quite a difference.


Google, and all other domain registrars, are obliged by ICANN to allow domain migrations in case that the original registrar is shutting down. Getting money from Squarespace is just icing on the cake.


I don't understand your point?

Google is selling Domains to Squarespace. Yes, many techies will migrate their domains, but majority of the people on Google Domains probably wont. That's why Squarespace thought it was worth paying anything for, after all.

Personally, I'm moving my domains already. But, saying Google Domains was shut down is inaccurate - it was sold, as business units/subsidiaries tend to be...


They are forced to sell it by their contracts with ICANN - this is not a decision that they have done voluntarily. If they can legally shut down Domains they would have done it.

Sure, in any other contexts, selling Stadia customers to Microsoft or Nvidia (for example) would be a voluntary decision, however they are barred from just shutting down this one. They can even shut down Gmail or YouTube with no legal repercussions (sure their reputation will suffer but legally it's in the clear), but Domains is in a different legal standing.


Present evidence it was forced vs. shut-down or stop spreading a made up rumor.


I’m not seeing why you’re being down voted. Indeed, the point being made (that Google would simply aborted all their domains if it weren’t for ICANN) is strange.

Of course they’re likely to not outright get rid of them thanks to ICANN. They could have however just given them away rather than selling them off. I feel like there’s some precedent there too? Maybe from Wordpress?

In any case, they weren’t forced to sell them. They had other options including _not_ shutting down. But even if they did merely give them to another company or sell them, people would have the chance to move their domain to another provider.

Really I just don’t get what point is trying to be made. Google shut down domains in every good faith interpretation of the phrase “shut down”. All the ICANN argument does is try to conflate “shut down” with “going against ICANN rules” but no one was ever suggesting that.


> In any case, they weren’t forced to sell them. They had other options including _not_ shutting down.

Fine, sure, but this is a cop-out. Clearly they really want to clear the thing: if it was to be a GCP-only option with no more consumer-focused Domains, they have temporarily set a transition period with no renewals and new domains and then bow out of consumer space, but even the enterprise version is being shu- sorry, I'll be using Google's term here, deprecated (https://cloud.google.com/domains/docs/deprecations/feature-d...). The Squarespace buyout is irrelevant here because unlike GCP Domains there are no automation features in the Squarespace's system (and have no plans to implement one), so you are required to migrate to another provider like DNSimple or AWS. This is a clear sign that they really want to dispose of it as soon as feasible.

> Really I just don’t get what point is trying to be made. Google shut down domains in every good faith interpretation of the phrase “shut down”. All the ICANN argument does is try to conflate “shut down” with “going against ICANN rules” but no one was ever suggesting that.

It's a reasonable assumption when you're talking about their first time in closing down things, but there is a clear trend, even solely in the enterprise space. (https://news.ycombinator.com/item?id=38020254) At this point, it is clear that Google does shut down things when they feel it.


And his context is what? Selling books and conferences? What has he actually shipped with his ideas?

To me, it's the Clean Code of web services.


Oh boy, a whole pizza!


Bad for both vegans and gluten intolerant people. Also pizza parties are sooo 2006.

Nothing demotivates people like a half assed reward. If you want something never to get done, offer a bad carrot. If you want only one thing to get done and nothing ever again, offer a good reward but then make the recipient fight you to get it. I thought pizza parties were the worst, and then I got an award that was announced but not delivered, and spent almost eight hours over the next month poking people to give me my goddamned prize. It became a second job and at the end I ended up resenting the entire experience.

Later at another job when we in theory had a generous reimbursement process that was actually a ton of red tape, I had flashbacks to that incident.


No, a full on everyone take the afternoon off catered food drinks to watch movies and play video games in our offices's bar paid for by the ops team personally.

Also don't assume we don't know our coworkers, when they first got to 8 in a row the slack channel looked like the Twitch chat of a popular streamer.

We have the buy-in from management that if it happens every day then it happens every day.

We are planning to change up the food if it ever happens again, pizza party is just a good title


Sounds good to me, as long as that catered food is pizza, preferably deep dish ;)


100%; we do that (see profile).


Why not use APCu?


I hadn't seen this before, but I'll absolutely look into this, thank you!

As for why AWS doesn't use it (if that's your question), I assume they didn't want to deal with the need for a system dependency also. That's something that is kind of a pain to me with PHP as well. Some PECL, some Composer makes mentally tracking and managing deps a bit trickier.


Classic over-engineered DevOps, adding complexity for complexity sake. When you have a hammer...

Everything you described was 2005.


In 2005 there were, for instance, fancy J2EE application servers instead of fancy container roulette tools.


No one is trying to get it for free. They are trying to get it for [significantly] less than 30%.

If it's so great to use Apple Pay (one click, easy to revoke payment -- sounds great!), why would a customer not use it over browsing to a random page, entering CC details, and worrying if it will be hard to cancel?

I'd guess the convenience is not worth 10%, much less 30%, to most users.


> They are trying to get it for [significantly] less than 30%.

So what is the right fee for access to iOS users, and in turn, paying for iOS development itself? This isn't just a transactional payment system, it's an end-to-end payment platform designed to take high-value customers and turn them into sales with minimal friction. iOS is that system, not just IAP.


> No one is trying to get it for free. They are trying to get it for [significantly] less than 30%.

And Apple charges 30% for sales of digital goods on their platform. You're trying to get what Apple is selling without paying for it. Don't sell on their platform them -- do what Amazon does with Audible or what Netflix does.

> If it's so great to use Apple Pay (one click, easy to revoke payment -- sounds great!)

Because that isn't what Apple is charging for, users don't pay this fee -- publishers do. They're charging publishers for the privilege to sell to Apple customers. I'm sure users like the convenience, I do, but the fee isn't for me. You're absolutely right that it's not worth 30% to me. But it's absolutely worth 30% to you when the alternative is not being able to sell on iOS and Apple knows it.

It's nuts that in threads like this that people begrudgingly pay Apple's 30% fee while in the same breath saying that they're overcharging. Well clearly not since you're paying it. If they were actually overcharging then you wouldn't be complaining because you just wouldn't have an iOS app.


> Because that isn't what Apple is charging for, users don't pay this fee -- publishers do. They're charging publishers for the privilege to sell to Apple customers. I'm sure users like the convenience, I do, but the fee isn't for me.

Do you seriously believe you're not, in the end, paying that?

I find it hard to believe that you do. Seems far more likey you're gaslighting for your idol, as Apple fanbois so often do.


You're not speaking to server authority but lag compensation.

Your "behind cover" example describes best your concern with lag comp. It works both ways. You having lower latency can suffer when attempting to take cover. However, you have the advantage when exiting cover; you will see others first.

It's as fair as it can be. As for feel, it definitely feels fairer than no lag comp.


People with a higher ping can only benefit from it if there is lag compensation in place - that said... lag compensation isn't an on-off switch - it makes things unfair to users with that unfairness switching sides depending on how much compensation you offer since higher levels of lag compensation will result in unresponsive "muddy" controls where you may often be teleported back in time to die after locally taking an action you thought compensated for it.

All these factors are pretty heavily interwoven in how the game ends up feeling to players.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: