Premature Obsolescence

G'day:
An online mate of mine just pointed me at some code he was fixing (not his own, I hasten to add), and drew my attention to some code commentary which made him laugh / cry / scowl / despair:

ColdFusion: Why weI fight

G'day, and apologies to Frank Capra for trivialising his work.

An alternative title for this article could be "Readers: can't live with 'em... can't kill 'em". But I liked the Capra allusion which popped into my head initially, even if it does self-aggrandise what I do here "somewhat".

Can I please remind you lot of something. At the top right of the page you are reading, second paragraph, it says this:

I tend to be a bit "forthright": I think CF is a good product, but I won't blindly defend it in all circumstances, and I have been quite critical of ColdFusion and Adobe at times. This will come out occasionally here: I make no apology for it.

It says that on every page of the blog. And I put it there on every page for a reason.

First: a digression. The back story of this blog - and the gist of the title - is this.

I have been in the ColdFusion community since about 2001 (working with CF since 2000, but was unaware of the community at the time). I have enjoyed reading the various blogs that have come and gone, but they all and one common thread: they were always - or at least almost always - never in the slightest bit critical or questioning of what Macromedia / Adobe were doing with ColdFusion. The general approach of the CF community seemed to be blind adulation, matter-of-fact stick to examples of how the code worked, or stony silence when something was a bit rubbish. No-one ever seemed to go "Oi, WTF is going on with this?"

I had been thinking about starting a blog for a number of years, but for a while I was suffering from imposter syndrome, and thought I'd probably only have enough material for about half a dozen posts, and then run out of steam. Plus it would simply not be of any benefit to the community. Plus I have the attention span of a goldfish, and lose interest in stuff fairly quickly.

But whenever it was - a year or so ago - I decided, screw it... I'm fed-up with where Adobe is taking this community (or more to the point: I'm fed up with that the community seems to be sleeping through this happening), and I perhaps do have an interesting alternative spin on what's going on in the CFML world, so I'll write it down. My position has always been to question what's going on, rather than just sit idly by watching it but not saying anything because I'm too darn polite (like an awful lot of people seem to be). The raison d'être for this blog is kinda "well someone's gotta say something".

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.

Short, Self Contained, Correct (Compilable), Example

G'day:

This is a lazy post, as it's just linking to another article, and a bit of me wittering on. But so be it.

Maybe you read my article ages ago, "Need help? Know how to ask for it". Here's more advice along the same vein.

