<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
        <title><![CDATA[Márcio Sobel - Blog]]></title>
        <description><![CDATA[yapping about stuff online]]></description>
        <link>https://blog.marciosobel.dev</link>
        <image>
            <url>https://blog.marciosobel.dev/rss_icon.png</url>
            <title>Márcio Sobel - Blog</title>
            <link>https://blog.marciosobel.dev</link>
        </image>
        <generator>RSS for Node</generator>
        <lastBuildDate>Wed, 17 Jun 2026 12:28:43 GMT</lastBuildDate>
        <atom:link href="https://blog.marciosobel.dev/feed" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[Astro vs. Nuxt: Which one should you use for your blog?]]></title>
            <description><![CDATA[If you're looking to start a blog, you will probably come across these two very popular options. In this post, I will discuss the pros and cons of each.]]></description>
            <link>https://blog.marciosobel.dev/astro-vs-nuxt</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/astro-vs-nuxt</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Wed, 17 Jun 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Hello! Over the past few days, I took a look at <a href="https://astro.build/">Astro</a>, a website framework whose main focus is content; that is, it was built with articles, documentation, and blogs in mind.<br />Its biggest benefit is achieved through minimal Javascript. This really caught my attention. I mentioned <a href="https://blog.marciosobel.dev/my-first-blog-post/">in my first post</a> that I had thought a lot about using Astro or <a href="https://gohugo.io/">Hugo</a> for my blog, but I ended up choosing <a href="https://nuxt.com/">Nuxt</a> because it is a framework made for building websites from scratch, which would give me more flexibility to shape the site to fit my style.<br />However, I decided to test Astro and see what it would be like for me. Who knows, maybe I'll use it instead of Nuxt on this blog!<h2>Why Astro?</h2>Right off the bat, what caught my attention the most about Astro was its focus on static content. This means it wasn't made to have a lot of interactivity: buttons, requests, forms... It was made for things that change very little, like documentation, articles, landing pages, and blogs.<br />It has first-level support for Markdown, the language I use to write my posts. Also, it avoids sending Javascript code to the user as much as possible; this means the sites are always super lightweight.<br />Well, I decided to test Astro because I had a nagging doubt regarding <code>Nuxt</code>: it carries <code>Vue</code>'s Javascript runtime along with it. Even though it's not that big of a deal, I wanted my blog to be as simple and lightweight as possible. And so my journey began!<h2>Recreating my blog with Astro</h2>Let's go, first let's see what I want to achieve here.<ul><li>Write my posts in Markdown and not worry about how they end up on the site; I just want to write, upload to the cloud, and Astro's build should update the listing and generate the links accordingly;</li><li>Have the site in two or more languages.</li></ul><br />Yeah, the blog is pretty simple; but, I believe that with these requirements, it will be enough to get my hands dirty with the framework.<h3>Starting the project</h3>This is the easiest and most straightforward part of this whole journey. I only needed to run:
<pre class="code "><code>pnpm create astro@latest</code></pre>
And follow the step-by-step instructions from the cute little robot.<br />The architecture is very simple, file-based routing... Everything is super intuitive. I didn't use any template, so for me, there was only an <code>index.astro</code>, with a completely blank screen, just with an <code>h1</code> reading "Astro".<br />Well, let's start checking some items off the list.<h3>Listing all posts</h3>I started by creating a <code>posts/</code> folder and put the blog posts in it. Since Astro was already made with handling posts in mind, it was very easy. You just need to create a <code>content.config.ts</code> file with the following code:
<pre class="code typescript"><code class="language-typescript">const blog = defineCollection({
  loader: glob({ base: &quot;posts&quot;, pattern: &quot;**/*.{md,mdx}&quot; }),
});

export const collections = { blog };</code></pre>
That was very easy. I used <code>zod</code> to create a schema for the frontmatter, the metadata, of the posts.<br />Then, in the <code>index.astro</code> file, the website's entrypoint, I placed the following:<h2>```astro</h2>import { getCollection } from "astro:content";
const posts = await getCollection("blog");<h2>if (!posts) return Astro.redirect("/404");</h2><h1>Blog</h1>
<ul>
  {posts.map((post) => (<pre class="code poetry"><code>&lt;li&gt;
  &lt;a href={post.id}&gt;{post.data.title}&lt;/a&gt;
&lt;/li&gt;</code></pre>  ))}
</ul>
<pre class="code "><code>Andddd that worked? That's too easy!

In Astro, any code executed inside the &quot;fences&quot; (`---`) runs only at build time. This means our application so far has a grand total of zero Javascript!
### Generating pages dynamically
After creating the post listing page, I wanted to create a page for each post. For this, I needed a dynamic route, meaning I would need Astro to generate the pages for me.

I would like to take this moment to say that Astro's documentation is very good! It would definitely be a lot more work to do this without it.

Anyway, I created a `[slug].astro` file. This file accepts any value as input, and I can use this value via code.
```astro
---
const { slug } = Astro.params;
---
&lt;p&gt;Slug: {slug}&lt;/p&gt;</code></pre>
Then I used this to get a post's ID. Fortunately, Astro already has a specific function to get an item from a collection: <code>getEntry</code>. It receives the collection and the ID to search for. After that, I needed to know how to show the Markdown content in HTML. Then I stumbled upon the <code>render</code> function, how useful!<h2>```astro</h2>import { getEntry, render } from "astro:content";
const { slug } = Astro.params;
const post = await getEntry("blog", slug);
if (!post) return Astro.redirect("/404");<h2>const { Content } = await render(post);</h2><Content />
<pre class="code "><code>And in theory, it was supposed to work super well... But Astro cannot know all the possible routes for `[slug].astro`, which prevented it from keeping the site clean of Javascript. To circumvent this, we have to tell Astro all the possible routes. We do this by exporting a `getStaticPaths` function, which fortunately can be async, where we return a list with all the completed variables. We can also pass props to each page, which means we can pass all the posts directly!
```astro
---
import { getCollection, render } from &quot;astro:content&quot;; // we now fetch the whole collection!

export async function getStaticPaths() {
  const posts = await getCollection(&quot;blog&quot;);
  return posts.map((post) =&gt; ({
    params: { slug: post.id },
    props: { post }, // we can pass the post directly to the page!
  }));
}

const { post } = Astro.props; // and the post is guaranteed to exist!
const { Content } = await render(post);
---
&lt;Content /&gt;</code></pre>
Okay! That was pretty easy.<br />Testing the different posts, I noticed that one of them was rendering accents incorrectly. For example, instead of the word <em>água</em> (which means "water"), the rendered HTML returned <em>Ã¡gua</em>. I was confused about the reason, and apparently Astro no longer defines the document's charset as UTF-8 by default. I was quite confused because <a href="https://docs.astro.build/en/guides/markdown-content/#frontmatter-layout-property">I only saw this mentioned in one place in the docs</a>? But that's fine, I lost a bit of time on this part.<h3>Dealing with different languages</h3>In case you've never noticed, this blog is available in both Brazilian Portuguese and English. As of the writing of this post, all posts are available in both languages. I don't know if at some point they will diverge and have different content.<br />Anyway, having multiple languages is necessary. Like the good programmer that I am™, I wanted to keep it dynamic enough to have the least amount of headache possible if I want to write in some other language. First, I changed the <code>content.config.ts</code> file to have the posts separated:
<pre class="code typescript"><code class="language-typescript">function createCollection(suffix: string) {
  return defineCollection({
    loader: glob({ base: `posts/${suffix}`, pattern: &quot;**/*.{md,mdx}&quot; });
  });
}

export const collections = {
  &quot;blog-en&quot;: createCollection(&quot;en&quot;),
  &quot;blog-pt&quot;: createCollection(&quot;pt&quot;),
};</code></pre>
And then I created an <code>i18n.ts</code> file with the following code:
<pre class="code typescript"><code class="language-typescript">const entries = {
  en: {
    &quot;all-posts&quot;: &quot;All posts&quot;,
  },
  pt: {
    &quot;all-posts&quot;: &quot;Todos os posts&quot;,
  },
};

export type Locales = keyof typeof entries;
export const locales = Object.keys(entries) as Locale[];
export const defaultLocale: Locale = &quot;en&quot; as const;

import { getCollection as getContentCollection } from &quot;astro:content&quot;;

export function getCollection(locale: Locale = defaultLocale) {
	return getContentCollection(`blog-${locale}`);
}</code></pre>
The page architecture looked like this:
<pre class="code "><code>src/
├── content.config.ts
├── i18n.ts
├── pages/
│   ├── [lang]/
│   │   ├── [slug].astro
│   │   └── index.astro
│   ├── [slug].astro
└── └── index.astro</code></pre>
And everywhere I needed the selected language, I just put <code>const { lang = defaultLocale } = Astro.params;</code>.<br />From then on, everything worked perfectly fine. I created a component that adds the language suffix to the URL, and that way I could switch languages. Everything worked perfectly and, so far, zero JavaScript!<h2>Where things started to go downhill...</h2>In Astro, Markdown is rendered into HTML. The rendering is very basic: links become <code>&lt;a&gt;</code>, headings become <code>&lt;h1&gt;</code>, <code>&lt;h2&gt;</code>... Everything normal. It turns out that I wanted a small customization: if you want to test it in this post, every title is clickable. I left it like this because, in case someone wants to share just a specific topic of the post, it is possible. To do this, I created a <code>Prose</code> component in Nuxt, which allows me to <em>override</em> the tags generated by Markdown.<br />In Astro, however, this is not possible. Not in a simple way. I had two choices:<ol><li>Use <code>MDX</code> to write the posts instead of markdown and call the components as needed, or;</li><li>Use a rehype plugin to alter the tags at rendering time.</li></ol><br />Since I'm not really a big fan of <code>mdx</code>, I went with the second option. It turns out that this generated very ugly code, barely functional (it bugged a lot), and that I wouldn't understand a few days later. But, that's fine, I did it anyway.<br />And voilà, after adding the css, I had an exact replica of my blog, 100% functional.<h2>Verdict and comparison</h2>Well, the entire blog didn't remain immune to JavaScript. It's possible to search for posts and there is a way to toggle between light and dark themes. I built the site and wanted to see how heavy it was.<br /><blockquote>The metrics are in the format <code>&lt;compressed_size&gt;/&lt;uncompressed_size&gt;</code>. The site will always be downloaded compressed and is uncompressed locally. You can access the reference post <a href="https://blog.marciosobel.dev/switching-to-nixos/">here</a>. All caches were disabled in the measurements.</blockquote><br />My blog, with <code>Nuxt</code>, the listing of all posts uses <strong>228 kB / 569 kB</strong>. Accessing a post uses <strong>351 kB / 657 kB</strong>.<br />The replica, with <code>Astro</code>, on the listing screen, uses <strong>164 kB / 166 kB</strong>. Accessing a post uses <strong>257 kB / 260 kB</strong>.<br />It is noticeable that Astro uses 28% less network than Nuxt in the listing, and 27% less when viewing a post, with its biggest difference being in the uncompressed data, possessing a difference of 71% in the listing and 60% when viewing a post!<h2>Conclusion: which framework am I staying with?</h2>The difference in the final bundle is certainly notable. Astro delivers a much lighter site, containing only the content you choose to deliver. But, despite this, I decided to stick with Nuxt. Here is why: I like to tweak things back and forth. I found Astro for this use case of mine to be not very flexible, especially in the part of modifying the markdown output. And, although it is much lighter, it is only in the uncompressed content; on the network side, the difference isn't that shocking. Today's phones and computers barely break a sweat to compensate for this difference. So I accept making this sacrifice in exchange for a better DX.<br />Nonetheless, Astro definitely won me over with its charm and simplicity. I will certainly use it to generate documentation for possible libraries of mine in the future. I didn't get to explore its full potential and, if I were starting from scratch, I would probably pick a template and build from there.<br />That was my review of Astro, I hope you had a good read. Until next time!]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Why I switched to NixOS (And why you should, too)]]></title>
            <description><![CDATA[Recently, I've switched to NixOS, making all my system declarative. In this post, I'll explain the pros, the cons, and if switching might be a good option for you.]]></description>
            <link>https://blog.marciosobel.dev/switching-to-nixos</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/switching-to-nixos</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Sat, 28 Mar 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Hello! Recently, I've switched to <a href="https://nixos.org">NixOS</a>, and <em>oh boy</em> it was one of the best things I've done. My system has never been so stable, while so freeing at the same time. I also have a lot more control over it: what's installed, where each config is, enabled services, daemons and so on. The <code>nixpkgs</code> repository is <strong><em>huge.<strong><em> And I do mean it: <a href="https://repology.org/repositories/graphs">it's bigger than the AUR</em></strong></em></strong></a>!<br />I will dive in why is it good, it's cons, and whether or not you should use it.
