Soft Arts

(NB: I originally posted this under the pen name of “Lee Morgan” in 2005).

A long time ago, long before I went to college, I worked as a dishwasher.

I must admit, for me, it was a dark time.

After several months of pearl diving, the sous chef, a great fellow named Bryan, offered me a position as a prep cook. “Dan,” he said, “I think that you’d make a great prep cook. You’re lazy.”

I was really hurt by his comment. I always worked hard and fast! How could he say something like that!?

He saw that I’d taken the bait. “Dan, what I mean is, you don’t have any tolerance for doing unnecessary work. You’re efficient. That’s what we need in prep cooks, because they have to do a lot of work in an eight hour shift. If you don’t learn how to save time, you won’t be done with your work when it’s time to go home.”

So they made me a prep cook. And I got buried. There really was a lot of work to do. And after about a month, Bryan started teaching me all of his tricks. After about four months, another prep cook told me that he’d been told in his review “you don’t have to be as good as Dan. Being *half* as good as Dan would be a good move for you.”

I didn’t know what to say. Bryan had been right. I work hard, and I despise inefficiency. And ultimately, it paid off for for me.

And the lessons that I learned slicing cases of produce and making ten gallon batches of soup and salad dressing paid off nicely when I finished college and moved into the software industry.

I fervently believe that it is completely worth everyone’s while to spend a lot of time getting your build environment set up and automated. When you are prototyping a new product, particularly a distributed one, building and deploying your product can take anywhere from several minutes to half an hour or more. Taking the time to automate your build can save you a huge amount of time and effort further down the line, particularly when you are troubleshooting and making frequent changes to your build.

When you are debugging code a long build and deployment process with lots of manual steps can derail your train of thought and cause you to make mistakes, forget what you were trying to do, or miss details you meant to watch out for when you finally got an opportunity to run your code.

This has been most apparent in servlet and midlet development, but it is also a huge factor in cluster and grid applications, particularly MIMD applications, where different nodes may be running different applications.

Arrgh. I have more to say about this, but it’s getting late. Time to sign off for now.

In the summer of 1994 I started a research assistantship at the Aerospace and Energetics Research Lab at the University of Washington. I joined a team working on something that Abe Hertzberg, who was the AERL director at the time, whimsically referred to as the Smogmobile. The car was steam powered, but used boiling nitrogen (highly purified air) instead on water.

Abe was motivated to try this approach because he had realized that battery powered electric cars, which were a popular idea at the time, weren’t going to scale effectively. By the time they were being used in the same numbers that internal combustion engine-powered vehicles were, disposal of the cars’ used lead-acid batteries would pose a formidable environmental problem.

This is certainly not a new conundrum - when the automobile was first introduced to London it was considered to be a source of great relief. The city streets at that time were subjected to an estimated 100 tons of horse manure per day due to the culture’s heavy dependence on horse drawn carriages.

Other problems, such as disposable diapers, have followed a similar pattern.

After years of seeing the same patterns I eventually formulated what I used to call “Pasco’s Law,” and will now formalize as “Pasco’s Law of Universal Adoption*” as I haven’t seen it articulated anywhere else yet:

        Everything has a negative environmental impact when enough people start using it

Looking at it another way, this could in someways be considered as an environmental application of the Second Law of Thermodynamics.

As a consequence, when presented with alternative energy ideas, my tendency is to look at the impact of the the approach, no matter how small, and consider the impact of it’s adoption on a global scale. I think that this is the only sensible rubric for picking a new energy source - you have to speculate on the scalability of the solutions in order to make a sensible comparison of them.

That being said, I think that there are some interesting ideas being tossed around and I’m interested in finding out more and being involved in the process of finding out what our future will be.

*If I’m lucky, I’ll have other ones before I retire.

Technorati Tags:
environment, alternative energy

If you haven’t caught an episode before, check it out. Hysterical.

I could not have said this better myself.

I’ve been working with the iPhone SDK for about a week now, and I have to say that with only a few noticeable exceptions, the experience has been the best handheld software development experience I’ve had in my life.

First and foremost, you get to develop your code on a Mac. After years of having to keep a Windows install around to do BlackBerry development, this is a freaking godsend.

Beyond that, the language you actually develop in is Objective C, which is now officially my programming language of choice. Objective C has all of the best things I love about C, Ruby, and Java.

The Coverflow Project

We have several iPhone/OS X projects going on at Brain Murmurs, including native clients for Mentat. We recently decided that we needed Coverflow functionality as a part of our toolset. This is easily accessible using the toolchain in a private class, but it isn’t available at the present time in the SDK.

David Brown and I decided that the best thing to do was roll our own implementation. I think that the odds are good that Apple will make a canned version of their standard view available in a future SDK release, but in the short term, developing our own implementation would force us to get up to speed on a lot of iPhone related technologies.

Unfortunately, because the contents of the SDK are guarded by a Non-Disclosure Agreement, I am not at liberty to say what APIs I was able to use to make this happen. I can say that it was fun, and cool, and that Apple has a lot of powerful technologies available to developers that are ready to roll up their sleeves and dig into it.

On the other hand, I don’t think that there is a legal problem with showing some screenshots of an iPhone showing pictures of my unlovely countenance.

I needed some photos for the project, so I just popped off several shots with my iSight and Photobooth at my office (hat courtesy of my son, Isaac). The results appear below:

Now, the basic implementation is there, but I’m obviously missing a few features like a reflection layer. I’ll probably add those in sometime tonight if I get the chance, but the main technical goals we had have been achieved.

UPDATE:
I’d initially tried to get the demo to run in landscape, but without success. I was eventually able to get landscape mode working thanks to some much appreciated help from Guy English of Rogue Amoeba (Thank you!).

I’d be happy to discuss the technical details involved to anyone else in the iPhone development program. Just get in touch with me using the contact info on the side bar.

-Daniel

Technorati Tags:
apple, GTD, iphone development, iphone sdk, Mentat, user interface design