I sat for hours in Design 101 trying to get a even coats of cadmium red, cadmium yellow medium hue, and pthalo blue acrylic and their various combinations in perfect circles to learn the basics of complementary colors and other ins and outs of color theory.  Now several years later, it all comes back to haunt me with Adobe's Kuler.  I've seen several for-pay downloadable apps to do this, but Kuler is free and web-based (Flash).  Simply pick from a library of pallets or generate your own using a variety of color relationships.  Use with Firebug for quickly knocking out CSS color schemes.

FireBug is an amazing web development plugin for FireFox.  Like Web Developer Plugin, it lets you tweak HTML, CSS, and JavaScript on the fly.  However, it also bakes in features like visualizations to make sense of CSS and deeply nested elements easily.  It also gives you a nice drill-down report of network traffic, so you can see exactly how much each element contributes to the total page size, which is great when you're trying to trim those extra Kb off your pages.  The UI is very well thought out and easy to understand. 

Hang on to Web Developer Plugin for the validation features, but this is definitely a must have for your web development toolbox.

http://www.getfirebug.com/

One of the more exciting things going on in the Microsoft development world is the upcoming release of Silverlight.  Silverlight is (or soon will be) Microsoft's answer to Adobe's Flash and Flex products.  Silverlight technology is powered by the .NET framework in the form of a trimmed-down CLR (CoreCLR) that runs on both Windows and Mac -- Scott Hanselman has a pretty good summary of the product and its associated jargon here.
Based on the early examples, I think Silverlight will quickly achieve the ubiquity that Flash has enjoyed; hopefully it will stir the interest of .NET developers who have avoided Flash in the past and drive the development of some really useful applications.  There's also a good DotNetRocks podcast available in which Brad Abrams discusses the philosophy behind Silverlight and gives some glimpses of its future direction.

See the difference between these two icons?  Me neither, but the one on the right has about an 8% smaller file size. Portable Network Graphics (PNG) is quickly becoming the prefered format for web graphics.  It supports alpha transparency for nice blendy graphics (now in most browsers), and has amazingly small file sizes.  But those small file sizes can be made even smaller thanks to some custom compression tricks and pulling out unneeded data.  PNGOUT is a great little command-line utility for doing just that. 

Since it's a command line app, it can be integrated easily into your build process to automatically compress any PNG files in your images folder, so that no matter where your PNGs come from, you can ensure they take up as little bandwidth as possible.

ASP.NET Health Monitoring is one of the more under-hyped features of ASP.NET.  It is a rich, flexible logging framework that can be used to log application events in a database, flat file, email, or custom source.  However, JavaScript errors, since they occur on the client-side, do not get the benefits of this framework.   Fortunately this can be fixed by linking the client to the server with a little Ajax.  James Newton-King has posted a great solution to do just this in ASP.NET. 

In this solution, a small script to capture errors from window.error is registered on the client.  These errors are wrapped in XML and sent to the server via XmlHttp.  On the server, an HttpHandler unwraps the XML and logs a Web Event for the exception- including browser information.  Viola!  Client-side errors in your application's event log.  This is extremely useful for debugging problem scripts and alerting you to problems in your application you may otherwise miss.

The Patterns & Practices team at Microsoft recently released the 3.0 version of the ever-useful Enterprise Library.  Among the changes in the current iteration of the library is the addition of a new application block - the Policy Injection Application Block ("PIAB").

The purpose of the PIAB is to provide developers a way to define "policies" that can be applied selectively throughout an application.  Imagine that you're building a human resources application and one of the requirements is that the application provide an audit trail for all changes made to an employee's personnel record.  The PIAB allows you to define this requirement as a "policy" and configure its behavior external to your application.

Here's how it works:

• Using the Enterprise Library Configuration tool, you define a policy (in this case we'll name it "Audit Policy")
• Each policy can have any number of associated "matching rules"; these rules define how/when the policy is applied.  The PIAB provides the following rules out-of-the-box:
  • Assembly Matching Rule
  • Custom Attribute Matching Rule
  • Member Name Matching Rule
  • Method Signature Matching Rule
  • Namespace Matching Rule
  • Parameter Type Matching Rule
  • Property Matching Rule
  • Return Type Matching Rule
  • Tag Attribute Matching Rule
  • Type Matching Rule
• Each policy can also have any number of "handlers"; handlers determine what happens when a policy is executed.  The PIAB provides the following handlers, which utilize other Enterprise Library application blocks, out-of-the-box:
  • Authorization Handler
  • Caching Handler
  • Exception Handling Handler
  • Logging Handler
  • Performance Counters Handler
  • Validation Handler
• In our HR application example, we'll elect to use a "Tag Attribute Matching Rule" that allows us to mark methods in our business tier classes as requiring audit functionality; in addition, we'll choose to apply the Enterprise Library's Logging Application Block as our policy's handler.
  
   The resulting XML in our application's configuration file looks like this (the Logging Application Block section has been omitted for brevity):
  

<policyInjection>
<policies>
<add name="AuditPolicy">
<matchingRules>
<add match="Audit" ignoreCase="false" 
  type=
  "Microsoft.Practices.EnterpriseLibrary.PolicyInjection.MatchingRules.TagAttributeMatchingRule,
  Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=3.0.0.0,
  Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  name="Tag Attribute Matching Rule" />
</matchingRules>
<handlers>
<add logBehavior="After" beforeMessage="" afterMessage="" eventId="0"
  includeParameterValues="true" includeCallStack="false" includeCallTime="true"
  priority="-1" severity="Information"
  type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.LogCallHandler,
  Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers,
  Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  name="Logging Handler">
<categories>
<add name="General" />
</categories>
</add>
</handlers>
</add>
</policies>
</policyInjection>

• In our application, we're going to mark each method that requires an audit trail with a "Tag" attribute...notice that "Audit" corresponds to our matching rule defined above:
  

      /// <summary>
      /// Note:  class must inherit MarshalByRefObject 
      /// for use with the PIAB
      /// </summary>
      class Employee : MarshalByRefObject
      {
          [Tag("Audit")]
          public void Save()
          {
              //write employee to data store
          }
  
          [Tag("Audit")]
          public void Delete()
          {
              //remove employee from data store
          }
      }

• The "policy injection magic" performed by the PIAB will occur as a result of the way we create an instance of our Employee class: 
  
  

  Employee ourEmployee = PolicyInjection.Create<Employee>();
  ourEmployee.Save();

  
  The Create() factory method actually builds and returns a "proxy class" -- in this example, the proxy class intercepts our call to the Save() method, evaluates the matching criteria and determines that the handler should be executed because of the "Audit" tag match.  The result in this case is that an entry is written to the Windows event log as defined by our Logging Application Block configuration.
  

The "policy injection" pattern is worth a look if you have common functionality that needs to be applied throughout your application, and you want to do so in a declarative, transparent way.

In the slides from Scott Guthrie's 'ASP.NET Tips and Tricks' TechEd Presentation, I ran across this gem.  You can turn off debugging server-wide by adding the following to <system.web> section in the server's machine.config file (typically located in C:\windows\Microsoft.NET\Framework\v<version>\Config):

       <deployment retail="true"/>

This is a great backup in case developers forget to turn it off in the application using <compilation debug="false"/>.  Scott also mentions a few of the negative results of forgetting this little setting:

• Slower performance due to debug code
• App uses much more memory
• Client-side scripts are not cached

One of our favorite .NET books is "Framework Design Guidelines" by Krzysztof Cwalina and Brad Abrams.  In fact, it's required reading here at LifeCycle, and we try to check all code with FxCop to adhere to as much of the guidelines as possible.   Here is an excelent video presentation on many of these principals by Krzysztof.  It's a little long- 3 hours- so you may want to break up your viewing a bit,  but this guy is an absolute genius and what he has to say can go a long way in making or breaking your applications and APIs. 

Last month I mentioned a couple upcoming tools for "next generation unit testing", but it should come as no suprise that Microsoft is also working on a similar tool of their own. From the maker of MbUnit, Pex is a unit testing framework that auto-generates test inputs for you. So, if you write a test like this:

[PexTest]public void MyTest(string input){...}

Then Pex is smart enough to generate tests for the full range of values for "input":

MyTest(""); MyTest(null); MyTest("somevalue");

Add in auto-correction, and the result is a pretty impressive test-driven development story. Unfortunately, this is currently only a Microsoft Research project. Hopefully it sees the light of day sometime soon (and not just for Team System!).