on Thursday, 8 January 2015

With a new year, comes a new release of NMoneys.


The amendment 159 from ISO has been applied. Amongst the changes are:

  • LTL has been deprecated in favor of EUR
  • Changes to CVE information


Issue #28 has been fixed and now, one has full control over what Money.Parse() does. It is still a pretty weak method (and that is hardly fixable, but ideas and contributions are welcome) and its usage is still not recommended.


Use your favorite package manager (or Nuget Smile with tongue out) to reference it:

If you get your kicks from downloading random zip files and manually referencing assemblies, follow the badge:

Dynamic Documents

on Saturday, 22 November 2014
More things coming out from my recent session about MongoDB.

Documents and Types

MongoDB is a document database. Such documents are stored as JSON (well, kind of). JSON has a very challenged simple type system.
.NET is an object-oriented environment that promotes types. Such type system is pretty rich.
Are MongoDB’s documents and .NET Framework types doomed to miscommunicate? They would be if not for the existence of the serialization bridge the driver provides.

Types Everywhere

Since .NET is type-happy, majority of the times we are working in our happy strongly-typed world.
Believe it or not, there developers out there that are very happy (and productive) in a less strongly-typed world.
I will measure my words carefully, trying to prevent them understood as heresy:
There are certain types of applications (or parts of all applications) where strong typing bring little benefits.
Wow. There I said it.
Imagine this scenario: data is carefully crafted and validated and taken care of at the time of writing it to persistence storage and whenever needs to be presented to the user, there is little (if any) manipulation of it, because those details were taken care of beforehand, at a time when computing cost is not so important as write operations tend to be fewer than read operations. For what is worth, we could be storing textual representations of the data and no one would care if that was the case.
In those scenarios we do not need types. The structured data only travels through the wire to be presented on a screen.

Type-wannabe: the Document

The serialization part of the MongoDB driver for C# offers a straightforward type to solve the problem: BsonDocument. It is a nicely designed and useful type that allows reading information from MongoDB without much fuss about the underlying type.
The “downside”? C# is not helping to have a clean syntax.
Let’s take this simple document:

And how to access when I started snowboarding:

From 33 to 42 characters. It does not look like much, but it's a whooping 27% increase in typing.
I do not know about you, but I would gladly accept a 27% increase in my paycheck, thank you very much.

Lipstick on a Type

In .NET 4, dynamics were introduced as a way to marry two different worlds: strongly and loosely typed with a more palatable syntax. I suspect it was just a trick to prevent developers doing Interop from quitting in mass.
That sounds like almost useful and applicable to our small problem in hand.
Unfortunately, the driver still lives in a pre-.NET 4 era, so they cannot provide out-of-the-box support for dynamics. There are some attempts out there, but I was not happy with taking a dependency on another (arguably more capable) JSON parsing library (JSON.Net) to just do that.
Since it was for educational purposes you are allowed to simply waste some of your scarce free time in search for a solution that no one cares about Smile

Dynamic document

It turns out it is really easy to provide support for accessing instances of BsonDocument as dynamic object, taking benefit from the usual dot notation. Thanks to DynamicObject.
By simply wrapping an instance of BsonDocument inside an inheritor of DynamicObject and overriding .TryGetMember() to wrap nested documents we are able to happily use dot notation (with a slight overhead):

To use it, just invoke the .AsDynamic() over an instance of BsonDocument

With this minimal baggage, you are able to, for example, write razor views that display data coming from an instance of such DynamicBsonDocument.
As for getting dynamic objects into BsonDocument instances… Well, that is a whole different story. That I am not ready or willing to tell… for the moment Winking smile

Easier projections in MongoDB

I have already written about the talk I gave in the local user group about MongoDB.
I always try to push the limits of what I want to show by adding a couple of more advanced (yet useful) scenarios. The one I want to describe here is document projections using the .NET official driver.

What is a projection anyway?

The term refers to a result of a query that is a subset of the source of information.
In relational databases, it is a subset of the complete list of columns being queried.
For MongoDB, it is a subset of the fields returned for all matched documents.


Last week I was able to give a talk in the local .Net user group, AAnug.

The topic in question was MongoDB and, more specifically, how it can be used by .NET developers (using the official driver).

Code, code, code

It was a mostly code-oriented session but I did not want to type everything myself (horrible typist, worse in front of people if possible), but being helped by a series of code snippets that I could use from LINQPad (no need to fire off heavy Visual Studio instances for simple code snippets).


Crafting snippets was not the most fun task in the world (for the lack of a less offensive term) as I could not find a good tool that can edit .snippet files comfortably (leaving out Visual Studio plugins, it runs slow enough already). The one I used (Snippet Editor) does the job, but just that.


I used branches for each topic of the session, so changing to a brand new workspace for the next demo was a matter of checking out a branch. For topics that used LINQPad (majority), I created a /snippets subfolder and configured LINQPad to load custom snippets from it:


That way, I only had the snippets I needed for the current topic in Intellisense and I had way less to type, minimizing the amount of embarrassment.

The Result

I feel the session went pretty smooth and I could deliver all the important bits in time (I only overflowed for the “Bonus Tracks”) without rushing. So it is definitely a technique that I will use again for code-heavy topics.
My only fear is that by not having to type it and even though I tried to emphasize what’s important from the code, some people might have felt overwhelmed by everything that happened on the screen. But I did not get negative comments from it, so it might be only an unfounded fear of mine.

You can head to its Git repository to see the contents and even browse the slides in its GitHub Pages site.

BDD Mini Match-up

on Thursday, 18 September 2014

