Forem: Das

Querying Your Test Results with OpenSearch MCP

Das — Sat, 11 Apr 2026 16:23:45 +0000

Ask your OpenSearch data questions in plain English using any MCP-compatible AI assistant.

This works with any test framework — Robot Framework is used here because that is where the data already lives.

Introduction

In the previous part of this series, every Robot Framework test result was streamed into OpenSearch the moment it completed — failures visible in a live dashboard without waiting for the suite to finish.

That part solved visibility. This part solves what happens after the run ends.

Every result is already in OpenSearch: test name, suite, status, failure message, tags, duration, run ID. The data is there. The question is how to use it efficiently. Building filters in Dashboards and writing DQL queries in Discover works, but it is slow and it breaks focus at exactly the moment you need to act.

Model Context Protocol (MCP) is an open standard that lets AI assistants connect directly to external data sources. OpenSearch has an official MCP server. Connect it to any MCP-compatible AI assistant — Claude, Copilot, or others — and your test data becomes queryable in plain English, from wherever you are already working.

The Problem

After a long CI run, the questions are always the same. Which tests failed? Have they failed before? Do they share a tag or a suite? What does the error mean? Is this a test bug or an application bug?

Answering those manually means switching tools: open Dashboards, build a filter, switch to Discover for the full message, run another query for the historical view. Each step is small. Across a team running multiple pipelines a day, it adds up — and context evaporates while it is happening.

MCP removes those steps. The AI assistant queries the index directly. You ask in plain English, you get an answer, you stay in the editor.

What is MCP?

Model Context Protocol is an open standard, originally developed by Anthropic and now widely adopted, for connecting AI assistants to external tools and data sources. Instead of the assistant working from what you paste into a conversation, it calls out to your systems and works from live data.

OpenSearch published an official MCP server: opensearch-mcp-server-py. Register it with any MCP-compatible AI assistant and it can query any OpenSearch index directly — no custom integration code, no middleware.

Note: The examples below use Claude Code. Any MCP-compatible assistant follows the same registration pattern.

Architecture

┌─────────────────────────────────┐
│     Robot Framework (local)     │
│     tests run as normal         │
└──────────────┬──────────────────┘
               │  end_test fires after each test
               ▼
┌─────────────────────────────────┐
│     opensearch_listener.py      │
│     indexes result immediately  │
└──────────────┬──────────────────┘
               │
               ▼
┌─────────────────────────────────┐
│     OpenSearch  (Docker)        │
│     port 9200                   │
│     index: robot-results        │
└──────────┬──────────────────────┘
           │
     ┌─────┴──────────┐
     │                │
     ▼                ▼
┌──────────┐    ┌─────────────────┐
│Dashboard │    │   MCP Server    │
│port 5601 │    │   (local proc)  │
│live view │    └────────┬────────┘
└──────────┘             │
                         ▼
                ┌─────────────────┐
                │  MCP-compatible │
                │  AI assistant   │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │  plain English  │
                │  queries + fixes│
                └─────────────────┘

The dashboard and MCP paths run on the same OpenSearch instance. The dashboard stays useful for live monitoring during a run. MCP is the interface for investigation and action after the run.

Tech Stack

Robot Framework — test framework with a listener API for hooking into execution
OpenSearch — stores every test result as it happens (from part one)
opensearch-mcp-server-py — official OpenSearch MCP server, published by the OpenSearch project
Claude Code — MCP-compatible AI assistant used in this setup (any MCP-compatible assistant works)
Python — ties it all together

Step by Step

Prerequisites

Everything from part one is in place: OpenSearch running in Docker, the listener shipping results, the robot-results index populated. Verify OpenSearch is healthy before continuing:

curl http://localhost:9200

A JSON response means it is ready. If OpenSearch is down when the MCP server registers, it will appear connected but return errors on every query.

1. The MCP Server Package

opensearch-mcp-server-py is already in requirements.txt and was installed in part one. Nothing new to install.

Security note: Only add MCP servers from trusted sources. This package is the official OpenSearch MCP server, maintained by the OpenSearch project.

2. Environment Variables

The MCP server reads connection details from environment variables. Create a .env file in the project root (already in .gitignore):

OPENSEARCH_URL=http://localhost:9200
OPENSEARCH_NO_AUTH=true

OPENSEARCH_NO_AUTH=true is for local development only. Never use it on a shared or production instance.

3. Register with Claude Code

