If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

Guard is one of the MANY projects coming out of the netfx project. (HOLY NUGET there’s a ton of these).

If you’re not familiar with the netfx project, you should become acquainted with it. Daniel Cazzulino (of Moq fame) and others have created an awesome set of add-on functionality to the .Net framework through these NuGet packages

Back to the Guard package:

Many .Net developers tend to write their guard clauses as such…

One problem with this is that if you were to rename the “value” parameter you have to make sure you rename the magic string “value” in the guard check.

The Guard package offers a solution that is a little more resilient to these types of rename issues as its usage will automatically either get renamed, or if you don’t you will get a compiler error.

The below test shows an example of its usage.

If you run that test, you’ll see a nice exception message.

If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

NSpec is one of many flavors of BDD framework out there. I’ve never used it, but its website looks good and has some nice documentation and examples.

What is your favorite BDD framework?

If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

Stimpack is another project leveraging ReactiveExtensions (RX). It’s based off of ReactiveUI and has some interesting concepts for consideration with a MVVM pattern.

This was probably originally added to my To-Research list mostly because of the RX factor.

I didn’t find an good sample project on how to use it, but if you read through the fairly clean test project you can probably figure out anything you need.

If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

Anna is an event-driven HTTP server library leveraging the ReactiveExtensions (RX).

The below sample copied / shortened from the GitHub site.

using (var server = new HttpServer("http://*:1234/"))
{
    // simple basic usage, all subscriptions will run in a single event-loop
    server.GET("/hello/{Name}")
          .Subscribe(ctx => ctx.Respond("Hello, " + ctx.Request.UriArguments.Name + "!"));
}

If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

NFeature looks to be a pretty solid feature toggle implementation written in .Net C#.

This project peaked my interest because I’ve wanted to try the concept of feature toggles in a project for a while now. With all the hubub last year about feature toggles vs feature branches. I’ve wanted to experience feature toggles first hand.

If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

xizzle is a project that attempts to give you CSS-Like selector capability over arbitrary xml. This project first piqued my interest because I hoped it would be a light weight alternative to fizzler (Somebody should put fizzler on the NuGet feed. 1.2.3 not it). Unfortunately it isn’t quite there. Maybe someday xizzle will be strong enough to compete with fizzler but at the moment it doesn’t support nearly the amount of selector syntax that fizzler does and once I started playing with it I was mildly disappointed in its selector capabilities. Was probably written to get a certain class selector options accomplished and the writer just didn’t need all that much support yet. But I think there’s some real potential for a project like this to push forward. Lightweight, all included easy syntax.

If you are coming to this series of posts for the first time you might check out my introductory post for a little context.

I found a description from a blog post for this project:

PineCone lets you take a C# class and then builds a schema for this class. This schema contains cached members that via IL Emit extracts all simple values from the object graph. All values are turned into a StructureIndex, which is contained by a Structure. Each StructureIndex holds a Guid pointing back to the structure so that you easily can navigate to the structure again.

It’s described as a component used in http://sisodb.com/ (which itself looked interesting) and he may use it on other projects.

A while back I posted about following the NuGet feed via an RSS reader. For some strange reason I’ve been reviewing this feed since then on an almost daily basis in my RSS reader. Throughout that time I’ve kept a small list of what I think are interesting projects that have put out a release since that time. Today we’re going to start a journey through projects that I’ve found during my review of the feed. Some projects are interesting because I could find a use for them, some are interesting because they are unique, and others solve an interesting problem.

Why were these packages chosen to post about over others?

There wasn’t any scientific process in place to decide what projects made this list or not but as I think back over my time reviewing the feed, below are some items that came to mind.

Some reasons I may have chosen a project:

• I could potentially see myself investigating its usage someday.
• It solved a problem in an interesting way.
• Preferred small, focused, unique packages.
• Preferred projects that were Open Source as in FREE.
  • Although I didn’t bother to look at any of the licenses so be sure to read into those before you use any yourself.
• Preferred projects that have a “Project Site” where I could browse the source code see examples or even documentation.
  
• For some reason if I saw it was hosted on GitHub I preferred those to sites that had their own dedicated location (Can’t explain why – just did…)

Some reasons I may have NOT have chosen a project:

• Tended to avoid projects that posted large numbers of packages even though many of them are still very good projects.
  EX:
  • NServiceBus
  • FubuMvc
• For some reason I tended to stay away from anything MVC related. There are probably very interesting projects for MVC on there, but I probably avoided them because I’m not doing anything MVC related at the moment.
• Avoided packages that had “utilities” or “common” or “helpers” in the package name.
  • But it might still be worthwhile checking out some of those open source “utility” projects. Just to get an idea of what others consider “needed on every project” and different approaches to the problems.

Some items to consider with these little NuGet gems.

• Make sure you read and understand any license the project has before including or using them in your own work.
• These posts won’t be full project analysis, but a generally a first impression.
• Be sure to research any project before using. I’m only mentioning them because they piqued my interest. Not because I have extensive knowledge of the projects or know their stability.

Today the PM of a project I am working on sent an email with a small list of issues that we needed to get resolved before shipping an early build to the customer for a weekly review. In his list of issues MY NAME was tagged next to a feature that I KNOW was working. I dev’d it, tested, saw it work.

