Saturday, August 30, 2003

Managed DirectSound - Working with 3D Sound

It was a long, long, long plane ride over here – about 20 hours. On the way, I wrote up the next DirectSound tutorial. It’s about positioning sound in three dimensions. You can find it here

I figure I’ll do one or two more tutorials on DirectSound to finish the series up for now, then return to Direct3D. I’ve been looking at vertex and pixel shaders recently, and they look pretty cool.

Wednesday, August 27, 2003

Off to Taiwan




I’m leaving today for Taiwan. I’ll be there for a couple of weeks, so
if I’m a bit light on the blogging, you’ll know why.



Tuesday, August 26, 2003

Publishing to MSDN Said Too Hard

Don blogs that  Jon Udell writes that blogging is easier than publishing to MSDN, and that since content seeks the path of least resistance, people tend not to write for MSDN. Well, what if there was an XML-based infrastructure behind MSDN with an API surfaced in such a way that people could write tools to insert and extract content in a web services metaphor? Hmm…I wonder if anyone is working on anything like that? ;)

Of course, this effort would take a while to complete, but if it was happening, you’d certainly want a super-bright, XML-focused person involved to make sure it got done right. If only he would blog more…

Saturday, August 23, 2003

The Circle of (Software) Life




So, I've recently made a conscious decision to not install Visual Studio.NET
on my new machine. I'm running Cygwin and Emacs,
building with NAnt, and doing source control
with CVS. Basically, I want to see how far I
can take it. Right now, I'm loving it, despite the fact that I've already found a
few bugs.



The thing is, I know eventually, when there's a new version of Visual Studio.NET,
or the version after that, or the version after that, I'll love that just as much.



It's a pattern I've seen in myself over and over again, and which I've observed particularly
in bright, technical people: “new” is way more interesting than “current”
or “old” . The phases go something like this:



1)      What
I'm using right now sucks! This bug and that bug are killing me.



2)      Hey,
here are about twelve other things that do something similar.



3)      Wow,
these eleven suck even worse.



4)      Hey,
this one is pretty cool…



5)      Wow!
This feature is awesome! How could I live without it?! (repeat several times).



6)      Period
of quiet contentment.



7)      D'oh!
First major/minor bug!



8)      OK,
I'm used to working around that.



9)      D'oh!
Another major/minor bug! (repeat serveral times).



10)  Eventually, goto 1. :)



In other words:



·        Features
that work escape our notice after we're used to them



·        Bugs
jump right out at us



·        Even
subtle bugs jump out after continued usage



·        Therefore,
over time, most software becomes annoying



Also note:



·        Most
software sucks so bad it doesn't even make it into the above loop.



I don't expect that my move to a more Unix-like environment will ultimately prove
to be better overall than my MSFT-only existence has. However, changing the
set of issues I run into is what keeps my brain engaged.



Thursday, August 21, 2003

Global Error Handling in ASP.NET

Brad Wilson has a response to my recent post. Here’s an excerpt:

I read Craig Andera's post about global error handling in .NET, and I thought I'd give an alternative implementation for global error handling.

We use a system like this to catch all unhandled exceptions, e-mail them to the admin, log them to the Event Log, and then give the user our own version of an "Internal System Error" page.

The HttpApplication object class contains an event called Error. This event is issued whenever an unhandled exception occurs. The exception that has been thrown is available via Server.GetLastError(). The easiest way to do this is by making a new class that overrides IHttpModule and registering it in Web.config, like so:

[The .NET Guy]

I like this a lot, and I think both techniques are valuable tools to have in your error handling arsenal – the way Fritz showed me gives you the ability to do per-page error handling, and Brad’s approach gives you application-level error handling. I plan to use both, especially since Brad’s way lets me catch more types of errors. On top of that, clever use of EIF can allow me to switch log messages for each of them on and off independently.

 

 

Handling Errors in ASP.NET

 The other day, I was working through some code, adding error handling. We use the Enterprise Instrumentation Framework to do this (oddly only available via MSDN Subscriber download at the Universal level). When I got into the ASP.NET web pages I’d written, I had a bit of a problem. I didn’t really want to add try/catch blocks around every single method in the page’s base class – that would be a little redundant, and would mean that I’d have to change code in a bunch of places if I decided to change the style of errors I was reporting.

This is where it pays to be friends with Fritz Onion. :) I pinged him, and he suggested a clever little hack (in the good sense of that word) to put all my error handling code in one place.

The trick is to re-implement IHttpHandler on the page class itself. Since IHttpHandler::ProcessRequest is the one entry point for all requests into the page – whether that’s a callback handler for an event from the client or the initial Page_Load call – I could simply delegate back to the Page class’s ProcessRequest, but catch any errors that came out of it. One place to put all my high-level error handling. And I could even rethrow the exception if I wanted to still use ASP.NET’s built-in error handling.

It goes something like this:

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

public class Default : Page, IHttpHandler
{
  public void ProcessRequest(HttpContext ctx)
  {
    try {
      // Let the Page class itself handle the processing, as usual
      base.ProcessRequest(ctx);
    }
    catch (Exception e) {
      // Log it here – event log, EIF, whatever

      // Use our own error page or simply re-throw
      ctx.Response.Redirect("myerror.aspx");
    }
  }

  public void Page_Load(object o, EventArgs e)
  {
    throw new ApplicationException("Whoops");
  }

  public void Button_OnClick(object o, EventArgs e)
  {
    throw new ApplicationException("Aiieeeee!!!");
  }
}

Wednesday, August 20, 2003

Give It a Good Whack




We all know what the solution to hardware problems are: a swift - literal - boot.
So when my Dell Inspiron 8100 refused to let me type the letter ‘a’ any
more, I simply took the damn keyboard apart and put it back on. Working great now.
Of course, the speakers don’t seem to work any more, but that’s a trade
I’ll make any day of the week.



This is just the sort of thing one wants to happen before one takes one’s computer
overseas for a couple of weeks. The cool thing is, I found some
instructions
on Dell’s website on how to take the keyboard off. There’s
some other maintenance stuff there, too. Which is handy now that I’ve completely
voided the warranty. :p



Monday, August 18, 2003

Dealing with Missing Assemblies

The other day, Sergey Vlasov asked me how to deal with the absence of the Managed DirectX assemblies on the target computer. It’s a great question, because – as more and more people work with Managed DirectX – applications are going to have to be prepared to run on machines that may have older versions of DirectX installed. Since Managed DirectX is new with DirectX 9.0 – and since it’s possible to install even DirectX 9 without the managed pieces – the absence of, say, Microsoft.DirectX.Direct3D.dll is a real possibility.

And this isn’t just a problem for DirectX assemblies. In general, it should be possible for applications to gracefully degrade when faced with a missing component. There are many definitions of “graceful degradation” – whether that’s throwing up a dialog box, emailing tech support automatically or downloading and installing the missing pieces depends on the application. But regardless, you have to know how to recover when your application tries to load an assembly and fails.

Anyway, as I was writing up this entry, it got a bit longer than I thought it would. So I decided to put it in with the rest of my articles. Read the article here.

The Nigerian SCO Connection

If you've been following the SCO lawsuit at all, you might have gone through the phases I did: "Wow, this sounds like bad news for Linux!" followed some time later by "Wow, SCO must be desperate to pull this sort of lame stunt."

Well, I'd say that this pretty much nails it on the head. :)

Friday, August 15, 2003

Rebuilding MSDN




As you may know, I'm a consultant. Right now, my main clients are Microsoft (you've
probably heard of them) and Integic (you might not have heard of them). Both of them
have some pretty interesting projects going on. I'd like to talk a bit about the one
at Microsoft.



 



I mentioned previously that I'm doing work for MSDN but that I wasn't allowed to talk
about it. Well, I've gotten clearance to mention a few things, so I'm here to share.



 



The project I'm involved in has already been mentioned a few times - both Tim
Ewald
and Sara
Williams
have talked about it in their blogs. The basic idea behind what we're
doing is to rebuild the parts of MSDN that need building, starting - where necessary
- from the ground up.



 



This is exciting for several reasons:



 



1) Tim has an all-XML vision for the system that is going to enable MSDN to provide
some interesting services to developers.



2) The team has some serious technical talent, and a few of them are old friends of
mine.



3) msdn.microsoft.com is obviously a gigantic, large-scale website, and I've always
been interested in the far end of that particular spectrum.



