Announcing Trailers for Netflix

Look at me! I made something and put it on the Internet. It’s called Trailers for Netflix.

I’m a big fan of Netflix Instant Streaming. But I had a problem finding stuff to watch on it, especially movies. Netflix is a giant wall of DVD box art and that didn’t help me find movies I’d like. So I didn’t watch many movies, even though I had already paid for them.

So one day I was sitting in a movie theater enjoying the movie trailers and I saw 3 or 4 movies I’d like to see. And then I had an epiphany. Why can’t I do this with the stuff on Netflix? Those movies are just as new to me as these upcoming theater movies.

So I made Trailers for Netflix. I cross referenced movie trailers on the Internet and the Netflix Instant catalog, did some usability testing and there you go. It’s will change your life, if you have Netflix. If you don’t have Netflix, you should sign up for their free trial.

At our house we’ve had a few already paid for family movie nights watching movies we never knew we’d like. And those movies were already right there on Netflix instant. We just needed to see the trailers.

It’s free, no sign-up needed, and fun. I hope you like it.

Video Production on a Shoestring

Image via Wikipedia

My wife Jennie has been cooking for people on special diets for over a decade. In that time she built up incredible skill in making food that tastes good with one hand tied behind her back. No gluten allowed? She knows a lot about nut flours. No sugar allowed? She figured out how to get raw honey to behave.

The ABC network ran a special recently on the people behind YouTube shows and how they are building careers by posting videos. That got Jennie inspired.

This article is written mostly to myself. Here’s how we made the first video, and what we’ll be thinking about in the future.

Make a video. Actually make a video. We have a big family, limited time, limited budget, and limited brainpower. Work within the constraints we have.

Which leads me to my first rule of doing new stuff: Don’t spend any money.

Whenever I get the itch to do something new anymore I try to do it without spending any money. Or to keep the budget at something ridiculously small. So for Jennie’s video, she used a little SD camcorder we picked up at a pawn shop for $80, and the built-in iSight camera in her iMac.

That actually worked out pretty well as you can see when you watch her video. Apple puts decent cameras in Macs. Our kitchen has a very pretty backsplash, and Jennie is quite pretty herself. So the whole thing looks plenty good enough for YouTube. I think you’ll agree.

Since it wasn’t convenient to pick up a 24″ iMac and point it over a mixing bowl (we didn’t actually try it, just sorta assumed) Jennie just used the camcorder. She  pointed and shot when she thought we’d want to see more up close. Since she shot the whole thing while I was at work, there was no one to help. It’s a nice constraint, really. The whole thing comes off like she’s showing you how to do this over Skype, but with a few closeups.

My only gripe with this setup was the audio. Jennie speaks loudly enough to be heard clearly, even over the red kitchen aid mixer. But even with that, you can hear that she’s several feet away from the microphone.

Image by Perfecto Insecto via Flickr

Even with what I consider to be so-so audio, we finished and released it. Which is principle two of doing new stuff: Actually finish something.

I was ecstatic when Jennie called me and told me she had finished shooting her video and liked how it came out. The hardest part, creating something of value, was done. And for my gripes about the techinically weak audio, her words are great.

So we were on track to actually assemble the footage and post something.

Now we had made at least one choice that made things complicated. By pausing the video and having closeups we had introduced an extra step. It would be easier if we had just shot the whole thing from the iMac in one go, no camcorder closeups, no pauses. That probably would not have been a very interesting video though. And besides, it’s no problem, we have an iMac with iMovie. What could go wrong now?

So I pulled together the camcorder footage and the iMac footage and started working in iMovie. That’s when I discovered what iMovie ’08 is good for. Turns out, nothing. This is footage shot on the iMac from the iSight camera in Photo Booth, mind you. I would play my second video clip and iMovie would play the audio from the first clip. It was maddening. I did eventually find a way to work around this, but even then, iMovie ’08 can’t actually let you show your closeup shot while leaving the audio from your main shot running. Useless!

I also tried Cinelerra. I have a modest Linux machine I use for development at home. I found Cinelerra to mostly be good for crashing.

After failing to edit the video for a whole evening I was discouraged.

I figured a free Linux video editor was what I wanted until I had more cash to burn on Premiere or Final Cut. So I did more research on Cinelerra. Maybe I could fix it. Well, it turns out no one uses it anymore. Everyone has moved on to OpenShot. That is a thing worth knowing. In 2011, the best video editor in Linux is OpenShot.

So I installed and fired up OpenShot. In just a few minutes I had all the footage imported and the first clip running and I was cutting into the closeups. It was perfect.

