8th Light Blog

Authors

Micah (15)
Justin (1)
Paul (15)
Jim (10)
Eric (15)
Doug (15)
Eric Meyer (1)
Colin (8)

Rails Migrations and Subversion

by: paul | September 28th, 2006 | 3 comments »

In rails, migrations are generated like so

paul-pagels-computer:~/RailsProjects/project paulpagel$ ruby script/generate migration CreatePacketTimestamp exists db/migrate create db/migrate/013createpacket_timestamp.rb

This creates a numbered migration with an up and a down schema direction. This has been incredibly helpful when dealing with the schema changes. The problem our team has found is doing migrations with subversion.

You run migrations by

paul-pagels-computer:~/RailsProjects/project paulpagel$ rake migrate

Which looks in the schema_info table to find which version of the schema your database is representing, and updates it to the most recent version (the highest number).

The problem comes into play when you have multiple people making migration scripts on their local machine at the same time. If two different people did a migration at the same time and committed them you would end up with two migrations. Which one gets run?

I am not sure how to solve this one yet. I have been loving rails, but this has already has put a dampener on it.

Ruby and Human Compilers

by: paul | September 26th, 2006 | 0 comments »

In Paul Grahamâ€™s Book, Hackers and Painters, he talks about patterns and Human Compilers. I started to think about how some traditional Object-Oriented patterns are implemented in different languages. What problems do these patterns solve?

Paul Grahamâ€™s human compiler is an interesting concept I would like to explore more with relation to ruby, which is what I have been working in lately. The object-oriented design patterns I have been taught are intended for one reason, to increase productivity. These patterns produce well decoupled, easily testable, clean, and reused code that makes it easier for developers to extend and maintain an application. It is the mind of the developer that produces this compiler to be able to read and interpret these patterns to perform workflow optimizations. When I see a pattern in the code, I can easily navigate the implementation and the problem that it is solving. I can hold the entire context in my mind to work on that piece of code. This human compiler is what allows me to move quickly through an unfamiliar piece of code. Moving to dynamic languages, I see the context I need shrinking in the traditional way, holding onto patterns. So I started to wonder, could we build patterns into the language better, or eliminate the need for them? Are the GOF patterns mostly just a method of satisfying our human compiler for statically typed languages?

I have suspicions that moving to ruby from C++/C#/Java will eliminate the need for many of the design patterns we have coveted in those languages. I would like to explore a few of them to prove this thesis. I want to look at the patterns that have helped make testing/design/decoupling better and see how they are different in ruby. Also, how can we transfer the values behind those patterns? The patterns were all based on good decisions, and can we learn anything from them or should we throw away the thought process that made them necessary?

Lets start by taking the most commonly used pattern, Abstract Server. Writing in C#, I need to create interfaces to make sure I donâ€™t violate the Interface â€“Segregation Principle and depend on concrete classes. This becomes a big deal in a statically typed language because you donâ€™t want to have to depend on a specific type. However, in ruby, you respond to messages of a class, which donâ€™t care what type the return values are. Also, because it is a compiled language, you donâ€™t want to have to recompile the clients of a class just because the implementation changes. In fact, in ruby, the Interface-Segregation violation goes away since there is no need for explicit interfaces to abstract, rather every class becomes an interface for itself.

Have you ever been working on a java/C++/ C# project and noticed an inheritance hierarchy that makes you twinge? Statically typed languages abuse inheritance by definition. Why do you need interfaces? Shouldnâ€™t an abstraction be one of behavior? In ruby, you send messages to objects, which is the same type of firewall, as each object acts as its own interface. However, since an inheritance tree got there, you need to decouple it since it is growing large and not maintainable. Or have you seen interfaces placed in front of a class for the sole value of abstraction. A good example of this I have seen is with Views in the Model/View/Presenter pattern. Something that looked like this:

public interface ISomeView
{}

