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'!

More Hibernation Fun :: Dialect does not support variable limits.

Had a sad-panda moment when I went to Linq to NHibernate with the following (rather straight-forward) syntax.

...

 var e = r.Where(w => w.Name.Contains(searchBy)).Select(c => c).Take(5).ToList();  

...
I bombed out on a simple test - with the exception being "Dialect does not support variable limits." Rather broad base of Google hits on this one...

Seemed like something wrong with the underlying dialect - so I needed to override; something like this:

 public class FixedMsSqlDialect : NHibernate.Dialect.MsSql2005Dialect  
   {  
     public override bool SupportsVariableLimit  
     {  
       get  
       {  
         return true; //because SQL Server DOES support TOP selects  
       }  
     }  
   }  

...


What was unclear was "where" does that go? Quick breeze through source revealed that it was 'set' right after the IPersistenceConfigurer was instantiated - so static method to use for my fluent configuration.
... 

 private static IPersistenceConfigurer PersistenceConfigurer(string connection)  
     {  
       var provider = MsSqlConfiguration.MsSql2005.ConnectionString(connection);  
       provider.Dialect<FixedMsSqlDialect>();  
       return provider;  
     }  

...

Now based on connection string - I can inject the "home-grown" default behavior from my GetConfiguration method.

...

 public FluentHelper(string connectionKey, bool autoConfig = false)  
       : this(  
         () =>  
         Fluently.Configure()  
         .Database(GetConfigurationOption(connectionKey))  
         .Mappings(m => m.FluentMappings.AddFromAssembly(Assembly.GetExecutingAssembly()))  
           .ExposeConfiguration((c =>  
           {  
             if (autoConfig)  
             {  
               BuildSchema(c);  
             }  
           })).BuildSessionFactory())  
     {  
     }  

 private static IPersistenceConfigurer GetConfigurationOption(string connectionKey)  
     {  
       string connection = ConfigurationManager.ConnectionStrings[connectionKey].ConnectionString;  
       switch (ConfigurationManager.ConnectionStrings[connectionKey].ProviderName)  
       {  
 ....omitted for brevity  
           default:  
             return PersistenceConfigurer(connection);  
       }  
 }  

Hurray - Linq Take() actually works now.