Wednesday 30 September 2015

Survey: bug tracking software UX expectations

G'day:
I haven't done a survey for a while. This one is a quicky about bug tracking software: "Bug tracking software expectations". It's only got a few questions:
  • What bug tracking software do you use?
  • When reading comments that have been added to an issue, in which order would you expect them to be listed?
  • When voting for an issue would you prefer (out of the listed options)
  • How important to you is it to be able to (perform a list of common bug-tracking tasks)
  • If you are a user of the Adobe ColdFusion bug tracker, what are your thoughts on it?

The last question kinda gives away my motivation for asking these questions: I'm hoping to lean on Adobe to get some stuff in their bug tracker to be changed.

Help me build a case, if you like. That URL again (in case you've lost it amongst the preceding dozen lines of text ;-) is https://www.surveymonkey.com/r/LJDXRNB.

Righto.

--
Adam

Tuesday 29 September 2015

ColdFusion bugs: credit where it's due

G'day:
I never thought I'd have cause to write something like this:

But it's true. The bulk of the bug tickets I've raised have been fixed. Many more are flagged to be fixed. There's a bunch that have been "deferred" or "closed/nuh-uh/nothappening", but they're mostly inconsequential.

So I myself have nothing to add to this drive to get the ColdFusion Team to look at outstanding bugs that are important to us (earlier: "A real prospect of getting engagement from the ColdFusion Team regarding your "favourite" bugs").

I guess I've been impacted by bugs other people have raised, so I'll sift through those too.


Weird.

--
Adam

A real prospect of getting engagement from the ColdFusion Team regarding your "favourite" bugs

G'day:
Dan Fredericks, backed by Elishia Dvorak and later Denard Springle have asked me to spread the word and garner some interest in an idea they've had to improve engagement between the ColdFusion community and the Adobe ColdFusion Team. We had a round of emails yesterday, and Dan and Denard have come up with this write-up:

This past weekend while attending NCDevCon 2015, Adobe... at the bequest and in conjunction with CFML community members... came up with an idea that we hope will help foster and facilitate better communication between the Adobe CF development team and community members.

The idea, in a nutshell, is to take advantage of the momentum we are building as a community with our Slack channel and work together to generate a list of the communities most pressing and important CF bugs that need addressed. They want us to use the Slack channel [#adobe] to accomplish this.

To participate, simply join the channel and work as a community to come up with a list of the most important bugs.

There are some caveats to this request... We ask for you to put in the bug number from the Adobe bug base and give a concise use case for why it should be in this list. Other community members can then comment on the bug and/or the use case. This way we can have open community dialog on the bugs to make sure we get the best and more pressing list of bugs for Adobe.

[The] channel will be used to do this for 3 weeks[...]. All community comments [in this period] will be used to aggregate the bug numbers and business cases, and turned over to the CF team to have a larger internal discussion of those bugs.

After a timely review of the aggregated data by the Adobe CF team they will update us on the status of the bugs on the list via the [#adobe] channel [you need to have subscribed to the #cfml channel first before that will work], a blog post and/or other Slack channels.

This status will include which bugs were accepted to be addressed, and which ones were not accepted. In each case the community expects a fuller explanation of what is chosen to be addressed and what is not, and why those decisions were made. It is our hope that this may lead to a more inclusive discussion of the bugs that are elected not to be addressed if the reasons given turn out to be poor. It is also the community’s expectation that the bug base will likewise be updated with fuller explanations for the actions taken on these bugs.

We hope by using Slack, which is getting a lot of daily use, the community can come together more readily with the Adobe CF development team and put together the best list possible. If this is a successful venture, then we will try using Slack more aggressively with the Adobe CF dev team to foster a more open relationship that benefits all concerned parties.

Monday 28 September 2015

ColdFusion: Adobe chip away at their own crappy generic CFScript syntax

G'day:
Here's some good news from the Adobe ColdFusion Team: it seems their not opposed to reversing some of their bad language design choices: they're thinking of deprecating cfloop() in favour of extending for().

Background: Adobe had been promising full CFScript functionality parity with tag-based functionality since ColdFusion 9 was in development. CFScript got enhancements in 9, and again in 10, but did not get the 1005 parity until 11. Unfortunately Adobe did a half-arsed job of this and simply implemented the rest of the missing functionality via basically calling tags in script. FFS.

So where we might have had to do this in the past:

<cfloop query="someRecordset" group="someColumn">
    <!--- outer loop stuff --->
    <cfloop>
        <!--- inner loop --->
    </cfloop>
</cfloop>

Adobe decided this would be a suitable CFScript implementation of equivalent functionality:

cfloop(query="someRecordset", group="someColumn"){
    // outer loop stuff
    cfloop(){
        // inner loop stuff
    }
}

Egad. This shows a chronic lack of language design skills, and seemingly a complete unawareness of how any other language might go about things. Why the hell are they still prefixing everything with CF??? How does syntax like that fit in with the aesthetic and precedent of all the existing CFScript implementation? It's just an exercise in laziness and dull-headedness.

Anyway, I've gone on about this enough in the past.

Right, so now we have this ticket (which I only now notice I actually raised!): "Error messaging with cfloop() is rather messed up", which has footnotes:

We will not take this up and might deprecate cfloop() in cfscript altogether in future.

[...]

There is an enhancement to support grouped query looping in for() syntax in cfscript. - #3754577. We will not deprecate cfloop before taking that enahancement.

3754577 observes that cfloop() doesn't actually have functional parity with its tag counterpart.

But the important thing here is this bit: "We [...] might deprecate cfloop() in cfscript altogether in future". I'm mad for deprecating cruft from the language, but the more important thing is that it seems if Adobe are actually given better alternatives for their generic tags-in-script functionality, they seem open to deprecating the generic stuff, in place of implementing a better, in-keeping-with-design-philosophy alternatives. This means we can tidy up CFScript a bit, if we put our minds to it.

ColdFusion 2016 is being developed as we speak, and I can speculate that we're possibly in the window for getting stuff done with the language (remember Rakshith promised ColdFusion 2016 would be a dev-centric, language-centric release), so now's the time to get the ideas in front of Adobe.

I've already floated a coupla ideas for improving the current CFScript implementation of some tags:


Those are just a coupla random ideas. What I want to know - and I want to get this info from you lot - is what other areas have Adobe let us all down in falling back to this generic "tag in script" syntax instead of doing a thoughtful implementation.

How would you implement <cfldap>? <cftransaction>? What about <cfmail>? Share your ideas (and get them into the bug tracker).

Righto.

--
Adam

Friday 25 September 2015

ColdFusion docs site: update and question

G'day:
I've received official word from Adobe as to the fate of the ColdFusion wiki (see yesterday's article "Is the ColdFusion community about to lose the ability to update the docs?"). What do you make of this?

Dear Adam,

Two years ago, we together made a decision to move ColdFusion documentation to a wiki model so that we can open the documentation up to chosen ColdFusion experts to improve and add value to the content. Today, we are at a juncture, where in, we have to move away from the wiki model temporarily due to multiple issues. From starting next Monday, 28 Sep 2015, ColdFusion documentation will go live at helpx.adobe.com. We will share with you the link to ColdFusion documentation when it goes live.

Meanwhile, we would like to not miss out on the value add you have been doing to ColdFusion documentation. Hence, we are setting up a DL (DL-CHL-CF) to which we will be happy to receive any information you deem right to be included in the ColdFusion documentation.

Thank you for supporting us,
ColdFusion documentation team.

So there we go. That sux. I am interested to know why they're moving away from the wiki model temporarily. And what sort of units of time this temporary state of affairs ought be be measured in.

More importantly, can anyone explain to me what the hell this means: "we are setting up a DL (DL-CHL-CF)". What the hell does that sequence of words mean? And is it reasonable to think I might already know what a DL is (especially a DL-CHL-CF one, as opposed to some other sort of one)?

I think the ColdFusion community is about to lose a great resource.

And I'll let you know when I find out what at DL is. A -CHL-CF one, at that.

Update:

Here goes, I got a reply from Adobe on this:

DL is a mail distribution list. It’s a mailing alias (we will communicate to you as soon as it is set up) in which the CF documentation team members will be available,

I'm not sure how anyone expected anyone to infer "DL" meant "a mailing list", but then again Adobe aren't exactly known for clarity or thoughtfulness of communications.

I have, btw, opted out of participation in their mailing list.

Righto.

--
AC

Thursday 24 September 2015

Is the ColdFusion community about to lose the ability to update the docs?

G'day:
(Hopefully this is a nod to Ian Betteridge in my subject line there).

I read this last night, on ticket 4010693:

Update: Adobe has copied the wiki docs over to AEM (Adobe Experience Manager). The AEM docs cannot be edited by anyone outside of Adobe. The wiki will be taken offline in about a week or so (guessing October 1st).

To verify, see Adobe's comments here: https://bugbase.adobe.com/index.cfm?event=bug&id=3921578

Thanks!,
-Aaron

And the comment in question is (from the pleasingly named "Jacob Jayakar Royal"):

Yes, Nitin, already migrated. All our CF content is there in helpx already. Wiki pages can't be viewed after a week or so.

So... um... what?

The only useful thing Adobe have ever done with the ColdFusion docs is to put them on the wiki so we (ie: the community) could actually fix them up. And now it seems they're taking it back in house?

I can't see anything that confirms Aaron's comment that "The AEM docs cannot be edited by anyone outside of Adobe", but that would really suck if it was so.

It would be really good if someone from Adobe (I'm looking at you, Anit) could clarify what's going on here?

Cheers.

--
Adam

Wednesday 23 September 2015

RWC: don't forget to watch Scotland v Japan

G'day:
After Saturday's f***ing amazing World Cup upset in which Japan beat South Africa (the Guardian describes it "Japan beat South Africa in greatest Rugby World Cup shock ever"), I think we should all be paying attention to how Japan continue to fare against the other teams in their pool. Ostensibly South Africa are one of the strongest teams in the tournament, so this suggests lesser-ranked teams like Scotland and Samoa might be a bit concerned about their chances against Japan, and this definitely changes things in Pool B.

Scotland get to find out what it's like to be on the receiving end of this new rugby juggernaut (OK, I'm overstating it there) this afternoon at 2:30pm (BST). That's 09:30 Eastern Time, and 06:30 Pacific time for those in the States (well: in those TZs in the States). And I'm sure people elsewhere in the world will have the geographical and temporal savviness to be about to work these things out for themselves. I'm making a point of sharing the kick-off time, because the fact it's mid-afternoon surprised me. It's bloody inconvenient actually, cos obviously I'll be at work, so can't watch it :-/

The IRB Rankings have been updated to reflect the weekend's matches, and as it stands Japan is ranked 11th; Scotland 12th. So it should be a fairly interesting match, and an important one for both teams. If you've not watched rugby before, it might be a good match to check out.

As I said the other day, I'm off to Olympic Stadium this evening to watch France v Romania. Am really looking forward to that.

Righto.

--
Adam

ColdFusion / Lucee: the first two things I do when I find a new CFML site

G'day:
I just had to email yet another ColdFusion-based website about security holes in their website. Which I found via a Google search result when searching for [something else]. It'll be interesting to see if they do anything about it.

If you run a ColdFusion website, do this:

http://yourdomain.com/CFIDE/administrator

Or on a Lucee website:

http://yourdomain.com/lucee/admin/web.cfm
http://yourdomain.com/lucee/admin/server.cfm

Or on Railo:

http://yourdomain.com/railo-context/admin/web.cfm
http://yourdomain.com/railo-context/admin/server.cfm

If you see anything other than a 404 page, your site is possibly insecure. You must not expose your admin UI to the public.

Then try this:

http://yourdomain.com/Application.cfm

If you get a CFML error message instead of your web server error page, you are also emitting information about your site you should not be.

Whenever I hear about a CFML website, I check those two things. depressingly often I find them not secure. And note: if you're in the habit of announcing the launch of new CFML-driven websites, make sure you've done this stuff first.

As I have said before: "Don't advertise yourself as a CFML website". Ideally you should not even be exposing URLs which have a .cfm extension, as this is giving away information you should not be giving away. That said, I would not worry too much about that, but definitely do worry about having you CF Administrator exposed.

What you really ought to do whenever you are going to launch a new CFML-driven website is engage Foundeo (disclosure: I have nothing to do with Foundeo, and I am making this recommendation solely because I respect the work they do) to do a security audit for you:  HackMyCF. They'll check all sorts of stuff for you, and make sure you're secure. And you really must do this sort of thing as a matter of course.

Don't leave yourself exposed and become one of those news stories.

--
Adam

New bug status for ColdFusion bugs: DELETED/NEVERHAPPENED

G'day:
This is just a repro of something Aaron said on the bugbase, which reveals a rather interesting act of weirdness on the part of the Adobe ColdFusion Team. And you know how I love those.


I spotted this today on the Adobe bug tracker (look quick, before it gets redacted!):

[ANeff] Bug for: Adobe is deleting thousands of tickets from their public bug tracker

Adobe is deleting thousands of tickets from their public bug tracker. 2,824 ColdFusion tickets have been deleted between June 9, 2015 and September 22, 2015.

Steps to Reproduce:
1) Try to view any of these ColdFusion tickets which were fixed in CF11 Update 3: 3041747, 3043855
2) Try to view any of these ColdFusion tickets which were fixed in CF11 Update 5: 3037144, 3039708, 3041684, 3041790, 3043111, 3043375, 3043657, 3044064, 3114274, 3226380, 3369472, 3520983, 3673298, 3842326
3) View attached 20150609_CFTicketsTotal.jpg and see total ColdFusion ticket count was 5,140 on June 9, 2015
4) View attached 20150922_CFTicketsTotal.jpg and see total ColdFusion ticket count was 2,316 on September 22, 2015
5) View attached 20150609_CFTicketsFiled.jpg and see -my- total ColdFusion ticket count was 455 on June 9, 2015
6) View attached 20150922_CFTicketsFiled.jpg and see -my- total ColdFusion ticket count was 328 on September 22, 2015