public class SomeView : ISomeView
{//some implementation}

This uses the philosophy that the Views need to be decoupled from the Presenters. This is true, but the point of decoupled is missed. Decoupling is a method of using firewalls to hide the implementation of code from its clients (Abstract Server). How does this degenerate do this? It doesnâ€™t. I have seen projects where inheritance is used liberally and there are interfaces for everything. I have also seen projects where inheritance is used conservatively and composition is used for everything, to prevent the formation of highly coupled inheritance trees. Finding the proper balance in static languages is difficult, but it is also a problem that should not exist. In ruby, inheritance is used on a YAGNI basis, as you only use it in the clearest of cases. It makes inheritance a tool to be used rather than monitored for abuses.

In ruby, you only inherit through necessity of behavior rather than clarity for form. Inheritance in most static languages is used as a tool for design patterns to make the code easier to read/work on/maintain for the developers. This is unnecessary in ruby since it is built into the language. Ruby does it instead of your human compiler. Writing beautiful code in java meant making the code clean and decoupled. Inheritance is no longer needed to do that in ruby, as it only serves a utilitarian purpose. Form is just as important in ruby as it is in static languages, it is just expressed without using features meant to serve efficiency purposes.

Self Shunt

by: paul | September 11th, 2006 | 1 comments »

The self-shunt method of testing has been conflicting for me. Self-shunt is a good testing pattern to test observers/views. A colleague of mine has started to convince me that self-shunt has some serious drawbacks. I want to explore the different ways to address the same pattern and how they fit into the test process and the test content. Are certain patterns easier to write and certain ones have a better final form?

Lets look at some code from Michael Feathers self shunt paper (see bottom for link). I extended it to do the mocking examples. The user story we are working with is the name of an item must be displayed on the led when the item is scanned.

Writing all of the tests did not require a concrete window (Display). We didnâ€™t need to create the stub of the file to use; we could just use the interface. All the test patterns let the test be isolated in the test class/interface/production class triad. As a developer, it is easier for me to produce faster without quality loss if my context of thought is limited as much to the scope of the test as possible. Each extra window I switch is more contexts to deal with.

Here are three different tests:


public class ScannerTest extends TestCase implements Display
{
    private Item lastItem;
    public void testScan()
    {
        Item item = new Item("corn flakes");
        Scanner scanner = new Scanner(this);
        scanner.scan(item);
        assertEquals(item,lastItem);
    }
    public void displayItem(Item item)
    {
        lastItem = item;
    }
}

The first test is making user of self-shunt test. Self-shunt was a quick way to start writing a test. The implementation on the interface in the test class will give you a good idea on what the implementation of the concrete class should look like when you get there. Also, the test is simple and the syntax is expressive. However, the scalability is questionable. If you had more than one self-shunted interface in a single test file, it would be hard to start differentiating between which variables are used in which. Also, moving around the file to get a good sense of what a test is doing is misdirectional and distracting. Ideally, I want to see the entire test on one screen, so I can read it. If there were many implemented methods in a test file that were not tests or helpers, there is the potential to be confused.


public class ScannerTest   extends TestCase
{
    public void testScan()
    {
        Item item = new Item("corn flakes");
        Display mockDisplay = new MockDisplay();
        Scanner scanner = new Scanner(mockDisplay);
        scanner.scan(item);
        assertEquals(item,((MockDisplay)mockDisplay).lastItem);
    }
}
public class MockDisplay implements Display
{
    public Item lastItem;
    public void displayItem(Item item)
    {
        lastItem = item;
    }
}

Then I wrote the hand mock test. This test got rid of the clutter of implementing interfaces in the test and having local variables. Also, there are no external libraries needed, like a dynamic mocking library. The test is simple and easy to read. The biggest drawback is dealing with the hand mock test file. It is untested code that I have seen a tendency for behavior to slip into, which is disastrous. It can cause a bug in your tests that take too long to track down. Ideally this doesnâ€™t happen, but I have seen it many times.


public class ScannerTest extends TestCase
{
   public void testScan()
   {
       MockControl control = MockControl.createControl(Display.class);
       Display mockDisplay = (Display) control.getMock();
       Item item = new Item("");
       mockDisplay.displayItem(item);
       control.replay();
       Scanner scanner = new Scanner(mockDisplay);
       scanner.scan(item);
       control.verify();
   }
}

Finally the dynamic mock test was written. This test was the simplest to write as a matter of process also the fewest lines of code. I never needed to leave the scope of the test function. It was just setting up my expectations and letting the test run. As Micah Martin pointed out to me, the test execution seems backwards and unreadable with dynamic mocks. The verification statements are at the beginning of the method and the execution is at the end. This is different than all the other tests in the system that follows an intuitive flow cycle of build, operate, and check.

With a little investigation I found Michael Feathers paper on Self Shunt (www.objectmentor.com/resources/articles/SelfShunPtrn.pdf).

Sentential Testing

by: paul | September 7th, 2006 | 4 comments »

In a project I have been working on, we recently decided to allow wrapped assertions to customize our unit tests. Our purpose was to make the unit tests be sentential enough to explain the meaning of the assertion in the execution of the assertion.

We can’t get rid of all developer comments (variable and method names) because, if we did, we would lose the ability to easily read and, consequently, easily maintain the code. In fact, writing easily readable code is a primary goal of good practices, since it is directly correlated with making code easily maintainable. This is important because maintenance is the most expensive part of the development process. However, we must be cautious about writting comments, since they can often have the opposite effectâ€š less maintainable codeâ€š when they are misrepresentations or plain lies. There is a balance that results in easily read and understood tests. Investing in writing tests to tell a story to the developers who may have to look at the tests in the future, makes maintenance and TDD easier and with a better flow.

We chose to achieve this balance by merging the assertions with the comments of the execution of the test, resulting in a pseudo-sentence. The statement is an explanation for the next developer to read. The form we chose is

Verify.That(positiveAssertionString).ProvedBy(subject).verb(predicate);

An example of one of these assertions is

public void test_PressingBrakesShouldDecelerateVehicle()
{

 int originalSpeed = vehicle.currentSpeed;
 vehicle.brake();
 Verify.That(â€š"Brakes decelerate vehicle.").ProvedBy(vehicle.currentSpeed).IsLessThan(originalSpeed);<br>

}

When a developer comes across this story, along with PressingEmergencyBrakeLocksTires(), SlamOnBrakesShouldSkid(), and BrakesShouldAntiLockAtIntervals(), the developer is told a story of what the class is doing. Why do we use custom asserts when good test names will solve the problem?

Changing tests should be cheap. As new designs and behavior evolve in the system, tests are changed to conform to the new structures. When implementing a new design to an existing system (such as breaking up an inheritance in favor of composition), I change the tests to fit the new structure on a macro level. However, this often implies that I am changing the behavior (if only slightly) to please the new design. Yet, test names, like comments, are not executable, so you canâ€š’t trust them to tell you what the tests test. On a system with heavy refactorings, a test might have its details changed five times without the developer thinking to verify the integrity of the names. An answer is to write sentential explanation of the test as the assert statement since the assert statement executes. I will trust execution over comments every time.

There is a project in its early stages called NSpec(.NET), which is a framework for assertions of a more sentential form. The project is based on the idea of Behavior Driven Development (BDD). RSpec, the same project for ruby has a form of BDD assertions which take full advantage of the features of the dynamic language. It allows you to add the assertion to the object from the test.

For example:
def pressingbrakesshoulddeceleratevehicle
vehicle.brake
vehicle.decelerating?.should_be_true
end

This is really cool! It defines the test as behavior of the object, which it is. However, when the code isnâ€šÃ„Ã´t ruby, there needs to be other means in place to bind the description of the assertion to something which executes.

Fri, 20 Jan 2006 05:37:12, nraynaud, Tests in a changing world You’re right, we are slowly going to agile world, and for now we have lots of meaningless test taken randomly from existing code (does it makes sense putting a multi megabytes source file in the compiler you test and expecting exactly 2008 errors? without even covering 10% of the compiler). We work on a language, yesterday, I added a restriction to the langugage, it took me 10 minutes to implement and test the change but the rest of the day to change all the others tests.

Moreover, I thank Intellij Idea that renames not only classes but also varialbes named after that class and even comments, this is on the way you takes.

Fri, 20 Jan 2006 13:13:22, David Chelimsky, should_be_decelerating I’ve just submitted a contribution to rspec that will make this even cooler. If vehicle can respond to any of these messages with a boolean value: vehicle.decelerating
vehicle.decelerating?
vehicle.is_decelerating
vehicle.is_decelerating?
then you can write this in your test:
def pressingbrakesshoulddeceleratevehicle
vehicle.brake
vehicle.should_be_decelerating
end
Admittedly, this may be confusing to a programmer who is looking for a “should_be_decelerating” method on vehicle, but the messaging is clear it fails (” should be true”) and it definitely improves the communication of intent. If you’re doing BDD (i.e. spec-first), you’ll get a !-NoMethodError-! on “decelerating”. Then it’s up to you to implement a method responding to any of the forms described above.

Fri, 20 Jan 2006 13:57:32, , How about using Higher Order Messaging style and let the user write:
vehicle.should_be.decelerating?
The test framework could mix should_be and similar higher-order messages into the Kernel module.

Fri, 20 Jan 2006 14:40:41, David Chelimsky, should_be That’s kind of how rspec works now. shouldequal, shouldcontain, shouldbe_true, etc are all mixed in to Object, so you can do things like someobject.someattribute.shouldbetrue. Your suggestion of tying it to a “shouldbe” method (rather than parsing the shouldbe_xxx message) might be more clear. I think, though, that “shouldbe.decelerating?” is weird to read (because of the question mark). Programatically, however, it does make the statement look more like the implementation. I’ll think on it some more…

PreFactoring

by: paul | September 7th, 2006 | 9 comments »

Prefactoring is when you see a piece of code which the story you are working on which has a refactorings which would make your story easier. I have seen prefactoring to be a dangerous process. On one hand, you save time when you know that this refactorings will need to be done. You are faced with the choice of writing temporary code (in the sense of duplicate then refactor) or refactoring, then writing quality code. The software designer in me always wants to choose the prefactoring solution, since it gets to make code cleaner, remove duplication, and be more efficient. Then I can stand on the mountain top waving my flag.

There are a few problems right off the bat. First, the uber-developer in all of us will refactor as much as we can, therefore refactor based scope creep is bound to show up. I don’t really know how to stay away from scope creep in this manner.

Prefactoring can lead to a version of design up front which is detrimental if you don’t need it. However, sometimes you know up front this design simplification will cut the story time in half. Do you prefactor? What kinds of smells make it ok or terrible to prefactor?

I have tried backing my way in and using test(s) as a life jacket, so once the test passes, the refactoring is done. However, the problem with this is it leaves me with half done refactorings. The code is constantly moving up in quality, however, it might not look it due to the inconsistencies produced by half done refactorings. I generally think of a complete refactorings as something that made my system better in some manner I would like developers who are extending the behavior of the system to use the refactorings as a model.

Do my refactorings make the system easier to extend? Half-factorings don’t, but they do provide a manageable slope moving positive. I don’t have the time to tackle the big refactorings, but I don’t want to leave them unfinished.

Wed, 22 Mar 2006 09:27:50, Uncle Bob, Half-factorings Paul, Keep the code clean! If the tests pass when the refactoring is half-done, then complete the refactoring. If you can’t complete the refactoring in this iteration, then keep putting effort into it during subsequent iterations. Make sure the team knows, so they can put some effort in too.

There are often times when a new story is easier to implement in a structure different from the one that exists. Refactoring (or “pre-factoring”) the system into that new structure to make that story easy to implement is often a good approach. However, leaving the refactoring in a half-finished state is messy.

Wed, 22 Mar 2006 18:30:36, Micah Martin, Prefactor ”’Prefactor”’ - I like that. If I counted all the time I’ve had to delete my prefactored code…. I believe there’s an Big Up Front Designer in all of us. Face it, BDUF is fun! Frequently I look at a prefactoring that I’ve just completed and realize I’ve been BDUFfing. Most of the time I delete it all because it’s too complex and unnecessary.

Sun, 23 Jul 2006 08:14:08, Sebastian Kubeck, BDUF To be honest, I never got BDUF right. Untill today, I need to start over one to four times untill I get what I want. I was convinced that I’m just lacking the skills to get it right the first time. Fortunately, I found out that people that are much smarter and much more experienced than me don’t get it right the first time either.

I learned in school that Mozart just wrote down his music which was already completely finished in his head. I was toled later that this is just another myth about this guy. Beethoven permanetly adapted his works. His handwritings are hard to read because his corrections. Bach adapted his works depending on the number of musiciants he could afford.

Conclusion: If not even the geniuses mentioned above get it right the first time, how should we “ordinary people” should ever be able to do it?

Over Mocking

by: paul | September 7th, 2006 | 0 comments »

I have noticed using more mocks lately. Instead of using them sparingly for controlling services which are not instrumental to what I am testing, I am essentially using them as a way to isolated what I am testing. This has me noticing a side effect I am not entirely comfortable with. To use the mock, I need to be able to have the mock in the production code, which means I need to inject an abstraction of the mock (dynamic mocks will do that for you).

So, the side effect is long parameter lists, specifically in constructors. Everything takes almost all the objects it uses. Then, to create the production objects are factories. I am using many more factories than I would without mass mocking. I am not sure if this is a good use of dependency decoupling and factory building as design techniques, or if this is a symptom of over design and tightly coupling the mocks to the tests, making it more difficult to change the tests without changing the interface the mock is implementing. Thoughts?

Wed, 24 May 2006 14:03:11, Dave Hoover, Create a default constructor Try poor man’s dependency injection: have a constructor that allows you to inject your dependencies (hidden behind interfaces) for testing, then have a default constructor that instantiates the concrete objects and injects them itself.

Wed, 24 May 2006 15:01:02, David Chelimsky, too many dependencies either way I don’t think mocks or factories are the real problem here. If A depends on the services of B,C,D,E,F,G,H and I, then it’s depending on too many things whether you inject the objects or instantiate them internally.

Wed, 24 May 2006 16:57:06, , Don’t “inject” dependencies. Mock an object’s peers in tests and pass real peers to it’s constructor or as method arguments. Composite objects should create objects they use internally and not expose them at the constructor. A composite object should be simpler than the sum of its parts. Also, avoid passing all dependencies into an object’s constructor: you can probably pass collaborators as method arguments, not constructor arguments.

Wed, 24 May 2006 17:24:56, Dave Hoover, Listen to Chelimsky The smell of a long parameter list leads me to think you may be able to collapse some objects behaind a coarser-grained interface.

Thu, 25 May 2006 11:24:12, Ryan Cooper, DI Containers I find using a DI container like PicoContainer eases the pain by making all (or most of) those factories unnecessary.

I’m still not happy about the long parameter lists in constructors, so I think I will give a few of the suggestions above a try. Thanks all.

Thu, 25 May 2006 16:08:05, Tim Ottinger, The “Airplane” retort “I’ll never be over mocking!”

Fri, 26 May 2006 10:48:42, Asher Sterkin, Over Mocking Personally I mock whatever and whenever I can. Usually a hardship with mocking reveals some interesting deeper design problems. If there are too many arguments for constructor it probably means the class under test has too many dependencies, which means a problem with cohesion. In my experience I seldom need to mock more than 5 interfaces per test case. It’s usually one or two as constructor arguments and two, max three for returned objects. If it’s more I try to re-factor.

Fri, 26 May 2006 16:25:43, Paul Pagel, “In my experience I seldom need to mock more than 5 interfaces per test case.” Do you only mock interfaces?

Sat, 27 May 2006 19:49:22, Rogerio Liesenfeld, I prefer to obtain dependencies with “new” wherever possible In the large (8000+ classes) J2EE web app I am currently working, many business classes obtain instances of other business classes by simply instantiating them with the “new” operator. Besides being the simplest way to obtain dependencies, this allows business service classes to maintain client-specific state, so that private methods don’t need to have any parameters.

Of course, with the mock objects tools previously available, it would have been difficult to unit test such classes. But I wanted to use “new”, and also have final classes, final methods, and static methods where appropriate. So, with that “itch to scratch”, I went ahead and created a new tool that would free me to design the application without constraints, and still have complete unit tests.

If anyone wants to give it a try, the tool is here: jmockit.dev.java.net.

Fri, 9 Jun 2006 10:30:20, Asher Sterkin, Over Mocking “Do you only mock inerfaces?” Not only, but I prefer so. In C++ it really doesn’t matter since there is no good mock library (I use my own which is based on link time substitution; I plan to sourceforge it soon). In Java and C# interfaces do not cost too much, but sometimes you have a class comming from the infrastrucure. You would like to mock it but you do not want to wrap it with an extra interface. For example I recently mocked Java’s TimerTask::cancel in order to validate that in a certain scenario a timer cancellation request is sent properly. I also do test what will my program do if the TimerTask::cancel returns false (too late to cancel).

Fresh Testing

by: paul | September 7th, 2006 | 2 comments »

Sometimes I sit down to write a test on something I haven’t worked on before or don’t know intimately, and I just can’t write the first test. I need a context of the system and a state of existing code. Then I generally do one of two things: look at how things are implemented in the code, or look at other tests that exercise similar behavior. Using either of these as a strict model to write a test is problematic to the flow of TDD.

By using the implementation code as a model, I am limiting one of the great things about TDD from the beginning, the fact the design should evolve as a byproduct of making the test pass. This TDD complacent method tends to ingrain existent design into my mind. These strict models resign to existing design, even if your story/test/problem isn’t exactly the same, just similar enough to convince you of the model.

Copy/pasting a similar test and editing is a developer mistake I commit sometimes when it looks like a freebie is being tossed at me: duplicate then abstract. It is very tempting, yet I have found it painfully regressive. Especially when the tests themselves have begun to rot, as their ability to act as developer docs are deprecated. It causes a lie in logic which is always painful. Either the debugger gets fired up or the test gets scrapped in order to handwrite anyway. Copy/pasting something which is similar is starting from a false expectation most of the time. It is more important to me to have faith in the integrity of my tests.

The most powerful TDD I see is at the beginning of a project, since there is a state of tabula rasa allowing you to move infinitely lateral. Before tests depreciates provides the best model for TDD. Test depreciation is unavoidable, as with design changes, the tests are changed with regularity to accommodate the new structures. The reason for having the tests is to have a safety net to make the code easy to change. It becomes important to keep tests “fresh” when there is already design in place. Otherwise good design appears to degrade due to over/improper use.

Handwriting a test from scratch can seem like an extra step, like reinventing the wheel. Most of the time the extra step is exactly that, an extra step, but in those cases where you are following a false model it is very expensive. It introduces the worst type of design into the system, the kind with little to no smell, but with false premises. Introducing bad design into tests or failing to maintain test code ends up introducing bad design into production code.

COMENTS

Thu, 5 Jan 2006 22:16:48, David Chelimsky, copy/paste Copy/paste can be a real problem, yet it takes an awful lot of discipline to abandon it completely. For example if you’re test driving something new - you write the first test which has some setup in it. You’re not ready to move stuff to a setup method because there’s no duplication to warrant it yet. So for the second test you copy/paste the first test, modify what you will, get it to pass, and then refactor out the duplication. With just a few lines of testing code that’s probably acceptable, but there’s a point where you get yourself in trouble. I guess that’s different for everyone, and perhaps on different days (depending on the coffee/sleep ratio). Maybe committing to a day of absolutely zero copy/paste to see if it really slows me down would be worthwhile.

Thu, 5 Jan 2006 22:53:53, Tim Ottinger, What he said I hate copying from any existing tests, always feeling like I’ve cheated somehow. It is a way to get by (or try to get by) when you don’t really know what you’re doing. When I talk about whether I [[really know][http://tottinge.blogsome.com/2005/12/30/how-can-you-not-know-java/]] something or not, I consider whether I can work from the blank slate. If not, then I don’t really know my topic. Not only is working from tabula rasa liberating, it’s a good indicator that you’ve done enough backgrounding. It’s good on so many levels.

I just wrote the other side of this blog, that [[naive tests don’t help][.ArticleS.TimOttinger.NaiveTestsDontHelp]] so you have to know the software to write tests for new parts. I think that it would be good if we could work on the pro/con of this and give guidance on navigating between sylla and charybdis. If you don’t know enough, you can’t blue-sky the tests. If you are copying the tests, then you only reinforce the implementation in testing (for better or worse). There has got to be a middle way, and some heuristics to help get around: something more useful than “pairing should fix that.”

Fri, 6 Jan 2006 15:50:00, Thomas Eyde, Copy/paste is for professionals – don’t do that at home I think the trick is to write the tests for the truly new requirements, then find reusable code if any, or refactor existing code to be reusable. Not easy, but that’s what I strive for.

I also think there’s nothing wrong to copy/paste and then refactor. It’s without the refactoring things start to get dangerous.

Sat, 7 Jan 2006 12:28:24, Matisse Enzer, Copy and paste as an iterative action Yesterday I was adding tests to some “legacy” code. After I got the library to compile under the test harness I picked one subroutine to test, and create d a test to run that subroutine. Of course I got a run-time exception because the subroutine I was testing made a call to a subroutines defined in some other library. So, I created a stub version of that subroutine in my test harness. ran the test again, another missing external subroutine. I copied and pasted the stub I had created, changed the name, reran the test. Several times. Each time adding a single “fake” subroutine. (Sometimes I had to edit the stubs to return some mock data.)

I also copied-and-pasted my first test. Renamed it, and changed the arguments it passes to the subroutine I’m testing. Did this three times.

Mon, 30 Jan 2006 22:46:53, Paul Pagel, the copy/paste problem There are many ways to introduce code debt into a system. Duplicate code is one of the worse. Copy/Pasting leaves the payment of this debt to the memory of the developer. So if it is copy/paste a few lines at a time, then refactor at the end of small cycles, then I go for it. But if it is going to be coping a file or a series of tests/methods, I won’t.

Smalltalk Bowling

by: micah | September 7th, 2006 | 0 comments »

I’ve been meaning to learn Smalltalk for years now. Recently Dave Astels and I have a had a few discussion on the topic. They all seem to circulate around the theme of Smalltalk being a key OO language of the past, and again in the near future. Now that Ruby has finally captures the attention it deserves, it’s not long before Smalltalk is back in the spotlight.

A few days ago, when he joined me for a train ride, I seized the opportunity and asked him to help me write some Smalltalk. He gave me a copy of Squeak and off we went to write the Bowling game.

Even though we only got through the first two test cases, Dave’s a good teacher and I was able to finish it on my own. The code is below.

My first impression of Smalltalk: “Damn, this requires a lot of clicking”. It requires two clicks just to run a test and another 5 clicks to see what failed. Dave gave me funny looks when I complained about this but I couldn’t believe people programmed this way. Later my dad, remembering a demo by Kent Beck, reassured me that there are keyboard shortcuts for everything. Thank goodness!

In general it’s a sweet language. Experience with Ruby and Objective C exposed me to many of the concepts so there weren’t many surprises. Perhaps the most peculiar thing I ran into was the Smalltalk equivalent to if/else statements. The ”ifTrue: ifFalse:” structure makes perfect sense but it was unexpected. An example can be seen in the ”score” method.

This is my first Smalltalk program and I’m sure I’ve made some newbie blunders. Feel free to rip my code to pieces in your comments. I’d love to hear advise and learn Smalltalk idiosyncrasies.


TestCase subclass: #BowlingTest
    instanceVariableNames: 'game'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Bowling'!
!BowlingTest methodsFor: 'testing' stamp: 'MDM 4/27/2006 18:11'!
setUp
    game := Game new! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 4/27/2006 18:19'!
testAllOnes
    1 to: 20 do: [:i | game roll: 1].
    self should: [game score = 20]! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 4/30/2006 19:52'!
testAllSpares
    1 to: 21 do: [ :i | game roll: 5 ].
    self should: [game score = 150]! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 4/27/2006 18:05'!
testGutterGame
    1 to: 20 do: [:i | game roll: 0].
    self should: [game score = 0]! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 5/1/2006 12:26'!
testHeartBreaker
    1 to: 11 do: [ :i | game roll: 10 ].
    game roll: 9.
    self should: [game score = 299]! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 4/30/2006 19:20'!
testOneSpare
    game roll: 5.
    game roll: 5.
    game roll: 1.
    1 to: 17 do: [:i | game roll: 0].
    self should: [game score = 12]! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 4/30/2006 19:44'!
testOneStrike
    game roll: 10.
    game roll: 1.
    game roll: 2.
    1 to: 16 do: [:i | game roll: 0].
    self should: [game score = 16]! !
!BowlingTest methodsFor: 'testing' stamp: 'MDM 5/1/2006 12:26'!
testPerfectGame
    1 to: 12 do: [ :i | game roll: 10 ].
    self should: [ game score = 300 ]! !
Object subclass: #Game
    instanceVariableNames: 'rolls'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Bowling'!
!Game methodsFor: 'scoring' stamp: 'MDM 5/3/2006 19:01'!
init
    rolls := OrderedCollection new! !
!Game methodsFor: 'scoring' stamp: 'MDM 5/3/2006 19:02'!
roll: pins  
    rolls add: pins.! !
!Game methodsFor: 'scoring' stamp: 'MDM 5/3/2006 19:03'!
score
    | roll score |
    roll := 1.
    score := 0.
    1 to: 10 do: [:i |
        (rolls at: roll) = 10
        ifTrue: [
            score := score + 10 + (rolls at: roll + 1) + (rolls at: roll + 2).
            roll := roll + 1
            ]
        ifFalse: [
            (rolls at: roll) + (rolls at: roll + 1) = 10 
            ifTrue: [ score := score + 10 + rolls at: roll + 2] 
            ifFalse: [ score := score + (rolls at: roll) + (rolls at: roll + 1)].
            roll := roll + 2
            ].
        ].
    ^ score! !
"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
Game class
    instanceVariableNames: ''!
!Game class methodsFor: 'as yet unclassified' stamp: 'MDM 4/27/2006 18:23'!
new
    ^ self basicNew init; yourself! !

Tue, 29 Aug 2006 02:03:35, Jamesl, Yay, Smalltalk … Very interested to see someone go ‘back’ to use some Smalltalk.

Other than the ‘click’ frustration that you experienced, what else did you ‘feel’ about the language ?

I’m a smalltalk zealot but get paid to do java, that’s just how it is.

Rgs,James.

Thu, 15 Jun 2006 08:40:37, snoobab, Good to see some smalltalk! Hi

Great to see Smalltalk code! I have been Java zealot for 6 years now and made a decision 2 months ago to learn Smalltalk. And I absolutley love Smalltalk’s simplicity and ideas and am hoping to apply these ideas in my paid software development. I’d love to find a job in South Africa using some Smalltalk.

Must say that you quickly learned alot of Smalltalk on a train ride! BTW you don’t have to override the ‘new’ method. You could simply implement the ‘initialize’ method on the instance side. This is called via the normal object creation. (Which can be found in the ‘new’ method on the instance side of class Behavior)

Fri, 12 May 2006 22:49:35, Dave Astels, Bowling in ruby ${chelimsky} posted one on his blog here

Fri, 12 May 2006 22:48:39, ,

Tue, 9 May 2006 21:01:15, Francesco Rizzi, see what happens ? ..I’m downloading Ruby now. :) I wonder if I’ll find a Ruby version of the bowling kata anywhere…

but this was about Smalltalk originally.. I got to admit that languages where you don’t need { and } around blocks that include more than one line scare me !

Tue, 9 May 2006 18:03:14, Dave Astels, sSpec on the way I’m currently working on a new version of sSpec (which is aligned with the latest rSpec). The first release will be for VW7.4, with a squeak version to follow.

Sun, 7 May 2006 19:33:09, Francesco Rizzi, rSpec ? cool…have you had a chance to look at rSpec (and the whole BDD vs TDD philosophy) ? —-”Yes! Dave assures me that I was the first user of the rSpec in it’s latest form. -${micah}”

Thu, 4 May 2006 00:48:13, Randy Coulman, Minor suggestions Overall, it doesn’t look too bad for a first effort. A couple of comments:

I haven’t used Squeak, so maybe it doesn’t have this method, but I’d be surprised. When you write a loop that doesn’t need to use the index variable, you can do n timesRepeat: [… whatever …] instead of 1 to: n do: [:i | … whatever …].
SUnit also has assert: and deny: methods that expect Booleans in addition to should: and shouldnt: that expect blocks. So instead of self should: [ game score = 300 ], you could put self assert: game score = 300. It’s a matter of taste, really, so either way is fine.
In VisualWorks Smalltalk, there are some add-on tools that make it much easier to run tests and find failures, so not as many clicks are required. I’d be surprised if someone hasn’t done the same for Squeak.

Great tips! Thanks Randy -micah

Paper Bullet

by: micah | September 7th, 2006 | 0 comments »

Work has me visit lots of software teams around the world. This past week I visited a particularly fun team. They worked in a large open work area with desk space for pairing and wall space for BCV (Big Visible Charts). Anyhow, there was one member in particular, I’ll call him Dan, that was notorious for his mischief. Most notably, he’d start paper bullet wars.

Paper bullet is not the term they used but that’s what I’m gonna call it. What you do is tear off a piece of paper and roll it lengthwise. Then fold it fold it in half so you’ve got a wedge shaped paper bullet. Then take a rubber band and stretch it between your thumb and index finger. Slide the wedge onto the center of the rubber band, stretch, aim, and release.

Dan had apparently surprised everyone on the team with a paper bullet in the face or neck at one point or another. They held a friendly grudge against him.

Early in the week I was unaware of the paper bullet wars and I found it peculiar that there were all these bit of paper on the floors and desks. Apparently wars were taking place all week but, being the guest, no one wanted to hit me and so who ever was pairing with me had immunity.

In the final hours of the last day they confessed at how nice they were and how lucky I was that I didn’t get shot all week. Frankly I was disappointed that I didn’t get to play all week so I spat out some fighting words… “You’re lucky you never got me involved!”. It began. I could hear them whistle past my ears as I was writing so unit tests or bounce off the wall behind me as I pass the keyboard to my pair, but I never got hit.

Thankfully, other team member armed me a rubber band and a hand full of paper bullets. At a quiet moment, I figured I’ve give this game a try. Grabbing the rubber band and paper wedge, I loaded and aimed right at Dan’s head. The rubber band was surprisingly flexible. Not knowing how hard to stretch it, I just kept pulling. As I looked down the trajectory, I was sure the projectile would curve. When I released I was shocked and horrified.

The bullet screamed across the room, straight as an arrow, pegging Dan right in the side of the head. It made a loud smacking noise upon impact. The whole team heard it and the room went silent. I was terrified. This was no way to treat your clients, I thought. The poor guy never even hit me so he didn’t deserve it. Apparently I was wrong. Everyone else thought he deserved it. The room broke out in laughter. Team members (not Dan) gave me a thumbs up, telling me “Thanks” or “Good job”.

I apologized to Dan later, trying not to stare at the red welt just below his temple. Dan, the sportsman that he is, congratulated me on my marksmanship. He’s a good guy.

So what’s the moral of the story? None really. But I will note that many of the development environments I visit are much more sterile and “professional” than this team…. and much less productive as well.

Wed, 19 Apr 2006 10:21:32, Greg, hey !? Did you visit my office recently and I didn’t know? We’re also doing this, but since there’s only 3 of us in the office, we sometimes have to use other targets than ourselves (when the red marks are becoming too obvious). We just destroyed an ugly dummy cd of some bad dutch singer here.

Wed, 19 Apr 2006 02:52:29, Mike, My mother used to say it’s only fun until someone’s eye is put out!

Tue, 18 Apr 2006 10:49:47, Dan (yes that one), Injury update The swelling is down…I can see out of that eye now…hope you come back soon :) :) :)

