Oren's been creating a lot of discussion on the web recently with his thought provoking and, apparently, controversial blog posts.  One of his more recent posts hits on the topic of tools being a weak replacement for a solid understanding of what you're trying to do.  I had a bit of a discussion on this with JP when we were at DevTeach and I'm* both of us are firmly on side with Oren.  Anyone can teach another programmer a new tool, like nHibernate, but that person won't benefit from the knowledge unless they understand the reason the tool is needed and how it's solving that problem.  Although I think knowing the short comings of the tool is important too, I think it falls further down the list.

Today I saw some code that made me cringe.  The only reason that I saw the code is because we had a unit test (really it is an integration test masquerading as a unit test) that started failing.  I don't understand what the change was that started the failures and that is creating a lot of long term anxiety for me.  Once I narrowed the source of the failure down to a small block of code (remember, integration test....so this covers about 10 classes with no mocking) I started to see that people had neglected some of the fundamentals of object oriented programming.

The first thing that I noticed was that we had two classes that were part of a small inheritance chain.  They looked something like this.

 
    public class SummaryCustomer
    {
        private int _customerName;

        public int CustomerName
        {
            get { return _customerName; }
            set { _customerName = value; }
        }

        private Address _mailingAddress;

        public Address MailingAddress
        {
            get { return _mailingAddress; }
            set { _mailingAddress = value; }
        }

        private int _number;

        public int Number
        {
            get { return _number; }
            set { _number = value; }
        }
    }
 
    public class Customer : SummaryCustomer
    {
        private string _phoneNumber;

        public string PhoneNumber
        {
            get { return _phoneNumber; }
            set { _phoneNumber = value; }
        }

        private Address _mailingAddress;

        public Address MailingAddress
        {
            get { return _mailingAddress; }
            set { _mailingAddress = value; }
        }
    }

The first thing that hit me was that the person naming these functions must not have understood what they were doing.  I like to think of inheritance from the "X is a Y" standpoint.  In this case it means that the "Customer is a Customer Summary", which to me makes no sense.  Regardless, there are other problems here.  To me the most egregious is the overriding of the MailingAddress property on the SummaryCustomer class with the exact same implementation in the Customer class.  In my IDE (courtesy of ReSharper) I get a warning saying that I should be implement the Customer.MailingAddress instance with the 'new' keyword to override the underlying instance.  This is actually what was causing the test to fail.

The code in the test and the code being called from the test looked something like this.

    public class SampleTestFixture
    {
        public void SampleTest()
        {
            CustomerDal customerDal = new CustomerDal();
            Customer customer = customerDal.RetrieveCustomer();

            customerDal.DeleteCustomer(customer);

            //some assertions
        }
    }

    public class CustomerDal
    {
        public Customer RetrieveCustomer()
        {
            //some retrieval code
            return new Customer();
        }

        public void DeleteCustomer(SummaryCustomer customer)
        {
            //some deleting code
        }
    }

What happens is that the RetrieveCustomer method returns a Customer typed object.  When that object is passed into the DeleteCustomer method as a SummaryCustomer type, things with the MailingAddress method start to go awry.  Because of the existence of the same property on the two different types, which also have an inheritance chain, the value in the MailingAddress property immediately after the RetrieveCustomer method call is not available in the DeleteCustomer method.

The easy solution for this was to get rid of the MailingAddress property on the Customer class, but it got me thinking about the things that Oren was getting at in his blog.  Developers absolutely need to understand the basics before they start implementing the tools.  In this case I consider inheritance to be the tool.  It's obvious that the developer (most likely more than one) didn't understand the ramifications of overriding a property, even with ReSharper telling him/her about it.

I see too many devs who are trying to implement things like inheritance without understanding why you use it or how you use it.  My experience in the industry is showing that there is a high percentage of developers out there who don't understand the basics of inheritance, polymorphism and encapsulation.  Without understanding those three corner stones of OO, you'll only be making them frustrated by showing them things like Dependency Injection, Mocking, or Inversion of Control. 

I'm a firm believer in apprenticeship style training.  The one-on-one mentoring that plumbers, millwrights and electricians get is a far cry from the learn-on-your-own-through-trial-and-error mentality of our industry.  Even in the best case scenarios, junior developers are lucky if they get a few hours a week of mentoring from a competent senior level developer.  That kind of timing can't begin to bring a junior developer to the level where they can be introduced to more complicated tools.  The exception to this are the developers who invest significant amounts of their own time reading, listening and trying.  Then again, this type of person usually rises to the top regardless of industry.

*JP pointed out that I had inadvertantly put him in the tools over fundamentals group by using the term "I'm".  Our discussion in Montreal definitely had us both on the fundamentals side of the equation.

We were lucky enough, with the help of MSDN Canada and DevTeach (thanks Wendy and Jean-Rene), to have Roy Osherove of ISerializable.com in Edmonton to talk on Agile software development.  Roy was kind enough to give up some more time away from his new family back home in Israel and travel out to Edmonton and Winnipeg to present to our User Group.  The event was fantastic.  We had our largest crowd since our inaugural meeting and there was a great buzz in the room. 

Like all his talks, Roy finished off with a song.  For us we got his Agile project rendition of Que Sera Sera.  If you want to find out what his songs are like, head over here to his first release on the web.  I have now listened to it Roy and it does sound fantastic for the hardware you claimed to be using.

Thanks again to all that helped sponsor this and to Roy for his time and passion.

Roy Osherove just arrived in town for his Edmug presentation tomorrow (May 22nd).  We're going to be out tonight at Ric's Grill downtown (104th Street and 102nd Ave.) at 7:30 pm.  There will be a reservation under my name, but leave a comment here if you'll be joining us.

Okay, it was noted today by Wendy that although attending the BoF on Pair Programming, no notes were posted here.  I can't speak for everyone, but my thought is that the BoF session was one of the most informative.  I've never participated in a BoF session before (and only for about 10 minutes of this one), but I was found the format very engaging.  I'm not one who gets up and asks many questions in a presentation (okay, never), but I felt like I needed to jump in and participate in the discussion.  I'm definitely going to make a point of trying to implement some of these sessions at either our user group meetings or the code camp.

A couple of the things that I picked up from the discussions were the build bunny, red cards and distributed pair programming. 

I've always wanted to get a device to plug into our build server status and the ladies at Oxygen have a build bunny that identifies the current and trending status of the build.  Wendy also mentioned that the bunny has a web service that she's been known to tap into when she is working remotely and in need of her co-workers attention.  I'm sure my guys at work would find this out and abuse it to no end.

Red Cards for pair programming was an interesting concept that I'd never heard of before.  The idea is that both people in the pair have a red card and they can use it when they feel that things are personally or professionally inappropriate or uncomfortable.  All other people on the team must respect the use of the red card and work to make sure the situation is resolved.

