From IoC to require

Lately I have been working on building out my first non-trivial application with node. It has been a very interesting smashing of my brain cells. Coming from a strictly typed language and moving into a prototype based language has removed a lot of my tools from my tool belt. I can no longer ‘scan assemblies for types’, even if I had an IoC i would be forced to use normal strings rather than Type names. I also no longer have my powerful toolset of Visual Studio and ReSharper (yes its a resource hog, but its damn powerful too). But of all the changes, I think it is the lack of IoC that is hurting me the most.

Last weekend I attended a session at Houston Code Camp on “Beyond AMD” where my good friend talked about the various ways people are extending JavaScript applications. Ryan summed them up into three flavors, you can modify an instance (duck punching), you use a factory (think jQuery $.fn) or you can use a plug in model (think flatiron.js Broadway). It was a great talk that really helped to round out my understanding of developing in JavaScript land.

It wasn’t until I was really rereading through the flatiron docs that it hit me. I really have two ways to get at things. One is by attaching it to a global (it seems that the app object is the preferred one) or I can use require to locate the objects I need. Since require felt right at the time, I started to happily require my way into happiness. That is until my first refactoring that changed a file path. You see require doesn’t have an app root concept so through out my code I am calling require(‘./file’) and then deeper in a nest I have require(‘../../../file’) and different files have different paths. For a moment I thought, Aha! I know what I will do. I will add to require the ability to do something like require(‘~/someFile’) where the ‘~’ was my package root. As I thought it about it having the file system involved at all just didn’t feel right. It seems that for JS the best thing for me to do really is to just extend the ‘app’ global.

It all comes back to the fact that I don’t have a type system in the way that I am used to thinking of it. Its ok, because I can stub this out quite easily for tests. But I do believe that it ALSO means I have to stay extra on guard because I am passing around a global and depending on its presence. It will be very interesting to me to watch how this next round of coding procedes because of this. I hope to report back with more, as I get actual experience doing it. But until then, I am jumping in feet first.


Side Bar: I am drawn to node because I feel it has the module problem solved well. Python has the whole 2.x vs 3.x distutils vs setuptools (easy_install vs pip) etc stuff going on. Ruby has the bundle vs gems thing going on, where node just has npm which is private by default with SEMVER support. I like this. (its still no APT-GET but it works nicely. :) )

I am also loving Sublime 2 – though I am missing VIM’s keyboard navigation.

I also, enjoyed reading this. JavaScript is tragically important. LULZ. Its funny cuz its true.

Posted in Uncategorized | 15 Comments

A story on composable systems

<warning>This is a long post that attempts to describe a positive experience leveraging multiple frameworks</warning>


Recently while working at Dovetail I had the absolute pleasure to provide a solution to a customer request. We were adding SAML authentication to our product, and we wanted to provide an extensibility point to handle unknown users. By default the product would show a not authorized screen if we encountered a valid SAML assertion referencing an unknown user. This was pretty easy to setup, but as I said, we really wanted this to be extensible. What I wanted to support was redirecting the user to a different page, maybe one that a customer has specified which would give the user the information needed to request access to our application through the approved channels. That would have been pretty easy with just a configuration entry, but we decided that really wasn’t enough. We also wanted to be able to handle a request to make a user right there. Well, now we need the ability to execute some code, a configuration file isn’t going to handle that very well. Even if we kept the config file approach we would have to redirect the user to somewhere else in the app, and then figure out how to shuffle all of the required data around. :( It just didn’t feel like a solid solution.

Thankfully, FubuMVC, Bottles and StructureMap came to the rescue. FubuMVC gives us controllers that can easily take dependencies on services (nothing to fancy here, you can do this in ASP.NET MVC too). So our SAML Authentication controller (or action in Fubu land) takes in a service that acts as a policy (SuccessfulSamlAssertionPolicy) it takes a valid SAML assertion, and attempts to locate the user in the database, if it finds them, the policy logs them in, and then redirects the user to the home page. If we can’t find the user, then we invoke the UnknownUserPolicy (another service/policy thing which is injected in the SuccessfulSamlAssetionPolicy) the default implementation of this policy simply redirects them to an error page of ours, but since it’s a interface/class pair, we can easily swap that out. This is where IoC/DI/StructureMap make things really nice.

So, the above may seem a bit complex (I definitely didn’t explain it that well). So lets break it down and make it concrete. I have an interface that looks like this

public interface UnknownUserPolicy
    //FubuContinuation is a way to redirect the user
    FubuContinuation HandleUnknownUser(SamlAssertion assertion);

we ship with the following implementation

public class DefaultUnknownUserPolicy : UnknownUserPolicy
    public FubuContinuation HandleUnknownUser(SamlAssertion assertion)
        return FubuContinuation.RedirectTo<LoginController>(c => c.Login(null));

Super easy code, nothing too hard here. We wire it up in StructureMap using a convention, so there is really nothing else to show. Now, lets imagine we have a customer, that doesn’t want them redirected to the login page, they should instead go to: . Using StructureMap, this is as easy as registering our policy later in the container (after the default registrations) by adding a line like this:


That will override the default policy and boom! We have just customized our application for this one customer. So that’s great and all – but I want that in only ONE deployed instance of the application. I do not want to modify the base product for this customer, and this is where Bottles comes to my rescue. :)

