Oren Eini (more popularly known as Ayende Rahien) has started a series of video casts to introduce his exemplary mocking framework known as Rhino Mocks. Rhino Mocks has recently shipped version 3.0, and I want to congratulate Oren on this milestone.

His video cast provides an introduction to Rhino Mocks, and also helps to understand how you might use it.

As Ayende states in his message announcing the cast, this is his first time doing something like this and suggests that there is an abundance of things wrong with the cast. I have to say that I disagree with him on this.

Sure, this isnt as polished as DNR TV, but then again, not much is. The important part of any cast on the net is not how well its polished, but rather the content behind it. I’d rather have an unpolished cast that has wonderful content behind it, rather than a well polished turd. :)

To this, I say, Ayende… This was fantastic. I enjoyed getting insight on using Rhino Mocks from the creator himself. I also really enjoyed seeing how the mind of a true TDDer works. Writing tests before writing code. It sounds good in theory, but making it work in practice is much more difficult. I think as more people watch this show, they’ll see that its really quite easy. It just requires some thought. I am so looking forward to the next one. :)

By the way, was it just me, or did anyone else find it hysterical that Ayende at the end of this cast mentioned that he updates his blog “occasionally”? I mean seriously… This guy cranks out more posts in a day than I do in a month, and its occasional?!?

For those of you who have not heard of or are using MonoRail yet, go take a look at the project website, or even better, go listen to Scott Hanselman’s podcast with the boys from Eleutian Technologies where they discuss MonoRail and the advantages it provides. I’m going to stop short of this turning into another ASP.NET WebForms sucks post. :)

What I do want to do is provide what I think is a useful ViewComponent. Honestly, the first one I wrote, but one that I find myself using quite a bit. It’s fairly simple in it’s functionality and what it provides. Essentially, it’s just a Log In / Log Out toggle.

I found myself writing something like this over and over, and decided it would be best to write it once more as a component, and then just to reuse this component wherever I need the functionality in the future.

The use of the view is fairly straightforward in that you just declare the component, and then specify two sections. The first is what should be displayed when you need to log in, and the other is what should be displayed when you can log out.

For example:

<span class="menuitem">
#blockcomponent(LoginComponent)
  #login
    $HtmlHelper.LinkTo("Log In", "Login", "Index")
  #end
  #logout
    $HtmlHelper.LinkTo("Log Out", "Login", "Logout")
  #end
#end
</span>

The component code is straightforward enough:

public class LoginComponent : ViewComponent
{
    private bool isLoggedIn;
 
    public override void Initialize()
    {
        base.Initialize();
 
        if (!Context.HasSection("login"))
        {
            throw new RailsException("LoginComponent: Must have a login section defined");
        }
 
        if (!Context.HasSection("logout"))
        {
            throw new RailsException("LoginComponent: Must have a logout section defined");
        }
 
        isLoggedIn = RailsContext.CurrentUser.Identity.IsAuthenticated;
    }
 
    public override void Render()
    {
        if (isLoggedIn)
        {
            Context.RenderSection("logout");
        }
        else
        {
            Context.RenderSection("login");
        }
    }
 
 
    public override bool SupportsSection(string name)
    {
        return name == "login" || name == "logout";
    }
}

The CHAOS Report released by the Standish Group in 1995 states that of all the IT projects only 16% are successful, with success being defined as on time and on budget. 53% of IT projects are either late or over budget, and amazingly 31% of all IT projects started are never even finished.

Surely, there’s a better way to deliver value to customers in a timely fashion…

Introducing SCRUM, which is classed as “agile development” which is a set of tools and work methods which are designed to:

• improve the ability to respond to market needs and demands
• cut down on waste and waiting periods
• reducing employee stress and increasing productivity

The central part of scrum is a sprint, which is a focused effort for a fixed period of time (typically 30 days) towards a fixed set of goals. There are certain roles within scrum, which are the following:

• The scrum team – This is the group of people that is actually performing the work of designing and problem solving. The team is a self-organizing group of 5-9 members, with no set project roles. A tester can write code, a developer can execute tests, etc.
• The product owner – This is the voice of the customer. Often times, this person is the customer, but it can certainly be filled by a person internal to the organizations. The product owner insures that the team is working on the right things for the business.
  • The product owner is also the administrator of the product backlog, which is a current to-do list where all specifications for a product are listed according to how profitable they are. The product backlog is visible to the entire organizations so all are aware of what to expect in future releases.
• The Scrum Master – The Scrum Master is a combination coach/gatekeeper/fixer. The Scrum Master conducts daily meetings with the team, which answer three questions:
  • What did you do yesterday?
  • What are you going to do today?
  • What is standing in your way?

The Scrum Master insures that the team is not disturbed and has the optimal circumstances to get their work done. Part of this includes removing any impediments from the team so that they can focus completely on achieving their sprint goals. Lastly, the Scrum Master holds an evaluation meeting, or retrospective, to reflect on what went well and what could be improved on and adapts those findings for the next iteration.

So, what happens during a typical iteration? First of all, the Product Owner compiles all changes planned for a particular product and prioritizes them. The result of this work is a product backlog, which is a constantly re-prioritized to-do list. Prior to each sprint, the highest prioritized goals are transferred to what is called a sprint backlog.

A scrum team of 5-9 people is then formed to tackle the work on this sprint backlog. More discussions occur with the Product Owner which form the goal and the prioritized functionality is then broken down into small tasks. Once tasks are determined, the team self organizes and does work against those tasks, for which the entire team is collectively responsible for.

After the sprint is over, a demonstration happens with the customer to show what value was added to the product. Also, a sprint evaluation or a retrospective occurs to determine what went right and what went wrong for the iteration.

Lather, rinse and repeat…

When you interop with a COM component, you may need to use the AspCompat attribute if the component has to run on a thread initialized into a single threaded apartment (STA). The question comes up: how do we know if the component needs to run in an STA?

K. Scott Allen (of odetocode.com) has provided a technique which can be used to determine whether you need to provide this attribute or not. Essentially, we need to dig around the HKCR section of the registry and find the component’s CLSID entry. Once you find that, you will find an InprocServer32 key, which holds the ThreadingModel value. If the ThreadingModel value is set to Apartment, you need to use the AspCompat attribute.

Now, if you’re designing service layers, and the service happens to use a COM component, how do you add an AspCompat attribute to a web service (.asmx)? In short, you will need to create a new HttpHandler to process requests for the web service. The new handler will inherit from System.Web.UI.Page and will have access to initializing the request using the AspCompat subsystem.

The class looks like this:

public class AspCompatWebServiceHandler : Page, IHttpAsyncHandler, IRequireSessionState
{
     public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback callback, object extraData)
     {
         return AspCompatBeginProcessRequest(context, callback, extraData);
     }
 
     public void EndProcessRequest(IAsyncResult result)
     {
         AspCompatEndProcessRequest(result);
     }
 
     protected override void OnInit(EventArgs e)
     {
         WebServiceHandlerFactory factory = new WebServiceHandlerFactory();
         IHttpHandler handler = factory.GetHandler(this.Context, this.Context.Request.HttpMethod, this.Context,Request.FilePath, this.Context.Request.PhysicalPath);
         handler.ProcessRequest(this.Context);
         this.Context.ApplicationInstance.CompleteRequest();
     }
}

After adding this class to your project, you’ll need to register the handler in the web.config file using something like:

<system.web>
     <httpHandlers>
         <add verb="*" path="ServicePath.asmx" type="MyNamespace.AspCompatWebServiceHandler, MyAssembly" />
     </httpHandlers>
</system.web>

If you’re seeing funky issues when using a COM component (in a service layer or not), you will want to investigate whether the threading model is becoming an issue. The difference in implementing this handler has made a night/day difference in our application’s performance and memory usage.

This is certainly one of the things that makes the ASP.NET framework great… the ability to drop in new functionality if you have a need to.

For those unfamiliar, Adobe Photoshop is the defacto standard in image editors, and the CS3 release is version 10 of this product, which has needed to be re-tooled to provide support for a whole new processor architecture (a universal binary for Mac OSX).

