Hopefully this will help both people searching for [sexy things to say to a man] and those interested in [choosing an Objective-C book]. (Both are real searches that have led people to this site.)

I just lost a bunch of formatting in the last few posts, specifically, p tags around paragraphs were not preserved among other problems. I think I have it all fixed now.

I’ll be submitting a bug to Apple this evening.

• First, I wanted access to the server logs so I could see all requests coming into the site, not just the ones captured by Google Analytics and Feedburner (or especially TypePad, whose site usage stats are a joke).
• Second, I wanted a place where I could create and host my own web mashups, and host any widgets, gadgets, and other software that I create.
• Finally, I wanted a place where I could get first hand experience with Google (and other) Webmaster Tools, specifically Sitemaps (and maybe robots.txt at a later point).

It’s kind of funny that my job involves developing for a major retail website, but I’m not provided an opportunity to learn about web crawlers or site optimization unless I do it on my own time.

I decided to get started with Sitemaps. A Google search for [WordPress Sitemap] quickly sent me to Arne Brachhold’s WordPress plugin. I went with the latest beta. Installation was pretty easy, and it worked like a charm. (I sent Arne a small donation as a few days later.)

Though the plugin supports including additional, non-WordPress generated files in the Sitemap (and even supports putting the file somewhere other than the blog directory), I wanted something a little more flexible.

Lesson of the weekend 8: The Sitemap protocol defines a index file that can point to other Sitemap files on your website.

I created an index file in the root directory, and added a pointer to the blog’s Sitemap file. I also created a small Sitemap file for the homepage and included a pointer to it as well.

This was the easy part. The last step was to create a Sitemap for the archived blog. There are numerous tools for creating Sitemaps, but I wanted to use the program developed by the mother ship. Unfortunately, this required running Python, which is something I had never done.

Lesson of the weekend 9: Thanks to the power of Unix and config files, running Python scripts, at least those created by Google, is a piece of cake.

This turned out to be no big deal. I ssh’d into my site, typed python and hit enter. A Python prompt appeared along with a message saying I was running 2.3.5. I quit out of Python (using Ctrl-D, after an amazingly useful error message told me that ‘exit‘ wouldn’t work), edited my configuration file, uploaded the files, and ran the script according to Google’s instructions. It took a few tries to get the script to execute successfully. I didn’t realize that my root folder under ssh was different than my root folder under ftp. Also, using the shortcut for my home directory (~/) didn’t work as I had expected.

With the Sitemap file created, I added another pointer in the index file and patted myself on the back. I didn’t bother creating a cron job to periodically recreate the file since I don’t expect the archived blog to ever change.

I submitted the Sitemaps to Google Webmaster Tools and Yahoo’s Site Explorer, but they take a few hours to update. I’ll save you the suspense and let you know they both validated the Sitemaps without incident.

Brief intermission: To say that I “patted myself on the back” is a bit of a misrepresentation. Here’s a better description. You know that scene in Cast Away where Tom Hank’s character finally lights the fire and triumphantly yells, “I have made fire!” (I think he’s even thumping his chest.) It was like that, but I was yelling, “I have run Python!”

Whew! I still have a ways to go here, believe you me.

There were still a number of changes I wanted to make to the blog archive. Basically there was a bunch of functionality that would no longer work because this was now a collection of HTML pages, and not a working blog. I needed to remove the subscription links, disable comments, fix the search, and some other cleanup tasks.

Lesson of the weekend 10: If you’re going to archive your blog using Deep Vacuum, get rid of the features that won’t work first.

I could have used a Perl script similar to the one I used to update Google Analytics ids, but I wasn’t sure how to handle multi-line changes. (See part 2 for details.) Instead, I decided to just put a warning on the home page, and deal with the real fix later.

To edit the HTML, I decided to download Coda. I had read a lot about it on various blogs and decided to give it a try. I made my changes on a my local version of the site, and then copy and pasted them into the server version. It worked like a charm, but the warning only appears on the archived blog’s home page. Like I said, I’ll fix the rest later.

Okay, I know I said I finish up this series in this post, but I can’t. It’s already long enough that editing is a pain even with WordPress’s edit box open really huge. I have to tell you the rest at a later time. I will say that the coolest part is yet to come, but you’ll have to wait to find what it is.

I don’t know many of the other names on the list except for John Gruber and John Siracusa, both of whom I have huge respect for and probably read every word they post to the Internets.

P.S. I’ll have my third and final Memorial Day Weekend story up this weekend. I’ve been out of town and haven’t had time to finish it. It’s much longer than the previous entries.

Even though the site was now successfully working, there were a few problems. The first was that the Google Analytics script contained the id of the old site. Since that site is going to be retired, and I wanted to track usage of the archives, I needed to update the id in every page it appeared in. Fortunately, I already had the answer, or so I thought.

