Software Artisan

Using Many Objects at Once

Berin Loritsch — Wed, 06 Aug 2008 11:53:00 +0000

Last article was meant to introduce you to the terminology that is common to object oriented languages. You should have a clear idea of what an Object is and what a Method is. Today, we are going to learn about how to use more than one object at a time. We’ll start with simple variables, which are simply names for objects you are using so you can get to them again. Then we’ll talk about some special objects called containers, whose sole purpose is to organize a group of objects for you.

A container is an object that holds a bunch of other objects

Variables

So there’s a little more terminology here. We can assign objects to individual variables fairly easily just by giving a name, using the equals sign, and the value. For example:

my_variable = 12345

As long as the first character of the variable name starts with a letter or an underscore “” character, the rest of the characters can be letters, numbers, and underscores. Almost all languages have this requirement, so that the computer doesn’t get confused between what is supposed to be a number and what is supposed to be a variable. Just a little helpful advice from someone with experience here, use variable names that make sense. It is better to type a few extra keys than wonder whether _cntr meant counter or center later on. It’s also better to use names that reflect the variable’s purpose rather than what it is made of.

array = ['cero', 'uno', 'dos', 'tres']
ones_column = ['cero', 'uno', 'dos', 'tres']

The variable named ‘array’ is kind of silly. It describes what kind of object is assigned to the variable rather than what we are using the variable for. The variable named ‘ones_column’ describes the purpose for the variable better. We are using an array of names to write out the ones column of a number.

Variables let us hold on to objects with a user friendly name so we can use them later

Arrays

Since we already introduced how to create an array above, let’s talk about how they are used. Arrays hold a bunch of related values together so that we can use them in interesting ways. Using the ‘ones_column’ example above, we can use any single digit number to get the name of that number.

Arrays are lists of information

puts ones_column[2]

# prints 'dos'

Remember in the last lesson, when we had a number do something using the times method? The number passed back to our code started at zero. The number inside the square brackets is an index number that starts at zero. So the first element in the array is always 0, not 1. That’s why we started the array with ‘cero’ (Spanish for zero) instead of ‘uno’ (Spanish for one).

An Array is a Collection, so like all collections it has an each method. The each method works just like the times method on the number objects. The method will pass back the elements (the objects) of the array one at a time in order. So, if we wanted to count in Spanish, we would use our ones_column array like this:

ones_column.each do |number|
  puts number
end

Hash

A Hash allows you to map one object as a key and another object as the value. Other languages will call the Hash a Map or a Dictionary, essentially letting you look up one object (a definition) using another object (the word to look up). Think of the word key in the terms of a map key. A symbol represents a concept, so to speak.

Hash lets you associate key objects with value objects

In Ruby, Hashes are created using the curly braces, and the key/value pairs are marked with the phrase: key => value . They can be quite handy when you have a lot of information to pass from one place to the next. One variable would take all the name/value pairs. If it helps, think of it as a collection of variables. It is most common to see string names be the key, but in Ruby we also have something called a symbol. Strings are surrounded by quotes, and they can change. Symbols have a colon in front and they never change.

my_map = {'string' => 'surrounded by quotes',
          :symbol => 'starts with colon',
          :string => 'not the same as a string'}

puts my_map['string'] # shows 'surrounded by quotes'
puts my_map[:symbol]  # shows 'starts with colon'
puts my_map[:string]  # shows 'not the same as a string'
puts my_map[:string.to_s] # shows 'surrounded by quotes'

In the above code, we set up a map of keys to string values. Just so you know, the objects don’t have to be the same type. In fact you’ll see that we used one string and two symbols for keys. You’ll also see that the Hash object treats them differently. The last lookup call might cause a little confusion, so look at the method being called on the symbol. The to_s method is on every Ruby object, and it is a convenient way to get a string out of the object. For a symbol, the to_s returns the name of the symbol (everything except for the colon). Because that happens to be the same name as a string key that is already in the map, it returns the value that belongs to the string.

This brings up a very important point, particularly for newbies. Save yourself a lot of headaches, and only use keys of the same type until you know exactly what you are doing. If you ever use many types of objects for different keys make sure you document your code with your comments. You don’t want to run the chance of spending hours tracking down a bug only to find it is the same thing I showed here. Talk about your ‘Doh!’ moments.

Strings

Ok, the Array and Map are good enough to get you going—there are more collection types and more things you can do with these collections, but strings are pretty important in programming. The string is your best tool for communicating with the user. On web forms, your values are all strings, and when you add content onto a page, they are strings. There are three ways of working with strings in Ruby, depending on how much power you need. We will introduce them from the simplest to the most complex.

Strings hold text

simple_string = 'single quotes and no processing'

The above string is rather simple. The single quotes mean to take the text AS IS, no escaped characters, no single quotes, and no formatting. You’d be surprised by how much you can use this simple declaration. If we ever needed to stick two strings together, we can use the plus sign (’+’).

hello = 'Hello'
world = 'World'

puts hello + ' ' + world

#shows 'Hello World'

Things can get messy when you have to show information your program has back to the user. The ’+’ concatenation only works for strings, so each object that is not a string needs to call the to_s method to be concatenated. Oh, and then you still have the problem of formatting the text to be pretty. There is a more powerful way to declare and use strings, and that is to use double quotes:

number = 4

puts "Number:\t#{number}"

In the string we sent directly to the puts method, we see a bunch of stuff that might look confusing at first. The first funny looking characters would be the ”\t”. The backslash (’\’) is an escape character, so you can access more special characters with it. You can embed double quotes by adding a backslash in front, or in this case you can embed a tab character. Essentially, we told the string to embed some white space. The next set of funny looking characters would be ”#{number}”, but when you realize that the number inside the curly braces is the same name as the variable we defined before, it suddenly becomes a little less confusing. Basically anything between the ’#{’ and ‘}’ will be treated like regular ruby. You can even do math in there if you really wanted. It’s best to keep it simple and only use it to display the value of variables in your string.

