A legitimate complaint about ColdFusion 8

I spotted this post on MXNA last night that at first appeared to be yet another CF is Dead type post. I'm not sure why I read it, but once I reached the second paragraph, I realized that it contained a legitimate complaint about ColdFusion 8's AJAX implementation. I suspect a good number of folks ignored it due to the title, so I thought I'd give you all a second chance. I don't necessarily agree with all of the complaints, but I do hope that Adobe does address some of this in future versions. Note: I've disabled comments on this post since it's really just a pointer.

Labels: Adobe, AJAX, ColdFusion

posted by Luis

Putting Object Oriented CF in Perspective

After reading this post from Ben Nadel last week, I got to thinking about an OO reality check. I'm doing an intro to OO in ColdFusion tomorrow for our staff, and one of the things I plan to emphasize is that these techniques are another tool for their toolbox. While there are times that OO will be the best tool for their project, there may be times where it makes little sense. I'm not going to pull out a nail gun, when a hammer is all I need. On the other hand, when I do really need the nail gun, sticking with a hammer is kinda silly. (not to mention slow)

The thing about OO is that it takes time to learn (I'm two years into the process, and still have a long way to go.) That doesn't, however, mean that I haven't been taking advantage of OO during that time. I see this as a Yahoo's problems are not your problems type situation.

But also realize that Yahoo's problems aren't necessarily your problems. There is no such thing as one-size-fits-all guidance. Strive to understand the advice first, then implement the advice that makes sense for your specific situation.

I code things the best way that I currently know, until I get into a situation where I say, "There's got to be a better way!", then I go out and figure out what that better way is. This not only grows my skills when I need it, but also means my applications use these techniques when they are required. I've read about this idea of development several times when dealing with design patterns. The idea is that design patterns were meant to be used to solve problems when they are needed. Using the most design patterns doesn't mean you win. I believe the same holds true for OO concepts. I've been recently dealing with an application written by a couple of developers who are no longer working with us. They were so focused on OO purity that they ignored many of CF's native features. In the right situation each of these decisions might make sense, but in this case, they combined for an application that is harder to maintain than it would've been if they had been focused on writing simple and maintainable code.

Perhaps Ben's difficulty in understanding a specific OO concept is that he's not yet really needed it. I'm not in any way suggesting that we don't spend time on learning things that we don't yet need to know. I've bookmarked some of the links from the comments to that post, and will read them as time permits; however, most of the code that I'm writing these days will continue to use Transfer, Reactor, or simple gateways and DAOs, which has been meeting my needs quite nicely. When I need something more, it's nice to know it's there, though. And please, keep up with the great posts and discussions on advanced topics.

The bottom line here is that effective development means using the right tool at the right time. There have been a number of times where I've started sections of code with comments explaining that if this section is expanded, it should be refactored to be more OO first (usually with a detailed explanation of what to do), but for the sake of simplicity and expediency, I’ve written it in a more procedural fashion. Occasionally, I go back and refactor those bits of code as the situation warrants. Other times, I just let them run as they are. It may not be the most textbook code, but I find it effective.

Labels: ColdFusion, Design Patterns, Object Oriented Programming

posted by Luis - 0 comments

We need a new UI paradigm

In my mind, one of the most exiting web 2.0 innovations for businesses (sometimes called Business 2.0) is mashups. The Summer edition of Innovations listed mashups and making data more available as trends in the business world. Working for a medical college, I can foresee the day when faculty members could use current medical trends to determine what areas to emphasize, or even analyze areas where the student body is weak in order to focus on those areas more. (Perhaps even both) The point is that in order to take full advantage of the increases in data accessibility, users will need to be able to create their own mashups. Of course I'm not advocating a Coghead type approach (I agree with Alex from Worse than Failure on this subject). I expect that developers will probably continue to build reusable mashups and reports, but for basic ad-hoc mashups to be effective, users will need to be able to do it themselves. The key to this, I think, will be the creation of a new UI paradigm.
If you think about it, most applications have general UI paradigms. If you are familiar with one Word Processor, you can perform basic operations on pretty much any word processor on the market. For advanced features, you've still got to learn the specific product. The same is true for everything from Email to mapping software (Google maps, or even something like Zillow don't work much differently than old standards like Mapquest.) The only questions left is "Who will introduce the new paradigm?", and "How long will it take to become Standardized?".

Labels: business 2.0, enterprise 2.0, mashup, user interface, web 2.0

posted by Luis - 2 comments

Gettin' Reorganized

I came back from Vacation a few weeks ago to find out that my department is reorganizing. It's taken a few weeks to find out what exactly that means, but essentially I (and my colleagues) are in the process of deciding to either be full time web developers or move into middleware. It's an interesting decision to make. In my case, most of what I currently work on, falls under the middleware umbrella, but moving over there means probably less coding (at the very least less, ColdFusion coding, probably no Actionscript work, and most certainly no Flex). It would mean, however moving into other interesting things like identity management, and data integration, that would give the reconstituted web development group broader access to interrelated data from various systems. At the moment I'm trying to figure out whether it'll be more interesting enabling this access, or building the mashups that will hopefully be and end result. Decisions, decisions... In any event, I'll either keep this blog Adobe/Web related, or have it removed from MXNA.

Labels: Actionscript, Adobe, ColdFusion, Flash, Flex, mashup, middleware

posted by Luis - 0 comments