https://danielwertheim.se/Ghost 0.11Thu, 01 Nov 2018 12:04:02 GMT60I was in the need of hosting an on premise NuGet server. I didn't want it hosted in IIS but self-hosted. Previously I've had good experience with ProGet so my first take was to try their free version. I had a minor issue with Windows Defender complaining during the install.]]>https://danielwertheim.se/just-put-together-lightnugetserver/88560132-c189-495e-9eef-7694b2775d62Sat, 18 Nov 2017 21:14:04 GMTI was in the need of hosting an on premise NuGet server. I didn't want it hosted in IIS but self-hosted. Previously I've had good experience with ProGet so my first take was to try their free version. I had a minor issue with Windows Defender complaining during the install. Apparently that is a known issue with some AV tools: "Anti-malware False Positives, Code Signing, and Safety of Inedo Products". ProGet would definitely have worked. But I didn't need all features. So I continued and looked at the options on this list and my second option was to look at putting together something using the NuGet.Server. It's well documented: here and at Scott Hanselman's blog. How-ever, I did miss two things:

I wanted it self-hosted in a service and I wanted support for multiple feeds with different API-keys

And voilà, the result became: LightNuGetServer. It will solve my needs and it will be adequate for my current use-case. If not, I can always switch later. It uses Topshelf and NuGet.Server and you configure it in a JSON-file. You could e.g. put up two feeds, with configuration like this:

]]>It's not the first time the Uri gives me pain. This time I got a bug reported on one of my libraries where parts of the provided URL got replaced. A URL is defined as a two string parts which are then used to construct a URI. Now, I'm most]]>https://danielwertheim.se/uri-wonders-or-not/ed709a4d-3ca9-4dd3-892e-96cce5ac20adFri, 17 Nov 2017 19:05:06 GMT

It's not the first time the Uri gives me pain. This time I got a bug reported on one of my libraries where parts of the provided URL got replaced. A URL is defined as a two string parts which are then used to construct a URI. Now, I'm most certainly misusing it, or have been putting to much hope to the smart people behind it. Look at the case below. The desired string is: http://mydomain.com:8081/cloud/test

Summary

]]>Ensure.That has been around for quite some time (2011-08-23). With the new release (v7.0.0) there are some changes, e.g. targeting .NET Standard 1.1 & 2.0 as well as .NET4.5.1 and a new contextual API. But it's also time to finally deprecate the]]>https://danielwertheim.se/ensure-that-updates/df53beae-1b7d-437c-94e1-3917d6844792Thu, 09 Nov 2017 21:23:12 GMTEnsure.That has been around for quite some time (2011-08-23). With the new release (v7.0.0) there are some changes, e.g. targeting .NET Standard 1.1 & 2.0 as well as .NET4.5.1 and a new contextual API. But it's also time to finally deprecate the old API lurking around in there, namely the Ensure.That flavor. So instead of:

Why am I removing it?

One reason is: "I don't use that flavor my self anymore and do not want to maintain three flavors.". The reason for me not using it is that the Ensure.That construct creates a new instance of Param<T> or Param every time you call it. Maybe this isn't that big of an deal for a few calls, but used in a loop where lots of values are being passed to a method that operates on these values after validating the input args... So, with this in mind, it's been marked as Obsolete generating a warning and will be removed in the next major version.

Another reason is, that the Ensure.That(..., ...) flavor allowed you to extend exception messages etc. Even throw completely other exceptions. This kind of goes against the intentions of being a simple and somewhat opinionated and just be about argument validation. The exception messages should be good enough. If not, feel free to issue a pull request. They are intended for devs/ops in logs etc. not for bubbling up to end users.

Feel free to disagree. And if you strongly disagree, feel free to fork, adapt and publish under a new name.

Cheers,

//Daniel

]]>A leader is supposed to do many things. One of all those things is "setting the tone". If you as a leader empower and favor a "bragging" and "bashing" behavior that is the behavior that will spread among your employees and will be part of your environment. There's a big]]>https://danielwertheim.se/leadership-setting-the-tone/e5625b7c-763c-4f7a-ae06-56423d00769bTue, 31 Oct 2017 10:32:00 GMTA leader is supposed to do many things. One of all those things is "setting the tone". If you as a leader empower and favor a "bragging" and "bashing" behavior that is the behavior that will spread among your employees and will be part of your environment. There's a big risk that people will reflect the people that you as a leader hold high.

I'm a firm believer of direct and open communication. And I do not hesitate in taking a discussion and to deliver my opinions. And I do not mind people doing the same. What I don't like is people continuously bragging and bashing. Creating a witch-hunt atmosphere. How do you think that will be looked upon from outsiders or newcomers to your team? The risk is high that you will scare new members of your team from expressing their opinions. Scared from becoming a target of your loudly expressed criticism.

Even the smallest things...

Even the smallest things are part of "setting the tone". One example of something that we all see and are annoyed about, but often fail completely at, is "The messy kitchen". It's really simple to fix. All you need is some "common sense". But why should you care?

If I as a customer were at your office for a business meeting and would see a messy kitchen, I would take that as signs of bad leadership in the office.

How would I as customer know that this behavior only affects the kitchen? How about the rest of the work? Are corners cut there as well?

You are more important...

As a leader you might believe that your work is more important than others and therefore you don't have to mind chores. Of course your work is important. Maybe even more important. But that is the work of being an awesome leader that ensures that the company delivers as it should in an effective manner with low friction. That clear goals and strategies exists. That your employees are provided with all the necessary tools needed to solve their work. But part of being a leader is also to have a good manner and to show respect and interest in others. I once had the pleasure of working for a manager who every day walked around and said good morning to all the employees and consultants. His door was always open and he listened and paid attention to YOU, not just your work. He took part in every day chores. We had a great atmosphere and if he would call me today and ask for help, I wouldn't hesitate for a second to help him.

//Daniel

]]>I'm currently building a simple solution that will have a few simple web APIs built using ASP.Net Core. The APIs are not going to be fully fledged REST APIs according to Richardson's maturity model. So there will not be any HATEOAS with resource linking etc. Each API will most]]>https://danielwertheim.se/asp-net-core-and-a-simple-discovery-endpoint/215efb13-1004-4090-8432-a4699320ec83Sun, 29 Oct 2017 18:56:59 GMTI'm currently building a simple solution that will have a few simple web APIs built using ASP.Net Core. The APIs are not going to be fully fledged REST APIs according to Richardson's maturity model. So there will not be any HATEOAS with resource linking etc. Each API will most likely have one or two endpoints. I want the root endpoint to provide some simple discovery info and not extensive Swagger enabled API docs but info like: deployed version, current time and available routes. This endpoint is used for simple discovery purposes and checking if a service is alive with e.g. simple smoke tests after deploy etc.

Please remember. This is very early sample code and just something for you to get inspired by.

Middle-ware

Even though this creates coupling between my services, in the form of shared infrastructure code, I've decided to expose this as a middle-ware hook:

app.MapWhen(ctx => ctx.Request.Path == "/", c => c.UseApiInfo());

The middle-ware is very simple. It will only support JSON as output. I could have used ObjectResult and used content-negotiation, but my design decision for these internal services has been to just use JSON for it.

]]>Recently I got the question if Structurizer could be used with anonymous types for flattening of object-graphs for logging. I've had the similar need, producing a key-value representation of some object graphs for the sake of logging and analytics. So lets have a look if we can build this with]]>https://danielwertheim.se/creating-a-simple-key-value-logger-for-an-object-graph/aa1e61f3-ba22-4caa-96ae-23d0dec5c39aSun, 04 Jun 2017 12:58:31 GMTRecently I got the question if Structurizer could be used with anonymous types for flattening of object-graphs for logging. I've had the similar need, producing a key-value representation of some object graphs for the sake of logging and analytics. So lets have a look if we can build this with a few lines of code using Structurizer.

StructureLogger

In Structurizer there's something called a FlexibleStructureBuilder which upon request, generates a cached schema representation of an object passed to it. Normal POCO classes or anonymous types. You can also configure and reconfigure it to control what to index in a certain type. But that is optional. Using this we can put together a StructureLogger.

That's all for this time. Now of course, ensure that your existing logging solution doesn't already support this. The post is more meant as an inspiration of what you can do with Structurizer.

Have fun,

//Daniel

]]>Recently I heard of the need of taking two typed objects and producing the delta of their properties. So lets look at a simple solution to an object compare that inspects the complete graph of two objects and produces a result of properties that doesn't match.

I have a simple

]]>https://danielwertheim.se/how-to-build-a-simple-object-graph-delta-comparer-in-csharp-using-structurizer/474d9e7a-50e0-4a6b-82b7-2f411d3f2c9fTue, 21 Mar 2017 21:03:15 GMTRecently I heard of the need of taking two typed objects and producing the delta of their properties. So lets look at a simple solution to an object compare that inspects the complete graph of two objects and produces a result of properties that doesn't match.

I have a simple project: "Structurizer" (GitHub and NuGet), that turns an object graph to structure indices, where each index contains: name, path, data type and the value for a leaf. The data is extracted using cached model meta and IL code is generated to access the properties in an efficient manner. All this provides a good foundation for building an object compare solution.

Remember. This is just a blog post, aiming at providing "inspiration". It's not an "all mighty feature complete solution".

A test

The test just shows some simple usage. The result of the compare exposes IStructureIndex data directly. Maybe you don't want to expose external library models, in that case you could map to something under your control.

Now to the final piece, and also where you would invest some time. I did a simple Zip between the different properties. Using the fact that I know that they are produced in the same order. But maybe you want to look at Index.Path and their associated values?

]]>We have all seen them. The strings lying around here and there in the code base. Some times at least exposed as constants in the class. But what else can you do? Well, you can have things like dedicated constant classes or key masters or value-objects or just allow the]]>https://danielwertheim.se/some-ways-to-tame-magical-strings-in-net-and-c/e6a60276-c9da-4e77-bcd5-44886d228fc8Tue, 07 Mar 2017 10:44:35 GMTWe have all seen them. The strings lying around here and there in the code base. Some times at least exposed as constants in the class. But what else can you do? Well, you can have things like dedicated constant classes or key masters or value-objects or just allow the user to easily pick a value using a simple Func<,>.

Before looking at the three "solutions" this blog post provides, we need to set a scene. Lets have some thing with a member that accepts a "country" being passed to it:

Glad you asked. That is the issue with this. You as a consumer of the Register method gets very little help of what you can pass. Perhaps there is some documentation stating what values can be passed or what ISO-standard for country codes it support. If not, we are left with something that could be used in various ways:

The old friend "CountryConsts"

To be clear. I don't like this one. I just don't. For the sake of discovery, a class with constants helps very little. Sure there's a class that is named in a way that you know is about countries, but other than that, there isn't that much of an improvement.

Introducing the above would not help in discovery but it would at least improve the code base seen to refactoring, organization etc.

The Value-object "Country"

Introducing a Country value-object gives us both assistant when it comes to discovery and also refactoring friendly and organised code. Further more, the Country class can be extended to e.g. implement implicit or explicit operator overloading for converting between a string coming from e.g. a database or similar. Sounds terrific, right? Do we have a winner perhaps?

It sure helps with discovery, but you can also return any string you want. This could be prevented by e.g. using a combination of the Country value-object and the Func, allowing you to pick a Country from a list instead of a string.

//Daniel

]]>Today, I was looking around in the source code of a project on GitHub and noticed some reflection used to extract methods. The methods in turn were used to apply state to instances during aggregations and projectins. I found out that the access path to the code only were once]]>https://danielwertheim.se/generic-method-cache-vs-reflection/f0dac66a-0eb7-45d1-83b8-f1f324bc2aa0Mon, 06 Mar 2017 14:56:34 GMTToday, I was looking around in the source code of a project on GitHub and noticed some reflection used to extract methods. The methods in turn were used to apply state to instances during aggregations and projectins. I found out that the access path to the code only were once per aggregate/projection type and that the reflected methods in turn were used within compiled lambdas so in this case the method extraction was OK. Introducing caching would obviously not make it go faster, on the contrary, slower. But what if you are in another case? A case where you are writing similar code and where you are extracting a generic type's members more than once via reflection? Is there a simple way to cache this? Yes, you can use a generic method cache. But how much would you gain from doing so? Lets benchmark.

Summary

To get real performance gain, you should not use the reflected members directly. You should instead turn the reflected members into compiled lambda statements or generate IL code for accessing the members instead. And of course cache these so that you don't compile or generate them each time. I've done previous measurements of compiled lambdas and IL generation for accessing properties. Go read to find the differences it make.

Result

The relative performance gain is high, but do note that we are down counting nano seconds.

]]>Using ConfigureAwait(false) is said to be a recommendation for e.g. third party library authors. Why? Well, lets say you are building a ASP.Net API hosted via IIS and consume a library that offers an async API for e.g. I/O bound work. When using it you]]>https://danielwertheim.se/do-i-need-to-use-configureawait-false-all-the-way/1de76739-410c-4c9e-a5ea-30086d618527Fri, 03 Mar 2017 18:03:51 GMTUsing ConfigureAwait(false) is said to be a recommendation for e.g. third party library authors. Why? Well, lets say you are building a ASP.Net API hosted via IIS and consume a library that offers an async API for e.g. I/O bound work. When using it you "manage" to introduce a blocking call via e.g. Task.Result higher up the call stack and suddenly you start experiencing dead-locks. This happens when the async task is completed and the captured context (where the task was created within) is being "restored" on a different thread (more info). By using ConfigureAwait(false) you explicitly state "do not capture any context" and thereby you avoid the problem. Right. But do you have to do it all the way? Lets see.

Before looking at the sample lets clear something out. When consuming asynchronous code, you should of course strive to be asynchronous all the way and don't introduce any blocking calls. If you need to, you can push it up as far as possible and wrap the code within, a by you started Task, e.g. via Task.Run.

Remote Web API

There's an API hosted at http://localhost:53573/customers/{id} that represents an API "out of our control". All it does is to return some fake Customer info e.g.

{
"Id": "759",
"Name": "Customer 759",
"Score": 1968
}

Library

The Remote API is accessed via a service in a library (NuGet or whatever) that doesn't make use ofConfigureAwait(false):

Success! No dead-lock issues now that we have ensured ConfigureAwait(false) usage in all "levels".

Summary

As the sample showed, we do get different behaviour when using ConfigureAwait(false) in all levels. Again. The best would be to always be asynchronous all the way, in other words: do not introduce any blocking calls.

Please do note that the behaviour will vary depending on where it's called from. An application running in a console application will not be affected by this as one running in ASP.Net hosted in IIS.

Feel free to provide corrections, thoughts, feedback etc.

Cheers,

//Daniel

]]>This week I held a talk at Swetugg, a two day Swedish conference for .NET developers. My title was: "NATS, what a beautiful message protocol!". In order to show a good use-case of NATS I put together a small demo where I read my heart rate in real time using]]>https://danielwertheim.se/visualising-my-heart-rate-on-stage-using-a-hue-lamp-and-a-heart-rate-sensor-and-net/36af1377-503c-4dea-883b-9553094c3c1fThu, 02 Feb 2017 19:36:00 GMTThis week I held a talk at Swetugg, a two day Swedish conference for .NET developers. My title was: "NATS, what a beautiful message protocol!". In order to show a good use-case of NATS I put together a small demo where I read my heart rate in real time using a sensor and ANT+ SDK, which was published via NATS. I then had two different services (apps) running. Both subscribed to the NATS subject to which the heart rate readings were published. One service wrote the data to InfluxDB so that it could be visualised in Grafana. In another subscriber I took the data and matched it to a certain colour and then used the HTTP-API of the Philips Hue bridge to make a Philips Hue Go indicate if I was "calm" or "stressed".

I got comments about it both during and after the talk:

Oh! Now it changed!

or...

When you stood behind the computer you where more calm. Then it turned green. At one point even blue.

ANT+ SDK

Due to licence restrictions and agreements, I'm not allowed to show all bits and pieces here. But if you head over to: https://www.thisisant.com/developer/ you will be able to signup and become an adopter and thereby gain access to SDKs and sensor/device profiles and keys.

That is what I did to be able to use a small Garmin USB receiver to access my Garmin heart rate sensor. The high level code looked like this:

This demo worked well for me. And shows a very good use-case for NATS. Pumping frequent, small sized sensor data, where transactional guarantees is not needed and "at most once" delivery is OK.

That's it. Hope it can inspire you to build something as well.

Cheers,

//Daniel

]]>I'm currently in the process of building a solution for controlling parts of my home, based on my current mood. The first source of sensor data is my own heart rate. I'm using it as input for controlling lights. Like changing colors etc. For dispatching the received heart rate to]]>https://danielwertheim.se/sampling-messages-from-nats-using-my-c-client-for-nats/3b5f9f9e-a124-429c-9a56-042b8eece725Sun, 22 Jan 2017 14:10:11 GMTI'm currently in the process of building a solution for controlling parts of my home, based on my current mood. The first source of sensor data is my own heart rate. I'm using it as input for controlling lights. Like changing colors etc. For dispatching the received heart rate to a light controller as well as a health indexer, I'm using NATS. The heart rate sensor gives me several readings each second and for the indexer I'm writing it down to a time series optimized database, InfluxDB. The data in turn is visualized in Grafana. The lamps are controlled by a separate application/service that also listens to the heart rates being published over NATS. The client I've built for NATS is based around IObservable<T>, hence it is RX friendly and we can therefore make use of Observable.Sample. This becomes really useful when controlling the lamps, as I don't want to react on each individual reading for setting new colors etc. I can instead make use of sampling and be picking one value over the period of lets say five seconds.

]]>Five releases so far in January. Some bugs, some changes and then of course new features. Also managed to both remove support for .NET4.5+ and bring it back again. Sorry for that. The last release just added a new NuGet package MyNatsClient.Encodings.Json which introduces JsonEncoding and some]]>https://danielwertheim.se/jsonencoding-and-bugfixes-in-my-nats-client/f1a4c3f6-db8d-4a9a-b7a3-b6a6bf08baa3Tue, 10 Jan 2017 21:48:56 GMTFive releases so far in January. Some bugs, some changes and then of course new features. Also managed to both remove support for .NET4.5+ and bring it back again. Sorry for that. The last release just added a new NuGet package MyNatsClient.Encodings.Json which introduces JsonEncoding and some helper extension messages for publishing entities as JSON as well as reconstructing them in your handlers. Lets have a quick look.

That's it. More encoders are to come. Will probably add the possibility to injected encoding/encoder or to register them and then have it be looked up by convetion. Not sure yet. Feel free to suggest what more there should be in this area.

Cheers,

//Daniel

]]>The Client that I'm currently building for NATS Server is based around IObservable<T> and when you hook up a subscription against the stream of MsgOp you have the possibility of injecting an IObserver<T> which allows you to inject a handler: Action<Exception>]]>https://danielwertheim.se/mynatsclient-and-exceptions/c7c72201-ad3d-4ed3-9cd2-3f35390e61f7Thu, 05 Jan 2017 10:30:10 GMTThe Client that I'm currently building for NATS Server is based around IObservable<T> and when you hook up a subscription against the stream of MsgOp you have the possibility of injecting an IObserver<T> which allows you to inject a handler: Action<Exception>; for OnError. This gives you the opportunity to register a handler for unhandled exceptions. Lets look at some samples.

Catch exceptions using an Observer

Subscribing with the use of an observer makes it easy for you to catch exceptions and handle them.

There are some more improvements coming to this area. Like generic exception handlers per client etc. This will be release v0.9.0 which will be out really soon.

Cheers,

//Daniel

]]>Just reached v0.7.0 of MyNatsClient and focus has been on simplifying the usage of it. This means that the client now keeps track of subscriptions and auto-subscribes when the client gets connected or re-connected. It now also allows you to setup a subscription both against the NATS server]]>https://danielwertheim.se/new-release-of-my-nats-client-focusing-on-simplifying-usage/0388a5b8-ef98-4f59-9291-7919752852bbFri, 23 Dec 2016 21:38:00 GMTJust reached v0.7.0 of MyNatsClient and focus has been on simplifying the usage of it. This means that the client now keeps track of subscriptions and auto-subscribes when the client gets connected or re-connected. It now also allows you to setup a subscription both against the NATS server and the internal observable stream of messages in one call. And the final bigger change is that it now supports simplifying methods for performing requests. Lets have a look at some short code samples.

Simplest pub-sub example

Before this release, you had to subscribe both to the in-process client.MsgOpStream as well as sending a sub command to the NATS server via client.Sub(...) or client.SubAsync(...). You still can. But you don't have to anymore. You can now do that in one call instead:

Subscribing & Unsubscribing

The Client will keep track of subscriptions. And you can set them up before connecting. Once it gets connected, it will register the subscriptions against the NATS server. If you make use of ConnectionInfo.AutoReconnectOnFailure it will also re-subscribe in the event of exceptions.

When subscribing to a subject using the client, you will be returned an ISubscription. The methods for subscribing are: