Spam really gets everywhere, the screenshot on the right is from the Tags box in the front page of DotNetKicks, a Digg-like online community dedicated to .Net programmers.

Technorati Tags: dotnetkicks,spam

If someone’s trying to go beyond the “get an implementation instance for a given interface” examples found in most of the tutorials then proper dependency injection will be the way to go. This means returning the proper instance for the given interface, but also properly the objects that instance needs, and also the objects needed by those objects, and this could go on forever. Unity can do this almost automatically, but to do so it may need hints on how objects should be created, specially to choose the right constructor when multiple are available (by default will choose the fatest of them all).

One of the ways this problem is solved is using an attribute that indicates which constructor should be used (the same is valid for either properties and method calls), as shown below:

public class MyClass

{

  public MyObject(SomeOtherClass myObjA)

  {

    ...

  }

  [InjectionConstructor]

  public MyObject(MyDependentClass myObjB)

  {

    ...

  }

} 

The problem is: Unity, and all other dependency injection containers, want to solve a simple issue: reduce coupling between modules, classes, etc. That’s achieved by removing the dependency to the proper implementation, you only have to know the contract to use (the interface) and the dependency injection container will return the proper implementation, whatever that may be. But, by doing this we’re adding another dependency: to the dependency injection container implementation (like Unity), and while this is reasonable for the class that needs to use the container is not so reasonable for the classes the container will use.

Take the code sample above: MyClass is just a plain class, by adding the InjectionConstructor attribute we’re adding a needless dependency because that class will never use Unity, it will be used by Unity. For me using this can be a design flaw that goes against what dependency injection is supposed to achieve. A safer, but more time consuming, way to get around this is to explicitly configure those dependencies (either in design time or run time) instead of letting Unity try to figure them out.

Technorati Tags: microsoft,enterprise library,dependency injection,unity,ioc

Oh, and it also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.
James Shore: The Decline and Fall of Agile
Doing Daily Scrums, Sprint Plannings and all those Agile related “ceremonies” won’t improve the process in any way, without a proper background (good team communication, choosing the right best practices, etc.) those “ceremonies” will only help to point the team’s flaws.

“WCF started with a clear bias towards SOAP, WS-* protocols, and other heavyweight standards that were being popularized at the time but had not been ubiquitously adopted.
(…)
I didn’t believe though that you could force the world to use a single approach for building web services.”
Nicholas Allen
Windows Communication Foundation has to be one of the most interesting pieces of the .Net universe released in recent years, mostly for being a huge improvement over the previous web service model in .Net. So when one the minds behind WCF writes about the framework’s future it’s certainly worth a closer look.

The Future of WCF, Part 1
The Future of WCF, Part 2

Hero Pattern

One popular solution to the operation issue is a Hero who can and often will manage the bulk of the operational needs. The Hero Pattern can work in a small environment when one individual has the talent and capacity to understand an entire system, including the many nuances required to keep it functioning properly. For a large system of many components this approach does not scale, yet it is one of the most frequently-deployed solutions.

The Hero often understands service dependencies when no formal specification exists, remembers how to toggle features on and off or knows about systems everyone else has forgotten. The Hero is crucial but the Hero should not be an individual.

I believe the best solution to the Hero Pattern is automation. However, it also helps simply to rotate individuals from team to team if the organization has the capacity. In banking, it’s sometimes mandatory to take vacation so any “I’ll just run this from my workstation” activities can be brought to light.

Scalability Worst Practices [InfoQ]

Lately I’ve faced this pattern, or maybe anti-pattern, more times than I ‘d like to, either for lingering around a “hero” or even being one. My experience tells me that Agile practices like Scrum, although never addressing it explicitly, when properly implemented can minimize this problem.

Eclipse Ganymede

Remarks

The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode.

This basically means you shouldn’t trust GetHashCode, because the result for a given string can, and surely will, be different depending where you are calculating it, namely between 32 and 64 bit architectures. The main lesson to be learnt here is GetHashCode, either for String or any other type, should only be used for disambiguation of entities in runtime.

Scrum em Português