I wanted an environment that I could quickly spin up and tear down to tinker with OpenFaaS. I settled on a combination of using kind and helmfile to make it easy to create/destroy the cluster as needed. I'm sharing it here in case it is of use to anyone else.
If you look at the requirement enforced by the randomness, it is meant to force you to use the array of users that is passed in as props to the component.
I had not seen node-jsdom. I see that it is forked from jsdom 3.x, which still works with node.js. Do windows users mind having to install the visual c++ compiler?
As a windows user, I avoid developing with node on windows machines, because building dependencies caused me trouble many times. pg, socket.io, bcrypt, jsdom, countless others.
If it's just the vc++ compiler, chances are node devs already have it installed anyway if they do in fact work on a windows machine.
Ok, this is just unbelievable. My original post was a complete fiction. I just made it up. I made up jsdom-node, I made up the fact that it was a node.js compatible fork, I made up dom.js, I made it all up as satire to poke fun at the javascript community. I thought these two replies about the C++ compiler were just continuing the joke. Honestly.
Imagine my shock to realize that the fake jsdom-node project I made up actually exists (in the form of node-jsdom) and actually exists for the reason I made up. What. The. Fuck.
It's not dependent upon my editor. Maybe I should move this up higher in the readme: https://github.com/zpratt/react-tdd-guide#running-the-tests-... . All I was adding for Webstorm was a note for the convenience of people who choose to use it, which I might be able to move into a mocha.opts.
I blame things like todomvc, which I think is great in spirit, but a huge menace in practice. It gives people false hope that framework x will solve all their ills. Any SPA that is more than trivial requires engineering skills. Additionally, it is likely that you'll be building said SPA with a team of developers who have varying skill levels. From my experience, a framework should provide a certain amount of level-setting (as opposed to something that is 100% custom) for new team members. However, there is nothing stopping people from putting data access logic in controllers or polluting the views with complex logic. Those sorts of mistakes can and will happen regardless of technology. The key is to pick the right technology for your team and the problem at hand and stick with it.
The main difference between Ampersand and Ember is that Ampersand has embraced npm and does not require you to find a way to fit the problem at hand into the framework. For example, at work we have an app that only uses the domain layer (collections and models) from Ampersand and uses React for the view layer. Ampersand has embraced the library concept and is not really a framework at all.
