diff options
| author | Paul Buetow <paul@buetow.org> | 2026-02-28 17:05:23 +0200 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2026-02-28 17:05:23 +0200 |
| commit | 8b8512a07a555ee8903817a6581ebc1c2347f9c5 (patch) | |
| tree | 5890ed00b8f26fa796571422dfd9f12c55cf7ba5 | |
| parent | a8c98037faeed3794058da7ceaf164d56c81d469 (diff) | |
Update content for md
| -rw-r--r-- | about/resources.md | 204 | ||||
| -rw-r--r-- | about/showcase.md | 349 | ||||
| -rw-r--r-- | about/showcase/debroid/image-1.png | 40 | ||||
| -rw-r--r-- | gemfeed/2023-08-18-site-reliability-engineering-part-1.md | 1 | ||||
| -rw-r--r-- | gemfeed/2023-11-19-site-reliability-engineering-part-2.md | 1 | ||||
| -rw-r--r-- | gemfeed/2024-01-09-site-reliability-engineering-part-3.md | 1 | ||||
| -rw-r--r-- | gemfeed/2024-09-07-site-reliability-engineering-part-4.md | 7 | ||||
| -rw-r--r-- | gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.md | 302 | ||||
| -rw-r--r-- | gemfeed/2026-03-01-site-reliability-engineering-part-5.md | 64 | ||||
| -rw-r--r-- | gemfeed/DRAFT-site-reliability-engineering.md | 152 | ||||
| -rw-r--r-- | gemfeed/DRAFT-taskwarrior-autonomous-agent-loop.md | 477 | ||||
| -rw-r--r-- | gemfeed/DRAFT-totalrecall.md | 272 | ||||
| -rw-r--r-- | gemfeed/index.md | 2 | ||||
| -rw-r--r-- | gemfeed/taskwarrior-autonomous-agent/ior-flamegraph.png | bin | 86989 -> 0 bytes | |||
| -rw-r--r-- | gemfeed/taskwarrior-autonomous-agent/ior-logo.png | bin | 46683 -> 0 bytes | |||
| -rw-r--r-- | index.md | 2 |
16 files changed, 373 insertions, 1501 deletions
diff --git a/about/resources.md b/about/resources.md index bd6962b2..f334c094 100644 --- a/about/resources.md +++ b/about/resources.md @@ -35,110 +35,110 @@ You won't find any links on this site because, over time, the links will break. In random order: -* Data Science at the Command Line; Jeroen Janssens; O'Reilly -* Systemprogrammierung in Go; Frank Müller; dpunkt -* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional -* Terraform Cookbook; Mikael Krief; Packt Publishing -* Java ist auch eine Insel; Christian Ullenboom; -* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt -* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press -* Polished Ruby Programming; Jeremy Evans; Packt Publishing -* Modern Perl; Chromatic ; Onyx Neon Press -* The Docker Book; James Turnbull; Kindle -* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly * Developing Games in Java; David Brackeen and others...; New Riders -* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press * Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner -* Site Reliability Engineering; How Google runs production systems; O'Reilly -* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications -* Raku Fundamentals; Moritz Lenz; Apress -* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton -* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications -* Effective awk programming; Arnold Robbins; O'Reilly -* Ultimate Go Notebook; Bill Kennedy -* Funktionale Programmierung; Peter Pepper; Springer -* DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible -* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly -* Chaos Engineering - System Resiliency in Practice; Casey Rosenthal and Nora Jones; eBook -* Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly -* Pro Puppet; James Turnbull, Jeffrey McCune; Apress -* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly -* The Practise of System and Network Administration; Thomas A. Limoncelli, Christina J. Hogan, Strata R. Chalup; Addison-Wesley Professional Pro Git; Scott Chacon, Ben Straub; Apress -* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly -* Programming Ruby 3.3 (5th Edition); Noel Rappin, with Dave Thomas; The Pragmatic Bookshelf -* Higher Order Perl; Mark Dominus; Morgan Kaufmann -* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook * Concurrency in Go; Katherine Cox-Buday; O'Reilly -* The Pragmatic Programmer; David Thomas; Addison-Wesley -* Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers -* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly * Seeking SRE: Conversations About Running Production Systems at Scale; David N. Blank-Edelman; eBook * DNS and BIND; Cricket Liu; O'Reilly -* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers -* Effective Java; Joshua Bloch; Addison-Wesley Professional +* Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers +* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton * Perl New Features; Joshua McAdams, brian d foy; Perl School +* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional +* Polished Ruby Programming; Jeremy Evans; Packt Publishing +* Effective Java; Joshua Bloch; Addison-Wesley Professional +* Chaos Engineering - System Resiliency in Practice; Casey Rosenthal and Nora Jones; eBook * The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible +* Terraform Cookbook; Mikael Krief; Packt Publishing +* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press +* Site Reliability Engineering; How Google runs production systems; O'Reilly +* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook +* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly +* Java ist auch eine Insel; Christian Ullenboom; +* Funktionale Programmierung; Peter Pepper; Springer * Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson +* Programming Ruby 3.3 (5th Edition); Noel Rappin, with Dave Thomas; The Pragmatic Bookshelf +* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly +* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly * Raku Recipes; J.J. Merelo; Apress -* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly * C++ Programming Language; Bjarne Stroustrup; +* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly * Leanring eBPF; Liz Rice; O'Reilly +* Raku Fundamentals; Moritz Lenz; Apress +* The Practise of System and Network Administration; Thomas A. Limoncelli, Christina J. Hogan, Strata R. Chalup; Addison-Wesley Professional Pro Git; Scott Chacon, Ben Straub; Apress +* The Docker Book; James Turnbull; Kindle +* Data Science at the Command Line; Jeroen Janssens; O'Reilly +* DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible +* Ultimate Go Notebook; Bill Kennedy +* Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly +* Effective awk programming; Arnold Robbins; O'Reilly +* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications +* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt +* Higher Order Perl; Mark Dominus; Morgan Kaufmann +* Systemprogrammierung in Go; Frank Müller; dpunkt +* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications +* The Pragmatic Programmer; David Thomas; Addison-Wesley +* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press +* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly +* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers +* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly +* Pro Puppet; James Turnbull, Jeffrey McCune; Apress +* Modern Perl; Chromatic ; Onyx Neon Press ## Technical references I didn't read them from the beginning to the end, but I am using them to look up things. The books are in random order: -* Relayd and Httpd Mastery; Michael W Lucas +* Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly * Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly +* Go: Design Patterns for Real-World Projects; Mat Ryer; Packt +* The Linux Programming Interface; Michael Kerrisk; No Starch Press +* Relayd and Httpd Mastery; Michael W Lucas * BPF Performance Tools - Linux System and Application Observability, Brendan Gregg; Addison Wesley * Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley -* The Linux Programming Interface; Michael Kerrisk; No Starch Press -* Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly * Implementing Service Level Objectives; Alex Hidalgo; O'Reilly -* Go: Design Patterns for Real-World Projects; Mat Ryer; Packt ## Self-development and soft-skills books In random order: +* Meditation for Mortals, Oliver Burkeman, Audiobook +* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing +* Deep Work; Cal Newport; Piatkus +* The Joy of Missing Out; Christina Crook; New Society Publishers +* Psycho-Cybernetics; Maxwell Maltz; Perigee Books * Slow Productivity; Cal Newport; Penguin Random House -* The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select -* So Good They Can't Ignore You; Cal Newport; Business Plus +* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books +* Ultralearning; Anna Laurent; Self-published via Amazon +* Getting Things Done; David Allen +* Influence without Authority; A. Cohen, D. Bradford; Wiley +* The 7 Habits Of Highly Effective People; Stephen R. Covey; Simon & Schuster UK +* Soft Skills; John Sommez; Manning Publications +* Staff Engineer: Leadership beyond the management track; Will Larson; Audiobook * The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook +* Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press +* Stop starting, start finishing; Arne Roock; Lean-Kanban University +* The Off Switch; Mark Cropley; Virgin Books (RE-READ 1ST TIME) +* 101 Essays that change the way you think; Brianna Wiest; Audiobook +* Digital Minimalism; Cal Newport; Portofolio Penguin +* Atomic Habits; James Clear; Random House Business * The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd -* Soft Skills; John Sommez; Manning Publications -* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books -* Ultralearning; Scott Young; Thorsons +* Solve for Happy; Mo Gawdat (RE-READ 1ST TIME) +* 97 Things Every Engineering Manager Should Know; Camille Fournier; Audiobook +* Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion * Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly -* Deep Work; Cal Newport; Piatkus +* The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select * The Courage to Be Disliked; Ichiro Kishimi and Fumitake Koga; Audiobook +* Eat That Frog; Brian Tracy +* The Good Enough Job; Simone Stolzoff; Ebury Edge +* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne +* So Good They Can't Ignore You; Cal Newport; Business Plus * Coders at Work - Reflections on the craft of programming, Peter Seibel and Mitchell Dorian et al., Audiobook -* The 7 Habits Of Highly Effective People; Stephen R. Covey; Simon & Schuster UK -* 101 Essays that change the way you think; Brianna Wiest; Audiobook -* Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion -* Influence without Authority; A. Cohen, D. Bradford; Wiley -* The Joy of Missing Out; Christina Crook; New Society Publishers -* Ultralearning; Anna Laurent; Self-published via Amazon -* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing -* 97 Things Every Engineering Manager Should Know; Camille Fournier; Audiobook * Eat That Frog!; Brian Tracy; Hodder Paperbacks -* Psycho-Cybernetics; Maxwell Maltz; Perigee Books -* Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press -* Solve for Happy; Mo Gawdat (RE-READ 1ST TIME) -* The Power of Now; Eckhard Tolle; Yellow Kite -* Digital Minimalism; Cal Newport; Portofolio Penguin * The Bullet Journal Method; Ryder Carroll; Fourth Estate -* Eat That Frog; Brian Tracy -* Staff Engineer: Leadership beyond the management track; Will Larson; Audiobook -* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business -* The Off Switch; Mark Cropley; Virgin Books (RE-READ 1ST TIME) -* Getting Things Done; David Allen -* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne +* Ultralearning; Scott Young; Thorsons * The Software Engineer's Guidebook: Navigating senior, tech lead, and staff engineer positions at tech companies and startups; Gergely Orosz; Audiobook -* Stop starting, start finishing; Arne Roock; Lean-Kanban University -* The Good Enough Job; Simone Stolzoff; Ebury Edge -* Meditation for Mortals, Oliver Burkeman, Audiobook -* Atomic Habits; James Clear; Random House Business +* The Power of Now; Eckhard Tolle; Yellow Kite +* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business [Here are notes of mine for some of the books](../notes/index.md) @@ -146,30 +146,30 @@ In random order: Some of these were in-person with exams; others were online learning lectures only. In random order: -* Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online -* MySQL Deep Dive Workshop; 2-day on-site training -* Protocol buffers; O'Reilly Online -* Red Hat Certified System Administrator; Course + certification (Although I had the option, I decided not to take the next course as it is more effective to self learn what I need) * The Ultimate Kubernetes Bootcamp; School of Devops; O'Reilly Online * F5 Loadbalancers Training; 2-day on-site training; F5, Inc. -* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon -* Developing IaC with Terraform (with Live Lessons); O'Reilly Online * The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online +* Structure and Interpretation of Computer Programs; Harold Abelson and more...; * Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training -* Functional programming lecture; Remote University of Hagen +* Protocol buffers; O'Reilly Online +* MySQL Deep Dive Workshop; 2-day on-site training * AWS Immersion Day; Amazon; 1-day interactive online training -* Structure and Interpretation of Computer Programs; Harold Abelson and more...; +* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon * Scripting Vim; Damian Conway; O'Reilly Online * Apache Tomcat Best Practises; 3-day on-site training +* Red Hat Certified System Administrator; Course + certification (Although I had the option, I decided not to take the next course as it is more effective to self learn what I need) +* Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online +* Functional programming lecture; Remote University of Hagen +* Developing IaC with Terraform (with Live Lessons); O'Reilly Online * Ultimate Go Programming; Bill Kennedy; O'Reilly Online ## Technical guides These are not whole books, but guides (smaller or larger) which I found very useful. in random order: -* Advanced Bash-Scripting Guide -* Raku Guide at https://raku.guide * How CPUs work at https://cpu.land +* Raku Guide at https://raku.guide +* Advanced Bash-Scripting Guide ## Podcasts @@ -177,58 +177,58 @@ These are not whole books, but guides (smaller or larger) which I found very use In random order: -* Pratical AI -* Dev Interrupted -* The ProdCast (Google SRE Podcast) -* Wednesday Wisdom -* Backend Banter -* Hidden Brain -* The Pragmatic Engineer Podcast -* Fallthrough [Golang] +* Fork Around And Find Out * Cup o' Go [Golang] -* BSD Now [BSD] +* Fallthrough [Golang] * Modern Mentor -* Fork Around And Find Out -* Maintainable +* The Pragmatic Engineer Podcast +* Backend Banter * Deep Questions with Cal Newport +* The ProdCast (Google SRE Podcast) +* Hidden Brain * The Changelog Podcast(s) +* Dev Interrupted +* BSD Now [BSD] +* Maintainable +* Pratical AI +* Wednesday Wisdom ### Podcasts I liked I liked them but am not listening to them anymore. The podcasts have either "finished" (no more episodes) or I stopped listening to them due to time constraints or a shift in my interests. +* Modern Mentor +* Go Time (predecessor of fallthrough) * CRE: Chaosradio Express [german] +* Java Pub House * FLOSS weekly * Ship It (predecessor of Fork Around And Find Out) -* Go Time (predecessor of fallthrough) -* Java Pub House -* Modern Mentor ## Newsletters I like This is a mix of tech and non-tech newsletters I am subscribed to. In random order: -* Changelog News -* Ruby Weekly * VK Newsletter * Register Spill -* Applied Go Weekly Newsletter -* The Imperfectionist * byteSizeGo -* The Valuable Dev +* Changelog News * The Pragmatic Engineer -* Andreas Brandhorst Newsletter (Sci-Fi author) +* The Valuable Dev +* Applied Go Weekly Newsletter * Golang Weekly +* The Imperfectionist +* Andreas Brandhorst Newsletter (Sci-Fi author) +* Ruby Weekly * Monospace Mentor ## Magazines I like(d) This is a mix of tech I like(d). I may not be a current subscriber, but now and then, I buy an issue. In random order: -* freeX (not published anymore) * LWN (online only) -* Linux Magazine +* freeX (not published anymore) * Linux User +* Linux Magazine # Formal education diff --git a/about/showcase.md b/about/showcase.md index bda3bc26..a9ba0e1d 100644 --- a/about/showcase.md +++ b/about/showcase.md @@ -1,6 +1,6 @@ # Project Showcase -Generated on: 2026-02-21 +Generated on: 2026-02-22 This page showcases my side projects, providing an overview of what each project does, its technical implementation, and key metrics. Each project summary includes information about the programming languages used, development activity, and licensing. The projects are ranked by score, which combines project size and recent activity. @@ -9,24 +9,24 @@ This page showcases my side projects, providing an overview of what each project * [⇢ Project Showcase](#project-showcase) * [⇢ ⇢ Overall Statistics](#overall-statistics) * [⇢ ⇢ Projects](#projects) -* [⇢ ⇢ ⇢ 1. hexai](#1-hexai) +* [⇢ ⇢ ⇢ 1. ior](#1-ior) * [⇢ ⇢ ⇢ 2. dotfiles](#2-dotfiles) -* [⇢ ⇢ ⇢ 3. epimetheus](#3-epimetheus) -* [⇢ ⇢ ⇢ 4. conf](#4-conf) -* [⇢ ⇢ ⇢ 5. foo.zone](#5-foozone) -* [⇢ ⇢ ⇢ 6. scifi](#6-scifi) -* [⇢ ⇢ ⇢ 7. log4jbench](#7-log4jbench) -* [⇢ ⇢ ⇢ 8. gogios](#8-gogios) -* [⇢ ⇢ ⇢ 9. yoga](#9-yoga) -* [⇢ ⇢ ⇢ 10. perc](#10-perc) -* [⇢ ⇢ ⇢ 11. totalrecall](#11-totalrecall) -* [⇢ ⇢ ⇢ 12. ior](#12-ior) +* [⇢ ⇢ ⇢ 3. hexai](#3-hexai) +* [⇢ ⇢ ⇢ 4. epimetheus](#4-epimetheus) +* [⇢ ⇢ ⇢ 5. conf](#5-conf) +* [⇢ ⇢ ⇢ 6. foo.zone](#6-foozone) +* [⇢ ⇢ ⇢ 7. scifi](#7-scifi) +* [⇢ ⇢ ⇢ 8. log4jbench](#8-log4jbench) +* [⇢ ⇢ ⇢ 9. gogios](#9-gogios) +* [⇢ ⇢ ⇢ 10. yoga](#10-yoga) +* [⇢ ⇢ ⇢ 11. perc](#11-perc) +* [⇢ ⇢ ⇢ 12. totalrecall](#12-totalrecall) * [⇢ ⇢ ⇢ 13. gitsyncer](#13-gitsyncer) * [⇢ ⇢ ⇢ 14. tasksamurai](#14-tasksamurai) * [⇢ ⇢ ⇢ 15. foostats](#15-foostats) * [⇢ ⇢ ⇢ 16. timr](#16-timr) -* [⇢ ⇢ ⇢ 17. dtail](#17-dtail) -* [⇢ ⇢ ⇢ 18. gos](#18-gos) +* [⇢ ⇢ ⇢ 17. gos](#17-gos) +* [⇢ ⇢ ⇢ 18. dtail](#18-dtail) * [⇢ ⇢ ⇢ 19. ds-sim](#19-ds-sim) * [⇢ ⇢ ⇢ 20. wireguardmeshgenerator](#20-wireguardmeshgenerator) * [⇢ ⇢ ⇢ 21. gemtexter](#21-gemtexter) @@ -48,15 +48,15 @@ This page showcases my side projects, providing an overview of what each project * [⇢ ⇢ ⇢ 37. mon](#37-mon) * [⇢ ⇢ ⇢ 38. staticfarm-apache-handlers](#38-staticfarm-apache-handlers) * [⇢ ⇢ ⇢ 39. pingdomfetch](#39-pingdomfetch) -* [⇢ ⇢ ⇢ 40. fype](#40-fype) -* [⇢ ⇢ ⇢ 41. xerl](#41-xerl) -* [⇢ ⇢ ⇢ 42. ychat](#42-ychat) -* [⇢ ⇢ ⇢ 43. fapi](#43-fapi) -* [⇢ ⇢ ⇢ 44. perl-c-fibonacci](#44-perl-c-fibonacci) -* [⇢ ⇢ ⇢ 45. netcalendar](#45-netcalendar) -* [⇢ ⇢ ⇢ 46. loadbars](#46-loadbars) -* [⇢ ⇢ ⇢ 47. gotop](#47-gotop) -* [⇢ ⇢ ⇢ 48. rubyfy](#48-rubyfy) +* [⇢ ⇢ ⇢ 40. xerl](#40-xerl) +* [⇢ ⇢ ⇢ 41. ychat](#41-ychat) +* [⇢ ⇢ ⇢ 42. fapi](#42-fapi) +* [⇢ ⇢ ⇢ 43. perl-c-fibonacci](#43-perl-c-fibonacci) +* [⇢ ⇢ ⇢ 44. netcalendar](#44-netcalendar) +* [⇢ ⇢ ⇢ 45. loadbars](#45-loadbars) +* [⇢ ⇢ ⇢ 46. gotop](#46-gotop) +* [⇢ ⇢ ⇢ 47. rubyfy](#47-rubyfy) +* [⇢ ⇢ ⇢ 48. fype](#48-fype) * [⇢ ⇢ ⇢ 49. pwgrep](#49-pwgrep) * [⇢ ⇢ ⇢ 50. perldaemon](#50-perldaemon) * [⇢ ⇢ ⇢ 51. jsmstrade](#51-jsmstrade) @@ -75,36 +75,38 @@ This page showcases my side projects, providing an overview of what each project ## Overall Statistics * 📦 Total Projects: 62 -* 📊 Total Commits: 12,551 -* 📈 Total Lines of Code: 311,290 -* 📄 Total Lines of Documentation: 41,076 -* 💻 Languages: Go (36.4%), Java (13.2%), C++ (8.1%), C (6.3%), XML (6.2%), Shell (5.9%), Perl (5.6%), C/C++ (5.2%), YAML (5.1%), HTML (1.9%), Config (1.2%), Ruby (1.0%), HCL (0.9%), Python (0.7%), CSS (0.6%), Make (0.5%), JSON (0.4%), Haskell (0.2%), JavaScript (0.2%), Raku (0.1%), TOML (0.1%) -* 📚 Documentation: Markdown (69.8%), Text (28.9%), LaTeX (1.4%) +* 📊 Total Commits: 12,631 +* 📈 Total Lines of Code: 317,099 +* 📄 Total Lines of Documentation: 40,325 +* 💻 Languages: Go (37.7%), Java (12.9%), C++ (8.0%), C (6.1%), XML (6.1%), Shell (5.8%), Perl (5.5%), C/C++ (5.1%), YAML (5.0%), HTML (1.9%), Config (1.2%), Ruby (0.9%), HCL (0.9%), Python (0.6%), CSS (0.6%), Make (0.5%), JSON (0.4%), Haskell (0.2%), JavaScript (0.2%), Raku (0.1%), TOML (0.1%) +* 📚 Documentation: Markdown (71.4%), Text (27.2%), LaTeX (1.4%) * 🚀 Release Status: 39 released, 23 experimental (62.9% with releases, 37.1% experimental) ## Projects -### 1. hexai +### 1. ior -* 💻 Languages: Go (100.0%) -* 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 342 -* 📈 Lines of Code: 29895 -* 📄 Lines of Documentation: 5502 -* 📅 Development Period: 2025-08-01 to 2026-02-13 -* 🏆 Score: 365.1 (combines code size and activity) +* 💻 Languages: Go (73.1%), C (26.3%), C/C++ (0.6%) +* 📚 Documentation: Markdown (80.3%), Text (19.7%) +* 📊 Commits: 384 +* 📈 Lines of Code: 21785 +* 📄 Lines of Documentation: 2428 +* 📅 Development Period: 2024-01-18 to 2026-02-21 +* 🏆 Score: 2219.6 (combines code size and activity) * ⚖️ License: No license found -* 🏷️ Latest Release: v0.21.0 (2026-02-12) +* 🧪 Status: Experimental (no releases yet) -[](showcase/hexai/image-1.png) +[](showcase/ior/image-1.png) -Hexai is a Go-based AI integration tool designed primarily for the Helix editor that provides LSP (Language Server Protocol) powered AI features. It offers code auto-completion, AI-driven code actions, in-editor chat with LLMs, and a standalone CLI tool for direct LLM interaction. A standout feature is its ability to query multiple AI providers (OpenAI, OpenRouter, GitHub Copilot, Ollama) in parallel, allowing developers to compare responses side-by-side. It has enhanced capabilities for Go code understanding, such as generating unit tests from functions, while supporting other programming languages as well. +I/O Riot NG is a Linux-only performance analysis tool that uses BPF (Berkeley Packet Filter) to trace synchronous I/O syscalls and measure their execution time. It captures stack traces during I/O operations and generates compressed output in a format compatible with Inferno FlameGraphs, allowing developers to visually identify performance bottlenecks caused by blocking I/O calls. This makes it particularly useful for diagnosing latency issues in applications where I/O operations are suspected of causing performance degradation. -The project is implemented as an LSP server written in Go, with a TUI component built using Bubble Tea for the tmux-based code action runner (`hexai-tmux-action`). This architecture allows it to integrate seamlessly into LSP-compatible editors, with special focus on Helix + tmux workflows. The custom prompt feature lets developers use their preferred editor to craft prompts, making it flexible for various development workflows. +[](showcase/ior/image-2.svg) -[View on Codeberg](https://codeberg.org/snonux/hexai) -[View on GitHub](https://github.com/snonux/hexai) +The tool is implemented in Go and C, leveraging libbpfgo for BPF interaction. It automatically generates BPF tracepoint handlers and Go type definitions from Linux kernel tracepoint data, attaches to syscall entry/exit points, and collects timing data with minimal overhead. The project is a modern successor to the original I/O Riot (which used SystemTap), offering better performance and easier deployment through BPF's built-in kernel support. + +[View on Codeberg](https://codeberg.org/snonux/ior) +[View on GitHub](https://github.com/snonux/ior) --- @@ -112,11 +114,11 @@ The project is implemented as an LSP server written in Go, with a TUI component * 💻 Languages: Shell (58.9%), CSS (11.0%), Config (10.2%), TOML (10.1%), Ruby (8.4%), JSON (1.1%), INI (0.2%) * 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 776 -* 📈 Lines of Code: 2960 -* 📄 Lines of Documentation: 653 -* 📅 Development Period: 2023-07-30 to 2026-02-21 -* 🏆 Score: 364.5 (combines code size and activity) +* 📊 Commits: 783 +* 📈 Lines of Code: 2961 +* 📄 Lines of Documentation: 949 +* 📅 Development Period: 2023-07-30 to 2026-02-22 +* 🏆 Score: 427.7 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -130,7 +132,31 @@ The architecture is straightforward: config files live in subdirectories mirrori --- -### 3. epimetheus +### 3. hexai + +* 💻 Languages: Go (100.0%) +* 📚 Documentation: Markdown (100.0%) +* 📊 Commits: 343 +* 📈 Lines of Code: 29895 +* 📄 Lines of Documentation: 5508 +* 📅 Development Period: 2025-08-01 to 2026-02-22 +* 🏆 Score: 341.8 (combines code size and activity) +* ⚖️ License: No license found +* 🏷️ Latest Release: v0.21.0 (2026-02-12) + + +[](showcase/hexai/image-1.png) + +Hexai is a Go-based AI integration tool designed primarily for the Helix editor that provides LSP (Language Server Protocol) powered AI features. It offers code auto-completion, AI-driven code actions, in-editor chat with LLMs, and a standalone CLI tool for direct LLM interaction. A standout feature is its ability to query multiple AI providers (OpenAI, OpenRouter, GitHub Copilot, Ollama) in parallel, allowing developers to compare responses side-by-side. It has enhanced capabilities for Go code understanding, such as generating unit tests from functions, while supporting other programming languages as well. + +The project is implemented as an LSP server written in Go, with a TUI component built using Bubble Tea for the tmux-based code action runner (`hexai-tmux-action`). This architecture allows it to integrate seamlessly into LSP-compatible editors, with special focus on Helix + tmux workflows. The custom prompt feature lets developers use their preferred editor to craft prompts, making it flexible for various development workflows. + +[View on Codeberg](https://codeberg.org/snonux/hexai) +[View on GitHub](https://github.com/snonux/hexai) + +--- + +### 4. epimetheus * 💻 Languages: Go (85.2%), Shell (14.8%) * 📚 Documentation: Markdown (100.0%) @@ -138,7 +164,7 @@ The architecture is straightforward: config files live in subdirectories mirrori * 📈 Lines of Code: 5199 * 📄 Lines of Documentation: 1734 * 📅 Development Period: 2026-02-07 to 2026-02-14 -* 🏆 Score: 314.0 (combines code size and activity) +* 🏆 Score: 284.8 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -154,15 +180,15 @@ The architecture routes current data (<5 min old) through Pushgateway where Prom --- -### 4. conf +### 5. conf -* 💻 Languages: YAML (80.7%), Perl (10.0%), Shell (6.1%), Python (2.3%), Docker (0.7%), Config (0.2%), HTML (0.1%) +* 💻 Languages: YAML (80.7%), Perl (9.9%), Shell (6.0%), Python (2.3%), Docker (0.7%), Config (0.2%), HTML (0.1%) * 📚 Documentation: Markdown (97.1%), Text (2.9%) -* 📊 Commits: 785 -* 📈 Lines of Code: 19079 -* 📄 Lines of Documentation: 6585 -* 📅 Development Period: 2021-12-28 to 2026-02-08 -* 🏆 Score: 250.8 (combines code size and activity) +* 📊 Commits: 791 +* 📈 Lines of Code: 19132 +* 📄 Lines of Documentation: 6572 +* 📅 Development Period: 2021-12-28 to 2026-02-15 +* 🏆 Score: 261.6 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -176,7 +202,7 @@ The project is organized into distinct subdirectories: `dotfiles/` contains shel --- -### 5. foo.zone +### 6. foo.zone * 💻 Languages: XML (98.7%), Shell (1.0%), Go (0.3%) * 📚 Documentation: Text (86.2%), Markdown (13.8%) @@ -184,7 +210,7 @@ The project is organized into distinct subdirectories: `dotfiles/` contains shel * 📈 Lines of Code: 18702 * 📄 Lines of Documentation: 174 * 📅 Development Period: 2021-04-29 to 2026-02-07 -* 🏆 Score: 215.8 (combines code size and activity) +* 🏆 Score: 203.4 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -196,7 +222,7 @@ foo.zone: source code repository. --- -### 6. scifi +### 7. scifi * 💻 Languages: JSON (35.9%), CSS (30.6%), JavaScript (29.6%), HTML (3.8%) * 📚 Documentation: Markdown (100.0%) @@ -204,7 +230,7 @@ foo.zone: source code repository. * 📈 Lines of Code: 1664 * 📄 Lines of Documentation: 853 * 📅 Development Period: 2026-01-25 to 2026-01-27 -* 🏆 Score: 117.3 (combines code size and activity) +* 🏆 Score: 112.3 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -218,7 +244,7 @@ The architecture keeps content separate from presentation: book metadata lives i --- -### 7. log4jbench +### 8. log4jbench * 💻 Languages: Java (78.9%), XML (21.1%) * 📚 Documentation: Markdown (100.0%) @@ -226,7 +252,7 @@ The architecture keeps content separate from presentation: book metadata lives i * 📈 Lines of Code: 774 * 📄 Lines of Documentation: 119 * 📅 Development Period: 2026-01-09 to 2026-01-09 -* 🏆 Score: 66.4 (combines code size and activity) +* 🏆 Score: 64.6 (combines code size and activity) * ⚖️ License: MIT * 🧪 Status: Experimental (no releases yet) @@ -240,17 +266,17 @@ The implementation uses a fat JAR built with Maven, requiring Java 17+. It's des --- -### 8. gogios +### 9. gogios * 💻 Languages: Go (98.9%), JSON (0.6%), YAML (0.5%) * 📚 Documentation: Markdown (94.9%), Text (5.1%) -* 📊 Commits: 108 +* 📊 Commits: 109 * 📈 Lines of Code: 3875 * 📄 Lines of Documentation: 394 -* 📅 Development Period: 2023-04-17 to 2026-02-08 -* 🏆 Score: 33.3 (combines code size and activity) +* 📅 Development Period: 2023-04-17 to 2026-02-16 +* 🏆 Score: 35.0 (combines code size and activity) * ⚖️ License: Custom License -* 🏷️ Latest Release: v1.4.0 (2026-02-08) +* 🏷️ Latest Release: v1.4.1 (2026-02-16) [](showcase/gogios/image-1.png) @@ -264,7 +290,7 @@ The architecture is straightforward: JSON configuration defines checks (plugin p --- -### 9. yoga +### 10. yoga * 💻 Languages: Go (66.1%), HTML (33.9%) * 📚 Documentation: Markdown (100.0%) @@ -272,7 +298,7 @@ The architecture is straightforward: JSON configuration defines checks (plugin p * 📈 Lines of Code: 5921 * 📄 Lines of Documentation: 83 * 📅 Development Period: 2025-10-01 to 2026-01-28 -* 🏆 Score: 31.0 (combines code size and activity) +* 🏆 Score: 30.7 (combines code size and activity) * ⚖️ License: No license found * 🏷️ Latest Release: v0.4.0 (2026-01-28) @@ -288,7 +314,7 @@ The implementation follows clean Go architecture with domain logic organized und --- -### 10. perc +### 11. perc * 💻 Languages: Go (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -296,7 +322,7 @@ The implementation follows clean Go architecture with domain logic organized und * 📈 Lines of Code: 452 * 📄 Lines of Documentation: 80 * 📅 Development Period: 2025-11-25 to 2025-11-25 -* 🏆 Score: 30.0 (combines code size and activity) +* 🏆 Score: 29.6 (combines code size and activity) * ⚖️ License: No license found * 🏷️ Latest Release: v0.1.0 (2025-11-25) @@ -310,7 +336,7 @@ The tool is built as a simple Go CLI application with a standard project layout --- -### 11. totalrecall +### 12. totalrecall * 💻 Languages: Go (99.0%), Shell (0.5%), YAML (0.4%) * 📚 Documentation: Markdown (99.5%), Text (0.5%) @@ -318,7 +344,7 @@ The tool is built as a simple Go CLI application with a standard project layout * 📈 Lines of Code: 13129 * 📄 Lines of Documentation: 377 * 📅 Development Period: 2025-07-14 to 2026-01-21 -* 🏆 Score: 26.1 (combines code size and activity) +* 🏆 Score: 25.9 (combines code size and activity) * ⚖️ License: MIT * 🏷️ Latest Release: v0.8.0 (2026-01-21) @@ -336,43 +362,17 @@ The project offers both a keyboard-driven GUI for interactive use and a CLI for --- -### 12. ior - -* 💻 Languages: Go (63.2%), C (36.0%), C/C++ (0.8%) -* 📚 Documentation: Markdown (79.3%), Text (20.7%) -* 📊 Commits: 344 -* 📈 Lines of Code: 15784 -* 📄 Lines of Documentation: 2313 -* 📅 Development Period: 2024-01-18 to 2026-02-21 -* 🏆 Score: 20.9 (combines code size and activity) -* ⚖️ License: No license found -* 🧪 Status: Experimental (no releases yet) - - -[](showcase/ior/image-1.png) - -I/O Riot NG is a Linux-only performance analysis tool that uses BPF (Berkeley Packet Filter) to trace synchronous I/O syscalls and measure their execution time. It captures stack traces during I/O operations and generates compressed output in a format compatible with Inferno FlameGraphs, allowing developers to visually identify performance bottlenecks caused by blocking I/O calls. This makes it particularly useful for diagnosing latency issues in applications where I/O operations are suspected of causing performance degradation. - -[](showcase/ior/image-2.svg) - -The tool is implemented in Go and C, leveraging libbpfgo for BPF interaction. It automatically generates BPF tracepoint handlers and Go type definitions from Linux kernel tracepoint data, attaches to syscall entry/exit points, and collects timing data with minimal overhead. The project is a modern successor to the original I/O Riot (which used SystemTap), offering better performance and easier deployment through BPF's built-in kernel support. - -[View on Codeberg](https://codeberg.org/snonux/ior) -[View on GitHub](https://github.com/snonux/ior) - ---- - ### 13. gitsyncer -* 💻 Languages: Go (92.5%), Shell (7.1%), JSON (0.4%) +* 💻 Languages: Go (92.6%), Shell (7.0%), JSON (0.4%) * 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 117 -* 📈 Lines of Code: 10446 +* 📊 Commits: 120 +* 📈 Lines of Code: 10568 * 📄 Lines of Documentation: 2445 -* 📅 Development Period: 2025-06-23 to 2026-02-07 -* 🏆 Score: 20.7 (combines code size and activity) +* 📅 Development Period: 2025-06-23 to 2026-02-22 +* 🏆 Score: 22.5 (combines code size and activity) * ⚖️ License: BSD-2-Clause -* 🏷️ Latest Release: v0.12.0 (2026-02-07) +* 🏷️ Latest Release: v0.12.1 (2026-02-22) GitSyncer is a Go-based CLI tool that automatically synchronizes git repositories across multiple hosting platforms (GitHub, Codeberg, SSH servers). It maintains all branches in sync bidirectionally, never deleting branches but automatically creating and updating them as needed. The tool excels at providing repository redundancy and backup, with special support for one-way SSH backups to private servers (like home NAS devices) that may be offline intermittently. It includes AI-powered features for generating release notes and project showcase documentation, plus automated weekly batch synchronization for hands-off maintenance. @@ -392,7 +392,7 @@ The implementation uses a git remotes approach: it clones from one organization, * 📈 Lines of Code: 6544 * 📄 Lines of Documentation: 254 * 📅 Development Period: 2025-06-19 to 2026-02-04 -* 🏆 Score: 17.9 (combines code size and activity) +* 🏆 Score: 17.8 (combines code size and activity) * ⚖️ License: BSD-2-Clause * 🏷️ Latest Release: v0.11.0 (2026-02-04) @@ -418,7 +418,7 @@ Under the hood, Task Samurai acts as a front-end wrapper that invokes the native * 📈 Lines of Code: 1902 * 📄 Lines of Documentation: 423 * 📅 Development Period: 2023-01-02 to 2025-11-01 -* 🏆 Score: 17.8 (combines code size and activity) +* 🏆 Score: 17.7 (combines code size and activity) * ⚖️ License: Custom License * 🏷️ Latest Release: v0.2.0 (2025-10-21) @@ -440,7 +440,7 @@ The implementation uses a modular Perl architecture with specialized components: * 📈 Lines of Code: 1538 * 📄 Lines of Documentation: 99 * 📅 Development Period: 2025-06-25 to 2026-01-02 -* 🏆 Score: 16.1 (combines code size and activity) +* 🏆 Score: 16.0 (combines code size and activity) * ⚖️ License: MIT * 🏷️ Latest Release: v0.3.0 (2026-01-02) @@ -454,7 +454,33 @@ The architecture is straightforward: it's a Go-based CLI application that persis --- -### 17. dtail +### 17. gos + +* 💻 Languages: Go (99.5%), JSON (0.2%), Shell (0.2%) +* 📚 Documentation: Markdown (100.0%) +* 📊 Commits: 400 +* 📈 Lines of Code: 4143 +* 📄 Lines of Documentation: 477 +* 📅 Development Period: 2024-05-04 to 2026-02-17 +* 🏆 Score: 15.6 (combines code size and activity) +* ⚖️ License: Custom License +* 🏷️ Latest Release: v1.2.4 (2026-02-17) + + +[](showcase/gos/image-1.png) + +Gos is a command-line social media scheduling tool written in Go that serves as a self-hosted replacement for Buffer.com. It enables users to schedule and post messages to Mastodon and LinkedIn (plus a "Noop" pseudo-platform for tracking) through a simple file-based queueing system. Messages are created as text files in a designated directory (`~/.gosdir`), with optional tags embedded in filenames or content to control platform targeting, priority, and scheduling behavior. The tool addresses limitations of commercial services by offering unlimited posts, a scriptable CLI interface, and full user control without unwanted features like AI assistants. + +[](showcase/gos/image-2.png) + +The implementation uses OAuth2 for LinkedIn authentication, stores configuration as JSON, and manages posts through a platform-specific database structure. Gos employs intelligent scheduling based on configurable weekly targets, lookback windows, pause periods between posts, and run intervals to prevent over-posting. It supports priority queuing, platform exclusion rules, dry-run testing, and can generate Gemini gemtext summaries of posted content. Built with Mage for automation, the tool integrates seamlessly into shell workflows and can be triggered on intervals to maintain a consistent posting cadence across platforms. + +[View on Codeberg](https://codeberg.org/snonux/gos) +[View on GitHub](https://github.com/snonux/gos) + +--- + +### 18. dtail * 💻 Languages: Go (93.9%), JSON (2.8%), C (2.0%), Make (0.5%), C/C++ (0.3%), Config (0.2%), Shell (0.2%), Docker (0.1%) * 📚 Documentation: Text (79.4%), Markdown (20.6%) @@ -462,7 +488,7 @@ The architecture is straightforward: it's a Go-based CLI application that persis * 📈 Lines of Code: 20091 * 📄 Lines of Documentation: 5674 * 📅 Development Period: 2020-01-09 to 2025-06-20 -* 🏆 Score: 15.4 (combines code size and activity) +* 🏆 Score: 15.3 (combines code size and activity) * ⚖️ License: Apache-2.0 * 🏷️ Latest Release: v4.3.3 (2024-08-23) @@ -480,32 +506,6 @@ The architecture follows a client-server model where DTail servers run on target --- -### 18. gos - -* 💻 Languages: Go (99.8%), JSON (0.2%) -* 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 399 -* 📈 Lines of Code: 4102 -* 📄 Lines of Documentation: 357 -* 📅 Development Period: 2024-05-04 to 2025-12-27 -* 🏆 Score: 14.6 (combines code size and activity) -* ⚖️ License: Custom License -* 🏷️ Latest Release: v1.2.3 (2026-01-31) - - -[](showcase/gos/image-1.png) - -Gos is a command-line social media scheduling tool written in Go that serves as a self-hosted replacement for Buffer.com. It enables users to schedule and post messages to Mastodon and LinkedIn (plus a "Noop" pseudo-platform for tracking) through a simple file-based queueing system. Messages are created as text files in a designated directory (`~/.gosdir`), with optional tags embedded in filenames or content to control platform targeting, priority, and scheduling behavior. The tool addresses limitations of commercial services by offering unlimited posts, a scriptable CLI interface, and full user control without unwanted features like AI assistants. - -[](showcase/gos/image-2.png) - -The implementation uses OAuth2 for LinkedIn authentication, stores configuration as JSON, and manages posts through a platform-specific database structure. Gos employs intelligent scheduling based on configurable weekly targets, lookback windows, pause periods between posts, and run intervals to prevent over-posting. It supports priority queuing, platform exclusion rules, dry-run testing, and can generate Gemini gemtext summaries of posted content. Built with Mage for automation, the tool integrates seamlessly into shell workflows and can be triggered on intervals to maintain a consistent posting cadence across platforms. - -[View on Codeberg](https://codeberg.org/snonux/gos) -[View on GitHub](https://github.com/snonux/gos) - ---- - ### 19. ds-sim * 💻 Languages: Java (98.9%), Shell (0.6%), CSS (0.5%) @@ -514,7 +514,7 @@ The implementation uses OAuth2 for LinkedIn authentication, stores configuration * 📈 Lines of Code: 25762 * 📄 Lines of Documentation: 3101 * 📅 Development Period: 2008-05-15 to 2025-06-27 -* 🏆 Score: 14.1 (combines code size and activity) +* 🏆 Score: 14.0 (combines code size and activity) * ⚖️ License: Custom License * 🧪 Status: Experimental (no releases yet) @@ -652,7 +652,7 @@ The implementation leverages Go's cross-compilation capabilities and Fyne's UI a * 📈 Lines of Code: 33 * 📄 Lines of Documentation: 3 * 📅 Development Period: 2025-04-03 to 2025-04-03 -* 🏆 Score: 4.7 (combines code size and activity) +* 🏆 Score: 4.6 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -875,11 +875,11 @@ The key advantage over traditional benchmarking tools is that it reproduces actu * 💻 Languages: Perl (65.8%), Docker (34.2%) * 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 19 +* 📊 Commits: 22 * 📈 Lines of Code: 149 -* 📄 Lines of Documentation: 15 -* 📅 Development Period: 2011-07-09 to 2026-02-03 -* 🏆 Score: 1.3 (combines code size and activity) +* 📄 Lines of Documentation: 21 +* 📅 Development Period: 2011-07-09 to 2026-02-17 +* 🏆 Score: 1.5 (combines code size and activity) * ⚖️ License: Custom License * 🧪 Status: Experimental (no releases yet) @@ -984,29 +984,7 @@ The tool is implemented around a hierarchical configuration system (`/etc/pingdo --- -### 40. fype - -* 💻 Languages: C (71.8%), C/C++ (20.0%), HTML (6.3%), Make (1.8%) -* 📚 Documentation: Text (65.1%), LaTeX (21.0%), Markdown (14.0%) -* 📊 Commits: 107 -* 📈 Lines of Code: 9363 -* 📄 Lines of Documentation: 2713 -* 📅 Development Period: 2008-05-15 to 2026-02-20 -* 🏆 Score: 0.9 (combines code size and activity) -* ⚖️ License: Custom License -* 🧪 Status: Experimental (no releases yet) - - -Fype is a 32-bit scripting language designed as a fun, AWK-inspired alternative with a simpler syntax. It supports variables with automatic type conversion, functions, loops, control structures, and built-in operations for math, I/O, and system calls. A notable feature is its support for "synonyms" (references/aliases to variables and functions), along with both procedures (using the caller's namespace) and functions (with lexical scoping). The language uses a straightforward syntax with single-character comments (#) and statement-based execution terminated by semicolons. - -The implementation uses a simple top-down parser with maximum lookahead of 1, interpreting code simultaneously as it parses, which means syntax errors are only caught at runtime. Written in C and compiled with GCC, it's designed for BSD systems (tested on FreeBSD 7.0) and uses NetBSD Make for building. The project is still unreleased and incomplete, but aims to eventually match AWK's capabilities while potentially adding modern features like function pointers and closures, though explicitly avoiding complexity like OOP, Unicode, or threading. - -[View on Codeberg](https://codeberg.org/snonux/fype) -[View on GitHub](https://github.com/snonux/fype) - ---- - -### 41. xerl +### 40. xerl * 💻 Languages: Perl (98.3%), Config (1.2%), Make (0.5%) * 📊 Commits: 670 @@ -1027,7 +1005,7 @@ The implementation follows strict OO Perl conventions with explicit typing and p --- -### 42. ychat +### 41. ychat * 💻 Languages: C++ (49.9%), C/C++ (22.2%), Shell (20.6%), Perl (2.5%), HTML (1.9%), Config (1.8%), Make (0.9%), CSS (0.2%) * 📚 Documentation: Text (100.0%) @@ -1050,7 +1028,7 @@ The architecture emphasizes speed and scalability through several key design cho --- -### 43. fapi +### 42. fapi * 💻 Languages: Python (96.6%), Make (3.1%), Config (0.3%) * 📚 Documentation: Text (98.3%), Markdown (1.7%) @@ -1072,7 +1050,7 @@ The tool is implemented in Python and depends on the bigsuds library (F5's iCont --- -### 44. perl-c-fibonacci +### 43. perl-c-fibonacci * 💻 Languages: C (80.4%), Make (19.6%) * 📚 Documentation: Text (100.0%) @@ -1093,7 +1071,7 @@ perl-c-fibonacci: source code repository. --- -### 45. netcalendar +### 44. netcalendar * 💻 Languages: Java (83.0%), HTML (12.9%), XML (3.0%), CSS (0.8%), Make (0.2%) * 📚 Documentation: Text (89.7%), Markdown (10.3%) @@ -1120,17 +1098,17 @@ The key feature is its intelligent color-coded event visualization system that h --- -### 46. loadbars +### 45. loadbars * 💻 Languages: Perl (97.4%), Make (2.6%) * 📚 Documentation: Text (100.0%) -* 📊 Commits: 557 +* 📊 Commits: 575 * 📈 Lines of Code: 1828 * 📄 Lines of Documentation: 100 * 📅 Development Period: 2010-11-05 to 2015-05-23 * 🏆 Score: 0.7 (combines code size and activity) * ⚖️ License: No license found -* 🏷️ Latest Release: v0.9.0 (2026-02-14) +* 🏷️ Latest Release: v0.11.1 (2026-02-17) ⚠️ **Notice**: This project appears to be finished, obsolete, or no longer maintained. Last meaningful activity was over 2 years ago. Use at your own risk. @@ -1141,7 +1119,7 @@ loadbars: source code repository. --- -### 47. gotop +### 46. gotop * 💻 Languages: Go (98.0%), Make (2.0%) * 📚 Documentation: Markdown (50.0%), Text (50.0%) @@ -1164,7 +1142,7 @@ The implementation uses a concurrent architecture with goroutines for data colle --- -### 48. rubyfy +### 47. rubyfy * 💻 Languages: Ruby (98.5%), JSON (1.5%) * 📚 Documentation: Markdown (100.0%) @@ -1187,6 +1165,29 @@ The tool is implemented as a lightweight Ruby script that prioritizes simplicity --- +### 48. fype + +* 💻 Languages: C (71.2%), C/C++ (20.7%), HTML (6.6%), Make (1.5%) +* 📚 Documentation: Text (60.3%), LaTeX (39.7%) +* 📊 Commits: 107 +* 📈 Lines of Code: 8954 +* 📄 Lines of Documentation: 1432 +* 📅 Development Period: 2008-05-15 to 2014-06-30 +* 🏆 Score: 0.7 (combines code size and activity) +* ⚖️ License: Custom License +* 🧪 Status: Experimental (no releases yet) + +⚠️ **Notice**: This project appears to be finished, obsolete, or no longer maintained. Last meaningful activity was over 2 years ago. Use at your own risk. + +Fype is a 32-bit scripting language designed as a fun, AWK-inspired alternative with a simpler syntax. It supports variables with automatic type conversion, functions, loops, control structures, and built-in operations for math, I/O, and system calls. A notable feature is its support for "synonyms" (references/aliases to variables and functions), along with both procedures (using the caller's namespace) and functions (with lexical scoping). The language uses a straightforward syntax with single-character comments (#) and statement-based execution terminated by semicolons. + +The implementation uses a simple top-down parser with maximum lookahead of 1, interpreting code simultaneously as it parses, which means syntax errors are only caught at runtime. Written in C and compiled with GCC, it's designed for BSD systems (tested on FreeBSD 7.0) and uses NetBSD Make for building. The project is still unreleased and incomplete, but aims to eventually match AWK's capabilities while potentially adding modern features like function pointers and closures, though explicitly avoiding complexity like OOP, Unicode, or threading. + +[View on Codeberg](https://codeberg.org/snonux/fype) +[View on GitHub](https://github.com/snonux/fype) + +--- + ### 49. pwgrep * 💻 Languages: Shell (85.0%), Make (15.0%) diff --git a/about/showcase/debroid/image-1.png b/about/showcase/debroid/image-1.png index d7cec344..3a28b1cb 100644 --- a/about/showcase/debroid/image-1.png +++ b/about/showcase/debroid/image-1.png @@ -54,7 +54,7 @@ <script type="application/json" id="client-env">{"locale":"en","featureFlags":["a11y_status_checks_ruleset","action_yml_language_service","actions_custom_images_public_preview_visibility","actions_custom_images_storage_billing_ui_visibility","actions_image_version_event","actions_workflow_language_service","alternate_user_config_repo","api_insights_show_missing_data_banner","arianotify_comprehensive_migration","batch_suggested_changes","codespaces_prebuild_region_target_update","coding_agent_model_selection","coding_agent_model_selection_all_skus","copilot_3p_agent_hovercards","copilot_agent_sessions_alive_updates","copilot_agent_snippy","copilot_agent_task_list_v2","copilot_agent_task_submit_with_modifier","copilot_agent_tasks_btn_repo","copilot_api_agentic_issue_marshal_yaml","copilot_ask_mode_dropdown","copilot_chat_attach_multiple_images","copilot_chat_clear_model_selection_for_default_change","copilot_chat_enable_tool_call_logs","copilot_chat_file_redirect","copilot_chat_input_commands","copilot_chat_opening_thread_switch","copilot_chat_reduce_quota_checks","copilot_chat_repository_picker","copilot_chat_search_bar_redirect","copilot_chat_selection_attachments","copilot_chat_vision_in_claude","copilot_chat_vision_preview_gate","copilot_coding_agent_task_response","copilot_custom_copilots","copilot_custom_copilots_feature_preview","copilot_duplicate_thread","copilot_extensions_hide_in_dotcom_chat","copilot_extensions_removal_on_marketplace","copilot_features_sql_server_logo","copilot_features_zed_logo","copilot_file_block_ref_matching","copilot_ftp_hyperspace_upgrade_prompt","copilot_icebreakers_experiment_dashboard","copilot_icebreakers_experiment_hyperspace","copilot_immersive_embedded","copilot_immersive_job_result_preview","copilot_immersive_layout_routes","copilot_immersive_structured_model_picker","copilot_immersive_task_hyperlinking","copilot_immersive_task_within_chat_thread","copilot_mc_cli_resume_any_users_task","copilot_mission_control_use_task_name","copilot_org_policy_page_focus_mode","copilot_redirect_header_button_to_agents","copilot_share_active_subthread","copilot_spaces_ga","copilot_spaces_individual_policies_ga","copilot_spaces_pagination","copilot_spark_empty_state","copilot_spark_handle_nil_friendly_name","copilot_stable_conversation_view","copilot_swe_agent_hide_model_picker_if_only_auto","copilot_swe_agent_use_subagents","copilot_unconfigured_is_inherited","custom_instructions_file_references","custom_properties_consolidate_default_value_input","dashboard_lists_max_age_filter","dashboard_universe_2025_feedback_dialog","enterprise_ai_controls","failbot_report_error_react_apps_on_page","flex_cta_groups_mvp","global_nav_react","hyperspace_2025_logged_out_batch_1","hyperspace_2025_logged_out_batch_2","initial_per_page_pagination_updates","issue_fields_global_search","issue_fields_report_usage","issue_fields_timeline_events","issues_cca_assign_actor_with_agent","issues_dashboard_inp_optimization","issues_expanded_file_types","issues_index_semantic_search","issues_lazy_load_comment_box_suggestions","issues_react_auto_retry_on_error","issues_react_bots_timeline_pagination","issues_react_chrome_container_query_fix","issues_react_defer_hot_cache_preheating","issues_react_deferred_list_data","issues_react_hot_cache","issues_react_low_quality_comment_warning","issues_react_prohibit_title_fallback","issues_react_safari_scroll_preservation","issues_react_use_turbo_for_cross_repo_navigation","landing_pages_ninetailed","landing_pages_web_vitals_tracking","lifecycle_label_name_updates","marketing_pages_search_explore_provider","memex_default_issue_create_repository","memex_display_button_config_menu","memex_grouped_by_edit_route","memex_live_update_hovercard","memex_mwl_filter_field_delimiter","mission_control_retry_on_401","mission_control_use_body_html","oauth_authorize_clickjacking_protection","open_agent_session_in_vscode_insiders","open_agent_session_in_vscode_stable","primer_brand_next","primer_react_css_has_selector_perf","projects_assignee_max_limit","prs_conversations_react","react_quality_profiling","repos_allow_finder_filters_rollout","repos_relevance_page","ruleset_deletion_confirmation","sample_network_conn_type","session_logs_ungroup_reasoning_text","site_calculator_actions_2025","site_features_copilot_universe","site_homepage_collaborate_video","spark_prompt_secret_scanning","spark_server_connection_status","suppress_automated_browser_vitals","suppress_non_representative_vitals","viewscreen_sandbox","webp_support","workbench_store_readonly"],"copilotApiOverrideUrl":"https://api.githubcopilot.com"}</script> <script crossorigin="anonymous" type="application/javascript" src="https://github.githubassets.com/assets/high-contrast-cookie-2c87d5c76bc5d1e0.js"></script> -<script crossorigin="anonymous" type="application/javascript" src="https://github.githubassets.com/assets/wp-runtime-826e1f078bede7e7.js" defer="defer"></script> +<script crossorigin="anonymous" type="application/javascript" src="https://github.githubassets.com/assets/wp-runtime-90e04992d1db2c94.js" defer="defer"></script> <script crossorigin="anonymous" type="application/javascript" src="https://github.githubassets.com/assets/19762-203ba93c6a6f3066.js" defer="defer"></script> <script crossorigin="anonymous" type="application/javascript" src="https://github.githubassets.com/assets/49863-8861e351482cb073.js" defer="defer"></script> <script crossorigin="anonymous" type="application/javascript" src="https://github.githubassets.com/assets/64220-5924ae3b3c473575.js" defer="defer"></script> @@ -98,13 +98,13 @@ <meta name="route-pattern" content="/:user_id/:repository/blob/*name(/*path)" data-turbo-transient> <meta name="route-controller" content="blob" data-turbo-transient> <meta name="route-action" content="show" data-turbo-transient> - <meta name="fetch-nonce" content="v2:8624b6e5-a58b-5e72-a90e-7876584e8ffd"> + <meta name="fetch-nonce" content="v2:fffee6a3-e93a-7c15-e5d1-eda7b6aff1ab"> <meta name="current-catalog-service-hash" content="f3abb0cc802f3d7b95fc8762b94bdcb13bf39634c40c357301c4aa1d67a256fb"> - <meta name="request-id" content="8D68:3F663A:A3D63A0:839BA48:6999840B" data-pjax-transient="true"/><meta name="html-safe-nonce" content="55d67e81931ca07505267c4dae00a5aed62cf2bc19476fe4eb91be0ccfc54d78" data-pjax-transient="true"/><meta name="visitor-payload" content="eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiI4RDY4OjNGNjYzQTpBM0Q2M0EwOjgzOUJBNDg6Njk5OTg0MEIiLCJ2aXNpdG9yX2lkIjoiNjMzNzcxOTcxNDQ0NjkzNTA1MSIsInJlZ2lvbl9lZGdlIjoiZnJhIiwicmVnaW9uX3JlbmRlciI6ImZyYSJ9" data-pjax-transient="true"/><meta name="visitor-hmac" content="668e36cab510e63c951178211edd0fd5a13d3eacd6d9971f909bd9bd59bd9f4c" data-pjax-transient="true"/> + <meta name="request-id" content="DFCA:164DFC:17582338:127EF5DB:699B1DF8" data-pjax-transient="true"/><meta name="html-safe-nonce" content="4cb4f4fc207451ffe443a5e6fe94bcde45043512abe08ec46c3e86ec4a747d10" data-pjax-transient="true"/><meta name="visitor-payload" content="eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiJERkNBOjE2NERGQzoxNzU4MjMzODoxMjdFRjVEQjo2OTlCMURGOCIsInZpc2l0b3JfaWQiOiIyMzI3MTgzOTI2MDkwMjEwODA4IiwicmVnaW9uX2VkZ2UiOiJmcmEiLCJyZWdpb25fcmVuZGVyIjoiZnJhIn0=" data-pjax-transient="true"/><meta name="visitor-hmac" content="11065452a802d0101b6baa1cdf5d97330e18a2e2c3b38491a2b0ed7dcdb4f684" data-pjax-transient="true"/> @@ -210,7 +210,7 @@ <meta name="browser-errors-url" content="https://api.github.com/_private/browser/errors"> - <meta name="release" content="1e9ddf6952a4b738d6e480c258c7af9917702457"> + <meta name="release" content="02ca89815a9cad62d8552002b860a416c0d294bc"> <meta name="ui-target" content="full"> <link rel="mask-icon" href="https://github.githubassets.com/assets/pinned-octocat-093da3e6fa40.svg" color="#000000"> @@ -310,10 +310,10 @@ </a> <div class="AppHeader-appearanceSettings"> <react-partial-anchor> - <button data-target="react-partial-anchor.anchor" id="icon-button-3810bd7d-c57a-4042-881d-36f41eac2a55" aria-labelledby="tooltip-cac1e8ac-8c6d-4e3e-be5b-3ee59758be85" type="button" disabled="disabled" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium AppHeader-button HeaderMenu-link border cursor-wait"> <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-sliders Button-visual"> + <button data-target="react-partial-anchor.anchor" id="icon-button-b2313cd2-e80a-426d-83aa-549edfcbb2fd" aria-labelledby="tooltip-f446e2ac-2723-40a7-8afc-e456762ba538" type="button" disabled="disabled" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium AppHeader-button HeaderMenu-link border cursor-wait"> <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-sliders Button-visual"> <path d="M15 2.75a.75.75 0 0 1-.75.75h-4a.75.75 0 0 1 0-1.5h4a.75.75 0 0 1 .75.75Zm-8.5.75v1.25a.75.75 0 0 0 1.5 0v-4a.75.75 0 0 0-1.5 0V2H1.75a.75.75 0 0 0 0 1.5H6.5Zm1.25 5.25a.75.75 0 0 0 0-1.5h-6a.75.75 0 0 0 0 1.5h6ZM15 8a.75.75 0 0 1-.75.75H11.5V10a.75.75 0 1 1-1.5 0V6a.75.75 0 0 1 1.5 0v1.25h2.75A.75.75 0 0 1 15 8Zm-9 5.25v-2a.75.75 0 0 0-1.5 0v1.25H1.75a.75.75 0 0 0 0 1.5H4.5v1.25a.75.75 0 0 0 1.5 0v-2Zm9 0a.75.75 0 0 1-.75.75h-6a.75.75 0 0 1 0-1.5h6a.75.75 0 0 1 .75.75Z"></path> </svg> -</button><tool-tip id="tooltip-cac1e8ac-8c6d-4e3e-be5b-3ee59758be85" for="icon-button-3810bd7d-c57a-4042-881d-36f41eac2a55" popover="manual" data-direction="s" data-type="label" data-view-component="true" class="sr-only position-absolute">Appearance settings</tool-tip> +</button><tool-tip id="tooltip-f446e2ac-2723-40a7-8afc-e456762ba538" for="icon-button-b2313cd2-e80a-426d-83aa-549edfcbb2fd" popover="manual" data-direction="s" data-type="label" data-view-component="true" class="sr-only position-absolute">Appearance settings</tool-tip> <template data-target="react-partial-anchor.template"> <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/primer-react-css.257816c5781f334a.module.css" /> @@ -361,7 +361,7 @@ -<qbsearch-input class="search-input" data-scope="owner:buetow" data-custom-scopes-path="/search/custom_scopes" data-delete-custom-scopes-csrf="pZNKFGWyfH6hPdNw-x3W_oSfUMWjEDQp7SQzPHkPlPNU2Q5nKrW3ByIr-byXCn9Tmyxz8maEvX7EdpzF15vDVA" data-max-custom-scopes="10" data-header-redesign-enabled="false" data-initial-value="" data-blackbird-suggestions-path="/search/suggestions" data-jump-to-suggestions-path="/_graphql/GetSuggestedNavigationDestinations" data-current-repository="" data-current-org="" data-current-owner="" data-logged-in="false" data-copilot-chat-enabled="false" data-nl-search-enabled="false" data-retain-scroll-position="true"> +<qbsearch-input class="search-input" data-scope="owner:buetow" data-custom-scopes-path="/search/custom_scopes" data-delete-custom-scopes-csrf="r8__dlvfPY92gcGDQG-7MaNYaausZr9KRJ7MhBtej082X7XBpOok8nNDIqAYelf7roGANuF78jkqsD3yzS6Fhw" data-max-custom-scopes="10" data-header-redesign-enabled="false" data-initial-value="" data-blackbird-suggestions-path="/search/suggestions" data-jump-to-suggestions-path="/_graphql/GetSuggestedNavigationDestinations" data-current-repository="" data-current-org="" data-current-owner="" data-logged-in="false" data-copilot-chat-enabled="false" data-nl-search-enabled="false" data-retain-scroll-position="true"> <div class="search-input-container search-with-dialog position-relative d-flex flex-row flex-items-center mr-4 rounded" data-action="click:qbsearch-input#searchInputContainerClicked" @@ -425,7 +425,7 @@ ></div> <div class="QueryBuilder-InputWrapper"> <div aria-hidden="true" class="QueryBuilder-Sizer" data-target="query-builder.sizer"></div> - <input id="query-builder-test" name="query-builder-test" value="" autocomplete="off" type="text" role="combobox" spellcheck="false" aria-expanded="false" aria-describedby="validation-120bdb6f-6ddb-46b7-a894-783c4c7aedd7" data-target="query-builder.input" data-action=" + <input id="query-builder-test" name="query-builder-test" value="" autocomplete="off" type="text" role="combobox" spellcheck="false" aria-expanded="false" aria-describedby="validation-1c7dcb4d-b4b1-4ac5-936b-74237917ddf3" data-target="query-builder.input" data-action=" input:query-builder#inputChange blur:query-builder#inputBlur keydown:query-builder#inputKeydown @@ -666,7 +666,7 @@ ></ul> </div> - <div class="FormControl-inlineValidation" id="validation-120bdb6f-6ddb-46b7-a894-783c4c7aedd7" hidden="hidden"> + <div class="FormControl-inlineValidation" id="validation-1c7dcb4d-b4b1-4ac5-936b-74237917ddf3" hidden="hidden"> <span class="FormControl-inlineValidation--visual"> <svg aria-hidden="true" height="12" viewBox="0 0 12 12" version="1.1" width="12" data-view-component="true" class="octicon octicon-alert-fill"> <path d="M4.855.708c.5-.896 1.79-.896 2.29 0l4.675 8.351a1.312 1.312 0 0 1-1.146 1.954H1.33A1.313 1.313 0 0 1 .183 9.058ZM7 7V3H5v4Zm-1 3a1 1 0 1 0 0-2 1 1 0 0 0 0 2Z"></path> @@ -707,7 +707,7 @@ </div> <scrollable-region data-labelled-by="feedback-dialog-title"> - <div data-view-component="true" class="Overlay-body"> <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="code-search-feedback-form" data-turbo="false" action="/search/feedback" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="GWLy8eVouXdz6HY+k8wno7VnXnOp0MYeF1BxWUxaDFTRh5rU89g3U98cxpzYGCywipXp+2EfGHDR8y68a26HTw==" /> + <div data-view-component="true" class="Overlay-body"> <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="code-search-feedback-form" data-turbo="false" action="/search/feedback" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="lFeMrAyU3TMWKqMyhZFSCKujNtJy+tc6C5YYynzAzSPmBrbtuC2gG6aew1NGJ8l7BphbLoZQvPahR3/aWvarZQ==" /> <p>We read every piece of feedback, and take your input very seriously.</p> <textarea name="feedback" class="form-control width-full mb-2" style="height: 120px" id="feedback"></textarea> <input name="include_email" id="include_email" aria-label="Include my email address so I can be contacted" class="form-control mr-2" type="checkbox"> @@ -745,7 +745,7 @@ <div data-view-component="true" class="Overlay-body"> <div data-target="custom-scopes.customScopesModalDialogFlash"></div> <div hidden class="create-custom-scope-form" data-target="custom-scopes.createCustomScopeForm"> - <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="custom-scopes-dialog-form" data-turbo="false" action="/search/custom_scopes" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="zlZJ7C6O0CWDZTBt7B5qqqSNWSIDQJaowlGfcFecCckF9fu52QGLssmW1SvBApsbIVMUWAKAxAvFf+IACc/0BA==" /> + <!-- '"` --><!-- </textarea></xmp> --></option></form><form id="custom-scopes-dialog-form" data-turbo="false" action="/search/custom_scopes" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="trl4T40Y6jpv+y23HB7xYjuZ4qcsDlwMGkSP6gytEowDyle1WGegwFhQFDd5BVdCUZVii9+6pxXSutm1c3wSdQ==" /> <div data-target="custom-scopes.customScopesModalDialogFlash"></div> <input type="hidden" id="custom_scope_id" name="custom_scope_id" data-target="custom-scopes.customScopesIdField"> @@ -763,7 +763,7 @@ placeholder="github-ruby" required maxlength="50"> - <input type="hidden" data-csrf="true" value="jRIcRYoCu3pZxVmP7GfCeo05Vet/nabQY500faaLUDNrn9WtZwwBrMiGf1pBif/E+SPFvJbekLbb5+p0DSCTSw==" /> + <input type="hidden" data-csrf="true" value="o3QVjgGx31d2TNyQc+ja9vSUdPbzizymhXP7Pw/JTc+ZT5m5+IHlOpQ4fBSp5PcF2mZXMA4VUXy9ehBorIbHKQ==" /> </auto-check> </div> @@ -818,7 +818,7 @@ <h4 data-view-component="true" class="color-fg-default mb-2"> Sign in to GitHub </h4> -<!-- '"` --><!-- </textarea></xmp> --></option></form><form data-turbo="false" action="/session" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="1QcTcEijHrIIQo0koksHxg39ZzTl1PamKfw7KhxJsFQXba7qjFnrjy4GJddcUO6EeIOdzbLrJ8MVe7tMkB+9Ug==" /> <input type="hidden" name="add_account" id="add_account" autocomplete="off" class="form-control" /> +<!-- '"` --><!-- </textarea></xmp> --></option></form><form data-turbo="false" action="/session" accept-charset="UTF-8" method="post"><input type="hidden" data-csrf="true" name="authenticity_token" value="NiESScOmu7qQB/yFYTt/DplpCdFLLQcFn2Y4S+V78RhBGPEkxmNfMoUhXIkx40jeccLkpF1y5ze9+duz3P3+dg==" /> <input type="hidden" name="add_account" id="add_account" autocomplete="off" class="form-control" /> <label for="login_field"> Username or email address @@ -840,9 +840,9 @@ <input type="hidden" name="allow_signup" id="allow_signup" autocomplete="off" class="form-control" /> <input type="hidden" name="client_id" id="client_id" autocomplete="off" class="form-control" /> <input type="hidden" name="integration" id="integration" autocomplete="off" class="form-control" /> -<input class="form-control" type="text" name="required_field_ae7b" hidden="hidden" /> -<input class="form-control" type="hidden" name="timestamp" value="1771668491818" /> -<input class="form-control" type="hidden" name="timestamp_secret" value="b74339c98fa1bd3a315c5ec7409d08bfee509d2a8052614110f7dcf9c07afb6c" /> +<input class="form-control" type="text" name="required_field_8c73" hidden="hidden" /> +<input class="form-control" type="hidden" name="timestamp" value="1771773433036" /> +<input class="form-control" type="hidden" name="timestamp_secret" value="a96a0e2fd4ac35da12fb3b57bf0650b99050f9e5300d70cbcd212be2676fc0b7" /> <input type="submit" name="commit" value="Sign in" class="btn btn-primary btn-block js-sign-in-button" data-disable-with="Signing in…" data-signin-label="Sign in" data-sso-label="Sign in with your identity provider" development="false" disable-emu-sso="false" /> @@ -869,10 +869,10 @@ <div class="AppHeader-appearanceSettings"> <react-partial-anchor> - <button data-target="react-partial-anchor.anchor" id="icon-button-cfa359c5-084f-4167-9940-1210260b9312" aria-labelledby="tooltip-30e63f7a-0397-4df1-b470-86ba843af58c" type="button" disabled="disabled" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium AppHeader-button HeaderMenu-link border cursor-wait"> <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-sliders Button-visual"> + <button data-target="react-partial-anchor.anchor" id="icon-button-e503a1ee-832a-4a8c-90a0-36b650aa2549" aria-labelledby="tooltip-84c8c49d-36cb-4c39-9071-c357301d04d7" type="button" disabled="disabled" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium AppHeader-button HeaderMenu-link border cursor-wait"> <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-sliders Button-visual"> <path d="M15 2.75a.75.75 0 0 1-.75.75h-4a.75.75 0 0 1 0-1.5h4a.75.75 0 0 1 .75.75Zm-8.5.75v1.25a.75.75 0 0 0 1.5 0v-4a.75.75 0 0 0-1.5 0V2H1.75a.75.75 0 0 0 0 1.5H6.5Zm1.25 5.25a.75.75 0 0 0 0-1.5h-6a.75.75 0 0 0 0 1.5h6ZM15 8a.75.75 0 0 1-.75.75H11.5V10a.75.75 0 1 1-1.5 0V6a.75.75 0 0 1 1.5 0v1.25h2.75A.75.75 0 0 1 15 8Zm-9 5.25v-2a.75.75 0 0 0-1.5 0v1.25H1.75a.75.75 0 0 0 0 1.5H4.5v1.25a.75.75 0 0 0 1.5 0v-2Zm9 0a.75.75 0 0 1-.75.75h-6a.75.75 0 0 1 0-1.5h6a.75.75 0 0 1 .75.75Z"></path> </svg> -</button><tool-tip id="tooltip-30e63f7a-0397-4df1-b470-86ba843af58c" for="icon-button-cfa359c5-084f-4167-9940-1210260b9312" popover="manual" data-direction="s" data-type="label" data-view-component="true" class="sr-only position-absolute">Appearance settings</tool-tip> +</button><tool-tip id="tooltip-84c8c49d-36cb-4c39-9071-c357301d04d7" for="icon-button-e503a1ee-832a-4a8c-90a0-36b650aa2549" popover="manual" data-direction="s" data-type="label" data-view-component="true" class="sr-only position-absolute">Appearance settings</tool-tip> <template data-target="react-partial-anchor.template"> <link crossorigin="anonymous" media="all" rel="stylesheet" href="https://github.githubassets.com/assets/primer-react-css.257816c5781f334a.module.css" /> @@ -910,10 +910,10 @@ <span class="js-stale-session-flash-signed-out" hidden>You signed out in another tab or window. <a class="Link--inTextBlock" href="">Reload</a> to refresh your session.</span> <span class="js-stale-session-flash-switched" hidden>You switched accounts on another tab or window. <a class="Link--inTextBlock" href="">Reload</a> to refresh your session.</span> - <button id="icon-button-de44b306-0da6-49b9-9ac3-e236296acae2" aria-labelledby="tooltip-6b6f45b2-91af-4443-ab42-2ad8980bf008" type="button" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium flash-close js-flash-close"> <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-x Button-visual"> + <button id="icon-button-f2b797a4-d1f8-4f89-8714-4b38c66a033b" aria-labelledby="tooltip-7f55372e-e470-4795-9634-ed49affce0fd" type="button" data-view-component="true" class="Button Button--iconOnly Button--invisible Button--medium flash-close js-flash-close"> <svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-x Button-visual"> <path d="M3.72 3.72a.75.75 0 0 1 1.06 0L8 6.94l3.22-3.22a.749.749 0 0 1 1.275.326.749.749 0 0 1-.215.734L9.06 8l3.22 3.22a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L8 9.06l-3.22 3.22a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042L6.94 8 3.72 4.78a.75.75 0 0 1 0-1.06Z"></path> </svg> -</button><tool-tip id="tooltip-6b6f45b2-91af-4443-ab42-2ad8980bf008" for="icon-button-de44b306-0da6-49b9-9ac3-e236296acae2" popover="manual" data-direction="s" data-type="label" data-view-component="true" class="sr-only position-absolute">Dismiss alert</tool-tip> +</button><tool-tip id="tooltip-7f55372e-e470-4795-9634-ed49affce0fd" for="icon-button-f2b797a4-d1f8-4f89-8714-4b38c66a033b" popover="manual" data-direction="s" data-type="label" data-view-component="true" class="sr-only position-absolute">Dismiss alert</tool-tip> diff --git a/gemfeed/2023-08-18-site-reliability-engineering-part-1.md b/gemfeed/2023-08-18-site-reliability-engineering-part-1.md index 5c61f9ac..d42b3126 100644 --- a/gemfeed/2023-08-18-site-reliability-engineering-part-1.md +++ b/gemfeed/2023-08-18-site-reliability-engineering-part-1.md @@ -8,6 +8,7 @@ Being a Site Reliability Engineer (SRE) is like stepping into a lively, ever-evo [2023-11-19 Site Reliability Engineering - Part 2: Operational Balance](./2023-11-19-site-reliability-engineering-part-2.md) [2024-01-09 Site Reliability Engineering - Part 3: On-Call Culture](./2024-01-09-site-reliability-engineering-part-3.md) [2024-09-07 Site Reliability Engineering - Part 4: Onboarding for On-Call Engineers](./2024-09-07-site-reliability-engineering-part-4.md) +[2026-03-01 Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./2026-03-01-site-reliability-engineering-part-5.md) ``` ▓▓▓▓░░ diff --git a/gemfeed/2023-11-19-site-reliability-engineering-part-2.md b/gemfeed/2023-11-19-site-reliability-engineering-part-2.md index 29749257..29070b18 100644 --- a/gemfeed/2023-11-19-site-reliability-engineering-part-2.md +++ b/gemfeed/2023-11-19-site-reliability-engineering-part-2.md @@ -8,6 +8,7 @@ This is the second part of my Site Reliability Engineering (SRE) series. I am cu [2023-11-19 Site Reliability Engineering - Part 2: Operational Balance (You are currently reading this)](./2023-11-19-site-reliability-engineering-part-2.md) [2024-01-09 Site Reliability Engineering - Part 3: On-Call Culture](./2024-01-09-site-reliability-engineering-part-3.md) [2024-09-07 Site Reliability Engineering - Part 4: Onboarding for On-Call Engineers](./2024-09-07-site-reliability-engineering-part-4.md) +[2026-03-01 Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./2026-03-01-site-reliability-engineering-part-5.md) ``` ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣾⣷⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ diff --git a/gemfeed/2024-01-09-site-reliability-engineering-part-3.md b/gemfeed/2024-01-09-site-reliability-engineering-part-3.md index 15b9a170..d79fdbf1 100644 --- a/gemfeed/2024-01-09-site-reliability-engineering-part-3.md +++ b/gemfeed/2024-01-09-site-reliability-engineering-part-3.md @@ -8,6 +8,7 @@ Welcome to Part 3 of my Site Reliability Engineering (SRE) series. I'm currently [2023-11-19 Site Reliability Engineering - Part 2: Operational Balance](./2023-11-19-site-reliability-engineering-part-2.md) [2024-01-09 Site Reliability Engineering - Part 3: On-Call Culture (You are currently reading this)](./2024-01-09-site-reliability-engineering-part-3.md) [2024-09-07 Site Reliability Engineering - Part 4: Onboarding for On-Call Engineers](./2024-09-07-site-reliability-engineering-part-4.md) +[2026-03-01 Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./2026-03-01-site-reliability-engineering-part-5.md) ``` ..--""""----.. diff --git a/gemfeed/2024-09-07-site-reliability-engineering-part-4.md b/gemfeed/2024-09-07-site-reliability-engineering-part-4.md index 4af52caf..22221c30 100644 --- a/gemfeed/2024-09-07-site-reliability-engineering-part-4.md +++ b/gemfeed/2024-09-07-site-reliability-engineering-part-4.md @@ -8,6 +8,7 @@ Welcome to Part 4 of my Site Reliability Engineering (SRE) series. I'm currently [2023-11-19 Site Reliability Engineering - Part 2: Operational Balance](./2023-11-19-site-reliability-engineering-part-2.md) [2024-01-09 Site Reliability Engineering - Part 3: On-Call Culture](./2024-01-09-site-reliability-engineering-part-3.md) [2024-09-07 Site Reliability Engineering - Part 4: Onboarding for On-Call Engineers (You are currently reading this)](./2024-09-07-site-reliability-engineering-part-4.md) +[2026-03-01 Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./2026-03-01-site-reliability-engineering-part-5.md) ``` __..._ _...__ @@ -68,4 +69,10 @@ By structuring the onboarding process with KT sessions, shadowing, comprehensive If you're looking to optimize your on-call onboarding process, these strategies could be your ticket to a more efficient and effective transition. Happy on-calling! +Continue with the fifth part of this series: + +[2026-03-01 Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./2026-03-01-site-reliability-engineering-part-5.md) + +E-Mail your comments to `paul@nospam.buetow.org` :-) + [Back to the main site](../) diff --git a/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.md b/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.md deleted file mode 100644 index 12cb4af8..00000000 --- a/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.md +++ /dev/null @@ -1,302 +0,0 @@ -# Meta slash-commands to manage prompts, skills, and context for coding agents - -> Published at 2026-02-14T13:44:45+02:00, last updated Tue 17 Feb 14:00:00 EET 2026 - -I work on many small, repeatable tasks. Instead of retyping the same instructions every time, I want to turn successful prompts into reusable slash-commands and keep background knowledge in loadable context files. This post describes a set of *meta* slash-commands: commands that create, update, and delete other commands, context files, and skills. They live as markdown in a dotfiles repo and work with any coding agent that supports slash-commands—Claude Code CLI, Cursor Agent, OpenCode, Ampcode, and others. - -> Updated Tue 17 Feb: Added section about skill management commands and the differences between commands and skills - -``` - ┌─────────────────────────────────────────────────────────────┐ - │ Cursor Agent [~][□][X] │ - ├─────────────────────────────────────────────────────────────┤ - │ │ - │ → /load-context api-guidelines │ - │ │ - │ Context loaded: api-guidelines.md │ - │ Ready. Ask me to implement something. │ - │ │ - │ → /create-skill docker-compose │ - │ │ - │ Analyzing "docker-compose"... │ - │ Generated: SKILL.md with frontmatter + instructions. │ - │ Save to skills/docker-compose/ ? [Y] │ - │ │ - │ ✓ Saved. Use /docker-compose anytime. │ - │ │ - └─────────────────────────────────────────────────────────────┘ - │ - │ slash-commands & skills - ▼ - ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ - │ /load- │ │ /create- │ │ /create- │ │ /docker- │ - │ context │ │ command │ │ skill │ │ compose │ - └──────────┘ └──────────┘ └──────────┘ └──────────┘ - │ │ │ │ - └──────────────┴──────────────┴──────────────┘ - │ - coding agent executes - your prompt library -``` - -## Table of Contents - -* [⇢ Meta slash-commands to manage prompts, skills, and context for coding agents](#meta-slash-commands-to-manage-prompts-skills-and-context-for-coding-agents) -* [⇢ ⇢ Motivation: collecting prompts for later re-use](#motivation-collecting-prompts-for-later-re-use) -* [⇢ ⇢ Loading whole context before asking the agent to do something](#loading-whole-context-before-asking-the-agent-to-do-something) -* [⇢ ⇢ Works with any coding agent that supports slash-commands](#works-with-any-coding-agent-that-supports-slash-commands) -* [⇢ ⇢ Commands that manage slash-commands](#commands-that-manage-slash-commands) -* [⇢ ⇢ ⇢ `/create-command`](#create-command) -* [⇢ ⇢ ⇢ `/update-command`](#update-command) -* [⇢ ⇢ ⇢ `/delete-command`](#delete-command) -* [⇢ ⇢ Commands vs skills: when to use which](#commands-vs-skills-when-to-use-which) -* [⇢ ⇢ Commands that manage skills](#commands-that-manage-skills) -* [⇢ ⇢ ⇢ `/create-skill`](#create-skill) -* [⇢ ⇢ ⇢ `/update-skill`](#update-skill) -* [⇢ ⇢ ⇢ `/delete-skill`](#delete-skill) -* [⇢ ⇢ Commands that manage context files](#commands-that-manage-context-files) -* [⇢ ⇢ ⇢ `/create-context`](#create-context) -* [⇢ ⇢ ⇢ `/update-context`](#update-context) -* [⇢ ⇢ ⇢ `/delete-context`](#delete-context) -* [⇢ ⇢ ⇢ `/load-context`](#load-context) -* [⇢ ⇢ Summary](#summary) - -## Motivation: collecting prompts for later re-use - -When I use a coding agent, I often find myself repeating the same kind of request: "review this function," "explain this error," "add tests for this module," "format this as a blog post" and may other cases. Typing long prompts from scratch is tedious, and ad-hoc prompts are easy to forget. I'd rather capture what works and reuse it. - -The solution is to treat prompts as first-class artefacts: store them as markdown files (one file per slash-command or per context), and use a small set of *meta* commands to manage them. The agent then creates, updates, or deletes these files through conversation—no hand-editing of markdowns. I can say `/create-command review-code we just did a code review` and the agent generates the command file based on the current agent's context, shows a preview, and saves it. Later I run `/review-code` and get a consistent workflow every time. - -Because everything is just markdown in directories (`commands/` for commands, `skills/` for skills, and `context/` for context), I can version it in git, sync it across machines, and gradually build a library of prompts. When a command grows too complex for a single file, I promote it to a skill—a structured directory with YAML frontmatter, a "When to Use" section, and detailed instructions. - -## Loading whole context before asking the agent to do something - -A separate but related need is *context*: background information the agent should have before I ask it to do anything. For example, I might have a document describing our Kubernetes setup, API conventions, or the architecture of a specific service. If I ask "add a new endpoint for X" without that context, the agent guesses and without having a reference to an existing project with an `AGENTS.md`. If I first load the relevant context file, the agent knows the naming conventions, the existing patterns, and the infrastructure—and its edits are more accurate. - -So I keep three kinds of artefacts: - -* Commands — Reusable workflows (e.g. "review code", "explain error"). They live as single `.md` files in a `commands/` directory. Meta-commands create, update, and delete them. Commands are simple: one file, one prompt. They work with any coding agent. -* Skills — Richer, more structured artefacts than commands. Each skill lives in its own directory (e.g. `skills/go-best-practices/SKILL.md`) and includes YAML frontmatter with metadata (name, description), a "When to Use" section, and detailed multi-step instructions. Skills can include additional files alongside the `SKILL.md`. They are the right choice when a workflow needs more structure, domain knowledge, or multiple steps. -* Context — Reusable background (project rules, API notes, infrastructure docs, personas). They live as `.md` files in a `context/` directory. I can create, update, delete, and—importantly—*load* them. Loading a context file injects that content into the conversation so the agent has it in mind for subsequent requests. - -The use case is: start a session, run `/load-context api-guidelines` (or whatever context name), then ask the agent to implement a feature or fix a bug. The agent already knows the guidelines. No need to paste a wall of text every time; the context is on demand. - -## Works with any coding agent that supports slash-commands - -I use different agents depending on the task: Claude Code CLI, Cursor Agent (CLI), OpenCode, Ampcode and others. What they have in common is support for custom slash-commands (or the ability to read prompt files). My meta-commands, skills, and context files are just markdown; there is no lock-in. Point your agent at the same directories and you get the same prompts, skills, and context. I don't need an MCP server returning prompts right now—the files on disk are enough. - -## Commands that manage slash-commands - -These meta-commands create, update, and delete other slash-commands. The target files live in `~/Notes/Prompts/commands/` (or your chosen path). Each command is one `.md` file. You can see the commands (and the context files) here: - -[https://codeberg.org/snonux/dotfiles/src/branch/master/prompts/](https://codeberg.org/snonux/dotfiles/src/branch/master/prompts/) - -### `/create-command` - -Creates a new slash-command by inferring its purpose from the name you give. - -* Parameter: `command_name` (e.g. `review-code`, `explain-error`, `optimize-function`) -* What it does: The agent analyses the name, infers intent and parameters, writes a description and prompt, shows a preview, and saves `{{command_name}}.md` to the commands directory. -* Good for: Turning the current task or a recurring need into a reusable command without editing files by hand. - -Example usage: - -``` -/create-command review-code -/create-command explain-error -``` - -### `/update-command` - -Updates an existing slash-command step by step. - -* Parameter: `command_name` (e.g. `create-command`, `review-code`) -* What it does: Reads the existing `.md` file, shows the current content, asks what to change (description, parameters, prompt text), applies edits, shows a preview, and saves. -* Good for: Refining a command after you've used it a few times or when requirements change. - -Example usage: - -``` -/update-command create-command -/update-command review-code -``` - -### `/delete-command` - -Removes a slash-command by deleting its definition file. - -* Parameter: `command_name` (e.g. `testing`, `review-code`) -* What it does: Verifies the file exists, shows what will be deleted, asks for confirmation, then deletes the file. -* Good for: Cleaning up experiments or commands you no longer use. - -Example usage: - -``` -/delete-command testing -/delete-command review-code -``` - -## Commands vs skills: when to use which - -Commands and skills both produce reusable slash-commands, but they differ in structure and intent: - -``` -| Aspect | Command | Skill | -|-----------------|--------------------------------|----------------------------------------| -| File layout | Single .md file in commands/ | Directory with SKILL.md in skills/ | -| Metadata | Markdown heading + description | YAML frontmatter (name, description) | -| Structure | Free-form prompt text | "When to Use" + structured instructions| -| Complexity | Simple, single-purpose prompts | Multi-step workflows, domain knowledge | -| Extra files | No | Yes (can include supporting files) | -| Best for | Quick one-shot tasks | Rich, repeatable processes | -``` - -Use a **command** when you need a quick, single-purpose prompt—something like "review this PR" or "explain this error." Use a **skill** when the workflow is more involved: it needs structured instructions, domain-specific knowledge, or multiple steps that the agent should follow in order. For example, my `go-best-practices` skill contains detailed conventions for project structure, naming, error handling, and testing—far more than would fit comfortably in a flat command file. - -The YAML frontmatter in skills (`name` and `description` between `---` fences at the top of the file) is what makes skills discoverable by the coding agent. When the agent starts a session, it scans the skills directory and reads the frontmatter to build a list of available skills—without having to parse the entire file. The `name` field gives the skill its slash-command name, and the `description` tells the agent (and the user) what the skill does, so the agent can suggest the right skill for a given task. Commands don't need this metadata because they are simpler: the filename *is* the command name, and the first heading serves as the description. - -In practice, I start with a command and promote it to a skill once it grows beyond a simple prompt. - -## Commands that manage skills - -These meta-commands create, update, and delete skills. Skills live in `~/Notes/Prompts/skills/`, each in its own directory containing a `SKILL.md` file with YAML frontmatter. - -### `/create-skill` - -Creates a new skill by inferring its purpose from the name you give. - -* Parameter: `skill_name` (e.g. `docker-compose`, `rust-conventions`) -* What it does: The agent analyses the name, infers intent, creates a directory `skills/{{skill_name}}/`, generates a `SKILL.md` with YAML frontmatter (`name`, `description`), a "When to Use" section, and detailed instructions. Shows a preview before saving. -* Good for: Creating structured, multi-step workflows that need more organisation than a simple command. - -Example usage: - -``` -/create-skill docker-compose -/create-skill rust-conventions -``` - -### `/update-skill` - -Updates an existing skill step by step. - -* Parameter: `skill_name` (e.g. `go-best-practices`, `compose-blog-post`) -* What it does: Reads the existing `SKILL.md`, shows its current content, asks what to change (description, "When to Use" section, instructions), applies edits, shows a preview, and saves. -* Good for: Refining a skill after real-world usage or when conventions evolve. - -Example usage: - -``` -/update-skill go-best-practices -/update-skill compose-blog-post -``` - -### `/delete-skill` - -Removes a skill by deleting its entire directory. - -* Parameter: `skill_name` (e.g. `docker-compose`, `rust-conventions`) -* What it does: Verifies the skill exists, shows what will be deleted, asks for confirmation, then removes the `skills/{{skill_name}}/` directory. -* Good for: Cleaning up experimental or unused skills. - -Example usage: - -``` -/delete-skill docker-compose -/delete-skill rust-conventions -``` - -## Commands that manage context files - -These meta-commands create, update, delete, and *load* context files. Context files live in `~/Notes/Prompts/context/`. Loading a context injects its content into the conversation so the agent can use it for subsequent requests. - -### `/create-context` - -Creates a new context file. - -* Parameter: `context_name` (without `.md`), e.g. `epimetheus`, `api-guidelines` -* What it does: Checks if the context already exists, asks what the context should contain (background, structure, sections), then writes `{{context_name}}.md` to the context directory. -* Good for: Capturing project rules, API conventions, or infrastructure notes once and reusing them via `/load-context`. - -Example usage: - -``` -/create-context epimetheus -/create-context api-guidelines -``` - -### `/update-context` - -Updates an existing context file by adding, modifying, or removing content. - -* Parameter: `context_name` (e.g. `epimetheus`, `api-guidelines`). If omitted, lists available context files. -* What it does: Reads the existing file, asks what to change (add section, modify section, remove section, rewrite, or full overhaul), applies changes, and saves. -* Good for: Keeping context up to date as the project or infrastructure evolves. - -Example usage: - -``` -/update-context epimetheus -/update-context api-guidelines -/update-context -``` - -### `/delete-context` - -Deletes a context file after confirmation. - -* Parameter: `context_name` (e.g. `epimetheus`, `old-api-guidelines`). If omitted, lists available context files. -* What it does: Verifies the file exists, shows a preview or summary, asks for confirmation, then deletes the file. -* Good for: Removing outdated or unused context. - -Example usage: - -``` -/delete-context epimetheus -/delete-context old-api-guidelines -/delete-context -``` - -### `/load-context` - -Loads a context file into the conversation so the agent has that background for subsequent requests. - -* Parameter: `context_name` (e.g. `epimetheus`, `api-guidelines`). If omitted, lists available context files. -* What it does: Reads the context file, displays its content, and confirms it is loaded. From then on, the agent can use that information when you ask it to implement features, fix bugs, or answer questions. -* Good for: Starting a session with "load our API guidelines" or "load our Kubernetes runbook" so the agent knows the infrastructure and conventions before you ask it to do something. - -Example usage: - -``` -/load-context epimetheus -/load-context api-guidelines -/load-context -``` - -## Summary - -``` -| Meta-command | Purpose | Good for | -|--------------------|----------------------------------------------|---------------------------------------------------| -| /create-command | Create new slash-command from name | Turning current or recurring tasks into commands | -| /update-command | Edit existing slash-command | Refining commands over time | -| /delete-command | Remove slash-command file | Cleaning up unused commands | -| /create-skill | Create new skill with structured instructions| Building rich, multi-step workflows | -| /update-skill | Edit existing skill | Refining skills as conventions evolve | -| /delete-skill | Remove skill directory | Cleaning up experimental or unused skills | -| /create-context | Create new context file | Capturing project/infra knowledge once | -| /update-context | Edit existing context file | Keeping context up to date | -| /delete-context | Remove context file | Removing outdated context | -| /load-context | Load context into conversation | Giving the agent background before tasks | -``` - -Context is what the agent *knows*; commands and skills are what the agent *does*—commands for simple prompts, skills for structured multi-step workflows. All three are markdown files you can create, update, and delete on the fly through the same coding agent—Claude Code CLI, Cursor Agent, OpenCode, Ampcode, or any other that supports slash-commands or prompt files. Start with commands for quick tasks, promote to skills when complexity grows, and load context when the agent needs background knowledge. - -Other related posts: - -[2026-02-14 Meta slash-commands to manage prompts, skills, and context for coding agents (You are currently reading this)](./2026-02-14-meta-slash-commands-for-prompts-and-context.md) -[2026-02-02 A tmux popup editor for Cursor Agent CLI prompts](./2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.md) - -E-Mail your comments to `paul@nospam.buetow.org` :-) - -[Back to the main site](../) diff --git a/gemfeed/2026-03-01-site-reliability-engineering-part-5.md b/gemfeed/2026-03-01-site-reliability-engineering-part-5.md new file mode 100644 index 00000000..bc2c78a9 --- /dev/null +++ b/gemfeed/2026-03-01-site-reliability-engineering-part-5.md @@ -0,0 +1,64 @@ +# Site Reliability Engineering - Part 5: System Design, Incidents, and Learning + +> Published at 2026-03-01T12:00:00+02:00 + +Welcome to Part 5 of my Site Reliability Engineering (SRE) series. I'm currently working as a Site Reliability Engineer, and I'm here to share what SRE is all about in this blog series. + +[2023-08-18 Site Reliability Engineering - Part 1: SRE and Organizational Culture](./2023-08-18-site-reliability-engineering-part-1.md) +[2023-11-19 Site Reliability Engineering - Part 2: Operational Balance](./2023-11-19-site-reliability-engineering-part-2.md) +[2024-01-09 Site Reliability Engineering - Part 3: On-Call Culture](./2024-01-09-site-reliability-engineering-part-3.md) +[2024-09-07 Site Reliability Engineering - Part 4: Onboarding for On-Call Engineers](./2024-09-07-site-reliability-engineering-part-4.md) +[2026-03-01 Site Reliability Engineering - Part 5: System Design, Incidents, and Learning (You are currently reading this)](./2026-03-01-site-reliability-engineering-part-5.md) + +``` + ___ + / \ resilience + | o | <---------- learning + \___/ +``` + +This time I want to share some themes that build on what we've already covered: how system design and incident analysis fit together, why observability should not be an afterthought, and how a design‑improvement loop keeps systems getting better. Let's dive in! + +## Table of Contents + +* [⇢ Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](#site-reliability-engineering---part-5-system-design-incidents-and-learning) +* [⇢ ⇢ System Design and Incident Analysis](#system-design-and-incident-analysis) +* [⇢ ⇢ ⇢ Resilience and cascading failures](#resilience-and-cascading-failures) +* [⇢ ⇢ ⇢ Learning from incidents](#learning-from-incidents) +* [⇢ ⇢ Observability: Don't leave it for when it's too late](#observability-don-t-leave-it-for-when-it-s-too-late) +* [⇢ ⇢ The iterative spirit](#the-iterative-spirit) +* [⇢ ⇢ Book tips](#book-tips) + +## System Design and Incident Analysis + +A big chunk of SRE work revolves around system design and incident analysis. What separates a well-designed system from a mediocre one is its ability to minimise and contain cascading failures. Unchecked, those can spiral into global outages. + +### Resilience and cascading failures + +There's a growing emphasis on building resilient systems so that when something fails, the blast radius stays small. That resilience needs to be baked in at design time: we identify weak points and address them before production. The goal is to keep services dependable and uninterrupted. + +### Learning from incidents + +When incidents do happen, their analysis is a goldmine. Every incident exposes gaps—whether in tooling (ops tools that aren't up to the job) or in skills (engineers missing critical know-how). Blaming "human error" doesn't help. The job is to dig into root causes and fix the system. Postmortems that focus on customer impact help us distil lessons and make the system more robust so we're less likely to repeat the same failure. + +System design and incident analysis form a feedback loop: we improve the design based on what we learn from incidents, and a better design reduces the impact of the next one. + +## Observability: Don't leave it for when it's too late + +Product and features often get the spotlight; observability is often an afterthought. Teams agree that "we need better observability" when they're already in the middle of an incident—and by then it's too late. Good observability needs to be in place before things go wrong. Tools that can query high-cardinality data and give granular insight into system behaviour are what let us diagnose problems quickly when chaos hits. So invest in observability early. When the next incident happens, you'll be glad you did. + +## The iterative spirit + +We also accept that system design is never "done." We refine it based on real-world performance, incident learnings, and changing needs. Every incident is a chance to learn and improve; the emphasis is on learning, not blame. SREs work with developers, backend teams, and incident response so that the whole system keeps getting better. Perfection is a journey, not a destination. + +## Book tips + +If you want to go deeper, here are a few books I can recommend: + +* 97 Things Every SRE Should Know: Collective Wisdom from the Experts by Emily Stolarsky and Jaime Woo +* Site Reliability Engineering: How Google Runs Production Systems by Jennifer Petoff, Niall Murphy, Betsy Beyer, and Chris Jones +* Implementing Service Level Objectives by Alex Hidalgo + +E-Mail your comments to `paul@nospam.buetow.org` :-) + +[Back to the main site](../) diff --git a/gemfeed/DRAFT-site-reliability-engineering.md b/gemfeed/DRAFT-site-reliability-engineering.md deleted file mode 100644 index b5471cdd..00000000 --- a/gemfeed/DRAFT-site-reliability-engineering.md +++ /dev/null @@ -1,152 +0,0 @@ -## System Design and Incident Analysis: Building Resilience in the SRE Landscape - -A significant portion of the work revolves around system design and incident analysis. - -The first axiom is the acceptance of a bitter truth: things will always break. No matter the precision of which a system is crafted, the inevitability of failures looms large. However, what distinguishes a well-designed system from a mediocre one is its ability to minimise and contain cascading failures. These failures, if left unchecked, can spiral into global outages with come with consequences. - -There's a growing emphasis on building resilient systems to avoid such cascading failures to circumvent this. Such resilience requires foresight in system design, wherein potential weakpoints are identified and addressed before deployed to production. Prevention is better than cure. The primary objective is ensuring that services remain uninterrupted and dependable. - -Yet, despite these preventative measures, when incidents do arise, their analysis becomes a goldmine of learning. Every incident exposes gaps within the system. Instead of attributing these incidents to nebulous concepts like "human error," the onus is on dissecting them to uncover underlying systemic issues. Whether it's a tooling gap where operational tools prove insufficient or an operational expertise gap where engineers lack critical skills, incident analysis shines a light on these deficiencies. - -In doing so, incident analysis is about rectifying the immediate issue and learning and evolving the system design. Every incident offers an opportunity, a feedback loop, to refine the system further. Through rigorous postmortems focusing on customer impact, organisations can distil valuable lessons. These lessons, when incorporated, make the system more robust and less susceptible to similar failures in the future. - -Moreover, as systems grow more complex, the importance of observability tools cannot be overstated. These tools, designed to query against high cardinality data, provide granular insights into system operations. They enable engineers to diagnose problems rapidly, especially in the chaotic aftermath of an incident, giving clarity amidst the turmoil. - -In conclusion, the symbiotic relationship between system design and incident analysis underscores the evolving ethos of SRE. While impeccable system design lays the foundation for reliable operations, incident analysis ensures that this foundation remains robust and dynamic, adapting to challenges. Together, they form the pillars of a resilient, customer-centric service environment that stands the test of time. - -Add paragraph about product wants features, but observability is often an afterthought. So often, during an incident, people start agreeing, and then it was already too late. - -[6 minutes to wt.](add) - -## The Heroic Facade and Team Dynamics: Rethinking Success in SRE - -The realm of Site Reliability Engineering is punctuated by the constant ebb and flow of system challenges. While individual excellence is commendable, the overarching belief in the SRE culture should be that true success lies in cohesive teamwork and not in individual heroics. - -he SRE Hero is an anti-pattern that can occur when a few individuals consistently step in to save the day during incidents or emergencies, earning themselves the status of heroes. While this might seem positive at first, it can lead to several negative outcomes and should be addressed to ensure the reliability and sustainability of the SRE team's operations. These individuals might possess specialized knowledge, quick problem-solving skills, or simply a willingness to work long hours. As a result, they become the go-to people whenever something goes wrong. - -This culture can emerge for various reasons: - -- Immediate Problem Solving: Heroes are praised for their ability to solve issues quickly. However, this may lead to bypassing proper post-incident analysis and learning, as the focus is on getting systems up and running as fast as possible. - -- Burnout and Fatigue: Heroes are often overworked and stressed, leading to burnout and high turnover rates. - -- Skill Asymmetry: If only a few team members possess specific knowledge or skills, others may not have the chance to learn, grow, and take on more responsibilities. - -- Dependency: Teams become dependent on heroes, leading to a lack of collaboration and shared ownership of systems. - -How can you fix it? - -- Incident Reviews and Post-Mortems: Conduct thorough post-incident reviews to understand the root causes of issues. Focus on learning and prevention rather than just quick fixes. - -- Distribute Knowledge: Encourage knowledge sharing by documenting incidents, solutions, and best practices. Consider implementing a knowledge-sharing platform or wiki. - -- Rotating Responsibilities: Rotate on-call and incident response responsibilities among team members. This prevents burnout and ensures that everyone gains experience. - -- Automation and Tooling: Develop automation and tools that enable the entire team to handle incidents more effectively, reducing the reliance on individual heroics. - -- Training and Skill Development: Provide training and resources to help all team members enhance their skills. This levels the playing field and reduces skill asymmetry. - -- Recognize Collaborative Efforts: Shift the focus from individual heroics to collaborative efforts. Recognize and reward team members who contribute to preventive measures, incident response improvements, and system stability. - -- Leadership Support: Management should actively support efforts to address the hero culture. This might involve setting expectations for collaboration, learning, and shared responsibility. - -- Celebrate Learning: Emphasize that learning from failures is a positive outcome. This encourages a culture of continuous improvement rather than blame. - -By addressing the hero culture and fostering a collaborative, learning-oriented environment, SRE teams can enhance their overall effectiveness, prevent burnout, and ensure the long-term stability of the systems they manage. - - - - -The allure of the "hero" is undeniable. There's a certain appeal in being the one who swoops in, fixes critical incidents, and saves the day. However, this hero culture, while often romanticised, has its pitfalls. Heroes are necessary, no doubt, but a hero culture can often obscure the collaborative essence of SRE. Recognising that heroes do their best work as part of a team is a profound acknowledgement that true heroes don't need a hero culture to excel. - -The danger of a hero-driven approach is that it can lead to an over-reliance on specific individuals. The assumption that certain team members will always be there to address and mitigate issues can be a dangerous precedent. It fosters a reactive culture rather than a proactive one. Instead of developing inherently more resilient and reliable systems, the organisation starts relying on these heroes as a Band-Aid® solution, masking deeper systemic problems. - -A further dimension to this issue is the impact on team morale. Continually being in the spotlight, heroes might be inadvertently sidelining other team members, leading to feelings of underappreciation or undervaluation. Such a dynamic can hinder sharing knowledge, collaboration, and preparation – the pillars that successful SRE teams are built on. - -However, this isn't to say that individual excellence should be curbed. Instead, it's about shifting the narrative. Building a team culture based on collaboration ensures that knowledge sharing becomes second nature. Such an environment propels teams towards a dynamic where preparation and proactive measures are valued over-reactive heroics. When success stories are shared as a collective win, it boosts team morale and fosters a sense of shared responsibility. - -In the broader spectrum of SRE, it's also crucial to recognise the silent work – the preventive measures, the well-thought-out systems, the meticulous planning – that ensures incidents don't occur. This proactive approach often goes unnoticed because, in a well-functioning system, the absence of issues is the norm. But this 'silence' is a testament to a team working harmoniously, with every member contributing towards system reliability. - -To conclude, while the heroics in SRE can often be the stuff of legends, it's vital to see beyond this facade. The countless hours of teamwork, collaboration, and shared responsibility lie in the shadows of these heroic acts. The future of SRE lies not in individual heroics but in teams that operate like well-oiled machines, with every cog, big or small, playing its part to perfection. - -## Monitoring, Observability, and the SRE Arsenal: Navigating the Nuances of System Reliability - -Site Reliability Engineering is characterised by a relentless quest for reliability, uptime, and seamless user experiences. Within this universe, the notions of monitoring and observability emerge not as mere tools but as critical lifelines that guide decision-making, error diagnosis, and preventive strategies. - -At its core, monitoring is vigilantly monitoring system health, alerting engineers to potential anomalies that might adversely impact system performance or availability. Every alert is treated as an exceptional circumstance warranting immediate attention. However, it's worth noting that only some alerts translate into genuine threats. As such, if an alert merely adds noise without substance, the onus is on refining the monitoring system to filter out such distractions. This process of continuous refinement underscores the dynamism inherent in effective monitoring. - -In tandem with monitoring is the concept of observability. Beyond just knowing that something went wrong, observability equips engineers with the 'why.' It offers a deep dive into the system's intricate operations, allowing for a granular understanding of its behaviours. Observability tools designed to query against high cardinality data become the SRE's best allies in this endeavour. They help comprehensively diagnose problems, especially when conventional monitoring alerts might not capture the nuanced layers of an issue. - -However, monitoring and observability aren't standalone entities; they feed into the broader ambit of error budgets, service level objectives (SLOs), and service level indicators (SLIs). These metrics and frameworks collectively serve as a mirror, reflecting the true health of services. While SLIs define quantitative measures about the reliability of services, SLOs set targets for these measures. On the other hand, error budgets provide a tangible metric of 'how wrong things can go' before the service quality deteriorates below acceptable levels. - -Yet, the human element remains paramount amidst this arsenal of tools and methodologies. No matter how sophisticated, observational tools are only as valuable as the engineers wielding them. It demands a spirit of curiosity, a relentless quest for knowledge, and a willingness to delve deep into data-driven narratives. SREs, therefore, need to be both technically adept and intrinsically motivated to leverage these tools to their fullest potential. - -To sum it up, monitoring and observability play pivotal roles in the intricate dance of system reliability. They are the compass and map, guiding SREs through the labyrinthine challenges of modern systems. By leveraging them effectively and in conjunction with other SRE methodologies, organisations can achieve the zenith of reliability, ensuring that their services remain robust, resilient, and remarkably user-centric. - -## The Ever-evolving Landscape of SRE - -To begin, the very fabric of SRE is interwoven with organisational culture. Successful SRE adoption transcends the mere automation of software operations—it is deeply cultural. It demands a seismic shift in how organisations perceive failures, value preventative work, and prioritise communication. In such an environment, writing is not just a skill but a critical tool for reliability. Precise communication enhances clarity, mitigates risks, and facilitates collaboration. - -Central to SRE's operational philosophy is the balance between innovation and stability. Every system has its error budget, representing the acceptable threshold of issues before service quality falls below expectations. These error budgets are more than mere metrics—they guide decisions, helping organisations balance pushing new features and ensuring system reliability. Such operational nuances remind us that while things will inevitably break in the engineering world, the informed response, driven by data and proactive work, sets SRE apart. - -However, the brilliance of SRE is not merely in the systems but the people powering it. The human element in SRE is both its strength and vulnerability. On the one hand, SREs must be ceaselessly curious, ready to adopt new learnings, and willing to iterate rapidly. On the other, the high-stakes environment and demanding on-call rotations place them at risk of burnout. It's a stark reminder that while systems need monitoring, the well-being of those who maintain them is equally crucial. Organisations must ensure that on-call schedules are sustainable, mentorship is available, and continuous learning is encouraged. - -The SRE world is also marked by its vast arsenal of monitoring systems, observability tools, postmortems, and more. These tools, designed for high cardinality data querying, are pivotal in diagnosing problems, especially when traditional monitoring might miss the subtleties. Yet, tools alone aren't the panacea. The SRE's mindset, the ability to discern tooling gaps, operational expertise voids, and resource inadequacies truly elevates the discipline. - -In conclusion, as a discipline, SRE is a beacon of continuous evolution. As systems grow more complex and user expectations rise, the SRE landscape will inevitably shift, demanding adaptability, resilience, and foresight from its practitioners. But in this ever-changing terrain, the core tenets remain—balancing innovation with reliability, valuing human well-being, and leveraging tools and data for informed decision-making. In the grand tapestry of engineering, SRE stands out as a dynamic, challenging, yet immensely rewarding realm, ever-responsive to the rhythms of technology and human ingenuity. - -## Effective Communication and Collaboration in SRE - -Site Reliability Engineering is not merely a technical discipline. At its core, SRE underscores the importance of effective communication and collaboration as critical tenets of a resilient and efficient system. - -The dynamics of modern organisations, especially those heavily reliant on technology, present systems of such complexity that no single individual possesses a complete understanding. As highlighted from the insights, "Each person inside an organisation has only a partial understanding of how the overall system works." Such compartmentalisation necessitates a culture of open communication and collaboration to ensure that different components, managed by other teams, work in harmony. - -The importance of communication is not just limited to the intra-team dynamics but extends to how teams convey the value of their work, especially the preventive work that pre-empts potential incidents. As many SREs might attest, we live in a data-driven world, but capturing the metrics on incidents that didn't occur due to preventive measures is a challenge. This highlights the need for SREs to be adept at articulating the significance of their roles and their actions to ensure system reliability. It's about making the invisible work visible, ensuring stakeholders understand the value delivered. - -Further emphasising the role of communication, the insights suggest, "Writing is good for reliability; the more precise, the better." Precise communication, whether in documentation, runbooks, or postmortems, is essential for ensuring that every team member, whether an SRE or from an allied discipline, is on the same page. It mitigates the risk of misunderstandings that could compromise system reliability. - -On the other side of the coin is collaboration. An SRE's role frequently involves liaising with various teams, be it developers, back-end teams, or dedicated incident response teams. Effective collaboration with these teams is crucial in a crisis. When cascading failures occur and overload symptoms present simultaneously, this culture of collaboration can make the difference between swift mitigation and a full-blown global outage. - -Furthermore, the insights provide a perspective against fostering a hero culture. "Recognise that heroes do their best work as part of a team, and true heroes don't need a hero culture to do good." Such a sentiment emphasises the collective over the individual. It's a call to ensure team dynamics are built on mutual respect, trust, and a shared understanding of goals rather than relying on individual brilliance. - -In conclusion, while SRE is deeply technical, its efficacy is intertwined with the soft skills of communication and collaboration. As systems grow more intricate and the stakes rise, the ability to communicate clearly and collaborate effectively will distinguish successful SRE teams from the rest. It's a reminder that there are people at the heart of every machine, every line of code, and nurturing human connections is paramount to ensuring machine efficiency. - -## Inherent Curiosity and Continual Learning in SRE - -The realm of Site Reliability Engineering is expansive, dynamic, and deeply integrated with the ever-evolving technological landscape. It's evident that an essential trait underpinning successful SRE practice combines inherent curiosity and an unwavering commitment to continual learning. - -Within modern organisations, technology infrastructures have burgeoned into complex ecosystems. It's been highlighted that "each person inside an organisation has only a partial understanding of how the overall system works." In such an environment, an SRE cannot afford to be siloed or static in their knowledge. The intricacies of systems and the myriad of potential issues necessitate that SREs possess an innate curiosity. It's this curiosity that drives them to explore beyond their immediate purview, to question why systems behave the way they do, and to unravel the intricacies that lie beneath surface-level observations. - -Yet, curiosity alone isn't enough. The pace at which technology evolves is staggering. New tools emerge architectural paradigms shift, and what was once a best practice might become obsolete in a short span. To keep up with this dynamism, SREs need to be invested in continual learning. Whether mastering a new observability tool designed for high cardinality data or understanding the nuances of error budgets and their implications, SREs must be lifelong learners. - -This commitment to learning is about more than just keeping up-to-date with tools and practices. It's about broadening one's horizon and developing a holistic understanding of systems. As cascading failures emerge and system outages threaten, an SRE with a comprehensive knowledge base built on continual learning is better equipped to identify root causes, devise mitigation strategies, and ensure system resilience. - -Furthermore, as we glean from the insights, there's a marked shift in the perception of SRE as a discipline. We're transitioning into an era where "an SRE mindset will be an important hiring requirement for every engineering role." Such a shift implies that the principles of SRE are becoming fundamental to the broader engineering domain. And at the heart of this mindset is the thirst for knowledge and the spirit of exploration. - -In conclusion, the world of Site Reliability Engineering is not for the complacent. It's a domain that rewards the curious, the seekers, and those with an insatiable appetite for knowledge. As systems grow in complexity and the stakes become higher, this inherent curiosity and dedication to continual learning will define the success and resilience of SRE endeavours. The journey of an SRE, thus, is one of perpetual exploration, driven by the quest to know more and do better. - -## The Iterative Spirit of SRE - -Site Reliability Engineering is more than just a technical discipline; it embodies a mindset that embraces iteration, proactive problem-solving, and continuous enhancement. - -At the core of the SRE ethos lies the principle that prevention trumps cure. To build systems resilient to cascading failures and ensure that user impact is minimised, SREs work diligently to improve system designs. However, a crucial component of this prevention strategy is recognising that system designs will never be perfect. Instead, they are continually refined based on real-world performance, learnings from incidents, and shifting user needs. By leveraging tools like error budgets and performance metrics, SREs can gauge the effectiveness of their systems, identify areas of concern, and make informed decisions about where to allocate resources for improvements. - -Moreover, the SRE approach to incident analysis further underscores this iterative spirit. No matter how minor, every incident is viewed as an opportunity to learn. Incidents expose gaps, areas where the system's design or execution fell short. Through postmortems focusing on customer impact and detailed investigations, these gaps become learning avenues, leading to system refinements. The emphasis isn't on apportioning blame but on extracting insights that can fuel the next iteration of the system. - -In conjunction with system design, the tools and practices employed by SREs are also subject to this iterative refinement. Observability tools designed for high cardinality data, rollback automation, and failover tooling are all components of the SRE arsenal, but their effectiveness isn't taken for granted. SREs are consistently evaluating the efficacy of their tools, ensuring that they align with the current system demands and making enhancements as required. The idea is not to find the 'perfect' tool but to recognise that as systems evolve, the tools to manage them must evolve in tandem. - -Finally, the SRE's iterative spirit extends to collaboration and communication. The continual drive to enhance and refine is not a solitary endeavour. SREs actively collaborate with developers, back-end teams, and dedicated incident response units. This collaborative approach ensures that diverse perspectives contribute to the iterative process and collective wisdom is harnessed. - -In summary, the essence of Site Reliability Engineering is characterised by an iterative spirit, a recognition that perfection is a journey, not a destination. Whether refining system designs, enhancing tooling or fostering collaborative dialogues, SREs are always looking for the next improvement, refinement, and iteration. It's this spirit that ensures systems are reliable and continually evolving to meet the ever-changing demands of the digital age. - -## The role of simplicity Simplicity - -## Book tips - -* 97 Things Every SRE Should Know: Collective Wisdom from the Experts by Emily Stolarsky and Jaime Woo -* Site Reliability Engineering: How Google runs Production Systems by by Jennifer Petoff, Niall Murphy, Betsy Beyer and Chris Jones -* Implementing Service Level Objectives by Alex Hidalgo - -E-Mail your comments to `paul@nospam.buetow.org` :-) - -[Back to the main site](../) diff --git a/gemfeed/DRAFT-taskwarrior-autonomous-agent-loop.md b/gemfeed/DRAFT-taskwarrior-autonomous-agent-loop.md deleted file mode 100644 index 7f4f21fe..00000000 --- a/gemfeed/DRAFT-taskwarrior-autonomous-agent-loop.md +++ /dev/null @@ -1,477 +0,0 @@ -# Taskwarrior as an autonomous AI agent loop: 48 tasks in one day - -> Published at 2026-02-21T23:11:13+02:00 - -[](./taskwarrior-autonomous-agent/ior-flamegraph.png) - -I let Ampcode autonomously complete 48 Taskwarrior tasks on my eBPF project in a single day. The agent picked up one task after another — implemented, self-reviewed, spawned sub-agent reviews, addressed comments, committed, and moved on — all without me intervening. Here is how the setup works, what the project is about, and the full skill that drives the loop. - -[Ampcode — the AI coding agent used for this project](https://ampcode.com) - -## Table of Contents - -* [⇢ Taskwarrior as an autonomous AI agent loop: 48 tasks in one day](#taskwarrior-as-an-autonomous-ai-agent-loop-48-tasks-in-one-day) -* [⇢ ⇢ What is ior and what does it do](#what-is-ior-and-what-does-it-do) -* [⇢ ⇢ ⇢ What is a syscall](#what-is-a-syscall) -* [⇢ ⇢ ⇢ What is eBPF](#what-is-ebpf) -* [⇢ ⇢ ⇢ What ior traces and why](#what-ior-traces-and-why) -* [⇢ ⇢ The problem: writing a full test suite by hand](#the-problem-writing-a-full-test-suite-by-hand) -* [⇢ ⇢ Before and after](#before-and-after) -* [⇢ ⇢ How the project-taskwarrior skill works](#how-the-project-taskwarrior-skill-works) -* [⇢ ⇢ ⇢ SKILL.md — the entry point](#skillmd--the-entry-point) -* [⇢ ⇢ ⇢ 00-context.md — project scoping and global rules](#00-contextmd--project-scoping-and-global-rules) -* [⇢ ⇢ ⇢ 1-create-task.md — creating tasks with full context](#1-create-taskmd--creating-tasks-with-full-context) -* [⇢ ⇢ ⇢ 2-start-task.md — fresh context per task](#2-start-taskmd--fresh-context-per-task) -* [⇢ ⇢ ⇢ 3-complete-task.md — the quality gate](#3-complete-taskmd--the-quality-gate) -* [⇢ ⇢ ⇢ 4-annotate-update-task.md — progress tracking](#4-annotate-update-taskmd--progress-tracking) -* [⇢ ⇢ ⇢ 5-review-overview-tasks.md — picking the next task](#5-review-overview-tasksmd--picking-the-next-task) -* [⇢ ⇢ The reflection and review loop](#the-reflection-and-review-loop) -* [⇢ ⇢ Code review: human spot-check at the end](#code-review-human-spot-check-at-the-end) -* [⇢ ⇢ Measurable results](#measurable-results) -* [⇢ ⇢ A real bug found by the review loop](#a-real-bug-found-by-the-review-loop) -* [⇢ ⇢ Gotchas and lessons learned](#gotchas-and-lessons-learned) -* [⇢ ⇢ ⇢ Cost](#cost) -* [⇢ ⇢ ⇢ Syscall wrappers on amd64](#syscall-wrappers-on-amd64) -* [⇢ ⇢ ⇢ Task granularity matters](#task-granularity-matters) -* [⇢ ⇢ How to replicate this](#how-to-replicate-this) - -## What is ior and what does it do - -I/O Riot NG (ior) is a Linux-only tool that traces synchronous I/O system calls in real time and produces flamegraphs showing which processes spend time on which files with which syscalls. It is written in Go and C, using eBPF via libbpfgo. It is the spiritual successor of an older project of mine called I/O Riot, which was based on SystemTap and C. - -[](./taskwarrior-autonomous-agent/ior-logo.png) - -[I/O Riot NG on Codeberg](https://codeberg.org/snonux/ior) -[The original I/O Riot (SystemTap)](https://codeberg.org/snonux/ioriot) - -At the top of the blog post you see an example flamegraph produced by ior. The x-axis shows sample count (how frequent each I/O operation is), and the stack from bottom to top shows process ID, file path, and syscall tracepoint. You can immediately see which processes hammer which files with which syscalls. - -### What is a syscall - -A syscall (system call) is the interface between a user-space program and the Linux kernel. When a program wants to do anything that touches hardware or shared resources — open a file, read from a socket, write to disk, create a directory, check file permissions — it cannot do it directly. User-space programs run in an unprivileged CPU mode and have no access to hardware. They must ask the kernel by making a syscall. - -For example, when a program calls `open("/etc/passwd", O_RDONLY)`, it triggers the `openat` syscall. The CPU switches from user mode to kernel mode, the kernel validates the request, locates the file on disk, allocates a file descriptor, and returns it to the program — or returns an error code like ENOENT if the file does not exist. Every file operation, every network packet, every process fork goes through syscalls. They are the fundamental boundary between "your code" and "the operating system." - -There are hundreds of syscalls in Linux. The I/O-related ones that ior traces include: - -* `openat`, `creat`, `open_by_handle_at` — opening files -* `read`, `write`, `pread64`, `pwrite64`, `readv`, `writev` — reading and writing data -* `close`, `close_range` — closing file descriptors -* `dup`, `dup2`, `dup3` — duplicating file descriptors -* `fcntl` — manipulating file descriptor properties -* `rename`, `renameat`, `renameat2` — renaming files -* `link`, `linkat`, `symlink`, `symlinkat`, `readlinkat` — creating and reading links -* `unlink`, `unlinkat`, `rmdir` — removing files and directories -* `mkdir`, `mkdirat`, `chdir`, `getdents64` — directory operations -* `stat`, `fstat`, `lstat`, `newfstatat`, `statx`, `access`, `faccessat` — file metadata -* `fsync`, `fdatasync`, `sync`, `sync_file_range` — flushing data to disk -* `truncate`, `ftruncate` — resizing files -* `io_uring_setup`, `io_uring_enter`, `io_uring_register` — async I/O - -### What is eBPF - -eBPF (extended Berkeley Packet Filter) is a technology in the Linux kernel that lets you run sandboxed programs inside the kernel without changing kernel source code or loading kernel modules. Originally designed for network packet filtering, it has grown into a general-purpose in-kernel virtual machine. - -With eBPF, you write small C programs that the kernel verifies for safety (no infinite loops, no out-of-bounds access, no crashing the kernel) and then runs at de-facto native speed in a VM inside of the Linux Kernel. These programs can attach to tracepoints — predefined instrumentation points in the kernel that fire whenever a specific event occurs, such as a syscall being entered or exited. - -ior uses eBPF to attach to the entry and exit tracepoints of every I/O-related syscall. When any process on the system calls `openat`, for example, the kernel fires the `sys_enter_openat` tracepoint, ior's BPF program captures the filename, PID, thread ID, and timestamp, and sends that data to user-space via a ring buffer. When the syscall returns, the `sys_exit_openat` tracepoint fires, and ior captures the return value and duration. This happens with near-zero overhead because the BPF program runs inside the kernel — there is no context switch to user-space for each event. - -### What ior traces and why - -ior pairs up syscall enter and exit events, tracks which file descriptors map to which file paths, and aggregates everything into a data structure that can be serialized to a compressed `.ior.zst` file or rendered as a flamegraph. The flamegraph shows a hierarchy of PID, file path, and syscall tracepoint, with the width proportional to how often or how long each combination occurs. - -This is useful for diagnosing I/O bottlenecks: you can see at a glance that process 5171 is spending most of its time writing to `/sys/fs/cgroup/memory.stat`, or that your database is doing thousands of `fsync` calls per second on its WAL file. Traditional tools like `strace` can show you this too, but `strace` uses ptrace which has significant overhead and slows down the traced process. eBPF-based tracing is orders of magnitude faster. - -## The problem: writing a full test suite by hand - -The ior project needed a comprehensive test suite at two levels: - -* Unit tests in `internal/eventloop_test.go` — these simulate raw BPF tracepoint data (byte slices), feed them into the event loop, and verify that enter/exit events are correctly paired, file descriptors are tracked, comm names are propagated, and filters work. No BPF, no kernel, no root required. -* Integration tests in `integrationtests/` — these launch a real `ioworkload` binary that performs actual syscalls, start ior with real BPF tracing against that process, wait for it to finish, and then parse the resulting `.ior.zst` file to verify that the expected tracepoints were captured. These require root and a running kernel with BPF support. - -Both levels needed happy-path tests (does it work correctly?) and negative tests (does it handle errors like ENOENT, EBADF, EEXIST, EINVAL correctly?). Across 13 syscall categories, that is a lot of test code — roughly 93 scenarios, each with its own workload implementation and test assertions. Having the LLM to instruct each of those tasks would have taken days and writing all of this by hand would take months. - -## Before and after - -Before I set up the Taskwarrior skill, my workflow with Ampcode looked like this: I would manually review the agent's output, then instruct it what to do next. One task at a time, constant babysitting. The agent had no memory of what was done or what was next. Context would degrade as the conversation grew longer. - -After: I front-loaded about 48 tasks into Taskwarrior with detailed descriptions and file references (Ampcode itself helped here to create the tasks as well), then told Ampcode a single instruction: "complete this task, then automatically proceed to the next ready +integrationtests task by handing off with fresh context." It ran for about 6 hours autonomously. I reviewed the commits over coffee. - -The key difference is that Taskwarrior acts as persistent memory and a work queue. The agent does not need to remember what it did — the task list tells it what is done and what is next. Each task hands off to a fresh Ampcode thread, so there is no context window degradation. Ampcode's handoff mechanism — where one thread spawns a new one with a goal description — maps perfectly onto Taskwarrior's task-by-task workflow. - -## How the project-taskwarrior skill works - -``` - ┌──────────────────────────────────────────────────┐ - │ │ - │ task add pro:ior "implement open_test.go" +agent │ - │ task add pro:ior "implement close_test.go" +agent│ - │ task add pro:ior "add negative tests" +agent │ - │ ... × 48 │ - │ │ - │ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ - │ │ Agent │ ─▶│ Self- │ ─▶│ Sub-agent│ │ - │ │ works │ │ review │ │ review │ │ - │ └─────────┘ └──────────┘ └──────────┘ │ - │ │ │ │ │ - │ │ fix │ fix │ │ - │ │◀─────────────┘◀─────────────┘ │ - │ │ │ - │ ▼ │ - │ git commit + push │ - │ task <id> done │ - │ ──▶ hand off to next task (fresh context) │ - │ │ - └──────────────────────────────────────────────────┘ -``` - -The skill lives in `~/.agents/skills/project-taskwarrior/` and consists of a `SKILL.md` entry point plus six markdown files — one per action. The agent loads only the files it needs for the current action, so it does not waste context on instructions it does not need right now. - -### SKILL.md — the entry point - -Every Ampcode skill has a `SKILL.md` with YAML frontmatter (name, description, trigger phrases) and an overview. This is what the agent sees first when it loads the skill: - -``` ---- -name: project-taskwarrior -description: "Manage Taskwarrior tasks scoped to the current git - project. Use when asked to list, add, start, complete, annotate, - or organize tasks for the project. Triggers on: tasks, todo, - task list, pick next task, what's next." ---- - -# Project Taskwarrior - -Taskwarrior tasks are scoped to the current git repository. -Load only the files you need for the current action so the whole -skill does not need to be in context. - -## When to load what - -| Action | Load | -|---------------------------|---------------------------------------| -| Create task | 00-context.md + 1-create-task.md | -| Start task | 00-context.md + 2-start-task.md | -| Complete task | 00-context.md + 3-complete-task.md | -| Annotate / update task | 00-context.md + 4-annotate-update.md | -| Review / overview tasks | 00-context.md + 5-review-overview.md | - -Always load 00-context.md first (project name resolution and -global rules); then load the one action file that matches what -you are doing. - -## Task lifecycle (overview) - -1. Create task -2. Start task -3. Annotate as you go -4. Completion criteria (best practices, compilable, all tests - pass, negative tests where plausible) -5. Sub-agent review (fresh context) -6. Main agent addresses all review comments -7. Second sub-agent review (fresh context again) to confirm fixes -8. Commit all changes to git -9. Complete task - -A task is not done until criteria are met, all review comments -are addressed, a second sub-agent review has confirmed the code, -and all changes are committed to git. Details are in -3-complete-task.md. -``` - -The key design decision is the table: the agent only loads the files relevant to what it is doing right now. Creating a task? Load `00-context.md` + `1-create-task.md`. Completing one? Load `00-context.md` + `3-complete-task.md`. This keeps context lean. - -### 00-context.md — project scoping and global rules - -This file is loaded with every action. It derives the project name from git and enforces that the agent only touches its own tasks (tagged `+agent`): - -``` -# Project Taskwarrior — shared context - -Load this with any of the action files (1–5) when working with tasks. -It defines project scope and rules that apply to all task operations. - -## Project name - -Derive the project name from the git repository: - - basename -s .git \ - "$(git remote get-url origin 2>/dev/null)" 2>/dev/null \ - || basename "$(git rev-parse --show-toplevel)" - -Use it as project:<name> in every task command. - -## Rules that apply to all task commands - -- Project and tag matching: The agent only reads, modifies, or - creates tasks that have both project:<name> and the +agent tag. - Do not touch any task that does not have +agent set. -- EVERY task command MUST include project:<name> — no exceptions. - When listing or querying, also include +agent so only - agent-managed tasks are shown. Never run a bare task without - the project filter. -- NEVER modify, delete, complete, start, or annotate tasks from - other projects or tasks without +agent. -- One task in progress per project. Do not start a second task - while another is started and not completed, unless the user - explicitly asks. -- Parallel work via sub-agents — the agent may spawn sub-agents - to work on tasks in parallel only after the user approves. -``` - -### 1-create-task.md — creating tasks with full context - -This is the most important file for setting up the autonomous loop. Every task must be self-contained — it must reference all files, docs, and specs needed so that an agent starting with zero prior context can work on it: - -``` -# Create task - -## Rules for new tasks - -- Create tasks in smaller chunks that fit into the context window. - Break work into multiple tasks so that each task's scope, - description, and required context can fit in one context window. -- Every task MUST have at least one tag for sub-project/feature/area - (e.g. +integrationtests, +flamegraph, +bpf, +cli). -- When an agent creates a task, always add the tag +agent. -- Include references to all context required to work on the task. - Every task must list or link everything needed: relevant files, - docs, specs, other tasks, or project guidelines. Put these in - the task description or in an initial annotation. - -## Add a task - - task add project:<name> +<tag> +agent "Description" - -## With dependency - - task add project:<name> +<tag> +agent "Description" depends:<id> - -## Conventions - -- Keep tasks small: each task should fit in the context window. -- Add dependencies when one task must complete before another. -- Add references to all required context so the task is - self-contained for fresh-context work. -``` - -### 2-start-task.md — fresh context per task - -This ensures each task gets a clean slate — no carry-over from previous work: - -``` -# Start task - -## Start each new task with a fresh context - -Work on each new task must begin with a fresh context — a new -session or a sub-agent with no prior conversation. That way the -task is executed with clear focus and no carry-over from other -work. The task itself should already contain references to all -required context; read the task description and all annotations -to get files, docs, and specs before starting. - -## Mark task as started - -When you begin working on a task, always mark it as started: - - task <id> start - -Do this as soon as you start work on the task. - -## Conventions - -- Start each new task with a fresh context. -- Run task <id> start when you start working. -- Do not start a second task for the same project while one is - already started and not done. -``` - -### 3-complete-task.md — the quality gate - -This is the heart of the skill. It enforces compilation, testing, negative tests, self-review, and a dual sub-agent review loop before any task can be marked done: - -``` -# Complete task - -## Completion criteria (required before "done") - -A task is not considered done until all of the following are true: - -- Best practices — the codebase follows the project's best - practices. -- Compilable — all code compiles successfully. -- Tests pass — all tests pass. -- Negative tests where plausible — for any new or changed tests, - include negative tests wherever plausible. -- All changes committed to git. - -## What the review sub-agent must check - -Review sub-agents (first and second review) must always: - -- Unit test coverage — double-check that coverage is as desired - for the changed or added code. -- Tests are testing real things — confirm that tests exercise - real behavior and assertions, not only mocks. Flag tests that - merely assert on mocks or stubs without verifying real logic. -- Negative tests where plausible — for all tests created, ensure - there are also negative tests. If positive tests exist but no - corresponding negative tests, flag it. - -## Self-review before any sub-agent handoff - -Before signing off work to sub-agents for review, the main agent -must ask itself: - -- Did everything I did make sense? -- Isn't there a better way to do it? - -If the answer suggests improvements, address them first. Only -then hand off to the sub-agent. - -## Before marking complete - -1. Self-review. Then spawn a sub-agent with fresh context. -2. Sub-agent reviews the diff, code, or deliverables and reports - back (review comments, suggestions, issues). -3. Main agent addresses all review comments — no exceptions. -4. Self-review again. Then spawn another sub-agent (fresh context) - to review the code again and confirm the fixes. If this second - review finds further issues, address them and repeat. -5. Commit all changes to git. -6. Only then: task <id> done - -## Conventions - -- A task is not done until: best practices met, code compiles, - all tests pass, negative tests included, all review comments - addressed, second sub-agent review confirmed, and all changes - committed to git. -``` - -### 4-annotate-update-task.md — progress tracking - -``` -# Annotate / update task - -## Reading task context - -When working on a task, always read the full context: description, -summary, and all annotations. Annotations often contain progress, -challenges, and references to files or documents. - -## Annotate a task - - task <id> annotate "Note about progress or context" - -While making progress, add annotations to reflect progress, -challenges, or decisions. Refer to files and documents so the -task history stays useful for later work and for the -pre-completion review. - -## Modify a task - - task <id> modify +<tag> - task <id> modify depends:<id2> - task <id> modify priority:H -``` - -### 5-review-overview-tasks.md — picking the next task - -``` -# Review / overview tasks - -## List tasks for the project - -Only list tasks that have +agent. Order by priority first, then -urgency: - - task project:<name> +agent list sort:priority-,urgency- - -## Picking what to work on (next task) - -Order by priority first, then by urgency. Check already-started -tasks first: - - task project:<name> +agent start.any: list - -If any tasks are already started, use one of those. Only if no -tasks are in progress, show the next actionable (READY) task: - - task project:<name> +agent +READY list sort:priority-,urgency- - -## Blocked vs ready - - task project:<name> +agent +BLOCKED list - task project:<name> +agent +READY list -``` - -## The reflection and review loop - -The real unlock was not just task automation — it was instructing Ampcode to reflect on its own work and then having it reviewed by a fresh pair of eyes. - -Having instructed in the skill for the agent to reflect on its own implementation ("Did everything I did make sense? Isn't there a better way?"), and then having a sub-agent with fresh context review all the changes and letting the main agent address the review comments, followed by another sub-agent reviewing the improvements again, made it a smooth ride. - -The sub-agent reviews consistently caught things the main agent missed — tests that only asserted on mocks, missing edge cases, and even a real bug. Without the dual review loop, the agent tends to write tests that look correct but do not actually exercise real behavior. - -## Code review: human spot-check at the end - -On top of the agent's self-reflection and the two sub-agent reviews per task, I reviewed the produced outcome at the end. I did not read through all 5k lines one by one. Instead I looked for repeating patterns across the test files and cherry-picked a few scenarios — for example one integration test from the open/close family, one from the rename/link family, and one negative test — and went through those in detail manually. That was enough to satisfy me that the workflow had produced consistent, runnable tests and that the whole pipeline (task → implement → self-review → sub-agent review → fix → second review → commit) was working as intended. - -## Measurable results - -Here is what one day of autonomous Ampcode work produced: - -* About 6 hours of autonomous work (16:13 to 22:03) -* 48 Taskwarrior tasks completed -* 47 git commits -* 87 files changed -* ~5,000 lines added, ~500 removed -* 18 integration test files -* 15 workload scenario files (one per syscall category) -* 93 test scenarios total (happy-path and negative) -* 13 syscall categories fully covered: open, read/write, close, dup, fcntl, rename, link, unlink, dir, stat, sync, truncate, and io_uring - -## A real bug found by the review loop - -During the negative test implementation for `close_range`, the review loop uncovered a real bug in ior's event loop. The `close_range` handler was deleting file descriptors from the internal `files` map before resolving their paths. This meant the path information was lost by the time ior tried to record it in the flamegraph. The fix was to look up the path first, then delete the fd. This bug would have been very hard to notice by reading the code — it only became apparent when a negative test expected a path in the output and got nothing. - -## Gotchas and lessons learned - -### Cost - -I burned through about 100 USD in one day on Ampcode's token-based pricing. The dual sub-agent reviews are thorough but token-heavy — each task effectively runs three agents (main plus two reviewers), and with 48 tasks that adds up fast. Lesson learned: I am subscribing to Claude Max next. If you are going to let an agent run autonomously for hours, flat-rate pricing is the way to go. - -### Syscall wrappers on amd64 - -Go's `syscall` package on amd64 silently delegates to `*at` variants. `os.Open()` calls `openat`, `os.Mkdir()` calls `mkdirat`, `os.Stat()` calls `newfstatat`. The agent kept writing tests expecting `enter_open` when the kernel actually sees `enter_openat`. I had to burn this into task descriptions as a permanent note: "CRITICAL: Always verify what the actual syscall is before writing test expectations." Once this was in the task context, the agent got it right every time. - -### Task granularity matters - -Tasks that were too broad ("add all integration tests") produced worse results than tasks scoped to a single syscall category ("implement open_test.go + workload scenarios for open, openat, creat, open_by_handle_at"). The smaller tasks fit in the context window, the agent could focus, and the review loop could meaningfully check the output. Bigger tasks led to context degradation and the agent cutting corners. - -## How to replicate this - -The recipe: - -* Use Taskwarrior (or any task tracker the agent can query via CLI). -* Create an agent skill that teaches the agent the task lifecycle: create, start, implement, self-review, sub-agent review, fix, second review, commit, done, hand off. -* Front-load tasks with detailed descriptions and file references. Each task must be self-contained. -* Tag tasks so the agent only works on its own tasks and does not touch anything else. -* Instruct the agent to hand off to a fresh context after completing each task. In Ampcode, this is the handoff mechanism that spawns a new thread with a goal. -* Enforce a quality gate: compilation, tests, negative tests, and dual sub-agent review before marking done. -* Use flat-rate pricing if you plan to run autonomously for hours. - -The skill files shown above are generic — they work for any git project and any coding agent that can run shell commands. The Taskwarrior CLI is the interface; the skill markdown is the instruction set. You can adapt them to your own project by changing the tags and the completion criteria. - -[Taskwarrior — command-line task management](https://taskwarrior.org) - -Other related posts: - -[2026-02-02 A tmux popup editor for Cursor Agent CLI prompts](./2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.md) -[2023-07-17 "Software Developers Career Guide and Soft Skills" book notes](./2023-07-17-career-guide-and-soft-skills-book-notes.md) - -E-Mail your comments to `paul@nospam.buetow.org` :-) - -[Back to the main site](../) diff --git a/gemfeed/DRAFT-totalrecall.md b/gemfeed/DRAFT-totalrecall.md deleted file mode 100644 index 4d1684d1..00000000 --- a/gemfeed/DRAFT-totalrecall.md +++ /dev/null @@ -1,272 +0,0 @@ -# TotalRecall: Learning Bulgarian with AI and Anki - -> Published at 2025-01-22T10:30:00+02:00 - -Learning a new language is hard. Learning Bulgarian? That's a special kind of challenge. The Cyrillic script, the complex grammar, the pronunciation - it all adds up. But what if we could leverage AI to make flashcard creation instant and effortless? That's where TotalRecall comes in. - -[TotalRecall on GitHub](https://github.com/yourusername/totalrecall) - -``` - ╔══════════════════════════════╗ - ║ 🇧🇬 TOTALRECALL 🧠 ║ - ║ ┌─────────┐ ┌─────────┐ ║ - ║ │ ябълка │→ │ 🍎 │ ║ - ║ │ [audio] │ │ "apple" │ ║ - ║ └─────────┘ └─────────┘ ║ - ╚══════════════════════════════╝ -``` - -## Table of Contents - -* [⇢ TotalRecall: Learning Bulgarian with AI and Anki](#totalrecall-learning-bulgarian-with-ai-and-anki) -* [⇢ ⇢ Why TotalRecall exists](#why-totalrecall-exists) -* [⇢ ⇢ ⇢ Learning Bulgarian](#learning-bulgarian) -* [⇢ ⇢ ⇢ Practicing agentic coding](#practicing-agentic-coding) -* [⇢ ⇢ How it works](#how-it-works) -* [⇢ ⇢ ⇢ The AI pipeline](#the-ai-pipeline) -* [⇢ ⇢ ⇢ Why OpenAI for everything?](#why-openai-for-everything) -* [⇢ ⇢ The science of memorable flashcards](#the-science-of-memorable-flashcards) -* [⇢ ⇢ ⇢ No English on the front](#no-english-on-the-front) -* [⇢ ⇢ ⇢ The power of personal connection](#the-power-of-personal-connection) -* [⇢ ⇢ ⇢ Sound comes first](#sound-comes-first) -* [⇢ ⇢ ⇢ Images over translations](#images-over-translations) -* [⇢ ⇢ ⇢ IPA for precision](#ipa-for-precision) -* [⇢ ⇢ Spaced repetition: The secret sauce](#spaced-repetition-the-secret-sauce) -* [⇢ ⇢ ⇢ Start small, stay consistent](#start-small-stay-consistent) -* [⇢ ⇢ ⇢ Review first, add new cards second](#review-first-add-new-cards-second) -* [⇢ ⇢ ⇢ Trust the algorithm](#trust-the-algorithm) -* [⇢ ⇢ ⇢ Quality over quantity](#quality-over-quantity) -* [⇢ ⇢ The technical bits](#the-technical-bits) -* [⇢ ⇢ Agentic coding insights](#agentic-coding-insights) -* [⇢ ⇢ ⇢ Clear communication is crucial](#clear-communication-is-crucial) -* [⇢ ⇢ ⇢ AI excels at boilerplate and testing](#ai-excels-at-boilerplate-and-testing) -* [⇢ ⇢ ⇢ The scaling challenge](#the-scaling-challenge) -* [⇢ ⇢ ⇢ Code duplication becomes a real problem](#code-duplication-becomes-a-real-problem) -* [⇢ ⇢ ⇢ Tests are your safety net](#tests-are-your-safety-net) -* [⇢ ⇢ ⇢ The context window problem](#the-context-window-problem) -* [⇢ ⇢ My learning workflow](#my-learning-workflow) -* [⇢ ⇢ ⇢ Morning routine](#morning-routine) -* [⇢ ⇢ ⇢ Encountering new words](#encountering-new-words) -* [⇢ ⇢ ⇢ Weekly maintenance](#weekly-maintenance) -* [⇢ ⇢ Future plans](#future-plans) -* [⇢ ⇢ Tips for language learners](#tips-for-language-learners) -* [⇢ ⇢ ⇢ Focus on frequency](#focus-on-frequency) -* [⇢ ⇢ ⇢ Use memory palaces](#use-memory-palaces) -* [⇢ ⇢ ⇢ Study before sleep](#study-before-sleep) -* [⇢ ⇢ ⇢ Embrace the mess](#embrace-the-mess) -* [⇢ ⇢ Try it yourself](#try-it-yourself) - -## Why TotalRecall exists - -Two motivations drove me to create this tool: - -### Learning Bulgarian - -I've been fascinated by the Bulgarian language for a while now. It's the oldest written Slavic language, and Sofia has become quite the tech hub. But finding good learning materials? That's tough. Most apps focus on the big languages - Spanish, French, German. Bulgarian gets the short end of the stick. - -AnkiDroid has been my go-to for spaced repetition learning. It's powerful, customizable, and works offline. But creating cards manually? That's tedious. Type the word, find an image, record audio, format everything... By the time you've made 10 cards, you're exhausted. - -### Practicing agentic coding - -The second reason is more technical. I wanted to explore agentic coding - letting AI assistants help write and refactor code. TotalRecall became my playground for this experiment. Could I build something useful while learning how to effectively collaborate with AI coding assistants? - -Turns out, yes. The combination of human creativity and AI assistance is powerful. I set the architecture, made design decisions, and the AI helped with implementation details, test writing, and refactoring. - -## How it works - -TotalRecall is beautifully simple: - -```bash -totalrecall "ябълка" -``` - -That's it. One command, and you get a complete flashcard with everything you need. But there's sophisticated AI magic happening behind the scenes. - -### The AI pipeline - -When you run that command, TotalRecall orchestrates multiple OpenAI API calls: - -1. **Translation** - Bidirectional translation (Bulgarian ↔ English) to understand the word's meaning -2. **Phonetic transcription** - IPA notation for precise pronunciation guidance -3. **Scene description** - AI generates a culturally appropriate scene description for the image -4. **Image generation** - DALL-E creates a memorable visual based on the scene description -5. **Audio synthesis** - High-quality TTS pronunciation that can be regenerated with different voices - -All this happens in seconds. The result? A rich, multi-sensory flashcard that engages visual, auditory, and linguistic memory systems. - -### Why OpenAI for everything? - -I could have used Google Translate for translations, or pulled IPA from Wiktionary. But OpenAI's models understand context. When you input "банка", it knows whether you mean "bank" (financial) or "jar" based on usage patterns. The scene descriptions are culturally aware - Bulgarian bread looks different from American bread, and the AI knows this. - -## The science of memorable flashcards - -After reading extensively about language learning and memory techniques, I've built TotalRecall to create cards that stick. Here's why our approach works: - -### No English on the front - -The cards show only Bulgarian text and images - no English translations on the front. This forces your brain to recall meaning from context and imagery, creating stronger neural pathways. When you see "ябълка" with an apple image, your brain learns to connect the Bulgarian word directly to the concept, not to the English word "apple." - -### The power of personal connection - -The best flashcards include personal context. While TotalRecall generates generic images, I recommend adding your own notes about where you first encountered the word. Did you see "хляб" (bread) at a Bulgarian bakery? Add that story. Personal connections make memories stick. So at will, a custom image prompt (not AI generated) can be specified. - -### Sound comes first - -Native pronunciation from day one is crucial. That's why every card includes audio. Your brain needs to hear the rhythm and melody of Bulgarian, not your English-accented approximation. The OpenAI voices aren't perfect, but they're leagues better than text-to-speech engines of the past. Plus, you can regenerate audio with different voices if one doesn't sound quite right. - -### Images over translations - -A picture of bread teaches "хляб" better than the word "bread" ever could. Images bypass linguistic processing and create direct conceptual links. DALL-E generates contextually appropriate images - Bulgarian bread looks different from Wonder Bread, and these cultural nuances matter. - -### IPA for precision - -The phonetic transcriptions are gold for pronunciation. Bulgarian has sounds that don't exist in English. The IPA shows you exactly where to place your tongue, how to shape your lips. It's the difference between sounding foreign and sounding fluent. - -## Spaced repetition: The secret sauce - -Anki's algorithm is based on the spacing effect - we remember things better when we review them at increasing intervals. Here's how to maximize it: - -### Start small, stay consistent - -Don't add 100 words on day one. Start with 10-15 new cards daily. Consistency beats intensity. Your brain needs time to consolidate memories during sleep. - -### Review first, add new cards second - -Always clear your review queue before adding new cards. Reviews are where the real learning happens. New cards are just seeds - reviews make them grow. - -### Trust the algorithm - -When Anki says to review a card in 4 months, trust it. The urge to over-review is strong, but it actually weakens memory formation. Let your brain struggle a bit - that's where learning happens. - -### Quality over quantity - -One well-made card beats ten mediocre ones. TotalRecall ensures quality with: -- Clear, native audio with regeneration options -- Relevant, memorable images from scene-aware descriptions -- IPA transcriptions for pronunciation precision -- Clean, distraction-free formatting - -## The technical bits - -Written in Go because I wanted something fast and portable. The architecture is clean: - -``` -internal/ -├── audio/ # OpenAI TTS integration -├── image/ # DALL-E image generation -├── anki/ # Card formatting -├── phonetic/ # IPA transcription fetching -├── translation/ # Bidirectional translation -└── config/ # YAML configuration -``` - -Each package has a single responsibility. The audio package doesn't know about images. The image package doesn't know about Anki. Clean interfaces everywhere. - -## Agentic coding insights - -Working with AI assistants taught me several valuable lessons: - -### Clear communication is crucial - -Vague requests get vague results. "Make it better" doesn't work. "Refactor this 80-line function into smaller functions, each handling one responsibility" does. The AI needs specific, actionable instructions. - -### AI excels at boilerplate and testing - -Writing comprehensive test suites? Perfect AI task. Implementing error handling patterns? Also great. Creative architecture decisions? Still very much a human job. The AI is your implementation partner, not your architect. - -### The scaling challenge - -Here's the hard truth about agentic coding: it gets exponentially harder as your codebase grows. When TotalRecall was 500 lines, the AI could keep everything in context. At 2000 lines? Not so much. - -Features start colliding in unexpected ways. You add batch processing, and suddenly the GUI breaks because it assumes single-word input. You change the default output directory, and it updates in the GUI but not in the CLI batch mode. The AI doesn't see these connections because it can't hold your entire codebase in memory. - -### Code duplication becomes a real problem - -The AI tends to solve problems locally. Need to validate Bulgarian input? It'll write a validation function right where you need it. Need it again elsewhere? It'll write another one. Before you know it, you have three different ways to validate Cyrillic text. - -This isn't the AI being dumb - it's optimizing for the local context you've given it. The burden of architectural consistency falls on you, the human. - -### Tests are your safety net - -The larger the codebase, the more critical comprehensive tests become. Every time the AI touches code, it might break something three files away. Without tests, you won't know until a user complains. - -My rule: before any AI-assisted refactoring, ensure test coverage. The AI is great at writing tests, so use it! Have it write tests for existing code before modifying anything. Then, when it inevitably breaks something, you'll know immediately. - -### The context window problem - -Modern AI assistants have impressive context windows, but they're not infinite. As TotalRecall grew, I had to become strategic about what context to provide. The entire codebase? Too much. Just the current file? Too little. - -The sweet spot: provide the interface definitions, the specific module you're working on, and any directly dependent code. Let the AI know about the broader architecture through comments and documentation, not by dumping everything into context. - -So after every feature, clear the context window and/or compact it to start fresh. - -## My learning workflow - -Here's how I use TotalRecall in practice: - -### Morning routine - -* Review all due cards in Anki (usually 50-100) -* which includes the review of failed cards -* Add 10-15 new words I encountered yesterday - -### Encountering new words - -When I find a new Bulgarian word (in articles, videos, conversations): - -1. Immediately run `totalrecall "word"` -2. Add personal context in Anki notes -3. Tag it with source (e.g., #news, #conversation) - -### Weekly maintenance -- Delete cards for words I'll never use -- Suspend cards I've truly mastered -- Adjust ease factors for consistently hard cards - -## Future plans - -TotalRecall already packs a lot of features, but I'm planning more: -- Batch processing for word lists -- Support for phrases and sentences -- Grammar pattern recognition -- Integration with Bulgarian dictionaries -- Automatic difficulty scoring based on word frequency -- Multiple image generation options per word -- Voice selection preferences per word - -But the real goal? Building a comprehensive Bulgarian deck for AnkiDroid. One command at a time, one word at a time. - -## Tips for language learners - -### Focus on frequency -Learn the most common 1000 words first. In any language, the top 1000 words cover ~80% of everyday conversation. TotalRecall will eventually include frequency data to help prioritize. - -### Use memory palaces -Assign Bulgarian words to locations in your home. Put "хладилник" (refrigerator) on your actual fridge. Spatial memory is incredibly powerful. - -### Study before sleep -Review your hardest cards right before bed. Your brain consolidates memories during sleep, especially from the last hour before sleeping. - -### Embrace the mess -Language learning is messy. You'll mix up cases, forget words you "knew" yesterday, and butcher pronunciation. That's normal. TotalRecall makes it easy to try again tomorrow. - -## Try it yourself - -If you're learning Bulgarian (or want to experiment with agentic coding), give TotalRecall a spin: - -```bash -go install github.com/yourusername/totalrecall@latest -export OPENAI_API_KEY="your-key" -totalrecall "котка" # cat -totalrecall "куче" # dog -totalrecall "вода" # water -``` - -Learning languages should be fun, not tedious. Let's make better tools. - -E-Mail your comments to `paul@nospam.buetow.org` :-) - -Other related posts are: - - -[Back to the main site](../) diff --git a/gemfeed/index.md b/gemfeed/index.md index f8634a5f..862b0110 100644 --- a/gemfeed/index.md +++ b/gemfeed/index.md @@ -2,9 +2,9 @@ ## To be in the .zone! +[2026-03-01 - Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./2026-03-01-site-reliability-engineering-part-5.md) [2026-02-22 - My desk rack: DeskPi RackMate T0](./2026-02-22-my-desk-rack.md) [2026-02-15 - Loadbars resurrected: From Perl to Go after 15 years](./2026-02-15-loadbars-resurrected-from-perl-to-go.md) -[2026-02-14 - Meta slash-commands to manage prompts, skills, and context for coding agents](./2026-02-14-meta-slash-commands-for-prompts-and-context.md) [2026-02-02 - A tmux popup editor for Cursor Agent CLI prompts](./2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.md) [2026-01-01 - Using Supernote Nomad offline](./2026-01-01-using-supernote-nomad-offline.md) [2026-01-01 - Posts from July to December 2025](./2026-01-01-posts-from-july-to-december-2025.md) diff --git a/gemfeed/taskwarrior-autonomous-agent/ior-flamegraph.png b/gemfeed/taskwarrior-autonomous-agent/ior-flamegraph.png Binary files differdeleted file mode 100644 index 80e9230b..00000000 --- a/gemfeed/taskwarrior-autonomous-agent/ior-flamegraph.png +++ /dev/null diff --git a/gemfeed/taskwarrior-autonomous-agent/ior-logo.png b/gemfeed/taskwarrior-autonomous-agent/ior-logo.png Binary files differdeleted file mode 100644 index 157df174..00000000 --- a/gemfeed/taskwarrior-autonomous-agent/ior-logo.png +++ /dev/null @@ -30,9 +30,9 @@ Everything you read on this site is my personal opinion and experience. You can ### Posts +[2026-03-01 - Site Reliability Engineering - Part 5: System Design, Incidents, and Learning](./gemfeed/2026-03-01-site-reliability-engineering-part-5.md) [2026-02-22 - My desk rack: DeskPi RackMate T0](./gemfeed/2026-02-22-my-desk-rack.md) [2026-02-15 - Loadbars resurrected: From Perl to Go after 15 years](./gemfeed/2026-02-15-loadbars-resurrected-from-perl-to-go.md) -[2026-02-14 - Meta slash-commands to manage prompts, skills, and context for coding agents](./gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.md) [2026-02-02 - A tmux popup editor for Cursor Agent CLI prompts](./gemfeed/2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.md) [2026-01-01 - Using Supernote Nomad offline](./gemfeed/2026-01-01-using-supernote-nomad-offline.md) [2026-01-01 - Posts from July to December 2025](./gemfeed/2026-01-01-posts-from-july-to-december-2025.md) |
