In typical web development scenarios, developers do not have to take any special care about memory management. It definitely makes it easier to program the process you’re working on, but it might bite you in the back when your application turns out to be popular. Increased load or growing amount of data being processed will result in higher and higher memory usage, which translates directly to higher costs. In today’s environments with dynamic scaling it is definitely less of a problem than it used to be in the past, but it does not nullify the issue. The additional resources still need to be paid for, and problems will accumulate.

Therefore, I think it makese sense to have at least basic knowledge on what’s going on behind the scenes when you create that new object. It’s worth to stop for a second and make sure that the way you coded that new feature is actually optimal in terms of memory usage (just to be clear, sometimes it doesn’t matter at all, but often it actually does). Should you use a class or a struct? Does this new field in you class have a big impact on overall memory usage or not really? Does that odd pause in your API’s processing that shows up in metrics from time to time is a sign of something bad going on? I was wondering about these (and other) topics myself, and after a bit of research I wrote the following:

• Garbage Collection in general
• .NET:
  • Overview of .NET Memory Management
  • Garbage Collector Internals
  • GC Memory Layout & Allocation
  • GC Advanced Topics

Most of the information in the articles are based on the excellent Pro .NET Memory Management book. I highly recommend it if you find yourself interested in the topic. My articles contain the bits that I found the most important for myself, with additions based on my own experimentation and other sources.

Hope you find it useful!

Recently I’ve been adding some content on databases to my website. There already was some content on specific database products, like:

• Microsoft SQL Server
• MongoDB
• elasticsearch

but I was missing some general facts on things that are common among databases in general. If you think about it, there’s quite a lot of topics that any database engine has to take care of. These are things such as:

• trancastions
• indexing
• partitioning and sharding
• …

As a result, a bunch of articles have been added under the Databases node. I know it’s gonna be useful to me, as a refresher, and I hope it’ll be useful to you as well.

I’ve added a new set of articles on asynchronous programming to my website. These articles are a deep dive into the mechanics of async operations, tailored for those curious about how it all works beneath the high-level abstractions provided by programming languages and frameworks. Here’s a quick summary of what’s covered:

• Overview of Asynchronous Code Execution: An introduction to the basic concepts and the difference between concurrency and parallelism. This article lays the groundwork for understanding how async code operates, especially in the context of operating systems and multitasking.
• Event Queues: A look into how operating systems like Linux, macOS, and Windows handle async operations through event queues, and the implications for programming.
• Green Threads/Fibers: An exploration of green threads or fibers, which are user-space managed threads that offer an efficient way to handle concurrency without relying heavily on the operating system’s thread management.
• Stackless Coroutines and Async/Await: A detailed look at how modern programming languages implement async/await patterns using stackless coroutines, simplifying asynchronous programming.

These articles are my attempt to break down the complex topic of async programming into more digestible parts. Whether you’re a seasoned developer or new to the concept, I hope you find these pieces enlightening.

Added a new article about Elasticsearch. Elasticsearch is a search and analytics engine, useful for handling large amounts of data in real-time.

I’ve been exploring it lately and jotted down some notes to clarify its main features for myself. If you’re curious or ever delve into the topic, they’re there on the site.

One of the sections of this site is Projects. Initially, it had a very similar structure to the rest of the website - a sidebar on the left, listing some of my projects, and the actual content about the projects on the right. Recently, I started to think about improving that sections, due to the following reasons:

• all of my projects are on GitHub, so maybe it would make sense to pull some metadata from there to make the view on them here more attractive
• again, all of my projects are on GitHub, so why would I duplicate the contents of README files as part of this website? Updating any README requires me to update it here as well

The result is a revamped Projects section. Its features are:

• projects are presented as clickable tiles (that take you to GitHub)
• projects’ titles, descriptions, programming language icon, and star counters are data pulled from GitHub using its API (I used Octokit)
• some projects have downloads counters. Projects with that characteristic are only those that are being distributed via some kind of store/package repository. In my case, I implemented services that pull that kind of data from: npm, crates.io, Gnome Extensions, Chrome Web Store, Edge Addons.
• projects’ data gets refreshed only during builds, to keep the client-side code as light as possible. To keep the data relatively up-to-date, I added a cron-based trigger to my GitHub Action, so that the data is refreshed everyday, in addition to builds on push.

Projects being displayed are still hand-selected, since displaying ALL of the stuff from GitHub would bring a lot of trash, which even I don’t want to look at.

Lately I’ve been playing around with the GTK toolkit, especially in the context of using it together with GJS to create Linux GUI apps with JavaScript (or preferably TypeScript). As usually, when learning something new, I’ve done some notes. They are available for anyone interested right here. It should give you a general overview of what GTK is, and what it consists of. It also gives a brief introduction into how to use it with JavaScript.

I found that one of the easiest way to develop GTK apps is by creating Gnome Shell extensions. Here’re a couple of them that I’ve authored:

• Quick Settings Audio Devices Hider
• Quick Settings Aduio Devices Renamer
• Do Not Disturb While Screen Sharing or Recording
• Dim Completed Calendar Events

The first two extensions were even highlighted on OMG! Ubuntu (Renamer, Hider), which was really cool to see.

Hey there! So, my website has been running on VuePress (v1) since the beginning. It’s been pretty good, but let’s face it, it had some shortcomings. VuePress websites are Single Page Apps (SPAs), which means there’s a lot of JavaScript involved. That’s fine for interactive sites, but for a content-focused website like this one, it’s not ideal. That’s where Astro comes in, a framework that puts performance first.

