This blog has become a bit flat

G'day:
I got this observation via email the other day:

Checked on your blog today for the first in awhile.

Your recent articles, read to me, as you fumbling around (lil rugby pun intended). I do still appreciate you being an honest ass and admitting when you are wrong.

More then fumbling with Adobe, I can see you fumbling with Javascript remapping and to your own admission, you need to rethink notions about functions.

[...]

I think you could be doing for more constructive blogging instead of poking the bears at ColdFusion... But I don't have a blog, what would I know.

The elided bit is because this was from Acker, and he's banging on about Node,js again. FFS.

But pillorying Acker is not the the point of this article.

Acker is right.

Things here have got quite stale, and a few of my recent articles have been a bit lightweight, and... well... ultimately wrong-headed.

There's two considerations here. I am literal about the "log" part of "blog". This thing logs what I'm doing when it comes to CFML, PHP, JS, [whatever other language I choose to look at], and - for the next six weeks - rugby. I don't claim to be an expert in anything I write about, and all I'm writing about is what I'm currently doing. I know a lot about CFML and I am still on the periphery of that community, and it's what I know best, so there's a bunch of CFML here. On the other hand my day job does not involve CFML - and hasn't for the best part of a year now... my last line of production CFML code would have been at least six months ago - it's all PHP and (client-side) JavaScript.

My issue is that I am not an expert in either PHP or JavaScript, so my articles there are always gonna be a bit hesitant and "this is what I'm trying", not "this is what you should try". In the process I've probably written more about Silex than most other people have, but it's all exploration, rather than incisive knowledge on the topic. I think I understand TDD more than most people do (that's damning me with faint praise, btw), but I've written about that now, so that topic has dried up.

Another issue is that I sometimes just stop caring about investing time in exploring more technology. Most of my "this is what I tried in Ruby", "this is how Python does something" articles are because I just go "hmmm... let's have a look". I'm just not in that mood at the moment. I am fairly open about the fact I don't like PHP as a language, and so I'm loath to write about it (although I have some Silex / Symfony stuff up my sleeve). And in my spare time I am reading novels or listening to podcasts (Im currently listening to a podcast that is reading and annotating the bible to me, of all things. I recommend it not non-believers and - especially - believers alike) and re-playing Skyrim, rather than investigating Clojure or more JavaScript or [whatever].

I had a hiccup with Adobe last week, but - hey - most of my goes at them have been well-grounded, but I needed to be wrong about something eventually ;-)

Anyway, sorry if my writing is shit at the moment. But... well... [shrug]. Don't read it them ;-). I'm sure it'll bounce back at some point. A bit sure. Well: whatever.

And now France v Italy is about to start. What's gonna happen in this game, after the last upset? VIA ITALIA (sorry Aurel, and Jerome, and my other French mates).

Righto.

--
Adam

Killing a muppet

G'day:
Firstly, if you feel so inclined, please take a refresher on my communications policy.

Secondly... I deeply dislike the concept of censorship, and this extends to moderation of the comments on this blog. The only comments I have blocked have been blatant exercises in spam advertising, other than that I have let every single comment through. Sometimes a comment might seem like spam so it gets blocked for a while by Disqus, but I have never - to my recollection - not approved any comment by a person whose intent was to comment on the article.

This changed this morning: I blacklisted my first respondent. This person was Acker Apple.

Acker is a bit of a plank (IMO), and seems to exist solely to bobble up and down like Beaker on The Muppets going "I like Node!" "Node is good!" "I used to use CF now I use Node!" "Node is Good!" "You're Bad, I'm Good!" "node node node node node", and other stuff which demonstrates the Dunning-Kruger effect is alive and well. Examples of this are here: "ColdFusion: Adobe updates their roadmap for ColdFusion. Forgets to give the language directions" and here: "What I'd like to see in ColdFusion 12 (redux, as is happens)".

