Nice article. As it happens, I have a similar one about debugging - but I think the two are very complementary. Mine approaches things from a different point of view - although they have aspects in common (resting and asking other people in particular - and yes, Stack Overflow is indeed wonderful). It's at http://www.yoda.arachsys.com/csharp/debugging.html if you're interested in a different take on the same topic.
Jon, I agree they are very complementary. I like how you followed up with suggesting more testing after a bug is fixed. I have to admit I'm guilty of skimping on that one. :)
Oh I'm guilty of not following through on many of the things I genuinely believe to be best practice :) I meant to say, btw - an answer in *4 seconds* on Stack Overflow? 4 minutes I can understand, but how could anyone even load the page, read the question, type a single word and hit post within 4 seconds?
I find myself forgetting about step 6, but when I remember to step back for a bit, I'm usually amazed at the progress I'm able to make afterward. Thanks for the article!
4 seconds on StackOverflow actually, what I think some people are doing is just immediately posting a message with just a sentence or less, then going back an editing it. So, after the editing, there are now five mostly similar answers posted (all written at the same time by different people), but that guy's post is on top, so he's the one people up arrow.
Look into using System.Diagnostics.Debug System.Diagnostics.Trace more often! And writing DebugVisualizers, they take some time to build but save soo much time when problems occur. I could probaly almost write a book about them, but I don't understand why those are so overlooked, so many people don't know or use them. And they have been in .NET almost forever. Just catch bugs early, instead of too late (when it becomes an adventure). It's not that hard to build some util class to make it even more easy. And when you think deeply about the concepts they are even very compatible with using unit testing, etc. Sure it's a bit depending on if you are an unit test 'public interface to your app only' or test both public and private methods. It might even be a nice first step towards doing more unit testing. Since adding a few Debug.Assert's is a lot less work than writing unit tests and keeping them up to date. The compiler will just remove all your debugging code when you compile to production. Well at least if you don't modify the standard behavior =) You can even create your own methods and add the debugging attribute to them, which will auto remove them on compiling to production code. So it doesn't cause any speed like issues. And even trace is wonderfull, Trace saved my life a few times already, when looking into some problem that only occurs at the production enviorment. Anyway, I am just too obessed with the System.Diagnostics namespace =) Nice article, certainly a very learningfull article for the startup programmer to quickly learn where to look for solutions and how to solve problems.
All ASP.NET developers need to know about trace.axd. 1. In your web.config, Go to the system.web section and find the trace tag. Make sure the enabled attribute is set to true. 2. Sprinkle statements like System.Web.HttpContext.Current.Trace.Warn(Finished Processing) through your code. This will even work in DLLs that are not in App_Code. 3. Go to your.application.root/.../trace.axd You will be rewarded with all of your trace messages, grouped by the page in which they occurred. This is -super- helpful when you're trying to debug something in production. LEAVE YOUR TRACE STATEMENTS IN PRODUCTION CODE. The very first time this saves your ass you will feel reborn. :)
Interesting. Except the spot where you recommend Spolsky's .NET forum, which is obscure. And no mention of the MSDN forums, which are better for MS questions than even the great and mighty Stackoverflow, and less egotistical. But other than that, good stuff!
Well, I see you mention Channel 9 and ASP.NET which are affiliated. But forums.msdn.microsoft.com is still the best resource in the world for MS-related programming troubleshooting.
Step Six: Walk away. Couldn't agree more. I can't tell you how many well, duh! moments I've had while driving home after a frustrating day chasing an issue!
We are the largest, most professional, specifications most complete air compressor export enterprises in China, with customers all over the world. Denair compressor is with European standard configuration and technology, free of maintenance. We can design and manufacture air compressor according to different working conditions and provide our customer the highest cost performance compressor, air compressor and screw compressor.
Nice article. As it happens, I have a similar one about debugging - but I think the two are very complementary. Mine approaches things from a different point of view - although they have aspects in common (resting and asking other people in particular - and yes, Stack Overflow is indeed wonderful).
ReplyDeleteIt's at http://www.yoda.arachsys.com/csharp/debugging.html if you're interested in a different take on the same topic.
Jon, I agree they are very complementary. I like how you followed up with suggesting more testing after a bug is fixed. I have to admit I'm guilty of skimping on that one. :)
ReplyDeleteOh I'm guilty of not following through on many of the things I genuinely believe to be best practice :)
ReplyDeleteI meant to say, btw - an answer in *4 seconds* on Stack Overflow? 4 minutes I can understand, but how could anyone even load the page, read the question, type a single word and hit post within 4 seconds?
I find myself forgetting about step 6, but when I remember to step back for a bit, I'm usually amazed at the progress I'm able to make afterward.
ReplyDeleteThanks for the article!
4 seconds on StackOverflow
ReplyDeleteactually, what I think some people are doing is just immediately posting a message with just a sentence or less, then going back an editing it. So, after the editing, there are now five mostly similar answers posted (all written at the same time by different people), but that guy's post is on top, so he's the one people up arrow.
Yes, but even to type a single sentence (after loading the question) in 4 seconds is very impressive.
ReplyDeleteHmmm... My gravatar is wrong. I wonder if I type my email wrong. It's definitely right on this message....
ReplyDeleteLook into using System.Diagnostics.Debug System.Diagnostics.Trace more often! And writing DebugVisualizers, they take some time to build but save soo much time when problems occur.
ReplyDeleteI could probaly almost write a book about them, but I don't understand why those are so overlooked, so many people don't know or use them. And they have been in .NET almost forever.
Just catch bugs early, instead of too late (when it becomes an adventure). It's not that hard to build some util class to make it even more easy. And when you think deeply about the concepts they are even very compatible with using unit testing, etc. Sure it's a bit depending on if you are an unit test 'public interface to your app only' or test both public and private methods.
It might even be a nice first step towards doing more unit testing. Since adding a few Debug.Assert's is a lot less work than writing unit tests and keeping them up to date.
The compiler will just remove all your debugging code when you compile to production. Well at least if you don't modify the standard behavior =) You can even create your own methods and add the debugging attribute to them, which will auto remove them on compiling to production code. So it doesn't cause any speed like issues.
And even trace is wonderfull, Trace saved my life a few times already, when looking into some problem that only occurs at the production enviorment.
Anyway, I am just too obessed with the System.Diagnostics namespace =)
Nice article, certainly a very learningfull article for the startup programmer to quickly learn where to look for solutions and how to solve problems.
just writing to let you know I submitted comments to that site.
ReplyDeleteAll ASP.NET developers need to know about trace.axd.
ReplyDelete1. In your web.config, Go to the system.web section and find the trace tag. Make sure the enabled attribute is set to true.
2. Sprinkle statements like System.Web.HttpContext.Current.Trace.Warn(Finished Processing) through your code. This will even work in DLLs that are not in App_Code.
3. Go to your.application.root/.../trace.axd
You will be rewarded with all of your trace messages, grouped by the page in which they occurred. This is -super- helpful when you're trying to debug something in production. LEAVE YOUR TRACE STATEMENTS IN PRODUCTION CODE. The very first time this saves your ass you will feel reborn. :)
Interesting. Except the spot where you recommend Spolsky's .NET forum, which is obscure. And no mention of the MSDN forums, which are better for MS questions than even the great and mighty Stackoverflow, and less egotistical. But other than that, good stuff!
ReplyDeleteWell, I see you mention Channel 9 and ASP.NET which are affiliated. But forums.msdn.microsoft.com is still the best resource in the world for MS-related programming troubleshooting.
ReplyDeleteThanks for the tips you guys (esp Duane who is Cousin Developer), will try it out.
ReplyDeleteVery nice article!!
ReplyDeleteStep Six: Walk away. Couldn't agree more. I can't tell you how many well, duh! moments I've had while driving home after a frustrating day chasing an issue!
ReplyDeleteOh I do hope to visit some day! What a great place to work!
ReplyDeleteBlessed be God, the Father of Christ Jesus our Lord, who in Christ has blessed us from heaven with every spiritual blessing.
ReplyDeleteI did not discuss that particular issue!!
ReplyDeleteWe are the largest, most professional, specifications most complete air compressor export enterprises in China, with customers all over the world. Denair compressor is with European standard configuration and technology, free of maintenance. We can design and manufacture air compressor according to different working conditions and provide our customer the highest cost performance compressor, air compressor and screw compressor.
ReplyDeleteI meant to say, btw - an answer in *4 seconds* on Stack Overflow? 4 minutes I can understand, but how could anyone even load the page
ReplyDeletei'm a .netor and i was learning .net glad to see you!
ReplyDelete