CFScript 2.0 follow-up

G'day:
A few days ago I put up this article: "CFScript 2.0?". At that juncture I was just soliciting input from the community. It's worth reading the comments if you're not up to speed with them. Especially from a Railo perspective as Micha, the chief engineer, offers his thoughts. It's a pity we don't get similar input from Rupesh on this, from a ColdFusion perspective.

I think it's been favourable enough to warrant enhancement requests to the vendors, which I have now raised: RAILO-3199; ColdFusion: 3822362.

Go have a vote (one way or the other! Even if you disagree, your input is valuable), and put your oar in and let your vendors know what you want them to do.

Cheers.

--
Adam

<cfmodule> in CFScript: does this behaviour make any sense?

G'day:
I'm in the process of documenting all of CFScript. Well: how to effect all of CFML's functionality in CFScript, really.

Today I'm looking at how <cfmodule> is handled in CFScript. Railo and ColdFusion implement it differently (although Railo also implements ColdFusion's implementation for sideways compatibility).

And I am puzzled with the way ColdFusion handles it.

CFML: <cfchart> / <cfchartseries> bug details for Adobe & Railo

G'day:
I need a place to put some pictures for a coupla bugs I need to raise, so I'll slap 'em in here and point Adobe & Railo at them. There's not much of interest going on below the fold, so don't bother reading it if you have something better to do.

Railo: CFC-based custom tags

G'day:
As a baseline for some more research I am about to do, I wanted to get up to speed with how Railo implements CFC-based custom tags. I had read their blog articles about them:

• CFC-based Custom Tags by Example - Part 1
• CFC-based Custom Tags by Example - Part 2
• CFC-based Custom Tags by Example - Part 3

But it hadn't completely "sunk in" for me just by reading. I decided to work from top to bottom of the technology, demonstrating to myself all the various facets of custom tags and how they are implemented via a CFC. And here it all is...

Don't advertise yourself as a CFML website

G'day:
Do you know what the first thing I do when I see a website which uses .cfm file extensions is?

Cool (I think?) Railo can have dynamic case values

G'day:
Thanks to NicholasC from IRC for putting me onto this. Apparently in Railo, one can have dynamic values for case values in a switch/case!

I'm sick of vendors screwing up CFML

G'day:
AAARRRGGGGHHHH!!!

How hard does any of this need to be? I'm posting this here and against the Railo bug report I started typing it into "CFHTTP accept callback UDF to report progress" (RAILO-3131). As it's stroppy, Micha should feel welcome to delete it from Jira. However it's staying here.

Different bugs in each() function in each of Railo and ColdFusion

G'day:
A quick one. I was investigating a bug in Railo, detailed in "Arguments - Struct or Array", and as well as verifying the bug in Railo, I found a different one in ColdFusion.

2

G'day:
I'm frickin' lousy with dates (as in "calendar", not as in "romance". Although the same applies, from memory ;-). Well: remembering dates is never a problem, but remembering what the current date is is something I'm not so good at. I forgot to touch base with my big sister on her birthday over the weekend... and there's another anniversary on the same day.

I've been doing this bloody blog for two years now. Which is approximately 23 months longer than I expected it to last.


Last year I gave you some stats ("1"). I'll try to do the same now.

