Brian Kotek:
Inversion of Control

I've been using ColdFusion for a long time. When I started back in late 1997, I was a very novice programmer. There wasn't much in the way of mailing lists, online forums, or books. There was no Google, and there were no blogs. As a result, I developed what I'd consider a pretty self-reliant nature on the subject of programming. I had to read the documentation, experiment, and try things out. And doing this, I was able to solve my problems.

I am a member of a number of public discussion forums and mailing lists, and have been for many years. I moderate several forums and lists. Over the years, I've tried to help others by answering questions or pointing them in the right direction to solve their problems. I'd like to hope that I've helped save some people some of the pain and time that I had to go through when I was learning ColdFusion.

Lately I've been seeing a disturbing trend: a rapidly increasing number of what I will call "lazy questioners". Sure, some of these folks have always been around. But in the last six to twelve months it seems like the number of these people has been making a rapid upturn.

On the one hand, this might be good news: it seems to indicate that more new people are coming into the community. I think that's great. However, what I don't think is great is their approach to asking questions.

If you are also a member of one or more forums or mailing lists, have you also noticed the increasing number of questions like these?

• How do I invoke a trigger from ColdFusion?
• Why doesn't this work: <cfif IsDefined("#url.id#")>...
• Why does my if block always run: <cfparam name="url.id" default="0" /> <cfif IsDefined('url.id')>...
• How do I zip something in ColdFusion?
• What is wrong with my query? [paste SQL]
• This doesn't work please help me. [paste 300 lines of code]
• Why doesn't this work? #XMLParse( [string with invalid xml characters in it] )#
• Will this work? [paste code]

The list really goes on and on, these are just a few of the ones I recall seeing recently. If you're asking yourself "what's wrong with those questions?", I'll tell you: either they're horribly presented questions or they could be solved in 30 seconds just by doing a Google search or actually looking at the documentation.

So what's the problem? The next response is probably "just ignore the question if you don't have anything nice to say." That's a valid response. And it would work, provided that everyone else also followed it. But they don't. When questions like these come up (daily at this point), at least one good-natured person decides to try and help. They politely provide a useful answer. Which is admirable. I often do this myself. But after thinking about the overall situation, I've come to the conclusion that it's actually a harmful choice. Here are some of the reasons why:

First, all this does is encourage the questioner's laziness. In fact, it encourages laziness for anyone asking a question. Why would someone bother to find an answer on their own when they see they can just ask someone else and know they'll get an answer?

It also means the person probably hasn't really learned much. They certainly haven't learned how to find the solution to a similar problem when (not if) they encounter one. The old adage "Give a man a fish, feed him for a day. Teach a man to fish, feed him for a lifetime." has never been more applicable. Answering a lazy question almost guarantees more lazy questions in the future. The questioner is banking on the generosity of others, and allowing them to shift the time and effort onto a bunch of other people. And, unfortunately, it works.

Which leads directly into the next negative result, which is an overall decrease in the usefulness of the list or forum. Lazy questions decrease the signal to noise ratio of a resource. They take time and attention away from valid and well presented questions. And it's not just the initial answer. Often, when a lazy question is answered, it triggers a long exchange where the questioner says "that still doesn't work" or "what about this variation". In response, the kind folks answering keep feeding into it, many times offering additional information that the questioner would have discovered themselves if they had put even minimal effort into solving their problem through Google or the documentation.

In essence, I think the ColdFusion community is too forgiving of lazy questions. I might get flak for saying this, but it's true: we're too nice when it comes to this issue.

Now to be clear, I'm not saying we should be mean, or that we should stop answering questions. We should absolutely keep answering questions. I certainly will keep trying to help people. But anyone asking a question should understand that there is a certain minimum level of effort that should be met before you ask. To me, the minimum level of effort is:

• Have you actually tried to run the code? What was the result?
• If there is an error, be able to provide the exact error to the best of your ability
• Have you read the documentation?
  
• Have you searched Google?
• Have you searched the past threads/messages?
• If the problem is SQL-related, have you run the query directly against the database, outside of CF?
• If you plan to paste code, have you eliminated all extraneous code and limited the code to only what is involved in the problem?
• Have you attempted minimal debugging with cfdump, cfabort, or cftrace?

This is not a lot to ask. In fact, this should be done out of common sense and common courtesy. If someone chooses not to meet this minimum level of effort, they should be met with a terse, blunt response, and NOT the answer to their question. There is a much more general and lengthy resource on this subject at the Smart Questions FAQ.