That’s all well and good, but what if I have a lot of text, I only need to embed a little bit of Ruby variables, and I want to do all the spacing and carriage returns myself? There is a way to define a big string by providing your own “terminator”. The terminator is just so that Ruby can know when the string is done and it can go back to normal Ruby processing.

really_big = <<-END
This string will keep going and going
on and on until I use the terminator
to make it end.
END

puts really_big

You can embed variables just like before using the ’#{}’ construct, but there really isn’t a whole lot of need for escape characters and such. When you have a big message you want to give to the user, this is usually the best way to get it done. The important thing is that you choose the terminator so it will never be text in your block. The characters ‘<<-’ basically tell ruby to keep adding lines to the string until we reach X where X is the terminator. In my example, I chose the word END in all capital letters, but you could just as well use TERMINAR or BATTLE_FLAG or any other gibberish you want. The string will start on the following line and continue until it hits the terminator you set up. Just make sure it is clear what you are doing so that when you come back to the code later you aren’t thinking What in the world did I do?

Intro to Programming with Ruby

Berin Loritsch — Mon, 28 Jul 2008 12:12:00 +0000

First of all, Ruby is a programming language that has become pretty popular with the advent of Ruby on Rails . That said, Ruby is a great first programming language to learn. I won’t bore you with it’s history, even though the language has been in existence for over a decade. For the summary about Ruby, check out http://www.ruby-lang.org/en/about/ and also look at the different tutorials. This tutorial is meant for people who don’t know squat about programming. If it’s confusing at all, let me know in the comments.

Before we delve into objects and things like that, let’s consider what happens when we have to use Ruby to help with other tasks. Those tasks can be deployment scripts, test support, etc. One of the most important things you will learn has nothing to do with actually making stuff work. It’s the comment. Basically you want to leave notes for yourself so that you can get back into the swing of things after you leave something alone for a while. To do that with Ruby, all you need is the ’#’ symbol. It marks the beginning of a comment, and the comment is over at the end of the line.

#
# A block of comments looks like this, with a '#' symbol
# at the beginning of every line.  Comments are supposed
# to help you remember things later on.
#

Start with good commenting habits, and keep them up. Some things are pretty self explanatory so make sure you document the big things and not what every line is doing. Remember that these are clues you leave to yourself, or anyone else who will work with the code about what’s going on.

Now, Ruby is an object oriented language, but before I get into making objects let’s look at what they can do for you. In Ruby, everything is an object—your numbers, ranges, collections, etc. To help wrap your brain around objects, think of them as “things”.

Objects are things you can tell what to do.

Let’s say you need something to be done five times. The number five is an object, which means you can tell it to do something for you. Core Ruby Doc has all the standard objects that are part of the language, but it can be a little overwhelming at the beginning. First of all, the number five is an Integer (there are no decimal points so math people tell us that the correct name is an Integer). If you look up Integer in the Ruby docs, you’ll find that a list of things that it can do. There are two that look pretty interesting to us, but for now we just want to do something five times. Here’s how we do it:

5.times do |num|
    puts 'Do something!'
end

Ok, what’s going on here? The number five is an object, and the ”.” symbol means “tell the object to do something”. The name after the ”.” is what we are telling it to do. So we are basically saying “Number 5, I want you to .times”. OK, so we are missing part of the picture. That part is the do block. Everything between the do and end is also being passed along with the message ”.times”. Let’s call the ”.times” message a method.

A method is something you can tell an object to do.

Continuing on, we have the do block followed by some pipe symbols ”|” and a name in the middle. This is how the number 5 passes something back into your do block so that you can use it. The name you give this something is called a variable. You can use it or ignore it, it’s up to you. We are ignoring it for now, but if we want to use it, we just have to use that name.

5.times do |count|
    puts 'Do something on time ' + count
end

What you see will change based on the value of the variable “count” that the number 5 is giving us. The documentation tells us that the number will start at 0 and go to just under our number. So we will see five lines counting up from 0 to 4. A lot of programming languages do this, so it’s just something you have to get used to. Everything between the do and the end markers gets run each time. The important thing is that the variable you named inside the ”|” symbols is how you use that variable.

OK, we are taking some baby steps here, but I’ll stop for today. First of all, we learned that things are called Objects and we tell Objects what to do by calling Methods (some people call them messages, but other languages use the word Method so we are just being consistent). We also learned that you could pass in a whole block into a method and have that object run that block for us. We learned that when we pass in a block to an object’s message, it can pass something back into our block so that we can use it. I want to point out that the whole “pass a block of code” thing is something that not every language can do. For instance at the time I am writing this, Java, C#, and C++ can’t do that.

Lastly, I want to start you thinking about something. The best code is self documenting, but it will never read like a book. As long as the details are clear, all you have to worry about in your comments is why you are doing something five times. With the last snippet of code above, it almost reads like English. We are saying “five times do something using ‘count’”. The word “puts” is actually a method on the text console object. Ruby makes some assumptions to make the code a little more readable.

What's the Minimum Requirement for a Successful Project?

Berin Loritsch — Mon, 21 Jul 2008 15:15:00 +0000

This is in preparation for a newbie series on the Ruby language; however, it’s included for your benefit here. There are certain things that any project needs to keep track of if it is going to be successful:

What needs to be done?
What was done?
And how close are we to being done?

I’m going to avoid all the project management and tech speak as much as possible. For you college students, pay attention, if you aren’t doing these things you are writing a recipe for disaster. So let’s look at these things one by one.

What needs to be done?

To answer the question you need to ask yourself, “if I get nothing else done what will make me successful?” These things are called requirements and every project has a different focus, so the requirements will not be the same. The next thing you have to ask yourself, “what is standing in between me and something I am proud to show off?” These things are called issues and they can be your own doing, or they can be external forces. Now, you can lump everything together, because you have to address both your requirements and your issues in any given release. A release is a version of what you are doing that addresses a list of things—whether they are requirements or issues. It’s kind of a package deal.

