Inferables for CLR- Scoping it out, Factoring in the Factories, And Finishing It Up.

In this final post in the Inferables IOC framework series, I will discuss how scope is managed, and how to make implicit factory bindings through interfaces. So if your into singletons, this post is for you. And if you just love the factory pattern but not the tedious coding of factories, then you’ll be smitten by this article as well.

Singleton Scope Through Convention:

To illustrate Singleton scoping, lets look at this code example defining some types:

namespace ScopeExamples
{
    public interface ISampleObj{}

    public class SampleObj: ISampleObj
    {
    }
}

If we use inferables multiple times to get an instance of the same object type, we will have a unique instance for each call.

var module = ModuleManager.CreateModule();
var obj1 = module.Get<ISampleObj>();
var obj2 = module.Get<ISampleObj>();

// comparison equals false- are different instances
var areSame = Object.ReferenceEquals(obj1,obj2)  

So what if you want a singleton? Well, like everything in Inferables, there is a convention for that. Just use the prefix Singleton in front of searched name:

namespace ScopeExamples
{
    public interface ISampleObj{}

    public class SingletonSampleObj: ISampleObj
    {
    }
}

Now, for the module that has been created, all instance retrievals of that type will be of the same allocated instance in memory:

var module = ModuleManager.CreateModule();
var obj1 = module.Get<ISampleObj>();
var obj2 = module.Get<ISampleObj>();

// comparison equals true- are same instance.
var areSame = Object.ReferenceEquals(obj1,obj2)  

If you prefer factory methods, just use the prefix CreateSington before the searched name in the method declaration:

namespace ScopeExamples
{
    public interface ISampleObj{}

    public static class SampleObjFactory
    {
        public static ISampleObj CreateSingletonSampleObj()
        {
            ...
        }
    }
}

Like using the Singleton convention on class definition, this pattern with factory methods will also result in creating singleton instance shared for all retrievals from the container module.

Shared Scope Through Convention:

Along with Singleton scope, Inferables also supports Shared scope. This scope is designed for dependencies that need only one shared instance per creation of the container. Like Singletons, Shared objects are defined by convention- using the Shared prefix in front of the search pattern. Unlike singletons, shared instances are not unique to the module.

To understand this concept better, lets look at an example:

namespace SharedExample
{
    public interface ILogger
    {
        void Write(string info)
    }

    public interface IDataAccessLayer
    {
        ILogger Logger{get;}
        ...
    }

    public interface IBusinessLogic
    {
        IDataAccessLayer DataAccessLayer{get;}
        ILogger Logger{get;}
        ...
    }
}

These interface definitions define a container business logic class- IBusinessLogic- and data access layer dependency-IDataAccessLayer- that both use a logging component -ILogger. If we wanted to have a central logging instance shared amongst the business logic container and its data access layer dependency, we could use this convention to accomplish this. First, lets create our class definitions for the IBusinessLogic and IDataAccessLayer, injecting the ILogger component through constructor injection:

namespace SharedExample
{
    public class DataAccessLayer: IDataAccessLayer
    {
        public ILogger Logger{get; private set;}

        public DataAccessLayer(
            ILogger logger)
        {
            this.Logger = logger;
        }
    }

    public class BusinessLogic: IBusinessLogic
    {
        public ILogger Logger{get; private set;}
        public IDataAccessLayer DataAccessLayer{get; private set;}

        public BusinessLogic(
            IDataAccessLayer dataAccessLayer, 
            ILogger logger)
        {
            this.DataAccessLayer = dataAccessLayer
            this.Logger = logger;
        }
    }
}

Now, we can define our ILogger class with the name SharedLogger, making it shared amongst its dependencies in a created container:

namespace SharedExample
{
    public class SharedLogger: ILogger
    {
        public void Write(string info){...}
    }
}

This will ensure that during retrieval of the business logic object, loggers will be shared between the business logic and its data access layer dependencies, but not separate business logic instances. We can see this in the sample code below:

var module = ModuleManager.CreateModule();
var bl = module.Get<IBusinessLogic>();

