Blog

So this blog is a bit of a spill over from a Twitter conversation I had today with Stefan Mischook, a PHP programmer and maker of all sorts of training videos at www.studioweb.com and www.killersites.com.  A few years ago, Stefan uploaded a video blog to YouTube titled "Should you learn Coldfusion?" (sic) where he presented a not-so-glowing review of ColdFusion through the lens of circa 2003.  I've seen the video before come up in YouTube searches.  Part of that is a testament to the pathetically small amount of actual CFML content on YouTube.  While I've recorded a number of screencasts and webinars that are posted online, they're all on Vimeo or Adobe Connect so alas I'm not contributing to that specific site.  

• www.youtube.com/watch?v=dLJpz

Last Tuesday I presented on the ColdBox Framework to my local Kansas City user group with an emphasis on the new 3.0 features like WireBox. Here is the slide deck I used.


http://slidesix.com/view/KCDevCore-ColdBox-3-WireBox-10-preso

I found an interesting little bug in the BlogCFC implementation of ColdFISH today. ColdFISH is a ColdFusion code formatting component that is instantiated once and cached as a singleton in the application scope in BlogCFC. The problem is, ColdFISH looks like it wasn't intended to be used as a singleton. It makes use of the variables scope to store the Java StringBuffer class it uses to gather up your formatted code as well as a number of other variables used to parse the code it is formatting. This means when two or more people hit a BlogCFC entry with larger code samples, race conditions exists.

I think the bane of development planning can be those conversations where you personify your framework and start debating about what a service should "know", whose "job" a particular operation is, or what the handler should "care" about. This is one of those sort of questions, but I'll keep it brief since I'm more interested in your opinions than my ramblings.

Today I offer you a question of preference. Should optional method parameters be defaulted to blank and assumed to exist, or should they only be defined if you intend to use them? In the name of code reusability I will find myself writing generic service methods such as userService.loadUser() which have a large list of optional parameters such as lastName, firstName, userName, companyID, userID, password etc. I will reuse this method any time I want to load a user or a list of users. The question is this: is it more correct to default all of the arguments or check for their existence?

A couple days ago Ray posted a screen shot from Adam L showing some new cfscript syntax in Bolt. I personally am excited about it. I certainly don't use cfscript for everything I code, but I definitely have gotten to the point where all my business logic is in cfscript. I just think it is cleaner. I have some questions of my own out the new Centaur syntax though. Here is my best stab at what the code in the screen shot looked like:

I just got out of a session with Jason Delmore talking about some of the new features being looked at in ColdFusion 9. He mostly talked about the ORM features being baked into the next version of ColdFusion courtesy of Hibernate. We also squeezed a few other tidbits of information out of him too.

As we push ahead with our app using ColdBox and LightWire, we have been configuring our Dependency Injection as we go. DI is one of those things I'm pretty certain I see the benefit to, but I'm not sure how sold on it I am. At this point, we may only have 50 to 60 CFCs so perhaps we're just not deep enough in to see the real profit yet. The only real advantage I've seen to date is having all of our dependencies spelled out in one configuration file (with the exception of the stuff you are auto-wiring). Other than that, I don't know that I have really saved any code. That being said, I don't have any circular dependencies, and my dependency levels don't get much more than 2 or 3 levels deep right now so maybe I just need to be patient.

Here's a little tidbit that will be old-hat to any Flex/Flash people out there, but as a CF guy, I found it pretty interesting. Most ColdFusion programmers have probably heard of implicit getters and setters as a pattern some have adopted in CFML (and others seem to vehemently oppose). While learning Flex, I have found that ActionScript 3 also supports implicit getting and setting but it means something completely different that what I had expected.

Lately I've noticed how impossible it is to talk about Object Oriented Programming without peppering your conversations with scholarly-sounding acronyms. I don't know if we programmers just like to sound smart or if we see it as part of a special club of sorts. As my good friend Anonymous once said, "If it is Computer Oriented and if it doesn't have an Acronym, then it doesn't exist" That being said, here is a list I comprised of acronyms that are related to OO or have come up recently in blogs about OO. See how many you can identify, and comment with any additional ones you think of.