There's nothing wrong with being a plank, and in very small doses it can be endearing. But when it ends up seeming like a mistake that the grown-ups let the children sit at the dinner table, a sensible and responsible grown-up will usher the children back out of the room so the adults can get on with it.

I was going to just tell Acker to shut up (I put it more directly than that), but having checked my comms over night I have had a couple of actual complaints about his conduct, and the very real fact he's toxifying the comments section on this blog with his continual nonsense, and it's discourgaing participation from more lucid & engaging participants.

To be very clear: the comments on this blog are very important to the content of the blog itself, and oftentimes the comments are more interesting that the article they're commenting on. I welcome all points of view, and especially ones that disagree with me as those are the ones I personally learn the most from. You can, in general, say whatever you like, in whatever tone you like (other than the usual societal / community nonos). I'm not blocking Acker because of his dissenting voice. I'm blocking him cos he's a bit of a cock.

So Acker has been ushered out of this particular room. I have blacklisted his email address (which is about all I can do on Disqus), and will monitor any further input from him by hand. If it is on-topic for any post he decides to reply to: I will consider approving it.

Equally, some other people need to learn to "not feed trolls" as the internet addage goes. This is even worse clutter than the original comments, IMO. I will take a very dim view of anyone adding to clutter in this vein, too. If someone is trolling: just leave them be. Don't become part of the problem.

Finally: apologies to my other readers who might have felt a bit put off by my lack of better/earlier handling of this.

Righto.

--
Adam

* Image from here used without permission. If you are the copyright holder and would prefer I do not use this image, let me know and I'll take it down.

ColdFusion: can't tell its null from its... elbow

G'day:
Blimey: Acker is being of some use! He threw me this code last night, and asked what to make of it (well, OK, Sean asked me, but still).

found something unexpected:

a = isnull(request) && isnull(server) && isnull(form) && isnull(url) && isnull(33);

a = true ... meaning all are null

What the actual f*ck?

So I knocked together some test code to make things more clear:

// acker.cfm    
areAllNull = isnull(request) && isnull(server) && isnull(form) && isnull(url) && isNull({}) && isnull(33);

