HTTP 2 is finally done

Finally the specs for HTTP 2 were finalized yesterday and will be integrated into Chrome 40 and a new FireFox coming over the next 10-12 weeks.  Here are some of the things to expect.

http://thenextweb.com/insider/2015/02/18/http2-first-major-update-http-sixteen-years-finalized/

https://www.mnot.net/blog/2014/01/30/http2_expectations

http://gizmodo.com/what-is-http-2-1686537168

How not to do Dependency Injection

Dependency Injection (DI) is not a new concept and has been discussed, blogged, and published many times.  There are a huge number of books out there on the subject.  I've seen many usages and implementations of it used by various clients I've consulted for. 

Like the author of the blog post I refer to below, one of the most common and mis-used, abuses of, and antipatterns I've seen is the wrapping of the DI model in a static container.








I recently found an excellent article that explains in great detail why this is a bad idea and a big anti-pattern - http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container.

Hopefully, this will help improve your understanding of what DI is and how it should not be used.

References to missing Types or Methods in referenced DLL

Ever wonder what happens if you have a binary reference to an external .dll and decide not to recompile the application or library that references/depends on it? You can get some strange errors depending on the changes that have been made. Ever experienced a BadImageFormatException, ExecutionEngineException, TypeLoadException, or MissingMethodException?

Firstly, the manifest file for the dependent app/library is not updated pointing to the new version. This can cause mismatched assembly version errors (BadImageFormatException).

Here are the results from some tests with the removal of types and/or methods on a referenced assembly (hereinafter referred to as ‘Bad Assembly’). All tests were done with x86 Console App/Library in separate solutions with a “static hardcoded” path reference to Bad Assembly (x64 shouldn’t matter):

1. Results were always the same for Release/Debug builds.
2. The bad assembly was always successfully loaded. ‘fuslogvw’ (.NET Assembly Load Viewer) confirmed this.
3. Setting the reference to Bad Assembly as “Specific Version” (using v1.0.0.0) and changing the version on Bad Assembly to v1.1.0.0 had no effect. However, I didn’t try defining Bad Assembly in the “assemblies” section of the app.config. It is possible that would have given a different result.
4. References to a missing Type OR calls to a missing Method from Bad Assembly in "static void Main()" resulted in a "System.ExecutionEngineException" (fatal error as shown below). This exception cannot be caught by any means: Assembly events, AppDomain events, try/catch block in "static void Main()". I confirmed this thru WinDbg. This is because it is the first method that the EE (CLR Execution Engine) tells the JIT to compile. Since JIT happens on a method-by-method basis and "static void Main()" is the entry point for the app, there is no place “upstream” where an exception can be caught. The error in the Event Viewer is completely cryptic and provides no indication what went wrong.
5. If the reference to a missing Type OR calls to a missing Method from Bad Assembly occurred “downstream” of "static void Main()" AND there WAS NOT exception handling upstream, OR there WAS exception handling upstream but the exception was rethrown so that is was never caught again, then results were same as #4.  (i.e. unhandled exception)
6. If the reference to a missing Type OR calls to a missing Method from Bad Assembly occurred “downstream” of "static void Main()" AND there WAS exception handling upstream, then the exception was caught as either a "System.TypeLoadException" or "System.MissingMethodException" respectively.  The exceptions were thrown from the JIT as the Type or Method was accessed.

HTH

Why you should use ReadOnlyCollection<T>

Many people believe that you should be using List<T> to return collections from a public API.  However, there are several reasons not to do so; instead return a ReadOnlyCollection<T>. The are several benefits of using a ReadOnlyCollection<T>:

1. The *collection itself* cannot be modified – not the items within it. i.e. you cannot add, remove, or replace any item in the collection. So, it keeps the collection itself intact – not the values of the items within it. To protect the items in it, you’d probably have to have private “setters” on any properties for the reference object in the collection – which is generally recommended. However, items that are declared as [DataMember] must have both public getters and setters. So if you are in that case, you can’t do the private setter, but you can still use the ReadOnlyCollection<T>. Using this as a Design paradigm can prevent subtle bugs from popping up.
2. Performance: The List<T> class is essentially a wrapper around a strongly-typed array. Since arrays are immutable (cannot be re-sized), any modifications made to a List<T> must create a complete copy of List<T> and add the new item. The initial capacity for a List<T> is ‘4’ unless specified thru the overloaded constructor. Obviously this can be very bad for memory and performance. Don’t forget that not only the items directly within the List<T> are copied – but every value and object with the entire object graph for that reference type – this could easily contain other references type, other collections, etc. This is why it is best practice to create/initialize a List<T> instance with the overloaded constructor which takes an ‘int’ denoting the size of the List to be created. This can almost always be done since you are usually iterating on a “known” size value at runtime. For example, creating a List<T> of objects from a "Repository or DataService" method usually iterates/reads from a IDataReader object which has a property of ‘RecordsAffected’. If you are going to be putting an item in the List<T> based on the number of times the IDataReader is Read – while(reader.Read()) you can easily create the list like so (and it is preferable to do it like this):

    if (reader != null && reader.RecordsAffected > 0)
    {
        List<Foo> someList = new List<Foo>(reader.RecordsAffected);
        while (reader.Read())
        {
            someList.Add(...);
            ...
        }
    }

Just as a side note…every time that a List<T> needs to grow in size, the size is *doubled*. So, if you happen to add just one more item to a List<T> that wasn’t constructed with a pre-determined size, and the List<T> expands to accommodate the new item, there will be a whole lot of unused space at the end of the List<T> even though there aren’t any items in it – bad for memory and performance.

Don't implement GetHashCode() on mutable fields/properties

CodeProject You shouldn't ever implement GetHashCode on mutable properties (properties that could be changed by someone) - i.e. non-private setters.   I've seen this done in several places and it results in very difficult to find bugs.

Here's why - imagine this scenario:

1. You put an instance of your object in a collection which uses GetHashCode() "under the covers" or directly (Hashtable).
2. Then someone changes the value of the field/property that you've used in your GetHashCode() implementation.

Guess what...your object is permanently lost in the collection since the collection uses GetHashCode() to find it! You've effectively changed the hashcode value from what was originally placed in the collection. Probably not what you wanted.