dan15

> With SSO via Google, FB, you have to agree to share data with them

Not sure about Google, but with FB you can choose which information to share with the site.

This is the main reason I don't use it. I like having predictable monthly pricing that remains consistent.

Your list is missing quite a few major providers in the "low end" VPS space, such as BuyVM, Ramnode, Virmach, HostHatch, and probably others I'm forgetting.

I guess this isn't usable outside of AWS? It's unfortunate that it's tightly coupled to one particular provider.

Most communication is via Workplace (group posts and chat). Emails aren't very common any more - mainly for communication with external people and alerting.

FB uses Office365 for email. It was on-premise Exchange many many years ago, but moved "to the cloud" a while back.

Facebook caches URLs pretty aggressively (often you need to explicitly purge the cache to pick up updates) so I don't quite understand exactly what happened here. The article is very light on details. Do you have 7 million unique URLs that have been shared on Facebook? Or is it the same URL being scraped over and over?

Are you correctly sending caching headers?

It's likely that apps that load the SDK are using other features of it, such as Facebook Analytics (which is similar to Google Analytics), not just login with Facebook.

Do you feel the same about Google Analytics? Its data collection is very similar.

> The first 3 of these will be severely cut back during the virus as offices are closed.

Facebook are still paying all contractors their regular pay, even if they're not needed at the moment:

> Facebook will pay contingent workers that cannot work due to reduced staffing requirements during voluntary work from home, when we close an office, when we choose to send an employee home, or when they are sick

https://techcrunch.com/2020/03/06/facebook-commits-to-paying...

> It's gonna harm some people who were on track to do better than exceeds, though.

There's no news about this yet, but I've heard that people that are on track to do better than exceeds will likely still have a review so that they don't miss out.

The other thing that wasn't really covered is that contractors are getting paid even if they're unable to work (for example, people that work in security and culinary teams that aren't required because the offices are closed). That's one of the best things IMO.

> I assume that if you integrate Babel and Webpack via webpack "loaders", some amount of work is saved (just guessing though)

The Webpack babel-loader just calls Babel with the source code, it doesn't reuse Webpack's AST: https://github.com/babel/babel-loader/blob/master/src/index....

It has to do it that way, since Babel could parse some syntax that Webpack doesn't recognise (like Flow or TypeScript annotations). Webpack loaders can even take non-JS input and produce JS output (eg. "svgr" takes SVG images and produces React components) so I don't think Webpack can even assume that the input is JS at that point.

DNS challenges are great for internal services too, where you want server-to-server communication to be encrypted but the servers aren't accessible over the public internet.

> You can't compile the code of scripting languages

Of course you can. Compiling is a process that takes some code as input and produces other code as output. The output code doesn't have to be at a lower level of abstraction (like assembly or machine code).

A compiler that produces code at the same level on abstraction (eg. going from TypeScript to JavaScript, or newer JS to ES3 JS) is often called a "transpiler" but a transpiler is just a type of compiler, and it's totally valid to call it such.

> which is now vanilla MIT with no stupid patent clauses

Except a patent clause actually gives you more protection, not less. That's why some other licenses explicitly include a patent grant, like the Apache license. I think the patent clause was a misunderstanding more than anything else. In any case, Facebook responded to what the community wanted.

In addition to this, one reason the JS tools of today are relatively slow is because they all need to parse the code. Babel parses it to compile it, then ESLint parses it again to lint it, then Webpack/Rollup/Parcel parses it again to bundle it. A single tool that reuses the same AST representation for all three tasks has the ability to become a lot faster.

> is the idea that people might continue to use the tsc/flow binaries in parallel with Rome

I think so, in the same way that people use both Babel and TypeScript (or Flow) today. TypeScript/Flow check the types, while Babel simply strips them out when compiling the code.

> Compiler here probably means transpiler.

A transpiler is a type of compiler, so it's fine to just call it a "compiler".

Works fine on BuyVM, which starts at $20/year. https://buyvm.net/kvm-dedicated-server-slices/

> Also, programming environment is just so much nicer IMO on mac.

Really? I had a Mac for a few years, but I found that I didn't like the environment as much as either Windows or Linux. A lot of programming environments work best on a Linux-like environment and don't do so well on something BSD-like (such as MacOS). There's a lot of open source software that only works on Windows and Linux, too... MacOS has such a small market share that many open source developers just ignore it.

Technically you don't have to with semver, it's just a good practice. From https://semver.org/:

> A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

Note that it says "MAY" and not "MUST", so it's optional.

> Obviously you won't be able to share cookies between the site and the api.

I don't know of any API that requires cookies from the site. Usually you use an access token or something similar for an API.

> But you have the additional challenge of having your api domain treated as 3rd party and are thus subject to all the security measures and sandboxing that come with that.

CORS solves most of the pain points. You just need to ensure the API is serving the correct CORS headers.

> Either you use LetsEncrypt which automates the pain away anyway or you do the sane thing and buy a wildcard cert

For what it's worth, Let's Encrypt plans to offer wildcard certs starting in January 2018.

Some ccTLDs have good infra though. Many of the smaller ones (particularly ones ran by CoCCA, such as .cx) use Dyntld or Packet Clearing House which have pretty good servers and connectivity.

I was using SVN for my personal projects 10+ years ago. It's crazy to think that some companies may not be using source control even today...

Pushes are failing for me with this error: "remote: fatal error in commit_refs". I'm seeing it across various repositories so it's not just one particular repo.

Discourse really isn't very good. If you want a more powerful forum system that doesn't need as much CPU power, get SMF or Xenforo or MyBB or something. If you want some new fancy thing, get NodeBB. Many of the sites that used to use Discourse are moving to NodeBB.

Oops, that's my fault. It looked fine in the Github editor's preview when I commented it out, so I assumed it'd actually work properly.

Chocolatey is coming soon, once they approve the package.

The recommended installation method is actually to use the package/installer for your environment. Currently there's a Windows installer, Debian package, and RPM package, with Homebrew coming soon. See https://yarnpkg.com/en/docs/install