Here are a few situations where I say the questioner's laziness should be called out:

• The answer could be found by simply reading the documentation on the tag or function, and it is obvious that they have not
  
• The answer could be found with a 30 second Google search
• The questioner is asking an advanced question on a complex subject when it is clear they have limited understanding of the subject or what they're even asking about, and they're expecting a free class on the subject (i.e. "I don't know much SQL, but how do I write this complicated query")
• The questioner is asking if something will work when they haven't even tried to run it
• The questioner is asking others to write their code for them
• The questioner is pasting huge amounts of code and expecting others to sift through it

In many other communities, lazy questions are met with harsh responses that range from "RTFM" to "JFGI" to derisive abuse. I'm not asking the community to go down that road. I love the fact that for the most part, the CF community is a very open and encouraging place. I just think that a small but growning number of people are taking advantage of that generous spirit. It's time to impose some minimal expectations on those who would ask for our time and assistance.

I'm expecting this to trigger some interesting feedback (hopefully nothing too rough, but if you disagree and can point out some flaw with my logic here, by all means go for it). What do folks think about this issue, and what is the best way to deal with it?

Comments (18) | del.icio.us | Digg It! | Linking Blogs | 2235 Views

In The ThoughtWorks Anthology there is a chapter called "Object Calisthenics". This section lays out a challenge to help push your understanding of object-oriented programming concepts. I decided to take this challenge by building a little Flex application, and I've been quite surprised by its effect. It really does make you think very deeply about what OOP means and how it affects the way you program.

In essence, the challenge is to write a non-trivial (about 1000 lines) program of your choosing that does not violate a set of 9 rules. The rules are very draconian, and they aren't advocating that you actually write all of your software this way (though obeying them in most cases probably would be a good thing). But the goal of the exercise is to really expose any lingering influence of procedural coding and force you to come to terms with them. While I chose to do this in Flex and ActionScript (since that is what I am currently learning in depth), I think some of these would probably need a bit of tweaking in a ColdFusion implementation, but most of it would still apply. Here are the rules:

1. One level of indentation per method. If you need more than one level in from the start of the method body, create another method and call it. So one level of a loop or if statement is ok, but any deeper and you need to break it out into its own method.
2. Don't use the ELSE keyword. This one is tough. We're very used to using if/else or switch/case. But good OO designs rely on polymorphism in place of conditional logic.
3. Wrap all primitives and Strings. That means instead of var zipCode : String, you need var zipCode : ZipCode, and instead of var age : int, you need var age : Age. The idea is to ensure that everything is an object, that the purpose of everything is self-evident from it's type, and that behavior related to that object has somewhere to go.
4. Use first class collections. This means you can't have var cartItems : ArrayList, but instead have var cartItems : CartItems. This means that behavior related to the collection has a place to live, and that the collection should contain no other instance variables.
5. One dot per line. This is meant to enforce the Law of Demeter. So this would be a no-no: invoice.lineItems.getLineItem(4). Although this discourages method-chaining in cases where a method returns the same object (a la JQuery), that isn't what this rule is trying to do. It's trying to stop you from reaching across class boundaries and digging into the guts of other objects.
6. Don't abbreviate anything. This is meant to enforce clarity, as well as identify duplication or misplaced responsibilities. If you're typing mergeUserPreferencesFromDatabaseAndCookies() too often, something is probably wrong, both in terms of what the method is doing and how many things are coupled to it.
7. Keep entities small. No class over 50 lines, and no package over 10 files.
8. No classes with more than two instance variables. This is meant to ruthlessly enforce the single responsibility principle for objects. If you need more instance variables, break them into composed objects.
9. No getter, setter, and property calls to other objects. This mandates the principle to "Tell, don't ask" and enforces strong encapsulation boundaries.

I chose to write a program that generates a game of 10 pin bowling, and then scores it. And wow, writing code to score a game of bowling was actually a lot harder than I initially thought, even without the above rules. But I'm just about done with it and when I am I'll post it here in case anyone wants to take a look at it.

But before I post it, I thought I would ask if anyone else is interested in giving this a shot? Would anyone be up for trying this (with a bowling score card or any other idea you like), sending them to me, and having me post them (anonymously if people prefer) and start a blog discussion about them? I think it would be quite educational to see how different people approach these rules to solve problems, and I'm sure everyone involved would benefit. Any takers?

