Showing posts with label Brian Sadler. Show all posts
Showing posts with label Brian Sadler. Show all posts

Tuesday 15 July 2014


I'm frickin' lousy with dates (as in "calendar", not as in "romance". Although the same applies, from memory ;-). Well: remembering dates is never a problem, but remembering what the current date is is something I'm not so good at. I forgot to touch base with my big sister on her birthday over the weekend... and there's another anniversary on the same day.

I've been doing this bloody blog for two years now. Which is approximately 23 months longer than I expected it to last.

Last year I gave you some stats ("1"). I'll try to do the same now.

  • I've now published 750 (this'll be the 751st) articles. I still have about a dozen in progress. The same ones as last year, funnily enough. The topics just don't have legs, I think.
  • And the word tally is now up around 600000 words. So in the second year I didn't write quite as much as the first year (350000), but spread over more articles (428 in the last 12 months vs 322 in the first year).
  • I've had another 3000 comments since the previous year's 2000. That's pretty cool. Thanks for the contributions everyone. Often the comments are more interesting than the articles, I find.
  • Google Analytics claims I've had 86000 visitors over the last year (up from 25k in the first year). So this thing is getting more popular. The average per day is 230-odd. It was around 120/day in year one. It's still not a huge amount of traffic, but I guess my potential audience is pretty small too.
  • The busiest day in the last 12 months was 5 March 2014, with 593 visitors. That was towards the end of the isValid() saga, with this article: "ColdFusion 11: Thank-you Carl, Mary-Jo, many other community members and indeed Rupesh", and a click-chasing one entitled "CFML is dying. Let's drop it off at Dignitas". Looking at the analytics, that was the bulk of it, plus I was writing a lot about new features in ColdFusion 11 around about then, which boosted things. That was also my biggest week ever, by quite a margin.
  • The most popular article last year was the one about me migrating from "ColdFusion Builder to Sublime Text 2". That's had 2200 visitors. The next most popular were as follows:
  • The most +1'ed article was "I am one step closer to being unshackled from ColdFusion". It's interesting that that was the one that people liked the most. It had 13 +1s. Most articles get none or maybe one, so that's quite a lot.
  • Last year I worked out which article had the most comments. I have no idea how I did that, and I can't be bothered working it out again. So erm... that'll remain a mystery.
I've blogged a lot about ColdFusion 11 during the year... what with it being in public beta and then being released. I've also compared its functionality to Railo's equivalents. I've shifted my primary dev platform at home to Railo now. I've done a lot of JavaScript over the last 12 months (I've spared you most of the detail), but haven't progressed in other languages as much as I'd like to. That's my mission for the next year.

I battered Adobe a lot about how they (don't) handle their bugs. I will continue to do this. They're long overdue for an updater to ColdFusion 10, for one thing; plus we should have had at least a coupla small updates to ColdFusion 11 by now.

The biggest shift in my coding practices in the last year has been down to reading Clean Code, and adopting a lot of its suggestions. My code is better for it. I've got my colleagues Chris and Brian to thank for this... both the encouragement to read the book, but also keeping at me about it. Sometimes to great irritation on my part. If you have not read that book: do so. Especially if you're either of the two members of our team who still haven't read it. Ahem.

Another thing I've been fascinated with this year gone is TestBox. I love it. I am looking forward to shifting off ColdFusion 9 at work so we can start converting our MXUnit styled tests to BDD ones. Brad and Luis are dudes.

I've bitched a lot about Stack Overflow, but contrary to what I threatened ("Not that it will really matter in the bigger scheme of things..."), I still answer questions there every day (if I can find questions I can answer, that is).

Railo continues to rock. As do Gert, Micha, Igal from Railo. They really have done brilliant work keeping CFML alive and interesting.

A bunch of people have motivated me to write this year... it's too difficult to pull out a list of the main miscreants, but Sean would be the top. And the list of my various muses (or adversaries!) is - as always - on the right hand side of the screen, over there.

Gavin deserves special mention, as he very kindly tried to raise money to get me across to CF.Objective() ("Shamelessful plug"), but we had to kill that plan just as it was getting started ("Do not sponsor me to go to CF.Objective()"). But happily Gert stumped up with a ticket at the last minute ("Well that was unexpected"), so I made it anyhow. I really am taken aback by you guys. Seriously.

And of course Mike from CFCamp paid for my entire conference last year too ("CFCamp 2013"). That was amazing. And I mean both Mike's generousity, and the conference itself. Go to it this year if you can: CFCamp.

Ray's done most of the work for ColdFusion UI the Right Way, but I've helped out a bit. I'm glad we got going with that project.

Thanks for your participation in this blog, everyone. If you weren't reading it or commenting on it, I'd've chucked it in. But you keep coming back. Cheers.

Oh and let's not forget: <cfclient> sucks arse. And I can tell that without using it, Dave Ferguson ;-)


Saturday 21 September 2013

CFCamp: what am I seeing on Day 2?

I'm sitting in the pub in Portumna, having completely my paternal input for the day, and just killing time until it occurs to me what else to do. And drinking Guinness (end of pint one). It will distress my mate Brian - with whom I was discussing this at the pub in London on Thurs - that I truly cannot detect a difference in a pint of Guinness served in London, and one served in Ireland. That said, they're both good.

I've not been doing any interesting coding in the last couple of days, and I am still digesting my last Ruby tutorial, and don't even have anything to complain about (well, OK, I could come up with something, I'm sure, but I'm in a happy mood so will leave that for next week ;-).  What I am is jealous of all the chatter from people reporting on the first day of NCDevCon, and the ongoing chatter about StrangeLoop over in the States. But of course we (in Europe) have our own conference coming up: CFCamp. As I wrote earlier I'm off to it, and I've given you my thoughts on which sessions I'll be attending (probably) on Sunday/Monday.

And now for Day Two...

Thursday 18 July 2013


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


Saturday 4 August 2012

Hungarian Notation

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


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
(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:
  • they're invoice lines;
  • there's clearly more than one of them (the names is plural)...
  • ... so it's a collection of some sort.
That's without any indication of data type; is is - however - a fair appraisal of what's going on.

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);'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.