Indirecthit » Tips

Media, Cookies & Domains

clong — Tue, 02 Mar 2010 14:34:41 +0000

With all the brilliant tools (Google Page Speed, YSlow, etc.) out there, web professionals can now easily see a few basic things to improve page speed performance. One suggestion is to send static content from a cookieless domain. On most sites I’ve worked with, we serve static content from a media subdomain and then the real content from the main domain (without www). I know with cookies, if the domain is .indirecthit.com it would send that cookie to any subdomain on indirecthit.com, therefore the media subdomain would have a cookie. An easy change: remove the . from the cookie domain. But when I looked at the PHP manual for setcookie, I came across the following statement:

The . is not required but makes it compatible with more browsers.

That doesn’t sound very good, I want it to be compatible with all browsers…

I couldn’t find much on it, from what I did find I believe the reason it doesn’t work with all browsers is for security. If I had the domain er.com, and I set a cookie to the domain er.com (notice the missing .), the browser could match this with older.com or lesser.com. If the website at er.com set the cookie to er.com (without the first .), the web server on older.com or lesser.com can access this cookie…not good. Therefore, even if I remove the . from the domain, it still would match media.indirecthit.com and that domain wouldn’t be cookieless.Doesn’t solve my problem and isn’t compatible with most browsers.

The solution, is to split out your media server on a different domain such as indirecthitmedia.com. This is why when you visit some Google properties it loads media content from gstatic.com not media.google.com or google.com. And obviously you don’t set any cookies to this new media domain. You will now score a bit higher on Google Page Speed and YSlow. Congrats!

Optimizing SQL Select: Using ‘IN’ in MySQL

clong — Thu, 10 Apr 2008 15:16:29 +0000

I’ve known for a bit that using the ‘IN’ condition for MySQL queries is much much slower then it should be. I didn’t realize how much will I was browsing the website Common Queries for MySQL and came across the section called The unbearable slowness of IN().

According to this page, using IN is two times slower then using EXISTS which is 50 times slower then using a JOIN. Wow! I don’t think I’ll be using IN anymore.

Conclusion, if you want to make your query faster don’t use IN. Take a look at The unbearable slowness of IN() for how to write the query using an EXIST or, if possible, a JOIN.

Finding Rural Postal Codes in Canada

clong — Fri, 28 Mar 2008 13:57:09 +0000

Yesterday, Alex, who handles marketing at Well.ca, asked for a list of top 50 rural customers in Canada. “Easy!” was my reply, then I thought about it. How to do it? Maybe if I get a list from Canadapost with all the postal codes and their population density I can use that. Maybe I can write up some crazy application to determine it based on the number of cities/towns that share the postal code.

And then, just for the hell of it, I checked Wikipedia’s article on Postal Codes…then the problem just became easier. According to the Wikipedia article, the first number in the postal code represents if the postal region is rural or urban. If the number is 0 (N0G2J3), the postal region is a rural area. If the number is anything else, 1-9, the postal region is an urban area. With this I wrote up a quick regular expression (^[a-zA-Z]{1}[0]{1}[a-zA-Z 0-9]+) and used the power of MySQLs regular expressions (have to remember MySQL can search w/ regular expressions) to write up a query to determine the top 50 rural customers. Easy!

Random fact: Wikipedia has all possible postal region codes (first 3 digits of the postal code) and their corresponding city/region. I wonder who took the time…The article is here.

Random fact II: The only provinces to have more then one letter as the first letter in a postal code is Quebec and Ontario. All the others have a specific letter to determine the province/territory. The map is here.