thepointless.com: beginning facebook integration

I've been taking time recently to work on thepointless.com. Frankly, it generates significantly more traffic than Svidgen currently does, and I'd like both reward and harvest those visitors, rather than let the flow of people slowly die off as I have in the past.

On a content level, I've removed a lot of fluff and pushed article-type content out to the angry stickman blog. The site has been trimmed down to a few outbound links and two activities: the clickometer and the dots. Both of these have generated a good deal of traffic in the past and have been featured on other sites, including some youtube videos.

I've also started some facebook integration. So far, this has involved three things:

1. (re)Creating a facebook page
   This was pretty easy to do. The site is pointless, so the facebook page could be equally pointless. The primary obstacle, which is still an issue, is getting facebook to properly auto-update notes based on the RSS feed of the angry stickman blog.
   
   In general though, I find this to have been a good investment. The page allows me to instantly remind previous "likers" that the site is still there, and it's still awesomely pointless. Furthermore, because it's social, interactions with the facebook page serve as a free advertisement directly in friends' news feeds.
   
2. Adding a Like button to the site
   This was pretty easy to do. It's set to share the count with the corresponding facebook page. It's easy for someone to click if they like what they see. And that subscribes them to future status updates from the site. Good stuff.
   
3. and Basic "score" publishing
   The clickometer and dots provide "scores" after the initial interaction. Using the simple JavaScript FB API, these scores can be easily published to a user's FB news feed. And a few folks publish their scores every day, which occasionally leads to an increase in traffic, and more importantly, a really awesome news feed item.

From a marketing perspective, the ROI for reworking the site and starting some basic FB integration has already been great. I'm seeing traffic slowly increase. And I've seeing pages/visit increase drastically. People are engaging more with the site and publishing their interactions, which is turn is drawing more attention.

Since this blog is intended primarily for geeks, I'd be willing to write a little about any of the specifics of the "integration." But, I'm not going to rush on that unless someone voices their interest. The main points are these:

• thepointless.com has been remade and has my active attention.
• facebook integration, even on a basic level, is really beneficial.

In any case, keep your eye on thepointless.com for more updates. I'm thinking of recreating the monkey war next, with facebook integration -- but who knows? It's thepointless.com after all, anything could [or couldn't] happen ... 

A brief authentication issue has been resolved

An issue with authentication, which was reported this afternoon, was preventing users from signing in. We can see how preventing users from signing in might be bad for business. So, we promptly corrected it.

The issue involved a few misplaced lines of code that break the user out of SSL after successful authentication. The code should have been moved to it's new home with a larger segment of code, but it's such a small snippet of code that it was simply overlooked.

For those interested geeks:

if ($signin_event == true) {
    make_secure(false);
}


After successful authentication, the $signin_event flag is set to true. After the core signin routines are called successfully, the make_secure() method is called with a value of false, returning the user to the "non-secure" version of the site. For the production version of the site, this means redirecting the user from an https URL to an http URL.

However, the redirect() method used in this make_secure() method outputs the HTTP Location header with some informational HTML and then terminates the script. And this was occurring before the session cookies were being sent — not a problem for the staging version of the site, which requires no redirection when make_secure(false) is called. For the production site, however, this was preventing the cookie headers from being sent. (One might say that the $signin_event didn't really happen yet :) )

We failed to detect this, because we already had the session cookies from our previous sessions, and it really didn't seem like a game-changing update. So, for ourselves and anyone else who happens to be human, here are some web development reminders:

• Keep the "subtle" differences between yours staging and production environments in mind. They start to seem trivial after awhile, and they're easy to forget. But, minute differences can be crippling.
• Test authentication, session, and cookie-related updates with a clean cookie cache. This is most important when you're playing with cookies. But, anything that touches "the session" in a unique way should probably be tested from a blank state.
• Always keep in mind which methods terminate the script, blocking other important actions. In the very least, be ready to check your methods if you have any doubts. It can be difficult to debug strange behavior if you've totally forgotten than redirect() terminates execution instead of returning. One might say that redirect() should never terminate execution anyway. I didn't necessarily like implementing it that way, but there's good rationale for it in this case.
• Be careful when you copy and paste! It sounds like a simple and stupid reminder. But, I've been involved in web development for years, and I still forget to fully examine my context when I'm tired, bored, under-caffeinated, or simply doing something tedious.

This is by no means an authoritative, comprehensive list to avoid mishaps. It's what came to mind while I was writing this update. So, there you have it.

If you have any tips you'd like to share for avoiding mishaps like this, feel free to comment.

effective use of the expires header and client-side caching

There are two problems for web developers when it comes to client-side caching:

1. The browser aggresively caches everything on your site, so the user doesn't see your new images, scripts, or stylesheets for days or weeks.
2. The browser carefully checks for new images, scripts, and stylesheets on every page load.
   

So, there's one group of people who are seeing old content and another group of people bogging down your server, because their browser is carefully checking for updated files with each page load. It would be nice if you could just tell everyone and everything when to check for new content, wouldn't it be?

Well, to be quite honest, you can.

In fact, at its best, you would be telling every browser never to check for new images, scripts, and stylesheets. Don't be shocked--this is a good thing.

By doing this, you save on bandwidth and server resources. And when you need to roll out a new image, you just change the name, which forces all clients to download the new image! It can be as simple as adding a version number to the file or query string. For example,

logo.png -> logo.png?v=2 -> logo.png?v=3
In the example above, the file name stays the same, but you force the browser to check for an update with the query string.

If you can do this, you can rest assured that everyone is seeing up-to-date content, and your server is under a much lighter load.

The header tags you need to worry about look like this:
Cache-Control: max-age=259200
Expires: Thu, 01 Dec 1994 16:00:00 GMT
In general, if we assume your content should never expire, you need to set the date in this header to be one year from the time of file access, but no more per the W3 specs. There are two easy ways to do this. One, which I won't go into detail on, is serving all your images via a script, which allows you a lot of flexibility in many ways, including setting the expires and cache-control header.

The other way assumes you're using Apache, and it's very easy to do. It requires your Apache server have mod_expires enabled and either have access to your main configuration file or have .htaccess enabled. For most developers, mod_expires will be enabled by default, and if you don't have access to httpd.conf, you can probably use .htaccess.

So, it's as easy as adding the following lines to the end of your .htaccess or main config file (usually httpd.conf):
ExpiresActive On
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"

And so forth for each file type you wish to "force" caching on.

Doing this can save many sites a huge number of HTTP requests per page load--often reducing most page loads to the one HTTP request they should be. At the same time, you'll be forcing yourself to use "new" file names for updated content, effectively forcing everyone to see new images and styling exactly when you want.

Happy caching!