I spent all day yesterday working with VS2010 RC. (MSDN Subscribers could download late on Monday. It becomes public today).

First impression:  It is much faster, and more stable than the beta 2 build.

The reason for the extra public build and the delay in the launch date was performance. (Soma and the Gu discussed this previously).

Caveats:  It’s only been one day. If I were making a ship decision, I’d say VS2010 RC needs a lot more soak time.

I put VS2010 RC on the PDC Laptop. (The Windows Rating is a 3.2, due to the Windows Aero score). On that machine, the VS2010 Beta was rather painful. It worked, but I could type noticeably faster than VS2010 could display characters. Even worse, slewing characters would cause the display to fall more than a screen behind in drawing.

None of those effects occur in the the VS2010RC. (VS2010 RC uses the hardware rendering on this machine. See Jason Zander’s discussion of perf changes betwen B2 and the RC for more information.) I spent all day coding on the PDC laptop. It kept up during the entire day. Scrolling, slewing keys, intellisense. It’s downright zippy.

As an extra added bonus:  The Add Reference dialog appears in a heartbeat.

As of now, I am doing all development in VS2010 RC.

This is going to be fun.  It’s a bit of LINQ, a bit of academic Computer Science, and a bit of meteorology.

Euler Problem 14 concerns a sequence referred to as hailstorm numbers.

Hailstorm number sequences are generated by applying one of two functions to a number in order to generate the next number. In this case, the sequence is:

n –> n / 2 (n is even)

n –> 3n + 1 (n is odd)

When n is even, the next number in the sequence is smaller. When n is odd, the next number in the sequence is larger

In all cases, it is believed that for every starting number, the sequence will oscillate for some time, and then eventually converge to some minimum number. (In this case, that minimum number is 1.)

These sequences are called hailstorm numbers because they (very simplistically) act like hail in a storm: oscillating up and down in a thunderhead before eventually falling to earth.

This particular problem asks you to find the sequence that has the longest chain, given input numbers less than 1 million.

Writing some code

The brute force method will take your computer a very long time to compute. The problem asks for the longest sequence, and you’ve got a million of them to compute.

Stack size is a related problem.  You could write a method that computes the next value, and then finds the sequence size recursively:

   1: private static long Generate(long n)

   2: {

   3:     if (n == 1) { return 1; }

   4:     var next = (n % 2 == 0) ? n / 2 : 3 * n + 1;

   5:     return Generate(next) + 1;

   6: }

A LINQ query gives you the answer:

   1: var answer = (from StartingValue in Enumerable.Range(1, 999999)

   2:              let SequenceSize = Generate(StartingValue)

   3:              orderby SequenceSize descending

   4:              select new { StartingValue, SequenceSize }).First();

This works, and does give the correct answer.

But I’m not really satisfied, because it takes more than 15 seconds (on my PDC laptop) to finish.

Making it Faster

There are two steps to making this faster.  The final version uses a technique called Memoization. Memoization enables you to avoid computing the same result more than once. Pure functions have a useful property in that the output depends on their inputs, and nothing else. Therefore, once you’ve computed the sequence length for, say 64, you should never need to compute it again. It’s always going to be the same.

Moemoization means to store the result for a computation and returned the stored result rather than do the work again. This can provide significant savings in a recursive algorithm like this. For example, memoization of the result for 64 (7) means saving the computations for 64, 32,16,8,4,2 and 1. Memoization of the results for longer sequences would mean correspondingly larger savings.

You could modify the Generate method to provide storage for previously computed results.  Here’s how you would do that:

   1: private static Dictionary<long, long> StoredResults = new Dictionary<long, long>();

   2:  

   3: private static long Generate(long n)

   4: {

   5:     if (StoredResults.ContainsKey(n))

   6:         return StoredResults[n];

   7:     if (n == 1) 

   8:     { 

   9:         StoredResults[n] = 1;

  10:         return 1; 

  11:     }

  12:     var next = (n % 2 == 0) ? n / 2 : 3 * n + 1;

  13:     var answer = Generate(next) + 1;

  14:     StoredResults[n] = answer;

  15:     return answer;

  16: }

