Alright, I very rarely use this space for non-technical news items, but this is just plain braindead. It seems the Coast Guard plans on holding gunnery drills on the Great Lakes.

Excerpt from the linked article below:

"The Coast Guard quietly announced plans to create 34 live-fire zones [in Lake Michigan and Lake Erie] -- all at least 5 miles offshore -- in the Federal Register Aug."

Now, the Great Lakes are a huge resource, for fresh water, for recreation, and for commercial shipping.  And, I also know that the Coast Guard does need to practice, and they need to practice using live ammo. 

But Come on!

Can you play somewhere else?

Isn't there another way to do the training the coast guard needs, without endangering boating and safety on the Great Lakes?

Dianne has been the driving force behind this event, so she has much more information.

The short version is that SRT Solutions is working with Bruce Eckel to bring his Thinking in Java training seminar to Ann Arbor from January 22- 26.

Dianne's post
Which has much more about the OpenLevel Java seminar
The Mindview registration page
Where you can sign up

On Tuesday (tomorrow, as I type this), the C# time will be hosting a chat about the VS.NET IDE features related to the C# language.

It's an excellent opportunity to get your voice heard with the team.

Yes, it's true. My abstract was accepted:

Curry Favor with Closures: An introduction to Functional Programming.

One of my readers commented recently on his concerns about Object and Collection Initializers in C#.  He raised some concerns about possible confusion over creating the wrong objects based on incorrectly calling an Add function. 

The reality is that this is a very low-probability occurrence, and relies on you making some very bad decisions. 

Let’s suppose you have an immutable class that supports an Add method to create a new instance by adding two existing values.  Here’s a sample of that class:

class MyImmutableClass
{
    private readonly string myDatum;
    public string MyValue
    { 
        get { return myDatum; }
    }

    public MyImmutableClass(string val)
    {
        myDatum = val;
    }

    public static MyImmutableClass Add(MyImmutableClass s1, MyImmutableClass s2)
    {
        return new MyImmutableClass(s1.MyValue + s2.MyValue);
    }
    public static MyImmutableClass Add(string s1, string s2)
    {
        return new MyImmutableClass(s1 + s2);
    }
}

The misuse would be:

var mic = new MyImmutableClass { “x”, “y”};

The concern would be that it would call Add() and give you one MyImmutableClass, with the wrong contents. 

The goodness is that it does not compile.

Here’s what the compiler says:

error CS1501: No overload for method 'MyImmutableClass' takes '0' arguments
error CS0029: Cannot implicitly convert type 'string' to MyImmutableClass'
error CS0029: Cannot implicitly convert type 'string' to ‘MyImmutableClass'

Yes, the compiler is sure trying to make this work.  It just can’t. 

The astute reader will see that my version of MyImmutableClass doesn’t have a parameterless constructor.  So, let’s add one and try again. The compiler still fails to do the wrong thing. This time you get:

error CS1801: The member initializer does not have an identifiable name

And, if you’re really determined to make it fail, you can try adding this:

public static implicit operator MyImmutableClass(string val)
{
    return new MyImmutableClass(val);
}

Still no luck.  So, I think the compiler does have enough safeguards to prevent errors from getting through.

Dianne Marsh and I are the featured speakers on .NET Rocks this week. 

The official blurb says:

Dianne Marsh, organizing committee member of CodeMash, and Bill Wagner, CodeMash speaker, appeared on the Internet Talk Radio Show “Dot Net Rocks” today.  They talked to hosts Carl Franklin and Richard Campbell about how broadening your horizons with different technology communities will help you become a better software development professional. 

Of course, the reality is that you can learn a lot just by listening to four nerds talking.

I love generics. I like the performance. I like the fact that my more general algorithms are now type-safe. I like the fact that my code is clearer, because the type parameter documents my intended use.

But, there’s one thing I hate about generics. I hate that generics don’t play well with the XML Serializer (or the SOAP Serializer).

