pashov.net/code|January 2015

Monthly Archives: January 2015

Others

Hidden game in your Chrome

Published by:

For most of you that use Chrome this screen is maybe well known
google game

 

If you hit space, that turns into a game – the dinosaur starts running and you have to jump over cactus. It is pretty basic but also very addictive. You can even catch yourself pulling the internet cable out just to play around with the dinosaur 🙂

google game 1

javaScript

Angular directive for Twitter Bootstrap with datepicker extended to select hour

Published by:

If you find the native angular directives for twitter bootstrap neat to use but miss the functionality to select an hour from the datepicker (the original version get as granular as days), you are not alone. I know there are a bunch of other other datepicker directives out there but i am kind of used to this one and that’s why i extended it to use hours also. Note – if you include it in your project, beware to change the name to something other than “ui-bootstrap-tpls.js” because if you update packages it will be overwritten by the new one.

Clone it under: https://ivopashov@bitbucket.org/ivopashov/bootstrap-tpls-with-added-hour-to-the-datepicker.git

Coding javaScript

angular controller inheritance minification issue

Published by:

In Angular we use $injector service to require dependencies in any point of time. We can use it to create a hierarchy of controller inheritance very easily – consider the following example:

var ParentController=function($scope){
    $scope.triangle={
        a:3,
        b:4,
        c:5
    };
}

app.controller('ChildController',['$scope','$injector',function($scope, $injector){
    $injector.invoke(ParentController,this,{
        $scope:$scope
    })
}])

What we basically do is declare a regular js function (ParentController), inherit from it through the invoke method of $injector service and pass any dependencies in the curly braces. Note that all dependencies in the parent must be resolved in the child and then passed along in the $injector.invoke. So now we have $scope.triangle inherited in the ChildController.

The above example works great until we don’t minify the js files when things get ugly and $injector starts throwing errors in the console. We need a little angular specific hack to fix that:

instead of :

var ParentController=function($scope){
    $scope.triangle={
        a:3,
        b:4,
        c:5
    };
}

we need to do:

var ParentController=['$scope', function($scope){
    $scope.triangle={
        a:3,
        b:4,
        c:5
    };
}]

The reason is that angular resolves dependencies ($scope in the example) by their names and when minified, names become unrecognizable to angular. A workaround of that is to annotate the functions with the names of the dependencies as strings, which will not get minified.

.NET

Variance and Contravariance in C# generics

Published by:

No, it is not a mistake – you didn’t landed on a math blog although the terms in the title sound more math than IT. However, variance and contravariance are terms deeply rooted in C# since version 4.

The simplest way to think about those is that variance preserves the direction (from less derived object to more derived on – i.e. object->string) while contravariance reverses it. Variance is somewhat intuitive as it coincides with assignment compatibility. It is natural to make something as Object a = “test string”.

If you examine IEnumerable interface in the .net dlls, you will find out that it’s signature is IEnumerable (we denote variant generics with out and contravariant with in) and it means that the interface works with generic types that behave variant. So that if we have SomeMethod(IEnumerable items) we can pass it parameter as IEnumerable items and that’s very logical because if we can enumerate and manipulate the less derived type it is safe to go through and manipulate the more derived type.

I personally find contravariance way more challenging. I wont try to explain it but rather show an example which is very self-explanatory:

 public class Animal
    {
        public void SayYourType()
        {
            Console.WriteLine(this.GetType().Name);
        }
    }


    public class Human : Animal
    {

    }

So far so good – we have a class Human to derive from Animal. They do nothing more than say their types so that we can keep things simple

    public interface ICallType<in T>
    {
        void CallType(T x);
    }

    public class AnimalTypeCaller : ICallType<Animal>
    {
        public void CallType(Animal x)
        {
            x.SayYourType();
        }
    }

    public class TypeDiscoverer<T>
    {
        T Item;
        ICallType<T> TypeCaller;

        public TypeDiscoverer(T item, ICallType<T> typeCaller)
        {
            Item = item;
            TypeCaller = typeCaller;
        }

        public void DiscoverType()
        {
            TypeCaller.CallType(Item);
        }
    }

lets have an interface that works with generics and exposes only one method that is able to call the type (Note the in keyword). Let’s also have a concrete implementation – the AnimalTypeCaller that inherits from ICallType and works with objects of type Animal. Finally we have a class that works with generics, takes a generic item argument and ICallType interface and is able to call the type of the underlying item using concrete implementation of the interface ICallType.

The magic lies in the next two lines though:

var humanTypeDiscoverer = new TypeDiscoverer<Human>(human,new AnimalTypeCaller());
humanTypeDiscoverer.DiscoverType();

we declare humanTypeDiscoverer that works with Human object but pass it AnimalTypeCaller, so we reverse the direction- > we handle more derived types(Human) with handler that works with less derived types (Animal). Even the intellisense will hint you that it expects ICallType of type Human but because of the contravariance and the in keyword, the above code is perfectly legal and works as expected and we can treat Humans with AnimalTypeCaller 🙂

This pattern is used with handlers and most notably comparers. IComparer is implemented this way. And if you think about it, it makes sense – it is ok to compare integers with an object comparer, but comparing objects with int comparer would be strange.

I suggest you to make yourself a little proof of concept if you still have difficulty to grasp the idea. I spent a lot of time reading on the topic but it took me only 15 minutes to make my own example. 10 lines of code say much more than pages of text. And are more interesting to read 🙂

.NET

Change MVC project name in VS

Published by:

Changing the MVC project name in VS is not a standard procedure as hitting F2 and typing the new name. Here are the steps to change the name:

– Click on the project name, hit F2 and rename the project

Go to project properties (right click the project and select Properties). Then under the Application tab change the Assembly name and the Default Namespace

– Go to any class in the project and select the namespace (that should be the old project’s name). Right-click it and select -> Refactor -> Rename and type in the new name. That should change the namespace for the project.

– Change the project folder’s name

Open the .sln with a text editor and manually change the project’s name

– Finally (that’s tricky) go to views folder, locate the web.config there and edit the namespace in the file