Stake Five

A little late, I know, but the jetlag has finally cleared enough to allow me to write coherently… Yep, just in time for me to head back to Bangalore and go through this all over again!

As many will know by now, we showed off a bunch of features coming in ColdFusion 8 aka Scorpio. Prayank covered image manipulation, Rupesh talked about CF-.NET integration, and I got to show off server monitoring. For those of you who couldn’t make it, we did record our presentations prior to heading out; I’ll send a link to those once I know where they’re being hosted. If you just can’t wait for those, check out some of the liveblogging summaries that Rob and Ray (thanks, guys!) put out from the sessions:

• Image Manipulation - Ray, Rob
• Server Monitoring - Ray, Rob
• CF-.NET integration - Ray, Rob

As is generally the case with the CF team, the developers presenting features are those who worked on them, so if you have any specific questions of these features, head on over to Rupesh’s or Prayank’s blogs (or mine, but you know where that is!) and leave us comments.

The one big MAX announcement that I think is going to be really interesting is the Apollo platform. Various technologies have attempted to provide simple network-distributed applications in the past, and all of them failed, though some do still linger on - Java WebStart (still alive and kicking), Zaplets (dearly departed), Droplets (still around, it would seem). Then, of course, there are newer contenders like the Yahoo desktop widgets; while that engine is pretty interesting, it doesn’t yet match Apollo for features and, for the moment, seems aimed towards more restricted one-off applications.

I think Adobe has got it right with Apollo - the programming environment is simple and familiar (JavaScript, HTML, Flex, PDF, all of which CF plays with nicely, of course), and Adobe owns what is arguably amongst the most powerful software distribution mechanisms on the planet, the installed base of Flash player users. You’ll be seeing Apollo applications in the enterprise pretty soon, I”m sure; but I’m equally certain that you’ll be seeing a lot more of them out in the wild, on the public web. This is one client technology you don’t want to miss out on.

Apologies all for the long silence - after I got back from a perfectly lovely holiday in Goa, work got pretty busy, especially with all the last minute preparations for MAX.

I arrived in Las Vegas last night. A little early, perhaps, but those of us who are presenting from the CF team decided to get here a day before MAX kicks off so we could beat the jet lag in time for our sessions. Being a night owl is great in Vegas, I know, but having my mind shut down thinking it’s time for bed won’t be so good when I have to deliver my session, Unlocking the ColdFusion Server Black Box. For those of you who are here, do attend it if you can - I’ll be previewing some new CF tools, and I’d love to get your feedback.

The best part about this for me is that I’ll finally be able to move some of the stuff I’ve been working on for Scorpio out of stealth mode. I’ll be writing more about it here, so those of you can’t make it out to MAX can get an idea of some of the things the CF team has been throwing in the pot for Scorpio.

I’ll be at the reception tomorrow evening, of course, so if you’re here, do come by and say hello.

Sean put up his wishlist for CF recently, and one of the interesting things he was wishing for was the capability to call CF from the command line.

The thing is, you can already do this, and fairly easily. Let’s start by getting the right tool for the job - go pick up cURL, a tool for invoking URLs from the command line. Do note that if you choose to download the HTTPS-enabled version of cURL, you will need to also get the libeay.dll library for SSL support from OpenSSL.

That’s really all you need. You can invoke cURL like so: curl (CFM template URL). The output of the CFM is printed to the stdout, which means it will show up in your DOS window/UNIX shell/whatever. Easy, huh?

To invoke a CFC, you’ll have to use the CFC HTTP invocation syntax, which is simple enough:

http://(hostname):(port)/(context, if JEE deployment)/(path to CFC)?method=(function to invoke)&(argument list)

Responses from CFC functions are returned in WDDX format, unless the function returns XML, in which case the XML is returned as-is. Oh, and do make sure you tag your function with access=remote so that CF will allow remote calls to it.

For example, to invoke a function called echo, which takes an arguments input1 and input2, on a CFC my.application.callme, on a standalone CF deployment, you could do this:

http://myhost/my/application/callme.cfc?method=echo&input1=yodel&input2=hey

For those who think all this is just too hard (yeah, right!), here’s a simple shell script that will do the job of invoking a CFC - edit it to change your serverroot, then invoke it at will, passing in the CFC, function and argument list (in the form arg1=val1&arg2=val2).

