November 30, 2009

Recently I was asked to create a CAPTCHA interface for a form. Other than the pretty cool browser plugins already available, support for CAPTCHA in ColdFusion is pretty easy, considering that CF9 supports it with the CFIMAGE tag and tags such as LylaCaptcha have been around for a while.

I’m not going to provide details on your implementation, but much rather some useful tips for adding CAPTCHA to your page.

Firstly, make sure that users have to use CAPTCHA as little as possible. If a user has successfully posted a form with CAPTCHA once, assume that they are human for the rest of the session, or at least until what they wanted to post has been validated and completed. There is nothing more annoying than having enter CAPTCHA over and over again.

Secondly, if other options are available, use them. For example, if you are targeting “robot” submissions, add a hidden field, and enforce validation that the field must be empty. Common robots just fill in all fields with crap containing URLs and advertisements for viagra. They rarely leave a field blank, so this method can work.

Another option might be to just ask the user a question, e.g. “what colour is the sky”? Or “please enter the word “yes” below. You could even have a button populates the answer using javascript to save the user some time.

So, if you’ve investigated the options above and still have to use CAPTCHA, here something that can make it easier for users to remember the string.

Consider the two CAPTCHA’s below. Which one is easier to remember?

FgSaNF or GaTsIF?

jGuSlR or kArDeF?

ajfhes or heslor?

The secret comes from the ordering of the letters – the first sets (green) are simply random. The second set (red) follows a consonant-vowel-consonant pattern. Many words follow this pattern (dog, cat, cure, full, wombat, copcar, tophat, hello, cassette, mustache to name a few), so it’s easier for users to understand.

Note that alphas and vowels are represented by the two strings declared at the top. Currently all characters can appear as likely as each other. One could make some characters more likely to appear than others by inreasing the numbers of characters in each string, e.g. "aaaaaeeeeeeeiiiioouuu" would make "a" and "e" more likely to appear than "o" or "u".

To take things even further, consonants such as "th", "ch", "ng" could be added to the list, but this would require the addition of a delimiter to the mix.

I saw this as a gap in the FarCry CMS, in which every site I have built using this CMS seems to have a requirement for. The big advantage of using jQuery over a technology such as flash is that it does not rely on external plugins, so will work reliably in more browsers.

August 27, 2008

I had really low expectations of Sitecore, I must admit. I have worked with 4 different content management systems in the past, and frankly, while they did the job they were pretty sucky. Corners were always cut, things were never “finished”, at least in mind.

The truth is that anyone can write a CMS. They are the simplest of applications. Basically you load stuff from a database and chuck it on a page. Anyone can do this, even the most lazy and retarded if programmers. And, where they all fail is ironically, the most important parts – interface and performance.

Sitecore is the first CMS that does things right. Although the interface is pure overkill it is practical – each of the different stakeholders needs are catered for by different areas – a content editing application for editors, a development application for devs, and an onsite design/edit system for business people who like to play with shiny things.

On top of that, a desktop interface has been created which allows you to have all your interfaces open at the same time – f***ing brilliant!

Furthermore, it’s got enough of the latest features to give any developer a hard-on – native XSLT support for displaying content, component scaffolding, a plethora of methods to format and display data.

The concept of a sidebar that contains descriptive content next to the main content in a HTML website is so gay. Sidebars are just stupid and they should have been banned from HTML. You see, no-one ever reads them. They violate the concept of flow in a document and pretty much just piss off all the people who have spent sleepless nights trying to get a 3 column fluid layout working in all browsers just because some selfishly naive designer thought it was a “good idea” at the time.

Once again, sidebars are so gay. No one ever reads them. They are a waste of time.

Edit: Interesting to note my site is now completely sidebar based. Oh how times change.

August 18, 2008

I have been a long term developer and supporter of the ColdFusion cause. I have been developing in the language for more than 10 years and have come to appreciate it as a convenient and reliable way to build web applications.

What is ColdFusion, may you ask? Well it is an application server language. In it’s day, people paid for this kind of thing, but these days application server languages are mainly free and/or cheap to install. However, Cold Fusion is not free, and it’s not that cheap. Anyway, that is beside the point.

The thing is, ColdFusion has not changed much in the last 5 years, well not in my mind, at least. When ColdFusion MX came out in 2004 it was groundbreaking, extraordinary. The whole thing was re-written in Java. While it was not as fast as it’s predecessors it became reliable, and so many new things were added on – component support, web services, native Java support – it was such a breakthrough that it made any later release seem like a bugfix more than anything else.

And in my mind that is exactly what CF7 was – a better working version of ColdFusion MX. Sure, it had some fluffy cfdocument tags thrown in and some minor syntax improvements but nothing revolutionary. CF8 introduced .net support and image manipulation, as well as better performance, but let’s face it, most people were using .net via web services (which is more standardised albeit less efficient) and using tools like CFC_Image to manipulate images. Furthermore, developers had started to adapt their practices to match the performance limitations of CF7, which, involved implementation of best practices anyway. So, CF8 wasn’t of any big help, to me at least.

It leads me to consider that Adobe has effectively “shelved” ColdFusion – some people are baffled by this concept but let me explain. Consider that Adobe sells 1000 copies of ColdFusion every year – lets face it that even this figure is ambitious considering that most people don’t need to buy a copy of CF every year and that many new projects are looking to start in Java or .net these days. Anyway, 1000 copies equals around 4 million dollars, given that all copies are the enterprise version.

However, Adobe would only receive half of this due to retail markup and distribution costs. Out of this comes marketing, admin, and support costs, which might leave around a million dollars for Adobe to play with. Consider that the average developer costs 100K per year and say that they have 5 or 6. Then there might be a manager or two, or even a tech lead who gets a little more – after all this Adobe might get a little profit – then there’s taxes… Which leads me on.

Adobe ask for around 25K for an enterprise license of LiveCycle, which, like ColdFusion is a Java based app that generates business documents (no, really) – Yet they can only ask around 4K for a ColdFusion license – why would this be so if Adobe hadn’t realised that about 4K is all they are going to get before they start scaring developers off? So it leaves them between a rock and a hard place.

Given that ColdFusion is pretty well established as an app server, in that it is relatively bug free and reasonably reliable – do they even need to continue development, or just shelve it and use it to push their *other* front end products? I would be leaning toward the second option.

Which leads me to the next point. In my mind, ColdFusion is “old hat” – while it was excellent in the 90’s and pretty good for the first half of this century, it’s becoming out-competed by the likes of .net and Java – not due to ease of development nor performance, but simply because more people out there know Java and .net – these languages are taught widely and are more trusted, simply due to the reputation of their respective vendors.

As said earlier, Adobe are between a rock and a hard place – and this is supply and demand in action – if they made it cheaper, more people would use it. However, then they would need to increase support and invest in their reputation as an application services vendor and for that they would need money, hence they would need to increase prices and effectively kill demand.