Slides from my DogFoodConf talk: Xamarin.Forms

A few weeks ago I was able to speak at the Dog Food Conf about the last few months we’ve spent developing an iOS app using Xamarin.Forms.


Lessons Learned: 4 Months of Xamarin.Forms from Eric Polerecky


It was a small room but made for great conversation. It was nice to use the slides as a starting point and basically going “off script” for the whole hour. Thanks to everyone that attended.


Here are some of the key points that I tried to make during my talk:

  • You can make good looking Xamarin.Forms apps; it’s hard but it can be done.
  • Custom Renderers rock.
  • Coding .NET on a Mac is getting nicer and nicer with Xamarin Studio and Mono Updates.
  • Azure is super amazing!
  • Xamarin.Forms ALL THE THINGS!

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….