I recently bought a new iPod nano, and I've had trouble twice with getting videos onto it. First, I purchased Dr. Horrible from the iTunes store, and didn't realize I was buying the HD version. When I tried to sync it to my iPod, I was told that the video wasn't transferring because it couldn't be played on my device. Why can't iTunes transcode it down to the resolution needed? (Dr. Horrible is funny, by the way, you should see it.)

Then I tried to load the Arabic Typography presentations, which are Quicktime files. Again, I was told they couldn't be played. I know these aren't HD, I'm not sure in what way they are incompatible.

Searching online, I find that Quicktime Pro will do the conversion for me. But I just paid Apple $200 for a piece of hardware, and am getting video content using their format, in one case paying Apple to download it. Why do I have to pay them again to be able to use the two together?

I tried using Handbrake to convert the video. It worked great on an .AVI file I tried, but crashed when attempting the .MOV conversion. Grr....

Michal Zalewski is maintaining an incredible document, the Browser Security Handbook. It catalogs and describes all the browser behaviors related to security concerns in web applications. Everything is covered in astounding detail, with tables of browser beaviors, descriptions of the issues involved, links to vendor-specific information, code for test cases, etc. It isn't very long, but it's got the highest signal-to-noise ratio of anything else covering these issues.

It's a fascinating read on a number of levels. First, as a web application developer, you need to understand the wide variety of possible threats. Second, as a software developer, it's interesting to see the differences in implementation at the far edges of a spec. Remarkable through and through.

Translating from one language to another is a fascinating topic: how do you adapt writing so that not just the meanings of the words and sentences are preserved, but also the sense of the entire piece? The same issues apply to typography and logos, and Arabic is different enough from latin text that the translation is particularly challenging.

Graphicology has two photo sets: Arabic versions of global brands and packaging logos. It educational to see how these logos are expressed in a completely different type system. The similarities zero in on what gives a logo a particular feel.

Ministry of Type has learned commentary, and the Brand New page about it has a number of interesting comments.

If you want to learn more, An Evening of Arabic Typography is a set of three presentations on the topic from last fall.

Last week I linked to some amazing photos of frozen soap bubbles. As we were expecting frigid weather of our own, I planned to try making some myself. The results weren't as spectacular as his, but it was a fun experiment.

There are a lot of factors to consider, I don't know which contributed what to the outcome. The temperature was about 15 °F. The soap solution was standard Walgreens brand soap bubbles. The trick here is that drug stores don't sell bubbles in the winter. We found a bottle lying around the house.

We tried this over two nights, and the first thing we discovered was that it helps to chill the bubbles. When we were first blowing bubbles, nothing froze, and the longer we were outside, the better they froze, because the solution in the bottle was getting colder the longer it sat outside.

One nice effect is that your breath is naturally cloudy on nights like this, so when you blow a bubble, it is filled with smoky breath. Even when the bubbles don't freeze, it's nice to see these smoke bubbles float away, and then pop, releasing your frozen breath into the air.

Of course, your warm breath inside the bubble also helps prevent it from freezing, so one area to explore is ways of blowing the bubbles without breath. We didn't have enough solution to use a waving wand to make the bubbles. Another possibility is to use a tube to blow through, so that your breath is chilled a bit before it forms the bubble.

When the bubble does freeze, it's fascinating to watch. You can see the frozen region expand over the surface of the sphere, in hexagonal shapes. In our experiments, it was rare for the entire bubble to freeze before it broke, though.

When a frozen bubble did break, it became a crumpled membrane. It was beautiful to watch a flock of bubbles freeze and then break into tiny fluttering gossamers, and float away. Different than the summer soap bubbles I'm used to, but still fascinating. And as the pictures show, occasionally a frozen bubble would be large enough that it would land on the ground and just sit there, like a failed blimp.

Peter Harkins succinctly distills out rules of database app aging, namely that fields become optional, and relationships become many-to-many. When I read that I wanted to add,

All booleans become enumerations.

but commenters have already extended the list.

One comment on the blog post in particular caught my eye. Jonathan Holland said,

This sounds more like database aging when your original schema was poorly planned.

I don't know what world Jonathan is working in. In my experience, these sorts of aging effects of applications are due not to developers doing a sloppy job as they are due to the domain needs changing. Sure, sometimes, developers try to ignore inconvenient stuff like timezones, but much of the time, the application needs change. When designing the schema for version 1, it's impossible to predict what version 3 will need. Trying to anticipate it won't guarantee your schema won't change, it will just mean you do a lot more work in version 1, and then version 3 turns out to be completely different than you expected, so not only does your schema stretch in difficult and unexpected ways, but half the flexibility you built in turns out to be completely unhelpful and possibly even a crushing burden.

Clay Shirky thinks the big thoughts about information overload, and does a good job of it:

But, you know, you never hear twenty-year-olds talking about information overload because they understand the filters they're given. You only hear, you know, forty- and fifty-year-olds taking about it, sixty-year-olds talking about because we grew up in the world of card catalogs and TV Guide. And now, all the filters we’re used to are broken and we'd like to blame it on the environment instead of admitting that we're just, you know, we just don't understand what's going on.

...

It's not so much that young people are smart and old people are scared. It's that young people don’t have to unlearn all the stuff that old people do have to unlearn if we want to understand this world. And unlearning is just about the least fun activity in the world. So, you know, it's easy to understand why people don't want to sign up for it. But it's also kind of pathetic that the people going around talking about information overload don't stop to factor in the idea that if the twenty-year-olds aren’t complaining about information overload, it probably isn't the problem we think it is.

Not everyone agrees. Samuel Fine said (in a comment to Aaron White),

Just because the youngsters are used to it doesn't mean they aren't worse off for it. They (and often, we) live in this world of static, useless fleeting tidbits of nothingness; we're acclimating, sure, but the long view is that we'll look back on, say, Twitter in 10, or 5, or 2 years and say, "Wait, what?" We're fooling ourselves. WE don't understand what's going on. We're just too deep in it to notice.

I have a theory about why people get so fat in modern America. We've developed evolutionarily to be very interested in fats and sugars. 10,000 years ago, if you found food high in calories, it was a really good strategy to eat as much of it as you could, because food like that was hard to come by. So people didn't need a limiter on their intake, the environment provided it for them.

Fast forward to now, and the environment has changed drastically. Now the eat-all-you-can strategy is a really bad idea, and it leads to really fat people who don't know when to stop.

I think we may be in a similar situation with information. People have a craving for information, whether it's factual stuff like science, or emotional stuff like gossip. Information has been getting exponentially easier to distribute and consume. People's natural strategy for information is, when you find some interesting information, eat it. 10,000 years ago, no one had to worry about how to limit their information intake. Now we really do.

As Shirky rightly points out, the internet didn't do this to us, it was really TV that tipped us over the edge into junk-info overload, and the problem has been growing ever since the invention of the printing press. So the internet, and poster-children like Twitter don't deserve particular attention, except for the fact that they are the fire hoses we deal with now.

The solution to the food problem is to be conscious of what you are eating, and have a plan, called a diet. Some foods are nutritious, and some are not, but you eat them anyway. You can decide.

The same is true for information. You have to decide what your information diet will be. I don't mean diet as in a way to eat less, just a way to eat consciously. Bodies all work pretty much the same way, so authorities can give us pretty good guidelines (don't eat too many sweets). But minds all work differently, so we each have to determine our own information diet. Perhaps reading all the latest on Brangelina is just what you need, or it's part of your goals to confront stupidity.

A diet is a way to choose what you will eat, and what you won't, what Shirky calls a filter. When people talk about information overload, they mean their filters aren't working, usually because they're not throwing enough away, but also perhaps because they don't apply to all the channels they need to. Their diets need to be tuned, because they're stuffing themselves.

And to make matters worse, in these information-rich times, we have to choose not just what to consume, but what to produce, because we all have tools within our reach.

Twitter is a lightning rod for these discussions because it's kind of like blogging, but actually works very differently. I don't know whether Samuel is right, that we'll look back on Twitter as the CB radio for a new millennium.

What I do know is that the internet is chock-full of information, and we can't simply belly up to the buffet and eat all of it. A bad info-diet won't kill you like a bad food-diet will, but it can distract you or make you feel bad about your skills as an infovore. Think about how you approach the cornucopia of information, plan your info-diet. Eat smart.

¶   Corkscrew: an amazing Rube Goldberg/Heath Robinson contraption for uncorking and pouring a bottle of wine.

¶   Microsoft Tag: a color 2D barcode, but maybe some of the compression is just from encoding unique ids with the real data at the server?

¶   Frozen bubbles: I wonder how cold it has to be to freeze soap solution?

I'm not sure exactly what PES is (a company, a person?), but I know they (he?) make excellent pixilated short films. Western Spaghetti made it to #2 on Time Magazine's list of top viral videos (who knew they even had such a list?) Game Over is a spot-on loving re-creation of classic arcade video games, but with cupcakes, beetles, and pizza instead of pixels. And KaBoom! is a war-time newsreel, re-enacted on a kitchen table, complete with a making-of video. Great stuff.

A recent posting on django-users is entitled Your IDE of choice, simply asking people for their IDE preferences.

These questions sometimes turn into silly flame wars about Emacs vs. vim vs. everything else, but in this case, it's a bunch of people chiming in with their choice, and I find it useful to read through to see what people are using. Often I discover new tools, as I did this time.

