Flash Forward

I consider myself to be an available light photographer. I typically take landscape (natural or urban) and wildlife (flora or fauna) photos, which implies that I make use of natural light to illuminate my subject. For the most part, it's a very WYSIWYG experience.

As such, I don't often find myself creating light for the scene. I rarely use my on-camera flash (it really sucks any sense of dimension out of a photo), but I have used an old Canon flash for off-camera macro photography. I bought an optical flash trigger so I can activate the remote flash using my on-camera flash. Unfortunately, the setup is awkward enough - and the results not satisfying enough - that I haven't gained any competency using a flash. And I have been OK with that deficiency.

Until now.

Carolyn got me a very nice flash for Christmas so I have become forced to become competent. I have tried playing with it on a few occasions in order to familiarize myself with the gamut of functions that I never realized a flash could have. It's quite frustrating to step out of one's comfort zone. I feel completely at ease with my camera in my hands, but with the addition of this inarguably helpful tool I have become a novice again.

Now, I have accepted (begrudgingly) the fact that I won't understand all the fancy features of the flash overnight; I don't even know what they are all for, let alone how to active them. What is most frustrating for me is not being able to create the lighting effect I desire. I am not able to correctly visualize how the scene will appear when I place the flash in a certain way using a certain setting. I mean, I understand the fundamental concepts of lighting, but I can't seem to consistently apply them.

On top of that, flash photography requires a much different mindset than available-light photography. Consider that when taking a photograph using available light, you take what you can get, and then you move on. If the sun has set then you can't get those cozy, warm colours any more. For me, this is great because I am under the pressure of the clock to get the shot; if I don't get it within that window then there's nothing more I can do.

That concept doesn't apply when you use flash. If you aren't getting the result you want then it's because you're not doing something right, and it's up to you to fix it. And there's no clock. No clock means there is no end. No end to getting the shot that's just a little bit better than the last one. For a perfectionist, this isn't healthy.

I suppose half the problem is that I don't know when I've nailed the shot; when I'm using natural light I have a sense of this, but not as much when using the flash. I expect this will come with time and practice, but knowing this fact doesn't make it easier.

So, practicing is what I have started to do. After a trip to the dollar store I acquired some coloured bristol board for backdrops, a foam board to keep them straight, and some clips to keep them attached. I managed to keep the foam board upright using some tape and a bookend, but I may invest in some better equipment after squishing my subject a few times. Below is a selection of my recent attempts. Note that they are all against a black backdrop; I was unable to illuminate the white backdrop enough, and the blue background just wasn't cutting it.

I have signed up for a day seminar for flash photography with Richard and Ryan in April, so I have high hopes for what I will learn. In the mean time I'll keep flashing.

New Year Resolutions

I'm not telling!

Rocky Holidays

Last Thanksgiving weekend, Carolyn and I went to visit our friends Andrea and Jeremy in Alberta. They moved out there last summer when Andrea got a ministerial placement in the metropolis of Killam. I can confirm that there is at least one stop sign in the town.

They were gracious enough to drive many hours and many hundred kilometers to show us the amazing Rocky Mountains, so I thought I should finally share some photos. Furthermore, I upgraded my computer over Christmas so I can do certain post-processing techniques (such as panoramas) much quicker.

We flew into Edmonton in the evening where we met Andrea, Jeremy, and Hiro. From there we drove straight to Canmore. Jeremy has booked us a great chalet, and this is the view we found in our backyard the next morning.

We drove into Banff National Park - my first visit - and headed for the Banff Gondola. The view on the way up is amazing, and once you're at the top - spectacular. We hiked around for quite some time and I took a number of photos. I think Jeremy and Andrea learned how time can slow to a crawl when I have my camera.

We then headed to Lake Louise for another short hike. Right on the lake is the Château Lake Louise, which is amazingly large and without a doubt has the best-smelling bathroom soap I have ever used. Everything since has left me wanting more from my hand-washing experience.

Just south of Lake Louise is the pristine Moraine Lake. I have never witnessed water so turquoise. Apparently it is one of the most photographed locations in Canada, and I can understand why.

Me and Carolyn at Moraine Lake.

Jeremy and Andrea at Moraine Lake.










To our dismay (and relief) we didn't have any real bear sightings (ask Carolyn), but on our way out of the park we had the pleasure of coming across a family of deer.




After ingesting some overpriced raclette in Banff, we headed back to Canmore. The next day we started the trek back to Killam. We stopped in Drumheller at the Royal Tyrell Museum. Sadly we got there too late to see any exhibits, but not too late to purchase some gifts for our dinosaur-crazy nephew. There were some dinosaur replicas outside the museum that Hiro was not too impressed with.

