Just a quick note to let everyone know that contact via email should be back up and running here at the site. Comments are also a good way to get in contact with me (plus they benefit everyone).

There has been quite a bit of news recently on the escalating war of words between Adobe and Apple. For the uninformed, Apple has essentially said "no Flash, ever" for either the iPhone or iPad, and Adobe has been pretty upset (rightfully so, in my opinion). Adobe employees have publicly denounced Apple, and Apple has fired back. It's all been a sort of "playground dispute" so far.

Let me first say that I don't love either company; they both have pretty serious failings in my eyes. But, in the end, I despise Adobe much less than I do Apple, so I'd love to see Adobe come out on top if at all possible. It occurred to me just the other day how Adobe could "get back" at Apple for this latest Flash debacle.

Simply put: Adobe should drop all OS X support for all of their future products. "If your OS won't support our products, our products won't support your OS." Just think about it: all of the artsy folks in the world who use Adobe products use them on Apple branded computers. Cutting them off might seriously impact Apple's new OS sales (and, admittedly, would probably hurt Adobe's bottom line, at least in the short term). But this seems like serious leverage to me. Granted, Apple's main revenue stream these days comes via the iPhone, but OS sales are still a vital piece of their puzzle. Putting the squeeze on a big vein like that might make Apple change its mind.

As this bickering continues, I can only hope that Android continues to grab market share. Could the iPhone vs. Android war turn into the Apple vs. IBM war from the 1980s? I can only hope so...

I've recently had a perfect storm of email woes here at this site. Last month, my email servers changed at DreamHost (for reasons I still don't fully understand), breaking all of my approved SSL certificates (not to mention my SMTP settings). Around the same time, I updated to Thunderbird 3.0 from 2.x. The new interface is bizarre, and I've only had problems from day one of the upgrade. As such, I am now actively working towards moving all of Born Geek's email (including this website) to GMail.

Unfortunately, someone is apparently squatting on my domain over at Google Apps. I attempted to reset the account password there, but no secondary email address is on record, making things much more difficult for me. I have started a manual password reset process (via proving to Google that I do indeed own the domain), and hope to have things up and running by this weekend.

Long story short, any direct emails sent to me through the contact form at this website may not be answered for a while. Please bear with me during this painful process.

It's nights like this that make me glad to be alive.

It has once again been ages since the last programming grab bag article was published, so let's dive right into another one, shall we? This time around, we'll be looking at some simple tricks involving GNU make.

1. Let Make Construct Your Object List

