Recently I had an interesting discussion about open sourcing most of the code that you write on a daily basis, especially in terms of commercial usage, for example creating your own product or service. Here are some of the thoughts and assumptions, and I’m really looking forward to hearing your own remarks and also share your experience.
Hey everyone, I haven’t been asking anyone for help with developing the software for quite some time now, but well, the time is the crucial part here. I wish that the day lasted much longer than it currently is, yet, since I can’t do much about it, I want to ask you for help with contributing to the open source projects that I’ve been working on. It could be anything, like a feedback or an actual contribution (e.g. via Pull Request) and maybe you will find some of the projects interesting as there is a few of them waiting to be developed further.
Recently I’ve been doing a lot of DevOps in order to automate the continuous integration and deployment (CI & CD) of the microservices as much as possible. In this article, I’d like to share with you some of my experiences how to get started with creating your own deployment process and this is going to be the first part of the series of articles related to this process.
It’s been quite a while since I posted the latest update of the Warden project designed for monitoring the resources in general. After a lot of back-end coding and refactoring, the time has come to finally focus on the new web interface implementation. And this is where the things start to become interesting (I promise).
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.
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.
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.
It’s been 2 months since the latest version of the Warden has been released as the NuGet packages. Although our focus (yes, I’m not the only one person anymore working on this project) has moved towards the development of so-called stack (brand new API, Website, Microservices etc.) I’m still actively developing the core library in order to make it even more useful than before.
Nowadays, the HTTP APIs act as gateways for petabytes of data and some chunk of it might actually require enhanced access rules. For example, you could create a link that allows the user to download the file only once, and within such link you would find a token.
I was in a need of creating such solution for my open source project Warden – a specialized, one-time link that can be used fetch the configuration object from the API.
It turned out to be fairly straightforward to implement the most basic version of such behavior.