> poor sleep quality, headaches, stomach issues and back pain
While it's true that volatile-pay work is extremely stressful, this seems like a cherry-picked study to be able to write a flashy headline to people rightly concerned over a hot-button issue. They could have just as easily just said that volatile pay causes anxiety and stress, which IMHO you don't need a study for, just like we don't need a study saying that eating less increases hunger symptoms.
Anxiety and stress itself is a well-known cause of all these above issues, and there are a multitude of other work-related stresses than just volatile pay.
Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner.
For instance I'm in the process of building a VScode and browser extension that would automatically star repo's of all npm packages and linked scripts used in your code (including dependencies). I think that's a basic gratitude thing for myself, and a tool some people might be interested in.
> the more API coverage a platform can provide the better
This is a very common opinion of people who consume APIs, but people maintaining the APIs often feel differently. Every API endpoint is a promise, and it's also a constraint on future innovation. Firefox is a good example, in that their old API allowed extensions to "intimately intertwine" [1] themselves, which proved a huge barrier to improving the Firefox core.
>Every API endpoint is a promise, and it's also a constraint on future innovation.
I'm not referring to keeping any particular API endpoint alive. The problem you raise can be easily mitigated with a correctly built-out API versioning system and - more importantly - API deprecation policy.
I'm referring to just API coverage of platform features. In that sense maintaining API's can be viewed as not much different than maintaining the actual platform features themselves. Obviously the more feature you provide the more maintenance/resources will be required. That goes for both API's and the features themselves.
Oh? If it's that easy, could you explain how you would have applied that in the Firefox case and avoided the massive problems they experienced?
Because in my view their problem wasn't about API versioning. They came out with a new version and deprecated the old, after all. It was that they provided way too much coverage early on.
I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API.
Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.
My point is very simple. You said "the more API coverage a platform can provide the better". I'm saying that's not true because it can create large long-term costs that outweigh the benefits. I even gave an example. I get why you as an API consumer want maximum surface area. But API producers often feel differently, and they have good reason to. I think the better general strategy for API producers is to open up gradually based on actual need discovered via dialog with community.
Users build their workflows around apps that use APIs.
Sometimes devs get bored/burn out/get a family/die/get a promotion, and stop building new features for apps. Sometimes, if users are lucky, they'll stay on top of security issues. But maybe, users install an app once and never update it even if it is getting updates. Which is risky, but if it works for them, whatever.
Service provider kills API endpoint.
App breaks.
User's workflow breaks. Worked yesterday, does not work today. :-(
Maybe, if the user is lucky, they connect with other users of the app, or users of other apps that are similarly affected, and they figure out workarounds, or someone creates a fork of the app(s) to use your new equivalent endpoint (if you even created one!) and, eventually, after much wailing and gnashing of teeth, they pick up the pieces of their workflow which you just broke and cobble together a new one.
Sounds cool, except that people will get banned. I'd recommend making a menu where people can click on individual dependencies to star, or have a button to star all (but with a very clear warning about the possibilty if getting banned).
Risk 1: Impersonation. ie, someone sets up hmrc.gov.gb and tells people "pay your taxes here" and scams a bunch of people.
Risk 2: Economic loss. People selling .gb domains might take away from .uk revenue.
Risk 3: Political fallout. Perhaps Chagos Islanders somehow get control .gb and demand that the UK give up .io in exchange. There's plenty of geopolitics that could get brought up.
Risk 4: opportunity cost. Perhaps later some major use for .gb arises, but by then it's too late.
These are all pretty small risks, but this is the kind of thing they may have in mind.
If the domain has ever been used for anything, there are serious security reasons to never reuse it.
For example, imagine your recovery email address for something important is bob@something.gb. If 'gb' is ever reassigned to someone else, they can now get access to anything ever registered at a gb address.
This is the reason things like gmail accounts are never recycled to another user. Early services like hotmail would recycle accounts, but it has since become an 'obviously bad idea'.
Ha. Happens to be there is a script out there somewhere which allows you to extract the private key of any of your MFA codes from Authy through Chrome DevTools (it's an Electron app) so you can use it in whichever MFA solution you want.
It could be because I wasn't spamming them with tweets i.e. I only sent them about 14 tweets total between their two handles over the course of a week, but I can see how they might've blocked someone else doing the same.
> Also, would this be affected by the latest changes at Twitter?
Sorry, I'm not familiar with those changes, so I'm not sure.
Under President Arafat, the Fatah-dominated Palestinian Authority adopted the 2003 Amended Basic Law, which stipulates Islam as the sole official religion in Palestine and the principles of Islamic sharia as a principal source of legislation. The draft Constitution contains the same provisions. The draft Constitution was formulated by a Constitutional Committee, established by Arafat in 1999 and endorsed by the PLO.
External actors, hmmm... I believe you mixed that up with internal actors like Hezbolla and others, who have a tight grip on the countries political system.
Last time I checked the leader of Hezbolla, which is part of the government of Lebanon said: "There is no solution to the conflict in this region except with the disappearance of Israel."
While they might sound convincing that they might mean this for everyone's good (and it might be good for everyone, this is typical of Google in GCP and elsewhere trying to force more modern experiences because "they know better" than everyone unwilling to upgrade their platform.
While it's true that volatile-pay work is extremely stressful, this seems like a cherry-picked study to be able to write a flashy headline to people rightly concerned over a hot-button issue. They could have just as easily just said that volatile pay causes anxiety and stress, which IMHO you don't need a study for, just like we don't need a study saying that eating less increases hunger symptoms.
Anxiety and stress itself is a well-known cause of all these above issues, and there are a multitude of other work-related stresses than just volatile pay.