If you are anything like me, everyday you are smothered in a stack of emails from various companies all delivering html formatted, image heavy flyers persuading you to buy whatever dead horse they are flogging. I know it is my own fault, after all I signed up to them in the first place, I've only got myself to blame. As I find myself checking (and deleting) these email on an Android mobile device now it has become hassle-some. So I set out to unsubscribe from the majority of them, which is where the inspiration for this article came from.

In a short period of time I have unsubscribed from around a dozen different email newsletters, and because of this the differences in the methods used to accomplish this have become glaringly obvious. I was very surprised at the variations in the methods used, some are very user friendly, and others are very much not. I won't name the companies involved.

Case one:

By far the easiest user interaction, this is a simple link from an email that provides you with a screen confirming your UN subscription. No prompt is required from the user, you are simply unsubscribed. All the data is passed seamlessly behind the scenes.

Case two:

Almost the same as above except that you are taken to a screen where you have to commit an action. You are presented with a screen displaying your email address, and prompted to click a button to confirm the UN subscribe action. This may be a handy safety net to step errors from the casual clicker.

Case three:

Clicking on the link from an email takes you to a generic page with a form on it. They have not transferred any form of token from the email so you are prompted to enter the email address you want to UN subscribe. Entering your email address takes you to a screen confirming your action. This additional step is unnecessary, and doesn't add any value at all.

Case four:

In this scenario we are passed to a page where we have to login. The subscription details are attached to an account application, and as such your credentials need to be verified. Based on passing an encrypted token from the email a user could easily be logged in automatically. Actually requiring a username and password adds an additional level of complexity. Once I logged in I then had to navigate to the subscription settings and choose to unsubscribe with a form similar to the ones mentioned above.

Case five:

In the most convoluted example I have come across so far I actually had to create an account. I arrived at the UN subscribe page and found that to subscribe did not require an account, but to change my subscription options did! This was a very strange scenario, requiring a user to create an account to stop emails. Once you have created an account the subscription options were managed through a form like the ones mention above.

Conclusions

I think the thing to keep in mind with functionality like this is the balance between usability and the business objectives. An obvious point to note is that businesses do not want their users to UN subscribe to their emails. This is their user base and they do not want to lose it. Still it is worth considering just how you interact with your customers, even when providing functionality you do not want them to use.

After all you can always just 'Mark as Spam'.

I've been developing in more and more random locations recently, and finally got fed up enough with manually moving and synchronising my own (local) development code that I've switched to an online SVN repository.

I used to use Beyond Compare for file syncing different code bases, instead of revisioning. It is good, but it isn't particularly quick, and you have to be thorough as it is still very easy to miss a file.

I had an online repository provider recommended to me, http://beanstalkapp.com/.

I've been using them a few weeks now, and they seem really good. They are always 'up', and the connection holds a good speed. There is even a free account if you just fancy trying it out.

The problem I had then is that my code was nicely versioned, and synchronised, but it was not on my live server. Pushing files up to live still required me to know what files had been changed, which is not ideal.

As I use Eclipse I thought I'd search for an Eclipse based FTP client, I've had no luck though, I just can't find an Eclipse based FTP synchronisation tool!

Luckily I had previously used Beyond Compare, searching around in their documentation it turns out that it can also handle local-to-ftp file/folder comparisons.

So for now I've settled on these applications, they both seem to allow me to release stable complete code versions. It would be interesting to see what toolset other developers have arrived at. I've had some exposure to GIT and ANT, but this seems a more comfortable process.

