My Startup Life [Review]


I just finished reading My Startup Life by Ben Casnocha. It an interesting and enjoyable read. It’s a mix of his story and insights and learnings from along the way. The insights and learnings are in side bars, which I found distracting. I might have enjoyed the story first and then then insights second. But I think a little more detail in the story and less or no sidebars would have been better. Anyway, I’d recommend it for anyone with an entrepreneurial streak. I’d give it 3/5 for a great story, good content and an okay mixing of the two.

Prototype classes and bind

I’m working with the Prototype JS library classes, which I’m really liking. But I ran into one stumbling block, Binding. In JS the scope in which your function can be called can change and as such the ‘this’ object can change. The main places this can happen is call back functions for events or anytime anonymous methods are used. Justin Palmer explains it really well here.

$(‘console’).observe(‘click’, prompt.focusLine.bindAsEventListener(prompt));

The above will bind the focusLine method to the _prompt object when the event callback is fired. The same thing applies for events within a custom defined Class.

Facebook.NET Configuration Section

I’m checking out the Facebook.NET libraries, and find the documentation to be very lacking. I could be looking in the wrong places. Anyway, to setup the configuration section, you need to reference the FacebookNET.Web.dll. Then in your config file add a section entry to the configSections tag like:

<section name="facebook" type="Facebook.Web.Configuration.FacebookSection, FacebookNET.Web" allowDefinition="MachineToApplication"/>

Then add the Facebook section with your info to the configuration tag:

    <application name="Facebook.NET App" apiKey="[App Key]" secret="[Secret]"/>

That’s it. Now you can access that info from code like:

var fbSection = (FacebookSection)ConfigurationManager.GetSection("facebook");
var secret = fbSection.Applications["Facebook.NET App"].Secret;

Castle microkernel Shows It’s strength

I’m a big fan of the stack, but the MicroKernel really shows it’s strength when you need to do a couple of custom things, and find out that the customization is really easy, and intuitive.

Setting up a facility to add a custom bunch of objects. I think there are already facilities to do this, but it’s really simple for standard cases and allows you to easily get things setup. You basically just need to override the Init method.

protected override void Init()

List<Assembly> assemblies = ReadConfigForAssemblies(FacilityConfig);
<span class="kwrd">foreach</span> (Assembly assembly <span class="kwrd">in</span> assemblies)


The configuration is already read in for you, so parsing that is easy.

public List<Assembly> ReadConfigForAssemblies(IConfiguration facilityConfig)
    List<Assembly> assemblies = new List<Assembly>();
        foreach (IConfiguration configuration in facilityConfig.Children)
            if (configuration.Name.Equals("assembly", StringComparison.InvariantCultureIgnoreCase))
    catch (Exception e)
        throw new ConfigurationErrorsException(
            "Assembly could not be loaded, check you have the correct name in the configuration.", e);
    return assemblies;

Lastly, you can search through the configured assemblies and register any types that match what your looking for.

private void LoadCommands(Assembly assembly)
    foreach (Type type in assembly.GetTypes())
        if (typeof (IMyInterface).IsAssignableFrom(type) && !type.IsAbstract && type.IsPublic)
            Kernel.AddComponent(type.FullName, type);

This is getting to be a long post, but I'm sure you're wondering about testing. It's easy too! You have to mock out the configuration stuff, but that's really it. I just put into a setup method and once done you have your container setup and ready for testing.

public void Setup()
    _container = new WindsorContainer();
    _facility = new CommandFacility();

    _mocks = new MockRepository();
    IConfiguration config = mocks.DynamicMock<IConfiguration>();
    IConfiguration configChild1 = mocks.DynamicMock<IConfiguration>();
    IConfiguration configChild2 = mocks.DynamicMock<IConfiguration>();

    using (_mocks.Record())
        Expect.Call(config.Children).Return(new ConfigurationCollection(new IConfiguration[] { configChild1 }));

    using (_mocks.Playback())
        _facility.Init(_container.Kernel, config);

There's more documentation on the Castle site. Next time custom dependency resolvers and sub kernels...

Castle MicroKernel Shows It’s Strength P2

Continuing from my previous post… Using Custom Dependency Resolvers and Sub Kernels. I think this is more of an edge case, but the fact that I can be done really easily is where the Castle strength is.

First, I see two nice things about Sub Kernels, they can be used by themselves or added as a child to another Kernel, meaning for testing and other uses, the Kernel can be completely hidden. Next, when added as a child, dependencies that live in the parent container can be used by types in the child container, automatically. I don’t know if there are any guide lines as to when to use a Sub Kernel, but I would consider it when you have a custom facility or a factory class which stores a lot of types or if you need to customize the Kernel in some way. Using a container is as easy as creating the class and allowing a Kernel to be passed in a Constructor when needed.

private readonly IKernel _container = new DefaultKernel();</p>

public MyFactory() {

_container.Resolver.AddSubResolver(<span class="kwrd">new</span> CaseInsensitiveDependencyResolver());


public MyFactory(IKernel parent) : this()



Secondly, Customizing the Kernel with a CustomDependencyResolver, is easy and very useful when you need to do that. In this case I have a simple Resolver which looks at the additional parameter dictionary (passed to the Resolve Methods) and looks for a match ignoring case. I just needed to implement the ISubDependencyResolver interface which only has two methods, and register it on the container using Resolver.AddSubResolver (You can also overwrite the main Resolver when the Kernel is created). SubResolvers should return null if they didn't resolve the dependency, the main Resolver will throw an error if it's a required dependency.

internal class CaseInsensitiveDependencyResolver : ISubDependencyResolver
    public object Resolve(CreationContext context, ISubDependencyResolver parentResolver, ComponentModel model,
                          DependencyModel dependency)
        foreach (DictionaryEntry entry in context.AdditionalParameters)
            if (dependency.DependencyKey.Equals(entry.Key as string, StringComparison.InvariantCultureIgnoreCase))
                return entry.Value;
        return null;

    public bool CanResolve(CreationContext context, ISubDependencyResolver parentResolver, ComponentModel model,
                           DependencyModel dependency)
        if (context == null || context.AdditionalParameters == null)
            return false;

        foreach (DictionaryEntry entry in context.AdditionalParameters)
            if (dependency.DependencyKey.Equals(entry.Key as string, StringComparison.InvariantCultureIgnoreCase))
                return true;
        return false;

Again, as always, there’s more info on the site.

Using flags in c#

Some notes about using enums as flags in C#. Use the FlagsAttribute on you enum. Have a None option set to 0. Have the first option start at 1, and each next value should be 2 times the previous one (I wonder what that pattern is called). Something like:

public enum PropertyOptions

None = 0,
IgnoreProperty = 1,
DisplayName = 2


Checking if a flag is set is done using the following syntax:

bool isIgnoreSet = (_options&PropertyOptions.IgnoreProperty) == PropertyOptions.IgnoreProperty;


Using The Enum:

Attribute Values on interfaces are not inherited

I guess it makes sense, that an interface is implemented, not inherited, but I think it’s confusing that interfaces are ignored when searching for custom attributes, using the GetCustomAttributes methods.

Attributes shouldn’t be thought of as part of an interface, strictly meta data in that case? No, I think, interfaces should have been searched, that member is part of an interface, and implementations should have access to that members metadata. If nothing else, custom attributes defined with inheritance should be required to be implements by the implementers.

Brutalist Framework