Forem: Antonio

# TRAE.ai with Memory: No More Re-briefing, 98% Time Saved

Antonio — Tue, 14 Oct 2025 17:57:41 +0000

Or: how I went from 8 minutes of "re-briefing" to 10 seconds with a continuity system for **TRAE IDE**

If you've ever used an AI assistant for programming, you know this frustration. You work for two hours on a project, maybe implement some features, write tests, make architectural decisions. Then you close the chat and go to sleep. The next day, you open a new conversation and the AI greets you with a cheerful "Hi! How can I help you?"

And you think: what do you mean, we worked together for hours yesterday!

So you start over. "So, I'm developing a CLI in Python. The structure is this. I use these patterns. The decisions we made are these." Eight minutes later you're back to the starting point, ready to continue working. But the flow is broken, concentration lost, and you wonder if it has to be this way.

Spoiler: it doesn't. And I just finished testing a system that proves it.

I recently discovered the coding assistant TRAE.ai. I downloaded the free version and after a few days I decided to purchase a monthly subscription, so I could do further testing and understand its potential. After these steps and discovering the existence of user_rules.md and project_rules.md files, I thought: Why not test these files by creating custom commands?

The Basic Idea

The concept is simple: instead of re-explaining everything every time, why not create a file where everything you do is automatically documented? I'm not talking about a README or code comments - the AI already reads those. I mean a real work session log that updates itself and contains everything: the changes made, the files touched, the decisions taken, what remains to be done.

At the beginning of each new session, just one command - LOADAGG - and the AI reads this log. In ten seconds it has loaded all the context and can continue as if it were the same conversation from yesterday.

Sounds too good to be true? I was skeptical too. That's why I decided to test it seriously before talking about it.

The Test of Truth

Before explaining how the system works, I want to show you proof that it really works. Because it's one thing to claim "the AI remembers everything", another to prove it.

I opened a new chat in TRAE, typed LOADAGG and waited ten seconds while the AI loaded the log file. Then, without giving any additional context, I asked four technical questions about the project.

First question: "How is the TODO object structured in the JSON file?"

The answer came immediately and precisely. The AI explained that the structure is {id, title, done, created}, described the type of each field, and even told me where in the code this structure is defined - all without asking "which project?" or "what are we talking about?".

Second question: "How do we handle persistence?"

Again, immediate answer. It told me that TODOs are saved in todos.json in the project root, formatted with indent=2, managed by specific functions in the todo.py file, and that the JSON file is excluded from versioning. All technical details it couldn't know if it hadn't loaded the complete context.

Third question: "What dependencies does the project use?"

It answered that the only dependency is pytest for tests, and there are no runtime dependencies - the project only uses Python's standard library.

Fourth question: "How many tests do we have and which ones?"

The AI listed all eight tests present in the project, naming them one by one. Not "about eight tests" or "some tests" - it named them all with the exact function names.

Four questions, four perfect answers, zero clarification requests. This isn't "it seems the AI remembers something". This is "it has completely memorized the context from a Markdown file and can work as if it were the continuation of yesterday's conversation".

How It Works

The system runs on TRAE IDE, which is an interesting coding assistant because it natively supports "rules files" - Markdown files that define how the AI should behave in that specific project. I leveraged this functionality to implement a continuity system based on three main files.

The first file, UPDATE_PR.md, is the heart of the system. It's the session log I mentioned before. Every time you finish working, you type SAVEAGG and the AI automatically generates a chapter in this file. The chapter contains everything: a summary of what you did, which files you modified or created, the technical decisions made, the current project status, what remains to be done. You don't have to write anything by hand - the AI analyzes the conversation and extracts all this information.

The second file, PROMPT.md, is a library of reusable prompts. If you have a type of request you make often - like "scan the project for possible optimizations" - you can save that prompt here and reuse it in new chats without having to rewrite it every time.

The third file, STRUTTURA_PROGETTO.md, is technical documentation that updates automatically. When you make important changes to the architecture or add relevant features, the DOCUPDATE command updates this file. At the end of the project you end up with complete documentation without having dedicated explicit time to writing it.

There are four commands in total:

Command	When	What it does
`SAVEAGG`	End of session	Saves everything in UPDATE_PR.md
`LOADAGG`	Start of session	Loads context in 10 seconds
`DOCUPDATE`	After important changes	Updates STRUTTURA_PROGETTO.md
`SAVETEST`	System validation	Documents if commands work

SAVEAGG saves the state at the end of a session. LOADAGG loads the context at the beginning of the next session. DOCUPDATE updates the technical documentation when needed. And SAVETEST I used during testing to document whether the commands were working correctly.

The Test Project

To test the system I used a real project, not a toy example. I developed a terminal TODO manager in Python - simple enough to complete in a week, complex enough to require multiple work sessions and architectural decisions.

Project Specifications