Bottles is a framework for assisting us in loading dynamic code in a controlled and predictable manner. Its built with an IoC container in mind, but is completely agnostic of them and FubuMVC entirely. When our application starts up, we go through all the usual stuff for a .Net / IoC project. We initialize logging, spin up our container, blah, blah, blah. The one new step that we add with Bottles though, is to run through every discovered Bottle, and look for ‘StructureMap Registries’ and load them into the container. Now, a bottle is pretty much a glorified zip file holding .Net assemblies — among other things. The bottles, being a separate file from the base product, can be used to modify our existing application. In this case, we have a Customer Bottle that does one thing. It executes that above piece of SM registration code to override the base UnknownUserPolicy. :) WIN.

So, by putting all of these various tools, patterns, and frameworks together, we were able to build a solution that allows for a lot of customizability, does NOT require us to change our base product (would have loved to have had this at the bank), and I think truly encapsulates the changes that customizations for a customer can bring into one easily deployable unit.

There are a LOT of things going on in this post, we have programming to interfaces, we have making small classes that do one thing well, we are using IoC, we are using a web framework that makes redirecting deep in the bowels of the app easy and testable, we have composition, dynamic code loading and a lot of ‘abstractions’ (Yup, learned about those at a young age 😉 ). Using all of these has allowed us to add a lot of seams to our application, and it’s this kind of power that keeps our application nimble and easily customizable for any customer.

Posted in Uncategorized | 8 Comments

Slice of Life: Converting my Personal Site