claude mcp add opensearch \
  -e OPENSEARCH_URL=http://localhost:9200 \
  -e OPENSEARCH_NO_AUTH=true \
  -- uv run --project /path/to/results-execution-monitoring python -m mcp_server_opensearch

Verify:

claude mcp list

You should see:

opensearch: ... ✓ Connected

4. Permanent Config for CLI and VS Code

The registration above is session-scoped. To persist it across sessions — and have it work in both the Claude Code CLI and the VS Code extension — add it to ~/.claude/settings.json:

{
  "mcpServers": {
    "opensearch": {
      "command": "uv",
      "args": [
        "run",
        "--project",
        "/path/to/results-execution-monitoring",
        "python",
        "-m",
        "mcp_server_opensearch"
      ],
      "env": {
        "OPENSEARCH_URL": "http://localhost:9200",
        "OPENSEARCH_NO_AUTH": "true"
      }
    }
  }
}

After saving, reload VS Code (Ctrl+Shift+P → Developer: Reload Window). Run claude mcp list to confirm.

Querying Results in Practice

Once connected, the assistant queries robot-results directly.

Isolating a specific run

Every document in a run carries the same run_id, which is printed at the start of each run:

What tests failed in run 88b407bf?

The assistant returns test names, suite names, failure messages, and elapsed times as a readable summary — not raw JSON.

In CI, pass the build number as the run_id so results are traceable to a specific pipeline build:

python -m robot \
  --listener opensearch_listener.OpenSearchListener:url=http://localhost:9200:run_id=${BUILD_NUMBER} \
  tests/

Then:

What failed in build 42?

Understanding failure patterns over time

A single failure is a data point. The same test failing across five runs over a week is a problem that needs a decision — is it a flaky test, a broken feature, or an environmental issue?

Show me all failed tests from the last 7 days

This tells you immediately whether today's failures are new or recurring. A test that first appeared today is a different priority from one that has been failing silently for a week.

Triage by tag

Not all failures carry the same weight. Tests tagged smoke are meant to catch the most critical issues fastest. Knowing whether failing tests are smoke tests or deep regression tests changes how urgently you respond.

Show me failures with the smoke tag from the last 3 days

Acting on failures — in the same conversation

Once the assistant has the failure list, the conversation continues without switching context. The failure message, test name, suite, and tags are all in the indexed document. The error is already in scope.

The Division By Zero Fails test is failing with ZeroDivisionError.
What should the Robot Framework keyword look like to handle that safely?

Which of these failures look like test bugs vs application bugs?

Generate a test case that correctly validates that dividing by zero raises an exception.

The path from "what failed" to "here is the fix" happens in one conversation, without copy-pasting anything.

Result

Before MCP: run finishes → open Dashboards → filter by run → open Discover for error messages → cross-reference previous runs manually → copy error into a chat → figure out the fix → switch back to editor.

With MCP: run finishes → ask what failed → ask if it has happened before → ask what the fix looks like → fix it.

The time between "run finished" and "I know what to do" is shorter. Not because the failures changed, but because the path from data to action is direct.

Conclusion

The listener from part one moved test result availability from the end of the run to the moment each test completes. This part moves analysis from dashboards and query consoles to plain English, in the tool you are already using.

The approach is not specific to Robot Framework or Claude. Any test framework with a hook system can stream results to OpenSearch using the same listener pattern. Any MCP-compatible AI assistant can be registered against the same MCP server. The infrastructure stays the same regardless of what is being tested or which assistant is being used.

Store results as they happen. Query them in plain English. Act on what you find.

Resources

GitHub — github.com/007bsd/results-execution-monitoring
Model Context Protocol — modelcontextprotocol.io
Introducing MCP in OpenSearch — opensearch.org/blog/introducing-mcp-in-opensearch
opensearch-mcp-server-py — github.com/opensearch-project/opensearch-mcp-server-py
Part one — Real-Time Test Results in Robot Framework

The complete code is in the GitHub repo. If anything in the MCP setup behaves differently, leave a comment.

Real-Time Test Results in Robot Framework

Das — Sat, 21 Mar 2026 20:44:19 +0000

No more waiting for the suite to finish to find out what failed.

Introduction

In a previous organisation, a proof of concept was built to stream Robot Framework test results into a live monitoring dashboard using the ELK stack (Elasticsearch, Logstash, and Kibana). The idea was simple: instead of waiting for the full run to complete and then reading the output report, results would appear in a dashboard the moment each test finished.

