Schof.org Atom Feed

Freak Show Deluxe at the Hollywood Fringe Festival

2011-07-01T00:00:00Z

I’ve never met a nicer bunch of freaks than the artists of the Freak Show Deluxe (FSD), a retro-futuristic collection of acts rescued from carnival side shows and the seamy, late-night side of state fairs.

FSD is an entertaining, funny, and often cringe-inducing show — I saw their act twice before I started shooting them, and enjoyed myself immensely both times.

For a group of people who can seem somewhat intimidating on stage, they’re an amazingly gracious, kind, and funny group backstage. I was honored to be there for the three shows I shot.

I wasn’t surprised by how hard working these professionals were — it’s common in small theater. I wasn’t prepared, however, for how much these people damage themselves in the course of their acts. Some of it is incidental to the act — you can’t walk on broken glass without cutting yourself occasionally — and some of it is done deliberately in cold-blooded preparation for a show. (Don’t worry. I wasn’t able to catch most of the mayhem on camera, and I promised not to reveal some of it.)

However, most of what happens on stage is exactly what it appears to be. This is what your back looks like after you’ve had a concrete block broken on your chest while laying on a bed of nails.

As usual, I’ve got a small collection of my favorite photos up at photos.schof.org, which I’d recommend anyone interested in FSD take a look at.

The rest of my shots are up on Flickr, but I really expect that only FSD cast members and their mothers will be looking at that — there’s a whopping 443 photos there.

I’d like to offer a sincere thanks to the FSD cast — I’m incredibly glad that they welcomed me into their backstage lives, and I’m very happy to have met such a talented and friendly bunch.

A Little More Clarity About SmugMug and Flickr

2011-05-14T00:00:00Z

I started my online photo display using Flickr, but I then changed to SmugMug because I liked the kinds of galleries I could create on SmugMug much better than the ones I created on Flickr, and because SmugMug allows me to use my own domain name, photos.schof.org.

However, there’s two types of photo collections I want to publish to the web, and I’m finding that I need both SmugMug and Flickr to make that happen. (I could probably do it with two separate SmugMug sites, but since I already have a paid Flickr account, I’m going with both.)

My photography workflow is simple — I’ll shoot as much as I can when I’m on location, trying to catch the peak of action, the peak of emotion, while still being in focus (except for the rare cases where being out of focus works). I end up deleting about 80 to 90% of the photos.

So on a typical shoot I’ll click the shutter release 1,500 times — perhaps 100 to 300 of those shots will make my first cut. All of these are decent shots that I don’t mind other people seeing. But there’s still far too many of them.

I’ll then go through and pick out the 10 to 20 real winners — they’re the photos I’m really happy with, and that I’m proud to have my name on.

I have been publishing these on SmugMug, and I’ll continue to do so — photos.schof.org, my SmugMug site, will be my portfolio site.

However, I’d also like to publish the larger collection of images, so that the people I’ve shot (and anyone who’s really interested) can view them. It’s entirely possible some of the people I shot in the larger project just won’t end up in the small pool of final selects, but I’d still like them to see their pictures.

I’ve been using SmugMug for that as well, but that has resulted in my photos.schof.org SmugMug site being a little muddled and confused.

I’ll be moving the large galleries over to Flickr, and using SmugMug solely for my portfolio, starting immediately.

New photos.schof.org Gallery via SmugMug.com

2010-11-24T00:00:00Z

I’ve been using Flickr for quite a while, and been satisfied with it — but I’ve been looking for a better way to host my photos. I wanted something that I could host on my domain, and I wanted both galleries/sets (groups of photos on a topic or event) and the ability to do slideshows or otherwise showcase photos that I like.

I think I’ve found that with SmugMug. I’ve only been using them for a few days, but I’m quite happy with them so far. I’ve created photos.schof.org, and it’s got most of my recent work on it already.

SmugMug, like Flickr, has integration with Adobe Lightroom built into Lightroom, so using it is easy — in fact, I think I like the SmugMug plugin for Lightroom better than the Flickr one.

I’ll keep you posted — but right now, I’m a happy SmugMug user!

The Elasticity of Memory, Part I

2010-07-19T00:00:00Z

My father says my mother hallucinates, but I don’t think “hallucinate” is the right word. It’s not as if you’re with her and she sees people who aren’t there. Instead, later she remembers things — sometimes very vividly — that never happened.

At first these were visits from people she knew — her father, her sister, old friends. It was easy for us to tell these things weren’t real — her father has been dead 20 years, her sister hasn’t left Denmark in 30 years, and her friends weren’t visiting either.

She’s come to accept that these things aren’t happening — though she had to call her sister in Denmark before she believed us that Greta wasn’t here.

Now she remembers things that are harder for her to verify on her own, so she asks us about them.

Today she called and asked if I’d had a bunch of friends over last night. I don’t live with my parents, and hadn’t been there last night, but I did have lunch there yesterday, and their next-door neighbors Daniel and Tatiana came over with their daughter Priscilla to visit for a while. Once I was sure Mom wasn’t talking about Priscilla and her parents, I knew this was another dream memory, and told Mom so.

