refactor: update references from GitLab to GitHub

Author: niklastypes

README.md

@@ -1,7 +1,7 @@
-# niklasbaier.gitlab.io
+# Dev Blog
 
 Static personal website using [Hugo](https://gohugo.io/) and the [Blowfish](https://github.com/nunocoracao/blowfish) theme.
-Deployed via GitLab pages to https://niklasbaier.gitlab.io/.
+Deployed via GitHub pages to my custom domain https://niklastypes.xyz.
 
 ## Requirements
 
@@ -53,5 +53,5 @@ The respective `img/featured/*.svg` assets have been adapted as well:
 
 ## Comments
 
-Article comments are powered by [Giscus](https://giscus.app/), which uses GitHub Discussions (of the [`dev-blog-comments repo`](https://github.com/niklasbaier/dev-blog-comments)) as the backend.
+Article comments are powered by [Giscus](https://giscus.app/), which uses GitHub Discussions (of the [`dev-blog-comments repo`](https://github.com/niklastypes/dev-blog-comments)) as the backend.
 Comments are enabled globally via `article.showComments` in `config/_default/params.toml`, and the Giscus widget is configured in `layouts/partials/comments.html`.

config/_default/hugo.toml

@@ -3,7 +3,7 @@
 # https://blowfish.page/docs/getting-started/
 
 theme = "blowfish" # UNCOMMENT THIS LINE
-baseURL = "https://niklastypes.xyz/" # "https://niklasbaier.gitlab.io/"
+baseURL = "https://niklastypes.xyz/"
 defaultContentLanguage = "en"
 
 # pluralizeListTitles = "true" # hugo function useful for non-english languages, find out more in  https://gohugo.io/getting-started/configuration/#pluralizelisttitles

content/projects/momo/posts/v0.2.0-project-setup.md

@@ -52,7 +52,7 @@ Speaking of pre-commit hooks, I added the following set to get started:
   - `mdformat-gfm`: adds GitHub-flavored markdown support (e.g. tables, task lists, fenced code block syntax highlighting and much more)
   - `mdformat-black`: formats fenced Python code blocks using `black`
   - `mdformat-admon`: supports admonition syntax (e.g. `!!! note`)
-  - `mdformat-frontmatter`: ignores any frontmatter; as the Markdown files get published to my [Hugo](https://gohugo.io/)-based [dev blog](https://niklasbaier.gitlab.io/), they require a certain *frontmatter*, e.g. to properly set the title, author, date and tags which would otherwise get formatted and hence become unusable; as there were some version conflicts amongst the different `mdformat` pre-commit hooks, I had to manually pin the version and exclude the hook altogether from `pre-commit-update`
+  - `mdformat-frontmatter`: ignores any frontmatter; as the Markdown files get published to my [Hugo](https://gohugo.io/)-based [dev blog](https://niklastypes.xyz/), they require a certain *frontmatter*, e.g. to properly set the title, author, date and tags which would otherwise get formatted and hence become unusable; as there were some version conflicts amongst the different `mdformat` pre-commit hooks, I had to manually pin the version and exclude the hook altogether from `pre-commit-update`
 
 I have also specifically set the Python version to `3.13` for `mypy` and `ruff` to ensure consistent behavior with the overall project Python version.
 
@@ -79,7 +79,7 @@ That way, I will now only need to care about *which* changes I want to bundle in
 
 ## Custom `cz` & Verbose `CHANGELOG.md`
 
-Speaking of the `CHANGELOG.md` - for this project, it plays an *exceptionally* important role. As you may have read in the [previous post](https://niklasbaier.gitlab.io/projects/momo/posts/v0.1.0-building-momo/#documentation--self-reflection), I am planning on **letting Momo write her own blog entries as some sort of reflection on her own development from her point of view**.
+Speaking of the `CHANGELOG.md` - for this project, it plays an *exceptionally* important role. As you may have read in the [previous post](https://niklastypes.xyz/projects/momo/posts/v0.1.0-building-momo/#documentation--self-reflection), I am planning on **letting Momo write her own blog entries as some sort of reflection on her own development from her point of view**.
 
 For this, obviously, Momo needs appropriate **context**. To start out, I hence want to provide Momo the `CHANGELOG.md` diff (or maybe even the full file for evolutionary context) as well as the actual code changes of the current increment.
 
@@ -101,7 +101,7 @@ Thus, when writing these developer diary entries, I can always refer to the actu
 
 I could have been done here but I wanted to add just *one more thing*.
 
-Reading a bit into how software releases are being done by bigger companies, I wanted to have a system in place where **one button** (the manual `bump-version` job trigger button in the GitLab UI) not only increments the project version signifying a step forward in the whole undertaking, but also takes care of doing a proper release as well as publish the "release notes" (aka my rambling) to [my dev blog](https://niklasbaier.gitlab.io/).
+Reading a bit into how software releases are being done by bigger companies, I wanted to have a system in place where **one button** (the manual `bump-version` job trigger button in the GitLab UI) not only increments the project version signifying a step forward in the whole undertaking, but also takes care of doing a proper release as well as publish the "release notes" (aka my rambling) to [my dev blog](https://niklastypes.xyz/).
 
 Hence, I added yet another `publish` stage to my CICD configuration with a `publish-dev-diary-entry` job that does the following:
 

content/projects/momo/posts/v0.3.0-getting-chatty/index.md

@@ -8,7 +8,7 @@ authors:
   - niklas
 ---
 
-After all the setup work of the [previous post](https://niklasbaier.gitlab.io/projects/momo/posts/v0.2.0-project-setup/), it was finally time to get my hands dirty with the *actual* development - so let's jump right in!
+After all the setup work of the [previous post](https://niklastypes.xyz/projects/momo/posts/v0.2.0-project-setup/), it was finally time to get my hands dirty with the *actual* development - so let's jump right in!
 
 As **Momo will be utilizing a local LLM**, i.e. specifically *not* sending any API requests to model providers such as OpenAI, Google or Anthropic, I needed a way to easily download & invoke an open-source model. Luckily, [ollama](https://ollama.com/) provides a slim CLI client to do just that.
 
@@ -79,7 +79,7 @@ The big advantage of using a proper logger over Python's built-in printing capab
 
 My logging framework of choice is [`structlog`](https://www.structlog.org/en/stable/) as it is using `dict`s as structured data formats to output information and comes with a set of sensible defaults out of the box. For now, all I'm logging, though, is the `MomoConfig` when starting a chat session.
 
-As mentioned in [my first blog post on Momo](https://niklasbaier.gitlab.io/projects/momo/posts/v0.1.0-building-momo/#the-way-ahead), I'm having big plans on integrating various **graphical clients** to interact with Momo, such as Discord, and maybe even WhatsApp or a dedicated web app. However, **the CLI will always feel most natural to me** and "closest" to Momo.
+As mentioned in [my first blog post on Momo](https://niklastypes.xyz/projects/momo/posts/v0.1.0-building-momo/#the-way-ahead), I'm having big plans on integrating various **graphical clients** to interact with Momo, such as Discord, and maybe even WhatsApp or a dedicated web app. However, **the CLI will always feel most natural to me** and "closest" to Momo.
 
 Hence, I'm using [`typer`](https://typer.tiangolo.com/) as [the FastAPI of CLIs](https://typer.tiangolo.com/#fastapi-of-clis) to set up a **terminal-first entrypoint to interacting with Momo**. Wait, isn't Pydantic AI also [the FastAPI of GenAI app & agent development](https://ai.pydantic.dev/)? It's all connected!
 

data/authors/niklas.json

@@ -5,8 +5,7 @@
     "bio": "Hi! I'm Niklas. Nice to meet you!",
     "social": [
       { "email": "mailto:baiern@proton.me" },
-      { "github": "https://github.com/niklasbaier" },
-      { "gitlab": "https://gitlab.com/niklasbaier" },
+      { "github": "https://github.com/niklastypes" },
       { "linkedin": "https://www.linkedin.com/in/niklasbaier/" }
     ]
 }