Answer My Query

The discussion, about what constitutes OSS and not, have been going on on Twitter and the .NET blogosphere for a couple of weeks now. The root of it all has been whether or not Microsoft should call their work with ASP.NET MVC as open-source or not. Reading what has been said and taking part in the discussion myself I feel that quite often the discussion is clouded by our individual thoughts on what constitutes as open-source or not, rather then what the actual definition states.

So what does the definition says? Well we can look at the Open-Source Definition, by the Open-Source Initiative, and the Free Software Definition, by the Free Software Foundation for guidance on that. I won’t recite any of sources because both have very clear definitions on their websites.

What’s missing from this picture?

There are a couple of things missing for both of them. Things like when and how often do you need to make source code publically available? Do you need to develop in the open, with public roadmaps and feature discussions? Do you have to accept code contributions or not?

For the most of us (?) those are no brainers; you should put code out in the public as quickly as you can, engage in discussions with your community and accept contributions with open arms as long as it is true to your vision.

However these are all values that we, as a community, layer on top of the definition of open-source and open-source software. These are things we have seen help increase the transparency in our projects, help improve quality and add more value to our work.

You can take all of that away and still do open-source, but you are selling yourself short (if you ask “us”) if you do.

What can we do?

You tell me! One idea I had tonight, while arguing about this on Twitter, was that maybe we need a way to measure the maturity of open-source participation of a company/product.

If you’ve ever read anything about REST you may have come across the Richardson’s Maturity Model for services on the web. Basically it’s a measuring stick for how far you’ve come with your REST adoption. Check out the link so read about the 4 levels of the model.

What if we could apply the same idea for open-source? What if we had something like this

• Level 3. Accepts patches
• Level 2. Make code available on a regular basis
• Level 1. Develops in the open
• Level 0. Compliant with the OSI / FSF definition of open-source

These maturity levels aren’t something I’ve been philosophizing about for a long time, in fact they popped into my head about 30 minutes ago while I was engaged in the Twitter discussion.

Just to be crystal clear; The number of levels and the the definition of each level is not something I would consider set in stone at the time of the writing.

Instead I hope they can inspire to some interesting discussion and perhaps even a consensus on what such a model should look like.

Maybe I’m just talking out of my ass here or maybe I am onto something. Either way, let me know in the comments. I personally thing something like this could help out when we, the community, talk about open-source and open-source software

[This post is by Android designer Alex Faaborg, on behalf of the entire User Experience team. —Tim Bray]

When we initially released Android Design, by far the number one request we received was for us to release stencils as well. The fine folks on the Android User Experience team are pleased today to release some official Android Design stencils for your mockup-creating pleasure.

With these stencils you can now drag and drop your way to beautifully designed Ice Cream Sandwich (Android 4.0) applications, with grace and ease. The stencils feature the rich typography, colors, interactive controls, and icons found throughout Ice Cream Sandwich, along with some phone and tablet outlines to frame your meticulously crafted creations.

Currently we have stencils available for those venerable interactive design powerhouses Adobe® Fireworks®, and Omni® OmniGraffle® and we may expand to other applications® in the future. The source files for the various icons and controls are also available, created in Adobe® Photoshop®, and Adobe® Illustrator®. Here are the downloads.

We’ll be updating these stencils over time so, as always, please send in your feedback!

Happy mockup making,
— Your friendly Android Design Droids

Entity Framework 5 beta is now available on nuget. EF5 includes many long awaited features which were dependent on the .NET framework 4.5 such as Spatial Data types, Enum support and Table-Valued functions. EF5 also includes significant performance improvements. You will need Visual Studio 11 in order to work with EF5, however EF 4.3.1 was also released which includes several bug fixes.

Install EF5 using the -includeprerelease tag

More info is available on the ADO.NET Team Blog here.
 

ASP.NET Web API provides a very similar model to MVC for resolving dependencies using a service locator pattern. What you basically do is to provide the implementation of that service locator to return any of the requested dependencies, and that implementation is typically tied to a DI container. 

The service locator can be injected into the Web API runtime using the ServiceResolver entry in the global configuration object (GlobalConfiguration.Configuration.ServiceResolver), which basically supports different overloads.

public void SetResolver(IDependencyResolver resolver);

public void SetResolver(object commonServiceLocator);

public void SetResolver(Func<Type, object> getService, Func<Type, IEnumerable<object>> getServices);

The first overload receives an instance of a IDependencyResolver implementation, which provides two methods for resolving one or multiple dependencies.

public interface IDependencyResolver

{

    object GetService(Type serviceType);

    IEnumerable<object> GetServices(Type serviceType);

}

GetService should return null if the dependency can not resolved. GetServices should return an empty IEnumerable if the same thing happens.

The second overload uses reflection for invoking the same two methods, GetService and GetServices.

The third overload receives a set of Func delegates for doing the same thing.

Autofac already provides a very smooth integration with ASP.NET Web API through a set of assemblies available in the “Autofac ASP.NET MVC integration” nuget package. The bad news is that you can not use the DepedencyResolver implementation in that package as it is not compatible with the one required by ASP.NET Web API.