The ideas that were raised about distributed pair programming were very informative.  I'm sure if I'll get into this situation, but knowing things like the fact that there are only so many days that you can be out of the office before the technique demands that you physically co-locate.

All good stuff to know as we're looking at pairing with our new team members at work.  Unfortunately management only sees this as a way to train newbies instead of a commitment to quality.

• Can you fetch that for me?  Eric Cote to Wendy (Hot Agilista)
• Large, succulient balls?  (Active Nick)
• I've got nuts in my throat. (Sean Solback)
• I have a question.  How is it that I won you heart? (Dave Woods to Beth Massi during her presentation)
• Couscous.  Twice as good and twice the fun. (Scott Bellware)
• I love your accent except when you talk. (anonymous)
• Eh!  Bryan Adams, eh!  Great Canadian eh! (your's truly when Roy started his regex song)

More can be found here courtesy of Oren.

DevTeach came to a close today.  For some it was probably earlier than for others.  For me, it is ending at 3am after an evening of amazing conversation, great laughs, good food and good drinks.  A fantastic way to end a spectacular conference.

We ended up at the Spaghetti Warehouse in Old Montreal tonight.  Eric Cote and I shared a couple of bottles of wine (by shared, I mean he had 2 or 3 glasses while I drank the rest).  The food was great although the service at Dave Woods table was less than amazing apparently.  Oh well, I got my booze so tough on them.

After a number of jibes and my coming clean with the Hot Agilistas (they do have names....Oksana and Wendy) about my posting of them we ended up walking back from Old Montreal to the Marriott's lounge for a few more drinks. 

The night ended with a couple of hours of listening to Jean-Luc David and Matthew play piano while Carl Franklin (and guest, Roy Osherove) played the guitar.  It was good and comfortable which made the event very enjoyable.

My advice is that you make the time and the money to get yourself to DevTeach in Vancouver during the late fall.  The people are fantastic, the content was amazing and the venue was stunning.  You won't get the intimate contact with speakers while you attend other big conferences.

Starting early cause he has too much to go through for the allotted time.

You don't need CAB to do large maintainable apps.

UI code is time intensive.  It deals with an extremely unpredictable external dependency (users) and it changes frequently.

It's worth your while to test the UI.

Screen Responsibilities

• Presentation
• Responding to User input
• input validation and business rules
• more that I missed....

Small controls can be tested right in nUnit.  No need for nUnitForms.

Maintainable Code Checklist

• Can I find the code?
• Can I "see" what the code is doing?
• Can I make changes with minimal risk of breaking other code?
• Can I quickly verify my changes?

The Humble Dialog Box

Miller is good with ReSharper.

Remove so much code from the view that it is verifiable by inspection only.  All other code (presenter) can be put under test.

Showing examples off all the flavours of MVP.

Miller mousing through ReSharper screens hurts my eyes.

MVP tips

• There's no ironclad rule of 1 screen == 1 presenter + 1 view
• Don't let the presenter become too complex
• Don't splash out of the tub
• Don't stay in the tub too long

Databinding makes test automation difficult.  Behaviour is implicit to the data binding configuration.

Notification Pattern:  An object that collects together information about errors and other information in the domain layer and communicates to the presentation.

Wow...he takes a shot at JP for running a nAnt script that never failed during his presentation.

Subcutaneous Testing:  Test the full application stack in an automated test.  Slice off the actual presentation view.  Use the test harness in place of the screen.

IoC with StructureMap.  Presentation chooser.

Had to leave early to see the Dave Woods Love In.

So I missed part 1 of this session and I walked into this one late,  so I'm feeling a little lost in the first demo of the slot.

Silverlight has it's own networking stack that works through the browsers networking stack.  You have access to everything the browser does.  i.e. headers, cookies etc.  Alpha version only supports same domain access.

Silverlight supports XmlReader and XmlWriter.  Nothing else is currently being offered in an attempt to keep the download size below 4mb.  Linq to Xml will be added in the future (post Alpha).

Wow.  The Fantasy Baseball demo app that Alan is showing has fantastic graphics!  This could be sexy if used and not abused.

Creates a class library using VB.  Imports:

• System.IO
• System.Net
• System.Windows.Browser <-- new for Silverlight
• System.Windows.Browser.Net <-- new for Silverlight

This makes it a Silverlight class library.

Supports JSON in the Alpha.  WCF and SOAP support coming. 

Both Async and Sync web services supported in the Alpha.  General purpose RAD async support is coming.

Silverlight on the server

• works with any webserver
• only requirement is to server Silverlight files to the browser (i.e. xaml, assemblies, resources)
• ASP.NET is a great platform for Silverlight apps
• use ASP.NET & WCF services from Silverlight
• Integrate Media into an ASPX page
• Integrate Silverlight content into an ASPX page

Linq in Alpha only supports querying in memory datasources.  XLinq and DLinq are coming.

Silverlight provides the ability to access the HTML DOM from Managed Code.  Available through System.Windows.Browser namespace

Silverlight allows you to access managed code from script.  Mark a property, method or event as Scriptable with a [Scriptable] attribute.  Don't forget to mark the class in addition to the property, method or event.  You also have to register your object with

WebApplication.Current.RegisterScriptableObject("SomeNameVisibleToJavaScript", this)

Accessing from JavaScript

var control = document.getElementById("SomeNameVisisbleToJavaScript");

control.Content.SomeNameVisibleToJavaScript.MethodName(...);

No intellisense in the Alpha version of the JavaScript functionality.  Is being looked at by the team.

There is no session state in a Silverlight app because it's all running on the client.

HTML integration

• persistent links
• Fwd/Back integration

Simple type marshalling only in the Alpha.  Complex type support coming.

Mac debugging requires a proxy client be installed on the Mac before you startup the browser.

Platform checking:

string platform = HtmlPage.BrowserInformation.Platform;

if (platform.Contains("Mac"))

{...}

JavaScript DOM support issues seem to be the only reason to do this.

Complexity kills

There are problems that technology, no matter how new, will not solve.

Scalability isn't always about hardware.  It could be about scaling the size of the developer team.

Elegance is recognized on sight.

What's a business rule?  If <x> then do <y>

Complexity arises from the fact that we have a lot of intertwining business rules.  Almost like a house of cards, you remove one rule and some or all of the others start to collapse.

Encapsulation is the answer.

Domain Model Pattern.  The DM is isolated and each component works with properties, methods and events.  Properties are usually readonly.  Change data through methods.  Let things be known through the events.

Domain models by definition are independent of things like UI, database and communications.

More and more logic in a DM increases the complexity of the testing.

Where do the rules get implemented in a 3 tier system? 

• SPs?  Not easily, or nicely. 
• In the DAL?  No. 
• In the Business Entity?  No, it's just data. 
• Business Components?  They don't have the data though.  Where would string validation occur?  In the BE or the BC?

Making changes to complex business logic in this scenario makes it hard to have confidence that your changes aren't breaking anything.

Customers and Orders is a good example for complex business logic.  So many possibilities.

Denormalization of a DB is a fact of life.  It can, as a side effect, eliminate some of the complexity from the business rules.

Denormalizing your code will happen too.  Lazy loading is scary because it can result in one developer bringing the system to it's knees.

Domains are split into projects (i.e. CustomerDomain and OrderDomain).  What would this do to your project count on a large system?  I can't see this being sustainable, although it will reduce developer code changing concurrency.

Another sales pitch on coding to the interface (even testing).  Look people, I already bought the store out of this!

Represent each scenario with an interface.  The interface can be used to restrict what the developer can do.  You can check that the coding to the interface exists, but it's hard to check if a developer has coded a method or not.  Restrict this possibility though the items exposed by the interface.

Using events in your DM can allow you to better separate the concerns.

Persistence by Reachability (not supported by nHibernate, Vanatec does.).  This is the ability for the ORM to cascade update or save the child objects when you save or update the top level object.  This is a big deal in the amount of code that you will write in the service layer.

Keep logic out of the service layer.  Separation of Concerns says that the service layer deals with transactions and database calls, not the logic.

IEnumerable is good.  Doing ICustomer.Orders.Add(blah) is the equivalent of saying "Hey you look hungry, let me open you up and stick a burger in your stomach".

Decorator is layering behaviour on myself to provide different functionality.

DM is not work doing if you have only 5 business rules.  Allows you to manage the complexity of a large number of rules.

Switching the object is not easy.  Decorator pattern gives you a lot of problems with persistence.

DM without TDD is useless.  You need tests or you end up with the same mess as if you hadn't done the DM.

Interfaces allow you to explicitly define your scenario and pass that knowledge on to your domain model.

Mario is going to record his presentation and posting it at his blog (www.mariocardinal.com).

Architecture establishes the context for implementation.

Damn Jeremy Miller!!!  His big head is now blocking my view.  Oh, now it's not.

Architects reduce complexity of the problem space by taking fundamental decisions that are costly to reverse.

Tests remove ambiguity

• 2 classes of stakeholders
• Deciders who need to understand the constraint and limitation of the solutions (narrative specification)
• Implementers who need to build and run the solution
• narrative spec doesn't provide concise information about design and decisions
• tests provide an explicit consensus about what is a successful implementation

Tests provide explicit complex

Tests are a design task

Wow....dense slides, but no time to read all the data....

Tests are operational artifacts and must be living and evolutionary.

Testing is a validation of architecture.

Responsibility of an Architect

• reduce complexity of the problem space
• execution related irreversible decisions (i.e. presentation, processing, state management)
• load time (configuration, deployment)
• design time experience (team members skill set, process for development, tooling, staging environment)
• share among the team members and stakeholders the solutions to reduce complexity

Architecture of structure is easier if you divide and conquer.

Layered architecture is a common technique to break apart complicated software systems into components.  Each layer, division in the Divide and Conquer mentality, needs to have the same level of granularity.

Divide upon a stable abstraction.  Structure all the main components interactions through interfaces.   Accept the fact that these interfaces are now almost impossible to change.

Building reversibility into architecture increases the complexity.  More seams in your application architecture increases complexity too.

Don't divide your application based on the physical deployment of the application.  Deployment decisions should come after the architectural design.  Make a distinction between the seams owned by the EAI guys and the seams owned by the developers.  Don't make seams just for the ease of deployment by the IT guys.

Creating only what you need allows you to evolve you code and architecture to the needs defined.

Architecture is what is not reversible.

Test only the risky interfaces.  Risk == Probability of change * Impact

Wow....Bellware just slammed an unnamed (for reasons I'll leave alone too) fellow CodeBetter member.

Udi Dahan quote...."Everything is a people problem"

I sat in on this presentation yesterday and didn't live blog it as I needed a typing break.  Roy's presentation was great.  If you've never seen it before, I've posted a link to a TechEd Europe video of what is essentially the same thing.

We're paid to create business value (amen).

Finding bugs does not create any business value.

Fixing bugs creates the business value.

Preventing bugs creates more business value.

Brian Marick's test type matrix (http://www.testing.com/cgi-bin/blog/2003/08/22).

A lot of bugs are found through exploratory testing (Business Facing & Critiquing the Product).

Depending on your requirements (business, industry, etc.) some types of testing may be more important to start early (i.e. security testing for defense industry software).

Tests tell us where we are from a business point of view.

If we're here to primarily provide business value, we need to be concerned with what the issues that endanger providing.  Test what's risky.

Risks

• Handling Schedule Risk
• Use short iterations
• allows to measure the completion of work in a fixed amount of time
• not possible without all different kinds of tests
• think about breaking down iterations into sub releases
• iteration includes the following tests
• acceptance
• usability
• exploratory
• unit
• property
• shipping an iteration should not mean it's been passed to testing.  It should be done, done, done.
• nothing happens outside an iteration
• don't reopen your iteration planning once you've set it and started work on it
• If it's not in the iteration you don't do it
• testing is a lifecycle issue

Customers don't know what they need and they're horrible at prioritizing.  If you can't ship, you've failed.

Unit tests while writing code.  Acceptance tests as soon as part of the feature works.  Because of this you'll have lots of tests.  Decide what to run and when to run them.  This is for unit and integration tests.  i.e. What is run locally by the dev, nightly, at checkin, etc.

Regressions are everyone's nightmare.  Automating helps a lot for keeping bugs fixed and not letting them creep back into the process.  They can happen because of lack of developer's running all the tests all the time.  Automated unit, Fit and acceptance tests can help, but not with security, performance or usability.

Test interactions with mock objects.  You still have to run all the tests all the time or you won't see the benefits.  Decrease coupling (aka. designing for testability).  Focus on smaller things.

Test Coverage is a metric that can be deceiving.  You have 100% coverage, but did you write all the code for all the features?  How good are the tests creating the coverage.

Nail down the testing requirements prior to working on the code.  If you don't have clear expectations you can not work towards meeting or exceeding them.

Make some of the testing (i.e. performance) part of every iteration.

Shipping is bigger than just features.

Wow....nobody is in Oren's presentation.  They must be getting their heads exploded in JP's.

Wow...Oren just said he posts at his blog "every now and then".

Interaction based testing does have any state to check, so you must test the collaborations (complex or simple) between objects.  Objects don't work in isolation.  Mocking dependencies allows us to test the main code in isolation.  You can accomplish this with Mocks, Stubs and Fakes.

• Fakes:  working implementation, but not a useful one (a DAL that returns from a dataset rather than a database)
• Stub:  empty implementation which may optionally record the calls made to it
• Mock:  pre-programmed for a certain scenario, verify that the scenario was executed properly.

And the maintenance guy steps in to stand right in front of the screen to shut off two lights.  According to Oren that was an integration test.

Testing that an SMS message was sent:

• State Based: Assert.IsTrue(webService.SentSMS);
• Interation Based:  Expect.Call(webService.SendSMS("1234", "hi"));

Interaction Based Testing

• Advantages
• Helps test in isolation
• Handles complex scenarios better
• Encourage best practices
• Disadvantages
• more complex tests
• require a different mode of thinking
• need to understand what is being tested, which isn't always clear

Steps of mocking

1. Create Mock
2. Set Expectations
3. Run Code
4. Verify Results
5. Pass/Fail Test

Now we get to see Oren code.  He's an MbUnit guy it looks like.  Definitely TDD.  Okay...this is how you use ReSharper to make you demo fly.  Roy Osherove comments that Oren's coding with ReSharper like there's UI Automation going on.

Oren uses a ReSharper Live Template of "nm" for  creating a mock object.  What's wrong with "cm"?  Does he have something against the letter "c"?

Hot Agilista update....I think they're stalking me.  Everywhere I am they are.

Straight Mocks don't allow you to do anything that you don't set expectations for.

Constraints:

• LastCall.Constraints(Is.Equal("1234"), Text.Contains("new password: "));
• allows you to say that the last call will have two parameters with a fixed valued and a partial value.  No need to worry about dynamic values in your tests.

SetupResult:

• SetupResult.For(userRepository.GetByUserName("sally")).Return(user);
• Works like a stub

Interesting code formatting for try...catch blocks.  I've never seen the catch on the closing chicken-lip line.

try

{

...

} catch (Exception e)

{

...

}

Oren is a ReSharper ANIMAL.  He's the Israeli JP Boodhoo....but about four times as big physically.

Oren recommends "Working Effectively with Legacy Code" because it has a lot of good ways to construct your tests.

[assembly: InternalsVisibleTo(Rhino.Mocks.RhinoMocks.StrongName)] -- can expose internal items for mocking

Hand-in-hand with mocking

• Dependency Injection
• Inversion of Control
• Programming to Interfaces
• Separation of Concerns

Don't fall into Test Paralysis.  Let your tests have room for change.  Don't specify too much in your tests because it can lock the test which can lock your code.

Make sure your tests are explicit in what they test.

Use the Rhino .Message(...) syntax to help document your tests.

Don't mock

• anything you don't own the interface for
• small granularity code
• System.Data
• Fluent Interfaces

This could be interesting in more ways that one.

And he starts with the "I don't feel embarrassed about perfect feedback scores" statement.

Sub title on the presentation is From Unit Testing to Behaviour Driven Design.

Common statements to challenge:

• Unit tests are documentation
• TDD is design

You must look at tests as documentation for anyone but you.

Scott's going to show the evolution of unit tests (using nUnit) over the years.

Story represents functionality, not specification.  It's for naming/identifying and then moving through planning.  Also known as placeholders for conversation.

Preferred customer discount example is a good one.

Here's how I would have written it 5 years ago....and there's generics in it?  I know....picky me.

Buddy next to me has the loudest laptop ever.  D'Arcy had the slowest last year and now I've seen the loudest.  What did I do to be punished with people who have shitty laptops?

The 5 years ago example shows that writing code all in one method has ramifications on the size and complexity of your tests.  You end up creating a lot of line noise (lines of code that have to be there, but don't directly relate to the task at hand).

Tool that pulls out the test names from the testing assembly and creates a document.

Test naming is important, both for clarity and documentation.  Ripping the test names out should allow you to convey the purpose of the testing to a non technical human.  Naming tests based on their real purpose.  If you're testing a 10% discount for preferred customers, naming should focus on the discount, not the customer or the preferred status.

BDD asserts that focusing on the behaviour will allow the domain language to be created naturally and in a sensible state.

Two types of people who should be tagged with creating a domain specific language are documenters and testers.

You can find inconsistencies and duplications or incorrect domain language by handing the testing names off to non-coders.  These can be software design issues (aka. spec issues).

I'm not seeing a lot of information on BDD yet.

The coding and refactoring in this presentation is painful.  Maybe I'm to used to JP.

Hot Agilista update!  They're in this presentation, but they look like it was a rough night.  Maybe they saw Woodsy dance last night.  I know that made me feel worse than normal this morning.

Wow.  15 minutes to show parameter based injection of a data access object on a method.  People are starting to fade.....

The argument that decoupling code will provide better documentation thorough the tests.

Sometimes you will have tests with large amounts of setup, but you should be doing everything in your design power to avoid this situation.

Simple tests tend to force you to write simple and loosely coupled code.

Finally!  JP has taken over the keyboard and design of the code.

JP has finished and things look way different, but the coding pace is painful.

Scott shows NUnit.Spec that shows his extension method work.  The syntax is quite clear and helps to flush out the readability through natural language structuring in your code.

order.GetTotal().ShouldEqual(150);

FIT can be used for both ASP.NET and WinForms applications.  This is a very good book according to Jeremy.

What's wrong with traditional requirements

BAs create an English language spec doc.  Developers interpret the spec doc to build code.  Testers interpret the spec doc to write test plans.  Then bug volleyball begins.

This can:

• Ambiguity in requirements.  English language docs leave too much room for interpretation.
• Often lacking in fine grained detail.  This is a problem with English docs.
• Often users don't know what they want until you are coding.
• Test plans are a duplication of spec docs
• Sequential development can lead to gaps in communications and understanding.  The handoffs create low fidelity.  Having devs, BAs and testers working at the same time can decrease efficiency.
• Slow feedback between coding and testing
• Missing requirements analysis detail.  These details can't be expected to come out in high level requirements.
• Regression testing

How we want to work:

• Build exactly the right thing.
• Deliver working software in increments with rapid iteration
• never be more than X (5?) days away from shipping.  Not how long the iteration is.
• Optimize throughput of working software
• Maximize our ability to accommodate changes
• Regression testing must be more economical

Moving to Executable Requirements

Reduce amount of bug volleyball.  Catch requirements bugs faster.  Make the requirements unambiguous.  Have way less churn.

Acceptance Test: "A formal test conducted to determine whether or not a system satisfies its acceptance criteria....."  Ward Cunningham

Executable Requirements:

• Express the detailed requirements as automated acceptance tests
• Red/Green compliance
• force details out into the open
• use examples as requirements
• requirements that bite back
• Get the tests out in front of development
• Give developers the ability to execute acceptance tests locally.  Bug count will drop dramatically.  Story TDD or Acceptance TDD will help to make us work faster.  More automated testing beyond nUnit.  Start out iteration with all the acceptance tests Red.  Once all are green and the iteration is over these tests move from acceptance to regression.  Your build can pass when acceptance tests fail (perhaps they aren't implemented), but it can't pass when the regression tests fail.

Tools:

• FIT (Framework for Integrated Tests)
• FitNesseDotNet (FitNesseDotNet.sourceforge.net)
• StoryTeller -- Supercharged FIT testing for .Net (storyteller.tigris.org)
• FitNesse (fitnesse.org)

Fit tests work best for business rule testing.  It's also good for flow based testing.  Can be used to test UI integration.  Jeremy is using it very successfully to drive WinForms.

What are the benefits of FIT testing and hot to realize them

Must be human readable and should turn into documentation as they're created.  To make readable FIT (and Fitnesse) uses HTML with tables rows and cells.

Green Pepper is standing on the shoulders of Fit.  Green pepper is potentially cleaner. (www.greenpeppersoftware.com)

Write your tests with the actual prose of the requirements plus the testing tables.  It looks very clean.

Fit tests require both C# (or other) and HTML specifications?

Feedback loop with Fitnesse is not as fast as it is with Story Teller due to the migration of files to build servers.

The DoFixture is the single greatest advance in test automation history.  Allows flow based testing.  Can create your own domain specific language for testing.  Use to coordinate other Fixtures.  i.e. WinForms Screen Manipulation.

When you attack Fitnesse tests, make your tests as small as possible.  Bigger tests are more brittle.  Leave big tests manual.

Like good unit testing you need to have seams in your codebase to be able to implement this type of testing well.

On a replacement project you can:

• Retrieve the data created in the database by an action in the old application
• Run the new client, inputting the same values, and compare the data created at the database level by the old and new applications

TableLoaderFixture can be used to setup the data in the database as you need it.  This can help you get a solid starting point.

Fitnesse tests can be both for developers and BAs.

Best Practices

• Just in time acceptance tests
• Remember the tests are business facing
• ubiquitous language
• very close collaboration between developers, testers and the customers
• write the tests together
• favour declarative test grammars
• self-contained tests

I had to walk over from my hotel to the conference hotel (about 5 blocks) like every other day.  I looked out the window this morning and saw that it was raining, but I wasn't prepared for the wind.  It was, well, staggering.  This morning was the first time I've ever seen an umbrella, sans operator, moving down the middle of a street faster than traffic.  I also was shocked to see that every trash bin on the sidewalk had one or two umbrellas stuffed in them.

I'm definitely glad to be indoors today.

This is a methodology.  It should be used like a design pattern.

"We think most process initiatives are silly.  Well intentioned managers and teams get so wrapped up in executing process that they forget that they are being paid for results, not process execution" -- Coad, Lefebvre, De Luca 19999

Process makes you think "The process is not as creative as it used to be" and then you quit.

History

First appeared in 1999.  Was a result of many failed attempts at the same project and a demoralized team.

Definition

A process designed and proven to deliver frequent, tangible, working results repeatedly.

It's not:

• YAP (yet another process) that exists for the sake of process
• not a set of process volumes that will sit on your shelf
• doesn't demoralize your team to bureaucrats and process-centric fanatics happy

Characteristics

• Minimum overhead and disruption
• Delivers frequent, tangible, working results
• Emphasizes quality at each step
• Highly Iterative

FDD is liked by a lot of people.

Devs because:

• use the word finished often
• they're involved in many parts of the process
• easy to supply managers with info

Clients because:

• see real results early
• progress reports are written in terms they understand

Managers because:

• gives them a good complete and accurate picture of the project's state

Processes need to be balanced between Heavy Processes (all or nothing) and Light Processes (pure textbook Agile?). 

Heavy Processes: Most companies spend too much money on process for too little value.  When problems come up the add more to the process.  Processes tend to be too inflexible.  Because of this, processes will just get ignored in silence.  Makes traditional PM's comfortable so it becomes a blame of the process not the person.

Light Weight:  A form of rebellion against heavy process and high ceremony.  Easy to swing from very heavy and going to very light.  You can lose "thinking before coding", sight of the big picture and you end up back in chaos.

Focuses of FDD

1. Communication and the language of communication
2. Way to manage complexity.  Standardizing the decomposition model.
3. Quality is introduced right at requirements and all the way through to delivery.
4. Just enough process to make sure the team is working together.  Not so much as to cause pain.

FDD roles

• Project Manager
• Chief Architect
• Development Manager
• Chief Programmer
• Class Owner
• Domain Experts

The list of roles is not fixed.  You can create large teams with a larger number of roles like Testers, Deployers, Technical Writers, Release Managers, etc.

Features

Functional requirements restricted to those of value to a user or client phrased in a language the user or client can understand.  They're small and able to be implemented within a single iteration.  Some features are small enough to be implemented in a few hours.  If you find that your features are too big to complete in an iteration then you should decompose.

Features have a naming convention like

<action> the <result> <by|for|of|to> a(n) <object>

i.e. Calculate the total amount of a Sale.

     or

       Determine the most recent Cash Register Assignment for a Cashier

Law of Consumption of Artifacts  If you produce it and won't use it, the artifact is useless.

Feature Sets

Grouping of features that are combined in a business sense.

Subject Areas

Major Feature Sets.

Feature Tree

Example

• SLA Mgmt
  • Viewing an SLA
    • View Tree hierarchy of SLA's
    • View list of SLAs
  • Viewing Reports of SLA

FDD Practices

• Domain Object modeling
• Developing by feature
• Individual Class (code) ownership
• Feature teams
• Inspections
• Regular Builds
• Configuration Mgmt
• Reporting/Visibility of Results
• Feature -> Work decomposition model

Assessment phases can be used to get a better idea of the specs and better estimate cost and time for the over all project.

Make sure you know how to get started on the project, how to verify you're completed correctly and how you know when you can get out of the project at the end.  Do the same for a feature list.  Plan by feature to come up with feature priorities.  Design by Features next, followed by Build by Feature.

God I love Joel!  Finally a presenter who uses cattle (ICattle, Cow, Cows, SalesManager etc.)  Joel Semeniuk is my new coding HERO!!!

Milestones, Visibility and Reporting

No status reports.  Milestones must be concrete, specific, measurable events defined with knife-edge sharpness.  Each phase is given a %age of overall work and then multiplied by the hours estimate.  This makes more sense at the Feature Set level.

Reporting is more detailed than just a burndown chart.  The data is less and less granular as it gets pushed higher up the management team.

FDD in VSTS

Add a couple of fields (feature, planned, actual).  Everything is a task in VSTS including things like Code Reviews, Decomposition, Coding, Code Inspections, etc.

Imaginet's GrandView tool.  Has single feature task dependency diagram.  Estimate views also exist for features.  This tool does all estimation, VSTS is only used for the construction phase.

Joel's cattle based class diagram makes the close to Day 1 of DevTeach 2007 a great thing.

Roy's writing a book.  The Art of Unit Testing.  Sample chapter available.

Why should I care

 Automated testing and regressions, data layer also can contain logic and the cost of changes is lowered.  How do you know if the impact of changes if you are asked to change something like a primary key definition after the application has gone into production?  Test and fix cycles will allow you to see defects, fix them and do it in a timely fashion.

How do you test logic that exists in triggers?  It's real logic and it needs to be tested.

Definition of a unit testable system using PC-COF rules

P - Partial runs are possible

C - Configuration is not needed

C - Consistent pass/fail result

O - Order does not matter

F - Fast

Fast is not relative.  Fast needs to be fast.  All your unit tests need to run in a time frame that will not dissuade developers from running the full suite of tests.  i.e. 1/2 a second per test for 10,000 tests will take 1 hour and 23 minutes.  That is not fast.

Don't ever do partial test runs.  This isn't good integration.  You might know that a partial run is good enough, but will any other developer know that?

Unit Testing vs. Integration Testing

Integration test are slower by nature.  They need configuration and large parts or whole systems to complete.

Usually can be written later in the project (you need many parts or whole systems, you have to wait for them to be built).

Must be able to separate these two types.  Put integration tests in a different project.  You don't want to run both types of tests together.

NEVER have developers get to the point where they say "It's okay, it should fail".

If you can't run tests, they won't pass.  If they don't pass, no one will maintain them.  If you don't maintain them, the test suite won't be useful.

Broken window theory.  Set the standard and consistently apply them.  Always expect tests to pass.  It should be a requirement of your project at all times.

To mock or not to mock the DB?

Mocking the DB == Faster testing, no setup fees.

Problem -- you don't test the DB logic (i.e. keys, indexes, RI, etc.)

Never mock a database.  Mocking the data layer is not a bad thing though and the two are different.

Rolling back DB state

• XML loading (semi manual)
  • Identity fields are an issue.  You will need to reseed or turn off and on the identity feature on the table if you want the ID to be the same.
  • hard to maintain if:
    • parent child relationships
    • schema changes
• Rolling back with COM+
• James Newkirk
• COM+ == System.EnterpriseServices
• Distributed Transactions
• MyObject:ServiceComponent
  • TestClass inherits from ServicedComponent and then every test runs inside a transaction which can be rolled back.  The only problem is that identity columns will change.
  • Requires the Transaction(TransactionOption.RequiresNew) attribute on the class
  • Teardown requires code to run ContextUtil.SetAbort();
• what if you're testing other serviced components?
• what if the objects under test require their own transactions?
• Don't do RequiredNew unless absolutely needed
• Use COM+ v1.5 (Services without components)
• doesn't require inheritance from ServicedComponent
• System.Transactions (.NET 2.0)
• automatic promotion of transactions
• very simple syntax (using clause)
• will employ distributed transactions (COM+)
• XtUnit
• has rollback attribute which creates a transaction implicitly
• must inherit from TestFixtureBase to use it
• can attribute only some tests instead of all in the class
• MbUnit
• has a rollback attribute
• SqlRestore
• slow
• requires exclusive DB access
• COM+ 1.5

Agilista alert!  They aren't in this presentation!  Instead I have Oren to be my eye candy.

Overview of Data Access Patterns

• Rehash of Fowlers Data Access patterns

Working and testing with DataSets

 How do you compare 2 datasets?  Use Darrel Norton's data compare extension to nUnit.

Pure DB tests with DataDude

Can auto generate a SQL unit test. Because the tests are in TSQL you can use BEGIN TRANS and ROLLBACK TRANS to handle ensuring data state.

In agile you want:

• ROI
• Good enough design
• make best design possible, but don't spend years on it
• flexible delivery options
• customer doesn't know what they want
• they learn as the project goes
• be able to make a complete turn in the code base
• move low priority features to the end -- this can save a project
• sustainable development through maintainable code
• understandable
• testable
• changeability
• avoid brittle
• avoid rippling changes

Do one thing at a time.  Too much is overwhelming.  The complexity is overwhelming.  Build little and assemble the pieces.

Minimize wasted motion.  Don't work on the unnecessary.  Don't work on something that is never going to be built.

Enable change at all points of the process.

The faster the feedback loop, the more productive you can be.  This is even true for developers.

Do the simplest thing that could possibly work.

• work means it can go to production.  Handles edge cases.  Has error handling.
• simple means it is minimal code repetition, elegant to a point
• simple means different things to different people.  You need to take this into account when designing.  Creating a common vision or dumbing it down.

YAGNI (You aren't gonna need it)

• build what you need right now
• the simple solution may be enough
• easy to add complexity, but tough to remove it
• makes shipping faster
• "We are going to need it"  counter this with "We'll make code that is easy to change"

Design vertical slices of deliverable functionality.  All design work should be traceable to immediate business needs.  You have to keep one eye on the upcoming features while you work this way.

Minimize rework by integrating early.  Test early.  Get feedback from users early (37 Signals territory).  Deploy early (does the server infrastructure work?).  Ultimately you want to shorten time between doing and verifying.

Delay commitment until the last responsible moment.  We all agree on this, but when is it?

• Utilize continuous learning
• Don't act on speculative design
• Keep your options open
• Think ahead!  Don't act ahead!

Don't go past the last responsible moment.  Be aware of outstanding design decisions.  Some of your decisions will need to be made earlier than others.

Abstractions can provide lots of reuse of code and development can be easier.  They also can add unnecessary complexity and can make it so that your changes are more difficult.  Make abstractions earn their keep.

Avoid "Architect Hubris" (defn. If we just build the framework upfront, coding will be easy.)

Things that are not related conceptually should not be related in the system (Pragmatic Programmer).

Separation of concerns, Cohesion, Coupling == Orthogonal Code

Always make sure you're ready to have your code readable (font size).  Bellware blurts out "MS sucks".  Miller responds "Or the guy driving does".

JP and Woodsy are looking like a pretty cute couple sitting together on that chair.

Single Responsibility Principle.  This is the most important design principle.

• "A class should have only one reason to change"
• One class, one responsibility
• An expression of cohesion

Keep each piece of code as simple as possible.

Don't worry about the cyclomatic complexity of a class, look at the worst cyclomatic complexity for a method within the class.

If you open a class with a *lot* of usings, you definitely have too many responsibilities.

First step in refactoring to SRP is to create a class for each area of responsibility.

Using HTML to show C# is a tricky way to make syntax error go away.

Open Close Principle (OCP).  "Software entities should be open for extension, but closed for modification." -- Robert C. Martin

The essence of OCP is to be able to add functionality by writing new code and not modifying existing code.

Depend on Abstractions

• Dependency Inversion Principle
• code to interface
• use mock objects to remove inconvenient dependency tests
• Don't let the abstraction leak
• if you code to an interface and then write a conditional for a specific class that implements that interface
• webforms is a leaky abstraction because of the abstraction of state that leaks into your code all the time even though webforms are trying to make you think the web is stateful

Testing seams are important for isolating the code so that you can write simple tests for small amounts of code.

I just realized that I'm sitting in a room (and a row of seats) with the Code Better crew (JP, Scott Bellware, Jeremy Miller and Rod Paddock) add to that Oren Eini.

State based testing and stateless testing argument breaks out between Oren and Jeremy.  Woodsy jumps in the middle and gets a mock object to the head.

2nd quote from the Pragmatic Programmer.  Top 5 on my list of must reads for developers.

Yesssss....the internet is back working.

Hot agilista report.....they're not on the floor this session, but they're still right in front of me.

"TDD gives you the sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it" -- Martin Fowler

Make your code easy to test.  You can cycle much quicker this way.

Testability is a first class quality in your code.  Testability means your code has good cohesion and coupling.

Isolate the ugly stuff (stuff that's inconvenient while unit testing) i.e. database, active directory, web services, messaging.

Dependency Inversion Principle:  code to the interface not the implementation.

Hot agilista note!  #2 (Wendy) has a compulsion to say "Bless you" to everyone in the room that sneezes.

When coding use Push, not Pull.  For example, don't code in DateTime.Now() if you need it.  Instead, push in a date.  If you want it to be Now(), great, if for testing you want something else, better.

Test small before you test big.  Don't get into analysis paralysis as a developer.  Don't think about the bigger code right off, work on a small piece and make it loosely coupled so that it can be rearranged as required after starting coding.

Agilista note:  They're writing notes to each other instead of speaking.  I'm sure the last one said "Why are we sitting near those to cuddling developers?"  Woodsy and JP don't have a clue.

Keep a short tail.  Make sure you don't have to bring too much with you when you move a class somewhere else.  i.e. moving a DTO shouldn't require moving the DAL and the database.  Also keeping a short tail allows you to test business logic by testing only the business logic.  Don't test due to a side effect of the business logic (i.e. the error message returned).

JP has deserted Woodsy for a seat closer to the action.  I'm sure that Woodsy would have given him more action if he'd asked.

Don't mock the children in a dependency chain.  Only mock the level that you're interacting with.

Don't work on an integration test until you know that all the individual pieces work correctly.

Design together

• no time for misunderstanding
• socialize the design -- this is a lot harder than making the design decision
• know the why
• collectively challenge the design every day
• talk about the design
• keep the team abreast of changing design strategies.

Freaking fantastic talk covering a whole lot of topics (as you can tell by the length of the post).

Roy will accept your emails, but he doesn't guarantee that he will read them.

The presentation is going to follow an agile method.  We're choosing the list of topics, then we get to vote on them and the highest votes will be discussed first.  Here's the list

• Scaling Agile to large teams (Scrum) -- 9 votes
• Scaling Agile in the Enterprise -- 7 votes
• Adopting Agile in organizations -- 25 votes
• Agile in distributed teams -- 35 votes (example of estimation gone wrong)
• Overview of Agile processes -- 20 votes
• Introducing into a team -- 20 votes
• Is Agile a defined process -- 2 votes (I don't think the idea person even voted on this)
• How to start pair programming -- 12 votes
• Team structure -- 24 votes
• Success story (bad to good) -- 20 votes
• Same team multiple projects -- 15 votes
• Customer involvement -- 12 votes
• Why do I like Agile -- 11 votes
• Agile estimation -- 40 votes
• How do you measure results -- 22 votes

Agile Estimation

Dev says 2 weeks

Dev Lead says 4 weeks

PM says 2 months

Project owner says 4 months so I'll out source to India to reduce risk

Estimation is a guess based on the abilities and ideas of the people who are going to do the work.  It's still a guess.  No two groups will do the same work in the same amount of time.  You have to remember that people have different situations...wives nagging, past experience, team doesn't like you, crush on the hot agile girls sitting in front of me.

Let your team work for one iteration and see what their pace is.  Having team members who are sick or on vacation should not be removed from the equation.

The best people to know how to estimate are the individuals.  More and more iterations will help developers increase their estimation skills.  The only way to learn how to estimate is to do it.

There are at least 2 rounds in an estimation process.  Having the whole team estimate can help them to understand the whole project and get comfortable with each other.

Do all estimation before starting the iteration in a day or two that is part of the planning process for each iteration.

Don't ever estimate for the entire project.  Just the coming iteration.

Estimating a project is a total guess.  Estimating an iteration is more educated because the situation is immediate and the prerequesites and team situation are currently know.

Requirements don't change during the iteration.  This keeps things focused and allows for replanning and refocused

The hot agilista chick loves the geek sticker on my laptop.

JP points out that you sometimes see that tasks aren't as fine grained as you want them.  You need to break them down on during the planning meeting.

Bellware jumps in and says "Breaking down the tasks into smaller pieces is a design process.  This is where the design part of an agile project occurs."

Roy has the bad ass "geek" shirt with some quasi dress pants and running shoes.....Justice Gray should take some notes.

Should people be optimistic or pessimistic with their estimation?  How do you acheive group consensus on an estimate?  i.e. 1 dev says 2hrs and another says 40.  If you get this its a sign that you may be missing something.  You have to look at it again and restimate it without any buffers.  Be completely realistic and truthful to the team lead.  the TL is the only one who sees them.  This builds a feeling of comfort in saying that it will take longer than you may want, but it's not a punishable offence.

Iteration planning is an operation planning session.  Project planning is strategic planning.  Very different goals.

JP is standing at the front without his water bottle!  He looks very lost!

Estimation may not fit with what the organization wants to hear.  i.e. "It must be ready by Q3".  You can either remove features or increase spending to meet these fixed deadlines.  You can't say "We will have it ready by Q3".  You can say "We will have it ready by Q3 with the most requested features".  This is a big difference and allows you to deliver a better product by the deadline.

Fixed money or fixed time table, the only thing that can change is features.  If it's fixed you usually get an extentions and you just finished 9 months lying to each other.

The appropriate resolution for a task depends on the length of the iterations.  3 week iterations == about 3 day tasks.  1 week iterations == 1 day.  Adapt this rule to your project.  JP is the man!  He did a project where tasks were 5 hrs or less!

Planning Poker tool is very good.

Agile in Distributed Teams

Working in an agile environment is different that distributed.  You can't be purely agile in a distributed team.  You need people to feel like they're sitting right next to you.  Email doesn't cut it.  Not having immediate access to the client is a *huge* problem.

Having a product manager is important.  They represent what the client wants.  They really need to know.  They need to be physically in the team.

Distributed teams are different from distributed people.  It requires the proper tools (IM, CI, Remote Desktop).

Hot agilista chick #2 has the name "Wendy"....some of you will know who I'm talking about.

You need to have one person managing the incoming requirements.  They have to work at managing the priorities.  This can be done using a point system where you give an allocation of points to a client and let them priortize by assigning points to tasks/features.

Hot agilista chick #2 (Wendy) is now talking about Scrum and how to do project management with it. 

Being agile means that you move resources to help teams meet deadlines.

Dependancy managment is something that is dealt with in design.  Agile or XP doesn't ignore them just like waterfall doesn't.

Adopting Agile in Organizations

People are reluctant because of irrational reasons.  i.e. TDD, test doesn't compile?  or Pair Programming only saves on hardware costs.  Ususally these items result in better quality and productivity.

The only real way to introduce this is through training because it takes people time to grok the methodology.

Change either happens from the bottem where a team just decides to do it, or a manager decides to implement it.  Teams implementing is usually better because managers can force methods or try to implement too much.  Forcing will cause people to do less.  First rule is to start small. i.e. CI or automated builds or shorter iterations.  To much at once leads to failure.

JP pontificates on the immediate deliverables for developers when changing a team.  You need to make the team feel like you have a vested interested.  Small wins, small victories.  Always use a staged approach.  Mentoring is more important than training.

Scott Bellware says that software productivity, in orders of magnitude, is changed by software quality.  Anything less than productivity and quality is just scrambling for expensive productivity.

Don't forget, Roy Osherove (minus friends) will be at Edmug on the 22nd of May.  If it's anything like this, Edmonton's software development teams will not be the same.

Jean-Rene has started and is announcing that DevTeach will be a twice yearly event.  The next show is in Vancouver Nov 26th to Nov 30th.  JR rocks.  Yesterday he said that he was worried about the number of attendees that he'd have at it.  I think DevTeach Vancouver is going to rock and I'm certainly going to be there.  Venue to be announced after this event.  JR has already told me and it's going to be a sweet location!

JR is showing the swag that will be drawn after each session.  Sweet...and an Internet cafe (10 laptops courtesy of Technet) to do the evals online.

On to the presentation now with Pablo Castro talking on Bootstraping the Data Platform:  The ADO.NET Entity Framework.  ADO.NET EF is like nHibernate and will save you time writing your data access layer.

One application gets a view of data that is not what will be needed by another application that shares the same data source.  EF will help you to abstract this situation away. 

MS Data Platform:

• provide a uniform way of describing business data
• give each application an appropriate view of the data
• enable the creation of services, from reporting to synchronization to integration
• apps and services use the same data model

EF will enable you to create apps using conceptual models instead of the physical data models.

Demo time.  And we're starting with creating a Data Source with a wizard.  Sigh.  When will we get past wizard based demos?  Pablo breaks new ground by not using Northwinds.  Instead he has some way to work with Encarta.  This is refreshing.

In memory objects are automatically synchronized with database values for things like identity fields or values updated by database triggers.

You must explicitly tell the framework to load (using a dot Load() syntax) and it will go out to the database and resolve the relationships and load the data appropriately.

Holy crap this guy needs ReSharper to remove all unused references (Ctrl-Alt-F works great for this).

You can edit the XML files through a designer that visualizes the schema.  This can let you change singulars to plurals.  Think of it like the Strong Type Dataset designer.

The room is filled with the sound of Vista starting up.  I have to give MS credit for make a much less intrusive startup sound than the one that was in XP.

This is a database technology

• Database independent
• extended ADO.NET provider model
• Broad access-path options
• Update: custom SQL or stored procs
• Retrieval: tables, views, stored procs
• Considering: table-valued functions
• Specialized mapping constructs
• use custom queries as base tables

I think that the MS has done a good job in this proving something that they might not have intended to.  They've shown that their design of the ADO.NET framework, using the provider model, has created great extensibility which allows for fantastic new tools to be added on going forward.  Whether this is one of them I'm not sure.

Folks, if you aren't going to DevTeach next week you really need to.  The content is fantastic, the venue is remarkable and the city is spectacular.  Top that off with good proximity to Rue Crescent, anglo-pub-central so I'm told, and you have a sure fire guarantee of fun (and me getting drunk).

Unlike Jeffery Palermo, I'm not organized enough to setup a Party with Palermo inspired event.  Instead I'm just going to head out to Les Trois Brasseurs (the one on Rue Crescent...direction here) on Tuesday night at 730pm.  There is no swag to give away (unless some great sponsor reads this and contacts me with swag.....), there is no free food (unless you can get me drunk enough to buy), and there is no free drinks (see the food point).

Leave a comment here if you're thinking of joining me so that I can try to get some reservations.

On Friday afternoon I noticed that our CC.Net server had stopped working.  I spent the entire afternoon looking into the cause of the problem to no avail.  Finally I resigned the idea that I was going to have it working before I left for a weekend out of town.  Today when I got back to work it appeared as though the elves that I was hoping were going to fix this issue, had actually taken the weekend off too.  I hunkered down and began troubleshooting again.

The symptoms that I was running into were these:

1. CruiseControl.Net service would start and I would be presented with a JIT Debugger window for errors in the Remoting namespace
2. Service would shutdown (didn't matter if I tried debugging or not)
3. Sometimes a kernal32.dll exception would appear in the Event Viewer (I think this is related to the JIT Debugger window)
4. Sometimes the CruiseControl.Net service would log information to the ..\CruiseControl.Net\server folder

Originally when I logged onto that server to do some maintenance on Friday, I was presented with a message saying updates had been applied and would you like to restart.  Of course I chose yes and went on my merry way.  Between the JIT Debugger pointing at the Remoting namespace and the updates having been applied sometime before the Friday failures, I figured that there was a problem with the ability for the service to communicate over remoting to localhost.  After spending a number of hours working on this angle, I finally gave up and did what any frustrated team lead does.....I delegated to one of my guys while I went to another meeting on productivity.

When I got back the answer to the problem was quite obvious.  Apparently the guy who was doing maintenance on this server on Friday (nobody point fingers....doh) had modified the ccnet.config file using CCNetConfig.  Being the frequent updater that my current employer is, the version of CruiseControl.Net in use is v1.1.xxxx.  It looks like there may be a bug in CCNetConfig since I specifically chose that version when opening the file and saving it (if you look in your ccnet.config file you'll see the commented out XML at the top of the file indicating which version of CruiseControl.Net CCNetConfig has labeled the file as), and yet the file was in an invalid format.

I spent a little bit of time looking to see what the problem was, but in the end I decided that a full day chasing the issue was enough time spent there.  What I do know is that the ccnet.config file that I have working currently does contain a far different structure than the one that CCNetConfig created for me.