I’ve been impressed with what the Processing community does with generative art, and Actionscript seems to be at a point where it can be used much like Processing. In that vein, I’ve been watching Mark Knol’s generative art for a while, and while I wanted to do something like it, I’ve never actually bothered to create sit down and start coding it up.

Today, I tried to recreate his work on the Google logo. While mine doesn’t seem to have as much depth or chaos, I think it turned out fairly well. With some tweaking, I could improve it, but for now I just wanted to put something out there.

Hope you like it!

Earlier, we learned how to block ads at the OS level. Blocking ads through the browser is awesome, but advertising these days is all about making inroads to the desktop. Even though Microsoft claims that their business is software, Live Messenger seems to be an ad vehicle. I quickly became tired of video ads constantly showing up in Live Messenger (especially those insipid Tru dating site ads) that would play as soon as the cursor went over them, so I resolved to do something about it. I fired up Fiddler, a proxy that allows you to view HTTP traffic. I saw several random requests for rad.msn.com, and upon further examination saw that it was serving ad content, which depending on the content type, would be handled appropriately by Live Messenger’s ad box.

I added rad.msn.com to my hosts file, and the ads were now blocked. Since there was now a blank box, I decided to go a step further and replace the image. I tried this before with a program that patched the ad out of the executable, but this isn’t a long-term solution, since any software update will require waiting on a new version of the patcher, and a subsequent re-patching. If I just serve a different image up, it’s fairly future-proof because Messenger is one the wiser. No matter what subdirectory or file is being requested by Messenger, this script will always throw back the custom image.

Using the index.php file we ended up with on our last ad-blocking adventure, we will add the following before the html is sent to the browser:

The exit() is added so we can bail out early after serving my custom image, and not serve up the normal adblock page (that I see in my browsers). The image size for the Live Messenger ad is 231×60 pixels.

I opted for an image that would blend in with the skin I use for Live Messenger, but wasn’t just a “blank space here” image. The skin shown is Oil Slick for Messenger Plus! Live.

To block ads on the web, we need to catch requests to a particular ad server and send them to our local server. We do this by adding an entry to the hosts file. The hosts file on a computer system gives the system information about where to find a computer on the network by mapping hostnames to IP addresses. For our purposes, we will be taking advantage of this by routing requests to ad servers from webpages to our personal system.

These steps will require that you have Apache HTTP server (or IIS with ISAPI_rewrite, something that can rewrite URLs) running on your local machine (or on a system with low latency, possibly on your network).

First, we will need to edit the hosts file, and add an entry in the form “127.0.0.1 ad.example.com.” If you are running Windows, examples should already be present in the hosts file. On Windows systems, this file can be found in %WINDOWS%\system32\drivers\etc\hosts, on Linux systems in /etc/hosts, and in OSX 10.2 and later in /private/etc/hosts.

So how do we get the hostname of an ad server? We can do this several ways, but you have to work for it just a little bit (I know, AdBlock makes it so easy). Since I am a web developer, I usually have the Firebug extension running, so I just click “Inspect” and the element is highlighted in the source code, usually with the URL of the server right there for me.

If you don’t have or don’t need Firebug, you can go the “view source” route. I have found the easiest way using this method is to search for some adjacent text you see in the rendered page, and look around for included Javascript files or hotlinked images. Most of the time the ad is easy to see. For included Javascript files that build the ad image, just block the whole server, and they won’t be able to render the ad, making the image server irrelevant. Often, ad servers will use several host names, requiring multiple entries in the hosts file.

If you’re using Firefox or Internet Explorer, you can usually right-click an image and select Properties to get information about an image’s location. Chrome seems to not want to give you that information easily, and selecting “Inspect Element” usually gives me mixed results, and a Webkit inspector that is surprisingly shoddy and works about three quarters of the time for me.

Once we’ve created the entry in the hosts file, we can test by closing all browser windows to force a reload of the file, then opening the ad server URL. If it goes to our local server instead of the ad server, we’ve successfully blocked the ad server across the entire operating system. Since we’re handling a bunch of HTTP requests anyway, why not do something with them?

I created a page that shows the word “Blocked” and the hostname instead of the Apache 404 error page, but I don’t want it displayed as my 404 URL for everything. I tried this, and it was problematic. I forget why.

To get our page handling all these misdirected requests, we’ll use some basic URL rewriting. You may need to adjust the example to suit your development environment, as this will take over all requests to your local server. This is the .htaccess file I have on my development machine’s DocumentRoot:

RewriteEngine on

RewriteCond %{HTTP_HOST} !^localhost* [NC]
RewriteRule (.+) index.php [L]

The RewriteCond takes any request that is not for “localhost” and sends it to the RewriteRule, which directs all requests to index.php:

I styled my block page in a nice light blue, so it shows up unobtrusively in ad-blocked pages. At the same time, you can easily see which items have been blocked. Since it replaces content that would otherwise be served from elsewhere, it doesn’t break page layout.

The advantage to blocking ads this way is that since I have my hosts file in a list of shortcuts, I can open it up, add an entry for an ad server, and close it. Since it is then blocked at the operating system level, any browser run from that system will respect the block.

That’s it! Happy ad-free surfing!

Wow, what a pain in the ass. I’m glad I didn’t personally pay for this software. I thought this was yet another PHP content management system.

Nope, it’s Perl.

To hopefully save someone from searching all over the web and back, here are the problems I encountered while installing. This guide assumes a semi-proficient knowledge of IIS configuration.

Install ActivePerl

First off, make sure you install ActiveState’s ActivePerl on your server. Manually configuring Perl is not something I’d care to dive into. If that’s your bag, go to CPAN (and why the hell are you reading this guide?).

