Today’s post was written by Jenny Holt who asked me if she could write a contributed content for my blog. She did agree with one of my previous articles about working remotely and wanted to share her thoughts about that matter. Thank you, Jenny!
It’s been a few months already since I’ve started working for good with distributed systems using (micro)services and asynchronous processing via service bus. Many issues and question raised and one of these was how to not lose the information about commands and events being processed and even more importantly, how to notify the user once the request has completed? I’ve had to come up with some solution that seems to be sufficient (at least for now) and I’d like to share it with you.
Writing a project documentation – everyone’s or at least the programmer’s nightmare, right? Although at a first glance many of you will most likely agree with the given assumption, I’ll try to convince you otherwise. Not only it doesn’t have to be a dull experience, but it might be a truly fun and quite refreshing activity, which shall provide the great value for the project.
Necessity is the mother of invention – that’s basically why I did create a new open source project called Lockbox. Its main purpose is to provide a centralized and secured storage for the application settings that can be easily fetched via HTTP request. Sounds interesting? Then let me guide you through the most important concepts of the Lockbox.
Not so long ago, I’ve eventually decided to dive into the world of microservices.
I did look for an opportunity to make use of this architectural pattern for quite some time and finally was able to do so.
After 3 months of trying out the new things and learning stuff mostly on my own (the hard way) I believe it’s a good time to share some of my experience. I have no doubts that at some point in the future when I look back at this post I might be like – “oh God, what was I thinking back then, it’s so wrong”, but well, let me show you what did I learn so far and maybe you won’t repeat some of my mistakes.
When someone talks about the diversification, it’s usually about financial assets. Every investor will tell you, that you should spread your investments amongst different sources of possible income. If you put 100% of all that you’ve got into a single asset and something goes wrong then you’re totally screwed. Yet, it’s not only about the financial market – let’s talk about diversifying our own skills.
Choosing a service bus that meets our demands is a crucial part when developing a distributed system. There are many services to choose from like MSMQ, Azure Service Bus or RabbitMQ and even more frameworks that you can use in your projects as an additional layer of abstraction that makes your coding much easier when it comes to dealing with the specific service bus implementation. In this article, I’d like to present how to use the RabbitMQ in .NET Core with the help of really nice RawRabbit library.
2016 is about to finish in a few weeks, yet there are a few more things that I’ve planned to do before this year comes to an end. I’m really into the open source right now and about to publish some tutorials. If that sounds interesting to you, please take a look at the whole post.
I’ve eventually decided to start using the *NIX system for the software development.
Being a Windows user and the .NET developer for many years now, it might seem like a radical change, but let me tell you this – it was a great decision and here is the explanation.
It’s been quite a while since I’ve started gathering some knowledge about the microservices architectural pattern that’s been on a hype recently. After reading many articles, some books like Microservices in .NET Core and talking with smart guys in the Devs PL Slack channel, I’ve eventually decided that the time has come to try to make the microservices happen in the real world project. That’s the beginning of my journey into the distributed programming and architecture, so please keep that in mind while reading this newbie’s post and remember I’d be more than happy to hear your opinions and feedback about the approach that I’m about to present.