Tuesday, February 19, 2008
New Logo!
As you may have noticed, we have a new logo. This logo was professionally designed for us by Andrew Harrington, and I think he did a great job. Of course we will be continuing to refine the site's look, but I think the logo is a great starting point.
Monday, February 18, 2008
Watch out for 500 errors due to gclid
One kind of 500 seeing I've been seeing is this:
After a little Googling, I discovered that Google AdWords adds this parameter to requests to track when people click through your ads. (We do a small amount of ads on Google.) Well every one of these that we've been paying for (!) have been getting 500 errors instead of the main page because of this added parameter! I have tg.strict_parameters set.
If you run a site and are using AdWords, make sure you aren't getting these errors. I would never have known if I hadn't turned on error reporting (see here).
GET /I shrugged these off (stupid bots) but no these are VERY BAD.
(traceback)
TypeError: index() got an unexpected keyword argument 'gclid'
After a little Googling, I discovered that Google AdWords adds this parameter to requests to track when people click through your ads. (We do a small amount of ads on Google.) Well every one of these that we've been paying for (!) have been getting 500 errors instead of the main page because of this added parameter! I have tg.strict_parameters set.
If you run a site and are using AdWords, make sure you aren't getting these errors. I would never have known if I hadn't turned on error reporting (see here).
Monday, February 4, 2008
More stuff coming soon
Although BandRadar is a labor of love more than a business (currently anyways) we have still been adding features and users at a slow but steady pace over the past few months. For example, we keep adding more artist info, as we can get it from online APIs such as last.fm and Musicbrainz, as well as album links to Cdbaby and Amazon. We also are currently on our third site design, with more improvements in that area on the way.
We also recently acquired an iPhone, and are seeing great possibilities for making the site more useful from portable wireless devices. I think one common scenario is:
(out at a bar)
Guy 1: Let's go check out a band!
Guy 2: Sure! Do you know who's playing around here tonight?
Guy 1: Uhh no... does anyone have a paper?
Of course if you have a web-enabled mobile device you could check BandRadar, but right now we're giving you ALL the events tonight -- too much to wade through on a tiny screen. What you really want to know is what's nearby, and a little about each one to know if it's something you'd like to check out.
This isn't hard to do. we could add a m.bandradar.com with a simplified webpage, enter your location and it finds the closest events. But what would be better would be to use the built-in GPS or cell-location features (like the iPhone has) so people could skip the "type in my location" step. That's the most painful part, really. It would go from taking 30 seconds (while your friends are waiting for you to quit futzing with your iPhone) to maybe 3 seconds. That difference boosts its usefulness tremendously, and it will be used much more.
Unfortunately, all these devices may know where they are, but they may not have a way to tell us this information. On the iPhone, its Maps app supports location, but it's written by Apple of course. Once the iPhone SDK is released it may be possible to write our own app with location info, but that's a big unknown. That still doesn't help people who own all the other location-aware devices out there now, or coming soon.
But we're thinking about these things. This is a killer feature that we personally would find very useful, and really want to make it happen if we can pull it off.
We also recently acquired an iPhone, and are seeing great possibilities for making the site more useful from portable wireless devices. I think one common scenario is:
(out at a bar)
Guy 1: Let's go check out a band!
Guy 2: Sure! Do you know who's playing around here tonight?
Guy 1: Uhh no... does anyone have a paper?
Of course if you have a web-enabled mobile device you could check BandRadar, but right now we're giving you ALL the events tonight -- too much to wade through on a tiny screen. What you really want to know is what's nearby, and a little about each one to know if it's something you'd like to check out.
This isn't hard to do. we could add a m.bandradar.com with a simplified webpage, enter your location and it finds the closest events. But what would be better would be to use the built-in GPS or cell-location features (like the iPhone has) so people could skip the "type in my location" step. That's the most painful part, really. It would go from taking 30 seconds (while your friends are waiting for you to quit futzing with your iPhone) to maybe 3 seconds. That difference boosts its usefulness tremendously, and it will be used much more.
Unfortunately, all these devices may know where they are, but they may not have a way to tell us this information. On the iPhone, its Maps app supports location, but it's written by Apple of course. Once the iPhone SDK is released it may be possible to write our own app with location info, but that's a big unknown. That still doesn't help people who own all the other location-aware devices out there now, or coming soon.
But we're thinking about these things. This is a killer feature that we personally would find very useful, and really want to make it happen if we can pull it off.
Error reporting is really nice to have
One thing that has really helped me feel better about the site lately is adding error reporting. That is, every time users get an error, I get an email. It's documented here: ErrorReporting.
I think most people want whole-site error reporting (documented as Method 3). The code listed worked great, but something irks me about cutting and pasting code out of the docs in order to add that feature. I felt compelled to review it line-by-line, which I don't think I would have felt the need to do otherwise.
Could this be made a standard part of TG, possibly?
EDITED: BTW spiders are really good as an automated testing system and finding bad links, as one finds after enabling error reporting.
I think most people want whole-site error reporting (documented as Method 3). The code listed worked great, but something irks me about cutting and pasting code out of the docs in order to add that feature. I felt compelled to review it line-by-line, which I don't think I would have felt the need to do otherwise.
Could this be made a standard part of TG, possibly?
EDITED: BTW spiders are really good as an automated testing system and finding bad links, as one finds after enabling error reporting.
Subscribe to:
Posts (Atom)