Monday, September 3, 2012

From IoC to require

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.
-d
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.










DIGITAL JUICE

No comments:

Post a Comment

Thank's!