// result is true, logger instance is shared between container and
// its dependencies
var result = Object.ReferenceEquals(bl.Logger,bl.DataAccessLayer.Logger);

var bl2 = module.Get<IBusinessLogic>();

// result is false, logger instances between different containers are
// unique to their container. 
result = Object.ReferenceEquals(bl.Logger,bl2.Logger);

Also, just like with Singletons, Shared scoping can be implied in factory methods using the CreateShared prefix. Using the factory method example below instead of the SharedLogger class results in the same shared scoping behavior:

namespace SharedExample
{
    public static class LoggerFactory
    {
        public static ILogger CreateSharedLogger()
        {
            ...
        }
    }
}

And Finally, Custom Factories:

The module mechanism in Inferables is very flexible, allowing creation of any type as long as it follows a pattern. In a production environment with many contributors to the codebase, it may be desirable to limit the types of objects Inferables can instantiate to prevent undesired object creation and errors. This can be accomplished through custom factories (yay!).

Custom factories are simply interfaces that follow a pattern, designed to serve up specific types based on Inferables’ conventions. Creating a custom factory is easy- simply define an interface and add methods following the convention below:

interface anyInterfaceName
{
    BaseType GetTypeSuffix();
    ...
}

We can illustrate this concept better with an example. Lets say we have some types defined somewhere:

namespace CustomFactoryExample
{
    public interface ICoolType{}    
    public class OneCoolType: ICoolType{}
    public class AnotherCoolType: ICoolType{}

    public interface ISpecialType{}
    public class SingletonSpecialType: ISpecialType{}
}

By the previously outlined conventions, we could then create a custom factory for these types by simply defining an interface:

public interface IAwesomeFactory
{
    ICoolType GetOneCoolType();   
    ICoolType GetAnotherCoolType();   
    ISpecialType GetSpecialType();   
}

To use this as a container in code, we would then create a factory instead of module using the ModuleManager.CreateFactory method. Inferables will generate the factory type based on its convention rules:

var factory = ModuleManager.CreateFactory<IAwesomeFactory>();

// creates an instance of OneCoolType
var ct1 = factory.GetOneCoolType();

// creates an instance of AnotherCoolType
var ct2 = factory.GetAnotherCoolType();

// creates a singleton instance of SingletonSpecialType 
var ct3 = factory.GetSpecialType(); 

Presto change-o, finit-o. And a custom factory is born :)

In Conclusion:

While introducing Inferables, I have received a lot of reactions like “Cool! Thats nifty I want to try it out”. I have also recieved alot of reactions like “Why create a IOC framework when so many exist today and they seem to do the job- why saturate this already saturated space?” My answer to that question can be summed up in a few points:

  1. IOC frameworks these days tend to be overkill. It can be argued that for the majority of cases in software development, dependecy injection works just fine just by using patterns like constructor injection. It would be nice that if an IOC framework is used, simple conventions can manage majority of desired business cases where patterns are becoming tedious- such as creating a mock proxy environment for parallel development and unit testing.
  2. Although IOC frameworks exist, not one really is built from the ground up to support convention. If a convention based approach exists, they usually are add-ons to a framework that was originally intended for configuration. Inferables is designed for the ground up only to support convention and hopes to produce new practice patterns in this realm of development
  3. Most important, its always great idea in software to try a new approach on an existing pattern, just get a conversation started and see where it leads. Best case scenario, a new useful tool is added to the community. Worst case scenario, we learn something. And thats what makes software development worthwhile :)

Thats what Inferable’s is about: an alternative approach for people who prefer a conventions based approach to coding, and want to try something new. With this, your feedback is appreciated. Please comment on suggestions on where to go next with the framework, it would be nice to grow this in the future. And if interested, fork and contribute to the Inferables project on GitHub. Until then, enjoy the injection :)


Inferables for CLR- A Good Name You Can Depend on.