Aspect	Detail
CLI Commands	`add`, `list`, `done`, `delete`, `clear`
Storage	JSON file (local persistence)
Tests	pytest - 8 total tests
Size	~150 lines of Python
Sessions	5 work sessions
Total duration	~55 minutes pure development

The project implements five commands: add a TODO, list TODOs, mark a TODO as completed, delete a TODO, and completely clear the list. Data is saved in a JSON file and I wrote eight tests with pytest to verify everything works correctly.

Session Timeline

Session	Date/Time	Work Done	Tests	Time
#01	12 Oct, 08:30	Setup + `add` command	3/3 ✅	~15 min
#02	12 Oct, 09:15	`list` command (after LOADAGG)	5/5 ✅	~12 min
#03	12 Oct, 10:00	`done` command	6/6 ✅	~10 min
#04	12 Oct, 14:30	`delete` + `clear` commands	8/8 ✅	~10 min
#05	13 Oct, 09:00	Cleanup and final validation	8/8 ✅	~8 min

I divided the work into five sessions. In the first session I created the basic structure and implemented the command to add TODOs. At the end of the session I typed SAVEAGG and the AI generated the first chapter in UPDATE_PR.md, documenting everything we had done.

The second session was the real test. I opened a new chat - so the AI had no memory of the previous session - I typed LOADAGG and waited ten seconds. Then I simply asked: "Implement the list command".

The AI didn't ask me "which project?". It didn't ask me "how is the code structured?". It didn't ask me "where are the files?". It simply implemented the command, following the style of the existing code, using the same conventions, integrating perfectly with the architecture we had established the day before. Because it had loaded all the context from UPDATE_PR.md.

The subsequent sessions followed the same pattern. New chat, LOADAGG, continue working without wasting time re-explaining. At the end: SAVEAGG, and the log updates automatically.

The Numbers

After five work sessions and about fifty-five total minutes of development, I collected the data.

Tested Commands

Command	Times Used	Functioning	Average Time
`SAVEAGG`	4 times	✅ 4/4 (100%)	~5 sec
`LOADAGG`	5 times	✅ 5/5 (100%)	~10 sec
`DOCUPDATE`	4 times	✅ 4/4 (100%)	~3 sec
`SAVETEST`	6 times	✅ 6/6 (100%)	~2 sec

All four main commands worked perfectly on all occasions I used them. Zero critical issues, zero errors that blocked the workflow.

Memory Test

Methodology: New chat, LOADAGG, then 4 technical questions without additional context.

Question	AI Response	Result
TODO object schema in JSON	Complete structure with types and code location	✅ Correct
How do we handle persistence	Details on file, format, functions, .gitignore	✅ Correct
What dependencies does the project use	Precise list: only pytest for tests	✅ Correct
How many tests and which ones	All 8 tests listed by name	✅ Correct

Score: 4/4 (100%) - The AI answered all questions correctly without asking for clarifications.

Time Savings

Metric	Value
Sessions with LOADAGG	5
Total LOADAGG time	~50 seconds (10 sec × 5)
Time without system (estimated)	~40 minutes (8 min × 5)
Net savings	39 minutes 10 seconds
Percentage saved	98%

And the time savings were measured precisely. It's not theory. It's real time saved with a stopwatch.

How It Feels in Practice

Numbers are important, but what really matters is how the work experience changes. And here there's a huge difference.

Before the system, every new session started with a "warm-up" phase. I had to re-explain the context, the AI asked clarifying questions, I provided details, a necessary but frustrating dialogue was created before being able to actually work. It was like having to repeat the same story every day to a person with amnesia.

With the system, you open the chat, type LOADAGG, wait ten seconds, and you're already at work. There's no warm-up phase. No clarifying questions. No cognitive friction. It's like picking up a book where you left it.

Let me give you a concrete example from the fourth test session. I had just implemented the delete and clearcommands and wanted to update the README with usage examples for these new commands. I simply typed: "Update README with delete/clear examples".

The AI read the existing README, understood the style we were using, followed the formatting conventions already established, created examples consistent with those of the other commands, and updated the file. Zero questions, zero hesitation. It worked exactly as if it were the continuation of the same conversation, because from its point of view it was - it had the complete context.

This is the real value of the system. It's not just time savings in a quantitative sense. It's elimination of friction, it's maintenance of workflow, it's the difference between feeling frustrated and feeling productive.

What I Didn't Test

I want to be honest about the limits. I tested the four main commands and they work. But the system I implemented in the project rules also includes some advanced features I didn't get to try.

For example, there's a LOADAGG LIST command that should show a history of all updates in tabular format. There's LOADAGG DIFF that should allow comparing two different project states. There's LOADAGG #number to load a specific update instead of the latest. And there's LISTPROMPT to see all saved prompts.

These features are defined in the rules and the logic seems solid, but I didn't test them in practice. So I can't guarantee they work. They might even work perfectly, but I simply don't know.

Another limit: the test project was relatively small, about one hundred fifty lines of code. Does it scale to large projects? I didn't verify. The principle should hold - the more complex the project, the more valuable having a session log becomes - but I don't have empirical data on projects with thousands of lines.