For years the Adobe Photoshop team has been trying to get away from the traditional death march to a more agile development style. For its CS3 release, it made the jump, with the help of VP Dave Story. The result? More weekends off, and a third fewer bugs to fix. Mary Branscombe quizzed co-architect Russell Williams on how they did it.

The intriguing portion of the article for me is how they handle deployments and iterative drops for “demos” (emphasis mine):

Did it change the way you put out betas?

An automatic process builds the program every night and runs a set of tests before posting the build on our internal servers for QE to test. We could take almost any of those daily builds and use them for demos.

The public beta was basically just “whatever build is ready on date X”. There were only a couple of “we really gotta fix this before we send out the public beta” bugs. With past versions, we couldn’t have done a public beta at all that far ahead of release – there would have been far too many bugs.

We weren’t swamped with a pile of bugs from the hundreds of thousands of people who downloaded – it really was in the good shape we thought it was. Wiith several hundred thousand downloads, there were fewer than 25 new bugs found.

Definitely an interesting read…

This article came through Google Reader not long ago, and initially I skipped past it, but I ended up coming back to it, because I think this message in this post epitomizes why so much of our software ends up in the state that it is.

The headline to the article is: “Microsoft ruined databinding when they dropped component support.“

Wow! Let me state that again: “Microsoft ruined databinding when they dropped component support.”

The core issue here is that Microsoft was unable to implement a component tray for components in VS.NET 2005. The model used in VS 2003 was much to buggy to consider for VS 2003 and has committed to looking at solutions for future solutions.

Microsoft ruined databinding when they dropped component support. I could not disagree more strongly with this statement, because I am absolutely positive that databinding still functions completely.

What Microsoft has done is created the need for developers to actually understand whats going on under the covers. Its not as easy to “write” an “application” by simply dragging and dropping things around on a design surface. I have no idea why this is a bad thing.

This type of simplicity can be great for a quick prototype, however, for maintainable, testable, quality software, people have to be willing to write some code instead of dragging/dropping database connections on a design surface.

Its much easier to get an elegant design, as well as a system under test when you have clearly separated concerns that can take advantage of concepts such as Inversion of Control and Dependency Injection. The designer-based databinding model did not allow for this at all.

We should only hope that by removing the component tray for VS.NET 2005 that Microsoft has encouraged developers to understand more about how the technology works, and that the developers are able to take some time to inject thoughts around quality and testing into the code.

Thank you Microsoft, for understanding that less can be more. I only hope that the Control lifecycle is the next thing on the chopping block. The concept of a Control/Page seems so bloated, if you think about the fact that all of this stuff happens so that you can get designed support in VS.NET.

Thanks for the laugh, Gina…

With the latest offering from Google going live (Google Apps for Your Domain), I’ve realized exactly how fast it is to get a business online. I’ve been using GAfYD for quite a while for the email and calendaring here at mattberther.com, but everything was already registered and so on.

My wife has recently decided to start a business, and after going back and forth on some names, we finally decided on one. As with any new business, finances are always a concern, so we were looking for ways that we could do this on the cheap. GAfYD came to mind, especially since I read about the applications going live for enterprise organizations recently.

I checked the website, and they still had a free version available, which offered everything we needed (simple web page, email and calendaring). The website also detailed a partnership with godaddy.com for domain registration. How convenient, I thought… as I typed in the business name to see if it was available. To my shock it was and within 15 minutes, I had completed the following steps to get Lindsay’s new business online:

• Registered and paid for a one year domain name
• Set up a basic introductory web page
• Set up the email addresses for the business (info@ and lindsay@)
• Set up Apple’s Mail.app for my wife to read the emails
• Set up iCal for the calendar integration (if only this was bidirectional)

Absolutely amazing… creating an internet presence for this business took less time than agonizing over whether or not we want to be an LLC or an S-Corp.

I would not have expected it to be this easy, but this is just another thing that Google has absolutely nailed. With this type of service, there is no reason why any business shouldnt have an online presence.

I guess this might be part of Google’s plan for world domination. ;)