A lot of groups I work with use GeoIP based decisions in their applications. Sometimes for basic features like guessing a timezone, or choosing the best mirror to load content off of. In other situations the code is handling things a bit more serious, like pricing selections, or billing providers (some of whom will not be tricked by hacks within your application).

I've seen a couple of choices made when it comes to testing these features:

• Hacking the code
  This one is pretty easy for developers, you just throw in a few hooks to convince the application that you're really somewhere else. This works, but it adds complexity to your application, and can leave you testing your hacks, rather than the application itself. This level of testing also requires that the developer be involved, since presumably QA doesn't have access to add these sorts of things to your application.


• Free Proxies
  These work, usually. Free proxies often provide limited feature sets, availability, or ad injection. As a result of their limited resources, they often end up being a bit slow, and prone to outages. I've used these for a while, and often find myself frustrated a the end. There's a couple out there decent from speed and stability, but they wont let you fill out POST forms.


• Pray
  I'm a pretty kick ass developer, it should work... Right?


• Tor
  A great anonymizer network, but quite slow. You're also left with whatever exit node it assigns to you.


• Commercial, single site proxies
  I've found a few proxies out there, generally aimed at people who want to pretend they're in a given country for content reasons. Either the US for Hulu, the UK for BBC stuff, etc. These ones generally reside in countries where there's content you want, and charge you according to the high bandwidth they expect you to use. You could buy a bunch, but now you're in serious money country, still without a proxy in less attractive locations.

One final element of complexity is that applications often end up with hard coded IP addresses for admin access. You need to get outside that range to test even regular features like authentication.

Not being too happy with these choices, I've started building up my own little collection of proxies. I've currently got one running in the US, UK, and France. I'm waiting for my server to finish provisioning in Argentina, Germany, and The Netherlands. Finally, I'm still negotiating with providers in New Zealand, Australia, and Japan.

If you're interested in getting access drop me a line (paul at preinheimer dot com), I've got rates aimed at individuals and corporations. I am of course willing to work with you if you have specific needs for a proxy in a different country.

Update
The problem was bigger than I thought, and solving the GeoIP Proxy problem necessitated launching a whole new company: WonderProxy. As of this update we've got proxies in over 40 locations, and over 25 countries. Take a look if you're interested.

In the past week I've dealt with some servers that were seeing some rather heavy load, with more traffic on the way. I noticed that the servers had AllowOverride All in their httpd.conf files, which immediately struck me as a problem. While .htaccess files can be quite handy during development (AllowOverride instructs Apache to process those .htaccess files), they're also quite horrible in production due to the performance hits involved in using them. Since the files allow configuration to be changed on the fly, they need to be read on every request. This requires a lot of unnecessary stat calls with each and every request.

I approached the development team requesting permission to turn the option off, in order to squeeze some extra performance out of each server. Rather than the happy smiles and agreement I expected, I was instead met with nervousness and uncertainty. Since the front end team uses them constantly, there was concerns that the change over from .htaccess to httpd.conf would consume a lot of time, and would be very difficult to maintain moving forward.

In order to allay their fears I created a .htaccess to httpd.conf script with the help of my friend Rich Bowen. It's designed to be executed from the command line from a sufficiently permissioned user from within the document root. It recursively scans all sub directories looking for .htaccess files, reads them in, and spits it all back out. There's a bit of intelligence involved in order to present the contents of .htaccess files with the least depth first (this way overriding works correctly), and warnings are generated if the RewiteBase instruction is encountered as it may require extra tweaking. Other than that I generally just pipe the output to htaccess.conf, then include that file from my basic configuration file. By re-running this script (and, of course, gracefully restating the server after checking to make sure all the conf files parse) as part of my normal sync process I get all the flexibility of .htaccess files, without the performance hit.

The script requires PHP 5, probably 5.1+ would be safest.


No warranties, test extensively. In terms of field testing (against my rather limited set of .htaccess files) it's been running on a site +10M uniques/day, using roughly 40 .htaccess files. I'd love to hear from you if you end up using it.

Source:.htaccess to httpd.conf converter, and again with thanks to Rich Bowen.

Way back in April I made a resolution to stop buying camera equipment until I had taken 100 "Keeper" images. Now 6 months later, I'm only half way there. But I'm glad I've done it. There's lots of great equipment out there, but really it's the photographer that makes the shot, not the equipment.

Here's a few of the ones I've got so far (full list of keepers at flickr):







I've joined a photography club at work (Some members shoot artistic nudes, so it's a tagged group). Hopefully this will provide additional motivation to get out there and take more pictures.