I’ve managed a few projects where we put everything in an issues list, and assigned version numbers to those things. The issues could be further classified into requirements, enhancements (aka new requirements), bugs (mistakes we made), configuration problems (environment problems), and risks (something that may or may not happen that we need to be aware of). The important thing is that you assign these things to a version so that you can have an idea of what the package is. The complete list of things to be done is your release, and as you knock them off, you can see how close you are to making a release. The list can grow as your are working and new bugs come up, or the people you are writing the application for come up with something new.

What was done?

To track what was done, you not only need to track how you are doing in your issues list, but you also need to make sure that your workspace (source code, etc.) matches what you said is done. You need to make sure that when you have a number of people working together on the same project, that no one accidentally deletes someone else’s work or added something extra. For software projects, the chief tool to keep track of what was in older releases and merging multiple people’s work together is called a version control system. Some common free version control systems include CVS and Subversion. For software projects, there really is no excuse for not using a tool for version control. The two listed are free open source projects, and the second one is a little better to manage. There are commercial software projects, but the important thing is that you are using something other than people to manage the process. Your version control software has to support the following functions:

Tagging (marking a set of code at a version in history so you can say what was done for a previous release)
Merging (when more than one person is working, their work should be merged into the controlled version and not just replacing the whole file)
Logging (every commit should have a message summarizing what was included in the change)

Document management systems usually don’t support tagging and merging. They just keep a history of versions of a document. They also usually require you lock a file so that no one else can touch it while the changes are happening. While that may be necessary when you are working with word processor documents, with source code it is an unnecessary restriction that gets in the way of doing work.

So how do we make sure we did what we said we did? You test. Testing is essentially checking the application is doing what we expect it to do. You can do testing manually, automatically, or some combination of the two. The best option is to combine automated testing with manual testing. The automated testing will always check the “blessed path” or expected way to use an application. That way you make sure you don’t accidentally break something with new changes. The manual testing (people actually using the application) will have people trying to break it or abuse the system. If they succeed in breaking it in an unexpected way you have a new bug and a new automated test to deal with.

How close are we?

Hopefully, the list of open issues is getting smaller and the number of passing tests is increasing. Eventually, the number of open issues for a release will reach zero, and all the new stuff will be fully tested and given the green light. That’s when you know you are ready to cut a new release. It helps to chunk up the work so that you can get a feel for how close we are getting a little at a time. Let’s say you have a long list of things for a release, and you think it’s going to take about six months to get it all done. If you wait until the end of those six months to begin checking your work, you are probably going to get overwhelmed with the list of things that went wrong. It’s better to break up the work into smaller chunks.

I find that one or two week cycles give a good balance between getting the work done and testing early. If you do too much work before testing, it will take a lot of work to fix the problems. If you do too little work before testing the work becomes tedious and unpleasant. It’s best to have a good battle marching speed to do little mini releases so that people testing will be able to catch and report problems before they get too big.

For any project where money is involved (i.e. just about anything other than an open source project) it’s important to see how close you are to your estimate. Unexpected problems can really affect when you get the work done. Let’s say you are marching along really well and it looks like you might even beat your 6 month deadline, but suddenly the database is imploding under the work load. Now you have to find out why it’s misbehaving and fix it. The problem might be a configuration problem, or it might be that you have too little database for your application, or it might be that you are doing too much with the application. Finding the problem and fixing might set you back a month, so meeting that six month deadline is starting to look like a pipe dream. Now you have to figure out how you are going to handle the schedule problem. You can move the schedule, change what’s required for the release, change the way you are doing things to speed it up, or make people work longer. There’s a physical limit to how long people can work, and the longer the work the exponentially more inefficient they become. If you can work smarter instead of harder, go for it. It will help you with the next release.

With open source projects, the schedule is less of an issue, and things are released when they are ready. However, if someone wants to help out and start helping, it’s always best to give a clear answer of what you are trying to do. If they can see the list of issues and help get it done quicker, more power too them.

Testing and Choosing Your Process

Berin Loritsch — Wed, 09 Jul 2008 13:27:00 +0000

Process . It’s a dirty word around some people. All it means is “A way to get something done”. Nothing more, nothing less. However, we have things like ISO 9001, CMM, Agile, XP, Scrum, etc. all presenting themselves as the way to develop your software. Each has it’s benefits and drawbacks, and each works with a different kind of client. If you hear anyone tell you that their way to do things is better, faster, etc. than anything you are doing without knowing the details you know you are dealing with a snake oil salesman. Even within the CMMI framework, there is a lot of leeway for you to have a heavy process or an agile process.

Process is just a way to get things done.

I’ve heard of some people’s software development process as “write a little code, run the app, write a little more code, and so on.” That process can work for some people, but not for everyone. I happen to be a fan of Test Driven Development coupled with Continuous Design—a fairly Agile approach. However, I know there is a lot of people who just can’t think that way. That’s fine. We just probably won’t be working on the same projects.

Manual Process vs. Automatic Process

The first aspect software development process is finding the right ratio between things you do manually, and things that the process takes care of for you—as a side effect of just doing the process. We programmers tend to be lazy, and so we do whatever is easiest on us to do. Ironically, we are so lazy sometimes that we would rather not invest the time to set up the automation unless there is a clear reason to do so. It’s actually a good thing because too much automation can get in the way of making changes. Of course, manual processes don’t scale very well.

Anything you do manually is something you have to remember to tell someone else.

When you are working alone, you can take all the shortcuts you want because you don’t have to explain what you are doing. The problem comes when you add someone to your team. All the things you were doing you now have to explain to someone else and get them to do it, or it won’t get done. Heck, sometimes you either forget a step even when you are by yourself. It’s for that reason we even consider automation. The places where we have the best benefit from using tools include configuration management and creating builds. I wouldn’t imagine writing any code without version control software of some sort even if I’m by myself. The versions are managed for you so you can go back to a release to reproduce issues if necessary, the code is backed up and managed beyond your own hard drive, and as soon as you add more people to the team it takes care of merging code for you. The benefits far out way the alternative. Creating a build might be easy or difficult depending on the structure of the complete application. The build process will create your distributables and run any tests you have included. Tools include Make, Rake, Ant, etc. and have differing levels of complexity. The important aspect is that you aren’t relying on someone else to make the identical configuration settings in their IDE to get the same executable. It’s all taken care of by the script.

