What is the best makeshift ice scraper?

TicTac container. Seriously, it saved my life this morning.

How to export a 1024 x 768 screencast from Adobe Premiere Pro CS4 to Youtube

Over spring break, I made some screencasts for the website I maintain for my job. We used a free, open-source screen recorder called CamStudio. Our plan was to upload them to YouTube and embed the videos into our site from there. The one problem: the Export Media dialog on Adobe Premiere Pro CS4 (the software I used to edit the screencasts) only has a setting for low-definition (320x240) videos. My screencasts were 1024x768, and shrinking them to 320x240 would make the video part pretty much useless.

So, I set about trying to find a setting that would work for a 1024x768 screencast. The majority of settings produced some weird-quality results, even with the quality settings turned up as high as possible, which makes me think it had something to do with a faulty interlacing/deinterlacing setting somewhere. When I changed the one interlacing setting I was able to find, the exported videos would work fine in QuickTime, but look completely messed up in VLC and, more importantly, YouTube.

Exporting to F4V actually did work in every media player I tried it in, but for some reason, YouTube was unable to convert it to a playable format.

Finally, after about 9 hours of fiddling with Adobe Premiere Pro's Export Media dialog, I found a setting of acceptable quality that worked on YouTube. I doubt many other people will need this, but since I was unable to find any information about the problem I was having online, maybe I'll save another person 9 hours of work. Here are the settings I used:

Export Settings
Format: QuickTime

Filters
No Changes

Video
Video Codec: H.264
Quality: 100
Width: 1,024
Height: 768
(Width and Height are unlinked)
Frame Rate: 30
Field Type: Lower First (this was the setting that deals with interlacing I believe)
Aspect: Square Pixels (1.0)
Render at Maximum Depth: Checked
Set Key Frame Distance: Unchecked
Optimize Stills: Checked
Frame Reordering: Unchecked
Set Bitrate: Unchecked

Audio
No Changes

Others
No Changes

I'm sure there are some optimizations to be made in these settings; things that are causing me to produce unnecessarily large files, things that make rendering slower, or things that, if I tweaked, would give me even better quality. However, after 9 hours, I don't care; this works, so for now, I'm done. Hope this helps someone.

My greatest beer-related discovery

Before college, I didn't drink at all, and even in college, I don't drink very much; once every couple weeks during the school year, maybe once or twice a week during vacations. During this short time, I'd never been able to get myself to like beer. I always wanted to, but I just never could. The taste always reminded me of garbage (or at least, what I imagine garbage would taste like). I spent a fair bit of time on Google trying to find what beers other people really like, and every one I tried had the same garbage-y taste.

