Forem: Matthias Schäfer

Chat With Your Obsidian Notes: Introducing HTTP MCP Server

Matthias Schäfer — Sun, 28 Sep 2025 12:08:40 +0000

Introduction
Why Obsidian HTTP MCP?
How It Works
What Makes It Nerdy-Perks-Worthy
Examples of Cool AI Interactions
Setup
TL;DR

Introduction

If you’ve been following my Obsidian setup, you know I love keeping my notes synchronized across devices with Syncthing (My Obsidian + Syncthing Setup: A Self-Hosted Cloud for Notes, Backups, and More). But I wanted more than just syncing—I wanted to interact with my notes intelligently, anywhere, anytime.

Why Obsidian HTTP MCP?

That’s why I developed Obsidian HTTP MCP, a lightweight server built on FastMCP that exposes your Obsidian vault over HTTP using the MCP protocol.

With this server, you can:

Connect AI clients like Cursor directly to your vault, enabling natural-language search, analytics, and even automated note modifications.
Query your notes on demand from scripts, dashboards, or any device that can speak HTTP.
Keep it lightweight and fast thanks to the FastMCP foundation.

Essentially, your vault is no longer just storage—it becomes an interactive knowledge engine.

How It Works

Each note in your vault is treated as an MCP “packet.” The server exposes endpoints to read, update, or analyze these packets. Using HTTP transport keeps things simple, secure, and accessible behind standard firewalls.

The real fun comes with AI integration. You can ask your desktop AI assistant to summarize notes, find relevant information, or even generate content based on your vault—all by chatting naturally. It’s like giving your notes a brain of their own.

What Makes It Nerdy-Perks-Worthy

AI-powered workflows: Chat with your vault, analyze content, or modify notes programmatically.
Cross-device access: Talk to your vault from scripts, mobile apps, or web tools.
Minimal overhead: Stateless and efficient, perfect for lightweight setups.
Hackable: Build bots, dashboards, or automation around your notes.
Secure: Runs behind your existing security without requiring cloud services.

Examples of Cool AI Interactions

Natural-language search & summaries: Ask your AI to find or summarize notes in plain English.
Automated note updates & generation: Let AI create or modify notes, draft meeting minutes, or generate flashcards.
Vault analytics & insights: Track trends, gaps, and recurring topics across your notes.
Personal knowledge assistant: Chat with your vault to answer questions, suggest connections, or recommend topics.
Code & workflow automation: Use AI to generate scripts, organize notes, or trigger automated workflows.

Setup

Run the MCP server on your remote server in a Docker container with one single command.
Add the client config to your desktop AI client (e.g., Cursor):

{
 "mcpServers": {
   "obsidian-http-mcp": {
     "transport": "http",
     "url": "http://localhost:9001/mcp",
     "headers": {
       "Authorization": "Bearer <MCP_API_KEY>"
     }
   }
 }
}

Start interacting with your notes.

For a more detailed description, check out the GitHub repository: obsidian-http-mcp and start chatting with your notes today!

TL;DR

Obsidian HTTP MCP is a lightweight server that exposes your Obsidian vault over HTTP using the MCP protocol. It lets you connect AI clients like Cursor to your notes for natural-language search, summaries, analytics, and automated modifications. Run it on a remote server, connect your AI client, and instantly turn your vault into an interactive, AI-powered knowledge engine. Check it out on GitHub obsidian-http-mcp!

My Obsidian + Syncthing Setup: A Self-Hosted Cloud for Notes, Backups, and More

Matthias Schäfer — Mon, 22 Sep 2025 19:40:48 +0000

There are two kinds of note-takers: those who trust their precious thoughts to the cloud (hello Notion/Google Drive/OneNote people), and those who stare into the abyss and think: “what if I built my own infrastructure for this?”

I belong to the second group.

Here’s how I turned Syncthing + Obsidian + a VPS into a note-syncing, backup-happy, cloud-replacing monster.

The Core Idea

Server: a VPS that acts as my “Syncthing master”
Clients: Linux, Windows, and Android devices, all happily syncing to the server.
Vault: Obsidian notes live in a single folder. That folder is the source of truth.

