Your site is playing host to a competition. You’re giving away a nice hefty prize. A TV, a mobile phone, a holiday perhaps for the winner and his or her mates. And the competition revolves around a pure computational figures – how many times someone votes for whatever you’ve uploaded – a picture maybe. A video, or some prose.
The big problem here is that there are some quite savvy users out there who will go almost to the ends of the Earth to win these competitions. And then what if you run another competition and you find the same set of users is trying to manipulate the system again? How do you control this and make sure the people who aren’t cheating get a fair shot at the prize?
That really is the question. How do you stop people cheating? Simply, you can’t. The longer version involves some methods that will certainly help to reduce the amount of cheating that takes place.
One of the first methods is to force people to enter valid email addresses to register – you send them an email and they can’t log in until they’ve activated using a link in the email. The link is usually encrypted and can’t just be guessed. This falls down though when you realise there are sites out there specifically designed to give you temporary email addresses for registering for sites. And the whole process can be scripted by someone with a bit of nouse.
So you make sure that users on your site can police the content for you – they flag it, and you delete it if you feel it’s contravening your terms and conditions – oh yes, and make sure the terms are bullet-proof. Make sure winners aren’t automatically decided by a computer – decide with “judges”.
Good stuff – we now have a user policed site where the users have to have access to the email account, and we’ve even put a CAPTCHA on the registration process to stop computers being able to automatically sign up.
These are wily users though. They’ll still try and get the prize. You could do any amount of verification though but at the end of the day, having a mechanism in place to remove offending users from a competition, or just to pick a different winner is probably the best failsafe. OK, so the whole process can’t be automated – most of it can – but you wouldn’t want to give that one user a TV, a holiday, and a few grand one after the other would you?
It’s well known that Flash makes sites look better. Isn’t it? Well only if you are stuck in the early part of 2000.
I would like to draw your attention to a few sites that use no Flash at all to get their desired effect across:
These are all great sites, some better looking than others, but it’s the technology I’m focusing on here.
Flash is good, but not when it’s used to make an entire site, or to replace content areas that don’t need to be Flash. Use it for videos. Use it for the analogue clock on bbc.co.uk, at least until SVG takes off and you don’t need to use Flash for that any more. Just please don’t use it as a replacement for real websites. Flash, as much as Adobe might say otherwise, still isn’t accessible, and most of the sites that I’ve seen built in Flash are a nightmare to maintain, and look horrendous.
Rant over.
Content distribution, now for the masses
We’ve known about Akamai, who’ve been long regarded as the leaders in CDN technology for some time now. As of a few weeks ago, there’s a new kid on the block.
Amazon released CloudFront on the 19th November, and it’s what I think has been lacking in their S3 storage solution that now makes Amazon a key competitor on the CDN front. That of what Amazon have termed “Edge Zones”. Nothing particularly complex in the definition: You upload your content, and you can have Edge Zones in the USA, Europe, Hong Kong and Japan. Amazon will automatically fetch the data from S3, cache it at the Edge Zone location, and from that point forward the transfer time for your users will be blistering!
I fully expect to see some really innovative uses coming out of this and we’ll keep tabs on it here and keep you abreast of the happenings. If you’ve got a project you’re working on that uses CloudFront, feel free to comment here. It would be really good to see the different uses people have for CDN tech.
For now, that is all. Back later with more fresh goss from the Tech world.
Yesterday, peering to McColo, an ISP accused of providing the transit for 75% of the world’s spam, was shut off. VNUNet and The Washington Post both talk about where the figures come from. I’d like to explain what this can potentially mean to the advertising world, and some realities that need to be checked first.
Connectivity
With 75% less email travelling through the pipes that make up the Internet, there is a huge amount of space freed up for people visiting legitimate sites, chatting on IM services, or sending legitimate email, amongst all the other things that happen on the Internet. That means potentially faster connections to websites that are located elsewhere around the world.
Email advertising
With less spam being sent, emails sent for legitimate marketing purposes will slowly get better and better spam ratings as less spam means it will be easier to spot the rogues coming through. This means more flexibility with email content, and therefore a greater ability to be creative in email campaigns.
Realities
This is great news. One problem though. Botnet owners (the people who “own” the networks that send the spam out) are a bit like parasites. They’ll quickly enough find another ISP to latch on to and reconnect with their zombie machines.
On the other hand, one email provider kindly gave me a graph from their spam filter over the last 7 days. It clearly shows a massive reduction in spam coming through the system in the last couple of days – the time in which McColo has been off-line:
How spam works
Spam is one of the very reasons why spyware (malicious software that sits on your machine) exists. Often, it turns your computer into a zombie machine. Ever found that your downloads are stupidly slow or you just can’t access websites? That may be because you’ve installed something and one of the botnets now controls part of your machine. They call home, and await instructions. When someone gives out those instructions, every zombie connected goes and sends mail out. This reduces the workload of the botnet owners and the requirement for them to have a whole host of computers for sending spam out. They just use us, like a virus uses us.
Can we expect change?
Maybe. If peering providers (the major ISPs that provide backbone services to the Internet) are quick enough to notify each other of the botnets, and they’re cut off at the source. However, if this particular set of botnets have lasted this long, how long would they last with a new provider. I guess we’ll find out soon enough, if spam levels return to normal in the next few weeks.
"It Doesn’t Work"
“The site doesn’t work.”
“What do you mean, the site doesn’t work?”
“It just doesn’t work.”
“So what is it doing that it shouldn’t be doing?”
“When I go to the site, I can’t do X.”
“But when I go to the site, I can do X.”
To a developer this is an all too common dialogue between someone looking over the site – usually someone non-technical, and definitely someone who hasn’t read up on Reporting bugs effectively.
After development comes testing, and during testing, bug reports are made. If the bug reports are unclear in any way, then it takes more time to fix them, because it takes more time to decipher their real meaning. So what this article is about is understanding the core elements of a good bug report, and why “It doesn’t work” is bad.
From the perspective of a developer, a good bug report consists of a specific set of things that must always be there in order to be able to replicate it. Without the ability to replicate a bug, the chances of it being fixed are very slim. The above article by Simon Tatham, a very well regarded developer, of PuTTy fame, is probably one of the best groundings I’ve seen for writing good bug reports for software, and it extends to web applications and sites too. The first of these things is a concise but clear summary of the bug. One line is enough – just something that describes the issue, eg. “Firefox 3.0.3 prevents upload of multiple files in new messages”. That’s a good summary that with some additional information as described below is the formative part of a good report.
The concept of “Show me how to show myself” is crucial here. What’s needed is a step by step set of directions by which you came to see the bug. The developer may well not have used the application in this way, and didn’t expect it to be, but users will always do the unexpected! If the issue is a display issue, take a screen shot, and include the whole window, not just a bit of it. If it’s a browser issue, and this happens a lot on the web, the developer needs to know which browser the issue happens in. If the same issue happens in every browser, one screen shot will do, but a comment to that effect is absolutely necessary. There are also some key facts that should be included with any and all bug reports: Operating System, Browser, Browser version, URL on which the error occurs. Some other useful pieces of information, depending on the bug report are: Flash version (or that it’s not installed), JavaScript status (on / off). If you think there are any more, there probably are, so feel free to comment on this article.
So, to conclude, we need a good summary (usually marked down in a subject field if you’re using a bug reporting system), a set of facts about the machine you’re seeing the issue on, a clear set of instructions on how to reproduce the bug, any additional information the developer might need to reproduce the bug, and if you can, a screen shot or set of screen shots to show the developer the problem you’re seeing.
Recent Comments