There are other areas where automation can help out, but it does depend on the culture of the project, and the ease of setting it up. How do you manage your issues? Many tools generate reports just from how you use the application. You can show how quickly you are burning through your issues, and you can see how fast or slowly you are approaching the completed release. Sometimes you can add flags to the tool to notify you if values are outside a certain set of parameters.

Testing your Process

In any software project there are number of things you have to keep track of, and your process (the way you get things done) should make it easier. So how do we know if the process is working or not? You have to start by identifying what’s important. What is going to make your client lose confidence in you? If you do nothing else, what has to be done? Do you really need full Earned Value Management (EVM) or can you get away with proving you are making progress at the expected rate. Many times it’s enough just to know when you are falling behind. One thing that’s a must in any process is that you produce the deliverables.

If anything important slips through the cracks, your process is broken. Period.

Once you’ve identified the important stuff you can’t miss, you keep track of it. So how do I do that? You do your process. If you can ensure your process takes care of tracking the important stuff, all the better. Keeping track of something is what some people call “metrics”. The thing I don’t like about metrics is that you are essentially associating numbers to parts of your process. Numbers people like metrics because they have something to play with. The reality is that numbers don’t mean anything at all. Trends mean something, numbers don’t. If you are getting better, (i.e. your trend is going in the right direction), your process is working. If you are getting worse, (i.e. your trend is going in the wrong direction), your process needs to be fixed.

So how do you track trends, and when does a change really mean something? The tricky thing with trends is that if your sample is too short you might make adjustments that are not warranted, but if the sample is too long you won’t make the adjustments soon enough. There is no substitute for your gut feeling when you are just starting to track how well your process is working. The trick is not to be alarmist, and make proper adjustments. It’s like learning to drive for the first time. You either make too many large adjustments and overcompensate, or you make too many small adjustments. The good news is that you aren’t going to crash right away.

There are a few things that process people (you know those heavy process proponents) forget to look at while they are testing their process. How much work is needed to feed the process, vs. how much work is spent actually making deliverables? If you need 5 people that do nothing other than track the project’s progress when you have a team of 3 developers generating code, there’s something a little off-kilter. Notice that I said the 5 people are feeding process. Ensuring you have a quality product is work that’s done for the deliverable. Ensuring you have a quality code review is not. That’s “meta-work” or work about work. It’s stuff done to feed the process. Even the discipline of code reviews can be brought into question as long as you gain the benefit another way. A cod review is merely a means to both mentor other team members and ensure the quality of the product. If your process handles those benefits in other ways, then you don’t need a formal code review.

Fixing a Broken Process

If you are like me, then you really won’t wonder about how you fix a broken process. You just make the changes on the fly and the process evolves. You know these “lessons learned” meetings people have that dig up all the surprises and issues that we ran across? Are you merely identifying lessons, or are you actually learning them? If a technology choice turned out to be bad, how can you make sure the same mistake doesn’t happen again?

You haven’t really learned a lesson unless you did something to correct it.

If you discover that something you are doing isn’t lending any value whatsoever, you shouldn’t be doing it anymore. The advantage of changing your ways vs. logging issues is that it actually fixes the cause of your heartburn. Logging an issue helps you vent and get things off your chest, but it’s still there until you actually do something about it. That’s why the traditional “lessons learned” meetings don’t work. They let people vent, and then nothing is done about it. “Yeah, that was painful. We’ll be doing it again next go ‘round too.”

One of the biggest lessons I learned is that waiting until a “lessons learned” meeting to vent is waiting too long. If you are experiencing some heartburn now, fix it now. If you spend more time collecting numbers than you do using those numbers (um, I mean metrics), then just how important are those numbers in the grand scheme of things? Can you find another way of collecting those numbers? It’s funny, but machines are much better about collecting them than people are. There’s probably some way of making those numbers be a byproduct of how you do things. In essence, if you can make your tools support the way you do things and keep track of the numbers for you, you are better off. As long as you are depending on people to actually log numbers, you are depending on the most unreliable source for numbers. It’s a pain to keep track of them. Even if we only need to type them into a form, it’s still a pain to keep track of them. Let your tools do all the data entry for you.

The bottom line is prove you need to change, change, and then prove your change is helping. It’s TDD for process. If you see a bad trend and the process is the culprit, prove it. Then decide what a good trend would be. Make your changes and see how close you are to the results you want. You may find that your change is “close enough”, in which case you are done. Of course, you may find that you just introduced more work than the way of doing things, in which case you revert back or make a different change.

Test Driven Development 101

Berin Loritsch — Thu, 03 Jul 2008 11:47:00 +0000

I’m back after a long hiatus, and I’m probably talking to the air right now, but that’s OK. For the two or three of you actually listening to me, listen on. We have a number of projects of different sorts at the company I work for, and you’d be surprised at how few do test driven development—and how few even write unit tests. In this day and age, not writing tests that can be automated at all is inexcusable. At the very least, the tricky stuff should be thoroughly tested. This article is for anyone who is either skeptical about or interested in Test Driven Development. That includes managers as well as developers.

What’s the Problem, Man?

We all ( at least should ) want to write quality software, and we will take this as the “given” in geometry. Since we want to write quality software, how do we do it? In the early cowboy days of software engineering, it was painful to write code. First you did all your planning, wrote what you hoped would work, printed the stacks of punch cards, and then loaded it on the main frame. Which explains all the texts on the huge design up front methodology. However, that was before my time. When I first started, we wrote a little, ran the software, and debugged. Which explains why debuggers were so important at that time. However, times have changed. We now have a plethora of unit testing frameworks and maintainable build scripts to incorporate the tests into the build process.

As soon as we ran into some hard problems that really couldn’t be completely designed up front (like TCP/IP stacks), we developers had to figure out a way to make sure things worked properly. I mean, the spec is pretty complete, but there are a lot of details and practical limitations imposed by hardware that you won’t find in the spec. If you attempted to alter the spec to include all these corner cases, you would also lose any way of understanding how it is supposed to work. This is how the automated unit test was born. All these corner cases had to be accounted for so that future changes to the code won’t break the existing functionality. I think everyone recognizes the importance of testing. It’s just how, when, and where testing happens that people disagree on.