First, i'll talk about what even <em>is</em> NixOS and how does it stand out from other Linux distros.<h2>What is Nix?</h2>Before talking about NixOS, let me introduce you to <code>nix</code>. <code>nix</code> is a <em>functional package manager</em>. This means that it treats packages like values in a purely functional programming language (like Haskell). The packages aren't installed where you would expect (like <code>/usr/bin</code>); instead, they are installed in <code>/nix/store</code>. And each package has its own unique subdirectory. Take Firefox for example:
<pre class="code "><code>/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/</code></pre>
This hash (<code>b6gvzjyb...</code>) is the unique identifier that will capture all the dependencies of this package. Thanks to the hashing, you are allowed to have multiple versions of the same package <em>at the same time,</em> without having to deal with dependencies conflicting or breaking.<br />Also, due to the unique identifier, <code>nix</code> is able to remove unused packages using a <em>garbage collector</em>. This means your system always have only what you want!<h2>What is NixOS?</h2>NixOS takes the <code>nix</code> package manager to the fullest, applying it's philosophy to a whole operating system. This means your kernel, drivers, monitor resolution, apps and configuration are all described in a functional, declarative manner.<br />The system does not follow the <a href="https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html">FHS standards</a>, meaning there is no <code>/bin</code>, <code>/lib</code> or <code>/usr</code>. Everything it contains is in the nix store.<br />The system configuration can be found at <code>/etc/nixos/</code>, where you'll find two files:<ul><li><code>hardware-configuration.nix</code>: Auto-generated by the operating system. You will probably never have to touch here (at least I hope so!)</li><li><code>configuration.nix</code>: Where your system configuration actually lives. Here's where you tell nix what packages should be installed, what services or daemons should be running, what desktop environment it should use, etc.</li></ul><br />Here's an example on how to install <code>git</code>:
<pre class="code nix"><code class="language-nix"># configuration.nix
{
    # ...
	environment.systemPackages = [pkgs.git];
}</code></pre>
...And that's it. If you ever want to uninstall it, you just have to remove the <code>pkgs.git</code> from the list. It's that simple!<br />But, saving the file won't install <code>git</code> by itself. This would be a nightmare. You have to <em>rebuild</em> your system. And I mean it literally. Running <code>nixos-rebuild</code> will rebuild your whole system, from the ground up, installing or uninstalling any package you added or removed from the configuration, stopping or starting services you've enabled, and so on.<br />This might be a bit worrying to you, but fear not! Thanks to the nix store, your system is fully backed up before you perform any rebuild. So if you ever, let's say, delete your video driver, you can just select your previous build from the boot manager. To rebuild your system, run:
<pre class="code "><code>nixos-rebuild switch</code></pre>
This will rebuild your system, and then change to it immediately (without needing to reboot your machine). You can also easily roll back to the previous configuration using the <code>--rollback</code> argument.<br />If you want to just see how your changes affect your system without creating a backup (almost like a "throaway" rebuild), you can simply run:
<pre class="code "><code>nixos-rebuild test</code></pre>
There are many other ways to rebuild your system, including building a VM, but I will not cover those here. Also, those two are probably the commands you'll run the most, anyway.<br />Well, that's a simple explanation of how <code>nix</code> and NixOS works. You will probably want to dive deeper, and for that I can't recommend <a href="https://www.youtube.com/@vimjoyer">Vimjoyer's channel</a> enough. There, you'll find more about the <code>nix</code> language, how to create modules, how to organize them and everything.<h2>Should you migrate to NixOS?</h2><h3>Pros</h3>First, let me funnel down to who I think NixOS suits best:<h4>Developers</h4>NixOS gives you such an amazing DX. It supports isolated, reproducible development environments, meaning that the argument "it works on my machine" actually means it works. You can think of this as Docker containers, but better! Also, you can use NixOS to declare a server structure, meaning that if you ever change architecture (maybe by switching hosts), you can have all your hosting settings and services up in seconds by copying the old machine <code>configuration.nix</code> file!<h4>Enthusiasts</h4>If you enjoy exploring stuff in tech, such as ricing, creating your own configs, or just tickling around in general, NixOS is a great fit! It's familiar enough to make you feel comfortable, while being different enough to keep things interesting and fun to mess with.<h3>Cons</h3>Now, I think NixOS is <strong>not</strong> a good option for you if you:<h4>Just want things to work fast</h4>If you just want to download VSCode and want it to work, or if you only use a browser, or even if you find that setting Neovim by yourself "too much work", then I think NixOS is not for you. Setting up NixOS is tedious and takes time. While you can just copy someone else's file to have a solid starting point, I believe that not making the system suit your own needs is not only a waste of it's potential and will only be a frustating experience if you ever want to change something.<h4>Are new to Linux</h4>If you're new to the Linux world, I think NixOS is too much to take. Go explore Ubuntu, Mint, or even Fedora. Then you can dive down into Arch, Void or NixOS. Get a feeling of how Linux works, how it's built to then be able to see how lower-level systems bends it to get the most out of it.<h2>Conclusion</h2>That's it! Maybe I'll make more posts sharing the stuff I find on the system. Meanwhile, you can find my current dotfiles <a href="https://github.com/marciosobel/dotfiles">here</a>. See you next time!]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Rust is the BEST programming language]]></title>
            <description><![CDATA[And I can prove it.]]></description>
            <link>https://blog.marciosobel.dev/rust-is-the-best-programming-language-ever</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/rust-is-the-best-programming-language-ever</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Mon, 19 Jan 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[You’re probably already tired of hearing that “Rust is safe”, “Rust is the most loved programming language in the world,” “Rust is the future.”<br />Even though these claims are based on solid foundations, very little is said about the <em>real</em> positive aspects of Rust. I’m going to list a few positive factors beyond the language’s safety, robustness, and speed.<h2>Clear Domain Modeling</h2>Rust allows you to model a domain in a clear and concise way. Enums with superpowers make it possible to define rules that, in other languages, would require much more boilerplate.<br />Let me give you an example:
<pre class="code rust"><code class="language-rust">enum DownloadStatus {
    Inactive,
    Processing { progress: u32 },
    Error(String)
    Done,
}</code></pre>
Here we have an enum that can give us metadata about a download. In other languages, you’d probably need to create a class with all the necessary metadata (which could be <code>null</code>), and then implement several <em>workarounds</em> to validate things correctly. With Rust, not only is it impossible for metadata to be <code>null</code>, but it’s also very easy to access it, with the guarantee that it’s always valid.<h2>Extremely Powerful Switch Statements</h2>In the programming universe, <code>switch</code> is used to check for equal values. In modern programming, the use of <code>match</code> has become more and more common: a new kind of <code>switch</code> that allows you to use patterns for validation.<br />Here’s an example of a <code>match</code> in Rust:
<pre class="code rust"><code class="language-rust">let value = 5;
match value {
    0..=10 =&gt; println!(&quot;Number is between 0 and 10!&quot;),
    11 | 13 | 17 | 19 =&gt; println!(&quot;Prime number!&quot;),
    n if n % 2 == 0 =&gt; println!(&quot;Even number!&quot;),
    n =&gt; println!(&quot;I don't know what to do with {n}&quot;),
}</code></pre>
It’s also possible to do <em>pattern matching</em> in an <code>if</code>. Using the previous <code>DownloadStatus</code> example:
<pre class="code rust"><code class="language-rust">let status = DownloadStatus::Error(&quot;Failed to download&quot;.into());
if let DownloadStatus::Error(error) = status {
    eprintln!(&quot;Download error: {}&quot;, error);
}</code></pre>
It may look like just more <em>boilerplate</em>, but <code>enum</code>s combined with this kind of <em>pattern matching</em> make the code much more robust and safe as the codebase grows!<h2>Explicit Mutability</h2>Another very positive aspect of Rust is its explicit mutability. Everything is immutable by default:
<pre class="code rust"><code class="language-rust">let x = 10;
x = x * 2; // Code fails here</code></pre>
The code fails because <code>x</code> is immutable. To make it mutable, we need to add the <code>mut</code> keyword:
<pre class="code rust"><code class="language-rust">let mut x = 10;
x = x * 2;</code></pre>
In this example, it doesn’t look like a big deal. But this becomes extremely useful when we’re talking about function arguments:
<pre class="code rust"><code class="language-rust">let mut myText = String::from(&quot;Hello, world&quot;);
printText(&myText);
changeText(&mut myText);</code></pre>
It’s immediately clear whether a function is going to mutate a variable or not. In C or Go, passing the address of a variable leaves its mutability up to the function’s implementation, forcing the developer to read the documentation or inspect the code.<h2>Macros!</h2>It’s possible to do <em>metaprogramming</em> in Rust — that is, code that writes Rust code. Macros in Rust are practically a whole new language, but the crates <a href="https://crates.io/crates/syn"><code>syn</code></a> and <a href="https://crates.io/crates/quote"><code>quote</code></a> make the process much more intuitive and fluid. I highly recommend watching <a href="https://youtu.be/SMCRQj9Hbx8">this video</a> to understand it better. I won’t go too deep into macros here, I could write an entire post just about them (maybe someday).<h2>Configuration in TOML</h2>I’ll admit it: I <em>love</em> <code>TOML</code>. More than <code>YAML</code>, and infinitely more than <code>JSON</code>. It’s a clear, minimal language, and you can read the entire <a href="https://toml.io/en/v1.1.0">spec</a> in about 15 minutes. Rust uses TOML to define versions, dependencies, features, formatter configuration... It’s great!<h2>Not everything is sunshine and rainbows</h2>Of course, Rust isn’t perfect. Especially at the beginning, when you have to fight against your own habits to program in Rust. It has several DX issues, like verbosity, long compile times (even in debug), and don’t even get me started on lifetimes. I won't be covering the bads here, only the pros. Perhaps I could make a evil version of this post only talking about the bad side of Rust.<h2>Conclusion</h2>Rust has great fundamentals, a wonderful macro system, and <code>cargo</code> rocks. It’s definitely a modern, robust, fast, and safe language. Winning the title of the most loved programming language in the world for several consecutive years is no surprise. I hope I managed to clearly cover some of the aspects of the language that I like the most, beyond the obvious points from many other posts on the internet (safety, <em>blazingly fast</em>, etc.).<br />If you’re starting to use Rust in a project, remember to make it very clear that you use it — just like an Arch user (btw). The cult must grow. 🦀]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[My first blog post]]></title>
            <description><![CDATA[Welcome to my blog!]]></description>
            <link>https://blog.marciosobel.dev/my-first-blog-post</link>
            <guid isPermaLink="true">https://blog.marciosobel.dev/my-first-blog-post</guid>
            <dc:creator><![CDATA[Márcio Sobel]]></dc:creator>
            <pubDate>Sun, 11 Jan 2026 00:00:00 GMT</pubDate>
            <content:encoded><![CDATA[Hello, welcome to my blog. I'm still starting, so my writting skills won't be that high lol. Although, I'm happy to finally have my own place to post my silly stuff.<br />As for a first post, I've tried to come up with a cool topic to stick to, but it would only make me get stuck on an infinite loop of ideas, so I will start with...<h2>How did I make this blog</h2>The first challenge was <em>how to write.</em> I've ended up sticking with markdown, since I'm already familiar with it's syntax.<br />Next step was picking <em>were to write</em>. There's lots of options (I thought a lot about using Astro or Hugo), but, since I wanted to have more control on the site itself, I've chosen Nuxt.<br />Nuxt allows me to not only have control over the site appearence, but this <a href="https://content.nuxt.com/">amazing module</a> let me place all of my posts in one directory as well, exatcly what I wanted!<br />Another really good thing Nuxt allows me to do is group my posts by language. I want to create posts in english and portuguese (depending on my will power).<br />Also, I remembered that I use Linux (Arch, btw.) and I've created a symlink in my Obsidian vault to the posts directory. This means I can write my posts directly on it!<br />Well, creating the blog in itself was quite simple, turns out that what was blocking me to create one was only... myself. Now I only need to decide...<h2>What am I gonna do over here?</h2>A blog is not like Twitter (currently X), Bluesky, Threads or any other social media where people post updates; it's a unique, personal corner that does not have any algorithms or content restrictions.<br />I've always had those moments where I see something cool, or I make something that I think it's cool, that I end up keeping to myself, because I have really extensive tastes that sometimes does not overlap with my social circle. So writting a blog would be a place where I can just yap about anything, put it in a box and let it be. Maybe someone likes it!]]></content:encoded>
        </item>
    </channel>
</rss>