AngularJS has a ton of functionality for building reusable components with systems like Directives. But how do you build multiple page controllers with shared model-style functionality? Click through to check out how we can utilize the Provider and Factory systems to encapsulate a shared base model across pages.
The next version of Octopress (3.0) is nearing release and is in beta now. I’ve switched this blog over to using the new version and it’s been great. It’s a pretty radical change from the previous version, but for me, this is exactly what I wanted Octopress to be originally. It’s highly modularized and lightweight, with a new deployment plugin that can natively push to S3 as well as github. Octopress at it’s core is now nicely separated from your Jekyll design. If you’re like me, you’ll appreciate that Octopress is now about extending Jekyll as opposed to being highly intertwined with it. I’ll write more about my experience in a future post, but I wanted to get a quick complement out to those working on Octopress 3.0. Love the new direction, keep up the great work!
Unit testing synchronous objects in Node.js is really simple. You have inputs, and you have outputs, and by exposing an object to all of it's possible inputs, you can assess that the outputs are sane. But what about something like an asynchronous Express.JS route handler? Read on to find out how you can track these sorts of modules.
Requiring files in Node.js comes in two varieties: The code you write, that is required by a relative path, and the code from the community (or your own packages), that live as node modules, and are required by module name. But what about library functionality, that gets used all over your application? Is there a better way to include this repeated functionality in your code than a bunch of relative paths?
Welcome to The Attic! Read on to find out about what this site is, who I am, and what you might find here.