One thing I didn’t realize about CruiseControl.NET until recently was that it automatically labels your builds. It uses a
We still need to get our continuous integration setup working again, but in the interim, manual labeling of releases is still helpful.
This week, an application I work on started logging an exception that provided no help at all in debugging the problem. My usual practice of running the app in debug mode with production values in the config file failed to reproduce the error too. After a couple of days of checking a bunch of different areas of code (and still not solving the problem), Bob (a consultant from Intervention Technologies) gave me some code to get at all the InnerException values for a given Exception. Download the function from here.
StackTrace can be pretty large. Since we log to a database, I was worried about overrunning the column width. I also wasn’t keen on the idea of looking at so large a text block if an Exception was nesting four or five additional ones. So instead of implementing the code above, I changed the code to log at each level. Doing it this way adds a log entry for each InnerException. Because the log viewer I implemented displays the entries in reverse-chronological order, the root cause of a really gnarly exception displays at the top. The changes I made to global.asax looked like this.
The result of this work revealed that the app had been complaining about not being able to reach the SMTP server to send e-mail (which it needs to send users their passwords when they register or recover lost passwords).
Once we’d established that the change was working properly, it was time to refactor the code to make the functionality more broadly available. To accomplish this, I updated our Log4Net wrapper like this.
When I first started developing solutions on version 2.0 of the .NET Framework, I saw examples that had some logic in the App_Code folder. For things like base pages, I thought App_Code was perfect–and that’s how I use it today. When I started to see applications put their entire middle tiers in App_Code however, I thought that was a bad idea. Beyond not being able to unit test your components (and the consequences associated with a lack of unit testing, coverage, etc), it just seemed … wrong.
Fortunately, there are additional reasons to minimize the use of App_Code:
I was at the San Jose Airport waiting on a flight to Los Angeles when this earthquake hit. It didn’t register with me that an earthquake was happening until a few seconds went by and I saw the walls and ceiling moving more and more. Everyone in the terminal (including me) dashed toward the nearest doorway or arch they could find. It was quite a scary experience, and one I hope never to repeat.
I spent a few hours this afternoon making chocolate at the Cacao Anasa kitchen. My friend Peter invited me to the third of these events since I’m in town for a conference. If it’s possible to have more fun in a kitchen, I’m not sure how. We made (and ate) truffles, cookies, chocolate bars, chocolate soup, and a bunch of chocolate-flavored drinks (spicy hot chocolate, and an assortment of stronger beverages).
Now that I’ve had freshly-made chocolate from my own hands, I’m sure I’ll be a lot more picky about what I buy.
The CEO/owner of Cacao Anasa, Anthony Ferguson, gave us a great education on the making of chocolate (and some of the health benefits). Before today, I would never have known that chocolate is actually tempered, not unlike steel. His biography is even more impressive than the great chocolate.
I came across this post about debuggers today. I found it a lot more nuanced than the Giles Bowkett post on the same topic. The part of the post I found the most useful was when he used the issue of problems in production to advocate for two practices I’m a big fan of: test-driven development and effective logging.
I’m responsible for an app that wasn’t developed using TDD and had no logging at all when I first inherited it. When there were problems in production, we endured all manner of suffering to determine the causes and fix them. Once we added some unit tests and implemented logging in key locations (global.asax and catch blocks primarily), the number of issues we had dropped off significantly. And when there were issues, the log helped us diagnose and resolve problems far more quickly.
The other benefit of effective logging is to customer service. Once I made the contents available to a business analyst, she could see in real-time what was happening with the application and provide help to users more quickly too.
Whether you add it on after the fact or design it in from the beginning, logging is a must-have for today’s applications.
Buried deep in this Giles Bowkett post is the following gem:
“Tests are absolutely not for checking to see if things went wrong. They are for articulating what code should do, and proving that code does it.”
While it comes in the midst of an anti-debugger post (and an extended explanation of why comments on the post are closed), it is an excellent and concise statement of the purpose of unit tests. It explains perhaps better than anything else I’ve read the main reason unit tests (or specifications, as the author would call them) should be written before the code.
If you use strongly-typed datasets in .NET, you’ve encountered the dreaded “Failed to enable constraints …” message. I most recently encountered it this morning, while unit testing some new code. There were far fewer search results for the phrase than I expected, so I’ll add my experience to the lot.
The XSD I’m working with has one table and one stored procedure with four parameters. A call of this stored procedure (via a method in a business logic class) returns a one-column one-row result set. My code threw a ConstraintException each time the result set value was zero (0). To eliminate this problem, I changed the value of AllowDBNull attribute of each column in the XSD table from False to True (if the value wasn’t True already). When I ran the unit tests again, they were successful.
I’ll have to research this further at some point, but I think part of the reason for ConstraintException being thrown in my case was the difference between the stored procedure’s result set columns and the table definition of the associated table adapter.
In any case, setting AllowDBNull to True is one way to eliminate that pesky error.
This Roy Osherove post surprised me because I hadn’t been aware of so many different interpretations of the idea before. Because I’ve always believed in at least some design up front, my understanding of TDD was the first of four mentioned:
“Test Driven Development: the idea of writing your code in a test first manner. You may already have an existing design in place.”
The fourth interpretation of TDD applies pretty well to what I do now whenever I inherit an application. Writing unit tests of the middle tier(s) of the application (if none exist) has proven to be very helpful whenever I’ve done this. Adding new features becomes easier, and regression testing becomes much easier.
This entertaining Phil Haack post on inherited code definitely tells the truth when it says:
“Here’s the dirty little secret about being a software developer. No matter how good the code you write is, it’s crap to another developer.”
Until I read this post, I hadn’t even thought about the thousands of lines of code I’ve left behind at various employers and how my successors regarded them. I remember getting very positive feedback from a colleague who wrote the .NET replacement for my VB6/COM+/SQL Server 2000 implementation of our online recruitment tool, but that’s it. My usual reaction to code I’ve inherited has rarely been empathetic. Phil’s right in trying to be more understanding.
And to anyone who has inherited my code in the past, I hope I didn’t make your job too hard.