Tue, 18 Apr 2006 06:44:08, Ryan Platte, Nice shot! Don’t be surprised if I hang out by a pillar if you come to another Chirb meeting, yikes!

Beware the Freebie

by: micah | September 7th, 2006 | 0 comments »

The milestones in the life of a story:

Creation: customer creates the story
Estimation: the story is estimated by developers
Selection: the story is selected for an iteration
Specification: tests are written the story
Implementation: the story is implemented to make the tests pass
Acceptance: the customer acknowledges completion of the story after seeing the passing tests and witnessing the new functionality

It is unavoidable. Every story must go through these milestones of life in order. A story cannot be estimated if it has not been created. A story cannot be selected for an iteration if it has not first been estimated. You can attempt to specify a story before it has been selected but you run the risk of being wrong, for the system may change many times before the story is selected. Implementing a story before it has been specified will lead to false implementations. And accepting a story that hasn’t been implemented is just plain silly.

It happens with some frequency, however, that a story gets implemented before it is ever selected, estimated, or perhaps even created. How? A developer may be look at a piece of code and think, “Hey, the customer mentioned he wanted to change this doohickey. I might as well change it now.”. Or a developer may working on one feature and say, “You know, I bet the customer would really like it if I improved this thing-a-magigger”. When this happens, the developer pridefully demonstrates the extra functionality to the customer and says with a smile, “You got a Freebie this iteration!”.

BEWARE THE FREEBIE! A Freebie, by it’s nature, has skipped at least one milestone in it’s life. Most Freebies skip the Selection milestone. This is unfortunate because maybe the customer didn’t really want that story after all. But that’s small potatoes compared to the real danger… Almost all Freebies have skipped the Specification milestone.

Skipping the specification milestone is blasphemous. If a feature has not been specified with tests, how do you know it really works? Worse, how will you know if it still works 2 months from now. Very often Freebies break and nobody knows about it.

I’ve seen it over and over and it’s regrettable every time. A perfectly innocent story is wronged by an overzealous developer. The poor story, out of sync from his peers, strays from the trodden path and becomes a Ghost Story. Becoming a Ghost Story is dreadful fate. They are those stories that were at one time complete, but have since become incomplete. You may never actually see a ghost story but they will surely haunt you. They cause users to have delusions of non-existant functionality and to make exclamations like “Hey! Why doesn’t this stupid app work like it used to?” or “What happened to my favorite feature?”. They keep customers up at night wondering if they actually selected the Ghost Story for an iteration of not. They torment developers forcing them to write code they’ve already written.

Avoid Ghost Stories by avoiding Freebies. Give every story a complete life with all it’s milestones. The next time a developers shows you extra functionality and calls it a Freebie, say “That’s nice. I’ll consider selecting a story for that in a future iteration.”

Mon, 24 Apr 2006 23:17:57, Old Grouch, Another hidded danger By skipping several stages, the freebie runs the risk of breaking something else. An assumption that doesn’t carry throughout the entire system. Usually minor, so it doesn’t show up for months. Then someone else has to rip their hair out. And declare that your parents were never married.

“The more innocuous the change, the greater the ramification.”

Tue, 21 Feb 2006 14:11:34, Gary Dieckman, Looking for Preston and Karen Martin Micah Martin - If your parents are Preston (Tom) and Karen Martin of Proctorville, Ohio, then your dad was best man at my wedding in 1970. I’d like to get in touch. Are you that Micah? gary@exprint.com

Nope, you’ve got the wrong Micah

Thu, 16 Feb 2006 10:09:50, unclebob, Other out of order disfunctions. Indeed! I think you have hit on an interesting way to describe a whole family of dysfunctions. I have certainly seen stories selected before they are estimated. I have seen stories accepted before they are specified. I have seen stories implemented before they are created. Each of these dysfunctions has it’s own particular set of symtoms and ramifications. What are they?

Thu, 16 Feb 2006 08:12:26, chelimsky, skipping selection Well said, Micah. It’s worth noting that 4 of the 6 milestones are customer milestones. As developers, we want to create the best software we create. We talk about it being a team effort (i.e. whole team, customers, developers, et al), but in the end it’s not really our (developers) software. And how can we expect our customer to feel ownership of priorities if we arbitrarily take the their any (sometimes all) of their milestones?

Prelude to the Mock Off

by: micah | September 7th, 2006 | 0 comments »

!title Prelude to the Mock Off You can read David’s side of the story here: Stop Mocking Me

He puts it gently… We’ve actually had some heated arguments about these mocking frameworks and it’a all kinda silly. In the end we’re writting good tests for well designed code. Still, these mocking frameworks rub me the wrong way.

Why do I prefer hand-made mocks? 1 They’re simple to write. Yeah it requires a new class but it only takes a couple seconds and it’s the most brainless code you’ll ever write. 2 They’re simple to use. If I want an instance of a DataEntryView I simple type new MockDataEntryView(). With a mocking framework, it takes 3 or 4 lines before I have a usable object. 3 They’re much more flexible. With mocking frameworks you can set returns values and expected method calls but that’s about it. Hand-made mocks are limited only by your imagination. 4 Mocking frameworks are refactoring-challenged. Especially NMock. Rename a method and dozens of tests will break. 5 Readability. Tests using hand-made mock are easy to read. Tests using mocking frameworks require murky configuration. 6 Mocking frameworks violate testing convention. Build, Operate, Check. Conventionally, all tests follow this flow. With mocking frameworks the flow becomes, Build, Check, Operate, Verify.
7 Failures are deceptive with mocking frameworks. When you get a failure in a test using a mocking framework, the line number usually points to a call to Verify. With Rhino it can point to the last line of a using block. Either way, the failure could have been caused by any number of assertions. Itâ€™s up to you to figure out which one. With hand-made mocks, line numbers pinpoint the problem by revealing the exact failing assertion.

What do I hope to get out of the Mockoff? Iâ€™ve played with several mocking frameworks before. I hope that by committing to use them for 3 days, Iâ€™ll gain insight as to so many people use them. Maybe Iâ€™ll find that they improve my productivity and Iâ€™ll use them in the future on a regular basis.

What do I expect to happen during the Mockoff? Iâ€™m trying very hard to have an open mind going into this. My stubborn self is expecting 3 days of frustration. My optimistic self is expecting to gain appreciation for mocking frameworks. Weâ€™ll see what happens.

Mon, 31 Oct 2005 12:22:11, SvenGorts, Unit Testing With Hand Crafted Mocks When I started using hand-made mocks, I expected that I would switch to the use of a mocking framework rather rapidly. Perhaps surprisingly this switch never happend and as of today hand-written mocks are still my preferred choice. The article ”’Unit Testing With Hand Crafted Mocks”’ available at http://www.refactoring.be/articles/mocks/mocks.html summarizes some of my personal experiences.

Mon, 31 Oct 2005 14:14:35, M. Scott Ford, I can’t argue with some of your points. But you may want to take a glance at NMock2. The code that you write is still refactoring challenged. Which is honestly a refactoring tool limitation in my opinion. (I could not resist!) I think that the mocking code with NMock2 is very human readable. Expectations are setup with Expect.Once.On(object).Method(“Method”).With(parameter1, parameter2).Will(Return.Value(result)). To me that is very readable, and it is the reason that I use NMock2 in all my tests (Why am I starting to sound like a salesman?)

The errors in this version have been improved as well. Unexpected calls throw at the point that they occur. And all of the unmet expectations are listed as part of any error thrown by NMock2. You still have to include a verify if you want to find out about unfulfilled expectations, but now, at least, it is just one instead of one per mock object.

I do use hand mocks as well. I just don’t use them as often. I like to mix and match. I pick the tool that will get me to a finished test that clearly demonstrates its intent the fastest. The “dynamic” mocks have their downsides, but I think that the benefits out weigh the cost. Personally, I like to make it clear what code in a test is “mock” code, and what code is supposed to me part of the class that is getting mocked. I think that the mock tools help keep this separation clear.

