Introducing Slotted – the ultimate signup tool.  

What is Slotted? Do you ever find yourself in charge of signing people up to do something / bring something / be somewhere / give something / etc.?  Then you should try Slotted.  It’s designed to make the whole process as painless as possible – for you, but more importantly for the people you are asking to sign up.

I expect to continue contract work for the immediate future.  But there’s something else worth mentioning.  Slotted is written in Ruby on Rails.  Yes, I’m moving toward Rails in my contract work as well.  I think I’ll skip the obligatory “why-I-am-moving-to-Rails” post.

If you try Slotted, I would love to hear your feedback.  We are iterating fast on features and trying really hard to get usability right. You can always comment here, or contact us from the Slotted site.

Introducing FlipIt.

FlipIt is a general purpose feature flipper for .NET.  It offers an easy way to deploy features and flip them off and on without touching code. In the very simplest case you flip the feature on/off for everyone all the time by changing a boolean setting. But it supports much more complex scenarios. For example, flip features:

1. By user segment
2. Based attributes of business transaction (such as by region)
3. By time of day
4. At random (split testing anyone?)

Really, you can flip features based on any condition imaginable and control those conditions over time without touching code.

Out of the box, FlipIt uses app settings, but it would be super easy to implement a different settings store and give the flipping power to an admin user.

Enjoy, and let me know what you think.

I’m creating a REST service. I want to host it on a machine without IIS.  No problem, WebApi supports self hosting.  But in production, it really needs to run as a Windows Service, not a console app.  How to do that?  Enter TopShelf.  TopShelf makes it easy to host a service either in a console or as a Windows Service.

My service class.

public class MyWebApiService
{
    private readonly HttpSelfHostServer server;
    private readonly HttpSelfHostConfiguration config;

    public MyWebApiService(string baseAddress, IDependencyResolver resolver)
    {
        config = new HttpSelfHostConfiguration(baseAddress);
        config.ServiceResolver.SetResolver(resolver);
        config.Filters.Add(new ExceptionFilter());
        config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
        server = new HttpSelfHostServer(config);
    }

    public void Start()
    {
        server.OpenAsync();
    }

    public void Stop()
    {
        server.CloseAsync();
        server.Dispose();
    }
}

And here’s how to make that service run under TopShelf.

static void Main(string[] args)
{
    var container = Bootstrapper.RegisterDependencies();
    var resolver = new StructureMapDependencyResolver(container);

    HostFactory.Run(x =>
    {
        x.Service<MyWebApiService>(s =>
        {
            s.SetServiceName("My Web Api Service");
            s.ConstructUsing(name => new MyWebApiService(BASE_ADDRESS, resolver));
            s.WhenStarted(svc => svc.Start());
            s.WhenStopped(svc => svc.Stop());
        });
        x.RunAsLocalSystem();
        x.SetDescription("Does really cool stuff.");
        x.SetDisplayName("My Web Api Service");
        x.SetServiceName("MyWebApiService");
    });
}

To create a Windows Service, run your console app with a switch.

MyWebApiService.SelfHost.exe install

That’s it! Enjoy.

@this.DataList("countriesList").Options(countries)
@this.TextBox(x => x.Countries).List("countriesList").Autofocus()
@this.SearchBox(x => x.Term).Placeholder("Enter search terms").Novalidate(shouldValidate)
@this.DatePicker(x => x.CompletedDate).Required(true).Limit(minDate, maxDate) //min, max
@this.TimePicker(x => x.StartTime).Limit(TimeSpan.FromHours(10), TimeSpan.FromHours(14), 60) //min, max, step
@this.NumberBox(x => x.CompletedDate).Limit(0, 100, 10) //min, max, step
@this.EmailBox(x => x.Email).Multiple(true).Autocomplete(false)
@this.SubmitButton("Submit").TargetBlank()

The above is just an example. There’s a lot more too. You know of course that a lot of this stuff is not yet supported by many browsers.  But it’s coming, and we wanted to be ready.  It might be some time before this is in the NuGet distro, but you can build the trunk and try it out now.

@inherits MvcContrib.FluentHtml.ModelWebViewPage<MyApp.WebUI.Models.MyModel>

If you decided to put the ModelWebViewPage class into your app directly, of course, adjust the namespace accordingly.  You should also remove any @model directive because the @inherits directive tells the view what the model is.

You probably also want to add this to the namespaces section of your Views web.config file (not the app level web.config):

<add namespace="MvcContrib.FluentHtml"/>

Use the fluent helpers just like you would in an aspx file, except with Razor syntax of course. For example:

@this.TextBox(x => x.FirstName).Id("firstName").Class("someClass").AutoLabel()

Enjoy!

Last spring I revealed my alter-ego as an iPhone app developer when I announced my first iPhone app, Bill It.  Today I am proud to announce that my second iPhone app, Better Do, is for sale in the App Store.  It’s free.  There are ads, which can be turned off for a low price.

