ohryan.ca

A Web Developer in Winnipeg

  • Facebook Does It Again

    in ,

    I feel compelled to comment on the new Facebook layout. Based on status updates, I was one of the last people on my friends list to receive the new layout. Every single one of their status updates were negative, all of my Facebook friends universally hated the new layout. It seems like that last redesign only came out a 3 or 4 months ago, I wonder if this might been partially responsible for the backlash. It’s human nature to hate change.

    I must say, when I first saw the screenshots of the new layout posted on the official Facebook blog a few weeks ago I was rather optimistic. The FB crew seemed to be embracing the new “real-time” web that’s become popular with the rise of Twitter. I really like the way that all your friends’ updates just appear in one big long list. It’s a major improvement over the old “news feed” which was entirely broken! There would be times when I’d see a “story” 2 times on the same day, or the story would appear one day, then re-appear the next for no apparent reason. It was frustrating.

    I haven’t run across it yet, but I imagine they the real-time feed could easily become incredibly busy and equally unusable. The filters along the left-hand side should help to alleviate this problem. But it’s possible that at certain times of the day, for heavy users, there is going to be too much junk to weed through.

    I’m really not sure how I feel about the overal design itself. They left the header and (floating) footer alone. Those two elements have have always been the least useful, most confusing elements of the site (like why does the “Inbox” drop down menu have a link to “view message inbox” that takes you to the same place as clicking “inbox” – baffling!). It’s lacking something I can’t quite put my finger on. It’s empty and busy at the same time, if that’s possible.

  • Even Google Makes Mistakes

    in

    This is an expert from a Gmail Blog Post re: the recent gmail outage:

    Unexpected side effects of some new code that tries to keep data geographically close to its owner caused another data center in Europe to become overloaded, and that caused cascading problems from one data center to another. It took us about an hour to get it all back under control.

    This sounds exactly like the types of bugs I create. The fact that Google makes these sorts of mistakes, even though they do a lot more testing and have bigger teams, etc; makes me feel good about my programming skills.

  • Revisiting Mobile Redirection Using .htaccess ReWrite Rules

    in

    This article is out of date, check my latest code snippet here.
    Back in 2007 I wrote a post detailing a method for detecting and redirecting mobile browsers using .htaccess. Since then the mobile landscape has changed quite a bit: iPhone and Android have been released, the PDA market is all but dead and phones are better in general.

    My original post was based on a PHP script by Andy Moore. It’s worth noting that he has continued to update his script and now has a fancy little generator to help you create a PHP based redirect ruleset. Check out detectmobilebrowsers.mobi for more info.

    His solution will probably work for a lot of applications, but there are 2 main reasons I prefer using Apache’s rewrite rules to redirect mobile browsers:
    1) Application independent. By putting the rules in the root .htaccess file you can easily redirect traffic across multiple directories, independent of any webapp that might or might not be running in those directories.
    2) Faster. Placing the rewrite rules in apache’s httpd.conf file is potentially faster, than running the regexp in a php script for every request.

    Enough of that, here’s the updated ruleset.

    # don't apply the rules if you're already in the mobile directory, infintine loop
    # you'll want to test against the host if you're using a subdomain
    RewriteCond %{REQUEST_URI} !^/mobiledirectoryhere/.*$
    # if the browser accepts these mime-types, it's definitely mobile, or pretending to be
    RewriteCond %{HTTP_ACCEPT} "text\/vnd\.wap\.wml|application\/vnd\.wap\.xhtml\+xml" [NC,OR]
    # a bunch of user agent tests
    RewriteCond %{HTTP_USER_AGENT} "sony|symbian|nokia|samsung|mobile|windows ce|epoc|opera" [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} "mini|nitro|j2me|midp-|cldc-|netfront|mot|up\.browser|up\.link|audiovox"[NC,OR]
    RewriteCond %{HTTP_USER_AGENT} "blackberry|ericsson,|panasonic|philips|sanyo|sharp|sie-"[NC,OR]
    RewriteCond %{HTTP_USER_AGENT} "portalmmm|blazer|avantgo|danger|palm|series60|palmsource|pocketpc"[NC,OR]
    RewriteCond %{HTTP_USER_AGENT} "smartphone|rover|ipaq|au-mic,|alcatel|ericy|vodafone\/|wap1\.|wap2\.|iPhone|android"[NC]
    # put your rewrite rules here

    Text Version

    As you can see, the user agent list is a fair bit less verbose. I’ve been testing the ruleset on a very busy site, based on over 250k mobile site hits this set of rules is causing a lot fewer false positives, while not missing any significant number of mobile browsers.