Even the most casual user of the internet is familiar with the irritating moment at which a website asks you to "Type in the characters in this image" - surely it knows what they are?!

The slightly more advanced surfer is acquainted with the reason why, too - the point is that computers can't read images! And, if you don't want spammers using automated programs to send thousands of comments/applications/requests to your website every day, you need to ensure that the end-user is an actual human. This is akin to the, in some circles well-known, concept known as the Turing Test.

The Turing Test is a test of a machine's capability to react in the same way as a human to stimuli. The classic example, often cited in relation to this matter, is of the game in which a person and a computer both respond to the same question, and another person attempts to discern which is which, given that they are both trying to impersonate the other. A computer which can succeed in convincing a person that it is human is said to have passed this test.

This particular test is orientated towards textual responses to textual questions; however, the concept of the CAPTCHA (NB: the term is ™ Carnegie Mellon University, so don't go using it everywhere :D) deals with a substantially separate issue.

The difference is twofold.

Obviously, the aspect of the human mind which is being tested for is no longer the ability to respond to a series of generic letters - it is to identify the shape of letters concealed within an image - i.e. from a set of coloured pixels. This task is of a significantly different nature.

Also, the entity (thing, person, computer etc.) which is performing the test is not a human playing the game, but a computer - the server. Therefore, the CAPTCHA-style tested is comprised of a computer trying to identify whether the entity it is communicating with is a human or a computer. This means that the test must have a firm logical grounding, in practice.

The general method for using CAPTCHA-style tests follows a structure similar to the following:

1. Receive new connection
2. Make some note of a detail which identifies it (such as PHP session ID, or IP address)
3. Generate the string (i.e. piece of text) to be disguised
4. Record it along with the identifying information
5. Write the text to an image, applying distortions and so on
6. Send the image to the user
7. Wait for a reply
8. Test if the response matches with the recorded string, and act accordingly

I've chosen to use the most common platform for this - a PHP script with the GD library. However, I have chosen to write my own script to generate the images... it's not very good. Have a look at the commenting page for some idea of how very bad they are :D

Anyway, I think that this will make a good front line against spammers (especially seeing as the comments must be approved anyway) seeing as it is a unique format, with even the image format being randomised. Shortly, as I do say on the commenting page, I will soon make it possible to register. Then, after the account is approved, no more verification images or moderation delays! Obviously, the registering system will be abused, but I can then ban accounts, and make the registering process tedious for the liar.

That's all folks! Why don't you comment me?

It's difficult to say what 'looks good' on a web page. There's no shortage of CSS tutorials, kits, and, of course, examples - but how does one actually construct one? This is my first real website, and I'm not exactly 'mature' (lol).

My Background

I'm a fan of the white background. It's a damn sight cleaner visually speaking, and hence a lot easier to read. The orange colour scheme originates in Seth Godin's blog, which is currently 9th in the Google search for "blog". :drops jaw: It's both lively and quite warm, IMHO.

And my much loved clean white colour complements it nicely - the slightly shaded in side panel (#FAFAFA) makes sure you remain interested in the primary material, as you don't get so easily distracted by another empty white space. The eye seems to gravitate towards white space.

An accompanying design-related observation is that large line-spacing is essential for good readability. Admittedly, my site is currently still very much in development - but I think (read: hope) you'll find it easy on the eye! The large grey space won't be such an issue in weeks to come, since, after adding the commenting facility to this blog/journal, I will definitely be creating an automated side-bar which fills with appropriate links and information. That hideous breadcrumb which is to be found at the top right if you visit an article (such as this one) will probably be moved over there too; I do think it's best to have one somewhere though, since the ability to jump by category is often very useful. I do wonder if Wikipedia would benefit from a breadcrumb which tracks your history of visited pages.

Font

I've switched from Georgia to the general sans-serif font. Everybody else uses it, so it appeals to the viewer's sense of continuity, and, of course, it's highly readable. I have heard it said that Georgia is highly readable on the screen, and will readily agree too - except where mathematics, equations and symbols are concerned.

My page on Euler's Identity looked horrific with Georgia, and all those little serifs. And trying to following the hierarchy of brackets just gave you headaches. Admittedly, they're still not classic examples of clarity, but they're better - trust me. I'll eventually install LaTeX, but that's still just another good intention. It's a remarkably good project, though, it must be said.

Anyway, everything's still evolving. Next generation: comments.

Okay, I admit it, I left the site unchanged for a long while.

Unforgivable.

But, now I've changed the main CSS style, I feel that I can start to develop the site's content. I'm also planning some restructuring work.

I spent this morning fixing up couple of CMS flaws. Firstly, curiously, different versions of MySQL seem to treat the timestamp type in different ways. I was getting the A non well formed numeric value encountered error at the point that my PHP script retrieved the value of such a field, when it was retrieved raw - but only on my local machine. Admittedly, my test platform and release platform should have the same versions, but I'm running Windows locally, not a version of Linux (I know, how could I?).

Anyway, it turns out that the Linux version has timestamp values returned as Unix timestamps, but the Windows version receives the textual representation. Solution? The UNIX_TIMESTAMP() function, a MySQL function which converts a column which would normally give textual representation into a Unix timestamp. Simple enough.

Now I use SELECT *,UNIX_TIMESTAMP(timestamp), so that the timestamp is returned in two ways. Then, test if UNIX_TIMESTAMP(timestamp) is 0. If it is, use the first value of timestamp. Otherwise, use UNIX_TIMESTAMP(timestamp). And then you're left with a normal Unix-style timestamp (seconds since '1970-01-01 00:00:00' UTC).

Anyway, that's fixed for now. Next project: revamp the site structure. The home page will become this blog - that's my first objective.