In my last post, I introduced one of the fundamental differentiators of the Inferables IOC framework, Bindings and Binding Expressions. In this post I will explain the next piece of Inferable’s IOC puzzle: name resolution and dependency resolution.

Name Resolution, How it works:

To explain name resolution, I present a simple IOC example. Lets say you have written some Inferables IOC code:

var module = ModuleManger.CreateModule("~");
var awesomeService = module.Get<CoolStuff.IAwesomeService>();

And lets say you have some types somewhere:

namespace CoolStuff
{
    public interface IAwesomeService{} 
    public class AwesomeService:IAwesomeService{}
}

When var awesomeService = module.Get<CoolStuff.IAwesomeService>();, Inferables will assign the awesomeService variable an instance CoolStuff.AwesomeService. We learned in my previous post, that IAwesomeService would look for implementation types under it namespace CoolStuff because of the binding expression “~”. But why did it choose the class AwesomeService specifically? (And no, the answer isn’t “‘Cause its the only one there.”) To explain this, first I need to let you in on a little secret: the module.Get<CoolStuff.IAwesomeService>() is really implicit form of this call:

module.Get<CoolStuff.IAwesomeService>("AwesomeService")

The covention that Inferables uses for implicit type resolution is: If the requested type is an interface that begins with an I, use the rest of whatever follows the I as the resolvable name. This is based on a pretty common naming convention already existing in C# and VB.Net., so it made sense just to make it a convention.

Now that the desired name specified, Inferables then follows this convention for name resolution:

  1. For namespace matched by the binding rule, look at all public classes that implement the requested base type, ordered by the type name longest to shortest in length.
  2. If a matching type ends with that name being requested, use that as a match, otherwise use the first type that implements the requested base type
  3. If no matches are found, throw an exception.

In this case the match was easy, namespace CoolStuff had one match that named “AwesomeService”, which was easily bindable based on the name resolution convention. Now lets look at a more complex example of types:

namespace CoolStuff
{
    public interface IAwesomeService{} 
    public class MyAwesomeService: IAwesomeService{}
    public class AwesomeService: IAwesomeService{}
    public class FantasticStuff: IAwesomeService{}
}

In this case, module.Get<CoolStuff.IAwesomeService>(“AwesomeService”) returns an instance of MyAwesomeService, since it has a longer name than AwesomeService and since it explicitly named (unlike FantasticStuff).

OK, So what about dependencies? This is dependency injection right?

So far in my post, I have explained how basic types are created. So how are dependencies injected into the parent types? For this, Inferables uses a strict convention of Constructor Injection. Why? Constructor injection is the only form of injection that does not introduce unexpected side effects for the target components. Field and property injection, though allow flexibility, has some serious drawbacks:

  1. With field and property injection, the component has now way of knowing which property gets instantiated after class initialization. This can create unexpected side effects to the state of component when it is initialized in the IOC container.
  2. Along with this, property injection forces the component to have both setter and accessor functionality for the injected properties, limiting when read only properties are desired
  3. Conventions for property injection usually require configuration or decoration, something against the spirit Inferables.

Constructor injection just makes sense when working with a conventions based approach: its simple, well known, and has none of the side effects mentioned above. With this, Inferables uses these rules to choose the appropriate constructor.

  1. Look for all public constructors.
  2. If there is only one, use that one.
  3. If there are two and there is a default constructor, use that overloaded constructor.
  4. If there are two and there is no default constructor, reject match on this type.
  5. If there are more than two, reject match on this type.
  6. If there are no public constructors, reject match on this type.

This convention insures that there is no ambiguity of what constructor gets used when creating a matched component: Use the overloaded if it exists, otherwise use the default. Simple, no confusion. Lets reflect this concept in our example:

namespace CoolStuff
{
    public interface IAwesomeService{}
    public class AwesomeService: IAwesomeService
    {
        public IHypeMaker HypeMaker{get; private set;}
        
        public AwesomeService(IHypeMaker hypeMaker)
        {
            HypeMaker = hypeMaker;
        }
        
        public AwesomeService(): this(new HypeMaker()){}
    }