Late in the evening I finally got to check another thing off my life-list: seeing a moose. The photo isn't great but it's proof.


We finished our our visit with another few days in Killam, enjoying some balmy weather and a fabulous Thanksgiving dinner.

New Blog

I have a new blog. I won't be abandoning tales of interest - not that it's bustling with activity - but I'll be writing all my work/tech related stuff on my other blog. If you're interested in that sort of thing, please go to:

http://perpetualdevelopment.wordpress.com/

And if you're not interested... well, you're welcome!

The Book of Revelation

Before you read any further be warned that I'm raising a Level 1 Geek Warning: if you are not in the software development industry, you'd probably enjoy your time better here.

Today, unlike most days recently, was a wonderful day at work. I actually didn't want to leave. I'm considering going to work early tomorrow. What happened? Well, let's go back in time a few months...

I think it all started with Ryan. Now, every day starts with Ryan talking. Usually before I get a chance to sit down and read my e-mail he's already bombarding me with questions about some obscure problem (perhaps only obscure because I'm only half-listening at this point). But those days he started talking about books - or more specifically, the interesting things he was learning about from those books - and I started to pay attention. He told me about this crazy mystical practice called 'test-driven development', where not only do the developers test all their code, but they write the tests before they write any code!?!?! I don't think I actually laughed at him, but I let him know that it all sounded well and good as an academic exercise, but it couldn't really be done in practice by sane individuals.

And so we moved on. Ryan kept reading and kept telling me to read these books, and I kept deflecting and diverting. Then something happened, and I'm not quite sure what it was (hey, I never claimed to be a good storyteller!) but I finally relented to the pressure. The book was 'The Pragmatic Programmer' by Andy Hunt and Dave Thomas (not of Wendy's fame). I don't want to say that this book changed my life, because I hate it when people say things like that. So, I'll just say that this book had a profound impact on how I view myself as a professional software developer. That sounds a lot less sappy.

This isn't a technical book. It's a book about good practices and good attitudes. It's about taking pride in one's career. The book is littered with tips, but here are the first five (which I also have posted on my office door) that I feel are applicable to anyone in any profession:

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

Make Quality a Requirements Issue
Involve your users in determining the project’s real quality requirements.

Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

In a sense, this book revealed a whole new world to me. I had been blind as to how software development could be done. I didn't realize how much more I could be (and arguably should be) doing. And thus I started to read.

I have since read (and recommend)

• Implementing Lean Software Development: From Concept to Cash
• Practices of an Agile Developer
• Refactoring: Improving the Design of Existing Code (minus the large reference section)

The book I am currently reading is 'The Art of Unit Testing'. I'm not terribly fond of the format of this book (a lot of repetition), but it's a good beginner reference. I knew before reading this of the importance of formal unit testing (even though I had done little of it myself), but it has enlightened me to some techniques, common problems, and frameworks that could save a lot of time and effort in generating new tests.

So that brings me to today. I had been working on a connectivity bug over the last couple of days and during my analysis had uncovered a few 'loose ends' in the connectivity framework that Ryan and I had developed. Empowered by the 'fix broken windows' philosophy we decided to fix the root of the problems as opposed to patching the symptoms. The root of the problem was unfortunately embedded in the original design, but as Martin Fowler says: refactoring means never having to say you're sorry.

It was this morning that we first embarked on our first voyage of pair-programming test-driven-development. We had done plenty of pair-programming before (very successfully I might add), but never true test-driven-development (TDD). We knew that one of the main classes in our framework had too much varied responsibility, and we wanted to break that up. Instead of liberally ripping apart the code we wrote test cases to help guide how we wanted to refactor. Instead of building from the inside out (i.e. implementation->API), we were building from the outside in (usage->implementation).

This shift in thinking was phenomenal. Traditionally in developing something, I would figure out generally what a component needs to do, and then figure out the best way for it to do that (i.e. figure out the best implementation). The API would then be driven by the implementation. In the act of generating the test cases however, we were thinking about what we wanted to be able to do with the class, which in turn defined how we wanted to use the class. Thus, we first defined the API, and the implementation flowed naturally from there.

Now, perhaps this is how everyone else has been developing software and I've just been in the dark. But I've been around long enough to know that this isn't necessarily common practice, even if it is common sense to define the API and interactions first. The great thing about doing TDD is that it creates a smart and usable design, and you get a mechanism to automatically verify the functionality of your component. Two birds, one stone.

If you haven't tried or heard of TDD, don't laugh and discount it like I did; I encourage you to research it to see if it's right for you. And, as Ryan has already mentioned to most of our colleagues, if you value your career as a software developer, you owe it to yourself to read 'The Pragmatic Programmer'. Let me know if you want to borrow it.

Stating the Obvious

I haven't posted anything in quite a long time.