October, 2003

Posts
  • Eric Gunnerson's Compendium

    GPS and Gradients...

    • 7 Comments

    Bellevue is a hilly place. It's perched (roughly) between two large bodies of fresh water. Lake Washington, to the west, is something around 10 or 15' above sea level, and Lake Sammamish, to the east, is about 40' about sea level.

    What that means for me is that if I'm going riding, I'm going to be riding up and down some hills. Some are steep hills, of the "I'd really like to stop now, but if I do I fear I will merely fall across the road and lie there until some vehicle approaches" variety. Others are less steep. As I was suffering going up one of these hills, I thought it might be fun to know exactly how steep it is (cyclists have weird senses of humor, and love/hate relationships with hills). A few web searches led me to this inclinometer, but being the techie that I am, it didn't seem cool enough, so I did a bit more research.

    Hills are measured in terms of gradient, which is merely the rise of the hill over the run. If you're going up 2 feet for every 100 feet you travel, you're on a 2% hill. As an aside, it turns out that humans are great at overestimating the steepness of hills. It's easy to think that some streets are nearly 45 degrees (100% gradient), but it turns out that the steepest streets around Seattle (and we have some steep ones) are a 21% gradient, a mere 11 degrees. Take out a piece of graph paper, and draw a triangle that's 10 units long and 2 units high. Take a look at that, and then try to reconcile it with the streets you've been on. Doesn't make much sense.

    Anyway, what I was looking for was a way to measure the gradient of the streets I was on. To do that, I needed a way to set a reference point, move forward, and then figure out the delta in distance and altitude. If you're thinking GPS, you're right on the button. This finally gave me an excuse to order a data cable for my Garmin Etrex, and yesterday afternoon I did a little drive on some hills with the GPS on, came home, and used a gps utility program to download the data, extracted it to a text file, imported to excel, it did some graphing.

    The result was fairly good, actually, except for the fact that the Etrex only saves data every once in a while (to save memory space), so in a car, the samples are too far apart to get a good reading. This wouldn't be a problem climbing on the bike, but might be when descending. I can get around that by taking the laptop with me and saving the location every second, which should give me more than enough resolution to get some good data. GPS isn't great on absolute position, and is even less good on absolute altitude, but it's quite good on relative measurements of both of those.

    I'll have to write a C# utility to run on the laptop, of course, so that I don't have to do all the ugly massaging and export. I might eventually buy a GPS for my pocket PC, as there are some small ones that fit in the compact flash slot.

     

     

     

  • Eric Gunnerson's Compendium

    Q: Compiler compatibility vs. comformance

    • 23 Comments

    I got an email from a customer today, in which he noted that the C# compiler allows you to write:

    bool b = ...

    switch (b)
    {
        case true:
            ...
            break;

        case false:
            ....
            break;
    }

    despite the fact that the spec does not list bool as one of the types that you can switch on.

    Unfortunately, we've shipped the current behavior, and one of our high-order goals is not to break existing code by changing the compiler. In most cases, that's a really good goal, as your customers are justifiably upset when the new compiler breaks their code.

    In this case, however, I think we may be going to far in not fixing a bug because there's a chance somebody might have written code that used it. I'm therefore looking for your opinion (noting, for the record, that it seems that I could sometimes be replaced by an auto-blogger question-asking piece of software) on what makes the most sense.

    Question:

    How would you have us trade off language conformance (and perhaps language innovation) vs language stability?

    More specifically, when is it acceptable for the compiler to give an error on code that used to work?

     

  • Eric Gunnerson's Compendium

    XML Doc comments and include files...

    • 8 Comments

    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

  • Eric Gunnerson's Compendium

    Exception class, return codes, and messages

    • 12 Comments

    I've had a couple of questions recently about how to architecture libraries with respect to exception handling, specifically related to exception granualarity. Questions like:

    • Is is okay to define an exception with a return code inside of it?
    • How many exception classes should I have?

    The first place to start is the Error Raising and Handling Guidelines from the Design Guidelines for Class Libraries. There is lots of useful information in the design guidelines even if you aren't writing libraries. The guidelines do mention something like "don't use return codes", but that's about it.

    One of the high-value design points when designing exceptions is robustness. The robustness of the customer's code depends directly on the way you structure your exception hierarchy. Here's some code that I've seen. Assume that ApplicationException is the actual type I'm catching, not the base type of a hierarchy:

    try
    {
        // code here...
    }
    catch (ApplicationException e)
    {
        if (e.Message.IndexOf("Database Connection Error"))
        {
             // recovery code here
        }
    }
    

    There are at least two problems with the code, one major, and one a bit more subtle. Do you see them?

    I'll start with the more subtle one first. If your exception messages are localized, it's likely that the string matching will fail. This is a bad bug, because it only shows up in the localized version in an error case, and your tests aren't very likely to catch it.

    The second bug is a whopper. If the exception that comes in isn't a database connection error, it is swallowed by the catch block, never to be heard from again. That's pretty much the worst thing that exception handling code can do.

    The problem is that the exception design has forced the user to look inside the exception to decide what to do. This is bad, whether it be the message text, a return code, or the type of an inner exception that the user is looking for. 

    To prevent this, I'd recommend the following guideline:

    • Make sure that your user doesn't have to grovel inside of your exception classes to find out whether to handle the exception or not.

    One way to determine this is to ask yourself, "Self, would a user ever care about the different cases where ApplicationException is thrown?" In some cases this is obvious, but in other cases, it's not quite so clear. My recommendation is that you err on the side of more granularity rather than less granularity.

  • Eric Gunnerson's Compendium

    PM: Renaming Windows Formsh

    • 4 Comments

    On Tuesday, I asked a question about whether people keep their form class names and form filenames in sync. I'd like to thank all who responded, and provide a little background on the issue. To do that, I'll have to explain a bit about our internal development a process.

    Many of you have probably encountered the problem of "feature creep", where new features keep showing up during development. Feature creep is bad because it throws of your completion estimates, makes it hard for your test team to know what you're planning on building, and generally annoys people. It's especially bad when you have a lot of interdependent teams, and the new feature isn't something you want but rather something somebody else wants, and it gets worse if there are multiple teams depending on you.

    One way to deal with this is to say, "No new features", after you reach a certain point in your release cycle. That would work great if planning was perfect, but it's fairly common to find out that a planned architecture has technical problems, or a new customer need comes to light, or somebody has a great idea, or a usability study shows that your current approach flat-out sucks. Not to mention the "we didn't think of that" factor, which we try to minimize but cannot eliminate.

    Our approach is to provide a standard process known as a DCR (Development Change Request). In a DCR, the PM who owns the feature gets to produce a document that describes:

    • What the issue is
    • Why it's important that we fix it
    • What the customer scenarios are
    • What options there are to fix it
    • The amount of schedule time (for dev, QA, and PM) that it will take to address
    • How we'll get that time (by cutting other features, or, if it's important enough, slipping the schedule to fit it in)

    This usually involves a considerable amount of research by the team, as it's really important to understand the subject deeply, and the research often involves more than one team.

    Once the DCR is written up, the PM (and usually other involved parties) meet with the management team of their product (in our case, it's our PUM, our dev manager, our qa manager, and our group program manager) to present the DCR. The management team will either approve the DCR, reject the DCR, or ask for more data.

     

    In this specific situation, the problem that we're trying to address has to do with the build system. If you've looked at the PDC session abstracts, you may have come across mention of something called MSBuild. MSBuild is a new build system that isn't coupled to the VS project system, which means you'll be able to build your Whidbey projects from the command line without loading VS.

    If you've gone spelunking in your windows forms files, you may have come across a line that says:

       System.Resources.ResourceManager resources = new System.Resources.ResourceManager (typeof(Form1));

    Behind the scenes, the Windows Forms designer has put some form resources in a .RESX file. These resources will get converted to a binary format by resgen.exe, and then put into the assembly as part of compilation. Since there may be multiple forms in one assembly, there needs to be a way to find the right resources for a form. For Windows Forms, the full name of the class was chosen as a key. The project system finds this out by talking to the Code Model, a sort of "mini in-process compiler" that also parses code for intellisense and other IDE features (if you read the PDC session abstracts closely, you'll find a new feature...). The code model tells the project system what the name of the form is, and this is passed to the compiler and used to name the binary resource blob in the assembly.

    The resource manager constructor gets that same name from the type passed into the constructor, uses it to find the correct blob, and things are hunky and hopefully, dory as well.

    Enter MSBuild. It seems like a good idea to be able to build windows forms projects in MSBuild, but there is a problem.

    There is no code model for MSBuild to ask for the form name, and no facility to find that information, so it's DCR time. We've spend the last few weeks talking about different options to solve this, but none of them are great, and we don't have a single candidate that we all like.

    One of the front runners has the bad characteristic of requiring a project file checkout whenever the form class name is changed, which could be a problem if the project file is already checked out exclusively.

    If our users typically rename the form file when they change the class name, then the issue is largely moot, as that rename would also require a project file checkout, and that's why I asked for your feedback.

    Several of the comments talked about the poor state of rename in VS (ie, you can't do a VSS rename from inside VS). I talked with the VSS PM, and he said that they are planning to do rename for Whidbey. Please read that as, "It's likely to show up, but don't get mad at Eric if it doesn't, as it's not his call". I did convey the feedback I got about the quality of the current solution.


     

  • Eric Gunnerson's Compendium

    Naked at Work...

    • 3 Comments

    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

    C# for the Java Programmer

    • 15 Comments

    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

    Apollo 11: Men on the Moon

    • 4 Comments

    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

    Foreign Translations...

    • 3 Comments

    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

    C# IDE: New Features for Whidbey

    • 7 Comments

    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

    The Visual C# Team at PDC

    • 1 Comments

    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

     

    Tuesday

    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

     

    Wednesday

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

                                     (Exhibition hall book store)

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

     

    Thursday

      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

     

    Tuesday

     

    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.

     

    Wednesday

     

    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.

     

    Thursday

     

    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

    Don't write code like this...

    • 8 Comments

    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

    Learning to speak in public

    • 2 Comments

    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

    Deterministic Finalization

    • 0 Comments

    C++ has deterministic finalization. When you declare a stack-based object, at the end of the scope, the destructor is called before other work is done.

    I just finished writing a response on this topic for a customer, and thought I'd share my favorite reference on the subject with you:

    http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572

  • Eric Gunnerson's Compendium

    PDC: New C++ language syntax

    • 1 Comments

    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

    Things My Girlfriend and I have argued about

    • 4 Comments
    One of my favorite pages on the net: http://www.thingsmygirlfriendandihavearguedabout.com/
  • Eric Gunnerson's Compendium

    Welcome to PDC (belated)

    • 0 Comments

    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

    New C# Language specs

    • 1 Comments

    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

    Comcast makes me happy...

    • 5 Comments

    Comcast is planning on raising its maximum download speed to 3Mbps.

    Hope it happens in my neck of the woods...

  • Eric Gunnerson's Compendium

    PDC: By our buttons you will know us

    • 1 Comments
    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

    Read this, or get ready to peel some onions...

    • 1 Comments

    A nice post

  • Eric Gunnerson's Compendium

    Cluetrain

    • 1 Comments

    Apparently, I'm "on the Cluetrain", though strangely, I don't recall boarding, or even buying a ticket.

    There are some interesting points here, and I do think that VS has focused mostly on the "edit and build" side of software development, without taking a larger view.

    Will that change in Whidbey? I think you'll have to wait and see.

  • Eric Gunnerson's Compendium

    SD Times: No Reservations about .NET

    • 1 Comments
    No Reservations about .NET
Page 1 of 1 (23 items)