lens envy

A few weeks ago, I wrote about the virtues of buying a lens separately from an SLR camera body in my Canon Digital Rebel XT Buying Guide. I've been noticing that my recommendations for good starter lenses are rather small compared to the lenses I see people carrying to events. First at the Cherry Blossom Festival and most recently this past Sunday at the Digital Days workshop, I'm seeing people, many of them, with monstrous zoom lenses.

It seems like everyone has a case of lens envy. People are walking around with lenses that cost well over $1000, protrude 6-12 inches out from the camera body, and weigh 5-10 pounds, but for what?! I truly think this is a case where consumers are feel that bigger or heftier is better. It may be the case some of the time, but it's obvious that a fair number of the consumers who own this equipment haven't a clue about how to use it, let alone why they even have it.

In general, most consumers, including myself at one point, feel that more zoom is always better, that way one can take pictures of faraway things. This is sort of a lazy mentality though. Instead of walking around, taking a few steps to get a little closer, and maybe finding a more interesting shot along the way, people are opting to stand in one spot and just use the zoom to bring the scene closer to them.

Although massive zoom lenses are useful in certain situations, mainly sports, wildlife, and high-end fashion photography, super telephoto zoom lenses have some drawbacks though. Technically, many of the telephoto zoom lenses tend to have small maximum apertures and slow shutter speeds. Minor camera shake (even by pressing the shutter release button) will cause the picture to blur if lighting conditions are less than noon sun bright. Some of the newer telephoto zooms correct for camera shake by building image stabilization into the lens (and paying more for it). Image stabilization dampens motion introduced by the photographer, but what about motion introduced by the subject? If the subject moves even just a bit, the picture will still blur. Maybe not a problem in a studio, but it's a major problem in the real world. The wind blows, animals and people move.

I think even more important than the technical reasons, telephoto zoom lenses put significant distance between the photographer and the subject. I noticed this during the workshop when we had a practice session with still lifes and models. Everyone was standing 5-10 feet back from the still life and 10-20 feet back from the model. Then there was me and my sis, blocking their view by crouching or standing within arms reach of the model because neither of us had zoom lenses on our cameras. In my philosophy, part of photography is understanding the subject: observing, relating, finding that element that is interesting that everyone else has overlooked. You just can't do that when you're standing ten feet back.

Save yourself some money, resist lens envy.

Now, just for kicks, a photo taken with my short lens from the workshop… This is the first and probably last time I'll be doing studio-type photography—it really wasn't my element. I was experimenting with aperture settings on my camera and the only interesting thing about this photo is the motion blur on the model flutist's fingers on her left hand.

photo contests

For the amateur photographers (like me) out there, a handful of photo contests are in progress right now:

• Washington Post Travel Photo Contest
• World In Focus by National Geographic Traveler and Photo District News
• The Blink of an Eye by Flickr
• Costco International Photo Contest

Place your entries and good luck!

a photo finds its way home

In an earlier post, I mentioned my experience taking pictures at Bay to Breakers. In total, I snapped around 220 pictures with my camera for the day, mainly of random people on the street. After getting back to DC, I decided to conduct a small uncontrolled and unscientific experiment. What are the odds of me finding someone in one of my photos? After all, everyone was kind enough to let me take a picture of them without saying much of anything (other than a thank you and a peace sign), so maybe I could return the favor and give them a full resolution photo of their costumed self on the route.

Where else does one start on such a venture other than craigslist? I posted a short message on the San Francisco board a week ago.

I was on the Bay to Breakers route with a SLR camera in hand and a bottle of champagne under my left arm. Thank you everyone for all the great pictures! If you remember my lens in your face, I'd be happy to share a copy of the original file with you. If you have a short description of your costume, I'll be able to look for the photo pretty quickly, or at least get some candidate photos.

Keep in mind, craigslist does not allow posting links in the messages—so I wasn't able to pass a link to my Bay to Breakers flickr set out and have people sift. Within the weekend though, I received two replies, all the replies I would receive from this message. One reply asked if I saw a group of people in costumes reenacting human conception. Another reply asked if I took a picture of a green snail with a wig and a handmade shell. No dice. I flipped through all my pictures and I found neither costume. So I sent some disappointing replies, but passed on the link to my flickr photo set anyway, just in case they wanted to double check on their own.

The next day, eureka! Patricia, the one in the green snail outfit that I didn't spot, recognized her friends in one of the pictures—the runaway brides.



