Month: December 2012

Damn You, iPhoto, Part I

(Presumably there will be more of these entries?)

The running joke among its users is that iPhoto is the product of Apple’s worst software engineers, a sort of place where the least-talented programmers go to fuck with their customers’ most precious data. And really, who wouldn’t you want in charge of that?

I dismissed this strain of thought for a while, until I actually tried using the software. Let me think about some of the things that are missing and presumed dead, and which I generally have to revert to my Windows machine or Picasa in order to do quickly/properly:

  • Batch lossless rotation with changes saved back to the original file.
  • Useful batch redating.
  • Fixing/removing the EXIF auto-rotation tag.
  • Panoramas, anyone?

But the kickers were these four:

  1. A hardcore system crash while using iPhoto, returning from the single, fullscreen image view to the albums view. The mouse could still be moved, but pressing the keys to perform a Force Close on iPhoto didn’t work, and pressing the Power button didn’t bring up the Shutdown dialog. The crash forced me to have to log into my Mac via SSH and attempt to ‘sudo reboot’ it. Which then also seemed to fail, and which killed my connection after attempting to at least ‘sudo sync’ the drives. A hard poweroff, pressing and holding the Power button worked. But it’s pretty disheartening when a single product can kill your whole system like that. Yes, I realize this could have been a one-off; but no, this should never, ever happen in userspace.
  2. Why does iPhoto insist on importing photos into the iPhoto Library bundle? Yes, I have a Macbook Air with SSD, and no, I really don’t particularly dig it when the iPhoto Library bundle is 6GB because it wants to manage the files for me and makes copies of everything I’ve imported. I don’t have that much space, really. Perhaps this is good for people who don’t want the hassle of managing their data. But it doesn’t help anyone else at all. Or, I take that back. If you have every last photo in your iPhoto Library bundle, then yes, backup is super easy. But guess what, it doesn’t even organize the files properly by date, it organizes them into folders by the date on which they were imported. Which is sloppy.
  3. When I make changes on the disk to the original file, iPhoto doesn’t pick up on them? What kind of bullshit is that? Oh, it relates to and is fully explained by point 2 above, but it doesn’t help when third-party tools that handle lossless rotation do their magic and leave you wondering why the changes don’t show up. You have to reimport those files, and then confirm that you want the duplicates to overwrite what’s already in the library. Awesome.
  4. Why is RAW or NEF import so slow on iPhoto? My brother’s quad-core iMac is able to import maybe 1 file per second. As if conversion and import was somehow still single-threaded (well, it probably is, but I haven’t checked).

To my mind, it feels like iPhoto isn’t getting dogfooded enough or at least that there aren’t enough champions of digital imaging actually using it at Apple. Free is very hard to compete with, and there’s no doubt in my mind that this stuff isn’t winning based solely on innovation. It’s good enough to be usable, but it’s definitely not as spectacular or “magical” as one could imagine. (But I guess for that there’s Lightroom, et al…)

Django IntegrityError On PostgreSQL

The answer is here:
http://www.chrisspen.com/blog/handling-postgresql-integrity-errors-in-django.html

I was seeing IntegrityErrors while trying to unit test uniqueness constraints within a database table (it’s not strictly necessary, I suppose, but I was just being thorough, so much for trying to do the right thing):

What didn’t make sense was that the exact same sequences of calls would work just fine in ipython, they just wouldn’t work when under Unit test.

Turns out, whenever an IntegrityError happens while using Django and PostgreSQL, for whatever reason you need to close the entire connection to reset the transaction in the exception handler, which looks like:

Django Unit Testing On Shared Hoster

So I’ve been trying to write unit tests for Django, but, as I’m doing a lot of work on a shared hoster, this isn’t working. The problem is that our user account doesn’t have CREATE/DROP DATABASE privileges on the server. This has been documented here, here, here, and here.

Which means I see the following if I try to run manage.py test, I get:

Unfortunately, there isn’t a first-class solution from the Django devs, so after reading that django-nose had a handy REUSE_DB parameter, I tried to install django-nose.

(no-deps because I’m working with Django 1.5 beta 1)

Then, in settings.py, I set TEST_RUNNER=’django_nose.NoseTestSuiteRunner’, and set the TEST_NAME key on your ‘default’ DATABASES entry to the same value as NAME.

Unfortunately, you still get errors, if you’re trying to use PostGIS, seems like transactions may not be a happy thing there:

So it looks like the only option I now have is to write unit tests that just run against a development database, and do a decent job of cleaning up after themselves in the setUp and tearDown methods. Using the standard nose distribution will do this, but if you just do “pip install nose” and try using “nosetests”, it will error out:

The problem is that nose doesn’t know about Django’s settings or modules. You have to make a copy of nosetests into the same directory where “manage.py” is located and change it so the DJANGO_SETTINGS_MODULE is incorporated into the os.environ resource. Like so:

Then you’ll see:

$ ./nosetests
……
———————————————————————-
Ran 6 tests in 4.955s

OK
$

Damn You, Emacs Autoinsert

Emacs can also be annoying when it autoinserts text without checking to see if it’s already there. Case in point, gettext .po files under Emacs 23.1. For whatever reason, my copy kept inserting this header whenever I opened a translation file:

If this header sneaks into a .po file, when you try to compile the file with Django’s compilemessages command, you get the following error:

What seems to happen is that this header is only inserted when you use C-x C-f to open a file. When opening a file directly from the command line, this corruption does not seem to occur.

If you look at the PO Group configuration options, this text is listed there as the default PO file header. I haven’t validated this as a solution, but you should be able to switch this value to be the comment character “#”, and that should take care of the problem.

Also, why the hell does the PO major mode not allow you to destroy entire msgid’s and their translations? This is really annoying. Yes, it’s nice sometimes when programs limit your options, but in this case, Emacs was messing up by inserting the bad header, then refusing me the option of removing it.