I have finally upgraded my blog from 1.5 to 2.5.1, which went quite smoothly. If I knew it was going to be this easy, I would have done it a long time ago and save myself some work. I had no idea so much crap was secretly posted to the blog and if you find more or anything else that has stopped working, please let me know.

I would also welcome a tip from fellow wordpress users on how to turn rich-text editing on. It’s hard to imagine that it simply doesn’t exist.

I was recently discussing how I think all code, especially mine, is crap and since this position has been and likely still is controversial, it might not be a bad idea to discuss it a bit more. This likely won’t avoid grievances and disputes, but it might save me some work in explaining myself.

I’ve never written a non-trivial amount of code that I wouldn’t find at least a bit embarrassing two years later. Partly because of my own deficiencies as a programmer, partly because our craft evolves and does so rather speedily. Even if I was as good a programmer as I would like to be, our profession would still develop and my code would eventually become crap. It would just take a bit longer than it does now. In a way, with maybe few exceptions, all code left alone is on natural trajectory to a state of crappiness.

Personally I don’t find this insulting. If anything I would be terrified to discover that my old code doesn’t bug me at all. I would see it as a signal that I haven’t developed my craft much in this time. You haven’t peaked until you stagnated .

There are also other benefits to this position. Since I find my code at least a bit dubious, I’m not enamored with it to the point, where I would find it difficult to ditch it if need be. It helps me being more detached and rational about its merits or lack thereof.

In contrast with what I just said, it also helps me from scraping it too soon. Accepting that some level of crappiness is a given, I don’t feel as much need in reformatting, refactoring or rewriting code that offends my sensibilities. I like reading pretty or even inspirational code as much as the next programmer, but esthetics are not too important. As long as code is functional, bug-scarce, maintainable and generally usable enough, it’s also pretty enough.

So if you happen to hear me insensitively remarking that some code is crap, please try to keep in mind that my completely universal belief means it’s not meant to be personal or even negative. I likely regard your code and skill higher than mine. I am truly sorry, if you nevertheless feel bad about it.

Debugging web applications used to be simple. You generated a page and sent it to client. Visitors performed actions and you got back their response. Since filling a form was practically the most complicated action they could perform, it was relatively easy to find bugs if you were smart enough to include debugging support on server. You just had to trace user’s steps to find the one where things went amiss.

Javascript heavy applications changed that. Now a lot of action is happening far from your eyes and even when application does communicate with a server, it might just be a request to store or fetch more data without any hints about what’s happening over there. That’s fine and we are all happy as long as everything works. Too bad that sooner or later it usually doesn’t.

That’s why I decided to write a simple debugging support I can plug in my older projects that I still need to support and use in any upcoming ones that could benefit from it.

Goals

I want my script to have the following characteristics:

• be short and simple enough so I can rely on it not to be a cause of new problems
• it can be triggered through Javascript or by manipulating URL
• adaptable to different scenarios
• it avoids unnecessary replication by supporting Firebug’s logging calls

Point two in the list means I should have a choice between automatic start of debugging by changing URL a bit or through Javascript at the time of my liking. This way I’m free to choose the best way and moment to debug my application.

By adaptable I mean I have free hands when it comes to how much gets logged, how far back do I keep logs and how does that information get sent to me.

Supporting Firebug means that its logging calls are used. So same debugging calls that might have been used during development can also be used for debugging problems in deployed site and don’t bother script execution in non-debug mode.

Implementation

Here’s result , packed in around 100 lines of code. It should be included at the top of your Javascript code or as quickly as you’d like to use it. I think it’s pretty self-explanatory, but you can also look at demonstration page described a bit later.

Debugging is stored in an object window.console and gets started by either including dbg=true parameter in URL or calling window.console.debugStart method. In later case you can provide the method with a function as first parameter that gets called on Javascript error or when we stop debugging with a call of window.console.debugEnd .

We can provide the same function by assigning it to window.console.debugDisplay . It gets called the same way with one parameter of an array of debugging messages. It’s completely up to it to decide what to do with that information and what value to return, but return values have the same meaning as they have in window.onerror handler. If processing Javascript error, true means that error was processed and script can continue and false will lead to error message dialog box.

window.console.debugStart can also receive a parameter object with attributes level , count and callback for debugging level, number of saved messages and debugDisplay function respectively. Level and message count can also be set through URL by providing parameters dbglevel and dbgcount .

Demo

You can see final result called in two ways. Using modified URL , where debugging parameters are set through URL, and the one , where debugging isn’t turned on by default. It’s same page in both cases and so is mostly its behavior.

In first case we start fetching debugging messages immediately and display them with a press on End debugging . We can’t restart debugging in this scenario, but we can in second case.

In second case we start and continue debugging with a press on Start debugging button, that got displayed in the first place because window.console.on was set to false . window.console.on is a Boolean that shows if debugging is currently turned on or off.

In both cases only messages of requested levels get saved.

Discussion

Even though I tried to leave things as open to extending as possible, I mainly tried to cover use cases I already encountered. Therefore this script, as it is, doesn’t support graceful handling of browser crashes, which it could, if it saved debug information to local storage when available.

Script also doesn’t support loading different libraries in debug mode. That is, if you want to load libraries stripped of debugging calls when not debugging, you can do that yourself, using window.console.on . This script won’t do it for you.

I do provide a skeleton debugDisplay in case you don’t provide one yourself. If you don’t, then debug message gets displayed using alert , which makes it hard to copy and paste, but easy enough to make a screenshot of. Setting debugging level is probably not as nice as it could be too.

It’s not completely stupid though, takes note of Array object’s suitability mainly for sparse and small arrays and should perform adequately when it comes to memory consumption even with new IE8 as long as count parameter isn’t too big.

At the end, it’s a piece of code as any I’ve written. Bugs are likely, so bug reports would be appreciated. Same goes for ideas and suggestions. If you need it, feel free to use it any way you want, but I would appreciate a ping just to see where my stuff ends up.