But I am sure that these are all arguments you have heard before, so I will shut up now. What I really wanted to do was tell you about NMock2, so here [http://vaderpi.scottandlaurie.com/blog/?p=185] is a short article that I wrote comparing NMock and NMock2.

Enjoy the Mockoff! I will enjoy reading the results.

Tue, 1 Nov 2005 04:37:38, Sagy Rozman, Tons of mock classes

They’re simple to write. Yeah it requires a new class but it only takes a couple seconds and it’s the most brainless code you’ll ever write.

I agree, and this is exactly why I don’t use them. I’m trying to write most of my tests as interaction based tests. At first I was going for the hand made mocks approach, but soon I discovered that the test.utils.mocks package was getting quite large. There where lots of mocks and it was getting out of control. When I started to refactor this code I suddenly realized that I was building j/nmock all over again. I then stopped and learned all there is to know about using these libs. Today I use the mock librarys more than hand made mocks.

Tue, 1 Nov 2005 04:43:23, David Chelimsky, re: Unit Testing With Hand Crafted Mocks Sven - I read your article. I like the idea of different types of substitutes. I can imagine that they do a lot to clarify the tests that use them. I’m going to experiment with that as part of my experiment.

Thu, 3 Nov 2005 03:45:47, IsmetKahraman, Sometimes, interacting with an API full of static methods does not allow to mock these classes. In these times, virtualmock really helps. Adding new behavior (here mocking behavior) by means of aspects is a different and a helpful approach. But for the time being, I prefer EasyMock in my TDD efforts. Simple, once accustomed it is a very natural way of dealing with external interfaces.

Sat, 12 Nov 2005 22:00:03, Steve Eichert, Have you tried Rhino Mocks? Rhino Mocks gets rid of the hard coded strings everywhere. I haven’t actually used it as I’m much more of a hand crafted mock guy, however, it does look interesting.

http://www.ayende.com/projects/rhino-mocks.aspx

Wed, 14 Dec 2005 09:22:37, Paul Pagel, I have been using used Rhino mocks lately, which have solved some of the objections to mocks you listed. One thing I have noticed about hand mocks is they end up with logic in them. Often mock classes, as they evolve, will contain logic around different results which is neccessary for the return type or to simulate minimal behavior for the mock to be useful. This logic becomes a lie, as it is not updated with the code, so when the production code gets changed, the tests using the mocks will still pass. The fact there is no executable accountability as a mocking framework would provide makes hand mocks dangerous unless they are bare bones. A mocking framework takes away the temptation, as they can only be bare bones mocks.

Wed, 14 Dec 2005 09:36:09, David Chelimsky, mostly stubs…. There is a distinction that “mockists” make between mocks and stubs. They are both fakes, but a stub is a class that you set up to behave in a known way when the class under test interacts with it - returning a known value in response to a query, for example. A mock records messages it gets from the class under test and reports back against expectations you set in advance. Whether you’re hand-mocking or rhino-mocking or any-framework-mocking - the problem of fakes becoming lies as the real classes change is related more to stubs (predefined behavior of collaborator) than mocks (verification of behavior of class under test).

That said, my biggest issue is the extra classes it produces. I’m in the middle of (gradually) splitting a hierarchy into two separate hierarchies. The existence of hand made mocks for every one of the production classes doubles the effort involved in this separation. Hand made mocks seem to be bound to static hierarchies. Tool generated mocks seem to be bound to the classes they mock and that’s all.

Wed, 11 Jan 2006 14:04:57, David Kreth Allen, So, Micah, what is your impression at this point? Are you more likely to use mock tools now? Any suggestions about when to favor one over the other?

IList, IComparable, ICarumba!

by: micah | September 7th, 2006 | 1 comments »

This IConvention is an interesting one. ”Let’s prefix all interfaces with a capital I.” Who thought of this? Why did they think it was a good idea?

Let’s say I want to implement the Command pattern in C#. I create the following interface…. and to be true the fathers of C# I use the IConvention.

public interface ICommand
{
    void Execute();
}

In my application I can now write Code like this.

public void ExecuteCommands(IList commands)
{
    foreach(ICommand command in commands)
        command.Execute();
}

Clearly, every object in the IList of commands is an Implementation of ICommand. And ICommand is an Interface because It starts with an I. That’s Important to know because If It didn’t have the I, It might be an abstract class or even a concrete class. And If that were the case then….. well…. hmmm…. it doesn’t really matter. I could call the class ICommand or I could call it Command. From the point of view of the client code, maybe Command it’s an interface or maybe it’s not. So if it’s all the same, I might as well submit to the convention and call it ICommand. Right?

Wrong! Prefixing interfaces with I is a mistake and this is why….

Assume that I really do need a Command abstraction. Should it be an interface or an abstract class? I can’t think of any logic to put in the base class and the Dependancy Inversion Principles says interfaces are preferred. So I’ll make it an interface and follow the IConvention naming it ICommand. After a while there are a dozen or so implementations of ICommand in the application. New implementations are popping up all the time. One day I realize that the application needs to know whether an ICommand has executed or not. Since this affects all implementations of ICommand I can add another method to the interface:

public interface ICommand
{
    void Execute();
    bool Executed { get; }
}

However, it’s not long before I realize that all the derived classes implement the Executed property with the exact same code. They also need a boolean field. So to avoid duplicate code, I’ll use Template Method like so:

public abstract class ICommand
{
    private bool hasExecuted = false;
    public virtual Execute()
    {
        PerformExecution();
        hasExecuted = true;
    }
    protected abstract PerformExecution();
    public bool Executed
    {
        get { return hasExecuted; }
    }
}

But wait! ICommand is not longer an interface. I can’t just leave that I sitting there. Clients will think it’s still an interface. So now I need to rename the class to Command without the I. Fortunately, !-ReSharper-! will help me there. But now I’ve got the Command class in a file named ICommand.cs. Renaming the file is a bit more challenging since it has to be changed in source control as well. So I rename the file in the subversion repository, then remove the ICommand.cs file from the Visual Studio project, and finally add the new Command.cs file to the project…. whew. That silly I sure causes a good deal of hurt.

I’ve stumble over this scenario more times than I care to mention. Experience has taught me that prefixing interfaces with an I is a choice that will come back and haunt me. So I don’t do it.

Here’s my dilema. Maybe you can help me. I’ve been translating Unclebob’s Agile Software Development book into C#. In the code examples I have heeded my experience and created interfaces without the I prefix. Reviewers don’t like this. They keep telling me that I need to add the I prefix. I’m torn. I feel in my heart of hearts that using the IConvention does more harm than good. Yet, readers of the book will be familiar with the IConvention and may be confused by examples that don’t use it. What’s the right thing to do?

Tue, 18 Oct 2005 12:04:30, Monica, The beauty of word processors Go without the ‘I’ and tell your readers/reviewers to embrace change.

As a compromise, have your code examples highlight the interface with a format option that clearly communicates it’s the interface you’re referring to..How often do you see the â€˜Iâ€™ anyway? Only on declarations/assignments correct? IMO what matters is the context that the interface is used in communicates reason and logic for using an abstracted or interfaced element.

Mon, 17 Oct 2005 16:37:14, Runar, IConvention and Hungarian Notation are Evil Micah, sometimes you must compromise, but never on principle. Your gut feeling and your experience are telling you the right thing. Our guide here is a general form of Codd’s Information Principle:

“Data should be stored in relations and in no other way.” More generally: Encode information in semantics, not in names.

To clarify; The indication that something is an interface should be codified as the relation “is an” between “something” and “Interface”. Calling it ISomething only causes you to have to maintain this relation in two places (which, incidentally, violates the OnceAndOnlyOnce principle). And maintenance is more difficult because these semantics cannot be discovered without parsing the type names. Besides, this parser breaks the moment somebody creates a class that violates naming conventions.

Mon, 17 Oct 2005 14:11:45, Phlip, reviewers There’s always a difference between what reviewers say and what a thought leader (or us;) should do about it. ;-)

Sat, 8 Oct 2005 07:53:37, Jed, Hungarian Notation I’ve always felt that Hungarian notation was nothing more than a “helper” for those languages with loose typing (e.g. Visual Basic, C/C++, and so forth) to help us work around the limitations of the language to prevent subtle (and not so subtle) conversion errors. When using a strongly typed language like C#, Hungarian notation serves no useful purpose. The only instance I see Hungarian notation used in C# is as a visual cue that pure abstract classes (interfaces) support multiple inheritance.

I realize this a recursive argument, but I go back to my original assertion that the only reason Hungarian notation is used here is to work around the limitations of multiple inheritance. As a potential point of contention, how many implementation classes that derive from IEnumerable have nearly duplicate code that iterate through a simple array? I tend to agree that multiple inheritance is rarely needed, but the only choice currently available is to duplicate the code with interfaces in those instances that it is needed.

However, I think the more important argument is that the I prefix is so entrenched at this point that breaking away from “tradition” is likely to cause more confusion. I feel your pain, but I think the real argument is that Visual Studio .NET and Subversion do not play nicely together yet. In other words, the more appropriate answer is better integration between Visual Studio .NET and Subversion to support “painless” renaming of files. Whether this is a new version of Ankh that isn’t quite so “broken” or a replacement product that works as well as Tortoise within Visual Studio .NET.

Sun, 25 Sep 2005 09:02:16, Barry, It’s just old IDEs vs. new IDEs Most modern IDEs (Eclipse, VS.NET) will assist you (class browser, syntax checking) and tell you whether or not you’re using an interface or a class. Older IDEs did not. Hence the naming conventions we have now (Hungarian et al.). However given the size of C# libraries and intended audience, it is probably better to stick with convention.

Wed, 21 Sep 2005 10:44:11, Tom Rossen, Syntax vs. convention

Using or not using IConvention is just a convention. When speaking English I (try to :) ) use articles. When writing C# programs I use IConvention.

Let’s not confuse C# with a natural language. Articles are part of the syntax of a natural language. Hungarian notation is a convention, one that moves code further away from natural language and therefore from readability.

BTW, “Hungarian notation” strikes me as an ethnic slur. How about “kitchenSinkNotation”?

Fri, 16 Sep 2005 19:27:12, Alex, AConvention in English. Answering uncleBob regarding nNouns etc. There are some languages out there that do not use articles. Your suggestion

Let’s prefix every noun with an (n), and every nadjective with an n(j), and jevery nadverb with a n(y), and jevery nverb with a (v). could look to them funny without anything else just because of multiple usage of articles a or an which do not add a single bit of extra information to the message.

However it seems to look natural to you.

Using or not using IConvention is just a convention. When speaking English I (try to :) ) use articles. When writing C# programs I use IConvention.

Anything that let people better understand each other is Ok. Sacred Wars don’t.

Fri, 16 Sep 2005 19:22:47, ,

Tue, 13 Sep 2005 22:05:58, Chaz Haws,

The “interface” is a kludge.

It’s not that we “need some multiple inheritance” - what we need is to combine two previously independent sets of behaviors.

Of course you’re right, vendors and standards should definitely go with pure abstractions. Doesn’t mean that’s appropriate for my code. Remember, I’m not questioning the presence of interfaces, I’m questioning the absence of full implementation multiple inheritance.

I’ve got nothing against an “interface”. But I’d like them a lot better if I could migrate them to abstract base classes without breaking multiple inheritance. That’s often critical to reduce duplication.

If I could do that, arguably there would be no perceived need to visually distinguish them with the I. And suddenly we’re back on topic!

Tue, 13 Sep 2005 12:41:12, ,

The “interface” is a kludge.

Whoa! I resemble that remark. An interface is a pure contract/specification. Its value may be more obvious in Java than in C#, because Sun encourages multiple vendors to provide implementations. An abstract class is a pragmatic partial generalization. It’s not that we “need some multiple inheritance” - what we need is to combine two previously independent sets of behaviors.

I know how to build ugly structures with interfaces and composition around the lack of something basic like inheritance, but the problem is I shouldn’t need to.

They don’t need to be ugly. The same desired behaviors and properties can be encapsulated in the same number of classes - they just won’t be base classes.

Mon, 12 Sep 2005 17:48:40, Chaz Haws, RE: Single-inheritance rant Tom, my own take on multiple inheritance is that it is rarely needed but shouldn’t have been removed from either Java or .NET.

The “interface” is a kludge. “We need some multiple inheritance, but that’s hard and you folks can’t be trusted with it, so we’re going to make up a new special kind of abstract class and let you use it with that.”

Well, to be honest that’s worked pretty well. But it’s also true that this whole thread is caused by the artificial distinction between an interface and an abstract base class. When artificial distinctions start getting in the way, it makes me want real multiple inheritance back.

Mon, 12 Sep 2005 17:21:32, Willem Bogaerts, abstractness

If I’m a derived class, I need to know what I can use from my base classes and what I have to define, don’t I? This seems fundamentally different from “outsiders” that don’t care whether method X is implemented by me or an ancestor. I’m NOT an outsider. I’m very much in the family.

No you don’t. If you are a derived class, you ARE a form of the superclass. So you’re everything but an outsider. Like Constable John Doe IS a policeman. And if you do need to know, you still don’t know unless you mark the abstract methods, not the class itself, with an ‘I’. An interface just is a purely abstract class.

I know how to build ugly structures with interfaces and composition around the lack of something basic like inheritance, but the problem is I shouldn’t need to.

As for prefixing, I’m torn between two sides. In languages where multiple implementation inheritance is forbidden, the prefix warns you in case you want to extend two “normal” abstract classes. Even before you write the “extends” keyword. On the other hand, you get a situation where “all abstract classes are equal, but some are more equal than others”. Classes that are not part of the interface-or-class struggle don’t need to know if a type is an interface implementation, and abstract class or an imlementation class.

Mon, 12 Sep 2005 10:36:17, James Grenning, Ditch the I, and th m_, and the DAO Get rid of the “I”. Also you C++ programmers should get rid of the “m” and you DAO fans should get rid of the DAO suffix. All these annotations put up a barrier to being able to “read” the code. When I read ICommand I feel like there is something missing, like I Command you to take out the garbage. When I see the C++ programmers “m” I find myself humming while I read the code mmmmm counter, mmmmm index, mmmmm transmitter, mmmm window. Was the programmer really happy and humming, or were they confused and not sure what variable name to use? Probably the latter. Ohhh. a member variable, that is something special.

DAO? I’d like to be reading in code in the problem domain if possible. DAO is a solution domain suffix. High level design should try to speak to the reader in the problem domain. What reads better Employee.pay() or EmployeeDAO.pay().

I guess I went a little off topic, but i feel better now.

Micah, please leave off the “I” and explain your reasoning. Maybe this will help Microsoft programmers to break themselves away from hungarian notation.

James

Mon, 12 Sep 2005 09:54:52, Tom Rossen, RE: Single-inheritance rant Ignoring for the moment the issues of thread and type safety (generics are now available in Java 5)….

When I … graduated … from C++ to Java, I was pissed about the lack of multiple inheritance. But eventually all the OO propaganda about “composition” started to make sense. I don’t know PHP, but I’ve created collections in Java that were similar to the one you describe.

Essentially you’re building multiple indexes over a single collection, and it should be possible to do this by composition in any reasonable OO language. I suspect that a combination of abstraction (polymorphism and interfaces) and composition could solve just about any problem that presents itself as requiring multiple inheritance.

Mon, 12 Sep 2005 08:50:35, sdc, dsd ff

Fri, 9 Sep 2005 18:31:17, David Chelimsky, super-abstractness Willem Bogaerts wrote “the "abstractness" level of the super class is surely an implementation detail. And implementation (or the lack of it) should not be visible to outsiders!”.

If I’m a derived class, I need to know what I can use from my base classes and what I have to define, don’t I? This seems fundamentally different from “outsiders” that don’t care whether method X is implemented by me or an ancestor. I’m NOT an outsider. I’m very much in the family.

Fri, 9 Sep 2005 14:12:50, Willem Bogaerts, Single-inheritance rant

But now we have strongly typed languages.

If you mean java, we have not. In the XP yahoo group I held a little rant about the claim that multiple inheritance would be difficult. On the contrary.

In my example, I wanted to write a collection class for PHP (it is not built-in). As I wanted to select the members by position or by name, they should inherit the NamedItem interface. After I did that, I noticed that all the subclasses shared the same code for setting, keeping and retrieving the name, so I changed the interface to an abstract class and put the code there. But that prevented me to store Tests, DatabaseQueries, and lots of other useful classes in a collection. Now, what is difficult about a class being able to have two superclasses? On the contrary, try to explain what is wrong with it. Single-inheritance-with-interfaces is a defect in languages that claim to be object-oriented. I think the prefix was introduced because it facilitates the programmer in typing the right keyword (extends or implements). But that keyword should not be necessary, as the “abstractness” level of the super class is surely an implementation detail. And implementation (or the lack of it) should not be visible to outsiders! Back to the collection, the language prohibits the use of a general abstract member class. Now I understand why, in an so-called “strongly typed” language like java, every internal storage has to be done with general “object”s and a lot of casting. I don’t see any strongly typed language here.

In short, this interface thingy is a language bug that you keep fighting day by day.

Wed, 7 Sep 2005 09:17:23, Tom Rossen, Awkwardness… I’m imagining Copernicus’ reviewers saying “Hey - where are all the epicycles?”

Can’t do anything about the FCL - untouchable legacy. But I trust Micah can handle this issue in the introduction. It shouldn’t be any more awkward than explaining how agile techniques differ from traditional approaches.

Tue, 6 Sep 2005 22:35:39, Naim Ru, Recanting…

OK, I can buy the arguments for going against the MS standard, and promote a new standard in C# for naming interfaces (in the hope of someday getting rid of the last remnants of Hungarian notation). Meanwhile we’re still stuck with the IPrefixedInterfaceNames in the .NET FCL; perhaps being inconsistent with this is not such a big deal.

However, remember that Micah posed this issue in the context of writing a book, where he may need to deal with the awkwardness of having two different naming convention for interfaces in print (his own + FCL’s), with no IDE or complier to help out the faithful reader… yeah, that could confuse some people.

Tue, 6 Sep 2005 16:02:18, Liz, ICommand I was translating a ton of java into C# and discovered that I had to add the I. Otherwise property conventions didn’t work correctly.

I did it, I hate it, and now I wonder if I have to change the java to mirror it.

Tue, 6 Sep 2005 14:56:28, Marco A, can’t stop the huns For whatever reason, people get addicted to the Hungarian notation and can’t let it go.