serverroot="http://localhost:8500/"

callto=`echo $1 | sed -e 's/\\./\\//g'`
cffunction=$2
args=$3

url=$serverroot$callto".cfc?method="$cffunction"&"$args

curl $url

For example, if your save your script as callCF.sh:

callCF.sh my.application.callme echo input1=yodel&input2=hey

Apologies to DOS users - the scripting that I have done, I’ve done on UNIX systems. Even when I’m forced to use Windows on the desktop, I always have Cygwin installed so I have all those great UNIX command line tools handy.

Now I hear you thinking - do we really have to have a server running to make all these invocations? Couldn’t we have a nice lightweight runtime that can be invoked on the fly? In theory, yes, of course we could. In practice, absolutely not - CFMX was built on the assumption that it would run within a JEE application server. Ripping out, and rebuilding, all the plumbing would be a prohibitively expensive task.

Well, there’s at least one wish fulfilled that we can all talk about - if only the others were as easy! I cannot, alas, yet tell you how many more of Sean’s, and others’, wishes will be granted for Scorpio… But rest assured, we’re paying attention. And some of those wishes, well, they’ve already been granted.

Update: Dopefly opines, as Sean does, that a gateway would provide for more secure invocation. I don’t entirely agree with them - this really comes down to where you choose to put your security, in a gateway, or in a CFC. It could easily be embedded in a CFC by checking that the CGI.SERVER_NAME is localhost, or by ensuring that the IP address of the caller, CGI.REMOTE_ADDR, is in a whitelist of IP addresses allowed to invoke the CFC.

Rupesh, of Coldfused? fame, is finally back to blogging, after having cranked out a final version of the CFThread POC. He’s one of the smartest guys I know, and is at least partially to blame for hiring me to the CF team…
Check out his entries on Handling J2EE Sessions with Cookies Disabled and JRun Threadpool Settings.

Like Hemant (get a blog, dude!) Khandelwal, the manager on our team, he came to Macromedia from Pramati, an Indian software product company that set out to create a JEE application server. While the Pramati technology is great stuff, it proved difficult for them to make it in a market already crowded with JEE application servers, especially when going up against the likes of IBM and BEA. During his time there, Rupesh worked on a lot of the hard security problems, so whenever we have to deal with things like HTTPS and certificate management, he’s our go-to guy.

And speaking of Hemant, he’s no slouch in the technical department either - he was responsible for the first commercial EJB 2.0 compliant container, in the Pramati JEE server, and has served on the EJB specification committee. While he does enjoy whipping us lazy louts to get some work done, I know he misses coding…

Artist’s impression of Ray nuking Ashwin

If it talks like a duck and walks like a duck, then it must be a duck… and, apparently, it’ll waddle a good deal faster than a turkey, or any other non-duck species.

I’ve been meaning to get to the subject of duck typing and performance ever since I saw Sean give his presentation at CFUnited. Unfortunately, the performance aspect of going duck was what caught most people’s attention; as Sean shouts out duck typing is not about performance.

I finally got round to downloading Sean’s source code and ran some tests of my own. Here’s the low-down - performance is affected only when the argument type or return type is specified as a CFC; if it is anything else, performance is about equal to the duck typed equivalents. If you’re typing arguments and return values to structs, arrays, strings, numbers, whatever, duck typing will not give you any performance gains. Apologies all if I’m repeating what’s already been pointed out; I searched around a bit and couldn’t find anyone else commenting on this particular detail.

CFC type checking is always going to be more expensive than checking any other type, since we need to jump through many of the same hoops as we do during createObject() to actually resolve the path to the CFC template - is the path to type being checked relative or absolute? Is it referenced via a mapping? Is the type being checked a supertype of the type passed in? You get the idea; evaluating these kinds of complex relationships is expensive.

So do duck type if your design calls for it, or if you’re having serious performance problems with code that checks for CFC types. Otherwise, make like a monkey and code!

Update: You can download the code I used for testing here. It’s identical to Sean’s code, with the exception of a new typedNative function in performance.cfm, which is used to test for “native” types, i.e., Struct, Array, whatever.

… no server (or language, or platform, or all of the above!) has gone before?

Much fuss has been made over CF not being an enterprise platform. All too often, it would seem, we’re the poor kids who get the ‘lite’ projects. Why is this?