I have my gripes with OpenShot. It lacks visual indicators for clip fades. It’s underlying engine is probably capable of fancy audio processing, but very little of that is accessible. And there are still some crash bugs.

However, it edits video. The basics are all there and actually work.

So in a couple of hours I had the whole video edited.

The only problem left was the low audio level.

I ended up using avidemux to do my last compression pass. I found in avidemux an option for compressing and then renomalizing the audio. This got the audio up to what I felt was a passably loud level.

So I lived with this. We needed to put this video out.

I have this theory about audio, see? I think our eyes are far more forgiving than our ears. Watch the original Veggie Tales release sometime. Even though the characters are just blobs and the movements are more geometric than organic, we still suspend our disbelief. We can synthetically produce images all day, and viewers will see real characters in them.

But have we ever seen a cinema debut of synthetically produced voices, for important charaters? C3PO? Human voice actor. Star Trek’s computer? Human voice actor. Toy story? All voice actors. We all thought CGI for a whole movie was neat, but the audio was just plain old voice acting. They didn’t have giant render farms for Buzz’s voice. They just miked Tim Allen.

So that leads me to believe that the priorities of commercial YouTobe video are as follows:

1. Be worth hearing.
2. Be worth seeing.
3. Audio quality. (distant third)
4. Video quality. (barely matters)

Image via Wikipedia

I think it’s a mistake to obsess about lighting and camera angles unless the audio is perfect. But maybe that’s just me. Maybe I’ll read this in a year and laugh at myself. But I think I’m right about this. I’ll be watching for an inexpensive simple to use lavalier mic that we can plug into the iMac. That won’t get us “radio good” but it should get us almost “TV good.” That’s a huge improvement over “post-processed Skype.”

In the end our little show has been well received in our circle of friends, including someone who I think ought to know better. Which leads to our principle of marketing and growth: Don’t try to compete with the established players.

I think Jennie is talented enough that she will eventually be able to make at least few dollars doing this, and I think she has a shot at some real money. However, we don’t think that we can compete head to head with Mario Batali or Alton Brown.

We’re drawing a smaller circle and focusing just on cooking with Spelt flour. If you want to learn to cook, go watch the Food Channel. But if you are interested in the many benefits, wonders, and intricacies of Spelt flour, come see Jennie. Spelt is becoming easier for us to get, which tells me it’s a growing market. Lucky us.

So we’ll see how this goes. We’ve been delighted with the response to our first “show” and hope to see all of you again when Jennie makes soft pretzels next time.

What’s Wrong with Learning Haskell

Image via Wikipedia

This is in response to the recent State of  Haskell survey. They asked what Haskell’s main weakness or blind spot was and I couldn’t stop typing. Instead of leaving a comment on the survey, I thought I’d write it down here.

First of all, I like Haskell a lot. I’m the Thompson in “Thompson-Wheeler Logo.” That cute shape that cleverly combines the lambda and monad bind shapes? My idea. The irony is not lost on me. That Haskell logo of mine is used all over the world, and yet I’m barely a mediocre Haskell programmer.

I’m getting better at using Haskell to accomplish things I care about. But I think my experience in learning the language has been a little harder than it needed to be. I don’t want to imply that this is anyone’s fault but my own. But perhaps my experience can serve as a warning to someone. See that hole? It is, indeed, a dark hole. It is not of interest to you, programmer.

In order to communicate not only to programmers like me but also to some of the Haskell “formalists,” I’ll try to map my informal statements to some formal writing tools. Now I’ll be the first to admit that all the pairs in the mapping will contain informal terms, which ruins the formality of it all. Hopefully you formal folks will find it helpful. If you didn’t or barely understood that, it wasn’t for you, which is a point we’ll revisit many times here.

(Motivation)

I’ve been around a lot of language communities. Haskell’s is my clear favorite. Haskell people are happy and helpful, which is unheard of for a programming community.

Despite this, for me it has still often been difficult to find answers to my questions. I think this is largely due to the fact that, when discussing things with the average (serious) Haskell programmer, I feel like I have a fourth grade education. I took some discrete math as part of my CS education, but I have too little math background to understand a lot of what I hear.

I think especially early on that I could have had an easier time. Some mechanism to steer me away from some Haskell resources would have helped. I’m not sure what that mechanism might have looked like, so I handwave over the details here. Perhaps you formalists know handwaving over the details as the “Axiom of Choice,” no? I hearby invoke it.

For instance, (Or in formal terms, Example 1.1)  I tried to get in tune with the current practice of Haskell by lurking on Haskell-Cafe. It worked when I was learning Ruby. Not here. This was a bad idea. I learned nothing and it made me feel bad. Yeah, poor me.

