You probably heard me talk about zero friction and maintainability often enough in the past. But they were always separate subjects. When I prepared for my Zero Friction talk, I finally figured out what is the relation between the two.

I talk about zero friction as a way to reduce pain points in development. And I talk about maintainability as a way to ensure that we build sustainable solutions.

Let us go back a step and try to realize why we even have the issue of maintainability. Bits do not rot, why am I so worried about proactively ensuring that we will keep the code in a good shape?

As it turn out, while code may not rot, the design of the application does. But why?

If you have an environment that has friction in it, there is an incentive for the developers to subvert the design in order to produce a quick fix or hack a solution to solve a problem. Creating a zero friction environment will produce a system where there is no incentive to corrupt the design, the easiest thing to do is the right thing to do.

By reducing the friction in the environment, you increase the system maintainability

3 Months ago I released Rhino Mocks 3.4, we have made some great improvement to Rhino Mocks in the meantime, and it is time for a new release. I generally don't believe in beta releases for Rhino Mocks, but this time we are coming up with a new syntax, and I want to get additional external input before we make a final release on that.

The biggest new feature is the new AAA syntax, which you can read about in the relevant post, but we had a few other new things as well.

• CreateMock() is deprecated and marked with the [Obsolete] attribute. Use StrictMock() instead.
• Better handling of exception in raising events from mock objects
• Fixing an issue with mock objects that expose methods with output parameter of type System.IntPtr.
• Allowing to return to record mode without losing expectations, thanks to Jordan Terrel, for submitting this patch.

I intend to write a lot more documentation about the new AAA syntax, but for now, you can visit the tests for the feature, to see how it works.

As usual, you can find the bits here.

Note that this release if for .Net 3.5 only. Rhino Mocks 3.5 RTM will be for .Net 2.0 and 3.5, but I am focusing on the capabilities that I can get from the 3.5 platform at the moment.

I intend to release the new version of Rhino Mocks soon, and I wanted to show the new syntax that I have been working on. I still need to write more thorough documentation, but I think that just the syntax should be a pretty good indication of how things are going.

Without further ado, here is the code:

[Test]
public void WhenUserForgetPasswordWillSendNotification_WithConstraints()
{
    var userRepository = MockRepository.GenerateStub<IUserRepository>();
    var notificationSender = MockRepository.GenerateStub<INotificationSender>();

    userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" });

    new LoginController(userRepository, notificationSender).ForgotMyPassword(5);

    notificationSender.AssertWasCalled(x => x.Send(null),
        options => options.Constraints(Text.StartsWith("Changed")));
}

[Test]
public void WhenUserForgetPasswordWillSendNotification_WithArgMatchingInTheLambda()
{
    var userRepository = MockRepository.GenerateStub<IUserRepository>();
    var notificationSender = MockRepository.GenerateStub<INotificationSender>();

    userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" });

    new LoginController(userRepository, notificationSender).ForgotMyPassword(5);

    notificationSender.AssertWasCalled(x => x.Send(Arg<string>.Matches(s => s.StartsWith("Changed"))));
}

[Test]
public void WhenUserForgetPasswordWillSendNotification_WithArgumentMatching()
{
    var userRepository = MockRepository.GenerateStub<IUserRepository>();
    var notificationSender = MockRepository.GenerateStub<INotificationSender>();

    userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" });

    new LoginController(userRepository, notificationSender).ForgotMyPassword(5);

    notificationSender.AssertWasCalled(x => x.Send("Changed password for ayende"));
}


[Test]
public void WhenUserForgetPasswordWillSendNotification_UsingExpect()
{
    var userRepository = MockRepository.GenerateStub<IUserRepository>();
    var notificationSender = MockRepository.GenerateMock<INotificationSender>();

    userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" });
    notificationSender.Expect(x => x.Send(null)).Constraints(Text.StartsWith("Changed"));

    new LoginController(userRepository, notificationSender).ForgotMyPassword(5);

    notificationSender.VerifyAllExpectations();
}

The class under test is:

public class LoginController
{
    private readonly IUserRepository repository;
    private readonly INotificationSender sender;

    public LoginController(IUserRepository repository, INotificationSender sender)
    {
        this.repository = repository;
        this.sender = sender;
    }

    public void ForgotMyPassword(int userId)
    {
        User user = repository.GetUserById(userId);
        sender.Send("Changed password for " + user.Name);
    }
}

Well, DevTeach Toronto is over, and so it my blogging hiatus. I haven't had time to blog because there was so much to do and take part of.

Now that it is officially over, I can look back and say that DevTeach is still my favorite conference. Leaving aside the great speaker and talk line up (thanks James, and thanks Scott for doing it on the last two DevTeach confs), what I really like about DevTeach is the interaction with the attendees and the amount of face to face time that you get with everyone. I haven't been able to crack what it is that makes DevTeach special in this way, but I have been to other big conferences, and they were good, but they weren't the same.

In short, in you have can make a conference, you really want to make it DevTeach.

I am feeling somewhat wrung out at the moment, the last week was intense. I had five talks and a panel discussion (which will be available on DotNetRocks! ) , and at some point it felt like playing musical chairs. I like presenting, make no mistake, but there is no denying that giving a talk is a high energy expenditure event.

Overall, I am happy with the way the talks went. I talked about:

• Rapid (maintainable) web development with MonoRail
• Advance usages of Inversion of Control containers
  
• Writing Domain Specific Languages in Boo
  
• Object Relational Mapping += 2: More then just data <-> object
• Building Zero Friction Development Environment
  

The last talk was a surprise one, I had to fill in for Roy, who was sick (but is getting better). For an off the cuff session, I think it went very well. It was somewhat like posting to my blog, live and in speech, instead of writing. At least, that was how it felt, far more informal and more abstract than most of my talks. It has also given me the chance to clarify some of my thinking in the area of zero friction development and why this should be a goal.

The Advance IoC and Advance OR/M talks were pure fun. Fundamentals are important, but there isn't enough discussion about what happens after you grok the fundamentals as I would like to see.

Of course, I know that the pace of those talks is fairly... daunting. I am trying to cover in one hours concepts that took me months and years to figure out. I am not trying to impart the actual knowledge in those talks, there is just not enough time for it, but I am trying to point the way to interesting approaches, the advantages that using those approaches gives you, and where you should explore further.

The panel discussion, which was recorded as a Dot Net Rocks podcast, talked about The Future of .Net. Me, Ted Neward and Scott Bellware sat and talked about this for a while. I think that it was a good discussion, but I really feel the need to find something else to point as the negative examples. We have been beating the same horse for too long. I accept nominations, by the way.

Too many hallway discussions and side talks to count or articulate, I am afraid.

Greg's talk about DDDD was interesting, we talked about it afterward, and I think that we are much closer in our thinking that it would appear on the outside. A lot of the things that Greg objects to are things that I would hurry to avoid as well. We take different approaches to avoiding them, most probably because we tend to build very different applications.

In summary, DevTeach rocked!

I had a lot of fun, and baring intervention from a higher power, I definitely intend to be in the next one.

Due to low amount of attendees, the DSL course that was suppose to run next week in Austin had ben canceled.