Tue, 6 Sep 2005 09:45:10, Tom Rossen, As IF…. Having fought the battle on multiple projects against pre- or post-pending “IF” in Java, I would urge you to take a stand against “tradition” (~= “antipattern”) here.

An interface has two audiences: users and extenders. If you’re using it, you shouldn’t care whether it’s an interface or a class, unless you try to instantiate it, and the compiler will tell you soon enough. Most of the time you’re not instantiating, just referencing.

If you’re extending it, you need to look at the doc or the source anyway.

Well-written code (small classes, small methods, clear separation of responsibilities) has no need of Hungarian notation. What makes code readable is its approximation of natural language - Hungarian notation degrades that.

Tue, 6 Sep 2005 09:20:20, Casey, Ummmm - hardly an issue If you don’t use I…. then you are creating a different standard to the one almost all MS/C# programmers adhere to. So the first problem is confusion.

The second and bigger one is, the example you give is flawed. If you hose to turn your ICommand interface to a base class, then renaming isn’t going to be the issue (as it can all be done by Resharper or equivalent in a few seconds at most). The problem is that many classes implementing your ICommand interface could now be very broken due to C# not supporting MI - so anything that has a base class already isn’t going to work… and now you have a massive architectural nightmare.

Think first…. Agile doesn’t mean ‘hack it together quick and fix it later’

Sun, 4 Sep 2005 02:32:59, Naim Ru, Interfaith Interfaces?

The .NET framework is filled with IPrefixedInterface names.

Looking at the following examples in printed form, which would be preferable, the following with inconsistent naming and perhaps a comment?

class Unforgettable : Fire, IList // yucky comment: Fire is an interface 
{
  // ... implementation here
}

â€¦ or this following one?

class Joshua : ITree, IList
{
  // ... implementation here
}

So, on the one hand you have potential confusion due to inconsistent naming conventions and you violate typical C# developer expectations. In printed code, you may have to add comments to help sort things out.

On the other hand, you have a notation (I*) that gives client code knowledge about a type it references which it does not strictly need (that it is an interface), which results in some small – but not insignificant – renaming pain that can happen during refactoring.

This is an interesting dilemma and a very close call. I prefer the consistency, and until I see better reasons to abandon the C# interface naming standard, I will continue to use IPrefixedInterface names in .NET code.

Sat, 3 Sep 2005 10:07:16, keithray, about I-prefixed interfaces See if you can put this story (“how I started with an I-prefixed interface, then changed it to an abstract class, and all the pain the ‘I’ caused”) early in the book, and say that for the remainder of this book, you will not use the I prefix and that you recommend your readers don’t do that either.

Thu, 1 Sep 2005 01:03:01, Chaz Haws, When to use an interface Okay, Micah, one more comment: In my work, the behavior that I’m looking for would almost always allow either an interface or an abstract class. I have so far tended to use the interface notation, due to brevity. But my most likely line of evolution is just as you describe. I make those kinds of changes all the time.

Come to think of it, I probably shouldn’t be using interfaces at all. I almost never need the multiple interface inheritance.

Thanks for making me think about it. I think I’m going to write a lot fewer interfaces.

Thu, 1 Sep 2005 00:44:31, Chaz Haws, Interface notation I don’t care for it myself. But I can see it being useful because it instantly communicates that multiple inheritance is an option for this type (as others have mentioned). If you can’t personally run all the tests that will demonstrate that converting from an interface to an abstract class, then that conversion isn’t really an ideal option for you anyway (as others have mentioned). If you’ve got those tests available, then this is a real issue, and you’ve got a good solution. People will nitpick it, though. Especially people that don’t think about source control all the time, like I do. How many reviewers reported that they were confused, as opposed to guessing that other people would be confused? I’m guessing zero. I hate having to make such choices. I feel your pain. Two parting thoughts: Multiple implementation inheritance would make this (rather artificial) distinction completely moot. I still miss that from C++. And we need more advanced source control to deal with just such refactorings. Name changes as classes evolve and source control needs to deal with that.

Wed, 31 Aug 2005 10:14:13, David Chelimsky, I think that a very interesting part of this discussion is the notion of where (in a design) to use an interface and when (in process) to introduce one.

As for the “when” question, the notion that we should introduce them earlier rather than later denies (defies?) TDD as a design activity. We don’t know that we need an interface until we need one, right? Experience suggests that in many cases this will be very early on - perhaps even during domain model discussions (if that’s your approach), but it also suggests that we won’t catch all the cases up front, at which point we need to be able to easily introduce interfaces later in the process.

As for the notion of the correct way to use interfaces, I find it limiting to suggest that they are only there to describe behavior. Agreed that interfaces serve us well as definitions of behavior, but I think that they also serve us well as definitions of structure. Expressing high level domain concepts like People and Accounts in interfaces allows us to begin to decouple implementations of one from the other, allowing us to choose where to start development based on business value rather than a preconceived notion of architecture. Not to mention dependency injection frameworks that prefer interfaces.

Wed, 31 Aug 2005 05:15:20, Thomas Eyde, Published code and Java vs C# syntax Some additional points: If this is a published library, then a rename will break existing code outside of our control.

Java has “extends” and “implements” which communicates very well on what the class inherits. C# doesn’t have that, instead it uses the convention that if you inherit from more than one thing, the first must be a class and there can only be one class.

I am not sure that is a valid argument. I used to think Hungarian notation was a good thing, too. I guess I have to try out my interfaces without the “I” before I make up my mind.

Wed, 31 Aug 2005 05:27:14, E Charignon, Make your book easy to read. As it was said before, modern tools tend to make this ‘I’ prefix convention useless. Unfortunatly, you don’t find this ease of navigation when reading a book and naming convention helps a lot. I made myself the same reflexions about comments. It might be wellcome to overcomment code examples into books because you are explaining something (you want to say in plain english what the code is doing) and the code there is not going to change once it has been printed. At the contrary, you would not make so many comments in you code since it will make bugs difficult to find and comments maintenance is a nightmare.

Wed, 31 Aug 2005 03:14:17, J Drakes, Use of interfaces I see. you suggest to use the -I- like the -able- in java. Interfaces that are root to “structural” objects rather than “behaviour” objects (pardon the artificial distinction) would drop the I. Behaviour tags would keep the I.

Tue, 30 Aug 2005 23:47:40, Eddie de Bear, Time to learn about correct use of Interfaces. I think you may actually be incorrectly using interfaces if this is the problem you have with them… Interfaces should be used for secondary behaviour, such as IDispose, ISerializable, IBendable, IKickable etc. i.e. where actually deriviving from a base type is not going to work. You can still treat each object as it’s interface type, even though it’s not… Maybe the I should be changed to B for Behaviour!!!

The real question is, do you have a problem with the I prefix, or do you have a problem correctly selecting between an interface and class in early stages of development???

Just my 2cents…

Tue, 30 Aug 2005 21:09:27, Keith Nicholas, Aye Aye Cap’n I think you should keep the I, but explain your reasoning why you don’t like it. However, your justification (so far) sucks. “I don’t like “I”s because my tools make it slighlty painful to change it later” dosnt seem like a really good reason to not have “I“‘s. If that was your reasoning then if resharper was made to automatically do a rename in subversion you’d be happy. Also if this was the case, then you should do some design up front so you get the names of classes right before you start work because its “painful” to change later….hmmm…

5 years of Extreme programming with C# using I’s and I’ve never thought, “bugger, I wish we hadn’t prefixed an “I” onto this”. When we have needed, we have simply taken the I off and made it abstract. no big deal. I did have a bit of hesitation in the beginning with pushing type information into the name but it really hasn’t hurt us. If you do think it does major harm I’d be interested in your reasoning that adds up to a “good deal of hurt” if you had a tool that renamed ICommand to something else in < 1 second….

Tue, 30 Aug 2005 13:33:14, Ivan Vaghi, Hungarian Notation Contrary to popular belief there seem to be some valid uses for Hungarian Notation, and it looks like its actual use is quite different from what it was originally intended for.

Spolsky here explains how to use it to create a ‘conventional’ algebra http://www.joelonsoftware.com/articles/Wrong.html

eg: daysTime1 + daysTime2 is correct daysTime1 + hoursTime2 is not correct daysTime1 + daysFromHours(hoursTime2) is correct

where both days and hours are plain numbers

Of course, you could use typed objects, but sometimes it’s just not worthed. Also note that the prefix indicates the semantic value of the number, rather than just pointing out the type of the number.

Hungarian-like naming can also be useful in dynamic languages for readibility.

eg: def enroll(aperson) #aperson is (usually :-) of type Person def distance(startpoint,endpoint) #it’s getting 2 Point instances

The hungarian-like style I like gives semantics, not just syntax.

Tue, 30 Aug 2005 13:01:44, Ben, IThinkYouMayBeOnToSomething Its funny, I’ve always hated the Hungarian notation. I’m not sure if this convention arose from that hideous pain of a standard, but for one reason or another its a standard that I happened to adopt. Probably for no other reason than seeing it used in other peoples code. What can I say, monkey see, monkey do.

What do you think of the hungarian notation? The developers at my new company love it, and really don’t want to abandon it, despite all my pleas. From what I’ve seen on the web, there are valid arguments on both sides of the coin.

Tue, 30 Aug 2005 11:35:33, Bill de hOra, Your reviewers are guilty of foolish consistency. Java went through this way back when with people appending IF to interface names, before it was dropped as a bad idea. Interfaces in static languages have enough problems without this cruft.

Put it this way. If you don’t drop the convention, I won’t buy the book.

Tue, 30 Aug 2005 10:06:18, , Ni vagree!

Tue, 30 Aug 2005 08:40:08, UncleBob, Hungarian Notation in the 21st Century. There was a time, long long ago in the 80s, when C compilers did not check types and programmers could pass ints to functions that took doubles, that Hungarian Notation (HN) might just possibly have been a sort of OK idea maybe. Maybe.

But now we have strongly typed languages. Now we have IDEs that tell us the type of an identifier simply by hovering over them with the mouse. Now we have Object Oriented languages which soften the notions of “type” and nudges us to hide type rather than expose it.

So, Captain, we are no longer using stone knives and bearskins to get our jobs done. And we don’t need the trappings that, just possibly, maybe, were a sort-of good-idea in the stone age.

I don’t miss the I’s (or the C’s, or the pszqt’s)

Hay! I’ve got a great idea! Let’s prefix every noun with an (n), and every nadjective with an n(j), and jevery nadverb with a n(y), and jevery nverb with a (v). nPeople vwill yquickly vfind nEnglish vto vbe jmuch jmore jreadable.

Tue, 30 Aug 2005 08:19:45, Michael Feathers, Micah wrote “Here’s my dilemma. Maybe you can help me. I’ve been translating Unclebob’s Agile Software Development book into C#. In the code examples I have heeded my experience and created interfaces without the I prefix. Reviewers don’t like this. They keep telling me that I need to add the I prefix. I’m torn. I feel in my heart of hearts that using the IConvention does more harm than good. Yet, readers of the book will be familiar with the IConvention and may be confused by examples that don’t use it. What’s the right thing to do?”

I think you should use the convention after you tell the reader just how stupid it is. I think I railed against it in WELC twice. Couldn’t help myself.

Tue, 30 Aug 2005 08:10:58, Mark Howard, drop the I Drop the I, it’s a bad convention that should have never been there. It smells of hungarian notation

Tue, 30 Aug 2005 06:46:21, Dave Hoover, I Agree with Thomas and Tanton Don’t rename the interface, implement it with an abstract class. Stick with the conventions of the language, readable code is the first step toward adaptable code.

Tue, 30 Aug 2005 04:46:50, Thomas Eyde, IConvention I don’t really see the problem. Why don’t you just do:

abstract class Command : ICommand {}

And you could have both artifacts in the same file, without the “I”: Command.yourfavouritedotnetlanguagesuffix

Tue, 30 Aug 2005 03:14:07, J Drakes, Different audiences This is not the first time I meet this problem. The way I see it, if you are a ‘user’ of the classes, then you shouldn’t care at all about the implementation details of what you call, you should just focus on the readability of the code. You are just using some ‘words’ whose use and semantics are expressed by the test cases. However, the very moment you decide that you want to modify that code, then you get swamped in all kinds of syntax-oriented technicalities and then you have to care about the nature of the ‘words’ that you are using, and those ‘I’ that you use to colour your code can be handy. I don’t have one single answer for you.. it depends. I usually solve it giving my expert users a set of classes that are easy on their eyes, while those classes are based on rougher code with the ‘I’s still sticking out.

Mon, 29 Aug 2005 23:51:02, Tanton Gibbs, Additional Problems I think there are more problems than just renaming files. If ICommand were an interface, then it could participate in Java and C#’s multiple inheritance of interfaces. However, if ICommand were suddenly changed to a class, many classes could be unduly broken. Determining if an entity should be an interface or a class should be something you strive to get right at the beginning. If you choose the interface prematurely, then I would think that you could add a helper class CommonCommandImpl that instantiates the interface and other classes could choose to inherit from if it made sense for them. Therefore, I think the least of your worries is renaming and if you chose to put the I in front of interfaces it would be neither a good nor a bad decision. I think if it is an “idiom” for that language, then you should follow it.

Software Apprenticeship

by: micah | September 7th, 2006 | 0 comments »

David Hoover asked me a few questions about my experiences as a software apprentice. I was happy to answer his questions and pleased to hear that he’s writing a book on the topic.

What is Software Apprenticeship?

Software apprenticeship is path for learning to become a quality software engineer. A software apprentice learns to write code by working with people people who already know how to write code and are good at it.

It’s also an attitude. People who practice the software craft are on a journey of continual learning. There is no piece of paper that deems a craftsman worthy. A craftsman qualifies himself by demonstrating his skills.

I’d argue that any great software developer has been through an apprenticeship stage at one point or another.

How did I hear about Software Apprenticeship?

I saw my father reading a book titled Software Craftsmanship by Pete McBreen. This was shortly after I finished an unsatisfying 5 years in college. I was also knee deep in my apprenticeship, though I didn’t call it that at the time. I read the book and fell in love with the idea that software is a craft. For several years of my life I practiced martial arts and the model for growth in Jujitsu is very similar to that of software craftsmanship. So the concepts were not new to me but seeing software in this light clarified a few things…

No wonder I was so unsettled with my college education… That’s not how you’re supposed to learn software. Of the dozens of classes I took in earning my Computer Science degree, only 3 classes involved writing code. Crazy huh? And even though I could write programs after I graduated, I didn’t know the first thing about writing real software. A lot of good college did me! It was working with the great people at Object Mentor, especially my father, that truly taught me to code.

Not long after I read Pete’s book, Ken Aurer invited me to a Software Apprenticeship summit. There, several pioneers in the software craftsmanship movement got together to share experiences. I learned a great deal but what I took away from that summit was the comfort that there were lots of people who believed in the craftsmanship model. It was only a matter of time before the rest of the industry caught on.

Where am I in my journey?

For those new to the craftsmanship model there are three stages: apprentice, journeyman, and master craftsman. I’m well on my journey as a journeyman. I work on a variety of software projects, I teach, I consult, and I learn more about software every day. And to take this entry full circle, I help other budding software apprentices get started on their journey by leading Object Mentor’s apprenticeship program every summer.

Wed, 22 Jun 2005 21:53:29, David Chelimsky, hands on I had the good fortune to attend a graduation at which Deborah Meier spoke. Ms. Meier is an innovator and educator who founded a grade school at which kids of varying ages/grades work in the same classroom. She described the inspiration for this, talking about how schools USED to be when we (in the US) were a more agrarian society. There were two comments she made that seem relevant in the context of this discussion. One was that you would never choose to take a tennis class in which students sat around talking about tennis and then, one special day, the teacher brought in an actual tennis ball and passed it around so everyone could hold it and see what it felt like.

