If you can, commit wholely to a parsing formatter and plug it into your CI pipeline. I've come to realise over the years that its not style I care about per-se, but consistency. With a parsing formatter and an opinionated linter, you're pretty much covered automatically across all development and developers.
Yep -- where I work, every language we use in any big way has a high-quality automated formatter, and we require all code to be formatted with these tools. It's been a dramatic improvement in code readability in general across the company. We have a few engineers who would consistently beat the formatter by a very small margin if they were formatting their code by hand, but they are the exception -- 95% of the code submitted across the company is improved by these tools.
I think quashing divisive conversations in the workplace is generally a healthy thing to do for the well-being of your employees, however Facebook has put itself in a unique position which also makes the move hypocritical.
Most of the APIs I use and build are best suited as RPC systems rather than hypermedia networks, so implementing the entire REST idea has never been immediately useful. Broadly the real consumers of RESTful APIs are not generic hypermedia clients (generalisation of browsers) which are able to traverse your flavour of hypermedia, but the things operating those clients. Most of the time, those “things” are dumb business logic applications that can’t explore the hypermedia to discover
new functionality and furthermore are not designed to do anything with it anyway.
If it is a human traversing the hypermedia however, they’re able to derive a lot of understanding about the API and its features, as if the API is self documenting, but that generally only occurs
during the development and debugging stages. After that the hypermedia is useless to the dumb business logic. Also I’m sure most humans prefer to browse the documentation on the alternative World Wide Web hypermedia network, as any good API would have documentation published there.
All in all hypermedia is mostly useful for intelligent consumers, so if that is not the consumer of your API and you suspect instead the consumer will be static business logic (the vast
majority of cases) then REST will not be particularly useful. As I mentioned an interesting use case would be bundling up documentation into the API itself and hyperlinking between that and related URLs, however the overhead is generally not worth it since you’re likely to do it better with documentation site.
> Most of the time, those “things” are dumb business logic applications that can’t explore the hypermedia to discover new functionality and furthermore are not designed to do anything with it anyway.
Dumb business logic is not the point. One of the benefits of HATEOAS is that it allows REST clients to be loosely coupled with REST services, in a way that APIs can change freely change (i.e., change endpoints around, break away functionalities into other services, etc.) without requiring clients to be updated under the penalty of breaking compatibility.
The main reason why no one does REST and everyone does RPC-over-HTTP is that while REST clients require tracking and updating state to support service discovery, RPC-over-HTTP just requires a single HTTP request to achieve the same purpose, albeit without the resilience and future-proof.
> One of the benefits of HATEOAS is that it allows REST clients to be loosely coupled with REST services, in a way that APIs can change freely change
My point is that even though they're loosely coupled, the API actually cannot change freely because the actual consumer of the API, the business logic, is still tied to the API through the client. If your API changes and the client/browser is still able to traverse it fine, but your business logic breaks, does that actually mean that the API is free to change? I don't believe so.
> My point is that even though they're loosely coupled, the API actually cannot change freely because the actual consumer of the API, the business logic, is still tied to the API through the client.
The main promise of REST is that following that particular application style does indeed allow the API to freely change without breaking backwards compatibility.
The main drawback of REST is that no one actually follows those principles.
With REST, the client is not tied to an API. The client seeks resources, and relies on content discovery processes to determine how to access those resources. The only endpoint that may be hard coded is a home/root endpoint, and all other resources are accessible through it by following hypermedia. With REST you care about the what, not the where.
> If your API changes and the client/browser is still able to traverse it fine, but your business logic breaks
This is where you're getting it wrong. REST is all about the interface. The interface has zero to do with the business logic. If you have an interface that allows you to access the same data but for some reason your business logic breaks due to non-opersrional reasons (i.e. extra latency from the content discovery process) you need to have a talk with whoever screwed that up.
> Dumb business logic is not the point. One of the benefits of HATEOAS is that it allows REST clients to be loosely coupled with REST services, in a way that APIs can change freely change (i.e., change endpoints around, break away functionalities into other services, etc.) without requiring clients to be updated under the penalty of breaking compatibility.
There is a very limited amount of useful things that you can do here without breaking "conforming clients", at the cost of forcing those clients to implement much more expensive and error-prone logic in order to not break.
In reality, clients aren't going to conform, they're going to hardcode logic and they're going to break if you do any of the things that "shouldn't break conforming clients".
This means that in practice, on top of being more annoying to use and implement, REST APIs are more likely to break than RPC-APIs, which you can trivially extend with optional parameters or additional procedures.
That is true, but I would argue that typical applications are hard to implement in a RESTful way, since there is always some kind of understanding necessary. A human could understand that "inbox" was renamed to "incoming mail" in an email application. But what should some kind of RESTful client without understanding the semantics do?
> I use vim simply because it is ubiquitously installed on every linux and Mac system no matter what or where
This was also my initial reason for learning Vim so that I could comfortably write code on any machine I encountered, but the editing experience was actually really fast and enjoyable so I stuck with it ever since.
I'm guessing Epic wants the court to break down Apple's monopoly on app sales on iPhones, potentially by requiring them to allow third party app sales via alternative marketplaces, then swoop in with their Epic Games iOS marketplace and capture a big chunk of Apple's in-app purchase lunch. Considering the sheer size of Apple's revenue from gaming despite not being a game development company[1], I'm guessing that Epic has weighed up the expectency of proceeding with this legal battle and decided its worth the risk.
I mean if this is their plan and they pull it off then hats off to them. As a consumer I welcome healthy competition.
I have been using Spectacle (https://www.spectacleapp.com/) for years wishing it had mouse driven window snapping. I even once tried to implement it myself but gave up. I just tried Rectangle by your suggestion and it is absolutely amazing. Thank you.
They generate on a cron job every 15 minutes and I also pass the site through a Cloudflare cache because I'm cheap and the actual code runs on a $5 DigitalOcean box :-)