Using the IIS Manager, navigate to your website and choose “Properties”. Under the “Home Directory” tab, click the “Configuration” button.

In the Application Configuration window, click the “Add” button.

Use the following values in the Extension Mapping dialog:

Executable: C:\Perl\bin\perl.exe "%s" %s
Extension: .cgi
Verbs: Check “Limit to:” and enter GET,HEAD,POST
Uncheck the box labeled “Verify that file exists” (this will speed execution on scripts)

Next, select the “Web Service Extensions” item on the left of the IIS Manager (at the same level as “Web Sites”). Select “Perl CGI Extension” and click the “Allow” button.

I already had PHP installed on this server, so I’m skipping that step for this guide. PHP is far less tricky to install, anyway, and there are extensive guides for this already.

Fix Shoddy Installation Procedures

When navigating to my Movable Type directory, I immediately encountered the error “CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers.”

Bad CGI application, bad! Smack it on the nose with a rolled up magazine!

First off, you should run the mt-check.cgi script to make sure everything’s on the up-and-up. If the script runs successfully, you’ve successfully installed and configured ActivePerl. Yay, you’re halfway (yes, halfway) there!

Near the top of this page, you should see the following:

Current working directory: [path]
MT home directory: [different path]

The MT Knowledge Base says to download this modified Bootstrap.pm file, and replace it with the version on your server. I honestly don’t know what’s different about it, or why they couldn’t include it with the installation, or even if it does anything different. Mindlessly obey.

The same page also advises to “Create a new “virtual directory” under IIS which points to the physical directory where the Movable Type CGI files are located (i.e., the “MT home directory” mt-check.cgi reports)” That explanation is freaking stupid. What it should tell you is “Do not install MovableType directly into the folder you wish to present to the world.” As in, I moved the entire thing to /cgi-bin/ and created a virtual folder named “blog” under the root folder pointing to /cgi-bin/. Your CGIPath variable in mt-config.cgi should match your virtual folder name (like http://www.example.com/blog/).

Install MySQL Driver

Oops, now navigating to the blog URL results in an error saying that the MySQL driver is missing (sharp readers will notice this was missing in mt-check.cgi as well, I did not). On your server, run the ActiveState Perl Package Manager, which should be in your Start menu. If you scan through all packages, you’ll notice a DBD-mysqlPP module. This will not work, as far as I know. You need to add another repository source to get the actual module you need.

In PPM, go to Edit > Preferences, then go to the “Repositories” tab in the preferences window. Add the CPAN repositories to its sources by either selecting “uwinnipeg” from the “Suggested” list, or do what I did manually. Enter “CPAN” for name, and http://cpan.uwinnipeg.ca/PPMPackages/10xx/ to the location box, then click the “Add” button. You should now have DBD-mysql available for installation. Install it.

That should be it! As far as configuring MovableType goes, that’s where I get off, because this installation was for a client who already knew how to use it, and already had his login information in the database (this was a server move).

Good luck!

Here are some .htaccess snippets I’ve had to use, and if you run your own site, blog, or some other third thing, you might find them useful.

Moved from one URL to another: My old blog url used to be verbose.pixelbath.com, and before that was pixelbath.com/verbose. Setting aside the notion that this blog moves around too much, the following snippet…

RewriteEngine on
RewriteCond %{HTTP_HOST} ^verbose [NC]
RewriteRule ^(.*)$ http://www.pixelbath.com/blog/ [R=301,L]

…redirects any host name containing ‘verbose’ will be redirected to the main blog URL. Useful because many sites had me linked to the old blog, and I didn’t want to break their links too badly. Nothing fancy, so please note that this does not transfer url parameters. It only redirects requests with the single word ‘verbose’ to the main blog URL.

Using a single file to handle all URL requests: If you’ve used almost any PHP CMS or MVC framework such as CodeIgniter or CakePHP, you’ve probably used something like this for “search friendly URLs”:

RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.+) /blog/index.php [L]

What this does is start from the /blog/ folder, and handle any requests under that. The first RewriteCond sets our rule to not apply to any physical files matching the request, and the second does the same for physical directories.

Once it passes the two conditions (a request in /blog/ that is not a physical file or directory), it goes to the RewriteRule, which simply takes all matching requests and redirect them internally to /blog/index.php. This is not a browser redirect, so the user will still see the URL the way they found it, something like http://example.com/blog/archive/foo. I use this technique on the comics pages by parsing the URL segments into comic and page requests.

Stop image and/or content hotlinking: Some netizens are either not savvy with the way the Internet works, or don’t give a crap because idiocy prefers the low-hanging fruit. Either way, I’ve actually got a few snippets for this purpose.

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?myspace.com [NC,OR]
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?blogspot.com [NC]
RewriteRule ^.*$ http://www.yourdomain.com/ [R,L]

The preceding snippet will block specific websites and their subdomains from hotlinking from your site, but will allow any other site not specified in your .htaccess file to do so. If you’d prefer to stick another image in place of the hotlinked one, this is particularly adviseable when you, (often with amusing results):

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?yourdomain\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/goatse.jpg [L]

This one will take any request with a referer not originating from your domain, or blank referers (because some users do legitimately blank their referer string), and redirect them to an image elsewhere on your site. This will work “inline” and display whichever image you specify on outside sites.

If you’d prefer to be plain and simple though, you can just set HTTP code 403 (Forbidden) on any image for any of the rewrites in this section. Simply replace the RewriteRule of each with:

RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]

Which simply sets any request for any image to 403 (Forbidden). Obviously, it should be used in conjunction with RewriteConds.