• I've now published 750 (this'll be the 751st) articles. I still have about a dozen in progress. The same ones as last year, funnily enough. The topics just don't have legs, I think.
• And the word tally is now up around 600000 words. So in the second year I didn't write quite as much as the first year (350000), but spread over more articles (428 in the last 12 months vs 322 in the first year).
• I've had another 3000 comments since the previous year's 2000. That's pretty cool. Thanks for the contributions everyone. Often the comments are more interesting than the articles, I find.
• Google Analytics claims I've had 86000 visitors over the last year (up from 25k in the first year). So this thing is getting more popular. The average per day is 230-odd. It was around 120/day in year one. It's still not a huge amount of traffic, but I guess my potential audience is pretty small too.
• The busiest day in the last 12 months was 5 March 2014, with 593 visitors. That was towards the end of the isValid() saga, with this article: "ColdFusion 11: Thank-you Carl, Mary-Jo, many other community members and indeed Rupesh", and a click-chasing one entitled "CFML is dying. Let's drop it off at Dignitas". Looking at the analytics, that was the bulk of it, plus I was writing a lot about new features in ColdFusion 11 around about then, which boosted things. That was also my biggest week ever, by quite a margin.
• The most popular article last year was the one about me migrating from "ColdFusion Builder to Sublime Text 2". That's had 2200 visitors. The next most popular were as follows:
  • Arrays in ColdFusion (part 1)
  • 212 untriaged ColdFusion 10 bugs
  • Arrays in ColdFusion (part 2)
  • ColdFusion vs JSON. How to make a developer cry
• The most +1'ed article was "I am one step closer to being unshackled from ColdFusion". It's interesting that that was the one that people liked the most. It had 13 +1s. Most articles get none or maybe one, so that's quite a lot.
• Last year I worked out which article had the most comments. I have no idea how I did that, and I can't be bothered working it out again. So erm... that'll remain a mystery.

I've blogged a lot about ColdFusion 11 during the year... what with it being in public beta and then being released. I've also compared its functionality to Railo's equivalents. I've shifted my primary dev platform at home to Railo now. I've done a lot of JavaScript over the last 12 months (I've spared you most of the detail), but haven't progressed in other languages as much as I'd like to. That's my mission for the next year.

