I recently came across some interesting code in Juval Löwy's Programming WCF Services and wanted to share.  It's simply something I had never run across before:

            IMyContract proxy = new MyContractClient();

            using (proxy as IDisposable)

            {

                proxy.MyMethod();

            }

The first thing to notice is that the proxy object is instantiated outside of the using block.  I don't think I've ever actually tried this, but it is perfectly permissible (if not recommended).  I used a dissembler to look at the IL this generates, and it is pretty much the same as instantiating the proxy object inside of the using brackets.  The main difference is that in this case, the scope of the proxy object extends beyond the using block.

Within the using brackets, this code casts the proxy object to the IDisposable interface so the Dispose method will be available.  Since a Using Block is basically syntactic sugar for a try-catch-finally structure that calls an object's Dispose method in the finally block, the equivalent try-catch-finally block would look like this:

            IMyContract proxy = new MyContractClient();

            try

            {

                proxy.MyMethod();

            }

            finally

            {

                ((IDisposable)proxy).Dispose();

            }

However, Juval's using statement does one additional thing.  It also checks to see if the proxy object even implements the IDisposable interface.  If it does, then the Dispose method is called on it.  If it does not, then nothing happens in the finally block.  The equivalent full blown code, then, would actually look something like this:

            IMyContract proxy = new MyContractClient();

            try

            {

                proxy.MyMethod();

            }

            finally

            {

                IDisposable disposable = proxy as IDisposable;

                if (disposable != null)

                {

                    disposable.Dispose();

                }

 

            }

... and we've condensed it to this ...

            IMyContract proxy = new MyContractClient();

            using (proxy as IDisposable)

            {

                proxy.MyMethod();

            }

It's probably not something that will come up too often, but if you have a situation in which you do not know whether an object implements IDisposable or not, but still want to implement a using block for readability and good coding practice, this is how you would go about doing it.  

Besides Juval's proxy example, I can imagine it coming in handy when dealing with collections in which you don't necessarily know whether all of the members of the collection implement IDisposable, for instance:

            foreach(IDog dog in myDogsCollection)

            {

                using (dog as IDisposable)

                {

                    dog.Bark();

                }

            }

It also just looks really cool.  h/t to Bill Ryan for pointing this out to me.

The seventh day of any project should always be devoted to rest and reflection.

There is a passage from James Watson's account about discovering the structure of DNA, The Double Helix, in which Watson decides that he wants to study X-ray crystallography (the technique that eventually leads to the discovery of the double helix structure).  He is told by an authority that because the field is so new, there are only five papers on the subject worth reading -- five papers to read in order to master an entire field of science!

This is also the current state of Silverlight development.  The final framework is not yet out, the books are still being written as authors hedge their bets on what will be included in the RTM of Silverlight 2.0, and there are no best practices.  Moreover, Silverlight development is so different from what has gone before that no one has a particular leg up on anyone else.  The seasoned ASP.NET developer and the kid fresh out of college are in the same position: either one can become a master of Silverlight, or simply let it slide by and work on other things instead.

So is Silverlight worth learning?  It basically fills in two pre-existing development domains.  One is Flash, and the other is ajax web sites.  It can improve on ajax web sites by simply having a simpler programming model, and by not being dependent on Javascript (as of the 2.0 beta realease) which tends to be brittle.  The update panel in ASP.NET Ajax and the Ajax Control Toolkit have made component based programming of ajax web sites easier, but if you ever read the Microsoft Ajax web forums, you'll quickly see that it still isn't easy enough, and people supporting sites that have been up for a year are starting to come forward with their maintenance nightmares.  The introduction of the Microsoft MVC framework raises further questions about whether the webform techniques that so many Microsoft-centric web developers have been working with will continue to be useful in the future. 

Silverlight, in some sense, competes with Flash, since it is a web based vector graphics rendering framework.  It is more convenient than Flash, for many developers, since it can be programmed in .NET languages like C# and VB, rather than requiring a proprietary language like ActionScript.  Even better, it does something that Flash does not do easily.  Silverlight talks to data, and it does so without requiring an expensive server to make this possible. 

When you are thinking about Silverlight, then, it is appropriate to think of a business application with a Flash-like front-end.  This is what it promises, and the technology's success will rise or fall on its ability to make this happen.