One common inefficiency in many Makefiles I've seen is having a manual list of the object files you are interested in building. Let's work with the following example makefile (I realize that this makefile has a number of design issues; it's a simple, contrived example for the sake of this discussion). I've highlighted the list of objects below (line 2):

CFLAGS = -Wall
OBJS = class_a.o class_b.o my_helpers.o my_program.o

all: my_program

my_program: $(OBJS)
    gcc -o my_program $(OBJS)

class_a.o: class_a.cpp
    gcc $(CFLAGS) -c class_a.cpp

class_b.o: class_b.cpp
    gcc $(CFLAGS) -c class_b.cpp

my_helpers.o: my_helpers.cpp
    gcc $(CFLAGS) -c my_helpers.cpp

my_program.o: my_program.cpp
    gcc $(CFLAGS) -c my_program.cpp

For very small projects, maintaining a list like this is doable, even if it is a bother. When considering larger projects, this approach rarely works. Why not let make do all this work for us? It can generate our list of object files automatically from the cpp files it finds. Here's how:

OBJS = $(patsubst %.cpp,%.o,$(wildcard *.cpp))

We are using two built-in functions here: patsubst and wildcard. The first function will do a pattern substitution: the first parameter is the pattern to match, the second is the substitution, and the third is the text in which to do the substitution.

Note that, in our example, the third parameter to the patsubst function is a call to the wildcard function. A call to wildcard will return a space separated list of file names that match the given pattern (in our case, *.cpp). So the resulting string in our example would be: class_a.cpp class_b.cpp my_helpers.cpp my_program.cpp. Given this string, patsubst would change all .cpp instances to .o instead, giving us (at execution time): class_a.o class_b.o my_helpers.o my_program.o. This is exactly what we wanted!

The obvious benefit of this technique is that there's no need to maintain our list anymore; make will do it for us!

2a. Use Pattern Rules Where Possible

One other obvious problem in our example makefile above is that all the object targets are identical in nature (only the file names are different). We can solve this maintenance problem by writing a generic pattern rule:

%.o: %.cpp
    gcc -c $< -o $@

Pretty ugly syntax, huh? This rule allows us to build any foo.o from a corresponding foo.cpp file. Again, the % characters here are wildcards in the patterns to match. Note also that the command for this rule uses two special variables: $< and $@. The former corresponds to the name of the first prerequisite from the rule, while the latter corresponds to the file name of the target of this rule.

Combining this pattern rule with the automatic list generation from tip #1 above, results in the following updated version of our example makefile:

CFLAGS = -Wall
OBJS = $(patsubst %.cpp,%.o,$(wildcard *.cpp))

all: my_program

my_program: $(OBJS)
    gcc -o my_program $(OBJS)

%.o: %.cpp
    gcc $(CFLAGS) -c $< -o $@

This is much more maintainable than our previous version, wouldn't you agree?

2b. Potential Problems With This Setup

Astute readers have undoubtedly noticed that my sample makefile has no header (.h) files specified as dependencies. In the real world, it's good to include them so that updates to said files will trigger a build when make is executed. Suppose that our example project had a header file named class_a.h. As the makefile is written now, if we update this header file and then call make, nothing will happen (we would have to make clean, then make again, to pick up the changes).

Header file dependencies aren't likely to be a one-to-one mapping. Fortunately, we can get make to automatically generate our dependencies for us. Furthermore, we can get make to include those automatic dependencies at execution time, without any recursive calls! The process for doing this is above and beyond the scope of this article, but I will be writing an article on this very subject in the near future (so stay tuned).

3. Target-Specific Variables Can Help

Suppose that we want to build a debug version of our program using a target. Wouldn't it be nice to be able to modify some of our variable values given that specific target? Well, it turns out that we can do just that. Here's how (the added lines have been highlighted):

CFLAGS = -Wall
OBJS = $(patsubst %.cpp,%.o,$(wildcard *.cpp))

all: my_program

debug: CFLAGS += -g3
debug: my_program

my_program: $(OBJS)
    gcc -o my_program $(OBJS)

%.o: %.cpp
    gcc -c $< -o $@

In this example, when we type make debug from the command line, our CFLAGS variable will have the appropriate debug option appended (in this case, -g3), and then the program will be built using the specified dependencies. Being able to override variables in this manner can be quite useful in the right situations.

Do you have your own make tips? If so, leave a comment! I'll be posting more about doing automatic dependency generation with make and gcc in the near future.

Back in December of last year, I made the decision to ditch my land-line telephone and go wireless only. I decided to pick up a smart phone, and chose the Motorola Droid: both because of the Verizon network (with which I was relatively happy) and because it wasn't an iPhone. Now that I've had an opportunity to play with it for a few months, I'd like to share some thoughts on the device.

Droid Hardware

Seeing as this is my first smart phone experience, I don't have anything else to compare it to, but the hardware is solid. It feels well built, looks nice (in a utilitarian sort of way), and works very well. The phone is heavy, which can be a minor annoyance. I like the fact that I can use either a physical or virtual keyboard, though the physical keyboard is a bit tight. Oddly enough, I find myself switching between the keyboards pretty frequently; sometimes I'll use the physical keyboard, while others I'll use the virtual one. Automatic word prediction, a feature I enjoy using, only works with the virtual keyboard, which probably explains why I bounce between the two (depending on how much I need to type).

The external speaker sounds great, which is a plus when I use the speaker phone. Equally as good is the display, which has vivid colors and incredibly crisp text. The touch screen is decent, though I can't help but feel that it's not quite as good as it should be. I sometimes have a tough time getting it to pick out exactly where to click, especially on crowded web page designs. Scrolling can occasionally feel laggy, but it has a nice inertia to it, which I appreciate (I hear that Android 2.1, which has yet to be released as of this writing, improves scrolling responsiveness). Fingerprints are obviously an issue on a touch screen, and a minor annoyance, but I've learned to live with them. Storing the phone in my pocket surprisingly helps keep the screen clean!

The battery has been nothing but a problem since the day I got this phone. Sometimes, I can get two or even three days of battery life out of a single charge (depending on my usage), while other times I get less than a single day. Occasionally, the battery will drain itself for no apparent reason. Several software bugs involving the battery are also still lurking in the OS; the charge indicator will report a values of 5% or 15% at random times. Plug the phone in, and the indicator resets itself. Hopefully this problem will be worked out in Android 2.1.

Wireless reception is a mixed bag. Signal strength is terrific in the car and outside. In my house, I get decent signal (between 2 and 3 bars). At work, and in many big-box stores, I get absolutely no signal whatsoever. My signal at work is so bad, that I essentially can't answer calls without walking out of the building (and I sit so far from a door that I can't make it outside before my voice-mail picks up the call). This annoys some people to no end, but I don't know of a decent way to deal with the problem, short of getting a new phone number via Google Voice, a solution I'm not terribly interested in.