Another time (Example 1.2) I tried to read the Comonad Reader blog. Another bad idea.

As a relative Haskell newbie, whose not-Haskell day job is web development, integrating systems, build engineering, tormenting managers, and sometimes just writing a lot shell scripts, Haskell-Cafe and the Comonad Reader are, and this important, don’t miss this: not for me.

Let’s be a bit more formal and state this as an axiom.

(Axiom 1) Again, I’m not sure how I could have known this, but it would have been nice if there was some way (Axiom of Choice?) that I could have known that these resources were, here it is: not for me. Those are for other people with different backgrounds and extremely different goals. We’ll call this the Axiom of Not for You. The italics are important. We don’t want confuse this axiom with the similar axioms of not for you, not for you, or the less emphatic not for you. This is the Axiom of not for you.

(Axiom 2) Despite the relatively small size of Haskell community compared to others, it’s ratio of diversity to headcount is higher than one might expect coming from, say, the Ruby community. This the Axiom of Not All Haskell Programs are Programs.

(Example 1.3) For instance, I’m a Ruby programmer. As someone who does his share of Ruby programming, I can take anything I read about Ruby and understand what it means to me.

And it’s easy to see why. Because at the end of the day, when people write Ruby programs, they are hoping to end up with a program. It’s is a program. You feed it to a computer which runs it. The computer, as a result does some useful work. I understand that.

But, it turns out, Not All Haskell Programs are Programs. There are people, I kid you not, who write these super elaborate Haskell programs, compile them, and consider their work done. I know. Inconceivable! They don’t even get a “Works on My Machine” sticker, because they don’t even know!

But when you understand that Not All Haskell Programs are Programs, it’s perfectly clear. Apparently those programs are really proofs encoded into Haskell’s type system, which is neat. If it compiles, and if you followed a few rules and understand a little Denotational Semantics, well then, you win! Yay! I can’t begin to tell you how happy I am for you. But the Axiom of Not for You applies here. I don’t need to understand that proof, maybe not ever. Those people are not programming, they are proving stuff. Proving stuff is not programming. Curry-Howard isomorphism notwithstanding, for my practical purposes, proofs are not programs.

(Example 1.4) Imagine that a nice girl with a dual background in programming in Haskell and driving steam rollers realized one day that some Haskell programs are steam rollers, and could, in fact, be used to steam roll. Roads. She also has a blog and writes this up. I stumble across this article. Using the previous axioms I would clearly understand that while it is an interesting and possibly revolutionary discovery that some Haskell programs can be used to steam roll, steam rolling is not programming. A steam roller is not a program and applications of steam rolling are not for me.

As to the mechanism to solve this, I think we need to realize that there are some workaday programmers like me looking to get a leg up on some of our harder problems. We value Haskell’s type system. Watching a program work perfectly the first time it compiles is a foreign yet pleasant experience. Getting more reliable code with less unit testing overhead is fabulous. Quick check is so neat I ported it to JavaScript.  And having an LOC count the size of a Python program but running with the performance of a C++ program is what motivated me to look at Haskell in the first place. Even slow unoptimized Haskell seems scary fast to me.

But, people like me need to be both steered to right learning resources, such as Learn You a Haskell or Real World Haskell, and steered away from the writings of Logicians and Type Theoreticians. My problem was that, not only did those two good books not exist yet, there wasn’t, and still isn’t, a mechanism to steer workaday programmers like me away from stuff we aren’t ready for yet.

So my humble suggestion, in all seriousness, is for the community to help the noobs not only with positive advice, like read LYAH, but also to steer clear of, or at least not worry about, say, automatic differentiation of types.

Thanks for reading.

Variation in Velocity

Tim Ottinger, a guy I’m proud to say was a co-worker of mine in an ancient past life, wrote a nice piece about a common mis-practice in measuring the velocity of a software project. I won’t re-explain velocity here. His article defines it very well and the way he explains how you can do it wrong really makes clear what it’s all about.

In case any of my 4 readers are too lazy to click, think of it as a number, bigger is better, measuring how quickly you are approaching the goal of shipping your software so you can get paid for the new stuff in it. How fast are we getting there? We have 30 things left to do. We are getting 12 done every three weeks. Looks like we start selling this thing in July. Yay!

Measuring it wrong leads to disaster, obviously. Oops, we couldn’t actually start selling until September. No one can sustain a business like that, at least not in this economy.

I’d like to quibble with this point:

“If velocity is going to have some normal variation due to emergencies arising, then many wise managers know to plan with a little slack.”

I don’t like seeing “normal variation” and “emergencies” so close together in the same sentence.

