That's it: no more ColdFusion_12 or CFClient

G'day:
You might or might not have twigged that I was running the @CFClient and @coldfusion_12 Twitter accounts. They were parody / pisstake / satirical account gently prodding the general business approach of the Adobe ColdFusion Team.

Well, anyway, someone filed an official complaint about them, so Twitter has closed them both down.

Brad tries <cfclient>

G'day:
This is just a heads-up. Brad's having a go at <cfclient>: "My First Foray Into CFClient". He's blogged about his initial challenges, and it makes for interesting reading.

In an epicaricatic sort of way.

Book review: Adam Tuttle's newest book

G'day:
Adam's been busy recently. You'll've heard about his new book "REST Web APIs: The BookREST Assured: A Pragmatic Approach to API Design" which is being released soon - I'll have a review up and a competition to win a copy next week - but he's also released the first book dedicated to ColdFusion 11's newest marquee feature: CFClient.

I know I have derided CFClient a lot, but it does have its good bits, and Adam has worked through them all and put a fairly accessible book together. Granted it's not very long, but for something that focuses on a single tag, I think that's fair enough. It's free and open source, so you should go get it, and give it a read. It might make you think again about whether or not to use CFClient. I have to admit it did give me pause for thought.

Go grab it from it's official website now (it's just a PDF): "CFClient The Good Parts".

I think Abram Adams (of trycf.com fame) said it best in his review when he said:

I felt like I was looking into the minds of Adobe engineers

It's exactly this attention to detail Adam Tuttle captures in this latest book.

CFML doyen Mark Drew had this to say:

I have been looking everywhere for an in-depth look at the useful features of the cfclient tag and I have to thank Mr Tuttle for providing it!

I am not good at reviews but I should say that this is not only The Good Parts, it is also the definitive guide.

5/5

I'll get back to you about the REST book next week (here it is: "Book review: REST Web APIs: The Book (win a copy here)"). The CFClient book'll keep you going until then.

Cheers.

--
Adam

Just for Andy Allan

G'day:

@DAC_dev I wonder how often I can find my way into your blogs posts simply by tweeting "CFClient" at you...
— Andy Allan (@fymd) October 30, 2014

More times that you probably thought when you said that, I wager.

--
Adam

Go and vote, pls

G'day:
Sorry for the silence recently... my life is getting very... complex of late.

Anyway, Adobe are playing at silly buggers with a bug that they're dragging their heels about, and they are saying it needs more votes to get more attention.

It's to do with CFClient, but just on principal, I've voted for it because they need to stop with these sloppy implementations. Hopefully you think likewise, so will go vote for this: "queryExecute params not working in mobile".

Sloppy, inconsistent implementations ought not need votes to get fixed. Adobe ought to have more pride in their work. But if instead they need votes... let's give them votes.

Cheers.

--
Adam

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

CFClient: pardon my ignorance / thought exercise / advice solicited

G'day:
This is a lazy-arse article, but it's Sunday and I am suffering from post-conference malaise. So... bad luck if you were after something incisive / thoughtful.

It perhaps might be thought provoking though.

And at least it's short. Once I get on with it.

ColdFusion 11: what <cfclient> compiles down to

G'day:
One of Sean's comments on another article ("ColdFusion 11: <cfclient>... how does normal CFML code and <cfclient> code interact?") got me thinking:

This doesn't surprise me at all: cfclient generates JS that runs in the browser; outside cfclient, you have regular CFML that runs on the server. You can't expect them to know about each other. This is like the frequent RTFM questions on SO about using CFML variables in JS!

Whilst I don't think it's quite so painfully obvious as Sean would like us to think, he does raise a reasonably good point. I'll reproduce my response too (which is a reasonable prelude to this article):

I suppose it depends how the JS is generated. Is it extracted from the file at compile time and created? Or is it compiled in situ as part of the compiled class, then at runtime JS is generated from it and returned to the browser? I'll need to check that (I suspect it's done at runtime).

