20061010 Tuesday October 10, 2006

Salute to our Troops


Salute to our Troops
Originally uploaded by Berin Loritsch.
I've never been in the armed forces, but living in the DC area I am surrounded by military men. I have the utmost respect for those who are willing to do all they can for our freedom. I'm privileged to live in this country, particularly for my freedom of worship.

I'm not one to glorify war, or to romanticize the darker periods of history. Still, it takes a certain quality of person to endure the hell known as war. It's to these brave men and women that I solute.

I know there are a lot of folks who disapprove of the US actions abroad, particularly in the middle east. I'm not one to argue for or against those actions. I'm just a voice saying, "Remember the fallen, and what they died for". They didn't die for oil, or monetary gains. They aren't mercenaries. They died for freedom, for the honor of their country. (2006-10-10 09:41:57.0) Permalink Trackback Comments [0]


It's Amazing What a Good Developer Will Do


Pathway to the Sky
Originally uploaded by Berin Loritsch.
Development is much easier now that I have a good developing agent. I'm using Kodak XTol now, and it is a world of difference better than Ilfosol S. First, Ilfosol S is a very low contrast developer and XTol is a much higher contrast developer. XTol is more flexible, because it is also a compensating developer, so with longer and more dilute development times I can have lower contrast if I need it. The quality of the image and the smoothness of the grain is what sets XTol apart. I even like it better than Perceptol. (2006-10-10 09:30:00.0) Permalink Trackback Comments [0]


Adding Routes to the Framework

It wasn‘t hard adding routes to the framework, and of course I followed the Ruby on Rails lead. The goal is to avoid having to write a whole bunch of redundant code just because. I created “Route“ objects which took care of matching URLs and populating the Request object. Each Route object is initialized with a String representation of the URL fragment it responds to and an optional Map of default request attributes. For example, you can create a Route that responds to the root of the context “/“ and pass in default request attributes to specify the controller and action. Alternatively, you can have parts of the URL match a named attribute. For example the common url spec “/{controller}/{action}“ will match the browser provided URL “/user/login”, setting up the controller to be the UserController class (see my previous post) and the action to be the login() method. It‘s a much more flexible API, and it actually produces cleaner code.

The next part of the agenda was to set up the interceptor filters. The controller can be set up so that certain methods are called before or after other methods. While the traditional Ruby implementation allowed you to do all kinds of fun things with the parameters, Java just isn‘t as flexible. As a result I added several methods such as beforeFilter(filterName), beforeFilterOnlyFor(filterName, actionNames...), beforeFilterExceptFor(filterName, actionNames...) and the “afterFilter“ equivalents. The Filters also specify a specific interface with methods aptly named “before“ and “after“. The framework includes a default implementation that uses reflection to call the filter methods to satisfy the beforeFilter and afterFilter variants. It keeps the code very clean.

Next on my agenda is to add the beforeAndAfter filter methods that accept the traditional Filter interface. I like the flexibility of the Ruby implementation where there is no explicit interface. As long as an object has a “before()“ method and an “after()“ method, it can be used as a filter. I just may continue using that, and keep the Filter interface hidden. Then I want to set up the “urlFor” methods. That will handle the largest portion of useful features in the ActionPack.

(2006-10-10 09:14:04.0) Permalink Trackback Comments [0]


20061007 Saturday October 07, 2006

ActionPack for Java

I know I haven‘t posted anything for a long time, but when you are working in downtown DC and the security measures are so draconian you don‘t have any access to the internet it makes it more difficult to keep the blog updated. So, I‘m on another J2EE project and because of the same draconian security measures I have to reinvent the wheel for most things. I can‘t even install a proper JDK! I‘m just glad Eclipse has a compiler built in. Since I have to reinvent the wheel, I might as well do it the way I wanted.

I really like the way program logic is done in Ruby on Rails, and there is no technical reason why I can‘t do that for Java. In fact, the Java Servlet specification makes it fairly easy. There are two methods of dealing with requests. You can use a Filter and FilterChain or you can use a RequestDispatcher. They take care of different aspects. The Filter allows you to inject your business logic and manipulate the HttpServletRequest and HttpServletResponse objects rather well. The RequestDispatcher allows you to use the results of another servlet/JSP/file in your response without changing the URL.