Another problem that is often brushed under the table is code slipping in that doesn’t need to be there. How often have you tracked down a problem only to discover code that was never supposed to exist be the culprit. You remove the offending code, and violá it works! The code could have been there from old legacy requirements that no longer apply, or it could be a developer without experience over thinking a problem. Nevertheless the code is there and it is causing problems.

If you adopt a clean as you go philosophy to developing software, you had better make sure you don’t accidentally breaking anything as you refactor your code. Even with “safe” refactoring, there is an inherent risk that you can inadvertently break something you didn’t think you would. If only there was a way to make sure all the important functionality keeps working…. Oh yeah, you do have a full test suite don’t you? Oh, it didn’t get written because you were under the gun and you were on a roll? Too bad.

Test Driven Development (TDD) was designed to not only address these issues, but to instill a discipline so that your unit tests would get written. Let’s face it, all people are lazy. It’s in our nature to not do anything we think is a waste of time. Sure we’ll do a little work now to avoid a bunch of work later, but we need to know it really is going to avoid a bunch of work later. What some people fail to realize about TDD is that the time will be spent somewhere. Either you write your tests up front or you spend time in a debugger later. Either you prove that your approach will work now, or you do it later. Either you break up your work into testable chunks now, or you attempt to do it later and fail at it.

OK, So How Does It Work?

At its heart, TDD is pretty simple—you simply perform a prove, fix, prove cycle. First you prove it doesn’t work . Then you fix the problem. Finally, you prove your fix worked . If you are lucky, your first “prove” step will prove the code already handles what you were thinking about. Write the test anyway, because you need to make sure that any changes will still support that test case. It’s fairly easy to see how to perform the mechanics of TDD, but less about it’s design implications without a little more explanation.

One of the side-effects of writing your tests before you write code is that it makes your code easier to test. Remember, people are lazy? Since a proper unit test sets up the environment and checks the effect of the call after, we make it easy to set up the environment. In fact, the less we rely on network connectivity or environment variables, the better. If a bit of code can be tested just by passing objects into it and examining the return value, then you aren’t going to be overly clever in your implementation. Easily testable code, also happens to be more modular. If you can pass in a mock object for something that would normally talk to the network so that you can have the mock imitate the situations you would encounter there, you can more easily test just the small unit you are working on.

Unit Tests vs. Integration Tests

In the best of all worlds, a project would have both. Unit tests make sure that the smallest unit (such as a method on a class) is doing what we expect it to do. A proper unit test also tests only one aspect of that method. It’s not uncommon to have several tests for the same method to make sure that all the corner cases are taken care of. Integration tests make sure all the different units work together like we thought they would. A unit test uses mock objects to isolate the thing we are testing from everything else. An integration test sets up the complete environment and runs the test against that environment. They are different tools for different problems. To do TDD, unit tests are required, but additional testing is a plus.

More often than not, code that is properly unit tested will work just fine. However, there are some issues that only crop up when the whole system is put together. Perhaps there is some race condition, or some complicated event loop that only appears in certain conditions. Once you track down the cause of the problem, you can write a unit test to reproduce the condition that caused the mess in the first place. With the new unit test, you fix the code, and everything should work in integration again.

Many times, the integration tests are all done manually. The challenge is that it is hard to set up a complete environment, test the user interface or system messaging, and evaluate the results automatically. The problem is that over time the number of tests that people have to do for a release becomes daunting. People are less picky than machines. If there is a tool to support integration testing like Selenium or some other testing framework, use it to at least catch regression issues. You know those issues where you accidentally break something that used to work when you add a new feature? Anything that was working and gets broken needs to be tested every time. Machines are good at doing rote repetition like that.

Battle Rhythm

When you sit down and start doing TDD, you’ll develop a battle rhythm. Most IDEs these days have support for running your unit tests without going through the whole build process. It’s pretty convenient, and it makes TDD a lot easier to do. So, you’ve got a new requirement and you need to get it working. It’s good to have a general idea of where you want to go, or how it is supposed to work, but don’t be a slave to that idea. We start writing the unit test at the easiest place it is to begin—whatever that may be. I personally find it is best to start with the happy path (the path where everything works as expected). For example, look at the pseudo code below:

Test String is a URL
--------------------
1. Use the string "http://bloritsch.d-haven.net" 
2. Pass the string to the String Utility "isURL" method
3. Assert the response is "true"

Of course, it’s pretty easy to make this one test pass. All we have to do is write the StringUtility.isURL() method to simply return true. No evaluation or anything. When we run the test, we prove that solution is good enough for now. So we need to start thinking about the next test. What if the string is not a URL? So we add the next test:

Test String is NOT a URL
------------------------
1. Use the string "I'm not a URL, ignoramus!" 
2. Pass the string to the String Utility "isURL" method
3. Assert the response is "false"

Now we’ve proven we have some work to do. So we change StringUtility to return true if the string starts with “http:”. It’s the simplest thing, right? But what if we want to include SSL encrypted URLs, or mailto URLs? So you add tests for them, and make them pass—without breaking the other tests you’ve written. All these tests are cumulative, so while they may have been extra work at the beginning, they can save your bacon later. Don’t forget about those corner cases, what if the string is null ? Etc.

By the time you are done with this method, you’ll have done the following things without even realizing it:

Documented what you consider a URL and what is not a URL (design documentation side-effect)
Proven the design works (design proof side-effect)
Tested the implementation (implementation proof)
Provided a safety net to do refactoring (supporting implementation malleability)

Sure the method is just a part of the overall design, but you’ve thought about and decided how the method is going to be used from the perspective of someone using the method. It’s a shift in thinking from being the “implementer” of the method, which usually results in code that is easier to use elsewhere. You’ve also introduced a level of trust in this method that you wouldn’t have if you just reached for that regular expression you found on the net to determine if something is a URL or not. You’ve also introduced a boundary where the implementation can be as simple or complex as you want—but code that uses the method won’t care about those details.