One day, with the prospect of playing a drinking game while watching Independence Day (drink every time there's an explosion... ughhh...), I decided I'd try a lite beer, so I wouldn't feel like I'd eaten an entire loaf of bread after my third bottle. I did a little research, and found that people had great things to say about Sam Adams Light. I got a six-pack, and to my surprise, I didn't hate it as much as I hated other beers. $9.00 for a six-pack of somewhat-tolerable liquid is pushing it, but at least I could play drinking games with my friends without resorting to Mike's Hard Lemonade.

The important part was this: instead of tasting like beer (and, by association, garbage), it tasted like water with a slight aftertaste of beer/garbage. This made me wonder: is there a beer that really just tastes like water? I asked my friend Trenton. The answer? Natty Light.

I'd been looking in all the wrong places. The people who had been telling me the "best beers" were people who loved beer and think it tastes like the nectar of the gods. I hate beer and think it tastes like the nectar that drips from a leaky garbage bag, so of course, the best beer for me is the one that tastes as little like anything as possible. And as fortune would have it, the best beer for me is also the cheapest beer. For less than the cost of two six-packs of Sam Adams light, I can buy a 30-rack of Natty Light.

Don't get me wrong, it still tastes gross. In the end, I really just don't like the taste of alcohol very much, and beer is no exception. But unlike with "good" beer, I can drink a few cans of Natty Light without dreading the taste of garbage each sip. And that's something I think we can all drink to.

Benchmarking Python decimal vs. float

I'm writing a web app that includes, among other things, a good amount of (rational) non-integer numbers. Whenever I'm in this situation, and I'm using a language that supports Decimals (as opposed to just floats and doubles), I always wonder which one I should use.

If you're a programmer, you understand the difference and the dilemma. Floats/doubles are very fast, as all computers (built within the last 15 years) have hardware specifically made to deal with them. However, they're not perfectly accurate; because of binary representation, numbers that we use a lot (like 1/10 or 0.1) cause the same problems that 1/3 (0.33333...) cause in base 10.

Decimals, on the other hand, are slow. They are handled entirely in software, and thus take hundreds of instructions to do things that would take less than 10 with floats/doubles. The upside is that they're perfectly accurate; 0.1 is 0.1 is 0.1.

So the question becomes twofold:

1. Do I really need my numbers to be perfectly accurate?


2. How much slower are decimals than floats/doubles?

In my case, the accuracy would be nice, but not completely necessary. And thus, the latter question becomes important. I'm not writing a large application, and I don't expect it to get too popular too quickly, so if the slowdown is only moderate, I'll take the accuracy.

To learn what the slowdown was, I wrote two quick Python test programs:


# Decimal test
 
from decimal import Decimal
 
a = 0
for i in range(0, 20000):
    a = Decimal('%d.%d' % (i, i))
    print(a)



# Float test
 
from decimal import Decimal # kept this in on the float version
                            # so they'd have the same overhead
 
a = 0
for i in range(0, 20000):
    a = float('%d.%d' % (i, i))
    print(a)


When I ran each of these with /usr/bin/time (which I just learned about a couple weeks ago, and has replaced counting seconds on my fingers as my favorite benchmarking tool), the decimal version took an average of about 1.5 seconds (over 10 runs), while the float version took an average of 0.5. Just to make sure no overhead was getting in the way, I upped the limit to 40000 and ran it again. Decimal took 3.0 seconds, float 1.0. I can now confidently say that Python floats are about 3x the speed of Python decimals.

Or are they? While this tests the creation and printing of decimals and floats, it doesn't test mathematical operations. So, I wrote two more tests. I'm going to be doing a lot of division on these numbers, and that's definitely the most expensive mathematical operation to compute, so I made sure to do it in the tests (along with some subtraction).


# Decimal version
 
from decimal import Decimal
 
a = 0
for i in range(2, 20002):
    a = Decimal('%d.%d' % (i, i)) / Decimal('%d.%d' % (i - 1, i - 1))
    print(a)



# Float version
 
from decimal import Decimal
 
a = 0
for i in range(2, 20002):
    a = float('%d.%d' % (i, i)) / float('%d.%d' % (i - 1, i - 1))
    print(a)


This time, the float version averaged about 0.6 seconds (1.15 with 40,000 iterations instead of 20,000), while the decimal version averaged over 11 seconds (23 with 40,000 iterations instead of 20,000). So while Python float creation and printing is merely 3x as fast as Python decimal creation and printing, Python float division is almost 20x as fast as Python decimal division.

So what did I choose? Decimals. In the context of these tests, the decimal slowdown may seem significant, but if I finished my app using decimals and profiled it, I can almost guarantee (based on the speeds here) that the bottleneck would not be decimal division performance. If I was running an app that was handling hundreds of simultaneous requests, I may consider switching (I may also spring for better hardware, but that's a different topic). However, for my purpose, 1/20th the speed of floats is more than fast enough.

P.S. As my very late discovery of /usr/bin/time should suggest, I'm extremely new to benchmarking. If anyone has any suggestions for me, or criticisms of my method, please leave your thoughts. This is something I'd like to get better at.

Why Facebook keeps changing their interface

Facebook has a new design. Every programmer I know loves it. Almost everyone else I know hates it. I could've written those three sentences a couple years ago, copy/pasted them every six months, and they would've fit perfectly every time.

Of course, the pattern has always ended the same way as well. People forget about it within a month, and when the next change comes around, it's "It was PERFECT the way it was, why are you changing it?!"

In fact, I've seen a bunch of people asking "why does Facebook keep changing the interface?" Most people are asking it rhetorically, with the implied answer being "to confuse users." However, if asked honestly, it's actually a pretty good question, with a pretty good answer.

Facebook has gotten where it is today by innovating. Prime example: the News Feed. When they added the News Feed, no one else was doing anything like it. Despite massive user riots, they stuck to their guns. Two years later, everyone loves it, all the social networks have copied it, and there would be massive user riots if they scrapped it.

Facebook has stayed at the forefront of social networking innovation by constantly throwing everything at the wall, keeping what sticks (News Feed), and scrapping what doesn't ("How do you know this person?"). It's in their best interest to do this; they make their money from venture capitalists and advertisers, not from charging users.

If they charged users, changing the interface so often would be a bad move; users would stop paying as soon as they became confused with a new interface, and they'd lose money. As it stands, users who are confused with a new interface can take a break at no cost to Facebook, come back in a few weeks (as they always have), and the advertisers and venture capitalists (who only care about long-term success) are happy.

Obviously, Facebook and its investors have become accustomed to the pattern: make a change, suck up the complaints (possibly while making some adjustments, like the additional privacy options after the News Feed was added), and reap the benefits of being a bastion of social networking innovation for another six months. Eventually, maybe the users will get used to it as well. I've actually seen a few status updates along the lines of "I guess I probably won't hate this so much once I get used to it" after this update, so who knows?

Apple takes it too far on form-over-function

Today, Apple announced the new iPod Shuffle. It drops the navigation buttons in favor of making it slightly smaller.

Your first question upon hearing this was probably the same as mine: "How do you switch songs?" Simple: the controls are on the cable of the prepackaged headphones.

Do you listen to your iPod with the headphones it came with? Most people I know don't. Admittedly, I don't know anyone who owns an iPod Shuffle (my mom used to, but that's it), so it's possible that iPod Shuffle buyers often stick with the default headphones. But be warned: if you buy an iPod Shuffle, and you want to use your own headphones, get ready to not be able to switch/skip songs.

I understand choosing form over function, up to a point. But to me, this just seems ludicrous. The difference in size between this thing and the last-gen iPod Shuffle is minuscule, and the functional sacrifice immense. But maybe I just don't get it.