4) I've never worked on a Microsoft project before this.



 



The part we're tackling now involves developing a system for the people that produce
and manage content at MSDN to more easily and quickly get that content out to the
public. And for the public to more easily, reliably, and flexibly access that information. 



 



I don't want to go into all the details of the system today - some things we're still
figuring out, some things will change, and some things might get dropped - but I have
permission to say more in future posts. And I will.



 



 



Tuesday, August 12, 2003

My Favorite VS.NET Shortcuts




I’m a keyboard kind of guy. I hate it when I have to put my hands on the mouse – it
slows me way down. So it should be no surprise that I’m a fan of emacs – keystrokes
for everything. Still, I tend to use VS.NET, because it’s got a bunch of stuff that
I can’t get (yet) in emacs, like Intellisense and integrated debugging.



As a result, I’ve made an effort to learn VS.NET shortcut keys. I find myself often
pointing these out to fellow developers, especially when I’m suffering, watching them
laboriously navigate the menu system or type with one hand. Here are my favorites.
Some of these have already made the blogging rounds, but hopefully you’ll find at
least one gem in here


















































































Key sequence




Command




Description




Ctrl-minus




Source “Back”




Works like your browser’s “back” button – takes you to the last line of code you were
looking at, whether it’s in a different file or the file you’re currently in.




Ctrl-shift-minus




Source “Forward”




Works like your browser’s “forward” button. Opposite of ctrl-minus.




Ctrl-k Ctrl-k




Toggle bookmark




Adds or removes a bookmark to the current line. I use this one frequently when adding
a using statement to the current file. Set a bookmark so I don’t lose my place, go
to the top of the file (ctrl-home), add the using statement, then jump back to the
bookmark.




Ctrl-k ctrl-n




Go to next bookmark




Navigates to the next bookmark. Because this gets annoying when there are lots of
bookmarks in the file, I generally toggle the bookmark off as soon as I get back to
it.




Ctrl-i




Incremental search




Incremental search is a great way to search really quickly: you type ctrl-i and then
immediately start typing the word you’re looking for. As you type each letter, VS.NET
will find the first instance of what you’ve typed so far. So, for example, if you’re
looking for “foo”, you type ctrl-i, then “f”, and it will find the first instance
of “f”. Then you type “o” and it will find the first instance of “fo”. If that’s “foo”,
you’re done. If it’s “for” you can either type “o” again to look for “foo” or type
ctrl-i again to look for the next instance of  “fo”. Emacs has had this forever,
but it’s nice to have it in VS.NET, too.




Ctrl-a Alt-e v b




Select all, Untabify




Turns all tabs into spaces. Useful when I’m pasting code into an email or Word.




Ctrl-a Ctrl-k Ctrl-f




Select all, reformat




Ctrl-k ctrl-f will “reformat” the selection, making sure all the code is properly
indented and even “fixing” which line the curly-braces appear on (you can set your
definition of “correct” in VS.NET preferences).




Ctrl-k Ctrl-c




Comment selection




Puts “//” comments in front of whatever text is currently selected.




Ctrl-k Ctrl-u




Uncomment selection




Removes “//” comments from the front of whatever text is currently selected




Ctrl-J




List members




Pops up the Intellisense list that you normally get when you hit “.” after a variable.
Very useful if you’ve navigated away from the list and you want to get it back.




Ctrl-shift-space




Parameter Info




