| Server Housekeeping
Most of us prepare web sites locally on their computer, be it
a PC or Mac, and use an FTP program to "put" the files
onto a web server that is owned and managed by an Internet Service
Provider (ISP if you prefer acronyms). The reason for this arrangement
is not the cost of purchasing a web server since most off the
shelf personal computers could perform reasonably well if used
as a web server for sites with average traffic. The biggest issues
are managing the server and supplying an "always on"
connection to the Internet that has a fixed address that "resolves"
to your domain name. It is typical for a business large enough
to justify the expense to spend around $1,000/mo. for their network
access. And managing their server(s) requires the services of
an IT professional who knows how to properly set up the network
and server(s) plus keep them running with sufficient security
to keep out hackers and guard against virus infection.
Assuming that server and network management are not within your
area of responsibility, what should the web developer be doing
(or not doing) to optimize the web site and run a tight ship?
Here are a few suggested "good practices" that might
eliminate some headaches, help keep your site running better,
and improve your ability to update and maintain it efficiently.
Establish and use conventions for file and directory naming!
Most learn quickly that the use of spaces and special characters
(!@#$% etc.) should not be used in a file to be placed on a web
server. All Macs and Windows computers allow the use of spaces
in file names but on a web server they are not recommended! Use
a dash "-" or an underscore "_" instead. If
you put a file named "this file.html" on many servers,
it will show as "this%20file.html" in the browser's
address window which is likely not what you want.
Macs allow the use of various characters in file names that Windows
will not allow such as the slash character "/" that
is typically used in typing a date. A file named "update3/27/02.html"
will not acceptable to a windows computer or a web server. The
Mac based developers need to be conscious of this as files would
need to be renamed if they had to be copied over to a Windows
computer in a cross-platform environment (thus breaking links
of course) and a web server would not accept them anyway. That
file ("update3/27/02.html") will open in a browser on
a Mac and would show as "update3%2F27%2F02.html" in
the address field ... say what! And Mac users, for exchanging
files with a Windows user don't forget that Windows needs the
".psd" suffix to recognize a file as a Photoshop document
(for example) whereas the Mac knows which program created a file
without the suffix.
And Windows users also need to be careful about file names if
they ever need to transfer their files to a Mac user (OS 9.x)
because there is a limit of 32 characters to file names. The files
will copy over to the Mac but the extra characters will be eliminated
and problems will occur. I'm not going to make a big case for
cross-platform "manners" here aside pointing out that
good web naming conventions will also minimize problems developing
in cross-platform environments as well.
As to web server naming conventions, you can always tell what
kind of server you are visiting (UNIX or Windows) by changing
the case in one of the letters of a file name that shows in the
address field. If you see "/myfile.html" and you change
it to "/MyFile.html" in the address field of the browser
and hit the enter key to reload the page, a Windows server will
still show the same page because it IS NOT "case sensitive."
A UNIX server will probably show a page not found error because
it IS case sensitive and is looking for a different file. If you
had a link using "MyFile.html" in a page but the file
is actually named "myfile.html" on the server, the link
would work on Windows but not on UNIX. If you ever needed to move
your site from one server to another, there could be problems.
It is a good practice to determine how you are going to name
files and folders from the beginning and stick to that scheme.
This avoids all possible problems. My own convention is to use
all lower case characters (along with dashes, underscores, and
numbers as needed) for file names including the suffixes (.html,
.jpg, etc.). I prefer to use leading caps on directory names.
And I put all images inside an "Images" folder along
side the files that reference them and not mixed in with the .html
files. But that is my convention. As long as you think through
your own conventions, your site will be the better for it.
Clean out development files and backups
This probably seems obvious to some but I bet you don't do it.
Other might say, "who cares ... I've got the space."
Regardless of perspective, it is a very difficult task to be diligent
with especially if your time is limited and/or valuable. I freely
admit to being responsible for generating a good deal of clutter
on my sites while developing and trying various different things
only to move on and forget about the unused files (images too
of course). I also back up files on the server prior to posting
modified versions (just in case). But there are several reasons
to reduce the "orphans" (files not linked or referenced
by other files) and out-dated files.
You might find some unintended files are being listed by search
engines! That would certainly be bad for most any site. Outdated
or development pages without proper linking within the site would
not be a positive image builder.
If you don't need to work on a site for a while and return to
make modifications, there will likely be a need to poke around
and remember which files are the real files and which are not.
Try to keep development work and backups on your local machine
and limit the server's set of files to what is actually being
offered to the public. Some development programs (Dreamweaver
by Macromedia for example)
provide tools for helping to identify orphan files and a way to
easily identify local files that are not intended to be put on
the remote server.
|
