AvocadoSoftware.com

I'm considering a blog change (domain name and blogging system). Any suggestions for blogging system? Here's my basic requirements:

• Use Windows Live Writer
• Insert pictures directly into post
• Paste CSS formatted code examples directly into post
• Use Feedburner to supply the RSS in the meta tags of the site / posts
• Post files for people to download

Not a terribly large list of requirements... this ancient version of CommunityServer that I'm using supports the first one, and the last one - and that's it. I don't want to move to Community Server 2007/8 at this point, because it's far too "functional" (re: feature bloated) for what I really do with my blogging.

I've heard dasBlog and SubText are good. SubText is a fork of the original .Text (which became Community Server) so I'm at least familiar with it's original architecture.

Other suggestions?

I'm in the middle of rebuilding the architecture used for my build processes, and I'm defining separate configuration files for each environment: Local (developers box), Dev (development server), Test, UAT, Production. These config files are all stored in the Trunk\Deploy\Configuration folder in my subversion repository.

One of the issues that we've seen in our projects, is that a developer is having to check out the entire Trunk of the repository so they can build - because certain files, like the config files, are stored in folders outside of Trunk\Code\.

Low-and-behold; Subversion Externals. :)

I go into my Trunk\Code\Project folder, right click add a subversion property named "svn:externals" with a value of "Configuration ../../Deploy/Configuration". I update my local copy of the Trunk\Code folder and magically, a Configuration folder appears with all of the correct config files for the correct environment. When I go to the Windows properties of this folder and look at the Tortoise tab, this folder is pointing back to the correct Trunk\Deploy\Configuration folder!

My developers will no longer be required to check out anything but the code folder, to their local box; and they will be able to maintain and modify any of the config files that they need to work with.

sweet.

I'm tired of the old "dredge" moniker... tired of nobody knowing who I am and tired of some of the associations that this name has. So, I'm going to be posting as myself, from now on: derick.bailey

Another interesting side effect of my conversations with Scott Bellware, today... I'm not sure if he agrees with these conclusions, but I certainly didn't come to them by my own thoughts alone.

My understanding of the Test Lab or QA department in a software development shop has been based on the idea that the QA team members are not developers - and that they shouldn't be, because a developer will write tests that they know will pass. Well, as it turns out - the reason was correct, but the conclusion was wrong.

In reality, a software development project needs to automate every level of testing - all the way out to the point where the actual customer is sitting down and using the software. This includes: Unit Testing, Integration Testing, and UI Testing. Whether or not you distinguish between these three levels is irrelevant; the testing of the system must be automated as much as possible. This leads us to the next question: What is an automated test? Typically speaking, it's code. Who writes code? Software developers. Do you see where this is heading? maybe? :)

If software is developed by software developers (duh), why is the software that tests the software not written by software developers?

Lets take this to the agile world of 2 week iterations (or sprints or whatever you want to call them). If the software requirements are being defined every two weeks, then the tests are being defined every two weeks as well. If we are automating the tests during these two week cycles, and the tests are written as code, then why are the software developers not writing the tests? The obvious answer is my reason above - the developer will write the test that they know will pass, because they wrote the code that is being tested. So don't let that happen - don't let the developer who is writing the code, write the integration / UI test code. Then, how do we let a developer write the integration / UI test code? Triples Programming.

The standard XP / Agile practice currently has developers working in pairs - one driving the keyboard / mouse, and one thinking two steps ahead. I say we add a third role and a third person to the mix - one developer to write the integration / UI tests at the same time that the unit tests / production code are being written. What you CANNOT do, though, is include that third role in only two people. The moment you break down to two people, you need to remove the integration / UI test writing or you end up with the original dilemma. You also need to ensure that the developers in the triple, are swapping positions on a regular basis - make sure everyone gets a change to drive the keyboard, think ahead, and code the integration tests.

By programming in triples, you get the advantage of specifying the integration tests as soon as the code is functional. You don't lose motivation to write those test, you don't lose clarity of what the functionality is supposed to be, and you don't have to re-discover the same functionality and clarity at a later time with a new set of minds (the QA team).

So, what happens to the QA team? They are still needed, certainly. But now they can focus on their subject matter expertise - the human interaction of manual and random of software testing by using the actual application. i.e. the parts of testing that can't (or shouldn't) be automated.

