AngularJS is designed to be as testable as possible. With its use of dependency injection, creating and manipulating mocks to test out individual components of your Angular application can be done in a stable, reliable way. Testing out each Angular component, however, comes with its own set of patterns to apply. Some of these patterns are similar cross-component, and using and understanding these core concepts of Angular testing can act as a nice bootstrap to your testing process.
Ruby and Rails are both built to help us write concise, meaningful code. One pattern I constantly find myself writing is a method that returns one thing, if it exists, or a default value. This can work well upfront, but it takes a little more care if the case gets any more complex. Fortunately, Rails has just the trick to keep the more complex case nice and lean in its ActiveSupport gem.
AngularUI Router is the de facto routing library in the Angular world. It takes the traditional routing mechanisms, and builds a subtle, but brilliant abstraction upon them. Instead of merely listening for requests at a set of URLs, it creates the concept of a set of states, each one configurable with an optional URL. This abstraction allows for flexibility when refactoring routes, but most interestingly, it creates the concept of a current state and stores key-value parameters of that state. Both the application’s state and state parameters are available for injection with $state and $stateParams respectively, although, as we’ll see, only one is necessary for injection in any given controller.
Rails is a fantastic framework to develop with, but it can occasionally be unforgiving when it comes to error throwing. I was recently coding up a soft delete method in a model when Rails gave me the perplexing error: “Undefined Method `stringify_keys’”. I wasn’t calling stringify_keys anywhere in my method nor was it anywhere in my model. A grep through the app directory of the codebase came up empty as well, and I was stumped.
A couple of years back, I made the switch from bash to zsh. I did so mainly because I saw a fantastic post on customizing the command prompt that I dove into head first, and I’ve stuck with it for the slightly improved tab completion. Your mileage may vary with regards to zsh, but I always find it difficult to do without it when I end up working on somebody else’s machine. Despite the improvement, there are a few differences between the shells, and I’ve come across a scipt or two that wasn’t especially zsh friendly. One of those is the very rake task that created this blog post.