She passed my info along to Erin, one of the brides, who then requested the original resolution photo. I, of course, obliged and reunited the original photo with one of its subjects :)

If I remembered a little more from undergraduate probability class, maybe I could calculate the odds, but my mathematical intuition, which I rarely trust, tells me the odds are slim. I'm not sure how many people read the ad, but only two people responded. And within one degree (Patricia knowing Erin), we found someone in one of the 44 photos (I didn't post all 220) I had in my flickr set.

Ken → (craigslist) → Patricia → Erin

If anything, craigslist is kind of a shortcut (science nerds might call it a wormhole) through the social network where supposedly everyone is connected to everyone else by six degrees or less. Either that or craigslist just enables people to form a quick "A knows B" relationship in the social network. Ok, enough geeking out.

I'm just glad even one of the photographs found its way home.

what is software engineering?

My informal response to a question from class: What is software engineering?

It seems like there are definitions by the dozen for software engineering. IEEE has one, along with every software engineering textbook author. I think we shouldn't miss the principle or essence of what software engineering is though.

Software engineering as a field emerged (and continues to grow and develop) as a result of increasing software costs, software development disasters, unreliable or insecure software, and more so nowadays, critical system failures that carry huge financial costs and sometimes human costs. Software engineering is a reaction to these problems and the goal is to find ways to solve or at least reduce the negative impacts of these problems and produce positive results: on-time, on-budget, safe, reliable, etc.

Unlike classical engineering fields, like civil and mechanical engineering, which have been around for centuries, software engineering is really in its infancy. The term software engineering itself was coined in the late 1960s. Although the word engineering connotes that we might know a lot, I contend that we actually know a little. If we knew a lot, we probably wouldn't be having software disasters (small and large scale) like we do now. If we knew a lot, we would have tried and true formulas, perhaps mathematically provable ones, to test concepts and dictate how we do our work. But we don't have that -- we do know we are grounded on a science, but we are still developing the actual engineering part. We are still learning and practicing how to build reliable software, we are still learning how to measure if we did something right or wrong, not just at the end of the project, but as the project is going along. We do not have predictive models like our classical colleagues that tell us whether we are right or wrong -- software is abstract and getting it right is really challenging. Not to mention, "right" in the eyes of our stakeholders (management, customers, etc...) changes over time and somehow we have to react to that makes it even harder.

Some would argue that because we don't have elegant (some might say funky) equations, laws, and models, software engineering is easy. The fact that anyone can sit down and write a fairly functional program in Excel further lends to that impression. However, I claim that because we don't have predictive models, because we don't have plug-and-chug equations, that makes our job all the harder! We have to be aware of everything that's happening (hundreds, maybe thousands of loosely-connected variables) and understand it well enough to make the right decisions to make sure we get to the end result we want, given all the constraints that are put on us by customers, management, technical limitations, and staff.

Not only do we not know a lot compared to our classical counterparts, what we do know changes by the day. Yes, there are some principles that stand firm, but if you think about how much software engineering has changed in the last 30 years, we're constantly updating our practice as we learn more. For example, structured analysis and design was the de facto standard for a long time, then object-oriented analysis and design came around and unseated it. It's only a matter of time before another paradigm shift arises where the next way of thinking resolves the shortcomings of object-oriented thinking and presents a new set of issues to solve. Compare this with our classical counterparts -- I don't see the laws of physics or chemistry changing on them anytime soon :)

In addition to building software systems, software engineering is concerned with modifying software systems. Once civil engineers finish building a structure, cut the ribbon, they are finished. Once we build software, it's only the beginning of a long lifecyle of modification and maintenance. In my experience, it's easy to build something from scratch -- you have a blank canvas to work with. The hard part comes when you have to modify something in place, change it to do something new, without breaking what already existed. And you already know how ugly the pre-existing code and documentation really is...

As uncertain as it sounds, it is pretty exciting though -- and I'm glad that we're able to be a part of (and hopefully contribute to) a field that is growing and changing so much within our careers.

Postscript: I very much respect my classical engineering counterparts. What they do is not easy either -- thermodynamics still confuses the daylights out of me. What we do share though is engineering itself, whose fundamental purpose is to apply our knowledge of science and the humanities to improve the human condition. Idealistic, I know, but I'd like to think it's true.

obsession with spelling