I battered Adobe a lot about how they (don't) handle their bugs. I will continue to do this. They're long overdue for an updater to ColdFusion 10, for one thing; plus we should have had at least a coupla small updates to ColdFusion 11 by now.

The biggest shift in my coding practices in the last year has been down to reading Clean Code, and adopting a lot of its suggestions. My code is better for it. I've got my colleagues Chris and Brian to thank for this... both the encouragement to read the book, but also keeping at me about it. Sometimes to great irritation on my part. If you have not read that book: do so. Especially if you're either of the two members of our team who still haven't read it. Ahem.

Another thing I've been fascinated with this year gone is TestBox. I love it. I am looking forward to shifting off ColdFusion 9 at work so we can start converting our MXUnit styled tests to BDD ones. Brad and Luis are dudes.

I've bitched a lot about Stack Overflow, but contrary to what I threatened ("Not that it will really matter in the bigger scheme of things..."), I still answer questions there every day (if I can find questions I can answer, that is).

Railo continues to rock. As do Gert, Micha, Igal from Railo. They really have done brilliant work keeping CFML alive and interesting.

A bunch of people have motivated me to write this year... it's too difficult to pull out a list of the main miscreants, but Sean would be the top. And the list of my various muses (or adversaries!) is - as always - on the right hand side of the screen, over there.

Gavin deserves special mention, as he very kindly tried to raise money to get me across to CF.Objective() ("Shamelessful plug"), but we had to kill that plan just as it was getting started ("Do not sponsor me to go to CF.Objective()"). But happily Gert stumped up with a ticket at the last minute ("Well that was unexpected"), so I made it anyhow. I really am taken aback by you guys. Seriously.

And of course Mike from CFCamp paid for my entire conference last year too ("CFCamp 2013"). That was amazing. And I mean both Mike's generousity, and the conference itself. Go to it this year if you can: CFCamp.

Ray's done most of the work for ColdFusion UI the Right Way, but I've helped out a bit. I'm glad we got going with that project.

Thanks for your participation in this blog, everyone. If you weren't reading it or commenting on it, I'd've chucked it in. But you keep coming back. Cheers.

Oh and let's not forget: <cfclient> sucks arse. And I can tell that without using it, Dave Ferguson ;-)

--
Adam

Both ColdFusion and Railo make an incomplete job of validating email addresses

G'day:
A question came up on StackOverflow just now "new to coldfusion. is there any function that defines Email is typed correctly" (how hard, btw, is it to give a coherent title to one's question? [furrow]).

My initial reaction was along the lines of "RTFM, and if you had, you'd see isValid() validates email addresses". However I also know that isValid() is very poorly implemented (see a google of "site:blog.adamcameron.me isvalid" by way of my findings/rantings on the matter).

So I decided to check how reliable it actually is.

The rules for what constitutes a valid email address a quite simply, and a laid out very clearly in various RFCs. Or if one can't be bothered doing that (although the engineers & Adobe and Railo should be bothered), then they're fairly comprehensively defined even on Wikipedia: "Email_address (Syntax)". I found that page by googling for it.

Anyway, I won't bore you by replicating the rules here, but I wrote some TestBox tests to test all the rules, and how isValid() supports them. The answer to this on both ColdFusion (11) and Railo (4.2) is "only to a moderate level". This is kinda what I expect of the Adobe ColdFusion Team (this is the level of quality they seem to aim for, generally, it seems), but am pretty let down by the Railo guys here.

I won't reproduce all the code here as it's long and boring, but it's on GitHub: "TestIsValidEmail.cfc".

Anyhow, the bottom lines are as follows:

ColdFusion:

Railo:

Railo did slightly better, but ran substantially slower (running on same machine, same spec JVM).

I hasten to add that 50 of those tests were testing the validity of individual invalid characters, so that blows the failures out a bit (given they pretty much all failed). But both also failed on some fairly bog-standard stuff.

It's seriously as if it didn't occur to the engineers involved to actually implement the functionality as per the published specification; instead they simply made some shit up, based on what their own personal knowledge of what email addresses kinda look like. This is a bit slack, I'm afraid, chaps. And would just be so easy to do properly / thoroughly.

NB: there are rules around comments in email addresses that I only gave superficial coverage of, but I covered all the other rules at least superficially in these tests.

---

One new TestBox thing which I learned / noticed / twigged-to today... one can write test cases within loops. One cannot do that with MXUnit! eg:

describe("Tests for invalid ASCII characters", function(){
    for (var char in [" ", "(", ")", ",", ":", ";", "<", ">", "@", "[", "]"]){
        var testAddress = "example#char#example@example.com";
        it("rejects [#char#]: [#testAddress#]", function(){
            expect(
                isValid("email", testAddress)
            ).toBeFalse();
        });
        testAddress = '"example#char#example"@example.com';
        it("accepts [#char#] when quoted: [#testAddress#]", function(){ 
            expect(
                isValid("email", testAddress)
            ).toBeTrue();
        });
    }
});

Here I loop through a bunch of characters, and Here for each character perform two tests. This is possible because testBox uses function expressions for its tests, whereas MXUnit uses declared functions (which cannot be put in loops). This is not a slight on MXUnit at all, because it predates CFML's support for function expressions; it's more just that I'm so used to having to write individual test functions it did not occur to me that I could do this in TestBox until today. I guess there's nothing stopping one from writing one's test functions as function expressions in MXUnit either, that said. But this is the encouraged approach with TestBox.

Nice one, TestBox.

Anyway, this is not helping me prep for my presentation tomorrow. Give me a ballocking if you hear from me again today, OK?

--
Adam

Looking at the bugs I've raised in Railo

G'day:
I've always banged on about how Adobe deal with ColdFusion bugs, and what my opinion is of this. I have not - to date - cast my magnifying glass in Railo's direction...

CFML enhancement: alternate function expression syntax; "lambda expressions"

G'day:
In this article I just want to - hopefully - extend the audience of a conversation taking place on the Railo Google Group ("Railo 5 lambda expressions"). Even if you're a ColdFusion developer (ie: only use the Adobe product, not the Railo one), this will still be relevant to you as Railo generally leads CFML development these days, so innovations they make will - perhaps some time in 2016 - make it into ColdFusion's dialect of CFML.

There are a lot of good brains in the CFML community, and I hope to encourage some more of them to join this discussion.

Doing a Railo silent install

G'day:
Yesterday I questioned Railo needing an admin password ("Admin passwords shouldn't have a min length requirement") on an existing ticket... one I am surprised to see was raised close to six years ago and seemingly has yet to be triaged by Railo. My comment was thus:

I'm getting fed up with being forced to put a password in every time I install a new Railo install. Because for every single occasion I've installed Railo, I have not needed the admin to have a password because machine security is handled separately, making this password a complete waste of time.

We are on the verge of migrating several hundred CF9 instances to Railo, and this is going to be a problem for us.

It's good you provide password control. It's poor that you attempt to decide for me whether I want to use one or not.

Hanging on to outdated knowledge: don't

G'day:
This has taken me a few weeks to sort out - I started on it well before CF.Objective() - but I think I've finally stared at log files for long enough to come up with my conclusion.

I'm working with a client's codebase. A lot of it was written a) a long time ago when come CFML coding practices were not as fleshed-out as they are now; b) initially on CFMX7 (which, of course, comes with penalties of its own). Their ColdFusion install has moved on to version 9, but some of their coding practices still languish in mid-last-decade.  Part of this is decision-makers arriving at a conclusion as to how ColdFusion does things based on how it did things in ColdFusionMX, and never re-assessing their position to see if it still had merit. Their position was never re-assessed partly because no-one ever questioned it. It was just the way things were done. Times and personnel have changed, so now questions are being asked. I hasten to add I don't think is at all unusual that this is the case, and often approaches stay static until someone new shows up and starts questioning stuff. We've had this @ work in the past, and I've noted it ("Hungarian Notation").