The problem with ELK is that it is no longer fully open source. Elastic changed its licensing in 2021. OpenSearch is the community fork that stayed open. This project is a rebuild of that original setup using OpenSearch, with the same goal: live test visibility while the suite is still running.

The approach works with any test framework that exposes hooks into the test lifecycle. Robot Framework is used here because that is where the original work was done, but the same pattern applies to pytest, Selenium, and others.

The Problem

When a test suite runs, results are only written to output.xml when the entire run completes. For short suites this is fine. For longer ones it creates a gap.

During the run, the only signal is whatever the terminal prints. A failure shows up as FAIL with a short message, but by the time the run finishes and the report is available, the context around that failure is gone. Was it a transient error? A timeout that only happens under load? Something that affected multiple tests in the same suite? There is no way to know without digging through logs after the fact.

What would actually help is seeing each result as it happens, with the full message, the test name, the suite, and the duration, in a searchable dashboard that stays available after the run.

Tech Stack

Robot Framework - test framework with a listener API for hooking into test execution
OpenSearch - open-source search and analytics engine for storing results
OpenSearch Dashboards - visualisation layer for building live dashboards
Docker - runs OpenSearch and the dashboard in containers
Python - the listener that ships results to OpenSearch

Architecture

+-------------------------------+
|  Robot Framework (local)      |
|  listener fires after each    |
|  test and ships the result    |
+---------------+---------------+
                |
                v
+---------------+---------------+        +---------------------------+
|  OpenSearch (Docker)          | -----> |  OpenSearch Dashboards    |
|  port 9200                    |        |  port 5601                |
+-------------------------------+        +---------------------------+

Robot Framework and tests run locally as usual. Docker handles OpenSearch and the dashboard without any manual installation needed.

Step by Step

Prerequisites

1. How the Listener Works

Robot Framework exposes a listener API, a Python class it calls at specific points during execution. The hook used here is end_test, which fires immediately after each test completes, before the next one starts.

class OpenSearchListener:
    ROBOT_LISTENER_API_VERSION = 2

    def end_test(self, name, attrs):
        doc = {
            "run_id": self.run_id,
            "suite": self.suite_name,
            "test": name,
            "status": attrs["status"],
            "message": attrs["message"],
            "tags": list(attrs["tags"]),
            "start_time": ...,
            "elapsed_seconds": attrs["elapsedtime"] / 1000,
            "indexed_at": datetime.utcnow().isoformat() + "Z",
        }
        self.client.index(index=self.index, body=doc)

Each test result is indexed into OpenSearch straight away. The document is in the index before the next test has started.

Each document looks like this:

{
  "run_id": "a3f2c1...",
  "suite": "Tests.Login",
  "test": "Valid credentials should log in",
  "status": "FAIL",
  "message": "Element not found: #submit-btn",
  "tags": ["smoke", "auth"],
  "start_time": "2026-03-21T12:20:35.701Z",
  "elapsed_seconds": 3.001
}

The run_id field is generated once per test run, which makes it straightforward to filter the dashboard to a specific run or compare runs over time.

2. Setup

Clone the repo and install dependencies:

git clone https://github.com/007bsd/results-execution-monitoring
cd results-execution-monitoring
pip install -r requirements.txt

Start OpenSearch and the dashboard:

docker compose up -d

Note: The first run downloads around 1 GB of images. Once containers are up, confirm OpenSearch is ready with curl http://localhost:9200. A JSON response means it is running.

Run the setup script once to create the index pattern and a starter dashboard:

python setup_dashboard.py

This is meant to get things running quickly. The dashboard it creates is a starting point, not the final word. See the section below on building dashboards manually.

3. Running Tests with the Listener

python -m robot --listener opensearch_listener.OpenSearchListener tests/

The listener confirms it has started and prints the run_id and index name:

As the run progresses, each result is confirmed in the terminal:

Open http://localhost:5601 before or during the run to watch results appear in real time.

4. Verifying Data in OpenSearch

To confirm results are being indexed correctly, the Dev Tools console at http://localhost:5601/app/dev_tools#/console can be used to query the index directly:

GET robot-results/_mapping

GET robot-results/_search
{
  "size": 1
}

5. Exploring Results in Discover

OpenSearch Dashboards has a Discover view that lets you search and filter all indexed documents. It is useful for digging into specific failures, filtering by tag, run, or suite, and understanding patterns across multiple runs.

6. Building Dashboards Manually