And obviously this system is specific to TRAE IDE. It works because TRAE natively supports rules files. You could adapt the concepts to other AI assistants, but it wouldn't be as smooth because they don't have this integrated functionality.

If I Had to Do It Again

With hindsight, there are a couple of things I would do differently.

The memory test, the one with the four questions, I did it at the end after completing all development sessions. But in reality it's the most important test - it's the definitive proof that the system works. If I had to start over, I would do it immediately in the second session, to have immediate confirmation that LOADAGG is really loading the complete context.

For the test project, one hundred fifty lines were fine, but probably fifty-eighty would have been enough to validate the system. Something even simpler would have allowed focusing exclusively on testing the commands without distractions.

And I would create a checklist to follow before each session. Like: "Before continuing, verify that LOADAGG worked by asking these four specific questions". Having a standardized procedure helps ensure the system is working as it should.

Perspectives

This is a proof of concept on a small project. But the potential is much bigger.

Imagine working on a project that lasts weeks or months. Every day you add a chapter to the log. After a month you have a complete chronology of everything that was done, all the decisions made, all the problems solved. You no longer have to ask yourself "why did I make this choice three weeks ago?" - it's documented.

Or imagine a team collaborating with AI. Each team member can read UPDATE_PR.md and see exactly where the project stands, what choices were made, what remains to be done. The knowledge base grows automatically instead of being lost.

There are many directions this could evolve. Automatic saving every fifteen minutes. Named checkpoints like in Git, to be able to return to specific states. Automatic export of documentation in different formats. Productivity metrics. But for now it's a working system that solves a real problem.

The Package on GitHub

After testing the system, I prepared a complete ready-to-use package. Sixteen files organized in a modular structure: system rules (12 commands), output examples, setup guides and documentation.

The package is generic, in both Italian and English, works with any project in TRAE IDE. Clone the repository, copy the .trae/ folder to your project root, and you have the system active. Three main commands (SAVEAGG, LOADAGG, DOCUPDATE, SAVETEST and TESTREPORT) and you're operational.

You don't have to understand how it works internally, you don't have to configure anything. It's plug-and-play. The repository also includes real examples of UPDATE_PR.md from the test project, so you immediately see what the session log looks like in practice.

Link: GitHub Repository

In Summary

Does it work? Yes, I tested it and the data confirms it. Is it perfect? No, there are features I didn't try and limits to consider. Is it useful? Absolutely yes, at least for how I work.

Validation Summary

Criterion	Minimum Target	Result Obtained	Status
Working commands	≥ 90%	4/4 (100%)	✅ Passed
Memory test	≥ 3/4 (75%)	4/4 (100%)	✅ Passed
Time savings	≥ 80%	98%	✅ Passed
Critical issues	0	0	✅ Confirmed

The numbers say that four out of four commands worked, that the memory test gave four correct answers out of four, and that I saved ninety-eight percent of the time I would have otherwise lost re-explaining the context.

But numbers aren't everything. The real change is in the workflow. It's going from "damn, I have to re-explain everything" to "LOADAGG, perfect, let's continue". It's working with an AI that remembers instead of one that forgets. It's eliminating that frustrating friction that breaks concentration.

For me it was worth it. If you work on projects that require multiple sessions and use TRAE IDE, it might be worth it for you too. The system is there, ready to use. Just copy the rules file to your project and start with SAVEAGG and LOADAGG.

And if you try it, I'd be curious to know how it goes. The most interesting tests are those on different projects, bigger, more complex. My data covers a specific use case - the real validation comes from replicability on different cases.

Written on October 13, 2025 - by Antonio Demarcus. Tested on TRAE IDE 1.3.0+ with a Python project of ~150 lines developed in 5 sessions. Measured data: 4/4 working commands, 4/4 memory tests, 98% time savings.

KillPort Advanced v2.0:Evolution of a Port Management Tool for macOS

Antonio — Mon, 06 Oct 2025 15:41:00 +0000

During daily development, we've all dealt with the frustration of processes that won't release ports. The classic workflow of lsof -i :8080, copying the PID, then kill -9 becomes repetitive and tedious.

An excellent solution already existed: killport by jkfran, a blazing-fast cross-platform tool written in Rust. I used it for months and it works great. However, for my specific needs on macOS, I wanted something more: integrated monitoring, interactive mode, advanced range management. So I created KillPort Advanced v2.0.

Why Start from jkfran's killport?

Before explaining what I built, it's essential to give credit to jkfran. His killport is:

Blazing fast: written in Rust, excellent native performance
Cross-platform: works on macOS, Linux, Windows
Minimal: does one thing and does it well
Reliable: used by thousands of developers

Without this project as a benchmark reference, I wouldn't have had solid comparison parameters. My work was to build on top of these standards, adding specific features for more complex workflows.

My Approach: Advanced Shell Script

I chose to write a pure ZSH function for several reasons:

Zero dependencies: no compilation, no binaries
Native integration: blends with the macOS terminal
Easy to modify: just edit a script
Instant installation: source and go

The challenge was maintaining performance comparable to an optimized Rust binary.

Extended Features

Flexible Management

# Single port
killport 3000

# Multiple ports
killport 3000 4000 8080

# Port range
killport 8000-8010

Interactive Mode

kpi  # Alias for --interactive

# Output:
# Listening processes:
# #    PORT     PROCESS           PID     
# 1    3000     node              1234    
# 2    8080     python3           5678    
# Select number (or 'q' to quit):

Integrated Monitoring

ports      # List all ports (alias for --list)
netstats   # Detailed network statistics (alias for --stats)

Watch Mode

killport --watch 3000
# Continuously monitors and auto-kills

Security

Protected ports (22, 80, 443, 3306, 5432) with mandatory confirmation
Dry-run mode (--dry-run)
Operation history (kph)

The Benchmark: Honest Comparison

I wanted to do a serious comparison with jkfran's killport installed via Homebrew. I created a complete benchmark suite that tests 5 different scenarios with detailed statistics.

Methodology

For each test I calculated:

Min (ms): minimum time
Max (ms): maximum time
Avg (ms): average time
StdDev (σ): standard deviation (consistency)

Tests performed:

Kill single port (5 iterations)
Kill 3 simultaneous ports (5 iterations)
Kill range of 21 ports (3 iterations)
List ports - Advanced only
Network statistics - Advanced only

Detailed Results

TEST 1: Kill Single Port

Tool	Min	Max	Avg	StdDev	Winner
killport (brew)	25ms	25ms	25ms	±0ms	✅
KillPort Advanced	27ms	27ms	27ms	±0ms

Difference: brew faster by 2ms (7%)

TEST 2: Kill 3 Simultaneous Ports

Tool	Min	Max	Avg	StdDev	Winner
KillPort Advanced	31ms	31ms	31ms	±0ms	✅
killport (brew)	32ms	32ms	32ms	±0ms

Difference: Advanced faster by 1ms (3%)

TEST 3: Range of 21 Ports (9100-9120)

Tool	Min	Max	Avg	StdDev	Result
KillPort Advanced	20ms	20ms	20ms	±0ms	⚖️
killport (brew)	20ms	20ms	20ms	±0ms	⚖️

Result: Identical performance

TEST 4 & 5: KillPort Advanced Exclusive Features

Feature	Time	Notes
`--list`	22ms	Lists active ports
`--stats`	22ms	Network statistics

Interpretation

Performance is virtually identical - we're talking about 2ms differences that are imperceptible in daily practice. The standard deviation of 0 indicates that both tools are extremely consistent and reliable.

According to BENCHMARK_GUIDE parameters:

✅ All tests < 30ms = Excellent
✅ σ = 0ms = Very consistent

Which One to Choose?

killport (brew) by jkfran - When to use it

✅ You want the bare minimum essentials

✅ You need cross-platform support (Linux, Windows)

✅ You prefer compiled binaries

✅ Pure performance is top priority

Installation: brew install killport

KillPort Advanced v2.0 - When to use it

✅ You work exclusively on macOS

✅ You need integrated monitoring (--list, --stats)

✅ You want interactive mode and watch mode

✅ You prefer easily modifiable shell scripts

✅ You need protections for critical ports

Installation:

git clone https://github.com/AntonioDEM/killport-advanced.git
cd killport-advanced
bash install_killport.sh
source ~/.zshrc

Simplified Installation

The automatic installer:

Finds source files
Configures everything automatically
Creates convenient aliases (kp, kpi, ports, netstats, kph)
Includes uninstaller (killport-uninstall)

Practical Examples

Web Development

# Express server stuck
killport 3000

# Multiple services
killport 3000 4000 8080

# Complete environment cleanup
killport 3000-3010

Debugging

# What's occupying ports?
ports

# Who's using most connections?
netstats

Automation

# Continuous auto-kill
killport --watch 3000 &

Reproducible Benchmarks

I included the complete suite to allow anyone to verify the results:

cd killport-advanced/benchmark

# Run benchmark
./benchmark_original.sh

# Visualize with ASCII charts
./benchmark_visualizer_original.sh

Generated outputs:

benchmark_results_TIMESTAMP.txt - Detailed report
benchmark_results_TIMESTAMP.csv - Data for analysis
benchmark_charts_TIMESTAMP.txt - ASCII charts (export)
benchmark_report_TIMESTAMP.md - Markdown report (export)

Complete guide: BENCHMARK_GUIDE.md

Results Transparency

I chose to publish all results, including those where jkfran's killport is faster. Honesty is fundamental: I'm not trying to "beat" the original project, but to offer an alternative with different features for different needs.

The 2ms difference in TEST 1 is negligible and probably related to the overhead of a shell function vs a compiled binary. But I gain monitoring, interactivity, and flexibility.