You might remember a while ago I had a look at one of CFML's favourite tropes: evaluate() is bad not least of all because it's slow ('"evalulate() is really slow". Is it now?'): that trope ends up being mostly bullshit. So one can't just settle in and accept what once might have been true will thereafter always be true.

The trope I'm looking at here is that on CFMX7 performance penalties in creating transient objects were such that they weren't a viable coding construct. The only feasible way of using object instances were as singleton's created with ColdSpring during application start-up, and using those as services throughout the life of the application. Beans were an inviable notion, so they must not be used.

Object creation in older versions of CF certainly wasn't an efficient process, I agree with that.

London Railo Group: Gert's over

G'day:
A very quick news announcement. There's a London Railo Group meeting next Tues (May 27), at Pixl8. Gert from Railo is going to be there, and he will be doing his "Railo 5.0 and Beyond" presentation from CF.Objective().

Difference between Railo and ColdFusion regarding annotating CFCs

G'day:
Yeah, I'll write some stuff up about CF.Objective() shortly, but I need to plan that a bit more before I put pen to paper. This is a quick no-brainer (so playing to my strengths ;-).

CFML: Advice for Adobe re Railo

G'day:
I was a bit surprised to read this this morning:

The sole reason for adding this functionality was to make it easy for the frameworks to define the datasources from within the framework without going through the administrator. If one has to go through the administrator to get the encrypted password, that defeats the whole purpose. You can very well keep it defined there. So why define it in the application at all? 
As far as the railo approach is concerned, I don't know the details of their implementation. As Hima said, after putting the encrypted string, your code would not be portable because encryption will be installation specific. In case they are claiming the encrypted string is portable, it would mean that they are encrypting it with a static key same across all installation which is not at all a secure practice.

I dunno if Rupesh was meaning "in general" or just "in the context of this topic".

However, to be clear, the very first thing Adobe engineers - especially senior ones who seem to make decisions - should be familiar with is how Railo does stuff, and what features it has. In the context of this specific issue, as soon as I compared ColdFusion's functionality unfavourably with Railo's equivalent functionality, Rupesh should have spun-up his Railo instance and had a look. That's if he didn't already know about it.