But, what’s the fun in that?  There’s no reuse. It’s a one off solution.

I want to write a generic Memoize function that lets me memoize any function with one variable. Wes Dyer’s post explains this technique in detail.  Memoize is a generic method that executes a function, abstracting away the types for both the parameter type and the result type:

   1: public static Func<T, TResult> Memoize<T, TResult>(this Func<T, TResult> function)

   2: {

   3:     var previousResults = new Dictionary<T, TResult>();

   4:  

   5:     // Important:  This is a lamdba, not the result.

   6:     return (T arg) =>

   7:     {

   8:         if (previousResults.ContainsKey(arg))

   9:             return previousResults[arg];

  10:         else

  11:         {

  12:             TResult result = function(arg);

  13:             previousResults.Add(arg, result);

  14:             return result;

  15:         }

  16:     };

  17: }

The first question you may have is how the previous results actually works. It’s a local variable, not a static storage. How can it possible live beyond the scope of the method?

Welll, that’s the magic of a closure. Memoize doesn’t return a value, it returns some func that enables you to find the value later. That func contains the dictionary. I go into this technique in Items 33 and 40 in More Effective C#.

In order to use this, you need to move Generate() from a regular method to a lamdba expression (even if it is a multi-line lambda):

   1: Func<long, long> GenerateSequenceSize = null;

   2: GenerateSequenceSize = (long n) =>

   3: {

   4:     if (n == 1) { return 1; }

   5:     var next = (n % 2 == 0) ? n / 2 : 3 * n + 1;

   6:     return GenerateSequenceSize(next) + 1;

   7: };

   8:  

   9: GenerateSequenceSize = GenerateSequenceSize.Memoize();

Now, we have the generate function in a form we can memoize. The only trick here is that you have to set GenerateSequenceSize to null before you assign it in line 2. Otherwise, the compiler complains about using an unassigned value in line 6.

You can extend the Memoize function to methods with more than one input, but for now, I’ll leave that as an exercise for the reader.

The January Visual Studio Magazine marks the first time the C# Corner is written by Patrick Steele. I’ve bowed out after a long run with the magazine and its predecessors.

The most important part is that the C# column is in great hands. Patrick is excellent at explaining concepts, and he’s going to bring a wealth of new ideas and concepts to the magazine. I feel much better walking away from the column knowing it is in such good hands.

It was hard to walk away after so much time with VSM and its predecessors. But it was time. I’ve written on so many C# topics that I was having trouble coming up with ideas that felt new. I felt like I was covering the same ground over and over.

That got me thinking about how long it had been, and what a long, strange trip it has been.

I started as the original C++ Fundamentals columnist for Visual C++ Developers Journal in the 1990s. That was a new magazine published by TPD, for the MFC / C++ Developer. It were covering techniques to bridge the divide between 16 bit and 32 bit applications. There was this amazing new OS code-named ‘Chicago’ on the horizon.

A few  years went by. I kept covering more topics related to C++ and windows development. More MFC, ATL, language enhancements and how the Microsoft C++ compiler tracked (or didn’t track) the C++ standard.

At some point in this period, Visual C++ Developers Journal was bought by Fawcette. TPD stopped being involved.

The turn of the century brought more changes.  This amazing new .NET platform and the C# language showed up. I started writing about C#and .NET fundamentals, instead of C++. Although the change was gradual: In the beginning, I was writing 2 C++ columns for every 1 C# column. Over time that kept changing.

Next, came some initiatives to capture more of the web audience. Several of the columnists starting writing a column online (at the rate of one a week). These weren’t all tech columns. Some were more opinion, or ‘tip’ columns. That felt like quite a grind. I was constantly under deadline pressure to come up with a new idea every week. It soon got harder: The readers liked the ‘how to’ columns most. I was asked to replaces the ‘tips’ and ‘opinion’ entries with more regular columns.