One of my jobs while I worked at Microsoft was creating the first every HTML-based dialogs to appear in an application. (I wrote the find dialog Dave Massy talks about in the second paragraph of this article.) Back in the day, the Internet was slow and hard drives were small, so we had to minimize the size of Internet Explorer. I was tasked with writing a sed script to strip comments and whitespace from the dialog files. Of course, I knew nothing of sed, and all I was given was MKS Toolkit manual. It wasn’t until years later that I even realized I was writing regular expressions. I just had a list of strange symbols and what they were supposed to mean. (Quick aside: I’m now the resident regular expression expert at work. My secret: Jeffrey Friedl. I love that book.)

So I knew of sed and what it can do. I figured I should be able to use the magic of the Unix pipe command to update all the files in the archive directory. Well, and hour or so of Google searches turned up nothing. (I even resorted to trying to read the sed man page.) I’m not sure where I read it, but I eventually learned:

Lesson of the weekend 6: sed cannot work “in place”. It must create a new file as output.

Lesson of the post-weekend writeup 1: Lesson 6 is wrong. I don’t know how I was misled.

So I had to move to a Perl-based solution. I know very little about Unix commands; I know nothing about Perl. Fortunately, this time Google delivered the answer quickly. I made a simple modification to one of the sample scripts, tested it on my local copy of the archived site via Terminal, then SSH’d to DreamHost and ran it on the server. It worked perfectly the first time.

Heady from my success, I decided to try something completely different for a while. I recently picked up an Airport Extreme. Why I needed it and the setup process will have to wait for another blog post. (I really had a very good reason for picking it up, and it’s generally worked out well.) I noticed in the advanced settings, that there’s an option to receive SNMP messages from the router. I thought that maybe there was an easy way to graphically track router usage and statistics. We’ll I’m certain there is, but I couldn’t find anything I could decipher. I ended up giving up.

Lesson of the weekend 7: SNMP is crazy hard to understand.

Okay, that takes us through Sunday morning, and Sunday afternoon is when things really get interesting. We’ll cover that (and there’s still a lot to cover) in the next post.

Also, I’ll apologize because this post has pretty much nothing to do with Cocoa. However, it has everything to do with the fact that MACS ARE TOTALLY AWESOME.

Seriously, this weekend it was like the scales lifted from my eyes (yet again) and I glimpsed the true greatness that is OS X.

And finally, I’ll apologize for turning into a raving Mac fanboy. Being a fanboy is not something I’m ashamed of. What I want to avoid is becoming a Mac apologist. We’ll see what happens.

The weekend started, as most weekends do, on a Friday night. Jo (my wife) and Erin (our friend) were enjoying a steak and salmon dinner at Daniel’s on Eastlake. I had received a gift certificate as an attaboy at work so we were splurging. During dinner I asked, “How thick do you think a 1600 page book is?” I was wondering because I had ordered Mac OS X Internals by Amit Singh. I had heard him interviewed on a podcast and was intrigued enough to purchase the book. I knew it was waiting for me when I got home.

At home, Jo and Erin rolled their eyes and settled down to watch a movie as I cracked open the tome. (As you can guess, I was on the receiving end of some rolled eyes and “what a nerd!” comments.) Jo pointed out that a book can be 1600 pages for a couple reasons: Either it contains a lot of information, or it is very poorly edited. Based on the first chapter, which is historical rather than technical, I have to side with the latter. Also, this book could really, really use some design work. I’ll save the details for a further post.

I’m hoping it gets better as it gets into technical topics. If you’d like, you can read a greatly expanded version (140 pages instead of 40) of chapter one here. Maybe the longer version is better, but my problem with the book so far is not its brevity. (Which is probably the same criticism that can be leveled at this post.) I do plan on going back and reading the longer version at some point.

Saturday was when the fun really began. Over the previous week, I had been trying to move our old blog to my new site, and convert it from TypePad to WordPress. TypePad is costing me money because you have to pay for the privilege of letting more than one person post to the blog, the site is slow, and the online editor is clunky and cluttered. Since creating this blog in WordPress, I’ve been blown away by the speed (thanks DreamHost!), features, ease of use, and awesome online editor.

However, even though the export and import went fine, the new site was still using images from the old site. Plus I had decided that I wanted to preserve the look and feel. Jo had spent a lot of time getting the blog to look cool, and I wanted that to be part of the archive. This turned out to be a giant pain. I tried to find a theme that was close to the old site and modify it, but it’s been years since I’ve had to massage HTML and stylesheets. (This is one of the benefits of moving into management.) After fighting with it for several hours, even with the help of FireBug, I decided a new approach was in order.

Lesson of the weekend 1: If you want to archive your blog, are moving to a new blogging platform, want to keep the look and feel, and aren’t going to continue adding posts, just create an HTML copy; don’t bother trying to perform a full migration.

