Wednesday, July 1, 2015

Windows 10 Insider Preview Build 10158 for PCs is anounced

I've been on build 10130 for a while already and I was wondering when the new build was coming. Turns out: it's already there since yesterday. 

Mine has been downloaded :)

Thursday, June 25, 2015

Poor man's interceptors: passthrough proxies

So let's say this is my greate setup:

And I want to log calls to the service without putting ugly logging lines inside the service or the calling object. How do I do this?

Well, you could go all the way with Ninject Interceptors - the way I normally do it:

Code here. Get both Nuget.Exensions.Interceptors and either the Castle or LinFu proxy package ( don't forget those ! ).

OK - that's nice - that's elegant. But I realised that there's also a more lightweight alternative to this - writing a passthroughproxy:

So now I have two implementations of IMyService: the PassThroughProxy and the MyService. The passthrough passes the call through to the injected IMyService but allows for that call to be overridden. That's what I've done in the LogAspect.
The LogAspect overrides the call - logs the call and calls its base method to propagate the call down to MyService.

Hooking this up goes as follows:

The reason I build something like this, is because I was trying to listen in on events. You can do the same thing for events, where you build a pass through proxy that propagates the events, but also logs. And I couldn't listen in on these with interceptors.

Code here

Wednesday, June 24, 2015

Mommy's code can't hold its own pants up

In order to disappoint the reader already before reading this post, this is nothing new. Martin Fowler wrote about this a long time ago in his blog post on the Anemic Domain Model.

This code is about the frustration I sometimes have coming across code that's written in a way that you need to understand the internals first, before you can use it. In other words: the API is not very safe. Let me try to explain.

So - we're going on a family trip - we get everyone in the car and let's go:

But what happens:

Really ?! So apparently we had to set something on MommysBoy - but that wasn't clear at all. Aren't constructor arguments for this?
So how do we solve this ? Let's NOT educate the kid, that will make things more convenient ( NOT ):

He's learnt nothing thusfar. (NOTE: I see this a lot) What I've also seen is writing a service to validate the son. Brilliant - let's get mom in there too, because her son can't go anywhere without her:

*Sigh*... But as a disclaimer - I probably did this too ( and maybe still do ).

There's such a thing as object oriented programming where you just write procedural code and then throw it into classes and methods just to stay DRY, but there's this other world of elegant object-oriented modelling of problems.

So how would I suggest to improve this? Make you're objects just smart enough to take care of themselves, but as dumb as possible. Like in real life :). And think about this: do you allow your object to be in an invalid state ? ( All of this I learnt from ).

You want your son to always have toy? Put it in the constructor. Or pass in a factory ( although he would probably get really spoiled ... ). He's got an age property that should not be negative? Make the setter private - make a SetAge method that checks for a correct value. 

There are so many smells of this type of coding: huge documentation explaining what to take into consideration when running, everything implements IValidateable, constant runtime errors when writing new things and so on.

Just make sure your kids can take care of themselves and save yourself and team a lot of agony!

NDepend 6 is out!

NDepend 6 is out and with a bit of luck, I'll get the opportunity to get a fresh license and see what's fresh in this release. 

If you don't know what I'm talking about: NDepend offers a wide range of features to let the user analyze a code base. It is often described as a Swiss Army Knife for .NET developers.

Can't wait to get my hands on this!

Tuesday, June 23, 2015

Booyah: Continuously Deploying our Azure services

Awesome! So I'm breaking up a monolithic application into cloud services which I'll host on the Azure platform. I had it up, running, and publishable from Visual Studio, with all the correct configs for the right environments.

Then I came across this blogpost: YES you should read it and see the awesomeness.

So now I'm continuously deploying my services on checkin to Azure - here's the proof:

Awesome. Do read the post - there are some little tips and tricks in there ( for instance, how to make sure the config transforms properly ). But if you have all the publish profiles set up correctly before, AND you're build server is up to date ( with build targets and things ), it'll be a breeze.

This is from the mentioned blog - this button gets you 90% of the way for you build configuration:

Monday, June 22, 2015

Wrapping IAsyncResult in Task<> using FromAsync

I'm working with a webservice for which a proxy has been generated with the APM pattern for asynchronous calls. I didn't know this acronym, it stands for Asynchronous Programming Model ( see this blog post ) and the one with Async/Await ( and thus with tasks ) is called TAP for Task-based Asynchronous Pattern.

Anyway - I just wanted to async/await these calls and as it turns out it's super easy. Here's the method signature before:

Wrap them using Task.Factory.FromAsync:

... and you're done. Super easy - unit tests verify that it works like a charm.

Credits to Justin Lovell who helped me get started and Stephen Cleary for another great blog post.

Friday, June 19, 2015

Dogfooding my own NuGet package :)

I've had a NuGet package out there for quite a while already, but never had the opportunity to use it 'professionaly'. Either because logging was already in place or someone had written their own EventLog tracelistener or something like that. But as of today I'm dogfooding my own NuGet package in our software !

I know - it's not exactly rocket science, but I am a fan of Common.Logging and I am a fan of NLog. And I hated the fact that I was always struggling with the adapter and the right configuration.