I’m very glad to announce that Machine.Fakes has found a new home. Simon Hohenadl and Christian Deger of Autoscout 24 have taken over as active maintainers.
The last nuget release was already done without any involvement from myself. I’m doing my best to help them getting up to speed with the internals, but I’ve high confidence that they won’t need much help to really grok it.
Thank you all for your support!
If you ask me about my personal highlights in 2011 (technology wise), I would probably name Machine.Fakes as one of those. Writing and using it has been such a tremendous amount of fun and was the source of getting to know lots of interesting people.
As technology is the battlefield of opinionated minds, not every feedback I received was pleasant (especially from the Belgian “what’s wrong with good old unit test” brigade), but overall I’m very pleased with the perception and the feedback for the framework.
As you may have noticed, I recently made a big technology switch. Since the start of the year I spend most of the time working with Ruby on Rails on OSX. Originally I thought Mono would give me a great opportunity to continue using Machine.Fakes, but as it turns out I currently just don’t have the time to do that. Maintaining a tool/framework without actually using it on a daily basis feels just wrong. In retrospective I think I must have anticipated something like this last year, when Alexander Gross and I moved Machine.Fakes into the Machine organization on Github.
The worst future for Machine.Fakes I can imagine, is that it becomes just another abandoned .NET open source framework, like all the dead ones on Codeplex. So this is my call for help:
If you’re using Machine.Fakes and are willing to take over as the active maintainer, please drop me a line. I will assist you as good as I can in order to make this happen!
512 days or 17 months or 1.5 years. That’s the time between todays post and my last one. Not as long as the Duke Nukem Forever development time, but it still strikes me how much time has gone by since I’ve written something down here.
Today is probably going to be a very personal post and for that matter also non-technical one.
In case you haven’t heard it yet, I’m going to give 2 talks at this years prio conference.
I’m very exited to be part of this years speaker line up (though the quality of the line up is a bit intimidating ;-)). Both talks will be on the 20th of October in Track 4
Looking forward to see you there …
I haven’t blogged in a while, mostly because time has become such a limited resource in the last weeks or to be honest actually months. Blogging, my current project, workshops, the F# Bookclub, preparation of the next conference appearances and of course xUnit.BDDExtensions all want a piece of that cake. Finding the right balance between those tasks is often not as easy as I would like it to be. More often as I like skipping blogging seems to be the easiest way to regain some time. I’m really sorry for that, but you know I try to do my best. On the other hand this is a new blog post, so things can’t be that bad, can’t they? Although I haven’t slept much the last 3 days, something inside me urges to write this post.
Yesterday’s F# bookclub meeting in Munich was awesome as usual. It’s very interesting to see our overall understanding of functional programming progressing. Slowly, but steady. Main topics we discussed on the last meeting were Currying and Tail Recursion. Finally “got that” (at least I think so ;-))
Two meetings ago we decided to do some coding on every meeting. The previous meeting we solved Kata FizzBuzz and on yesterday’s meeting we tried to dance with Roy Osheroves StringCalculator. We didn’t make it completely to the end, but I think we solved most of the Kata.
Last F# book club meeting in Munich was awesome (as usual). 2 weeks ago we decided to do a Code Kata on each subsequent meeting. This week was our first, with Kata FizzBuzz.
A lot of my free time currently goes into learning F#. While I had a great time playing around with the F# REPL FSI, I came to the conclusion that using FSI is not my preferred way of a) learning the F# language and b) to develop code. Writing unit tests simply for the purpose of learning and understanding of a language/component/system (aka "Learning tests") seems to be a better fit, at least for me. So, I sat down in order to see how I can use my beloved xUnit.net for this. As it turns out it’s not that difficult, but it’s got some hurdles.
This is just a quick update of an older post of mine. Since StructureMap’s convention API has changed quite a bit, here is the updated version of the code used in the post using the new APIs introduced in StructureMap 2.5.4.
Crap, time can go by so fast. On Monday a tweet by Ralf Westphal caught my attention and I felt the need to comment. It started as a series of Twitter replies, but to be honest Twitter isn’t suited or made for those kind of discussions. So I started to write this post in order to explain why I disagree with Ralf (or at least don’t get the intended message of his tweet). Yeah a short look into the calendar indicates that I’m a little late, but I thought better late than ditch the post and forget about it.
In his tweet he basically states (my translation from German to English) that
If a domain model consists only of POCOs it should be called data model
My first thought was a) does he mean anemic domain models and b) what has POCO to do with that? As I found out he didn’t mean anemic domain models. So let’s take a look at the POCO aspect.