The other was the fact that in days of school gone by there were many experts and a few novices. The 7 year olds helped the 6 year olds. The 8 year olds helped the 7 and the 6 year olds. Etc, etc. Many experts and few novices - not one expert responsible for 30 novices. This made me think of the blacksmith analogy that permeates the Craftsmanship book.

Wed, 22 Jun 2005 01:53:36, KelleyHarris, ?Finding mentors for mid-career people? Great article Micah. Any suggestions for mid-career people looking to find mentors, full-time, part-time, or remote? Seems like there is room for a service connecting people. There is also room for a service providing object mentoring post OM courses.

There is no piece of paper that deems a craftsman worthy. A craftsman qualifies himself by demonstrating his skills. As people look for new jobs, what would be some good ways of demonstrating skills, at the resume & interview stage?

Any suggestions on open-source projects with great OO TDD code?

Mon, 20 Jun 2005 08:51:34, George Jensen, My Story I guess my story would be different from Micah’s in that, Higher Ed was good for a few seasons, but by no means did I expect to begin learning a craft there. If the above statement were a microcosm for Liberal Arts experience, we might assume it a bankrupt philosophy. This is the impression Micah might give off. After spending a week with Uncle Bob with Java immersion (2002), I can say I was one of those “Masters Level” students who knew nothing of good programming practices. I studied History in undergrad, and Information Science in Post-grad; but I continue to be pulled by the curious efforts Uncle Bob uses to hown the craft of programming, and his old-factory style of learning programming as a “craftmanship”.

I ask daily: With all the altruistic spirits of academia stuffed down our modern minds, why is it so refreshing to hear the obscure rant of Uncle Bob (and others) toting this old-factory campaign about “craftmanship” as a life goal?

Fri, 17 Jun 2005 10:02:01, Uncle Bob, Things have indeed changed. Keith, Things have indeed changed; at least in some sectors. A couple of years ago I brought in an intern who was in a CS masters program. This inidividual simply could not write code, nor had they been taught to write code. I was flabbergasted. I’ve poked around a bit since and have found that, at least at some schools, it is possible to acquire a BSCS, and even an MSCS, without ever having to write a line of code. Incredible!

Thu, 16 Jun 2005 11:22:16, Patrick Morrison, Things were different, but not necessarily better I must’ve gone to college around the same time Keith Ray did, as I can’t think of a CS course I took that didn’t involve at least some programming. But, with one exception (Principles of Software Engineering), every single course required the student to work alone… this is the antithesis of the craftsmanship model, and I’m sure it stunted my growth as a practicioner.

Thu, 16 Jun 2005 09:50:09, keith ray, things have changed When I went to college and got a computer science degree, just about every computer science class required writing code. The only one that didn’t was the one where we designed a CPU. Those who were in computer engineering rather than computer science had a sequel to that course: they had to implement their cpu design.

We programmed in FORTRAN, Pascal, C, 68000 assembler, and COBOL, and the “survey of computer languages” course had us writing short programs in APL, LISP, SNOBOL, and other some other languages.

Jack and Jill

by: micah | September 7th, 2006 | 0 comments »

Once upon a time there live a young girl named Jill and her next door neighbor Jack. Perhaps you’ve heard of them. When Jack and Jill were about 5 years old they both desperately wanted to learn how to ride a bike. Jill’s father, being a practical man, bought Jill a nice child-size bike and took Jill outside to practice riding the bike every chance he got. Jill’s dad would hold Jill up right and move with her while she pedalled. Within a few days Jill was able to ride for moments at a time without her father’s support. After another day, Jill could ride her bike all by herself.

Now Jack’s family was a bit more rigorous. Jack’s father thought it important that Jack have a solid understanding of bike riding and the science behind it before he start riding a bike. So instead of a bike, Jake’s dad bought various books on physics and cycling history. For weeks Jack learned from his father much about kinetic and potential energy. He gained an understanding for gyroscopic forces and much, much more. After about a month, Jack knew everything there was to know about bike riding. It was at this point that Jack’s dad bought a bicycle for Jack. Jack proudly mounted the bike and promptly fell off. He mounted the bike again, peddling slowly and ended up in another painful fall. Meanwhile Jill was effortlessly riding her bike around block, feeling bad for her friend Jack.

Later in life both Jack and Jill graduated high school and wanted nothing more than to become software developers. Jack, following societal protocol, applied to a prestigious university was accepted to the computer science (CS) program. At the onset of his first semester, Jack was mildly disappointed to find that CS program alloted only one class in the first semester that had anything to do with computers. This class was called “Computer Algorithms I” and involved no programming what so ever. Other than this Jack learned Calculus, Philosophy, and other peripheral classes… lots of classes that had nothing to do with computers.

Meanwhile Jill moved to Chicago to become an apprentice for a renowned software company. On day 1 Jill was learning to write Python code as she worked side by side with an expert programmer. Like a kid in a candy store, Jill was nearly overwhelmed with all the software knowledge and learning experiences surrounding her. It was great!

After a few years, Jack had graduated. With all the calculus, differential equations, spanish, number theory, and computer architecture classes, there was no doubt that Jack was a full fledged CS graduate. It didn’t matter that he had only written a couple hundred lines of code by this time… He had a bachelor’s degree! Jack soon landed a programming job in the IT department of a large company. On his first day Jack was introduced to the project he’d work on. He met the team, found his desk and was anxious to get started. Later that day his project manager walked in with a thick binder titled “Data Model/Object Model” and said “Read this by next week”.

At around the same time Jill already knew how to program in Python, Java, C#, and had dabbled in a few other languages as well. Object Orientated principles and pattern came naturally to Jill since she had used them extensively on a daily basis. Having worked on a few successful projects she knew a bit about managing projects and what it takes to get them done. No doubt about it, Jill was a software developer to be reckoned with.

Sat, 22 Oct 2005 18:35:39, Sy, How much shallower you could be? Jill you mentioned probably one of those who think programming is learning syntax of many languages, assimilating technologies and spending rest of the life buidling “nigh performance”, “scalable”, “enterprise” apps for naive users to let them do data entry. Clearly you haven’t solved demanding problems in programming. Try this: write a program to find the contingeous set of elements in int array whoes sum is maximum. This problem comes up in image processing and most “programmers” (i.e. VB, C#, Java hero types) would have difficult time to come up with anything efficient. If you do come up with something, can you analyse it’s performance on asymptotic scale? About learning calculus, have you (or are you able to) write cool simulations (like those in billiords game)? Do you know how and why Google’s BigTable structure works? Have you ever tried to write 3D rendering for choosen vantage point? Can you look at kernal code and tell me why it must manage threads in some specific way? Writing code in high level language for data entry screens is easy. Creating cool algorithms is hard. And if you didn’t took a courses in CS, you probably even wouldn’t know what Big O notation means or how Hashtable works internally or why Trie DS is vastly more efficient for search.

Vast majority of self tought programmers end up in mediocre jobs in big company and climb up the ledder to become a dev lead or manager in 4 years while their mates are still trieng to graduate with CS major. They might joke about CS majors wasting their years but there is stark diffrence in their capabilities and where they would finally end up. People who could answer above questions would probably be working on ground breaking projects at Google or MS or Nasa while people who can’t would be still trieng to fix the bugs in their trivial so called enterpirse apps.

Discloser: I’m not CS major!! I leard this truth hard way and wasting my years developing software for insurance and financial companies for 8 years. Yeah, I’m now senior programmer, make big bucks but had been rejected twice by MS and once by Google.

Mon, 17 Oct 2005 13:13:57, Alex Mueller, A true education never ends I understand the alluded to point of this story. People learn in many different ways, and what works for one may not work for another. However, I do have a few comments on the importance of education, and by education, I mean the underlying desire that motivates individuals to pursue knowledge.

The point of this story is that traditional education taught in schools will not guarantee understanding, competence, and ability. Individuals will retain different aspects of an education. A true student is never finished learning. A true education extends beyond the classroom.

A traditional education conveys to me these things. One is the ability to learn new concepts, and when required, to regurgitate these. The most visible result of education is the ability of the individual to complete a project from start to finish, essentially, doing what needs to be done, when it ought to be done, regardless of whether they like it. In the world outside of the classroom, this is a valuable lesson to learn. Another lesson is balancing work and life.

Achieving the degree is an accomplishment worthy of accolades, because it is not easy. I do not want this Jack and Jill story to belittle education. For those students out there who pursue education in addition to working, tending to families, and dedicating their time to outside activities, these individuals represent the hard work and dedication needed for success. A lesson learned the hard way.

The individual is responsible for their drive to succeed, and this cannot be taught. Ultimately it is up to them to pave their own roads. Jill appears to already be successful, but this does not make her approach any more or less appropriate. Jack’s education alone will not suffice, he needs to apply it.

This story compares Jill to Jack, at a time when Jill has been working in the industry for some time, and Jack has just begun a new job. Give Jack some time before condemning him. Education is perhaps better left to the individual to decide which path is more suitable.

Sun, 16 Oct 2005 22:57:53, someone, JackAndJill Is it any wonder Jill Advanced much faster than Jack (When jack, wanting to be a programmer, took Computer science related courses, instead of Software Engineering ?!) Did everyone here miss that point ?

Anyhow, Education is important, school is not. I know several people, who to begin with in software / computer fields were H.S. drop outs. This is not to say, I would advise anyone to do so, because I would not. However each individual needs to find thier own path in life. If you speak to anyone in the computer field, and asked if they would hire someone with experience, or someone with a degree, well, any one of you in the field knows the answer to this.

From personal experience I would say a well rounded education would/could help in any situation, but as always there are exceptions to every ‘rule’.

Sun, 7 Aug 2005 15:17:49, Bill Caputo, There is an implied premise here that is the real problem… …and that is the increasing emphasis on College as: “Preparation for Career.” In so doing, it has also become the new high school, so now adulthood is reached after college. It wasn’t like this 200 years ago. Older descriptions of college seem to describe a place where one “Prepares for Life” by learning about it, and learning how to learn about it. The so-called classical education wasn’t practical, but it was essential for taking one’s place in “learned society.” An unintended consequence of extending education to everyone? (it was once the purview of the wealthy only, some guy named Jefferson among others were big on changing that. My take on this then, is that college then apprenticeship might be the best path of all – if only the colleges didn’t cost a fortune, and only attract people because they might need to “get a job someday.”

All I know for sure is that I didn’t study computers in college, but my education serves me very well everyday I go to work with them.

Thu, 14 Jul 2005 14:23:53, Vishal Shah (vishalshah.org), Never reason from one example/case/situation Picking an apple from a lot of 10,000 will not say anything about a lot. Picking an example of this->John and this->Jill gives a person nothing to reason/imply/believe. Besides we don’t need just on kind of apples. We need a variety of them that suits different tastes and recipes. Every person is unique in its own and this idea can not be generalized or “reckoned”.

This post hence says nothing to me. In fact I am worried as it might send a wrong statement to readers. Instead here is something that you can rely on - “Believe in yourself”

BTW. At the end of day, despite Jill being a great software developer might not be as happy as Jack because he got a wonderful wife whom he met in college. While Jill never found someone she could truly love because she did not have a chance to find the opposite type. She also missed the chance of having a college life, which once lost can never be regained. To gain something you have to loose something and it is upto that particular person to decide what he/she would rather loose.

Thu, 14 Jul 2005 09:45:02, Suresh V., And what happens when it is time to redesign the bike…

Sat, 18 Jun 2005 02:03:43, bookie, heres another perspective in my experience, there are two kinds of ppl, people who build things versus pppl who build tools. both kind of people are required in any domain to function well. However, lets not typecast one over the other, maybe jack might become a toolmaker and be no good at building anything. maybe jack might become someone who proves p = np. maybe jill will write really bad c^n algorithms.

point being fitting people to their jobs is as important.

Fri, 17 Jun 2005 09:50:06, Uncle Bob., A Learning Attitude. At Object Mentor we practice the apprenticeship model. Young bright people from 16 years and up, are encouraged to work on real projects with real developers, in an atmosphere of learning. We teach them a lot, and (if they have the hunger) they learn a lot. There is no better way to learn a craft, like software engineering, than sitting with a master or a journeyman.

That being said, learning must be broad. We would be doing a huge disservice to our apprenctices if we channeled them to learn nothing but the craft of software. We would also be doing a huge disservice to ourselves. Learning, regardless of ”’what”’ you are learning, is beneficial to everything else you have learned. Your career as a software engineer will be enhanced if you learn a little American History. You will be able to understand the company you work in much better if you study a little political science. You’ll have a better perspective on life, including your employment and your carreer, if you study some Philosophy. You’ll have a better perspective on just about everything if you study a little Astronomy and Cosmology .

So, whether it be college, reading, mentoring, or apprenticeship, the main thing is the Learn.

Fri, 17 Jun 2005 08:13:51, Mohan K Jadhav, Though I have graduated in an Engineering Major other than the Computer Science, I would say that it is not the college degrees that would help one to acquire the skills. It is the learning attitude that matters most. Of course, a formal and a structured education would always help in understanding the ‘how’ part of anything since in the college one is supposed to study the fundementals of the various subjects. I agree with Rod, that the combination of throery and practice is a powerful arsenal.

Thu, 16 Jun 2005 10:42:30, Phil Spitler, Could not agree more Micah, you hit the nail on the head on this one. I have been programming for over 8 years now and until recently never went to college for one day. The one class I signed up for I dropped because it was aweful. Style guidelines (e.g. hungarian notation) were of more importance than learning to write code. Needless to say, in the future I don’t see college playing a role in my programming career.

Thu, 16 Jun 2005 10:18:14, Rod Morehead, College can be a time of Mentoring When I went to Austin College, a small liberal arts college, I wasn’t sure what I wanted to be. But I took a wide range of courses, and discovered I had talent in Computer Science.

A computer science professor there, Mike Higgs, takes all his students under his wing, and gives them a firm grasp of the experiential and the theoretical. During college I served internships, putting what I had learned to work. After graduation, his connections helped me get jobs multiple times in my career.

The combination of theoretical and experiential is powerful, it allow ideas from both areas to cross-pollinate. I have know many software engineers who excel in only one area are the other, but the ones who have both are the most useful: they can combine the how and why.

Some people can teach themselves what they don’t receive during formal training, and college is not for everyone, but if you can I recommend it. Without college I would not have gained other non-computer science related skills that are invaluable in my day to day work. College helped me become a life long learner, which is a key ingredient in software craftsmanship, and gave me a mentor and friend.

Thu, 16 Jun 2005 07:46:24, Joe Kuhn, Add on comment about Micah’s Jack and Jill article There’s a critical component to riding a bike, the balance part, that you can teach your kid with a scooter before ‘graduating’ to a two wheeler. My kid was two when he got on the scooter I gladly bought him because I could see the opportunity. When he was three he was free wheeling all around the neighborhood on the littlest 2 wheeler we could find. It took him about 30 minutes to get the pedal coordination figured out when starting. I’ll always remember his older sister clapping and yelling, “you got it Johnny” when he did it all himself. Micah’s article is consistent with this concept of teaching the critical component to exclusion, if you know you want to be a programmer. College is over rated and over priced. So we can stop emphasizing the bs when hiring!

But some kids don’t know what they want to do when they go to college…

Building a City

by: micah | September 7th, 2006 | 0 comments »

Building software is like building _____?

The common belief is that software is like engineering. Most people seem to think that building a software system is like building a bridge. This is likely the premise that Waterfall was built upon.

process	Building a Bridge	Building a Web App
Analysis:	How Long? What’s it gonna hold? What weather does it need to endure?	What’s the feature set? How many hits? How much data? What platform?
Design:	Draw diagrams. Do calculations. Build miniature model and stick it a wind tunnel.	Think about high level architechture. Draw class diagrams. Draw some dynamic runtime diagrams.
Implementation	Build the bridge.	Write the code.

As an enlightened agilist, I know better than this. Building software isn’t like building a bridge. But what is it like then? There is a craftsmanship movement that says software is a craft similar to woodworking or blacksmithing. I believe this is true. However, I can’t say that building a software system is like building a wooden table or a chainmail shirt. Having built both a wooden table and chainmail shirt I can attest the the fact that these analogies don’t capture the depth or complexity in software. So what does?

Cities! Building software is like building a city. No city starts with an analysis committee to decide how may people are going to live there. The population of a city changes over time. The infrastructure of cities is not designed before the city is built. A city’s infrastructure starts simple and evolves over time as the city grows and changes. Cities are not built in one fell swoop. Cities start as small towns and are built up over time as new needs arise.

For those who have had the privilege, think about the first time you played SimCity. Do you remember the first time playing, just trying to figure out the rules. You probably started by building a small residential, commercial, and industrial zone along with a couple roads to connect them and a power plant. It wasn’t long before these zones were fully populated at which point the citizens began to complain about crime. So you had to build a police station and add more building zones. Soon these were fully populated and the citizens complained about other problems. As the needs would arise you had to add a fire station, schools, libraries, and eventually, an airport, sports stadium, and the coveted Archology. That’s how I started.

Although functional, my first city was eternally haunted by pollution, traffic, crime, poverty, and other normal city problems. This wasn’t good enough. I wanted to build the perfect city; A city without all those normal city problems. So I pulled out a piece of paper and designed a city where the industrial zones where far from the residential zone. This avoided pollution. I drew an elegant highway system that was sure to avoid any form of traffic. The city layout was an even grid to evenly distribute police and fire station coverage. It was perfect! I started a new game to build my perfect city. In an hour I was bankrupt. I tried again, and again I went bankrupt. I must have tried a dozens times to build the perfect city and went bankrupt every time. Finally I gave up and reverted by to my very first approach….. start small and build as needed. This more agile approach seemed to work every time.

Building software is like building a city. Start small and go from there.

Mon, 14 Mar 2005 20:19:23, Hui Deng, Yeah, Anything complex will follow the same rule.

Tue, 15 Mar 2005 00:02:08, Kelley Harris, Very nice analogy for software. Adds time dimension and more complexity I like that the city analogy includes the time dimension, evolution, and enough complexity that most people would be struck by the limits of their ability to predict the future. Consider weaving in a comment about the cost of change curve.

Other analogies with time dimension:

growing a company
growing a garden
developing a farm
developing a network (or the internet)

Tue, 15 Mar 2005 06:14:48, Denis Krukovsky, My wife is an Architect. She’s real Archirtect, she designs houses. She heard words like Analysis and Architecture from me and wondered why I’m professionally using words from her profession. Then she saw my diagrams, and she told me the same I just read.

Denis Krukovsky http://dotuseful.sourceforge.net/

Wed, 16 Mar 2005 00:16:42, Chris Noe, Deeper analogies I like the city analogy. How about exploring this a little further by looking at specific activities in developing a software system. In the evolution of a city, what would be the analogies for:

prototyping refactoring debugging performance tuning configuration management defining requirements database conversion archiving involving stakeholders federating with other systems open source continuous integration backing out a deployment the system has crashed

What city-building analogies might we learn from? Which things do we do better in software? What other software activities might have urban analogies??

Wed, 16 Mar 2005 14:07:07, Joseph Graves, More analogies The usual poor analogy I hear is “building a house” - I once had a contest to try to find 100 better analogies, but I must admit SimCity is quite good. I personally liked Barbecue (as opposed to Ronco Sho-Time Rotisserie set it and forget it software development).

Thu, 17 Mar 2005 14:40:18, MicahMartin, Deeper analogies explored This is interesting….

”’Refactoring:”’ - construction. Chicago suburbs are notoriously slow at refactoring.
”’Debugging:”’ - This could be a lot of things… Why is Main street so congested? Why does Hinkston Park flood periodically? Why is there so much crime on the south side?
”’involving stakeholders:”’ - democracy/voting
”’open source:”’ - communes?
”’the system has crashed:”’ - power failures, blizzards, hurricanes, …

Thu, 17 Mar 2005 19:56:19, Erik Meade, That’s pretty sweet.

It also helps to explain the tie in with http://www.c2.com/cgi/wiki?ChristopherAlexander the only “real” architect I have met said Christopher Alexander was not well recieved in his field.

Buffer to the Rescue

by: micah | September 7th, 2006 | 0 comments »

Recently I was working on FitNesse to solve the problem of large file uploading and downloading. Previously when a file was downloaded FitNesse would happily build a response in memory including the entire contents of the file. If the file being downloaded was 10k then the response was just over 10k and if the file was 10M then the response was just over 10M. With larger files FitNesse would run out of memory before it could finish building the response. Similarly, when uploading large files, FitNesse would attempt to read the entire uploaded file into memory.

For downloading the solution was to build a response that used an InputStream to read a few bytes at a time and write them. That was simple. For uploads a similar approach had to be taken where the uploaded file is read in a few bytes at a time an saved in a temporary file. But reading the uploaded file from the request was a very interesting problem. Here is a sample HTTP request for a file upload:

>POST /files/ HTTP/1.1
Content-Type: multipart/form-data; boundary=----------x0xKhTmLbOuNdArY
Content-Length: 273
------------x0xKhTmLbOuNdArY
Content-Disposition: form-data; name="responder"
upload
------------x0xKhTmLbOuNdArY
Content-Disposition: form-data; name="file"; filename="sampleFile.txt"
Content-Type: text/plain
This is a sample file.
------------x0xKhTmLbOuNdArY--

Notice that this is a multipart request and the parts are separated by bunch of characters called a boundary. The first part is called responder and has the value upload. This tells FitNesse that the user wants to upload a file. The second part is the file. It’s name sampleFile.txt and its content is This is a sample file.. Notice that there is no indication of the length of the file content. The Content-Length header says that the body of the request has 273 bytes but that includes all the parts. FitNesse has to read this request one or more bytes at a time without reading even one byte too many. Think about how FitNesse should read that file content. We know that it starts just after Content-Type: text/plain and ends just before the boundary(————x0xKhTmLbOuNdArY) but we don’t know how long it will be.

The original implementation for reading the file content looked something like this:

public void read(InputStream input) throws Exception
{
    int b = input.read();
    if(b == -1)
        changeState(FINAL_STATE);
    else
        bufferByte((byte) b);
    if(bytesEndWith(bufferIndex, bufferedBytes, boundary))
    {
        bufferIndex -= boundary.length();
        changeState(FINAL_STATE);
    }
}
public static boolean bytesEndWith(int index, byte[] bytes, String boundary)
{
    int boundaryLength = boundary.length();
    if(index >= boundaryLength)
    {
        String subString = new String(bytes, index - boundaryLength, boundaryLength
        return boundary.equals(subString);
    }
    else
        return false;
}

This code, though plagued with two significant problems, served it’s purpose well in production use for almost two years. The first problem is it’s blatant inefficiency. For every byte it reads allocates a new String object, copies N bytes into the new String, and performs a String.equals(…). This would take forever for large files but it never gets the chance because the second problem is that it stores the file contents in memory and it runs out of memory for files larger than 2M.

So I began to change the code to copy the bytes to a temporary file instead of storing them in memory. This presented another problem. The code above stops reading after it reads the last character of the boundary. This side effect left all the uploaded files ending with the boundary characters. So the I had to change the algorithm so that it only saved a given byte if it was not part of the boundary, all the while not reading one byte past the boundary. This was a fun problem to solve and I’ll leave it up to the reader to figure it out.

Then it worked!. I uploaded a 1k file…. Perfect! 1M file… no problem. 10M file… chug chug done. It worked! These were bigger files than FitNesse could ever upload before. I started to search my hard drive for bigger and bigger files to upload. I zipped up a Norah Jones album of MP3s into a 55M file and tried to upload it…. chug chug chug chug… chug chug… nothing was happening. Hmmmph. This was strange. After some unsuccessful investigation I decided to put some debugging print statements. At one second intervals it printed the number of bytes that it copied from the uploaded file. Here’s what I got.

1: 186111
2: 406326
3: 614362
4: 832503
5: 1055980
6: 1276115
7: 1498393
8: 1718883
9: 1939458
10: 2159426
11: 2383254
12: 2606731
13: 2831223
14: 3055475
15: 3278818
16: 3502605
17: 3727047
18: 3951934
19: 4175221
20: 4397783
...

After a minute my browser, Safari, got tired of waiting. It would cancel the request and send it again. I suppose if it was patient or another browser was used it would successfully upload the file after a few minutes. But what gives? I was uploading the file from my laptop, to my laptop. Why the heck was it copying the bytes so slowly. I figured it must be the algorithm for finding the ending boundary of the file contents. After all it was reading one byte at a time and performing comparisons for each byte. Considering that there were 54818697 bytes in the file, that’s a lot of work. So I pulled out my microscope and tweezers to fine tune and optimize the algorithm. After about an hour I felt confident that I had significantly improved the performance so I tried to upload the file again. … I was disappointed to see that there was no significant difference. I tried again to optimize it…. no improvement. I tried again. In fact I work all evening, slept on it, and continued the next morning. Nothing I did seemed to improve the speed of the upload.

Boy was I huffed. What was I doing wrong? I knew that the upload shouldn’t take nearly as long yet nothing I did improved the speed. I went out on the balcony to enjoy the landscape of southern France. The scenery there is soothing. Gentle mountains meet the sky to create an intricate horizon where you can see in the distance tiny man-made structures silhouetted atop hills and cliffs.

Then, like the sun shining in the night sky, the solution hit me. There was nothing wrong with my algorithm except that it was reading one byte at a time. Of course! It was the hardware. Each call to read() goes to the hardware and it’s the hardware that so damn slow! After decorating the InputStream with a BufferedInputStream it worked like a well oiled machine. The upload speed was almost 20 times faster. See the timed results below.


1: 3695256
2: 7848677
3: 11930853
4: 16097509
5: 20253106
6: 24413788
7: 28577127
8: 32724919
9: 36883849
10: 41037989
11: 45198658
12: 49365492
13: 53519640
done copying: 54818697

What are you doing in France? -DaveHoover

Staying with my in-laws. - MicahMartin

I think profiler could help you to save much time :) Instead of trying to guess what was wrong with the algorithm you could just see it.

I wrote a routine to the same requirement. I read bytes into a largish buffer until buffer full or end of stream or until newline. It’s essentially readlin() so when I hit a boundary string, the buffer exactly equals the boundary. I’ve never checked to see how often newlines happen to occur in normal binary files, but I suspect I’m never really filling the buffer.

Jim Standley http://www.SurfScranton.com/Architecture

Delegates Vs Command Pattern

by: micah | September 7th, 2006 | 0 comments »

Delegates: one of the few unique aspects of .NET. How useful are they?

Here’s a delegate declaration.

private delegate double Operation(double a, double b);

That syntax can take some getting used to. In order to use the Operation delegate we’ll need some methods that match the double (double, double) form.

public static double Add(double a, double b)
{
    return a + b;
}
public static double Subtract(double a, double b)
{
    return a - b;
}
public static double Multiply(double a, double b)
{
    return a * b;
}
public static double Divide(double a, double b)
{
    return a / b;
}

There’s nothing special about that. Now to create an instance of the Operation delegate.

Operation math = new Operation(Add)

Again the syntax can throw you off a bit. This line instantiates an instance of Operation with the Add method and stores it in a variable named math. To use math you invoke it as though you were calling a method.

double result = math(1, 2);
Console.WriteLine("result: {0}", result);
>> 3

Invoking math, with parameters 1 and 2, actually called Add with the same parameters, hence the result of 3. The oposite behavior can be achieved by using the Subtract method instead of Add.

Operation math = new Operation(Subtract);
double result = math(1, 2);
Console.WriteLine("result: {0}", result);
>> -1

math just delegated the call with parameters 1 and 2 to Subtract and so the result was -1. So far this isn’t very useful. We can wrap methods up in delegates and call methods through the delegate but that’s just a lot of extra work. The power of Delegates comes into play when you don’t know which method to use. Assume this code was used in a bank system. A frequent action of a bank system is to adjust the balance of an account.


private double balance = 0;
public void AdjustBalanceBy(double adjustment, Operation operation)
{
    double newBalance = operation(balance, adjustment);
    LogAdjustment(balance, newBalance);
    balance = newBalance;
}

Notice that AdjustBalanceBy takes an Operation Which means it could be Add, Subtract, Multiply, or Divide to adjust the balance. There might be operations we haven’t considered yet like applying interest. AdjustBalanceBy could take care of that for us as long as we give it a delegate that calls ApplyInterest(double, double). The code in AdjustBalanceBy would never have to change and that’s exactly how the Open/Closed Principle says it should be. How would this be done without delegates? The Command Pattern would work great!

public interface Operation
{
    double Run(double a, double b);
}
public class Add : Operation
{
    public double Run(double a, double b)
    {
        return a + b;
    }
}
public class Subtract: Operation
{
    public double Run(double a, double b)
    {
        return a - b;
    }
}
...
public void AdjustBalanceBy(double adjustment, Operation operation)
{
    double newBalance = operation.Run(balance, adjustment);
    LogAdjustment(balance, newBalance);
    balance = newBalance;
}

There’s a bit more code without delegates but we’re saved from the wacky syntax. Considering the extra language complexity of delegates, I feel the Command pattern has the upper hand here. Point for Command Pattern. !meta Delegates 0 - Command Pattern 1

What about multicasting?

Delegates have this feature called multicasting that allows you to add multiple delegates together. Here’s an example.

Operator math = new Operator(Add);
math += new Operator(Subtract);
math += new Operator(Multiply);
math += new Operator(Divide);
math(1, 2);

When math is called at the bottom, all four operations are performed. In this case it’s not particularly useful but for something like a button, where, when clicked, multiple actions need to take place, multicasting is very convenient. But what happens to all the return values? Each of the methods combined in the math delegate above returns a value but math can only return one value.

Operation math = new Operation(add);
double result = math(1, 2);
Console.WriteLine("result 1: {0}", result);
math += new Operation(subtract);
result = math(1, 2);
Console.WriteLine("result 2: {0}", result);
math += new Operation(multiply);
result = math(1, 2);
Console.WriteLine("result 3: {0}", result);
math += new Operation(divide);
result = math(1, 2);
Console.WriteLine("result 4: {0}", result);
OUTPUT
>>result 1: 3
>>result 2: -1
>>result 3: 2
>>result 4: 0.5

Interesting. Multicasted delegates only return one value from the combined execution. This suggests that multicasting should only be used when you don’t really care what the return values are. The Command Pattern alone can’t compete with multicasting but along with his good buddy Composite, they’ve got things under control.


public class Composite : Operation
{
    IList operations = new ArrayList();
    public double Run(double a, double b)
    {
        double result = 0;
        foreach(Operation o in operations)
            result = o.Run(a, b);
        return result;
    }
    public void AddOperation(Operation o)
    {
        operations.Add(o);
    }
}

This version of Composite mimics the delegate’s handling of the return values but it could easily average them, store them in a list, or do whatever else your funny bone fancies. Composite gives much more control over combined execution and so I say it earns another point for Command Pattern. !meta Delegates 0 - Command Pattern 2

Events

Oh gosh. Get a load of this syntax.

button.Click += new System.EventHandler(SomeAction);

An intuitive interpretation: button.Click - Telling the button that it was clicked button.Click += - Adding something to the clicking of the button… Huh? new System.EventHandler(SomeAction) - SomeAction must be a method the fits the EventHandler method form. An instance of EventHandler is created with SomeAction. After those logical steps a developer concludes that Click must be a public field (or property) of Button of EventHandler which is a delegate. And the developer would be wrong! Click is actually an Event. The declaration looks something like this:

public event System.EventHandler Click;

The whole Event construct is rather silly because, as far as I can tell, it could just as easily be replaced with a public field (or property). 1 point deduction from delegates for flagrant misuse of syntax.

Final Score
Delegates: -1
Command Pattern: 2

—- !commentForm “There’s a bit more code without delegates but we’re saved from the wacky syntax. Considering the extra language complexity of delegates, I feel the Command pattern has the upper hand here” What is complex about the keyword delegate followed by the required signature of your choosing? In what way is this “wacky”? Clutching at straws is the phrase that springs to mind. * The declaration of delegates is not terribly complex. It’s the use of delegates that’s complex. Operation operation - It looks like a regular object but you can’t use it like a regular object. operation(…) ”Why is operation being invoked as though it were a method? Why can’t all objects be invoked like methods?” When you come across delegates in code there’s moment of confusion where you have to figure out that the variable that you thought was an object is really a delegate. - MicahMartin ”Delegates make functions first class objects, this is actually what the command pattern is trying to emulate, how can you possibly object to that? In version 2.0, anonymous delegates extend this to make lambda’s possible, this is fantastic, and far better than the command pattern.” “How would this be done without delegates? The Command Pattern would work great!” Yes it would and as much as we would like everyone to be aware of and study design patterns not everyone will. Therefore when they study dotnet and come across this concept supported in their language they will be able to use and benefit from it without even being aware of the command pattern. If and when they move on to design patterns they will be in the comforting position of knowing two approaches to a particular problem and can weigh up for themselves the pros and cons of each method. * Good point. Having delegate-like functionality built into the language is very powerful. In fact Ruby, my favorite language, would not be half as wonderful without blocks. Languages like Ruby and Smalltalk have very elegant implementations of blocks and closures. Delegates are not elegant. - MicahMartin “The Command Pattern alone can’t compete with multicasting but along with his good buddy Composite, they’ve got things under control.” And so we keep on adding patterns just to get the same level of functionality that multi-cast delegates offer? Aren’t you people the same ones that tell us not to add patterns for the sake of it? Refactoring to Patterns by Josh Kerievsky, anyone? How often will you need the return values from multi-cast delegates? Depends, is the answer. Therefore if you don’t, multicasting is fine and less work. * Agreed. When programming in .NET there’s no point in fighting it; you have to use delegates. When you don’t need the return value, multicasting is easier. - MicahMartin ”delegates make multicast commands first class, that’s better than a command composite.” “The whole Event construct is rather silly because, as far as I can tell, it could just as easily be replaced with a public field (or property).” Not sure what you are getting at here but then I’m not sure what you are getting at in the whole article. Your remark “as far as I can tell” implies to me that you haven’t actually spent that much effort getting to know dotnet. It seems to me an exercise in Microsoft bashing yet again. I’m guessing you’re a Sun worshipper (of the Java kind). Perhaps you should applaud MS for its efforts in helping “mortal” developers get good code written quickly instead of finding any excuse to criticize. * Do an experiment. Next time you’re about to declare an event, declare a public instance of a delegate instead: public Operation myEvent = new Operation(Add);. It’ll work just like an event. One benefit of this alternative to events is that you won’t have to worry about the annoying null pointers that Thomas describes below. - MicahMartin ”Incorrect, event is an access modifier, all events are delegates, event simply means that only += and -= can be used, with a public delegate, one could replace the entire delegate via assignment, killing all previous subscribers. The event keyword enforces the observer pattern. Public delegates allow aButton.Click = new EventHandler(MyAction), Public event delegates allow aButton.Click += new EventHandler(MyAction) and =- new EventHandler(MyAction), but not =, this is vital.” Steve Bate —- “Button.Click += …” The most silly thing about this syntax is that the Click spontaniously changes from null to something on the first +=, and suddenly becomes null when you apply -= a certain amount of times. So after an operation when you expect to remove something from a collection, the collection itself becomes null. That’s why you usually see a test for null just before an event is invoked. Why they invented this and why they think this is smart, is beyond me. Worse is that it seems it’s not fixed in Whidbey. Thomas Eyde * I agree wholeheartedly. When I teach C# classes, students trip over this quirkiness like clockwork. - MicahMartin ”There’s nothing weird about that, it’s quite natural… Click += new Action, allows Click to act as both AddListener and RemoveListener, and makes perfect sense, since Click is a list of actions. It’s a nice use of operator overloading to simplify the common action of adding and removing event listeners.” —- Yes, it is a shame. The thing that I think is worst about the event/delegate mechanism is that it doesn’t evolve well. Imagine having an event called TransactionAdded. It’s an event so anyone can attach a delegate to it to find out when a transaction was added. Okay, now what should we do if we need another event called TransactionUpdated? Easy. We add it. But, is that the best thing? Now we have two events that people have to register for when they want to know about transaction operations. If we’d used a interface, a listener with two methods (added, updated) we could’ve just registered an object. ”A delegate is essentially a one method interface, and covers by far the vast majority of UI cases of listening to events, and nothigng prevents you from doing as you suggest, so what’s the complaint? Interfaces force you to declare objects to implement them, delegates are move flexible and allow you to pass any function that matches the correct signature, this allows polymorphism without forcing you to implement an interface, a great advantage when you don’t have access to the original source. Delegates are an extra tool that give you more flexibility than interfaces.” The sad thing about the event/delegate mechanism is that it lulls you in with the event for that first method, especially with the multicast feature. After you have that first event, many people will add a second and third event rather than refactor to an interface and a list of objects. In fact, I’m working with another team that’s done this just today. - MichaelFeathers ”Everything has potential for abuse, that doesn’t mean we shouldn’t want those extra tools. Delegates give you something interfaces can’t, polymorphism at the method level, rather than the object level, why wouldn’t you want that?” —- Why not use both? I use the Command Pattern and Delegates/Events. The fact is that the .NET Framework has the Button.Click += new EventHandler() syntax built in and that is how events are handled. So in my event handlers I execute Command objects and add them to a Command Stack (when necessary). This allows me to take advantage of the nice code completion in Visual Studio, while still using the nifty GoF Pattern.


...
private CommandStack _commandStack = new CommandStack();
someButton.Click += new EventHandler(myEventHandler);
protected void myEventHandler(object sender, EventArgs args)
{
     _commandStack.Execute(new SmurfCommand("Kill Gargamel!"));
}
...

Regardless, I think the intention of delegates was not to piss off GoF loyalists, but rather to introduce a better way of doing function pointers. Likewise the intention of events was to offer a different approach to anonymous methods & classes (though in C# 2 anonymous methods/classes are brought in). After all C# is named C# because the language is like C++, only sharper (or duller if you ask a POJO). ;) - Ben Monro !* Tue, 20 Sep 2005 09:10:10, Dave, Instance Methods A comparison of delegates and the command pattern using only static methods is only half the story. Using instance methods for delegates is quite simple, but emulating the functionality in the command pattern, while also simple, adds still more clutter to create and manage the additional object reference in each command class, and even if you favour the command pattern to save you learning a new syntax the extra “boilerplate” clutter it involves shifts the clarity of the construct over to the delegate. At least in my opinion. Another wrinkle is that the instance delegate implicitly has access to private members of its class, while the command pattern can only access public members of the referenced class, forcing you to expose a method to do the actual delegate work. Your subtract operation becomes:


public class Subtract: Operation
{
        private ContextObject _c;
        Subtract (ContextObject c)
        {
             _c=c;
        }
    public double Run(double a, double b)
    {
        return _c.Run(a,b);
    }
}

That seems a lot of extra boilerplate per class when delegates get it for free via: math = new Operation(c.Subtract); Worse, in this case I’ll already have c.Subtract written with the correct signature for the command class to call…this reduces the ‘command’ class to little more than an adapter that doesn’t really need to adapt anything. The entire class becomes redundant! —- Tue, 20 Sep 2005 17:16:32, Michel, C++ Equivalents “Delegates: one of the few unique aspects of .NET. How useful are they?” There are equivalents/alternatives to delegates in C++ so I would argue they are unique to .NET. Look att boost.function/boost.signal in conjunction with boost.bind gives a quite elegant and good alternative to the command pattern and it avoids additional single method intermethods and virtual calls. Look at www.boost.org for more info. At least boost.function and boost.bind is going in to the TR1 C++ specification. /Michel —- Thu, 22 Sep 2005 06:11:58, Bart De Boeck, Delegates versus inner classes What do you think about the arugments in - http://java.sun.com/docs/white/delegates.html - http://msdn.microsoft.com/vjsharp/productinfo/visualj/visualj6/technical/articles/general/truth/default.aspx Bart http://www.xenopz.com/blog/bartdeboeck/ —- Mon, 26 Sep 2005 08:58:12, Chaz Haws, Delegate complexity I’ll grant you I’d have liked an easier to explain model for “event”. It does make a weird kind of sense once you know what it’s doing, but… feh. But the delegate itself really is pretty straightforward. In most cases it gets me everything I wanted from the Command pattern, and I find the shorter syntax to be more elegant. One other point: With pre-existing code of the right interface, Command would need a new class for each method, but delegates would need nothing at all. As for whether they are unique to .NET, well, actually no. The “closure” in Borland’s C++ Builder is the same thing. That was of course a feature in Delphi. So Anders is fond of his delegates. Me too! In the pre-Boost dark ages of C++ I tried to implement something like delegates. It was functional, but never as clean as the modern delegate syntax. I have a healthy respect for the complexity being hidden in there. (I’m even more impressed with Boost doing it without language support, but I’m not doing much C++ lately so I haven’t used it.) Of course, in C++ we overloaded operator() to help support this and could make any object look like a function call. So that part didn’t surprise me at all about delegates. —- Fri, 20 Jan 2006 04:29:03, Norman Sasono, How about Delegates + Events VS Observer Pattern? Who scores? —- Mon, 23 Jan 2006 11:25:08, Ravi Venkataraman, Much simpler in some other languages These patterns are much simpler in other languages that support first class functions, like Python. For example, you would write: (Syntax may not be exact)


def add(a,b): return a+b
def subtract(a,b): return a-b
def multiply(a,b): return a*b
def divide(a,b): return a/b
def run(f,a,b): return f(a,b)

The run function could be called thus:


run(add, 1, 2)
run(subtract, 1, 2)
run(multiply, 1, 2)
run(divide, 1, 2)

This, I believe, is much more expressive and intuitive. I believe Ruby lets you do this too. And of course, so does Lisp. Notice the difference in syntax between the C# delegate and the simplicity of Python. —- Mon, 23 Jan 2006 13:07:41, , Nowhere in the .NET literature are delegates ever described to be a replacement for the Command pattern. They are always used for the observer pattern or for “glue code” between components or where you would otherwise have to define an interface with one method (like Runnable in Java). —- Mon, 23 Jan 2006 14:51:25, , C# is not that different from Python In C# the code looks very close to Python. The biggest difference is the explicit types.


int Add(int x, int y) { return x + y; };
int Sub(int x, int y) { return x + y; };
...
run(Add, 1, 2);
run(Sub, 1, 2);
...

You can use anonymous functions, like Python’s lambda operator:

run(delegate(int x, int y){return x*y;}, 1, 2);

And, better than Python, anonymous functions are not limited to expressions.

// Multiply slowly!
run(delegate(int x, int y) {
    int result = 0;
    while(x-- > 0) result += y;
    return result;
}, 1, 2);

Mon, 23 Jan 2006 15:10:52, Ravi Venkataraman, Yes, there are some similarities between Python and C#. What has been omitted in the C# example are a few lines that do appear in the original article. The place where you declare a special type called a delegate, where you instantiate the delegate with the selected function, etc.

Also, I’m not sure that the run(Add, 1,2) style is permissible in C#.

Anyway, this topic is about the benefits of delegates vs standard patterns. I gave the example of Python to show that one need not be restricted to these two choices only, there are options in many other languages that are simpler and more expressive.

Mon, 23 Jan 2006 15:22:17, Ravi Venkataraman, In Python, too, lambda operators are not limited to expressions, I think.

Mon, 23 Jan 2006 16:54:21, , 1) Yes, the run(Add, 1, 2) is permissible in C# 2. 2) No, Python lambda expressions are limited to expressions only – no statements allowed. 3) C# 2 provides a number of useful, generic delegates in the System namespace that somewhat reduces the need for defining new delegate types, but yes I assumed that the delegate type had been declared as above.

Mon, 23 Jan 2006 16:56:30, , And while I’m about it…

4) C# 2 has real closures over mutable variables (unlike Java) and scoping rules that don’t get confused between global variables and variables in intermediate scopes (unlike Python). The only drawback to delegates in C# 2 is the delegate keyword itself; if only they had chosen “do” instead.

Mon, 23 Jan 2006 19:43:53, Ravi Venkataraman, Python lambda expressions can involve other functions. Hence they are quite powerful in their own way. They are definitely substitutes for blocks of code. You wouldn’t need to write blocks of code because functions are so easy to define and use in Python.

Mon, 23 Jan 2006 23:17:24, Ravi Venkataraman, In the previous post, I wrote, “They are definitely substitutes for blocks of code. ” I actually meant, “They are definitely not substitutes for blocks of code. ”

Tue, 24 Jan 2006 08:38:38, , Functions are easy to define in any language. The question is not are they easy to define, but can you define them where they are most useful?

How convenient would the built-in control-flow statements (if, while, for, try/catch) be if you could only pass lambda expressions or functions to them, instead of defining their bodies inline? *!

#################

Authors

Categories

Archives

by: paul | September 28th, 2006 | 3 comments »

by: paul | September 26th, 2006 | 0 comments »

by: paul | September 11th, 2006 | 1 comments »

by: paul | September 7th, 2006 | 4 comments »

by: paul | September 7th, 2006 | 9 comments »

by: paul | September 7th, 2006 | 0 comments »

by: paul | September 7th, 2006 | 2 comments »

by: micah | September 7th, 2006 | 0 comments »

by: micah | September 7th, 2006 | 0 comments »

by: micah | September 7th, 2006 | 0 comments »

by: micah | September 7th, 2006 | 0 comments »

by: micah | September 7th, 2006 | 1 comments »

by: micah | September 7th, 2006 | 0 comments »

What is Software Apprenticeship?

How did I hear about Software Apprenticeship?

Where am I in my journey?

by: micah | September 7th, 2006 | 0 comments »

by: micah | September 7th, 2006 | 0 comments »

Building software is like building _____?

Building software is like building a city. Start small and go from there.

by: micah | September 7th, 2006 | 0 comments »

by: micah | September 7th, 2006 | 0 comments »

What about multicasting?

Events

Final Score Delegates: -1 Command Pattern: 2

Final Score
Delegates: -1
Command Pattern: 2