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
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 latest in my Managed DirectSound series. This time we talk about how to control frequency, pan, and volume.
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.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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”).
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.
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.
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">
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.
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.
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.
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]
