Brain.Save()

A few days ago I created my own little political action committee on Facebook.

As you might infer from the title of this post, it's about ending nuke-you-luhr terrorism.

All are welcome and membership is free. The link is here. 

We now return to our regularly scheduled programming.

As we get closer to PDC, it's nice to be able to talk a little bit more concretely about what Oslo is.

As others have mentioned, Oslo has three basic components:

• A tool that provides a visual environment for creating, editing, and interacting with models
• A language for authoring models in a concise, textual way
• A relational repository for storing models, querying models, and making model data available to other parts of the platform

As Don mentioned, one of the goals of Oslo is to make application definition more of a data manipulation exercise as opposed to a code authoring exercise. We'll talk a lot about what this means in detail at PDC.

We're also going to be talking about how core parts of the development platform (.NET -- specifically, .NET 4.0) are evolving to support this vision while remaining independent of the Oslo-specific components. We've been doing a lot of work to bring WCF and WF forward in .NET 4.0 and I'm pretty excited to be able to tell you about them.

Should be a great PDC...

Tagged as: software, indigo

I've often used the "Hundred Dollar Exercise" with groups of folks at SDR's to get a rough sense of how to prioritize features.

This is where you give people a list of possible things you might build and 100 virtual dollars to spend across all of those. The more important you think a feature is, the more money you spend on it. The results aren't really scientific but it's a quick way to get a general sense of how important various things are to customers.

In smaller groups, it's interesting to run the exercise multiple times.

Between each iteration, you can have a discussion about why a person chose to invest more in Feature X vs Feature Y and the rationale behind their decisions. Everyone in the room listens to the arguments, and then you run the exercise again until the everybody's "budgets" agree within some reasonably small epsilon.

This is same consensus-building approach that Wideband Delphi uses for task breakouts and work item estimation, but applied to the domain of relative priority instead of individual task duration. 

The hunch is that the same crowd-based wisdom that helps Wideband Delphi produce accurate estimates will also apply well to other nebulous problem domains like strategy and opportunity analysis.

We're looking at making some improvements to our configuration system in the next release of WCF.

I'm very interested in hearing peoples impressions of today's configuration experience with WCF. What works well? What irritates you? What's easy and what's hard? If you could change one thing (or five) about WCF configuration and the SvcConfigEditor.exe, what would it be? What's really important to you that we absolutely should not change?

I'm particularly interested in real-world feedback on how you'd grade the current solution on the following:

• Out-of-box developer experience
• Managing change across development lifecycle (dev/test/production)
• Separating out "stuff the IT Pro twiddles" from "stuff the service developer twiddles"

But any and all feedback you have in this area would be valuable, so don't be shy. Lots of folks from the product team will be watching the comments on this post as well as it's link cloud. If you prefer email, send me mail at smaine @ microsoft . com and I'll make sure it gets to the right people.

Check out http://blogsvc.net -- a neat open-source implementation of an APP content management system built using the WCF web programming model. Nice work, Jarrett!

I hope the new Service Document OM we added in 3.5 SP1 will help cut out some of the more tedious parts of your implementation.

Side note -- are you doing open source work with the WCF web programming model? Send me an email (smaine @ microsoft . com), I'd love to hear about it

Congrats to all my friends working in the Identity space on the relase of first beta of the Zermatt SDK.

Other folks have written some great posts that provide the background and motivation for Zermatt better than I ever will, and there are some links you should check out at the bottom of this post.

Suffice it to say that Zermatt is about making the power of the claims-based identity protocols we shipped in WCF V1 programmable and usable by normal humans.

Zermatt has a few things that I think are really exciting:

• Integration with IIdentity/IPrincipal, so code that you've written using [PrincipalPermissionAttribute] can be easily adapted to use claims-based authorization.
• A new HttpModule for ASP.NET Web Application, making it much easier to turn web applications into claims-based identity consumers.
• New ASP.NET UI controls for adding federated identity login capability to your web pages.
• New framework API's that make creating security token issuers (STS's) much easier to implement.

I highly recommend reading Keith Brown's whitepaper for Zermatt developers, as it gives a great overview of what Zermatt is about and the value proposition it holds for connected application developers.

I'm really looking forward to playing with this.

Here are some more links:

• Zermatt announcement from Vittorio Bertocci
• Zermatt announcement from Keith Brown
• Download the Zermatt Beta SDK

Happy hacking!

Overheard in the restroom at a recent Web 2.0 gathering:

"Did you see that new RPC stack that Google is wearing? How gauche!"
"I know! It's so last season..."
"The whole thing is just so...I don't know...petty bourgeoisie"

And here I thought all the cool kids were doing REST. Silly me.

Tagged as: indigo, software

I recently discovered a new (to me, at least) feature in Visual Studio called "Export Template". This guy lives in the VS File menu and makes it really easy to spit out VS project/item templates that you can use to create new apps. Very cool, and very easy.

One thing that's bugged me about the default WCF templates that ship in the box is that sometimes, the templates are too rich for what I want to do. Specifically, we don't ship an item template for an "empty .svc file" that doesn't have any configuration and doesn't spit out any code behind. I find myself wishing for this when I'm writing quick-and-dirty ASP.NET apps that host WCF services.

So last night I took my newfound knowledge of VS's "Export Template" feature to build me a few new templates that were more geared for what I personally wanted, and I thought I'd share.

The first one defines a custom System.ServiceModel.Activation.ServiceHostFactory inline in the .svc file, which lets me set up bindings imperatively:

<%@ ServiceHost Language="C#" Debug="true" Service="Service" 
                Factory="CustomFactory" %>

using System.ServiceModel;
using System.ServiceModel.Activation;

public class CustomFactory : ServiceHostFactory
{
    protected override ServiceHost CreateServiceHost(System.Type serviceType, System.Uri[] baseAddresses)
    {
        var host = base.CreateServiceHost(serviceType, baseAddresses);
        host.AddServiceEndpoint(typeof(Service),
                                 new BasicHttpBinding(), "");

        return host;
    }
}

[ServiceContract]
public class Service
{
    [OperationContract]
    public void HelloWorld()
    {
    }
}

If I'm being a bit more disciplined and externalizing bindings and such in config like a Good Developer, I can get an "empty" .svc file using the InlineService template. This one will throw an exception unless you explicitly add at least one endpoint in configuration yourself:

<%@ ServiceHost Language="C#" Debug="true" Service="Service" %>
using System.ServiceModel;

//Don't forget to add at least one endpoint in configuration!

[ServiceContract]
public class Service
{
    [OperationContract]
    public string Get()
    {
        return "Hello, world!";
    }
}

And finally, here's one that uses the System.ServiceModel.Web.WebServiceHostFactory to bootstrap my development of REST services. This one doesn't need any configuration at all, thanks to WebServiceHostFactory:

<%@ ServiceHost Language="C#" Debug="true" Service="RestService" 
                Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>

using System.ServiceModel;
using System.ServiceModel.Web;

[ServiceContract]
public class RestService
{
    [OperationContract]
    [WebGet( UriTemplate="*" )]
    public string Get()
    {
        return "Hello, world!";
    }
}

If you like, you can download these templates for your own use here:

CustomServiceHost_CS.zip
CustomServiceHost_VB.zip
InlineService_CS.zip
InlineService_VB.zip
RESTService_CS.zip
RESTService_VB.zip

To install, just copy the .zip file to your <user>\Documents\Visual Studio 2008\Item Templates directory (no need to unzip, It Just Works):

 

Once that's done, you should see them when you do "Add New Item" to an ASP.NET Web Site or ASP.NET Web Application Project in Visual Studio. You can see them hanging out in the bottom of this dialog:

If you find these useful, let me know. Especially if you have interesting ideas about Item Templates/Project Templates relating to WCF development that you'd like to see in the box...

Tagged as: software, indigo, visual-studio

I spent a little bit of time this weekend playing around with IIS7's Hostable Web Core feature. This is a new thing in IIS7 that allows you to host IIS7 in a worker process of your own choosing. Kanwalijeet Singa has a nice description of the feature on his blog.

I love the idea of a having a lightweight, rehostable version of the IIS pipeline that can I stick anywhere. HostableWebCore is a great step in that direction, but (looking at things from a framework perspective, at least) it's not quite what I want.

