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.

The Eclipse Project is home to a quite reasonable amount of sub projects, the list keeps growing every year, so to help the end-user the Eclipse Foundation arranges a simultaneous yearly release of Eclipse and all sub projects. Ganymede is the 2008 release, following Europa in 2007 and Callisto in 2006, and it contains Eclipse’s latest version (3.4).

Eclipse Ganymede

Some time ago I wrote about GetHashCode method and now Paulo Morgado has also faced some “hash related” issues to deal with (also in Portuguese). Again, the reminder should be not rely heavily on GetHashCode.

Recently I ran into some unexpected, and rather strange, issues on an application server using the Enterprise Library 2.0 Cache Application Block. Apparently there were occurring some strange collisions while retrieving the data from CacheData (the table where the cached data is stored) where the same cache key was having multiple entries, something the Dictionary container where the data is stored isn’t too happy about. The guys at Patterns and Practices, for performance issues, don’t use the cache key as a primary key for that table, but a much more efficient and more easily “indexable” integer, which, in this case, is being calculated using the GetHashCode of the cache key. Usually the GetHashCodeimplementation isn’t a fully blown hash algorithm (unlike the more robust MD5 or SHA) so I allways doubted of the uniqueness, particularly in this case where the application server was moved from a 32 bit to a 64 bit architecture, nothing a quick trip do the good old MSDN wouldn’t confirm:

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.

All those Portuguese speaking interested in Scrum followers now have a place to share thoughts, experiences and everything else Scrum related, yet in a very early stage.

Scrum em Português

James Carr has compiled a pretty little list of Test Driven Development Anti-Patterns and posted it some time ago in his blog. I have to admit I’ve done some of them once or twice.

TDD Anti-Patterns [via ISerializable]

Technorati Tags: tdd, test driven development, unit testing

InfoQ has an interesting article gathering several thoughts and rants regarding the usefulness of Maven as a build tool, despite having used Maven with some success I must agree with some of the referred problems.
Maven has a declarative approach to a project, rather than the procedural approach of Ant, which makes it easier to move around from one project to another, something that doesn’t happen in Ant; and not to forget the dependency management, which is indeed is a killer feature (although I admit I’ve never tried Ivy). But the documentation still is poor and sparse and it requires the team and build process do adjust to the Maven philosophy and structure.

Debate: Is Maven the right tool for builds?

Technorati Tags: maven, ant, ivy, build

Jelle Druyts has released a neat little tool for Visual Studio that allows to easily design and visualize the configuration for a .Net solution, without messing around with ConfigurationSection and ConfigurationElement source files, which is quite handy when things become a bit more complicated. It’s still is in an early stage, but it looks rather promising.

Configuration Section Designer

Hey, now I can debug the .Net framework or, in other words, now I can’t blame the framework every time I have a problem.

.NET Framework Library Source Code now available - ScottGu’s Blog