Better Do is a To Do list app.  Yeah, I know, another To Do list app?  Aren’t there hundreds of those?  Indeed there are.  But none of them work for me.  There are generally two types of To Do list apps: too-snazzy and too-simple.  The first type promises to totally manage all of your tasks as long as your enter a whole bunch of information, including a fixed due date for each.  The second type is a basic list, maybe with categories, and maybe it lets you re-order tasks.

Better Do assumes that tasks fall into typical time-frames.  When you think of a task, you want to write it down before you forget.  At that moment you don’t care about setting an exact due date, but you do have an idea of the time-frame:

• Today (Go to post office, Reply to Jim)
• Tonight (Call mom, Take out the trash)
• This Weekend (Fix the fence, Holiday shopping)
• Some Day (Learn Japanese)

At the start of a day you might want to review all your tasks and move certain items to Today.  But if you’re like me, as the day unfolds you realize that maybe you were a little…ambitious.  You decide to push certain things.  Now you don’t want those deferred tasks staring you in the face all day, do you?  No problem.  Move them to:

• Tomorrow
• This Week
• Next Week

My favorite thing about Better Do is that it’s very easy to move, sort and generally mange your tasks with minimal taps.

Give it a try, and please rate it or review it.

Should Assertion Library (“Should” for short) is a library of test assertion methods for .NET.  It is totally independent of, and completely compatible with any testing framework.  It was created by Eric Hexter, and I subsequently added a fluent interface which I ported from ShouldIt.  ShouldIt is now deprecated.

Should comes in two flavors:

• normal (Should.dll)
• fluent (Should.Fluent.dll).

Get It

You can get the latest binaries from NuPack or the project site.

By the way, if you haven’t tried NuPack yet, go get it right now!  You’ve got it? Okay, open the Package Management Console and enter:

> Install-Package Should

or

> Install-Package ShouldFluent

This will install Should as a package in the current solution.  You probably want to use either the fluent API or the normal API in any given test project – but not both.  Choosing one or the other will promote a consistent practice within your team.  Obviously, I prefer the fluent API.

Use It

There’s not much to say about usage.  It’s really pretty intuitive and discoverable.  Just start typing “.Should” after your actual object, and you will see what’s available.  To give you a taste, here’s a simple example:

actual.ShouldNotBeNull();
actual.ShouldBeType<Foo>();
actual.ShouldBeSameAs(expected);

Or fluently:

actual
    .Should().Not.Be.Null()
    .Should().Be.OfType<Foo>()
    .Should().Be.SameAs(expected);

There are several examples of both the normal and the fluent syntax here.

Enjoy!

A Note To ShouldIt Users: If you have been using ShouldIt, just remove the ShouldIt DLLs, add Should.Fluent.dll, and change the namespaces.  Everything should just work. Of course depending on which test framework you were using with ShouldIt, the underlying assertion behavior could change slightly. It should be pretty easy to spot the differences and make any small corrections as needed.

Almost a year and a half ago I created ShouldIt.   Soon after I added a fluent API.  My goal was to create a test assertion library that would be portable across all major test frameworks.  This would allow me to move from project to project using the same nice test assertions without the sick feeling I was getting from copy-paste reuse.  So I created the API, sprinkled in a little MEF, stirred, and ShouldIt was born.  It felt really good.

My joy was dampened however by one nagging issue.  Although ShouldIt plugged nicely into any framework I might ever use, it carried with it a binary dependency to some particular version of each testing framework.  This made it really hard to distribute, and thus hard to achieve any kind of adoption.  This is probably why Eric Hexter yawned when I told him about ShouldIt.  He went looking for a better way.

Then Came Should

Recently he found it, and created Should Assertion Library (or “Should” for short) .  Whereas ShouldIt leveraged the assertion machinery of whatever test runner you might be using, Eric created a library with it’s own machinery, thus completely breaking any dependence on a testing framework.  On a side note, I had briefly considered doing this myself with ShouldIt.  I was cured of this notion by perusing the assertion source code in NUnit.  It is, uh, non-trivial.  So how did Eric pull it off?  Is he a more talented and dedicated programmer than I am?  Probably yes, but he did not create it either.  Rather, he forked the assertion machinery of xUnit (with the blessings of the xUnit folks).  Brilliant!

They Get Married

When I saw Should Assertion Library I knew immediately that this was the way to go.  My only complaint was that ItUsedVeryLongPascalCaseNamedAssertionMethods.  Okay, you either love the fluent style of assertions or you hate it.  I love it, and I refuse to go back.  So I decided to see how hard it would be to port ShouldIt’s fluent API bits into Eric’s project.  It turned out to be very easy, so I suggested to Eric that Should Assertion Library might support two styles: fluent and long name.  He agreed, and very soon the Should.Fluent assembly was created.

More: Getting Started With Should Assertion Library.