James Gregory

In my previous post I talked about my exception logging system that I laid to rest. Fortunately for me that doesn’t mean my applications are logless, quite the contrary. I’ll explain…

When I came to terms with my logging system being inadequate and hard to maintain, I began looking for a replacement. To my delight I came across ELMAH written by Atif Aziz. ELMAH is basically a couple of HttpModules and a HttpHandler that intercept any unhandled exceptions from within your application and log them. This is where the fun begins…

Something I’ve always been tinkering with for my ASP.Net applications has been exception logging. I often get irritated when users (or applications) supply me with misleading or incorrect error messages, or at least incorrect directions of how to recreate the error.

I worked for quite some time trying to create a Logging system that would cater for my needs, and I got quite close to doing that. I created a small go-between object for the Trace and Debug logging and wrote that to my own XML file. The idea behind it, of course, was to make it easier for my self in debugging problems, if I could supply my self with all the data that I know I would require to trace an issue then, in theory, I could correct it much more quickly. This took me quite some time to create and of course was not perfect.

Note from future James: There’s nothing practically useful here for you now, this has been long-since made irrelevant; however, it is an interesting insight into what things used to be like! Kids these days etc…

Having a debugger for JavaScript wasn’t part of the browser itself yet, Firebug was the first good example of this and but only came out the year of this post, and Chrome wasn’t a thing for another 4 years. Instead you had to connect Visual Studio to Internet Explorer, and debug JavaScript that way.

Similarly, Visual Studio could debug Stored Procedures. I remember this being particularly painful and involving copy-and-pasting DLLs into various directories in your system. I’m glad we don’t work with Stored Procedures much anymore.

Debugging is a great thing… Often though I’ve dreamt of some greater, more useful debugger. It would have helped if I’d actually gone out and looked for such a thing.

Anyway, I haven’t found a better debugger. I’ve found how to use the current one better! I’ve enabled client-side script debugging, which is fantastic. No more using IE or Firefoxes vague error messages, I can now step through code just as you would VB/C#.Net. The big one for me though has to be the ability to debug Stored Procedures, yes SQL Server Stored Procedures. Breakpoints, step-through, the lot.

Future James note: Again, super cute in a the internet-is-still-small kinda way.

I’m outta there, finally free from the bounds of a supermarket job. I’ve been taken in by Evolution Interactive, a web/multimedia design company.

I’m now a ‘New Media Developer’, nicer than ‘Checkout Assistant’ if I do say so my self. It’s very strange to be in a real job, doing something that I actually want to do (and like doing). This is going to take some getting used to…

Note from James 15 years later: I’m leaving this here because it’s cute and an early example of my experimentation in multiple languages that would serve me well throughout my career. I find the casualness of it amusing now. The download link is long since dead, and who’d want to run a Delphi program that a 20 year old wrote?

While bored yesterday I decided to have a go with programming in Delphi, something which I’ve been intending to do for quite some time now. Anyway, here is the result.

Download CaesarShift.zip 244kb (this download is no longer available, sorry)

It’s a simple cryptography program based on the shifting letters (Caesar Shift) methods. Took me about two hours, not bad to say I’ve never programmed in Delphi before.

Delphi seems nice, I’m not too keen on the syntax of the language though. Its all rather too much like VB for my likings, messy and unstructured. Maybe that’s just me though.