Wi-fi support is terrific, as is the built-in GPS (which I'll come back to in a moment). Rounding out the hardware is the camera, which is nice, but something I haven't made much use of. The 5 megapixel resolution is a bit much in my opinion, as resulting images are too large for uploading to the web (I had to grab a free app to resize images for posting purposes).

GPS Navigation

The Droid comes with free turn-by-turn navigation via Google Maps. This is my first experience with a GPS navigation device and I absolutely love it. Google Maps navigation has been updated several times since I got the phone, with some terrific new features, including pinch-to-zoom, improved search results, and more. Navigating at night is convenient with a night-mode (on-screen graphics are dimmed to avoid being so bright), and drive time estimations are typically quite accurate. Being able to get real-time traffic reports is another great feature that has come in handy a time or two. The navigation software will even reroute your directions if you drive off course, which can be quite handy in the right situations (a missed turn, for example). I picked up a weighted, friction dash mount for using it in the car (I didn't want a suction cup on the windshield), and so far so good.

Software - Android OS

I'm pleased with the Android operating system. User actions have a nice feel to them, and I think the layout is clean and efficient. Again, I have nothing else to really compare this to. Changing the phone's settings can be a bit of a bother. There are loads of menus and sub-menus, and it's hard to remember where certain settings are stored. There are places here where some additional polish would be welcome. For example, it's super easy to set my phone to silent mode on the unlock screen; but when I'm actually using the phone, I have to navigate through several menus of options to make that change. This kind of inconsistency, especially for something so common as a silent mode switch, is bizarre.

As a developer, I'm impressed with how Android works behind the scenes. Applications are actually collections of code chunks. In other words, there's no "main" function like your typical computer program. I won't go into why this is the case here, but suffice it to say that these design decisions make for some interesting capabilities.

Software - Apps

A number of terrific applications are available for Android, though the library is currently much smaller than the iPhone's software library (though, to be fair, the iPhone has been out for far longer). I routinely use several apps:

• WeatherBug for forecasts (this app has the cleanest look of all the weather apps I've tried, which is saying a lot, considering how terrible the WeatherBug website is).
• Either Twidroid or Seesmic for Twitter access, depending on my mood.
• Shopping List Plus for grocery lists. Not a perfect app, but it lets me say so long to pen and paper!
• Wapedia for accessing Wikipedia articles (I can't find a decent link for the app itself).

Concluding Thoughts

So far, I'm happy with the decision to switch to wireless only. Although I occasionally miss the clarity of a land-line telephone, I find this wireless phone is good enough for the little amount of talking I do. Having a phone that's capable of doing other tasks for me (managing my calendar, my shopping list, catching up on Twitter, etc) is great, and I don't see myself going back.

I may or may not have mentioned before that I have a goal of visiting and photographing every state park in North Carolina. As a precursor to setting out on that goal, I have created a map of state park locations. Each location uses GPS coordinates provided by the state park service. Now that I have a GPS device that uses Google Maps (a Motorola Droid; review coming soon!), I figured this would be a terrific way to make it easy for me to get driving directions to certain locations.

While looking through all of the official state park pages, I learned a number of interesting facts:

• Four state parks require entrance fees out of the 39 parks in the state. They include Jordan Lake, Kerr Lake, Falls Lake, and Chimney Rock.
• Two state parks do not have public access or public facilities at this time: Mayo River State Park and Haw River State Park.
• One state park can only be accessed by taking a ferry: Hammocks Beach State Park.

The location markers on the map I've created are currently being used by me to keep track of where I've been. However, the map is publicly available, so feel free to use it to navigate to any of the state's parks. If you have any suggestions on how the map could be improved, feel free to leave a comment. I'd like for this to be a helpful resource for people.

As shameful as it is for me to say, I had not, until just recently, ever read The Hobbit or The Fellowship of the Ring (or, for that matter, the other two volumes of The Lord of the Rings). I'm not sure why I never read them. Perhaps it's because I heard from some people that the books were hard to read. Well, I'm finally getting around to reading them, and I must say that I've enjoyed them thoroughly. Here are some thoughts:

The Hobbit

Though technically not a part of the The Lord of the Rings, The Hobbit is clearly where it all starts. As such, I read this book first, and I'm glad I did. Reading this story first provides a great deal of context for things learned in Fellowship. I particularly loved the way the book was written: it always seemed to me like an old man was telling me the story as we sat around a camp fire. Often the narrator would go off on a tangent, then later realize that he had gotten onto a tangent, and would finally have to apologize to you, the reader. Very enjoyable. The one thing I didn't like about this story was the abrupt ending. After the climax is a single chapter, wrapping up a number of threads in a short period of time. Such a jarring transition seems detrimental to the whole story on some level. Overall, however, a terrific story.

The Fellowship of the Ring

This is by far one of the best books I've read in a long time. Tolkien's command of the English language is outstanding, as is his inventiveness. Every character feels alive and their interactions are wonderful to experience. My absolute favorite scene is at the parting of the Company with Galadriel and Celeborn from Lothlórien. Galadriel gives each member of the Fellowship a gift, and she asks Gimli, the dwarf, what he would like. At first he says he wants nothing, but she presses him, so he answers that a single hair from her head would be his heart's desire. He then continues to assert that he doesn't want this; he's only saying so because she commanded him to speak. Here is her reply:

The Elves stirred and murmured with astonishment, and Celeborn gazed at the Dwarf in wonder, but the Lady smiled. "It is said that the skill of the Dwarves is in their hands rather than in their tongues," she said; "yet that is not true of Gimli. For none have ever made to me a request so bold and yet so courteous."

She then asks Gimli what he would do with such a gift, and he replies that he would simply treasure it, in memory of her words to him at their first meeting. This pleases her, so she gives him not one hair, but three. Gimli takes them and vows to have them set in an imperishable crystal to be an heirloom in his house, and a token of goodwill between the Dwarves and the Elves until the end of time.

Scenes like this one are peppered throughout the text, and are truly wonderful to take part in. I'm greatly looking forward to the next two books, even though I know how the story plays out.

One of the things I most appreciate about Perl is that it requires code blocks to be surrounded by curly braces. In my mind, this is particularly important with nested if-else statements. Many programming languages don't require braces to surround code blocks, so nested conditionals can quickly become unreadable and much harder to maintain. Let's take a look at an example:

if (something)
    if (another_thing)
    {
        some_call;
        some_other_call;
        if (yet_another_thing)
        {
            do_it;
            do_it_again;
        }
    }

Note that the outer if-statement doesn't have corresponding curly braces. As surprising as it may seem, this is completely legal code in many languages. In my opinion, this is a dangerous programming practice. If I wanted to add additional logic to the contents of the outer if block, I would have to remember to put the appropriate braces in place.

Had I attempted to use this code in a Perl script, the interpreter would have complained immediately, even if warnings and strict parsing were both disabled! This kind of safety checking prevents me from shooting myself in the foot. Some may complain that requiring braces makes programming slightly more inefficient from a productivity standpoint. My response to that is that any code editor worth its salt can insert the braces for you. My favorite editor, SlickEdit, even supports dynamic brace surrounding, a feature I truly appreciate. It's a shame that more programming languages don't enforce this kind of safety net. Hopefully future languages will keep small matters like this in mind.

On February 22, several new laws went into effect in the United States in the attempts to protect consumers from credit card companies. Included among these laws is a rule that credit card statements must include information on how long it will take to pay off the balance when paying the minimum amount each month. I've heard a great deal of talk on the radio about this particular change, mostly to the effect that it should help wake people up to the fact that minimum payments aren't a great idea, at least from the consumer's point of view; the credit card companies love this scenario.

That got me thinking about credit cards in general here in the United States. According to creditcards.com, the average credit card debt for American households in 2008 was $10,769 (for households with a credit card); almost $11,000! It boggles my mind that there are people out there with a running balance that high. My credit card debt is $0, which means someone out there has a debt of nearly $22,000! How does that even happen?

Most people must live well above their means, which makes no sense to me at all. Maybe that's because I've been pretty tight with my money all my life. I remember saving up chore money to buy my first Nintendo system. Every video game purchase was a result of hard work and scrimping and saving on my part. As a kid, I literally kept paper ledgers tracking how much money I was taking in versus how much was going out. Saving just came naturally to me. I paid for every vehicle I've ever owned, I paid for my college education, and I graduated debt free (or nearly so; I had about $1000 in student loans which I immediately paid off once I got a full time job). I'm what the credit card industry calls a "deadbeat." I pay my bill on time, in full, every month. How can I possibly do that? By staying within my means!

I essentially treat my credit card like a debit card: I know how much money I have in my bank account, so I know not to spend more than that. It's not that hard! Online money management tools like Mint.com only make that process easier. Month to month, I can track where my money is going, and how I'm doing overall.

I'm not sure what the answer to America's credit card debt problem is. At the very least, money management should be taught in school. Growing up, I had plenty of friends who got into trouble with money by purchasing things well outside of what they were capable of. The sad thing is that money management isn't that hard; it simply takes a little bit of self control. Which is something most Americans apparently just don't seem to have.

So that all of my regular readers are aware, I am taking a much needed break from blogging during the month of February. I've been in a writing funk lately, and I figured that a small break would do me some good. Updates will resume in March.

What do you think about Apple's iPad? Will it fly, or will it flop? Here are a few brief thoughts I had on the newest product from Cupertino:

• The name is absolutely terrible
• No physical keyboard is a huge minus on something this size
• Only one connector (Apple proprietary) is a huge mistake
• Data plans through AT&T are a big negative
• What does this give me that I can't do already on my laptop or netbook?
• No multitasking seems like a poor decision
• What a terrible name!

Perhaps Apple will prove me wrong, but I can't see this device catching on the world over. The "cool" factor just isn't there; the keynote demos consisted of boring stuff like editing spreadsheets and documents, something the "kids" of today aren't interested in. So what do you think?

In my recent post on gripes I have with Firefox 3.6, I mentioned in passing that I detest (and disable) the AwesomeBar. I had a recent lunch-time discussion with Dustin about this very topic, and Michael asked about it in a recent comment, so I thought I'd post a few thoughts on why I dislike the AwesomeBar as a whole.

For the uninitiated, the AwesomeBar is simply the address bar in Firefox 3.0 and later. Prior to version 3, the Firefox address bar was a simple edit box with an associated drop down menu. URLs that you manually entered into this box were saved in the URL history (the drop down menu), and would be auto-completed in future accesses to the URL bar. When Firefox 3.0 was released, Mozilla changed the behavior of the URL bar considerably. Instead of being a repository for typed URLs, the address bar became a "one-stop shop" allowing users to search through bookmarks, history, and previously typed URLs.

So what do I dislike about it?

Performance, Performance, Performance

Without a doubt, this is my number one complaint with the AwesomeBar (and, these days, Firefox in general). When the AwesomeBar made its debut, its performance was terrible. It was so slow, in fact, that as I typed into the URL bar, I would lose key strokes as Firefox struggled to keep up with potential suggestions. For example, as I typed a URL like https://borngeek.com/, I would end up with something like http://wweek.com/ (note the loss of the w.borng characters). Behavior like this is completely unacceptable, but was, for me, the norm for a long time. I'm not sure if Firefox still suffers from this issue because I never use it!

Results Ordering

When the AwesomeBar was first introduced, there was no way to specify what it should suggest as you search. As a result, there was much debate about which results should appear higher in the results list: should history take precedence over bookmarks, or vice-versa? In my experience, search results were never what I wanted them to be. Often, my target search would be the third or fourth result from the top, requiring me to use the arrow keys to select it. Poorly sorted suggestions essentially forced me to scan the results list for each query, wasting my time in the process. I know that Firefox has improved this greatly (you can now specify what kind of results are returned), so this is an admitted non-issue today.

Why Do I Need This?

My last complaint is simply, why is the AwesomeBar something I need? Unlike many computer users, I have very few actual bookmarks; instead, I maintain a static-HTML page of links I frequently visit. Because my bookmark count is so low, I never have a need to search my bookmarks; I already know what is or is not there, as well as how to get to it. Similarly, it's not often that I need to search my browsing history. When I need to do so, I simply open the history sidebar (Ctrl + H) and search there. What was the AwesomeBar giving me that wasn't already available in the browser? I'm not sure the answer to that is very substantial.

I think I would have more respect for the AwesomeBar if it came disabled by default. Shipping Firefox 3.0 with this enabled radically changed the behavior of a key UI element, something that seems pretty dangerous to do from a "keep the end user happy" standpoint. Mozilla enjoys screwing around with the default settings, however, so I've since come to expect this kind of thing from them. For now, the AwesomeBar is disabled in my browser. Until I see a good reason to do otherwise, it will stay in its upright and locked position.

Last night, while surfing around for some medical information, one of the sites I stumbled upon through Google's search results tried to install a Trojan on my computer! This was surprising, seeing as I was using Firefox 3.6 with AdBlock turned on. Thankfully, Microsoft Security Essentials saved the day, alerting me to the fact that a nefarious application was trying to install itself. The tool caught the incursion, alerted me, and successfully removed it from my system. I then did a full scan and it found no other problems.

I've read that drive-by attacks like this are becoming more common, but until now I hadn't ever been affected. Several of my plug-ins were outdated, so I updated them, though I'm not certain any of them were involved in this attack (Java never loaded, and there was no embedded media on the site).

That being said, make sure to surf with protection; there's some nasty stuff out there.

As you have undoubtedly heard by now, Firefox 3.6 has been released. I've been using it for a few days now (I picked up the release candidate earlier this week), so I have a few thoughts on it.

Faster Performance

If Firefox 3.6 is faster than 3.5, then it's not by much. I have yet to see any gains. When I installed Firefox 3.6, I blew away my old installation completely. I'm using a new profile, with a fresh install, and cold starts still take upwards of 15 or 20 seconds on my laptop (Core 2 T7400 at 2.16 GHz, with 2 GB of memory, on Win XP). I only store 14 days of history (versus 90 days by default), I turn off the Awesomebar (which I hate), and I only use 7 extensions (Adblock Plus, CoLT, Console², Firebug, Googlebar Lite, Linkification, and Web Developer), none of which seem to be the problem. Mozilla had better make significant gains here in the future. Browsers like Chrome are literally miles ahead in this realm (Chrome cold-starts on my system in as little as 5 seconds).

HTML 5

I haven't played with the HTML 5 stuff, but there's been plenty of news about websites adding HTML 5 variations of their content (like YouTube and Vimeo). The only problem? Firefox doesn't support the H.264 encoding being used by these sites! I understand their licensing standpoint, but if the world chooses H.264 over OGG, they had better jump on board pretty quick.

Personas

Do we really need Personas? This feels like something that AOL would have rolled out back in the day, for every grandma computer user. The real-time preview mechanism feels very scary to me; the fact that document-level content can alter the look and feel of my web browser feels like a security nightmare waiting to happen. What kinds of exploits will crop up as a result of this?

Plug-in Checker

This is the one feature of 3.6 that I actually appreciate. A new update mechanism allows you to quickly see if your plug-ins are out of date, which was pretty painful before. Unfortunately, I have a number of plug-ins on my laptop here that aren't recognized by the updater, but maybe that will improve with time.

I'm hoping that the next release of Firefox, whenever that may be, will be a step in the right direction. Lately, Mozilla really seems to be heading into some strange territory. As much as I love Firefox, I'm growing tired of the bloat, I dislike their possible plans to ditch extensions, and the new UI features seem insipid at best.

The only thing holding me back from moving to Chrome (which I also enjoy), is the lack of decent extension support. When that feature gets implemented, I just may switch, so consider yourselves on notice Mozilla. The next Firefox release had better be good to win back my respect.

Earlier this week, I picked up a copy of the 2004 title Thief: Deadly Shadows from Steam. Last night, I found out the hard way that the game doesn't auto-save your progress; my character fell from a lofty spot, died, and I lost a couple of hours of progress. This got me thinking about the state of auto-saving in video games today, something that I now clearly take for granted.

Back in the day, games never auto-saved your progress. One of the earliest titles I recall using an auto-save feature was the original Far Cry, which (in actuality) used a checkpoint saving system. I'm sure there were titles before that which used an auto-save mechanism (the first Serious Sam might have used one back in 2001). Since that time, nearly every game I've played has had some form of an auto-game saving mechanism.

Take one of my current favorite games, Torchlight. With regards to saving your progress, it lies at the complete opposite end of the spectrum from most old games: you cannot, at any point, manually save your progress! In essence, it only auto-saves, nothing more. What a change from having to consciously remember to save every so often.

Going forward in Thief: Deadly Shadows, I'll have to remind myself to save every so often. Otherwise, I'll end up wasting more time like I did last night. Live and learn.

Earlier today, I finished watching the fourth and final season of It's Garry Shandling's Show. I enjoyed the whole series so much, that I wanted to share a few thoughts on it. For those who don't already know, It's Garry Shandling's Show was a sitcom that ran on the Showtime network between 1986 and 1990. In it, Garry Shandling plays himself, and is fully aware that he is a sitcom character. All of the characters around him also realize that they are a part of a television show, so the whole experience is very "meta." Garry often involved the studio audience in the story, and each show opened and closed with a monologue. The fourth wall was broken as a rule on the show, not as an exception, so the viewer at home was usually in on every situation and joke.

What I like most about the show is how unique a premise it is, even to this day. Having the characters of the show all realize that they are on television is very clever and made for some great gags. Garry would often exploit this fact to the fullest; whether walking between sets to keep a thread going, or advancing time in silly ways to push the story forward. The supporting cast is all terrific, and the comedy outstanding. There were some episodes where I literally laughed until I cried. You gotta love a show that can do that.

The fourth season is definitely the weakest of them all. I listened to a number of episode commentaries, and it was interesting to learn that many of the writers felt the show went in the wrong direction in the fourth season. Showtime had a fairly small audience, so the show's ratings were never terrific (even though it was nominated for, and won, a number of awards). After Fox picked up the last two seasons, ratings tanked, mostly because the show was never meant to air with commercials. Upon debuting on Fox, the show came in at number 99 out of 100 shows; only The Tracey Ullman Show was worse. Interestingly enough, during the fourth season, many of the writers from It's Garry Shandling's Show also went to work on a little television show called The Simpsons, which debuted in the top 5 of the ratings. It's ironic, then, that the same writing staff would garner a top 5 rating and a 99th rating in the same year.

If you get a chance to check out this show, I highly recommend it. In some ways the show may be dated, but the humor is clever, and there are some very ground-breaking ideas. I'm greatly looking forward to checking out Garry's subsequent show, The Larry Sanders Show.

Over the holiday break, I stumbled upon a wonderful article describing several CSS tricks to add eye-candy without images. I've been using rounded corners here at the site since the last theme update, and thanks to this article, I'm now employing drop shadows. The effect is subtle, but adds a lot to the design; in short, I like it.

The style rules for adding drop shadows are very simple, though proprietary; it's a shame this stuff can't be standardized properly. Here's the code to use a drop shadow (the values shown are the ones I'm using on the site):

#myelement {
    -moz-box-shadow: 1px 1px 3px rgba(0, 0, 0, 0.5); /* Firefox */
    -webkit-box-shadow: 1px 1px 3px rgba(0, 0, 0, 0.5); /* Webkit */
    box-shadow: 1px 1px 3px rgba(0, 0, 0, 0.5); /* Standards way */
}

The article even details the appropriate style code for Internet Explorer, but I haven't included it here, mainly because it's ugly. Other effects that the article explains are glow (the opposite of drop shadow, essentially), gradients, rotating images with CSS, transparency, and a few more advanced tricks. It's great that this support is built-in to most standards compliant browsers. So long to those annoying images that try so desperately to do the same thing!

Update: So it turns out that adding this eye candy significantly reduces scrolling performance in Firefox (quite an annoyance). Chrome doesn't have this issue, so it's clearly a Firefox problem. Should I keep the shadows and suffer the performance hit? Or should I chuck them and keep things snappy?

Also, Webkit browsers don't support the inset modifier for shadows, which means you see even less eye candy in Chrome, et al.

Update 2: I've removed the drop shadows for the time being. After all, this stuff is experimental.

I recently stumbled on an incredibly wonderful website; one that threatens my productivity just as much as Wikipedia does. The Vintage Ad Browser is a trip down memory lane, showcasing magazine advertisements from as far back as 1800. All kinds of categories are available to peruse: from Airlines & Aircraft, to Gender (some of which, today, are quite sexist), to Transportation. This site is one of those black holes on the internet, where you can get lost down a trail of links. I highly recommend checking it out; definitely worth bookmarking.

For better or worse, my online news site of choice is CNN.com. Last year, when they rolled out their new look, they also introduced a feature (which is still in "beta") called NewsPulse. It's essentially a look at what stories are being viewed most by site visitors during a given time period. For quite some time now, I've found the feature amusing, so I try to check it every once in a while. The most popular stories (over a longer period of time) typically fall into one of the following three categories:

1. Celebrity stories
2. Stories involving sex
3. "Big News" stories

In general, the popularity of any given story follows the order above. Celebrity news, especially celebrity death stories, seem to be very popular. The recent death of Casey Johnson, the Johnson & Johnson heiress, was particularly popular because it fit both of the first two categories: she was a 'celebrity' and very openly gay.

I've always enjoyed looking at statistics like this. Google's year-end zeitgeist is equally as enjoyable to peruse (though, it's obvious that it's filtered to be family friendly). This kind of data paints an interesting picture into our culture's interests.