Just a Thought...

Using JUnit 4 Theories to Test Contracts

Berin Loritsch — Tue, 09 Feb 2010 16:08:00 +0000

I’ve been putting off upgrading to JUnit 4 for a while. After all, just how much does it really buy you? It turns out, that JUnit 4 grants you a number of advantages that weren’t available with JUnit 3. One of those features is currently in an experimental phase: Theories. Theories let you specify a bunch of data points, which can be applied to each theory in your class. For example, if you want to test some boundary conditions on a class, you can make it happen easily like this:

@RunWith(Theories.class)
public class VerifyMyAlgorithm {
    @DataPoint
    public static int limLow = 0;

    @DataPoint
    public static int limHigh = 3000;

    @DataPoint
    public static int belowLimLow = limLow - limHigh;

    @DataPoint
    public static int aboveLimHigh = limHigh * 2;

    @DataPoint
    public static int median = (limHigh - limLow) / 2;

    @Theory
    public void verifyTwoParameters(int first, int second) {
        assertInRange(limLow, limHigh, MyMath.algorithm(first,second));
    }
}

I wanted to keep it simple just so you can get the basic idea. Essentially the @RunWith() annotation changes the basic behavior of your test class. It enables the use of the following annotations: @DataPoint, @DataPoints (more on this later), and @Theory. The data points you specified are collected and matched together so that each unique combination of datapoints is applied to the parameters in your theory. If your theory takes one parameter, the theory is run once per data point. If your theory takes two parameters it is run with every unique combination (15 times in this case).

But wait, there’s more! Sometimes we want to generate our datapoints with code. For example, we may need prime numbers up two four significant digits, or we need to initialize our data. In order to do that, we can use the @DataPoints annotation. The return type of your static method will be an array of datapoints. I could rewrite the example above like this:

@RunWith(Theories.class)
public class VerifyMyAlgorithm {
    @DataPoints
    public static int[] attemptLimits() {
        return new int[] {0,3000,-3000,6000,1500};
    }

    @Theory
    public void verifyTwoParameters(int first, int second) {
        assertInRange(limLow, limHigh, MyMath.algorithm(first,second));
    }
}

The DataPoints functionality in concert with the theories are the foundation of what is ncessary to automatically test the contracts of each service. I’ve thrown together a rudimentary class scanner that uses reflection to iterate over classes in the classpath to determine if they match the criteria for the service. For example, you can look at all classes that implement an interface, or extend a base class, or even have an annotation. From that list of classes we can test the contracts of the implementations. The nice aspect of this approach over creating a base test class and extend it manually for each implementation we write, is that it automatically finds the new implementations for you. I have yet to release the class scanner, but you can implement your own pretty well. Here is an example of how it would be used:

@RunWith(Theories.class)
public class EnforceLocakableContracts {
    @DataPoints
    public static Lockable[] collectImplementations() {
        Collection<Class<?>> klasses = new ClassCollector()
                .assignableTo(Locakable.class).recurse().collect();

       Lockable[] implementations = new Lockable[klasses.size()];
       int i = 0;
       for (Class<?> klass : klasses) {
           implementation[i] = klass.newInstance();
           i++;
       }

       return implementations;
    }

