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.
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.
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…
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.
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:
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.
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!!!");
}
}
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