What I Learned

This project taught me:

Serious benchmarking: how to test correctly and honestly
Advanced shell scripting: complex argument and state management
Performance tuning: optimizing scripts to compete with binaries
Documentation: the importance of clear guides and examples

Credits and Acknowledgments

jkfran for original killport - fundamental as reference
The open source community for feedback and support
All project contributors

Useful Links

KillPort Advanced Repository: github.com/AntonioDEM/killport-advanced
Original killport Repository: github.com/jkfran/killport
Complete Benchmark Report: benchmark_report_20251005_214913.md
Benchmark Guide: BENCHMARK_GUIDE.md
Detailed Comparison: Confronto_con_brew.md

Conclusions

KillPort Advanced v2.0 doesn't want to replace jkfran's killport - that would be presumptuous. It's a macOS-specific evolution that adds advanced features while maintaining comparable performance.

If you're looking for a cross-platform, fast, and minimal tool, use jkfran's killport.

If you work on macOS and want monitoring, interactivity, and protections, try KillPort Advanced.

Both are open source, both work great.

If you find this project useful, leave a star on GitHub. And if you have suggestions or bugs, PRs are welcome.

Complete Guide to Git for Multi-Platform Development: From Mac to Windows Without Conflicts

Antonio — Thu, 02 Oct 2025 07:39:22 +0000

Introduction: The Problem Every Cross-Platform Developer Knows

Raise your hand if you've never found yourself in this situation: you work on a project on your Mac at the office, come home, open your Windows laptop, do a git pull and... boom! Conflicts everywhere. Files that appear modified even though you've never touched them. Configurations that don't work. Paths that don't exist. Line endings gone crazy.

If you recognized yourself in this description, this article is for you. After months of work on my Smart Conda Terminal project – a VSCode extension that needs to work perfectly on both macOS and Windows – I learned (often the hard way) how to manage a truly multi-platform Git workflow.

In this article, I'll share everything I've learned: from initial configuration to best practices, from tricks to avoid conflicts to solutions for the most common problems. Not a theoretical guide, but a practical manual born from field experience.

Why is Multi-Platform Development So Complicated?

Before diving in, let's understand why Git makes our lives difficult when we work on different operating systems:

1. Paths are Different

// macOS
"python.defaultInterpreterPath": "/Users/tony/miniconda3/envs/sct-dev/bin/python"

// Windows
"python.defaultInterpreterPath": "C:\\Users\\Tony\\miniconda3\\envs\\sct-dev\\python.exe"

2. Line Endings are Different

Unix/Mac use LF (Line Feed: \n)
Windows uses CRLF (Carriage Return + Line Feed: \r\n)

Result? Git sees every single file as modified, even if you haven't changed a comma.

3. Shell Scripts Don't Work on Windows

Bash scripts that run perfectly on Mac? On Windows you need PowerShell or WSL.

4. VSCode Configurations are Platform-Specific

Terminal profiles, conda paths, interpreter settings... all different.

The Strategy: One Repository, Two Platforms, Zero Conflicts

The solution I developed is based on three principles:

Shared configurations for everything that is platform-agnostic
Local files ignored by Git for platform-specific paths and settings
Intelligent automation that detects the platform

Let's see how to implement it step by step.

Initial Setup: Preparing the Ground

1. Cross-Platform Git Configuration

First of all, let's configure Git correctly on both platforms:

# Name and email (same on both)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# Line endings - CRUCIAL to avoid conflicts
# On Mac/Linux:
git config --global core.autocrlf input

# On Windows:
git config --global core.autocrlf true

# Editor and other useful settings
git config --global core.editor "code --wait"
git config --global push.default simple
git config --global color.ui auto

2. The .gitattributes File: The Line Endings Savior

Create this file in the project root and commit it:

text

# .gitattributes
* text=auto eol=lf
*.sh text eol=lf
*.js text eol=lf
*.json text eol=lf
*.md text eol=lf
*.py text eol=lf

# Binary files
*.png binary
*.jpg binary
*.ico binary

This file tells Git: "Whatever the operating system, always use LF internally, and let the local system decide how to save files."

3. The Intelligent .gitignore

A well-crafted .gitignore is essential. Here's mine:

# Dependencies
node_modules/
.node_modules/
npm-debug.log*
package-lock.json

# Build outputs
out/
dist/
*.vsix

# OS files - Here's the trick!
.DS_Store          # macOS
Thumbs.db          # Windows
*.swp
*.swo