Now the project I’m working on encourages unit tested code, which is a fantastic project to be on since I am a big proponent of Unit/Integration/Automated tests. Heck I wrote a tool to help run them easier (StatLight).

What I did.

The problem was this. I dev’d a feature out in like 5 minutes, took about 2 seconds to decide if I should write a unit test to prove my feature worked and this is where I failed. Manually verified my change checked in the production code without its test and I was hurriedly moved on to the next task.

About 20 min later I get a quick I.M. from a co-worker saying he had a small merge conflict in the file I just checked-in. Quickly told him how to get around his merge issue (not realizing after he checked in) that my “quick 5min dev task” was accidently removed in the merge.

What I SHOULD have done!

What I should have done was write the 2 lines of test code first. (you can argue test after/test first, I prefer test-first). Proven my code wasn’t working, by running the test, and then implement the 5 min feature making the test pass. Then when my co-worker ran into his merge issue.

Test would have failed telling him his merge didn’t go as planned.

This would have also avoided

• PM wouldn’t have had to discover the issue, Screenshot and write up an email.
• I wouldn’t have had to peruse source control history to understand why my “working” feature wasn’t working.
• I wouldn’t have had to willingly confess my sins in this post.

If your feature doesn’t have a coinciding automated test. How do you know it’s still working?

Happy Testing!

Get The Build

What is StatLight?

In short, it allows you to run your Silverlight tests on a Continuous Integration server or alongside your daily development.

Fore more information go check out the project site http://statlight.codeplex.com

Some ramblings (about the project).

It’s funny how the release cycle of this open source project has turned out. I don’t have any sort of calendar reminder that pops up saying “it’s been 4 or 5 months and time to get out a new release”. However, since I first open sourced the project I’ve put out a new release on a pretty consistent 4/5 month cycle and have done so since December 2009. It just so happens about every 4/5 months there is enough features and or fixes piled on top that It’s time to put out an “official” build. Not bad for a part time (free to the community) gig.

Thanks to the guys at CodeBetter and JetBrains for giving us a TeamCity build server, I put a build of StatLight up on their TeamCity server. This has been great for myself. When issues or feature request come in, all I have to do is dev them out, push the code out to GitHub and the TeamCity build produces an artifact that people can pull down and use/test right away.

What’s the difference between a TeamCity build and an “official” release of StatLight? To be honest, NOTHING. When I decide it’s time to release an “official” build, I head over to the TeamCity, download the latest build and throw it up on CodePlex and NuGet and call it the “official” release. I guess the biggest difference is this means I now have to go update the documentation out on the CodePlex site. I’m not particular happy with this process and hoping my new pet project using http://sphinx.pocoo.org/ to generate a CHM documentation file will help with future versioning of the tool. I’m working on a new blog post for how I got this working…

Some more ramblings (about this release)

This build comes with some pretty major internal refactorings. Finally, after 3 years, I’ve put in an IOC container (really liking TinyIOC for this task). This cleaned up quite a bit of the codebase. Introduced a couple regressions, bug the community was great in helping me figure this out and I’ve beefed up my test coverage to avoid this in the future. There is more cleanup to do in the codebase, but much of the hard work was done and it’ll be small refactorings as I see them going forward.

Some of this build’s highlights:

I’d highly recommend reading the release notes on the download page to get a full list of features/fixes. http://statlight.codeplex.com/releases/view/73869

• Support for Silverlight 5.
• Overhauled the “Continuous” mode. (Provide better U.I. and support for multiple xaps/dlls)
  • Note: I was getting a bug report that it could occasionally run a xap multiple times. Hopefully it’s fixed now, but if you see it and can reproduce it. Let  me know.
• MSTest TRX output format. (Note: This was requested heavily, but when it was added I didn’t receive much feedback on whether it was working or not… So if you have issues, first start a Discussion or file an  Issue)

Special thanks to Bob Brumfield for fixing a number of pathing issues after a directory re-structuring I made in the project. With his fixes we were able to get Silverlight 5 support into the project sooner than later.

Sort-of known issue with this build.

Due to the large scale refactoring that happened within StatLight I wouldn’t be surprised if a few regressions were introduced. Hopefully not as I’ve setup a large amount of automated tests around the project. But It’s hard to get everything.

I’ve had a few people report an issue with symptoms similar to the following.

• http://statlight.codeplex.com/discussions/284494
• http://statlight.codeplex.com/workitem/14579

If you experience any sort of “Invalid or malformed application: check manifest” error. This is probably due to a StatLight web server side exception not being reported out correctly. Try downloading the latest from the TeamCity build (follow the link on the StatLight home page).

What’s to come?

If you feel brave, and clone the current codebase you could get some early access to a version I have working with the Windows Phone Emulator. This was actually an early branch of the project I created many moons ago, and one that a user forked and added a couple fixes to a while back. I’ve since merged this into the main-line of StatLight.

This early version doesn’t yet support the full gamut of what StatLight’s Silverlight version supports, but I’m hoping to get it in there. It should work with the recent builds of the Microsoft.Silverlight.Testing that work on the phone. If you’re interested in helping out here, the big reason I don’t support most everything on the phone is related to the big ol monster build script in StatLight. I have to add some magic dust to this script and make dual compile other projects for both Silverlight and the phone. The codebase itself shouldn’t have to change much, but the build scripts and integration tests will require the majority of the effort.