It’s not that anything’s “wrong”–I just don’t feel like I have anything I need to broadcast to the internets.  (Well, except for Twitter, but I’m kinda flaky on that score, too.) I don’t feel like writing rants and I have no desire to share intimate details of my life.  And frankly, in the last year or so, I’ve started to dig this IRL thing more.

That said, I do miss the connections and conversations I used to maintain via blogging.  I’m still online (way too much, of course), and you can easily reach me via email at tom at underscorebleach dot net. Please do drop me a line.

But now… it’s back to the real world for me!

But I do own an iPod, and I did use iTunes to rip my CD collection, so I’d been using iTunes to play the AAC and M4P files–until now.

My favorite little Winamp replacement, Quintessential Player, has a plugin for playing AAC/M4P files. Get it from RareWares. Then you needn’t use Microsoft’s abominable resource hog (Windows Media Player) or Apple’s abominable resource hog (iTunes). You get to use a fast, skinnable little player, and you feel extra special nerdy cool while you do it.

Since more and more apps are downloadable as ISOs, I think this will be useful.

But it got me to wondering: Why doesn’t TiVo store the box’s settings online? My TiVo is networked and “calls home” every 15 minutes or so. TiVo.com stores the device ID of my box. Why couldn’t the TiVo pass back my season passes and lineup info? I’m not even asking for web management of Season Passes and the To Do List; I’d just like to have the main box info backed up remotely. Seems easy enough.

It was quaint and really quite thoughtful, and I must say that having those lug nuts simplified matters for me today.

In the past few months, I’ve become more interested in the Chicago technology “scene.” (”Scene” is a funny word when you’re talking about techies and startups, but I don’t have a better word.) Chicago is home to plenty of cool startups and interesting tech types, but the coverage sucks. I’m aiming to change that.

WindyBits is a site dedicated to covering the ideas, events, and people in Chicago technology. We feature:

• Articles on Chicago technology
• Events in Chicago technology
• Tech-related Chicago news and Chicago-related tech news

This is a fun project for me, and just a side project, but it’s a lot of work! Anyway, you, the loyal jotsheet reader, are invited to slide on over to WindyBits and offer encouragement and suggestions. Oh, and an incoming link from you important bloggers wouldn’t hurt.

In so doing, I’ve had to disable WP-Cache, but since the site seems to be peachy since I switched back to using the PHP Apache module (default), I think the performance/availability will be fine.

Related security tidbit: Using require() with an external file to increase security on wp-config.php’s database password storage.

Update: WP-Cache security

I decided it would be prudent to enable WP-Cache. In its default configuration, it’s unnecessarily secure, so here are two steps you can take.

All of these steps apply only to those whose http daemon runs as www or nobody, not their own users. If Apache runs as you, everything can be 700 and 600.

