Showing posts with label Sean Corfield. Show all posts
Showing posts with label Sean Corfield. Show all posts

Sunday 13 July 2014

Seven Languages [etc], and how guilt tripping me tends to work

G'day:
A few weeks ago Sean piped-up about the sequel to "Seven Languages in Seven Weeks":

Seven more languages? I hadn't even looked at the first seven yet :-|

I do actually have the first book at home (Marcos, I must give it back to you), but haven't really opened it.

However then this happened:

I claim I don't "do" peer-pressure, but it seems to have worked this time. I'm over in Ireland @ the mo', so don't have the book with me, but bought my own soft-copy of "Seven Languages in Seven Weeks" y/day, and have commenced working through it. And once I've done that, I will consider moving on to the sequel.

The first language is Ruby which I've done a bit of already, and at the end of Day 1 I have not covered anything I didn't already know or haven't already actually covered on this blog:


However the writing style is accessible, and I've now paid to learn this stuff, so I had better work through it.

I'll keep you up to date as I go (and guilt trip me if I do not!). In the mean time, Ben Nadel did all this stuff years ago, so maybe go read what he had to say on the topic: "Seven Languages In Seven Weeks: A Pragmatic Guide To Learning Programming Languages By Bruce Tate". There are links to each day's progress at the bottom. I think perhaps I'll go read them myself.

This seems a bit of a pointless article, outwardly. The general gist is that once I have said I am going to do this stuff, I want you to give me a hard time if I go not. I'm crowd-sourcing motivation, it seems.

But short-term... I'm done with programming for the weekend. I shall now resume drinking Guinness and waiting for my flight. And probably pass the time with a DVD rather than with code.

Righto.

--
Adam

Friday 11 July 2014

Quickly: read Sean's comments and code

G'day:
I said this on Twitter last night, but in case you're wise enough not to busy yourself with that sort of nonsense, I'll repeat it here.

A few days ago I posted some woolly code which implemented a case / when in CFML ("Some more TestBox testing, case/when for CFML and some dodgy code"), and solicited help in improving it.

Sean's leapt to the fore and reworked it in a much more clean fashion. His comments start here, and there's links to his code. He's put a lot of effort into it, and I'm quite chuffed he's taken the time that he has.

So thanks, Sean. And everyone else: you could learn a thing or two by comparing my effort and his approach to tidying it up.

I haven't analysed his code thoroughly myself yet - I've just had no time - but will be doing so over the weekend, and will write up my conclusions.

Again: thanks Sean.

--
Adam

Monday 9 June 2014

CFML enhancement: alternate function expression syntax; "lambda expressions"

G'day:
In this article I just want to - hopefully - extend the audience of a conversation taking place on the Railo Google Group ("Railo 5 lambda expressions"). Even if you're a ColdFusion developer (ie: only use the Adobe product, not the Railo one), this will still be relevant to you as Railo generally leads CFML development these days, so innovations they make will - perhaps some time in 2016 - make it into ColdFusion's dialect of CFML.

There are a lot of good brains in the CFML community, and I hope to encourage some more of them to join this discussion.

Saturday 3 May 2014

ColdFusion 11: what <cfclient> compiles down to

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

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


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

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

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

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

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

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

Thursday 6 March 2014

Wednesday 12 February 2014

ColdFusion 9 on Windows 8

G'day:
I'm about to pop down to NZ for a coupla weeks to see me folks and make sure they're all still in working order and the like. And drink beer with my NZ-based mates. As part of this, I've retired my old Netbook, and have bought myself a new cheapish laptop (or an "ultrabook" as apparently they are being fashioned, these days) as its replacement. The reason I had the netbook is that the battery life was excellent, which was very handy on long-haul flights, plus it was a handy size for using on aircraft and when lurking in airport terminals. Which I do frequently enough for that to be a consideration. Anyway, this new thing has Windows 8 on it, and I spent Fri eveing and Saturday morning setting it up. Which went fine until I needed to install ColdFusion 9.

Thursday 26 December 2013

Identifying when a regex pattern matches at position zero in a string