...

Ok, ok, ok... if you really want to stick with pair programming you can take this concept and assign 2 teams per story; 1 team to unit test / write production code; and 1 team to integration / UI test.

I finally jumped onto the bandwagon, after some friendly advice from Scott Bellware. Please update your RSS feed reader to point to my new RSS feed location:

http://feeds.feedburner.com/DerickBailey

I've spent a lot of time, over the last year or so, working in Model-View-Presenter code. During this time, I've had a lot of questions; come up with a lot of different answers to the same questions; implemented a lot of different infrastructures for MVP including auto-magic view instantiation, manual view and presenter instantiation; and changed my mind about how best to implement certain portions of MVP a thousand times. Through all of this, I've come to some fairly good conclusions and a set of best practices that are helping my team(s) build better software, faster.

My current project list includes several developers that have not worked with me, or with MVP. As such, I'm seeing these developers go through the very same questions, pain, trials and tribulations that I've gone through in the last year. Hopefully, I'm able to prevent much of this pain for them - when I see a person questioning or implementing in ways that I don't think are correct, I do what I can to provide additional guidance, information on my experience with what they are doing and general direction for moving forward.

With this in mind, I can assume that there are a lot of developers out there asking the same questions and traveling down the same paths. My hope is that I can provide some answers and clarifications to help make the journey easier, not only for those that I work with, but also for those learning this on their own.

Assumptions

I'm assuming that you are familiar with several key concepts that MVP deals with, including:

• Inversion of Control / Dependency Injection
• Separation of Concerns
• Single Responsibility Principle
• Unit Testing

I'm assuming that you have some knowledge of and experience writing MVP code, and that you are searching for answers to questions in how you should implement what, where.

I'm assuming that you are doing an MVP setup because you want testability in your code, aside from the other benefits that this separation of concerns gives you. Many of my comments and best practices assume that you are unit testing.

And lastly, I'm implementing MVP with these best practices in C# and Visual Studio 2005 - my current language and environment of choice. These concepts, though, are (mostly) language and environment agnostic. You should be able to apply them to any .NET language, Java, maybe even Ruby / RoR (though it's likely that these concepts are built into RoR); and these concepts are not limited to web development. I am currently coding client-server windows applications, pocket pc applications and web applications, using MVP very successfully.

1) The Presenter is the Active Controller; The View is a Passive Doer

Rule #1 - The view is a passive, ignorant doer. It has no knowledge of when to do anything. It has no control over anything. It does what it's told, when it's told to do so, by the presenter. The only thing the view knows, is *how* to do what the presenter tells it to do. This probably the most important concept  to get right, when implementing an MVP setup - all other concepts, implementations and techniques that can be used, are mere side-effects and implementation details of this concept.

And yes, you can guess the MVP camp that I live in, based on this statement. :)

(Note: Don't confuse the term "active controller" with MVC, or the "supervising controller" MVP pattern. I'm using this term very loosely here, to help you see that the presenter knows what to do and when to do it; the view only knows how to do what it's told to do.)

2) Presenter: Speak to the IView Interface

Never allow your presenter to speak directly to an implementation of a View, or to know anything about any specific implementation of a View. Breaking this rule will cause your code to be un-testable by introducing references and resource requirements that are outside the scope of Unit Testing.

In fact, I will go so far as to say that the actual view implementation is completely, totally useless and irrelevant to the process that you are coding. If you find yourself in a situation where you can't code the process without having an implementation of the view, then you need to step back and re-define the boundaries between your view and presenter - see rule #1, and refactor.

But, if the view implementation is completely useless, how do know that the process being coded will work? How do we ensure that the presenter talks to the view at the right times? The answer is: mock / stub objects in your unit tests. RhinoMocks is your friend. If you don't like RhinoMocks or any other mocking container, write manual stub objects. Just remember rule #1 when you code the mocks / stubs. If you break rule number one when you implement your mock / stub, then you need to re-think / refactor.

Additionally, don't let your view's interface define anything more than how the presenter speaks to the view. This brings us to the next point:

3) View: Don't Speak Through the IView Interface*, Speak to the Presenter