This simple example shows my concerns. Suppose I have this simple type:

public struct TimeSeriesPoint
{
    private readonly DateTime timeStamp;

    public DateTime TimeStamp
    {
        get { return timeStamp; }
    }

    private readonly double dataValue;

    public double DataValue
    {
        get { return dataValue; }
    }

    public TimeSeriesPoint(DateTime timeCollected, 
        double dataPoint)
    {
        timeStamp = timeCollected;
        dataValue = dataPoint;
    }
}

I’d like to store them in a collection like this:

public class TimeSeries
{
    private List< TimeSeriesPoint > points = new List< TimeSeriesPoint >();

    public ICollection< TimeSeriesPoint > Points
    {
        get { return points; }
    }
    // More goodness elided.
}

Notice that the list of points is exported as an ICollection<TimeSeriesPoint>, not as a List<TimeSeriesPoint>.  That’s because it gives me more freedom. I can  change the internal collection storage without affecting the interface.  (Suppose I decide I need data binding capability and change to a BindingList<T>). It’s goodness.

Except for this problem:

The XmlSerializer won’t write or read that collection, when typed as an interface.

If I change the property type to List<T>, it works:

public List< TimeSeriesPoint > Points
{
    get { return points; }
}

Note that I don’t need (nor do I want) a setter for the property. That’s fine.  As long as the collection type support Add(), you’re fine. 
But, I don’t like it.  I’d like to keep the property typed as an interface. There is an alternative, but I like it even less.  See, the XML Serializer knows how to serialize an old-fashioned IList. 

But, that results in this ugliness:

public class TimeSeries
{
    private List< TimeSeriesPoint > points = new List< TimeSeriesPoint >();

   [XmlIgnore()]
    public ICollection< TimeSeriesPoint > Points
    {
        get { return points; }
    }

    [XmlArrayItem(typeof (TimeSeriesPoint))]
    public System.Collections.IList SerializablePoints
    {
        get { return points; }
    }
}

There are several bits of badness here.  First, notice that ICollection isn’t being used in the serialized points.  That’s because ICollection just doesn’t have the necessary capabilities to participate in serialization. Therefore, you have to use IList instead of ICollection. But far worse, the public interface of the class is quite a bit more cluttered than I would like.  I’ve got two different properties that allow clients to access the list.  Which to use? (the generic one). Why do both exist? (because the XML Serializer is broken). 

What have you done when you’ve run up against this bug?

Last night, GANG members were treated to an excellent session from Dustin Campbell.

His talk title was "Coding: Get Back to the Basics".

Now, here's the problem:  That title doesn't do the talk justice. It sounds boring, it sounds dry as dust, and it just doesn't make people say "I've got to get me some of that".

Thankfully, nothing could be further from the truth.  Dustin did a fantastic job of making the material entertaining.  And, let's face it, writing better code is going to make you a better developer.  Yes, knowing more about the .NET 3.0, the newest W*F technology, or SOA, or some other new product release is cool, and will have the full support of the corporate marketing engine. That's cool too.  But, when you get down to the bottom of it, you find code.  You find algorithms. You find low-level design decisions.  If you've been to Dustin's talk, you'll find quality.