    public interface IHypeMaker{}

    public class HypeMaker: IHypeMaker{}
}

In this case, the call to module.Get<CoolStuff.IAwesomeService>(“AwesomeService”) uses the overloaded constructor public AwesomeService(IHypeMaker hypeMaker)- it gets precedence based on the aforementioned IOC conventions. Also, when resolving the parameter hypeMaker, Inferables uses the its name resolution convention based on the parameter type being the requested type, and the matching name being the parameter name. As a result module.Get<CoolStuff.IAwesomeService>(“AwesomeService”) generates this code to instantiate the object:

return new CoolStuff.AwesomeService(new CoolStuff.HypeMaker());

Factory Methods, Another Way to Make it Happen.

The constructor convention allows easy understanding of how to create types, but there may be a scenario where this isn’t enough. For instance, maybe an author wants to have the variable to be polymorphically chosen based on some logic that is outside the rules, or maybe there is a component that doesn’t advere to the constructor rules. For this, Inferables allows the use of factory methods. Factory methods are easy to create- simply add a public static method call “Create{ResolutionName}” returning the requested type, and your done resolvable by your binding rules. When resolving requested bases, These methods have precedence over constructed types: so if one exists in the Binding Path, it will be used in lieu of any types that match the requested type.

Lets apply this pattern to our example:

namespace CoolStuff
{
    internal interface IAwesomeService{}
    internal class OkService: IAwesomeService{}
    internal class BetterService: IAwesomeService{}
    internal class AwesomeService: IAwesomeService{}
    
    public static class AwesomeServiceFactory
    {
        public static IAwesomeService CreateAwesomeService(IConfig config)
        {
            switch(config.ServiceType)
            {
                case "Ok":
                    return new OkService();
                case "Better":
                    return new BetterService();
                case "Awesome"
                    return new AwesomeService();
                default:
                    throw new System.ArgumentException(
                        "Type not supported.");
            }
        }    
    }
    
    public interface IConfig
    {
        string ServiceType{get;}
    }
    
    public class Config: IConfig
    {
        ...
    }
}

In this case, the call to module.Get<CoolStuff.IAwesomeService>(“AwesomeService”) uses the factory method CoolStuff.AwesomeServiceFactory.CreateAwesomeService(IConfig config). As a result >module.Get<CoolStuff.IAwesomeService>(“AwesomeService”) generates this code to instantiate the object:

return CoolStuff.AwesomeServiceFactory.CreateAwesomeService(new CoolStuff.Config());

Happiness :)

Whats next?

Hey, what about singletons and shared instances? Don’t they matter? Can you create these with Inferables? Yes and yes, I will cover these in my next post.


Inferables for CLR- The Wonders of Bindings

Last week on devitalics, I introduced a new dependency injection framework called Inferables for CLR, novel in its convention over configuration based approach for “Inversion of Control” (IOC for short). In this post, I want to begin a breakdown of the system, starting with an intrinsic part of how Inferables framework works: Bindings.

Introducing Bindings:

With Inferables, Bindings represent the “master plan” on how the IOC container will behave. Instead explicitly setting “requested base is assigned to this specific type”, inferables takes the approach of “we will assign this requested base by locating a type based on a resolution rule”. This rules based approach has some nice advantages over explicit type mapping:

  1. Code and dependencies can be added without any need to “configure them”, saving time and preventing the “oops, I forgot to map that service :(” syndrome.
  2. Since the rules are known, locating the mapped types for instantiation is straight forward, so there is no need to disect a configuration file, analyse set up code, or hunt down decorations. Just look at the namespace of the requested type and go from there.
  3. Since these rules have to be followed, it ensures that on a larger team of developers, code is named and placed appropriately- easing in future maintenance as the project gets more complex.

Last week I showed a little demo code highlighting how this convention based IOC framework works:

using Inferables;
...

var module = ModuleManager.CreateModule("~");
var snarkyService = module.Get<ISnarkyService>();

var message = snarkyService.GetSnarkyMessage();

We can expand CreateModule(“~”) to a more verbose expression:

var binding = new Binding("~");
var module = ModuleManager.CreateModule(binding);

This binding created var binding = new Binding(“~”); is the rule of resolution, telling Inferables IOC container- the module- where to look up requested implementations of types. The Binding Expression “~” specifically defines the behavior of that binding.

Binding Expressions Explained:

To get an idea how bindings work with these expressions, lets set up some types in a few namespaces for Inferables to map:

namespace Foo.Bindables
{
    public interface IBar{}
    public class Bar: IBar{} 
}

namespace Foo
{
    public class Bar: Foo.Bindables.IBar{}
    public class NotFooBar: NotFoo.IBar{}
}

namespace Foo.Impl
{
    public class Bar: Foo.Bindables.IBar{}
}

namespace NotFoo
{
    public interface IBar{}
    public class Bar: IBar{} 
}

And somewhere in the execution base, lets use the the following IOC code for creation of types:

var binding = new Binding("~");
var module = ModuleManager.CreateModule(binding);

var bar = module.Get<Foo.Bindables.IBar>();
var bar2 = module.Get<NotFoo.IBar>();

For Inferables, the binding expression “~” can also be written longhand as:

* => ~

This formal binding expression represents how Inferables does its job:

Match Path (Namespace Pattern of Requested Type) maps to Binding Path (Allowed Namespace Pattern for Resolvable Types).

In the case of “* => ~”:

  1. The Match Path applies to any namespace.
  2. The Binding Path applies to use same namespace of Match Path.

Thus, the IOC segment results in the following:

  1. var bar = module.Get<Foo.IBar>(); results in creating a Foo.Bindindables.Bar instance.
  2. var bar2 = module.Get<NotFoo.IBar>(); results in creation a NotFoo.Bar instance.

Match Path with Suffix Expression:

Binding expressions can be more directed, for example:

*.Bindables => ~

This sets up a more specified set of rules to match, with the inclusion of namespace suffix after the Match Path wild card “*”:

  1. The Match Path applies to any namespace with the suffix “Bindables”
  2. The Binding Path applies to use same namespace of Match Path.

Thus, this code with the modified binding expression:

var binding = new Binding("*.Bindables => ~");
var module = ModuleManager.CreateModule(binding);

var bar = module.Get<Foo.Bindables.IBar>();
var bar2 = module.Get<NotFoo.IBar>();

Acts as such:

  1. var bar = module.Get<Foo.Bindables.IBar>(); results in creating a Foo.Bindindables.Bar instance.
  2. var bar2 = module.Get<NotFoo.IBar>(); throws an exception, since the NotFoo namespace is not resolvable from the binding expression.

Binding Path with Match Path Prefix Expression:

Another expression:

*.Bindables => -

Sets the prefix of the Match Path to be the Target Path. Thus:

var binding = new Binding("*.Bindables => -");
var module = ModuleManager.CreateModule(binding);

var bar = module.Get<Foo.Bindables.IBar>();
var bar2 = module.Get<NotFoo.IBar>();

Acts as such:

  1. var bar = module.Get<Foo.Bindables.IBar>(); results in creating a Foo.Bar instance, using the prefix path path of Foo.
  2. var bar2 = module.Get<NotFoo.IBar>(); throws an exception, since the NotFoo namespace is not resolvable from the binding expression.

Complex Expression:

Here’s another one:

*.Bindables => -.Impl

This one is interesting:

  1. The Match Path applies to any namespace with the suffix “Bindables”
  2. The Binding Path applies to use same namespace of prefix of the Match Path before “Bindables”, with the added suffix of “Impl”.

And if we modify our code:

var binding = new Binding("*.Bindables => -.Impl");
var module = ModuleManager.CreateModule(binding);

var bar = module.Get<Foo.Bindables.IBar>();
var bar2 = module.Get<NotFoo.IBar>();

We get this result:

  1. var bar = module.Get<Foo.Bindables.IBar>(); results in creating a Foo.Impl.Bar instance, using the prefix path path of Foo and suffix path of Impl.
  2. var bar2 = module.Get<NotFoo.IBar>(); throws an exception, since the NotFoo namespace is not resolvable from the binding expression.

Explicit Expression:

And we can be explicit too. Here’s an example:

NotFoo => Foo

This explicit expression results in this behavior:

  1. The Match Path applies to only the namespace “NotFoo”.
  2. The Binding Path applies to only the namespace “Foo”.

Thus:

var binding = new Binding("NotFoo => Foo");
var module = ModuleManager.CreateModule(binding);

var bar = module.Get<Foo.Bindables.IBar>();
var bar2 = module.Get<NotFoo.IBar>();

Acts as such:

  1. var bar = module.Get<Foo.Bindables.IBar>(); throws an exception, since the Foo.Bindables namespace is not resolvable from the binding expression.
  2. var bar2 = module.Get<NotFoo.IBar>(); results in creating an Foo.NotFooBar instance.

Compound Binding Expressions:

Is there a way to get this code to not throw an exception? Yes there is:

*.Bindables => ~.Impl, NotFoo => Foo

This compound binding expression combines a list of binding expressions to attempt in succession. Thus:

var binding = new Binding("*.Bindables => ~.Impl, NotFoo => Foo");
var module = ModuleManager.CreateModule(binding);

var bar = module.Get<Foo.Bindables.IBar>();
var bar2 = module.Get<NotFoo.IBar>();

Acts as such:

  1. var bar = module.Get<Foo.Bindables.IBar>(); results in creating a Foo.Impl.Bar instance, using the prefix path path of Foo and suffix path of Impl.
  2. var bar2 = module.Get<NotFoo.IBar>(); results in creating an Foo.NotFooBar instance.

And now the code works. Yay :)