I took a break and wrote a book (Effective C#, the first edition).

I wrote for a while, and then there were more changes.  Visual C++ Developers Journal merged with Visual Basic Programmers Journal to become Visual Studio Magazine. This was a challenging time to write for this magazine. The audiences for VCDJ and VBPJ were very different. And, most importantly, they were both afraid of losing content to the ‘other’ audience. C# aficionados were concerned that they’d lose coverage to the larger VB market. VB developers felt the same fear of losing coverage to the newer, and perceived to be cooler C#. That was a tough era. The editorial staff did a tremendous job to navigate a very tough set of market perceptions.

I stayed on break and wrote a second book (More Effective C#).

Then, I was approached to come back and write the C# Corner column for Visual Studio Magazine. Having finished the book, it was time to keep writing again. It was fun for a while. I was and still am impressed by the energy that 1105 media is bringing to the publication.  I had a blast over the past two years writing for a reenergized Visual Studio Magazine.

Then, while still trying to write the column, I updated Effective C#, covering C# 4.0, and other recent enhancements to the language.

I was running out of ideas for the column. Visual Studio Magazine deserves better content. That’s why I worked with Michael Desmond and the editorial team at VSM to turn over the column to Patrick. I’m glad it’s in good hands.

So what’s next?

I’m now writing content for the C# Developer Center. The cadence will be roughly once a month, and I’ll be writing on current and upcoming language features in the C# language.

I have enjoyed reading other posts about how much people enjoyed CodeMash. It is my favorite yearly conference. The people are brilliant, and energized about technology. It’s also one of very few events that embrace people with very different views.

I use CodeMash to learn about technologies I don’t get much time to use during my regular work.  This year, that was Ruby, and Silverlight.

First ruby.  I took a crazy route.  I went to the pre-compiler with Joe O’Brien and Jin Weinrich on the Ruby Koans. But I did it with a twist:  Instead of the reference Ruby implementation, I used IronRuby. After some initial hiccups that worked quite well.  The test harness used by the Ruby Koans makes use of an END block in the test code. An END block (in Ruby) is code that is executed as the interpreter exits. It’s rather common as a test harness: load all the tests, and have the END block reflect on all tests, and execute them. It took me a while to get over that hump, but once I did, I learned quite a bit about ruby during the rest of the morning.

During the main conference, I went to some other .NET and Ruby talks (see My CodeMash Schedule). I’m impressed with the integration story for dynamic languages and the rest of the .NET stack. I am not a Ruby expert by any means, but I’ve whetted my appetite for more Ruby learning. And now, I feel like I can be somewhat productive in the language.

I went to both of Jesse Liberty’s Silverlight talks. Going into a .NET topic may not seem like stretching my horizons, but I don’t have a lot of background in Silverlight (Mike Woelmer knows quite a bit more than I do).

Jesse gave two talks: One was very basic, and the other a bit more advanced. Jesse is a great speaker, he’s very engaging, and provides a great amount of information in a small amount of time. He provided a great foundation for someone starting in Silverlight, with or without a .NET development background. I’m much more equipped to dive into the richness that is Silverlight. Jesse helped me get over that initial hurdle of working in a new environment.

It’s the rest of CodeMash that makes the conference special: The time outside of sessions was filled with great conversations about all kinds of technologies. That’s what makes CodeMash special. Hey, it was such a mixing of different views that the Java Posse even invited Chris Smith and I to be on their CodeMash panel. It was CodeMash, so no one came to blows.

Of course, after the tech talk was over, I spent the weekend at the Kalahari with the family in the water park.

As promised, here are the slides and demos from my CodeMash Talk:  Going Dynamic in C#.

Slides.

Demos.

Please note that the demos are compatible with VS2010 Beta 2. They will not load (or run) on VS2008. I believe they will be compatible with future VS2010 builds, but predicting the future is very hard.

Thanks to the CodeMash committee for letting me speak again. It’s a great experience, and I’m proud to be a small part of the conference.

A new year means it’s time for CodeMash.  Tomorrow I begin the annual geek pilgrimage into the water park for tech knowledge.  I’m amazed at how much the conference has grown, and the strength of the session list. It was difficult to decide where to spend time, but here’s my current plan:

We’ve got great keynoters this year, and I’ll be attending all of those. I am attending the precompiler again this year. Here’s the current plan:

• Wed AM:  The Ruby Koans (Joe O’Brien and Jim Weirich
• Wed PM:  Open. I’m not sure what

Thursday:

Friday:

• 9:30: Going Dynamic in C# (Bill Wagner). Of course, I have to be there.  But, I hate pimping my own talk, so if I weren’t speaking at this slot, I’d pick:
• 9:30 (alternate) Being an Evil Genius with F# and .NET (Chris Smith)
• 10:45: Restful Interfaces to 3rd Party Websites with Iron Python (Kevin Dahlhausen) (I’m picking this because I’ve seen Jim Holmes’ Leadership talk, and I need to learn Python better)
• 1:45: Iron Python with ASP.NET (Chris Sutton)
• 3:35: What’s new in Silverlight (Jesse Liberty)

Some of this will likely change, but I think you can see the goals:  I want to learn more about dynamic languages in general. I also want to take the opportunity to learn as much Silverlight as I can. Jesse Liberty is a great teacher, and I can’t pass on this opportunity.

Of course, like every CodeMash, I’ll probably make a number of changes to this one as well.

Before I discuss my 2010 predictions, it’s important to provide a disclaimer using my 2009 predictions.  One of my predictions was spot on.  At the end of this post, I said:

“Of course, I’m probably wrong about many of these.”

That one was right. The other four, less so. Cloud Computing has not achieved the market share I would have thought it would by now. I’m going to call that one “delayed” not “wrong”. I still think Cloud Computing will be important, it is just taking longer. Rich Internet Applications was just plain wrong. While I think (almost) every application will make use of the internet, and people want rich applications, the term will lose favor. It won’t have meaning if everything is ‘rich’ and ‘internet’. “Multi-touch goes mainstream”. Not yet. I still think that will happen. The mouse as a metaphor is very long in the tooth. We do crave better ways to interact with our computers. We have it with some special purpose applications. We’ll get there with other apps as well. My final prediction “Social Networking as a business tool”, was much better. In the last year, Detroit and Ann Arbor newspapers stopped printing. I didn’t miss a beat. All those papers have great web sites (http://www.freep.com, http://www.detnews.com, and http://www.annarbor.com). Even more immediate, all those sources, and several of their reporters are on twitter. I get news more quickly following them, and following their links than I did reading the dead tree edition with my morning coffee.

On to 2010 Predictions

Armed with the confidence that I’m probably wrong, I’m ready to divulge my thoughts about 2010.

Polyglot Programming Languages

For the past few years, many industry leaders were saying that developers needed to know multiple languages. They were right, because learning multiple languages (if done correctly) meant that you needed to learn different programming idioms: procedural programming, object oriented programming, functional programming, and so on.

But that’s painful. Why should I need to learn new syntax to use new idioms? Curly braces aren’t allowed in FP? semicolons aren’t permitted in dynamic languages?

Instead, why can’t a general purpose programming language support multiple programming idioms? C#, VB.NET, and C++ are starting to seriously support that. (Other languages may be doing this as well; I don’t know). All these languages have added (or are adding) lambda expressions which support functional programming concepts. (C++ has used Class Type Functors for this purpose for some time). C# is adding support for dynamic typing (as is VB.NET, in a more strict fashion than previously supported). Implicit typing is supported in C#, C++, and VB.NET as well.

This trend will continue as more and more developers want to use the best programming idiom for a particular task without learning a totally different syntax. Any programming language that calls itself a “general purpose language” will support multiple idioms.

Value Placed on Comp. Sci Skills

For the past several years, the conventional wisdom has been that ‘business skills’ are more important than ‘core technical skills’. That trend is changing. While I don’t believe we’ll return to those days where anti-social behavior is tolerated (or worse, celebrated), I do believe that serious technical talent is valued more than it was. Even The Economist has predicted fewer MBA students in the coming year, saying it will “…cut off the supply of bullshit at the source.” 

OK, MBAs aren’t that bad. Or, maybe they are. But the fact is that technical talent and skill is important. “Soft Skills” complement hard skills; they aren’t a substitute.

In 2010, more companies will want Comp Sci or Software Engineering grads for their developer positions.

Small, Focused Applications Rule

In an interconnected world, large enterprises are no longer going to tolerate the “One Application to Rule them All” concept. They will start looking for best of breed solutions to each individual problem. The suites that solve everything are going to decrease in value. (or at least customer value). They do everything, but not exactly the way a large enterprise wants. More importantly, they don’t have the integration points needed between these important processes.

Finally, CIOs will be looking to avoid “vendor lock in”, whether that’s a real strategy, or just defensive posturing.

But APIs are the Key Value

Balancing that trend is the fact that too many business processes are stitched together from disparate programs that have no interoperability strategy. Businesses cannot compete if their disparate programs don’t coordinate automatically. It’s too much friction, and no added value. In fact, that’s what drove the trend toward the enterprise suites that claimed to do everything: it was a way to finesse the interoperability requests.

Going forward, the single most important feature for business programs will be data import / export. That must be in a standard format, and it must be a programmable API.IT may or may not be REST, SOAP, or some new made up word. But, I’m confident that any serious product in the business world will have a clear strategy to interoperate with other programs that solve other business problems.

Conclusions

These last two predictions will mean that future systems will built using these concepts:

1. Each process is a small, focused applications that solves a single problem.
2. The inputs and outputs of that process will be in a standard format.
3. Enterprise developers will stitch together different commercial applications are handle *part* of their business processes.

Notice how those last two also fit well with the cloud strategy? Processes in the cloud. You’ll interact with those small processes using a rich UI on whatever screen you have.

Of course, I’m probably wrong again.

In my last post, I wrote about the new items in the second edition of Effective C#, and those items that were removed to make room for the new items. Now, let’s discuss what happened to the items that I carried over from the previous edition.

Every item received a rather significant update for this new versions. However, you won’t see that from looking at the table of contents in InformIT. That’s because the advice is very similar to the earlier edition. However, the way you implement the advice has changed significantly. As I mentioned in the last post, the C# language has made many significant enhancements over the years since the first edition was published. We have many different tools at our disposal to express our designs. That means we have many new techniques that we can use to achieve the same goals of better software, and clearly communicating our designs to other developers.

In the new edition, I re-wrote all the samples to use the latest version of C#, taking advantage of all the features in C# 4.0. That does not mean I use C# 4.0 syntax in every single item. It does mean that I thought about how to express an idea using the full palette of features available in C# 4. In many cases, that meant using features available in C# 3, or even C# 2. In other cases, the samples will include some of the latest C# features. In all cases, I updated the justifications for the advice, and how to implement the goals, in the context of C# 4.0.

Even if you have no experience with earlier versions of C#, you can use the advice in the second edition. Furthermore, you can use much of the advice even if you have not updated your environment to C# 4.0, and .NET 4.0.

The 2nd edition of Effective C# is now available on Rough Cuts. With that, I’ve started to get questions via email about how I decided which items to add, and which items to drop.

It should be clear from the additional content what’s new: I added coverage of the significant C#4.0 features like dynamic invocation and named / optional parameters. New library additions like PLINQ are also covered.

It’s much harder to see how I decided which items to drop. There are 15 completely new items in the 2nd edition, so that meant finding 15 items to drop. (Several other items have the same title, but were significantly rewritten – that will be the subject of another blog post.) Here’s how I decided which items to remove:

Items that are less important now. A number of the items in the first edition discussed techniques that were much more important before generics were available. Some of these items were those that discussed boxing and unboxing, the collection classes, and the data set class. All of those techniques and libraries were far more useful in C# 1.x than in the current .NET universe.

Items that have become common practice. C# has been around for almost a decade, and the community is much more mature than it was in 2004, when Effective C# was published. Some of the items are part of the conventional wisdom now

Items that assumed your last language was C++ or Java. The early adopters of C# were developers that came from C++ (on the Windows platform) along with some developers that came from Java. That’s no longer true.  College grads (since 2002 or so) are using C# for their first professional programming experience. Others are coming from VB, Ruby, Python, or PHP. (I’m not claiming that C# is grabbing market share from all those languages; the migration happens in all directions.) It just wasn’t right to assume that every C# developer has C++ or Java experience anymore.

The poster child for dropping items is the original Item 41, where I advocated using DataSets rather than implementing IBindingList yourself. I didn’t rewrite this item because the obvious answer now is to use BindingList<T> when you need the IBindingList capability. If you were using DataSets for some other reason, pick some other generic collection type. There are many, and the options grew again in .NET 4.0. Those generic collections have better APIs (the type parameter means the compiler ensures type correctness), and better performance (boxing / unboxing doesn’t apply. It’s not often that it’s trivial to get better performance and better chances at correctness. Even in the 1.x days, I didn’t advocate using DataSets are part of a service API. That was and still is a painful choice.

There’s also been many enhancements in the .NET framework that mean there are better data solutions. LINQ, along with the query syntax pattern (See Item 36 in More Effective C#), means there are much better ways to work with data in .NET 4.0.  Chapters 4 and 5 of More Effective C# discuss these important techniques. The entity framework has matured, and is a better way to handle data transfer between layers and machine boundaries. (I still need to look more closely at the latest EF, I know some of the changes, but not all).

All in all, I’m happy that the second edition did preserve quite a bit of the original advice from the first edition. The C# language has grown, and there are better tools in the C# toolset. It was clearly time for an update that represented the changes in the C# language, the .NET framework, and the C# community at large.

That was a twitter comment I made this morning during the PDC keynote. A number of folks have reposted it.

Twitter’s character limit means I’ll elaborate here.

I don’t think this is a bad thing for WPF, or people that build WPF applications. Silverlight is gaining more and more features, and those features mean that over time, Silverlight will become a superset of WPF. That’s very different from the original vision where Silverlight was a subset of WPF.

I think over time, you’ll see one advanced graphics / UX framework for .NET development. I believe it’s name will be Silverlight.

I don’t know how long it will take, as there are still some gaps and differences. I also think there will be some continued enhancements to WPF in the short term. As time goes on, those enhancements will be smaller and smaller, and Silverlight will be the single framework.

Of course, I also think that any investment in WPF (now and in the future) will be extended to the Silverlight ecosystem.

In the end, I think this is branding. Silverlight has much more buzz than WPF. It’s clear that Microsoft should merge WPF and Silverlight into one framework. If there is going to be one UX framework, its name will be Silverlight.

I received the following question (paraphrased) this week:

“You are an advocate of converting imperative style programming into re-usable frameworks as you did in your November VS Magazine column. I agree from a developer’s perspective. But, one thought that came to mind is the imperative style is quicker to grasp from a maintainer’s perspective because the code is in one place in contrast to several little functions that need to be pieced together. Is your thinking that once the framework of functions is setup and re-used, then a maintainer only has to learn it once and subsequently the idiom is quickly recognized? Effectively, there is a high cost the first time the idiom is encountered but then the future cost is lower?”

Actually, I think the imperative code seems easier to maintain because we’ve all seen so much more of it. That’s probably even more true case of maintenance developers. Only some of our universities discuss declarative programming languages. There’s even less declarative programming in products and enterprise projects these days. Declarative programming is unfamiliar to many of the professional developers writing code today.

In our regular day to day jobs, it’s not that what we do is incredibly hard. What makes some tasks feel hard is that we are unfamiliar with the tools or the task. Declarative program is one of possible tools that most developers are likely to avoid, because it is very unfamiliar. That’s a shame (in my opinion) because forcing yourself to think in different ways will make you a better software engineer. Furthermore, the problem you describe above will go away. The more exposure that developers have to declarative programming, the easier it will be to understand it and maintain it.

On your specific concern, I honestly think that the declarative style makes it clearer to see exactly what each function does. Those smaller, simpler functions are easier to understand. In my opinion, that makes it easier to understand larger algorithms composed of these smaller functions.

Kirill Osenkov provides some details on this feature that was added in Beta 2 of C#4.0. I must admit a certain ambivalence toward this feature. On the one hand, this feature will make working with Office COM APIs even easier (as Kirill shows). On the other hand, I fear a rising chorus asking to implement defining indexed properties in C#. That would be a mistake. It would end muddling the waters of what objects ‘owned’ other objects and properties. 

foo.SomeProperty[3]

could represent two very different object models. Is SomeProperty a type that implements an indexer? Or is SomeProperty a property of foo that requires an index? That starts to matter quite a bit when you wonder about LINQ queries and other ways to access whatever data is behind SomeProperty.

I’m close to thinking that I’d have preferred this change wasn’t made. It’s a bit troubling to think that the language accepted changes solely to support interop with COM style APIs. But as long as the indexed properties remain in a box, and are only used for that particular scenario, it won’t be a serious concern.

A friend of mine asked me for some pointers relating to giving technical talks recently. We had a great discussion and I thought that some of the advice was general enough that I would share it here. Many of us are involved in user groups, and we (as a community) owe it to our other members to help everyone learn.

Of course, I’m not the world’s authority on speaking, and I have quite a bit to learn. I want to hear your speaking tips as well.

Tell a Story

View your talk as a story, in the literary sense. This has a lot of implications in your talk.  First, think about books you really like (or even a movie). The very beginning hooks the audience immediately. You may not know much about the story yet, but you are hooked.  You need to know more. OK, I admit that very few tech talks have the same hook as “Raiders of the Lost Ark”. But still, work on the hook as much as you can.

Next, continuing the ‘story’ analogy, consider the different components of your talk as characters in the story.  Your story (at least for this talk) revolves around one topic.  All other topics. are supporting characters. They are part of the story, but they have supporting roles. Do not spend more time on these supporting roles than they deserve. That limits your ability to tell the main story. These supporting characters can be covered, but only in such as these supporting characters tell your main story.  Look through your slides, and your samples and look for opportunities to focus on your main story rather than these supporting characters. For example, if your talk is about C# 4.0, you may use a Silverlight application to demonstrate the features. Concentrate on C# 4.0, not Silverlight. (Of course, if your talk is about Silverlight, you do exactly the opposite).

Everyone Needs Practice

Listen to yourself. Do you have an verbal tics? ‘Um’, ‘So…’, Most of us have them. Work on minimizing those tics. They will hurt your delivery.

Mix up the slides and demos. Almost all great speakers split up the cadence of their talk. They do some discussion. Then some demos. Back to slides, or a story, and onward. Staying in any one of those styles for too long will lose the audience.

Demos need the Most Practice

Let’s talk about demos. That is the hardest part.  It’s hard because we usually don’t speak while we are coding, and no one likes ‘dead air’. That’s why I use the trick of saying what I’m coding.  It avoids ‘dead air’ and I’ve never been able to code one thing while saying something else.  It’s usually something like:

“I’ll new up a List of Employees so that I can run a few queries. We’ll have to initialize it with some data. (see note one below).  Now that we’ve got a collection let’s find the most expensive employees. That’s a query from emp in employees where salary is …”

By talking through the code, you can keep your focus.

Note: some code is not relevant to your talk, like initializing a collection with a bunch of values. Use a snippet, or already have that written. When you practice, you’ll spot these. They are the bits of code that you don’t want to talk about, because they aren’t part of the story.  Just put them in place, and move on. It will give you more time to talk about your main story.

Have the crutches handy

There are two crutches I have ready all the time:

1. Snippets for bits of code I forget. Everything I type is on the snippet clipboard, in case I forget something. I try not to just paste code, but it helps to know that I can grab those if something bombs.
2. The finished demo somewhere on disk. I’ve often forgot some small bit needed to make the demo work right. It’s easy to do on stage. And, when a demo doesn’t work, it’s easy to get really nervous really fast. Therefore, I always have a way to get to the finished working demo quickly. When the demo bombs, I’ll try to fix it once. If I can’t get it working with one quick session, I punt and say something like “I must have forgotten something, so let’s load the finished solution and look at it. We’ll find what I missed, and you’ll never forget to do that again. Especially if forgetting it means your demo doesn’t work and look foolish on stage.” Then, I load the finished solution. I run and prove to the audience that it works. Then, I look at the code and explain what’s in the pre-loaded solution that wasn’t in the demo that broke. (Trust me, it’s really easy to find.)

Finally, you have to use the big font. And, you have to practice with it because that will make sure you format code so it looks good on the big screen.

The more you practice, the better you’ll be. Talk to any experienced speaker, and you’ll hear stories of when that person gave a talk that felt like a failure. They are great speakers because they learned from that experience. Everyone can do it, but it does take practice.

You probably noticed that Visual Studio 2010 Beta 2 was released for download today (for MSDN subscribers). The general release will be Wednesday (Oct 21).

I’ve had limited time (obviously) to work with this, but I’m already impressed.  The WPF editor has shown lots of progress. It’s much more responsive than in earlier beta builds. The language features (at least for C#) are coming along well.

That bodes well for the announced release date of March 22, 2010. Yes, they’ve placed a stake in the ground, and this release has an official launch date.

In addition, Microsoft made some announcements about MSDN licensing and pricing.  Microsoft has the full announcement here. There are a couple of interesting items that are very important in this announcement:

1. Every Visual Studio Premium license includes Team Foundation Server with 1 Cal. That means if your team has VS Premium, you can use TFS right out of the box.

2. WIndows Azure “Development and Test Use”. Visual Studio Premium (and above) will include compute hours (and data storage) in Windows Azure for test purposes. (UPDATE:  The full terms are here.) VS2010 with Premium MSDN will get (initially) 750 hours of compute time per month, 10 Gigabytes of storage, and more).

That promises to be a very exciting 2010!

I love it when I find those small new bits of functionality in the .NET framework. It’s all the big items that get all the love at conferences and in magazines.

Lazy<T> is one of those items.

Let’s imagine you’re writing an application and in some scenarios, but not others,  you need a particular object. Furthermore, suppose that object you need is very expensive to create and use. You don’t want to create it everytime your application runs. You only want to create it when you need it.

Sure, you could manage all that yourself, but Lazy<T> makes it easy.  You just create a lazy wrapper on the expensive object:

Lazy<ExpensiveResource> ownedResource = new Lazy<ExpensiveResource>();

You can simply reference ‘ownedResource.Value’ to get at the expensive object. The first time you access ownedResource.Value, the expensive resource will get allocated, but not before.

Lazy<T> also has a boolean propoerty, named IsValueCreated, that you can check to see if the value has been created. That would be useful when you need to store information from the expensive resource, but only if it’s been used.

Supporting Types without default constructors

Lazy<T> does not enforce the new() constraint. You can use Lazy<T> for types that must be instantiated using a different constructor, or even a factory method. A second constructor specifies a Func<T> that returns the new expensive resource:

Lazy<ExpensiveResource> ownedResource = new Lazy<ExpensiveResource>(

    () => new ExpensiveResource("filename.data"));

You can use this second constructor to better control what code creates the expensive resource. I’ve used a different constructor here, but you could use a factory method, an IOC container, or any method.

We’re living in a Multi Core World

There are two other constructors in Lazy<T>:

public Lazy(bool isThreadSafe);

public Lazy(Func<T> valueFactory, bool isThreadSafe);

These two constructors indicate that you are running in a multi-threaded envrionment, and the lazy construction of of the owned object must be synchronized. (After all, it’s an expensive resource. You don’t want two of them.)

It’s a simple type, but it’s one of those types you’ll find yourself reaching for over and over again.

I’m glad it’s been added.