• Geany is a new programmer's editor with some project and build features. If the development keeps progressing, it could be useful.
• rope is a Python refactoring library that I had seen before, but it doesn't integrate with an editor I use day-to-day (yet), so I haven't been able to try it. It seems very capable.
• Turns out Komodo Edit, my current workhorse editor, has gone to 5.0, and I didn't even know. I think asking 4.4 if there are any updates should say, "Yes, 5.0!", but it doesn't.
• Dillo is a web browser. People still write browsers from scratch?! It sounds very idealistic ("Our policy is not to work around broken HTML."), but isn't this a hopelessly uphill battle?
• ecb is the Emacs Code Browser, which looks like a clever shoehorning of standard tree control file browsers into the Emacs world. How do they render the icons and stuff?
• Pyrox looks like yet another start on a wxPython-based editor, along the lines of UliPad, PyScripter, and so on. Unfortunately, the site is only in Spanish, so I can't really tell.

Other than Komodo Edit 5, none of these are going to become part of my tool set, but it's good to keep on top of what's out there.

James shows his oldest files, a meme he picked up from Doug who got it from Brandon, its creator.

See one of the above posts for details, but the idea is to find the oldest file in your home directory tree, and tell its story.

I found these:

1986-08-20 .\pscom\avl.h
1986-08-20 .\pscom\avl.c

(full files: avl.h and avl.c)

PSCom was a PostScript preprocessor that I wrote while employed at Digital. We wrote a lot of PostScript code, and wanted to be able to use conditional inclusion, macro replacement, and lexical compression (similar to what jsmin does for JavaScript today). PSCom was the result. It's a C program, and I'm amazed to remember the amount of work that went into providing basic features we take for granted now in the Python world, and in any modern programming environment.

avl.c starts like this:

/***    
 ***    avl.c --
 ***    
 ***    The AVL height-balanced tree abstraction.
 ***    Six functions are defined:
 ***    
 ***            newavl()
 ***                    returns an empty avl tree.
 ***            addnode(tree, key, data, compare)
 ***                    Adds a new node to the tree given.
 ***            node = findnode(tree, key, compare)
 ***                    Finds the node in the tree.
 ***            modnode(tree, key, data, compare)
 ***                    Modify an existing node.
 ***            im = startiter(tree)
 ***                    Starts an iteration over the nodes, returning an
 ***                    iteration map.
 ***            im = nextnode(tree, im, &node)
 ***                    Returns the new map, and writes a pointer to the next
 ***                    node.
 ***            size = avlsize(tree)
 ***                    Returns the number of nodes in the tree.
 ***    
 ***    N.Batchelder, 5/7/85.
 ***    Adapted 1/13/85.
 ***/

Clearly this would simply be a dictionary today, but I had to go and write an entire data structure to be able to store the symbol table for PSCom. The adapted date must be a typo, it was adapted 1/13/86, based on the comment in avl.h If it was truly begun in May of 1985, then it was originally part of a different project, perhaps a PostScript-like language implementation I was working on while at Penn.

One odd feature of PSCom: when shortening identifiers, you could choose the set of characters that would be used. PostScript has very lenient rules regarding allowable characters in identifiers, so you could use -_= as the set to choose from, and end up with a final file that looked like hardware timing diagrams, or ,.:;' which would be indistinguishable from chicken scratch.

One thing about the code that strikes me now: I wrote a lot of comments back then! I should get back into that habit...

I like using unusual text characters to decorate my site, for example, my home page uses lots of mid-dots (· ·) and chevrons (» »), as well as other special characters. To keep the HTML source from being cluttered with those inscrutable numeric entities, I wrote this Django tag:

special_ch = {
    '':     '',
    '>>':   '»',    # RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
    '<<':   '&#xab;',    # LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
    '(c)':  '&#xa9;',    # COPYRIGHT SIGN
    'S':    '&#xa7;',    # SECTION SIGN
    '*':    '&#x2022;',  # BULLET
    '.':    '&#xb7;',    # MIDDLE DOT
    '-':    '&#x2013;',  # EN DASH
    '--':   '&#x2014;',  # EM DASH
    ':>':   '&#x25b6;',  # BLACK RIGHT-POINTING TRIANGLE
    'o':    '&#x25e6;',  # WHITE BULLET
    '[]':   '&#x25ab;',  # WHITE SMALL SQUARE
    '<>':   '&#x25c7;',  # WHITE DIAMOND
    }

@register.simple_tag
def ch(value):
    return '&#xa0;'.join([special_ch[s] for s in value.split(' ')])

Now I can use the ch tag with a mnemonic representation of the character in question. Spaces become non-breaking spaces to help control the layout around these characters:

<p>{% ch ">> " %}more text..</p>
<p>{% ch "(c) " %}2002{% ch "-" %}2009</p>

becomes

» more text..

© 2002–2009

The tag reference takes more space than the entities, but I can tell how they will display, without having to memorize the Unicode code points.

Happy New Year, everyone.

Wishing you love, health, peace and the
happiness of your pursuits
in the coming year.