In Summary:

As you can see, binding expressions are powerful enough to create a very flexible IOC convention, with a clear sense of where to place resolvable types. This is where Inferables gets the first part of its juice. The other peice of the puzzle, name resolution, will be explained in my next post. Until then, happy coding and tell me what you think:)


Inferables for CLR- Ditching Configuration on Dependency Injection.

Dependency Injection, arghh, a configuration eyesore! -even with exceptional lightweight frameworks like NInject and Castle Windsor. Hoping to change a small part of the world (or at least my world for that matter), I started working on a new solution on Github. Inferables For CLR is inspired by convention over configuration software approaches, providing a dependency resolution system that is based on where code is located and named relative to project namespaces, instead of a configuration mechanism. The result is easier management of standard injection patterns just by putting stuff in the right place :)

An Example:

Lets say your have some injectable classes defined somewhere- a set of loggers for instance:

namespace LoggerStuff
{
    public interface ILogger
    {
        void WriteMessage(string message);
    }

    // A trace logger
    public class TraceLogger: ILogger
    {
        public void WriteMessage(string message)
        {
            Console.Writeline(message);
        }
    }
    
    // A debug logger
    public class DebugLogger: ILogger
    {
        public void WriteMessage(string message)
        {
            Console.Writeline("DEBUG:" + message);
        }
    }
}

And lets say you want to inject them into a class:

using LoggerStuff;

namespace SnarkyServiceLib
{
    public interface ISnarkyService
    {
        string GetSnarkyMessage();   
    }
    
    public class SnarkyService: ISnarkyService
    {    
        private ILogger traceLogger;
        private ILogger debugLogger;  
    
        public SnarkyService(ILogger traceLogger, ILogger debugLogger)
        {
            this.traceLogger = traceLogger;
            this.consoleLogger = debugLogger;
        }
        
        public string GetSnarkyMessage()
        {
            traceLogger.Write("Thinking...");
            traceLogger.Write("Still thinking...");
            traceLogger.Write("I've got it...");   
            debugLogger.Write("Not really thinking, just doing static code");
            
            string message = "SnarkyNess!";
        
            debugLogger.Write("Created Message.");
            
            return message;
        }
    }
}