writeOutput("
isnull(request): #isnull(request)#<br>
isnull(server): #isnull(server)#<br>
isnull(form): #isnull(form)#<br>
isnull(url): #isnull(url)#<br>
isnull(33): #isnull(33)#<br>
isNull({}): #isNull({})#<br>
areAllNull: #areAllNull#<br>
");

And on ColdFusion, this yields:

isnull(request): YES
isnull(server): YES
isnull(form): YES
isnull(url): YES
isnull(33): YES
isNull({}): NO
areAllNull: NO


Adobe you dicks. How can an entire scope be null? How can 33 be null??? I looked in the docs ("IsNull()") and that didn't say anything like "oh, we just make sh!t up about what's null or not. To be honest we just don't know. I mean... how can one actually tell? What is null, anyhow?", which might explain it. But no.

Lucee are not lunatics:

isnull(request): false
isnull(server): false
isnull(form): false
isnull(url): false
isnull(33): false
isNull({}): false
areAllNull: false


I despair, Adobe. I really do. Chris Blackwell could not have put this better:

@DAC_dev that's phenomenal. Adobe should extend their boolean type to 'true / false / fuck knows'

— Chris Blackwell (@d1rtym0nk3y) July 30, 2015

Raised as bug 4028246.

Update:

Just an update on this. In a moment reminiscent of the Orwellian position that 2+2=5, Adobe had this to say on the topic of the nullness of 33:

Are you having a f***ing laugh, mate?

And now these're something about Elvis to investigate too...

--
Adam

JavaScript: expectations re-adjusted re Promises

G'day:
First off a proactive apology. I generally sit in the pub on my Saturday afternoons in Galway (every second weekend), and write some ballocks on this blog. I think we're all used to that. I'm doing that now, but prior to kicking off with the writing I have already been sitting around for two hours watching the All Blacks play the Springboks in a hard-fought, narrow-margined 20-27 victory to NZ. And this entailed drinking four pints of Guinness as the build-up and match was under way, and I'm tucking into my fifth now. So f*** knows how coherent this article will be. The up-side is that I wrote the code for this beforehand :-S

OK, so the framing for this article is the previous article: "JavaScript: getting my brain around Promises", and my admission here is that I didn't actually get my brain entirely around JavaScript promises. I set my bar slightly too high (or: just wrong) for how I'd expect JavaScript to work, as it turns out. I'm spoilt by CFML, I guess. I'll update key points of that article, but make sure to read that one first as it's still mostly all right (IMO), and this article just clarifies a coupla points I didn't quite "get" last time.

My chief misapprehension was that JavaScript Promises themselves imparted some manner of asynchronicity to code execution, but this is not the case. They are just a handling mechanism for other code which itself is asynchronous. Once I wrote some code that respected that, things made more sense to me.

Here are some examples of how Promises help streamlining async code.

JavaScript: (not ~) getting my brain around Promises

G'day:

Update / caveat

2015-07-24

I just had it wrong about this. See my next article: "JavaScript: expectations re-adjusted re Promises". Ignoring this side of things, the rest of this article does correctly reflect the mechanics of Promises, I think.

2021-01-14

I've just come back to this, and feel the previous update - originally buried halfway through the article - was not as emphatic as it should have been. My understanding / expectations of how Promises in Javascript work are just wrong in this article. I considered taking it down completely, but decided to leave it here. There's a lesson to be learned here: at the point at which things were not behaving how I'd expected, I should have done more research, rather than plouging ahead with even more wrongness. Oh well.

Thanks to Ryan for setting me straight in his comment.

My recommendation is to only read this if you want to laugh at me being extensively wrong. There is very little value in it other than that.

A few weeks ago I made a suggestion that some manner of Futures / Promises could be added to CFML ("What I'd like to see in ColdFusion 12 (redux, as is happens): Futures/Promises"). If nothing else this yielded a hilarious/frustrating series of comments. I also raised a ticket for same: 4010501.

I've messed around with a Future-ish sort of construct in the past ("CFML: Threads, callbacks, closure and a pub"), but never looked at Promises before, beyond reading the JavaScript docs for them ("Promise"), and being intrigued.

Way back when all the Acker-fracas was taking place I started knocking together some code to get me up to speed with JavaScript's implementation, just so I knew how they worked, and also to verify my suggestion had merit for CFML. I parked the code due to being sidetracked by other things, but I figured I'd write it up now. First I need to remind myself what all this code does.

According to the JavaScript docs, a Promise is:

The Promise object is used for deferred and asynchronous computations. A Promise represents an operation that hasn't completed yet, but is expected to in the future.

[...]

A Promise represents a proxy for a value not necessarily known when the promise is created. It allows you to associate handlers to an asynchronous action's eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of the final value, the asynchronous method returns a promise of having a value at some point in the future.

I'm always rubbish at understand docs, so my reaction to that is "that's nice". I figured I needed to write some code and observe the behaviour, then I'd get a handle on what was going on.

The syntax of promise usage is:

new Promise(executor);
new Promise(function(resolve, reject) { ... });

Basically the constructor takes an argument that is a call back function, which itself takes two arguments (both call backs themselves), which can be called by the executor in either success or failure situations.

Epicaricacy

G'day:
This is a lazy-arse article - not least of all because I just point you back to one of my other articles from a few days ago - but in case you missed all this due to not following the comments on said article, the comments on "What I'd like to see in ColdFusion 12 (redux, as is happens)" are... well... something to behold as it all unfolds.

As Dan Skaggs said on IRC:

It's like a train wreck...I can't tear my self away from the page waiting for the "New Reply" message to pop up somewhere

Heh.

It starts slowly, but stick with it.

Anyway, yeah I'm a big meany for drawing attention to it. But hey... the headline warned you.

--
Adam