This blog has been moved to http://info.timkellogg.me/blog/

Saturday, May 29, 2010

Why I Decided To Start A Blog


I strongly believe that for every avenue of life that we enter, we should leave it a better place. So for every job that I take, my goal is to leave a more efficient or more powerful work group behind. By blogging I can bring up issues that I come across, and if I also bring up solutions to those problems I can give other people the chance to learn from my experiences.

I also believe strongly in open source software (OSS). I wish there were more companies like Google that invest a lot of capital in developing OSS. From a business standpoint, when considering investment in public resources like OSS, it is hard to see the ROI. I think Google has done an exceptional job of finding revenue from OSS, and I think that is positive for the world.

Blogging is similar to OSS in the way that blogs are a public resource and they're written by regular people in their spare time (I wish I could be paid to develop OSS). I read a lot of blogs from other technical people. Some of them I follow regularly, others I end up inadvertently reading by googling for some technical problem. Blogs are free content that adds value to our lives.

Starting a blog was a result of a lot of thinking. It's been bugging me for a while that I read all these blogs and I don't write one. I think its important to give back at least a portion of what you consume. If you don't like what I have to say here you don't have to read it. What I say here won't waste anyone's time or clog their inbox without their consent. Since this blog can't ever be a burden on society, it can only add value. So in that line of logic, this blog is necessary.

Friday, May 28, 2010

Incidental Inversion of Control

This morning I started reading about the Spring Framework and, as usual, I followed a rabbit hole to learn what the phrase Inversion of Control (IoC) means. IoC is also known as the Hollywood Effect ("don't call us, we'll call you"). A lot of programming frameworks use an inversion of control to take care of the bulk of the work and leave your code to perform its task (and only its task).

Most web frameworks are a good example of IoC. In Java web applications, the framework takes care of all HTTP complexities and turns control over to your servlet or JSP when the time is right. This leaves your JSP to process the request and return a response - easy! The ASP.NET framework has an excellent inversion of control with its postback model. The framework allows for applications to be built very similar to Windows applications - the underlying framework takes care of display issues and calls parts of the applications code when the time is right. A lot of these calls to code are handlers for events like Click, Load, and others.

As I read about this "new" concept I began to realize that it wasn't new at all. ASP.NET and J2EE use it extensively. In fact, I have created such a framework without realizing what I created. In the middle of last year I created a pluggable scheduler interface for our eQube environment that allows the programmer to simply specify report names and filter values via XML, and when it comes time to do something special, the programmer can hook into events and have the framework execute some JavaScript code to do something special.

I stumbled into creating this framework after doing several short projects that required some boilerplate code to interface with the eQube APIs. It all happened quite innocently, but having taken the incidental route to IoC framework I have gotten much more value than I thought I would. For instance, it is suddenly very easy to run a report with 400 different filter configurations. I just put together some XML to spec the report and throw in a block of JavaScript to change the filter values. The inversion of control takes away most of the responsibility and leaves me to do my job, and only my job.

After today's lesson in inversion of control, I'm brainstorming new ways to use it. Perhaps even consolidating my other code into the scheduler framework, or maybe integrating it with the spring framework. As always, there's power in doing less.