If you find yourself adding methods and properties to the view interface, and these methods and properties are never called by the presenter, then you are likely trying to define methods that the view uses to speak to the presenter. Typically, in the situation, you find yourself creating method signatures on the view interface, and then in the view implementation, the implementation for that method is empty - you're not actually using it for anything because the presenter is never calling it; or, you find that the implementation of the method does nothing more than make a call to the presenter. In either of these situations, you are likely trying to define how the view speaks to the interface, in the wrong location.

What you should be doing, is creating public methods and/or properties on the Presenter so that the view implementation can call these methods and let the presenter know that something just happened.

* The major exception to this rule is when you have made the design decision for the view to communicate with the presenter via events raised by the view. In this case, your view interface defines the event, the view implementation raises the event, and the presenter listens to the event through the view interface definition.

4) View to Presenter: What Should be Communicated, and How?

Riding on the tails of item #3 is an inferred rule: what the view communicates to the presenter, and how.

The "what" is significantly more important than the "how". There are dozens, if not hundreds or thousands of ways to implement the "how" - everything from events defined in the view interface, to public methods on the presenter, to abstractions and auto-magic wiring of messages and method calls. The "how" largely depends on the MVP (or MVC) framework that you are using. I am going to assume that you are not using an existing MVP framework and that you are coding up the view and presenter by hand, allowing them to shake hands and talk, as needed.

So what should the view communicate to the presenter? Event information. Let's take a screen with a button on it, for example. When a user clicks that button, the button raises an event that is handled by the view's implementation. Once the view's implementation is handling this event, what do we do? If you look back at rule #1, the answer should be obvious - the view shouldn't do anything other than communicate this event to the presenter, so that the presenter can decide what to do. If the presenter needs the view to do something at this point, the presenter will tell the view what to do, and when.

Let's extend this to a slightly more complicated situation - let's say there is a text box on the screen, and a user of the system is allowed to change the text in that text box. What should the view do when a user changes the text in this box? The answer hasn't changed - the view should communicate this event to the presenter. The only difference is that the view is now communicating the event occurrence with the data associated with the event - i.e. the view tells the presenter that the text was changed, and here is the new text.

5) Presenter: Don't Trust the View - It's Implementation is Unknown

What is the view, in our Model-View-Presenter code? It's an interface - a definition of the methods, properties, etc. that need to be implemented so that the presenter can properly communicate with the view implementation. Step back for a minute, and think about how you code the presenter - you code against an interface definition, not against an actual implementation. If you are coding a presenter, and your presenter only knows about the view interface - then how do you know what the actual view implementation is going to do? You don't know, plain and simple.

Unfortunately, in most software development projects, a developer is given an entire M-V-P stack to code. The developer creating the presenter is likely to be the developer that is implementing the actual UI for the real view. This situation lends itself to bad coding practices - it's easy for the developer to make assumptions about how the view will behave, when coding the presenter; and letting the view make assumptions about how the presenter behaves, when coding the view implementation. Be honest with yourself - when was the last time you made an assumption about one class, while coding against it in another class? I'm guessing it was 30 minutes ago, or less. If not, then I commend you on your discipline - seriously, it's hard not to do that.

But, why are these assumptions dangerous? Why shouldn't we "know" that the view will handle data this way, at this time, when we code the presenter; or "know" that the presenter will call these view methods at this time? Let's look at this from the "allow assumptions" methodology, first.

Code a presenter that works perfectly and processes all of the data in the correct sequence; but put all of the data storage in the view's interface. Don't let the presenter hold onto any data - only let the presenter read data from the model and read data from the view, when the presenter needs data. If the presenter needs to hold onto data, push it out to the view and read it back in from the view when it's needed. What's the end-result of this situation? Assuming you are the person implementing both the presenter and the view, you are probably safe and things probably work great.

Now - what happens when Joe Frankfurter, fresh out of college, gets assigned to your project and has to change the UI elements on your view? Chances are, Joe is going to forget to hold the data properly, accidentally overwrite the values and references, and generally cause the data stored by the view to be invalid and/or corrupted. How does your presenter work, now? It's either throwing exceptions left and right; or if you've coded perfect exception handling and null reference checking, it's at least popping up warning signs all over the place, saying that it can't find the data it needs and/or asking the user to re-enter information they have already entered. The worst part; Because of the complex requirements and extraneous properties and methods on the view, Joe spent 2 weeks working on that view and you are delivering the project tomorrow... guess who gets to work all night, to fix the bugs?

