Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

This is a special edition of Weekly Concerns, in that I'm attempting to cover the recent dust up over TDD that was triggered by DHH and responded to by several notable developer pundits. Note that I respect all of the developers in this conversation and I believe they are all making important points, but the way they communicate can be somewhat... abrasive... so make sure your jimmies are secure before you start reading.

• April 22: David Heinemeir Hansson's opening keynote at railsconf which lays the groundwork for...
• April 23: TDD is dead. Long live testing. by David Heinemeir Hansson.
• April 25: Monogamous TDD by Uncle Bob Martin.
• April 29: RIP TDD by Kent Beck
• April 29: Test-induced design damage by David Heinemeir Hansson.
• April 30: TDD, Straw Men, and Rhetoric by Gary Bernhardt. First DAS blog post in years.
• April 30: When TDD doesn't work by Uncle Bob Martin.
• April 30: Slow database test fallacy by David Heinemeir Hansson.
• May 1: Test Induced Design Damage? by Uncle Bob Martin.
• May 1: The TDD Divide: Everyone is Right by Cory House.
• May 2: Professionalism and TDD by Uncle Bob Martin.
• May 3: A remix of Professionalism and TDD by Gregory Brown.
• May 9: Is TDD dead? Part 1 panel discussion on Google Hangouts with David Heinemeir Hansson, Kent Beck, and Martin Fowler.

Lots of others have weighed in, of course, in blog posts and on Twitter. This type of discussion has been going on since Kent Beck wrote his TDD book; I believe it will continue long into the future. So I guess it's probably a good time to reread Jim Holmes book "Best Practices in Software Engineering and Testing", which is no longer available, but I will reprint in its entirety here (completely from memory, so forgive me if the phrasing isn't quite right):

"Use your brain."

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Having been almost a month gone from Zimbra (aka Telligent), I'm starting to remember and notice some things that I've previously taken for granted.

One of the axioms that was drilled into me in my early days at Telligent was "no ticket, no work". Which is to say, if it's not work that's been defined and entered into the backlog and approved for work and ready to be tracked, then don't do it. There are several benefits to this approach. One is that it tends to address gold-plating and adhoc features (since I have to take the time to think about something and communicate it to the team).

But one of the things about this approach that I definitely took for granted was how this helps with tracking. For every commit I did to source control, I had to put the ticket number in the commit message. The tracking system we were using just happened to have the ability to integrate with source control, which was nice. But even if it didn't, as long as I know the ticket number, I could very easily search the commit logs and see what code changes were made for the ticket in question. This made code reviews, retrospectives, conflicts, documentation, bug fixes, etc so much easier.

It doesn't cost you but a few seconds to put the ticket number in your commit message, and a few more seconds to put in a decent commit description while you're at it.

Read GitHub language trends and the fragmenting landscape.

Here's a quote from that article: 

Both C# and Objective-C are unsurprisingly almost invisible, because they’re both ecosystems that either don’t encourage or actively discourage open-source code

I don't know if I could agree that either are being "actively discourage[d]" (certainly Jeremy Miller has some thoughts on the matter).

BUT, what I want to tell you today is: put your C# code on to GitHub today! Even if you don't think it's very good, it might help someone, it might help you get some more experience with git and GitHub, and it will certainly help bump up that C# graph.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• 10 Mistakes that C# Programmers Make, from Toptal.
• The user is drunk - how to think about UIs by picturing a drunk user...
• ...which reminds me of the $5 Guerrilla User Test - buy someone a drink at a bar and observe them try to complete tasks...
• ...which reminds me of Steve Krug's excellent book, Don't Make Me Think, which is now in its 3rd edition.
• Video of Brian Cavalier presenting "AOP-ing your JavaScript" at SpringOne2GX 2013.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

I'm starting to wind down this blog post series. A couple more tweaks and you'll be all caught up with how I'm using this aspect in a system that I'm actively working on right now.

But first, let me address some of the criticism that I've received in comments, reddit, and so on.

Mainly, the criticism about my aspect making the return value be an empty collection (instead of null) if the return type is a collection. I totally expected this criticism, and I definitely think it's fair. I pondered this idea a lot myself before I came to the conclusion that I did, and it's entirely possible that I'll change my mind later. So, if you are following along, and thinking about creating an aspect like this, you should definitely think carefully about doing this; don't just copy and paste my aspect and call it a day.

I think it comes down to a choice: do I want to always be checking for nulls, or when there's a collection can I just assume that it will (at worst) be empty? I based my decision somewhat on the Framework Design Guidelines - my API should return an empty collection (or array) instead of nulls. My thought process was also that this aspect is responsible for the return value being null in the first place (because it's handling the exception and not bubbling it up), and therefore it should make a reasonable attempt at not disrupting normal program flow by returning an empty collection.

This is an opinionated approach, and it may not mesh with what you are trying to do, you or your team's coding style, and where you intend to use this aspect.

Okay, on with the show.

The aspect I've written is able to send an error message up through the stack and eventually to the UI (in my application right now, that's either MVC ModelState or a display element in my Telerik Reporting reports, but it could easily be other UI elements too). Here's the relevant bit of code:

While I'm developing, that's great. I get the exception message and it helps me pinpoint the error. There's no stack trace, but you could add that too if you wanted (or check it out on Exceptionless logs). But there's a problem: I do not want my users (especially any malicious ones) to see detailed error messages like that. So, just add in some configuration and logic to show (or not show) a verbose error message. It's a piece of cake, and it really isn't something that's specific to AOP (other than to show that AOP code can be configured just like any other part of your code). I also want to refactor this to only use Exceptionless when in production: I don't need to log any exceptions that I create locally when I'm in the process of writing code.

Notice that I kinda hand-waved the configuration stuff away into the staic class/method IsThisSite.RunningLocally? The RunningLocally code is simply a check of Web.config (or App.config) using ConfigurationManager.AppSettings. How you manage your configurations is up to you and your team.

Also notice that GetErrorMessage could be customized to show different error messages depending on the exception (or not).

Okay, so I think this aspect is in pretty good shape. It's helpful, cuts down on boilerplate, and implements a very important cross-cutting concern requirement (error handling/logging). But, a) you shouldn't have to take my word for it that it works, and b) what if I want to refactor it? It should be unit tested (which is the next and final post).