Pops up the method information list you normally get when you hit “(“ after typing
a method name in. I use this all the time, as I often start typing in the method’s
parameters, then have to go do something else, like read the help. When I come back,
this key sequence lets me pop up the completion list again.




F12




Browse definition




Jumps to the definition of whatever the cursor is on. Useful for when you’re thinking,
“Umm, what does this method do?” Combine with ctrl-minus to jump right back to where
you were.




F7




View code




VS.NET often insists on showing me the stupid designer view when what I want to see
is the code. F7 shows me the code.




Shift-F7




View designer




Sometimes I actually do want to see the designer. This will show it to me when
I’m in the corresponding code file.




Those are the main ones that I use day-to-day. There are many, many more – I find
it really useful to browse through the Tools->Customize->Keyboard dialog every
once in a while, looking for good ones (the keyboard shortcuts show up in “Shortcut(s)
for selected command”).



Monday, August 11, 2003

More on VS.NET XML Intellisense




Astute reader Ross
Donald
points out this
article
in MSDN, which talks about some of the VS.NET-specific schema extensions
you can use to make your XSD more VS.NET-friendly. Ross has also created
a schema
for editing XSLTs in VS.NET…with Intellisense.



Saturday, August 9, 2003

Primate Programming




Quote:



"Humans and higher primates share approximately 97% of their DNA in common. Recent
research in primate programming suggests computing is a task that most higher primates
can easily perform. Visual Basic 6.0™ was the preferred IDE for the majority
of experiment primate subjects." 



Site:



http://www.newtechusa.com/ppi/main.asp



Amusing.



Thursday, August 7, 2003

Schema Intellisense in VS.NET

The other day, I was playing around with Microsoft’s Enterprise Instrumentation Framework (EIF), and I got to wondering how it was that VS.NET “knew” about the schema for the configuration files. You see, it was giving me Intellisense in the XML editor, letting me know what elements and attributes were legal to appear as children of whatever element I was inside. Very cool.

I thought maybe it was going to the namespace URI and downloading the schema, but opening a browser and pointing it to the URL in question yielded nothing, so that couldn’t be it. After a bit of poking, I discovered that what it was doing was looking in a particular directory for schemas. On my machine, that directory is C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Packages\schemas\xml. This morning I whipped up this new schema:

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema targetNamespace="http://staff.develop.com/candera/schemas/IntelliSchema.xsd"

                  elementFormDefault="qualified"

                  xmlns:mstns="http://tempuri.org/XMLSchema.xsd"

                  xmlns:xs="http://www.w3.org/2001/XMLSchema"

                  xmlns="http://www.w3.org/2001/XMLSchema">

  <xs:element name="foo">

    <xs:complexType>

      <xs:choice minOccurs="1" maxOccurs="unbounded">

Tuesday, August 5, 2003

Estimating System Load

A client of mine asked me to estimate how many users a single machine could support when running a prototype I’d written. It’s a question I’d often been asked before, but just infrequently enough that I always had to sit down and think through the answer. So I finally decided to write down the method I use. I’ve posted it here.

Monday, August 4, 2003

When Is a Throw Not a Rethrow?




There’s something I ran into recently that even experienced programmers can
get wrong. We were adding error handling to something, and I saw this in the code:



catch (Exception e)

{

    LogError(e);

    throw e;

}



The idea being that we log all errors in our components, but then throw them again
to let the higher level systems actually figure out what to do. This works well. The
problem comes in with the throw – it actually works much better to do this:



catch (Exception e)

{

    LogError(e);

    throw;   // Rethrows the exception we just caught


}



Notice the absence of an argument to the throw statement in the second variation.



The difference between these two variations is subtle but important. The second variation
is the only one that actually re-throws the original exception. Meaning that
the exact same information is passed along up the stack. With the first variation,
the higher level caller isn’t going to get all the information about the original
error. For example, the call stack in the exception is replaced with a new call stack
that originates at the “throw e” statement – which is not what we
want to record.



Sunday, August 3, 2003

Managed DirectSound Tutorial

Well, I’m back from Redmond. It was a good trip, despite the eleven-hour days we averaged. Next time we’re not letting Don Box pick the movie (Tomb Raider 2 was terrible). ;)

While I was on my way out there, I started a new thread in my Managed DirectX tutorial series: Managed DirectSound. DirectSound is a lot easier than Direct3D, at least to get the basics right, so this one actually gets us all the way to making things come out of the speakers. In future editions, I’ll cover how do control the sound more precisely (volume, balance, playback speed) and eventually get into 3D sound and sound effects.

Friday, August 1, 2003

I made a difference




 Ted Neward posts this
interesting story
showing how real-world security has nothing to do with just
installing a firewall:




Two weeks ago, I taught a Guerilla .NET course for DevelopMentor in Boston. Two
or three days ago, a student who listened to me rant about SQL Injection attacks during
the Code Access Security module lecture sent us (myself and the other two instructors)
the following. It's obviously been edited to protect the guilty…



 [The
Mountain of Worthless Information
]