Action Items:
1) Restore the tickets deleted between June 9, 2015 and now.
2) Delete no more tickets.



My emphasis.

I can confirm a lot of the bugs I have raised have been deleted. I don't track the numbers, but I can see they're way down. Also looking at one of my older blog articles ("Most popular unhandled ColdFusion bugs"), all the ones I checked from that list - and a reminder: those are the most popular unhandled bugs: so ones we clearly care about - have been deleted.

So what's going on here then? What on earth would possess Adobe to delete this stuff? Even if a ticket has been fixed, it's all valuable historical information... not everyone will be patched-up or running the current version, and the ColdFusion Team has a nasty habit of closing tickets when they can't be arsed doing anything about it, so a lot of historical bugs will still actually be potentially impacting their clients. All this sort of action is achieving is increasing potential work for their clients as they troubleshoot issues which might actually already have been identified and discussed (if not fixed).

What's more, the content of those tickets is - on the whole - the community's work, not Adobe's. I put effort into tickets I raise so they're googleable and reproduceable and are intended to stay there so as to save people time if they run across the same issue. So please don't delete my bloody work, Adobe. Or Aaron's work. Or Ray's or anyone else's.

And, um... please explain.

Update:

And, indeed, they have explained. Apparently it was not their team that did it, it was another team. The team who looks after the Adobe bug tracker were a bit too zealous in making older versions of ColdFusion unselectable when raising new tickets, and in the process made all the tickets for those versions "invisible". Okey dokey then. I do have to wonder why no-one on the ColdFusion Team noticed this change, or checked the results of it, or... seemed to care, prior to Aaron bringing it up..?