I will concede that some of the fault lies with the product. There are long standing requests such as CFC serialization that have yet to be addressed. There are performance issues that have been found with CFSWITCH, string concatenation and other areas of the server.

So I’d like to ask all of you - what’s your number 1 problem that stops you from being able to sell CF up to your management/customers as an “enterprise” grade solution? Leave your comments here, and I promise they’ll be looked into.

At the same time, I think we as a community have some work to do as well. How do we change the impression that CF is not an enterprise platform? There is a problem to CF being such an easy language to learn, with so much power packed into individual tags; it’s just as easy to abuse that power as it is to use it. Could CF provide more checks and balances to ensure that this does not happen? Perhaps, but definitely not in every case.

So do start applying those best practices and numerous frameworks (and un-frameworks!) in your projects. Read the presentations Sean’s put up, Ben’s resources page, and the numerous CF blogs dealing with this stuff. I’m the last person to claim that the application of these best practices and patterns are easy to understand the first time round; but as you get into them, I think you’ll find that they become a habit, an integral part of the way you design and code.

On an (un)related note, the crew of the good Starship Enterprise celebrated their 40th anniversary this weekend past - happy birthday, Star Trek!

I like Spry. Why? Simple - they got their data model right.

Not that I’ve done a lot of AJAX work, but from what I’ve seen of other frameworks, it seems that the general focus has been on creating cool UI components. While this is not at all a bad thing, the result is that AJAX data models are not nearly as mature as they could be.

Continue Reading »

There’s been much rubbing of magic lamps and wishing of wishes over what features we should throw into ColdFusion 8 aka Scorpio. Sean has the roundup of comments from Simon Horwith, Brian Kotek and Brandon Harper. Which will be granted? Only Damon can tell… Loudmouth that I am, I can’t help but add my own 2 paisa to the debate.

CFML is a simple language. Joe/Jane developer can get up and running building a CF application in a fraction of the time it would take with practically any other technology. At heart, CFML is a language rooted in tags. There’s no need to digest half a dozen reference books to dive into CFML - you can just pick the tags you need and go from there.

Adding new language features to parallel those available elsewhere (Java, Ruby, whatever) does not detract from this power - it adds to it. Your applications can be as simple or as complex as you want them to be. But even when they’re complex, the complexity can be isolated at a layer of abstraction above the actual business logic, because the business logic is still largely composed of simple, powerful tags. The key, of course, is to ensure that the features we add do not mess with CFML’s essential simplicity; if there’s one thing the CF team is paranoid about, this would be it.

But addition of any new feature is tempered by the time we have available to release, and the number of other features in queue. Prioritisation is a hard task, especially when we have you, our vociferous users, to answer to. Some features will make it, and others won’t - you know how the game is played. So you’ll see some new features that will enrich the CF language, allowing more object oriented behaviour and what-not. And you’ll soon see others like CFPRESENTATION and CFPDFFORM, which Jason showed off at CFUNITED, that will continue in the CF tradition of making hard things easy.

Some have asked whether CF should ship a framework to help define how to build applications. I would have to disagree. Each framework brings its own architectural philosophy to the table, and each is valid in its own space. Today we have frameworks that are great for building web applications. But what about frameworks for applications with Flex front ends? What if someone were to build a framework to enable CF as a data integration hub, using all the rich network interfaces that are available? Each of these will have their own specific requirements - no framework is sufficiently generic to address all needs.

CF goes far enough to make things easy, but at the same time stops short of defining how you should build your applications. That little detail, we leave to you…

Bert brought up a rather interesting scenario where he needed to force templates to be reloaded into the template cache, since he was generating bits of CFML code at runtime. I suggested that he might also want to take a look at the evaluate() function, since that would probably allow him to solve his problem in a simpler manner.

As has been noted often enough, evaluate() and iif() are not the most performant of functions, since they do need to dynamically compile the expressions that they’re being asked to process.

Evaluate() simply processes the string passed to it as if it were an expression. Iif() is the CF implementation of the Java ternary operator “?” which is exactly what it calls to do its work; this is faster than using <cfif><cfelse></cfif> to achieve the same effect. Once iif() has figured out which expression to evaluate, it simply delegates control to evaluate() to actually process the expression.

Continue Reading »