So if you believe in this promise with, say, 65% to 75% conviction, then you will want to learn Silverlight.  There are currently about 5 articles worth reading about it, and they can all be found here.  Most other tutorials you will find on the Internet simply deal with bits and pieces of this information, or else try to pull those bits and pieces together to write cool applications.

But after that, what?  The best thing to do is to start writing applications of your own.  No company is likely to give you a mandate to do this, so you will need to come up with your own project and start chipping away at it.  The easiest path is to do try to copy things that have gone before, but with Silverlight, to see if it can be done.  Many people are currently trying to write games that have already been written better in Flash.  This is a great exercise, and an excellent way to get to know the storyboard element in XAML.  It doesn't really demonstrate any particular Silverlight capabilities, however.  It's pretty much just an "I can do it, too" sort of exercise. 

A different route can be taken by rewriting an data aware application that is currently done in Winforms or ASP.NET AJAX, and seeing what happens when you do it in Silverlight instead.  Not as cool as writing games, of course, but it has a bigger wallop in the long run.  This will involve getting to know the various controls that are available for Silverlight and figuring out how to get data-binding working.  (Personally, I'm going to start playing with various interactive fiction frameworks and see how far I can get with that.  It's a nice project for me in that it brings together both games programming (without fancy graphics) and data-aware applications.)

Finally, after getting through the various Microsoft materials and reading the various books from APress and Wrox and others that will come out shortly, where does one go to keep up with Silverlight techniques and best practices?

• Brad Abrams is blogging about it
• As is Jesse Liberty
• As is Scott Guthrie
• As is Scott Hanselman
• Method ~ of ~ failed by Tim Heuer is a great site for Silverlight apps and tutorials
• And so is http://www.adoguy.com/ by Shawn Wildermuth
• You also can't go wrong checking out something called Silverlight Games 101

Warning: there is a bit of profanity.  I'm warning you because profanity is obviously worse than being compared to Adolf Hitler.  On the other hand, sometimes dirty words can be as funny as logical fallacies -- and so can Hitler. 

A well placed adjective can thoroughly change the meaning of a word.  Some adjectives are so powerful that the the combined phrase becomes more significant than the noun the adjective modifies, leaving the unmodified noun seeming naked and weak without it.  For instance, a cop is an important member of society, but a rogue cop is a thing of legend.  An identity is good to maintain, but a secret identity is essential to maintain.  A thief is a lowly member of society, but an identity thief is lower still.  A secret identity thief is the lowest of all.

Then there are adjectives so overwhelming that they obliterate the word they modify, leaving none of the original meaning behind.  A fallen angel, after all, is a devil, and a fair-weather friend is no friend at all.

I used to work for adjectives.  You might have seen me on the side of the road holding a cardboard sign with words to that effect.  I began my career as a junior developer, then worked up to being just a developer -- which, although unmodified, was significant enough that it underscored the fact that "junior" was just a kind of slur.  After developer came advanced developer, then expert developer, and finally senior developer.  There are currently lots of senior developers around and very few junior developers, unlike the way it was back in the day.  They all tend to wonder what comes after the adjective "senior".  One can become an architect, of course, but the change of theme, and the fact that it is unmodified, merely serves to impress upon everyone that architects don't actually do any coding.  As a sort of gesture to make up for this damning through faint praise, an architect will occasionally receive a hyphenated title of developer-architect, which to my ear just makes things worse.  After senior developer, one can also become a manager of course, much the same way a Jedi padwan can become a Sith lord, but this is a path of last resort.

Our Sith overlords could meliorate the situation by simply coming up with a new adjective, of course.  I always thought awesome developer had a nice ring to it.  Recent politics, besides revealing how our democracy really works, also inspired me with a different notion.  The term super delegate left me wondering if super wouldn't make a good modifier for the great developer.  With repetition, we may be able to gentrify that somewhat wild modifier, super, and re-appropriate it from the comic connotations that have tended to diminish it.  What better public identity is there for an über geek than super developer?

This morning, however, I was surprised to discover that there is something even more powerful in Democratic electoral politics than the super delegate.  It is the undecided super delegate.  Amazing, isn't it, that not doing something can make a person more powerful than actually doing something?  Rather than waste their potency by declaring for one candidate or the other, these undecided are able to curry special favor by simply not deciding, not declaring, not having an opinion one way or the other.

