diff --git a/data/blog/an-introduction-to-rabbitmq.mdx b/data/blog/an-introduction-to-rabbitmq.mdx
new file mode 100644
index 0000000..713468f
--- /dev/null
+++ b/data/blog/an-introduction-to-rabbitmq.mdx
@@ -0,0 +1,92 @@
+---
+title: An introduction to RabbitMQ
+date: '2023-05-16'
+tags: ['#rabbitmq', '#messagebroker']
+draft: false
+summary: A brief overview of RabbitMQ's main concepts
+images: []
+layout: PostLayout
+canonicalUrl:
+---
+
+## What is RabbitMQ?
+
+[RabbitMQ](https://www.rabbitmq.com/) is an open-source message-broker software written in Erlang.
+
+It's called Rabbit because it was originally developed by Rabbit Technologies Ltd. 🐇
+
+- It is very reliable and used by a large number of companies
+- Fast and powerful with in-memory processing
+- It implements multiple communication protocols such as AMQP, MQTT, STOMP e HTTP
+- It's a platform-agnostic solution
+
+## How does it work?
+
+Essentially, here are some core players in RabbitMQ.
+
+- **Producer** - application who sends the message
+- **Consumer** - application that receives the message
+- **Message** - information that is sent from a producer to a consumer
+- **Exchange** - message routing agents
+- **Queue** - a sequential data structure that is a medium through which messages are transferred and stored
+
+A **binding** is like a link you set up to bind a queue to an exchange.
+
+The **routing key** is a message attribute the exchange looks at when deciding how the message will be routed to queues depending on the exchange type.
+
+### Basic flow
+
+A producer sends a message to an exchange.
+An exchange is responsible for routing the message to different queues with the help of header attributes, bindings, and routing keys.
+The consumer can be subscribed to a queue and receive the message.
+
+Producer -> Exchange -> Queue -> Consumer
+
+## Types of exchange
+
+- **Direct** - route messages to queues based on a routing key
+- **Fanout** - route messages to all queues that are bound to it
+- **Topic** - route messages to queues that match a wanted pattern
+- **Header** - route messages based on header arguments
+
+
+
+## Queue
+
+The queue works in FIFO (_First In, First Out_) pattern.
+
+There are some important [queue properties](https://www.rabbitmq.com/queues.html#properties):
+
+- **Durable** - if the queue must be saved even after the broker restart (disk persistence or just in memory)
+- **Autodelete** - remove the queue automatically when the consumer disconnects
+- **Expiry** - defines the time that there are no messages or clients consuming and when this time is reached, the queue is deleted
+- **Message TTL** - 'message time to live', if the message gets to it and it is not consumer, then it gets excluded
+- **Overflow** - when the queue is so busy that is overflowing
+ - Drop-head - older messages are removed to receive new ones
+ - Reject publish - queue rejects messages
+
+## Reliability
+
+RabbitMQ has some [resources](https://www.rabbitmq.com/reliability.html) that can be configured to ensure that messages are always delivered, even encountering failures of various kinds.
+
+- **Consumer acknowledgment** - when the consumer confirms the message receive
+- **Publish confirm** - exchange returns to the producer if it receives the message
+- **Queues and durable messages**
+
+## RabbitMQ simulator
+
+There's a great simulator to understand how it works called [Try RabbitMQ](http://tryrabbitmq.com/).
+
+## RabbitMQ via Docker
+
+You can also run RabbitMQ on your own and see how these concepts work.
+
+To run it via Docker:
+
+```bash
+docker run -d --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.11-management
+```
+
+RabbitMQ user and password is _guest_.
+
+You can also check more [downloading and installation options](https://www.rabbitmq.com/download.html).
diff --git a/data/blog/conventional-commits.mdx b/data/blog/conventional-commits.mdx
new file mode 100644
index 0000000..8bca975
--- /dev/null
+++ b/data/blog/conventional-commits.mdx
@@ -0,0 +1,98 @@
+---
+title: Conventional commits
+date: '2023-02-10'
+tags: ['#git', '#conventionalcommits']
+draft: false
+summary: How your commit message can make a difference
+images: []
+layout: PostLayout
+canonicalUrl:
+---
+
+## Conventional commits, have you ever heard of it?
+
+As developers, we are writers. As writers, we intend to communicate through everything we write such as code, documentation and also commit messages.
+
+[Conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) are a standardized format for writing **commit messages**.
+
+By adopting conventional commits, teams can create commit messages that follow the same structure, and format, making it easier to review and understand changes made in the codebase.
+
+It clearly helps avoid terrible commit messages with no meaning and increases the team's communication through git commit messages.
+
+Conventional Commits are related to [Semantic Versioning](https://semver.org/) assisting in controlling major, minors, and patch versions.
+
+## How does it work?
+
+According to Conventional Commits, the commit message should be structured as:
+
+```
+[optional scope]:
+[optional body]
+[optional footer(s)]
+```
+
+The **type** is an indicator of what has changed. Some of the most famous types will be listed [below](#types-of-commits) in this post.
+
+The **scope** is optional and used to indicate which part of the project was changed.
+
+The **description** is a brief description of the change. Should be written in an imperative mood.
+
+The **body** is free-form and may consist of any number of newline-separated paragraphs.
+
+## Types of commits
+
+- **feat** - introduces a new feature to the codebase
+- **fix** - a bug fix
+- **docs** - changes to documentation
+- **style** - changes that are related to white spaces, formatting, removing comments, missing semi-colons
+- **refactor** - refactoring of code
+- **test** - addition of tests or correcting existing ones
+- **build** - changes related to the build of the application or external dependencies
+- **ci** - changes made to the continuous integration configuration files and scripts
+
+A commit that has a footer **_BREAKING CHANGE:_**, or appends a **_!_** after the _type[scope]_ introduces a change that can break the app and it is usually associated with a new major version.
+
+## A few examples
+
+The following examples are on the Conventional Commits documentation.
+
+**Commit message with ! to draw attention to breaking change**
+
+```
+feat!: send an email to the customer when a product is shipped
+```
+
+**Commit message with scope**
+
+```
+feat(lang): add Polish language
+```
+
+**Commit message with multi-paragraph body and multiple footers**
+
+```
+fix: prevent racing of requests
+
+Introduce a request id and a reference to latest request. Dismiss
+incoming responses other than from latest request.
+
+Remove timeouts which were used to mitigate the racing issue but are
+obsolete now.
+
+Reviewed-by: Z
+Refs: #123
+```
+
+## VS Code extension
+
+The [Conventional Commits VS Code extension](https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits) is very helpful extension to write commits the Conventional Commits way.
+
+
+
+## Commitlint
+
+You can also set your project up with Conventional Commits using [Commitlint](https://commitlint.js.org/#/).
+
+Commitlint checks if your commit messages meet the Conventional Commits format.
+
+
diff --git a/public/static/images/posts/direct-exc-rabbitmq.png b/public/static/images/posts/direct-exc-rabbitmq.png
new file mode 100644
index 0000000..13dfb49
Binary files /dev/null and b/public/static/images/posts/direct-exc-rabbitmq.png differ