Ember is an opinionated framework. Like other such frameworks, it takes a while to learn how the pieces are designed to fit together and how you can structure your code to be harmonious with it, rather than fight it.
What I’ve found is that often, it helps to think outside the boxes ember provides you: controllers, routes, components, etc. Ember’s dependency injection is a great tool for helping you with this.
Objects are named in Ember’s dependency injection container are given a full name that consists of two parts: the type of object, and a name. For example,
route:application would be the name for your ApplicationRoute. Or
controller:question.edit for your QuestionEditController. You’re not limited to Ember’s predefined categories, however; you are free to make up your own type. Read more on Learning to Love Ember’s Dependency Injection…
In my last post, I argued that “untestable code” is code that cannot be efficiently unit tested. Today I’d like to walk through my top five anti-patterns that make writing unit tests painful. If you aren’t in the habit of writing unit tests, hopefully these tips will help you build more testable code and see how test-driven development can help drive clean design.
Let’s start by considering a worst-case single line method:
What’s so bad about this code? Well, let’s assume that this is a pretty important feature to get right, and that your code had better work as expected. We definitely want to be able to validate this method. Read more on This Code Is Untestable! (Part 2, for Developers)…
Here are a few tools we’re using on my current project, a non-trivial Ember.js application, to do just that.
Read more on Practical Abstraction in Ember.js…
Dependency Injection is relevant in Ruby. I say this because solving problems with highly decomposed systems of collaborating, narrow-purpose objects is still the best way I know, if I want to drive my code with tests and be able to change it later. DI tools help enable this type of design by carrying the burden of object instantiation and locking it outside our actual domain code.
(There’s a strange history of opinions revolving around DI in Ruby, and they’re worth discussing… sometime soon.)
I’ve been having a hard time finding a good DI tool for Ruby. I’m ready to move forward from DIY and enjoy some of the great conveniences that tools like Guice provide, such as automatic instantiation of object trees based on constructor and type info. So I wrote Conject, and though it’s still young, it’s working and showing promise.
Read more on Conject – Modern Dependency Injection in Ruby…
Guava’s EventBus provides a publish-subscribe event mechanism which allows objects to communicate with each other via the Observer Pattern. The EventBus shies away from the traditional “Event Listener” pattern seen in Java where an object implements a particular interface and then explicitly subscribes itself with another object.
In a recent project we chose to use the EventBus in conjunction with Guice (a dependency injection library) and have had a lot of success with it. Specifically, objects in our system only have to express what events they care about without being required to explicitly register with the EventBus or any other object. Read more on The Guava EventBus on Guice…
In a previous post we announced Objection, a dependency injection framework created for Objective-C. Since then, we have been actively using Objection in our iOS projects and we have added a few new features: Protocol Bindings, Eager Singletons, and Meta Class bindings. Meta class bindings are useful when there is an external dependency that is implemented using only class methods.
Read more on Meta Class Dependency Injection in Objective-C…
For those of you that are familiar with the how and why of dependency injection (DI), we’ve created a DI framework for Objective-C called Objection. Those familiar with Google’s Guice will feel right at home with Objection.
Read more on Objection: Dependency Injection in Objective-C…