Yearly Archive 2016-10-24

ByMogens

Rebus FM has a new address…

…even though we didn’t move!

The Horsens Municipality just threw at us today that our address has been changed from

Søndergade 15F, 2. sal

to

Søndergade 15H, 2. sal

Of course it does not matter that much these days, but in case you were planning on stopping by for a cup of coffee, Søndergade 15H, 2. sal is the place to go.

I think the address has been updated in all the relevant places. Good thing we don’t have any business cards yet 😉

ByMogens

Today is cake-day in the Alley…

…because Mogens has – once again, after a break that has lasted a couple of years – received the “Most Valuable Professional” award from Microsoft, a.k.a. Microsoft MVP.

Here is what a bunch of programmers look like when they are high on sugar:

2016-10-03-13-47-57

ByMogens

Fleet Manager status

Work is ongoing with building Fleet Manager, but it is not going as fast as we would like.

However, that does not mean that there is no progress – we are working slowly, but steadily, in order to provide a truly useful tool with a sturdy backend and an acceptable frontend 🙂

If you are interested in trying it out, please go to the Fleet Manager pre-alpha sign-up page and register yourself – then we will get in touch as soon as we think we have something that is worth trying out.

ByMogens

Rebus 2 is out!

I am happy to announce that Rebus 2 has finally been published with a “real version number”.

After many year of notorious unwillingness to bump the version to something binding (i.e. >= 1.0), Rebus is now out in version 2.0.1, accompanied by its > 30 integration packages.

This means that all APIs are now stable, and users can rely on pulling down only non-breaking changes when they update packages within the v2 range.

Happy messaging! 🙂

ByMogens

Rebus roadmap

Rebus 2 has been in development for about 1,5 years now, and it has been used in production for at least one year by myself and many others… and by “Rebus 2”, I mean Rebus versions >= 0.90.0 🙂

Sorry about the confusion

First off, I would like to apologize for the confusion about the versions. For historical reasons the versions less than and including 0.84.0 are known as “Rebus 1”, and versions greater than and including 0.90.0 are known as “Rebus 2”. If you are interested, you can see the original announcement in this blog post.

Fixing the versioning

In order to “fix the versioning”, Rebus will soon become a real version 2.0.0.

In semantic versioning this marks as big step, as versions < 1.0.0 are allowed to make breaking changes for every single release, and thus are inherently unstable. Therefore, when Rebus becomes 2.0.0, it means that patch increments are for bugfixes and small improvements, minor increments are for backwards compatible feature additions, and then the major version number is incremented whenever a change is made which is NOT readily compatible with existing code.

When is this going to happen?

A few things need to be done before this is going to happen, where the main thing is that the ground must be laid for how the Rebus code repository should be split into separate repositories in the future.

It does not mean that 2.0.0 will necessarily wait for all of the libraries to have been moved, it just means that a few libraries must have been moved to prove that the code structure and everything surrounding the code works to support the new way.

If you are interested, you can follow the progress here on GitHub – for now, the due date for the milestone is set to the October 1, 2016.

Summary

If all goes well, Rebus 2.0.0 will be published on October 1, 2016 🙂

ByMogens

Rebus now has a data bus

The most recent addition to Rebus is a “data bus”, i.e. an implementation of the claim check pattern as described in The Good Book.

With the data bus, it has suddenly become extremely easy to transfer e.g. large CSV files from one endpoint to another, because the bus now supports creating attachments from streams, as well as opening up attachments as streams again in the receiving end.

Data bus attachments support including arbitrary metadata along with the attachment, allowing you to pass along file names, information about who made the attachment, etc.

You can read more about the feature on the official documentation wiki page.

ByMogens

Open source update

As part of daily work, little code snippets and useful bits crystallize and turn out to be so useful that it would be a shame not to share it with anyone.

Yesterday, two new small and focused projects were added to rebus-org: Owino and Swindler.

Owino

Owino is a NuGet package with OWIN extensions. At the moment, it has one single extension method: RegisterForDisposal, which is an extension method on IAppBuilder. You can use it like this:

public void Configuration(IAppBuilder app)
{
    // we're using Windsor
    var container = new WindsorContainer();

    // we're doing stuff
    // (...)

    // we ALWAYS dispose our IoC containers after use
    app.RegisterForDisposal(container);
}

which then ensures that the container is properly disposed when the application shuts down – no matter if the OWIN endpoint is hosted in-process, in an IIS, in a test, or somewhere else.

