Cool Railo thing I learned at the London Railo Group meeting last night

G'day:
Last night was the first meeting of the London Railo Group. A bunch of people in the local London Railo community got together at the Pixl8 offices and had an informal catch-up and drank beer and ate pizza. There was only about a dozen people there, but I think it was a successful first meeting. Well done Alex Skinner for organising it, and Mark Drew for giving an impromptu presentation on some random Railo stuff he finds interesting.

Minor common-sense tweak to CFML from Railo

G'day:
This is just a quick confirmation I was wrong about something.

Railo docs licence weirdness?

G'day:
I just noticed this in the licence (yes, I read licences) for the new Railo docs site:

The Railo Docs Site by Mark Drew (@markdrew) is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

CFML: Tickets for those operators I mentioned

G'day:
This afternoon I posted an article suggesting some more operators than CFML might benefit from. At that stage I had not raised any bugbase tickets as I wanted to get a feel for what people thought before doing so.

I've had uniformly positive feedback, so I've raised tickets where necessary:

Operator	ColdFusion ticket	Railo ticket
<=>	3614455	RAILO-2582
==~	3614456	RAILO-2581
?.	3614459	RAILO-2579
??	3589888	Already implemented as a variant of ?:
.. / ...	3614460	RAILO-2579

CFML: A bit more on getFunctionCalledName(): it's broke in Railo

G'day:
Sorry for the "slow-news week" this week (well: it's been a coupla weeks now). Everything I'm planning to write up will take a while to prep, which means I find excuses to do something else instead.

A while back I wrote about getFunctionCalledName(), mostly because I can never find it in the ColdFusion docs as I never remember enough of what it's called to google it properly. So that article was purely google-bait (it didn't work, just in case you're interested... I still cannot ever remember what getFunctionCalledName() is called, nor can I successfully google it up).

London Railo Group

G'day:
Me mate Alex Skinner of Pixl8 is hosting the new London Railo Group. The first get together is on Weds Aug 28 - so two weeks' time - at their offices in Clapham.

I'm gonna pop along and take advantage of the beer and the wifi, and I think I saw mention of pizza somewhere (can't find the reference now). Oh, and having a yap about Railo and CFML and that sort of stuff.

