Recently my Tai Chi instructor asked me to take pictures of my class for the school's web site. His digital camera has some shutter lag which makes photographing people in motion a hit or miss proposition. So, I took a hundred or more shots, knowing that I only needed a couple of good shoots.
As I was doing this I was reminded of my old days learning to shoot black and white photos, (which happened long before there was such a thing as digital photography) and I was struck by the similarities.
I learned photography from an old friend, long since passed away named Christopher Resnik. Chris taught photography from the ground up. We bought 100 foot rolls of 35mm film and made our own film cartridges. Cameras back then were fully manual and Chris wouldn't even let us use a light meter...preferring to train our eyes to read the light and determine the exposure. To this day I can look around and know that such and such a day requires an F8, 1/250 second exposure with 400 ASA film. Today most people probably don't even know what those terms mean.
Since we bought film in bulk and did all of our own darkroom work it was quite inexpensive and so we shoot a lot. Chris used to say that is you got one or two good shots out of a 36 exposure roll you were doing well. When we found an interesting subject we'd take a number of shots of us...from various angles, with various exposures and with various perspectives. We might take whole roll of film on a single subject. Taking 100 Tai Chi shots reminded me of that.
Back in the days before digital cameras a roll of color film might cost $3-$5 to buy and then perhaps $10-$12 to process. With that price model you were careful how you spent your photos and a roll of film might sit in the camera for months or a year.
We've now come full circle in a way. Photos are basically free, especially since many people never make prints but instead view their photos on a digital picture frame or online via Snapfish or KodakGallery.
A missing element for most digital photographers however is the culling process. Back in the day, after processing a roll we'd stay in the darkroom evaluating our photos and would throw out 90% of them. We shot 36 pictures of that flower so that we could find the best one, but then we left the other 35 shots on the darkroom floor. Today most digital photographers take the 36 photos, post them all to Snapfish and go on their way. After a few months they have 100s or 1000s of pictures, most of which are awful and have no idea where the dozen or so gems are.
I'm sure there's a metaphor in here for the pace of modern life but it escapes me. I do however like when life comes full circle.
For my own pictures, (and I have a 3 year son so I take a lot of pictures), I've developed a culling process. When I plug my digital camera or my IPhone into the computer it creates a new directory where all the pictures go. I then create a subdirectory called so_so_shots. I immediately look at each picture and if it isn't great it gets moved to the so_so_shots directory. Since I'm just moving them rather than deleting them I can be quick and ruthless in the decision. This lets me easily manage a much smaller set of much better pictures.
Saturday, January 24, 2009
Tuesday, January 20, 2009
Why I don't want a Kindle yet
The Kindle is Amazon's book reader and its an amazing device, but one that I don't want yet.
The Kindle has an astonishingly readable screen (using electronic ink rather than a display tube or LCD). This means that once its painted a page there is no electricity needed to maintain the image so its always on, and the battery life is very good.
So why don't I want one of these cool devices that would let me take all/most of my books with me? Because Amazon wants me to pay for all of those books again.
As I look at my book shelves I see hundreds of books, most which were purchased from Amazon. They know this. And yet, when I buy a Kindle I have to turn around and repurchase all of those books again if I want to put them on the device. And I have to pay what amounts to full price.
When you buy a Kindle Amazon should give you and electronic copy of all they books you've purchased from them, say in the last couple of years. Until they do something like that the advertising line that you can take all your books with you simply isn't meaningful.
The Kindle has an astonishingly readable screen (using electronic ink rather than a display tube or LCD). This means that once its painted a page there is no electricity needed to maintain the image so its always on, and the battery life is very good.
So why don't I want one of these cool devices that would let me take all/most of my books with me? Because Amazon wants me to pay for all of those books again.
As I look at my book shelves I see hundreds of books, most which were purchased from Amazon. They know this. And yet, when I buy a Kindle I have to turn around and repurchase all of those books again if I want to put them on the device. And I have to pay what amounts to full price.
When you buy a Kindle Amazon should give you and electronic copy of all they books you've purchased from them, say in the last couple of years. Until they do something like that the advertising line that you can take all your books with you simply isn't meaningful.
Thursday, January 8, 2009
A Tutorial for Adding Groovy to a Java Project
I program primarily in Java and have done so for close to ten years. Before that I programed in C++, C, Pascal, Prolog (yes, I had a real job using Prolog!), and even Fortran and assembler. So I know that languages wax and wane in their importance. So, I decided to add a class or two written in the Groovy language to one of my side projects.
For those not familiar with Groovy its one of a surprisingly large group of languages whose source code is different from Java, and yet runs on the Java runtime. Java source code is compiled into Java bytecode which is executed by the Java Virtual Machine (JVM) on your computer. Groovy source code is also compiled into Java bytecode which then runs on the very same JVM. This allows the two languages to interoperate in interesting ways.
As a starting point for this tutorial I assume you have an existing Java based project, use Ant to build your system and use Eclipse as your development environment. None of that is required for Groovy but it is a fairly standard setup and its what I use, both at home and at work.
The steps are basically
a) download and install the Groovy GDK
b) add a how-to-compile-groovy task to your Ant build.xml (the task is included in the GDK)
c) add the groovy-all.jar file to your library path
d) add the groovy-plugin to your Eclipse project
e) enable groovy-nature in your Eclipse project
f) write a Groovy class and use it.
Overall this should take no more than twenty minutes or so. One of the really cool things is that once you have a Groovy class you can use it from your Java classes just like any other class...your Java code has no idea its using a class written in Groovy.
Now lets look at the steps listed above in cookbook manner.
a) go to http://groovy.codehaus.org/Download and select the latest stable release (currently 1.5.7). Click on the download link and follow the very simple instructions.
b) add the following task to your build.xml to define how to compile groovy code:You then need to actually compile your groovy source files. A standard build.xml will have a compile target that invokes the javac task compile your java source files. I changed that so the my compile task was empty but depended on java_compile and groovy_compile targets. See the full definition of the groovyc task options here: http://groovy.codehaus.org/The+groovyc+Ant+Task
c) the Groovy GDK includes a groovy-1.5.7-all.jar file. Add this to your library and execute paths
d) From Eclipse, select Help, Software Updates, Find and Install, Search for new features to install, next.Now select New Remote Site. Enter Groovy as the Name and http://dist.codehaus.org/groovy/distributions/update as the URL.Press Ok and you should find Groovy added to the list of Sites to include in search. Press Finish.It should find Groovy, check the features you want and press Next.Accept the license terms and press Finish. At this point the plugin will be downloaded and installed.
e) From Eclipse select your proejct, right click and select Groovy->Add Groovy Nature. Eclipse will now understand files with the .groovy extension.
f) Remember that any Java file is also a Groovy file, so if you want to start with baby steps just rename one of your java files to have a groovy extension. Eclipse and Ant will recognize it and compile it to bytecode and then allow you to use it.
You could then take another small step and remove most of the semi-colons, because Groovy doesn't require them.If your class has import statements from various java packages you can probably remove them as well since Groovy automatically imports them.
Clearly you then want to write a class that actually uses Groovy features but that's beyond the scope of HelloGroovyInAJavaProjectWorld.
Enjoy.
For those not familiar with Groovy its one of a surprisingly large group of languages whose source code is different from Java, and yet runs on the Java runtime. Java source code is compiled into Java bytecode which is executed by the Java Virtual Machine (JVM) on your computer. Groovy source code is also compiled into Java bytecode which then runs on the very same JVM. This allows the two languages to interoperate in interesting ways.
As a starting point for this tutorial I assume you have an existing Java based project, use Ant to build your system and use Eclipse as your development environment. None of that is required for Groovy but it is a fairly standard setup and its what I use, both at home and at work.
The steps are basically
a) download and install the Groovy GDK
b) add a how-to-compile-groovy task to your Ant build.xml (the task is included in the GDK)
c) add the groovy-all.jar file to your library path
d) add the groovy-plugin to your Eclipse project
e) enable groovy-nature in your Eclipse project
f) write a Groovy class and use it.
Overall this should take no more than twenty minutes or so. One of the really cool things is that once you have a Groovy class you can use it from your Java classes just like any other class...your Java code has no idea its using a class written in Groovy.
Now lets look at the steps listed above in cookbook manner.
a) go to http://groovy.codehaus.org/Download and select the latest stable release (currently 1.5.7). Click on the download link and follow the very simple instructions.
b) add the following task to your build.xml to define how to compile groovy code:
c) the Groovy GDK includes a groovy-1.5.7-all.jar file. Add this to your library and execute paths
d) From Eclipse, select Help, Software Updates, Find and Install, Search for new features to install, next.Now select New Remote Site. Enter Groovy as the Name and http://dist.codehaus.org/groovy/distributions/update as the URL.Press Ok and you should find Groovy added to the list of Sites to include in search. Press Finish.It should find Groovy, check the features you want and press Next.Accept the license terms and press Finish. At this point the plugin will be downloaded and installed.
e) From Eclipse select your proejct, right click and select Groovy->Add Groovy Nature. Eclipse will now understand files with the .groovy extension.
f) Remember that any Java file is also a Groovy file, so if you want to start with baby steps just rename one of your java files to have a groovy extension. Eclipse and Ant will recognize it and compile it to bytecode and then allow you to use it.
You could then take another small step and remove most of the semi-colons, because Groovy doesn't require them.If your class has import statements from various java packages you can probably remove them as well since Groovy automatically imports them.
Clearly you then want to write a class that actually uses Groovy features but that's beyond the scope of HelloGroovyInAJavaProjectWorld.
Enjoy.
Monday, January 5, 2009
Tai Chi, Software Design and simplicity
Its always interesting when different aspects of life intersect. In this case Tai Chi, Software Design and simplicity. One of the lessons I've been learning in my Tai Chi studies is the value of simplicity and minimalism. Most of the flaws in my technique end up being attempts to do to much. My motions tend to be too large and often too complex. Such large and complex motions are relatively easy to defeat.
In software as well there is the truism that the code you don't write doesn't contain any bugs. There are many possible refactorings that can increase the quality or robustness or performance of a program, but code that no longer exists takes no time to run, doesn't need to be learned and doesn't obscure the structure of a program.
The trick of course is that simplicity is hard. My Tai Chi Shifu (instructor) gives me simple instructions from which I somehow deduce complexity. Only after continued study am I sometimes able to get the flash of "oh, that's all I have to do?" as I see the simple and powerful move hiding inside my attempts.
Even though I know this to be the case I do not seem to be able apply to new moves I learn. There seems to be need to for the learning to be a process. The simple move doesn't seem to be obvious so I flounder about adding unnecessary nuances.
This makes more sense to me in software design, perhaps because I've been doing it for so long. In software I do have the ability to move fairly quickly to a simple design, and to spot the extraneous complexity in most designs. In software the simple code path usually seems to leap out of the spaghetti I often encounter.
One way of looking at this might be via the Dreyfus model of learning (see Pragmatic Programmers). The Dreyfus model describes five stages of skill:
Novice, Advanced Beginner, Competent, Proficient and Expert.
Novices need to be given a cookbook description of how to perform a task, while Experts simply do the task and might not even be able to describe how or why they are doing it. The inability to describe why can be a problem. I've had bosses ask me why I think design X is better than design Y. My answer that Design X "sings" or is "beautiful" while Design Y "feels" clunky does not tend to convince them.
I remember watching a documentary about an about-to-retire Cotton Inspector trying to teach his apprentice how to select the best cotton. The expert said to rub the cotton between your fingers and feel when it was "good". The apprentice had no idea what that meant but it was the best answer the expert could give him.
I think that most people stay in their comfort zone and thus stay within whatever skill level they've achieved. While I might claim to be in the expert group in software design I'm certainly no higher than advanced beginner or competent in Tai Chi. Hopefully this makes me a better instructor as I can relate to the students just starting to study Tai Chi.
Whether all of this eases my learning curve with Groovy or Scala (new computer languages) remains to be seen :-) It does however remind me of the quote by Blaise Pascal: "I have made this letter longer than usual because I lack the time to make it shorter".
In software as well there is the truism that the code you don't write doesn't contain any bugs. There are many possible refactorings that can increase the quality or robustness or performance of a program, but code that no longer exists takes no time to run, doesn't need to be learned and doesn't obscure the structure of a program.
The trick of course is that simplicity is hard. My Tai Chi Shifu (instructor) gives me simple instructions from which I somehow deduce complexity. Only after continued study am I sometimes able to get the flash of "oh, that's all I have to do?" as I see the simple and powerful move hiding inside my attempts.
Even though I know this to be the case I do not seem to be able apply to new moves I learn. There seems to be need to for the learning to be a process. The simple move doesn't seem to be obvious so I flounder about adding unnecessary nuances.
This makes more sense to me in software design, perhaps because I've been doing it for so long. In software I do have the ability to move fairly quickly to a simple design, and to spot the extraneous complexity in most designs. In software the simple code path usually seems to leap out of the spaghetti I often encounter.
One way of looking at this might be via the Dreyfus model of learning (see Pragmatic Programmers). The Dreyfus model describes five stages of skill:
Novice, Advanced Beginner, Competent, Proficient and Expert.
Novices need to be given a cookbook description of how to perform a task, while Experts simply do the task and might not even be able to describe how or why they are doing it. The inability to describe why can be a problem. I've had bosses ask me why I think design X is better than design Y. My answer that Design X "sings" or is "beautiful" while Design Y "feels" clunky does not tend to convince them.
I remember watching a documentary about an about-to-retire Cotton Inspector trying to teach his apprentice how to select the best cotton. The expert said to rub the cotton between your fingers and feel when it was "good". The apprentice had no idea what that meant but it was the best answer the expert could give him.
I think that most people stay in their comfort zone and thus stay within whatever skill level they've achieved. While I might claim to be in the expert group in software design I'm certainly no higher than advanced beginner or competent in Tai Chi. Hopefully this makes me a better instructor as I can relate to the students just starting to study Tai Chi.
Whether all of this eases my learning curve with Groovy or Scala (new computer languages) remains to be seen :-) It does however remind me of the quote by Blaise Pascal: "I have made this letter longer than usual because I lack the time to make it shorter".
Saturday, January 3, 2009
software haiku
I wrote this haiku a couple of years ago to describe the software I was working on and it seems pretty appropriate to Wabi Sabi. For non-software developers spaghetti is an adjective used to denigrate code whose logic seems to go in all directions at once with no hope of untangling it.
Code in Haste no Pattern
Spaghetti's not food for the brain
The mind recoils, I weep
Code in Haste no Pattern
Spaghetti's not food for the brain
The mind recoils, I weep
Subscribe to:
Posts (Atom)