By no means do I consider myself an expert programmer. Hell, I can barely call myself a novice, really. But I do tend to have an understanding of the basic principals of web programming, and when I have something in mind for a project, I’m pretty good at laying out a design and then building a framework.

When it came to my firetower website, I had a few things in mind. I wanted people to be able to see a map with locations of all the firetowers I’ve been to. I wanted links to each location, and descriptions of the towers with photos. So, what I had at first was a single page with an imagemap with little firetower icons that you could click on in order to see descriptions of the towers.

But then I started to realize how it’d be neat to have all the descriptions in one file and dynamically generated HTML, so I could easily add more if I wanted, without having to make another HTML page for each one. If I were to visit a bunch more towers, this would be easier for me in the long run. This approach also has the added benefit of efficiency in that the content that would normally be repeated in every HTML page (such as the header, body tags, and everything else) can instead be written in one place and doled out on the fly.

The reason I decided to use Perl was because, really, it was all I had used before. Now that I’m learning a bit more about both CSS and PHP (thanks to setting up this site), it’d be interesting for me to remake the firetower site and see whether I can do a better job. But back then I was sort of afraid of both those things because they seemed so complicated.

Anyway, I spent several days (or was it weeks?) working on the code, including several major revisions which lead to increasing efficiency. Originally, several routines were all in their own files (completely isolated scripts to handle various input, always passed back and forth between scripts as environmental variables), but I found I could save a bit of trouble by using a BASIC-style top-down approach with subroutines (I know why this can be bad, but in the case of the small firetower script it worked well). What I ended up coming up with seems to work pretty well.

The basic flow of the program is like this:

Someone decides to visit the site. Cookies are checked and at this point one of two things can happen. 1. The user doesn’t have a cookie set that says they’ve read the disclaimer page (or they have a garbled cookie, or a cookie saying they disagreed to the disclaimer), so the disclaimer page is printed. 2. The user’s cookie says that they previously agreed to the disclaimer, which means that they can see the content of the site.

At the disclaimer page, the user can choose to disagree or agree. There’s also an option to use “text mode” which means that upon seeing the content of the site there will be a list of plaintext links to the tower information instead of a graphical map. This is set in a cookie so that the setting is retained throughout the visit, as well as for future visits. The option can also be changed later.

The main content of the site is handled with a few routines. The first thing that happens is a generalized header is printed which contains HTML from content-type through setting the font. So, basically, the first chunk of HTML. Next, depending on what the user’s preferred navigation choice is (text, imagemap, or google map), the main chunk of content is printed out. Since there’s also an option to re-read the disclaimer page, that gets handled here as well. There’s also an error trap in case unexpected input is passed to this part of the script - it would result in the error “Incorrect argument specified”.

After this, a generalized footer is printed containing the navigation choices. These choices POST back to the main script so the main content can be reprinted if the user wants to use google maps instead of the imagemap.

All that’s left at this point is what happens once the user clicks on a link to see more information about a firetower. The information is passed back to the main script as an environmental variable which is then passed to a separate library that contains all the information about the towers. All of the printing of tower information is done here.

A few simple benefits of my design are: 1. since cookies are checked every time the script is called, there’s no risk of the content being displayed if the cookie isn’t properly set, and 2. the firetower data library is easily expandable, and 3. the main script is pretty compact - without comments, it’s less than 10KB, and much of this is just HTML content that’s outputted to the user.

If you look at the bottom of this page, in the footer, you’ll notice some (currently two) color bars. If you click one of the color bars, the “skin” of this site will change based on the color bar you clicked. I thought this would be a neat functionality to have, but I had a very difficult time finding pre-made scripts that would do exactly what I wanted. So, I came up with something, based partly on A List Apart’s guide. It works pretty well, is easy to configure, and is expandable to any number of styles. At some point I’m hoping to make it a little more portable (easier to configure). In the meantime, I’m learning my way around PHP, but I decided to post my style switcher in case it could benefit anyone else.

The style switcher uses cookies so that the stylesheet settings aren’t lost as the visitor navigates the site. The cookie duration can be set for a session only, meaning the next time the user visits the site, the default style is used. Alternatively, the cookie can be set for a longer duration so that the user doesn’t have to change the style on subsequent visits (this is how the cookie is set in the example).

Where you may wish to start is with a simple PHP script to set the cookie, based on input sent to it from a link or form. In the case of my site, when a user clicks one of the color bars in the footer, a variable is passed to the switcher.php script, which looks like this:

<?php
require( dirname(__FILE__) . ‘/wp-config.php’);
$style = $_GET['set'];
setcookie(’sitestyle’, ” . $style, time() + 864000, COOKIEPATH);
wp_safe_redirect(wp_get_referer());
?>

If you aren’t using a WordPress installation, the line beginning with “require” can be removed. You’ll have to change “COOKIEPATH” to include the path and domain name, as in

setcookie(’sitestyle’, $style, time() + 864000, ‘/’, ‘domain.tld’);

The line beginning with “wp_safe_redirect” would also be changed, maybe to something like:

header(’Location: ‘.$_SERVER['HTTP_REFERRER']);

There are probably better ways of doing this, but you’ll want to keep in mind the general idea of redirecting back to the page the user came from. Otherwise, they won’t be able to switch the style and reliably stay on the same page.

Anyway, you may have noticed that basically any text could be passed to the switcher script and saved into a cookie. This isn’t a huge deal since there aren’t really any benefits to a user intentionally garbling their cookie. Regardless, the next script will read the contents of the cookie and decide which style to use based on the contents. If the cookie contains something that isn’t expected, the script will simply use the default style. This script can be used directly with the page on which you’re actually setting the stylesheets:

<?php

$path = “http://www.joshebben.com/wp/wp-content/themes/main/”;

if (isset($_COOKIE['sitestyle'])) {
$style = $_COOKIE['sitestyle'];
if ($style == “default”) {
$style = $path . “style.css”;
}
elseif ($style == “contrast”) {
$style = $path . “style-contrast.css”;
}
else {
$style = $path . “style.css”;
}
}
else {
$style = $path . “style.css”;
}

?>

Following the flow of the program, it first checks to see if a cookie is set called “sitestyle”. If it isn’t set (the very final ‘else’), the default style will be used. If the sitestyle cookie does exist, the script checks to see what the contents are. If the contents are something unexpected (the second to last ‘else’), again, the default style will be used. Otherwise, a style will be chosen based on the predefined contents of the cookie. You could add more elseif statements if you wanted more style possibilities. Of course, keep in mind that each style requires an independent stylesheet with this setup.

Finally, you’ll need to replace your current stylesheet tag:

<link rel=”stylesheet” type=”text/css” media=”screen” title=”User Defined Style” href=”<?php echo ($style) ?>” />

This will grab the $style variable, which was just set a moment ago when the cookie was checked.

Feel free to adapt this and use it however you want. Thanks to the guide on A List Apart for providing a base for me to work with.

If you’re using an older case for your computer or think you might have temperature problems, you may wish to consider adding a “blowhole”. Simply put, a blowhole is a vent located on the top of a computer case with an outward-blowing fan attached in order to help remove hot air.

Because electronic components inside computers tend to produce a lot of heat, and because heat can damage these same components, it’s important to keep an air current flowing through your case so that the heat can be expelled. While many newer cases tend to have adequate ventilation, many cases do not. If you think you could benefit from more airflow, you can consider adding your own vents. (Plus you’ll legitimately be able to tell your friends you have a “blowhole”!)

Please note that this guide obviously can’t do everything for you. If you mess something up trying to mod your case, it’s not my fault. Don’t mess around with your case if you aren’t comfortable doing so.

Anyway, here’s a list of the essentials that you’ll need before proceeding:

• PPE (Personal protective equipment). You’ll be working with power tools and sharp stuff, so be prepared with safety glasses and work gloves.

• Duct tape to protect your case and masking tape so that you’ll have a nice writing surface.

• Fine-point permanent markers for writing on the tape

• A small carpenter’s square

• An electric drill capable of receiving a hole saw

• Drill bits for drilling the screw holes

• A hole saw, arbor and pilot bit (I purchased a 3-1/8″ hole saw with a built-in arbor and a separate pilot bit designed for the hole saw. You can alternatively use a 3″ saw, both sizes will approximately work with an 80mm case fan.)

• An 80mm fan and grille for each vent

• A clean work area, preferably somewhere you can get a little messy–metal shavings aren’t fun to clean out of carpeting.

If you haven’t already, begin planning out where exactly you want the new vent. Keeping in mind that hot air rises, you might want an exhaust fan on the top of your case, or an intake fan near the bottom. Regardless of the location, make sure that you’ll have enough clearance for the fan. Here’s an illustration I created of typical vent locations:

Once you have a general idea for the location, remove the case panel from your case and put a layer of duct tape where you want the vent. Put a layer of masking tape over the duct tape for a better writing surface. Next, use your square (or trace a case fan) to draw a square outline of the vent. Basically, you should end up with an 80mmx80mm square:

You should next make a center mark so you’ll know where to position the pilot bit once you start cutting. To do this, make a mark 40mm in on each side of the square and connect the marks:

You’re almost ready to begin cutting the hole. If you haven’t used a hole saw before, keep in mind that you’ll need to insert the pilot bit through the saw’s arbor and then tighten the arbor’s screw. Be sure the screw it tightened onto one of the flat sides of the bit, otherwise the bit will be able to spin freely. Also, you’ll want to make sure the pilot bit sticks out a bit on the cutting side of the saw, as you want the pilot bit to drill in before the hole saw starts cutting. Here’s a photo of the assembled hole saw:

Next, attach the hole saw to your drill much like you would any other bit. The pilot bit should stick far enough out the back of the hole saw so that it can be held securly by the drill.

The next step (actually drilling the hole) probably has the most potential for frustration. Basically, you need to position the pilot bit into the center marking you made earlier and slowly begin drilling. You’ll want to start off slowly so that the bit doesn’t slip. Once it pops through the case panel, the hole saw will make contact with the case panel and probably cause the drill to stutter a bit. Continue cutting, making sure the cut is even. After the cut is nearly finished, the drill will probably jump suddenly (as there is much less resistance than before). If the circular cut-out is still hanging on, you may need to stop drilling and bend the cut-out back and forth in order to remove it.

Now that the hole has been made, it’s time to drill the holes for the case fan screws. You can simply position the case fan over the hole in the orientation you like and use your marker to mark the positions for the screws. You could also measure everything a bit more precisely, but the “eye it up” method worked fine for me. It’s probably a good idea to start with a small bit for drilling the pilots, and work your way up to a larger bit to create holes that will be able to accommodate the fan’s screws. Your final bit size for standard case screws should be 5/32″. Here you can see the panel, sans tape, nearly complete:

Because the hole might come out looking a bit rough, you might want to add edging material, paint it, or grind/sand it. Since I wasn’t going for pure aesthetics, I decided not to, but the choice is yours. Either way, the final step is to screw in the fan and grille. Nearly all case fans include small arrows on them to show the direction of airflow, so if you added a vent to your top panel, be sure the arrow is pointing up to expel the hot air. If you want to draw in cool air with a lower vent, the arrow should obviously point inward. Finally, hook up the fan’s power connector to your power supply and put the panel back onto your case.

Replacing a video card’s HSF (heatsink/fan) is a pretty straight-forward process. However, the process does require a bit of patience and basic technical understanding as well as, of course, tools. You’ll also want to take precautions such as grounding yourself or using an anti-static device in order to avoid damaging the video card.

Below is the original, unmodified EVGA GeForce 6800 (Vanilla). Once the card has been pulled from the case and the power disconnected, start looking for the screws that are holding on the original HSF, and carefully remove them. There are a lot of them. Save them in case you need them again.

Part of the HSF has now been removed. You can see how wussy the stock fan and fins are:

Take caution to remove the rest of the HSF slowly and carefully. The heatsink is often glued to the memory modules, so you’ll probably need to carefully peel away the heatsink. Once this has been done, you’ll be able to see the bare components. The small black chips are the RAM, and the large chip in the center is the GPU. Before proceeding, it’s recommended that you clean out any dust and also make sure the chips are clean and ready for the new cooler. You can wipe away any leftover thermal compound from the GPU.

Here’s the front and back of the new cooler. Once you’re ready to install it, remove the plastic cover from the GPU thermal compound and peel away the tape from the RAM’s thermal compound. Avoid touching any of the thermal compound. After this, installation is really as simple as lining up the new cooler onto the video card and carefully tightening the screws that came with the new cooler.

This is the finished product. Clearly, the new HSF has a larger fan and a bigger heatsink. Next we’ll see how it actually performs.

(Methodology: For idle temperatures, the PC remained turned on but unused until temperatures stabled over a period of several minutes (assumed to be the normal idle temperatures). For gaming temperatures, each game was played with typical settings (the same settings before and after) for fifteen minutes and then temperatures were taken. All readings were provided by the tools included with nVidia’s drivers.)