Peter Boughton (who doesn't appear to exist on social media, damn him!), is one of the most clued-up CFML dudes I know, and is the most helpful person - by far - on the ColdFusion feed on Stack Overflow. Today he was addressing a question on Stack Overflow, and was confounded by example code that didn't compile, thus making it a bit hard to work out what was wrong with it. Yeah, sure, he could wade through it and fix it and then run it, but - really - why should he have to? If you're asking for help, then you should be doing as much of the work as possible to present your problem, and the person helping you should only be doing the bare minimum of wading through your stuff to work out what's wrong with it. They should not be fixing your example code so that it can even run! In most of the help forums we are just volunteers, and we give up our time to help. So it'd be good for people to respect that idea, and minimise the amount of time we need to invest in getting your code working.

And the thing that most people really seem to not get is the code needs to fulfill the following criteria for it to be effective example code:

• Short. Only the stuff that demonstrates the issue. Nothing that is not related to the issue. It's noise, and unhelpful.
• Self-contained. It should be able to be copy and pasted and then executed. it can't have dependencies on other bespoke code, database connections, environmental considerations, etc.
• Correct. Well obviously if one needs help with code there will be some problem with the code somewhere, but it should compile, and there should not be any problems with it that aren't directly related to the "thing" that you can't work out.
• Example. Not just a swag of code copy and pasted from the middle of yer app. An example of the problem. A test case.

That's my summary of the very good doc that Peter pointed the person asking the question to. The doc is here: "The SSCCE: Short, Self Contained, Correct (Compilable), Example". If you ever need to ask for help with code… read and understand that. And as per my earlier article, also read and understand this one: "How To Ask Questions The Smart Way".

And don't waste people's time, when you're expecting them to help you.

Righto.

--
Adam

"What you didn't know about CFML", eh?

G'day:
A few weeks back the existence of a document / flyer / thingey entitled "What you didn't know about CFML". A lot of people sent Twitter messages announcing its existence, other people (sometimes the same people) had various 140-char-long observations to make about it. I think conceptually it's a good idea (-ish), but it could do with some polish. Here are my thoughts on it...

"ColdFusion (CFML) is an application server and software development framework..."

Well ColdFusion might be those things, but CFML isn't. CFML is - and we all know this - is the language ColdFusion - and Railo, OpenBD (kinda) - processes/serves/uses. The doc should get its terminology right here.

The original wording - which doesn't include "CFML" - must've come from Adobe: if one googles "ColdFusion is an application server and software development framework", there are plenty of matches for that exact paragraph used on the flyer. Interestingly (?) I cannot find the text on Adobe's own website though. I guess their description has moved on, they now say:

Adobe® ColdFusion® application server enables developers to rapidly build, deploy, and maintain Java™–EE applications for the enterprise.

That said, I think the description is fine, other than the misuse of "CFML".

Myth: No One Uses CFM Any More

There's some supposed metrics here: 12000+ companies, 778000+ developers etc using CFML. But there's no references to corroborate these figures, so they're a bit empty. Down the bottom there are some reference sites which I guess are used for some/all of the figured cited (each figure should have  a reference), one of which is trends.builtwith.com. This actually claims to have well over 200000 sites using ColdFusion, so that might've been a more impressive figure to use.

Prelude to a storm

G'day
I started doing some research for this evening's blog article just now. It's relating to that "What you didn't know about CFML" thing that did the rounds last week, and the Adobe ColdFusion Evangelism Kit. After one minute of research I'm already fucked off.

Things I don't like about CFScript

G'day:
This is a lunch-time article so I gotta be quick.

Now don't let the title put you off... I love CFScript and that's what most of my code is written in. I think tags only have a place in files in which one is interacting with text, other than that, one's code should always be in script. However some of the ways things have been shoe-horned into script make me shudder slightly. Or a lot.

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

For Pete's sake: "deprecated" does not mean "removed"

G'day:
One thing I hate (of a very long list, it seems...) is people simply not getting what the notion of "deprecation" means. In the context of software (~ features) I mean.

For goodness sake: if one has a software system and one declares an element of that system to be "deprecated", this does not mean it's been removed from the system, or will now break, or will work in any way different from how it did before it was marked deprecated.

If we're talking about ColdFusion, and we were to say that <cfform> (pseudo-random example, but a frickin' good candidate for deprecation!) was deprecated as of CF11... then it would still work exactly the same as it does in CF10 in CF11 and every subsequent release of ColdFusion until it was finally retired.

All deprecation means is to flag that a feature will no longer receive enhancement (or bug fixing, etc), and that it will possibly be removed from the product at some later date. I would go as far as to say that if one was being professional about things, then simply saying in the release notes of CF11 that <cfform> was deprecated (but no mention of when it would be removed) then that's almost a guarantee that it'll still be there in CF12 as well. Deprecation is one thing, but the decision to actually remove something from the language ought to be flagged 1-2 version out (something that Adobe has never done).

Damn you and your opinions, Dave Ferguson

G'day:
(Just kidding Dave... that's just a reference to Scott saying I'd be doing a blog article about you after hearing the latest CFHour: "Show #189 - Manage Your Indention").

This is clarification of something Dave did dwell on during that podcast, in reference to my article 'Really, Adobe: "NotWorthEffort"'. And to fulfill Scott's observation that I'd feed-back on what Dave said.

That article draws attention to what I perceive is slack-arse-ness on Adobe's part in how they dealt with a user-raised issue on the bugbase relating to the toScript() function (3041310).

The lads on CFHour made a few points / observations which are relevant, but at least partially tangential to the point I was trying to make.

