Mozilla’s missed opportunities

In the past couple of months Mozilla Corporation has sought to narrow its scope. First there was the announcement that at least for the next year and a half or so the focus of platform development will be on developing the Firefox browser as the platform. This primarily means no standalone XULRunner. And since being standalone was kind of the whole point. Now there’s the announcement that they’re dropping Thunderbird because they think it’s a distraction from building their web browser.

When I look at this graph from Janco Associates I see Firefox’s market share’s growth slowing:
(firefox market share chart)

The Making Of LOL Feeds

Last week I wrote and released my LOL Feeds site. It takes RSS or Atom feeds from the web and makes a series of lolcat-style images on a web page. It’s really way funnier than it sounds.

Initially I wanted to be able to auto-generate Jerk City comic strips based on my friends’ twitters, but when that seemed hard I opted for lolcats style images. After all we’d been seeing a lot of the lolcats on twitter – they’re displayed when the site is undergoing maintenance.

The original version of the script was very very clever. It used the Google AJAX Feed API and the Flickr API to pull in feeds and random images of cats from Flickr, combine them together with a PHP script I wrote to generate transparent PNGs of text live onto the page. It used the browser’s own text-flowing algorithms to lay out the text. It was however amazingly slow.

Browsers only allow a low number of concurrent connections to one site – four or eight I think – and this made the text crawl in. Also while the Google AJAX Feed API and Flickr API are pretty snappy they’re way slower than doing it server side. I was sad about this because I’m kind of in love with fully dynamic client-side applications (just look at my home page) but I actually wanted this to see the light of day.

Out with the old, in with the goo(gle)

[flickr-photo:id=28961855,size=m] Some time ago I reworked my home page to feature content from various other sites I post to (blogs, flickr, delicious) by using some JSON tricks to pull in their feeds. I blogged about how to do this with Feedburner’s JSON API, so that my actual page was just static HTML and all the work was done client-side.

Last week I decided to revisit this using Google’s new AJAX feeds API. Feedburner‘s API never seemed to be well supported (it came out of a hackathon) and it forced me to serialize my requests. In the process I neatened up a bunch of the code.

Insecurity is Ruby on Rails Best Practice

Ruby on Rails by default encourages developers to develop insecure web applications. While it’s certainly possible to develop secure sites using the Rails framework you need to be aware of the issues at hand and many technologies that make Rails a powerful easy to use platform will work against you.

Cross Site Request Forgery
CSRF is the new bad guy in web application security. Everyone has worked out how to protect their SQL database from malicious input, and RoR saves you from ever having to worry about this. Cross site scripting attacks are dying and the web community even managed to nip most JSON data leaks in the bud.

Cross Site Request Forgery is very simple. A malicious site asks the user’s browser to carry out an action on a site that the user has an active session on and the victim site carries out that action believing that the user intended that action to occur. In other words the problem arises when a web application relies purely on session cookies to authenticate requests.

OpenID for the mathematically challenged

The other day I got the OpenID bee in my bonnet and grabbed James Walker‘s module and installed it on my server. Actually I grabbed it from CVS, and then discovered that the CVS version is half-ported to some new Drupal 6 form API, so I ended up using the DRUPAL-5 tag.

Anyway, I use Dreamhost which I love for many many reasons (primarilly it’s really cheap and seems to work really well). Unfortunately they don’t build their PHP with BCMath or even GMP, which means my PHP can’t do the hard math that’s required for crypto. Luckily there’s a mode of OpenID that doesn’t require any work on the relaying party side. So I made a small change that allows James’ module to work in this “dumb” mode.

The Sidekick ID and the iPhone

There were two interesting announcements today. First the Sidekick ID which had been previously leaked was formally announced and reviews have started to show up. Secondly Apple announced that the OS X Leopard will ship three months late – more than two years after the previous release of OS X. This slip is being seen as evidence that Apple is having trouble building as many products at once as it wants to.

In the four years I was at Danger we were building exactly one product at a time. We failed to separate the development of the hardware, the OS and the applications. Separating the client and server schedules was a slow and painful process. In the two years since I’ve left things seem to have improved. The fact that they’re able to ship two products (even if they are quite similar) is really exciting. That Danger is succeeding where Apple, with their 30 years of experience, is beginning to stumble is cause for congratulations.

Burning your Drupal feed in two easy steps

[flickr-photo:id=136409681,size=m] FeedBurner provides all kinds of neat stats, but it didn’t seem straight-forward to “burn” my blog feed since I’m using Drupal 5. After a little fiddling I think I’ve got a pretty good idea how to make it work in probably the simplest way possible. In fact, it doesn’t require and Drupal configuration at all.

  1. First I set up a FeedBurner account and burned my feed. The feed Drupal produces for me is: http://ianloic.com/rss.xml. Now when I access http://feeds.feedburner.com/ianloic I get the contents of that feed. It’s pretty simple, but so far nobody is going to see that feed.
  2. Then I simply told Apache to redirect all requests for that feed, except the ones from the FeedBurner bot to my FeedBurner feed. With the slight of hand magic of mod_rewrite this is pretty straight forward. In the root of every Drupal install there’s an .htaccess file containing a bunch of stuff. I just added a few lines to the mod_rewrite.c block of that file:
      # Rewrite rss.xml to http://feeds.feedburner.com/ianloic
      # unless FeedBurner is requesting the feed
      RewriteCond %{HTTP_HOST} ^ianloic\.com$ [NC]
      RewriteCond %{HTTP_USER_AGENT} !FeedBurner.*
      RewriteRule ^rss.xml$ http://feeds.feedburner.com/ianloic [L,R=301]

    This will cause Apache to send a 301 redirect to http://feeds.feedburner.com/ianloic any time anyone requests http://ianloic.com/rss.xml, unless their HTTP User Agent begins with FeedBurner.

  3. Now I’ve got access to all the FeedBurner statistics and fun features. Since I didn’t actually touch the Drupal configuration I’m pretty sure a similar approach can be taken to applying FeedBurner to any feed.