I’d been keeping an eye on Astro for a while, and when it reached version 2, I thought it was the perfect time to switch this website from VuePress to Astro. The transition went smoothly, and here’s a quick overview of what I had to tackle:

Building core components: Astro doesn’t come with built-in features like navbars, sidebars, or tip boxes, which VuePress does. So, I rolled up my sleeves and created them myself.

Code syntax highlighting: VuePress has a nice out-of-the-box syntax highlighting configuration, while Astro provides only the default code syntax coloring. To get specific line highlighting, I had to craft a custom component.

Recreating the theme: My site’s theme used to be coded into VuePress, intertwined with its default theme. Switching to Astro gave me the chance to clean things up, and now I’m in the process of transitioning it to Tailwind CSS.

One of Astro’s coolest features is Content Collections. It lets you organize content by splitting it into different types (for me, it’s “articles” and “posts” like this one). Each type can have its own TypeScript-typed metadata, making it easy to fetch content along with its metadata and work with it in various ways. This feature came in handy when building components like the Sidebar.

To wrap it up, Astro is pretty awesome for static websites that focus on content. If that’s what you’re looking to create, I’d definitely recommend giving Astro a try.

I’ve added an article about one of the pillars of Observability in modern distributed cloud systems - Tracing. Tracing is nowadays a part of the OpenTelemetry standard, it’s the part of the standard that is the most stable and well-defined. Tools like Jaeger alrady implement the standard, so it’s the right time to jump on board, and start tracing out apps using OpenTelemetry SDKs. You can find the article here.

I added an overview of the SELinux subsystem, which is one of the popular MAC systems that are available on Linux. It’s used mostly in the Red Hat world (Red Hat Linux, Fedora), but can also be found on other Linux distributions (also on Android). I was interested in the topic mostly due to the fact that Podman relies on SELinux when mounting volumes. Lack of any SELinux knowledge might lead to issues when containers try to access the mounted files. While learning about SELinux, I found it to be quite an interesting topic. You can see my gist of it here.

I’ve been studying Angular for a few weeks now. Although I’ve used this technology numerous times in the past (e.g., in my master thesis), it’s been a few years ago and I naturally forgot most of the things, even the basics.

Anyway, since I need Angular again for one of the projects that I’m working on, I had to pick it up again, and as a result, an Angular Series was born. I’m still working on it, especially on the NgRx bits, but the whole thing is at around 90% level of completion. I already see myself going back to some parts of it as I’m starting to use Angular, which proves that it’s useful. I hope it will be useful for you as well.

I have to admit that I was very Vue-focused in the last years, and I didn’t think I’d be ever switching to anything else. I’m not so sure anymore! Angular is definitely more involved, it requires you to write more boilerplate code (it’s changing with Standalone Components!), but it’s also very well structured and it kind of reminds me a bit of ASP.NET Core’s way of doing things.

For small quick projects I’d probably stick with Vue.js, but for bigger ones, Angular could be a great alternative.

ASP.NET Core is such a fundamental technology in the projects that I work on that I decided to write an overview of it. In the process, I have looked into the parts that I do not normally utilize (like Razor Pages). It was an interesting journey that helped me to put my knowledge of the ASP.NET Core framework in order. My main interest in the ASP.NET Core land has always been the Web APIs and most of the knowledge in my article series is applicable to that.

You can find the articles here.

Kubernetes is such a commonly used technology nowadays that various tooling and solutions have been born around it. One of them is Helm. In one of the projects I’ve been working on professionally, I had to make use of Helm. Well, I didn’t really have to, but it turned out to be the easiest solution. A part of my task was to deploy WordPress onto a K8s cluster. Solution offered by Bitnami was so simple that I decided to dig a bit deeper into Helm. As a result, I packaged another app with Helm making its deployment easier. An additional result is an Overview of Helm that I’ve written. I know I will be getting back to it anytime I need to use Helm. Hopefully, you will find it useful as well.

There seems to be a lot of hype around Rust recently. Especially in the Linux community, Rust seems to be gaining popularity. One of the reasons for it is the GTK 4 toolkit and the gtk-rs bindings project for it.

I wanted to explore why that language became so popular, so I decided to learn it, at least on a beginner level. The lessons I’ve learnt have been noted in the Rust Series.

I think the language is quite interesting and its heavy focus on memory safety has high impact on how the programmer writes code. You have to kind of switch your mental model to what Rust requires and rememeber that variables should be modified in one context only. There also seems to be a lot of ideas from functional programming that Rust devs like to use, and Rust has some utilities built-in to make it easier to apply them (like the Result monad). What I really liked was the match keyword and the ease of returning data with it. It’s important to note though that Rust is quite a difficult language. There’s lots of things to keep in mind, especially when it comes to sharing data between functions (even more difficult in parallel context). Personally, I still prefer the ease of C# and freedon of JavaScript/TypeScript over Rust, but I can see why many people seem to love it nowadays.

While learning Rust, I’ve purchased the Rust in Action from Manning. I got so used to high quality of Manning publications and I did not expect any surprises in that area. However, with that book, it seemed to me like the author was delivering the content out of order, and it was just unbearable for me. I stopped in the middle, and picked up the official Rust book. I have to admit, it’s one of the best tutorial books I’ve ever read, and it cannot even be compared with the Manning one.

The best way to learn any new programming language is to actually write some code. I did just that and created a small CLI utility called Puff. It is a fairly simple tool allowing you to manage certain files (like configs) in a central place with the help of soft links.

If you want to learn Rust, I suggest that you go through the Rust Book. My content is a brief summary of that book.