I had a magic moment this weekend when my wife and both of our babies were all asleep. I thought to myself "What should I do with this free time?". So, of course, I used it to make my first ColdFusion Builder extension, "Set IIS Root".

The extension allows me to right-click on any project or folder and set it as the web root in IIS directly from ColdFusion Builder. The functionality to do this was originally written by my friend, Jason Holden. Admittedly this is now only useful on flavors of Windows that have IIS, but don't allow multiple sites (Windows XP Pro, but not Windows 2003 or Vista), but I am in that group so it saves me time.

I was a little concerned about how difficult it would be to make an extension for ColdFusion Builder. It turned out to be really easy, taking me about an hour (or less) including the time to learn how to make an extension and to test it out. The ColdFusion Builder development team deserves major kudos here as do the authors of the documentation.

[More]

I have been thinking this for some time, but it seemed like hubris (and flame bait) to say it. So be it - it needs to be said. I worry that ColdFusion ORM is being / will be marketed where it isn't appropriate.

(What is DataMgr?)

What is Better?

It can't be helped, "better" is a word that only makes sense in the context of goals to be met. After all, it is impossible to tell if a sedan is better than a truck unless you know your goals. Do you need to get to work on low gas mileage or haul cargo? I will use the criteria that Adobe ColdFusion engineer, Rupesh Kumar, has laid out in "ColdFusion ORM - An Evolution in building datacentric application":

[More]

I don't "do OO" development in ColdFusion. I'm starting with that statement not to spark another debate about whether to use OO in ColdFusion, but rather to clarify that while this post is about a principle of object oriented development, you don't need to "Do OO" in order to learn, use, and benefit from composition.

In the last "OO Principles" entry, I introduced composition. The examples that I used were barely complicated enough to show some of the benefits of composition. Much more complicated than that, however, and you can also run into some challenges. While these do not (in my opinion) overcome the advantages of composition, they are still worth considering.

[More]

I attended CFUnited 2009 last week and I had a really great time. The last presentation that I attended was "Using Apache Derby, the Open Source Database Embedded in ColdFusion 8" by Charlie Arehart. I went to this presentation partly because I am interested in learning more about Apache Derby and partly because I try to catch at least one Charlie Arehart presentation per ColdFusion conference.

As usual for Charlie, the whole presentation was well delivered and packed with useful information. Most significant for me, however, was the difference between the two kinds of Derby datasources.

[More]

In programming, discussions often come up about which approach to solving a problem is faster. Although I think these discussions often miss the point (as other decision factors often trump execution speed), they are still often informative.

I have had a few occassions recently where I wanted to answer these questions myself. It seemed tedious to continue to write code to test that out, so I decided to write a generic "Code Timer" to run code and test for execution times.

[More]

I don't "do OO" development in ColdFusion. I'm starting with that statement not to spark another debate about whether to use OO in ColdFusion, but rather to clarify that while this post is about a principle of object oriented development, you don't need to "Do OO" in order to learn, use, and benefit from composition.

In the last "OO Principles" entry, I talked about encapsulating CFCs. The example that I use was the need to have a datasource in a component. It should be clear from that entry that you could pass in more methods as well.

[More]

I don't "do OO" development in ColdFusion. I'm starting with that statement not to spark another debate about whether to use OO in ColdFusion, but rather to clarify that while this post is about a principle of object oriented development, you don't need to "Do OO" in order to learn, use, and benefit from encapsulating CFCs.

When I first started using CFCs, I knew that encapsulation and decoupling were important, but this brought up new challenges. For example, if I had a method that queried a database, how would it know what datasource to use?

[More]

One thing I have wanted to do in ColdFusion for some time is to limit the arguments scope in a function to arguments I have declared with cfargument. That feature doesn't exist, but I made the next best thing.

[More]

Clark Valberg recently convinced Hal Helms, Brian Kotek and Ben Nadel to do a recording together discussing OO programming in ColdFusion.

The discussion reminded me of an NPR debate I listened to several months ago on whether we should bomb Iran to prevent them from acquiring nuclear weapons (unfortunately, I don't remember the specific wording of the question). The debate had three experts on either side of the question. All six seemed to agree that we would almost certainly never need to bomb Iran because so many better options exist but that we should remove the option from the table (just in case). From there it quickly moved to a semantics debate about the wording of the question on the table.

[More]

Ben Nadel recently posted a blog entry about moving queries to service layers (something I am a big fan of). Both the blog entry and the comments that followed were great and well worth the read. I especially liked Hal Helm's comment about differentiating between queries that are necessarily the same and those that are accidentally the same.

One thing that came up in this discussion was how to name the methods that retrieve data. One example was "getArticlesByAuthorID()" (I'm just picking one of many that followed this pattern). To me, this is a code smell. The method name describes not only what you want, but how you are going to get it.

I would do it differently.

[More]