The setup script creates a starter dashboard to get things going, but most people will want to build their own visualisations on top of the data. OpenSearch Dashboards has a full visual editor for this, no configuration files or scripts required.

To create a visualisation:

Go to http://localhost:5601 and open Visualize from the menu
Click Create visualization and choose a chart type
Select robot-results as the index
Configure the metric (e.g. Count) and bucket (e.g. Terms on status) to get a pass/fail breakdown
Save the visualisation with a name

To build a dashboard from those visualisations:

Open Dashboard from the menu
Click Create new dashboard
Click Add from library and select the saved visualisations
Arrange the panels, set a title, and save

Some useful combinations to start with:

Pie or donut chart of status for an overall pass/fail ratio
Data table of recent failures showing test, suite, and message
Bar chart of elapsed_seconds by test name to spot slow tests
A metric panel showing total fail count for the current run
Filter by run_id to isolate and compare specific runs

Result

Once the stack is running, every test result appears in the dashboard the moment it is indexed. Failures are immediately visible with the full message, test name, suite, and duration, without waiting for the suite to complete.

Conclusion

The standard approach to test reporting is batch: everything is available when the run finishes, and not before. For short suites this is acceptable. For longer ones it is a genuine visibility problem.

Streaming results to OpenSearch as each test completes inverts that. Results are available immediately, failures are visible in context, and the history of every run is retained and searchable without any extra work.

The listener pattern used here is Robot Framework-specific, but the underlying idea applies to any test framework with a comparable hook system.

Resources

GitHub - github.com/007bsd/results-execution-monitoring
Robot Framework Listener API - robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#listener-interface
OpenSearch Documentation - opensearch.org/docs/latest
OpenSearch Dashboards - opensearch.org/docs/latest/dashboards
Docker - docs.docker.com

If you try setting this up and encounter any issues, please leave a comment. The complete code for this project is available on GitHub

Real-Time Data Monitoring Using InfluxDB and Grafana

Das — Sat, 14 Mar 2026 11:51:04 +0000

A practical guide to building a live monitoring dashboard for any data source.

Introduction

In a previous organisation, I built and maintained several internal monitoring dashboards. The idea came from patterns I had seen in engineering blogs about observability systems, and I experimented internally with a similar setup to bring different metrics into a single real-time view. The architecture behind those dashboards was straightforward and reusable.

This project is a recreation of that setup using publicly available APIs, tracking weather across two cities, commodity prices, and exchange rates EUR->INR as a working example. It continuously collects data, stores it in a time-series database, and visualises it in a live Grafana dashboard. It is a starting point for anyone who wants to experiment with real-time data or build similar dashboards for their own projects.

Organisations and individuals often have access to data from multiple sources that updates continuously. The challenge is not finding the data. Most of it is freely available. The challenge is aggregating it into a single, live view that is easy to read and act on.

Without a proper pipeline, data either gets checked manually, sits in spreadsheets, or simply goes unmonitored. A real-time dashboard solves this by automating the collection, storage, and visualisation in one place.

The same problem exists at different scales. Whether it is infrastructure monitoring inside a company, tracking external data feeds, or keeping an eye on any system that produces regular measurements, the approach is the same.

Tech Stack

InfluxDB — time-series database that stores all collected data
Grafana — visualisation layer that renders live dashboards
Docker — runs the entire stack in containers
Python — polling script that fetches data and writes to InfluxDB
Telegraf — alternative data collection agent by InfluxData

Note: This project uses a Python script for data collection, but Telegraf or any other tool that can write to InfluxDB works just as well.

Architecture

There are two separate flows in the project.

Live data flow

Data Sources (APIs)
        │
        ▼
   poller.py
   (runs every 15m)
        │
        ▼
     InfluxDB
     (storage)
        │
        ▼
     Grafana
        │
        ▼
     Browser

Dashboard setup flow

dashboard.yml
      │
      ▼
build_dashboard.py
      │
      ▼
dashboard.json
      │
      ▼
Grafana loads it automatically

The live data flow runs continuously in the background. The dashboard setup flow runs once locally, and again whenever the dashboard configuration is updated.

Note: The dashboard can also be created manually through the Grafana UI without using any configuration files or scripts. The code-based approach is used here to keep the setup version controlled and easy to modify.

Step by Step

Prerequisites

Before getting started, make sure the following are installed:

Docker Desktop — required to run the stack
Python — required to generate the dashboard configuration

Note: Docker is used here to demonstrate the full setup locally. InfluxDB and Grafana can also be installed directly on any machine or server without Docker if preferred.

1. Data Sources

Three publicly available APIs are used in this project, covering weather, commodity prices, and exchange rates. No API keys or signups are required.

Any API or data source that returns regularly updating values can be used here. The structure of the pipeline does not change regardless of what data is being collected.

2. Data Collection

The poller is a Python script that queries the APIs every fifteen minutes and writes the results directly to InfluxDB.

One concept worth understanding in InfluxDB before writing data:

Tags describe the data and are indexed for filtering. Examples: city name, source identifier, category.
Fields contain the actual numeric values that get stored and plotted.

Getting this distinction right makes querying and building dashboards significantly simpler.

3. Storage with InfluxDB

InfluxDB is a time-series database built for handling measurements that arrive continuously. Data is written as timestamped points, which makes it well suited for infrastructure metrics, sensor readings, financial feeds, or any other regularly updating values.

Each record written contains a measurement name, tags, numeric fields, and a timestamp.

To verify the connection is working, the Grafana Explore view can be used to query the bucket directly. A simple query returning the last hour of data confirms that the poller is writing successfully and Grafana can read it.

4. Visualisation with Grafana

Grafana reads from InfluxDB and renders the data as a live dashboard. It supports charts, stat panels, colour thresholds, gauges, and auto-refresh at configurable intervals.

It also connects to many other data sources including Prometheus, PostgreSQL, and others, making it flexible beyond just this stack.

One of the more useful features is the time range selector. The same dashboard can show data from the last 5 minutes all the way through to months of history, and the panels update instantly as the range changes.

Grafana also supports alerting. Alerts can be configured on any panel to trigger notifications when a value crosses a threshold — useful for staying on top of data without having to watch the dashboard continuously. Notifications can be sent to email, Slack, PagerDuty, and many other channels.

5. Dashboard as Code

Grafana dashboards are often created manually through the UI. That works for quick experiments, but the exported JSON becomes large and difficult to maintain over time.

In this project the dashboard is defined in a dashboard.yml configuration file. A script converts it into the JSON format Grafana expects, and Grafana loads it automatically on startup.

This keeps the dashboard fully version controlled. Adding a new panel is a matter of updating one line in the config file.

6. Running the Stack

The entire system starts with one command:

docker compose up -d

This launches three containers: InfluxDB, Grafana, and the poller. The dashboard is immediately available at localhost:3000. Pre-configured, pre-seeded, already collecting.

Result

Once the stack is running, the dashboard provides a continuously updating view of all collected data. It refreshes automatically, is colour-coded by thresholds, and is queryable over any time range.

The same setup can be pointed at any data source without changing the underlying infrastructure. The only part that changes is the polling script.

Conclusion

The pattern covered in this project: collect, store, visualize. It is a solid foundation for building active monitoring dashboards around any kind of live data.

The data collection piece is intentionally flexible. Telegraf works well for infrastructure and system metrics with minimal configuration. A custom script makes sense when working with external APIs that need specific handling. A cloud function or a scheduled job fits just as well depending on the environment.

What stays consistent is the rest of the stack. InfluxDB handles the time-series storage reliably regardless of where the data comes from. Grafana turns it into something usable, with the added ability to set up alerts and query across any time range without much overhead.

The same approach applies whether the goal is monitoring application performance, tracking external data feeds, or building visibility into any system that produces regular measurements.

Resources

GitHub — github.com/007bsd/live-monitor
InfluxDB Documentation — docs.influxdata.com
Grafana Documentation — grafana.com/docs
Grafana Alerting — grafana.com/docs/grafana/latest/alerting
Telegraf — influxdata.com/telegraf
Docker — docs.docker.com

If you try setting this up and encounter any issues, please leave a comment. The complete code for this project is available on GitHub.

Building a Fully Local LaTeX Thesis Workflow with VS Code and MiKTeX

Das — Sat, 14 Mar 2026 11:11:52 +0000

Why I Didn't Use Word

I tried writing in Word at first. It works fine for small documents, but once the thesis started growing, it became harder to manage. Formatting, figures, and updating the table of contents sometimes caused other sections to shift unexpectedly. Fixing small layout issues was taking more time than actual writing.

For a long academic document with references, numbered figures, and strict formatting requirements, I wanted something more structured.

Why I Didn't Use Overleaf Either

Overleaf is the go-to recommendation for LaTeX beginners, it runs in the browser, there's nothing to install, and it has a live PDF preview. For a quick document, it's fine.

But for a full thesis, it has real limitations:

For security reasons, you may not want your research or unpublished work stored on a public platform
The free tier has limits
Your data lives on their servers
You can't work offline

The alternative? Run everything locally. Your machine, your files, your Git repository. Free forever. Works offline. Private by default.

The Stack: LaTeX + MiKTeX + VS Code

LaTeX — the document preparation system. You write in plain text with markup, and LaTeX produces a perfectly formatted PDF
MiKTeX — a LaTeX distribution for Windows that manages all the packages you need, installing them automatically when required
VS Code — the code editor, used here as a LaTeX editor with the LaTeX Workshop extension
XeLaTeX — the compiler. Better than pdfLaTeX for modern fonts and Unicode
Biber — bibliography manager, works with BibTeX .bib files
Makeglossaries — handles abbreviation lists and acronyms
Python + Pygments — required for the minted package for syntax-highlighted code blocks

Step-by-Step Setup

Before you start: This guide covers Windows. The same tools exist for macOS and Linux with slightly different installation steps.

Step 1: Install MiKTeX

MiKTeX is the LaTeX engine. It comes with XeLaTeX, Biber, and Makeglossaries, and it will automatically download any missing LaTeX packages the first time you compile.

Go to miktex.org/download
Download the Windows installer and run it
Choose Install for all users if you have admin rights, otherwise install for yourself
After installation, open a terminal and verify:

xelatex --version
biber --version
makeglossaries --version

If anything is missing, MiKTeX's package manager can install them.

Step 2: Install Python and Pygments

The template uses the minted package for code syntax highlighting. Check if Python is already installed:

python --version
pygmentize -V

If not, download from python.org/downloads. Then install Pygments:

pip install pygments

Step 3: Install VS Code and Extensions

Download from code.visualstudio.com
Install and open VS Code
Search and install the LaTeX Workshop extension from the Extensions panel

Step 4: Clone the Template and Configure the Compiler

git clone https://github.com/007bsd/metropolia-thesis-latex.git
cd metropolia-thesis-latex
code .

Or download the ZIP from GitHub directly and open the folder in VS Code.

The project includes a .vscode/settings.json that already configures LaTeX Workshop to:

Use XeLaTeX as the compiler
Set main.tex as the root document
Auto-clean auxiliary files after building

Step 5: Compile Your First PDF

Open main.tex. Click the green ▶ Build LaTeX project button in the top right, or press Ctrl+Alt+B.

LaTeX Workshop will run the full compilation sequence:

xelatex -shell-escape -8bit main
biber main
makeglossaries main
xelatex -shell-escape -8bit main
xelatex -shell-escape -8bit main

The first compile may take a minute as MiKTeX downloads any missing packages. When it succeeds, main.pdf appears in the project root and opens automatically in the VS Code PDF preview panel.

Step 6: Start Writing

Open any file in the chapters/ folder and start editing. Every time you save (Ctrl+S), LaTeX Workshop auto-recompiles and the PDF updates in real time.

Project structure:

my-thesis/
├── main.tex          ← Master file
├── chapters/         ← One .tex file per chapter
├── biblio.bib        ← Bibliography
├── illustration/     ← Images and figures
├── code/             ← Code files for minted snippets
└── style/            ← Formatting rules

Tips From Actually Using This

Manage references with Zotero. Collect and organize references in Zotero, export directly as a .bib file into biblio.bib. Works seamlessly with Biber and saves a lot of manual formatting.

Keep your Git commits small. Commit chapter by chapter, not just at the end. You will want to roll back if you rewrite a section and change your mind.

Don't edit your style files. These contain the formatting rules. If you change them and something breaks, debugging is painful.

The Result

After compilation succeeds you have a properly formatted PDF — table of contents, numbered figures, bibliography, and acronym list all generated automatically. No style settings touched manually. No Word. No cloud.

Why This Matters Beyond the Thesis

For students in technical fields, getting used to LaTeX means getting comfortable with plain text and structured writing. That mindset helps beyond just thesis work.

The setup took me around 30–45 minutes. After that, it was just writing.

Resources

Template repository: github.com/007bsd/metropolia-thesis-latex
MiKTeX: miktex.org
VS Code: code.visualstudio.com
LaTeX Workshop extension: Search "LaTeX Workshop" in VS Code Extensions
Pygments: pip install pygments
Zotero: zotero.org

If you run into any issues setting this up, feel free to leave a comment — happy to help based on my experience.