Kris Kemper

Working on some ruby code for a little while, I had an idea for a tool that would be useful.

Basically, what I want is an inspection tool that also has a bundle in textmate, so that I can see the history of objects that are created, as well as interactions in a form that is searchable and that quickly shows what really happened. It would be like having debugging on all the time.

The goal of this tool would be to allow developers to view what really happens with the code when it executes. Sometimes finding the source of bugs is difficult because statically analyzing code is not the easiest way to predict the future state of an object, or to predict the interactions between objects. You don’t really know what happens until the code executes.

Nor is traditional debugging an efficient way to get the information that you need. You have to set a break-point, add in a line to call the a debugger, or even print out some information in order to answer a question about the actual execution of the code.

What I want is a tool that records a wealth of data about the actual execution of some code, such as when I run a test, or initiate an action from a controller. Then, I would like to be able to filter/query that information to get more precise information.

For the inspection tool, I’d like to know things like:

- See the actual methods and fields of a class or object instance at the beginning and end of code execution
- See all calls made to an object, or a specific instance of an object
- See all callers of a specific method of a specific object type or object instance
- Detect changes in the structure of an individual object that happens, such as methods being added or redefined after the object is initialized
- View all changes to fields of an object
- I would like to see the order that objects are created in. I would like to see when all objects of a certain type were created, or objects that respond to a specific method
- I would like to see all interactions between 2 objects
- I would like to be able to further scope the search, so that I only see information within the scope of a specific method call

Preferably, I would want to be able to view all of this information after running the code one time. And then be able to enter some search criteria into a form and have it reduce the amount of information to match my search criteria. Then, I can tweak some starting data in a test, and then rerun the test and get a new set of information to query.

I think that most of this information could be obtained by creating a Module to intercept all method sends to every object, and save some data about the context of the call when it’s made. Then, a client tool could parse the output, and allow a developer to query it.

I tried to do some googling to find something like this, but all I found were standard debugging tools, which I don’t think have the features that I’m looking for. If anyone knows of something that can do what I want, let me know.

In Java, iterating over a collection and collecting some objects based on a condition is a classic example of something to put into a method. Here is an example:

In Ruby, you can do this in one line.

It’s lovely how much more succinct that operation becomes. It can actually get more succinct by using Symbol#to_proc:

There is still the question of whether to move this to a method. Now, moving it to a method doesn’t reduce multi-line duplication the way it would in the Java example; there is only a minor amount of single line duplication that can be reduced.

The resistance I often get to refactoring a single line to a method is that it creates more total lines in the file with the def/end lines and spacing. Also, it takes a slight amount of effort to do the refactoring, and some developers won’t refactor unless the need is glaring and obvious.

There are still important reasons to move this to a method, and those reasons are better readability of code and reducing duplication of expressions. Without the refactoring, you’ll see code that looks like this:

After the refactoring, this is what it would look like.

It’s a minor point perhaps, and I’m sure that I could come up with much more excessive examples, but I just wanted to focus on a simple example. By replacing the expression with a symbolic reference, a method in this case, you express in English something that is a programmatic operation. This improves readability quite a bit.

Also, there is the additional benefit of abstracting on the concept of expired claims. By having multiple places using “all_claims.select(&:expired?)” to express expired claims, you duplicate the implementation detail that expired claims are derived from a larger collection of claims. This may not always be true, and a change in that derivation results in a change in many places.

Perhaps the question here is how DRY should you make your code. I’m still undecided on this on this point, but I think that the amount of work that it takes to reduce duplication to this level is minimal, and the result will be an important part of a pristine codebase.

I recently saw an interesting and polymorphic way to get rid of using a case statement when using enums. This is possible by defining a method for each instance of an enum.

I’m sure that you have seen code like this:

And then somewhere in the code, you might see:

This is a common smell in a code base where client code has logic that should be better encapsulated. Now, whenever someone adds a friend, they are going to have to search for references on Friends and add a new entry, or they are going to get a RuntimeException from the switch statement. In a well tested codebase, there is probably going to be a unit test that asserts that all Friends have best friends. In any case, the switch statement in the client object code is not great from an OO standpoint and it creates a maintainability issue.

The first refactoring is to move all Friend related logic to the Friend enum where it belongs.

Now, we can just ask the Friend who their best friend is.

Nice. Still, I’m not wild about that switch statement. Developers still have to know to update it, and really, I’d rather not even have to throw an exception because it was misused. It would be better if the structure of the code did not allow misuse.

Here is an example of how to do this:

Then,

Great, now we know that when someone adds a new friend, they will immediately be confronted with having to supply a best friend. My only issue with this approach is that all the method definitions become verbose when you introduce many methods like this. I tried different approaches to solving this problem, but due to the enums referencing each other, I was not able to do a different approach.

Here is an example of what you can’t do:

This won’t work because you can’t reference Chandler in the enum definition for Joey. The Chandler Enum hasn’t been defined yet, so this won’t even compile. However, you can “trick” the compiler by fully referencing Chandler using Friend.Chandler;

However, the result is not what we want:

Joey.bestFriend(); –> null
Chandler.bestFriend(); –> Joey

Even though I can reference the other enum instance this way, it resolves to null. The reason lies in the fact that when the Enum is compiled, each instance is a static final field, and initialized in a static block. Here is a snippet of the generated code:

Interestingly, I can write a program that tries the fully qualified name for explicit static constants, and it works:

But if I use a static initialization, it doesn’t:

Interesting. The compiler is smart enough to resolve the correct value when you don’t use a static initialization block. Back to my original example with Friends. The next attempt was to create an anonymous constructor (actually, an instance initializer) for the enum instances and see if I could get what I want:

I had to remove the final from bestFriend, since I’m inializing the value when the object is instantiated using an instance initializer. This compiles, and seems like an okay approach. My hope was that the references to other enum types would get resolved in much the same manner as in the case of creating a method that returns each one. Interestingly, this doesn’t happen.

The reason is that even though I am using an instance initializer, it’s being called from a static block since the instances are created in a static block. Turns out to be a naive attempt. Here is what it ends up looking like when the enum gets generated as a class:

Oh well. That’s as far as my experimentation went. I’m satisfied that I can at least create an anonymous subtype of an enum that returns the correct value, but if anyone has any ideas on how to do this in a cleaner way, let me know.

I wrote some tests a few weeks back where I had to sum up a bunch of values on a collection of objects and assert that the summation happened correctly. A naive way to do this is to build the test objects with all the values equal to 1, sum them, and assert that the total is the same as the number of objects created for the test.

In this example, you could test calculateClaimTotal by creating 3 claims with amounts = 1, and assert that the total is 3.

This may seem sufficient for a simple summation, but it becomes more flawed when the summation becomes based on business rules. Now, if the values to be summed are all 1, you can’t differentiate which rules were enforced by looking at the resulting number directly.

Now, we want to be able to differentiate that the active claims are the ones that get summed. This can become a bloated assertion to make. For instance, you can extend the test objects and count invocations on getAmount(). Then, you can assert that only the objects you expected where used to calculate the total.

A much simpler way of asserting that the objects that you expected were the ones that were used is to use amount values that, when summed, always have a distinct result. This is achieved by using numbers that map to distinct bitwise values:

00001 = 1
00010 = 2
00100 = 4
01000 = 8
10000 = 16

There is no way to add any of these numbers and have them be equal to any other summation of a subset of the numbers. This is because addition of 2 of these numbers is equivalent to an “or” operation on the bits of the numbers:

00001 = 1
00010 = 2
+__________
00011 = 3

This characteristic allows me to identify exactly what claims where used in the summation, because the resulting value could only occur from the values I expect:

Claim 1 is active with value = 1
Claim 2 is inactive with value = 2
Claim 3 is active with value = 4

I can assert that calculateClaimTotal will return 5 here, and that 5 will occur if and only if Claim 1 and Claim 3 are the ones used for the summation. Essentially, a bit location set to 1 instead of 0 will uniquely identify the object that the value came from.

I call this an old school testing technique because these days, there is not a lot of bitwise math that occurs in the course of programming. Back in the day, high performance C programmers would use bitwise operation often, and api’s such as the win32 api used bitwise math as part of api.

Even in today’s fancy world of high level abstraction, sometimes it takes a smooth low level trick like this one to achieve the most succinct code.

Recently, Andy Palmer post a blog article called returning null considered dishonest.

I felt that the topic started to go down the road of enforcing a contract in order to prevent nulls. Checked exception are an example of explicitly adding new behavior to the contract. The contract details a response to certain parameters in the form an exception.

Taking a step away from checked exceptions, you have unchecked exceptions. Unchecked exception that are typed are especially pointless, as they weren’t declared in the first place, and generally shouldn’t be explicitly handled. If you do want to make contract enforcement with unchecked exceptions, you can throw RuntimeExceptions or do an Assert.true() at the start of the method to make sure that a method is called with then needed preconditions.

My issue is that you’re adding behaviour - behavior that was probably added somewhere else already. Every line of code added incurs an extra bit of cost in terms of maintenance. Super defensive coding strategies should be justified due to the merits of the given situation, but not used as a default behaviour.

Null’s are okay when they are not meant to be handed out as a meaningful response. Once you try to use null values to convey a value or a meaning, then you start seeing a proliferation of nulls and null checks.

For instance, I’m not advocating this:

Nor am I advocating this:

I’m essentially advocating this:

Don’t check for null, don’t throw exceptions. Just make sure that nulls don’t occur at the entry point to the system. Most of the time, you should just write your method to do stuff and make sure that the error conditions are handled in one place as early as possible to their introduction into the system, such as when the user enters some data.