1. Keep wp-content/ chmod’ed to 755.
   • Initially, you must chmod wp-content/ to 777 so the WP-Cache plugin can write wp-cache-config.php.
   • After wp-cache-config.php is created in wp-content/:
     • Chmod wp-content/ to 755
     • Chmod wp-content/wp-cache-config.php to 666.
     • Change line 430 of wp-content/plugins/wp-cache/wp-cache.php to
       if ( !file_exists($wp_cache_config_file) && !is_writable($dir)) {
       • Replace if ( !is_writable($dir)) {
       • Credit: Joerg
2. Secure the wp-content/cache/ directory
   • Chmod wp-content/cache/ to 777 (this is unavoidable)
   • Place the following .htaccess file in wp-content/cache. (This prevents the cache directory from being Web-accessible. If anyone on your shared hosting box writes to this directory, their files won’t be accessible and they can’t steal your bandwidth. Yes, this is a fringe scenario, but that’s kinda what security is about.)

     Options -Indexes
     <Files *>
             order deny,allow
             deny from all
     </Files>

I fixed the problem and thought I’d share for anyone else in my situation.

Don’t run Wordpress under php-cgiwrap

This is the real fix. The two items below seem to help, but this is the solution: don’t take Pair’s advice and run WP under php-cgiwrap. When using php-cgiwrap, Wordpress turns into an incorrible memory hog.

php-cgiwrap offers added security, since Wordpress will run as your user on the box, allowing you to chmod important files (e.g. wp-config.php) to 600. However, the benefits of the security are outweighed in this case by the fact that it just makes your site kinda unreliable.

When you switch to the normal WP/PHP situation — running PHP as an Apache module — you’ll need to relax some of the permissions in wp-content/ and WP’s cache/ directory. You also need to make wp-config.php world-readable (the nobody/www user has to be able to read it). This isn’t a problem for accessing the file from the Web — the database settings are hidden in PHP variables, not exposed to a Web user — but if you’re skittish, you can require() the database values from an external file.

Use WP-Cache

Well, it’s almost a given these days. Has to be the most useful plugin for Wordpress, but this alone couldn’t save my PHP process under php-cgiwrap — even when I bumped the expiration time up to 12 hours.

Disable Wordpress’ internal cache

I don’t know if this helped, but it didn’t seem to hurt. And from this thread, the WP cache seems like a bad idea, anyhow.

Note: This tutorial is for advanced users. Be careful! I screwed my blog’s commenting up for a while after posting this. :) I do not recommend messing with scriptaculous stuff — just leave it be. If you’re a novice, you probably don’t care about your site being a little bit slower, so this isn’t worth the effort.

Background

The best thing to do is to consolidate your CSS and JavaScript into singular files. This isn’t always possible — sometimes, the contents of included CSS and JavaScript depend on variables set in the plugins — but usually the included JavaScript and CSS are static.

Step 1: Find the culprits

Simply View Source on your site. Search in-page for “JavaScript” and “CSS” and see how many files you’ve got. Some are included inline (<style type="text/CSS"> and non-src <script>) and some are external (<link rel="stylesheet">, @import, and <script src>).

Inline includes bloat page size of the html. External includes ratchet up the number HTTP requests that a browser must make. The external includes are a bigger culprit in slowing down your site; it’s better to have make 1 HTTP request of a 2k external JavaScript than 2 HTTP requests of 1k files. In fact, it’s probably still better to make 1 HTTP request of a 4k file than 2 requests of a 1k file; the total download time will be similar, and on subsequent page views, the browser needs to check on the Last-Modified status of 1 file rather than 2. A highly technical analysis of this concept is at “Bulk File Transfer Measurements,” where you’ll see that throughput is poor until file size is at least 10k.

Step 2: Consolidate

Create consolidated JavaScript and CSS files. Copy the plugin-generated JavaScript and CSS into these files.

Note: It’s a good idea to make these consolidated files separate from your theme’s CSS/JavaScript, as you’ll want the consolidated plugin files to be portable when you change themes.

Step 3: Disabling the inclusion of the CSS/JavaScript from the plugins

This is the trickiest part, which is why I recommend this exercise only if you’re an advanced user. You should be careful here, as it’s really easy to mess things up. The best thing to do is to deal with one plugin at a time, iteratively reloading your cache-disabled blog to make sure things are still cool.

First you’ve got to find the plugins that are inserting the CSS and JavaScript. You might not know which plugins are responsible. For this task, do some grep’ing in the plugins directory (/path/to/wp/wp-content/plugins).

Good starting points: grep -Hnr "add_filter('wp_head'" *.php and grep -Hnr "add_action('wp_head'" *.php

This looks for plugins that are inserting something in the <head> of the document.

You can also grep for unique names in inline styles or JavaScript. External files should be clearer, as the includes should reference the plugin name somehow, since the files are often in the plugin’s subdirectory.

Once you find the responsible plugins, comment out the add_filter (i.e. // add_filter), or do whatever you’ve got to do in the plugin to disable inclusion.

Step 4 (optional): GZip it!

The consolidated files should be static; that is, they’re never going to change unless you install a new plugin that adds its own CSS and/or JavaScript. Because they’re static, you can gzip the consolidated CSS/JavaScript files for faster download. All browsers can handle gzipped files, and the filesize after compression is about 1/10 of its uncompressed size.

Simply execute: gzip stylesheet.js and it’ll created stylesheet.js.gz. You can then include this gzipped file, and the browser will understand (from the Content-Type returned by the web server) that it needs to unzip the file.

Step 5 (optional): Apache trick

One last thing.

Seems few people like to do this, but I think it’s handy. Instead of having:

<link rel="stylesheet" href="http://underscorebleach.net/path/to/stylesheet.js.gz" />

in your templates, I prefer this:

<link rel="stylesheet" href="/path/to/style/" />

This way, you can:

• Silently change the stylesheet returned by the HTTP request for that directory. You simply change the Apache configuration rather than having to update multiple HTML files or includes to reference the new file. As long as all of your templates — even non-WP templates — reference the directory, you’ll never have to worry about referencing an non-existent external JavaScript or CSS file.
• Serve a gzipped file transparently and not confuse people as to why the file extension is “.gz”.

For the above example, create a .htaccess file in the directory of your stylesheet and use the DirectoryIndex directive:

DirectoryIndex stylesheet.js.gz stylesheet.js

This means that when a browser requests that directory, it will be fed stylesheet.js.gz (if it exists) before stylesheet.js (if it exists). This order ensures that (a) the gzipped, smaller file is fed first, and (b) if you gunzip the file to modify it and forget to re-gzip it, you won’t have a problem.

Conclusion

WordPress users with lot of plugins might have 5 or 6 extra JavaScript and CSS files included, often externally. This increases the number of HTTP requests and slows down page load. Consolidating and gzipping the plugins’ JavaScript and CSS improves user experience.

That’s right. I don’t have the energy. Many of you know me as a prolific ranter, an inclination (or failing? or talent?) in full display here at the jotsheet. But there comes a point at which one’s frustration moves beyond the pale. To dedicate the time to write a suitable, all-encompassing rant would only exacerbate the problem.

I’m not angry anymore. I’m just kind of sad. I mean, I wasted a lot of time on that Movable Type shit. I’m past the denial and the anger; I’ve quietly accepted the trial that was Running a Large Blog Using Movable Type™.

I’m not angry about the 10 minute rebuilds or the 90 second post times. I’m not angry about the 30 second page load times for the admin interface (well, Dreamhost might have been to blame for that, too). I’m not mad that MT’s plugins are less extensive, less flexible, less interesting, and harder to install than WordPress’. I can look past the fact that building a CMS on Perl is, uh, probably not a great idea. I’m okay with the fact that much of the MT enthusiasts from 2003 have moved on to greener pastures. I’m all right with Six Apart placing a commercial license on the creaking mass of Perl code known as Movable Type.

But I do have a couple of things I’d still like to get off my chest, before I put this puppy to bed for good.

Dynamic publishing in Movable Type is a dirty, dirty lie

Jay Allen, oh Jay Allen. How you lied to me. Remember when you said…

Yes, Virginia, Movable Type 3.1x does have dynamic publishing. And it rocks! By switching some or all of your templates to dynamic publishing, you can drastically cut down or eliminate the time it takes to get an entry published or to rebuild your whole blog.

See, the thing is, I talked to Virginia too, and she told me dynamic publishing in Movable Type is a big steaming pile of hippo shit. With peanuts mixed in. I was a pretty freakin’ advanced MT user in my day and I couldn’t get that dynamic mojo workin’ after tinkering with it one night for, oh, 3 hours. How’s a normal sap gonna do it? Eh, Anil?

The lesson of entry_basename

I’ve got just one more piece of MT dirty laundry to air. This is a little story about a field called “entry basename.”

Long ago, most MT blogs had an ID-based permalink. A post might have the URL http://somewhere.com/blog/001293.html. Some enterprising and adventurous bloggers were unhappy with this arrangement and instead changed the permalink configuration to the use the title of the post, e.g. http://somewhere.com/blog/this_is_the_title.html.

An even smaller group of people, myself included, wanted complete control over the permalink structure and used a plugin to get a completely configurable permalink, e.g. http://somewhere.com/blog/custom_permalink.html.

A couple of years after this all went down, Six Apart caught a clue and built into Movable Type 3.2 the ability to specify a custom permalink. (It was there in MT 3.0D but worthless.) The new field was called “entry_basename,” and if you set your entry_basename for a post to “custom_permalink”, it would get the same URL as above. This change was put in by Six Apart to give users more control over the publishing of their blogs, but with the caveat that its intricacies were best left to advanced users:

[I]f you edit the basename of a published entry, it will very likely change the published filename, hence breaking incoming links to the entry.

Armed with this information about entry_basename, I was pretty confident approaching my conversion from MT to WordPress. My thought process was simple:

1. Move my permalink setting into the “entry_basename” field. (Using the custom permalink plugin, it had been stored in the “keywords” field.)
2. Export from MT.
3. Import into WP.

I ran into just one little problem: Movable Type doesn’t export the information. That’s right; they went to all these pains to give their beloved users complete control over permalinks—and even warned with a wagging finger that we ought not to change the entry_basename after publishing, lest we “break incoming links”—yet they didn’t bother to include the field in the export.

This made the field utterly useless for someone in my position, converting from MT to WP, but what’s a heckuva lot worse is what’s happened to MT users switching installations: they lose all their permalinks. For example:

• Joe builds a blog in Movable Type, version 3.2.
• Taking note of the fancy new entry_basename field, Joe customizes the permalinks of his blog entries.
• Joe decides to move his website to a different host.
• Joe is pleasantly surprised to learn that he cannot export from Movable Type 3.2 on his old host and import in Movable Type 3.2 on his new host. Everything breaks.
• Joe gives up and moves to WordPress.

The saddest part is that Six Apart knows all this. They acknowledged it in July 2005 and still haven’t bothered to fix it:

Warning: Currently, the export format does not include the basename field. This means if you use this method and you then export your entries, when you import them into a new weblog your assigned basenames will not be carried over.

I’m afraid I still can’t wrap my head around it: Six Apart adds a feature to give its users more control, warns them to be careful not to break links with it, and then provides no way not to break links with it. And they don’t warn their users upon export. And they’ve publicly acknowledged (albeit buried in a note on sixapart.com I spent 20 minutes looking for) the technically minor problem for 14 months yet haven’t done a thing to fix it.

I just don’t understand.

Conclusion

This isn’t a rant. It’s really more of a plea: If you’re thinking about starting a blog, avoid Movable Type. If you’re on Movable Type now and still have a small number of posts, get out while you can. If you’re on a big Movable Type blog—I can pick you out because you fall asleep in your chair during the rebuilds—then pray.

Oh, and one more thing. Six Apart, over the past couple of years, I’ve become intimately aware of your damage control strategy. You troll the blogs looking for criticism of MT and come hat in hand to the comments section, professing to love MT users and blogging and free expression and open source and kittens and Perl and everything else.

Well, don’t bother coming here.

Anil, Ben, Mena, Jay (and Virginia), and anyone else at 6A: do your PR elsewhere. Find another sap to get on MT. Do some database backups at Typepad. Hell, rip off MSN and MySpace and make a new CMS. (Oh wait, that’s Vox.) Just don’t bother me.

Background

If you’re interested in why moving your blog from Blogger to WordPress is a good idea, look no further than Anita Campbell’s write-up. Once the birth pains of the transition are over, there are no real drawbacks besides lost PageRank from your Blogger blog—if you published on BlogSpot and can’t transfer that Googlejuice to your new host via a real 301 redirect.

Note: If you’re self-hosting your Blogger blog, check out Maintain permalinks moving from Blogger to WordPress by Justin Watt. If you need to convert from Blogger Beta to Wordpress, check out this tutorial. My tutorial below does not work for Blogger Beta.

Requirements

This is what you need to play:

• A Blogger-driven weblog
• A fully installed version of WordPress 2.0+ (it has the nice import utility)
• A basic text editor - Notepad will do
• Some technical know-how (or an adventurous spirit), because I’m not going to hold your hand

What this will and will not accomplish

• Will redirect visitors no matter what their browser situation
• Will redirect them to the best, most relevant page on your new WordPress blog
• Will not preserve PageRank from your BlogSpot blog to your new blog. This would require a 301 Permanent Redirect and access to the server, not provided by Blogger.
  • If you publish using Blogger to a remote location using FTP/SFTP, you may be able to preserve PageRank. However, I’m not going to cover that here. You will need to research 301 redirection from your Blogger server to your WordPress server using 301 redirection.

The menu

Here’s what we’ll be doing today, kids:

1. Saving the Blogger template
2. Backing up data from Blogger
3. Import data from Blogger into WordPress
4. Prepare the WordPress host for redirects from Blogger
5. Modify the Blogger template to include redirects
6. Test!

Some of this is based on a tips page from Quick Online tips.

Step 1: Save the Blogger template

Click the Template tab, highlight the text, paste it into a text editor and save it.

Step 2: Back up data from Blogger

Follow Blogger’s detailed directions on backing up your data. (In essence, you change your template to post a text file of all your entries to the homepage of your site.) It’s a little wonky; I couldn’t get the backup to work with comments, so I just backed up entries.

Step 3: Import data from Blogger into WordPress

This is the coolest step. :) WordPress 2.0 has a straight-up slick import utility for Blogger. Go into the WordPress admin area, select the Import tab, select Blogger as the type of blog you’ll be importing, and follow the directions. Looove it.

Step 4: Prepare the WordPress host for redirects from Blogger

Credit a file in a text editor called from_blogger.php and put the following into it. Wherever there is the text http://www.yoursite.com/blog/, replace it with the root location of your WordPress blog!

• PHP source — save as from_blogger.php and move to your server

This file will take the redirect from Step 5, parse the URL that’s being passed from Blogger, and redirect the user to the corresponding imported entry on WordPress. If it can’t find the corresponding entry, it directs to the root of the blog.

Put this file somewhere on your WordPress host. If you don’t want to modify anything else in this tutorial, put it at http://www.yoursite.com/from_blogger.php.

I owe this section partially to Owen Barder. (I say “partially” because his code had formatting issues and a big typo that I spent a long time trying to debug, and therefore I’m not giving him all the credit. :)

Step 5: Modify the Blogger template to include redirects

Remember the text file with the Blogger template from Step 1? Open it and Save As with a new filename. We’ve got a couple of things to add.

1. Immediately after the opening <Blogger> tag, add the following:
   • Add this text after <Blogger> in your template

   This will redirect to the root of your new WordPress blog if the users come to a main or archive page on your Blogger site. If they come to the page of an individual blog entry, it will redirect them to the from_blogger.php script, where we’ll try to pass them along to the appropriate location in the new WordPress blog.

2. Add the following in the <head>:<meta http-equiv="refresh" content="5;url=http://www.yoursite.com/blog/" />

   This will redirect folks who have javascript disabled.

3. Add the following helpful text for the non-javascript users who won’t be immediately redirected. This will display as a yellow box that sits above all other content in the top-left corner.

   <div style="position: absolute; top: 30px; left: 30px; border: solid 2px #333; color: #000; background-color: yellow; padding: 5px; width: 350px; z-index: 5;">
   <p><strong>My blog has moved!  Redirecting...</strong></p>
   <p>You should be automatically redirected.  If not, visit <a href="http://www.yoursite.com/blog/">http://www.yoursite.com/blog/</a> and update your bookmarks.</p>
   </div>

4. Fully republish your Blogger blog.

Test!

It’s always a good idea to test! However, it can be tricky in this situation you’ll be immediately redirected from your old blog to your new blog as soon as your visit, getting the same treatment as your visitors.

To test, first turn off javascript.

• In Firefox, go to Tools > Options > Content > uncheck Enable Javascript.
• In Internet Explorer, go to Tools > Internet Options > Security > Internet Zone > Custom Level… > disable “Active Scripting” (under Scripting).

Now try the following tests:

1. Go to the homepage of your old blog. You should be redirected in 5 seconds to the homepage of your new blog.
2. Go to the homepage of your old blog. Go to an individual entry page. Turn javascript on. Reload the page. You should be transferred to the corresponding individual entry page on your new blog.

Conclusion

Well, there we have it! We backed up our template and our data first, but then we created the world’s friendliest redirects from Blogger to WordPress so users with bookmarks to old entries get shot right over to the appropriate entry on our new website. Hooray for beer!

I imagine that some of you won’t get this right on the first try, but please try to be self-sufficient before posting questions here. I’ll be very hesitant to even respond. There are lots of other resources on the Web about how to do the Blogger to WordPress migration; I just thought I’d post my experience.

That said, lots and lots of people are on it, so maybe you can’t avoid it. (I try but I fail.) If you can’t avoid it, at least make it usable. Here’s what I do.

Prerequisites

1. Firefox — not Internet Explorer
2. Greasemonkey — an extension for Firefox that lets you modify the look/feel/features of websites. If you don’t already have it, install this extension, then restart Firefox to make it active.

Hacks

All of the following scripts require Greasemonkey.

• MySpace custom style remover — no more annoying backgrounds and fonts on users’ profiles. No custom layouts. The default look and feel. Thank God.
• Automatic MySpace media remover — disables loading videos, audio, etc. unless you specifically request to see them.

Ad blocking

There are some MySpace-specific ad blockers out there, but the best route is probably to use Adblock and configure it to block MySpace ads.

1. Install Adblock. (You can use this for sites other than MySpace, too; it’s a great extension.)
2. Save these MySpace ad filters as a text file on your hard drive.
3. Import the filters into Adblock.
   • Hit CTRL-SHIFT-P to bring up the Adblock window
   • Click the Adblock Options text at top-right, select “Import filters…” and select the filters text file you saved.

Note: as MySpace adds new advertisers, that list of filters may become incomplete.

A final note

I don’t know if ad blocking violates MySpace’s TOS. I’m not endorsing behavior — just telling you how to do things. I will tell you that this will definitely improve your MySpace experience and make pages load about 5x faster!

Many more MySpace Greasemonkey scripts are available.

Also, I will not offer support for this entry. I will not tell you how to install an extension or troubleshoot any problems you have. You’re on your own. But do feel free to post comments about other hacks for MySpace.

Promo code: MAX97

Compare the hosting plans, pick the best one for you, and input “MAX97″ at Step 5 to get the best price possible.

And remember, after you sign up, you can create your own promo code, publicize it on your blog or website, and make a little cash for yourself!

Details of “MAX97″ discount code

The “MAX97″ code gives you the best discount on everything, period. Here’s a screenshot of the code’s setup (which is set in stone once you make it) from my DreamHost admin screen:

At Step 5 of the setup process, you’ll be able to enter the promo code. Initially, it will look like this:

After clicking Update, you’ll see the $97 discount is applied. (The example is for the popular “Crazy Domain Insane” plan.)

The evolution of DreamHost codes

Perhaps you’re wondering what this whole DreamHost promo code thing is all about, and why there are a ton of people offering them on blogs. I wrote about this about six months ago, and here’s a summary:

The story goes like this. [DreamHost] gives its users money when they refer new customers. By its own admission, my web host has a ridiculously high profit margin, allowing them to pass on a generous fee ($97) for every new user signed up in an existing customer’s name. But this was the old system, and frankly, it wasn’t very exciting. Many online businesses have similar referral programs, and the amount of money you can make off such a system is roughly proportional to the number of friends you’ve got online willing to do you a favor.

Then my hosting company had a very interesting idea: allow their users to give up part of the $97 award as a discount. Allow their users to create custom codes. Why? To spread the wealth and to create competition. No longer would all of the award money go to the existing customer; now it would be split between the existing and new customer.

When DreamHost initially rolled out the system, savvy users realized that that the sweet spot was to something between a $0 discount to their users (the old affiliate system) and a $97 discount (which would pay the affiliate nothing). Initially, most folks offered a $50 discount. Some more, some less, but this was pretty common.

Soon after, folks started upping the ante. Folks mixed in a little SEO and a smidgen of deception (see: rise of “dreamhost-promo-code”-type domain names) and trying to work their way up the SERPs. The discount amounts went up: form $50 to $60, $60 to $70, and so on. And then, of course, came the $97 promo code.

Today, the full, $97 discount permeates the SERPs. Affiliates are giving away the full $97 amount available in their discretionary discount, and you might think the Internet has taken a shift toward altriusm. That’s not quite right.

Secondary referrals

Initially, the profits to be reaped from giving a full $97 discount are slim. In fact, they’re $0. I give you $97 off your bill, and I don’t get a penny. But here’s the catch: if you refer someone to DreamHost, I receive $5.

Some folks might think that’s a pyramid scheme. It’s not. It’s actually just a clever twist for an affiliate program, and the “pyramid” has only two steps. Beyond that, nobody loses in this “scheme”; you get the biggest discount possible, and if you didn’t use a code to sign up with DreamHost, you’d be paying $97 more, period.

That’s about it, folks.

So. That’s how it works. Why am I teling you this? First, because hardly anyone’s forthcoming about how affiliate programs work and the financial interest they have in them. You’ll read a lot of people saying things like, “Here’s the full DreamHost discount. I don’t make a penny, but enjoy!” That’s not the whole truth. I guess I believe that honesty is the best policy, and you’re more likely to reward me than some other schmoe who’s deceptive. (Yeah, in the interest of honesty, I like to make money, too!)

And hey, if you’re feeling really generous, you can give me more money when you sign up (and get a smaller discount) by using a different code. I definitely don’t expect that, but what the heck:

• “75ALIVE” = $75 for you, $22 for me
• “88ISGREAT” = $88 for you, $9 for me
• “DEAL90″ = $90 for you, $7 for me

But perhaps the importantance of SERPs—that’s “search engine results page” for the uninitiated—was never clearer to me than when I received an e-mail today from my mother. Mom’s competent enough with getting around the Web and doing word processing, but she doesn’t do much more than that. She’s a typical Internet user. Today, she was doing some research on gas exploration leases, and this is what she wrote:

If you “google” gas fact sheet.pub, you’ll find an informative article from Cornell in New York about gas leases.

Also, if you google shale gas doc, you’ll find interesting info on how they actually extract gas, along with pictures of wells and rigs.

A message board of people discussing gas exploration leasing can be found by googling Naro forum.

I wrote her back and asked why she hadn’t included URLs to the sites she mentioned. The simple answer. She didn’t know how.

I’m not writing to embarrass my mother, of course. (And truth be told, I wrote this up without asking her permission first. Pretty rude of me, eh?) But think about that: the practice of search has so permeated our use of the Web that some users have no idea what a URL is anymore. They speak of sites not in reference to their name, or their URL, but their placement and key terms returned on a Google search.

Backstory

I spend a lot of time on this website. Far too much time, in fact. I tweak it endlessly: the design, the CSS, the underlying HTML. I moderate comments. I make my own (usually snarky) comments. I produce new content, of course. And, like most bloggers, this is for the pure enjoyment of self-expression. I just like to write and to rant. I’ve never tried to make anything big out of this.

Well, for good reason. This site isn’t a big deal. It’s silly and stupid, and that’s kind of the way I like blogs. I don’t think they should take themselves too seriously, and when they do, I think they lose a lot of their appeal. In the 4+ years of this site’s existence, I’ve taken pains to make sure the content of this site stayed true to the core, guiding principles of free flaming, free expression, and rampant, unadulterated sarcasm.

The System

Rewind to about two weeks ago. For the first time ever, I made some money off this site.

Is that a bad thing? Not in and of itself. It’s not bad if it doesn’t corrupt the appeal of my blog. It’s not bad if I still enjoy my blog afterward.

The story goes like this. My web host gives its users money when they refer new customers. By its own admission, my web host has a ridiculously high profit margin, allowing them to pass on a generous fee ($97) for every new user signed up in an existing customer’s name. But this was the old system, and frankly, it wasn’t very exciting. Many online businesses have similar referral programs, and the amount of money you can make off such a system is roughly proportional to the number of friends you’ve got online willing to do you a favor.

Then my hosting company had a very interesting idea: allow their users to give up part of the $97 award as a discount. Allow their users to create custom codes. Why? To spread the wealth and to create competition. No longer would all of the award money go to the existing customer; now it would be split between the existing and new customer.

It was a brilliant innovation. Here’s why:

• The hosting company immediately recruited loyal users to advertise on their behalf.
• The hosting company did not suffer financially by the move, since they were paying $97 out anyway. Now, they simply paid it to two parties.
• Existing users provided tangible benefits to prospective hosting customers.
• Existing users were still able to benefit financially (albeit less) but were no longer locked into the level playing field of the old system.
• New users benefited tangibly with discounts to which they were not previously exposed. Furthermore, existing users had a reason to tell new users about discount codes. There was no reason before.

Money and blogs

So, it’s an interesting system. No, it’s a brilliant system. But, truth be told, I’m a bit uncomfortable with playing this game on the jotsheet. I’ve criticized bloggers in the past for “selling out” and writing sponsored blog posts. How is this different? It’s not.

However, after much thought, I’ve come to the conclusion that my previous idealistic view of blogs as pure avenues of expression was hopelessly na�ve. It is inevitable that blogs will be structured to make money; for many popular blogs, this structure is already in place. The question is how this can be done properly.

In my own mind, I’ve come to grips with “the money question” vis-�-vis blogs in the following way:

1. Monetary interest in any product, site, or topic must be fully disclosed. Do not sacrifice your personal values for a few extra bucks.
2. Running a good blog is time-consuming. As Ben said to me, “You spend enough time on your site—you might as well make some money off it.”
3. You can’t please everyone. I probably annoyed people with what they see as shilling. There’s nothing special about my site, and they’re free to go elsewhere.

The Game

In the bigger picture, I have found this entire experience over the last week or so to be enthralling. For whatever reason, I’ve shied away from business-oriented endeavors much of my life and have never seriously considered business school or anything of that nature for my long-term career. Although it probably sounds funny, this experience probably constitutes my first exposure to relatively pure capitalism. Success in this little game is a question of SEO, advertising, personal appeal, segmenting, understanding of context, and business intelligence. It’s very exciting. Very exciting indeed.

To my regular readers, I appreciate your patience. I’m still playing this game. Partly for the money, partly for the experience, but it will infringe in a small way on my blog, at least in the near-term. That’s the decision I’ve made.

The Code

If, after all that, you’re just looking for a code, look no further:

$90 discount: DEAL90 (and $7 to me, because you’re just that nice)

Full $97 discount: MAX97 (best discount available)