Establishing OSS policies in a proprietary software company

My company produces proprietary software but consumes a lot of FOSS libraries and components. Until recently, our standard contracts were of the 'we own everything you do' type. Obviously that created some difficulties for someone like myself given that I'm active in the .NET OSS community. The irony being that if I signed it, I wouldn't be able to support the very OSS libraries I maintain and that the company uses.

We'd like to establish a corporate policy where developers can contribute back and, possibly, create new OSS. I believe this is strategically a good move for several reasons, including:

Read more...

Gulliver's Travels Tests

Like writing lots and lots of fine-grained "unit" tests, mocking out every teeny-weeny interaction between every single object?

This is your application:

Now try to change something.

Read more...

Bubbling exceptions in Nancy up the owin pipeline

In the application I am building I have a requirement to do common exception handling within my OWIN pipeline via custom middleware:

private class CustomExceptionMiddleware : OwinMiddleware
{
    public CustomExceptionMiddleware(OwinMiddleware next) : base(next)
    {}

    public override async Task Invoke(IOwinContext context)
    {
        try
        {
            await Next.Invoke(context);
        }
        catch(Exception ex)
        {
            // Custom stuff here
        }
    }
}

Read more...

Protecting a Self-Hosted Nancy API with Microsoft.Owin.Security.ActiveDirectory

This post is the Nancy version of Vittorio's "Protecting a Self-Hosted API with Microsoft.Owin.Security.ActiveDirectory". Since I'm lazy, I may even be lifting some parts of it verbatim, if you don't mind, Vittorrio ;)

I'm going to skip the intro to Owin etc, if you are reading this, you probably know all about it by now. (Except for you Phillip; Get yout s**t together man!). This tutorial will be using Nancy.MSOwinSecurity that I introduced in the previous post.

What I am going to show you is how you can set up a super simple Nancy HTTP API in a console app and how you can easily secure it with Windows Azure AD with the exact same code you use when programming against IIS Express/full IIS.

Read more...

Uniqueness in a DDD-CQRS-ES application

A while back I blogged that set based based concerns, i.e. duplicates, that when analyzed aren't really a problem. An example of this could a be a duplicate product in a catalogue. The worst that can happen is the user sees the item twice when browsing / searching. Everything still works - the customer can still purchase it, you can still ship it. It's low risk, low impact and life goes on.

There are situations though where global uniqueness is a real requirement, for example, choosing a username during a new user registration process. The problem here is that if a duplicate occurs you may have a security issue, or maybe neither user can log in. It depends on your application of course, but this may be considered high risk.

Read more...