Since I started using and working on Ninject I have never seen a good use case for Activations Blocks like they are implemented at the moment. That’s why I’m currently planning on changing their behavior to give them more sense. This blog post will explain what I have in mind at the moment.
For a project we use some SunRay 3 Plus terminal with the Sun Oracle VDI server. After all I only can say this thin client solution rock!!! But in the project time we hade to debug a problem. The problem was some Sun Ray Clients did unexpected reboots every 2 till 5 minutes. And it comes even stranger, next day the Terminal works without any problem and another terminal reboots. After some vi action we found the following error in the Log of the vdi server.
These are the slides with comments of my conference talk at MedConf 2012 in Lucerne: Software development without using open source software (OSS) is unthinkable in today’s world. This holds also for medical technical projects. This presentation is split into three parts. First we take a look at some myths and facts about open source software. Then at how to integrate an OSS into your project so it can be validated against regulatory requirements. And finally, we’ll see what is important when...
In my last post I described the problem domain behind client / server localization. In this post I’m going to tackle how dynamic translation can be achieved in a client / server environment. The basic idea is to use compiled resources from the server side and transport it over the wire to the client. When talking about “resources” we want to use a mechanism which is really close to the way localization generally works under .NET. To understand this we need to have a look into...
Imagine you need to code the following requirements:
When an exception is thrown the transaction must be rolled back
The thrown exception must be rethrown
The productive code could look like:
Now how would you write the requirements above in two separate unit tests? Here comes FluentAssertions into the play.
If you are familiar with hamcrest and JUnit the time will come when you have the need to create your own matchers. Creating your own matcher can be as simple as useful. One reason for creating your own matcher could be that your object is not a default object like a String or a Collection. And if you would like to get a more readable version of the assert for the next developer who has to read your test. Let’s make an example. If you have an object with two methods; “getName”...
Currently, I have some spare time and wanted to play around with geeky stuff. The guys from sharpcrafters.com provided me a evaluation version of their tool PostSharp. PostSharp is a framework for aspect oriented programming in .NET. In short, aspect oriented programming helps you to remove unnecessary boiler plate code such as logging, transaction handling, exception handling and many more. The boiler plate code I’m talking about is also called cross-cutting concern because it cuts...
Unfortunately, ASP.NET providers like the MembershipProvider and RolesProvider aren’t designed for dependency injection. Many users have problems to assign dependencies to them. In this blog post I’ll show a way to how this can be done using Ninject.Web.Common 3.0.0. This solution works for MVC and WebForms.
Have you ever thought that JUnit assertions are not really readable and do not correspond to natural language? It is a mess that the expected value is the first argument on an assert? This would not be like the spoken language where you would say “assert that this value is equal to this expected one” ? Or have you had tests where the expected value and the value to test were inverted? In this case you have not found an old friend of JUnit called hamcrest.
Recently, I’ve given a short presentation about pair-programming and the stereotypes people show while pair-programming. As always when talking about pair-programming, there is a discussion how to sell it inside a team to peer developers or even worse to managers. Their killer argument is that two people in front of a single computer result in doubled effort needed to complete software.
Let my show you why this is wrong.