G'day:
Yet another quick one. I was reading a post on the Adobe ColdFusion forums earlier this morning (I'm sitting on the train en route to work right now), which was discussing the recent ColdFusion "10.0.1" updater.
This raised a question mark for me: what's the new build number for 10.0.1? I like to tuck this info away in the back of my mind, because... err... well no good reason really.
Showing posts with label Courting Controversy. Show all posts
Showing posts with label Courting Controversy. Show all posts
Tuesday 4 September 2012
Tuesday 21 August 2012
The ColdFusion issue tracker
G'day:
This is just a filler post that I can write this morning on my way to work and finish of before 9am. I started doing part three of my series of articles on CF arrays, but realised I needed CF10 to do the code, and we've only got CF9 on our work PCs. So I'll have to do that one at home.
So, anyway, for most of the life of ColdFusion, neither Allaire nor Macromedia provided a public-facing issue tracker for ColdFusion. I had only just started with CF when it was an Allaire product, and never really had need to investigate bugs (it was safe to assume any bugs that cropped-up were in my own code, not theirs. This is actually generally still the case ;-). By the time I actually knew what I was doing and knew a CF bug when I saw it all I had by way of communicating this to Macromedia was the "black hole". Or as they'd prefer to call it: the "wish list". This was a simple form that allowed one to enter in a bug or an enhancement request, submit it, and that's the last you'd hear of it. Not an encouraging user experience.
This is just a filler post that I can write this morning on my way to work and finish of before 9am. I started doing part three of my series of articles on CF arrays, but realised I needed CF10 to do the code, and we've only got CF9 on our work PCs. So I'll have to do that one at home.
So, anyway, for most of the life of ColdFusion, neither Allaire nor Macromedia provided a public-facing issue tracker for ColdFusion. I had only just started with CF when it was an Allaire product, and never really had need to investigate bugs (it was safe to assume any bugs that cropped-up were in my own code, not theirs. This is actually generally still the case ;-). By the time I actually knew what I was doing and knew a CF bug when I saw it all I had by way of communicating this to Macromedia was the "black hole". Or as they'd prefer to call it: the "wish list". This was a simple form that allowed one to enter in a bug or an enhancement request, submit it, and that's the last you'd hear of it. Not an encouraging user experience.
Friday 17 August 2012
Quality of CFML documentation
[This is a "toned-down" edit of the first draft I made of this doc. The initial doc had a bit more vitriol in it than would be considered helpful. Plus I was going to have to give it an NC-17 rating for its language. It's a good thing to draft something then cool-off before pressing "send" sometimes]
G'day:
I've had a long day, some things that could gave gone smoothly didn't, and I'm in an intolerant mood. Some would say "sounds pretty much like your default setting, Cameron". Fair cop.
Anyway, I'm trying to write this second article about ColdFusion arrays (now complete... I started on this rant a few days ago), and I'm reading the official Adobe docs for inspiration (OK, not "inspiration", I guess. Anyway: I'm reading their docs).
G'day:
I've had a long day, some things that could gave gone smoothly didn't, and I'm in an intolerant mood. Some would say "sounds pretty much like your default setting, Cameron". Fair cop.
Anyway, I'm trying to write this second article about ColdFusion arrays (now complete... I started on this rant a few days ago), and I'm reading the official Adobe docs for inspiration (OK, not "inspiration", I guess. Anyway: I'm reading their docs).
Thursday 9 August 2012
Two timelines: Railo vs ColdFusion
G'day
This is just a quick bouquet (for Railo) and brickbat (for ColdFusion).
Here's the timeline of a bug that was found in Railo:
Note that this is a fairly trivial issue, and the workaround is fine. But it's now fixed, and will be released shortly.
This is just a quick bouquet (for Railo) and brickbat (for ColdFusion).
Here's the timeline of a bug that was found in Railo:
| Time | Elapsed Time | Milestone |
|---|---|---|
| 8 Aug 2012 15:10 | - | Potential bug in int() function reported on the mailing list |
| 8 Aug 2012 15:50 | 40min | Bug confirmed by community member |
| 8 Aug 2012 21:23 | 6hrs | Probable cause of bug suggested by community member |
| 9 Aug 2012 08:03 | 17hrs | Ticket raised |
| 9 Aug 2012 09:11 | 18hrs | Explanation of issue offered by Railo dev team member |
| 9 Aug 2012 10:39 | 19hrs | Bug fixed ready for next release |
| 9 Aug 2012 10:39 | 19hrs | Workaround offered by Railo dev team member |
Note that this is a fairly trivial issue, and the workaround is fine. But it's now fixed, and will be released shortly.
Saturday 4 August 2012
Hungarian Notation
G'day:
Here's another old-skool and divisive topic: the usage of Hungarian notation in variable-naming.
As a brief overview for those not interested in following the link, Hungarian notation is a convention that suggests adding a prefix to a variable name to identify the variable's type, eg "qRecords" instead of just "records", or "sFirstName" instead of just "firstName".
I think this is what Adam Tuttle is alluding to in his comment below, but I don't think he quite nails it.
AC 2016-12-30
A quick aside: either "qRecords" or "records" is a really crap name for a recordset, unless the data describes your old vinyl collection. ALL compound data structures are "records" really. Your variable name should reflect the data, not its structure or where it came from (eg: the database). I say this only because I see a lot of code with variables like that.
Anyhow, a quick summary of likely prefixes would be as follows:
(this is a bit plagiarised from my workplace, but... err... yeah well OK you caught me there [gallic shrug]).
I did my formal programming education back at the beginning of the 90s, with a lot of focus on C (and - chuckle - COBOL). One of the recommendations made in the C classes was to use Hungarian notation to make more clear what variables represented. The practice kinda stuck with me. I think this is at least partially due to my nature being slightly one of "a place for everything, and everything in its place", and I like rules, and I have had a tendency to place adherence to the rules above giving thought to whether the rule is valid ("at all ~", or just in the given context). I've recently found myself reflecting on this - I consider it a significant logic failing in the way my brain works, and is intellectual laziness - so I've been questioning some of my SOPs recently.
Anyway, I bought into the notion that carrying the data type around in the variable name was useful, so even in my home/scratch coding, I use H/N. Equally this wasn't entirely without assessing various nay-saying opinions, and basically disgarding them as facile or specious (which mean much the same thing, I guess) in the context of ColdFusion code - especially as CFML is "forgivingly" typed.
Recently we had a new starter at work: "new to us", not "a newbie", and as with any new starter moving into a senior position (or, hey, any position), he started questioning pretty much everything we do. I think we get some things right in his view, but he did raise a question mark over our usage of Hungarian notation. And for once he made a compelling case against it. When I say "for once", that's not a reflection on how compelling his cases usually are, I mean its compelling in the context of the other cases against Hungarian notation.
Basically it boils down to the notion that one doesn't actually need to know the type of the data until one comes to use it. And then the context of how it's being used will explain what the data type is. Or that - even then - one really didn't need to know that info all the time. For example, given a variable "invoiceLines", what data type is it? One can't say. But what can one say about it is:
But let's pretend we're looking through some code, and we're still not savvy as to the data type of these invoice lines. And all we have to go on is:
We need to do stuff with the variable, so need to know what data type it is. OK, if you just made that "get" call you must've had a reason to do so, and you looked up the API to see what method to call, and should have paid attention to the method's return type. So you should already know.
What if it was already being set, and you just need to do stuff with it? Well the variable must've been created for a reason. Look at the code nearby:
...it's an array.
It's a query.
It's an object.
Right, there you go: when the variable comes to being used, one can generally identify what type it is by how it's being used. If it's not being used adjacent (ie: within a few lines) to where it's being created, your code probably needs refactoring: why is it being created if it's not being used?
If you can't tell even after this point just dump the thing out and then you know. Write your code and then your code will be clear to the next person add to what the type is.
So far this was all just an intellectual exercise, and I have no control over the code I write in this regard during my day job but I'm gonna drop H/N from my own coding. I've not used it in my sample code on this blog, and I don't think it's suffered any readability issues at least in that regard.
What are your thoughts on this topic (and the readability of my code, too, for that matter)?
I've had commuting dramas this morning: the tube was down at my station, so instead of one 30 min tube journey on s single line all the way to the office; it's been bus, train, tube, and had taken an hour now. Still: enough time to write this blog entry I guess (on my phone... :-S), but now I need to crack on with some work.
[24 hours pass]
Bloody hell. Yesterday was a bit or a 'mare, and I didn't get a chance to proofread this and press "send". Then I had to go to the pub with the lads because we all deserved a pint, then 4022 pints later I got home, and collapsed in a heap. Now it's Saturday morning and I've just had a chance to proofread this, and am about right to press "send". Am very pleased, btw, that I am off to watch some Olympic boxing (of all things... I actually have no interest in boxing. Or any knowledge about it at all, other than it involving people bashing the sh!t out of each other. Should be fun) today.
Righto.
--
Adam
Here's another old-skool and divisive topic: the usage of Hungarian notation in variable-naming.
As a brief overview for those not interested in following the link, Hungarian notation is a convention that suggests adding a prefix to a variable name to identify the variable's type, eg "qRecords" instead of just "records", or "sFirstName" instead of just "firstName".
Update:
This article addresses the usage of "Systems Hungarian Notation" not "Apps Hungarian Notation" (see the distinction in this Wikipedia article: "Systems vs. Apps Hungarian"). Systems Hungarian Notation was not Simonyi's original intent, however it seems to be the one that's been most adopted. That said, I don't think Apps Hungarian Notation has merit either in modern code. Its theory is reasonable, but its approach of using abbrevs. isn't great. If yer going for clean code, then clearly and fully articulate your variable names where you can.I think this is what Adam Tuttle is alluding to in his comment below, but I don't think he quite nails it.
AC 2016-12-30
A quick aside: either "qRecords" or "records" is a really crap name for a recordset, unless the data describes your old vinyl collection. ALL compound data structures are "records" really. Your variable name should reflect the data, not its structure or where it came from (eg: the database). I say this only because I see a lot of code with variables like that.
Anyhow, a quick summary of likely prefixes would be as follows:
| Data Type | Prefix | Example |
|---|---|---|
| string | s | variables.sName = "Zachary" |
| list | l | variables.lColours = "red,green,blue" |
| integer | i | variables.iAge = 42 |
| float | f | variables.fRatio = 3.1415 |
| boolean | b | variables.bShowHeader = true |
| array | a | variables.aPeople = ["Adam", "Zachary"] |
| date | d | variables.dBirthday = 2011-03-24 |
| query | q | variables.qPeople |
| struct | st | variables.stParams |
| xml | x | variables.xAddress |
| wddx | w | variables.wInvoiceLines |
| instance of an object | o | variables.oInvoice |
I did my formal programming education back at the beginning of the 90s, with a lot of focus on C (and - chuckle - COBOL). One of the recommendations made in the C classes was to use Hungarian notation to make more clear what variables represented. The practice kinda stuck with me. I think this is at least partially due to my nature being slightly one of "a place for everything, and everything in its place", and I like rules, and I have had a tendency to place adherence to the rules above giving thought to whether the rule is valid ("at all ~", or just in the given context). I've recently found myself reflecting on this - I consider it a significant logic failing in the way my brain works, and is intellectual laziness - so I've been questioning some of my SOPs recently.
Anyway, I bought into the notion that carrying the data type around in the variable name was useful, so even in my home/scratch coding, I use H/N. Equally this wasn't entirely without assessing various nay-saying opinions, and basically disgarding them as facile or specious (which mean much the same thing, I guess) in the context of ColdFusion code - especially as CFML is "forgivingly" typed.
Recently we had a new starter at work: "new to us", not "a newbie", and as with any new starter moving into a senior position (or, hey, any position), he started questioning pretty much everything we do. I think we get some things right in his view, but he did raise a question mark over our usage of Hungarian notation. And for once he made a compelling case against it. When I say "for once", that's not a reflection on how compelling his cases usually are, I mean its compelling in the context of the other cases against Hungarian notation.
Basically it boils down to the notion that one doesn't actually need to know the type of the data until one comes to use it. And then the context of how it's being used will explain what the data type is. Or that - even then - one really didn't need to know that info all the time. For example, given a variable "invoiceLines", what data type is it? One can't say. But what can one say about it is:
- they're invoice lines;
- there's clearly more than one of them (the names is plural)...
- ... so it's a collection of some sort.
But let's pretend we're looking through some code, and we're still not savvy as to the data type of these invoice lines. And all we have to go on is:
invoiceLines = invoice.getInvoiceLines();
We need to do stuff with the variable, so need to know what data type it is. OK, if you just made that "get" call you must've had a reason to do so, and you looked up the API to see what method to call, and should have paid attention to the method's return type. So you should already know.
What if it was already being set, and you just need to do stuff with it? Well the variable must've been created for a reason. Look at the code nearby:
numberOfLines = arrayLen(invoiceLines);...it's an array.
numberOfLines = invoiceLines.recordCount;It's a query.
numberOfLines = invoiceLines.getLineCount();It's an object.
Right, there you go: when the variable comes to being used, one can generally identify what type it is by how it's being used. If it's not being used adjacent (ie: within a few lines) to where it's being created, your code probably needs refactoring: why is it being created if it's not being used?
If you can't tell even after this point just dump the thing out and then you know. Write your code and then your code will be clear to the next person add to what the type is.
So far this was all just an intellectual exercise, and I have no control over the code I write in this regard during my day job but I'm gonna drop H/N from my own coding. I've not used it in my sample code on this blog, and I don't think it's suffered any readability issues at least in that regard.
What are your thoughts on this topic (and the readability of my code, too, for that matter)?
I've had commuting dramas this morning: the tube was down at my station, so instead of one 30 min tube journey on s single line all the way to the office; it's been bus, train, tube, and had taken an hour now. Still: enough time to write this blog entry I guess (on my phone... :-S), but now I need to crack on with some work.
[24 hours pass]
Bloody hell. Yesterday was a bit or a 'mare, and I didn't get a chance to proofread this and press "send". Then I had to go to the pub with the lads because we all deserved a pint, then 4022 pints later I got home, and collapsed in a heap. Now it's Saturday morning and I've just had a chance to proofread this, and am about right to press "send". Am very pleased, btw, that I am off to watch some Olympic boxing (of all things... I actually have no interest in boxing. Or any knowledge about it at all, other than it involving people bashing the sh!t out of each other. Should be fun) today.
Righto.
--
Adam
Tuesday 31 July 2012
Comparing installations: CF10, Railo and OpenBD
G'day
I'm doing this second post today to make up for the missed one y/day. Not that I imagine anyone's day was ruined by not having a new article to read on this blog, but anyway, here you go.
I've just run through the installation processes for ColdFusion 10 (Enterprise), Railo 3.3.4.003 (using the .exe installer), Railo 4.0.0.013 (the Jetty version), and OpenBD 2.0.2 (the Jetty version).
It was an "interesting" process.
I'm doing this second post today to make up for the missed one y/day. Not that I imagine anyone's day was ruined by not having a new article to read on this blog, but anyway, here you go.
I've just run through the installation processes for ColdFusion 10 (Enterprise), Railo 3.3.4.003 (using the .exe installer), Railo 4.0.0.013 (the Jetty version), and OpenBD 2.0.2 (the Jetty version).
It was an "interesting" process.
CFCHART phones home
G'day
Sorry about the lack of post today (or yesterday, depending on your TZ)... I had some family dramas to deal with that needed to take precedence over my waffling.
This is just going to be a quick post too.
Stephen Walker put me onto this via Twitter, and all credit for noticing this goes to him.
Sorry about the lack of post today (or yesterday, depending on your TZ)... I had some family dramas to deal with that needed to take precedence over my waffling.
This is just going to be a quick post too.
Stephen Walker put me onto this via Twitter, and all credit for noticing this goes to him.
Sunday 29 July 2012
Are CFINSERT and CFUPDATE as bad as everyone makes them out to be?
G'day
This is a bit of a lazy-Sunday sort of posting. I was on the Adobe forums last week, and CFINSERT and CFUPDATE came up in conversation. The person asking the question was asking about <cfqueryparam> and I responded to that (and cross referenced to my post on that topic, should you want to read it), but I mostly left the <cfinsert> and <cfupdate> side of things alone, sniffing with distain and moving on to something else.
I decided I didn't like leaving the question unanswered, so revisited it today.
I could recall a discussion a while back about these two tags not parameterising their values, which kinda invalidates them in my view. But I decided to find out where they're at now.
I found this bug that was raised on the old bug tracker which covers this topic, and the ticket is still open so it seemed like the problem still existed. However I never trust the Adobe bug tracker because... well... err... it's just not very good and not very accurate, so I decided to re-investigate for myself. I knocked together some quick code, thus:
This is a bit of a lazy-Sunday sort of posting. I was on the Adobe forums last week, and CFINSERT and CFUPDATE came up in conversation. The person asking the question was asking about <cfqueryparam> and I responded to that (and cross referenced to my post on that topic, should you want to read it), but I mostly left the <cfinsert> and <cfupdate> side of things alone, sniffing with distain and moving on to something else.
I decided I didn't like leaving the question unanswered, so revisited it today.
I could recall a discussion a while back about these two tags not parameterising their values, which kinda invalidates them in my view. But I decided to find out where they're at now.
I found this bug that was raised on the old bug tracker which covers this topic, and the ticket is still open so it seemed like the problem still existed. However I never trust the Adobe bug tracker because... well... err... it's just not very good and not very accurate, so I decided to re-investigate for myself. I knocked together some quick code, thus:
Friday 27 July 2012
Why do CFML arrays start at 1 instead of 0?
G'day
A few weeks ago whilst investigating something completely unrelated, I came across an interesting thread on StackOverflow, in which someone had asked why ColdFusion arrays start at index 1 rather than index 0 like other languages do.
This was an old thread, but my thoughts on it were a bit different from the others thusfar offered, so I wrote up my own point of view. Whilst writing it I started to think "I wish I had a blog for this sort of thing, rather than posting it on an old thread on StackOverflow"... and it was that thought that culminated in me finally starting this blog.
Anyway, I realise it's a bit of a duplication, but I'm "reclaiming" the post for myself. Here it is.
A few weeks ago whilst investigating something completely unrelated, I came across an interesting thread on StackOverflow, in which someone had asked why ColdFusion arrays start at index 1 rather than index 0 like other languages do.
This was an old thread, but my thoughts on it were a bit different from the others thusfar offered, so I wrote up my own point of view. Whilst writing it I started to think "I wish I had a blog for this sort of thing, rather than posting it on an old thread on StackOverflow"... and it was that thought that culminated in me finally starting this blog.
Anyway, I realise it's a bit of a duplication, but I'm "reclaiming" the post for myself. Here it is.
Wednesday 25 July 2012
The holy grail
No, this ain't about Grails, sorry. I dunno anything about Grails, so anything I write about it would be rubbish, anyhow.
What it is is a follow-up to a conversation (if that's the right word) on Twitter last night regarding ColdFusion and backwards compat between releases.
Adobe treats the notion of backwards compatibility in ColdFusion as a "Holy Grail": it's often cited as one of the most important considerations when undertaking changes/enhancements to the language.
Whilst I respect "maintaining backwards compat" as a goal, I do not respect the lengths Adobe go to sometimes to preserve backwards compat at the expense of... well... doing work. I think this has lead to some inertia in the language, and has contributed to ColdFusion lagging behind both in comparison to its competitors (Grails etc), and even now its imitators (Railo & OpenBD). ColdFusion might be a RAD language from a development perspective, but it's a creaky old behemoth when looking at its release cycle and recent language innovations. Take note I am specifically referring to language innovations here, not the various plug-ins and wrappers for third-party efforts such as Hibernate and Ehcache integration.
When I say "language innovations", I mean stuff at a level I cannot integrate myself. Closures in CF10 would be an example here. Or Application.cfc from CFMX7, or CFCs in general from CFMX6.0. Continuing to improve CFScript coverage would be an example if this, too.
What it is is a follow-up to a conversation (if that's the right word) on Twitter last night regarding ColdFusion and backwards compat between releases.
Adobe treats the notion of backwards compatibility in ColdFusion as a "Holy Grail": it's often cited as one of the most important considerations when undertaking changes/enhancements to the language.
Whilst I respect "maintaining backwards compat" as a goal, I do not respect the lengths Adobe go to sometimes to preserve backwards compat at the expense of... well... doing work. I think this has lead to some inertia in the language, and has contributed to ColdFusion lagging behind both in comparison to its competitors (Grails etc), and even now its imitators (Railo & OpenBD). ColdFusion might be a RAD language from a development perspective, but it's a creaky old behemoth when looking at its release cycle and recent language innovations. Take note I am specifically referring to language innovations here, not the various plug-ins and wrappers for third-party efforts such as Hibernate and Ehcache integration.
When I say "language innovations", I mean stuff at a level I cannot integrate myself. Closures in CF10 would be an example here. Or Application.cfc from CFMX7, or CFCs in general from CFMX6.0. Continuing to improve CFScript coverage would be an example if this, too.
Saturday 21 July 2012
Joe Rinehart's thought-provoking video
Joe Rinehart released a very forthright and thought-provoking video about what he perceives to be some significant issues with ColdFusion as it stands today. If you've not watched it already, here it is:
And the URL is: http://www.youtube.com/watch?v=I1KjX5NOD7c.
I've taken the liberty of transcribing the "script" of the video here (well: I couldn't be bothered doing a 100% transcription, so it's a bullet-pointed transliteration/paraphrase), as a basis for a discussion. I hope you don't mind Joe, and if you do: let me know and I can work out an alternative approach. But just to be clear, the text in the grey box below is Joe's good work, not mine. I was just the typist.
And the URL is: http://www.youtube.com/watch?v=I1KjX5NOD7c.
I've taken the liberty of transcribing the "script" of the video here (well: I couldn't be bothered doing a 100% transcription, so it's a bullet-pointed transliteration/paraphrase), as a basis for a discussion. I hope you don't mind Joe, and if you do: let me know and I can work out an alternative approach. But just to be clear, the text in the grey box below is Joe's good work, not mine. I was just the typist.
Thursday 19 July 2012
According to ColdFusion "0,6" == "6,0". And both are integers to boot
G'day
If you participate on StackOverflow or the Adobe ColdFusion Forums, you might be aware of this already. But I thought I'd write it up again, and also solicit people's opinions on the topic.
Consider this code:
What would you expect this to output? Would you be surprised to here it outputs this:
I was, initially. My reaction was something along the lines of "WTF?"
If you participate on StackOverflow or the Adobe ColdFusion Forums, you might be aware of this already. But I thought I'd write it up again, and also solicit people's opinions on the topic.
Consider this code:
<cfset list1 = "0,6">
<cfset list2 = "6,0">
<cfoutput>
<cfif list1 eq list2>
#list1# equals #list2#<br />
<cfelse>
#list1# does not equal #list2#<br />
</cfif>
What would you expect this to output? Would you be surprised to here it outputs this:
0,6 equals 6,0
I was, initially. My reaction was something along the lines of "WTF?"
Subscribe to:
Posts (Atom)