If you’re like me, you spend a lot of time jumping from project to project in
a Linux shell. I find that I have to switch back and forth between
directories. The bash shell has commands to maintain a
directories. I’ve written some functions that use these utilities to make
directory navigation easier. I’ve found these functions very useful, and
perhaps you will too. Let’s see them in action first with some examples, and
then look at the code:
In yesterday’s article about Google Buzz, I guessed that “the problem was that
the population for whom the system was designed wasn’t necessarily the only
population actually using the system.” I gave Google the benefit of the doubt:
I am certain Google tested their application thoroughly. They’ve been known
to do extensive usability tests for the seemingly tiniest of changes to their
web site. But even the most well-implemented tests are incomplete if they’re
not performed on a statistically representative sample of the audience.
But today, the BBC reported that Google has admitted that they only tested Buzz internally, and
bypassed their regular rigorous testing procedures — possibly in an attempt
to get it out the door as soon as possible. I’ll let the pundits decide if it
did more harm than good to the firm, but it’s a warning to other software
developers: skipping testing can lead to embarrassing failures.
In the first few days after the release of Google Buzz many people (including myself) criticized
Google for exposing their users’ private information. This was a couple of weeks after Apple got a lot flak
for their unfortunately-named iPad, and the same week that we heard
reports of a woman who broke up with her
boyfriend after finding some suggestive text messages on his cell phone -
messages that came pre-loaded on the phone. I think that all these cases were
not caused by a lack testing, but by testing the wrong audience. Let’s
examine these three cases and see what we can learn from them:
I came across some comments made about an open source program that I had
written in perl. The user was complaining about how he couldn’t get it to
install. The reason was that the program relies on other modules from the
archive of open source perl software known as CPAN (Comprehensive Perl Archive Network), and one of them failed to install.
I had this dilemma a few days ago: I had taken almost 4,000 pictures during a
vacation 12 months ago. The vacation was in Asia (two continents over), and
the time on my camera was wrong. I was importing the pictures into Adobe’s
Lightroom, and wanted them to have the correct time just in case I wanted to
know when in the day certain pictures were taken. I thought of looking for
pictures taken during sunset, and then using solar calendars to figure out
when sunset was at a certain landmark on a certain day of the year. But then I
had a better idea:
In a previous article we looked at how lenses work. We learned about the focal
length. Today we’ll focus on camera lenses and what the term f-stop means.
The term f-stop is a ratio. It has no dimensions. You don’t measure an
f-stop in meters, inches, kilograms or even degrees Fahrenheit. An f-stop is
the ratio of two distances. It’s the ratio of the focal length of a lens to
its diameter. In figure 1, the f-stop is f/d _where _f is the focal length
and _d _is the diameter.
One of my favorite activities in spring, summer and even early autumn is
sitting outdoors by a campfire. For safety reasons, outside my home I can’t
make a campfire on the ground, so I use a standalone fire pit. The older
children, as well as my nephews and nieces like learning how to start a
campfire without matches. I usually use metal and flint.
When I first started dabbling in woodworking at the age of 15, the only tool I
used to cut wood was an old, rusted woodsaw. Every cut would start straight
and true, but as I’d push the saw deeper into the wood, it would buckle and
warp, my arms would get tired, and the cut would stray from the line. A few
years ago I learned about pull saws and once I started using them I have stuck
with pull saws for all my manual wood-cutting tasks.
As of this past weekend it’s been fifteen years since I started my career as a
software developer. With the exception of a few months here and there, I’ve
spent all these years working on Linux or Unix-like operating systems. I’ve
noticed that despite the wide variety of tools and applications I have used
and continue to use, some key skills are always in demand in this field. One
of these is mastery of a text editor.
I’m interested in tinkering with High Dynamic Range photography,
but before I get Photomatix, the software that’s recommended most often, I thought I’d try out a technique that’s a
very crude approximation of HDR. It involves taking one image that’s
underexposed, and one that’s overexposed, and merging them in Photoshop. The
technique is described in this article at luminous-landscape.com. Essentially, you
put the underexposed image in a layer above the overexposed one. Create a
layer mask on the darker layer, and copy the brighter image to the layer mask.
Apply a Gaussian blur to the layer mask, and you have your blended image.