Firstly: yeah, the code that toScript() generates works. It's slightly verbose, but it works. That's a very low bar to set though, isn't it? The approach taken here demonstrates a certain lack of finesse that one might expect from a function Adobe (OK: it was Macromedia) have provided to effect a better solution that just rolling one's own. And surely that's the intent here? It also kinda shows their hand in regards to their JavaScript capabilities, which seem to be "less than ideal" (I'd actually say: "not up to the job").

Moan moan moan bloody moan

G'day:
Another point for Rob Glover... he reminded me about one of my pet hates yesterday... CFML code in which the dev has closed the tags. I wrote an article about closing CFML tags ages ago. But what else annoys me in my CFML world?

Here's a list of CFML- or dev-oriented pete peeves of mine. In no particular order. And why? Just for the hell of it, on a slow news day.

The idea that pointless closing  CFML tags is "a thing"

'nuff said.

Comments that simply state what the next line of code is doing

eg:

// create the object
theObject = createObject("TheComponent");

Seriously? F*** off if you do that. If a person is looking at that file, they understand CFML (or at least they should, and comments are not the way to solve that if it's not the case!), and reading the code is a fine way of identifying what the code does.

This is made worse by poorly maintained code in which the comments reflect the state of the code as it was a year earlier, but not how it is now.

Use comments to explain what's not already on the screen, and not readily inferrable from what's on the screen: why you're doing something, how an algorithm works, or an explanation of why unlikely-looking code needs to be the way it is (eg: some third-party service wanting dates as strings, or something).

Copying and pasting of code instead of refactoring

If you want the same functionality somewhere else in your code base: refactor, don't copy and paste (or as I term it in this context: "cu*t and paste". Because if you do it: you are one). I don't know how many times I've needed to fix something only to find out that the same bit of logic exists in several places in the code base.

Using tags in logic-only files

Tags are for interacting with mark-up. They are clumsy and clunky-looking when used in logic-only files. The only time they should be used in these cases is when Adobe have dropped the ball and there is no script-compatible implementation of the given functionality.

Not RTFMing (or should that be "RingTFM"?)

Asking questions (especially in a written forum) before even bothering to just look up the answer in the docs. Or via Google. It's just laziness, and people like that do not deserve the help they are soliciting.

CFML's "Wizard" tags

Like anything to do with the UI (<cfform>, <cfpod> etc), and including <cfinsert> and <cfupdate>. Have some pride: do your work properly.

Adobe's attitude to their clients

Their support of and participation in their developer community is appalling.

Not understanding when to use #

Thanks to David Nash for this one. Its not complicated (like when to use an apostrophe), yet so many people simply do'nt bother to learn the languages' syntax properly. NB: sic.

Not having a basic understanding of computing

Not understanding why floating point numbers are inaccurate, why data types have size limitations; or how Javascript runs on a client machine and ColdFusion runs on a server and the two don't interact directly, etc. I don't expect people to be able to write a C compiler (cue Sean to say something along the lines that he has ;-), or know the intricacies of the architecture of a CPU, but an understanding of the basics of the tool set one uses daily for one's career.

Being partisan about technology

Because I use Railo doesn't mean ColdFusion is automatically the villain (it's not for those reasons), or if I like CFML then PHP automatically sux, etc. Or I like Apple products therefore Microsoft products are automatically bad, etc. I know we work in IT, but not everything is binary. And you sound stupid if you hold opinions like that.

That's a random ten. There'll be others, and things that annoy me more, but happen less frequently so have not sprung to mind in the last 15min since I decided to write this.

I'm sure you'll disagree with at least some of these, or have some other ones of your own. Go on then...

--
Adam

weB LOG

G'day:
Just so you know... I never sit on any of the stuff I blather on about, or save it to make a particular point.

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

"If you don't ask, you don't get"

G'day:
I don't often get a chance to quote Gandhi, but there you go. It was gonna be "If you tolerate this...", but that sounded a bit egregious in the context I am going to use it. Plus Gandhi has a bit more cred than the Manics. Sorry Wales.