Comments (14) | del.icio.us | Digg It! | Linking Blogs | 2537 Views

This will probably be appearing on a number of blogs today, but it looks like this is the first post about it. As some of you may or may not know, my coworker Joe Rinehart's wife Dale was diagnosed with Multiple Sclerosis just before Christmas. A group of community members, including myself, have taken it upon ourselves to set up a donation pool to try and offer a little assistance to the Rineharts in this difficult time and offset the large and ongoing medical expenses associated with this illness.

Just to be clear: Joe has nothing to do with this and hasn't asked anyone for help. That's just not the kind of guy he is. We felt that, as a valued friend and community member, we would contribute to a small fund to help him out. We thought it was the least we could do. While doing this, it seemed obvious to put the word out to the community in case anyone else was likeminded.

I won't make this long and preachy. Joe's helped a lot of people over the years, and Model-Glue is being used by a huge number of people. So if you know Joe, or have benefited from his efforts, please consider making a donation. If you'd like to join us in helping, we've set up a simple page at http://www.helpsupportjoeanddale.com/.

The Paypal account that gets the donations is my own, so you'll see my user name (brian428) on the Paypal page. Rest assured that all donations will be transferred directly to Joe. No shenanigans here. Just an attempt to help out a friend. I know times are tough right now for a lot of folks, but thanks in advance for anything you feel you can contribute.

Respectfully,

Brian

Comments (3) | del.icio.us | Digg It! | Linking Blogs | 1389 Views

As anyone who has frequented my blog in the past is probably aware, I haven't been doing much blogging lately. Work at Broadchoice has continued to be very intense, and what little time I have away from code has been spent slaughtering zombies in Left 4 Dead! On top of this, I haven't been doing much work with ColdFusion lately, as all of my effort has been directed into learning and coding in Flex, AIR, and Groovy. So I've actually been a bit uncertain about what I have to say that anyone else might care about.

I've decided that my blogging slackness has to change! So I'm hereby laying out a preemptive New Year's Resolution that I will be back to blogging more in 2009.

The focus here will likely expand to include entries on learning and using AIR, Flex, and Groovy since that's been the core of what I've been doing for the last several months. I'd also like to talk about some more general topics that apply regardless of language: things like object-oriented programming, test-driven development, refactoring, and application design. I realize that many folks out there haven't yet taken the plunge into Flex or AIR, so I'll try to keep those topics loose and ensure that any underlying themes are (hopefully!) useful to both RIA and non-RIA developers. With AIR and Flex rapidly gaining traction, I think 2009 will see a large number of ColdFusion developers at least looking seriously at these technologies and learning them, if not using them on full-blown applications.

ColdFusion 9 is also coming and will most likely be released some time in 2009, and hopefully earlier rather than later! When I can, I want to start writing about some of the new features that have been announced for the next release, including Hibernate support, AIR integration, and language enhancements. I think that some of these may trigger fairly fundamental changes in how CF apps are built and maintained, and I have no doubt that there will be an avalanche of blog posts and discussion forum threads on these topics once Adobe pulls the curtain back.

Do these sound like topics folks in the CF blogosphere would be interested in reading about? Am I missing anything that folks might want to hear about that I haven't mentioned? If so, please comment and let me know.

In the meantime, I'm already working on a few new posts in tandem and will get them ready for publication shortly. Thanks for sticking with me through the slow period! I hope everyone has had a good holiday so far, and has a great New Years.

Comments (4) | del.icio.us | Digg It! | Linking Blogs | 1662 Views

I'm happy to say that the Broadchoice Workspace application has gone gold! If you haven't already given it a look, please download it and let us know what you think. If you don't already have Adobe AIR installed, the installer should set that up for you as well.

On a personal level, we built this application in an incredibly short time, and my hat is off to our entire team. Many long days and late nights were poured into this effort, and I hope that shows in the final product. Working with Joe, Ray, Sean, and the numerous others who helped put this together has been incredibly rewarding.

And even though we're all breathing a sigh of relief at making it to this point, we're not anywhere near finished. We plan to keep adding new features and incorporating user suggestions, so in many ways this is just the beginning. (Yes, sorry, that was cliché, but it's true!) Thanks also go out to our beta testers for all their great feedback. I hope everyone finds Workspace to be a useful and promising new collaboration tool.

Comments (2) | del.icio.us | Digg It! | Linking Blogs | 1695 Views