The Ember guys are having a hard week. I promised Tom Dale I'd try and help by "arm-waving" an API together that I feel expresses a bit more about the main ideas behind Ember. It's Friday, I've had a beer or two... but I got inspired...
Any tool can create a mess. Some seem more prone to messes then others - that's what I thought of KnockoutJS until recently when I had a chance to catch up with Steve Sanderson - Knockout's creator. We talked, I tried some different things. I've changed my mind.
Continuing on with building out a NodeJS app with Express and other buzzwords - I decided to build out a page using my API, while I build the API.
The best way to build an API is to use it while you're building it. At least that's what I find the most effective. But how am I going to consume this API?
NodeJS has a pretty specific convention when implementing callbacks in modules - function(err,result). Does this always make sense?
Mongo is installed, our data is ported. Time to roll together our first model: the Customer. How do you model this stuff with MongoDB and Node?
The data has been rolled into MongoDB - at least the first round - and now I need to get the API up and tested.
I've chosen to use MongoDB - now what?
I love learning in the open. The simple process of relaying what you see/do/think/learn/fear/love can, itself, be illuminating. So here we go again - I'm going to fuddle around live, with some edge technologies, and you get to laugh at me.
This was a multi-day bug with 10 deployments behind it. I was tired, frustrated and hateful of the incessant problems Internet Explorer brings to the world. I was about to give up. To hack in Yet Another IE Workaround, when I noticed something strange in the response headers...