With Inferables for clr, dependency injection is managed by relative namespace location, requiring no need for configuration in files or code. Thus, through the powers of the Inferables library:

using Inferables;
...

var module = ModuleManager.CreateModule("~");
var snarkyService = module.Get<ISnarkyService>();

var message = snarkyService.GetSnarkyMessage();

results in creating a SnarkyServiceLib.SnarkyService class, injecting LoggerStuff.TraceLogger and LoggerStuff.DebugLogger as inner members.

How it works:

With ModuleManager.CreateModule(“~”), Inferables maps implementation classes to be found in the same namespace as their requested base definition. With such, it creates an implementation for

module.Get<ISnarkyService>()

that looks like this:

return new SnarkyService(new LoggerStuff.TraceLogger(), new LoggerStuff.DebugLogger());

Lets break down the steps of this wondrous magic:

  1. Inferables looks under the namespace SnarkyServiceLib to find an implementation for ISnarkyService- finding SnarkyService
  2. Next, it finds an appropriate constructor: public SnarkyService(ILogger traceLogger, ILogger debugLogger)
  3. Finally, it finds appropriate injectable matches to ILogger under its relative namespace LoggerStuff and based on the chosen names of the constructor parameters: TraceLogger and DebugLogger

How to override default injection patterns:

Lets say you want to inject something else besides the standard resolution pattern for testing, This can be done by adding another resolution pattern. For instance, lets you want to resolve a dependency to replace the DebugLogger. Simply put it under a new namespace resolution path:

namespace LoggerStuff.Mocks
{
    public class MockDebugLogger: ILogger
    {
        public void Write(string message)
        {
             Console.Writeline("Not really logging, just a mock :(");
        }  
    }
}

And change your code:

var module = ModuleManager.CreateModule("~.Mocks,~");
var snarkyService = module.Get<ISnarkyService>();

var message = snarkyService.GetSnarkyMessage();

With these changes, Inferables now acts like this:

  1. First, look for implementation types with locations starting with target type namespace with an additional .Mocks suffix.
  2. If it can’t find it there, then look for implementation types that are found in the same namespace as the target type.

With these resolution changes, Inferables creates an implementation for

module.Get<ISnarkyService>()

that looks like this:

return new SnarkyService(new LoggerStuff.TraceLogger(), new LoggerStuff.Mocks.MockDebugLogger());

What’s Next:

Right now, I am finishing features and testing for a .9 release, and would like your feedback. Try it out for yourself: https://github.com/nmuhonen/Inferables-for-CLR and happy coding :)


I’m Changing Directions…

Hello all devitalics fans. I just wanted to let you know that I am shifting directions with content theme I will be posting about in the future. This is mainly because of personal revised interest into the enterprise line-of-business development market.

Here’s what you can expect out of the upcoming tomes from this internet blog:

  • Windows.Next  Enterprise development:  This topic has been kind of a bread and butter concept for my consulting business at Useable Concepts. With the announcements at the microsofts recent //Build/ Conference for both client and server technologies, there is a lot of new exciting technology just itching to be talked about. Expect some upcoming posts with some major nerditude built in.
  • Google Cloud Enterprise development: Google’s turn key based enterprise solution with Google Apps is continuing to gain traction in the small to medium business space, as well as few guinea pig large enterprise subscribers. What interests me in this emerging market is custom line-of-business development with App Engine. I hope to interest you as well with my upcoming posts on the subject.
  • IOS Enterprise Client Development: IOS and Objective-C. Yes, it is now impossible for me to deny the enterprise potential of this platform with projections of overall IPad sales reaching close to ~40 million by the end of 2011, maybe 100 million by the end of 2012. Watch in real time as I walk developers through the process of creating IOS client software for their enterprise.

Stay turned. A lot of cool content coming up for those enterprise line-of-business nerds out there like me.


Prototype Storyboard Concept: CiteMob!