The AutofacDepedencyResolver class in that package implements System.Web.Mvc.IDependencyResolver, while ASP.NET Web API expects a System.Web.Http.Services.IDependencyResolver implementation. Nothing that we can not fix with  a simple few lines of code. We can reuse the existing implementation through the third overload that receives a set of delegates.

The following code snippet illustrates how you can register all dependencies in the Autofac container and use that for resolving all the Web API dependencies,

ContainerBuilder builder = new ContainerBuilder();

builder.RegisterType<ContactRepository>()

    .As<IContactRepository>()

    .InstancePerHttpRequest();

builder.RegisterApiControllers(Assembly.GetExecutingAssembly()); 

IContainer container = builder.Build(); 

var resolver = new AutofacDependencyResolver(container);

GlobalConfiguration.Configuration.ServiceResolver.SetResolver(

    t => resolver.GetService(t),

    t => resolver.GetServices(t));

One the things you can do with Autofac is to set the lifetime of the dependencies instances to be equal to a http request lifetime by using the “InstancePerHttpRequest” method. I also created a simple extension method “RegisterApiControllers” to automatically register all the existing Api controllers in the the project into the DI container.

public static class RegistrationExtensions

{

    public static IRegistrationBuilder<object, ScanningActivatorData, DynamicRegistrationStyle> RegisterApiControllers(this ContainerBuilder builder, params Assembly[] controllerAssemblies)

    {

        return

            from t in builder.RegisterAssemblyTypes(controllerAssemblies)

            where typeof(IHttpController).IsAssignableFrom(t) && t.Name.EndsWith("Controller")

            select t;

    }

}

Using the code above, you should be able to use a API controller that looks like this (The contact repository is injected as a depedency)

public class ContactController : ApiController

{

    IContactRepository repository;

    public ContactController(IContactRepository repository)

    {

        this.repository = repository;

    }

When I started thinking about adding animations to the slide presenter I pictured a few different types of animations – simple animations to make items appear one by one, but also animations to pan, zoom, and rotate a slide (like Prezi, which is Flash based, but really more like Impress.js, which is all script and CSS).

I wanted animations to be decoupled and extensible, yet still give the slide presenter control over the animations. When an animation like "appear one by one" is in effect, then a "move forward" operation shouldn't go to the next slide, but should step the animation forward to make an item appear. Once all the items are on the screen then "move forward" can advance the slide. A "move back" should cancel any running animations and go to the previous slide.

It's funny – as I was thinking of these features I thought about eventing with jQuery trigger and completion signals with jQuery promises. Then I thought I better keep it simple and plowed ahead using function callbacks for everything.

My unit tests told me the design wasn't working. When small changes make tests break and feel brittle, it is a general indication of trouble – like a warning bell.

With YAGNI disproved I was back to promises and triggers. At the heart of the matter is a completionSignal. All the animation modules rely on completionSignal to broadcast when the animation is finished, and tell them if the animation needs to stop early (the presenter triggers the killAnimations event if the slides need to jump backwards, to the home, or to the end).

var completionSignal = function () {

    var deferred = $.Deferred();

    var complete = function () {
        $(window).unbind("killAnimations", complete);
        deferred.resolve();
    };

    $(window).bind("killAnimations", complete);

    return {
        resolve: complete,
        promise: deferred.promise()        
    };
};

The beauty of a deferred object, which typically represents an asynchronous operations,  is how other components can register zero or more functions into callback queues via the object's promise. When the deferred object is resolved (successful completion) or rejected (failed), the object invokes the proper callbacks. We'll see an example in just a bit, but for more, see "Creating Responsive Applications Using jQuery Deferred and Promises". For custom events and trigger see  "Event Aggregation with jQuery".

Simple Animation

To see how animation works in the slide presenter, here is a simple animation that will pop up an alert box for the current slide before allowing the presentation to move to the next slide. Animations are added using data- attributes.

<section>
    <h1>This is the title</h1>
    <ul>
        <li data-animation="alert">Show this in a popup</li>
        <li>More text</li>
    </ul>
</section>

The slide presenter finds the data-animation attributes, then looks up a module to call using the value of the attribute. Multiple animations modules can register with the slide show software.

p5.registerAnimations({
    "onebyone": onebyone,
    "timedAppear": timedAppear,
    "zoom": zoom,
    "addclass": addclass,
    "alert": annoying
});

The "alert" animation is aliased from a module named "annoying" (because any kind of modal dialog is annoying). The annoying module uses a signalCompletion to help with lifetime events.

var annoying = function (element) {
    var signal = completionSignal();

    return {
        step: function () {
            alert(element.text());
            signal.resolve();
        },
        done: signal.promise
    };
};

The public API exposed from any animation requires a step method and done property. The slide show software is responsible for invoking the step method when the slide show tries to move forward. The animation is responsible for resolving the "done" promise when the animation is complete. The animation can also use the signal to register cleanup code (none needed in this example). The presenter software uses the promise with jQuery's $.when to remove completed animations from it's call queue.

$.when(animation.done)
 .then(function () {
     currentAnimations.remove(animation);
 });

Does This Painfully Boring Series Ever End?

I'll try to wrap it up next week by looking at only two more pieces: formatting code in a slide, and rotating, panning, and zooming with CSS 3 transforms.

For all the code, see github.