--
Adam

Saturday 19 September 2015

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

RWC: South Africa v Japan

G'day:
Firstly: holy f*ck! Yesterday I said this:

Pool B

There's a strong fight for second spot here, with Samoa and Scotland being strong contenders, and Japan having half a chance if they have some luck. South Africa will be clear winners of their group. USA just rounds out the numbers

South Africa (3)
Scotland (10)
Samoa (12)
Japan (13)
USA (15)

I think Scotland are playing uncharacteristically well, and will just edge Samoa.

Well.

The South Africa v Japan game was something to behold, and Japan won. Fantastic stuff. This really changes things in this group, and I don't know what to think now.

It was not a case of South Africa playing badly: they played a good game, but Japan hadn't "read the script" and came out fighting, indeed taking an early lead. Throughout the whole match the score seesawed:

(South Africa) 0-3 (Japan) (8min)
7-3 (17min)
7-10 (29min)
12-10 (33min and HT)
12-13 (43min)
19-13 (44min)
19-16 (47min)
19-all (55min)
22-19 (58min)
22-all (60min)
29-22 (62min)
29-all (68min)
32-29 (72min)
32-29 (@ 80min, which is fulltime, until there is a stoppage)
32-34 (84min)

Japan just took it to South Africa, and both teams had an answer every time the other scored. Although the South Africans had a look of disbelief on their faces for a lot of it.