The battle rhythm of proving, fixing, and proving actually improves your development speed. It may not seem like it at first, but by testing all along the way we’ve minimized the time we will have to spend in a debugger. The ramp up time is a little slower, but as you get your battle rhythm going, you stay at a constant pace. Without TDD, I find myself working with bursts of productivity interrupted by long periods of finding out exactly where I went wrong in a debugger. With TDD, I find myself working at a steady pace, and those occasions where I missed something I spend much less time in the debugger. Once I’ve discovered the culprit, I add the test case that reproduces the error condition and then make it work. Now, when I refactor code I can make sure I don’t reintroduce the problem accidentally.

Silver Bullet?

There is no silver bullet, and no golden hammer that will make things work perfectly the first time. There are only tools that help you get closer to the ideal. TDD is a tool that helps improve quality from the start. Most detractors of TDD look at the claims of documenting your design as being false—or at least unreadable to normal people. I may give them that argument, but TDD isn’t about documenting design, it’s about building a better quality product with the minimal amount of investment. It’s about improving your productivity over the course of a software project. It’s about reducing the number of “doh!” bugs to virtually none saving your brain cells for the more complex problems. Finally, it’s about minimizing the risk involved in refactoring or even rewriting your software.

All of these benefits are things that the text books say are a good thing. It’s also done in a way that is less painful to developers. Writing documentation is a pain in the butt, however, writing test cases is something that directly benefits the developer. It benefits the project over it’s period of performance. Bottom line? More bang for the buck.

No Fear

Berin Loritsch — Thu, 01 May 2008 00:24:00 +0000

No Fear

How often do you see something cool, and take a picture of it? How often does it resurface 60 years later? Yep, this picture is another from the set of pictures my grandparents took around 1949. I think it is quite telling how no one thought it strange to take a camera to a pool back in the day, but now it’s an international crime.

No doubt this gentleman was showing off for the ladies. No matter how strong you are, you can only hold a pose like that for so long. Without all the modern gadgetry of today, my grandma was able to take this picture quickly enough. When photographing people you do have to be ready. The camera was loaded, and probably set for a reasonable exposure given the time of day. All that was needed was to cock the shutter (if it wasn’t a press type shutter that was self cocking) and release it. Advance the film and be ready for the next one.

Is there anything that could have done better? Absolutely, but what’s done is done. I think in this instant age where everything is done for you, the effort to retry is so little that people tend not to be as critical as they should be before pulling the trigger. The really good picture is lost in a sea of mediocre pictures, and will likely never see the light of paper.

Quite frankly, quantity is the enemy of excellence. I’ve taken literally thousands of pictures, and more than half of them are really good—some excellent. However, the pain of going through them all will likely cause them to never really get any special treatment. Wall space is more precious than album space, which is in turn more precious than hard drive space or negative storage space. While I publish far fewer pictures and take far fewer pictures now, the ones I do take are on average better than when I took several at a time. This fact doesn’t change whether I shoot digital or film.

Don’t be afraid not to take a picture if you can’t make it special. Have you ever taken a picture of something you thought was amazing, but after you took the picture it looked so-so? I know I have. Have you ever taken a step to either side or gotten lower or higher to reveal on film (or digital frame) what you were experiencing? Do your walkabout quickly to get in position if you can. A mediocre picture of a spectacular event is is more frustrating to me than not having the right picture of the event. I’ve not taken pictures because the moment passed before I found the right position—but I’ve also learned from that experience. I can better anticipate the right perspective now.

Don’t be afraid to make your own decisions about what you like and don’t like. There’s lots of opinions and guidelines about what makes a good picture. However, if you don’t like a picture that follows the rules then you don’t like it. Break the rules and make something you do like. That’s when you develop your own style.

Don’t be afraid to try something different. Whether it’s going old school or new school, you can only grow by incorporating new tools or processes. Just make sure you don’t try too much too quickly. Introduce yourself one bit at a time to the new stuff. Build on what you’ve learned so far and go a step further. Don’t spend thousands of dollars on equipment you’ll never get around to using. As you add to your equipment, learn to use the new stuff properly before you get the next thing.

Lastly, don’t be afraid to enjoy what you do. If all you are doing is worrying about how to make your equipment pay for itself with jobs then it’s only a matter of time before you get burned out. Find something that you enjoy, that relaxes you, and don’t worry about trying to make it pay for itself. Just have fun.

Printing Family History

Berin Loritsch — Thu, 24 Apr 2008 02:42:00 +0000

Test Strips on Oriental VC FB Paper

I got it stuck in my head that I would print all the negatives that I inherited from my grandparents. These are a treasure trove of years gone by that capture a world we have forgotten about. Along with these negatives comes some inherent problems. The negatives are pretty near 60 years old already, and were made before the film base was standardized on something that doesn’t deteriorate so quickly. The film is either Kodak Plus-X or Kodak Tri-X (they had several rolls of each). None of it is safety-film which means it isn’t. The film format is 127 film. That means it is not quite as big as modern day medium format or as small as 35mm film. The negatives are about 4cm wide with some frames 6cm, some 4cm, and some 3cm. I can’t find proper sleeves, and the film has a nasty curl due to being stored rolled up in a plastic baggy.

Archivists will tell you to make sure you store the film in archivally safe sleeves that are acid-free, buffered, lignin-free, etc. Lignin is found in paper, cardboard, etc. Rubber-bands deteriorate and the byproducts also help break down the negatives. These negatives were stored in a plastic baggy with the original cardboard boxes when available (which is where I got the dates from), or wrapped with rubber bands that were disintegrating. I can’t say it’s archivally safe, but there is no more cardboard or rubber bands anymore. Due to the storage conditions, some of the negatives are damaged, but most are OK for now. I really need to find out how to copy the negatives on to standard film. I’d rather step up a size rather than down, because I don’t want to lose any more information than I have to.

