Does your team utilize a step-by-step installation guide to build and deploy various environments, or do the Development, Test, and Release Management folks simply "wing it"? I certainly hope it's not the latter.

Do you use the U2U CAML Query Builder instead of writing CAML queries from scratch? If not, then you must really know your SharePoint (or perhaps you just enjoy making things harder than they need to be).

Here's a little PowerShell script I whipped up to import the TechnologyToolbox.com log files into a SQL Server database for some "quick and dirty" analysis.

If you think that programmatically filtering errors in ELMAH is as easy as specifying filters in Web.config, you might be in for a surprise.

In my previous post, I briefly mentioned the unit tests I created while trying to figure out why my ELMAH filter was not working as expected. Well, here they are for your enjoyment (or idle curiosity).

I finally got around to configuring an ELMAH filter for the TechnologyToolbox.com website (so I wouldn't be bothered by frequent email messages due to failed hack attempts). During the process, I also discovered a couple of bugs in ELMAH (and learned a lot more about the internal workings of ELMAH).

Here is the PowerShell script I developed to avoid accidentally including "junk" in code samples I create for my blog.

There are a couple of options for creating a zip file for a specific folder. You can either use a third-party solution (like the PowerShell Community Extensions) or do it all with "out-of-the-box" functionality.

This PowerShell script makes it much easier to perform code coverage analysis in Visual Studio 2010 and .NET Framework 3.5 solutions (e.g. SharePoint 2010).

It takes a little more work than expected, but you actually can "have your cake and eat it too" when it comes to Visual Studio 2010 code coverage analysis and .NET Framework 3.5 solutions (e.g. SharePoint 2010).