As Adobe was playing catch-up with this feature, all the devs involved in it should have already gone over the feature in Railo and used that as a basis to make the CF implementation at least as good, if not better.

I'd be fine if Rupesh had said "yeah, we looked at that and didn't think it had merit because [reason here]", but it sounds like he didn't even know about it.

It would not surprise me if Rupesh doesn't even have Railo installed.

Adobe have to be all over what Railo is doing. They should be members on their mailing list (not just lurking, but actively discussing stuff), they should be checking out all the new features (and bugs!) as soon as they come in, and in general know exactly what the opposition is doing. Not least of all because they could learn a thing or two from Railo's implementation of things.

Obviously it cuts both ways, but I already know the Railo bods are fairly familiar with how ColdFusion operates.

When I read stuff like this, the silo of naïveté that the Adobe team resides in that I have a mental image of gets slightly higher, and the walls slightly thicker.

--
Adam

Defining datasources in Application.cfc

G'day:
This feature of both Railo and now ColdFusion hasn't been talked about as much as I think it should have been. Both CFML platforms - as of 4.1 in the case of Railo, and 11 in the case of ColdFusion - allow one to define entire datasources in Application.cfc. Not simple reference to existing DSNs created in CFAdmin (or via the Admin API, if you've ever tried that), but defining the whole thing right there in Application.cfc.

ColdFusion REST services and restSetResponse() revisited

G'day:
Ages ago I wrote an article lamenting the way restSetResponse() has been implemented: "restSetResponse() requires the method to be returntype void. What?". At the time I was looking at how it was instrumental in how "ColdFusion takes something that should be easy and makes it hard" in the context of exception handling. That's slightly edge-case-y, I'll admit it.

But I think I've encountered a standard-operating-procedure situation today which demonstrates the implementation of restSetResponse() is not fit for purpose. Literally: it's not fit for the purpose it has been implemented for.

Today has been a frickin' frustrating day. I sat down to do another backbone.js tutorial ("Backbone.js Beginner Video Tutorial"), having finished "Anatomy of Backbone.js" and "Anatomy of Backbone.js Part 2" from CodeSchool yesterday. I started watching the video @ around 10am, and was inspecting the code on Github at 10:20am. At that point in time I figured I had better knock together the server-side code the tutorial will need: basically some RESTful web services for get-all, get, create, update and delete. Easy. I set out to implement this code using Railo, and had it all operational by 11:30am. At that juncture I started reading up on exactly what I should be returning for the less-obvious situations: the response for a GET is obvious: return the object(s) concerned. But what do I return for a POST? And a DELETE? So I started reading the HTTP spec ("Hypertext Transfer Protocol -- HTTP/1.1 - 9 Method Definitions"), which explained it all clearly.

One interesting thing I read on Stack Overflow which had me going "oh yeah! (duh)", was in answer to this question:

However I am wondering what should be the HTTP status code is the request sent by the client is valid (DELETE mySite/entity/123) and the entity to delete does not exist.

Because I was facing the same question (and with GET operations too). The answer is the very obvious:

In that case, the service should return an HTTP 404. Strictly speaking, a DELETE or a GET request for a resource that does not exist is not a "valid" request - ie. the client should not re-attempt that request because it will never succeed... The HTTP protocol defines 2 categories of problems - those with a 4xx status code, where the client must modify the request before retrying it, and those with a 5xx status code, which indicate that the service ran into trouble and the client should/could retry the same exact request without changing it.

As I'm perpetually wont to say to people who marvel that REST is some kind of wonderous thing... it's not. It's just "making HTTP requests". We do this every day in our browser. REST requests are no different. So if a resource doesn't exist... 404 the request.

Official word from Adobe PSIRT re Heartbleed and ColdFusion

G'day:
Adobe have completed their analysis of the Heartbleed issue in regards to their products, including ColdFusion, and have offered some guidance: "Heartbleed Update".