“Well, your Dad says the same thing, so I guess they weren’t really here.”

Later I asked her about the memories. “Today we talked about Daniel and Tatiana and Priscilla coming over yesterday, which did happen, and about a bunch of my friends coming over last night, which didn’t happen. Is there any difference between those two memories for you?”

“Oh, yes! They’re very different. When your friends come over it’s like a Swedish movie. It’s just dozens of young girls flitting around in white dresses. They’re very nice, and don’t cause any problems. They’re just always moving around the house. I just assumed they were your friends.”

In some ways my mother is in the hardest part of dementia. She’s losing her reality, her ability to tell fantasy and imagination from reality, and she’s still alert and thoughtful enough to know it’s happening. At first this hit her very, very hard.

The hardest hit was also one of the most mundane. We were in the doctor’s office, and she needed to give a urine sample, and she had gone to the restroom before we left the house, so the medical assistant gave her a dixie cup full of water.

My mom gave the empty cup back, and somehow that got transmuted in her mind to her giving a urine sample. And no matter how much my father and I insisted that she hadn’t given a sample, she stood firm. It wasn’t until all the nurses in the office and the doctor confirmed that she hadn’t given a sample that she realized she was wrong.

This simple error shook her much more than thinking her dead father was visiting. She could no longer trust the evidence of her eyes and ears and mind.

All of this raises thorny questions about the nature of reality that I don’t feel qualified to talk about. Our eyes and ears and other senses are the instruments we use to model the world in our own heads. But our brain is an instrument as well, and when it’s not working correctly it doesn’t matter how sharp your vision or how sensitive your hearing. We’re all using imperfect instruments to perceive our world.

All of this completely terrifies me. Not only because of the obvious impact on my mother, but because I’ve become aware of my attachment to my own rationality and ability to perceive the world accurately. I’m a student of Buddhism, and I’ve found the knowledge that all things end to be a comfort as we approach the end of my parents’ lives. I’ve come to accept the inevitability of death — but this is rubbing my face in the liklihood of my own loss of awareness before death — and it will take much more meditation before I come to accept that.

My mother grew up in a small farming village in Jutland, in Denmark. It’s the kind of place that people in Copenhagen make fun of, filled with people the city-dwellers think of as ignoramuses with funny accents.

She went from there to an elite boarding school near the capital, and eventually from there to America, where she met my father, earned a Master’s Degree, taught in high schools and colleges, and had a son.

She’s always been proud of her academic ability, a voracious reader of newspapers and news magazines and books.

Lately she’s come to terms, at least a lot more, with the fact that she can’t trust her own brain or her own perceptions. It no longer seems to shake her so deeply when she finds her memory at odds with reality. She even jokes about it now — when I offered to take her to the Library she said there’s no need. “The best part of Alzheimer’s is that you can read the same book over and over again and not mind.”

She sometimes gets frustrated — more so on good days than bad — when she asks me five times in ten minutes if I’d like steak for dinner (I’m a vegetarian) and realizes how many times she’s asked the question.

On bad days, though, she doesn’t realize — just asks again and again — and this actually seems easier for her. Alzheimer’s is a disease that may actually get easier for her as it progresses.

I’m very thankful for one thing — that this doesn’t seem to be changing the basic nature of my mother. She’s losing her reality, but she’s not losing herself. She actually seems to be getting sweeter, more gentle, more loving, and more able to express that love as the disease progresses. Even her fantastical memories are of people she loves coming to visit, or of friendly young people filling the house.

At least for now, she’s still the mother I love and the mother who loves me. And I’m going to treasure that for as long as it lasts.

UPDATE September 3, 2010: This essay was republished on the Dakim.com blog.

Creating a Custom File Object in Python

2010-05-20T00:00:00Z

I ran into an interesting problem recently at work. We had six gigabytes of data in 58,000 media files of various types that we needed to install off of a DVD. For various historical reasons, these files were put in one large tar file, which was split into one-gigabyte chunks so that our installer software didn’t choke on it.

Our installer copied these files to the hard drive, where a Python script concatenated them back into a six-gig tar file, and then extracted the files from the tar file to their final destination.

As you could guess, this was slow as hell, and I was asked to take a look and see if I could speed it up. I didn’t think I could do much to speed up extracting files from a tar file, (I figure the Python code in the tarfiles module is probably pretty optimized by now.) but copying the files to the hard drive, then concatenating them on the hard drive seemed like something that could be made much simpler.

I thought I’d see if I could mock up a file-like object that would read through each of the split tarfile chunks, as if the file was already concatenated. That would eliminate both the “copying chunks to the hard drive” part, and the “concatenating tarfile chunks into one tarfile” part. That just leaves extracting files from the tarfile on the DVD (still stored in chunks) and writing the extracted files to the hard drive.

