As I’m sure you recall from my earlier post, I had managed to upload an archive of our old blog to the new site.
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.
{ 2 } Trackbacks
[...] code and reading books.Just for a refresher, in part 1 I migrated our old blog to this new site. In part 2 I used some Perl to fix some problems caused by the migration and spent a lot of time learning [...]
[...] dialogs. This must have involved a significant development effort on Apple’s part. (I have some experience with web browser development.) I think they must really want pages to look identical in all [...]
Post a Comment