I cannot say I am a big BDD-er. I have used it for commercial projects, mostly to define complex scenarios for complex pieces of code (a custom discount engine comes to mind) but it comes with a price tag that I am not willing to pay for the majority of tests I write (unit tests).

I am not going to describe what BDD is, philosophy, syntaxes, flavors… I am just going to mention my experience with a couple of tools one can use if developing for the .NET Framework.

A little experiment

Quite long time ago I started SharpRomans as a learning experience with some interns here at my company. The idea was to create an implementation of roman numerals using some BDD techniques in order to get rich executing documentation.
The experiment was never completed until some time ago I decided to re-launch it, this time in Github.

The interesting thing of the experiment in regards of BDD was the tool I used: StoryQ.


I chose this veteran framework for a veteran project and I have been quite a happy user. In fact, I generated the whole Specification section of the project wiki by transforming the resulting XML report into Markdown (not too shabby for not having touched XSLT in years).

The way the tool was used in SharpRomans was simply using the library to write tests that are run by NUnit. An example of such test could be:

As one can see in the code, it is a quite pleasant fluent interface that leverages delegates in quite a clever manner to later infer the names of the steps and the arguments and their position via the usage of underscore placeholders.

The execution of such test produces several reports. A console output:

And a “pretty” HTML report (resulting from transforming an XML into HTML thanks to XLST):


It is easy to get the code syntax right, but if one prefers using the included “Text-To-Code converter”, it is a simple WPF application that allows converting a Cucumber like syntax into .NET code that uses their fluent interface. It is a great addition.

While look any further?

As I have said, I am pretty happy with the tool. What could have taken me to evaluate alternatives?
Well, besides the sheer desire to improve and do more with less, I have had my share of complaints for which I take some responsibility for not notifying the author or submitting a patch (although, in my defense, I tried, but was too complex for the time I allocated for it).

  • The code generated by the tool cannot be customized Sad smile
  • If one wants a different reports, one has to put with transforming XML, which is not my cup of tea.
  • Stability is a double-edge sword. People might look at the activity of the project and be put off by the fact that is has not shown any activity for years

The contender. BDDfy

If one can say only a good thing about the project is that they have raised the level of documentation for other OSS projects. It is pretty impressive.

Another thing that can be said is that it covers a lot more ground, in the sense that it is more ambitious in the styles and workflows that can support. To compare apples to other similar fruits I am going to stick to its FluentAPI.

And it generates (by default) a couple of nice reports. A console output:

And the mandatory “pretty” HTML report to show off our stakeholders what their money can buy:


The API feels quite the same, with fluent .Give(), .When(), .Then() but there are a couple of key differences:

story “context” is provided as a set of attribute properties

one can have (as with StoryQ) all-scenarios-in-one-test. When everything goes alright (all scenarios pass), everything is good; but, when one scenario breaks, all subsequent scenarios are not run (unlike StoryQ). To solve this issue (and that is my opinion about it) we can easily move to a test-per-scenario (which StoryQ can’t handle) at the cost of syntactic noise in the code

And if one looks at the console output, one can see that the story part is repeated for each of the scenarios, which I, personally, don’t fancy.


They are both quite nice frameworks and both can support my way of doing BDD. StoryQ is lean and BDDfy is more powerful and its flexibility can accommodate other workflows different than mine.

A couple of nice extras that BDDfy brings to the table are:

  • a nice looking metro report (that has to be configured without any sweat)


  • an even nicer markdown report.

That might have come very handy to generate the spec for SharpRomans, which I could have copied and pasted to the wiki. But then, I would not have written this puppy (and that might have been a good thing Smile with tongue out).

More Nmoneys.Serialization

on Thursday, 21 August 2014
The release for packages supporting third party serialization libraries of Money instances has already been announced.
Straighforward as their usage might be, or useful the inline comments might be, what was missing was more detailed documentation available on the project homepage. No more.

Lazy summer blogging

Why is telling that one is blogging while on holiday even important? Because it is different this time. It is the first time in some years that I do not have a laptop with me.
The documentation was indeed written online using an iPad Air Wifi with a bluetooth Microsoft Wedge keyboard, and so is this post (using Posts) and I have to say I am pretty pleased so far.
Writing on this smaller keyboard takes some time to get used to and my hands often reach out where the "normal" key would be, but it is night and day as what can be achieved with the on-screen keyboard.
Of course, being a keyboard thought for Windows (and not iOS) and given the lack of customization that Apple's OS offers there are a few oddities. Despite choosing the right keyboard layout (using Win + Space) there are some keys that are "missplaced"; most important are asterisk and curly braces. So one has to revert to clumsy copy and pasting or just play a little game of "find the right key combination". That is probably only a problem for programmers akin to the curly brace cult, as for emails and "normal" writters the Wedge is a wonderful complement with its ingenious stand/keyboard cover and overall portability and feeling of the keys.


on Wednesday, 6 August 2014

I have already touched the subject of NMoneys serialization in the context of a third party serialization library.
Even a custom converter was released as a Nuget package. But real world experience taught me it is not enough.

A new model

I have always been hesitant on the policy to adopt when depending on third party libraries in my packages: shall I fix it to a known version? Fix the upper limit to the next semantic version and hope for the best? Update the minimum version every now and then?
Quite a few questions and few definitive answers.

In this particular case (serialization using a Json.NET converter), I chose to break with the past and deliver the custom converters and everything else as source code and remove the dependency to the serialization framework from my package.
Is this the way to go? It definitely has its advantages, but time will tell.

New horizons

A side effect of the decision is allowing the user of the package to tweak the serialization process or remove the artifacts that won’t be used.
It also gives me the opportunity to supply the same code for Json.NET and RavenDB (that uses an internalized version of the former) just by switching namespaces during the build process.