One of the more overlooked forms of testing (you do test don't you?) is regression testing. I'm a big fan of scripted testing using both scripted tests to actually run against your code base (think cfUnit or Junit) and scripted testing as in a basic word doc of testing instructions.

This word doc can be as simple as 'click button N' - what displayed on screen? You can literally just list the actions, expected consequences and actual conqequences.

Regression testing is the practice of going back after a release and testing the functionality that was already present. IE did you break anything by releasing your new functionality. Often the business and IT focus is on the shiny new development, not the integrity of the existing application.

Developers in particular are guilty of zoning in on the specifc area that they are directly involved with. This can sometimes lead to other areas suffering, especially if you have an OO application layer. In just how many places is each individual object referenced? A change to it may work in one area, but have devastating consequences in another.

I've seen cases of this where its been months later before an error has reared its head, and without an accurate change log it can be difficult to track the root cause down. Needless error tracking and bug fixes take developers away from actually developing, and essentially cost the business money due to bad practice.

I mentioned scripted testing above as it has had unforseen beneficial consequences. If you have done anything like this in the past, your regression testing will be very easy. You will have a handy library of repeatable scripted tests, so it is very easy for you to measure the previous results against any new tests you might perform. Thus making it instantly obvious wether your functionality is still behaving as it was before the release.

One of the more common problems with a ColdFusion application, especially when it starts to grow or involves more than one developer is variable scoping, and scope bleed through issues. More recently I have had to re examine the framework of an application, in an effort to track and eliminate any instances of this.

Not properly scoping a variable, IE:

Forces ColdFusion to add the variable to the 'variables' scope. This scope is available to the entire template. This is even more important when you consider CFC's and the potential damage that a leaked variable could cause. One of the major benefits of OO in ColdFusion is the encapsulation that it provides. As soon as you start declaring un scoped variables, then you lose that.

Mike Schierberl has quite an in-depth blog about this subject, http://www.schierberl.com, he goes into a great deal of depth about this subject, and he has built and maintains the varScoper project. The varScoper allows you to scan your code base for un scoped variables, and after a quick inspection of its output it seems very reliable. I'm not sure its 100% foolproof, but would be a valuable addition to a QA process.

Changes to the Var scope in Coldfusion 9

I am currently not using ColdFusion 9 in any environment; in fact my hosting company is still on 7! That said it appears that there are some significant changes to the Var scope in ColdFusion 9.

Ben Forta sums it up nicely here:

http://forta.com/blog/index.cfm/2009/6/21/The-New-ColdFusion-LOCAL-Scope

He does touch on an interesting point in the article above. I quite like the structured layout of a CFC, and part of that regime for me is declaring all the Vars at the top of a function. It sort of matches the layout of an Action Script class as well, declaring all your constants etc at the top of the script. It is also a very easy coding standard to adopt and enforce if you are part of a larger team.

A recent development involved some changes to a large script that was using a product called ImageMagick (link). It is an image manipulation tool that allows you to perform transformations and other actions on image files. The product seems stable enough, and can be executed from a web interface using cfexecute, in a kind of command line prompt method.

It got me thinking as to why the application wasn't using cfimage, and then lead me to examine the wider topic of whether to use ColdFusion's in built functionality, or opt for other third party products.

I can think of a few obvious deciding factors for both pro and con, the first that springs to mind is performance.

Is there a marked performance difference between a ColdFusion function, and the third party application? Is it better to pass the load of to the operating system, rather than have ColdFusion perform whatever processing function it is supposed to do? In this case it would be a race between cfexecute, and cfimage, so there may be very little difference in it.

The second major point that springs to mind is the knowledge base of the developer, and the structure of whatever framework you are using. What I really mean by this is 'if your chosen technology can perform a function, why not utilise it to its full potential?' . It seems a bizarre choice indeed to deliberately not harness a function that your platform can already provide, and instead introduce another code base or application into the framework.

It also introduces another hurdle for the development staff, they may well be familiar with how an existing Tag works, but be totally unaware of the third party application, as was my case here.

A long winded intro, but here is the code I used:

I've dealt with Cross Site scripting (XSS) attacks before ( http://www.mccran.co.uk/index.cfm/2009/4/6/Cross-Site-scripting-hack-test-form), so I'm familiar with the principles involved. In this example there is a subtle difference.

In the example above the vulnerability was created by POSTING a text string through the form action. In this example we will examine a similar vulnerability using GET. IE we will simply pass the attacking string through the url of the form, setting the form field value in the traditional 'url?variable=N' way.

To demonstrate this create a simple form:

Call your form in a browser. Now append on the end of that url the text string below.

?attributes.formValue==>"><%2Ftitle><%2Fiframe><%2Fscript><%2Fform><%2Ftd><%2Ftr>
<%2FIfRamE>

Reading through the string you'll notice that it is an Iframe constructor that is calling a url, in this case www.Google.com.

As the url is setting the value of 'attributes.formValue' this will be inserted into the form on the submit action. We are not posting it, so it will not be picked up by any custom POST action code.

One interesting point to mention here is that testing this in IE 8, it will actually be blocked by default, as it has detected that scripts are running over different domains.

So if you are in the habit of writing POST detection scripts, make sure you handle any other submissions as well!

Recently I was looking at the scalability of a web platform, and had to perform some stress analysis on it to evaluate whether or not it would accommodate the potential user base for a new application.

The idea was to pose the question:

"N percentage of web pages should load in X seconds, with no more than Z percent errors."

[More]