As I promised in my previous post, I am revealing the first protyping concept to be explored on devitalics.com. I’m calling it CiteMob: an website for collaboration and massive content creation. The idea follows the belief that all people should be encouraged to deliver personally authored rich content to the web, adding more dimension than microblogging and social networking have to author, and connecting people more cerebrally. CiteMob is kind of a mash up of Twitter, WordPress, and Facebook, allowing a contributor to add content and recieve encouragement from her/his peers. With a novel built in citing and ratings system used during the creation of content, a user cites as they create. In this universe, reading, citing, and mixing into original content are the name of the game.

The audience intended consists of variety of people. First I hope to attract people with a lot to say, but too maybe a bit too shy to say it and start up a blog. Citemob acts as “rich content social network” allowing more complex ideas to make into the web from sources that didn’t believe themselves important enough and feel limited by microblogging sites like Twitter. Along with nascent “CiteMobbers”, this authoring tool also can create a weighted latice-work for experienced bloggers and content contributors, giving their readers and admiring fans referrals to brand new “Cites” they’ve “Mobbed” about.

This first draft UX consists of a simple “login, read, cite, create” workflow, with the read having a “cart” to collect citations in a custom Cite article to be created later by the reader. During the citing and collecting process, the reader would have a ratings system for the citings, allowing the reader to give a thumbs up or down to the article. This will inevitably create a massive directed acyclic graph of related cite information, allowing for some potentially wicked spacial navigation of prospective “CiteMobbers” content. (Maybe we’ll include games like asteroids! Eh, maybe not – at least for the time being :) )

Here are the splatterings of CiteMob’s first concept draft, courtesy of yours truly, awful handwriting and all:


Marvel at the wond’rous drawing!

This chicken scratch is kind of a free association technique I use often, a great process to see different angles of a concept that aren’t always clear in the initial vision. To distill this into a web app targeting standard PC Browsers, my next CiteMob Storyboard post delves into design and flow of the actual UX screens, in a way that is (hopefully) clearer to the reader than this initial concept drawing. Stay tuned…


The Path to Prototype.

Wouldn’t it be cool to watch a plan from conception to prototype emerge into existence in the blogoshpere? Wouldn’t you like to see someone get naked to world with their creative and technical innards all out and danglin? I sure do, and that’s coming up next on devitalics.

Like any process that is free wheeling, fun, creative, spontaneous, and groundbreaking (hopefully), some planning is required (What?). Really it is. I have found all my zany endeavors, no matter how inspirational they may be, need some sort of track to development in  order to to be truly appreciated. Software prototyping is no different, and with that, I have laid out 4 stages from inspiration and perspiration to creation. Here is a breakdown of the those steps to be witnessed on this blog, each to be appropriately categorized for the public’s pleasure:

  1. Storyboard: Probably the most important part of the process, conceiving and refining the actual idea to be fleshed out as a prototype. This is crucial to drive the requirements for the prototype. This step will be done with mainly with pencil and paper for a more organic feel (sorry trees! Hello scanner!).
  2. Comp:  Flesh out the storyboard UI into real assets using some design tools. Then take the comps and apply them to a mock UI- ie, for web apps, a few static html pages, for mobile apps, a few screens. Expect to see a lot of Illustrator, Photoshop, and Dreamweaver work here. 
  3. Architect: With features and comps in place. Design the technology of the app, starting with the database and moving towards the ui. Keep hosting decisions, if any, simple, this is a prototype ya know.
  4. Implement: Implement the prototype, feature by feature, to eventually reveal the prototype to the world!. Expect many posts on this one :).

For the technical people in the audience, no coding should occur at the Storyboard or Comp stage of the process. The reason: to keep the objective clear to design an experience, not a piece of technology like some cool new server side web framework, or jquery plug-in, or… well, you get the idea. I’ve seen to many of my projects go to the toilet by losing site of the UX and getting lost in some nerd-gasm that inevitably proves itself pointless. I hope to keep my prototypes clean and avoid those here on devitalics.

There it is, the groundwork for the devitalics prototyping process and an incubator for some interesting discussion. Next up: my first Storyboard post.


Follow

Get every new post delivered to your Inbox.

Join 73 other followers