I was rather surprised to see the National Spelling Bee televised in prime-time this year. Growing up, the National Spelling Bee barely made an appearance in the newspaper, let alone television. Just today, washingtonpost.com (free registration required) carried three articles above the fold about the bee: Prime-Time Pressure for Top Spellers, 13-Year-Old N.J. Girl Wins Spelling Bee, and Online Gamblers Get Behind Spelling Bee. I guess the spelling bee has come a long way.

My nearly two-decade-long obsession with spelling started, albeit unhealthily, in the fifth grade when I lost the elementary school spelling bee -- in front of the entire school in an assembly. The word: ricotta. I grew up in a rice-based household, so I had no idea what ricotta was, even after asking the moderator for the definition (it's a what kind of cheese?!) and to repeat the pronunciation twice. It's not one of those words that come up in casual reading either. At the time, it only had one pronunciation, ri-'ka-ta. Nowadays, it has two: ri-'ka-ta and ri-'ko-ta (a more accurate Italian pronunciation). Either way, I generally don't eat it (although I have no issues with the taste of it per se).

Nowadays, the obsession manifests itself with me exerting independence from automated spell checkers, bleeding red ink on the occasional documents I happen to edit, and picking out typos from major publications, and even sometimes writing the editors to point it out. Yes, this includes you, washingtonpost.com. One can only imagine how much it burns me up when I see certain mistakes on semi-public works (signs, writing on the Web, and documents in the workplace). Examples: using an apostrophe ('s) to pluralize a noun, affect/effect, alot/a lot, to/too/two, their/there, it's/its, site/sight, assure/ensure/insure, principal/principle, and especially here in DC, capital/capitol, just to name a few. I know not everything has to be perfect, but if one is going for credibility, it's totally shot when there is a misspelling in six-inch high letters.

This is just spelling. Think of what goes on in my head when grammar and typography get put into the mix. I once e-mailed the editor of the science section in a major newspaper about how carbon dioxide is denoted as CO₂ (letter O), not C0₂ (numeral 0), in their article (originally in print, republished on the Web) about global warming. It never got corrected.

Pop quiz: What's the difference (in usage) between a hyphen (-), an en-dash (–), and an em-dash (— or --)? Anybody?

If you're wondering what happened to the girl who beat me in the elementary school spelling bee, she's now a folk/jazz/bluegrass singer touring the country. She might have the better end of the bargain :)

visual c++ 2005 and openGL

For my non-technical audience, scroll down and pretend this entry isn't here :)

I was trying to set up Visual C++ 2005 for OpenGL programming and I found absolutely nothing on the Web for 2005, so I'm publishing this quick and dirty guide to explain how to set up Visual C++ 2005 for basic OpenGL and Open GL Utility Toolkit (GLUT) programming. GLUT allows for a platform independent means of creating windows and registering callback functions to handle events. This allows one to run OpenGL-based programs without having to integrate Win32, MFC, or Windows Forms API calls (useful if one wants to test a concept without having to write all the Windows calls).

Download and Install GLUT for Win32
Windows comes with an Microsoft implementation of OpenGL, but does not come with a GLUT implementation. Nate Robins ported Mark Kilgard's original GLUT implementation to the Windows platform. Download the latest version of the binary, 3.7.6 at the time of this writing, from Nate Robins's GLUT for Win32 page.

The GLUT package comes with glut.h, glut.lib, and glut32.dll. Unzip these files and copy them into their proper respective locations, listed below.

glut.h → C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\Include\gl

glut32.lib → C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\Lib

glut32.dll → C:\WINDOWS\system32


Setting Up a Project in Visual Studio for OpenGL and GLUT
1. Launch Microsoft Visual Studio, start a new project (File → New → Project).

2. For the project type, select Visual C++ → Win32 → Win32 Console Application. Select the directory to save the project, preferably somewhere on C: drive and give the project an appropriate name.

3. Include the necessary headers in the primary source file (for compilation):

     #include "windows.h"
     #include <GL/gl.h>
     #include <GL/glu.h>
     #include <GL/glut.h>

4. Add the necessary libraries in the project settings Project → Project Name Properties, Configuration Properties → Linker → Input → Additional Dependencies (for linking):

     opengl32.lib
     glu32.lib
     glut32.lib

5. If the main function signature is defined as the former, replace it with the latter:

     int _tmain(int argc, _TCHAR* argv[])
     int main(int argc, char* argv[])