Hold on. YAML gained popularity as a nice syntax for JSON, which itself was a subset of JavaScript, a full programming language. Now, we are adding some computational capabilities back to YAML? Wouldn't it be better to just execute JavaScript to generate a JSON object and skip building a new language inside of YAML?
The question is what happens to these lifestyle businesses when a VC backed company comes along with a $100MM raise in the space and a free product. Do they survive? Does the team lose their livelihood?
I do agree that Kubernetes is too complicated an low-level for most needs, especially for small projects. However,
my experience is that while most apps start out really simple, if they are even modestly successful, they'll eventually need something not supported by whatever PaaS/Serverless/whatever they've chosen for deployment.
The hope with Adapt is that you start out with a really simple interface that looks like a PaaS/Serverless (Heroku, Zeit, adapt new/run etc.) but can be tweaked over time without having to throw out everything that was great about the PaaS. And by no means is Adapt limited to Kubernetes, it's just what is there now.
I think that a simple interface to something like Fargate/ECS with Adapt would be pretty nice as it removes the K8s complexity but handles all the container build/repo management stuff for you.
That is exactly the idea behind Adapt (and said better than I've been saying it). The goal is to hide all the DevOps details but still make it easy to customize the parts that you need to customize via JSX and React concepts.
If you check out some of the components in adapt/cloud/src, most of them are small too, and just use other simpler components like LocalDockerImage, DockerContainer, RepositoryImage, etc.
I think the real problem we have with infrastructure is one of evolution, abstractions and leaky abstractions.
First, infrastructure is not a static thing, it changes over time in response to code updates, environmental load (autoscaling), etc. And the details here matter. How should new code be rolled out (blue/green, how fast, what are the quality metrics, etc.). What should happen to the old instances while the new stuff is rolling out? When should they be killed?
What we really need is a good way to declaratively specify what to do, and how the components in that declarative specification should evolve as new stuff is rolled in, load changes, etc. We need a good way to specify the control plane for our infrastructure. adaptjs (adaptjs.org) is our TypeScript-based open source project to provide this. It is still early stage, but I think it is pretty promising.
The second issue is one of abstraction. All these things are complex and often need customization to suit the particular application challenges. Using templates, CDK, Pulumi, or anything else to generate YAML is fine, but as the article points out, you have no insight into how your specification got realized into the low-level infrastructure.
Moreover, you have to care since you need to know the low-level implementation to debug, understand cost, analyze logs, etc. Adapt has some machinery so that you don't always need to understand the low-level implementation for this stuff, but since it is still early, that part of the system needs work before it is ready for prime time.
More generally, waiting until the end to write tests is a great way to get poor code coverage, and test cases that are very hard to debug. Unit tests as you go along is the way to go. If you must, reserve system testing until the end.
There is what the standard says, and there is what people actually do. If everyone promotes char to int in practice, then any machine where this doesn't happen is going to have a tough time running the bulk of code out there.
In a standards committee, the standard is the standard, in practice common practice is the standard.
Maybe. Investors can give up on a company and want to get their money out which would result in this kind of sale. More likely, as you said, the company will be forced to go for bust given the current climate.
It is also possible for investors to block an exit that can be great for founders and employees. For a $1B fund, a $150MM exit on $10MM raised doesn't move the needle, but it could be life changing for the founders and early employees. Good investors will care about this and try to figure something out. Others might just block the transaction.
An important point that the article doesn't discuss is understanding the possible value of your options if the company actually exits.
There are few factors here - what percentage of the company's total share count do your options (vested and unvested) represent. How big of a liquidity preference are you sitting behind. What are the odds the company clears this liquidity preference. What is the likely valuation of any successful exit (i.e., one the clears the liquidity preference, and in the case of options, clears the strike price of the options issued). What are the odds of such an exit. And finally, what are the change of control terms.
In terms of what fraction of the company do your options represent, you'll have to ask how many shares are outstanding and then make a guess as to how many more will get issued between now and success. Remember, each financing results in lots more shares being issued.
What is the liquidity preferences your options sit behind. Usually options convert to common, so that means you are the lowest person on the totem pole. If the company has raised $100MM, there is very likely at least a $100MM preference. That means that if the company exits for $90MM the common shareholders (that's the employee option holders) will get nothing.
In terms of valuations, you can figure out what your options are worth at various exits above the liquidity preference, but only if you know the terms of later financing rounds. Generally, I'd recommend exercising at least 1 share of options as soon as possible so that you have shareholder information rights which should tell you what these terms are so you can calculate the option value.
More importantly, what are the odds of such exit. Generally, a company has more options to exit for $100MM than it does for $1B than it does for $10B. Of course, if the company is wildly successful, the higher the odds of a bigger outcome. The question is, what threshold of success is needed for the options to have enough value.
Finally, you should consider the change of control terms. If a company is acquired, do your shares vest immediately, or are they converted to shares of the acquiring company? What happens if the acquirer fires you? If you are early enough you might be able to negotiate for better change of control provisions. You want to avoid a scenario where the company has a successful exit and the acquirer is not incentivized to keep all the employees that have meaningful option stakes. This is usually less a problem in software developer roles, and more of an issue for sales and executive staff (CFO, CSO, etc.) but it doesn't hurt to have better terms.
In any case, employee stock options are complicated, and often the terms matter more than the price. There is a quote, can't remember who said it, "You name the price, I name the terms."
It seems like there are a lot of these IPOs lately. The article mentions Uber and Lyft, but there are others. Peloton is a recent one. WeWork had to shelve its IPO. Pure Storage is still losing money. How many of these companies can never make enough money to justify their IPO price, and how many are wisely investing in growth and market dominance. How long does it take to tell? Amazon took over a decade to show profits, if memory serves.
Unfortunately, I think the import by URL, by itself is a bad idea. You ideally want reproducible builds, and npm provides a form of that with its enforcement of semver and hash checks in the lock files.
If you are really pedantic, you should probably also check in node_modules with every release you care about.
Having said that, having a system that can source modules from a URL and then enforce hashing and versioning could be a win. I'd just hate to see a repeat of the early golang build system that led to the rise of gb.
I think the problem is that building any new abstractions is a pretty big lift today, and so innovation is slow moving. Something like this can make that innovation easier, eventually giving way to some simple YAML files.
Unfortunately, it seems like every app eventually has its own pet requirements as it matures, meaning that building new abstractions might be important as part of the UI.
But generally, I agree, tools like this are needed because existing abstractions aren't good enough. I'm just not sure they will ever be good enough when everyone has custom requirements and app-specific architectures.
Umm, the correct answer is to switch doors. It has been discussed ad naseum as you mention. The simplest way to see that the switch doors gives you a 2/3's chance of winning is as follows.
Without loss of generality, assume that you always pick door 1.
If the car is placed randomly, you have a 1/3 chance of getting the car. To see this, note that when not switching, you only win if your initial guess has the car behind it, which happens 1/3 times.
When you switch doors you only win if not switching loses. Since not switching wins 1/3 times, switching wins 2/3 times.
You can write a simple program to simulate the game and see that switching wins 2/3 times.
I love this comment: "The reason why we put it in is not physical data loss, but once in a blue moon you will have a bug that destroys all copies of the online data and your only protection is to have something that is not connected to the same software system." I think that is often overlooked when designing HA storage systems.
The purpose of double blind review is not to anonymize the work of well known authors - conferences, informal conversations, etc. guarantee that the work of established members of the community will be known, even before Google.
What double blind review does is give the unknown author a fair chance as there is always the outside possibility that it is the new work of a well known author that the referee has simply not seen yet.
A "fun" exercise in C++ is to take a line of code that makes extensive use of advanced features, like templates, smart pointers, etc. and step through a -O0 compile with gdb. I was shocked, in some cases, about how many different functions were called for what looks like a simple expression.
This can lead to some interesting errors. For example, writing
void foo(const std::string s)
by mistake, instead of
void foo(const std::string &s)
won't result in a compiler error, but will result in an unusually large, and unexpected overhead in calling foo.
On the other hand, STL is great (less the error messages). I sorely miss it when programming in C.
Historically, publishers provided at least two valuable services: distribution and marketing. They captured the value they were providing by "taxing" distribution (i.e., adding a profit margin for themselves). ebooks make distribution cheap and easy making publishers unecessary in that role.
Marketing is still valuable, but publishers never directly charged for that (as far as I know), hence their dilemma.