In my continuing journey with TeamCity, I’ve discovered something highly annoying… not with TeamCity but with Adobe.

I’m trying to build a master configuration with an Ant script that will automatically build several child modules. First thing I realize is that I have to override the path properties of the child Ant script with relatives paths from the parent script. Ok, that makes sense since it’s a subtask being called from the scope of the parent, so the paths have to be from that directory.

Then I try to call COMPC in the child Ant script. It chokes hard with:

[compc] command line: Error: unable to open 'api/src/Manifest.xml'

“That’s odd,” I think. I know I’m passing it the right path (contained in the ${src.dir} property). However, just to check, let’s echo out the contents of the path I’m sending to the child script.

<fileset id="dir.contents" dir="${src.dir}" includes="*"/>
<property name="file.name" refid="dir.contents"/>
<echo>${file.name}</echo>

I run the script again, and lo and behold, guess what echoes out?

 [echo] Manifest.xml

wtf?

Ant says that the file exists in the path contained in the ${src.dir} property, but the COMPC task says it doesn’t exist?

<compc output="${build.dir}/${build.file}" debug="false">
	<include-namespaces uri="${namespace}" />
	<namespace uri="${namespace}" manifest="${src.dir}/${manifest.filename}" />
   ...

Still haven’t figured this one out, because I’m now stuck in the process of throwing darts with a blindfold on, simply guessing which directory COMPC thinks it’s starting from, because, of course, there’s no way to output anything from inside the COMPC task.

ARGH!!!

I’ve had a task I assigned to myself open for some time now. I needed to figure out how to implement Flex/ColdFusion messaging for our clients. There were three (3) criteria for success:

1. It needed to integrate seamlessly with our existing Cairngorm Extensions
2. It needed to allow for application level messages
3. It needed to allow for client specific messages

The trick was to create an abstract class that multiple departments could use, because internally we use ColdFusion, Java and .NET to produce and consume messages. In our department, we use ColdFusion, so I had to create a concrete implementation of the abstract class called ColdFusionMessagingDelegate which handles the construction and publication of an AsyncMessage to a ColdFusion Event Gateway.

Other departments’ implementation of this process will be different, so I couldn’t force an implementation in the abstract class.

Additionally, in the application I was using for testing, I wanted to have two categories of messages:

1. Messages intended to be produced and consumed by individual clients
2. Messages intended to be consumed by any client

To that end, I created another abstract class at the application level that simply passed along specific a Flex Producer and Consumer for each category. I then created two concrete classes. One specified the Producer and Consumer for the application, and the other specified the Producer and Consumer for that individual client.

Here’s a diagram showing the architecture.

Generic Messaging Architecture

So far, it’s working great in the development test lab, but I still need to get with my colleagues for a group code review and hopefully fine tune the code and the architecture a bit more.

I’ve been obsessed lately with reading about Agent Oriented Programming (AOP). I’m fascinated about the concept of making objects autonomous and capable of responding to environmental changes, rather than predefining what they will and will not do (as opposed to what they can and cannot do).

It is interesting, for me, to note that AOP and Service Oriented Architectures (SOA) started to gain momentum around the same time, and yet the interest, and advancements, in SOA quickly outdistanced those for AOP.

In my opinion, this is because the practical applications for AOP are minimal, while the concepts of SOA can quickly and easily be grasped and implemented in many business environments.

I can’t really find any white papers from someone who’s actually implemented a project with this kind of architecture, so it all seems stalled in the theoretical phase still. Of course, I can’t think of a project that I’m working where we could use this.

I still find it fascinating, though.

What Is An Agent?
Properties of Agents
Agent Oriented Software Engineering
A Taxonomy for Autonomous Agents
Jam! Agent Architecture

A bit closer to home this time.

My family’s company back home has been running a ColdFusion-powered site that I wrote for them yyeeeeaaarrrsss ago. My sister, who is now running the marketing department, wants to do an overhaul of the site, because it has been yyeeeeaaarrrsss since the first version.

Obviously, I’m not available to help them out full time – y’know, being four states away with a wife and two kids and all – and she’s found it impossible to find anyone with ColdFusion skills back in Pittsburgh. She’s made the decision to use PHP as the technology for the new site.

Kinda speaks for itself there.

Weird that I’ve been a small time evangelist for ColdFusion all these years and recently all I’ve been hearing about is how people are deciding to not use it any more.

What’s going on?

Was speaking with a friend back home today who works for a very large financial institution. They currently have a major investment in the Adobe stack of technologies, including ColdFusion. However, the decision was recently made – as usual, at a business level – to become a Microsoft shop.

One of the critical elements in this was the fact that ColdFusion developers, specifically highly talented ones that can architect enterprise level applications, simply did not exist in the marketplace. There are too few of them, and they are all currently employed, and the cost of developing someone of this caliber was simply too high and would take too long.

I’ve read far too many times in the past 12 years about how Allaire/Macromedia/Adobe does not make the appropriate efforts to get the ColdFusion development platform into the hands of kids early, when they are learning development, so that when these kids coming out of college enter the workforce they know Microsoft or Java technologies, or both, and then may possibly, occasionally, touch upon a couple of features of the ColdFusion platform years later.

The result is more and more business decision makers not even considering it as an option. Technology aside here people, look at it from a business perspective. Ok, fine, ColdFusion is a great platform. It has lots of features and is easy to learn.

So what?

I need to hire 9 people right now who have vast, deep experience in building mission critical applications that perform at the highest level, scale with the organization and the user base, and are extensible so that we can keep making it better.

Having gone through this process many times myself… I’m sorry but ColdFusion doesn’t cut it. I love the platform, I love the people, and the community, but if I got funding to build a major application or system, and needed a large, experienced development team, I would not choose ColdFusion.

Now, once the system got off the ground and the underlying architecture was solid and we needed to start expanding the system, making sub-projects from it, then sure I’d consider hiring a few ColdFusion developers because you can build applications very quickly with and perform some integrations more easily.

Bottom line is that, while I’m sad to see another promising ColdFusion shop being slowly dismantled over the next two years, I can’t say I disagree with the decision.

It sucks.