AngularJS - why you so cray (AngularJS Response Headers)

A frequent functionality of web applications when dealing with REST web services is for the server to set headers on the response that the client should use in subsequent request. Angular support this fine, but for some reason - it returns them in toLower() format. So if you send out a header that is ‘X-Foo-Happy-Count’, what you will get back in your header on the client is ‘x-foo-happy-count’. While certainly having everything work in lower case will eliminate some of the issues that come from mixed case - that’s not the expected behavior and Angular does evil stuff by making that decision for you without warning you that it has done it.

Investigating Sails.js

After investigating some infrastructure choices for Node.js projects I’ve finally decided to take a look at Sails.js - a neat little Rails-like MVC for Node. Its actually pretty interesting in version 0.9, but was missing some critical features - namely Associations/Relationships.

However, the Sails team is nearing completion on version 0.10 of Sails which has a fairly robust implementation of Associations via Waterline. But to check this out, you have to remove your existing version of sails:

sudo npm uninstall sails

and then install the version 0.10 branch:

sudo npm install sails@git:// -g

From there you should be good to go to explore the way it handles associations.

Comment on salad post

I thought I’d try to text post this time to see what happens.

It’s generally the dressing that kills you with salads —this is especially true with the Caesar Salad.  I’ve found that getting the dressing on the side, then dipping your fork in the dressing before each bite gives you the taste and uses a lot less dressing overall.

Angular.js vs Ember.js - going with Angular

After a lot of time spent trying to determine which of these two epic frameworks I would go with I finally decided to go with Angular because it is very explicit in the way that it does things - it doesn’t hide behind “convention” and it was just plain easier to read other people angular.js code and have an idea of what they were doing compared to reading complex ember.js code. Granted, both of them are strong candidates and it literally took me WEEKS to make this decision of what I was going to use atop my NodeJS stack, but its a done deal and now I can move on and do more cool stuff.

It didn’t hurt that Angular has a LOT of momentum, books and support from Google. 

MongoDB Aggregation Framework

Over the past few weeks I’ve had a chance to really dig into the aggregation framework and while I’m impressed by what you can do with it, I’m disturbed by the very scant documentation that describes all of the things you can do with it at the right level of detail. 

While there are good books from 3rd parties that describe a lot of the features at the right level of detail - I would have assumed that the authors of the original documentation would have created something more competent.

The hard part of dealing with node.js

Node.js has proven to be highly capable for building server applications. I have rewritten a Java server engine in Node.js and it has taken roughly a week. This old server served an API for managing mobile devices, their locations, and providing services to them. I’ve replaced 100% of that functionality with Node.js and its has actually been pretty easy to do.

One area that has been somewhat difficult has been producing the Oauth2 server functionality. While there are some implementations out there, it is difficult to get a lot of information about them from a production perspective.

One area that has come very easily has been moving over ORM functionality for MongoDB. Mongoose is a great framework that supports validation, mapping, and sub-document population (the coolest part). Love it! 

Another truly inspired framework is async which allows you to perform asynchronous processes, map/reduce tasks, etc. Doing this level of async and synchronization with Java is why so many developers who have to do this thing have moved to Scala.

Still no regrets for moving to node.js… though Javascript’s duck typing for pretty much everything makes you read documentation 50 times before you truly understand what’s going on.

Fun times continue….

Node.js is criminally easy to use. I’ve been able to port an absurd amount of server functionality over to it in hours. At this rate I will replace the ENTIRE Java-based API infrastructure in days.

It just flows like water. Every time I think I’m about to hit something difficult, I run across a module that has already solved the problem (sometimes years ago) and drop it in and it just works. Brings a tear to my eyes. Literally wiping tears from my eyes with how easy this is. 

This level of easy must be accompanied by bad scaling or something.

Node.js is actually pretty damn awesome :)

The first few days of messing with node.js are nothing short of liberating. While you’re generally operating at a lower level in the stack than you might with any of the myriad frameworks for other platforms, the benefit is that there is nothing getting in the way of getting things done QUICKLY. No web.xml, no configuration files, no trying to grok the questionable design decisions of some API writers and working around them to get scalability, etc.

I now understand why there is such momentum behind node.js. Its extremely easy to get started and get results that are production quality in a very short amount of time. The one downside though is that Javascript has some holes as a language, but for the most part you don’t have to hit those very often fairly early in development. I’m sure the seas will get rocky as I start to implement some of the business logic, but I’ve actually been able to refactor some of the existing codebase for services that I had in SpringMVC down to node.js in hours and have it working with the existing MongoDB infrastructure.

So far very happy.