• Eric Gunnerson's Compendium

    As the weather turns colder, a young man's thoughts turn toward...


    Holiday lights.

    The first house that my wife and I bought was in a development with an active homeowner's association. The first year, we got a flier from the association that said:

    Holiday decoration contest

    $100 first prize
    $50 second prize
    $25 third prize

    With hundreds of houses in the development, we didn't figure we had any chance, but we did put up a few more lives than usual, and somehow won second prize.

    A monster was born.

    After a trip to Point Defiance Zoo's excellent Zoolights got me thinking about animated light displays. I had wanted to do some microcontroller programming, but didn't have an application until now. I hooked up with one of the robotics experts in my group, and bought the parts to build a BotBoard, and did the hardware and software for an 8-channel light sequencer.

    The sequencer was destined for a Santa animation. It starts with some flashing landing lights, and then Santa and his reindeer appear. A few seconds later, Santa and the presents move onto the roof, then up to the chimney, then disappearing down the chimney. Pause, and the sequence repeats.

    It was a lot of fun to write the software - the BotBoard runs a Motorola 68HC11E2 processor that is programmed over the serial port. A very cool processor with built-in timers and other useful subsystems, but it's a 8-bit architecture, and you get to program it in assembly language (you can find compilers if you want). Debugging is interesting...

    So, we got that project done, but only won third prize.

    A few years passed, and I had some leftover BotBoards, so I built the second controller. This one was a 16 channel controller, but uses the same basic architecture. It runs a 10' tree made up entirely of lights (well, lights, electrical conduit, and a whole lot of wire).

    For my most recent application, I wanted to do something different. One of the things that I found annoying was that the lights that outlined the house were white, and static. I wanted some thing different. I could have built another sequencer, but that would have given me a quick switch between colors. I wanted something more subtle.

    To do this, you have to get into dimming. That makes the project tougher, as you now need to have tight control on the timing to get it to work. It's also a bit harder to fit everything into the 2K of EEPROM and 512 bytes (yes, bytes) of memory you have.  This one took me a while, but ultimately gave me a very good project.

    In fact, I was able to write an article on it for Nuts & Volts magazine.

    So, as Thanksgiving approaches, I need to get ready to put up all three of the animated displays and a few thousand over lights. The total number of lights is around 13,000.

    I've been hoping to spend some time building some new sequencing - perhaps one that can be driven over a serial port.

    If you happen to live in the Bellevue area, you can stop by. I'm going to try to post some pictures when it's all up and running.

    Oh, and if you think I'm out of control, take a look at this, and of course, the granddaddy of them all, PlanetChristmas. 35,000 Lights.  Here's a video.

  • Eric Gunnerson's Compendium

    Book Review: The Salmon of Doubt


    Like many people, I was saddened when I heard about Douglas Adams' death last May.

    Of course, I had read Hitchhikers many years ago, and had also read his Dirk Gently series. I also had the unique (well, not *truly* unique) privilege of hearing him speak when he did a talk at Microsoft a few years ago.

    I recently came across a copy of The Salmon of Doubt, which I would describe as a brain dump of a bunch of useful things that Douglas had on his computers at the time of his death. There are a lot of short articles and essays, and then a few chapters from a never published Dirk Gently book. The articles and essays are varied and interesting, and the chapters, while a bit uneven, are definitely good stuff.

    Overall, I liked the book a lot, and found out a lot about Douglas that makes me more convinced that the world has truly lost a unique soul.

    One especially poignant part of the book is the order of service for his memorial. If you have Richard Dawkins speaking at your memorial service and David Gilmour performing "Wish You Were Here" (my absolute favorite Floyd song), you're hangin' in the right crowd in my book.

  • Eric Gunnerson's Compendium

    New CLR Profiler release


    From Jan Gray's blog (Jan is another of the Perp team members), a new release of the CLR Profiler. This tool, which used to be known as the "Allocation Profiler", was written by Peter Sollich, who also happened to be a member of the C# design team for a while.


  • Eric Gunnerson's Compendium

    Generics Algorithms


    A few weeks ago, Anders walked into the C# design meeting and said, "I think I have a way to get generic algorithms to work with our current support", and then proceeded to outline a scheme on the whiteboard. I dutifully copied it into our design notes (after being away from the design process for a couple of years, keeping the notes up to date is my big contribution).

    Today, I was home taking care of my sick daughter, so I spent some time playing around with his idea.

    The basic idea is to create a generic class that defines the operations that can be performed on a data type, and then create specialized implementations. Something like:

    public abstract class Calculator<T>
        public abstract T Add(T a, T b);

    and then derive a specific class from it:

    namespace Int32
        public class Calculator: Calculator<int>
            public override int Add(int a, int b)
                return a + b;

    We'll be using Int32.Calculator to perform operations on ints. We could extend thte calculator class to perform more operations, and create implementations to deal with different types. So that's the first part of the scheme. It's somewhat reminiscent of template specializations in C++, but it's not

    We can now define a library to use it: 

    class AlgorithmLibrary<T> where T: new()
        Calculator<T> calculator;

        public AlgorithmLibrary(Calculator<T> calculator)
             this.calculator = calculator;

        public T Sum(List<T> items)
            T sum = new T();

            for (int i = 0; i < items.Count; i++)
               sum = calculator.Add(sum, items[i]);

           return sum;

    This class encapsulates algorithms inside of it. When we want to use it, we can write:

    AlgorithmLibrary library = new AlgorithmLibrary<int>(new Int32.Calculator());

    I should perhaps explain how this works. When we construct library with int as the type argument, that means that constructor is looking for a Calculator<int> rather than a Calculator<T>, which is convenient, since that's the class we passed into it.

    Ultimately, we end up with a version of Sum that uses the int calculator to do its operations.

    That gives us a workable scheme, though it is a bit ugly because we have to create the calculator and pass it in. The neat way that Anders came up to get around this is to use a pattern-based approach, and use reflection. We first look for the calculator class off of the type, and if we don't find it, we look in the standard place. This means that you can have the AlgorithmLibrary constructor find the right calculator for us.

    This all worked out fairly well. I'd show you the whole code, but I'm not quite happy with it, and I'm not sure it would run on the PDC bits, so you'll probably have to wait for a while. Here's a sample of using it:

      List<double> ld = new List<double>();


      AlgorithmLibrary<double> cd = new AlgorithmLibrary<double>();

      Console.WriteLine("Sum is {0}", cd.Sum(ld));
      Console.WriteLine("Mean is {0}", cd.Mean(ld));
      Console.WriteLine("SD is {0}", cd.StandardDeviation(ld));

    One concern with this approach is performance. I did a few quick benchmarks, and for lists, this approach takes about 50% longer than coding it by hand. For arrays, it's about twice as slow. I think the major problem is the virtual function, but there may be a way to make that faster.


  • Eric Gunnerson's Compendium

    C# Performance


    If you're concerned about performance, you should read Rico Mariani's blog.

    Rico is an architect on the CLR team, and, coincidentally, is one of the developers who interviewed me way back in 1994.


  • Eric Gunnerson's Compendium

    Public fields vs properties


     If you search on MSDN, you won't find any general C# coding guidelines. When people have asked how they should write their code, they often get pointed to the class library design guidelines. There is lots of good advice there, but not all of it applies universally.

    One of the guidelines says:

    • Do not use instance fields that are public or protected

    it goes on to say that this is important because properties don't version well.

    Some people have taken this as an absolute rule, so I've been seeing lots of code that uses properties on every class. If you don't need the versioning advantages of properties, you don't need to spend the time writing lots of trivial properties (those where the getter and setter don't do anything special).

    In fact, I'll say that a bit stronger. You probably shouldn't use properties unless you need them, as it takes more work and makes your classes harder to read and maintain.

    So, when should you use properties that you don't need? My suggestion is to only use them at versioning boundaries. If a class and the classes that use it are always compiled together, than properties don't buy you any advantage. If they are compiled separately, then using properties instead of fields looks like a better idea.

    Or, to put it another way, writing trivial properties makes sense at the locations where your component interfaces with other components.




  • Eric Gunnerson's Compendium

    Note to my younger self


    Note to my younger self: Eat better.

    There won't be any programming content here, so you may choose to ignore this post, though you may regret it in a decade or two. Don't say I didn't warn you.

    A few weeks before PDC, I started have a problem of a very personal nature. That's right, I had an outbreak (incident? flare up? episode?) of hemorrhoids. It's not something you generally want to publicize, and in fact, I didn't talk about it. I've decided to blog about it, for a simple reason:

    If somebody had told me what I'm going to tell you when I was in my 20s, I would have had the opportunity to change my habits.

    Most Americans eat less than half the fiber they should, which also means they're probably eating fewer vegetables than they should be. Trust me when I tell you that you don't want this condition. And since over 50% of Americans have it at one time or another, the odds aren't good. A decent diet can make it unlikely you will ever have to deal with it. Not to mention the other benefits.

    After my first "encounter" about a decade ago, I changed my diet a fair bit and got better, but after the recent episode - and a fairly miserable few weeks, including a unhappy week at PDC, I decided to see a specialist, who last Tuesday did a small bit of surgery. After which I found out an interesting pharmaceutical fact.

    Well, perhaps "found out" isn't really the right term. Something like, "had beat into me over five increasingly miserable days".

    My doctor had written me a prescription for Vicodin, the trade name for Hydrocodone, an opiate that's more potent than morphine, to help control the pain. It is wonderful against pain. But it is not without side effects.

    If you go to a drug website, you'll find a list of side effects. There are a lot of fun "mind altering effects", which I like to call "crazy thinkin'", but the most important one is the second one. Apparently opiates are well known to utterly and completely shut down the later stages of digestion. For me, two vicodin did me in. Saturday night found me in the emergency room treating that condition, and today I'm feeling better than I have in the last 6 months.

    The choice is yours.



  • Eric Gunnerson's Compendium

    An Introduction to C# Generics


    An Introduction to C# Generics

    By one of my friends, Juval Lowy, founder of IDesign.



  • Eric Gunnerson's Compendium

    C# Team Chat: New Features in Whidbey


    The C# team is hosting a chat on MSDN next week discussing the changes in Visual C#, including both language changes and IDE changes.

    November 20, 2:00 P.M. Pacific time/5:00 P.M. Eastern time - You can find more information about this chat on

  • Eric Gunnerson's Compendium

    Quiet CPU Fans?


    I recently built a music system for the ski cabin (you can only listen to Infinity so many times). It's a Micro-ATX system with a 40Gig drive, a CD ROM, and 256M of memory. More than enough for music. It runs the same custom MFC application that I use for my music system at home, and I'm using an old PocketPC as the remote control.

    The system works great, except that the CPU fan that I got at my local PC store (the original one I got was too tall) sounds like a hair dryer. So, I'm shopping for a new CPU fan that's quiet.

    The search has been a bit confusing, so I'm looking for some help. The CPU is an Athlon 1.3GHz, and the fan needs to be not much bigger than the "small heatsink" size (ie about 3" square), and it can't be too tall (about 3" max).


  • Eric Gunnerson's Compendium

    Things My Girlfriend and I have argued about

    One of my favorite pages on the net:
  • Eric Gunnerson's Compendium

    C# IDE: New Features for Whidbey


    I'm sitting in a large conference room watching my manager, Scott Wiltamuth, do a presentation about the new features in the C# IDE. The highlights are:

    1. Expansions, which are user-written "code templates" which are triggered through the standard CTRL-Space syntax. They are somewhat like a Cut/Paste, except that you can define fields in the text that can be replaced, and the IDE will highlight as you step through them.
    2. Code formatting. Formatting is always a religous issue, and previous versions of C# didn't give you very much freedom in following your own formatting beliefs. In Whidbey, we've developed an approach with much finer-grained control on how you code is formatted. There are 80-some different settings that you can set to control exactly how your code is formatting
    3. Refactoring. VC# in Whidbey contains support for some commonly-used refactorings. One of our goals WRT refactorings is to be able to make the refactorings that we do very trustworthy. In other words, to make sure that they work every time. To do that, we've hooked in to the C# compiler, so that refactoring can use the "gold standard" information about the code when doing refactorings.
    4. Debug visualizers. Visualizers are C# forms that the debugger uses to display values. If you've ever tried to figure out what's going on in a hashtable or a dataset, you know that the current model isn't great. With visualizers, you can use a custom viewer on top of the data.
    5. New build system (ie msbuild). Think of something like Nant.
  • Eric Gunnerson's Compendium

    PDC: New C++ language syntax


    I spent a bit of time in the session on the new C++ language syntax, and I saw a similar presentation a few weeks ago back in Redmond. The current release of VC++ uses an extension syntax to "add on" the managed (ie clr) concepts onto the existing C++ syntax.

    For Whidbey, the C++ team has ingrained the managed concepts deeply into the language syntax, which should make it easier to write managed code using C++.

  • Eric Gunnerson's Compendium

    Welcome to PDC (belated)


    Well, I'm here

    PDC (and OOPSLA, which also runs this week) had a run-in with mother nature, and mother nature is ahead. Fires in California shut down the LA regional FAA office. FAA Regional offices control large amounts of airspace around a region, handling all flights once they've left the airspace local to the airport.

    This meant that nothing was leaving airports on the way to LAX. Our 12PM flight left at about 4:10, and we were all grateful, since most of the people in our group didn't make it at all. Anders wasn't able to get down here to present at OOPSLA, though he's expected to get here sometime today.

    The fires have also imparte a slight tinge of woodsmoke in the air, lending a "summer camp" feeling to the whole city, and noticeably worsening the already viscous LA air.

    I'm staying in the Westin 'Bonaventure' (literally, "We are sorry that we can't offer you the queen size bed we promised you, but we can offer you a room without a minibar"), with interior architecture designed by the same guy that built the "marble ramp"(link) toys that I (I mean "my daughter") enjoy so much. The lobby has big supports under the towers, with spiral ramps around them going up and down. Sounds like a good idea except a) you can only get to certain levels with the elevators and b) the food court (good idea in concept) is spread out around the entire perimeter, and you can't actually see what the other restaurants are like, so you have to walk all the way around to find out what there is and then continue the walk back to the one you want. Given the quality of the cuisine, perhaps that's a benefit.

    I went in this morning, got my registration stuff, and stopped by the keynote for a few minutes. I was happy to see that, despite any travel problems, the room was *packed*. I couldn't stay for very long, as I had to leave for a series of customer meetings that the C# team was holding.

  • Eric Gunnerson's Compendium

    PDC: By our buttons you will know us

    All the C# team members will be wearing "C# Team Member" buttons, often with very nice black C# polor shirts. We also have buttons for you, if you wish to identify yourself as a C# programmer.
  • Eric Gunnerson's Compendium

    New C# Language specs


    New Language Specs are online.

    Note that there's a language discussion forum devoted to the language there.

    If you don't own Word, download the free Viewer

  • Eric Gunnerson's Compendium

    Don't write code like this...


    I've just finished doing a security review of my MSDN columns, and as part of that, I needed to add some security to an add-in architecture, so the add-in architecture won't run antisocial code. The approach taken by .NET security is reminiscent of ACLs, which means (at least to me) that it's confusing and I need to read the code 5 or 6 times before I understand it. Along the way, I got a chunk of code from somebody on the .NET security team, which I'll reproduce here:

    private NamedPermissionSet FindNamedPermissionSet(string name)
    	IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy();
    	while (policyEnumerator.MoveNext())
    		PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current;
    		if (currentLevel.Label == "Machine")
    			IList namedPermissions = currentLevel.NamedPermissionSets;
    			IEnumerator namedPermission = namedPermissions.GetEnumerator();
    			while (namedPermission.MoveNext())
    				if (((NamedPermissionSet)namedPermission.Current).Name == name)
    					return ((NamedPermissionSet)namedPermission.Current);
    	return null;

    Ugly, isn't it?

    The root of the problem is that PolicyHierarchy returns an IEnumerator instead of an object that supports IENumerable.  This means that I can't use foreach on it, and have to write the traversal myself. This decision also means that, without a collection returned, there's no place to hang a useful method like "LookupLabel()" on, so all users are stuck writing the search code themselves (or encapsulating it off into a separate method).

    PolicyLevel.NamedPermissionSets uses a different approach, that of returning an IList, which is better than an enumerator, as I could use foreach on the IList, but the person who wrote this sample didn't because they didn't know about foreach. If they had, they would have done the right thing.  

    We need to not do this.


  • Eric Gunnerson's Compendium

    SD Times: No Reservations about .NET

    No Reservations about .NET
  • Eric Gunnerson's Compendium

    The Visual C# Team at PDC


    The Visual C# Team and PDC


    PDC is next week, and a lot of C# team members will be there. This schedule outlines our main activities during the week.


    You’ll know that you’ve found a C# team member by the “C# Team Member” button that they’re wearing. If you see one of us, feel free to approach us at any time – we’re there to talk to you.


    The Visual C# Team and PDC


    PDC is next week, and a lot of C# team members will be there. This schedule outlines our main activities during the week.


    You’ll know that you’ve found a C# team member by the “C# Team Member” button that they’re wearing. If you see one of us, feel free to approach us at any time – we’re there to talk to you.


    Visual C# PDC Schedule Overview



    2:00PM – 3:15 PM   IDE Enhancements for the C# Developer (515AB)

    3:45PM – 5:00 PM   Language Enhancements (150/151/152/153)

    5:00PM - ??              Discuss the two C# talks, or other topics (Tools Lounge)

    5:15PM – 6:30 PM   Advanced Debugging Techniques (408AB)

    7:00PM – 9:00 PM   Ask the Experts



      1:00PM – 2:00PM   Book signing, Scott Wiltamuth & Anders Hejlsberg

                                     (Exhibition hall book store)

    3:00PM – 4:00PM    C# Developer Lounge (Tools Lounge)



      1:45PM – 2:45PM  Panel: Future of .NET Languages, Anders Hejlsberg

    6:00 PM                   LA .NET User Group Meeting,

                                    Joe Nalewabau, Shaykat Chaudhuri (not at the convention center)


    Detailed Schedule




    The Visual C# team will be presenting three talks at PDC, all of which are back to back on Thursday (note to self – make sure we don’t do this next time).


    Visual C# "Whidbey": IDE Enhancements for the C# Developer

    Tuesday 2:00 PM – 3:15 PM

    Room: 515AB


    Visual C# PUM Scott Wiltamuth (PUM = “manager of the whole Visual C# team”) and IDE Program Manager Anson Horton will be showing off many of the new IDE features for the C# programmer, including refactoring and data visualization.


    Visual C# "Whidbey": Language Enhancements

    Tuesday 3:45PM – 5:00 PM

    Room: 150/151/152/153


    Anders Hejlsberg, distinguished engineer and lead architect for the C# compiler, will be presenting on the new C# language enhancements, including generics, iterators, anonymous delegates, and partial classes.


    Discuss the two C# talks, or other topics

    Tuesday 5:00 PM - ?

    Room: Tools and Developers Lounge (Level 2 near room 309)


    After Anders finishes his talk, the team will be available in the Tools and Developers Lounge (which I’m told is out in the middle of one of the concourses) to answer questions about C# or about either of the C# talks. Scott, Anson, and Anders will be available, as will other C# team members.


    Visual Studio "Whidbey": Advanced Debugging Techniques

    Tuesday 5:15PM – 6:30 PM

    Room: 408AB


    Visual C# Debugger Program Manager Habib Heydarian will show off the new features of the Whidbey debugger.


    Ask the Experts

    Tuesday 7:00 – 9:00 PM

    Room: Expo Hall? (I think - don’t quote me on that one)


    The C# team will be out in force for Ask the Experts, as will the rest of the Microsoft teams. If you have a hard problem to solve or a tough question to get answered, this is a great place to spend some time.




    1:00PM – 2:00PM   Book signing, Scott Wiltamuth & Anders Hejlsberg

                                    (Exhibition hall book store)


    Scott and Anders have recently finished “The C# Programming Language”, the C# specification in book form.


    3:00PM – 4:00PM   C# Developer Lounge (Tools Lounge)


    The C# team will be hanging out in the tools lounge for this hour. Please stop by with questions, or just to chat.




    1:45PM – 2:45PM  Panel: Future of .NET Languages, Anders Hejlsberg


    A panel discussion on where .NET languages are going.


    6:00 PM                  LA .NET User Group Meeting,

                                     Joe Nalewabau, Shaykat Chaudhuri


    Joe and Shaykat are Program Managers in the Visual C# team.

  • Eric Gunnerson's Compendium

    Foreign Translations...


    A while back, I wrote about having copies of translations of my book that I didn't know what to do with. A few of you wrote that you would like copies. Here's what I've decided to do:

    I'm going to give away the foreign copies to anybody who wants them, with the following provisions:

    1) It can't be too much hassle on my part. Too much hassle involves lots of trips to the post office, dealing with customs, or tapdancing on a bar while singing "what do you do with a drunken sailer".

    2) You'll cover any postage necessary

    3) If you're coming to PDC, I'll bring it with me. In fact, since doing that will likely be less of a hassle, I'll give priority to those requests.

    4) You'll agree to write me a paragraph telling me what you're doing with C#.

    Interested? Send me email at, telling me what version you're interested in.



  • Eric Gunnerson's Compendium

    Apollo 11: Men on the Moon


    On July 20th, 1969, a 5-year-old boy living in Caldwell, Idaho stayed up past his bedtime to watch a very grainy television transmission of Neil Armstrong's first steps on the moon, which cemented an interest in space that has lasted over the decades.

    Since that time, I've watched coverage of countless space missions, but until I got access to NASA TV a couple of years ago, I only got what the networks wanted to show me (not that NASA TV is particularly good - you would get better production values from a high school AV class. NASA continues to make a huge mistake in not doing decent programming). Networks often miss the interesting stuff, and with the exception of a few specials, few people have seen the the archival footage that lurks in NASA's vaults.

    Spacecraft films was founded to solve that problem. They have spent time going through tons of footage from the Apollo 11 mission, and have produced Apollo 11: Men on the Moon, a 3 DVD set with over 10 hours of content. I have yet to watch all the content, but they've taken a very innovative approach. For the launch, you can watch simultaneous views from 5 different tracking cameras, synchronized with the audio. For the touchdown, there is the single video taken from the LM, but with 4 different choices for audio. You can listen to CAPCOM talk to the astronauts, or you can listen to flight director Gene Kranz (author of the excellent Failure is not an option) as he talks to his flight controllers, as they work through computer problems during the landing, or you can listen to all of them at once in a 5.1DD mix (though the multichannel is marred by one very noisy channel). During Armstrong and Aldrin's moonwalk, they've overlaid the TV video with a one-per-second 16mm film, and the excellent 70mm still camera shots.

    If you're a space buff, you need this set.

  • Eric Gunnerson's Compendium

    Learning to speak in public


    I enjoy giving presentations - there's something about being up in front of a crowd that is very powerful, especially when they're laughing.

    But I wasn't always like that. In fact, throughout high school and college, I avoided those sorts of situations as much as possible. When I got out of school and started working (at Boeing Computer Services, doing engineering graphics), I decided that being able to speak in public was a skill I wanted to have. Boeing sponsored a Toastmaster's chapter, but that seemed like an artificial situation (I told myself). To be honest, it was probably more that deciding to do something like that is a big move, so I put it off.

    One day, a fellow motorcyclist who I had taken a motorcycle safety course from suggested that I become an instructor for MSF. That seemed like a great idea - I could learn to speak, teach people to ride better, and make a little spending money (very little, it turns out). So, I sent in an application and was accepted to the 1990 instructor class.

    Though the format has changed since then, at the time the course ran for 8 days straight. You started with 6 days of covering the beginning rider course in excruciating detail. For the classroom sections, you walk through what you need to present and do short practice sections of presentation. For the range (ie riding) sections, you learn how to present an exercise, how to demo an exercise, where to stand, what appropriate coaching is, how to get the students to do what you want, and how to keep track of time. You'll spend 8 hours a day on this, plus 4 hours at night studying.

    Then, on Friday night, an unsuspecting class of students shows up to be taught by the instructor candidates, with your chief instructors there only to observe (and to rescue you if you really screw up).

    The result is not pretty.

    The classroom sessions go pretty well - the curriculum is very good, and even if you just read the talking points and show the videos, the students will do well. The range, however, is another matter.

    MSF courses teach skills in progressions - the students learn one skill, and then the next exercise builds on that skill. A cornerstone of that approach is that students need to actually *learn* a skill before they go to the next exercise. Unfortunately, it requires skilled instructors to ensure that, and we were far from skilled. We chose exercises to lead by lot, and I drew exercise 11, which is titled, "Shifting and turning on different curves(3) and shifting and making sharp turns". It requires the students to put together actions smoothly and in the right order on an intimidating course. It's very, very useful in a well-taught class, but for me, it turned into the exercise from hell. To get a passing grade as an instructor, the students need to achieve the point of the exercise, and the combination of them not getting good instruction and my inability to keep them in the right path of travel meant that it was pretty much a foregone conclusion that I would not get a passing grade on that exercise. Luckily, I had passed my first classroom section, and I only had one more range exercise to teach, "stopping in the shortest distance", which is pretty much impossible to foul up as an instructor. So, I passed the course, though it was incredibly intense. That's to make the real courses seem easy.

    After a while, I started teaching the classroom section by myself. The courses only have 12 people in them, so the size isn't that intimidating, but you have to be "on" the during the whole course. Over time, I got so that I really enjoyed teaching the courses, though I had to give them up recently because of other time committments.

    Onto C# Land. The original C# team was part of the VC++ team, and we had 4 devs, 5 testers, and one PM working on the compiler, plus Anders and a couple of other people on the design team. After we announced C#, there was a ton of call for talks on the subject, and limited resources, so I started doing talks (one of the nicethings about MS is that I was able to do talks even though I was a QA lead, not a PM). In one quarter, I did 23 talks on C#, and found that I was a bit of a ham when I got up in front of people.

    If there's a point to this story, it's that if you want to get good at something, you need to just do it. But try not to start in a the "Rock Star"-talk-to-3000-people-at-PDC mode.

  • Eric Gunnerson's Compendium

    C# for the Java Programmer


    I've signed up to do a "C# for the Java Programmer" presentation on campus the week after PDC. I have some ideas for what I'm going to cover, but I'd like your input.

    What topics are the most important in this talk? What was the most non-obvious thing that surprised you about C#?

  • Eric Gunnerson's Compendium

    Naked at Work...


    This is not the newest manifestation of the "Dress Casual" trend.

    Naked at Work (And Other Fears): How to Stay Sane When Your Job Drives You Crazy

    Is a book that I've been reading. It's a self help book, but not the "do these things to make yourself better" vein. More in the "this is why the world seems to be the way that it is".

    I picked this up at the library because I liked the title, and I was happy to find that it has a fair amount of wisdom in it. For example, just because we think about ourselves all the time does not mean that other people think about us all the time. That means if our boss sounds grumpy when he meets us in the hall, it's much more likely that he's not grumpy about us, but about other, more important things in his life.

    The big surprise for this book - based on my assumption that the title was dreamed up by the publisher to sell more books - was that it is genuinely funny. Paul Hellman has a style that is not unlike Dave Barry's, and in my book, that's a pretty good place to be. Here's an example of an anecdote from the book:

    Anecdote #20: Traffic Item in the paper: A union debate whether to block rush hour traffic to "draw public attention to worker' gripes." Is there a connection between rush hour traffic and workers' gripes? I think yes! I'm a worker, and one of my main gripes is -- rush hour traffic. Maybe the union's motto should be, "We're not going anywhere and neither are you." But I doubt the public would react favorably: "This traffic is driving me NUTS!!! And yet -- it's also increasing my sympathy for workers' gripes!" Anyway, it doesn't really matter. You can't block rush hour traffic. It's already blocked! That's the whole point of rush hour traffic. If the union really wants public support, they should figure out a way to unblock it.

  • Eric Gunnerson's Compendium

    XML Doc comments and include files...


    When we first added XML doc comments to C#, we thought that using them would give us much more accurate documentation, as the developers would update the docs when they changed the code. This works pretty well for small libraries, but if you have a UE group that works on your docs, it's pretty inconvenient for them to have to check out your source files to work on docs.

    So, we added an "include" syntax that lets you keep the docs in a separate file, which the compiler then reads to get the actual xml to use.

    This is all documented here

Page 42 of 46 (1,128 items) «4041424344»