If yer around, head over. Alex and the crew are cool bods (I've been working for / with them on and off for years, so know them well), and it'd be good to get the Railo community in London in touch with each other.

Hopefully see ya there.

--
Adam

Saving class files in ColdFusion (and Railo): anecdote should not take precedence over analysis

G'day:
There was a thread the other day on the Railo Google Group regarding the "Save Class Files" setting on Railo. I piped up with my usual spiel that I don't think it's a worthwhile setting to use on ColdFusion:

Yeah, I can't vouch for Railo, but on ColdFusion saving class files rapidly becomes a performance hit on the system (Windows) if your app is such that you generate more than a thousand or so classes. The reason being - it seems - that Windows really struggles to file-scan a directory to find the pre-compiled class if it's needed... say the one in memory has been garbage collected... once there are more than a few hundred files in that directory. On big apps it's more expedient to let the class recompile from source code than rely on Windows finding and loading a saved one.

I doubt this is a problem on *nix-based file systems.

The issue with CF is that all the classes are stored in one flat directory. If they were stored hierarchically (which shouldn't be too much of an issue?), then there'd be no problem. I did mention this to the Adobe bods, but they looked at me like I was speaking [some language they didn't understand... CF perhaps], and that was that.

Anyway... I dunno if the same consideration exists on Railo, but this would be one reason why one might not want those class files saving. Something to test, perhaps.

Mark Drew subsequently suggested it might be a topic for a blog article, so here one is.

New Railo docs site

G'day:
Bam Bam Bam. Three articles in rapid succession this evening!

I shoulda said something about this earlier, but it slipped my mind. Mark Drew has been beavering away getting the new Railo online docs sorted out, and they're now live.

The site is here: Railo Documentation Viewer.

Wanna know the best thing? This is the URL for the docs on <cfassociate>: http://railodocs.org/cfassociate. I did not look that up, I just knew all I needed to do is to type the tag (or function) after the domain name, and it works. Contrast this with Adobe's equivalent docs. Take a deep breath... http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7f5b.html. Got that? Railo seem to have a better grasp of web concepts like SEO and URL hackability than Adobe have (well if Adobe does, they don't care).

On SEO... if I search for "railo docs cfassociate" the first link is the page above. If I try "coldfusion docs cfassociate" I get the CF8 version of the docs as the first link, and the docs for ColdFusion 7 are third. ColdFusion 9 and 10 don't actually show up on that search, but Google displays them as results for "similar" searches: "coldfusion docs cfassociate", then the CF9 docs are listed. Oddly, if I actually do a search for "coldfusion cfassociate", I get the CF8 match first, the CFMX7 match on the second page (who the hell every looks at the second page of Google's search results? ;-), and by the time I gave up... page 5... I'd still not seen a link to the docs for any currently-supported version of ColdFusion. Blimey on page 3 there was a link to this blog of me talking about the tag, but nothing from Adobe on CF10 or even CF9. Slack. How can a web company be so poor at making sure their own docs are googlable?

Stupid (but trivial) bug with htmlEditFormat()

G'day:
I was putting Adam Tuttle's htmlDecode() UDF through the approval process just before, and found a daft (and admittedly pretty inconsequential) bug with htmlEditFormat() whilst I was about it.

Things I dislike: rules for the sake of rules

G'day:
Rules are great things to have if there's a point to them. However rules just for the sake of it are just dumb. Here's a dumb rule ColdFusion has.

ColdFusion: I've come to a conclusion

G'day:
This is something that I've been mulling over / worrying about / contemplating for a coupla months now. I find myself poised over the keyboard frequently about to write this increasingly often. And Rob Glover is to thank for making the comment on Twitter that made me think "actually, yeah..."

This is my conclusion. I now believe Adobe is doing more harm to ColdFusion and CFML in general than they are good. And I think it's time - for the benefit of CFML as a language - for them to pull out. There's a few reasons for this.

Firstly, whilst they are "mothership", the language is just not going to go anywhere. As far as I can tell, no-one involved in the Adobe ColdFusion Team actually uses CFML as a matter of course, and I think the entire business unit is completely detached from the community. Worse, what they are doing on a day-to-day basis is Java. Whilst Java is a great language, it's not even remotely the same in intent as CFML is, and - worse - Java is a behemothemic (I made that word up) old juggernaut which works in a completely different way than the spritely languages that compete in the space CFML is struggling to be relevant in. Adobe don't (seem to ~) know how CFML is used, what the target market is, and what they should do with it to keep it relevant.

Secondly... $$$. I guess this makes sense. Adobe are not in the business of making a great language, they're in the business of making money for their shareholders. To do this, they need revenue, and to have revenue, they need to sell licences. Because they're in the software selling business. Unfortunately the people they market CF / CFML to are the people who pay for the licences, and all they need to do is to generate enough smoke, and angle the mirrors in the right way, and the licence-purchasing decision makers will re-up their licences. Especially if - and I think this is where the bulk of Adobe's ColdFusion revenue comes from - the person signing the cheques (dear god, I actually typed in "checks" then, initally) is doing so on behalf of some US government agency, and there's very little oversight on the sort of money they're paying; and what's more important to them is continuity, not innovation.

Thirdly. And this is how I came to this conclusion, remember, so this is the third reason that influenced me to think the way I do: Railo. I've been using Railo since it came on the scene, but only in the capacity of reading the mailing list and testing stuff out. I have never had any of my apps running in production on Railo. This is not slight on Railo, it's just that I have always worked for ColdFusion shops; licences already purchased. But over that time I've seen Railo arrive as the third possibly-viable CFML solution (after ColdFusion and BlueDragon... the New Atlanta one, not the Alan Williamson one, which came along around about the same time as Railo?), and then surpass BD (closed or open) becoming the second player in the CFML market, to now pretty much being the leader in the CFML community. I don't mean in revenue, or in "stature", but in importance. Basically I've gone from not giving a shit what Railo might have to say about CFML, to not giving a shit what Adobe might have to say about it (I never gave a shit about BD, for varying reasons). This is partly because Adobe hardly ever say or do anything sensible / useful about CFML other than when there's a release cycle on, and more recently because what Railo is saying about CFML and the CFML community just makes sense. Whereas everything out of the Adobe stable these days is going more and more heavily on the marketing smoke and mirrors, and is almost entirely without substance.

Fourthly I've been looking at other languages recently. I'm a slack-arse when it comes to forwarding my career prospects: I'm good at CFML and that finds me work. Well has done so far. I'm lucky in that regard (although I will never become a rich person with my work ethic, I at least have a place to hang-out and write code every day ;-). So I've pretty much focused on CFML and enough JS to get by over the last decade. However now that I'm looking, what I do see out there is every other relevant language just does stuff better than CFML does these days. It's a complete frickin' myth that CFML is still this quickest-to-market / rapid-development language. It might be so in the context of "my simple website", like what CFML used to excel at ten years ago, but in the context of doing more than "making it easy to generate HTML", even my superficial knowledge of competing languages reveals that CFML is basically irrelevant in that space now. Now I'm not saying some stuff on a line-of-code-by-line-of-code basis is simply easier to do in CFML, but I really think ColdFusion is lacking the bigger picture here. Plus it just moves too damned slowly to keep up. THat and when they do decide to do new stuff, it's crap like <cflclient> (ColdFusion 11's apparent marquee feature) which seems to be a wizard for writing JavaScript for mobile apps. In CFML. What? Are you lunatics, Adobe?

Update: <cfclient>? Wah?
Someone asked what I'm on about with this mention of <cfclient>. It was mentioned on a slide in a presentation I saw at cf.Objective() of new features coming to ColdFusion 11. There was also discussion of the CF -> Mobile functionality in the same presentation, and again at Scotch on the Rocks. I do not claim any specific knowledge about the functionality other than what's in the public domain via those sources.

The shining light here for CFML though, is Railo. They listen to their developers / their community. They do Railo (and accordingly CFML ~) consultancy, so they know what people on the ground are actually doing, and they enhance then language in ways that will benefit professional CFML developers. They seem to look at what other languages are doing, and consider those features for Railo / Railo's CFML. They keep the language alive and moving. They seem to give a shit about CFML (the Adobe ColdFusion Team seem to be interested in CFML because it pays their salary, and not really beyond that. Well that's my impression).

So here's what I think. Adobe? Give up on ColdFusion and CFML. You're not helping.

And Railo? Screw what Adobe might have done / might be doing with CFML. Take the language as your own (that sounds more melodramatic than I intend it to, but you get the idea).

What do you think?

--
Adam

Another day, another ColdFusion JSON bug (and a Railo bug too, just not with JSON)

G'day:
Well at least this time it wasn't something that caught me out. This one wasted someone else's time.

CFML: getObjectMetadata()

G'day:
This is a strange article, this one. It started off just being a feature request which I was typing into the Adobe bug tracker, but decided to write my thoughts up here, by way of soliciting other people's thoughts too. On re-read just before pressing "publish", I realise the framing for the point is about five times longer than the point itself. Oops. Oh well. It's a slow news day here. It's Monday after all.

ColdFusion has a function getMetadata(),  which can be called on a variety of objects: an CFC instance, a user-defined function, a property, a query. I'm just focusing on on its usage with "objects".

Here's an example of getMetadata() being called on an object:

// Bloggable.cfc
interface {

    public void function g(required numeric x);

}

// Parent.cfc
/**
@hint Parent component
*/
component {

    /**
    * @hint Method defined in Parent
    */
    public void function g(required numeric x){
        return;
    }

}

// Sub.cfc
/**
@hint Demonstrating getMetadata() results
*/
component extends="Parent" implements="Bloggable" {

    /**
    * @hint Method defined in Sub
    * @x A number
    */
    public void function f(required numeric x){
        return;
    }

}

<!--- test.cfm --->
<cfdump var="#getMetadata(new Sub())#">

Stand-alone repro case for that weird interface bug

G'day:
This is a follow-up to the article from yesterday detailing some weirdness I was getting when using Mockbox to mock methods in CFCs which implemented interfaces.

I have no factored-out Mockbox as a factor in this issue. The tangentially-related issues in Mockbox still stand, but I wanted to have a repro case that did not have any third party code in it. And now I have one.

Reserved words? Or not? Make up yer mind

G'day:
What a busy CFML day today (ed: it's now the following day... I didn't get this finished last night) has been. And it seems it just keeps on giving. Here's a quirky one that has bitten me on the butt before, and has now bitten the butt of someone on Stack Overflow too.

CFML: Floating point bum-biting: Railo version (OpenBD just errored)

G'day
Just FYI (and because someone asked), these are the results of the code I used for last night's article on some floating point weirdness, when run on Railo. Code:

<cfoutput>
<cfif structKeyExists(server, "railo")>
    server.railo.version: #server.railo.version#<br>
<cfelse>
    server.coldFusion.productVersion: #server.coldFusion.productVersion#<br>
</cfif>
<hr>

<cfset theValue = 1.15>
<cfset theMultiplier = 100>
<cfset theDivisor = 5>
<cfset theProduct = theValue * theMultiplier>


Default<br>
#theProduct# % #theDivisor# = #theProduct % theDivisor#<br>
#theProduct# / #theDivisor# = #theProduct / theDivisor#<br>
#theProduct# \ #theDivisor# = #theProduct \ theDivisor#<br>
<hr>

Precision<br>
<cfset thePreciseProduct = precisionEvaluate(theValue * theMultiplier)>
#thePreciseProduct# % #theDivisor# = #thePreciseProduct % theDivisor#<br>
#thePreciseProduct# / #theDivisor# = #thePreciseProduct / theDivisor#<br>
#thePreciseProduct# \ #theDivisor# = #thePreciseProduct \ theDivisor#<br>
<hr>
</cfoutput>

CF Live

G'day:
Hey, in case you've not heard, Russ Michaels (who also runs CFMLDeveloper, who host my code) has launched a site "CF Live".

isValid(). Groan

G'day:
Some things (OKOK, most things...) just piss me off.

ColdFusion / Railo WebSockets survey results

G'day:
I didn't get much interest in the "ColdFusion / Railo WebSockets: do you use 'em?" survey as mentioned in my article the other day. Not to worry. I think that speaks for itself in a way: plenty of people looked at the article, but not so many figured it was worth their while / interest in filling out the survey.

I only got 24 responses, but here's the breakdown of those I got.

ColdFusion / Railo WebSockets: do you use 'em? (survey)

G'day:
I've just started looking at the technical side of the WebSocket offering in ColdFusion 10. It's an interesting-looking technology, but I'm just wondering what real world practical applications people are putting them to. I've seen plenty of "chat demos" and the like, but nothing that one would really want to do in the real world. So I'm just gauging the community's usage of them.

As far as I can tell Railo doesn't have WebSocket supprot built-in, but there's a WebSockets Extension. I've not tried it. But I will at some stage.

Anyway, I want to know about your usage of WebSockets, or also if you've not used them and/or have no interest in them at all. I've knocked together a quick survey (four questions). If you fancy filling it in: good for you, and thanks. If you feel like re-sending the Twitter message I will send out advising of said survey, that'd be cool too: the more responses the merrier.

Cheers.

--
Adam