Castle Windsor Web.config or App.config AppSettings Interface

   1: container.Register(

   2:                Component.For<IApplicationConfiguration>().UsingFactoryMethod(() => new DictionaryAdapterFactory()

   3:                    .GetAdapter<IApplicationConfiguration>(ConfigurationManager.AppSettings)));



Your open source report card


Checkout this out.

Except that it is full of lies! 51% JavaScript to 49% C#

SQL Replication is too confusing

Here is my SQL use case:

Customer has invested in P2P transactional replication in SQL Server 2008R. Their database has many unique and composite key constraints that is likely to cause merge conflicts.


  • Is there a method to automagicly resolve conflicts (ie: merge replication business logic resolvers) when using P2P transactional replication
  • Is Merge publishing a supported way to handle databases with a high potential for conflicts
  • Is Merge publishing deprecated

CSS and JavaScript bundles & Super Simple View Engine

This might be a little bit of a hack but here is how I was able to create a simple asset pipeline when using NancyFx with Super Simple View Engine.

I am using SquishIt but I think you can do the same with Cassette.

Install SquishIt

Install-Package SquishIt -Version 0.9.5

In your Nancy bootstrapper


Here is a link to a gist

In your SSVE page(s)


If you would like a complete sample you can checkout

ASP.NET Identity IUser*Store Implementations for ASP.NET MVC5 OWIN


Here is a gist that I can’t believe does not exist.

Xamarin.Android and the ART of crashing


At this time developers and power users are moving over to ART.

Xamarin.Android does not yet have support for ART.

Side note: Everything compiles, deploys and runs…..until it doesn’t. Xamarin has API support usually the same day something is released. I don’t think the community is looking for ART support the very same day – this is more then binding – but please…help us not fail.

I’d rather not be able to deploy from Xamarin Studio until ART support is complete.

Pretending to be dumb.

Reading data and displaying it on a screen. It’s most of the applications that we build.

Each application has a problem area but it’s often a small part of the application.

Why do we pretend that we don’t have common patterns that can be used to accomplish common tasks?

What value is gained from “driving the design thru tests” of the values of a configuration file?

What type of “emergent object oriented design” do we expect to find in a controller action that responds to a GET method and returns a json result for an article?

Ok, so let’s get to the real question here.

How do we balance architecture with TDD?

The REAL question(s)…..

Are there areas of our application that we don’t need TDD for?

Do we ignore code coverage number for generated code?

When we configure a module/provider/whatever your framework calls it; do we test the configuration values?

It’s to think……….

On bounded context

I’ve been spending a ton of time thinking about DDD, systems, components, SOA, and all that junk. Coming around to the concept of bounded context.

Here are some of the descriptions of bounded context.

Wikipedia says (emphasis mine):

Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.

ThinkDDD says (emphasis mine):

A Bounded Context can be considered as a miniature application, containing it’s own Domain, own code and persistence mechanisms.
Within a Bounded Context, there should be logical consistency, each Bounded Context should be independent of any other Bounded Context.
Communication to and from a Bounded Context is done via a Context Map

Digging into what a Context Map is, Domain-Drive Design Community says (emphasis mine):

Problem: People on other teams won’t be very aware of the Context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other.

Solution: Identify each model in play on the project and define its Bounded Context. This includes the implicit models of nonobject-oriented subsystems. Name each Bounded Context, and make the names part of the Ubiquitous Language.

An article on by Jak Charlton has this little gem in one of the comments:

Apart from the benefit of logical and physical separation, this allows different teams to work on different Contexts, with little impact on each other until a Context Map needs to change.

My take away:

I’m pretty good with a bo staff too….



How to make pair-programming worthless……dumbass


When we work in an environment that offers us the ability to practice agile development its easy to forget that pair-programming is not the norm. We are a small minority and we need to put our best foot forward. Not only to our external customers but our new members.


Not long ago you were just waking up.


In an open work environment a pair is struggling to solve their problem. Neither of them are experienced with the tech stack. One of the pairs is the primary driver while the other is passive.

Sidebar: I’ve always found that the passive person is the one responsible for flow, syntax, review. The passive actor is a very important part of pairing. Knowing when to interject and when to let the driver wonder take a long time to master.

Anyway; back to our story.

After a while, a long while….and a third set of eyes..the team realize the issue is an incorrectly configured route. Simple.

At this point the passive pair speaks up with this amazing insight about a common, I’ve done it a thousands times before, routing is dark magic based on regex problem and calls the driving pair partner “Dumbass”


Alright; there are so many problems with this story but I can only stop shacking my head long enough to focus on one.


Programming is not easy and there is no place for this type of attitude towards another developer. I’ll nitpick your implementation,  your reason, your logic, the value and 1000’s of other things I think you could do better but this has no place in our community.

In all of the places I’ve worked I don’t think I can say I’ve heard one developer “put down” another developer in this way….most of the time we are wittier than this :)



My workplace is nothing like this. I just hope we, as a community, don’t end up here: