One possible way to compose application using OWIN spec

When composing your server apps with OWIN there are many options. OWIN spec is very flexible and it doesn’t  force you into particular application architecture (this is a good thing). So, using standard OWIN middleware components to compose your application is pretty easy and straightforward.

I prefer to clearly (at the assembly level) separate middleware from the server and the application. That makes it easier to work with for a bigger team, and when potentially, application teams are not the same as server and/or middleware team. Organizing your application in this way could look something like this, starting with middleware components project:

and then application is configured and ran like this:

So, having this in place, application developers – potentially different team(s) then middleware team – would write:

which models application interface as resources, and exposes them via standard HTTP verbs…

If you prefer CQRS – you can have middleware dispatch to handlers and then write your applications something like this:

Bottom line, OWIN is awesome.

Function oveloading in JavaScript

I was trying to get different behavior from the function depending on its arguments, a feature found in various programming languages such as Ada, C++, C#, Delphi, D, and Java, that allows creating several methods with the same name which differ from each other in the type of the input and the output of the function” – but not in JavaScript. It has been argued that method overloading is not such a good idea (Bertrand Meyer: Overloading vs Object Technology), and in JavaScript using different function names seems to be a right way to go…

But, the interface for the user of this api in that case would look like this:

[gist /]

but I didn’t want that. I wanted this:

[gist /]

Turned out to be easy to add a wrapper on top of the explicitly named api:

[gist /]

Simple Continiuos Integration with FAKE and windows scheduler #fsharp

Below are the details about a very simple CI setup,  the one that simply checks GitHub for changes to ‘master’ and if

there were any, runs FAKE build script.

First FAKE script:

The only part that should be interesting (the rest is standard FAKE) is conditional dependency for ‘Default’ task.

It depends on returned value from a custom FAKE task that checks if there are changes on GitHub.

Here is the custom task:

That is all – “simple” is the keyword  🙂 – here is the screenshot of it running:


Till next time…