Technology...
I guess you are reading this because you wanted to know a little more about the technology that is sitting behind
this site. If you look below this text you will see I have broken down the technology into the various logical
layers it occupies to make explaining this a little easier for myself.
Server platform
This website is served up from a shared Windows 2000 Server-grade system (dedicated is so much more cute an all
but damn those things are expensive and since this is just a site developed using spare time that's a little
out of my sustainable budget). Naturally since this is a Microsoft operating system it will be running IIS
(Internet Information Services. It was Internet Information Server, but as of version 5 this was all changed
since IIS was doing so much else beyond serving web-traffic), it does not make sense to make the shift from
running the native web-server on a platform that it is not entirely suited for. Under win32 a well tuned IIS
setup can equal a not-so-well-tuned apache setup in terms of volume of pages served and service uptime which is
all that really counts when all is said and done.
Yes, I am fully aware of just how trivial it is to make
apache
into a fully fledged web-server on any win32 platform but realistically it cannot emulate the features of
languages like ASP flawlessly which is why I wanted a system running IIS 5 - because if I am paying for it I
want the most up-to-date version of whatever I want and I want it to be as comparatively reliable as possible.
However let us say for a moment that I was just after a purely hosting package with a dynamic scripting language,
in this case I would probably chose apache, but definetely not running on a win32 platform simply because the very
nature of a win32 lends it to be more unstable than either a well-tuned unix or linux box running apache. The major
problem with any win32 platform is that you can only tweak to the level you are allowed to, where as with an open
source solution you can tweak all the way down to the source if you need to. This alone means you can do things
which you would not dream of doing under anything else.
Server-Side Scripting
In addition to simply serving up static pages, like any other web-server IIS can accept plug-ins, modules, filters -
whatever name you are familiar calling them their role is to parse certain types of page before they are served to
the client. Normally this takes the form of executing commands which have been written into the page in a language
the plug-in understands - by default
ASP is one of the languages IIS
will interpret in this way.
As you browse this site you will notice a lot of the pages end in
.asp, this means that these pages are
processed between being read in by the server and being sent down the wire to yourselves. In other words what
you see right now is not literally what is in the file on the server - it has been processed by the server which
executed the commands it was told to which resulted in the page you see before you.
One of the ways I use this to my advantage is to create what amounts to a template into which I can insert content,
this simplifies creating pages no end, since with a few simple commands I have a page with all the right tags on and
which has the same
look and feel as the rest of the site, and if I decide to change a part of the shared
features of the site I can do it just by editing one file and have it replicate across the site instantly. With a
set of static pages that process would take quite a while.
Markup
Okay this is just a fancy name for the tags, elements and attributes that make up the source code of each and every
page, all of which need to be passed to your browser for you to be able to see it.
Some of you who understand a little more about the web will no-doubt be thinking
you mean html, not markup!
well no actually I do mean markup as that is the generic name given to a language that enables text to be displayed
in the format you come to accept as websites. Why would
html be the wrong term? Well technically this page
(or any other on this site) is not actually html since it does not attempt to conform to the html specification.
Instead it conforms to the
xhtml specification which superceded html and has more in common with
xml
than it does html (it is in fact the cross-over language between pure xml and compliant html) so you can see why
calling it html doesn't work, so borrowing a leaf from the book of the
W3C
who came up with these standards I opted to call this markup.
If you didn't know already I am quite fanatical about having a standards compliant site, since I also like new
technology (such as the XHTML) this ended up being a solidly written website using a very modern markup language,
the sole objective of which, is to separate the content and layout from the design and styling aspects on a page.
Styling
Until quite recently the only way to make your site look good was to make use of styling attributes of the tags
that made up your page but unfornately this meant that you often ended up re-coding pages for different browsers,
not to mention requiring separate printable versions. Heaven help you if you did not use one of the mainstream
browsers.
Once the major browsers began to support the style attribute and CSS (style-sheets), designers had a way to make
specify how their pages should look in a format which was largely un-ambiguous. Not only that but they needed to
contain less text, which meant it ran faster (since a single CSS file could style an entire site), you could avoid
browser compatability issues by simply creating a CSS file for any type of viewing device you needed to support.
With a new set of CSS files any new styling could be tested and rolled out across your site with no extra work
required, and most importantly this made your page accessible to more people than it was possible to support before,
including those with alternative browsers, handheld devices, or people with disabilities who have special
requirements for browsing the web.