The last 10min - when South Africa got ahead and looked like holding on - spelled the end of my fingernails, but that last 4min after full time was... just... something to behold. At the 80min mark Japan had a chance for a fairly certain penalty which would have tied the scores, but they decided "ballocks to this, we can win this", and took the line out and slogged on. They crossed the line at one point after a huge rolling maul, but neither the ref (nor the TMO, nor me) could see the ball being grounded, so they reset for a scrum and kept going. Then at that 84min mark a gap opened in the Saffer defence and Japan took advantage of it. History made.

So what happens in that group now? I'm sure South Africa will regroup, but now both Scotland and Samoa will want some of them, and both sides will be picturing themselves winning. South Africa could well exit the tournament in the pool stage here, and... what... I can't call the result really.

That Japan side can beat either Scotland or Samoa to top the group, and any of South Africa, Scotland or Samoa second. I'm gonna hope for a South Africa early exit (this is epicaricacy at play), and Japan to top the group with Scotland second. This, however, will not change the quarter final results. Although England will have just sat bolt upright and gone "what have we got here then?"

Cool!

--
Adam

The approach to implementing/designing .lucee

G'day:
I'm reproducing this from a post I made on the Lucee Language Forum. I'm repeating it because... well... I wrote it so I can do with it what I like, plus it'll reach a more diverse audience here, I think. And people should feel free to say what they like in response here, unlike how things will be nannied on the Lucee forum.

The approach to implementing/designing .lucee

Continuing the discussion from "Redux: Rename “component” to “class” in the Lucee dialect":

Dom Watson had said:
Support for using 'class' rather than 'component' seems to be pretty strong, the hiccup here is drawing a more far reaching proposal. Anyone, cough @adam_cameron cough, tenacious enough to flesh out the breadth of what should be changed and wrap it up in a proposal that we could move forward with?

Well here's the thing. I think LAS's entire approach to "planning" and building .lucee is back to front. The approach of starting with CFML, doing a rename, and then bolting stuff on, taking stuff out, changing stuff around is entirely (entirely) the wrong approach. What's been delivered so far is - I'm afraid - a waste of everyone's time: it's just CFML spelt differently. This is of no point or use to anyone, as its basis starts with all the things about CFML which are wrong, out-of-date, only partially realised, etc. With a bunch of stuff that's good, there's no denying that too. But no-one needs a "kinda CFML, kinda not, based on a language designed in the 1990s and shows it". Where's the market for that? Beyond being an outlet for the LAS dev squad's mores to "do their own thing".

Anecdotally, Java looked at C++ and identified an OK basis, but with a lot of hoary bits and set out to create a similar language which was a bit more approachable. C# came along later and did the same thing with Java. However they didn't start with the earlier language, open the hood and start pulling things out, chucking more stuff in, then standing back and declaring some sort of Heath-Robinson-esque mishmash to be what they set out to do. No. The designers actually... well... designed the new language. From the ground up. They allowed the good bits of the earlier language to influence their design decisions, but it was a purposeful ground-up design.

What I think you should be doing is going to the drawing board and wiping it clean. Acknowledge there's a body of good work in the internal libraries of the Lucee CFML implementation, but the language that stuff implemented isn't representative of the direction you think a modern "if we had our time again" language might take.