All that said, several of the negatives are in good shape and almost all are printable. The picture at the top of this article is one of those pictures. As you might expect when the person taking the picture (my grandma) is not a professional photographer, many of the negatives present significant challenges. This negative is losing contrast to the shadow detail, so I have to bump it up on the paper. This picture requires a #4 contrast filter to bring out any definition. I may have to go up even more than that, but I think I’ll live with this. The quality going to limit how much I can enlarge the picture. The picture would have been even more striking if grandma thought to reflect a little light up underneath this gentleman. A large sheet of white paper would do the trick nicely. Based on the angle of the highlights and the shadow under this guy, it was probably taken around noon.

In my insanity to grow my darkroom skills, I decided to use fiber based (FB) papers. They are similar to resin coated (RC) paper in the sense that it is paper, and it uses a gelatin based emulsion. Other than that they are completely different. When RC paper gets wet, it doesn’t feel any different. The chemicals only penetrate the emulsion, and thanks to the resin or plastic coating on the paper it does not penetrate the paper. RC papers are therefore much more convenient in that the process is a whole lot quicker. FB papers feel different once they are in the solutions. The paper actually gets wet, and you can feel the fiber of the paper much better. Glossy also looks different. The gloss on a FB print is virtually unnoticeable until the print dries, where on RC paper it is ever before you. It seems that FB paper is more susceptible to dry-down effects. However, FB paper does take toning better than the RC paper cousins.

Bottom line, this will be a good learning process and I will be able to pass on my personal family history to another generation. Part of the process will be making digital copies as well as copies of the negatives.

Presque Isle Lighthouse

Berin Loritsch — Thu, 17 Apr 2008 14:01:00 +0000

Presque Isle Lighthouse

Out of only three hours of photography, I got four pictures with my large format and a roll of small format pictures. The trip was primarily to support my son’s basketball team, but I was able to get some time aside. Even in the winter you can find some truly wonderful pictures. You just need to be able to look properly.

This particular subject was a bit challenging. If I went to the beach my view was obstructed by dense dead trees. However, here I had the sun coming through gray clouds, almost backlighting my subject. The bright spot in the upper right corner is where the sunlight was coming from. My Rodenstock 26cm super-aplanat lens was made in 1935, so it doesn’t have all the improvements in lens manufacturing made since then. It still resolves an incredible amount of detail.

This particular picture is not a scan of a print, but of the negative. In order to overcome some of the problem areas of the picture I had to do some digital dodging and burning. I have to say that I don’t enjoy doing these things digitally because I think in terms of stops, not percentages. Nevertheless the light refractions in the lens obscured the top of the lighthouse so I had to do something. I dodged it about 30% which was enough to make it more substantial without making it look fake. I dodged the edges of the picture slightly differently for each edge due to the way the tones lay. The right side with the tree didn’t need as much burning as the left side. Additionally the sky required more dodging than the ground. Lastly, the sky where the sun was peaking through required some more control so I burned that top corner in an additional 40%. The tree in the middle had a bit too much weight, so I had to dodge it. Unfortunately, the scan didn’t have any more detail to give me. An optical print will help me out there.

I played around with different toning options and I found that selenium just didn’t suit it very well. I wanted a cooler look to it, so I went for a simulated gold tone. I did try a sepia tone as an alternative, and I was pleasantly surprised at how nice that would look—but went with a straight gold tone.

Sometimes playing with a scan of a negative digitally will help with visualizing what you can do with the optical print. Looking at this picture, I can see how I should have changed my angle a little bit. I wanted the large tree on the right to help frame the picture, but the tree in front of the light house is not at a good angle. I probably should have set up in the brush on the right side of the large tree. Sometimes you have to choose between personal safety and the perfect shot. Traversing snow and ice while carrying several pounds of equipment isn’t the best idea.

When I print this optically, I will definitely have to put it on 11×14 or larger paper. It needs the breathing room of the larger area so you can get up close and see the detail. The 11×14 also might cut off the little bit of the sign on the right.

How much does it really cost to do film?

Berin Loritsch — Thu, 10 Apr 2008 23:34:00 +0000

I’m not going to argue about quality, process, etc. It’s just a pure look at the cost of film vs. the cost of digital. Let’s be honest, there are some real gear junkies out there so we aren’t going to talk about the people who change their camera every week for half of a megapixel more resolution. We’re going to talk about real people and real situations. So first off there are certain costs that are the same. Your lenses and your flash units are not likely to be any different with film vs. digital at any format size. Medium and large format cameras where the shutter is in the lens use a standard cable release for remote operation. Small format cameras like to get you to spend more money for the same thing so a remote for your film camera may not work for your digital camera. What’s worse is that a remote for one model of a company’s camera won’t necessarily work with a different model of the same company’s camera. It’s still a constant expense, so go figure.

OK, so now that we got that out of the way, what’s different about digital vs. film (other than the fact that one is digital and the other is film)? First off, the cost of the sensor for a digital camera is very high in comparison to the “sensor” for a film camera. One is several hundred (or thousand depending on format) dollars, and the other is less than $10. That’s right, film is a light sensitive material, hens it is a film camera’s sensor. The big difference of course, is that you can only use film once and you can use a digital sensor several times. That’s the rub. Your up front costs are going to be higher with digital, but over a given time your consumable costs will overtake that initial investment. That’s a fact no matter how you slice it. Digital also has consumables in the form of compact flash cards and hard drives. They are convenient in that they can store large amounts of photos, but dangerous because if the device fails you lose everything. That’s why you need more than one, and to back them up on other drives. With film, the negative is your storage device and it requires physical damage to lose pictures.

Small format cameras are a little worse than medium and large format cameras in the sense that you have to replace the entire camera when you upgrade. Medium and large format cameras have changeable backs where you can use the same camera for both film and digital, depending on the client and your budget. By the way, a digital back for a medium format camera is several thousand dollars. You can purchase several small format digital SLR cameras for the same price. For the sake of argument, let’s keep things in the realm of the small format SLR cameras.