Bring-your-own-process is nice, but I think I really want bring-your-own-app-domain as well. Having an appdomain barrier between the host and the pipeline is nice for reliability and enables things like AppDomain recycling, but I don't think I need that in all cases. I'd like to be able to new() up an IHttpHandler with some state in the host and stuff it in a Handlers collection and be done, without having to indirect though a local copy of applicationHost.config. I'd be willing to treat that pipeline configuration as immutable once opened in exchange for this capability.

I'd like to break the dependency on the physical file system as well, while we're at it. It would be nice if file system structure on disk were an option, not a requirement.

I wish the scope of HostableWebCore was at the virtual directory/application level instead of the site level. I'd love manage the HTTP.SYS URL reserverations externally instead of having HostableWebCore do it for me. This mainly so I can have multiple instances of this thing listening on the same port, demuxing by URL prefix at the HTTP.SYS layer. Right now I can't have multiple instance of HostableWebCore share the same port and that's heartbreaking.

Finally I wish there was a way to manage the receive loop externally so I have my own listener sitting under this thing pulling messages of of HTTP.SYS, I can just push these requests into the pipeline myself. Decoupling the pipeline from a direct dependency on HTTP.SYS would be a nice thing. I'd like to be able to swap out HTTP.SYS entirely in favor of my own sockets-based receive loop if I wanted to do such a thing. It's true that most scenarios would just use HTTP.SYS, but the ability to have different listeners is a good proof point for the architecture IMO. I also have a couple of crazy ideas floating around in my head that would use this capability, but I'm not quite ready to go public with those yet :)

To finish this off, here's an example of some hosting code that I'd like to be able to write:

public static void Main()
{
    var pipeline = new PipelineHost()
    {
        Port = 80,
        Hostname = "*",
        UrlPrefix = "mysite/myapp",
        
        Modules = 
        {
            new OutputCachingModule(),
            new SessionStateModule()
            {
                Provider = new SqlSessionStateProvider()
                {
                    ConnectionString = "Server=myDb;IntialCatalog=ASPNet;IntegratedSecurity=true"
                }
            }
        }
        
        Routes =
        {
            new Route()
            {
                UriTemplate = "customers/{id}",
                Handler = new CustomerHandler()
            }
        }
    }
    
    pipeline.Start();
    Console.ReadLine();
}

 

There are obvious issues around separation of concerns here when you define the behavior of the app completely inline like this. However, there are lots of ways to address those; the fact that the app can be be written this way if you want to is another one of those leading indicators that you got the arch right.

What do other folks think?

Tagged as: musing, software

This post probably sets me up for an awkward conversation with ClemensV on Monday, but oh well. To Clemens and the DasBlog crew -- thanks a ton for all your hard work to make DasBlog the engine that has powered Brain.Save() since I first started writing it back in 2003 (!).

However, I felt it was time to move on to a more 'turnkey' solution for my site.

I flipped the site over last night to Graffiti CMS 1.1 while I was eating an AllAmerican Slam at my local Denny's. The move was seriously that simple. I was able to use the DasBlog Import feature to move the content over pretty much automatically...all 800+ posts came through mostly unscathed. The hardest part was finding a theme that I liked. I'm not really a CSS wizard (which is probably obvious), but I was able to find a reasonable starting point on the Web and then twiddle a bit to get to a good place for now.

Overall, I'm really impressed with what Graffiti has to offer.

One of the reasons why I made the switch was the ecosystem that seems to be building around Graffiti themes, widgets and plugins. I spend my spare time hacking on code for other projects (i.e. not my blog), so I'm looking for a lot of off-the-shelf/off-the-web functionality from the product and the community.So far I've been pleased with what I've seen other people build for me :)

There are few things that I'm still looking for:

• A reasonable solution for syntax-highlighted code that plays well with Graffiti themes. I've noticed that some of my old posts containing syntax-highlighted code don't render well with the new CSS, and I'd like to get that fixed. Ideally I'd be able to do this through a Chalk Extension or a tag that gets processed on the server (<div class="code"> would be ideal).
• An "archives" page that every post I've every written, from newest to oldest (potentially several pages organized by month/year).
• Chronological "next post"/"previous post" links that appear in the single-post view
• Some way for administrators to tag posts directly from the index view, so I don't have to explicitly open each page in the editor

These are all pretty common idioms and I'm sure they are doable with a little bit of Chalk/widget magic...anyone want to educate me?

Tagged as: metablog, graffiti