Monday, July 8, 2002
My new cameras arrived today, and already I've gone through two rolls (the seemingly prerequisite trial rolls). And I'm halfway through the roll of 120 film.
The Holga 120SF came in very bare packaging - a box that says camera, and a small instruction booklet, and this giant heap of plastic (since 120 film is medium format. 35mm is small, I suppose).I hope I got it loaded up right. I've got some black and white 120 film in there right now. It's very very easy to shoot over a picture (which can be nice in some instances).
The LC-A 35mm came in beautiful packaging - including two rolls of ASA100 film (apparently the LC-A gets its best colors on 100 film), and a small square hardbound book full of photos and austrian words (an accompanying book all in newsprint has translations, I believe). The camera was in a beautifully wrapped brick. The wrapping was just white paper with black string, and two stickers - one in the center with heavily inked serif letters stating the cameras name and operating temperatures with a purple-inked packaging date; and a small red sticker in the lower left corner stating made in russia. Underneath the wrapping paper, the plastic brick had another layer of wrapping - this time blue with red and yellow stamp art. Inside of that, was the plastic brick containing the camera. The bottom half was black, the top half clear, with half-stickers on the side with red-on-bronze text with the word Lomo. The camera, batteries, and wristband were all inside wrapped nicely and tightly in tissue paper.
The Supersampler came in some pretty cool packaging as well - not as nice as the LC-A, but still nice.
And now there's the Pop 9 to get - a camera that takes nine identical pictures on a single 35mm frame. And Lomo's started offering the Loreo, a camera that takes 3D (Stereoscopic) pictures on normal 35mm film. I'm thinking, however, that the Loreo and the Holga are not Lomo products, but rather cameras that fit The Lomography Way. And these cameras seem to have some history of their own - many people I spoke to at local film shops/labs recognized the name Holga more than Lomo. What appears to be a new article calling the Loreo the Camera of the Month has no mention of Lomo anywhere in the article.
Still, these two cameras are on my wish list. Film rules.
An optimization dilemma
I'm facing a nice little Python/Zope programmers dilemma. I have a critical Zope Python Script - Python code objects in Zope that are editable through the web, and are subject to being run in a "restricted mode" interpreter that enforces Zope security policies. It's quite long for a single script, weighing in at approximately 170 lines. But it does its job well, and is written with maintainability in mind (there's only one variable in there that I find non-obvious, and whose usage I might change).
Unfortunately, it seems to do its job slowly. I think there are a few contributing factors to this:
- Restricted Python. I think the security overhead is slowing the execution down. In evaluating the script's code, it doesn't really need to go through this.
- SQL Calls. There are a lot of calls into SQL Methods, both read and write. I'm not sure if this can be helped, or indeed is having any real noticeable effect on the speed.
- Generating/Sending Emails. I think there might be an issue here. The MailDropHost Product by Jens Vagelpohl could help as it sends mail asynchronously.
With those points in mind, I've started tackling the first bullet by moving the code into an External Method, where it is not victim to the Restricted Python interpreter. As a bonus, the code can be checked into CVS. But now I face a new dilemma - inline or breakout?
Since the code was originally written as a Zope Python Script, it was one big inline piece of execution. Now that it's an External Method, I have the opportunity to refactor, and turn the code into a class/singleton wherein the code is broken out into methods that are executed in a certain order. My newer instincts are pulling me in this direction. But I know that it brings in new overhead to the code whose speed I'm already concerned about. Now, instead of dealing with restricted Python, I'd have to deal with a number of new function calls and name lookups. And, possibly, Thread Safety issues.
The code in question is very central business logic. In order of importance, it needs to be solid, maintainable, and relatively fast. It succeeds on the first two points (very solid, fairly maintainable). The third one is a matter of some debate, most of which is going on inside my head. Future writings in this space will look at the avenues explored and if they yielded any results.