Basically those plans represent the size of the clusters that are deployed for your APIs.
All of them come with a minimum 3 node database layer, and each plan increases the node counts. The medium and large plans also increase the CPU/mem of the database nodes.
Thanks! It's a great point to make. Early on I worked on a "migration" ability for the resources, so that every change you make automatically updates the underlying database. But the longer I worked on that, the more I realized I could create/delete as many APIs as I wanted working out what's necessary. Then scale it up for longevity. And the time it took to create/delete APIs was nearly as fast as some of the build times I've experienced for front-end applications.
That's ultimately what I think the value is: API development as hyper-iterative as front-end apps.
I'm still clearly working out how to describe this value. I'm developing more examples to help define what I think the best use-cases are.
Don't forget to look at industries where maybe there already exists large solutions or organizations, but aren't doing as much as can be done to help those that need it most. Education and Healthcare are a few of these. You might not make billions of dollars improving Kindergarten classes in North America, but you could "change" the world.
I wish there was more information about "where" they're going now. They imply that it's not Ember that's broken rather Ember isn't done and the problems are hard that Ember is trying to solve. So I'd ask - why not stay with Ember and help solve the hard problems? Or did you find another technology that "solved" it?
Fair. I'm only suggesting that before we collectively steam roll an open source project and its volunteers with "I don't get it, so it sucks" mobs, that maybe we spend a weekend with it. Maybe over that weekend we learn "oh dear $DEITY". And maybe, just maybe we contribute back to it in an effort to "help".
Your day job is to build a piece of web software and you can’t take a few days to learn the ins and outs?
This is the opinion I had when all of the previous Ember flare ups happened. My thoughts were exactly this. It would behoove so many of us to simply spend more time with new technology and ideas before we simply throw our hands up and say "it confuses me".
I think this might be an over-emphasis on writing and coding for both articulation and problems solving. Doing both won't provide "everyone" better results. There are many ways people approach communication and problem solving. To say writing and coding are the best or only ways to develop these skills is in my opinion very short sighted and limiting.
I would have the opinion that you don't mean "real logic" as much as you mean "model data". In other words if you follow the examples you give, I wouldn't see any reason that the model would not have those fields accessible directly or via a standardized "get" as opposed to direct function calls. I would argue that "real logic" in your view/template is a "real bad" idea.
Technically it's free. Plenty of websites with all sorts of helpful information about programming. But paying to be a part of a box and a small community while working in a competitive environment is worth money. To me at least.
I've been doing CrossFit for a year now. I couldn't articulate enough how it has improved my posture and general fitness. There isn't one particular thing about CrossFit, rather the whole. I'd recommend to anyone.
This is actually where I think Ember does better than the Angular sample provided. Ember controllers hold the "data" in a "content" field on the controller (proxied). Any model can be placed there. If you do add a "people" field to the controller (as in the sample) I'd argue that does what you're describing here as "bad" because it's specifying information in the view about the model.
The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.
The examples provided to describe the difference between controllers in Ember and Angular do not appear to be different to me at all. In fact I'd argue that they are identical. It feels to me as though the author is wanting them to be different because maybe it's a style preference from the templating perspective?
If I'm not mistaken I've read Gruber complain about Apple's products with bad UI/UX before. I'm not sure Apple doing this would change the outcome of the analysis. I also didn't read the article and hear "bad UI === Microsoft".
It's a setback - but I find it less dramatic than what you make it to be. Mobile web still has tremendous value over native (specifically in deployment options). If some of these things get addressed by device builders we could see a real explosion of "apps" not unlike the explosion that has already occurred. I'm a fan of native implementations for the exact reasons Tobie laid out, but I'm a bigger fan of Mobile web for distribution reasons.
I would be interested in more opinions about Paleo. I'm actually on this diet myself and experiencing similar results (however I've added Crossfit and I think that's been more influential than my diet). My curiosity is about the notion that somehow Vegetarian style diets or even diets with grains is truly damaging. I read the Paleo Solution. I want to know how much is Robb Wolf just spreading his own bias around?
But it's not. In fact intelligent completion is incredibly hard for dynamically typed languages. Those IDE that do perform intellisense or autocomplete with dynamic languages do it with very basic ability. In a real world dynamically written code file the editor simply has no way of knowing the members of a class. Or if it is even a "class".