The magic is in Syncthing: every device talks to the server, syncing notes bi-directionally. That means I can edit notes anywhere (on my phone while commuting, at my desktop during coding sessions, or on my laptop while pretending to relax on the couch). Within seconds, the changes ripple across all devices.

The server is both sync hub and backup repository. So even if a laptop dies or my phone decides to go for a swim, the notes remain safe.

Why Syncthing?

Because it’s basically the anti-cloud cloud.

No accounts, no subscriptions, no vendor lock-in.
Runs on everything (Linux, Windows, macOS, Android, even routers if you’re into that).
Peer-to-peer magic: devices talk directly if they can, fallback via relay if they can’t.
Once set up, it’s “just working.”
Easy to setup with Coolify

It’s like Dropbox, but nerdier and without the creepy terms of service.

Obsidian Layer

Obsidian treats its vault setup (themes, plugins, workspace config) as just more files. Which means: once you throw your vault folder into Syncthing, the entire setup syncs too.

That’s right: I can install a plugin on my Linux machine, and seconds later it’s magically available on Windows and Android. My hotkeys, my color scheme, my crazy plugin combos — they all follow me around.

Extra Features

This is where it gets fun. I didn’t stop at “just syncing notes.”

GitHub Backup

I run a cron job that pushes the entire vault into a private GitHub repo.

Why? Because:

Extra safety net (never enough backups).
Version control: it’s basically git history of my brain.

Automated File Handling

Sometimes, notes get messy. Attachments pile up, screenshots end up in random places.

Solution: a small Python script (also running via cron) that cleans up and reorganizes things.

Think of it as a Roomba for my vault.

Beyond Notes: Syncthing as a Personal Cloud

Here’s the twist: once you’ve got Syncthing humming along on a VPS, you’ve basically built your own cloud framework. Notes are just the start.

Google Drive replacement: throw in any folder you want synced across devices. Done.
Phone DCIM backup: my Android dumps new photos straight to the server, even when I’m abroad. They’re instantly safe, without me ever touching “Google Photos”. Pay attention to the disk space of your server. Images take much space then notes.

I like to think of it as: Syncthing is my cloud OS, the VPS is the data center, and my devices are just clients.

TL;DR Setup

VPS with Syncthing installed → acts as master and backup hub.
Clients: Linux, Windows, Android with Syncthing.
Vault folder = synced everywhere.
Obsidian config = synced too.
Extra spice: GitHub backup, Python scripts, cron jobs.
Bonus: Syncthing doubles as Google Drive + photo backup replacement.

Closing Thoughts

Most people pay for cloud storage. I prefer paying for a VPS and hacking my own.

With Syncthing + Obsidian, I get real-time sync, complete control, no vendor lock-in, and some extra nerd cred.

If you’re into self-hosting, data ownership, or just like to tinker with infrastructure, I can’t recommend this combo enough. It’s not just notes — it’s a self-hosted cloud ecosystem.

Free Hugo Autotranslator for Github Pages

Matthias Schäfer — Thu, 26 Jun 2025 20:25:31 +0000

The problem and the idea

I want to write a blog post in english or german, and I don't want translate it
manually every time. This is much easier to maintain and obviously much less
annoying.

So the idea is to automate this translation process. Therefore it should
automatically detect if the post is written in german or english and translate
it to the other language.

I like to use Github Actions to translate before deployment.
For this I want to use free translation service.

The translation possibilities

There are many possibilities to translate text using code.
Most of them aren't free, or have a limited length of characters.
For example the API interface of known translation services like the DeepL API,
or AI services liken OpenAI (which require a payed API key).

Googletrans

For the first start I want to go with a free version. To do this I found the
free python package googletrans. It is actually deprecated, but does still work
with Python 3.12. This is ok in my case, because I can run it in Github Actions
using an old environment.

Hugo multlingual mode

To realize a multilingual website hugo must be prepared setup in multilingual
mode.
The main setup is done in the hugo.toml.
In my case it works best like this:

title = 'Website title'
theme = 'PaperMod'
defaultContentLanguage = "de"
defaultContentLanguageInSubdir = true
enableMissingTranslationPlaceholders = true

[languages]

[languages.de]
baseURL = 'https://<githubUsername>.github.io/<reponame>/de'
languageName = "Deutsch"
weight = 1
contentDir = "content"

[languages.en]
baseURL = 'https://<githubUsername>.github.io/<reponame>/en'
languageName = "English"
weight = 2
contentDir = "content"

The markdown files are generated like this:

content
- post1
-- index.md (original file)
-- index.en.md
-- index.de.md
- post2
-- index.md (original file)
-- index.en.md
-- index.de.md

How to translate

Realisation of the auto translation using Github Actions and python

Setup of translation environment in Github Actions workflow

The first part of the Github Actions job is getting a python 3.12 environment
and install the required dependencies.
The second part is about running the actual translation script in python and
commit the new, generated markdown files.

The second job is the deployment to the public directory (which contains the
hugo html files) to the gh-pages branch which can be used in Github Pages.

jobs:
  translate:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: pip install requests python-frontmatter langdetect googletrans==4.0.0-rc1

      - name: Translate Markdown files
        run: python scripts/translate_markdown.py

      - name: Commit translated files
        run: |
          git config user.name "github-actions"
          git config user.email "github-actions@users.noreply.github.com"
          git add content/
          git diff --cached --quiet || git commit -m "Auto-translated markdown files"
          git push
        continue-on-error: true
  deploy:
    runs-on: ubuntu-22.04
    needs: translate
    env:
      HUGO_CACHEDIR: /tmp/hugo_cache
    concurrency:
      group: ${{ github.workflow }}-${{ github.ref }}
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: true  # Fetch Hugo themes (true OR recursive)
          fetch-depth: 0    # Fetch all history for .GitInfo and .Lastmod

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: 'latest'
          extended: true

      - name: Define cache
        uses: actions/cache@v4
        with:
          path: ${{ env.HUGO_CACHEDIR }}
          key: ${{ runner.os }}-hugomod-${{ hashFiles('**/go.sum') }}
          restore-keys: |
            ${{ runner.os }}-hugomod-

      - name: Build
        run: hugo --minify

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        if: github.ref == 'refs/heads/main'
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

Auto translation

The translation script consists of the following main parts:

Find markdown files
Check if files changed (hash check)
Identify language of markdown file
Replace code blocks, shortcodes, urls, ... with placeholders (masking)
Translation
Unmask placeholders
Save translated text into new files

import frontmatter
import hashlib
import re
from langdetect import detect
from pathlib import Path
import shutil
from googletrans import Translator

LANGS = {"de", "en"}
BASE_PATH = Path("content")

translator = Translator()


def hash_text(text: str) -> str:
    return hashlib.sha256(text.encode("utf-8")).hexdigest()


def translate(text: str, source: str, target: str) -> str:
    try:
        result = translator.translate(text, src=source, dest=target)
        return result.text
    except Exception as e:
        print(f"Translation failed: {e}")
        return ""


def mask_placeholders(text):
    placeholders = {}
    placeholder_id = 0

    def add_placeholder(match):
        nonlocal placeholder_id
        ph = f"[[000001100000{placeholder_id}]]"
        placeholders[ph] = match.group(0)
        placeholder_id += 1
        return ph

    # Mask code blocks
    text = re.sub(r"```

.*?

```", add_placeholder, text, flags=re.DOTALL)

    # Mask inline code
    text = re.sub(r"`[^`]+`", add_placeholder, text)

    # Mask full markdown links and images
    text = re.sub(r"!\[[^\]]*\]\([^)]+\)", add_placeholder, text)  # images
    text = re.sub(r"\[[^\]]+\]\([^)]+\)", add_placeholder, text)  # links

    # Mask Hugo shortcodes
    text = re.sub(r"\{\{\s*[<%].*?[>%]\s*\}\}", add_placeholder, text, flags=re.DOTALL)

    # Mask **_**
    text = re.sub(r"\*\*(.*?)\*\*", add_placeholder, text, flags=re.DOTALL)

    return text, placeholders


def unmask_placeholders(text, placeholders):
    for ph, original in placeholders.items():
        text = text.replace(ph, original)
    return text


for md_file in BASE_PATH.rglob("*.md"):
    if md_file.suffix != ".md":
        continue
    elif md_file.name.endswith((".de.md", ".en.md")):
        continue  # skip already translated files
    else:
        print(f"file: {md_file}")

    # Load base file
    post = frontmatter.load(md_file)
    content = post.content
    try:
        detected_lang = detect(content)
    except Exception as e:
        print(f"Could not detect language for {md_file}: {e}")
        continue

    if detected_lang not in LANGS:
        print(f"Skipping {md_file}: unsupported language ({detected_lang})")
        continue

    other_lang = "en" if detected_lang == "de" else "de"
    base_name = md_file.stem
    parent_dir = md_file.parent

    source_file = parent_dir / f"{base_name}.{detected_lang}.md"
    target_file = parent_dir / f"{base_name}.{other_lang}.md"

    post_hash = hash_text(content)

    # Skip if translated file exists AND content hash hasn't changed
    if target_file.exists():
        existing_translated = frontmatter.load(target_file)
        if existing_translated.get("base_hash") == post_hash:
            print(f"✅ Skipping {md_file}: translation up-to-date")
            continue
        else:
            print(f"🔁 Updating translation for {md_file} → {target_file}")
    else:
        print(f"🌍 Translating {md_file} → {target_file}")

    # Copy base file to language-specific name if missing
    shutil.copy(md_file, source_file)
    print(f"📄 Copied {md_file} → {source_file}")

    # Mask placeholders before translation
    masked_content, placeholders = mask_placeholders(content)

    # Translate masked content
    translated_masked_content = translate(masked_content, detected_lang, other_lang)
    if not translated_masked_content:
        print(
            f"⚠️ Translation failed for {md_file} from {detected_lang} to {other_lang}, skipping."
        )
        continue

    # Unmask placeholders in translated content
    translated_content = unmask_placeholders(translated_masked_content, placeholders)

    # Prepare translated post with metadata and base_hash
    translated_post = frontmatter.Post(translated_content, **post.metadata)
    translated_post["base_hash"] = post_hash

    # Translate title if exists
    if "title" in post.metadata:
        translated_title = translate(post.metadata["title"], detected_lang, other_lang)
        if translated_title:
            translated_post["title"] = translated_title

    # Save translated file
    with open(target_file, "w", encoding="utf-8") as f:
        f.write(frontmatter.dumps(translated_post))
        print(f"✅ Translated and saved {target_file}")

After the new files are commited. The push to main triggers a new hugo build.

Building Shellmaster: A Fun Way to Learn Linux Shell Commands

Matthias Schäfer — Sun, 06 Apr 2025 16:33:23 +0000

Learning Linux shell commands can be daunting, but what if it could be fun? That’s the idea behind Shellmaster, a quiz game app that helps users master shell and bash commands through engaging quizzes.
Check it out on Google Play Store: Shellmaster - Apps on Google Play
While building Shellmaster, I encountered several interesting technical challenges and learned a lot about Flutter, PocketBase, Unleash feature flags, and Google Play Console deployment. In this article, I’ll share some key takeaways from the development journey.

App Features
App Development
1. Choosing Flutter for a Cross-Platform Quiz App
2. PocketBase as a Lightweight Backend
3. Using Unleash for Feature Flags
4. Deploying via Google Play Console
Conclusion

App Features

Shellmaster is designed to make learning Linux commands fun and interactive. Here are some of its key features:

Multiple Quiz Modes: Test your knowledge with different game modes, including timed quizzes and practice sessions.
Difficulty Levels & Categories: Questions are categorized into easy, medium, and hard levels, covering essential shell commands, scripting, and system administration.
Progress Tracking: Keep track of your performance and improve over time.
Custom Challenges: Users can set their own challenges and compete with friends.
Offline Support: Play quizzes without requiring an internet connection.
Dark Mode: Enjoy a sleek dark mode for better readability.

APP Development

The next chapters are about my learning during the development process.
If you are interested in some nice Flutter stuff keep reading. If you are only here for Linux and Bash check the app out on Google Play Store Shellmaster - Apps on Google Play.

Choosing Flutter for a Cross-Platform Quiz App

I chose Flutter because of its fast development cycle, beautiful UI capabilities, and cross-platform support. With a single codebase, I could target both Android and (potentially) iOS in the future. Some of the key Flutter features I leveraged include:

Custom UI components: I built a custom AppBar (CSAppBar) for a consistent look.
State management: I used provider to handle quiz state and user preferences efficiently.
Smooth animations: Animated background color changes in the quiz questions enhance the user experience.

PocketBase as a Lightweight Backend

For managing quiz data, user progress, and authentication, I opted for PocketBase, an open-source backend written in Go. It provides a SQLite database, real-time subscriptions, and an API with minimal setup. Here’s why it worked well for Shellmaster:

Self-hosted control: Running PocketBase on my VPS gives me full data ownership.
Easy integration: PocketBase exposes a REST API that Flutter’s http package can easily consume.
User authentication: Built-in authentication allowed me to manage user progress across devices. I will add the possibility for user login in the future.

Example: Fetching Quiz Data from PocketBase

Future<List<Question>> fetchQuestions() async {
  final response = await http.get(Uri.parse('https://your-pocketbase-url/api/collections/questions/records'));
  final data = jsonDecode(response.body);
  return data['items'].map<Question>((json) => Question.fromJson(json)).toList();
}

Using Unleash for Feature Flags

To enable progressive feature rollouts and A/B testing, I integrated Unleash, an open-source feature flag system. This allowed me to toggle features dynamically without releasing a new app update.

Why Use Feature Flags?

Experiment with new features (e.g., a “hardcore mode” for experienced users)
Enable/disable features remotely without requiring an app update
Gradual rollouts for testing on a subset of users

Implementing Feature Flags in Flutter

final unleash = UnleashClient(appName: 'shellmaster', instanceId: 'your-instance-id', url: 'https://your-unleash-server');
await unleash.start();
bool isHardcoreModeEnabled = unleash.isEnabled('hardcore-mode');

Deploying via Google Play Console

Publishing Shellmaster on the Google Play Store involved several key steps:

App Signing & Bundling: Flutter’s flutter build appbundle made generating an AAB package easy.
Play Console Setup: Setting up store listings, screenshots, and descriptions took more time than expected.
Testing & Release Tracks: Using internal, closed, and open testing helped catch bugs before full deployment.
Review Process: Google’s review process required proper compliance with data policies, especially for user authentication.

Conclusion

Building Shellmaster has been an exciting journey, combining Flutter’s UI capabilities, PocketBase’s lightweight backend, Unleash’s feature flags, and Google Play Console deployment. The result is a fun and educational quiz app that helps users improve their Linux shell skills interactively.

If you're interested, check out Shellmaster on the Shellmaster - Apps on Google Play and let me know your thoughts!

What are some interesting tech stacks you've used in your apps? Let’s discuss in the comments!

7 Ways to Refactor Your Flutter Application

Matthias Schäfer — Tue, 07 Jan 2025 11:23:17 +0000

Refactoring is a vital part of maintaining and improving your Flutter application.
It ensures your codebase remains clean, consistent, and efficient as your app grows.
In this article, we’ll explore seven practical ways to refactor your Flutter application.

1. Use Parameters in Widgets for Consistency

When building widgets, hardcoding values like padding or fontSize can lead to inconsistencies. Instead, pass these values as parameters to make widgets reusable and consistent.

Example: Use parameters instead of hardcoded values

class GreetingWidget extends StatelessWidget {
  final String name;
  final double _fontSize = 20;
  final double _paddingVal = 10;

  const GreetingWidget({
    required this.name,
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    final String greeting = 'Hello, $name!'; // Internal parameter

    return Padding(
      padding: EdgeInsets.all(_paddingVal),
      child: Column(children: [
        Text(
          greeting,
          style: TextStyle(fontSize: _fontSize),
        ),
        Text(
          "nice to see you!",
          style: TextStyle(fontSize: _fontSize),
        ),
      ]),
    );
  }
}

By defining paddingVal and fontSize as internal parameters, the GreetingWidget can easily maintained.

2. Create a Global Parameter File

The next step to creating internal parameters for consistency, is creating global parameters for consistency.
All values that should remain consistent throughout your app, such as colors, scaling factors, or button sizes, store them in a global file.
This file doesn't need a special formatting. You can easily make it like this.

Example: Global Parameters File

// wrapperBox
double boxWidthFactor = 0.9;
double paddingVal = 10;
double borderWidth = 3;
double borderRadius = 10;
double boxHeaderTextSize = 16;

To use this global parameters in different files. Just import the global parameter file at the beginnging.

Usage:

import 'package:<appName>/common/src/globals.dart';

Text(
  'Hello, World!',
  style: TextStyle(fontSize: boxHeaderTextSize),
);

This approach ensures consistency across the entire app and simplifies updates.

3. Organize Your Dart Files Effectively

A well-structured lib directory improves code readability and maintainability. A common structure is feature-based organization:

Example File Structure

lib/
|-- features/
|   |-- home/
|   |   |-- home_screen.dart
|   |   |-- home_controller.dart
|-- shared/
|   |-- classes/
|   |-- funcs/
|   |-- widgets/
|   |-- utils/
|   |-- themes.dart

Refer to Flutter Professional Folder Structure: Feature-first or Layer-first? for an in-depth guide to file organization.

4. Create Custom Widgets for Reusability

If you find yourself duplicating similar widgets, extract them into custom widgets. This reduces code duplication and improves maintainability.

Example: Extracting a Custom Widget

class CustomCard extends StatelessWidget {
  final String title;
  final String subtitle;
  final double _fontSize = 12;

  const CustomCard({
    required this.title,
    required this.subtitle,
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Padding(
        padding: EdgeInsets.all(paddingVal),
        child: Column(children: [
          ListTile(
            title: Text(title),
            subtitle: Text(subtitle),
          ),
          Text(
            "Hello hacker",
            style: TextStyle(fontSize: _fontSize),
          ),
          Text(
            "nice to see you!",
            style: TextStyle(fontSize: _fontSize),
          ),
        ]),
      ),
    );
  }
}

Usage:

CustomCard(title: 'Flutter', subtitle: 'Custom Widgets');

5. Differentiate Internal and External Parameters/Methods

When working with Flutter, distinguishing between internal and external parameters or methods is essential.
Internal parameters or methods are private to the widget and typically have an underscore (_) prefix,
while external parameters or methods are exposed to other widgets or parts of the app and lack this prefix.

When to Use an Underscore

Use an underscore (_) for private properties or methods that should not be accessed outside the widget.
Internal parameters or methods are intended for use within the widget's implementation only.

Example: Internal Parameter with Underscore

class CounterWidget extends StatefulWidget {
  @override
  _CounterWidgetState createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int _count = 0; // Internal parameter

  void _increment() { // Internal method
    setState(() {
      _count++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Count: $_count'),
        ElevatedButton(onPressed: _increment, child: Text('Increment')),
      ],
    );
  }
}

In this example, _count and _increment are internal and should not be accessed outside _CounterWidgetState.

When to Avoid an Underscore

Avoid underscores for public properties or methods that are meant to be used by parent widgets or other components.
External parameters or methods define the API of your widget and should be accessible.

Example: External Parameters

class GreetingWidget extends StatelessWidget {
  final String name; // External parameter

  GreetingWidget({required this.name});

  @override
  Widget build(BuildContext context) {
    return Text('Hello, $name!');
  }
}

Here, name is an external parameter passed by the parent widget, defining the widget's behavior.

Best Practices

Use underscores (_) for private/internal properties or methods to encapsulate implementation details.
Keep external parameters clean and intuitive to create a clear API for your widgets.

6. Scale Widgets Using Screen Size

To make your app responsive, scale widgets based on screen size using the MediaQuery class.

Example: Responsive Padding

class ResponsiveBox extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    double screenWidth = MediaQuery.of(context).size.width;

    return SizedBox(
      width: screenWidth*0.8;
      child: Text('Responsive Box'),
    );
  }
}

This ensures your UI adapts gracefully to different screen sizes and prevents your app from overflow.

7. Usage of Providers: Managing State Effectively

The provider package simplifies state management by allowing widgets to listen to changes and rebuild accordingly.
This is necessary if you need the same data in different widgets (read or write).
Here are two popular provider type I already used:

ChangeNotifierProvider

Use ChangeNotifierProvider for managing mutable state.
For example a quiz game app with a QuizProvider.
If some widget modifies the quiz data with the help of the QuizProvider, every Consumer of the quizd data will be notfied.

Example: Quiz Game App

import 'package:provider/provider.dart';

const GameUI({
  super.key,
});

@override
Widget build(BuildContext context) {

  return MultiProvider(
    providers: [
      ChangeNotifierProvider(
        create: (context) => QuizProvider(),
      ),
    ],
    child: const Scaffold(
      appBar: CustomAppBar(),
      body: Body(),
    ),
  );
}
class QuizProvider with ChangeNotifier {
  late QuizGame _quizGame;
  QuizProvider({});

  void loadGame() async {
    var questions = await fetchAllQuestions();
    _quizGame =
        QuizGame();
    _quizGame.init();
    notifyListeners();
  }

  void selectAnswer(int selectedAnswers) {
    _quizGame.currentQuestion.selectedAnswer = selectedAnswers;
    notifyListeners();
  }

  void submitAnswer() async {
    _quizGame.submitAnswer();
    notifyListeners();
  }

  void nextQuestion() async {
    // await Future.delayed(const Duration(milliseconds: 200));
    _quizGame.nextQuestion();
    notifyListeners();
  }
}

The QuizProvider data can be accessed using context.watch<QuizProvider>() or manipulated using context.read<QuizProvider>().submitAnswer()

FutureProvider

Use FutureProvider for widgets that depend on asynchronous data.

Example: Fetching User Data

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';

void main() {
  runApp(
    FutureProvider<User>(
      create: (context) => fetchUser(),
      initialData: User(name: 'Loading...', email: 'Loading...'),
      child: MyApp(),
    ),
  );
}

class User {
  final String name;
  final String email;

  User({required this.name, required this.email});
}

Future<User> fetchUser() async {
  await Future.delayed(Duration(seconds: 2)); // Simulate network delay
  return User(name: 'John Doe', email: 'john.doe@example.com');
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: UserScreen(),
    );
  }
}

class UserScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final user = Provider.of<User>(context);

    return Scaffold(
      appBar: AppBar(title: Text('User Info')),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('Name: ${user.name}', style: TextStyle(fontSize: 24)),
            SizedBox(height: 10),
            Text('Email: ${user.email}', style: TextStyle(fontSize: 18)),
          ],
        ),
      ),
    );
  }
}

Refactoring doesn’t have to be overwhelming. By applying these seven techniques, you can improve your Flutter application’s maintainability, scalability, and overall quality.

Free Obsidian PC Android sync

Matthias Schäfer — Thu, 02 Jan 2025 14:37:10 +0000

Obsidian is a great tool for collecting ideas.

I use it mainly for the following reasons:

Research
Collecting information
Saving some spontaneous ideas

Depending on my actual situation I prefer to use my laptop or my phone.
To always have access to my vaults, regardless of the device I am using, I need to sync the data between my devices. For that purpose Obsidian provides the Sync Plugin. But for this plugin they charge you 4$ a month, which I don't want to spend, if there is another option.

I found a solution which meets my requirements:

Crossplatform availability: Linux, Windows and Android
No manual work: no downloads, no copies, no nothing
free to use

What I use now:

Syncthing-fork on my android phone
Syncthing on my windows and linux machine
Shell script to backup the data in a git repository

Setup:

Install syncthing on the devices you want to use Obsidian
Create folders on every device to store the Obsidian files locally
Linking the devices using the QR code
Share the folders (also using QR code)
Copy your vault into the new directory and open it in Obsidian
optional:
- create a git repository in your Obsidian directory and backup the files to your github account

Obsidian Git autobackup

#!/bin/bash

git-autopush() {
  REPO_DIR = $1
  cd "$REPO_DIR" || {
    echo "Repository not found: $REPO_DIR"
    exit 1
  }

  # Check if the repository has changes
  if [[ -n $(git status --porcelain) ]]; then
    git add .
    git status

    TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
    git commit -m "Auto-commit: $TIMESTAMP"

    git push origin "$(git rev-parse --abbrev-ref HEAD)" || {
      echo "Failed to push changes."
      exit 1
    }

    echo "Changes pushed successfully."
  else
    # Check if there are committed changes to push
    LOCAL_BRANCH=$(git rev-parse --abbrev-ref HEAD)
    if [[ -n $(git rev-list origin/"$LOCAL_BRANCH"..HEAD) ]]; then

      # Push changes
      git push origin "$LOCAL_BRANCH" || {
        echo "Failed to push changes."
        exit 1
      }
      echo "Changes pushed successfully."
    fi

  fi
}

git-autopush $1

First flutter app for marathon training

Matthias Schäfer — Sat, 16 Nov 2024 10:50:02 +0000

I am proud to say that I was able to build my first flutter app in 4 days more or less ready for production.

Before these days I hadn't any experience about flutter. But I always like the idea to easily build apps for personal use.
After some failed attempts to build some useful personal apps over the last two years using python i heard about flutter.
So this month I had some free time and set me the challenge to learn flutter, build an android app and publish it to google play store IN 4 DAYS.

The app I've chosen is some kind of pacing calculator I can use for running and triathlon training. For this purpose I used a google doc so far. In only need a few simple string and math operations on a few pages, no backend required. This seems to be perfect for my first app, not to complex and I would use to optimize my training in the future.

The development process actually starts one day to early. With my plan I could not wait to start and build a coffee card app in the evening of day 0 using the Flutter Crash Course of Net Ninja on Youtube.
With the learnings I get from this tutorial I start at the morning of day 1 with my own flutter app called "GOALPACER".

In the next 3 days I was able to build this app using VSCO on my Linux machine. I managed to provide 4 functionalities:

Finish Time Calculator: Calculates finish time based on your pace for running, swimming and biking.
Pace Calculator: Calculates the necessary pace for your desired finish time
Heart Rate Zones Calculator: Estimate your heart rate zones based on your maximum heart rate
Pace Converter: Converts paces from min/mile to min/km

Even if the design is pretty easy and far from perfect I am really happy with the result.

The last step is to publish the app on google play store. In the end this is more complicated then I have expected. At the moment I am in a state where I am searching for closed loop testers. As a private first time developer it is necessary to do a closed loop test with 20 people, before you can publish to the play store.

So if you are interested on the app or want to chat, feel free to contact me. I would like to get some testers from the community to get some independent opinions from different people.

Forem: Matthias Schäfer

Chat With Your Obsidian Notes: Introducing HTTP MCP Server

Table of Contents

Introduction

Why Obsidian HTTP MCP?

How It Works

What Makes It Nerdy-Perks-Worthy

Examples of Cool AI Interactions

Setup

TL;DR

My Obsidian + Syncthing Setup: A Self-Hosted Cloud for Notes, Backups, and More

The Core Idea

Why Syncthing?

Obsidian Layer

Extra Features

GitHub Backup

Automated File Handling

Beyond Notes: Syncthing as a Personal Cloud

TL;DR Setup

Closing Thoughts

Free Hugo Autotranslator for Github Pages

The problem and the idea

The translation possibilities

Googletrans

Hugo multlingual mode

How to translate

Setup of translation environment in Github Actions workflow

Auto translation

Building Shellmaster: A Fun Way to Learn Linux Shell Commands

Table of Contents

App Features

APP Development

Choosing Flutter for a Cross-Platform Quiz App

PocketBase as a Lightweight Backend

Example: Fetching Quiz Data from PocketBase

Using Unleash for Feature Flags

Why Use Feature Flags?

Implementing Feature Flags in Flutter

Deploying via Google Play Console

Conclusion

7 Ways to Refactor Your Flutter Application

1. Use Parameters in Widgets for Consistency

Example: Use parameters instead of hardcoded values

2. Create a Global Parameter File

Example: Global Parameters File

Usage:

3. Organize Your Dart Files Effectively

Example File Structure

4. Create Custom Widgets for Reusability

Example: Extracting a Custom Widget

Usage:

5. Differentiate Internal and External Parameters/Methods

When to Use an Underscore

Example: Internal Parameter with Underscore

When to Avoid an Underscore

Example: External Parameters

Best Practices

6. Scale Widgets Using Screen Size

Example: Responsive Padding

7. Usage of Providers: Managing State Effectively

ChangeNotifierProvider

Example: Quiz Game App

FutureProvider

Example: Fetching User Data

Free Obsidian PC Android sync

I found a solution which meets my requirements:

What I use now:

Setup:

Obsidian Git autobackup

First flutter app for marathon training