Evan J Palmer's Blog

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

Month: June, 2013

Two lessons learned from being a dickhead

935298_490304544373912_380161838_n

My film-editing-colleague and I made two funny faux pas with clients recently.

The first one occurred when emailing a prospective client. My business partner and I were writing up an email. We were discussing how we should not be too formal, which I think is true, for us. We joked we should call them new client “bro”  so my mate typed it into the email. We laughed and he upped the anti and changed it to “Broski”…. then accidentally clicked send.

Yup – we called a potential client “Broski” in writing.

Then we just pretended that we meant to do it. They decided to go with us, for some reason anyway, so now when we go to shoot we’re going to have to pretend we just talk like that.

The second faux pas was during the last shoot we did. We had all this footage of the carpark for which we were making a promotional video. During editing we noticed in the background of one of the shots, a mother was running with a pram. In another shot, a shading looking character with a hood walked past. Obviously we thought it would be funny to edit the two together so it looked like the shady guy was stalking/chasing the mother through a car park.

How did the client respond? This is an actual quote from an email:

1. Delete the scene with the man with the hood walking past.
2. Delete the scene with the woman running with the pram.

Makes sense.

Two lessons I learned:

1) Don’t write up joke emails
2) Your clients aren’t idiots

The benefits of working on a computer that is an absolute piece of shit

scientist

Surprisingly, I’ve found that having a low spec computer with HDD (in oppose to an SSD) has HELPED my skill set improve.

I think that might actually be irony, and not in an Alanis Morissette kind of way, but in the literal sense.

How you ask?

Well my solution takes perhaps 30-60 seconds to compile. And maybe the same amount of time to attach to a process. This is way too long. Not only do these minutes add up ove the days and weeks, but in this length of time it’s easy to lose focus on the problem.

To work around this, I’ve tried as much as possible to not attach my debugger.

So I don’t have to attach my debugger, I ensure my Tests are granular, and my logging is good – i.e my code is better.

I’ve seen a marked improvement in my unit tests since I’ve made this conscience change to my workflow.

TDD: Arrange Alter Act Assert

Prostheta_03-128

Here’s a pattern I’ve been using for managing maintainability of my unit tests (something I’ve had trouble with).

[Test]
public void MakeReissuePayment_DoesNotUpdatesReissuedAttendees_WhenUnSuccessful()
{
// Arrange
SetUpForPayment();

// Alter
_paymentSuccess = false;

// Act
MakeReissuePayment();

// Assert
_attendeeReissueRepository.Verify(x => x.Save(It.IsAny<AttendeeReissued>(), _transaction.Object), Times.Never());
}

What I’m doing here is the usual AAA pattern, but adding an alter step after I’ve arranged the standard values to run though this type of test.

So I will arrange my values to make the test pass. So that is, set up mock expectations with some private members, then make the smallest change possible to make the test unique/useful (alter).

It is important to note that in the SetUp() method, that NUnit calls before each test is run, it is important to reset all your private members, so that you can ensure they haven’t been altered in subsequent tests.

I’ve based this pattern of the pattern Roy Osherove offers in his great book The Art Of Unit Testing. It’s not a replacement for Object Mothers, but I find they can be overkill for some tests.

I never write the “Alter” comment (I just think it), because I don’t want to freak out other developers who are reading my code (“What the hell is Evan doing?”), but I think this really helps me keep my tests nice and maintainable.