Most code bases are not published to the public. There is a big difference between published api’s and internal code bases. With a public api, you have to create more of a contract, because you want to give your providers something that they can depend on. There are too many consumers for immediate communication and collaboration. In an internal codebase, you are your own consumer and supplier.

My point here is that I disagree with adding more code complexity to fix a problem that is generally a behavioral issue. Having to handle every possible unwanted condition of a method parameter becomes a method tax, creates duplication, and results in a lot of tests that aren’t testing the interesting stuff.

I often think about the qualities that separate the “good” developers from the “bad”, the skilled from the unskilled. I’ve met a wide range of developers over the years, from skilled and experienced developers to developers that can barely write code. There are a lot of people somewhere in the middle. Whenever I pair-program with someone for any length of time, it’s a window into how they work, and I can see firsthand the strengths and weaknesses of their programming style and work ethic. I can judge people on very specific merits from that kind of close interaction.

Depending on the project (or even the team) there may not be a lot of pair programming going on, and I can only judge people through a higher level observation. It’s not a great way to judge a developer for the most part - it’s hard to tell what they do on a day to day basis that leads to them producing their portion of the software. At this higher level of observation, you can generally tell how fast someone delivers features, and how many bugs people generate. Even then, it takes a lot of time and reasonably repetitive or comparable tasks before such measurement can be even remotely reliable.

With such limited information, I tend to make a quick judgment initially about people based on a “gut feeling” that I get from talking to the person about work. I don’t base many decisions on that judgment, but I tend to start people off at a certain level in my mind and I wait until they prove or disprove my initial reaction.

It reminds me of when I was in college and the semester was in the first week. There were some project/group based programming classes where we could organize into our own teams. Over the first week or so, we would have to form teams that we would have for potentially the rest of the semester. Without much to go on, I would talk to people and try to get a feel for their ability and work ethic. If I had a good feeling about them, I would ask if they had formed a group yet. If they hadn’t, one of the next questions I would ask was what grade they wanted to get in the class. It’s a very direct question and it’s usually easy to determine if someone truthfully wants to make an “A” in the class. The next question was usually to ask them what grades they made in previous classes.

One of my earlier professors recommended this as a way to align goals when building a team. If your goal was to make an “A” in a class, then build a team with that as it’s stated goal and get them to commit to it. I wanted to make an “A” in every class, and I was willing to work for it. I was hoping to find other “A” grade oriented people like me. If that couldn’t work out, I would hope that I could get “B” grade people and occasionally “C” grade people to produce “A” quality work.

I labeled people with a grade based on the grades that they made in previous computer science classes, as well as my own observations. They got either an A, B, C, D, or F. I found that people could often move about one grade higher under the right conditions, but would never more than that. So, a “C” developer would not produce “A” quality work. This isn’t that surprising, getting an “A” in college is as much about learning how to get an “A” as it is about personal ability and work ethic. Learning how to get an “A” takes practice.

All characteristics aside, there was one quality that I found was the differentiating factor between an “A” grade developer and the other grades: Flawless delivery. In the classes that I took, getting an “A” in a class meant keeping a grade above a 90 for the entire semester (with a 100 being the max). In order to reliably accomplish this goal, you had to aim for a 100, and use the other 10 points as a buffer against minor mistakes.

There are 3 main factors to achieving flawless delivery of those projects: knowing what is expected from the graders (essentially, having clear acceptance criteria), having the ability to accomplish it, and having the motivation/desire to accomplish it. When your goal is flawless software, you get good at it after a while. When I was in school, I even found a deep sense of satisfaction when I submitted the code for my project knowing that I nailed it - that I was almost certainly going to get an “A,” and probably even a 100 point grade. I take it for granted, but one important activity that is worth mentioning is that that in order to accomplish flawless software, you have to personally and thoroughly test what you build to ensure that it works.

I kept that behavior after I got out of college. When I complete a feature, or a set of features, I like it to be as close to working perfectly as possible. I don’t want to see any bugs come out of it, even in the first round of QA. In fact, if I do get bugs in the first round, I make a mental note as to why It happened and consider how to prevent that in the future.

I generally don’t differentiate between missed requirements and technical bugs - as a developer, I play an important role in making sure that it is understood and agreed upon as to what I will be making. I’m not advocating that details specifications - I may build the feature and demo it to a product owner. Regardless, when I show that demo, I do my best to make sure that demo works flawlessly.

As a final note, striving to produce flawless software becomes significantly more important when a software team frequently delivers to production. As a developer, you have a great influence in whether a bug makes it to production. In some cases, you will know areas that are risk for breaking due to a change that non-developers (or even other developers) wouldn’t guess. It’s as important to ensure that you don’t break other parts of the system as it is make sure your code works; Often, it’s far more important.