Well, I have been in Spokane for a week now. I still feel like I am just settling in. My car finally shipped (thanks to MN for helping) and should arrive this week. The contents of my apt may not be here until Christmas, so it will be a little rough until then. The weather the last two weekends has been as bad as the worst I saw in Philadelphia (and it is only December). I wish I could find reliable information on what are the best winter tires.
Tuesday, December 11, 2007
Monday, November 12, 2007
SC07: It Begins
All around you will find Intel trying to make waves
Celebrating the 45nm Launch - 45 steps to Technology Leadership
Ok. So they made 45nm, what's next? With the physical limit a few nm away (from what I understand, 30nm is the limit), what are they going to shock and awe us with next?
Everyone is trying to get the final touches finished on their booths while eagerly awaiting the food coming in just 5 minutes. After an hour of eating, we will have a half hour break before the VIPs get their privileged two hour private run on the show floor. From what I hear, D-Wave is claiming to have the first quantum computer presented here, but we will have to see about that.
Saturday, November 10, 2007
News
It has been too long since my last post, for which there are a number of reasons.
- Super Computing 2007
- Vacation Preparation
- New Job
- Moving
I head to Reno, Nevada early tomorrow morning for SC07. I have been trying to get my research ready for presentation. Hopefully this year will be as fun and interesting as last.
The day after I get back from Reno, my girlfriend and I are flying to Aruba for ten days.
There is a lot of preparation when I will essentially be gone for fifteen days. This should be a nice break compared to the bedlam to come.
I resigned. When I get back from Aruba, I will be working my last week as a Software Developer for NAVTEQ. I will be moving 2529 miles from Philadelphia to Spokane, WA to take the role of Software Quality Assurance Director for PlayXPert.
I will be doing software architecture, software development, developer management, project management, system administration, continuous integration, QA management, and other tasks.
Along with the new job comes moving. I work for one week, during which I need to pack every morning and night ( as I will be gone for the two weeks prior ) which leaves no room for anything. I start Monday, December 3rd.
This come as a stumbling block for my Ensurance project on CodePlex. It is stable, fully featured, and usable, but I will not be able to work on it for a month which really pains me. The only pieces missing are the distribution tasks such as strong naming, finishing internationalization, and such. I was really looking forward to implementing the full set of fluent parameter attributes, but there is a minimal implementation right now.
I will try to post from SC07 with anything that I find.
Thursday, October 11, 2007
New Ensurance Release
Yesterday I released version 0.4 on Codeplex. All of the functionality for the 1.0 release is finished. I am trying to wrap up all of the tasks needed for a distribution. When all of that is done I will mark the release as 1.0. I am still looking for functionality ideas.
Friday, October 5, 2007
Long time, no posts, new OS project Ensurance
I have been incredibly busy lately and thus there have been no posts. I have finally published the first release of my project Ensurance on CodePlex. It is based on the NUnit 2.4.3 framework and is intended to be used for production code to verify particular constraints in an application. Check out the CodePlex page for more information. I will be posting sample code soon.
Sunday, September 2, 2007
Portable 'supercomputer'
The story of the Calvin College portable supercomputer really irks me. It is getting a lot of attention for doing nothing. You can see it on engadget, Slashdot, and others. Anyone can build a cluster like what they have. The only credit I will give them is that not everyone would go through the benchmark and analysis as they did. On the other hand, these people are still on the same old trail of HPC. They ignore the entire issue of programming -- they used HPL code. Ask if they can write their own code for the microwolf. What kind of real application performance can they achieve? The engadget article says "Talk about a solid price-to-performance ratio." - what load of crap. How about asking real questions and reporting real HPC news?
Ninject Dependency Injection Framework
I have been playing with Ninject for a couple days now and I am having a lot of fun. One feature I have been really digging is Contextual Binding. The kernel allows multiple modules to be loaded that define the bindings of your types. So depending on which modules and bindings are set, I can change the way other binding resolve. Here is an example:
Say I want to resolve a different type of car dependent on a selected engine. I have an interface IEngine and two classes V4, V6 that inherit from IEngine. If V4 is resolved by the kernel then the car returned would be a Civic; an Accord if a V6 is returned. Here is the code in custom modules:
internal class EngineModule : StandardModule
{
public override void Load()
{
Bind<IEngine>().To( typeof ( V4 ) );
}
}
internal class CarModule : StandardModule
{
public override void Load()
{
IContext context = new StandardContext( Kernel, typeof ( IEngine ) );
IBinding binding = Kernel.GetBinding<IEngine>( context );
Type implementationType = binding.Provider.GetImplementationType( context, false );
Bind<ICar>().To( typeof ( Accord ) ).OnlyIf(
delegate
{
if ( implementationType == typeof ( V6 ) )
{
return true;
}
return false;
} );
Bind<ICar>().To( typeof ( Civic ) ).OnlyIf(
delegate
{
if ( implementationType == typeof ( V4 ) )
{
return true;
}
return false;
} );
}
}
I can then load the modules into my kernel and use it to resolve cars:
internal class Program
{
private static void Main( string[] args )
{
IModule[] modules = new IModule[] { new SettingsModule(), new EngineModule(), new CarModule() };
IKernel kernel = new StandardKernel( modules );
ICar car = kernel.Get<ICar>();
Console.WriteLine( "I just got a brand new {0} {1}.", car.Manufacturer, car.Model );
Console.WriteLine( "It has a {0} cylinder engine with {1} horsepower and {2} ft-lb torqe.", car.Engine.Cylinders, car.Engine.Horsepower, car.Engine.Torque );
Console.WriteLine( "Time to start the Engine!" );
car.Engine.Start();
Console.WriteLine( "Sound good, but I am going to turn it off for now." );
car.Engine.Stop();
Console.ReadLine();
}
}
Nate Kohari just wrote a first cut user guide that is very helpful when getting started.
Monday, August 27, 2007
Running Mocked Unit Tests in FinalBuilder With Coverage
I just read an article by Craig Murphy on running unit tests in FinalBuilder. I liked the article and it gives some good pointers. I wish he had written it a while ago, it would have been helpful to me. We use TypeMock which will not allow us to make our unit tests as simply. When I wrote our build scripts I took the same general approach he did.
Starting in the Main ActionList we defined a few variables that give the paths to the applications we use. I also created an ActionList call RunTest which I will go into detail below. For each DLL being tested a call to RunTest is made passing in the name of the DLL to be tested.
In each call we set the CURRENTDLL ActionList Parameter with the name of the DLL (Animation,Audio,Core,..).
NCOVEROPTIONS holds the command-line options for ncover.console.exe. The same follows for NUNITOPTIONS and TMOCKRUNNEROPTIONS. The rest of the ActionList Parameters are used as temporary variables allowing me to put together very complex command argument strings and parse XML into variables.
The RunTest ActionList is separated into two try...catch blocks. The first to run the tests and the second to process the results.
Here are what the commands are doing:
Set Variable NCOVEROPTIONS
//x "%BUILDDIR%\%CURRENTDLL%Coverage.Xml" //l "%BUILDDIR%\%CURRENTDLL%Coverage.Log"
Set Variable TESTDLLS
"%ROOTDIR%\bin\%CURRENTDLL%Tests\%CURRENTDLL%.Tests.dll"
Set Variable NUNITOPTIONS
%TESTDLLS% /xml:"%BUILDDIR%\%CURRENTDLL%TestResult.xml" /noshadow
Set Variable PARAMETERS
-first -link NCover %NCOVER% %NCOVEROPTIONS% %NUNIT% %NUNITOPTIONS%
Execute Program
%TMOCKRUNNER% %PARAMETERS%
-Wait For Completion, Log Output, and Hide Window are checked. I do not check the exit code. The second try block handles it.
The first sets up all of our variables and launches the TMockRunner application with all of our parameters. The second tries to read the test results into the TESTFAILURES variable. If the TMockRunner failed then the file will not exist and the Catch block will append our error message to indicate this. If there are test failures we read the failed test cases into a temporary error variable using XPath. This temporary variable is appended to the error message variable which is sent via email to our team. This allows us to find the exact tests that failed directly from our email.
That is basically it. Our CI server runs the FinalBuilder script with a few extra options and processes the NCover output to give us a nice web page.
Saturday, August 18, 2007
Parallel Functionals
I have used the loop tiling code with scheduling algorithms to parallelize Dustin Campbell's code from his post A Higher Calling. The parallelized funtionals can be found here. It uses the scheduling algorithm code from the last post. The parallel reduction is actually based on Joe Duffy's serial reduction.
Scheduling Algorithms
I have uploaded my current version of the scheduling algorithms code that I referenced in my previous post. You can view the file here. I no longer have access to a multi core/processor machine so I cannot benchmark them properly right now.


