CFML: Response for Russ

G'day:
I feel like writing more in response to Russ than Twitter messaging will sensibly allow, so am doing a quick blog article instead.

The context is as follows:


Thread for blog article
Note that the RT's of Matt's messages aren't quite in the correct order, but as his Twitter account is "private" (that was easily circumvented ;-), I cannot include them inline in a custom timeline. But the gist of the exchange is preserved.

Right, so I feel the decline of CFML as a language is mostly down to Adobe's stewardship of it. There are a few factors here:

Request for clarification on some stuff from Adobe

G'day:
I've encountered some questions regarding the recent update, and have questions of my own... and I don't know the answers. So I'm gonna raise 'em here and bring 'em to Adobe's attention and see if we can get some answers. It's nothing major, and for once not a gripe (well... not on the scale that I often gripe, anyhow...).

ColdFusion Builder comes to Linux

G'day:
Real quick... this morning Matt Gifford blogged "ColdFusion Builder Linux Support", observing:

Many developers have been asking for ColdFusion Builder support for Linux for a long time, [...]

Initially reported in 2011, “ColdFusion Builder 2 Won’t Run Under Linux” (bug #2832512 ) has been commented on by a fair number of people (24 is a fair number in my book), but sadly the ticket has been closed and the reason marked as “not enough time”. Say what?

However...

Follow-up: ColdFusion support for OSX 10.9 - fixed

G'day:
Very quickly... I've talked about this twice:

• "So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10"
• "Adobe backtracks on no-support for ColdFusion 10 on OSX 10.9"

Pleasingly... this issue (3653076) is now marked "fixed/to test" on the bug tracker.

Adobe ColdFusion 10 docs now-community maintainable

G'day:
This is good news. I have just been able to "fix" an entry in the Adobe ColdFusion 10 docs!

CFSummit: interesting ColdFusion 2016 stuff

G'day:
Not that I was at CFSummit, but thanks to Tony Junkes, I saw some interesting slides about ColdFusion "2016" (yeah, the next version, not 11) which can only lead one to speculate...

But first a gripe (hey, this is me, remember). Dazzle? Are you trying to make a mockery of ColdFusion, Adobe? This is like some programming newbie who gives themselves the handle "ProgrammingNinja!" or something. It's not up to you to decide how cool you are; it's up to the audience around you. Rethink that bloody name to something less self-aggrandising. And less like something out of TAoPQotD.

Anyway, the interesting stuff...

Road Map

(yeah, sorry, the links are gonna be links to the photos of the slides that Tony took sorry).

Here we have (time to get my table-based layout skill ready):

Future of the web - vertical			Areas
Mobile			Enterprise Mobility
			Responsive Multi Screen Content
Modernized Platform			High Performance Runtime
			Modular Nimble Engine
			Enterprise Class Package Manager
			Language Revamp
		Horizontals
Peformance		Security		HTML5

OK, so I'm going to ignore the mobile stuff as it'll still be as wrong to be doing it in ColdFusion 2016 as it is in ColdFusion 11, so I simply don't care.

Modular nimble engine

But "modular nimble engine" sounds interesting. Well forget "nimble": that's marketing-speak. But very pleased they're modularising things. But I wonder to what extent? This conversation has done the rounds a lot of times, and I've posted my own take on it as well: "Survey Results: ColdFusion Modularisation". It can only be a good thing though. ColdFusion has become such a cruft-filled monster that it's time it shook some stuff out of the core. I'm all for leaving stuff like <cfform> and <cfclient> as deprecated options, but they should not be part of the core install. People can install them if they want them using the...

Enterprise class package manager

Here's Tony's photo of the slide (I'll spare you my design skills this time). Cool! Hopefully this is like Ruby Gems or Node.js's NPM system (not that I've used the later... I've not touched node.js, but I've heard great stuff about NPM). It's high time for this, and something people have been clamouring for. It seems to have all the key points:

• A portal/registry to list all packages available
• an organization (excuse my ghastly American spelling... I'm quoting this) - a custom package registry
• CF Developers - easily contribute to this registry
• info about package exposed as a REST webservice
• Configure multiple registry URLs

That sounds... perfect. I guess the "Organization" bit is like a sub-registry. So Adobe will maintain an official one, but people can also maintain their own ones? Say for example Ortus want to have BoxManagerBox or something for all their... boxes. Seems reasonable.

Language revamp

(Tony's first photo; second photo; third photo).This is a monster. Check out all the bullet points:

• Focus on optimized performance on JVM
• Breaking backwards compatibility
• Anything with quotes is a string, scope search
• Increased support for OOP - retain simplicity
• Tighten interface implementation
• Collection datatypes
• New logging framework
• Create WAR and deploy anywhere
• Image manipulation revamp
• Extending the language
• Concurrency
  • Existing support - CFTHREAD and CFLOCK
  • Synchronized functions and blocks
  • Concurrent data structures
  • Atomic variables and non blocking IO
  • Inherently concurrent - Actor model

What a mountain of stuff!

Adobe backtracks on no-support for ColdFusion 10 on OSX 10.9

G'day:
I mentioned this the other day: 'So there won't be support for OSX 10.9 "Mavericks" on ColdFusion 10'. I just checked the bug tracker, and ticket 3653076 has now been marked "To Fix". Hopefully they mean "for ColdFusion 10" (and, realistically, they should fix it in CF9 too, as it's still a supported version of ColdFusion), not just for ColdFusion 11.

Good work to two groups of people:

• the community, for rounding on this issue and making their voices heard. The ticket's only existed for three days, but it's got 33 votes and 20 comments. That's very active for a ColdFusion issue;
• the Adobe ColdFusion team for seeing sense in this matter.

Yay everyone!

--
Adam

<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.

Well - like it or not - it's open source now

G'day:
I was awake at 4am for some reason (now after 5am). However answered a question on StackOverflow and stirred the pot a bit on Twitter. This is not a good use of my time though. Earlier today Adobe announced they'd been hacked, and have had a lot of personal details stolen, and the source code for Acrobat, ColdFusion and ColdFusion Builder are now out in the wild.

CFML: savecontent update

G'day:
Remember I logged that E/R (3643125) the other day, regarding a suggested enhancement to how savecontent works? The idea was to make it work like this:

content = savecontent {
    // stuff goes here
}

Instead of this:

savecontent variable="content" {
    // stuff goes here
}

Well it's been marked "to fix". How cool is that?

Nice one, Adobe. And cheers to everyone who voted for it.

--
Adam

Adobe: Observations on Rakshith's recent blog article

G'day:
I've just seen Rakshith's Twitter update pointing us to a new blog article from him, "ColdFusion: News and Updates from Adobe".

News and updates from #Adobe on #ColdFusion http://t.co/dyHHz0RJoM
— Rakshith Naresh (@rakshithn) October 1, 2013

This seems to be a response of sorts to Cutter's blog entries recently:

• "What's Wrong With ColdFusion?"
• "What's Wrong With ColdFusion? Round 1 Response"

I'm just jotting down my thoughts. I'm typing this as I'm reading the article.

Rather than viewing Adobe and community as two separate entities, we are keen to work with the community with a common goal of reviving ColdFusion. And in that context the feedback that we have been receiving is extremely valuable.

Well this is good news. I was beginning to get the impression that Adobe didn't really care or pay attention to the community, because... well they seldom seem to, and I think they get a lot of licensing revenue automatically, just as large US companies and govt agencies automatically re-up their licences no matter what Adobe to with ColdFusion. So in that light... perhaps they think they don't need to engage with us developers. We don't pay their bills, after all. This is just supposition, but the impression I get sometimes.

I have to say though, that I think the Adobe team need to put their money where their mouth is. This is the first sniff I've heard from them for weeks. The last entry on the official blog was two weeks ago, and prior to two posts then... a month before that! That's no good. And where are their developers in the community? They need to be part of the community.

The last entry on Rupesh's blog was in 2010! The penultimate entry is entitled "ColdFusion Survey : We are listening". I note Rupesh's blog runs on PHP, btw.

Shilpi... the "security tzar"... the last blog entry on her blog was in July: "Slides & Recording of e-seminar on Security Best Practices for ColdFusion".

Ram? March 2012 was his most recent ColdFusion blog article (taken from "Ram's Blog: My ColdFusion Blogs".

I could go on, but you get the point: they're invisible. It's the same on the ColdFusion forums, Stackoverflow, Twitter. They are not part of the community. Time you joined in, people.

ColdFusion: Tirade averted... (update: no, actually: tirade)

G'day:
Last night someone from the community directed me at this issue on the bugbase: "Updating a task via cfschedule resets task to defaults". Neither of us could believe what Adobe had said to justify themselves. Fortunately in the interim cooler heads have prevailed, and they're on the case, but - dammit - I want to mention this anyhow.

The story with this bug - and it's a bug, Uday - is this:

If you are updating a scheduled task via the cfschedule tag it is possible for some of the task info to be reset back to default. For example, if task had an eventhander configured and cfschedule was used to update task but eventhandler attribute was not used then eventhandler would be set to blank. The eventhandler attribute is just one example as this affects other attributes equally.

So that's a bit rubbish.

Last night, the response from Adobe - via Uday Ogra - was this:

This is by design. As this action re-creates the schedule task. For updating particular attributes of an existing task it is recommended to use admin UI

This is yet another example of Adobe people being bloody jobsworths, IMO. I am gobsmacked by the stunning ignorance of Uday's justification here on two levels:

• Who cares if it's by design: it's poor, lazy design. I'd be cool with this is Adobe went "oh yeah... oops", but to try to justify this away with "oh, it's meant to be like that" is pathetic. Indeed if you actually went out of your way to design something like that it doubles the question marks over your capabilities here: introducing a bug during development is one thing; specifically deciding to design something this poorly is unbelievable. Do you mean to say you sat down and went "right, when one uses this functionality to do an update, we'll blow away all the settings to didn't specifically set for update. Yeah: that's what people will want". Shudder.
• What sort of bloody moronic advice is "as an alternative, use the UI". How is that gonna help us in our code? What sort of completely detached from reality suggestion is that? How is it a solution to a coding problem to suggest "use the UI instead".

I owe Adobe an apology, so here it is

G'day:
I've added this to the article in question, but I am also gonna post it separately as a testament to my stupidity, and to basically apply some scorn to myself.

... although Adobe seems to have fixed their own notifications on the bug tracker

G'day:
I buried this at the bottom of my previous article, but on reflection it's pretty good news in and of itself, so I'll elevate it to its own quick article.

The Adobe bug tracker seems to have started sending out update notifications at last!

Adobe possiblynot messing with ColdFusion community projects again

G'day:

Stop Press

(although, like, that can only be done before something gets published, I guess ;-)
There's a chance this is down to an IP address change on Adobe's end, and a DNS caching issue on my end. Stay tuned...

...Stop the press, take to it with a sledgehammer, throw press away

Well I owe Adobe an apology! It was indeed mostly an IP address chance at their end, and DNS caching on my end. Once I got the server restarted (with some config changes), the DNS issue is solved, and I can reach Adobe again. They have changed their bugbase JSON responses slightly so I need to rejig my end of things, but that's nae bother and I should have it sorted out tomorrow.

I really did leap to judge too soon here, and I feel a bit daft for having done so. I'm all for applying derision to a situation, but I do actually think it should have a foundation, and it doesn't in this case.

Apologies, Adobe.

I'm gonna leave the rest of the article here as a monument to my stupidity.

This time, let's nip something at the bud: I don't give a shit who interprets who is at fault for any of this, nor how people confuse the notions of fault and blame, and will contort analogies to convince themselves they're right (I am not blameless here). This isn't about that.

Adobe have messed with the viability of some community projects again. This time: my ones.

99

G'day:
Just quickly... Adobe's got the Untriaged ColdFusion 10 Bugs List down to fewer than 100 now. Nice one! We're getting there!

--
Adam

ColdFusion: Latest from Adobe on the getParameter() thing

G'day:
Just noticed this new comment on 3222889:

Of course the method is there since it is part of the interface. It is just that the call for getParameter('param') is returning null and we will have to debug Tomcat source to understand that. This object is coming from Tomcat and we don't have any control on it and hence we can't do much about it.
However, I am curious to know the scenarios when you would like to use it. We anyway provide you the Form scope through which you would get all the request parameters. What would be the scenario when you would not want to use the Form scope and use the getParameter method of the request object?
We exposed the API to get the underlying application server's pageContext object and we are giving that. But if some method on that object is not working correctly, it would certainly be not a bug with ColdFusion, would it? 

This kinda conflicts with Micha's findings about the same, doesn't it?

I'd also like to point out that this has already been explained in comments against the ticket. However it would of course require Rupesh to pay attention to them.

But fair's fair: there's not a huge amount of detail from Damon there. I will touch base with him and see if I can get a better understanding of what's going on, and why he needs this, and replicate it here.

And now I have a day job to attend to.

--
Adam

CFML: Things I do like: contrasts

G'day:
This is a follow-up from yesterday's article "Things I dislike: jobsworths". In this article we see the constrast between how Adobe conduct themselves, and how Railo do in a similar (well, hey, identical) situation. The very same situation.

Yesterday I observed that the blameshifting and general work-avoidance tactics from elements of the Adobe ColdFusion Team is very bloody slack, and really not acceptable. This is in the context of an - admittedly minor / edge case - issue with how some methods within the ServletRequest implementation (or usage, not sure) seem to work. The issue itself is - as I say - inconsequential, but Adobe's antics of excusing themselves from doing anything about it were lamentable.

In the course of troubleshooting / reproducing / investigating this issue, I noticed the same behaviour seemed to be occurring on Railo. In the spirit of fair play, I hit Railo up about it as well to see how they'd deal with it (and expecting some technical guidance which I was unlikely to get from Adobe).

The contrast in reaction could not be more profound. Just to give the executive summary before I start copying and pasting material you could have already read elsewhere: Railo technical support rocks. And in particular Micha goes above and beyond what I'd expect from any vendor's engineers. At this really really puts to shame how Adobe's team conduct themselves.

Decompiling ColdFusion's code: from the EULA

G'day:
This is just to save me typing on Twitter.