A used small format film camera can be had for $25-$400 depending on the model you buy (consumer/pro, age, etc.). You can buy a small format digital camera for about $500-$900 depending on the model you buy. Add to that a compact flash card for $20-$50 depending on the size and speed you buy. So just how many rolls of film will it take to overtake the initial plunge? Again, it depends on what kind of film you use. Slide film is near $10 a roll, but if you do black and white film is around $3 a roll. The price of lab development also varies based on the lab and the type of film. Slide film can cost near $10 a roll to develop at a pro shop, regular color film can cost about $4 a roll at a pro shop or $1.50 a roll at Target. If you develop black and white film yourself it will cost you pennies a roll—definitely worth it. So you can see that the answer depends on a lot of different things.

Let’s say you are the extravagant type and you shoot Fuji Astia 100. It costs $5 a roll, but to get it developed unmounted it costs $6 a roll (mounted is $10). That’s $11 a roll. Now, let’s say you also you skimped on the body knowing you were going to upgrade to digital later. So that’s $25 for a cheap used camera. Slide film is typically very low grain and very rich colors. To produce equivalent pictures you’ll need a nice digital. Let’s go for the $900 model (roughly what I paid for my used Canon 30D). The difference between the $925 (camera and compact flash card) digital and the $25 film camera is $900, so it would take roughly 82 rolls (just under 3000 pictures) to hit the break even point where the up front cost of digital equals the same cost in film.

Now, let’s say you are shooting sporting events and you need to take several pictures in a row quickly. You’ll need a better film body so your up front cost is something like $400 for a used top of the line model (roughly what I paid for my used Canon 1N). You’ll also need high ISO film if you are shooting indoors, which means you are working with normal color negative film. You have a choice between Fuji Press 800 for $3.50 a roll or Fuji Pro-Z 800 for $5.50 a roll. Developing costs for a pro shop is about $4 without prints. Let’s call it an even $8 for simple math. Using the same digital camera from the last example, your difference is only $525. You can shoot 65 rolls (2300 pictures) before you hit the break even point. In sports photography that number comes up really quick. Digital is a clear winner here.

For the aspiring fine art photographer, black and white is king. You’ll want the nicest camera you can afford because you want to enjoy the process, but you are now shooting black and white film and developing it yourself. Fomapan 100 (a very nice film) is about $3 a roll, and to develop it yourself costs about $0.50 or cheaper a roll depending on the chemicals you use. That’s $3.50 total per roll, and for the sake of argument we will compare the same two cameras in our last example. You will have to shoot 150 rolls of film (5400 pictures) before you break even. Since this style of photography is slower paced, your digital gear might need an upgrade before you reach that mark. The film gear will be just fine for years to come. My personal belief is that film renders a better black and white image than you can get from digital. That’s my opinion, and you can take it for what it’s worth. If we took the cheapy film camera and the expensive digital camera the difference is even more drastic at 257 rolls (9252 pictures).

For the casual shooter, film provides a great starting point as you get your equipment together. For the more prolific types of photography such as sports and event photography, digital is a clear winner. It will pay for itself rather quickly. For the fine art photographer, you can’t go wrong with film. There is no real demand on quantity of pictures, and the archival quality of film has been proven based on history rather than simulated projections. There are plenty of other reasons to choose film, but those are all personal choices. The truth is that digital cameras (not the cheap point and shoot variety) cost a lot more in the initial investment, and film has a continual cost you need to incur as you take pictures. Eventually, digital will become cheaper as long as you don’t keep upgrading your body. I use both, personally.

Pyro Based Film Processing

Berin Loritsch — Wed, 02 Apr 2008 02:21:00 +0000

Ice Dunes

One of my favorite combos is Efke 25 and WD2D+, a pyrogallol based developer. Pyro (what we darkroom nuts call pyrogallol) based developers stain the film, and the staining action increases with the density of the silver. What this means in layman’s terms is that you get nice, clean sharp edges and your open spaces are smoothed out. You’ll notice that there is almost no grain.

Let me give a little more technical information before I dive into the fun stuff. Efke is a traditional emulsion film that has orthochromatic characteristics, although I’m not sure if it is classified as an ortho film. Basically, it’s not that sensitive to red light. At ISO 25, you may think it’s pretty slow but my 4×5 Calumet has to be mounted on a tripod anyway. You’d be surprised how easy it is to find a good exposure setting even when the ISO is so slow. Wimberly’s Developer #2, Version D+ (WD2D+) is a staining developer with a hardener built in. Unlike other pyro based developers, WD2D+ provides an orange stain. All pyro developers are more toxic than regular developers, but if you take reasonable care you’ll be fine. If you have good darkroom habits you’ll be just fine.

Not every scene lends itself to pyro, and sometimes you actually want more of that good, honest grit. Typically, I reach for the pyro when I want delicate highlights and clean edges. I commonly use it for snow scenes, or if I have smooth curves like silk sheets or something of that nature. I find that a negative can have a tremendous amount of detail that the enlarger picks up but your eyes don’t. Again, it’s not a magic bullet. After using it yourself, you’ll get a better feel for how it develops your pictures. WD2D+ tends to make things “cleaner”, and perhaps a little more sterile—but not in a bad way. Contrast this with Rodinal which also has great acutance (sharpness) but gives a grittier, more honest feel.

This particular scene, Ice Dunes , was shot at Presque Isle in Erie, Pennsylvania. I took meter readings on the darkest spot and the brightest spots and found that there really wasn’t a whole lot of contrast. I placed the shadow reading on Zone III and the highlights fell on Zone VII. Yes, I use the zone system—but I’ve tailored it to the way I think. It’s a tool to help get what you visualize to reality. I could have done N+2 development, but pyro really isn’t made for pushing film. I figured that there might be some detail that would have more shadow and more highlight than my meter would pick up.

The picture was scanned in using my Microtek i800 flatbed scanner, scanned at 16 bits. Once I got in the computer I played with it in the Gimp giving it some levels adjustments, burning the sky a lot, and the ledge a little bit. I dodged the open area in ice to make things stand out a bit. Finally, I gave it some digital toning of my own. I consider this a practice round for the darkroom which I have yet to use in a long time.