1.Put your local software in the /usr/local tree.
2.Pick up a scheme for naming and storing your Web documents and programs.
3.And most importantly, stick to your organizational scheme.
These won’t make any sense unless you commit to them for the long haul. Spending a lot of time setting up an organizational scheme won’t work unless you’re able to do it. If you find that you cannot organize when you have a deadline, simplify what you pick and make it a part of our life.
Local Software
What is local software? Local software is local. It’s not part of your original system distribution. It’s the software that you’ve added. This is software that will need to survive future upgrades. Installation of your Web server software is a good example. You should store it in a way that makes it easy for you to upgrade both your operating system software and the software you have added.
Many software upgrades will replace, without impunity, programs that they find in the standard UNIX directories, such as bin, etc, and usr. If your modifications are to survive operating system upgrades, you’ll need to find a place where these programs can happily coexist.
A good place is in the /usr/local tree. This directory can be the entry point for programs that you add. A good model to follow is to mirror your UNIX software like this:
Put all binaries that you add in /usr/local/bin. This makes it easy for users to find and easy for you to maintain. If you upgrade a program to a new version, which is also included in your operating system release, keep the original in its place. Set /usr/local/bin in your path, ahead of the other system directories. You can do this by adding an entry to your PATH environment variable. Where this is done depends on the shell you are using. Typically, this will be in the .profile or .cshrc files in your home directory. Note that these files start with a period, so they normally will be hidden from view.
In the .profile file, the new path addition will look like this:
PATH=/usr/local/bin:/usr/ucb:/bin/...
Note that the paths to the directories that search for executables are separated by colons. Directories listed first are searched first.
If you are using the csh (c shell), you will want to put an entry into your .cshrc file. This is the same as your .profile entry, but the csh syntax for defining the environment variables is a little different:
set PATH=(/usr/local/bin /usr/ucb /bin ...)
Under the csh, multiple paths are separated by spaces and grouped together with parentheses.
Other directories, such as /usr/local/etc, contain the Web server tree. Storing it in its default place removes one source of potential problems. By keeping the default installation location, future upgrades will find the files in their standard locations. Moving default installation locations without having a really good reason for the change is asking for trouble. Future upgrades won’t work properly because they will not be able to find supporting files, and you will be required to spend time hunting for the problem.
Having a written organizational policy will help cast in stone the structure of your site. If everyone decides on their own where to place files, you’ll end up with a mess. Software will be installed and configured wherever someone felt that the files should go. Perhaps, they were installed on top of your system’s distribution—a practice that often spells disaster if later you find out there’s a bug, and the version that came with your operating system worked better!
An organizational scheme permits you to easily back up software you have added. If you need to install an additional machine and want to upgrade some of your customizations, the process is simplified and becomes really easy. All you need to do is copy the /usr/local tree, and everything is there. From that point, you can either opt to remove software you won’t need or just keep it. The UNIX rdist command can be very helpful in maintaining multiple identically configured systems in sync.
Should you ever need a backup, a quick tar -cf /tmp/usrlocal.tar /usr/local will take care of the problem. You don’t need to differentiate or select from various places that may contain files you added. It’s all kept together.
File Packages: Organizing HTML and Resources
The concept of page wrapper was developed at accessLINK. A page wrapper is no more than a directory that keeps all relevant resources (images or additional HTML files) grouped together in a bundle. The concept is hierarchical, so ideally you would group a section of multiple page wrappers together into a section.
Grouping HTML files into a page.htmld directory is a good way of keeping tabs on files (we group root trees in a sitename.ws wrapper; ws stands for Web site).
My experience has been that if I create a directory that contains all the necessary resources for an HTML document and group it all in a wrapper, it becomes easy for me to maintain that page. The system also enhances the recycling of disk space. If you are working on a HTML file and you remove a reference to an image that is stored in a different directory, it’s likely to remain there. If it is near your HTML file, more than likely the file will be discarded, freeing disk space for other things.
This organizational scheme works best when several people are responsible for keeping a site running. When a document needs to be updated, the location of all the related resources are stored together and nicely packaged. The alternative is chaos. In a normal scenario where forty HTML files are stored at the same directory level along with associated resources (such as images or videos), it becomes impossible to determine what needs to be done. To figure out referenced images in a file, you have to look at the HTML code and search for the tags for the image filename. With the wrapper, much of the chaos is removed and the structure is simplified. By simple inspection of the directory’s contents, you can find what you are looking for.
It’s no miracle that this basic structure also happens to follow the physical structure of the site. The directory structure mirrors the navigational structure, providing another level of reinforcing the way the site is organized for people who update and manage this site. Just by navigating it, you have an understanding of the physical layout of a site.
Additional Benefits of the Wrapper Approach
This approach works in several levels. It allows you to name graphics and resources generically, such as header.jpeg. However, the generic name works fine because more than likely there is only one header file, not a hundred. If you were using one general graphics directory, each graphic would need a unique name or some other cryptic-naming scheme. By localizing resources near their point of use, each name is descriptive, clear, and readable. This also removes a lot of the creativity involved in inventing filenames. The context of the file provides information about what it is, so you don’t need to peek into the file to figure out what it contains.
This approach also allows you to create HTML template files. If you were going to add a product, it becomes a matter of duplicating one of the existing wrappers, updating new header.jpeg graphics and the new text. The rest remains the same. This makes you more efficient when you have to add or build a Web site because you can always leverage on previously done work.
From a maintenance point of view, the htmld approach helps to keep directories smaller and clutter free. From a security standpoint, it also lets you clearly see suspicious files that you didn’t put there. If you know where and what your files are, you’ll have a better chance of noticing if you’ve had a break-in or if someone put something in the wrong spot. If you just throw it all in together and have 30 or 40 files per directory, it becomes difficult to figure out what is going on, and it takes more careful reading. Later the site will have many stale HTML files or graphics that are no being longer used. Cleaning up at this point is time-consuming because you have to think about what each of the files contain. If you remove any haphazardly, more than likely you’ll break something.
Filenaming Suggestions
When you are creative with your filenames, it becomes more difficult to know what a file contains. What is header2.gif? I don’t know because there’s no context, and I doubt that the person who created such a file could remember either. If it’s all packaged, then you know who’s the client of that resource, and you can create a visual and organizational association; you know what things are.
I title everything firstSecondThird.type. The first word is in lowercase letters. Any word after has its first letter in uppercase. I don’t use spaces, dashes, or any other character that is not a letter or a number. Periods are used to separate file extensions. This makes it easy for me to read and type filenames, and it removes the possibility of any nonalphanumeric characters from becoming part of a filename.
Web Site Documentation
While you are building your site, you may want to clearly document the standards used for creating a site. For example, it is useful to document colors used on an image. Better yet, create template files that can be used for creating new graphics. In Adobe Photoshop, this is really easy. Add a layer and enter the size of the text and font face that you used for a graphic title. This will allow future titles to be consistent and will save you a lot of time in generating artwork. Pass this information to those that create artwork for your site. You’ll be glad if you do. |