Over the last few months I have been having a lot of fun converting my personal site ( from a pure static html site, to one that uses a back end server side language.

When I first started the main purpose was to learn a little more about python. So I started off using Flask, a micro framework for python. Flask is a lot like Sinatra for ruby and the comparison was a lot of fun because my good friend Ryan Rauh (RyRy) was writing a site in Sinatra at the time so we were able to compare and contrast the two approaches quite easily.

As I learned more about flask and all that it could do, I was impressed by how much I could do with so little. It served as a solid reminder that we should strive for simpler solutions.

In addition to learning python I also took the time to dive into LESS. Organizing the CSS content of applications has always been difficult for me. Finally, with LESS I had variables and the ability to nest selectors. Basically, all of the things that I have wanted CSS to do for a very long time. I started out using the runtime compilation modes of LESS, but as I learned more I eventually switched to running the watch mode on the compiler and then stripping that functionality out of the app. Right now, I really like this approach. It feels more like PROD vs DEV, but I still have the ability to iterate quickly. The real choice to use LESS, was that the popular CSS framework from Twitter called Bootstrap had just launched. By studying their approach and trying to deconstruct things I have learned a lot about CSS and its application to better CSS approaches.

But as with all things in the technical world, a change was on the horizon. That change was SASS/SCSS. RyRy read a post somewhere comparing SCSS and LESS and he came away with the impression that SCSS RULED, and LESS DROOLED. This was one of those moments, where I gave RyRy a stern look and then sat down to start converting my website from LESS to SCSS, because when the guy you ask all of your questions too, changes directions sometimes its just easier to go with the flow. Thankfully it wasn’t that hard, allowed me to revisit my CSS and improve things further.

Around the same time, I discovered, a SCSS friendly grid system, finally I can get rid of the BS classes like span-4 and what not that have been plaguing me since I first found blueprint.css and 960grid. Whoot! I have been able to further clean up the website’s CSS approach.

Well, of course the project can come to a close quite that simply. After improving my CSS and getting an understanding of python, I of course, had to completely rebuild it something new and shiny. Damn, my attention span.

So, yeah. Node.js the new shiny language/framework. My JavaScript skills have always suffered, so I rationalized changing my backend code to JavaScript as a means to improve my JS skillset. So, I converted my site again, learned a lot about JavaScript in the process, melted my brain trying to get things to work in this under powered language (under powered because I am used to my language providing much more to me).

So now my site is running Node.js – its a whole lot cleaner and easier to work on. I love how simple the underlying code is, and I have really learned a lot about some of the new languages and frameworks out there.

Posted in Uncategorized | 1 Comment

Sunday Thought: Patient / Fast

Some times I am such a dolt.

I open a new OSS project and my first thoughts are usually “This library is ^&*$% it doesn’t do anything right.” 

“RAGE! (╯°□°)╯︵ ┻━┻”  don’t they know that, MY WAY is better!

Its sad, but that is exactly what I am thinking. I am on such an immediate gratification high, thanks to my 8 core, 8GB RAM, SSD, super high speed internet capable machine that I forget that not everything can be measured in sub-second latency. Things like instant on-demand movies, and Amazon 2 day shipping don’t help with my attitude either. When it comes to learning, this demand for instant gratification has, many times, gotten in the way of what it is I really want to accomplish.

So, I ran into this situation again this week, and after IM’ing the maintainer – complaining about how this and that worked (ok, lets be honest – I was whining like a 4 year old) – I kinda just snapped out of it. I recalled a quote from the book The Toyota Way, where they stated that the #1 problem with new engineers is that they can’t slow down. They just want to charge into things head first and solve all of the problems. Hmm, sounds a lot like me. Except that I have 10 years underneath my belt now. So, why am I still acting like a new developer? My biggest guess, is that I haven’t really honed my process. I need more people to catch me acting this way and to call me on it. But that can be hard to find in our community, because we all tend to act this way.

We, developers, are always on the look out for the next shiny library or framework that we can “learn” and by learn I mean implement. We like libraries so simple that a new programmer could understand them. We don’t want a learning curve at all. I think that this is one of the reasons things like express.js, flask, and sinatra play so well in our community. You can see, immediately, how it works. They have almost no abstraction over the underlying concepts. Let’s not forget, that its the abstractions that bring the real power, and that not every abstraction is a poor or leaky one.

Its Sunday, which is an introspective day for me, and I want to try and improve myself. I think that if I could work on this aspect of my skills and attitude, I would become a better developer. Being a better developer is something that I want to be. Ok, so how am I going to do this. After much thought, I was reminded of a similar experience that worked well for me outside of the software development world.


For that last three months I have been training in Olympic Lifting. Now for those of you that have never performed olympic lifts, you need to know that while strength is a big part of it, skill also plays a huge part. You can’t just hoist 150 pounds over your head with out a level of skill. The snatch is an explosive lift, that requires an insane amount of patience and balance. My coach and teammates have a phrase that I have come to love. “Patient / Fast”, which means to me that you have to move fast, but at the same time be patient in the pull. It took me a long time to really grok that concept. It feels like a damn Zen koan at times, but I keep repeating the phrase and each day it reveals itself to me a bit more.

So there I was, at the keyboard, about to burst a vein, when I woke myself up from my emotions, calmed down – and asked myself what would “Patient / Fast” look like here? I decided that I would patiently look through the code, asks questions to myself via comments and then go answer them, and start to understand what the code was doing, on the flip side I would be very fast to start writing, running, and debugging unit tests to get ahold of the code base. Sure enough, the code started to reveal itself to me, I could see the author’s intentions much better now. I started to build up a good amount of understanding, and was able to effectively solve my problem but was also even able to make a nice pull request back to the library that I think cleaned up a very small part of the code base. :) 

In the end, I spent more time than the old me would have liked understanding the library. But the reality of it is, this small investment in understanding a key part of my infrastructure is going to pay dividends in the long run. And less than a day understanding how a critical part of my system works, is indeed a small investment. So, from here on out I am going to remember. Patient / Fast

Posted in Uncategorized | 1 Comment

Fine Grained Issues

One of the little things that I have noticed as a new trend for us here at Dovetail is the use of finer grained issues. Smaller and more focused issues. While this is nothing new, and has always been a helpful thing to do, it has never been easy to do (at least for me). You have to go to some website or app, type a bunch of information into the app and then start over with the next fine grained issue.

Well, I have found a command line app for creating github issues. Its called ‘ghi’

with this I can open issues with the following simple command

githubrepo> ghi -o "issue title"


githubrepo> ghi -o "issue title" -m "issue body"

ghi assumes that you are in a directory of a git repository, which is also nice because you don’t have to tell it which repo to send the issue to.

Take this, and combine it with and you can get some amazing issue management. Lightweight enough for me to actually use it, and captures enough data that its helpful to the team. Since we all get emails of the issues, the team is alerted and then we all can start piling on comments. Then once it is done, we can simply push the commit with a ‘close #123′ and now the issues is closed.

Again, nothing amazing, just a simple tool and a simple technique that is making my life better.


Posted in Small Ideas | 1 Comment