These numbers are complete make believe.
69 karma · joined July 2, 2012
These numbers are complete make believe.
As for executing a tree of connected components, in the current state of Hyperlight-Wasm you'd probably want to take a collection of components and compose them together using something like https://github.com/bytecodealliance/wac to create a final component composed together from multiple components.
When I think of a portable spec for serverless, I think of something more like a Trait of an Interface that needs to be implemented, less a app hosting model. If you think about it like that, then Web Assembly component model [1] would be a great fit for defining an interface that could be implemented in a variety of languages.
[1]: https://github.com/WebAssembly/component-model/blob/main/des...
[k8s-infra]: https://github.com/Azure/k8s-infra
Nope. That is an experience that will push them right back to OSX or Windows.
The author or company building the software requires money in exchange for using their software. The revenue acquired through the license is then use to pay for additional development.
Revenue sharing seems to imply some kindness / goodwill agreement.
Coming from a rails background, this was the closest out of the box testing experience. Tests are generally handled within a transaction and also offer fixtures and other goodies. Definitely recommend giving it a test drive.
Persistent Volume Claims go a long way toward the stateful service "feature".
To go another step further on stateful services, SF's stateful services are only supported in a couple languages. Where mounting a volume in K8s which will follow your container is pretty darn accessible to any language.
Nearly all the libraries working with AMQP 0.9 will not function when targeting an AMQP 1.0 service.
If you are thinking about a masters in CS, you must check out the OMSCS program. The cost to value ratio is completely off the charts!
"total program cost of about $6,600 over five terms"
And that glimpse is without a family...
The fact of the matter is grep is a poor tool to try to find your step definitions. There are tools out there that are much better for such things, vim with http://www.vim.org/scripts/script.php?script_id=2973, or an ide or <your favorite tool>.
You could make the claim that any abstraction is unnecessary if you see no value in it. It doesn't mean others will not find value in it.
Personally, I find it quite easy to understand and convey to non-devs the stories told through gherkin. That is part of the value prop for me.
If no one is reading them but the devs, I'd rather use something other than gherkin.
The second claim against cucumber / gherkin is not it's fault, it's the toolset's fault. Using grep to find your step definition is not very effective.
If you use a tool like Rubymine, you can jump directly to the applicable step definition through one key combination.
The thing that the library is doing, is now replacing a wsdl with an expert that develops a swagger document. This to me sounds problematic. The wsdl had some idea of versioning of the contract, and was dependent on the developer of the service to update the wsdl with updates of their service.
I imagine, and correct me if I'm wrong, but the swagger doc will have to updated by the expert per release of the service (obviously, pending any implementation changes of the service). This actually puts the consumers of the framework at risk of incompatibility via 1., the developer changing the service, and 2., the expert not updating the swagger definition upon 1. Is this accurate?
Please don't take this as me saying that I'd like to go back to wsdls. That is certainly not at all what I'm advocating.