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.

• Commit to Github or other public git repos without sharing your private information (like API keys and passwords and such)
• ReSharper and Roslyn would seem to go together like a lime and a coconut, but it seems that's not in JetBrains's immediate plans.
• However, DevExpress claims to be all-in with CodeRush and Roslyn. I don't know if these points of differentiation makes any difference right now, but could be interesting in, say, 6 months to a year from now.
• I was able to see Gary Bernhardt's session "The Birth & Death of JavaScript" at CodeMash this year, which is now available as a video on Destroy All Software. It might seem like a satire at first, but it's actually a really deep, layered, and meaningful talk that should be of interest to everyone, not just JavaScript or web developers.

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

StructureMap 3 was released recently, and as a regular user of StructureMap, so far I have to say that I'm pleased.

Mainly because not much was really broken, and also because I'm just happy to see a project I use so much continue to get updated.

There are a couple things that are moved around or renamed. In this post, I'll be talking about HTTP request scoping, decoration, and assembly scanning.

HTTP Request Scoping

StructureMap 3 no longer includes anything tied to HttpContext. But don't panic! It's all been moved to another package: StructureMap.Web. The API is a little different as well. Compare and contrast:

Also note that the cleanup (which I typically put in Application_EndRequest in Global.asax.cs) is also a bit different. In StructureMap 2, I would just call ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects();. In StructureMap 3, instead I call HttpContextLifecycle.DisposeAndClearAll();.

Decoration

If you are using the decorator pattern, then you probably often wire it up in your IoC container. In StructureMap 2, you used EnrichWith. In StructureMap 3, you use DecorateWith. I also think, but I'm not 100% sure, that DecorateWith is a little smarter about types as well. which I only noticed in some of my Castle DynamicProxy stuff. Behold:

If you have my book, AOP in .NET, then you'll know that a change to "EnrichWith" is fairly significant to the code examples in that book. But luckily, it's a relatively easy change (or you can just keep using StructureMap 2.x).

Assembly Scanning

Not a big deal here, just note that some of the assembly scanning extensions (specifically TheCallingAssembly, AssembliesFromApplicationBaseDirectory, AssebliesFromPath) have moved to the StructureMap.Graph namespace. No biggy, especially since ReSharper is able to point these things out and add "using StructureMap.Graph" automatically.

Summary

StructureMap 3 is definitely worth a shot. Based on the NuGet numbers so far, it's not being installed en masse just yet. But based on how I use StructureMap, it's practically a no-brainer to make the upgrade. One thing I didn't mention above (because it's not an API change) is that the error messages in StructureMap are now way more useful, and there are other benefits (like performance) that you are essentially getting for free (in terms of the time you'll spend upgrading). The only drawback is that documentation (as always) is lagging, but between the unit tests, Stack Overflow, and just noodling around, I haven't found that to be much of an impediment to an otherwise splendid tool.

I really enjoyed Cammy's brief talk on AOP in Ruby, and I think she successfully shows that even software written in a dynamically-typed language like Ruby can still benefit from AOP. There is some sort of technical issue early in the video that caused the sound not to be recorded, but it is fixed about 20 seconds in.

Follow Cammy on Twitter.

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.

• Why Your Previous Developer was Terrible - I tend to lash out emotionally when I see bad code, but I always feel uncomfortable blaming the previous developer, since I have no idea what kind of constraints (personally and professionally) they were working under. It's not always possible, but I try my best to seperate the art from the artist (and the code from the coder).
• Learn CSS Layout is an interesting CSS tutorial, that kinda reminds me of the various koans and git immersion types of tutorial sites.
• Did you see that "Everything from a 1991 Radio Shack ad is now done on your phone" thing making the rounds recently? Here's another analysis of technology costs then and now. Very roughly, the equivalent technology is not the $3000 nominal price in the Radio Shack ad, but at least $3.56 million.
• In MySQL, there's a sometimes handy GROUP_CONCAT function built in. Pete Shearer shows a way to accomplish something similar using FOR XML PATH and Microsoft SQL.

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

In the last post, I added some compile time validation to make sure that the aspect is being used in the correct places. Today, we're going to look at actually logging the exception.

Remember early on when I said that this aspect is not generally applicable? For this part, it's especially true, since I'll be using a specific logging library + service: Exceptionless.

The application that I'm working on is meant to be deployed to an Azure web site. Because of this, I have to think a little differently about logging. You can still log to the file system, of course, but on a cloud service that may not be the best idea. You could log to table storage on Azure Storage. You could also log to a normal database. However, I wanted to use something that: a) requires very little work, b) provides some useful monitoring tools that I don't have to build, c) is very low cost or free. So, based on my research and an endorsement from Mark Greenway, I decided to explore Exceptionless.

Using Exceptionless is as simple as installing a NuGet package, pasting in your API key, and then using an extension method.

Here's how I could use Exceptionless in my aspect:

This is very similar to what I did initially, but since this project is in development, I made a few adjustments along the way to make my life easier.

SQL exceptions. Especially during development, it's very likely that I'll screw up a SQL query, forget to run a migration script, etc. Additionally, since I'm using constraints in my database, I want to handle the case where a user is trying to delete an entity and a constraint is preventing them. So I modified the aspect some more:

The way I'm checking for "constraint" exceptions feels very hacky to me, but I haven't found a better way yet.

NotImplementedException. Again, since I'm still in active development, often times a NotImplementedException will pop up. For these exceptions, I want them to crash right away, and I also don't need to worry about logging.

Now that SQL exceptions and not-implemented exceptions are handled on their own, any other exception is one that I still want to log and output to the UI in a friendly, non-yellow screen way. During development, I definitely want to see the full exception message, but that's something that will definitely need to be revisited before going into production. Back to the list:

• This only works for ITerritoryService
• Swallowing exceptions: we should at least be logging the exception, not just ignoring it. <- We are now logging exceptions!
• If the method has a return type, then it's returning null. If it's meant to return a reference type, that's probably fine, but what if it's returning a value type?
• What if it's returning a collection, and the UI assumes that it will get an empty collection instead of a null reference?
• Do we really want to return the exception message to the user? <- We'll revisit this later.
• What if I forget to use ServiceBase as a base class on a new service?