I took the tack of building my Controller so that it operated in the Filter space. I invoked the controller using reflection, which worked like a charm. I even built in logic to return a 404 response if a requested action wasn‘t implemented. I also really liked how Rails controllers fell through to rhtml files if they didn‘t send a response right then. I used the RequestDispatcher to handle that logic. In my work downtown, I figured it was much easier to fall through to a JSP than anything more elaborate. Truth be told, my Controller infrastructure is rather agnostic about what really implements the response. It could be JSPs, a Cocoon instance, etc.

In fact it would make a wonderful addition to Cocoon to tame the wild beast. In essence, the Controller framework would live as a filter that works before Cocoon gets the request and Cocoon merely responds with a pipeline. No need for CForms or other heavy work.

The true power of the Rails integration has to do with integrating the ActiveRecord and ActionPack modules. I wish I had the time to really flesh that out downtown, but I simply got myself to a point where I can move forward and get the job done. I believe I‘ll start fleshing that out — still living at a Filter layer for most things. That gives us the best of all worlds. We can use whatever we want to handle the display aspects and be as simple as merely forwarding a file or as complex as a full XML pipeline.

All this coming to a repository near you….

(2006-10-07 10:20:40.0) Permalink Trackback Comments [3]


20060901 Friday September 01, 2006

I've got to get a handle on developing film

p57-s2-delta-400-0004
I developed my roll of film where I was experimenting with the zone system. Now I had already started the roll pulling the film to ISO 250 so I could use Perceptol on it. Unfortunately, I didn‘t quite have enough Perceptol for even 1+1 dilution. It ended up being about 1+2, and even though I extended the development time it just wasn‘t enough. There were no strong blacks or whites. Admittedly in the evening there wasn‘t a lot of high contrast light. I still didn‘t get what I was looking for and most of the pictures ended up looking rather gray like the one posted with this article.

Also quite anoying are the streaks from the developer getting caught up in the sprockets. Before I got them because I agitated too vigorously. Now I‘m not agitating enough. I‘ve gotten some good tips, and I‘ll be changing developers soon. I need to get a good routine down that is repeatable and high quality.

(2006-09-01 17:35:54.0) Permalink Trackback


20060830 Wednesday August 30, 2006

Zone System and Exposure Meters

Here‘s the basic premise of the zone system. Your tonal range is separated by 10 stops ranging from pure white to pure black in a printed picture . By performing a set of test shots at the rated speed of the film, you can more easily visualize what the tones look like. Most important is the reference zone, Zone V. Zone V is what your exposure meters are calibrated to reproduce. That means if you point the meter in shadows, the shadows will be exposed to render medium gray. As a result the highlights will likely fall outside the usable range of the film.

Ah, but here is where things fall into place. The usable range of film would be zones II through IX, with zones III through VIII having full detail. You always want the darkest part of the picture where you want full detail to be in zone III. Then using your spot meter you can find out where other parts of the picture happen to fall. To expose the shadow detail in zone III, you spot meter the shadow and drop the suggested exposure two stops. It‘s not a hard and fast rule, but it provides you with better tools to interpret what your meter is telling you.

Of course it still works with color film, although it‘s easiest to think of tones in terms of black and white. The bottom line is that once you‘ve calibrated your system to middle gray, you have a wonderful tool at your disposal. And there‘s the rub. How do you calibrate your exposure time without a densitometer? Most of us enthusiasts don‘t have the tools at our disposal to perform the tests to make the system really work for us. There is a way to do it using an enlarger and prints, but if your workflow stops with a scanner like me, what do you do? I‘ll have to figure something out. I may have to buy a used densitometer to make it worth my while.

(2006-08-30 22:28:22.0) Permalink Trackback


Rapid Evaluation Madness

I‘ve wrapped up the last project using Ruby and ActiveRecord to extract big complex records about people and turn them into Wiki pages. Thanks to WikiMedia‘s XML import ../../../page/bloritsch/format__the_process_wasn__8216.css;t too difficult. While I learned more about Wiki markup than I really cared to, the real story with that was how to pull 12,688 records that each had no less than 16 associated sets of records and attachments using ActiveRecord and Microsoft SQL Server. Once I got the connection working (using ADO) I quickly ran into a problem of scale. The way ActiveRecord works is that it uses lazy initialization to build all the objects as you need them. With a set of 12,688 complex objects (and associated attachments) I would run out of memory after processing around 1,000 records — and I have 2GB on my machine.