# IDE - Keep only shared configs
.vscode/settings.json.local
.vscode/*.local.json

# IMPORTANT: DO NOT ignore these
!.vscode/settings.json
!.vscode/launch.json
!.vscode/extensions.json
!.vscode/tasks.json

# Logs and cache
*.log
.npm
.cache/

# Environment
.env
.env.local

# Conda specific
.smart-conda-terminal/
conda-meta/

The key is in the IDE section: we keep shared configurations (with !) but ignore local ones.

Project Structure: What to Commit and What Not

project/
├── .vscode/
│   ├── settings.json       ← COMMITTED (general settings)
│   ├── launch.json         ← COMMITTED (debug config)
│   ├── extensions.json     ← COMMITTED (recommended extensions)
│   └── tasks.json          ← COMMITTED (common tasks)
├── .gitattributes          ← COMMITTED
├── .gitignore              ← COMMITTED
├── package.json
├── src/
└── project.code-workspace  ← OPTIONAL, see below

The Secret: Two-Level Configurations

Level 1: Shared Settings (.vscode/settings.json - committed)

{
    "editor.formatOnSave": true,
    "editor.insertSpaces": true,
    "editor.tabSize": 2,
    "files.trimTrailingWhitespace": true,
    "files.exclude": {
        "out": false,
        "dist": true,
        "node_modules": true,
        "**/.DS_Store": true,
        "**/Thumbs.db": true
    }
}

Level 2: Workspace with Environment Variables (optional)

Instead of hard-coded paths, use variables:

{
    "folders": [{"path": "."}],
    "settings": {
        "python.defaultInterpreterPath": "${env:CONDA_PREFIX}/bin/python",
        "python.terminal.activateEnvironment": true
    }
}

On Windows, ${env:CONDA_PREFIX} will automatically resolve to the correct path.

Daily Workflow: The Four Commandments

1. Before Starting: PULL

cd your-project
git pull origin main

Simple but fundamental. Avoids 90% of conflicts.

2. During Work: Small and Frequent Commits

❌ Bad:

# After 3 days...
git commit -m "various changes"

✅ Good:

git commit -m "feat: Add Windows terminal profile support"
git commit -m "fix: Python path resolution on Windows"
git commit -m "docs: Update cross-platform setup guide"

3. Before Finishing: Verify

# What did I modify?
git status

# See the differences in detail
git diff

# Everything ok? Add
git add .

# Commit with clear message
git commit -m "feat: Implement auto-platform detection"

4. When You Finish: PUSH

git push origin main

Conflict Management: Real Situations and How to Solve Them

Scenario 1: "Your local changes would be overwritten"

The problem: You have uncommitted local changes and do git pull.

The solution (stash method):

# 1. Set aside your changes
git stash

# 2. Download updates
git pull origin main

# 3. Reapply your changes
git stash pop

# 4. If there are conflicts, resolve them manually

Scenario 2: Merge Conflicts

When Git can't merge automatically, you'll see this:

<<<<<<< HEAD
const version = "1.0.0";  // Your version
=======
const version = "2.0.0";  // Remote version
>>>>>>> origin/main

How I solve it:

Open the file in VSCode
Decide which version to keep (or merge both)
Remove the markers <<<<<<<, =======, >>>>>>>
Save and commit:

git add conflicted-file.js
git commit -m "resolve: Merge conflict in version number"
git push origin main

Scenario 3: Crazy Line Endings

Symptoms: Git shows modified files even though you haven't touched them.

Diagnosis:

git diff file.js
# If you only see "^M" or invisible differences, it's line endings

Cure:

# 1. Add .gitattributes (if not already there)
# 2. Normalize all files
git add --renormalize .
git commit -m "fix: Normalize line endings"
git push origin main

Automation Scripts: Platform Detection

For scripts that need to work everywhere:

#!/bin/bash

# Detect platform
detect_platform() {
    case "$(uname -s)" in
        Darwin*)    echo "mac" ;;
        Linux*)     echo "linux" ;;
        MINGW*|MSYS*|CYGWIN*)  echo "windows" ;;
        *)          echo "unknown" ;;
    esac
}

# Get correct conda path
get_conda_path() {
    PLATFORM=$(detect_platform)

    case $PLATFORM in
        mac|linux)
            echo "$HOME/miniconda3"
            ;;
        windows)
            echo "$USERPROFILE/miniconda3"
            ;;
    esac
}

# Use the function
CONDA_PATH=$(get_conda_path)
echo "Conda path: $CONDA_PATH"

Best Practices: The Golden Rules

1. Meaningful Commit Messages

I use the Conventional Commits format:

feat: Add new feature
fix: Fix bug
docs: Update documentation
style: Code formatting
refactor: Code restructuring
test: Add tests
chore: General maintenance

2. Pull Requests for Important Changes

# Create a branch for the feature
git checkout -b feature/new-feature

# Work on the branch
git add .
git commit -m "feat: Implement new feature"

# Push the branch
git push origin feature/new-feature

# On GitHub: create Pull Request
# After review: merge to main

3. Don't Commit Generated Files

Never ever commit:

node_modules/
Build outputs (dist/, out/)
Log files
Local configurations
Credentials

4. Test on Both Platforms Before Pushing

Personal checklist:

Does the code work on Mac?
Does the code work on Windows?
Do tests pass on both?
Is the documentation updated?
Is the commit message clear?

Troubleshooting: The Most Common Problems

