Lately I’ve been working on a library to consume Hydra Core hypermedia-rich APIs. This is something I’ve been planning for a long time now and given that the Argolis server-side component pretty much works it was about time I started working on consuming the API Documentation.

In this post I showcase the simplest usage of heracles and describe some design decisions. I guess I should write about Argolis too in the near future.

Given that I’m fairly satisfied with the state of my server-side Hydra library for NancyFx called Argolis it is now time to write some client-side library to consume it. I did some spiking in another small project and it was now time to do it properly. I’ve already had some experience with TypeScript and JSPM so I decided to give these two a go.

Unfortunately getting the project setup right was harder than I’d hoped. Here’s how I managed to get my first test to pass.

I know that some people will hate me for mixing the words testing database with gherkin all in one sentence, but I’ve found that it’s a quite nice combination. Gherkin’s table feature (SpecFlow in my case) allow for very nice test definitions, with NDbUnit it is quite simple to populate the database, and thanks to LocalDb the tests are beautifully portable.

I recently wrote about the Registrations class of NancyFx. It is a great tool for implementing reusable Nancy packages, which define all their DI requirements and does that with no dependency on any concrete DI container.

Unfortunately every rose has its thorns and there are some limitations and the exact behaviour slightly differs between containers. Read on to see what are the problems you can face when using the Registrations class for setting up your application.

Inspired by recent training sessions on DRUG Software Craftmanship and another on the following week on DDD Wro meetup I decided that it would be best for me to explore the wikibus.org domain by conducting a solitary event storming.

In a previous post I detailed my struggle with deploying a .NET (Nancy) application to Heroku. Longer story short, I failed. I guess it should be possible with .NET Core, but I don’t plan to migrate just yet, because I don’t see clear benefits and there are some limitations. Running my application on Linux is not a goal itself, so instead I looked for an alternative.

Attributes are a very useful feature of many languages but I personally feel that they are used too often and in wrong circumstances. They’re primary shortcoming is the fact that attributes are set up at compile time. During code execution they can only be read but not modified.

The open-closed principle is the second letter of the SOLID acronym. SOLID is a set of software design guidelines which help build better software. The open-closed principle declares that

software entities should be open for extension, but closed for modification

One way to satisfy this principle is through the use of the Strategy design pattern, sometimes called Policy. I’d like to show how easy it is to employ this pattern in reusable and extensible components for a Nancy application.

I find overloading operators a very powerful tool in a programmer’s arsenal, yet it seems a very rare practice among C# developers. I’ve just got bitten by a simple scenario where an explicit cast operator is a questionable idea.

I just noticed that I forgot to change the permalink of my last post. I intended to write about tech, but ended up writing about buses only. Too bad, but I’m not going to change that now. I this post I will write a little bit more about what I’m actually implementing for wikibus.org