The way around the high volume of data problem is actually pretty simple. ActiveRecord really wasn‘t designed for this type of problem, so I had to work around a couple of limitations. First, I can‘t have 12,688 complex objects in memory at the same time (some of those attachments were about 25MB and that data was loaded in as well). I can have 12,688 simple IDs in an array. So I used a simple query to get the IDs and then looped through looking up each person by itself. Worked like a charm.

Now I‘m on a rapid application evaluation/development project to incorporate a survey management tool into the government infrastructure. I have to slog through some documentation before I get down and dirty. In the process of setting up the server I ran into a particularly ugly snag. The SELinux extensions prevent the MySQL server RPMS from running. I‘ve seen a couple links, but I don‘t have the authority to download the patches I need. This is quite frustrating, but as the high level architecture documentation takes precidence I have to push it off a bit. My due date is tomorrow. Yes, government hoops are fun. You spend a lot of time creating paper for people to skim through and never look at again. Such is life as a contractor.

(2006-08-30 19:27:23.0) Permalink Trackback


I know I haven't posted anything new lately....

Much has happened and I am wildly busy. I have a new office in Washington D.C. for a short term contract (2-3 months). I have bought and devoured some Ansel Adams technique books. Man, the Zone system makes a whole lot more sense now. Not to mention I really want to buy a view camera too. I have many comments to post later when I have a bit more time.

(2006-08-30 18:06:48.0) Permalink Trackback


20060724 Monday July 24, 2006

New Old Camera


New Old Camera
Originally uploaded by Berin Loritsch.
I bought a Super Ricohflex, which is an older Twin Lens Reflex (TLR) camera. The top lens is for focusing and the bottom lens is for picture taking. I was expecting a more hefty camera, but this one is fairly light. In fact I was very surprised at its size. As you can see by the picture the TLR is shorter than a Wacom tablet pen.

The Super Ricohflex has a limited set of applications it can be used for, and it likes doing things a little differently. The lens is a wide angle 80mm lens, and to be different they marked it as an 8cm lens. It has seven apertures marked in full stops ranging from f/3.5 to f/16. The most limiting part of the camera is the range of shutter times. It has six times marked: 1/200, 1/100, 1/50, 1/25, 1/10, and B (bulb). I have to have the right lighting conditions if I want to use the smaller apertures, which is not something that will take place in daylight. Since I like to use Provia slide film (a daylight balanced film), using it indoors will likely have a strong yellow or orange cast to it.

I'll report on picture quality when I get the pictures back tonight. It is a medium format camera, and uses 120 format film (6cm wide, 120mm long). It will fit 12 square pictures on the film.

While the controls do require some getting used to, particularly for someone spoiled by SLR cameras with all sorts of automatic gadgetry, it's really not that difficult to use. To focus, you pop up a hood on the top and look down. Because the picture is reflected up to you, your left to right directions on the viewfinder are reversed. That said, the hood also has a magnifying glass to assist with critical focus. Once you are done with the focusing, you can look down on the side of the upper lens to see how much depth of field you have. All in all, you can't complain about something as simple as this camera. (2006-07-24 07:22:42.0) Permalink Trackback Comments [2]


20060722 Saturday July 22, 2006

Feedback, It's What's for Dinner

I may be an odd fellow. As I learn something new, I always want to know its origins. Where did it come from and how does it make our lives better. As part of this natural pull, I recently bought a 50 year old Twin Lens Reflex (TLR) camera. It was my cheapest option to enter the world of medium format photography, which promises better resolution and more incredible pictures. I haven‘t gotten the pictures back from the developer yet, so I can‘t say if the claims are true for this camera. However, I‘ve made a few observations.

As cameras have progressed, we have more and more feedback available to us. In the beginning, cameras were made without meters and you had to go by the “Sunny 16” rule. Without boring you with details, the sunny 16 rule is a guide to base your exposure on. Many photographers still swear by it and won‘t bother with modern gadgetry. But as cameras evolved, and the bikini was introduced (the biggest boon to camera sales in history), more and more cameras came equipped with exposure meters. Now you had visual feedback that would tell you what you should already know (the Sunny 16 rule). Only thing is that meters could get fooled. They judge how bright the light is by comparing the average intensity with a medium gray (18% to be exact). If the picture had too much white or black, the meter would give you erroneous feedback. Which is part of the reason some photographers carry around a callibrated gray card with them.