"Permission denied (publickey)"

Problem: Git can't connect to GitHub.

Solution:

# Generate SSH key
ssh-keygen -t ed25519 -C "your.email@example.com"

# Copy the key
# Mac:
pbcopy < ~/.ssh/id_ed25519.pub
# Windows:
cat ~/.ssh/id_ed25519.pub | clip

# Add it on GitHub: Settings → SSH Keys

# Test
ssh -T git@github.com

"Repository too large"

Problem: The repository has become huge.

Solution:

# Remove untracked files
git clean -fd

# Compress
git gc --aggressive --prune=now

"Detached HEAD state"

Problem: You checked out a specific commit.

Solution:

# Return to main branch
git checkout main

Tools That Simplify Life

1. GitHub Desktop

Simple and intuitive GUI, perfect for beginners.

2. GitKraken

Advanced graphical visualization of branches and history.

3. VSCode Built-in Git

My favorite. Perfect integration with the editor.

4. Git Aliases

Shortcuts for frequent commands:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"

Now I can do git st instead of git status.

Conclusion: The Perfect Workflow Exists

After months of experimentation, my daily workflow has been reduced to this:

Morning (start work):

git pull origin main

Evening (end work):

git status
git add .
git commit -m "feat: Clear description"
git push origin main

In case of problems:

git stash
git pull origin main
git stash pop

Simple, right? The key is in the correct initial configuration. Once everything is set up properly, Git becomes an ally, not an enemy.

Final Checklist for Your Project

.gitattributes configured for line endings
Complete and tested .gitignore
Multi-platform Git configuration (core.autocrlf)
Two-level VSCode settings (shared + local)
Scripts with automatic platform detection
SSH keys configured on both platforms
Workflow documented for the team
Tests on both operating systems

Useful Resources

Pro Git Book - The Git bible, free
Git Cheat Sheet - Essential commands
Conventional Commits - Standard for commit messages
GitHub Flow - Workflow with branches

Do you have questions or suggestions? Write to me in the comments! This workflow is constantly evolving and I'm always curious to discover how other developers handle the same problem.

If the article was useful to you, leave a clap 👏 and share it with other developers who work on multiple platforms!

Final note: All the code and configurations shown in this article are taken from my real project Smart Conda Terminal, a VSCode extension for intelligent management of Conda environments. The repository is public and can serve as a practical example of what's described here.

Tags: #GitHub #VSCode #Python #NodeJS #DeveloperTools #Conda #ExtensionDevelopment #JavaScript #Productivity #OpenSource

How I Built My First VS Code Extension to Solve the Conda Environment Headache

Antonio — Thu, 02 Oct 2025 06:53:54 +0000

The Problem That Drove Me Crazy

Picture this: You're a developer working on multiple Python or Node.js projects. Each project has its own conda environment with specific dependencies. Every single time you open a terminal in VS Code, you have to remember to type:

conda activate my-project-env

Forget to do this? Your code breaks. Wrong environment? Dependencies missing. Different project? Different environment to remember.

After the hundredth time of forgetting to activate the right environment and spending 10 minutes debugging why my imports weren't working, I thought: "There has to be a better way."

The Journey: From Frustration to Solution

As a developer who works primarily with Python data science projects and some Node.js side projects, I was constantly switching between environments. The mental overhead was real:

Project A: conda activate datascience-env
Project B: conda activate webapp-env
Project C: conda activate ml-research

I started looking for existing solutions. There were a few VS Code extensions that helped with Python environments, but nothing that gave me the seamless, zero-friction experience I wanted for both Python and Node.js projects.

That's when I decided: "I'm going to build this myself."

What I Built: Smart Conda Workspace

Smart Conda Workspace is a VS Code extension that automatically configures your terminal to use the right conda environment for your project. No more manual conda activate commands. No more forgetting which environment goes with which project.

Key Features:

✅ Zero-friction setup: One command to configure everything
✅ Multi-language support: Works with Python AND Node.js projects
✅ Cross-platform: Windows, macOS, and Linux
✅ Multi-shell support: Automatically detects and configures Zsh, Bash, or PowerShell
✅ Project memory: Saves settings in a .conda.workspace file

How It Works (The Technical Bits)

The extension leverages VS Code's powerful Extension API to:

Detect available conda environments using the conda CLI
Integrate with VS Code's terminal system to modify shell initialization
Persist configuration at the project level
Auto-configure shell profiles (.zshrc, .bashrc, PowerShell profiles)

Here's the user flow:

1. Open your project in VS Code
2. Press Cmd+Shift+P (or Ctrl+Shift+P)
3. Type "Smart Conda: Configure Workspace"
4. Select your desired conda environment
5. That's it! Terminal automatically uses the right environment

The Magic Behind the Scenes

When you configure a workspace, the extension:

Detects your shell type (Zsh/Bash/PowerShell)
Modifies the VS Code terminal integration settings
Creates a .conda.workspace file to remember your choice
Sets up automatic environment activation for future sessions

Why I Chose JavaScript Over TypeScript

As a first-time extension developer, I made the deliberate choice to use vanilla JavaScript instead of TypeScript. Here's why:

Faster iteration: No compilation step meant faster testing cycles
Simpler debugging: Direct source-to-runtime mapping
Lower complexity: One less layer of abstraction to learn
Immediate gratification: Code changes reflected instantly

While TypeScript has its advantages for larger projects, JavaScript was perfect for this focused solution.

The Development Process

Research Phase (Week 1)

Studied VS Code Extension API documentation
Analyzed existing conda/Python extensions
Understood terminal integration capabilities
Researched cross-platform shell differences

MVP Development (Week 2-3)

Built basic environment detection
Implemented VS Code command registration
Created simple UI for environment selection
Added basic error handling

Polish Phase (Week 4)

Added cross-platform support
Implemented persistent configuration
Created proper workspace integration
Added comprehensive error handling

Publishing (Week 5)

Created marketplace assets
Wrote documentation
Set up GitHub repository
Published to VS Code Marketplace

Challenges I Faced

1. Cross-Platform Shell Differences

Different operating systems use different shells with different syntax:

macOS/Linux: Bash/Zsh with POSIX-style commands
Windows: PowerShell with completely different syntax

Solution: Dynamic shell detection and platform-specific configuration generation.

2. VS Code Terminal Integration Complexity

VS Code's terminal system is powerful but complex. Understanding how to properly integrate with terminal profiles took significant research.

Solution: Deep dive into VS Code's terminal API documentation and studying existing extensions.

3. Conda CLI Variations

Different conda installations (Miniconda vs Anaconda) can have slightly different behaviors.

Solution: Robust error handling and fallback mechanisms.

What I Learned

Technical Skills

VS Code Extension API: Deep understanding of commands, configuration, and terminal integration
Cross-platform development: Handling different OS environments gracefully
Shell scripting: Working with Bash, Zsh, and PowerShell programmatically

Product Development

User experience design: Reducing friction is everything
Documentation importance: Clear setup instructions are crucial
Iteration value: Start simple, add complexity gradually

Personal Growth

Shipping mindset: Perfect is the enemy of done
Problem-solving approach: Sometimes you have to build the tool you need
Open source contribution: The joy of solving problems for others

The Impact

Since publishing Smart Conda Workspace, I've received feedback from developers who were facing the exact same frustration. The solution resonated because it addressed a real, daily pain point.

Key metrics after launch:

Downloads from VS Code Marketplace growing steadily
Positive user reviews highlighting time savings
Feature requests showing real-world usage
Other developers contributing ideas and improvements

What's Next

The extension works great for its core use case, but there's always room for improvement:

Planned Features:

Auto-detection: Automatically suggest environments based on project files
Environment creation: Create new conda environments directly from VS Code
Dependency management: Integration with environment.yml files
Team sharing: Better support for team environment configurations

Technical Improvements:

Performance optimization: Faster environment detection
Better error messages: More helpful troubleshooting guidance
Integration expansion: Support for more project types

For Fellow Developers: Key Takeaways

1. Start with Your Own Pain Points

The best projects solve problems you personally experience. If it annoys you daily, it probably annoys others too.

2. Choose the Right Tool for the Job

Don't over-engineer. JavaScript was perfect for this project, even though TypeScript might seem "more professional."

3. Focus on User Experience

Technical complexity should be hidden from users. The best tools feel like magic.

4. Ship Early, Iterate Often

My first version wasn't perfect, but it solved the core problem. User feedback guided improvements.

5. Documentation Is Product

Clear setup instructions and good documentation are as important as the code itself.

Try It Yourself

Smart Conda Workspace is completely free and available in the VS Code Marketplace. If you work with conda environments, give it a try:

Install the extension from VS Code Marketplace
Open a project with conda environments
Press Cmd+Shift+P → "Smart Conda: Configure Workspace"
Select your environment
Enjoy never typing conda activate again!

GitHub Repository: [https://github.com/AntonioDEM/smart-conda-terminal/tree/main]

Final Thoughts

Building Smart Conda Workspace taught me that sometimes the best solutions are the simple ones. We don't always need complex architectures or cutting-edge technologies. Sometimes we just need to eliminate one small friction point that happens a hundred times a day.

The goal wasn't to revolutionize development workflows. It was to save developers 30 seconds and a bit of mental overhead every time they opened a terminal. Those 30 seconds add up.

What daily friction points are you experiencing in your development workflow? Maybe it's time to build the tool you've been wishing existed.

If you enjoyed this article, consider trying Smart Conda Workspace and leaving feedback. As a solo developer, every bit of input helps make the tool better for everyone.

Have questions about VS Code extension development or want to discuss conda workflows? Drop a comment below or reach out!

Tags: #VSCode #Python #NodeJS #DeveloperTools #Conda #ExtensionDevelopment #JavaScript #Productivity #OpenSource