> For packages typed with JSDoc, CTRL/CMD clicking on a function will take you to actual code rather than a type declarations file. I much prefer this experience as a dev.
ok i didn't think about this, that's an underrated benefit
It doesn't. You might be thinking of libraries that you wrote, not packages from e.g. npm, which are distributed as JavaScript + type definition files not as TypeScript code.
In real IDEs, not glorified text editors like VSCode, it does. I use this often in IDEA, it's muscle memory so I'm not even completely sure what to press, but it's likely "go to definition" and by default is tied to ctrl+alt+b.
IDEA adds its own analysis on top of that provided by the language server.
Works on JS + every variant of type definitions I've ever seen, among many other things (not only programming languages, but also database objects, etc).
> IDEA adds its own analysis on top of that provided by the language server.
IDEA implements its own analysis and doesn't use tsserver at all. Its semantics diverge in subtle ways, I believe in both directions (some code that tsserver considers valid IDEA will consider invalid and vice versa).
assuming they were able to acquire customers and dominate the world with that business model, would that have prevented them from doing algorithmic feeds and promoting clickbait and poisoning politics and the rest?
sure, people would have been able to cancel their monthly facebook subscriptions if they didn't like that stuff. but we can effectively do that now just by not using it.
That is database schema. The post asks for opinions on database contents. They are related though, so it's a valid question.
> I suppose you include a script to update staging
Essentially, yes. But if I write a script to do it on staging, why don't I write one for prod as well? Maybe I could even go beyond that. Make a simple tool to handle those scripts for me (that's migrations).
It requires some version control and deployment discipline, which is something you probably wouldn't have if you're adding columns directly on the prod db.
I learned very early that no developer should have access to prod db. Not even read access. No writing, definitely. Schema changes by a single developer outside version control should be impossible.
Not so much an exception but a work around according to the guardian newspaper [1]:
[...] the law specifically says “no head and shoulders portrait or bust of any person, living or dead, and no portrait of a living person may be included in the design on the reverse of any coin “created to mark the US anniversary”.
The proposed design features a wider illustration of Trump on the reverse side, a move that legal experts said would fall outside the ban on a “head and shoulders portrait or bust”.
Ironically, also because Go is one of few popular languages for web applications that can produce a single executable binary and does not require a container to deploy with ease.
I think there's a pretty big citation needed on that part of the article. I'm not clear that Docker contributed to that anywhere near as much as a general increase of momentum around Go as it became better known in the industry.
I've never heard of anyone basing their choice to use Go off of the fact that Docker used it. Certainly, the fact that Google was pushing Go mattered far more.
I think you should see this article as someone who's a huge fan of Docker due to working there for years.
I know Vercel has their fingers in a bunch of pies, but is there any significant vendor locking? I worked at a place where we just put nextJS in a docker container and hosted it ourselves, but maybe we would have got more on Vercel?
ok i didn't think about this, that's an underrated benefit
reply