July was officially too hot for blogging. That's my excuse, anyway.
I was also spending most of the month adapting my body to the idea that 6am is a civilised time to wake up. It turns out, I am capable of functioning as a fully mobile human being at seven in the morning. Who'd have thought?
The reason for the self-imposed jetlag is, of course, my new job. I've left the maintenance treadmill of bespoke systems integration and got myself a position with a fast-growing ISV, working on their web platform and internal tools. The office is in Oxfordshire, hence the early starts, but the job, the working environment, and the team are all - so far - compelling enough to justify the daily drive.
So I've been getting stuck into some serious JavaScript and ASP.NET development again, at last. It's great to spend all day in VS and a web browser again, rather than up to my neck in T-SQL glue scripts and batch jobs. It's especially great to have joined a company where, whenever I say something like, "You know, if we did this, we'd be able to do that...", the response hasn't been, "You're right, but we don't have the budget right now" - instead, it's been more like, "That would be great! Do it!"
They also use good tools. We've got FogBugz and Subversion and a MediaWiki intranet site - all fantastic tools for the job. In the development team we're using CodeRush and Refactor!, which keep astonishing me with the ways they speed up my coding. And any day now I'll get used to the fact that it automatically inserts the brackets when I type 'if' so I won't keep writing code that says 'if ((value != null))'.
When necessary, though, they're not afraid to build their own, and indeed a fairly big part of my job is working on tool development. So there's installation tools, a bespoke build server, some neat little database management tools, and some really complex windows forms apps that are used to manage and develop websites built on our core application platform. I've also had a chance to play around with DXCore extensions for Visual Studio (I threw together a little extension to highlight naming convention violations, for example), and I'm looking at building out some test hooks on the core application code that will marry up to some Selenium extensions to enable automated functional web testing. All part of building up a custom toolset that lets us add complex features more easily, reliably, and efficiently.
And in the spirit of tool integration, today I added a little feature to our application error page that I thought was worth sharing. When the application is compiled in debug mode, if you run into an unhandled exception, our error page dumps out a stacktrace to the browser along with the usual friendly error message. This is the usual helpful .NET information, including filenames and line numbers, but they're over in the web browser window. Wouldn't it be great to have a quick way to jump directly to the source of the error in Visual Studio without having to dig out the source file, and navigate to the line number?
Well, it turns out, you can make a quicker way. Just before it dumps out the stacktrace to the browser, I stuck in a few lines of code that:
- Check whether there's a debugger attached (System.Diagnostics.Debugger.IsAttached)
- If so, pull out the filename and linenumber information from the error stacktrace
- Log a message to the debugger (System.Diagnostics.Debugger.Log) in the form "<FILENAME>(<LINENUMBER>):"
- Log the rest of the stacktrace information to the debugger
Now, if VS is attached to the ASP.NET process, whenever an error occurs, as well as the error page popping up in the browser, I get the stacktrace dumped to the debug output window, plus those formatted filename and linenumber lines. Now, those lines are special, because VS.NET interprets output lines in that format as references, and if I double click them, it navigates me directly to the sourcecode line referenced - boom, straight to the crux of the matter.
So now, when I hit an unhandled exception, I just switch to VS.NET, open up the debug output, double click at the top of the stacktrace to go right to the source, set a breakpoint, and refresh the browser to get a debug break right at the location of the exception. Saves a few minutes every day, at least. And that means I can get into the queue on the A34 that much sooner.