Things progressed and we also got feedback on whether we were in focus or not (within a certain margin of error of course, we are dealing with machines). Now in the digital age, we have the ultimate feedback: the captured picture. More and more gadgetry thrown at the problem of how do we make beautiful pictures? The gadgets can‘t make beautiful pictures, but they can offer possible reasons why it didn‘t come out like you may have wanted. And that‘s the topic for today: feedback.

I have to say, with a good feedback system in a framework or application it is much easier to diagnose what might be happening. I‘ve worked on quite a few systems with feedback that ranged from console messages to live monitoring of a running system. In each system the feedback you got could point you in the wrong direction. It could send you on a wild goose chase. That can be very frustrating, particularly when you have people wanting some sort of answer and you are no closer to having one than you were when you started. The bottom line is that your feedback system can be fooled. Even if your feedback system includes the final result (such as a digital picture), it can‘t tell you why the technically correct picture didn‘t impress you. It can‘t tell you if one composition is stronger than another. Some things are left to the person to answer.

So if your monitoring system can be fooled, how can you trust it? What do you do if you can‘t trust your instruments? Pilots have to answer that question. An airplane has very sophisticated instruments, and a skilled pilot can fly a plane successfully without looking through any of the windows. The pilot can also tell if an instrument is out of whack because the instruments have instruments and warning lights. In the event of a complete failure of the monitoring system, the pilot has to actually pilot the plane. They have to make decisions based on what they can see from the cockpit. With software, we might feel like we are flying the Wright brother‘s plane or you might feel like you are flying the most advanced stealth bomber. Either way, we need to know a certain amount of information at a glance.

The problem for us software engineers is deciding what instruments actually help. How can we tell what is going on in a running system? What is the most telling metric? Is it memory consumption? It might tell us if there is a memory leak somewhere. What about average time to process a request? Well that might only be useful in development. In my experience, the best metrics are the ones that have a definite cause and effect relationship. If the metric looks like X then I need to do Y to fix the system. If I have a compilation error, I need to fix the syntax of my program. If a unit test fails, I need to fix my program. If I get a NullPointerException, no wait you don‘t still get those do you? :)

Even when you have a set of clean and distinct cause and effect type of meters built into your system, things can still go haywire. It‘s at those times that you have to step back and pull from old-school sensibilities. I may not be old school in age, but I am in spirit. Of course you go down the list of things that could possibly be an issue. The amount of data, the amount of traffic, possible sequences of events. Eventually you have to go outside the realm of common issues. In a military institution, the computers in the control tower would all go down at the same time twice a day. It wasn‘t until an embedded programmer noticed the radar making a full sweep and frying all the electronics in its path at the exact same time the computers went down that they found out what the problem was. Yes, the answer can be that bazar.

I have four cameras now. A digital, two 35mm film cameras, and an old medium format camera. Of them all, I am most comfortable with my high end 35mm camera. It has just the sensors I need, and it is very accurate most of the time. Out of the several hundred pictures I have taken with it, only a small percentage have been not so great. I have a lot of trust in what it can do, and because of it I have less trust in my starter 35mm camera. In fact, I have less trust of my digital point and shoot camera. Most of its pictures are overexposed, and the focus isn‘t as sharp as I‘d like. I‘ve been told that my vintage medium format camera can give me better results, but until I have any kind of real feedback I won‘t know for sure. It does encourage you to think more about what you are doing before you do it.

At the end of the day, the one thing that helps to understand and diagnose issues more than anything else is to shorten the feedback time. Once you have a quick feedback, you can decide how helpful it is. The longer it takes to try/fail/diagnose the more frustrated you become. Sometimes going without a modern convenience can really improve the system. Sometimes you can retrofit the modern convenience into the older design. No matter how quick your feedback system is, if you can‘t trust what it tells you then it is useless. You have to know what can fool the system and how to compensate for it. With cameras it is relatively easy because everyone has the same basic answers regardless of whether they are using Canon, Nikon, Kodak, Rollei, or Hasselblad. The only differences have to do with what buttons you press, but not the type of adjustments you are making. Software is not nearly so simple. Many times the same symptom points to completely different issues based on whether you are using Microsoft, Oracle, or IBM. It‘s this disconnect that makes it difficult to build a stronger community of common issues and solutions. Remember that community is just a larger system that needs feedback too.

(2006-07-22 22:44:11.0) Permalink Trackback