    @Theory
    public void lockShouldApplyToOneUser(Lockable lockable) {
        User one = TestSupport.createUser("one");
        User two = TestSupport.createUser("two");

        assertFalse(lockable.isLocked());

        lockable.acquireLock(one);

        assertFalse(lockable.canAccess(two);
    }

    @Theory
    public void lockableShouldBeAccessibleByLocker(Lockable lockable) {
        User one = TestSupport.createUser("test");

        assertFalse(lockable.isLocked());

        lockable.acquerLock(one);

        assertTrue(lockable.canAccess(one);
    }
}

So on and so forth. Just add a new Theory for each aspect of the implementing class you want to test. With this approach, testing implmentations of an interface is essentially future proofinf yourself against lazy programmers. There are some aspects that this approach doesn’t handle well just yet, such as complex setup for each object.

As of JUnit 4.7 there are a few problems, but they are not insurmountable:

You see one pass/fail per theory (not per implementation)
Failures do not show what implementation failed (fixed in the stacktraces provided by JUnit 4.8.1)
The first failure kills future tests. You may have errors in multiple implementations but you won’t be able to find it until you fix the first implementation.

The best thing is to upgrade to JUnit 4.8.1, which is still not available in Maven repositories yet. However, you can also use the System.out approach to find out what the last thing tested was.

There is a feature request for theories to allow you to run them discretely. I.e. each run gets displayed in your test report individually with the parameters supplied in the test name. That will address the shortcomings and make this an even better approach.

What's the purpose of the new iPad from Apple?

Berin Loritsch — Thu, 04 Feb 2010 00:08:00 +0000

No new technology has stirred up consternation like Apple’s new iPad introduced last month since the release of the iPhone. Apple purports that there is a market for something in between a laptop and an iPhone/iTouch. I agree with them on that point; however, the market may or may not jump on the iPad. Time will tell, of course.

In the keynote, Apple compares the iPad to something called a “NetBook”. NetBooks users can be divided into two major camps: people who want a cheap way to do Windows, and people who just want to browse the web and check email. The current NetBook market has offerings with Windows and Linux. They are tiny, have cramped keyboards, and really aren’t that remarkable. The iPad would be a great alternative for folks who don’t care about Windows. But I don’t think that’s the market, really.

Amazon has this thing called a Kindle, and Barnes and Noble has their version of a competing product. The Kindle is pretty cool, it is designed to make reading electronic books an enjoyable pastime. I see commuters with Kindles all the time. The Barnes and Noble device is a direct competitor, and because it doesn’t do a whole lot more, they will have a hard time taking over the Kindle. The good points about the Kindle include battery life an Apple device can only dream of, and a display that is easy on the eyes. I noticed Apple’s new book store app with books you can download. I think Apple is aiming for this market with a vengeance—doing for books what they did to the music industry.

The kindle uses something called “liquid paper” which consumes very little energy and is very easy on the eyes. It’s not backlit, and has a similar contrast to what you get with a regular paper book. The liquid paper only consumes energy when the screen has to change. The downside? Only 16 shades of gray. We haven’t had limitations like that since the Commodore 64. However, for reading it is a superior technology. Because of it, the Kindle can hold a charge for more than a week with normal use. That beats iPad’s 10 hour limit handedly. The very thing that makes viewing pictures and watching movies great on the iPad is what makes reading books for extended periods of time a strain on the eyes. The contrast is too great for comfortable reading.

That said, the iPad’s market is bigger than just replacing the Kindle. Think about a commuter. They hop on a bus, run to a train, and take more than an hour to get to work. Many commuters keep themselves entertained watching movies, playing games, texting, reading, studying, and sleeping. Often times on the train you are lucky if you can sit down. A laptop is just a non-starter in this arena. Smart phones, iPods/iTouches, Kindles, newspapers, and physical books rain supreme. They have an advantage that they can be held with one hand while people are staring at them. The other hand comes in to play if the user is texting or interacting with an app. I think the iPad will work very well in this market.

People need something unobtrusive to take notes with, yet is natural and intuitive to use. Even better would be the ability to have your reference material (Bible, text books, etc.) open so you can reference parts of it in your notes. It’s a matter of time before there’s a really good note taking app for that. The casual internet user will prefer to have something like the iPad than a desktop or laptop hooked up in a room. If you have FiOS, they give you a wireless router in the package. Why not have a couple devices that make good use of it?

Consider going to a meeting where you are presenting. Now, if your iPad has your slide deck you can really limit the amount of cruft you have to take with you. With the right adapter, you can display the slides on a projector or large screen. However, if you forget the connector and you have a small number of people you are briefing, you still have a big enough display to work with. You can at least see your notes while you are presenting.

There’s going to be a lot more uses for this thing that have yet to be imagined. The exciting thing is that Apple has thrown down the gauntlet and created a new platform… again. What people choose to do with it has yet to be seen. The early adopters will be the commuters, and their enthusiasm will infect others.

Apple does consumer devices like this very well. Sure it lacks the ability to run multiple applications at once. It’s not designed for that to begin with. It’s designed for the user who is going to do one thing at a time. Did you notice that the iPhone/iTouch/iPad doesn’t have a window based UI? Each app takes up the full screen. You are supposed to do only one task at a time.

Am I going to buy one when it comes out in March? Maybe not. I’m going to stick with my iTouch until the iPad starts to really define its market.

Naked Objects, Point - Counterpoint

Berin Loritsch — Fri, 18 Dec 2009 14:27:00 +0000

The Pragmatic Programmer folks have a new book out called Domain-Driven Design Using Naked Objects which caught my attention. The title caught my attention, and I figured the author was using Naked Objects in the same vein as Jamie Oliver as “The Naked Chef” (old series on Food Network). Essentially, the ingredients are used to their full potential, complimenting each other without the heavy use of spice. So I decided to do some research on where this came from. My suspicions were confirmed, and made even more sense when I found the original thesis came from someone at Trinity College, Dublin.

I found the original thesis by Richard Pawson entitled Naked objects where he details the principles behind the concept. The thesis is very readable, as theses go. It is broken up into an introduction, a case study, guiding principles, etc. What I found more interesting was the forward written by the pioneer of the MVC pattern, Trygve Reenskaug. The concept of Naked Objects isn’t exactly new, and it should be lauded for its intent of getting back to the proper intent of object oriented design and programming. Of course, as a technology, and as some of the design constraints of naked objects, the thesis is not without detractors. For example a short paper by Larry Constantine called The Emperor Has No Clothes: Naked Objects Meet the Interface .

The true value in something like Naked Objects is to get you to adjust the way you are thinking. The main concept is to build the complete logic of the system using a finite set of domain objects. The framework is designed to take care of database persistence and user interface. According to the forward in the thesis, the spirit behind MVC is that each view is mapped to only one object, although each object might be mapped to many views. The controller is responsible for mapping the events of the view (inputs, etc.) to the domain model. Essentially the domain model (or model) uses views for output and controllers for input. This is different from the way it was originally described to me and I originally understood the pattern. Pawson argues that the framework can generate the user interface views and controllers automatically. Further advances in the concept also automatically maps the domain model to a relational database using Hibernate .

The software developer side of me likes this concept. It’s less plumbing to worry about. I don’t have to know how to code a user interface. I can get my work done quicker. However, the user interface design side of me loathes the concept because the user interface (admittedly by Pawson) is not easily grasped without training, nor is it particularly accessible. The architect in me is thinking about how I can have my cake and eat it too. Ignoring the problem of database mapping for a moment, the real challenge is in the view/controller (VC) layer. Pawson sites arguments from advocates of Object Oriented User Interface (OOUI) design that there is only one true correct way of representing an object. Yet turns around and presents two: an icon to represent the object and a dialog box to represent the content in the object. In my own project I am working on now, there are at least two representations of every object: the view in a list, and the view of the full content of the object. Nevertheless, there still remains concepts I can leverage.

In some respects Wicket would be an ideal candidate for dynamic generation of VC code. Or at the very least, due to its attempt to treat the view layer in an object oriented manner, some extensions to the application can dynamically generate the controller side. I have some reservations about pursuing that too far at the moment. The real conundrum is in the presentation layer. Managing information and behavior is something that object oriented languages are designed to handle. It is right and good to take advantage of the features of your language to properly model the business domain. However, representing that same information to the user in a way that makes sense to the user is a completely different discipline. I can argue against the principles in OOUI till I’m blue in the face, but that doesn’t solve the fundamental problem.

What we need is a way for the programmers to create the functionally complete object oriented domain model, while your user interface specialists concentrate on their responsibility. While frameworks such as Wicket have tried to address that very problem, it is my personal opinion that they fall a little short. I don’t think the fault lies with Wicket. The fault lies within the current set of W3C standards and differing levels of browser compliance. The W3C is still stuck on a model that prefers static information. If the W3C were to truly pursue a model where the user interface layer is bound to certain objects and the browser makes calls to the server to render these objects we might have a better solution. We’ve already started down this path with AJAX and the myriad of Javascript frameworks to make this work. Needless to say that there is a lot of future work that has to be done in order to truly see a synergy from functionally complete domain models and an object oriented user interfaces.

The goal of such an endeavor should be to allow user interface designers these freedoms:

Create the representations of the objects as they see fit
Create the rules of how to select the correct view from the different possibilities.

The controller logic should be built into the browser already, in terms of invoking the domain model (or representations of a remote object).

While I’m on the subject of Naked Objects and domain models, I’d like to make a minor rant on Object/Relational Mapping tools. One of the problems is that ORM tools tend to require accessor and mutator methods (getters and setters) for every field that is going to be persisted to the database. While you are technically encapsulating the internal state of the object, in 99.44% of the cases there is no difference in using the accessor and mutator methods and directly accessing the underlying attributes of the class. In a properly designed object, you only need to expose information via accessors that the user is allowed to see, and you only provide mutator methods for what the user is allowed to change. ORM tools require you to violate those principles if you want to persist the information down to the database. Some ORM tools (ActiveRecord) generates these accessors and mutators dynamically for you. That’s great for convenience, but terrible for a properly designed domain model. For the time being, there really is no alternative unless you write the ORM layer yourself. Not recommended if you can help it.

Wicket Impressions

Berin Loritsch — Fri, 04 Dec 2009 14:02:00 +0000

I chose Wicket for this project, partly because I met some people who were very enthusiastic about the framework, and partly because I wanted something that was easily tested. My client requires a Java solution, so Ruby on Rails was out. I did a quick little shoot out between three Java framework options, and Wicket passed the first impression stage.

Now I’ve got a couple of iterations of software development with it under my belt and I’m starting to feel a bit more comfortable with the framework. As far as Java web frameworks go, its pretty good, but… I would do things a bit differently. The application is written in a style that would actually better fit Ruby, SmallTalk, Lisp, or some language that supported passing in procedures or lambdas (as the language gurus call them) natively. Take for instance the Link class. In order to do anything useful, you need to subclass and implement the onClick callback method—even if all you want is to go to another page. Here is an example:

add(new Link("wicketId") {
    @Override
    public void onClick() {
        // do fancy logic
        setResponsePage(new IncidentPage(incident));
    }
});

If this were Ruby the code would look like something like this:

self << Link.new("wicketId") do 
    // do fancy logic
    respond_with(IncidentPage.new(incident)
end

So am I complaining about semantics? Possibly. However, there are more “Java” ways of accomplishing the same class—particularly if you want to manage all business logic in a few classes. The more “Java” way would be something like using the java.lang.Runnable interface. That would allow you to set up an enum to include all your business logic like this:

enum IncidentLogic implements Runnable {
    EDIT {
        @Override
        public Page run() {
            // do fancy logic
            return new IncidentPage(incident);
        }
    }
}

and it would be used in your page like this:

add(new Link("wicketId", IncidentLogic.EDIT));

I’ve also experimented with using a dynamic proxy to bind any method to an interface. That would let you set up a logic utility class and reference it like this:

add(new Link("wicketId", Linker.link(IncidentUtility.class, "edit"));

It’s not as pretty but it works. Now here’s the nice thing about Wicket. If I feel strongly enough about it, I can create my own subclass of the Link object to implement that approach myself. My DynamicLink would look something like this:

public class DynamicLink extends Link {
    public static interface Executable {
        Page do();
    }

    private final DynamicLink.Executable click;

    public DynamicLink(String wicketId, DynamicLink.Executable action) {
        super(wicketId);
        this.click = action;
    }

    @Override
    public void onClick() {
        setResponsePage(click.do());
    }
}

In fact, I think I may just do that. It’s better than having bits and pieces of behavior spread throughout the Pages and panels defined in the application. I think I find it a bit frustrating when i need to do things like that just to format dates the way I want. Why can’t the provided DateFormatter let you set the pattern you wanted to use? Why do I have to subclass the one in Wicket just to get that feature?

At the end of the day, my complaints are minor and the Wicket community is helpful. I’m fine with that. The Wicket framework is probably one of the leaders in providing a test harness that can be used easily in your JUnit tests. That is a much bigger selling point to me.

Wicket, Spring, Hibernate, Testing... Yeah, it's like that.

Berin Loritsch — Tue, 10 Nov 2009 16:57:00 +0000

I have to deliver a product using Java. Due to politics and approved baselines, etc. I can’t use Ruby on Rails. I’ve done my own thing in the past, and so this time I decided to save some time by incorporating Wicket, Spring, and Hibernate using auto-wiring, and attributes. Getting it all to talk together took the better part of a day, but I got it to deploy and run fine.

I’m an avid unit tester, so I was happy to learn that Wicket has some facilities to make testing a bit easier without forcing you to create your own Servlet mock objects. I was really happy about that, so I decided to try it out. Unfortunately, I ran into a rather nasty roadblock. Spring was complaining about the ContextLoaderListener not being loaded. It’s defined in my web.xml file, but the autowiring requires the spring context to be loaded in a particular location. Finding out how to fix that problem took me the better part of half a day.

The problem is that Wicket hides the ServletContext object away from you. You can’t add values, because the test framework is initialized on construction. Attempts to obtain the ServletContext and manually add the Spring web application context just weren’t working. That’s because it is configured when the WicketTester object is constructed and ignored after that. I needed to be able to inject my own ServletContext with the Spring integration taken care of. I finally figured it out here, because the forums just working for me. Please note that this is tested with Wicket 1.4 and not any of the earlier versions:

final MyApplication app = new MyApplication();
tester = new WicketTester(app) {
    @Override
    public ServletContext newServletContext(final String path) {
        // web context
        ServletContext context = new MockServletContext(app, path);
        // spring context
        XmlWebApplicationContext spring = new XmlWebApplicationContext();
        spring.setServletContext(context);
        // configure spring
        spring.setConfigLocation("classpath:application.xml");

        // put spring where Wicket can find it
        context.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, spring);
        return context;
    }
};

So let me explain what I did. I created an anonymous subclass of the WicketTester class so I could override the factory method “newServletContext” to inject my spring configuration. Done properly, the wicket folks can take care of this by providing a SpringWicketTester subclass in their spring integration library. The SpringWicketTester would let you specify the location of your Spring configuration file, and it would override that method for you. For now, you’ll have to do it yourself.

I put the WicketTester initialization in a subclass of the JUnit TestCase class. That way I don’t have to repeat myself for setting up my Wicket testing.

Ruby IDEs Come of Age

Berin Loritsch — Fri, 16 Oct 2009 02:07:00 +0000

There’s nothing better than finding that sweet spot with developing your software where your tools work with you, and all is right with the world. With Java that started when JetBrains introduced their IntelliJ IDEA product. That product changed the way we think about integrated development environments, and even the open source alternatives like Eclipse imitated the features included in the IDEA product. At some point they specialized differently, each with their own set of pros and cons.

The Ruby development environment lagged seriously behind with people content to use glorified text editors.

Ruby on Rails brought a whole new community of developers to the Ruby platform, many who were curious malcontents from the Java arena like me. For folks who were used to the IDE integrating with your version control system, and even your issue tracking system, going back to text editors alone wasn’t going to cut it. Yet, so strong was the pull from Rails that some enterprising folks started creating a Ruby IDE: RadRails. RadRails is now a plugin for the Aptana web development platform, and Eclipse based tool. Aptana was my IDE of choice for quite a while. Since I was already used to Eclipse, and I had a set of plugins that I already enjoyed using, there really wasn’t much reason to switch. Except for this nagging feeling things could be better. I was still sorely missing refactorings, decent intentions, and working type-ahead for the Ruby API. Sure I was aware of the technical limitations, but I knew it could be done.

I limped along until I noticed that the Ruby Language had made Ruby 1.9.1 the new official Ruby. It had Rake and RubyGems as standard components, so there will be no issues with the stinking Linux distros that refuse to make an RPM for RubyGems. It’s all included. Of course, there are still some growing pains with some gems. Check out Is it Ruby 1.9 for details (they have a sister site for JRuby in case you are interested). I had an upgrade project ahead of me that required some features from Ruby 2.3.x, cleaning up, and security enhancements. Since I had to re-implement the site anyway, Ruby 1.9 was measured to execute faster, and I had the liberty of doing so, I decided to make Ruby 1.9.1p243 the new baseline.

That’s where my troubles began. It wasn’t just the Gems either. The IDEs just couldn’t handle it. They turned into glorified text editors with the ability to track commits. The debug feature was broken.

I remembered the Zen like experience that I had with JetBrains IDEA from the Java world, and knew they also had a product for .NET. I hoped they had a product for Ruby, and sure enough they have the RubyMine product. If you are looking at Ruby 1.9, or Rails 2.3.3+ don’t look at RubyMine 1.1.1. Look at their new RubyMine 2.0-beta. This is what Ruby programming should be. The price point is currently $79 USD with the current promotion, but normally it is $99. That puts it in the range that mere mortals like me can afford. It works quite nicely with Ruby 1.9, and even Rails 2.3.4 (although that wasn’t the version they developed against). I have my refactorings, my intentions, my effortless subversion integration. Formatting works. It’s fast. Type-ahead doesn’t flake out. Debug works (made possible with coordinated efforts between myself, the debug-ruby-ide gem maintainer and the JetBrains team—the latter two doing the heavy lifting). Let me tell you, JetBrains is as good and responsive as they always were, and the Ruby community is like the Java community used to be, but better and more pragmatic.

Aptana and RadRails will catch up, it’s a matter of time. However, JetBrains RubyMine works now, and it works better and faster than Aptana. On Windows, RubyMine performance is acceptable (on par with Eclipse), but on Mac it sings. Eclipse/Aptana’s performance doesn’t change no matter what platform you are on.

While I’m at it, I do have a major gripe with the Eclipse baseline. As a developer, I have a list of plugins I depend on because those features don’t come out of the box with Eclipse. However, the Eclipse developers who are ever moving forward, break the plugin API and the plugins I need to use. I can’t download a version of Eclipse and expect it to work properly. Then, if I have to hunt around for an older version, God help me. At least Aptana goes through great efforts to provide a stable and usable baseline. OK Eclipse, how is it that you provide an IDE for developing enterprise applications, and you don’t bundle the plugins for Subversion, CVS, and GIT? If Aptana can do it, why can’t you? It’s unthinkable that a responsible developer will touch code without the safety net of a version control system. Give them tools out of the box so they don’t have to separately install these plugins. Support the open source projects around you, so open source version control systems should have preferred status. And don’t release a version of Eclipse until you’ve got those plugins working with it. Really. I mean it. It helps you out in the long run.

Web Accessibility

Berin Loritsch — Tue, 04 Aug 2009 15:08:00 +0000

I’ve been spending a lot of time looking into accessibility for web sites to finally get a grip on what needs to be done. Sadly, it is overlooked by the big guys when it doesn’t really have to be so hard. There are several types of disabilities including:

Visual (full, partial, or color blindness; Photo-Epileptic Seizure [PES] susceptibility)
Motor control (full or partial disabilities preventing the use of a mouse)
Cognitive disorders (dyslexia and the like)
Auditory (full or partial deafness)

The main issue with accessibility is the lack of knowledge and reasonable resources available to help. In particular, the tools that are needed to support people who have the disabilities are expensive and complicated. There are tools available that everyone can have at their fingertips that will help. Most are Firefox plugins, some require you to use an external site. Below are a few of the resources I’ve found:

The folks at WebAIM have several good recommendations. For example, you know those “edit in place” controls on Flickr? You can make them keyboard accessible by applying the attribute “taborder=’0’”. The control will be in the page’s natural tab order. I did a little experimentation and the control supplied by Script.aculo.us can take care of all these things for you. The only issue is that IE 6 won’t put the control in the tab order unless it is in the original markup. Dynamically changing the DOM to put it in won’t put the control in the tab order with that browser.

Web Design 101

Berin Loritsch — Fri, 17 Jul 2009 19:25:00 +0000

This is a departure from the film and darkroom printing posts, so apologies and I’ll be back on that later.

I’d like to think I’m a pretty good application designer, although some of the things that I’ve seen on other sites have left me a bit jealous. Face it, I didn’t have a background in web design. I know what I should be able to do, and what it ends up looking like. The problem is familiar to anyone who has designed for the web: IE and non-standard implementations of HTML, JavaScript, CSS, etc. The way it’s supposed to work is you whip open the standards, see what CSS can do for your style, and do it. When you see impressive use of CSS from the CSS Zen Garden you start thinking, why can’t I do that?

I come from an application development background, where we can design our desktop apps with nice grid based layouts and do all kinds of fancy things. From there I went on to web development, and have always been frustrated with my inability to escape using tables for layout. Tables are great for lining things up, but they can cause their own issues when you start incorporating AJAX and other goodies. Then you have to worry about what your client’s browsers can do and what they can’t do. At least I don’t have to worry about Netscape 4 and it’s 30 second lag time to sort out nested tables anymore.

So, I think I’ve solved the worst of my problems. I solved the nonstandard JavaScript implementation problem by using Prototype.js which really made it easy to take care of AJAX support for tags and made some of my complex form handling easier. I was still doing my own JavaScript implementations of type-ahead controls and the like. Then I discovered Scriptaculous which took the pain out of 90% of the more advanced control issues I had.

But what could be done between the presentation hell that Internet Explorer puts me through compared to other browsers on the market? IE positioned things just a bit off, and handled the positioning of divs a little crazy as well. If I was going to both have a nice visual grid layout and use markup the way it was intended, I needed a solution like prototype and scriptaculous to help me out. Enter Blueprint CSS to take away the pain and suffering of using divs to align your content. Now blueprint provides some nice little “plugins” that use CSS to do pretty buttons or decorate links with graphic icons all with pure CSS. The graphic icons degrade gracefully as IE 6 does not support the type of selectors it uses. However, the library included a couple PNGs with transparencies. So what does one do about the fact that IE 6 does not render that nicely? Fix it up with Unit PNG Fix of course.

Now my header looks like this:

    <head>
        <title>My Site</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
        <link rel="stylesheet" href="css/screen.css" type="text/css" media="screen, projection">
        <link rel="stylesheet" href="css/print.css" type="text/css" media="print">
        <!-- Fix nonstandard IE spacing -->
        <!--[if lt IE 8]><link rel="stylesheet" href="css/ie.css" type="text/css" media="screen, projection"><![endif]-->

        <!-- Site CSS -->
        <link type="text/css" href="css/mysite.css" rel="stylesheet"/>

        <!-- Fix IE6 PNG transparency issues -->
        <!--[if lte IE 6]><script type="text/javascript" src="lib/unitpngfix.js"></script><![endif]-->

        <!-- Prototype.js/Script.aculo.us  -->
        <script type="text/javascript" src="lib/prototype/prototype.js"></script>
        <script type="text/javascript" src="lib/scriptaculous/scriptaculous.js"></script>
    </head>

It seems like a lot, but it makes my life so much easier. I highly recommend Head First Web Design as it covers all these wonderful concepts and more.

Print a Month Project

Berin Loritsch — Fri, 26 Jun 2009 12:44:00 +0000

Starting in July, I’m starting a new project to help sharpen my skills and maintain a consistent production. The basic principles are as follows:

Every month I take a new picture
That picture is then manipulated and prepared to the best of my ability
The final result is a matted print

The goals are to fine tune my process, try new techniques, and increase my proficiency. The reason for dealing with a print is is for the work to reach its full potential.

Why every month, and not every week or every day? Mainly because I want to have an attainable goal. Something that is reasonable for me to do, yet will push me. Due to my schedule between work and church, I have far less time than I really want in the darkroom. I’m trying to make better use of my time in the darkroom. Additionally, the goal of one print a month allows me to really dig deep into a print and experiment with ways to make it better through dodging, burning, toning, or more creative approaches.

"Beyond" the Zone System

Berin Loritsch — Mon, 22 Jun 2009 12:14:00 +0000

In the process of trying to coerce a working system in my darkroom, I purchased the book “Beyond the Zone System” because I know it has a lot to help understand sensitometry. What appeals to me is the ability to both test the speed of your film and the development time within 6 sheets. Since Ansel Adam’s film speed test takes seven sheets and an unknown amount of sheets for the dev test (at least one but in practice a few more), I’m all about conserving resources. The cost of the sheet of film is only one part of the cost—it’s the investment in time that I’m most concerned about.

BTZS starts out with a nice little overview of how paper and film work together to make the finished image. It also has a review of all the types of math and graphing theory that pertains to this testing process. The math’s not that hard, but the problem is in the way it’s presented. You can tell the author has a wealth of information, and he tries to make it accessible all in one or two chapters, but you almost end in confusion.

Where my head really starts swimming is when he gets in to calculating film speed. With Ansel Adams, it’s simply a density of 0.1 over film base+fog. The author covers the history and the pros and cons of how film speed was calculated over time, instead of just choosing one and teach how to do that one. It’s useful information, but the alternatives could be moved to an appendix to make that section more accessible.

With a proper handle of the basics of how the film and paper relate to each other, you can intelligently make decisions on exposure, development, and printing decisions. The road to understanding taken in the BTZS approach is very technical, which is not for the feint of heart. However, once you’ve learned the basics, you learn useful bits of information. For example, changing development times is similar to changing apertures—they both follow the same geometric progression of numbers (4, 5.6, 8, 11, 16…) to produce the same changes in final density. Shutter speed times and film speed numbers follow the same progression of numbers.

If you are serious about understanding more about how your materials work and respond to light, this book is definitely something you should have in your library. It will take time to “get it”, but once you do it will help you with your final results. You have a better understanding of why you choose a particular density for your print materials. You also have a better understanding of how zones don’t equal stops of exposure—yet the two still relate predictably.