G'day:
Sean asked on Twitter today for input into how to best handle a shortfall in some TestBox functionality. The TestBox Jira ticket is this one (it also contains basically what I'm about to say here!): "toThrow() cannot match empty message & cannot match detail". The reason for the first stated problem is because of the way CFML's reFind() function works.

Consider this code:

// reFind.cfm
param name="URL.input" default="";
pattern = "^\d*$";
match = refind(pattern, URL.input);
writeDump(var=[{input=URL.input},{match=match}]);

The gist of this is that the reFind() call checks to see whether URL.input is a string which comprises (in its entirety) zero or more digits.

Here are the results with a few test inputs:

array
1
struct
INPUT123
2
struct
MATCH1

array
1
struct
INPUTabc
2
struct
MATCH0

array
1
struct
INPUT12c
2
struct
MATCH0

array
1
struct
INPUT1b3
2
struct
MATCH0

So this shows that it only lets solely-numeric values past: values like 1b3 return a zero match. OK, so far so good.

But hang on. The pattern was for zero or more digits. So zero digits is also legit here. Let's try giving an empty string (which is indeed zero digits) as the input:


array
1
struct
INPUT[empty string]
2
struct
MATCH0

This is correct. The match of zero digits occurs at position zero in that empty string. That's a match. However... reFind() returns 0 if no match was found. As it turns out, this was not sensible behaviour, because it means that there's no way to distinguish between no match, and a match at position zero. Oops.

Wednesday 6 November 2013

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

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

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


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

Tuesday 10 September 2013

CFML: Way to make me feel thick, Sean... by explaining <cfparam> to me

G'day:
OK, it's not about <cfparam>, but relating to its CFScript-ready chum: param.

Yesterday I wittered on about things I don't like in CFScript, and one example I used of "how not to do it" was the <cfparam> tag's CFScript equivalent, which seemed to be just "<cfparam> without the '<cf' and '>'":

<cfparam name="foo" default="bar" type="regex" pattern="[a-z]+">

Becomes:

param name="foo" default="bar" type="regex" pattern="[a-z]+";

Sean quickly pointed out that that is unnecessarily verbose and disagreeably ugly, but the unnecessary part is because... actually it's not necessary. Because one doesn't need to be so verbose with param. These all work:

param favouriteNumber;
param favouriteNumber=3.1415;
param numeric favouriteNumber=1.1414;


That is much better syntax. It doesn't match anything else in CFML that I'm aware of, but it's quite neat so I'll forgive that.

I had a look around last night, and I could neither find reference to this in the docs, and only actually one place that mentioned param at all, which was the "what's supported in CFScript" page of the docs. However looking again this morning, I've spotted this page too: "Tags" (the irony being that the info about a non-tag is on a page entitled "tags" is not lost on me). Adobe really need to lift their game when it comes to documenting CFScript: it is not longer a second-class citizen when it comes to CFML, yet it's still treated that way in the docs. The <cfparam> page should detail the script equivalent, and each CFScript statement / keyword / construct should have its own separate page (again, with a link across to the tag equivalent).

Friday 26 July 2013

Recognising the people who help me with this blog

G'day:
Adam Tuttle (that's twice today) was quipping last that I'd mentioned him twice on the blog on Weds, and I should try for three times y/day (which failed: just the one mention, sorry). Anyway, as a joke back I said I should tag my articles with the people who I mention - these are usually people who have helped me, or caused me to write the article - and whoever is at the top of the list is automatically on my "give them beer next time I see them" list.

And then I thought... well why not? People do help me out and inspire me to write, and I appreciate it. So I did go through all my back articles last night, and tagged them up with the people I have mentioned in them, and I will continue to do so. So there are people's names listed at the bottom of the article on the "tags" bit, and the tag cloud thing on the right hand side also lists a bunch of people amongst the other tags I've got. Now there's been a whole swag of people tagged up, and the tag listing became unhelpful with every tag displayed, so you don't get a mention on the right unless you've got 3 mentions (or are Chris who only had two mentions until now, but as he wrote my most popular article, I decided to list his anyhow. And now he's got his third mention anyway).

Sean's currently at the top of the leaderboard, and there's a fair gap back to the rest of the pack.

Anyway... cheers y'all for your help along the way.

--
Adam

Thursday 18 July 2013

1

G'day:
I'm a bit late with this as it happened a week or so ago, but I just noticed I've been prattling away on this blog for a year now.

Apropos of nothing, here's some mostly useless information about this blog.

I said in one of my earlier articles that I've learned more about ColdFusion since I started this blog than I had in the preceding few years. This continues to be the case, and I've learned a bunch of good stuff about Application.cfc, ColdFusion regexes, JSON (grumble), REST, interfaces (in general, as well as ColdFusion's inplementation of them), and various other odds 'n' sods. Even some web sockets stuff, whilst troubleshooting that security issue from a coupla weeks back. I've also used Railo a lot more, and had a look at Coldbox. Beyond ColdFusion I've also started dabbling with PHP and Ruby. It's been cool! I hope some of it was useful to you, or at least slightly interesting. Or killed some time whilst you tried to decipher what I was wittering on about.

To close, I'd like to say special thanks to a few people whose participation in this blog has been helpful, interesting or thought-provoking. In no particular order, and it's certainly not an exhaustive list:
  • Chris Kobrzak
  • Sean Corfield
  • Andrew Myers
  • Bruce Kirkpatrick
  • Brad Wood
  • Andrew Scott
  • Adam Tuttle
  • Ray Camden
  • Gavin Pickin
  • Jay Cunnington
  • Simon Baynes
  • Duncan Cumming
  • Brian Sadler
There's been a bunch of great input / correction / sanity-checking / bullshit-detection done by a heap of other people too.  Cheers to everyone who's participated here.

And now on to year 2...

--
Adam

Thursday 20 June 2013

Is ColdFusion's REST implementation more verbose than it needs to be?

G'day:
I've been using some REST web services at work recently (CFML calling .NET ones; I'm just working on the CFML side of things, unfortunately), and also pottering around with ColdFusion 10's REST stuff at home occasionally. And then I wrote my "things I ain't researching" article, and one of the entries in that was to look more at CF's REST implementation more thoroughly, as well as Taffy and Relaxation. That in turn reminded me of a thread on Twitter in which Sean was denigrating ColdFusion 10's approach to REST, instead espousing a by-convention approach to things, or just in general not having the REST config alongside the code itself. I don't necessarily agree with him on the latter (I don't necessarily disagree, either!), but it's thought-provoking.

One thing that persisted in my mind is that it seems like there's a lot of horsing about making a method REST-callable, and after discussing a conventions-based approach with both Sean and separately with Adam Tuttle, I turned my mind to that.

God my writing is awful today, sorry. Slightly hungover. Bear with me.

OK, so here's a CFC and a method:

component {

    public string function greet(required string name) {
        return "G'day #arguments.name#!";
    }
}

The minimum I seem to be able to get away with to "RESTify" this is:

component rest=true {

    remote string function greet(required string name restargsource="query") httpmethod="get" {
        return "G'day #arguments.name#!";
    }
}

Saturday 11 May 2013

Interface inheritance what one can and what one cannot do

G'day:
Today's article is brought to you via my baby netbook, as I sit on my bed in my hotel room in Portumna, Co. Galway in the the Republic of Ireland. My ex-wife and my son (25-months-old) live in Portumna, and this is why I pop across to Ireland every two or three weeks (you might have heard me mention it on Twitter or elsewhere). I get to see my boy for four hours on Sat and Sun, every - as I said - 2-3wks. This sux, but that's the way it is.

I only have internet here if I go sit halfway down the stairs, and despite that being doable as I'm the only guest here this weekend, it's a bit cold for that today. So I'm writing this article without the benefit of docs or fact checking! Wish me luck. Or enjoy picking apart whatever it is I end up getting wrong. Heh: in reality I will check everything before I publish... the internet works in the bar downstairs, so I'll proof-read and publish over an early evening Guinness.

Wednesday 8 May 2013

An Architect's View: Sean's feedback on my recent article about ColdFusion interfaces

G'day:
It's a good day for this blog when someone like Sean Corfield reacts to something I write with an article-sized response in the comments. I've asked him if it's OK to reproduce this as a "guest-author" article, which he's agreed to. I did this because I freely admit I'm making up my opinion regarding ColdFusion's interface implementation as I go along, whereas Sean knows an awful lot about the subject - and had a hand in their genesis - as far as CFML goes. So if I'm discussing this topic, his opinions are important ones to reflect upon.

Below is a reproduction of his comment posted against my article entitled "Interfaces in CFML. What are they for?". I have some opinions on this - actually most are "yeah, good point" - but I'll cover them in a separate article.

Thanks, Sean, for taking the time to write this:

Saturday 20 April 2013

Completely useless information about a quirk in ColdFusion's CFML

G'day:
I'm just preparing to return to the UK on Tuesday evening (I'm currently in NZ), and as I do not intend to set foot back on these shores for a long time, there's been a lot of beer-drinking with NZ-based mates for the last few days. I was at the pub from 3pm until [I have no recollection of leaving, really] yesterday, and am about to head off to another pub to drink again with some different mates (and some of the same mates again). We're mustering at 1pm. I'm still feeling the rigors of yesterday's effort, and am trying to steel myself to start again. I have about an hour before I need to head out, so this is a very quick and silly article.