There is a tradition in the West that the undecided are in some sense the most contemptible beings, scorned by all sides.  Before the gates of hell, Dante and Virgil encounter the third host of angels who neither sided with God nor with Satan, as well as those "who lived without or praise or blame," and perpetually lament their state.  Virgil states harshly:

These of death
No hope may entertain: and their blind life
So meanly passes, that all other lots
They envy.  Fame of them the world hath none,
Nor suffers; mercy and justice scorn them both.
Speak not of them, but look, and pass them by.

In the late Platonic school of Athens -- alternatively known as the old school of Skepticism, or Pyrrhonic Skepticism --, on the other hand, this suspension of affirmation was considered a moral virtue, and was called the epoche (a term later appropriated by Husserl for Phenomenology).  They found this suspension of belief so difficult, however, that they used ten argumentative tropes which they learned by heart to remind themselves that nothing should ever be asserted, lest they commit themselves to falsehood.  The true philosopher, for the Pyrrhonic skeptic, is not one who speaks the truth, but rather one who does not speak falsehoods.  Well into the modern era, one finds an echo of the Pyrrhonic tropes in Kant's four antinomies.

Whether undecided super delegates are Pyrrhonists or Kantians I cannot say.  I choose to withhold judgment on the matter since, after all, the real intent of this post is simply to congratulate two of my colleagues in the Magenic Atlanta office on their promotions.  Through hard work and natural talent, Todd LeLoup and Douglas Marsh are now both Senior Consultants.  With such adjectives we give public praise to the good and the great among us.

I've spent today going through all of the Hands-On-Labs provided on the silverlight.net site.  The five labs are basically word documents, with some accompanying resources, covering various aspects of Silverlight 2 development.  More importantly, they are extremely well written, and serve as the missing book for learning Silverlight.  Should anyone ask you for a tech book recommendation for learning Silverlight 2 beta 1, you should definitely, emphatically, point them to these labs.  They are both comprehensive and lucid.  These labs are supposed to take an hour to an hour and a half each, so all tolled, it constitutes approximately seven hours of work.

1. Silverlight Fundamentals is a great overview of the features of Silverlight and how everything fits together.  Even though it covers a lot of territory you may have come across in other material, it does it in a streamlined manner.  In reading it, I was able to make a lot of connections that hadn't occurred to me before.  It is your basic introductory chapter.

2. Silverlight Networking and Data demonstrates various ways to get a Silverlight application to communicate with resources outside of itself using the WebClient and WebRequest classes.  I couldn't get the WebRequest project to work, but this may very well be my fault rather than the fault of the lab author.  The lab also includes samples of connecting to RSS feeds, working with WCF and, interestingly, one exercise involving ADO.NET Data Services, a feature of the ASP.NET Extensions Preview.

3. Building Reusable Controls in Silverlight provides the best walkthrough I've seen not only of working with Silverlight User Controls but also with working between a Silverlight project and Microsoft Blend.  This is also the only place I've found that gives the very helpful tidbit of information concerning adding a namespace declaration for the current namespace in your XAML page.  I'm not sure why we have to do this, since in C# and VB a class is always aware of its namespace, and the XAML page is really just a partial class after compilation, after all -- but there you are.

4. Silverlight and the Web Browser surprised me.  In principle, I want to do everything in a Silverlight app using only compiled code, but the designers of Silverlight left open many openings for using HTML and JavaScript to get around any possible Silverlight limitations.  This lab made me start thinking that all the time I have spent over the past two years on ASP.NET AJAX may not have been a complete waste after all.  A word of warning, though.  The last three parts of this lab instruct the user to open projects included with the lab as if the user will have the chance to complete the lab using them.  It turns out that these projects include the completed versions of the lab exercises rather than the starting versions, so you don't actually get a chance to work through these particular "hands-on" labs.  On the other hand, this is the first substantial mistake I've found in the labs.  Not bad.

5. Silverlight and Dynamic Animations begins with "This is a simple lawn mowing simulation...."  The sentence brims with dramatic potential.  Unlike the previous lab, the resources in Silverlight and Dynamic Animations include both a "before" and an "after" project, and it basically walks the user through using a "storyboard" to create an animation -- and potentially a game.  It's Silverlight chic.

In retrospect, if I had to choose only one resource from which to learn Silverlight 2, it would be these labs.  They're clear, they're complete, and best of all they're free.