Slides from my DogFoodConf talk: Xamarin.Forms
October 12, 2014
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
March 10, 2014
Your open source report card
March 4, 2014
Checkout this out. http://osrc.dfm.io/detroitpro
SQL Replication is too confusing
March 3, 2014
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
March 3, 2014
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-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 https://github.com/detroitpro/monafx/tree/develop
ASP.NET Identity IUser*Store Implementations for ASP.NET MVC5 OWIN
February 11, 2014
Here is a gist that I can’t believe does not exist.
Xamarin.Android and the ART of crashing
February 10, 2014
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.
February 7, 2014
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
February 6, 2014
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 devlicio.us 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….
February 6, 2014