Of digital cameras and photography

In our house, we had two polaroid cameras. Brother and I, being young, were never allowed to touch them, but we saw parents use them often. On every birthday party, every gathering, we’d have a lot of pictures taken and then developed — you know how it used to be and is with polariod cameras.

Then one miserable day when I was still in school, some miscreants broke into our house and stole the cameras. Ever since, we have been deprived of cameras.

We do have digital cameras in our cell phones now. Brother is obsessed with taking pictures of himself with his cell phone all the time, while dad enjoys snapping cats when they aren’t looking. And mine’s just not good enough (at slightly more than 0.3 Mpx (mega pixels), you can hardly dream about becoming a photographer). But, that’s the conundrum: these cameras are just not up to the task. Granted, I could probably invest in a sophisticated cell phone equipped with a better camera that might cost me an arm and a leg, but cell phones don’t appeal to me. Furthermore, if you are from around here, you already know the perils of keeping an expensive cell phone. And, it is not like you can separate out the camera from the cell phone without decapitating it completely.

All these years I have waited for occasions where friends would bring their cameras, to take snaps of myself. That may probably paint me as desperate, come to think of it. I have also been to some exotic places and wished dearly that I had had a cam.

Finally, last week I decided to reach out on a limb and buy a proper, standalone digital camera. A friend from Down Under, Grant, helped narrow down the choices of cameras, constraint by my self-imposed budget, to the Canon PowerShot A580, and the Nikon Coolpix L16. I nearly went for the A580, but on the day I was going to place an order for it, I had a reeking afternoon (which I may if I feel up to it blather about another time), and decided to settle on the Nikon L16, overkill features and therefore price being the reasons for turning down the A580.

I have been playing with the Nikon L16 since the last week. I am no seasoned camera owner or photographer to be able to expertly judge how well the camera fares, but I find it satisfactory. The product page is here, so you can check out the features of the camera without having to rely on my words. I have been playing with different shooting modes, exposure settings, flash settings, and whatnot. These are all novel to me, and I am enthralled by what something so small as this camera is capable of. The fruits of my toying with the camera are on display on my flickr account. The camera works seamlessly with the MacBook. The installation CD that came with the camera has a Nikon Transfer utility and a copy of Panorama Maker 4 for OS X.

As an aside, people who frequent my blog will have have noticed instantly that I have reverted back to the simple, clean theme for the blog. The previous theme was neat, if you can put it that way, and I have tried some other themes too, but I always find myself at home coming back to this theme.

Stay safe, folks!

A guide to configuring two different Django versions for development

Django 0.9x and Django 1.x branches are so far apart that a project built on top of the former, not least when it has been rolled off into production, that porting it to the 1.x branch of Django can easily escalate into a nightmare. If you have to maintain a legacy Django project — I choose to call projects built on anything before 1.x legacy –, you will find that it is easier if you maintain two different versions of Django on your development environment. How do you do that, is the quagmire this post revolves around.

I prefer Apache with mod_python to Django’s simplistic development web-server for Django projects. Initially, the task of setting up mod_python and Apache to your tastes may seem daunting. However, once you get around its not so steep curve, the difficult task becomes second nature.

I am working with Python 2.5 on a project with Django 1.0.2. Django is deployed on the system in the site-wide default directory for third-party Python modules and applications. I also have to support development for a legacy application built on Django 0.97 (a trunk snapshot from a time long ago). My requirement is simple: I want to be able to run both projects simultaneously without having to muck around tweaking configurations besides the one time when I set the projects up.

A garden-variety solution is to change the default Django directory in the Python path to point to the specific Django that is the need of the moment. This approach puts upfront a limitation of not being able to run both projects side by side. It also is annoying because it requires tap-dancing around Django directories when switching between the two versions. It is not a considerable blow to productivity, but if it can be avoided for a better, more efficient solution, there is no reason not to.

The solution I am proposing involves having the recent Django set up as the default, with the legacy Django installed in a different directory—after all, the legacy Django is the odd item of the group. I develop on an OS X environment, where I have the two Django versions set up thus:

/Library/Python/2.5/site-packages/django

/Library/Python/2.5/site-packages/django-0.97/django

You can probably tell which is which.

I have both projects deployed as virtual hosts on Apache, each running off of the root of the web-server without stepping on the feet of the other. They can easily instead be set up to, instead of the root of the web-server, serve from under a unique sub-URL path. That is mostly a matter of preference.

For each virtual host, I have assigned a domain name based off of the name of the project. I should emphatically point out that these domains are set up to resolve to localhost on my system. They may likely have real world twins that are routable over the Internet, but for all intents and purposes, they are local to my development environment. I have done it so, partly out of convenience, and partly because one of the projects hinges on subdomain-based user-to-account mapping (what this means, simply, is that registered users on the project are assigned different accounts that directly relate to subdomains, and can log in to the project only via their respective subdomains) for proper functioning. For the latter, the domain based approach was inevitable.

With that in mind, here are the virtual host settings for the two projects

<VirtualHost *:80>
   ServerAdmin root@localhost
   ServerName projectone.com
   <Location "/">
      SetHandler python-program
      PythonHandler django.core.handlers.modpython
      SetEnv DJANGO_SETTINGS_MODULE projectone.settings
      PythonPath "['/Users/ayaz/Work/', 
            '/Users/ayaz/Work/projectone/'] + sys.path"
      PythonDebug On
   </Location>
</VirtualHost>

<VirtualHost *:80>
   ServerAdmin root@localhost
   ServerName legacyproject.com
   <Location "/">
      SetHandler python-program
      PythonHandler django.core.handlers.modpython
      SetEnv DJANGO_SETTINGS_MODULE legacyproject.settings
      PythonPath "['/Library/Python/2.5/site-packages/django-0.97', 
            '/Users/ayaz/Work/', '/Users/ayaz/Work/legacyproject/'] + sys.path"
      PythonDebug On
        </Location>
</VirtualHost>

While each line of the above is important, the following is the highlight of this post:

   PythonPath "['/Library/Python/2.5/site-packages/django-0.97', 
            '/Users/ayaz/Work/', '/Users/ayaz/Work/legacyproject/'] + sys.path"

I have effectively injected the path to Django 0.97 into Python path. What this helps achieve is that when mod_python loads the Python interpreter to serve an incoming request for the project, Python analyses its path, looking for a module named django. The first successful match is under the /django-0.97 directory, which, if I have not already lulled you into sleep, is where Django 0.97 lives.

For the curious, all possible mod_python directives are documented here.

All this is a one-time headache: you pop in a pill, and forget about it. I can now type in projectone.com or legacyproject.com in the browser to get to either project.

I should mention, still and all, that I have of late come to know of virtualenv, a Virtual Python Environment builder. It may be a more proper solution than what I have proposed, but I have not yet used it myself to say more.

I hope I was able to clearly explain what I had intended to.