By Michael Flanakin @ 7:31 PM :: 3708 Views :: .NET, Development, Technology :: Digg it!

Silverlight has been Microsoft's golden child since v2 was released last year. The impact within the community has been astounding. Some demand the use of Silverlight without actually recognizing when and where the technology makes sense and others scoff at Silverlight either in favor of Flash or as a technology as "useless" as Flash. I roll my eyes every time I hear any of these three opinions... and they happen a lot. Flash went thru the hype cycle years ago and now it's Silverlight's turn. What I find amusing is that the hype seems to be much more powerful with Silverlight than it ever was with Flash. All we can do is fight the good fight.

Not every rich experience needs to be Silverlight. JavaScript frameworks are making life as a web developer easier and easier, so I'd recommend that always be the default choice. Unfortunately, most developers still find the pain of JavaScript development too great. While I'm a big fan of JavaScript, it is far from a perfect language and is severely lacking when it comes to development and debugging tools. Flash and Silverlight both simplify things with better tools and a single-platform vision that tremendously improves cross-browser development, but Flash is still lacking the one thing that makes Silverlight a no-brainer: XAML, backed by real programming languages.

XAML is immensely powerful and will continue to grow as more and more WPF features make it into Silverlight. XAML takes a new way of thinking, but it's well worth it for the simplicity and ease of development you get. But, more important than XAML is the fact that you have any .NET language you want and, with the inclusion of the Dynamic Language Runtime (DLR), there's virtually no reason not to use Silverlight. The one and only benefit Flash has is more mature tools. This is very important, but it is only a matter of time. Microsoft has both the will and the ability to overcome the current Flash tooling. The days of Flash are severely numbered. A look at the job market only confirms this. I just wish I had some of the same numbers from when Flash was initially released to compare the difference.

I truly believe that, if you're a web developer using any language, you need to take the time to understand how Silverlight can benefit you. Yes, HTML5 is coming, but the power and flexibility of environments like Silverlight will quickly surpass anything the W3C will ever be able to come out with a specification for. Heck, in less than 2 years, we've seen 3 releases of Silverlight and a beta version for the fourth, with speculations that Silverlight 4 is likely to release at Mix 2010, making it 4 full releases in 2.5 years. I'd like to see any one W3C spec ratified and fully released in all major browsers in such a timeframe. Such a feat is completely unheard of. Nevertheless, don't let me blab on about it. The numbers speak for themselves...

By Michael Flanakin @ 3:31 PM :: 4984 Views :: .NET, Development :: Digg it!

One thing I love about C# is that I'm constantly learning new ways to simplify and write less code. Perhaps PowerShell has a lot to do with this, but I put a lot of value in the power of the one-liner. With that, I wanted to share something small I recently discovered.

There are three main ways to initialize your read-only class properties: field initializer, constructor, or property accessor. The first thing you need to consider when determining the right approach is whether you should use a readonly or get-only variable. A readonly variable has two primary benefits: guaranteeing the value won't change and better ensuring thread-safety. I'm not going to go into either of these, but I will say, if you can make your variable readonly, do it. The main reason not to make your variable readonly is if its initialization is resource-heavy and the variable isn't always crucial. There are other things to consider, but I want to focus more on the implementation of this code rather than the reasoning behind deciding on a good approach.

Back in the .NET 2 days, I used the following approach to lazy loading.

private PersonCollection _people;
public PersonCollection People
{
    get
    {
        if (this._people == null)
        {
            this._people = new PersonCollection();
        }
        return this._people;
    }
}

One way to achieve a one-liner would be to use an inline if statement.

private PersonCollection _people;
public PersonCollection People
{
    get { return ((this._people == null) ? (this._people = new PersonCollection()) : this._people); }
}

The main problem with this is there's more one-liner than simplicity. This is a common problem with the inline if statement. For this reason, I avoided this type of lazy load approach.

Recently, when hammering thru some code, typing == null just made me think about the ?? operator. For those that don't know, this is essentially a null-check included with .NET 2 to simplify the use of nullable types (Nullable<T>). If the value on the left is null, the value on the right is returned.

private PersonCollection _people;
public PersonCollection People
{
    get { return this._people ?? (this._people = new PersonCollection()); }
}