Deming had a purist view about variation, much like Tim’s purist view on velocity. Both are correct.

In Deming view there are exactly two kinds of variation.

Common causes of variation are statistical noise. Even the most well-managed stable system has variation. You don’t and can’t know the cause of it. You can manipulate it indirectly by experimenting on your environment, procedures, materials, etc. in hopes of making a new stable system that is better than the old stable system. “Why” is a dangerous question to ask here. It’s nearly impossible to have any confidence in our answers.

Special cause variation is introducing new causes, often by accident, into a system. These include but are not limited to emergencies. You fix them by looking for a root cause and eliminating it. We want special causes to be rare, and we mitigate our risk by building ever more robust systems to work in.

If we work in systems where special causes of variation are common, what can we say? We still haven’t figured out how to build robust systems. Agile at it’s best seems like a candidate for being that system. But if we can still say “normal variation” and “emergencies” in the same sentence with a straight face, we have a long, long way to go.

That sounds about right, come to think of it.

Ribbon Hero

Could someone replicate this educational game for Emacs?

Is it inevitable? Has it already been done? I hope so.

Maybe someone could do it for org-mode too.

qc.js in the Wild

I was glad to see some Haskell folks using qc.js.

I’m most excited by this quote:

In the future, we will probably also start testing DOM and user interface related code; hopefully, that will work just as well.

I share that hope. That’s exactly where I’m hoping this line of development leads. Given that they are clearly smarter than I am, it could really happen.

Film Forum Fresh Features

We’re trying something new this year for our Indianapolis Film Forum.

So far the group has already done two films, Avatar and Book of Eli. This year’s twist is posting video of the discussions online. We’ll see how it goes. So far I like what I see.

If you’re in Indianapolis perhaps you’d care to join?

qc.js: QuickCheck for JavaScript

I’m really excited to release this to the world.

QuickCheck is a fairly new testing concept that came out of the Haskell community. The goal of QuickCheck is to save time when writing unit tests.

I wanted to try QuickCheck in JavaScript, and I was really surprised to find no one had done a port. So I gave it a whirl and I found it was less complicated than I thought.

Therefore, here is qc.js: QuickCheck for Javascript.

Firebug Console showing qc.js output.

Here’s a quick synopsis of why you might want it:

When we write conventional unit tests we construct a series of test cases to try to exercise the majority of some bit of code.

QuickCheck changes the structure of this. Instead of individual test cases, we take our code and consider some aspect of it’s inputs. We then write functions which check properties of the output of arbitrary inputs to our code.

A property of an add function might be that given two arbitrary positive integers, the result should be larger than each of them.

A property of a sort function might be that given an arbitrary list of arbitrary integers and two different arbitrary indexes smaller than the length of the list, the element at the smaller list index should be smaller than the element at the larger list index. (woo mouthful)

So given a function like that, we can generate hundreds or thousands of arbitrary inputs and run our code and then the property function each time.

It’s fun to work with.

For some code, especially simple pure computation, it’s very quick and easy to write properties and you get good test coverage with less effort than the xUnit framework for your language.

John Hughes, one of the researchers who popularized this concept, has a video showing how to describe arbitrary inputs for normal impure code.

He shows how random unit testing can be creepy good at finding obscure corner case bugs and helping us understand the implications of the code we are writing.

I’ve got in the back of my mind to try using qc.js to throw arbitrary input events at a DOM/JS user interface to weed out weird bugs. At this point I have little more than a vague sense that it should be possible.

But anyway, enjoy.

My BitBucket repository.

John Hughes explains QuickCheck and demonstrates his Erlang implementation.

TJ Ford Called My House

I wrote about TJ Ford’s call to my house for Indy Cornrows. How fun was that?

Better Sports Motivational Analogies

I have acquired a distaste for motivation and the culture around it. That goes extra for managers who think a speech containing Tiger Woods accomplishments is going to get sales up.

With that said, I was impressed with a bit from a Basketball coach on keeping players accountable for off season workouts. As in, actually doing them. At all. Keep in mind, that this is different from some boss who read ESPN this morning and had a moment. This is an actual coach.

The first thing that’s interesting is that even pros at the highest levels of competition have problems getting motivated during the off season. Some of them don’t do what they are supposed to do, for what appears to be the same reasons as developers and writers.

Second, an experienced coach is telling us that striving for greatness isn’t the key. It’s showing up at all that gets the job done. And his prescriptions are mostly low tech and focused on accountability.

Third, he advocates working in pairs. I wonder if the same managers who think pair programming reduces throughput would think the same of pair workouts.

When there’s a really tough development task to do, nothing gets it done faster than a team of two engineers.