If it's done at compile time, then, yeah... there's no way initialising any variables referenced in the "server side" part of the source code which are also needed in the client side part of it, as the values won't be known.

If it's done at runtime, it should be easy enough though? Same as how one might do it with CFML writing out a <script> tag, containing JS variables which have CFML variable values as their values?

If it's all done at compile time, I don't see why <cfclient> is a *tag* as opposed to a different file type (.cfjs or something), as there's no merit in having both server-side (outwith the <cfclient> tags) and client side (within them) in the same file. Because never the twain shall meet, as you point out.

Looks like I have another blog article to write on the topic...

List of articles on Adobe ColdFusion Forums for Anit

G'day:
This is not an article, per-se, but just a list of links for Anit, I'll then be posting the link to this on Twitter. The links below are simply reproductions of my existing blog articles on the given topics, and do not represent new writing on my part.

Anit, these are the questions I wanted to ask the Adobe ColdFusion Team about some features of ColdFusion 11. As you suggested, I have posted them on the Adobe ColdFusion Forums. Here are links to the forum articles.

• ColdFusion 11: custom serialisers. More questions than answers
• ColdFusion 11: <cfclient> in the context of the CFML language, not the tooling
• ColdFusion 11: <cfclient> seems to require /CFIDE to be available
• ColdFusion 11: <cfclient>... how does normal CFML code and <cfclient> code interact?
• ColdFusion 11: <cfclient> ports a lot of CFML functions to JS
• ColdFusion 11: allowedextforinclude functionality has changed. But the docs haven't been

Thanks mate.

--
Adam

ColdFusion 11: <cfclient> ports a lot of CFML functions to JS

G'day:
I will start this article - which won't be a long one - by stating I am an adequate JavaScript developer, but I am by no means an expert. I'm at that stage wherein I'm au fait with the syntax and the nuts and bolts of writing OO-esque JS, but I don't spend enough time doing it to know the minutiae of "best practice" and don't automatically know the differences between the "best" way of doing something, and just "a way of doing something". Hence this article asks a question, rather than making any concrete statements.

ColdFusion 11: <cfclient>... how does normal CFML code and <cfclient> code interact?

