For Christmas my wife got me a new Zune 8GB, which I'm really enjoying so far.  I think Microsoft has done a really good job putting the newer Zune's together.  Not only is the UI pleasant, but the thing light weight and easy to use, which is in sharp contrast to the older hard drive based devices.  Originally my wife got me a 16GB SanDisk Sansa View, which would constantly freeze up, even after a firmware Flash.  I just wanted something that works, so I got a Zune.

Now that I can listen to podcasts on the commute to and from work, I've done a little bit of searching and thought I would try out the following podcasts:

• DotNetRocks
• Hanselminutes
• Polymorphic Podcast
• FLOSS Weekly
• Agile Toolkit Podcast

I got these from these Ayende and Jeffrey Palermo's blog posts and comments.

As a side note I stumbled upon what Ayende Rahein means: Freedom Dawn.

I needed to make a change to some existing legacy* JavaScript that validates credit card numbers in the browser.  For the most part the project was green field except for a few services, so overall test coverage was very good - except for the JavaScript code.  The lack of test coverage in the increasingly growing JavaScript libraries was starting to really bother me, so I set out to find a way to create "unit" tests for my JavaScript code that didn't require any setup or any extra steps for another developer to run.  What I really was wanting, was for my JS tests to be integrated and run along side my NUnit tests.

After some searching it appeared that JsUnit looked to be the most widely used and supported JavaScript testing facility available.  The one problem with this is that it requires you run the tests through a frame in a browser, which is a whole lot slower and less integrated with our NUnit tests that I wanted.

