Netflix has challenged the nerds to build a better recommendation technology.  I love the service but I dare say their recommendation system lags behind Amazon.com, at least for my tastes.  This problem seems to scream for some type of AI (genetic algorithms?) solution.  I wish I had time to play with it.

If you know me, you know I am an audio nut.  A peak at my living room (pictured here) might give you an idea I'm not well in the head, let alone the lunacy involved in the custom home theater that's being built in the basement right now.

The world of audio is a great place to observe tons of Snake Oil being sold and a sad, sad departure from the available Science that could guide us towards better sound.  Its not unlike many areas of computer science, where the Morts have never even heard of the science their day-to-day work is based on.  If you know SQL experts who are great at their job but who weren't aware that the concepts come from relational algebra, set theory, etc. then you know what I mean.

Over the past year I've become very interested in the effect the listening room has on sound.  Audiophiles like me spend a fortune on equipment that has perfect frequency response and near-zero harmonic distortion then put the system in a room that creates 30db peaks and valleys and flutter echos that ruin the stereo image, the list of room problems goes on and on.

I recently created a Room Mode calculator for my audio site, http://www.KlipschCorner.com/.  Room Modes are essentially the frequencies your room will cause to sound louder than they should due to the dimensions of the room.  For example, a 60hz sound wave is 19 feet long making a room with any dimension being 19feet a bad call.  Rooms with the common 8ft ceiling are tough to treat due to the frequency ranges being close to 8ft or 4ft.  A room mode calculator is useful when planning a new listening room because one can quickly see if there will be room modes at any "problem" frequencies and also see the distribution of room modes, where an even distribution is desirable.

There is a graphical component as well as a tabular component.  My hosting provider, while their service is great, chose to license a rather poor charting utility, so if anyone wants to send a free license of Infragistics my way you'd be saving me a lot of pain.

You can see the end results at http://www.KlipschCorner.com/Tools/ModeCalc.aspx and I suppose I can make the KlipschCorner.Acoustics library as it stands now available via some open source license.

I wonder if DirectSound could be made to do some time-domain analysis (using test tones and a microphone for input) for calculating sound decay rates vs ambient noise in a room?

Its not like me to not blog like this, man have I been busy.  Its time for an update.

My new title is Director of Mobile Technology at CarSpot.com here in Milwaukee.  My mandate is to create a .Net development department for Mobile, Web, and Desktop development, establish code guidelines, architectural guidelines, and best practices, try to get some best practices carried into the other technical departments, etc. 

So far I have re-architected and re-written one of our products, and am in the process of doing a 50-client release of this product.  Fifty units is a big deal on this product so I've had my hands full.

Generally, I'm hoping to have a better chance at "doing things right" than I've ever gotten as a consultant.  At a product company, where the product IS the focus, its easier to convince management to invest in getting the right tools and going back to refactor things and all that.  Contrast this to consulting where "Oh that damn web site project for FY07 planning" is always being pushed out far faster than is practical and quality of product and quality of life always suffers.

I have some long overdue technical stuff coming up next.

After becoming frustrated at "Visual Studio 2005 command prompt" yet again I become a powershell user today.  I'm not doing any scripting right now but its good to see MSFT recognize that a good command line can be very handy.

I am done with my stint in the Land of Beer, and with being a consultant. 

Long story short, I am going to start building the .Net development department at a product-oriented technology company in Milwaukee.  Having been a consultant for my entire career this is a new direction for me to go in.  I have no complaints about SafeNet at all, and I'd still highly recommend talking to them if you want to do consulting in SE Wisconsin.

The details of my new gig will leak out over the coming weeks as titles are finalized and things take more form.  In the meantime, I need to start writing about technology again.

private const string DOLLAR_SIGN = "$";
private const string COMMA = ",";

Hmm...

Which bit of code do you think is more maintainable by someone other than the original developer:

if(_speakerTypeCode == 543678){

//do something

}

or

enum SpeakerTypes {

HornLoaded = 543678,

Electrostatic = 12334
}

if(_speakerTypeCode.Equals( SpeakerTypes.HornLoaded)){

//do something

}

I'm still amazed at some of the things I find in code, sometimes even my own code.  The above monstrosity is not mine, although I do occasionally find something abhorrent in my own code.  I read a blog recently, I believe it was the Shade Tree Developer, who said that this is a great way to gage personal growth.  Go back and look at code you wrote and see if you find things that you'd never do today.

I upgraded to the latest version of DasBlog.  Everything appears to be working great.  Hooray.

I really don't like the C# "as" operator.  I have to admit that I made it a point not to use this solely because it made me have a brief moment of "VB.NET flashback".  I personally have a strong dislike for VB.NET syntax but that's just my preference.  Because of my VB.NET bias I did not look at the C# language spec to see if "as" functioned differently from

string foo = (string)myType;

As it turns out I tracked down a difficult bug in our system that was due to the fact that using "as" returns a null reference rather than throwing a class cast exception like c-style casting does.  Granted part of the problem was people swallowing exceptions in code, but I'm wondering: under what circumstances would one want the behavior that "as" provides?

I am doing a new gig at the Land of Beer, Miller brewing.  Sean McCormack got me involved in an agile project here on a short time frame so I've not had a ton of time to blog lately.  There's a lot to talk about as this project slows down though.

I cannot say that I am a test driven development expert by any means.  However, upon arriving on this project and trying to retro-implement unit tests for a bunch of code that had no tests before I have come to a new understanding of the value of unit tests for regression testing, and for a specific aspect of the TDD paradigm.  Upon arriving and going over the projet I'd seen that the team lead was printing out class diagrams, going through the unit test packages, and checking off Method names that had a test.  I had kept meaning to look at code coverage tools in the past and the sheer amount of tests odewe needed made me look a little more seriously.  As it turns out they were already using TestDriven as part of the developer setup.  TestDriven is by itself a great tool and will have a place in my toolbox henceforth.  TestDriven installs an interesting right-click menu in VS2005 that gives you various options for running tests at the class/method/project/solution level.   More interesting to me at the time was the "Test With --> Coverage" option.  If you don't have Team System it tells you to go install NCover which I had not used before.  NCover is actually a very solid code coverage tool.  You can probably see where this is going and certainly TDD experts will file this under the "duh" department.  TestDriven + NCover + NUnit = tells you how much of your code is covered by unit tests.  NCover is smart enough to show you if, for example, you covered all the various "if()" branches inside a method and such.  This is Very handy and not just for unit tests.

We found, in general, that the application had "thong-level coverage" from unit tests; as any good christian will tell you the thong leaves too much uncovered!  We strove to get it to "Burqa-level" coverage and made a lot of progress before the timeline demanded we start on new development.

Upcoming rants:

"About Casting"

"Funny Stuff I've heard at work recently"

"Indirect paths to success"

Looks like I have some invalid HTML in here somewhere, the visual styles on the links are hozed.