Nothing happened, really, since announcing the beta, so this is just a little public service announcement to tell you that Tababular is out now as version 3! 🙂
“What’s tababambabular?”, you might ask?
It’s just a little nifty library that can format data as tables, which is a nice thing to do sometimes.
E.g. in automated tests, instead of outputting one manually formatted crappy-looking test output after another, why not just collect the data and print it as a table? Here’s an example from the Fleet Manager’s driver, where emitted saga snapshot states are presented in a nice, readable summary form:
+-----------+--------------------------------------+ | Revisions | SagaId | +-----------+--------------------------------------+ | 0 | 42d9beb5-d94c-4f62-9c60-65beb40c9b5e | | 1 | | | 2 | | | 3 | | +-----------+--------------------------------------+ | 0 | 1c4c3db0-9ac2-4541-9752-ed01719aa217 | | 1 | | | 2 | | | 3 | | | 4 | | | 5 | | | 6 | | | 7 | | +-----------+--------------------------------------+
Or how about CLI applications? Check out how Fleet Manager’s administration CLI presents the list of accounts in our DEV environment:
Happy formatting! 📜
Lots of small changes, only a few of them breaking(*), nothing earth-shattering 🙂
Another slightly bigger change is that Rebus now targets .NET 4.5, .NET 4.6, and .NET Standard 2.0. If anyone is missing the .NET Standard 1.3. support, please ✉️➡️[email protected] and let us know why 👻
Some of the smaller changes include a few performance improvements 💨, an extension point to customize how topic names are created out of .NET types, the ability to “fail fast” (i.e. skip retries) in various situations 💥, and a way to delay message processing when starting up the bus.
As usual, WIRE-COMPATIBILITY is 100% with all versions of Rebus from 2 and up, so you don’t need to go all-in to start upgrading your endpoints! 😇
See the full 5.0.0 changelog entry for more details on what was changed.
(*) In theory, all changes can be breaking… in this case, the version was bumped to 5 primarily because the
IRoutingApi interface was extended with the
Defer method signature, and because all of the testing helpers were moved.
If you’re running your Rebus stuff on .NET Core, and you’re using “Microsoft Extensions Logging” (that’s just not a bite-sized title for a logging library), you’re in luck: Rebus now has Rebus.Microsoft.Extensions.Logging, so you can
var loggerFactory = new LoggerFactory() .AddYourSinksHere(); Configure.With(...) .Logging(l => l.MicrosoftExtensionsLogging(loggerFactory)) .Transport(t => t.Use(...)) .(...) .Start();
and have Rebus log its stuff there, too.
The package is currently in alpha, but since there’s not much to it, we expect it to be pretty stable.
Happy logging! 🤠
For almost a year, this GitHub issue has been open – but I’m happy to announce that I’ve closed it just now, which I’ve done of course because Rebus’ Azure Service Bus transport has now finally been ported properly to Microsoft’s new Azure Service Bus driver.
When the new driver came out, lots of people were puzzled, because it lacked the management operations from the original driver. This meant that queue creation, topic creation, and even mundane stuff like subscribing to topics, could not be done with it.
It took a long time and some pretty dedicated community work for the driver to come out with management operations in it, which happened about two months ago (as a prerelease, stable version was out one month ago).
Today, all of our Fleet Manager environments have been running with Rebus’ new Azure Service Bus transport a week or more, so we’re ready to let Rebus.AzureServiceBus 6.0.0 out into the wild 🦁🌳which in turn means that Rebus can use Azure Service Bus on the .NET Core 2.0/.NET 4.6.1 and later runtimes.
The process of building larger software projects holds many small opportunities for separating out small utilities and helper libraries, and one such opportunity has again arisen 🙂
It’s of course not meant to be able to replace real message brokers and queueing systems, but if you’re in a tight spot, and all you have is MongoDB, then it might just save the day! 🤠
Using it is easy – you can configure it like this:
var config = new Config( connectionString: "mongodb://MONGOBONGO01/Readme", collectionName: "messages" );
and then you send a message to a queue named
my-queue like this:
var producer = config.CreateProducer(); var payload = Encoding.UTF8.GetBytes("Hej med dig, min ven!"); var message = new Message(payload); await producer.SendAsync("my-queue", message);
When it’s time to receive a message, you create a consumer for a specific queue like this:
var consumer = config.CreateConsumer("my-queue");
and then you get the next message like this:
var messageOrNull = await consumer.GetNextAsync(); // do stuff with the message if it's not null
MongolianBarbecue uses lease-based locking of messages, so it’s safe to use in any kind of distributed scenario you can come up with (e.g. like competing consumers). Moreover, it is pretty easy to use it to implement distributed locking, which can be used to implement exclusive access to a distributed resource.
This is just a tiny update about the nifty little library that is Tababular, because I enjoy using it so much, and I think more people should be using it too 🙂
The latest prerelease (3.0.0-b02) adds .NET Standard 2.0 as a target, and it has had a make-over making it appear more spacey, and therefore easier to decode visually:
+-------------+--------------+-------------+ | FirstColumn | SecondColumn | ThirdColumn | +-------------+--------------+-------------+ | r1 | hej | hej igen | +-------------+--------------+-------------+ | r2 | hej | hej igen | +-------------+--------------+-------------+
Last but not least, it has had its reflection routines implemented using the brilliant FastMember library, thus making it easier on your CPU 😊
So… we’ve been pretty busy here at Rebus FM, building the 2nd incarnation of our Fleet Manager product (which is actually the 5th or the 7th rewrite of the frontend, depending on how you count it… but who cares?!).
We celebrated Labour Day by working even harder, which means that it’s available now! We just call it Version 2, but if you have been using the old Fleet Manager, you can probably see that it looks a little different:
It has seen numerous improvements – too many to mention, really – so I suggest you go check out some screenshots on the updated Fleet Manager page, or just go to https://manager.rebus.fm if you’re already a customer.
To whet your appetite as a Rebus user, who is eager to one-up your game, I have posted a bunch of screenshots here on the Fleet Manager page.
While Fleet Manager is still in development and is nowhere near finished yet, it can still be quite useful to provide an overview over what is running and what is not.
If you are interested in getting access, please go consider the Rebus Pro offering – it includes a 24h support agreement in addition to instant cloud-hosted Fleet Manager access.
It took a couple of iterations to figure this out, but finally it has become clear which shape the commercial Rebus offering is going to take.
Say hello to REBUS PRO! 🙂
Rebus Pro is
accessible by subscription (monthly, with savings for 3 or 6 months commitment).
Please shoot an email to [email protected] if you are interested in hearing more 🙂
(*) Bring Your Own Hardware 😉
It only took 23 beta versions to get there 🙂
The cool thing about Rebus 4 is that it targets both .NET 4.5 and .NET Standard 1.3, making it possible to run Rebus endpoints on all server platforms that matter. In fact, I know of people who at this point have been running quite a lot of Rebus on AWS… On Linux! In Docker containers!
Most integration packages have been updated too, and almost all of them are supported on .NET Core as well, so you should go ahead and try it out.
Notable exceptions at this moment are
MSMQ is not supported by any .NET Standard version, so it’s quite obvious why the 4.0.0 version of that package still only targets .NET 4.5.
Azure Service Bus is supported on .NET Core now though, but it has been implemented in a completely new version of the driver that has a radically changed API and therefore requires a lot of work to update. Version 4.0.0 of
Rebus.AzureServiceBus will therefore target .NET 4.5 only.
You may go
Update-Packages Rebus now 🙂