To get faster feedback on my JS tests I immediately thought of using WatiN to drive the JsUnit tests.  After a quick Google search I found that Adam Esterline had already done something very similar.  The main difference between what he's done and what I wanted was that I wanted JsUnit errors results right there in my ReSharper test runner window and I wanted my test scripts to be pure JavaScript rather than HTML files that JsUnit uses (because I wanted to keep the SOC high, and be able to dynamically change the location of JsUnit relative to my test scripts).  Like Adam, I'm auto generating a test HTML page for JsUnit and using WatiN to drive IE (although since I get my results outside of IE, I'm thinking I can drop using WatiN altogether for this and make it browser independent).

The workflow for using the JsUnit utility library is as follows:

1. In your test project include a reference to JsUnit.Utils.dll
2. Create a folder (or two) to contain your JavaScript JsUnit test fixtures.
3. Create your JsUnit test fixtures as separate .js files.
4. Create a .NET NUnit test fixture with a test that runs the JsUnitTestRunner from JsUnit.Utils.

Here's my solution explorer window with the JsUnit.Utils reference and the c# and the JavaScript fixtures.

Once that is setup you create a single NUnit test that kicks off all the JsUnit tests.

/// <summary>

/// This runs all JsUnit tests found in the JavaScript folder and makes

/// their results available through NUnit (if any fail).

/// </summary>

[TestFixture]

public class JavaScriptFixture

{

    #region Setup/Teardown

    [SetUp]

    public void SetUp()

    {

        jScriptTestDir = AppDomain.CurrentDomain.BaseDirectory + "\\..\\..\\JavaScript\\";

        jsUnitDir = ConfigurationManager.AppSettings["JsUnitDir"];

    }

    #endregion

    private string jScriptTestDir;

    private string jsUnitDir;

    [Test]

    public void RunAllJSUnitTests()

    {

        Assert.IsTrue(Directory.Exists(jScriptTestDir),

                      string.Format("Could not find the JsUnit tests directory: '{0}'", jScriptTestDir));

        Assert.IsTrue(Directory.Exists(jsUnitDir),

                      string.Format("Could not find the JsUnit directory: '{0}'", jsUnitDir));

        ITestFileReader reader = new SuffixTestFileReader(".js", new TestFileReader(jScriptTestDir));

        new JsUnitTestRunner(reader, jsUnitDir).Run();

    }

}

Running this test through the ReSharper Test Runner runs all my JsUnit tests, so when I choose "Run All Tests from Solution," it really means "run all tests".  More importantly, if any JsUnit tests fail during execution the JsUnit error is displayed in the output window.  Here's my "testShouldValidateCreditCard" test that is failing which shows the JsUnit error text:

If you've ever used JsUnit before I bet you're wonder how I'm getting the result back, since JsUnit is entirely web based and only supports posting results to a URL (generally for use with the JsUnitServer).  What I'm doing is unpacking an ashx file that is an embedded resource, copying the current running DLL (JsUnit.Utils.dll) to the bin directory under the current running directory, and then starting the .NET 2 webserver.webdev.exe to listen for results using the unpacked ashx file.  The results are then saved out to a predetermined text file which JsUnitTestRunner is looking for and then parses out any errors.  I could use .NET remoting or something fancier, but this works well enough for now.

There's still a lot that could be done to clean this up, like removing the WatiN dependency, adding new features and so on.  There are also a few bugs I need to work out, but so far so good.

*legacy in the sense that there were no unit tests, even though the code is only a month old.

ReSharper 3.1 just came out, and of course I immediately installed it.  So far so good.  It fixed a couple of annoying crashes for me and added a new feature.

• I can now open my MSBuild project files without ReSharper crashing constantly.
• Visual Studio has yet to crash on exit.
• And the best reason to upgrade: solution wide error analysis has been added.  Pic below.

Today at work we needed to compare the contents of a SQL table against an FTP directory.  We originally had a process that involved a lot of steps using Excel, NotePad, and command line FTP.

You could create a PowerShell script that iterates the SQL Server data and verifies each file is on the FTP server. This seemed like it would be slow so I opted for running FTP directly from my query (assuming you have xp_cmdshell enabled). Here's an example. Notice it's getting the FTP commands to run from the ftpoptions.txt file.

declare @FilesOnDisk table

(

[File] [nvarchar] (50)

)

insert into @FilesOnDisk ([File]) exec xp_cmdshell 'ftp -A -s:c:\temp\ftpoptions.txt ftp.microsoft.com'

select * from @FilesOnDisk where [File] is not null

Now we can join this temp table data to our local SQL Server table to find missing files on the FTP server...

There's a discussion around lines of code (LOC) and code base complexity right now, and I had commented about one the better code bases that I maintain was around 80K LOC, as compared to a much smaller code base that I maintain.  80K was just a guess at the time, but the engineer in me wanted hard numbers.  I downloaded .NET Line Count Utility from CodeProject and pointed to our back end server solution (yeah it takes sln and csproj files as input!).  To my surprise I had guessed the # LOC within 35 lines.  The actual number was 80,035 LOC.  Either I'm good at estimating LOC, or more likely I just got lucky.

I encountered a really annoying bug in the SQL Server SMO scripting library today.  Once you script out a single "DROP" script the internal scripter is left in a bad state and starts throwing NullReferenceExceptions on any subsequent call to the Script method.  I haven't found a good way around this yet.  Unfortunately the only reference I can found about this issue confirms the bug but nothing else.  Hopefully this will be fixed in SQL Server 2005 SP3, because it sure isn't fixed in SP2.

Data binding DateTime fields in MonoRail is pretty powerful and flexible, but not really straight forward.  Most of the time you can just provide the domain object propery as an argument to the a form helper method, but with DateTime's split across multiple select boxes this doesn't work when you post back to your controller method.  To get DateTime's to work across several HTML select fields you need to explicitly provide the selected value like so:

$Form.Select("billing.accountExpiration", $billing.accountExpiration.Month, [1..12], "%{tabindex='11'}")
$Form.Select("billing.accountExpiration", $billing.accountExpiration.Year, [$DateTime.Now.Year..2011], "%{tabindex='12'}")

I asked the alt.net group what issue/feature tracking software everyone would recommend, and thankfully I got a lot of responses about what people are using or have used in the past.  Really useful stuff.  It would take an individual years to glean this kind of first hand experience.  Here's a summary of recommendations (good and bad):

• TRAC - Python based OSS app. It seemed a lot of people have used this.  Most people think it's OK, but the consensus is that it's kind of "wonky" at times.  The UI isn't particularly pleasant, but Ayende did create a simple Winform UI for it at one point - not sure it still works or how well.
• Mingle - Developed by ThoughWorks.  ROR app.  The UI is pleasant and customizable.  The pricing is different, it seems you pay monthly.  Wave of the future, especially for software that gets released frequently (permanent beta)?  Compared to the competition this appears to be a rather expensive option - but possibly worth it.
• FogBugz - The UI is pretty simple/clean, and has a good dashboard.  I liked the fact that is contained "evidence based tracking" which sounds really smart and useful - as long as everyone enters their actual time on a task accurately.  Phil Hack said, "...FogBugz is hands down awesome. Anyone that disagrees with me, you're wrong. End of story."
• StoryVerse - MonoRail reference project or real OSS based project?  The code AND the UI look really clean.  I'm not sure if this is still active or how full featured it is, but it definitely looks promising.
• Gemini - Got some mixed reviews, but I think most people gave it a +1.  It looks like a lot of companies are using this one.  Integrates great with SVN.  The screenshot of the home page reminded me of Jira.
• Elementool - Fairly cheap.  Free version fields.  From Donn, "Unintuitive and just a hassle to use. Never integrated it with anything though. I wouldn't want to. I just want to STOP using this product."
• Lighthouse - Looks like a hosted ROR app?  From Brian, "It has rough edges in some areas, but overall is a very nice interface, and you can use email to create and comment on issues.  It only has ONE status field (which at first seemed limiting, but then I realized was liberating - at least for this project).  If all you are doing is tracking open items (for example on a maintenance project) it may be all you need."
• TargetProcess - ASP.NET agile management tool.  It will manage bugs, features, and support tickets.  It integrates with SVN.  What's cool is that it uses NHibernate to data access, so it appears you could use any RDMS that NHibernate supports.
• BugTracker.NET - This is a very simple OSS ASP.NET app, but one look at the code you'll run screaming. 
• AxoSoft - TODO: more info
• MS Project Server - It's "enterprisey".

Today I discovered that in Monorail you must add an HTML name attribute to each element you want the SmartDispatchController to autowire for controller method parameters.

Without any name attributes on my emailAddress and password text boxes, the values were null that were passed into my controller method (BTW - isn't that a nice clean controller method?):

public void CreateAccount(string emailAddress, string password, string returnUrl)
{
    UserServiceResponse response = userService.CreateNewAccount(emailAddress, password);
    if (response.HasErrors)
    {
        Flash.Add("Summary", response.ErrorMessages);
        RedirectToAction("New", "ReturnUrl=" + returnUrl);
    }
    else
    {
        CancelView();
        Session[AuthenticationFilter.UserKey] = response.User;
        Redirect(returnUrl);
    }
}

Adding the "name" HTML attribute made the values auto populate as needed:

<input id="emailAddress" name="emailAddress" type="text" tabindex="1" />

If you need to override the Prototype submit behavior in MonoRail's FormHelper.FormTag, you will need to use on_submit instead of onSubmit.  This isn't obvious since every other parameter seems to match up to the JavaScript libraries params.

With that out of the way I can hook my custom validation and display logic for a non-domain object ala Billy McCafferty's post.

Here's an example to override the onsubmit behavior:

$Form.FormTag("%{action='login', on_submit='false'}")