Now let's look at this from the "don't assume anything" way.

Code a presenter that works perfectly and processes all of the data in the correct sequence; and code the presenter so that it maintains private references to all of the data that is needed for these processes. Ensure that the presenter is in control of the real data that is being processed, 100% of the time. When the view tells the presenter that some new data is available, the presenter validates, verifies, and quadruple-checks the new data to ensure that it really is valid and to ensure that it will not cause issues with processing. If the presenter finds that the data is not valid, it tells the view to prompt the user with a message stating why the data is not valid.

Now let's have Tom Cheeseburger join the team, fresh out of college. Put Tom on the view implementation for this new presenter and let him make all the same junior mistakes that Joe was making. What's the end result, this time? When Tom drops the object reference, corrupts the data, and overrides data with invalid values, the presenter hums along nicely and the process still succeeds. At the very worst, when Tom has the view tell the presenter some bad data, the presenter says "I don't think so" and tells the view / user why that data is bad. The end result, though, is that the presenter - having complete control over the data that it needs to process - is very stable and the process is more likely to succeed, even when the view implementation is terrible. The worst part; because of the simplified view interface with only a few properties and method, Tom spent 2 days coding this view full of bugs and you only have a week and a half until you have to deliver it. Oh, wait - that doesn't sound so bad when compared to Joe's situation. A little guidance for Tom, few informal code reviews, and Tom's view implementation is good to go with plenty of time to spare.

Which of these two situations would you rather be in? Ask yourself how many time's you been in the Joe Frankfurter situation. I'm betting it's more than you can count or remember. Now, ask yourself how many times you've been in the Tom Cheeseburger situation? Chances are, if you are not coding with good MVP standards - not very often.

Real World Example

Before you blow off my examples (re: #5) as fictional, academic, or whatever - here's a true situation that illustrates the points I'm trying to make.

I was leading a project last fall with a set delivery date. One week before that delivery date, the customer arrives and wants a demo of the product. The demo goes as expected - a few minor things here and there.. and then disaster strikes. The customer asks "so... what about requirement XYZ from the User Requirements Document?". After a few small heart attacks, I go back to my developers - who literally were fresh out of college... this is their first job, this was their first major project - and asked them to start work on the requirement with the understanding that they would need to work extra hours, etc. to get it done. Guess how long it took? ... Less than 24 hours. Two developers, fresh out of college, implemented an entire vertical slice of an application - including the enterprise integration and messaging slice - in less than 24 hours. How's that for proof in the pudding?

Summary

Take a moment and look back at the five best practices that I've listed out, and notice how the first one is very short, very terse, and very high level... then look at number five again - it's very long, very verbose, and very low level (in comparison). I've organized these best practices in this manner with a specific goal - start with a high level goal and provide supporting concepts and guidance and each level below. If I when any deeper, at this point, I would be writing code instead of providing concepts and guidance (and the code to support these concepts deserves and entire post of it's own).

Hopefully I've helped answer some of your questions about MVP. If nothing else, I hope that I've at least provided some guidance that will help you to answer the questions for yourself.

One last important note: These "best practices" are entirely subjective, based on my research, experience, and actual usage of MVP in the last year. Everything in this post is subject to change without notice, when I find a better way to do things. ... In other words, just because I said so, doesn't mean it's right. :) Please keep that in mind as you move forward with your MVP usage.

Chad Myers over at LosTechies, posted some interesting questions about TDD. I don't consider myself to be a TDD master - actually, I've had the same questions that Chad has, over the last year - and I do have some opinions, now, and thought the world might want to know. :)

I'm repeating Chad's questions here, and numbering them so I can respond accordingly.

TDD Practice Questions

1. How much up-front design do you tolerate? How do you know when to stop (i.e. 'when algorithms start getting discussed, it's testing time')?
2. What about certain "I just know we'll need this" type stuff (i.e. putting a try/catch{Console.WriteLine(ex);} in your console main() method?)
3. When writing a test, in order to even get it to compile, you have to build an interface or two, a concrete class with some NotImplementedExceptions in it, etc. How far do you allow that to go?
4. If, during the middle of testing on a story, you realize that your up-front design wasn't correct, do you stop and discuss with your pair right then, do what you need to do and proceed, or do you pull back and go back to full pre-test design mode on that story?
5. When proceeding to a new story, you discover that a test you wrote for a previous story no longer reflects the requirements. Do you refactor that test immediately, mark it as ignored until you finish the current story and cycle back to the ignored one? Something else?
6. If the new story's requirements involve a slight tweaking to an existing test, do you tweak it, or make a new one and discard the old one (i.e. 'No changing existing tests!' or 'Only change if it's a minor compiler issue, but otherwise don't change it')?
7. If you're, say, building up your model and it passes tests, but you're seeing that it's infantile and that the next few upcoming stories will produce significant changes to produce a new emergent model, is it appropriate to step back and consider a larger refactoring, or do you keep plugging and make the changes into the existing model even if it could benefit from some housekeeping that is otherwise out of scope?

My Answers

1. Enough to know what I'm supposed to build.
   
   You really need to answer this question based on your individual project. I recently built an enterprise integration project that took our core maintenance system and brought some disconnected operations into it. On this project, I did not have a lot of up front design. I knew that the system needed to operate in a disconnected mode, I knew it needed to be operational even when there was no one logged into the computer or running the software, and I knew that it needed to do bi-directional communication with the master maintenance system, to perform a limited set of maintenance related tasks. I started with a few assumptions / up front design - build a Windows Service to run the core process, build a client-server architecture to host the UI, build on top of a messaging system to support the communication needs. Beyond this, the functional requirements of those tasks drove the design of the project during the construction of the software.
   
   Conversely, I've worked with a team that was building a system for a laboratory, recently. With the requirements from the customer, the process that they requested, and the required conversion of existing data that the customer had; we required a large up-front design, to determine if the data conversion and functional requirements were going to be met by our proposed solution. The major design of the system was known up front, but the implementation was still a work-in-progress during the construction of the software.
   
2. This is one of the questions that I still battle with, and I answer it differently every time I ask the question. I try not to add features and functionality unless I know that I need them right now - when it comes to the domain model and core infrastructure services of my application. However, with items like the Console.WriteLine(ex) question, I don't see any issue with adding those into the application's Main method. After all - you are not going to unit test the App's Main Method... you are going to integration test it.
   
3. In terms of implementing interfaces, I try not to manually code stub objects anymore. Instead, I try to use RhinoMocks whenever possible so that I can avoid that question. I used to code stub objects all the time, and would have dozens of Not Implemented methods - the end result is that my unit tests were horrendously difficult to maintain and I had dozens of duplicate stub objects to provide a certain method to a certain unit test. RhinoMocks helped me clean that up and keep my unit test code stub object requirements manageable size. There are times when you really do need a stub, and when you do need one, you build the methods you need and allow the Not Implemented methods when you really don't need that method for your tests.
   
   If you're asking about real objects that you are stubbing out the method signatures for, in your unit tests - you shouldn't allow NotImplemented methods to live in your code for very long... you should only be adding the methods that you need, for your software to perform it's required functionality. If you have a real object with a Not Implemented exception being thrown, you are probably looking at a method that can / should be deleted from the code base.
   
4. Once again, it comes down to your specific situation.
   
   I spent some time doing pair programming with a coworker, a while back. During this time, we continuously ran into situations where the next functional requirement caused a change in our existing designs. When this occurred, we would only make changes as we needed to. We would write a new unit test for some new functionality, and if the previous designs did not allow us to make the unit test pass, we would go back and modify our previous designs - making changes and updates to the unit tests in those changing areas, as we go. The great thing about unit tests in this situation is that you can consider them to be a "to do list" of sorts. During the times that we were changing our existing designs, we would often forget about an area or the new functional requirements that we were trying to satisfy. Fortunately, a complete run of the entire unit test suite would show the now broken tests and be a reminder to us on what we needed to change.
   
   During this pair programming time, there were a few occasions where we got to a new requirement and looked back at our design and implementation with the realization that the entire model was wrong and needed to be re-written from the ground up, with the knowledge of this specific requirement in mind. At those times, we did what a lot of people would never even consider - we deleted every class and every unit test in our system and started from scratch. The lessons learned along the way and the knowledge of other requirements lead us to a new design that accounted for the functionality that we would need - but we were still able to code the existing functionality on an as-needed basis. We provided extensibility through additional interfaces and abstractions, without creating "future-code"... stuff that "we know we'll need this in a bit, so let's do it now".
   
   I've gone through these "design, fix, redesign, fix, rebuild from scratch, fix" cycles numerous times. Every time it happens, it scares the heck out of me to delete existing code and start over. In my experience, though, the end result is worth the effort - fewer bugs in the system, a model that more accurately represents the business needs, and better extensibility and flexibility that allows for change in the future.
   
5. Fix it as early as possible. If you don't fix it now, you're likely to create more work for yourself because you'll have something new that interacts with that broken piece, and will have to fix the broken piece and the new piece. If you fix the broken piece now, you won't have to re-write the new piece later.
   
6. If you are changing the meaning of a test (i.e., you have to rename the test to accurately reflect what is being tested and why), then you are automatically destroying the old test and creating a new one - even if you are only destroying it semantically and you are really just renaming and changing a few details. If the meaning of the test remains the same, and you are only changing some of the implementation details (because you changed the design, via question #4 or whatever), then leave the test where it is and just change the implementation to meet the new implementation needs.
   
7. See my answer to question #4.

TDD Style Questions

1. Assert.That(x, Is.EqualTo(y)) or Assert.AreEqual(y,x)?
2. How many asserts/test? Any caveats?
3. How do you know what to put in the SetUp method?

My Answers

1. Syntax is a personal choice and almost irrelevant. If they are both technically correct, then choose the one that most correctly represents what you are trying to say. I prefer to code in english as much as possible (read the first 9 chapters in Steve McConnell's "Code Complete 2", if you haven't). However, I also prefer simple APIs. I don't like the Assert.That(x, Is.EqualTo(y)) syntax because it creates a complex API set that I have to know. RhinoMocks is a great example of what you are suggesting, here. I love RhinoMocks and will continue to use it... but I don't always like the strange API calls that I have to make.
   
2. If you have a single object and a single method call that is being tested, with a single output value; the answer is easy - you have one output value, so you need one assert. In the real world though, your have a system under test that interacts with two or more sub-objects and interfaces, each with multiple behaviors and / or values changes that get invoked when you make a single method call on your system under test. The real answer is that you need one assert for every behavior / value that you expect when that one method is called. If your method returns seven values and call two methods on a child object via an interface, you need nine asserts for that one test.
   
3. Anything that is used by EVERY test in your test fixture. If there is even one test in your test fixture that does not need the information provided by the Setup method, then you should not have that information in the Setup test - move it to a common method that can be called by each of the tests that does need the information.
   

TDD Mechanics Questions

1. Is a refactoring tool absolutely necessary?
2. If so, what is the bare minimum features that the tool would need to facilitate decent TDD?
3. Integrated IDE test runner or a background source-watching auto-runner?

My Answers

1. Absolutely, 100% NOT required. In fact, I would recommend that you exercise your mind now and then, and purposely work without a refactoring tool from time to time. Remind yourself what it really takes to refactor something - understand the true cost of refactoring by doing it manually. When you understand this cost, you'll see why you really do want a refactoring tool. Personally, I can't stand coding without Resharper. However, it doesn't support Visual Studio 2008, at the moment, so I'm stuck refactoring everything by hand when I code in VS2008. It really makes me appreciate Resharper that much more and I'm looking forward to the EAP / release of Resharper 4.
   
2. Resharper has a built in unit test runner, which is really nice. I use it whenever I'm in VS2005 and writing unit tests. However, TestDriven.Net also has some really nice integration into VS2005/2008 for unit test running. I use this in VS2008, since I can't use Resharper at the moment.
   
3. Both. See #2, and build yourself a Continous Integration Server (We use CruiseControl (the CC.NET flavor)) with automated unit test running. We schedule builds on our CCNet server to run every 15 minutes, and every time it builds, it runs all of our unit tests for us.

Hopefully this information will be useful to someone else out there, who may be asking the same questions. I'm glad to see Chad asking these questions, and I know that I've asked the same questions in the past. The learning curve on this stuff can be very steep and very painful. If we all pitch in and try to answer these questions when they pop up, hopefully we can reduce the learning curve and entry cost.