Tuesday 9 April 2013

CFML: Quick survey: do you actually use onApplicationEnd()?

G'day:
I'm in rapid fire mode today.

When talking about all this onApplicationEnd() stuff recently, Bruce asked a good question: what does one use it for? I mean in real life? Well: I don't.

Do you? If you do, and fancy sharing, pls fill out this survey. It's one question: just a bit of typing.

Update:
The survey is closed. The results are here.

NB: as Sean has just pointed out... my wording was slightly vague before, but I'm also keen on you answering even if you don't use onApplicationEnd(). There's a "no" option in there too. It'll be good to see the split of do/don't use it.

I'll report back with what people say when when the frequency of submissions flattens out.

Cheers.

--
Adam

Friday 8 March 2013

Clarification about the ++ / thread-safety thing

G'day:
First things first, it's 11pm on Friday, I've just got back from being at the pub since 6pm and I have had half a dozen pints, so I don't vouch for the quality of this article.

I don't shrink away from over-stated "headlines" on this blog, but I don't like to misrepresent anything. I have a couple of things to clarify based on feedback I've had from the articles earlier today:

Sean prompts me to look at ColdFusion threading some more

G'day:
I got a bit of a slap-down from Sean y/day regarding that code I posted using <cfthread> (well: thread, but samesame). I've yet to clarify whether he was referring the code I was triaging from CFLib, or my scratch code demonstrating a decoupled approach to same, but it's encouraged me to look into things a bit more thoroughly anyhow. I appreciate the slap-down, because it identified a gap in my knowledge, giving me the opportunity to fill that gap.

