Living in the Tech Avalanche Generation

Well it looks like some members of the DotNet Community have decided to take a nutty very strange and unusual position of biting the hand that feeds, by posting a petition of signatories to a VOTE of NO Confidence in the Entity Framework (soon to be released).

Three questions arise from this:

Do I disagree with their main assertions?

Simply the answer is NO, I do NOT disagree with any of the points made in the assertions on the petition. In fact I believe their contribution, in dispensing opinion based on real world business experience to the development community is enormously valuable and to be considered seriously by developers where it’s appropriate. However I am not so sure about their skills in diplomacy.

Why do I think this is nuts strange?

Microsoft know very well what the position of this collection of people is and the thing that stuck out to me as being “off”, was the title of the exercise and even perhaps the method. Firstly, using a petition denotes a protest more than it does a community warning or announcement and secondly, the title of the petition “Vote of No Confidence”,  I think is less than diplomatic and sounds a little desperate.

What will the Founders think?

I will be interested to note how this plays out with the contribution of the Data Programmability Advisory Council (the fathers of DDD) who oddly enough are not signatories of the petition………

[Factory Method Pattern - Episode 1]

First up let me the explain that this will be the beginning of a series of posts that document a look at the GOF design patterns as implemented in C#. As this is the first episode in the series I am going to take a moment to explain the reason behind it. One thing I know for sure is that design patterns were NOT a big part of learning in University in my day and judging by the graduates that come out of the various institutions these days, that assertion would still appear to hold true.

During a dinner recently with some of my colleagues, I asked the question, “who was taught design patterns at University”? Unsurprisingly the only response I had in the affirmative was something along the lines of, “I remember learning the observer pattern at University”. Clearly the teaching institutions need to rectify this anomalous situation - don’t you think?

If you look inside a lot of small(ish) to medium(ish) development teams (and I see them as a consultant), you might be surprised to know that the idea of using patterns doesn’t get spoken of much in the course of general daily discussions and perhaps you’ve heard the old one liner that:

“You may not have heard about them but you’ve probably been using some without knowing.”

That statement may have some merit, but to a fairly insignificant degree in my opinion. I cant remember a time when I heard someone spout forth, “you should use the decorator pattern” or “it sounds like you need to consider the facade pattern”.

So rather than bemoan the emptiness of this impoverished circumstance, I have decided to try and help change it a little with a series of posts that document the GOF patterns implemented in C#. I will be using the content for training purposes in the near future when the series is complete.

So first up we will look at the creational patterns and specifically we start with the Factory Method Pattern. Rather than include all the content as part of this post itself, I have posted the code and training PowerPoint for download here.

I used to be a VB 4, 5, and 6 hacker back in the day and I will confess that when I first went down the .NET path I chose VB.Net as the language vehicle of learning. Shortly after developing my first .NET application I made the immediate decision to switch languages and decided to use C# as my first choice. The reasons were simple: I found the language more compact, more elegant to read and the resources for .NET in the early days seemed to far more abundant in C#.

From time to time I do choose to implement a component or two using VB.Net; this was simply to stay in touch with the language. Most recently I found this exercise a bit harder to stomach when I had to write some lambda’s in VB 9.0.

Dim dlo As DataLoadOptions = New DataLoadOptions()
dlo.LoadWith(Of Customer)(Function(c As Customer) c.Orders)
db.LoadOptions = dlo

Any more brackets and keywords and I would be ready to pick up my guitar to make a living. This code had me really thinking that I was glad to that my “checking in with VB.Net” was an occasional practice, in fact it got me to thinking that perhaps it was becoming a bit of waste of time and that the practice should be more about checking out a new language paradigm rather than another empirical statically typed language for the same platform. Enter the polyglot programmer debate. And so, the outcome is that I have made the determination that my spare “language time” will go into Ruby and F# having assigned some value to the idea that both functional and dynamic languages should be explored NOW and in some depth. Functional programming has caught my imagination quite a bit of late and I can see some real application in the document management domain where we constantly find ourselves dealing with large recursive trees of data that are immutable.