DEV Community: Theoklitos Bampouris

Pi Coding Agent: A Self-Documenting, Extensible AI Partner

Theoklitos Bampouris — Mon, 13 Apr 2026 11:40:30 +0000

Originally published at https://www.bampouris.eu/blog/pi-self-documenting/

Meta-lesson: One of Pi's most powerful features is that you can ask it to explain itself. The agent can read its own documentation, investigate its codebase, and help you extend or modify its behavior—all through natural conversation.

The Scenario: Renaming and Enhancing the "Agent" Tool

In this session, I asked Pi to help rename the "subagent" tool to simply "Agent" and then enhance it with model configuration capabilities. What followed was a perfect demonstration of how Pi operates as a self-documenting system.

The Initial Request

User: Configure the subagent extension of pi coding agent such as the tool which "Delegate tasks to specialized subagents with isolated context" to be renamed: "Agent" (including all its references and calls etc.).

Phase 1: Pi Investigates Its Own Structure

Instead of requiring me to know where files are located, Pi immediately began exploring its own codebase:

Reading the Documentation

📖 Reading: /Users/.../.nvm/.../pi-coding-agent/README.md

Pi accessed its own README to understand:

How extensions are structured
Where tools are registered
How the agent system works

Finding the Extension Files

find ~/.pi/agent -name "*.ts" -o -name "*.js" 2>/dev/null | head -30

Result:

/Users/.../.pi/agent/extensions/list-agents.ts
/Users/.../.pi/agent/extensions/subagent/agents.ts
/Users/.../.pi/agent/extensions/subagent/index.ts

Reading Extension Documentation

📖 Reading: /Users/.../pi-coding-agent/docs/extensions.md

This document explained:

"Extensions are TypeScript modules that extend pi's behavior. They can subscribe to lifecycle events, register custom tools callable by the LLM, add commands, and more."

Phase 2: Understanding the Implementation

Pi read its own extension source code to understand the current implementation:

📖 Reading: ~/.pi/agent/extensions/subagent/index.ts
📖 Reading: ~/.pi/agent/extensions/subagent/agents.ts
📖 Reading: ~/.pi/agent/extensions/list-agents.ts

From these files, Pi learned:

Tool Registration: The tool was registered with:
- name: "subagent"
- label: "Subagent"
- A description mentioning "subagents"
Three Operation Modes:
- Single: One agent + task
- Parallel: Multiple tasks array
- Chain: Sequential with {previous} placeholder
UI Rendering: Display text using theme.bold("subagent ")
Error Messages: "Subagent was aborted"

Phase 3: Executing the Changes

Pi systematically updated all references:

Tool Registration Changes

name: "subagent" → name: "agent"
label: "Subagent" → label: "Agent"
Description updated from "subagents" to "agents"

UI Display Updates

All theme.bold("subagent ") references changed to theme.bold("agent "):

Chain mode display
Parallel mode display
Single agent mode display

Error Message Update

"Subagent was aborted" → "Agent was aborted"

Documentation Updates

list-agents.ts description updated
File header comments updated

Phase 4: Debugging (When Things Go Wrong)

After reloading, an error appeared:

User: After reload we get the following issue: [Extension issues] ParseError: Unexpected token

Pi's response:

📖 Reading: /Users/.../.pi/agent/extensions/subagent/index.ts

Found: "The edit accidentally duplicated the description lines"

Fix applied - duplicate lines removed, file now parses correctly.

Phase 5: Enhancing the Tool (Feature Addition)

Next request:

User: Investigate if the agent tool can accept model configuration as input via prompt... If it cannot in the current configuration, then adjust it so that it can. The model from input should have priority.

Investigation Phase

Pi investigated how models are handled:

grep -n "ctx.model\|modelRegistry" ~/.pi/agent/extensions/subagent/index.ts

grep -n "model" ~/.pi/agent/extensions/subagent/index.ts | head -30

Found that the current implementation:

Read model from agent markdown file frontmatter
Had no input parameter for model override

The Enhancement

Pi added a model parameter to the tool schema:

model: Type.Optional(Type.String({
  description: "Model to use (e.g., 'anthropic/claude-sonnet-4-20250514'). Overrides agent's frontmatter model.",
})),

Then implemented the priority logic:

First priority: Model from input parameters
Fallback: Model from agent markdown frontmatter
Final fallback: Main agent's running model

The implementation involved:

Adding model?: string to SingleAgentTask type
Modifying runSingleAgent() to accept and use the model parameter
Updating all three execution modes (single, parallel, chain) to pass the model
Updating the tool description to document the new parameter

Key Insights: Pi as a Self-Documenting System

1. Documentation is Always Available

Pi has built-in knowledge of its own documentation locations:

Pi documentation (read only when the user asks about pi itself):

- Main documentation: ~/.nvm/.../pi-coding-agent/README.md
- Additional docs: ~/.nvm/.../pi-coding-agent/docs
- Examples: ~/.nvm/.../pi-coding-agent/examples

2. Extension System is First-Class

From the docs:

"Pi ships with powerful defaults but skips features like sub agents and plan mode. Instead, you can ask pi to build what you want or install a third party pi package that matches your workflow."

3. Three-Level Model Fallback System

The implemented enhancement shows a robust pattern:

Input model → Frontmatter model → Main agent model

This graceful degradation ensures the tool always works while respecting user preferences.

4. Skills System for Specialized Knowledge

Pi can load skills from ~/.pi/agent/skills/ that provide specialized instructions. The session shows skills for:

autofix (CodeRabbit integration)
changeset-pr (versioning)
code-review
frontend-design
git operations
and many more...

What This Demonstrates

You Can Ask Pi About Itself

"How do I configure extensions?"
"Where is the documentation for themes?"
"How do I add a custom tool?"

Pi will read its own docs and explain.

Pi Can Modify Its Own Code

The agent can:

Find its own extension files
Read and understand the code
Make precise edits
Fix errors when they occur

Extensions Are Powerful

The subagent → Agent tool demonstrates:

Custom tool registration
Type-safe parameter schemas (using TypeBox)
Multiple execution modes (single, parallel, chain)
UI rendering customization
Error handling

The Philosophical Point

Pi embodies a different approach to AI tooling. As the documentation states:

"Pi is aggressively extensible so it doesn't have to dictate your workflow. Features that other tools bake in can be built with extensions, skills, or installed from third-party pi packages. This keeps the core minimal while letting you shape pi to fit how you work."

The fact that Pi can:

Explain its own architecture
Read and modify its own extensions
Help you build new capabilities

...makes it a genuinely self-improving system.

Try It Yourself

Want to explore Pi's self-documenting capabilities? Try asking:

"Show me how extensions work"
"How do I create a custom skill?"
"What tools are currently available and what do they do?"
"Help me modify the theme/colors"
"Read the documentation about sessions and explain branching"

Pi will demonstrate the same pattern: read docs → investigate code → explain → implement if requested.

Conclusion

This session demonstrates something profound: Pi is an AI system that can understand and modify its own behavior. It's not a black box—it's a transparent, extensible platform that invites exploration and customization.

The ability to ask "How do I extend you?" and receive a working implementation is a glimpse into a future where AI systems are not just tools, but collaborative partners in building the exact workflow you need.

Info about the above described pi session

Session date: 2026-04-12

Pi: @mariozechner/pi-coding-agent

Model: mimo-v2-omni via opencode-go

Revolutionizing Git Workflows: The MCP Git Commit Generator

Theoklitos Bampouris — Sat, 09 Aug 2025 10:32:10 +0000

Originally published at https://www.bampouris.eu/blog/mcp-git-commit-generator

Introduction

In the world of software development, writing clear, consistent commit messages is both an art and a necessity. Good commit messages tell a story, help teammates understand changes, and make code history navigable. Yet, many developers struggle with crafting meaningful commit messages that follow established conventions like Conventional Commits. Enter the MCP Git Commit Generator – a revolutionary tool that leverages the Model Context Protocol (MCP) to automatically generate conventional commit messages from your staged git changes.

What is the MCP Git Commit Generator?

The MCP Git Commit Generator is an intelligent MCP server that analyzes your staged git changes and automatically generates conventional commit messages. Built with Python and leveraging the power of AI through the Model Context Protocol, this tool bridges the gap between your code changes and descriptive, standardized commit messages.

Key Features at a Glance

🤖 AI-Driven Analysis: Automatically analyzes staged git diffs to understand the nature of your changes
📝 Conventional Commits Support: Generates messages following the widely-adopted Conventional Commits specification
🔧 Flexible Integration: Works with VS Code, Cursor, Windsurf, Claude Desktop, and other MCP-compatible clients
🐳 Docker-Ready: Ships as a lightweight Docker container for easy deployment
🔍 Inspector UI: Includes a debugging interface for testing and development
⚡ Multiple Transport Options: Supports both stdio (default) and Server-Sent Events (SSE) transports

The Problem It Solves

Before: The Commit Message Struggle

Every developer has been there – you've made significant changes to your codebase, staged your files, and now you're staring at the commit message prompt. Questions flood your mind:

Should this be a feat, fix, or refactor?
What scope should I use?
How do I summarize these complex changes concisely?
Am I following the team's commit message conventions?

The result? Either rushed, uninformative messages like "fix stuff" or spending precious development time crafting the perfect commit message.

After: Intelligent Automation

With the MCP Git Commit Generator, this friction disappears. The tool:

Analyzes your staged changes using git diff
Understands the context of modified files and their relationships
Determines the appropriate commit type (feat, fix, docs, etc.)
Suggests relevant scopes based on changed files
Generates a complete conventional commit message ready for use

Technical Architecture

Core Components

The MCP Git Commit Generator is built with a clean, modular architecture:

src/mcp_git_commit_generator/
├── __init__.py     # CLI entrypoint using Click
├── __main__.py     # Module launcher
└── server.py       # MCP tools implementation

MCP Tools Exposed

The server exposes two primary MCP tools:

1. `generate_commit_message`

This is the star of the show. The tool:

@mcp.tool()
def generate_commit_message(
    repo_path: Optional[str] = None,
    commit_type: Optional[str] = None,
    scope: Optional[str] = None,
) -> str:

Parameters:

repo_path: Optional path to git repository (defaults to current directory)
commit_type: Optional commit type override (auto-detected if not provided)
scope: Optional scope override (auto-detected if not provided)

Process:

Validates the git repository
Retrieves staged changes using git diff --cached
Analyzes file status and change patterns
Generates contextual analysis for AI processing
Returns a conventional commit message suggestion

2. `check_git_status`

A utility tool that provides comprehensive repository status:

@mcp.tool()
def check_git_status(repo_path: Optional[str] = None) -> str:

This tool reports:

Staged files ready for commit
Unstaged modifications
Untracked files
Current branch information

Transport Flexibility

The tool supports two transport mechanisms:

stdio (default): Perfect for CLI integration and MCP clients
SSE (Server-Sent Events): Ideal for web-based interfaces and the Inspector UI

Integration Ecosystem

MCP Client Support

The tool seamlessly integrates with popular development environments:

VS Code Integration

{
  "servers": {
    "mcp-git-commit-generator": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--mount",
        "type=bind,src=${userHome},dst=${userHome}",
        "ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest",
      ],
    },
  },
}

Claude Desktop, Cursor, and Windsurf

Similar JSON configurations enable the tool across different AI-powered development environments, making it accessible regardless of your preferred IDE.

Docker-First Approach

The tool ships as a Docker container, providing:

Consistent Environment: Same behavior across different systems
Easy Installation: No Python environment setup required
Security: Runs as non-root user with minimal permissions
Portability: Works on any system with Docker

Real-World Usage Scenarios

Scenario 1: Feature Development

You've just implemented a new user authentication system:

# Stage your changes
git add src/auth/ tests/auth/ docs/authentication.md

# Use the MCP tool (through your IDE)
# Generates: "feat(auth): implement OAuth2 authentication with JWT tokens"

Scenario 2: Bug Fixes

You've fixed a critical performance issue:

git add src/database/query.py tests/test_query.py

# Generates: "fix(database): optimize N+1 query in user profile loading"

Scenario 3: Documentation Updates

You've updated project documentation:

git add README.md docs/api.md

# Generates: "docs: update API documentation and installation guide"

Development and Debugging

Inspector UI

The included Inspector UI provides a powerful debugging interface:

Interactive Tool Testing: Test tools with different parameters
Real-time Debugging: Set breakpoints in tool implementation
Parameter Validation: Verify tool arguments before execution

Development Workflow

The project includes VS Code tasks for streamlined development:

Start MCP Server: Launches server with debugging support
Start MCP Inspector: Opens the Inspector UI for testing
Flexible Environment: Supports both uv and traditional pip workflows

Technical Innovation

AI-Powered Analysis

The tool doesn't just parse file names – it performs intelligent analysis:

# Analyzes diff content, file patterns, and change types
analysis = f"""
## Git Change Analysis for Conventional Commit Message

### Changed Files:
{files_result.stdout}

### Diff Preview:
{diff_result.stdout[:1500]}

### User Preferences:
- Commit Type: {commit_type or 'auto-detect'}
- Scope: {scope or 'auto-detect'}
"""

This rich context enables AI models to make informed decisions about commit message generation.

Conventional Commits Compliance

The tool strictly follows the Conventional Commits specification:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Supporting all standard types:

feat: New features
fix: Bug fixes
docs: Documentation changes
style: Code style changes
refactor: Code refactoring
perf: Performance improvements
test: Test additions/modifications
build: Build system changes
ci: CI/CD changes
chore: Maintenance tasks
revert: Commit reverts

Performance and Reliability

Lightweight Design

The tool is designed for speed and efficiency:

Fast Git Operations: Direct git command execution
Minimal Dependencies: Only essential packages included
Docker Optimization: Multi-stage builds for smaller images

Error Handling

Robust error handling ensures reliability:

def get_valid_repo_path(repo_path: Optional[str]) -> Optional[str]:
    """Validate git repository path with proper error handling"""
    if not os.path.isdir(repo_path) or not os.path.exists(
        os.path.join(repo_path, ".git")
    ):
        return None
    return repo_path

Future Implications

The MCP Git Commit Generator represents more than just a commit message tool – it's a glimpse into the future of AI-assisted development workflows. By leveraging the Model Context Protocol, it demonstrates how AI can seamlessly integrate into existing development tools and processes.

Potential Enhancements

Future versions could include:

Custom Convention Support: Beyond Conventional Commits
Team-Specific Rules: Organization-specific commit patterns
Multilingual Support: Commit messages in different languages
Integration Metrics: Track commit message quality over time
Advanced Scope Detection: ML-powered scope suggestion

Getting Started

Quick Setup

Install Docker (if not already installed)
Configure your MCP client with the provided JSON configuration
Start committing smarter:

git add your-changes
# Use the MCP tool through your IDE
git commit -m "generated message"

For Developers

The project welcomes contributions and provides comprehensive development guidelines:

git clone https://github.com/theoklitosBam7/mcp-git-commit-generator.git
cd mcp-git-commit-generator
uv venv && uv pip install -e .

Conclusion

The MCP Git Commit Generator transforms one of the most mundane yet important aspects of software development – writing commit messages. By combining the power of AI with the flexibility of the Model Context Protocol, it eliminates friction while maintaining consistency and quality.

Whether you're a solo developer looking to improve your git history or part of a team striving for better collaboration through clear commit messages, this tool offers a compelling solution. Its Docker-based approach ensures easy adoption, while its MCP foundation provides a glimpse into the future of AI-integrated development tools.

The era of "fix stuff" commit messages is over. Welcome to the age of intelligent, automated, and meaningful git history.

Try it today: The MCP Git Commit Generator is available as a Docker image at ghcr.io/theoklitosbam7/mcp-git-commit-generator:latest

Learn more: Visit the GitHub repository for detailed documentation and configuration examples.

Happy committing! 🚀

Setup Unit Testing Tools in Angular CLI Project

Theoklitos Bampouris — Fri, 21 Jan 2022 21:04:00 +0000

Originally published at https://www.bampouris.eu/blog/setup-unit-testing-angular

Every developer have to ensure that his/her application is working as expected. A safeguard to that purpose are unit tests.

The Defaults of an Angular CLI Generated Project

An Angular CLI generated project comes by default with Karma and Jasmine for unit testing. However, there are people who prefer other tools such as Jest.

I'm not going, in this post, to compare or choose the one over the other. I will only show you the steps to move from Karma/Jasmine to Jest. At the end, it's just a case of taste.

Remove Karma & Jasmine Related Packages

Uninstall the npm packages:

npm uninstall karma karma-chrome-launcher karma-coverage karma-jasmine karma-jasmine-html-reporter jasmine-core @types/jasmine

Delete the no more needed Karma configuration files:

rm ./karma.conf.js ./src/test.ts

Install Jest

npm i -D jest @types/jest jest-preset-angular @angular-builders/jest

@types/jest: This package contains type definitions for Jest.
jest-preset-angular: It is Jest preset configuration and TypeScript preprocessor with source map support for Jest that lets you use Jest to test Angular projects.
@angular-builders/jest: Allows running ng test with Jest instead of Karma & Jasmine. The builder comes to provide zero configuration setup for Jest while keeping the workspace clear of boilerplate code.

To make use of @angular-builders/jest, the only we need to do is to change our angular.json file as below:

  }
},
"test": {
-  "builder": "@angular-devkit/build-angular:karma",
+  "builder": "@angular-builders/jest:run",
  "options": {
-    "main": "src/test.ts",
-    "polyfills": "src/polyfills.ts",
-    "tsConfig": "tsconfig.spec.json",
-    "karmaConfig": "karma.conf.js",
-    "inlineStyleLanguage": "scss",
-    "assets": ["src/favicon.ico", "src/assets"],
-    "styles": ["src/styles.scss"],
-    "scripts": []
+    "no-cache": true
  },
  "lint": {

You may find details how to change the builder options here.

Setup Jest in our Project

We create a config file in project's root directory with the name jest.config.js:

module.exports = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/setup-jest.ts'],
};

As you guess from the above configuration, we will now create setup-jest.ts in root directory:

import 'jest-preset-angular/setup-jest';
import './jest-global-mocks';

The second import above is optional at first. Because jest-preset-angular uses JSDOM, which is different from normal browsers, we might need some global browser mocks to simulate the behaviors of real browsers in JSDOM. To add global mocks, we can create jest-global-mocks.ts and use it in our Jest setup.

You may find more information about jest-preset-angular in official docs and about Jest and JSDOM in this article.

Here is an example of jest-global-mocks.ts:

Object.defineProperty(window, 'CSS', { value: null });
Object.defineProperty(document, 'doctype', {
  value: '<!DOCTYPE html>',
});
Object.defineProperty(window, 'getComputedStyle', {
  value: () => {
    return {
      display: 'none',
      appearance: ['-webkit-appearance'],
    };
  },
});
Object.defineProperty(document.body.style, 'transform', {
  value: () => {
    return {
      enumerable: true,
      configurable: true,
    };
  },
});

Finally, in tsconfig.spec.json file, we have to take care of at least two things:

Replace jasmine in types array with jest, as we want our tests to be type-checked against Jest typings and not Jasmine.
Remove test.ts entry from files array. This file was responsible for Karma setup, we don't need it here anymore.

"compilerOptions": {
  "outDir": "./out-tsc/spec",
  "types": [
-    "jasmine"
-  ]
+    "jest",
+    "node"
+  ],
+  "esModuleInterop": true,
+  "emitDecoratorMetadata": true,
},
"files": [
-  "src/test.ts",
  "src/polyfills.ts"
],
"include": [

For other options you may check here.

Last But Not Least

A nice and powerful tool to simplify our Angular unit tests is Spectator:

Helps you get rid of all the boilerplate grunt work, leaving you with readable, sleek and streamlined unit tests.
Write tests for components, directives, services, and more, without having to learn TestBed, ComponentFixture, and DebugElement APIs.

We can install it with:

npm i -D @ngneat/spectator

I hope in a future post to show a few examples of how we can use it and take advantage of its features.

Avoid Memory Leaks in Angular

Theoklitos Bampouris — Thu, 25 Mar 2021 13:33:16 +0000

Originally published at https://www.bampouris.eu/blog/avoid-memory-leaks-angular

Almost five years ago, Ben Lesh wrote a nice article with title: RxJS: Don’t Unsubscribe. The author of course doesn't tell us to never care about our Subscription. He means that we must find a way that we don't have to perform .unsubscribe() manually in each one. Let's start our mission!

Our Road Map

The lifetime of some global components, such as AppComponent, is the same as the lifetime of the app itself. If we know that we're dealing with such a case it is acceptable to .subscribe() to an Observable without providing any memory leak guard step. However, handle memory leaks during the implementation of an Angular application is a critical task for every developer. We'll begin our quest with showing what we mean with memory leak and we'll proceed solving the problem at first with the "traditional" way of .unsubscribe(), until we explore our preferable pattern.

The Bad Open Subscriptions
Unsubscribe the Old Way
The Async Pipe
The RxJS Operators
The DestroyService
Conclusions

The Bad Open Subscriptions

We have a simple demo app with two routing components: FirstComponent and SecondComponent (First Cmp and Second Cmp nav link buttons respectively). The FirstComponent (corresponding to path /first) subscribes to a timer1$ observable and sends messages to a ScreenMessagesComponent via a MessageService. The messages are displayed at the bottom of the screen.

Live Example

export class FirstComponent implements OnInit {
  timer1$ = timer(0, 1000);

  constructor(private messageService: MessageService) {}

  ngOnInit(): void {
    this.timer1$.subscribe((val) =>
      this.messageService.add(`FirstComponent timer1$: ${val}`)
    );
  }
}

When we navigate to /second path, FirstComponent has been destroyed. However, we still see outgoing messages from the above subscription. This is happening because we forgot to "close the door behind us": our app has an open Subscription. As we go back and forth we add more and more subscriptions which will close only when the app is closed. We have to deal with Memory Leaks!

Unsubscribe the Old Way

A straightforward way to solve to above problem is to implement the lifecycle hook method ngOnDestroy(). As we read from the official documentation:

...Unsubscribe Observables and detach event handlers to avoid memory leaks...

export class FirstComponent implements OnInit, OnDestroy {
  private timer1$ = timer(0, 1000);

  private subscription: Subscription;

  constructor(private messageService: MessageService) {}

  ngOnInit(): void {
    this.subscription = this.timer1$.subscribe((val) =>
      this.messageService.add(`FirstComponent timer1$: ${val}`)
    );
  }

  ngOnDestroy(): void {
    this.subscription.unsubscribe();
  }
}

Furthermore, if we have more than one Subscription, we have to do the same job for each of them.

export class FirstComponent implements OnInit, OnDestroy {
  private timer1$ = timer(0, 1000);
  private timer2$ = timer(0, 2500);

  private subscription1: Subscription;
  private subscription2: Subscription;

  constructor(private messageService: MessageService) {}

  ngOnInit(): void {
    this.subscription1 = this.timer1$.subscribe((val) =>
      this.messageService.add(`FirstComponent timer1$: ${val}`)
    );

    this.subscription2 = this.timer2$.subscribe((val) =>
      this.messageService.add(`FirstComponent timer2$: ${val}`)
    );
  }

  ngOnDestroy(): void {
    this.subscription1.unsubscribe();
    this.subscription2.unsubscribe();
  }
}

In case we don't have only one or two subscriptions and we want to reduce the number of .unsubscribe() calls, we can create a parent Subscription and add to it the child ones. When a parent subscription is unsubscribed, any child subscriptions that were added to it are also unsubscribed.

Live Example

export class FirstComponent implements OnInit, OnDestroy {
  private timer1$ = timer(0, 1000);
  private timer2$ = timer(0, 2500);

  private subscription = new Subscription();
  constructor(private messageService: MessageService) {}

  ngOnInit(): void {
    this.subscription.add(
      this.timer1$.subscribe((val) =>
        this.messageService.add(`FirstComponent timer1$: ${val}`)
      )
    );

    this.subscription.add(
      this.timer2$.subscribe((val) =>
        this.messageService.add(`FirstComponent timer2$: ${val}`)
      )
    );
  }

  ngOnDestroy(): void {
    this.subscription.unsubscribe();
  }
}

Using a parent Subscription we don't have to care about plenty of properties and we also perform only one .unsubscribe().

The Async Pipe

AsyncPipe kick ass! It has no rival when we want to display data "reactively" in our component's template.

The async pipe subscribes to an Observable or Promise and returns the latest value it has emitted. When a new value is emitted, the async pipe marks the component to be checked for changes. When the component gets destroyed, the async pipe unsubscribes automatically to avoid potential memory leaks.

Live Example

@Component({
  selector: 'app-first',
  template: `
    <p>first component works!</p>
    <p>{{ timer3$ | async }}</p>
  `,
})
export class FirstComponent implements OnInit, OnDestroy {
  ...

  timer3$ = timer(0, 1000);

  ...
}

Using the AsyncPipe there is no need neither to .subscribe() nor to .unsubscribe() manually.

The RxJS Operators

RxJS is a library for composing asynchronous and event-based programs by using observable sequences. It has some great operators such as:

We won't stand in each of them. We'll see only the usage of takeUntil operator.

Lets values pass until a second Observable, notifier, emits a value. Then, it completes.

At first, I'd like to mention the dangers as described in this article: RxJS: Avoiding takeUntil Leaks. takeUntil operator has to be (usually) the last operator in the pipe.

If the takeUntil operator is placed before an operator that involves a subscription to another observable source, the subscription to that source might not be unsubscribed when takeUntil receives its notification.

Live Example

export class FirstComponent implements OnInit, OnDestroy {
  ...
  private destroy$ = new Subject<void>();

  constructor(private messageService: MessageService) {}

  ngOnInit(): void {
    this.timer1$
      .pipe(takeUntil(this.destroy$))
      .subscribe(
        (val) => this.messageService.add(`FirstComponent timer1$: ${val}`),
        (err) => console.error(err),
        () => this.messageService.add(`>>> FirstComponent timer1$ completed`)
      );

    this.timer2$
      .pipe(takeUntil(this.destroy$))
      .subscribe(
        (val) => this.messageService.add(`FirstComponent timer2$: ${val}`),
        (err) => console.error(err),
        () => this.messageService.add(`>>> FirstComponent timer2$ completed`)
      );
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

Here, destroy$ is our second Observable (notifier), which emits inside ngOnDestroy() lifecycle hook, triggered that way the completion of our data streams. An advantage to this approach is it actually completes the observable and so the complete() callback is called. When we call .unsubscribe() there’s no way we’ll be notified that the unsubscription happened.

The Drawback

All the above solutions actually solve our problem, however they all have at least one drawback: we have to repeat ourselves in each component by implementing ngOnDestroy() for our purpose. Is there any better way to reduce boilerplate furthermore? Yes, we'll take advantage of takeUntil and Angular's DI mechanism.

The DestroyService

Live Example

First, we'll move the ngOnDestroy() into a service:

import { Injectable, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';

@Injectable()
export class DestroyService extends Subject<void> implements OnDestroy {
  ngOnDestroy() {
    this.next();
    this.complete();
  }
}

The FirstComponent both provides the instance of the service (through the providers metadata array) and injects that instance into itself through its constructor:

@Component({
  selector: 'app-first',
  template: `<p>first component works!</p>`,
  providers: [DestroyService],
})
export class FirstComponent implements OnInit {
  ...

  constructor(
    private messageService: MessageService,
    private readonly destroy$: DestroyService
  ) {}

  ngOnInit(): void {
    ...
  }
}

We have the exact same result as the previous one! We can provide an instance of DestroyService in any component that needs it.

Conclusions

Eventually, I think that the preferable way to manage our RxJS subscriptions is by using takeUntil operator via an Angular service. Some benefits are:

Less code
Fires a completion event when we kill our stream
Less chance to forget .unsubscribe() or .next(), .complete() methods in the ngOnDestroy() implementation

GitHub repo with the examples is available here.

SQL: Copy Tables and Massive Update

Theoklitos Bampouris — Sat, 06 Apr 2019 18:59:46 +0000

The road map

There are a lot of times during development where we make a mistake and all or part of our data are gone. Even worse when we lose them due to a bug in our production version.

In this post, we'll see how to create a database table as a backup from an existing one, copy the data, and make a massive update joining these two tables. We'll quote the corresponding SQL statements from different RDBMSs: MariaDB, PostgreSQL, MS SQL Server, IBM DB2, SQLite.

MariaDB

Create the table

CREATE TABLE tbl2 LIKE tbl1;

tbl2 table will inhert all the attributes from tbl1.

Copy the data

INSERT INTO tbl2
SELECT * FROM tbl1;

We may use the WHERE clause to insert only a part of tbl1's data.

Massive update

UPDATE tbl1 a
INNER JOIN tbl2 b ON
a.key = b.key
SET a.column1 = b.column1;

PostgreSQL

Create the table

CREATE TABLE tbl2 ( LIKE tbl1 INCLUDING ALL );

Copy the data

INSERT INTO tbl2
SELECT * FROM tbl1;

Massive update

UPDATE tbl1 a
SET a.column1 = b.column1
FROM tbl2 b
WHERE
a.key = b.key;

MS SQL Server

Create the table and copy all data

SELECT * INTO tbl2
FROM tbl1

Create the table ONLY

SELECT * INTO tbl2
FROM tbl1
WHERE 1 = 0;

Massive update

UPDATE a
SET a.column1 = b.column1
FROM tbl1 a
INNER JOIN tbl2 b ON
a.key = b.key;

IBM DB2

Create the table

CREATE TABLE tbl2 LIKE tbl1;

Copy the data

INSERT INTO tbl2
SELECT * FROM tbl1;

Massive update

UPDATE tbl1 a
SET a.column1 = b.column1
FROM tbl2 b
WHERE
a.key = b.key;

SQLite

Create the table only

CREATE TABLE tbl2 AS
SELECT * FROM tbl1
WHERE 1 = 0;

Copy the data only

INSERT INTO tbl2
SELECT * FROM tbl1;

Create the table and the data at the same time

CREATE TABLE tbl2 AS
SELECT * FROM tbl1;

Massive update

UPDATE tbl1
SET
column1 = (SELECT b.column1
    FROM tbl2 b
    WHERE b.key = tbl1.key)
WHERE tbl1.key IN (SELECT b.key FROM tbl2 b);

In SQLite we may take advantage of the Row Values Method, in the case we want to use more than one key:

UPDATE tbl1
SET
column1 = (SELECT b.column1
    FROM tbl2 b
    WHERE (b.key1, b.key2) = (tbl1.key1, tbl1.key2) )
WHERE (tbl1.key1, tbl1.key2) IN (
  SELECT b.key1, b.key2 FROM tbl2 b);

Originally published at https://www.codingnotebook.eu/sql-copy-tables-and-massive-update/

How to reset your forgotten password in PostgreSQL

Theoklitos Bampouris — Sat, 12 Jan 2019 14:53:58 +0000

The moment you realize the problem

It's a good practice even for your local DB server to provide a password for each user. PostgreSQL's default user (who is also an admin) is postgres.

A standard method to get access to our DB is using psql command via terminal (I'm running Manjaro Linux). So, we type:

psql -U postgres

We enter our password and we get the message

Don't Panic!

First of all, we must find the "PostgreSQL Client Authentication Configuration File", which has the name pg_hba.conf. In Manjaro, it lives in path /var/lib/postgres/data/pg_hba.conf. Be careful that it is required to have root permissions.

sudo nano /var/lib/postgres/data/pg_hba.conf

We change the md5 authentication in "local" connection to trust

local   all             all                                     trust

and we restart our server

sudo systemctl restart postgresql

Now PostgreSQL doesn't ask a password and we are allowed to connent with user postgres

Next step is to reset the password

We exit psql, we turn back pg_hba.conf to it's previous state (md5 authentication) and we restart the server. We are able to connent using our new password for user postgres.

Originally published at https://www.codingnotebook.eu/postgresql-reset-password/

DSPPGM: Display Program

Theoklitos Bampouris — Sat, 12 Jan 2019 14:47:57 +0000

A little bit encyclopedic intro

IBM's iSeries operating system (formely AS/400) is a legacy computer system which is mainly used in Financial Services industry (Banking, Insurance). It supports application development in many programming languages, yet the most famous are COBOL, RPG, CL.

In Feb 1993, IBM first introduced ILE (Integrated Language Environment) for ILE C and in May 1994 COBOL, RPG, CL join the party. ILE is anenvironment in which code from many languages can be compiled, bound together, and run.

So we can see PGMs with attributes CBL (for COBOL/400) and also with CBLLE (for ILE COBOL).

COBOL/400 is the standard COBOL adopted by IBM for the AS/400 system. It differentiates in the sense that the file handling for reports and subfiles, indicator usage and any other feature specific to AS/400 have been incorporated in it.

The problem

You, as a developer, often have to find the source code from which a pgm object was compiled. Someone tells you: "Try the DSPOBJD (Display Object Description) command". Let's do it! Go to command line, write DSPOBJD, press F4 button, fill in the required fields and press ENTER.

Select option 8 and notice the displayed information.

Voilà! The source code is in Library USER04441, in Source file MYFILE, in member EMPCBL. Our problem is solved! Now let's find EF1MAIN's source code. Following the same process:

Wait! What's going on? Where is our information? We have to remember that EF1MAIN is a CBLLE program. When it was compiled it didn't produced directly the executable object, but an intermediate MODULE and from this the PGM was created.

The Solution

There is another command which is more generic: DSPPGM (Display Program). The Display Program Information for a CBLLE program has a lot of screen, so we have to press ENTER until we see:

With 5 option we get:

The source code is in Library USER04441, in Source file SUSANA, in member EF1MAIN.

Now, we really solved our problem!

Originally published at https://www.codingnotebook.eu/dsppgm/

DEV Community: Theoklitos Bampouris

Pi Coding Agent: A Self-Documenting, Extensible AI Partner

The Scenario: Renaming and Enhancing the "Agent" Tool

The Initial Request

Phase 1: Pi Investigates Its Own Structure

Reading the Documentation

Finding the Extension Files

Reading Extension Documentation

Phase 2: Understanding the Implementation

Phase 3: Executing the Changes

Tool Registration Changes

UI Display Updates

Error Message Update

Documentation Updates

Phase 4: Debugging (When Things Go Wrong)

Phase 5: Enhancing the Tool (Feature Addition)

Investigation Phase

The Enhancement

Key Insights: Pi as a Self-Documenting System

1. Documentation is Always Available

2. Extension System is First-Class

3. Three-Level Model Fallback System

4. Skills System for Specialized Knowledge

What This Demonstrates

You Can Ask Pi About Itself

Pi Can Modify Its Own Code

Extensions Are Powerful

The Philosophical Point

Try It Yourself

Conclusion

Revolutionizing Git Workflows: The MCP Git Commit Generator

Introduction

What is the MCP Git Commit Generator?

Key Features at a Glance

The Problem It Solves

Before: The Commit Message Struggle

After: Intelligent Automation

Technical Architecture

Core Components

MCP Tools Exposed

1. generate_commit_message

2. check_git_status

Transport Flexibility

Integration Ecosystem

MCP Client Support

VS Code Integration

Claude Desktop, Cursor, and Windsurf

Docker-First Approach

Real-World Usage Scenarios

Scenario 1: Feature Development

Scenario 2: Bug Fixes

Scenario 3: Documentation Updates

Development and Debugging

Inspector UI

Development Workflow

Technical Innovation

AI-Powered Analysis

Conventional Commits Compliance

Performance and Reliability

Lightweight Design

Error Handling

Future Implications

Potential Enhancements

Getting Started

Quick Setup

For Developers

Conclusion

Setup Unit Testing Tools in Angular CLI Project

The Defaults of an Angular CLI Generated Project

Remove Karma & Jasmine Related Packages

Install Jest

Setup Jest in our Project

Last But Not Least

Avoid Memory Leaks in Angular

Our Road Map

The Bad Open Subscriptions

Unsubscribe the Old Way

The Async Pipe

The RxJS Operators

The Drawback

1. `generate_commit_message`

2. `check_git_status`