DropkickM16

I wish these losers the worst. Working for zuck is its own reward.

Thank you, White Knight!

lol

You are seriously begging the question here.

Yes, as the world moves more and more toward online commerce, a statute specifically crafted for "fraud using transmission of information over wires" is just the modern tool we need to fight back.

Brett_Kavanaugh: U.S._Circuit_Judge_(2006–2018) https://en.wikipedia.org/wiki/Brett_Kavanaugh#U.S._Circuit_J...

No, as the employee option pool is generally common stock which is instead taxed at the most recent 409A valuation. The preferred stock issued in the VC deals you're talking about usually has liquidation preferences and other terms attached that make it more valuable.

https://www.quora.com/What-is-a-409A-valuation

I think your first point is obvious, but I disagree with your second, at least 'at-scale'.

In the case where you have loose coupling but are representing multiple entities that scale in different ways, microservices allow you to separate concerns and separately scale those concerns relative to their requirements in terms of memory/CPU/disk/network/etc. The best factored code running in a single horizontally-scaled layer will be inefficient if 90% of requests are manipulating entity A, and entities B, C, and D have a lot of intricate business logic but are rarely touched (they are better off if separated and scaled individually)

The overhead you allude to is definitely something to take into account. If you're a 5-20 person startup without a serious need to scale up or lacking people who have built the tools that make microservices easy, you should avoid the issue for now. But ultimately, decoupling services so they can horizontally scale independently is a huge win.

You can always add a version=v1 to the query parameters and use that as an override when performing content negotiation. It's still not terribly convenient.

It depends on how your API is designed. If it's a tightly coupled RPC-style API or something, this is obviously a bad idea because you'll break every client that didn't see the change coming. But the goal of designing APIs in a hypermedia style is to eliminate this tight coupling and include in each response all the information that a client would need to traverse the application's states. When this is designed properly, it is easier to change the API's functionality without breaking existing clients.

The web is a great example of this (although you may have to squint a bit to see it). Browsers don't need to add additional code or install plugins to handle forms with different fields or links to content of different types, because the semantics of those elements and their interactions are well-defined.

I figured out how to insert strings with quotes on level 6 - if you use a param list like username[]={string"with'quotes'"}, it bypasses the safety check but still gets coerced to a string by the ORM. Unfortunately, I wasn't clever enough to actually do anything with that...

Can you point me to a source for this argument? I'd be interested in taking a look at the reasoning behind it. Obviously, that's an approach that a lot of people take for pragmatic reasons, but it doesn't seem to allow the kind of hyperlinking that's the core idea of HATEOAS. Of course, the term "object representation" is pretty generic, and may obviously somehow include links to related resources and application states.

I don't think adding metadata to your responses goes against the ideas of HATEOAS. On the contrary, HATEOAS requires enough metadata about the application state and possible transitions so that a consumer can fully interact with the API without relying on out-of-band information (URL patterns being the most common example).

Selling stuff to people and convincing them they need it has always been important for a startup.

If only this were an option!

I have mixed feelings about 'augmented reality' (especially with regards to those bluetooth jerks), but this seems like it would be extremely useful with HUDs.

I don't necessarily know any better, but I think that we can probably estimate the number of galaxies in the entire (observable and unobservable) universe given the assumptions that the composition of the universe is generally homogeneous and that the big bang theory is correct. If this is the case, we can calculate an approximate number of galaxies from the combination of observed galaxy density and the extrapolated size of the universe based on the time since the big bang.