In my last post I described the fluent calculator kata which we came up with for our coding dojo. When we started implementing the kata we decided to modify the initial set of ”requirements” slightly in order to make it a bit more complex. Here is the changed requirement:
The calculator should never throw exceptions. When an overflow occurs the calculator should throw an InvalidOperationException with an inner ArithmeticException.
I’ll show you what design and tests we came up with.
We are currently preparing for the next coding dojo in our team. A team mate and I came up with a nice kata which we are going to try out today. We didn’t check if there is already such a kata available on the internet. So please take no offense if you already came up with a similar solution
- All input values should be int.
- The calculator should never throw exceptions.
- The api should guide through the fluent interface, i.e. after the calc method you are never again able to call the calc method.
- It is possible to get the result by implicitly casting it to int.
Every now and then people get confused when they try to use the NinjectObjectBuilder for NServiceBus. In this blog post I want to describe the purpose of the NinjectObjectBuilder for NServiceBus and highlight the difference between Ninject and Ninject together with NServiceBus.
In a typical Daily Scrum, every team answers the three questions about what was done, what is next and which impediments there are.
We moved away from this form of Daily Scrum because it is not very efficient and not focused on Sprint Backlog items. It’s not efficient because we do a lot of pair programming and several team members work on the same User Story at once. Therefore, some team members could only say “I did the same as already said”. This way of doing the Daily Scrum makes it hard to plan the next 24 hours as a team, too. Planning the next day is a team task and cannot be answered by a single team member for him- or herself.
So, what do we do then?
Target audience: Softwarearchitekten
Urs’ comment: Dieses kleine Büchlein beschreibt typische Verhaltensmuster von Softwarearchitekten – sowohl positive wie negative. Auf unterhaltsame Weise beschreiben diese Verhaltensmuster, was einen guten Softwarearchitekten ausmacht und vor was er sich in acht nehmen muss um es sich nicht mit dem Team, den Stakeholdern oder dem Projekt selbst zu verspielen.
Dani’ comment: Beim Durchlesen dieses Buches habe ich mich selber in der einen oder anderen Rolle wieder erkannt und musste schmunzeln. Sehr unterhaltsam aber auch lehrreich für die Selbstreflektion.
Target audience: Everyone interested in usability testing
Urs’ comment: The book is funny, short and informative. I didn’t read this book because I want to perform usability tests. We have usability experts in our company for this. But, I wanted to learn more about this topic and this book showed me a lot of important things to know about usability testing. For me the most interesting information in here is what to expect from usability testing and how to integrate it into an Agile way of working.
Target audience: Softwarearchitekten
Urs’ comment: Ich habe in letzer Zeit einige Bücher zu Softwarearchitektur gelesen, dieses hier ist aber mit Abstand das Beste. Es deckt einerseits ab, welche Aufgaben ein Architekt wahrzunehmen hat, andererseits beschreibt es das Vorgehen bei Erstellung, Dokumentation und Bewertung von Softwarearchitekturen. Auch technische Konzepte zur Persistenz, Kommunikation usw. kommen nicht zu kurz.
Dieses Buch gibt einen Überblick über viele architekturrelevante Themen. Und obwohl es nicht all zu dick ist (und das bevorzuge ich ja bekanntlich bei Büchern), steckt sehr viel Information drin.
Für mich eine Muss-Lektüre für Softwarearchitekten.
We all know that people have been struggling to adapt the modularity and composition root approach Ninject and particularly the people around Ninject have been promoting over the years. After several years of stackoverflow frustration and people constantly demanding new feature for Ninject, we sat down and decided to listen carefully to the people’s needs. After endless meetings with no real agenda we finally came to the ultimate conclusion:
Ninject’s way addressing modern application composition is completely flawed. People don’t want modularity or composition roots. They always have been using Service Locator style dependency resolving and don’t want to learn new techniques. So here is the big announcement:
We will no longer support modularity and composition root; thereby completely deprecating all existing APIs and extensions for Ninject in the next major version.
The new interface we came up after a long design session will look like the following:
Ninject.Kernel.Instance.Locator.Resolve<TService>(params object constructorArguments);
Under the hood it will use ultra rocket science expression tree dynamic lambda compile algorithm. The algorithm is kept under copyright and will not be part of the usual Apache and MS Public licensed public code but instead be hosted on a private github repository. But what I can say here is that the output of the dynamically generated code will look like the following:
return Activator.CreateInstance(typeof(TService), constructorArguments);
We strongly advice against trying this code at home! It can lead to serious out of memory damage!
But wait there is more! We even sat down with Anders Hejlsberg and the next major C# upgrade will use Ninject under the cover. It will be possible to do DI with the new keyword. Your dreams will come true! You’ll then be able to write code like this:
new IFoo(new IBar(42));
This will then automagically (using the new compiler services) be transformed into:
This feature is so powerfull that there will never again be a new Ninject release. All will be baked in the new keyword. Happy service locating!
The first time when I tried out Office 365 it was a total fail. I was told from guys from Microsoft that there have been some issues which should be fixed by now. So today I did another try out with Office 365 because I think the idea behind it is simply amazing. For a pretty fair price you get a full Office Suite in the cloud plus the ability to install it locally on up to 5 Machines with the home license. This would suffice to never worry again about Office licensing for home usage and my home computers would always run the latest and greatest. So here is how my second visit to Office 365 turned out.
Today, I saw some ads about Office 365. Office 365 is a complete Office Suite based on the Office 2013 version, which is hosted in the cloud. The idea is brilliant. You pay a small annual fee and get SkyDrive space and most of the office tools included. More information can be found here . I wanted to subscribe for the trial period of one month to test the Home Edition for my personal use. My motivation was that you get up to 5 workstations at home included in the annual fee and of course all upgrades during the subscription period for free. So I signed up with my Windows Live ID.