In a few hours I was able to code up a file-like object that actually worked. No unit tests, but I could pass it as an object to tarfile.open(), and tarfile.open would extract files from it:

multifile_obj = multi_file_object.MultiFileObject(list_of_files) tarfile_obj = tarfile.open(name="content", fileobj=multifile_obj, mode='r|') tarfile_obj.extractall(path=targetpath)

Here’s some of that early, ugly code. I’m presenting it in-line in this article, without a link to a downloadable file, because you shouldn’t use this code. (If you want good code, go to the download link at the end of this article.) It contains lots of assumptions about how file objects work that aren’t correct, and has no tests — but it works.

NOTE: In thinking about this, presenting my original code, warts and all, is probably not the best teaching tool. I should probably clean this up and remove (or at least comment better) the errors I made in it. But that will have to be another night.


class MultiFileObject:
    """ Creates a file-like object that tarfile can use as a file object.
    Concatenates multiple split files into one file, without actually doing
    that. Reads only bufsize bytes from each file, until it reaches the end
    of the last file.

    NOTE: One possible limitation of this class is that the last chunk of bytes
    read from each file may be smaller than bufsize. As long as calling
    functions depend on getting a return block of None back to indicate the file
    is done, we're good. If they depend on getting a return back of < bufsize
    back, we're not good. We seem to be good so far."""
    def __init__(self, filepaths):
        self.fileobjects = list()
        for filepath in filepaths:
            self.fileobjects.append(
                open(filepath, 'rb'))
        self.maxfileindex = len(filepaths)
        self.fileindex = 0


    def __iter__(self):
        self.fileindex = 0
        for fileobj in self.fileobjects:
            fileobj.seek(0)
        return self

    def next(self, bufsize=DEFAULT_BUFSIZE):
        """ This function is the meat of the class. Does all the hard work.
        Accepts self, and the bufsize to use. Returns a block of bufsize,
        or possibly of slightly small than bufsize if the remaining bytes in one
        of the files is < bufsize.

        Raises StopIteration when out of bytes to return; otherwise returns
        bytes.
        """
        if self.fileindex > self.maxfileindex - 1:
            raise StopIteration
        for currentfile_index in range(self.fileindex, self.maxfileindex):
            while True:
                chunk = self.fileobjects[currentfile_index].read(bufsize)
                if chunk:
                    return chunk
                else:
                    self.fileindex += 1
                    break
        raise StopIteration

    def read(self, bufsize=DEFAULT_BUFSIZE):
        """ This read function mimics the read function available in a true
        file object. We return bytes as long as there are bytes to return;
        then we return None.
        """
        try:
            contents = self.next(bufsize)
            return contents
        except StopIteration:
            return None

As an example of one misconception, real file objects don’t return None when they run out of content to return, they return the empty string. Another is that read() implementations probably don’t call next() in most file objects. Still, it has the essential parts of a file object. Let’s look at that.

I found the “Classes & Iterators” chapter of Dive Into Python 3 very helpful in figuring out how to do this. (Although there are some translation issues in using DiP3 to learn how to code in Python 2, DiP3 is so much better of a book than DiP2 that it’s worth it.)

So the first thing we need in any class is an __init__ method. We create some data structures and initialize variables here. Nothing very special.

The __iter__ method is called not just when instantiating the object (as with __init__) but whenever the iterator is “started.” (I’m sure there’s a Pythonic term for “starting” an iterator, but I don’t know what it is.) For instance, in the following code:


test_object = MultiFileObject(file_list)

for each_line in test_object:
    print(each_line)

for each_line in test_object:
    print('Line was %s' % each_line)

The __init__ method will only be called once, when test_object is created, but the __iter__ method is called twice; once for each for line.

I probably only needed a read() method, but I implemented next() too because it made testing the basic functionality of this file object much easier.

OK. That gives us a working proof-of-concept. But it’s not production code. My next step was to read carefully through the documentation on file objects, and write unit tests for each testable statement I found in the docs. I omitted everything about writing, because this class only needs to read for my purposes, and I omitted seek() and tell() because I didn’t need them, and they seemed like a pain in the ass to implement.

Honestly, I spent about three hours putting together these unit tests, and I did most of it at home. I was testing much more of the spec than was necessary to complete my task, and it seemed like a poor investment of my work hours. Implementing a more thorough class was something I wanted to do in order to publish this article.

On another day I spent a few hours rewriting my code until it passed my tests, and then started using it at work. (I work at a great place. I have permission to open-source code like this that has nothing to do with our core business. The code that provides our competitive advantage is all closed source, and I understand the business reasons for that.)

I learned a tremendous amount about how file objects work while implementing these tests, and I consider this a really valuable exercise. As a continuation of that exercise, I’d love to expand MultiFileObject so it supports writing and all the associated methods, as well as seek and tell. It would then be a complete drop-in replacement for the file object. (No promises about when that’s getting done, though.)

You can download the code as a Python file, or check it out of version control on BitBucket. I welcome comments and suggestions.