G'day:
Another quick one. I'm raising these quick-fire questions here because Adobe have declined to suggest a better place to raise them, other than as comments on one of their blog entries. Well that was Ram's suggestion (which I don't think is terribly-well thought out). He declined to react to my suggestion that the Adobe ColdFusion forums might be a good place. Anit suggested Twitter or just emailing him, but I think there'd be public interest in this stuff, so don't want to resort to email.

As I'm the master of what goes on on this blog: I'll clutter this thing up.

ColdFusion 11: <cfclient> seems to require /CFIDE to be available

G'day:
This will be a short one... I just want to trot out various observations I make about <cfclient> as I make them. I don't want to waste too much effort on it.

I also feel a bit dirty round about now... I'm about to use a <cfform> tag.

As should everyone, I do not expose /CFIDE to the outside world. This is a terrible vector for security vulnerabilities. One that Adobe seems to be dragging its heels about resolving once and for all ("Isolate the /CFIDE/scripts directory from the rest of /CFIDE" (3732913)).

So when I'm using <cfform> (which is only ever when I am writing example code like this), I need to redirect ColdFusion to look in my isolated directory which just has the script stuff in it:

ColdFusion 11: <cfclient> in the context of the CFML language, not the tooling

G'day:
This article could end up being a complete waste of space, as I am operating under more real-world re-interpretation of the raison d'être of <cfclient>, as described by Ram:

ColdFusion [11] has added support for client side CFML (<cfclient>) and this code is translated to JavaScript

Mike Henke has pointed out that the first part of this "CF11 has added support for client-side CFML" is actually bullshit (my wording, not his):

"ColdFusion Splendor has added support for client side CFML" is probably phrased wrong and gave me flash backs to VBScript or CFML running in the client browser.
Maybe this is better verbiage. "ColdFusion Splendor has added support for CFML to generate JS".

Because... there's not such thing as "client-side CFML". That would imply CFML actually running on the client (ie: the browser, or the mobile device, as is the target of <cfclient> as a concept). This is absolutely not true. I know Ram went on to qualify what he meant there, but the messaging from Adobe on <cfclient> has been inaccurate. Possibly I think to the point of actual misrepresentation (in the legal sense, I mean).

What <cfclient> does is... convert CFML code to JavaScript. So let's look at that idea.

<cfclient>: worrying discussion

G'day:
The more I read about <cfclient>, the more the alarms bells change from tending towards air raid sirens, and more like the horns of the Rapture (or if you prefer). Here's a series of comments on the Adobe ColdFusion Blog about how looping over arrays will "work" in <cfclient>.

ColdFusion: <cfclient>: from a pig's ear, a silk purse could rise?

G'day:
I've got two muses today: Dan Fredericks who had a go at me yesterday about being a big meany about <cfclient>: and Sean for giving me the "penny-drop" moment. I think the concept of <cfclient> is salvageable. Just the concept. Not the implementation. Nuh-uh.

Firstly Dan had a half-way decent point, as articulated on Twitter:

@boyzoid @dfgrumpy http://t.co/acSqV30m2N Don't think crushing an alpha tag is helpful, feedback would be better..agree?
— Dan Fredericks (@fmdano74) November 5, 2013

And the conversation went on from there (you'll need to look it up). In theory Dan is right: constructive criticism is better than criticism. However I really don't actually see anything that's good to a useful degree about <cfclient>. Otherwise I would have mentioned it. Here's the best constructive criticism I can muster for <cfclient>:

<cfclient>

G'day:
CFSummit 2013 started today - I'm quite jealous of everyone who's there btw - and Adobe opened with a variation on their keynote they used at cf.Objective(), SotR and CFCamp, which covers some of the new stuff in ColdFusion 11. And, naturally, they spent some time on <cfclient>. And then if I'm reading my Twitter feed and the schedule correctly, after the keynote they did another presentation looking more closely at the technical side of new features, including some <cfclient> code. And there was an eruption of Twitter traffic on the topic of <cfclient>. Personally, I think the whole idea of <cfclient> is a blight on CFML, and demonstrates Adobe have learned very little since those "heady" days of <cflayoutarea> and <cfpod>.

CFCamp: Rakshith's Adobe ColdFusion Keynote: notes of my own

G'day:
I fired most of this stuff out on Twitter as it happened, but here's an aggregation of some things that crossed my mind during Rakshith's Adobe / ColdFusion keynote at CFCamp.

First things first... I was very relieved that there was a big chunk of this presentation showed actual code. This is a huge improvement over cf.Objective() and Scotch on the Rocks wherein the main Adobe presentations were aimed at IT Managers rather than developers, and was just promotional material with very little substance. Rakshith's presentation today was really good. This is not just my opinion, everyone else I talked to said the same thing.

Hang on... what did Rakshith say?

G'day:
I was writing the previous blog article about improving thread syntax, and suddenly went... hang on... what? What did you say, Rakshith? And I dug back into his blog article from yesterday "ColdFusion: News and Updates from Adobe"...


This was buried half way down the article:

There are quite a few language improvements such as [...] member functions that are already a part of the upcoming version

What?! Member functions? COOL.

</cfform>

G'day:
This is gonna be quick as I'm a) hungover (yeah... 10pm and I'm still hungover from y/day!); b) had a few medicinal beers to try to deal with (a); c) absolutely nackered, and want to just vegetate and watch a DVD.

I want to actively participate in the demise of <cfform>, <cflayout>, <cfajax> and the like as "a thing" that CFML developers might accidentally use.

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