Swindler

Yesterday Jeremy Miller talked about having to juggle AppDomains in order to properly test code that relies on ConfigurationManager.

You don’t have to pull out the big gun to shoot that tiny bird though, because it IS possible to have the current AppDomain load another app.config – it just requires some tweaking of some private static fields in ConfigurationManager and some other places.

Swindler makes that part easy, because you can just do this:

[Test]
public void SomeTest()
{
    using (AppConfig.Use("my.custom.app.config"))
    {
        // ConfigurationManager will load app settings,
        // connection strings, and custom sections from
        // my.custom.app.config in here
    }
}

which then provides a way to actually test that you can pick up app settings, connection strings, and any custom configuration sections that you might have created.

Where to get it?

They’re both MIT-licensed and can be downloaded from the following places:

ByMogens

Sometimes, it’s the little things…

Lately, I’ve been messing around with making small CLI apps quite a bit. I use it to perform various backend tasks on a couple of cloud-hosted APIs, which has turned out to be a really nice way of automating backend tasks while not needing to build any kind of graphical UI for them.

The other day I wanted to be able to manage user accounts from the command line as well, which required me to input a password to the CLI app somehow – but how to do that without passing the password on the command line?

If I had to do it like this, I would make the password part of that particular console window’s history:

C:\> whatever createuser -user [email protected] -password nooneMustSeeThis!!

which would pose a general security risk. An obvious way to fix that, is to have the CLI app prompt the user for the password, allowing me to enter the password at runtime:

C:\> whatever createuser -user [email protected]

Creating user '[email protected]'

Please enter password: nooneMustSeeThis!!

...

While this is better than accepting it directly as a parameter, it is still not totally acceptable, because the password will be perfectly visible in the console window’s buffer history.

Usually, when prompting the user for a password, we let UIs output little asterisks as a placeholder for each character – and that is of course what we should do 🙂

And that is what I made a small (the smallest one I have made to this date) NuGet package called “Shtern”, which contains one single static method: Password.ReadLine().

With Sthern, the password input scenario would look like this:

C:\> whatever createuser -user [email protected]

Creating user '[email protected]'

Please enter password: *******************

...

while of course delivering the password string to the application. And that was exactly what we needed 🙂

As usual, the code is on GitHub and the package is on NuGet.org.

ByMogens

Tababular

Sometimes it’s nice to be able to work with text, especially when you’re building command-line applications. I usually end up with a bunch of little text formatting helper methods, and recently I made one that could format a JSON array as a nice ASCII table.

I figured that this could be of use to other people as well, so I pulled it out, cleaned it up, added a few nifties, and made it into a NuGet package: Tababular (the code is on GitHub as usual).

First you

Install-Package Tababular -ProjectName YourProject

and then you can do this:

var objects = new[]
{
    new {FirstColumn = "r1", SecondColumn = "hej", ThirdColumn = "hej igen"},
    new {FirstColumn = "r2", SecondColumn = "hej", ThirdColumn = "hej igen"},
};

var text = tableFormatter.FormatObjects(objects);

Console.WriteLine(text);

which will give you something nice to look at:

===============================================
| FirstColumn  | SecondColumn  | ThirdColumn  |
===============================================
| r1           | hej           | hej igen     |
===============================================
| r2           | hej           | hej igen     |
===============================================

and that’s it 🙂

(although there’s a few nice details, like e.g. the ability to properly format multiple lines in cells, etc.)

ByMogens

Rebus FM and open source

It should come as no surprise that we love open source here at Rebus FM – after all, we are building our business around Rebus, which has always had pure open source pumping through its arteries.

We are doing other things too, which we plan to release on the rebus-org organization on GitHub.

If you are working with either Microsoft SQL Server or the excellent PostgreSQL in .NET, you might want to check out our latest addition to the org: Migr8.

Migr8 is a sweet database migration tool that allows for having migrations written as short and sweet scripts, either in C# code or as text files.

It is pretty unique because it supports parallel development of migrations, and thus is the perfect companion if you are working with a git-flow-like workflow where multiple branches are being developed at the same time.

Moreover, Migr8 has now been extended to support PostgreSQL – so, depending on which database you want to use, you can either

Install-Package Migr8 -ProjectName YourProject

or

Install-Package Migr8.Npgsql -ProjectName YourProject

and then start migrating that database.