Selling the house

https://my.matterport.com/show/?m=6SH1cnAxWLr&brand=0

The Counted

http://www.theguardian.com/us-news/ng-interactive/2015/jun/01/the-counted-police-killings-us-database#

Why Ember

http://blog.yodersolutions.com/why-i-recommend-emberjs-over-angularjs/

Ember.js sucess story

http://www.talentbuddy.co/blog/building-with-ember-js-at-groupon/

Asynchronous Repository Pattern

I've been thinking a bit about network and other I/O latency problems and the traditional repository pattern. Started toying with the idea that a repository facade could explicitly expose a "promise-like" interface like the following.

public interface IRepository<T, in U> where T: class, new()
                                          where U: struct
    {
        Task<T> GetById(U id);
        Task<bool> Save(T entity);
        Task<bool> Remove(T entity);
        Task<IEnumerable<T>> GetAll();
    }

Where T is the DTO and U is the underlying identifier type (int, Guid etc.)

This is all essentially client-side whereas the client is communicating with a resource (and perhaps resource is a better name than repository). So for instance, if I was communicating with a ReSTful service - my resource (or implementation of this particular pattern) could look something like the following.(This is currently implemented using RestSharp client using the ServiceStack.Text serializers)

public class RestfulClient<T, U> : RestClient, IRepository<T, U> where T: class, new()
                                                                     where U: struct
    {
        private readonly string _resource;
        private readonly ServiceStackJsonDeserializer deserializer;
        private readonly ServiceStackJsonSerializer serializer;
        private const string requestString = "application/json";
        private const DataFormat requestFormat = DataFormat.Json;

        public RestfulClient(string baseUrl, string resource)
            : base(baseUrl)
        {
            this._resource = resource;
            this.deserializer = new ServiceStackJsonDeserializer();
            this.serializer = new ServiceStackJsonSerializer();
            ServiceStack.Text.JsConfig.EmitCamelCaseNames = true;
            this.AddHandler(requestString, new ServiceStackJsonDeserializer());
        }

        private string UrlWithId(U id)
        {
            return string.Concat(this._resource, "/", id);
        }

        private RestRequest FormatRequest(string resource, Method method, T entity)
        {
            var req = new RestRequest(resource, method);
            if (entity != null)
            {
                req.RequestFormat = requestFormat;
                req.JsonSerializer = this.serializer;
                req.AddParameter(requestString, this.serializer.Serialize(entity), ParameterType.RequestBody);
            };
            return req;
        }

        public Task<T> GetById(U id)
        {
            var t = Task.Factory.StartNew(() => 
                this.deserializer.Deserialize<T>(this.ExecuteGetTaskAsync(FormatRequest(UrlWithId(id), Method.GET, null)).Result), 
                CancellationToken.None);
            return t;
        }

        public Task<bool> Save(T entity)
        {
            var t = Task.Factory.StartNew(() => 
                this.Execute(FormatRequest(this._resource, Method.POST, entity)).ResponseStatus == ResponseStatus.Completed, 
                CancellationToken.None);
            return t;
        }

        public Task<bool> Remove(T entity)
        {
            var t = Task.Factory.StartNew(() => 
                this.Execute(FormatRequest(this._resource, Method.DELETE, entity)).ResponseStatus == ResponseStatus.Completed, 
                CancellationToken.None);
            return t;
        }

        public Task<IEnumerable<T>> GetAll()
        {
            var t = Task.Factory.StartNew(() =>
                this.deserializer.Deserialize<IEnumerable<T>>(this.ExecuteTaskAsync(FormatRequest(this._resource, Method.GET, null)).Result), 
                CancellationToken.None);
            return t;
        }
    }

Instantiating the implementation could be as simple as:

var rc = new RestfulClient<ToDo, int>("http://localhost:53327", "api/v1/todos");

Consuming looks like:

rc.GetById(id).ContinueWith((todo)=> Console.Write(todo.Result.Title));

The nice thing is that the consuming client gets all the benefit of .ContinueWith (etc.) I'm not sure if I'm chasing dragons at this point - but I'm mulling it over...thoughts?

Adhering to the DRY Principal in Javascript/Knockout

One of the things that honestly "hurt my feelings" when developing an HTML5 replacement application awhile back - was that the ViewModel needed to be declared in multiple places. Once in the service and again in the client. Of course, all the demonstrations during tech-week seemed to gloss over this with very simplistic applications. Required reading - Pragmatic Principles
Now, there may be ample reason to want to do this -> what I'm enacting upon in the client may require a subset (possibly?) but I would contend that it should probably be a different service call. Don't transfer bytes that you don't need! So I created a static class helper to be used within a Razor template - and proceeded to forgot all about it. 
A colleague from another department heard about/asked me about it and I rediscovered it. Enjoy. As always YMMV. If you improve on it - share it. I'll laud you copiously.

The helper:

public static class HtmlHelper
    {
        private static string JavaScriptify(string s)
        {
            return string.Join(".", s.Split('.').Select(x => x[0].ToString().ToLower() + x.Substring(1, x.Length - 1)));
        }

        public static IHtmlString KnockoutFrom<T>(this HtmlHelper<T> html, T obj)
        {
            var serializer = new JsonSerializer
                                 {
                                     ContractResolver = new CamelCasePropertyNamesContractResolver()
                                 };

            var sb = new StringBuilder();
            sb.Append("(function() {");

            var json = JObject.FromObject(obj, serializer);

            sb.Append("var vm = ko.mapping.fromJS(" + json + ");");

            var type = obj.GetType();

            var ns = JavaScriptify(type.Namespace);
            sb.Append("namespace('" + ns + "');");
            sb.Append(ns + "." + JavaScriptify(type.Name) + " = vm;");

            sb.Append("})();");

            return new HtmlString(sb.ToString());
        }
    }

The template:

@Html.KnockoutFrom(Model)

WSDL service returning DataSet? Seriously?

Just got a 'last-minute' TODO - have to establish another interface for state agency. Like any good developer - I grab the WSDL and 'prop-up' a test service. Imagine my surprise when I see the defined method results as DataSet. Yup. Can be anything - based on nature of the "select" - egads. 

The ONLY reasonable  - and its by NO MEANS reasonable - "theory" that *might* explain this 'design' decision is that auto-generated proxies won't 'break'. (Yea. It's a lame excuse and kinda defeats the purpose of contract-first development) Besides, auto-generated proxies are for the faint-hearted (HTTP/XML for me).

How to generically 'mock' a dataset? Grab NBuilder from NuGet and add to your project. Then add a POCO representation of the fields you wish to return. Then call this:

private static DataSet CreateDataSet<T>(int numberOfRows = 1)
        {
            var datatable = new DataTable(typeof (T).Name);
            typeof (T).GetProperties().ToList().ForEach(
                x => datatable.Columns.Add(x.Name));
            Builder<T>.CreateListOfSize(numberOfRows).Build()
                                    .ToList().ForEach(
                                        x => datatable.LoadDataRow(x.GetType().GetProperties().Select(
                                            y => y.GetValue(x, null)).ToArray(), true));
            var dataset = new DataSet();
            dataset.Tables.Add(datatable);
            return dataset;
        }

soapUI tests against WSDL methods work - now 'back-to-work'!