Revisit core concepts like:

  • what sort of language it ought to be? Is the historically-organically-grown weirdo mishmash of procedural and OO really what you want to be perpetuating?
  • would you want to strengthen the approach to OO that it has (discussions like "component" or "class")
  • what about data types? We've been talking about structs a lot recently, but do they have so much place these days in an OO language, if objects are cheap and easy? Possibly not!
  • should arrays start at one or zero (personally I'm undecided, but I err towards 1)
  • lists? No.
  • tags for everything? Or a much smaller subset of tags for using in views?
  • etc


But plan the thing, plan it in a way that yer happy with, then implement it. Don't build the thing on a platform of sand and weird & poor Allaire/Macromedia/Adobe decisions. Make it your own thing.

Or... just don't bother. Do it properly, or not at all.
What do you think? What's .lucee trying to do? Where's its niche? Does it have a niche?

Right... back to watching Japan being very competitive against South Africa...

--
Adam

Friday 18 September 2015

RWC 2015



G'day:
The Rugby World Cup starts today, so technology & on-topic-ness be damned.

The RWC is held every four years. In its current format, 20 finalist teams compete in four pools of five teams each; the top two going through into quarter finals, thence to semi finals and a final (oh, and a "bronze" final to compete for 3rd or 4th place). There are 102 teams in the current world rugby rankings, and the 20 finalist teams are those in the top 20 positions at a certain date. Qualifications for the next World Cup start shortly after the preceding one.

The last World Cup was held in New Zealand in 2011, and the winner was New Zealand, narrowly beating France in the final (final score 8-7). RWC 2015 is being held in England, with a coupla games in Wales.

There have been seven Rugby World Cups thusfar:

  • 1987 - New Zealand beat France 29-9, at Eden Park in Auckland
  • 1991 - Australia beat England 12-6, at Twickenham in London
  • 1995 - South Africa beat New Zealand 15-2, at Ellis Park in Johannesburg
  • 1999 - Australia beat France 35-12, at Millenium Stadium in Cardiff
  • 2003 - England beat Australia 20-17, at Stadium Australia in Sydney
  • 2007 - South Africa beat England 15-6, at Stade de France, in Paris
  • 2011 - New Zealand beat France 8-7, at Eden Park in Auckland

So NZ, Aussie and South Africa have won it two-apiece, and England once. France have had a few chances, but have never quite made it.

Below are are my predictions for this year. Note that I actively support the All Blacks (that's NZ, OK?), Ireland and Wales; actively do not support South Africa, Australia, England and France. I'm ambivalent about the rest, although I don't mind Scotland or the Pacfic Island nations winning a match.

So, how is it going to come together? I'll go pool by pool.

Monday 14 September 2015

JavaScript: a eurekaFFS moment

G'day:
This was going to be another "how would you solve this?" code quiz things, but in the end the problem proved to be really a lot easier to solve than I expected it to be, so I'll just use it as a demonstrating of me being daft instead. Oh, and some Jasmine unit tests.

This puzzled stemmed from this article: "Expectation management: mapping a changing array". I was wanted to take an array:

["a","b","c","d","e"]


and pass it through a function and end up with this:

[
    ["a", "b", "c", "d", "e"],
    ["b", "c", "d", "e"],
    ["c", "d", "e"],
    ["d", "e"],
    ["e"]
]

Where each progressive element has the rest of the array that was in the previous element.

My initial - not working - attempt was this:

// closure.js

var letters = ["a","b","c","d","e"];
var remappedLetters = letters.map(function(number,index){
    var localCopyOfTheseLetters = letters.slice();
    letters.shift();
    return localCopyOfTheseLetters;
});

But this demonstrates the issue that I'm altering the array as I remap it, which is pretty poor form. And doesn't work. The "doesn't work" part is the killer there.

So I decided "OK, let's have a quiz how to do this best".

First things first I knocked together some unit tests to make sure the thing works as I develop it:

Sunday 13 September 2015

The Adobe ColdFusion Team loses a good 'un

G'day:
I was a bit let down to read this yesterday:


It seems like long-standing ColdFusion Team member Hemant is moving on to new things. Firstly: congratulations to Hemant on the new gig. You've been at Adobe for ages, so it must be a big thing to move on!

For my part: I've been interacting with Hemant regarding ColdFusion for a bloody long time. He was always a key participant in the ColdFusion pre-releases, and always had an indefatigable approach to dealing with his clients in a professional and collaborative manner.

Recently his participation has been less obvious, and I had wondered if he was still around; perhaps his role had changed, or perhaps victim of some policy team management have adopted to stop team members from engaging with the public (except, obviously, for Anit)

I always had the impression Hemant knew what he was on about, understood ColdFusion, and also understood to a better degree than most of his colleagues the motivations and needs of the ColdFusion community.

Hoepfully Adobe will find someone suitable to fill Hemant's shoes, and they step up to keep ColdFusion fresh, and perhaps also put additional efforts in to add a new communications channel (over and above Anit) back to the ColdFusion Team.

I look foward to Adobe's introduction of his replacement.

Best of luck, Hemant. It's been good working with you on the occasions we've interacted.

Righto.

--
Adam



Friday 11 September 2015

ColdFusion: getting the audit trail exposed on the bug tracker

G'day:
Just quickly. Obviously I've fallen foul of the Adobe bug tracker in the last coupla days... mostly due to my dim wits, but not helped by the fact it doesn't present information as thoroughly as it could.

Aaron Neff has had the presence of mind to raise a ticket to get the audit trail exposed on the UI, which I think would help a lot with the clarify of what's going on, and also better expose the activity taking place on issues we're interested in.

The issue is "[ANeff] ER for: Display audit trail on tickets" (4054727). It's already been marked as "To Fix", but I'm sure we could get action on it more quickly if we got some more votes & observations added to it from as many people in the ColdFusion community as possible.

Can I urge you to go have a vote.

Righto.

--
Adam

Wrong

G'day:
I was wrong to call-out Rupesh about being dishonest yesterday, in the context of this ticket on the bug tracker: "Closures cannot be declared outside of cfscript". I wrote the the article "ColdFusion Team: further erosion of trust" which expressed my derision at my then perception that Rupesh was acting deceitfully.

Both Rupesh and Peter Boughton have furnished evidence to demonstrate I was mistaken, and given that, my reaction to the situation was poor, and out of line.

Rupesh dug out the issue's audit trail showing it had been marked as "Open / To Fix" for quite some time:


And Peter did what I should have done initially, and dug out the Google cache of the page, the relevant detail of which is:



That demonstrates that on 6 Aug 2015, the ticket was marked "To Fix".

I'm not going to dispute that evidence, but I'm buggered if I understand it. I do not understand how I'd be motivated to chase up a ticket which didn't need chasing?! But it seems I did. And I reacted poorly when this was pointed out to me.

This is not the place for me to comment on why my conclusion about Rupesh's feedback was what it was, I was just out of line to jump on him like that.

In the comments of that first article, Rupesh asked "[...] I expect an unconditional public apology from you on this!", and fair enough.

Rupesh I was clearly wrong in my assessment of your actions and motivations for same. It was very bad form of me to not research the situation (as Peter did) first, and my way of dealing with it was outright wrong.

Rupesh also asked me to take the article down, but I'm not going to do that. I am however going to update it and make it clear that I was wrong, and point readers to this article for clarification. I want it to stand as an indictment of myself, so that people know how I can over react, and do the wrong thing.

I am genuinely completely bemused as to how I misread the status of that ticket, but that doesn't really matter here. I am not particularly enamoured with myself today.

Sigh.

--
Adam

Thursday 10 September 2015

re: "erosion of trust"

G'day:
If you read my blog article this morning "ColdFusion Team: further erosion of trust", you should re-read as I have updated it.

Rupesh maintains - and has offered evidence - that the ticket was reopened ages ago. Here's the audit trail he provided:



The key bit here is the bottom entry which show the ticket being reopened.


On the public-facing UI did not reflect that when I commented yesterday. It's as simple as that.

However Rupesh has provided this evidence, and whilst it doesn't match what I saw, he genuinely seems to be maintaining this is the true status.

So, faced with Rupesh and his log, and me and just my witterings on, you should draw your own conclusions as to what reality is here.

I'm not going to take the previous article down (I mention this solely because he has suggested I should) because I stand by what I say, and it continues to be my interpretation of the situation.

However I am not going to suggest Rupesh is posting that log in anything other than good faith, and this all just makes things seem a bit odd.

I'll leave it to you to decide WTF is going on here. But you should apply Occam's Razor to all this, and - TBH - it falls in favour of Rupesh. I'm not gonna ignore that.

Specifically to Rupesh: if you're not just being dodgy, then I apologise for thinking that you are, and drawing everyone's attention to this. However it would be disingenuous of me to suggest I don't still think you're dodgy. Sorry, but... well... there you go, I'm not going to lie about it.

Righto.

--
Adam

ColdFusion Team: further erosion of trustI'm an arsehole

G'day:

Update 4:

I was completely wrong in what I said in this article, and I am not proud of myself as a result. I am leaving the article here as evidence of what a prick I can be. You should instead read this article: "Wrong".


Saturday 5 September 2015

Expectation management: mapping a changing array

G'day:
I've been staring at this code (/variations thereof) for a week or so now (since JavaScript: running Jasmine unit tests from the CLI; more specifically my JavaScript version of the code I rewrote from "Some CFML code that doesn't work"). I noticed an idiosyncrasy in the first JavaScript version of that code which didn't make sense to me at first. And I ass-u-me`d that my previous expectations made sense and JavaScript was being weird. Then I ran the equivalent code in some other languages and now... not so sure. So here we are: I'm writing a blog article about code I'm not sure I'm completely comfortable with.

It does not help that I'm on my eighth pint of Guinness for the afternoon. But perhaps only as far as my typing goes (which is proving to be a real challenge).

Here's the general gist of what I was trying to do with CFML:

// closure.cfm

letters = ["a","b","c","d","e"];
remappedLetters = letters.map(function(number,index){
    var localCopyOfTheseLetters = duplicate(letters);
    letters.deleteAt(1);
    return localCopyOfTheseLetters;
});
remappedLetters.each(function(series){
    writeOutput(series.toList(" ") & "<br>");
});

Don't worry so much about running that: it does not do what I want (mostly), but more what I'm trying to do, and my expectations of the results.

What I want from this code is to iterate over the letters array, and for each element of it return the whole array from that point. So I'm not really using the callback's value, I'm just leveraging the fact that the map() iteration method loops over each element of the array, so I get to defined - element by element - its replacement.

On Lucee - which is what I tested this with - I get what I want:

a b c d e
b c d e
c d e
d e
e


And this is what I mentally leveraged when working out my code for that "Some CFML code that doesn't work" article. The rest of my logic was predicated on that approach working.

When I tried the same logic on JavaScript:

// closure.js

var letters = ["a","b","c","d","e"];
var remappedLetters = letters.map(function(number,index){
    var localCopyOfTheseLetters = letters.slice();
    letters.shift();
    return localCopyOfTheseLetters;
});
remappedLetters.forEach(function(series){
    console.log(series.join(" "));
});

I get a different result:

C:\src\otherLanguages\js\arrays\map\changeOriginal\js>node closure.js
a b c d e
b c d e
c d e

Huh? Why does it stop after three element? I'm iterating over a five-element array after all. I surmise that under the hood JavaScript is using some sort of Iterator.next() operation. Given I am changing the array I'm iterating over via closure, by the time I get to the third iteration of my map() call, I've lopped two elements off the array, so its length is three, so the map() process exits when Iterator.next() rechecks where it is in the array, and finds out it's at the end. This is entirely supposition, but it seems reasonable.

But initially I was thinking "dumb-arse JavaScript, if I call a method on an object, then the method should be called on the object's current state!". This makes sense for a one-off method, but does it make sense for an iterative method? Hmmm. I had not thought about that. And I had no answer, and given my two comparative cases (Lucee, JavaScript) behaved differently, I didn't know what ought to be the "right" answer. And by "right" I mean "industry standard". I erred towards JavaScript being right, and Lucee being wrong.

Running this example on ColdFusion behaves like JavaScript. But to be honest: I back Adobe to get things right even less than I do LAS, so I filed that as "nice to know".

I did my usual thing of testing out my limited repertoire of other languages running equivalent code.

Null coming to a ColdFusion near you?

G'day:
Am at the pub watching England in the process of handing Ireland their arses to them, which is... disappointing. Still: Ireland's still in the game, and there's 40min left.

Anyway, I spotted this status change to a ticket I raise  in the Adobe bugbase this morning:

Null


[Just] Sort it out[...]. Break any backwards compat you need to to do this. Just make it work. Null is a real thing, stop pretending it isn't or than an empty string is a suitable facsimile of it.

And... blimey... they've only gone and changed the status of the ticket to "To Fix" (admittedly with a sub-status of "Investigate".

About bloody time.

Now... they might investigate and decide to "Close/NeverFix/CantBeArsed" so what you - the ColdFusion community - need to do is go make yer voice heard, and vote and or comment on that ticket. Remind Adobe that lack of the formal concept of null in the language is a right pain in the arse, and wastes a lot of our time. It might have made sense to omit this back when ColdFusion was first release back in the 90s an all it was for was looping over record sets and displaying them, but our industry has moved on and the expectations on CFML devs now is to write applications not "My Web Site", so the kind of code we're writing has changed, and we need these "more complex" (scowl) constructs.

Null is pretty fundamental to... well... programming.

One thing Adobe must do is look at how Lucee has implemented this, and make sure the implementation is congruent. I can't see how it wouldn't be, but... still.

Anyway, ColdFusioners.... go let Adobe know this is important to you.

Back to watching the second half of this "friendly"(*) between England and Ireland.

--
Adam

(*) it's not friendly.