Since I knew we weren’t going to be creating any new posts, I figured a copy of the site would be enough. I don’t really know how I knew this, but there is a nifty Unix tool called wget that can be used to make local copies of websites. I figured that OS X, given its Unix roots, would have a copy, but apparently it doesn’t. I didn’t trust myself to compile it from scratch (I’m still a ways away from that level of competency), and I didn’t trust a build from a random blog (Sorry Kevin!) I did find an application called DeepVacuum, which is a Mac GUI on top of an modified wget. I downloaded it and gave it a try. (Don’t ask why I trusted the software from HexCat and not Kevin. I don’t have a good reason. When I give it some thought, it’s more likely that if someone was trying to get me to install malicious software, they would set up a professional looking website, and not use some random blog.)

DeepVacuum worked like a charm, so I now had a local copy of Kris and Jo go to Paris. I Pointed Firefox at the home page via the file system and everything seemed to work fine.

Here’s where the awesomeness starts to set in. If you check out my about page, you’ll see that I have little to no Unix experience. We’ll, there’s no motivator like necessity. Unlike the “one click” install for WordPress, DreamHost doesn’t offer a one click upload of 100 megs of html and images. The web-based FTP client provided by DreamHost that I’d been using until now had transfer limits, so it would take forever. I have plenty of experience with command line FTP clients. Windows has shipped with one for a while, and they’re all pretty much the same. But in an effort to save disk space and bandwidth, I needed to compress the files first.

Here’s the dilemma. Once the file was on the DreamHost server, I’d need to decompress it. Since they’re running Debian Linux, it’s not like I could use WinZip to do it. I knew what I needed to do: I had to learn gzip.

I open up Terminal and type man gzip. I then read a few paragraphs and decide to try another route. The first problem is that my terminal window is way too small. Preferences doesn’t have any window-related options, and I completely miss the the “Window Settings…” item in the Terminal menu. Google searches return nothing because the Internet apparently assumes a certain level of competence, so I go hunting around the menus again. This time I find the “Window Settings…” item, but get intimidated because the drop down says “Shell”, and I don’t want to change anything about my shell settings. Finally the light bulb goes off, albeit dimly. The drop down is to select which options you’re changing. This seems like a serious usability problem. The dropdown is being used as a substitute for a tabbed dialog. Because in most OS X dialogs, settings are applied immediately, I figured changing the dropdown would change some setting, and I wasn’t sure exactly what it would change. What does the shell have to do with “Window Settings…” anyway?

So I went to the Window and Color tabs and increased the windows size and made some other adjustments.

Lesson of the weekend 2: A drop down control is a very poor substitute for tabs.

Lesson of the weekend 2.5: To change the size of your Terminal window permanently, go into “Window Settings…” (under the Terminal menu) and select “Window” from the dropdown. Once done, choose “Color” from the dropdown and change the window transparency. You’ll want to do this because …

Lesson of the weekend 3: Translucent terminal windows are totally awesome! Seriously. Take a look at this screenshot.

Okay, even with the bigger window, the man page sucks. I hadn’t really learned this lesson yet, but I’ll post it for you now.

Lesson of the weekend 4: Unix man pages suck.

Why can’t the man pages include simple usage examples? Who cares about the bugs? And why does a program like gzip require 11 paragraphs of description at the beginning? I think the Microsoft Word manual is shorter. After this weekend, I don’t even try to read the man pages anymore. I’ll first try –help, then -h, then a Google search for [Unix command tutorial]. It took me going through a few more commands to really learn this lesson.

Here’s an incredibly useful piece of information that should probably be the first thing in the gzip man page.

Lesson of the weekend 5: gzip can only compress a single file.

How do I know this? From a Google search on [gzip tutorial]. I no longer remember the exact page, but I now knew that what I needed to create was a tarball. Reread everything I just said about gzip, but replace gzip with tar. I finally found this page, created my tarball, and used OS X’s command-line FTP client to upload it to my DreamHost account.

I used SSH to connect to DreamHost, and used gunzip and tar to upback my tarball. (I’m already familiar with SSH because we sometimes have to use it, via PuTTY, at work.) One note, I could only get SSH to work if I connected using ’ssh username@hostname’ within terminal. Supplying the username via a parameter, or leaving it off completely didn’t work. Have I mentioned how much the SSH man page sucks?

Though it only took a few minutes to read, this took several hours to actually accomplish, plus I was really tired so I went to bed.

However, I was super jazzed and couldn’t really sleep. The great thing about learning gzip, tar, and SSH is that these tools exist on practically every computer in existence, so long as it’s not running Windows (and doesn’t have Cygwin or something similar). I could do this on DreamHost’s Debian Linux machines, the Solaris machines at work, or any Unix box. This exercise was a giant leap in my quest to move beyond Windows.

I got my brain to relax by working on a Rubik’s Cube. (I can solve everything but the last two corners! Arrgh!)

Since this is a natural stopping point, and this post is already too long, I’ll continue the rest of this story later. Let’s just say that what happened on Sunday was even cooler.