In my previous post I detailed what open source projects we have contributed code to, but this post will highlight what projects we have made publicly available.
We host all our open source projects from GitHub, feel free to browse our repositories. I would like to highlight just one project in this post, the AzureWorkers.
AzureWorkers is a project we started back in August to create a framework for running multiple worker threads within one single Azure Worker Role. It allows us to quickly spin up more workers to do different things. I have already posted on how to use this project, so I won’t repeat myself, but instead talk about why we chose to open source it and not keep it closed off.
Looking at Githubs President Tom Preston-Werner‘s blog post about this same issue he basically makes the points for me! So, thank you Tom! I would like to highlight two things though:
- We do not open source business critical parts
- Open sourcing parts of our stack makes it possible and legal for us to use code written at work for hobby/home projects
Business critical parts
For us all code related to risk management is any way is business critical, it is the essence of UXRisk and what Proactima can bring to the software world. This needs to be protected and so we do not open source it. So far it has been very easy in determining if something is business critical or not, presumably it will get harder as we develop more code in the gray areas between technology and risk knowledge.
Use in hobby/home projects
In most employment contracts it is specified that all work carried out during office hours when employed belongs to your employer, which is only to be expected! But if you open source that work then you are free to use the code/result in other projects too! A colleague of mine, Anders Østhus, is using our AzureWorkers in his latest project (to be published I hope!). This would have been hard to do, legally, if we had not open source that project.
In summary I would like to thank my employer for allowing me to not only blog about my work, but also to share the fruits of our labor with the world. So thank you Proactima!
We have a requirement to instantiate a service facade based on a single parameter, this parameter will then be used to load configuration settings appropriately. A fellow team member reminded me that this looked like a factory requirement so I started to look at Ninject Factory. At first I didn’t quite get the examples, but decided to just try it out and see what would work. Turns out to be pretty simple! This post is mostly as a reminder to myself and perhaps a bit of guidance for others looking at doing the same.
There are three requirements for using Ninject Factory:
- Install the nuget package
- Create a factory interface
- Create a binding to the interface
Point number two looked like this for me:
The IServiceFacade interface and concrete implementation looks like this:
Tying it all together is the Ninject Module:
Line number 5 will make Ninject create a proxy that calls the constructor on ServiceFacade, with the prefix input and the IService implementation (bound on line 7). To make use of the factory I did this:
Here I inject the factory interface and call the create method (line 23). The magic happens inside that create method, since this is a proxy generated for me by Ninject! The really cool thing is that all regular bindings still apply, so if you look at the constructor for ServiceFacade it takes the prefix string and an interface (IService) that I bind in my module. Stepping into (F11) the create method in debug mode I end up in the constructor for ServiceFacade, perhaps as expected, but very cool!
Also worth mentioning; you could have more inputs to the create method and only the names matter, ordering does not. So if I needed both prefix and postfix I would have them in any order between the factory interface and the constructor, as long as names match it’s OK. And finally you are not restricted to one method on the factory interface, so I could have had a CreateWithPrefix and a CreateWithPostfix method etc.
The complete source for this is not available, as it’s part of a much bigger project known as UXRisk and it is not open source.
Proactima values knowledge and part of that is sharing the knowledge. One way of sharing, in software development, is to contribute to open source projects. So in UXRisk we have contributed to open source projects that we use:
We have contributed minor fixes to package versions and the ability to inject on Azure Worker Roles. So just small changes that we needed in our work, but very rewarding to be able to fix it ourselves.
Semantic Logging Application Block
We are using ElasticSearch (ES) for our logging needs and there was no built in sink to store logs in ES, so we created our own implementation. We basically reused the code from Azure Table Storage and adapted it to our needs. In cooperation with another member of the Semantic Logging Application Block (SLAB) codeplex site our code was accepted into the master branch of SLAB.