Evan J Palmer's Blog

A blog about learning (code, improv, film and, anything else).

Month: May, 2013

Modernizr’s load method.

2001-l-odysee-de-l-espace-1968-g

I reckon I found a gotcha in modernizr’s load method.

Peep this yo:

Modernizr.load({
  test: Modernizr.input.placeholder,
  nope: ['/v2/Scripts/jquery.placeholder.min.js'],
  complete: function () {
    var inputs = $('input:text[placeholder]');
    if (inputs != undefined && inputs.length > 0) {
      inputs.placeholder();
    }
  }
});

When do you think inputs.placeholder would get called?

I would have thought only when Modernizr.input.placeholder is false, right?

WRONG YOU IDIOT! GO BACK TO GRADE SCHOOL!



I apologise. That was too harsh, but it is worth noting that complete() will be called, regardless of success, so it’s necessary to test in the complete() block (line 7).


Modernizr.load({
  test: Modernizr.input.placeholder,
  nope: ['/v2/Scripts/jquery.placeholder.min.js'],
  complete: function () {
  if (!Modernizr.input.placeholder) {
    var inputs = $('input:text[placeholder]');
      if (inputs != undefined && inputs.length > 0) {
        inputs.placeholder();
      }
    }
  }
});
Advertisements

Computers do what you tell them to.

jurassic-park1_481597

So there’s some conventional wisdom in computer science that goes something like “computers only do what you tell them to do”. So basically, if your code isn’t working it’s your fault. In other words, your code is working, you just told the computer do something dumb.

So picture this, you click on the reporting tab of your application, and see an error page. That’s exactly what should happen. You told the computer to get the data, and divide “a” by “b”. Since “b” was zero and you told the computer that when when you divide by zero you should throw an excpetion. And when you throw an exception, you should show the error screen.

See! You told the computer to show the error screen when you click the reports tab!

Right?

Well no – the programmer did. But YOU didn’t. So mabe the addage should changed to:

“Computers only do what the programmer told them to do?”

Right?

Well I don’t think that’s right either.

I mean, the programmer didn’t tell the machine to throw a DivideByZeroException. It’s true the developer should have handled that case, but the programmer didn’t tell it to do that at all.

The language designer did.

So should the adage be change to:

“Computers only do what the developer and language designer told them to”

Maybe – although it doesn’t really have the same ring to it.

Anywho, my only point is that computers don’t do what YOU (i.e. one peson) told them to do. They do what a person who told a person who told a person who told a ….

In the words of Jeff Goldblum in Jurassic Park:

[We] stood on the shoulders of geniuses to accomplish something as fast as you could, and before you even knew what you had, you patented it, and packaged it, and slapped it on a plastic lunchbox, and now! Now you’re selling it, you wanna sell it!

http://www.hark.com/clips/lmkybthqdz-you-stood-on-the-shoulders-on-geniuses

Paul Irish’s Asshole Effect

... because the Boondock Saints are Irish.

In Paul Irish’s epic video on 10 Things I learned from the jQuery Source, he shows this great pattern to use to combat the ” Asshole Effect”.

(function($, window, document, undefined){
...
})(jQuery, this, document);

Me likey.

MOQ: what parameter was passed to a mocked function?

I came across an awesome feature of MOQ today.

I needed to see what parameter was passed to my mocked function in order to see if my LINQ was behaving correctly.

I couldn’t just test the return value of the function I was testing, because the value I was interested in was lost due to it being passed to an invocation of a method.

Enter MOQ callbacks.

According to the docs (https://code.google.com/p/moq/wiki/QuickStart):

// access invocation arguments
mock.Setup(foo => foo.Execute(It.IsAny<string>()))
    .Returns(true)
    .Callback((string s) => calls.Add(s));

Which basically means, we can pass a lambda to the CallBack method of the mocked function that matches the parameter we expect. We can now access this in the test and store it to a local variable (or do anything else to it progammatically).

Then assert it!

So sweet!

17 Things I Learned Filming for a Client

My friends and I recently completed our first paid video editing job for a client.

In some ways it’s very different to what we usually do. So, not just a bunch of friends hanging out, drinking beer and filming whatever we wanted. This time we had people with a time constraints taking time out of their busy days, relying on us to get the correct footage.

I learnt:

  1. Make sure you have a back up power source
    It’s stressful as you see the power supply go down on your battery when the client is relying on you to be effective with their time. Make sure you have an additional power supply, or batery pack and your charger with you.
  2. Make sure you have loads of space to record all the footage you need
    Don’t run out of disk space. You don’t want disk space to be an issue for getting those awesome shots when other people’s time is at stake. Make sure you have additional memory cards and a laptop to transfer the media onto.
  3. When interviewing people, be sure to be supportive, but don’t talk about freezing on camera
    We tried to make people comfortable by saying things like “You’ll be fine. when I’m on camera, I just freak out and forget my lines, but you – you’re awesome and will be fine”. I don’t think that is the correct tactic, because it puts the thought in the talents head that people can freeze. Just don’t mention it and be super supportive.
  4. Think carefully about lighting. Use lighting that’s available, if you can’t bring your own.
    Ideally you should bring your own lighting, but remember to get it right the first time
  5. Have a director
    Someone (preferably a single person, maybe you) should act as a director. The point is that one person should be calling the shots, ensuring there is quiet on set, directing the talent and making a final call on all decisions.
  6. Be mindful of background noise
    Same with shooting anything, really, but you might not be able to re-shoot as easily
  7. If you’re unsure, retake
    Better safe than sorry!
  8. Be mindful of your client’s time
    We’ve got lots of people waiting around to be shot. Five workers, and a manager. Should I shoot the manager first? Do any of the staff need to get back to their regular duties quickly?
  9. Sync audio in post with Plural Eyes
    Plural Eyes is a beautiful piece of software that syncs up audio for you
  10. Make life easy for yourself: get it right first time
    Pay attention to light, audio, framing etc  the first time around. It’ll save you hours in post.
  11. Record lots of ambient noise
    Get it while you’re on location! As film editors will know, this stuff is invaluable for patching up audio and seaming together cuts.
  12. Be a good director
    Make sure you’re filming the best that each person can be. Give them confidence and keep an eye on their body language.
  13. Get the rough cut to the stakeholder as early as possible. This is a tough one, because you don’t want to get it to them too early – before it looks half decent. But you want feed back as fast as possible.
  14. Be more specific with time frames after each review. This means say something like, “we’ll make these changes by tuesday, and when we meet on Wednesday, we expect that you will have a very minimal change set”.
  15. Understand the script/vision as well as you can from the beginning. Read the script several times. Ask questions about it. What is trying to be conveyed in the video.
  16. Recommend stuff, but be accommodating. Ie. from our experience, we think not centering this will look nicer, but of course, if you feel strongly we can keep it there”.
  17. Keep old versions/sequences so you can “rollback” or review when necessary.