So, anyway, Sean made a coupla interesting observations which I'll look at here.

Friday 28 December 2012

Callbacks and built-in functions as first-class functions

G'day:
This will be my most unplanned blog article to date. I saw a thread on the Railo newsgroup over Xmas, and whilst catching up with my responses just now, decided "oh, I'll be able to come up with an article about that".

The posting on the mailing list was asking whether one can pass a built-in function (BIF) as a callback.

I currently have no idea what I'm about to say about this, so I am as interested in what I continue to type as you are (the conceit is that if you've got this far, you have at least a small amount of interest)...

Tuesday 18 December 2012

Positive Communication from Adobe regarding ColdFusion

G'day:
In a break from the perceived doom & gloom I have been seeing recently regarding CFML - this blog, Sean's blog, Andy's blog (Andy's gripe is specifically about the ColdFusion installers not working on the current versions of Windows), the Fusion Authority blog etc, some  stuff from the Railo community (which seems a bit counterproductive to their cause, but it's only an element of the lunatic fringe that engage in this), and various series' of sound-bites on Twitter - Adobe published a very positive-sounding article on their official ColdFusion blog yesterday. It should come as no surprise that Adobe are sounding positive about their product, but it's really not something we hear too much of too often (Rakshith, take note ;-).

One might think that the article was all just self-promotion & marketing spiel, but this one actually had a bit of meat to it, which was refreshing.