Dustin talked about cohesion, coupling, and how that affects code quality (you know, did you write that method: "ReadAllRecordsFromTheDataBaseFilterTheListAnd\
PrintTheReportWhileDeletingTheRecordsYouDidntReallyNeedAnyway"

Bad Coder.

Did you refactor that (maybe for days) into differnet methods that each have one simple purpose?

Good Coder.

He also discussed some neat tricks you can do with generics, how delegates lead to lamdbas, and a few nifty tricks you can do with extension methods.

I'm not showing the examples, yet, because he's giving the same talk in Dayton on December 13th.  If you're in the neighborhood, go.

Darrell Hawley gave the presentation for the November Ann Arbor .NET Developers Group on Web Services, WSE, and how that relates to WCF.

He started with an overview of Web Services, and how SOAP, WSDL, and SOA in general, do not adress important issues such as security.  Well, as we try and implement and deploy web services in our daily lives, we find that elements of security, like authentication and authorization become very important.  So, Microsoft began producing WSE (Web Service Enhancements) toolkits.  These include WS-Policy, WS-Security, and WS-SecureConversation.

While these enhancements have all been included in WCF, there is still reason to look at WSE. If you've got any web services already deployed, and want to quickly address these issues (while you wait for your company to decide when to deploy WCF and .NET 3.0), this may be the solution. 

Darrell gave a good overview of the difference between direct and brokered authentication, and the tools available in WSE to test the brokered scenarios.

He showed a number of different user authentication protocols available for WSE:  clear text, x509 certificates, encrypted username and password, and a completely secure conversation. 

While WCF certainly deprecates a lot of what was delivered in the various WSE toolkits, they are still worth investigating. Everything you learn using WSE will apply (although not without some minor modifications) to the WCF world. 

Thanks to Darrell for a good presentation. Especially given the incredibly short notice.

First of all, if you ever have the chance to hear Scott Collins give a technical talk (or any other talk, for that matter), you have to hear him. His wealth of knowledge and his speaking style make difficult problems approachable.

His discussion was on the development of computer languages, and the future of programming languages. He started with the definitions of the problem domains, machine languages, and you (the programmer). These three areas have quite a bit of distance between them. You bridge these three areas using computer languages, libraries, and your programs. 

What you can learn from that is that all languages (even general purpose languages) have a grammar and contain first-class types that shorten the distance between its chosen problem domain, and you, and the machine.

You can see this in some historical examples:

• FORTRAN was written for mathematics.
• PERL was written for sys admin tasks.
• LISP was written to explain how computers work.

By picking the language that is ‘closest’ to your problem domain you do gain some advantage. But, you can build anything in any language.

However, some languages are closer to the problem domain (see Mathematica) than others. That is (at least in part) because Mathematica is more like a domain language than a general purpose language.

When you build large programs you are building your own domain language. Think about this: Your team doesn’t ask questions about how to fashion loops, or how to add numbers. Rather, they are asking questions about how to use the code and libraries your team has already implemented.  Language features help you create these domain languages.

This is important, because you are a language designer. It's not a general purpose language, rather, it's the language for your chosen domain. That might be a product suite, it might be a framework, or it might be some assemblies used in a set of internal tools.

One of his key points is that you can learn a great deal about software development by expeanding your horizons, and looking for, and at, other languages and design metaphors. If you really want to grow, stop thinking of anything as ‘the answer’, and think of it as ‘one answer’.

There are some real differences in computer languages that help you build your own domain languages:

• Can I implement type as good as built-in?
• Can I treat code like any other value?
• Can I control object lifetime?
• Can I build new types at runtime?
• How much type knowledge at runtime?
• Can I build new types as runtime?
• Is it up to the task?
• How smoothly can I integrate my code into the language vocabulary?

There is also critical mass:  Is it in use in the wild?  (For example, Latin is cool, but very few people use it)

He added a great satirical look at many of our current languages.  Why was it written?  Who used it?  What did they do it for? That's important, because your users want a language too. (For example, emacs is a language: For editing.)  Give it to them.

So, here’s some conclusions:

• New languages will keep coming.
• Old languages will continue to change.
• The very things you like about your language are the very things that make someone else hate it.
• Most arguments are about ridiculously small points.

On design:

• Choosing the right language is less important than building the right language for your problem domain.
• Apply the right parts of the team to the right parts of the language.
• Building your design as a language helps you solve problems more elegantly.
• Your program is a part of the users language. Give it to them.

So, we are all language designers. For our teams, for our users, and for other people.

The question period was hilarious. But, I was laughing too hard to take good notes.  I will say it's the only time I've heard the words "pupperoni" and "Objective C" in the same sentence.