diff options
| -rw-r--r-- | about/resources.gmi | 198 | ||||
| -rw-r--r-- | about/showcase.gmi | 277 | ||||
| -rw-r--r-- | about/showcase.gmi.tpl | 160 | ||||
| -rw-r--r-- | about/showcase/debroid/image-1.png | 36 | ||||
| -rw-r--r-- | gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.gmi | 1 | ||||
| -rw-r--r-- | gemfeed/atom.xml | 668 | ||||
| -rw-r--r-- | gemfeed/index.gmi | 1 | ||||
| -rw-r--r-- | index.gmi | 1 |
8 files changed, 809 insertions, 533 deletions
diff --git a/about/resources.gmi b/about/resources.gmi index 94e54b6c..f6f40292 100644 --- a/about/resources.gmi +++ b/about/resources.gmi @@ -35,110 +35,110 @@ You won't find any links on this site because, over time, the links will break. In random order: -* DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible -* Modern Perl; Chromatic ; Onyx Neon Press -* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications -* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly +* 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 -* Perl New Features; Joshua McAdams, brian d foy; Perl School -* Pro Puppet; James Turnbull, Jeffrey McCune; Apress * Polished Ruby Programming; Jeremy Evans; Packt Publishing -* Chaos Engineering - System Resiliency in Practice; Casey Rosenthal and Nora Jones; eBook -* Funktionale Programmierung; Peter Pepper; Springer -* Java ist auch eine Insel; Christian Ullenboom; -* Ultimate Go Notebook; Bill Kennedy -* Data Science at the Command Line; Jeroen Janssens; O'Reilly -* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly -* Concurrency in Go; Katherine Cox-Buday; O'Reilly +* 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 -* The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible +* 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 -* Seeking SRE: Conversations About Running Production Systems at Scale; David N. Blank-Edelman; eBook -* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly -* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly -* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional +* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton * Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications -* DNS and BIND; Cricket Liu; O'Reilly +* 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 -* The Pragmatic Programmer; David Thomas; Addison-Wesley -* C++ Programming Language; Bjarne Stroustrup; -* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton -* Effective awk programming; Arnold Robbins; O'Reilly -* Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner -* Raku Recipes; J.J. Merelo; Apress -* Developing Games in Java; David Brackeen and others...; New Riders -* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press -* Systemprogrammierung in Go; Frank Müller; dpunkt -* Effective Java; Joshua Bloch; Addison-Wesley Professional -* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook -* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers -* Terraform Cookbook; Mikael Krief; Packt Publishing -* Site Reliability Engineering; How Google runs production systems; O'Reilly -* Leanring eBPF; Liz Rice; O'Reilly * 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 -* The Docker Book; James Turnbull; Kindle +* 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 +* Perl New Features; Joshua McAdams, brian d foy; Perl School +* The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible * Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson -* 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 -* Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly -* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt +* Raku Recipes; J.J. Merelo; Apress +* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly +* C++ Programming Language; Bjarne Stroustrup; +* Leanring eBPF; Liz Rice; O'Reilly ## 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: -* Implementing Service Level Objectives; Alex Hidalgo; O'Reilly -* Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley -* BPF Performance Tools - Linux System and Application Observability, Brendan Gregg; Addison Wesley -* Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly * Relayd and Httpd Mastery; Michael W Lucas +* Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly +* 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 -* Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly ## Self-development and soft-skills books In random order: -* Staff Engineer: Leadership beyond the management track; Will Larson; Audiobook -* 101 Essays that change the way you think; Brianna Wiest; Audiobook -* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing +* 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 Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook +* 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 -* Coders at Work - Reflections on the craft of programming, Peter Seibel and Mitchell Dorian et al., Audiobook -* The Good Enough Job; Simone Stolzoff; Ebury Edge +* Ultralearning; Scott Young; Thorsons +* Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly +* Deep Work; Cal Newport; Piatkus * The Courage to Be Disliked; Ichiro Kishimi and Fumitake Koga; Audiobook -* Eat That Frog!; Brian Tracy; Hodder Paperbacks +* 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 -* Deep Work; Cal Newport; Piatkus -* Solve for Happy; Mo Gawdat (RE-READ 1ST TIME) -* The Power of Now; Eckhard Tolle; Yellow Kite +* 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 -* Stop starting, start finishing; Arne Roock; Lean-Kanban University -* Influence without Authority; A. Cohen, D. Bradford; Wiley -* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne -* The Software Engineer's Guidebook: Navigating senior, tech lead, and staff engineer positions at tech companies and startups; Gergely Orosz; Audiobook +* Eat That Frog!; Brian Tracy; Hodder Paperbacks * Psycho-Cybernetics; Maxwell Maltz; Perigee Books * Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press -* Meditation for Mortals, Oliver Burkeman, Audiobook -* Getting Things Done; David Allen -* Soft Skills; John Sommez; Manning Publications -* 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 -* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business +* 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 -* So Good They Can't Ignore You; Cal Newport; Business Plus -* Ultralearning; Anna Laurent; Self-published via Amazon -* Digital Minimalism; Cal Newport; Portofolio Penguin -* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd -* Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly -* Ultralearning; Scott Young; Thorsons +* 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 +* 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 Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook => ../notes/index.gmi Here are notes of mine for some of the books @@ -146,22 +146,22 @@ In random order: Some of these were in-person with exams; others were online learning lectures only. In random order: -* Ultimate Go Programming; Bill Kennedy; O'Reilly Online -* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online -* Scripting Vim; Damian Conway; O'Reilly Online -* AWS Immersion Day; Amazon; 1-day interactive online training +* 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 * Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training -* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon -* Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online -* Apache Tomcat Best Practises; 3-day on-site training -* MySQL Deep Dive Workshop; 2-day on-site training -* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. * Functional programming lecture; Remote University of Hagen +* AWS Immersion Day; Amazon; 1-day interactive online training * Structure and Interpretation of Computer Programs; Harold Abelson and more...; -* The Ultimate Kubernetes Bootcamp; School of Devops; O'Reilly Online +* Scripting Vim; Damian Conway; O'Reilly Online +* Apache Tomcat Best Practises; 3-day on-site training +* Ultimate Go Programming; Bill Kennedy; O'Reilly Online ## Technical guides @@ -177,58 +177,58 @@ These are not whole books, but guides (smaller or larger) which I found very use In random order: -* Modern Mentor -* Dev Interrupted -* The Pragmatic Engineer Podcast -* Wednesday Wisdom * Pratical AI +* Dev Interrupted * The ProdCast (Google SRE Podcast) +* Wednesday Wisdom * Backend Banter -* The Changelog Podcast(s) * Hidden Brain +* The Pragmatic Engineer Podcast +* Fallthrough [Golang] * Cup o' Go [Golang] * BSD Now [BSD] -* Fallthrough [Golang] -* Maintainable +* Modern Mentor * Fork Around And Find Out +* Maintainable * Deep Questions with Cal Newport +* The Changelog Podcast(s) ### 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. -* Ship It (predecessor of Fork Around And Find Out) +* CRE: Chaosradio Express [german] * FLOSS weekly -* Modern Mentor +* Ship It (predecessor of Fork Around And Find Out) * Go Time (predecessor of fallthrough) * Java Pub House -* CRE: Chaosradio Express [german] +* 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 -* Golang Weekly -* The Valuable Dev -* byteSizeGo +* Register Spill +* Applied Go Weekly Newsletter * The Imperfectionist -* Monospace Mentor -* Changelog News +* byteSizeGo +* The Valuable Dev * The Pragmatic Engineer * Andreas Brandhorst Newsletter (Sci-Fi author) -* Register Spill -* Ruby Weekly -* Applied Go Weekly Newsletter +* Golang 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: -* Linux Magazine -* Linux User * freeX (not published anymore) * LWN (online only) +* Linux Magazine +* Linux User # Formal education diff --git a/about/showcase.gmi b/about/showcase.gmi index 4e64cda6..25e51895 100644 --- a/about/showcase.gmi +++ b/about/showcase.gmi @@ -13,75 +13,74 @@ This page showcases my side projects, providing an overview of what each project * ⇢ ⇢ ⇢ 2. dotfiles * ⇢ ⇢ ⇢ 3. epimetheus * ⇢ ⇢ ⇢ 4. conf -* ⇢ ⇢ ⇢ 5. dotfiles.bak -* ⇢ ⇢ ⇢ 6. foo.zone -* ⇢ ⇢ ⇢ 7. scifi -* ⇢ ⇢ ⇢ 8. log4jbench -* ⇢ ⇢ ⇢ 9. gogios -* ⇢ ⇢ ⇢ 10. yoga -* ⇢ ⇢ ⇢ 11. perc -* ⇢ ⇢ ⇢ 12. totalrecall -* ⇢ ⇢ ⇢ 13. ior -* ⇢ ⇢ ⇢ 14. gitsyncer -* ⇢ ⇢ ⇢ 15. tasksamurai -* ⇢ ⇢ ⇢ 16. foostats -* ⇢ ⇢ ⇢ 17. timr -* ⇢ ⇢ ⇢ 18. dtail -* ⇢ ⇢ ⇢ 19. gos -* ⇢ ⇢ ⇢ 20. ds-sim -* ⇢ ⇢ ⇢ 21. wireguardmeshgenerator -* ⇢ ⇢ ⇢ 22. gemtexter -* ⇢ ⇢ ⇢ 23. rcm -* ⇢ ⇢ ⇢ 24. terraform -* ⇢ ⇢ ⇢ 25. quicklogger -* ⇢ ⇢ ⇢ 26. sillybench -* ⇢ ⇢ ⇢ 27. goprecords -* ⇢ ⇢ ⇢ 28. gorum -* ⇢ ⇢ ⇢ 29. guprecords -* ⇢ ⇢ ⇢ 30. geheim -* ⇢ ⇢ ⇢ 31. docker-radicale-server -* ⇢ ⇢ ⇢ 32. algorithms -* ⇢ ⇢ ⇢ 33. randomjournalpage -* ⇢ ⇢ ⇢ 34. photoalbum -* ⇢ ⇢ ⇢ 35. ioriot -* ⇢ ⇢ ⇢ 36. ipv6test -* ⇢ ⇢ ⇢ 37. sway-autorotate -* ⇢ ⇢ ⇢ 38. mon -* ⇢ ⇢ ⇢ 39. staticfarm-apache-handlers -* ⇢ ⇢ ⇢ 40. pingdomfetch -* ⇢ ⇢ ⇢ 41. fype -* ⇢ ⇢ ⇢ 42. xerl -* ⇢ ⇢ ⇢ 43. ychat -* ⇢ ⇢ ⇢ 44. fapi -* ⇢ ⇢ ⇢ 45. perl-c-fibonacci -* ⇢ ⇢ ⇢ 46. netcalendar -* ⇢ ⇢ ⇢ 47. loadbars -* ⇢ ⇢ ⇢ 48. gotop -* ⇢ ⇢ ⇢ 49. rubyfy -* ⇢ ⇢ ⇢ 50. pwgrep -* ⇢ ⇢ ⇢ 51. perldaemon -* ⇢ ⇢ ⇢ 52. jsmstrade -* ⇢ ⇢ ⇢ 53. japi -* ⇢ ⇢ ⇢ 54. perl-poetry -* ⇢ ⇢ ⇢ 55. muttdelay -* ⇢ ⇢ ⇢ 56. netdiff -* ⇢ ⇢ ⇢ 57. debroid -* ⇢ ⇢ ⇢ 58. hsbot -* ⇢ ⇢ ⇢ 59. cpuinfo -* ⇢ ⇢ ⇢ 60. template -* ⇢ ⇢ ⇢ 61. awksite -* ⇢ ⇢ ⇢ 62. dyndns -* ⇢ ⇢ ⇢ 63. vs-sim +* ⇢ ⇢ ⇢ 5. foo.zone +* ⇢ ⇢ ⇢ 6. scifi +* ⇢ ⇢ ⇢ 7. log4jbench +* ⇢ ⇢ ⇢ 8. gogios +* ⇢ ⇢ ⇢ 9. yoga +* ⇢ ⇢ ⇢ 10. perc +* ⇢ ⇢ ⇢ 11. totalrecall +* ⇢ ⇢ ⇢ 12. ior +* ⇢ ⇢ ⇢ 13. gitsyncer +* ⇢ ⇢ ⇢ 14. tasksamurai +* ⇢ ⇢ ⇢ 15. foostats +* ⇢ ⇢ ⇢ 16. timr +* ⇢ ⇢ ⇢ 17. dtail +* ⇢ ⇢ ⇢ 18. gos +* ⇢ ⇢ ⇢ 19. ds-sim +* ⇢ ⇢ ⇢ 20. wireguardmeshgenerator +* ⇢ ⇢ ⇢ 21. gemtexter +* ⇢ ⇢ ⇢ 22. rcm +* ⇢ ⇢ ⇢ 23. terraform +* ⇢ ⇢ ⇢ 24. quicklogger +* ⇢ ⇢ ⇢ 25. sillybench +* ⇢ ⇢ ⇢ 26. goprecords +* ⇢ ⇢ ⇢ 27. gorum +* ⇢ ⇢ ⇢ 28. guprecords +* ⇢ ⇢ ⇢ 29. geheim +* ⇢ ⇢ ⇢ 30. docker-radicale-server +* ⇢ ⇢ ⇢ 31. algorithms +* ⇢ ⇢ ⇢ 32. randomjournalpage +* ⇢ ⇢ ⇢ 33. photoalbum +* ⇢ ⇢ ⇢ 34. ioriot +* ⇢ ⇢ ⇢ 35. ipv6test +* ⇢ ⇢ ⇢ 36. sway-autorotate +* ⇢ ⇢ ⇢ 37. mon +* ⇢ ⇢ ⇢ 38. staticfarm-apache-handlers +* ⇢ ⇢ ⇢ 39. pingdomfetch +* ⇢ ⇢ ⇢ 40. fype +* ⇢ ⇢ ⇢ 41. xerl +* ⇢ ⇢ ⇢ 42. ychat +* ⇢ ⇢ ⇢ 43. fapi +* ⇢ ⇢ ⇢ 44. perl-c-fibonacci +* ⇢ ⇢ ⇢ 45. netcalendar +* ⇢ ⇢ ⇢ 46. loadbars +* ⇢ ⇢ ⇢ 47. gotop +* ⇢ ⇢ ⇢ 48. rubyfy +* ⇢ ⇢ ⇢ 49. pwgrep +* ⇢ ⇢ ⇢ 50. perldaemon +* ⇢ ⇢ ⇢ 51. jsmstrade +* ⇢ ⇢ ⇢ 52. japi +* ⇢ ⇢ ⇢ 53. perl-poetry +* ⇢ ⇢ ⇢ 54. muttdelay +* ⇢ ⇢ ⇢ 55. netdiff +* ⇢ ⇢ ⇢ 56. debroid +* ⇢ ⇢ ⇢ 57. hsbot +* ⇢ ⇢ ⇢ 58. cpuinfo +* ⇢ ⇢ ⇢ 59. template +* ⇢ ⇢ ⇢ 60. awksite +* ⇢ ⇢ ⇢ 61. dyndns +* ⇢ ⇢ ⇢ 62. vs-sim ## Overall Statistics -* 📦 Total Projects: 63 -* 📊 Total Commits: 13,313 -* 📈 Total Lines of Code: 314,278 -* 📄 Total Lines of Documentation: 41,499 -* 💻 Languages: Go (36.1%), Java (13.1%), C++ (8.1%), Shell (6.5%), C (6.3%), XML (6.1%), Perl (5.5%), C/C++ (5.2%), YAML (5.0%), HTML (1.9%), Config (1.3%), Ruby (1.0%), HCL (0.9%), CSS (0.7%), Python (0.7%), Make (0.5%), JSON (0.4%), TOML (0.2%), Haskell (0.2%), JavaScript (0.2%), Raku (0.1%) -* 📚 Documentation: Markdown (70.1%), Text (28.6%), LaTeX (1.4%) -* 🚀 Release Status: 39 released, 24 experimental (61.9% with releases, 38.1% experimental) +* 📦 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%) +* 🚀 Release Status: 39 released, 23 experimental (62.9% with releases, 37.1% experimental) ## Projects @@ -117,7 +116,7 @@ The project is implemented as an LSP server written in Go, with a TUI component * 📈 Lines of Code: 2960 * 📄 Lines of Documentation: 653 * 📅 Development Period: 2023-07-30 to 2026-02-21 -* 🏆 Score: 364.6 (combines code size and activity) +* 🏆 Score: 364.5 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -139,7 +138,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.1 (combines code size and activity) +* 🏆 Score: 314.0 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -163,7 +162,7 @@ The architecture routes current data (<5 min old) through Pushgateway where Prom * 📈 Lines of Code: 19079 * 📄 Lines of Documentation: 6585 * 📅 Development Period: 2021-12-28 to 2026-02-08 -* 🏆 Score: 250.9 (combines code size and activity) +* 🏆 Score: 250.8 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -177,29 +176,7 @@ The project is organized into distinct subdirectories: `dotfiles/` contains shel --- -### 5. dotfiles.bak - -* 💻 Languages: Shell (59.2%), CSS (10.9%), Config (10.1%), TOML (10.0%), Ruby (8.4%), JSON (1.1%), INI (0.2%) -* 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 762 -* 📈 Lines of Code: 2988 -* 📄 Lines of Documentation: 423 -* 📅 Development Period: 2023-07-30 to 2026-02-14 -* 🏆 Score: 225.0 (combines code size and activity) -* ⚖️ License: No license found -* 🧪 Status: Experimental (no releases yet) - - -This is a **personal dotfiles management repository** that uses [Rex](https://www.rexify.org/) (a Perl-based infrastructure automation framework) to declaratively install configuration files across multiple machines — both locally (laptop/workstation) and remotely (servers). The `Rexfile` defines granular tasks (e.g., `home_bash`, `home_tmux`, `home_sway`) that copy or symlink config files for tools like Bash, Fish, ZSH, tmux, Helix, Ghostty, Sway/Waybar, Pipewire, SSH, and AI coding assistants (Cursor, Claude, Amp, OpenCode). A top-level `home` task runs all `home_*` tasks at once. It also includes platform-specific package installation tasks for Fedora, FreeBSD, and Termux. - -The architecture is straightforward: source configs live in categorized subdirectories (e.g., `bash/`, `fish/`, `tmux/`), and Rex's `file` resource ensures they're placed at the correct `~/.config/...` or `~/...` paths with proper permissions. Some configs (like fish and gitsyncer) use symlinks instead of copies for live editing. The repo also supports a private companion repo (`conf_private/dotfiles`) for sensitive files like calendar data. - -=> https://codeberg.org/snonux/dotfiles.bak View on Codeberg -=> https://github.com/snonux/dotfiles.bak View on GitHub - ---- - -### 6. foo.zone +### 5. foo.zone * 💻 Languages: XML (98.7%), Shell (1.0%), Go (0.3%) * 📚 Documentation: Text (86.2%), Markdown (13.8%) @@ -219,7 +196,7 @@ foo.zone: source code repository. --- -### 7. scifi +### 6. scifi * 💻 Languages: JSON (35.9%), CSS (30.6%), JavaScript (29.6%), HTML (3.8%) * 📚 Documentation: Markdown (100.0%) @@ -241,7 +218,7 @@ The architecture keeps content separate from presentation: book metadata lives i --- -### 8. log4jbench +### 7. log4jbench * 💻 Languages: Java (78.9%), XML (21.1%) * 📚 Documentation: Markdown (100.0%) @@ -263,7 +240,7 @@ The implementation uses a fat JAR built with Maven, requiring Java 17+. It's des --- -### 9. gogios +### 8. gogios * 💻 Languages: Go (98.9%), JSON (0.6%), YAML (0.5%) * 📚 Documentation: Markdown (94.9%), Text (5.1%) @@ -287,7 +264,7 @@ The architecture is straightforward: JSON configuration defines checks (plugin p --- -### 10. yoga +### 9. yoga * 💻 Languages: Go (66.1%), HTML (33.9%) * 📚 Documentation: Markdown (100.0%) @@ -311,7 +288,7 @@ The implementation follows clean Go architecture with domain logic organized und --- -### 11. perc +### 10. perc * 💻 Languages: Go (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -333,7 +310,7 @@ The tool is built as a simple Go CLI application with a standard project layout --- -### 12. totalrecall +### 11. totalrecall * 💻 Languages: Go (99.0%), Shell (0.5%), YAML (0.4%) * 📚 Documentation: Markdown (99.5%), Text (0.5%) @@ -359,7 +336,7 @@ The project offers both a keyboard-driven GUI for interactive use and a CLI for --- -### 13. ior +### 12. ior * 💻 Languages: Go (63.2%), C (36.0%), C/C++ (0.8%) * 📚 Documentation: Markdown (79.3%), Text (20.7%) @@ -385,7 +362,7 @@ The tool is implemented in Go and C, leveraging libbpfgo for BPF interaction. It --- -### 14. gitsyncer +### 13. gitsyncer * 💻 Languages: Go (92.5%), Shell (7.1%), JSON (0.4%) * 📚 Documentation: Markdown (100.0%) @@ -407,7 +384,7 @@ The implementation uses a git remotes approach: it clones from one organization, --- -### 15. tasksamurai +### 14. tasksamurai * 💻 Languages: Go (99.8%), YAML (0.2%) * 📚 Documentation: Markdown (100.0%) @@ -433,7 +410,7 @@ Under the hood, Task Samurai acts as a front-end wrapper that invokes the native --- -### 16. foostats +### 15. foostats * 💻 Languages: Perl (100.0%) * 📚 Documentation: Markdown (54.6%), Text (45.4%) @@ -455,7 +432,7 @@ The implementation uses a modular Perl architecture with specialized components: --- -### 17. timr +### 16. timr * 💻 Languages: Go (96.0%), Shell (4.0%) * 📚 Documentation: Markdown (100.0%) @@ -477,7 +454,7 @@ The architecture is straightforward: it's a Go-based CLI application that persis --- -### 18. dtail +### 17. 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%) @@ -503,7 +480,7 @@ The architecture follows a client-server model where DTail servers run on target --- -### 19. gos +### 18. gos * 💻 Languages: Go (99.8%), JSON (0.2%) * 📚 Documentation: Markdown (100.0%) @@ -529,7 +506,7 @@ The implementation uses OAuth2 for LinkedIn authentication, stores configuration --- -### 20. ds-sim +### 19. ds-sim * 💻 Languages: Java (98.9%), Shell (0.6%), CSS (0.5%) * 📚 Documentation: Markdown (98.7%), Text (1.3%) @@ -553,7 +530,7 @@ The implementation follows a modular Java architecture with clear separation bet --- -### 21. wireguardmeshgenerator +### 20. wireguardmeshgenerator * 💻 Languages: Ruby (65.4%), YAML (34.6%) * 📚 Documentation: Markdown (100.0%) @@ -575,7 +552,7 @@ The tool reads host definitions from a YAML file specifying network interfaces ( --- -### 22. gemtexter +### 21. gemtexter * 💻 Languages: Shell (68.2%), CSS (28.5%), Config (1.9%), HTML (1.3%) * 📚 Documentation: Text (76.1%), Markdown (23.9%) @@ -597,7 +574,7 @@ The architecture leverages GNU utilities (sed, grep, date) and optional tools li --- -### 23. rcm +### 22. rcm * 💻 Languages: Ruby (99.8%), TOML (0.2%) * 📚 Documentation: Markdown (100.0%) @@ -619,7 +596,7 @@ The implementation centers around a DSL module that provides keywords like `file --- -### 24. terraform +### 23. terraform * 💻 Languages: HCL (96.6%), Make (1.9%), YAML (1.5%) * 📚 Documentation: Markdown (100.0%) @@ -641,7 +618,7 @@ The infrastructure uses a **modular, layered architecture** with separate Terraf --- -### 25. quicklogger +### 24. quicklogger * 💻 Languages: Go (96.1%), XML (1.9%), Shell (1.2%), TOML (0.7%) * 📚 Documentation: Markdown (100.0%) @@ -667,7 +644,7 @@ The implementation leverages Go's cross-compilation capabilities and Fyne's UI a --- -### 26. sillybench +### 25. sillybench * 💻 Languages: Go (90.9%), Shell (9.1%) * 📚 Documentation: Markdown (100.0%) @@ -689,7 +666,7 @@ The implementation is intentionally straightforward, using Go's built-in testing --- -### 27. goprecords +### 26. goprecords * 💻 Languages: Go (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -711,7 +688,7 @@ Under the hood, it parses `uptimed`'s simple `uptime:boottime:kernel` record for --- -### 28. gorum +### 27. gorum * 💻 Languages: Go (91.3%), JSON (6.4%), YAML (2.3%) * 📚 Documentation: Markdown (100.0%) @@ -734,7 +711,7 @@ The architecture consists of client/server components for inter-node communicati --- -### 29. guprecords +### 28. guprecords * 💻 Languages: Raku (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -756,7 +733,7 @@ The implementation uses an object-oriented architecture with specialized classes --- -### 30. geheim +### 29. geheim * 💻 Languages: Ruby (86.7%), Shell (13.3%) * 📚 Documentation: Markdown (100.0%) @@ -778,7 +755,7 @@ The architecture leverages Git for storage and synchronization across multiple r --- -### 31. docker-radicale-server +### 30. docker-radicale-server * 💻 Languages: Make (57.5%), Docker (42.5%) * 📚 Documentation: Markdown (100.0%) @@ -800,7 +777,7 @@ The implementation uses Alpine Linux as the base image for a minimal footprint, --- -### 32. algorithms +### 31. algorithms * 💻 Languages: Go (99.2%), Make (0.8%) * 📚 Documentation: Markdown (100.0%) @@ -823,7 +800,7 @@ The project is implemented in Go 1.19+ with comprehensive unit tests and benchma --- -### 33. randomjournalpage +### 32. randomjournalpage * 💻 Languages: Shell (94.1%), Make (5.9%) * 📚 Documentation: Markdown (100.0%) @@ -846,7 +823,7 @@ The implementation is a straightforward bash script using `qpdf` for PDF extract --- -### 34. photoalbum +### 33. photoalbum * 💻 Languages: Shell (80.1%), Make (12.3%), Config (7.6%) * 📚 Documentation: Markdown (100.0%) @@ -869,7 +846,7 @@ The architecture is straightforward and Unix-philosophy driven: users configure --- -### 35. ioriot +### 34. ioriot * 💻 Languages: C (55.5%), C/C++ (24.0%), Config (19.6%), Make (1.0%) * 📚 Documentation: Markdown (100.0%) @@ -894,7 +871,7 @@ The key advantage over traditional benchmarking tools is that it reproduces actu --- -### 36. ipv6test +### 35. ipv6test * 💻 Languages: Perl (65.8%), Docker (34.2%) * 📚 Documentation: Markdown (100.0%) @@ -916,7 +893,7 @@ The implementation uses a simple CGI script ([index.pl](file:///home/paul/git/gi --- -### 37. sway-autorotate +### 36. sway-autorotate * 💻 Languages: Shell (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -938,7 +915,7 @@ The implementation uses a bash script that continuously monitors the `monitor-se --- -### 38. mon +### 37. mon * 💻 Languages: Perl (96.5%), Shell (1.8%), Make (1.2%), Config (0.4%) * 📚 Documentation: Text (100.0%) @@ -961,7 +938,7 @@ Implemented in Perl, `mon` features automatic JSON backup before modifications ( --- -### 39. staticfarm-apache-handlers +### 38. staticfarm-apache-handlers * 💻 Languages: Perl (96.4%), Make (3.6%) * 📚 Documentation: Text (100.0%) @@ -984,7 +961,7 @@ Both handlers are implemented as Perl modules using Apache2's mod_perl API, conf --- -### 40. pingdomfetch +### 39. pingdomfetch * 💻 Languages: Perl (97.3%), Make (2.7%) * 📚 Documentation: Text (100.0%) @@ -1007,7 +984,7 @@ The tool is implemented around a hierarchical configuration system (`/etc/pingdo --- -### 41. fype +### 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%) @@ -1029,7 +1006,7 @@ The implementation uses a simple top-down parser with maximum lookahead of 1, in --- -### 42. xerl +### 41. xerl * 💻 Languages: Perl (98.3%), Config (1.2%), Make (0.5%) * 📊 Commits: 670 @@ -1050,7 +1027,7 @@ The implementation follows strict OO Perl conventions with explicit typing and p --- -### 43. ychat +### 42. 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%) @@ -1073,7 +1050,7 @@ The architecture emphasizes speed and scalability through several key design cho --- -### 44. fapi +### 43. fapi * 💻 Languages: Python (96.6%), Make (3.1%), Config (0.3%) * 📚 Documentation: Text (98.3%), Markdown (1.7%) @@ -1095,7 +1072,7 @@ The tool is implemented in Python and depends on the bigsuds library (F5's iCont --- -### 45. perl-c-fibonacci +### 44. perl-c-fibonacci * 💻 Languages: C (80.4%), Make (19.6%) * 📚 Documentation: Text (100.0%) @@ -1116,7 +1093,7 @@ perl-c-fibonacci: source code repository. --- -### 46. netcalendar +### 45. netcalendar * 💻 Languages: Java (83.0%), HTML (12.9%), XML (3.0%), CSS (0.8%), Make (0.2%) * 📚 Documentation: Text (89.7%), Markdown (10.3%) @@ -1143,7 +1120,7 @@ The key feature is its intelligent color-coded event visualization system that h --- -### 47. loadbars +### 46. loadbars * 💻 Languages: Perl (97.4%), Make (2.6%) * 📚 Documentation: Text (100.0%) @@ -1164,10 +1141,10 @@ loadbars: source code repository. --- -### 48. gotop +### 47. gotop * 💻 Languages: Go (98.0%), Make (2.0%) -* 📚 Documentation: Text (50.0%), Markdown (50.0%) +* 📚 Documentation: Markdown (50.0%), Text (50.0%) * 📊 Commits: 57 * 📈 Lines of Code: 499 * 📄 Lines of Documentation: 8 @@ -1187,7 +1164,7 @@ The implementation uses a concurrent architecture with goroutines for data colle --- -### 49. rubyfy +### 48. rubyfy * 💻 Languages: Ruby (98.5%), JSON (1.5%) * 📚 Documentation: Markdown (100.0%) @@ -1210,7 +1187,7 @@ The tool is implemented as a lightweight Ruby script that prioritizes simplicity --- -### 50. pwgrep +### 49. pwgrep * 💻 Languages: Shell (85.0%), Make (15.0%) * 📚 Documentation: Text (80.8%), Markdown (19.2%) @@ -1233,7 +1210,7 @@ The architecture is lightweight and Unix-philosophy driven: password databases a --- -### 51. perldaemon +### 50. perldaemon * 💻 Languages: Perl (72.3%), Shell (23.8%), Config (3.9%) * 📊 Commits: 110 @@ -1254,7 +1231,7 @@ The implementation centers around an event loop with configurable intervals that --- -### 52. jsmstrade +### 51. jsmstrade * 💻 Languages: Java (76.0%), Shell (15.4%), XML (8.6%) * 📚 Documentation: Markdown (100.0%) @@ -1279,7 +1256,7 @@ The implementation is minimalistic, consisting of just three main Java classes ( --- -### 53. japi +### 52. japi * 💻 Languages: Perl (78.3%), Make (21.7%) * 📚 Documentation: Text (100.0%) @@ -1302,7 +1279,7 @@ Implemented in Perl using the JIRA::REST CPAN module, japi supports flexible con --- -### 54. perl-poetry +### 53. perl-poetry * 💻 Languages: Perl (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -1325,7 +1302,7 @@ This project exemplifies creative coding where Perl keywords and constructs are --- -### 55. muttdelay +### 54. muttdelay * 💻 Languages: Make (47.1%), Shell (46.3%), Vim Script (5.9%), Config (0.7%) * 📚 Documentation: Text (100.0%) @@ -1348,7 +1325,7 @@ The architecture uses three components working together: a Vim plugin that provi --- -### 56. netdiff +### 55. netdiff * 💻 Languages: Shell (52.2%), Make (46.3%), Config (1.5%) * 📚 Documentation: Text (100.0%) @@ -1371,7 +1348,7 @@ The tool uses a clever client-server architecture where you run the identical co --- -### 57. debroid +### 56. debroid * 💻 Languages: Shell (92.0%), Make (8.0%) * 📚 Documentation: Markdown (100.0%) @@ -1396,7 +1373,7 @@ The implementation uses a two-stage debootstrap process: first creating a Debian --- -### 58. hsbot +### 57. hsbot * 💻 Languages: Haskell (98.5%), Make (1.5%) * 📊 Commits: 80 @@ -1417,7 +1394,7 @@ The implementation uses a modular design with core components separated into Bas --- -### 59. cpuinfo +### 58. cpuinfo * 💻 Languages: Shell (53.2%), Make (46.8%) * 📚 Documentation: Text (100.0%) @@ -1440,7 +1417,7 @@ The implementation is elegantly simple: a single shell script ([src/cpuinfo](fil --- -### 60. template +### 59. template * 💻 Languages: Make (89.2%), Shell (10.8%) * 📚 Documentation: Text (100.0%) @@ -1463,7 +1440,7 @@ The implementation uses a **Makefile-based build system** with targets for compi --- -### 61. awksite +### 60. awksite * 💻 Languages: AWK (72.1%), HTML (16.4%), Config (11.5%) * 📚 Documentation: Text (60.0%), Markdown (40.0%) @@ -1486,7 +1463,7 @@ The architecture is remarkably simple: a single AWK script ([index.cgi](file:/// --- -### 62. dyndns +### 61. dyndns * 💻 Languages: Shell (100.0%) * 📚 Documentation: Text (100.0%) @@ -1509,7 +1486,7 @@ The implementation uses a two-tier security architecture: SSH public key authent --- -### 63. vs-sim +### 62. vs-sim * 📚 Documentation: Markdown (100.0%) * 📊 Commits: 411 diff --git a/about/showcase.gmi.tpl b/about/showcase.gmi.tpl index b4d85947..6ddec4cb 100644 --- a/about/showcase.gmi.tpl +++ b/about/showcase.gmi.tpl @@ -8,13 +8,13 @@ This page showcases my side projects, providing an overview of what each project ## Overall Statistics -* 📦 Total Projects: 63 -* 📊 Total Commits: 13,313 -* 📈 Total Lines of Code: 314,278 -* 📄 Total Lines of Documentation: 41,499 -* 💻 Languages: Go (36.1%), Java (13.1%), C++ (8.1%), Shell (6.5%), C (6.3%), XML (6.1%), Perl (5.5%), C/C++ (5.2%), YAML (5.0%), HTML (1.9%), Config (1.3%), Ruby (1.0%), HCL (0.9%), CSS (0.7%), Python (0.7%), Make (0.5%), JSON (0.4%), TOML (0.2%), Haskell (0.2%), JavaScript (0.2%), Raku (0.1%) -* 📚 Documentation: Markdown (70.1%), Text (28.6%), LaTeX (1.4%) -* 🚀 Release Status: 39 released, 24 experimental (61.9% with releases, 38.1% experimental) +* 📦 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%) +* 🚀 Release Status: 39 released, 23 experimental (62.9% with releases, 37.1% experimental) ## Projects @@ -50,7 +50,7 @@ The project is implemented as an LSP server written in Go, with a TUI component * 📈 Lines of Code: 2960 * 📄 Lines of Documentation: 653 * 📅 Development Period: 2023-07-30 to 2026-02-21 -* 🏆 Score: 364.6 (combines code size and activity) +* 🏆 Score: 364.5 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -72,7 +72,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.1 (combines code size and activity) +* 🏆 Score: 314.0 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -96,7 +96,7 @@ The architecture routes current data (<5 min old) through Pushgateway where Prom * 📈 Lines of Code: 19079 * 📄 Lines of Documentation: 6585 * 📅 Development Period: 2021-12-28 to 2026-02-08 -* 🏆 Score: 250.9 (combines code size and activity) +* 🏆 Score: 250.8 (combines code size and activity) * ⚖️ License: No license found * 🧪 Status: Experimental (no releases yet) @@ -110,29 +110,7 @@ The project is organized into distinct subdirectories: `dotfiles/` contains shel --- -### 5. dotfiles.bak - -* 💻 Languages: Shell (59.2%), CSS (10.9%), Config (10.1%), TOML (10.0%), Ruby (8.4%), JSON (1.1%), INI (0.2%) -* 📚 Documentation: Markdown (100.0%) -* 📊 Commits: 762 -* 📈 Lines of Code: 2988 -* 📄 Lines of Documentation: 423 -* 📅 Development Period: 2023-07-30 to 2026-02-14 -* 🏆 Score: 225.0 (combines code size and activity) -* ⚖️ License: No license found -* 🧪 Status: Experimental (no releases yet) - - -This is a **personal dotfiles management repository** that uses [Rex](https://www.rexify.org/) (a Perl-based infrastructure automation framework) to declaratively install configuration files across multiple machines — both locally (laptop/workstation) and remotely (servers). The `Rexfile` defines granular tasks (e.g., `home_bash`, `home_tmux`, `home_sway`) that copy or symlink config files for tools like Bash, Fish, ZSH, tmux, Helix, Ghostty, Sway/Waybar, Pipewire, SSH, and AI coding assistants (Cursor, Claude, Amp, OpenCode). A top-level `home` task runs all `home_*` tasks at once. It also includes platform-specific package installation tasks for Fedora, FreeBSD, and Termux. - -The architecture is straightforward: source configs live in categorized subdirectories (e.g., `bash/`, `fish/`, `tmux/`), and Rex's `file` resource ensures they're placed at the correct `~/.config/...` or `~/...` paths with proper permissions. Some configs (like fish and gitsyncer) use symlinks instead of copies for live editing. The repo also supports a private companion repo (`conf_private/dotfiles`) for sensitive files like calendar data. - -=> https://codeberg.org/snonux/dotfiles.bak View on Codeberg -=> https://github.com/snonux/dotfiles.bak View on GitHub - ---- - -### 6. foo.zone +### 5. foo.zone * 💻 Languages: XML (98.7%), Shell (1.0%), Go (0.3%) * 📚 Documentation: Text (86.2%), Markdown (13.8%) @@ -152,7 +130,7 @@ foo.zone: source code repository. --- -### 7. scifi +### 6. scifi * 💻 Languages: JSON (35.9%), CSS (30.6%), JavaScript (29.6%), HTML (3.8%) * 📚 Documentation: Markdown (100.0%) @@ -174,7 +152,7 @@ The architecture keeps content separate from presentation: book metadata lives i --- -### 8. log4jbench +### 7. log4jbench * 💻 Languages: Java (78.9%), XML (21.1%) * 📚 Documentation: Markdown (100.0%) @@ -196,7 +174,7 @@ The implementation uses a fat JAR built with Maven, requiring Java 17+. It's des --- -### 9. gogios +### 8. gogios * 💻 Languages: Go (98.9%), JSON (0.6%), YAML (0.5%) * 📚 Documentation: Markdown (94.9%), Text (5.1%) @@ -220,7 +198,7 @@ The architecture is straightforward: JSON configuration defines checks (plugin p --- -### 10. yoga +### 9. yoga * 💻 Languages: Go (66.1%), HTML (33.9%) * 📚 Documentation: Markdown (100.0%) @@ -244,7 +222,7 @@ The implementation follows clean Go architecture with domain logic organized und --- -### 11. perc +### 10. perc * 💻 Languages: Go (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -266,7 +244,7 @@ The tool is built as a simple Go CLI application with a standard project layout --- -### 12. totalrecall +### 11. totalrecall * 💻 Languages: Go (99.0%), Shell (0.5%), YAML (0.4%) * 📚 Documentation: Markdown (99.5%), Text (0.5%) @@ -292,7 +270,7 @@ The project offers both a keyboard-driven GUI for interactive use and a CLI for --- -### 13. ior +### 12. ior * 💻 Languages: Go (63.2%), C (36.0%), C/C++ (0.8%) * 📚 Documentation: Markdown (79.3%), Text (20.7%) @@ -318,7 +296,7 @@ The tool is implemented in Go and C, leveraging libbpfgo for BPF interaction. It --- -### 14. gitsyncer +### 13. gitsyncer * 💻 Languages: Go (92.5%), Shell (7.1%), JSON (0.4%) * 📚 Documentation: Markdown (100.0%) @@ -340,7 +318,7 @@ The implementation uses a git remotes approach: it clones from one organization, --- -### 15. tasksamurai +### 14. tasksamurai * 💻 Languages: Go (99.8%), YAML (0.2%) * 📚 Documentation: Markdown (100.0%) @@ -366,7 +344,7 @@ Under the hood, Task Samurai acts as a front-end wrapper that invokes the native --- -### 16. foostats +### 15. foostats * 💻 Languages: Perl (100.0%) * 📚 Documentation: Markdown (54.6%), Text (45.4%) @@ -388,7 +366,7 @@ The implementation uses a modular Perl architecture with specialized components: --- -### 17. timr +### 16. timr * 💻 Languages: Go (96.0%), Shell (4.0%) * 📚 Documentation: Markdown (100.0%) @@ -410,7 +388,7 @@ The architecture is straightforward: it's a Go-based CLI application that persis --- -### 18. dtail +### 17. 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%) @@ -436,7 +414,7 @@ The architecture follows a client-server model where DTail servers run on target --- -### 19. gos +### 18. gos * 💻 Languages: Go (99.8%), JSON (0.2%) * 📚 Documentation: Markdown (100.0%) @@ -462,7 +440,7 @@ The implementation uses OAuth2 for LinkedIn authentication, stores configuration --- -### 20. ds-sim +### 19. ds-sim * 💻 Languages: Java (98.9%), Shell (0.6%), CSS (0.5%) * 📚 Documentation: Markdown (98.7%), Text (1.3%) @@ -486,7 +464,7 @@ The implementation follows a modular Java architecture with clear separation bet --- -### 21. wireguardmeshgenerator +### 20. wireguardmeshgenerator * 💻 Languages: Ruby (65.4%), YAML (34.6%) * 📚 Documentation: Markdown (100.0%) @@ -508,7 +486,7 @@ The tool reads host definitions from a YAML file specifying network interfaces ( --- -### 22. gemtexter +### 21. gemtexter * 💻 Languages: Shell (68.2%), CSS (28.5%), Config (1.9%), HTML (1.3%) * 📚 Documentation: Text (76.1%), Markdown (23.9%) @@ -530,7 +508,7 @@ The architecture leverages GNU utilities (sed, grep, date) and optional tools li --- -### 23. rcm +### 22. rcm * 💻 Languages: Ruby (99.8%), TOML (0.2%) * 📚 Documentation: Markdown (100.0%) @@ -552,7 +530,7 @@ The implementation centers around a DSL module that provides keywords like `file --- -### 24. terraform +### 23. terraform * 💻 Languages: HCL (96.6%), Make (1.9%), YAML (1.5%) * 📚 Documentation: Markdown (100.0%) @@ -574,7 +552,7 @@ The infrastructure uses a **modular, layered architecture** with separate Terraf --- -### 25. quicklogger +### 24. quicklogger * 💻 Languages: Go (96.1%), XML (1.9%), Shell (1.2%), TOML (0.7%) * 📚 Documentation: Markdown (100.0%) @@ -600,7 +578,7 @@ The implementation leverages Go's cross-compilation capabilities and Fyne's UI a --- -### 26. sillybench +### 25. sillybench * 💻 Languages: Go (90.9%), Shell (9.1%) * 📚 Documentation: Markdown (100.0%) @@ -622,7 +600,7 @@ The implementation is intentionally straightforward, using Go's built-in testing --- -### 27. goprecords +### 26. goprecords * 💻 Languages: Go (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -644,7 +622,7 @@ Under the hood, it parses `uptimed`'s simple `uptime:boottime:kernel` record for --- -### 28. gorum +### 27. gorum * 💻 Languages: Go (91.3%), JSON (6.4%), YAML (2.3%) * 📚 Documentation: Markdown (100.0%) @@ -667,7 +645,7 @@ The architecture consists of client/server components for inter-node communicati --- -### 29. guprecords +### 28. guprecords * 💻 Languages: Raku (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -689,7 +667,7 @@ The implementation uses an object-oriented architecture with specialized classes --- -### 30. geheim +### 29. geheim * 💻 Languages: Ruby (86.7%), Shell (13.3%) * 📚 Documentation: Markdown (100.0%) @@ -711,7 +689,7 @@ The architecture leverages Git for storage and synchronization across multiple r --- -### 31. docker-radicale-server +### 30. docker-radicale-server * 💻 Languages: Make (57.5%), Docker (42.5%) * 📚 Documentation: Markdown (100.0%) @@ -733,7 +711,7 @@ The implementation uses Alpine Linux as the base image for a minimal footprint, --- -### 32. algorithms +### 31. algorithms * 💻 Languages: Go (99.2%), Make (0.8%) * 📚 Documentation: Markdown (100.0%) @@ -756,7 +734,7 @@ The project is implemented in Go 1.19+ with comprehensive unit tests and benchma --- -### 33. randomjournalpage +### 32. randomjournalpage * 💻 Languages: Shell (94.1%), Make (5.9%) * 📚 Documentation: Markdown (100.0%) @@ -779,7 +757,7 @@ The implementation is a straightforward bash script using `qpdf` for PDF extract --- -### 34. photoalbum +### 33. photoalbum * 💻 Languages: Shell (80.1%), Make (12.3%), Config (7.6%) * 📚 Documentation: Markdown (100.0%) @@ -802,7 +780,7 @@ The architecture is straightforward and Unix-philosophy driven: users configure --- -### 35. ioriot +### 34. ioriot * 💻 Languages: C (55.5%), C/C++ (24.0%), Config (19.6%), Make (1.0%) * 📚 Documentation: Markdown (100.0%) @@ -827,7 +805,7 @@ The key advantage over traditional benchmarking tools is that it reproduces actu --- -### 36. ipv6test +### 35. ipv6test * 💻 Languages: Perl (65.8%), Docker (34.2%) * 📚 Documentation: Markdown (100.0%) @@ -849,7 +827,7 @@ The implementation uses a simple CGI script ([index.pl](file:///home/paul/git/gi --- -### 37. sway-autorotate +### 36. sway-autorotate * 💻 Languages: Shell (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -871,7 +849,7 @@ The implementation uses a bash script that continuously monitors the `monitor-se --- -### 38. mon +### 37. mon * 💻 Languages: Perl (96.5%), Shell (1.8%), Make (1.2%), Config (0.4%) * 📚 Documentation: Text (100.0%) @@ -894,7 +872,7 @@ Implemented in Perl, `mon` features automatic JSON backup before modifications ( --- -### 39. staticfarm-apache-handlers +### 38. staticfarm-apache-handlers * 💻 Languages: Perl (96.4%), Make (3.6%) * 📚 Documentation: Text (100.0%) @@ -917,7 +895,7 @@ Both handlers are implemented as Perl modules using Apache2's mod_perl API, conf --- -### 40. pingdomfetch +### 39. pingdomfetch * 💻 Languages: Perl (97.3%), Make (2.7%) * 📚 Documentation: Text (100.0%) @@ -940,7 +918,7 @@ The tool is implemented around a hierarchical configuration system (`/etc/pingdo --- -### 41. fype +### 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%) @@ -962,7 +940,7 @@ The implementation uses a simple top-down parser with maximum lookahead of 1, in --- -### 42. xerl +### 41. xerl * 💻 Languages: Perl (98.3%), Config (1.2%), Make (0.5%) * 📊 Commits: 670 @@ -983,7 +961,7 @@ The implementation follows strict OO Perl conventions with explicit typing and p --- -### 43. ychat +### 42. 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%) @@ -1006,7 +984,7 @@ The architecture emphasizes speed and scalability through several key design cho --- -### 44. fapi +### 43. fapi * 💻 Languages: Python (96.6%), Make (3.1%), Config (0.3%) * 📚 Documentation: Text (98.3%), Markdown (1.7%) @@ -1028,7 +1006,7 @@ The tool is implemented in Python and depends on the bigsuds library (F5's iCont --- -### 45. perl-c-fibonacci +### 44. perl-c-fibonacci * 💻 Languages: C (80.4%), Make (19.6%) * 📚 Documentation: Text (100.0%) @@ -1049,7 +1027,7 @@ perl-c-fibonacci: source code repository. --- -### 46. netcalendar +### 45. netcalendar * 💻 Languages: Java (83.0%), HTML (12.9%), XML (3.0%), CSS (0.8%), Make (0.2%) * 📚 Documentation: Text (89.7%), Markdown (10.3%) @@ -1076,7 +1054,7 @@ The key feature is its intelligent color-coded event visualization system that h --- -### 47. loadbars +### 46. loadbars * 💻 Languages: Perl (97.4%), Make (2.6%) * 📚 Documentation: Text (100.0%) @@ -1097,10 +1075,10 @@ loadbars: source code repository. --- -### 48. gotop +### 47. gotop * 💻 Languages: Go (98.0%), Make (2.0%) -* 📚 Documentation: Text (50.0%), Markdown (50.0%) +* 📚 Documentation: Markdown (50.0%), Text (50.0%) * 📊 Commits: 57 * 📈 Lines of Code: 499 * 📄 Lines of Documentation: 8 @@ -1120,7 +1098,7 @@ The implementation uses a concurrent architecture with goroutines for data colle --- -### 49. rubyfy +### 48. rubyfy * 💻 Languages: Ruby (98.5%), JSON (1.5%) * 📚 Documentation: Markdown (100.0%) @@ -1143,7 +1121,7 @@ The tool is implemented as a lightweight Ruby script that prioritizes simplicity --- -### 50. pwgrep +### 49. pwgrep * 💻 Languages: Shell (85.0%), Make (15.0%) * 📚 Documentation: Text (80.8%), Markdown (19.2%) @@ -1166,7 +1144,7 @@ The architecture is lightweight and Unix-philosophy driven: password databases a --- -### 51. perldaemon +### 50. perldaemon * 💻 Languages: Perl (72.3%), Shell (23.8%), Config (3.9%) * 📊 Commits: 110 @@ -1187,7 +1165,7 @@ The implementation centers around an event loop with configurable intervals that --- -### 52. jsmstrade +### 51. jsmstrade * 💻 Languages: Java (76.0%), Shell (15.4%), XML (8.6%) * 📚 Documentation: Markdown (100.0%) @@ -1212,7 +1190,7 @@ The implementation is minimalistic, consisting of just three main Java classes ( --- -### 53. japi +### 52. japi * 💻 Languages: Perl (78.3%), Make (21.7%) * 📚 Documentation: Text (100.0%) @@ -1235,7 +1213,7 @@ Implemented in Perl using the JIRA::REST CPAN module, japi supports flexible con --- -### 54. perl-poetry +### 53. perl-poetry * 💻 Languages: Perl (100.0%) * 📚 Documentation: Markdown (100.0%) @@ -1258,7 +1236,7 @@ This project exemplifies creative coding where Perl keywords and constructs are --- -### 55. muttdelay +### 54. muttdelay * 💻 Languages: Make (47.1%), Shell (46.3%), Vim Script (5.9%), Config (0.7%) * 📚 Documentation: Text (100.0%) @@ -1281,7 +1259,7 @@ The architecture uses three components working together: a Vim plugin that provi --- -### 56. netdiff +### 55. netdiff * 💻 Languages: Shell (52.2%), Make (46.3%), Config (1.5%) * 📚 Documentation: Text (100.0%) @@ -1304,7 +1282,7 @@ The tool uses a clever client-server architecture where you run the identical co --- -### 57. debroid +### 56. debroid * 💻 Languages: Shell (92.0%), Make (8.0%) * 📚 Documentation: Markdown (100.0%) @@ -1329,7 +1307,7 @@ The implementation uses a two-stage debootstrap process: first creating a Debian --- -### 58. hsbot +### 57. hsbot * 💻 Languages: Haskell (98.5%), Make (1.5%) * 📊 Commits: 80 @@ -1350,7 +1328,7 @@ The implementation uses a modular design with core components separated into Bas --- -### 59. cpuinfo +### 58. cpuinfo * 💻 Languages: Shell (53.2%), Make (46.8%) * 📚 Documentation: Text (100.0%) @@ -1373,7 +1351,7 @@ The implementation is elegantly simple: a single shell script ([src/cpuinfo](fil --- -### 60. template +### 59. template * 💻 Languages: Make (89.2%), Shell (10.8%) * 📚 Documentation: Text (100.0%) @@ -1396,7 +1374,7 @@ The implementation uses a **Makefile-based build system** with targets for compi --- -### 61. awksite +### 60. awksite * 💻 Languages: AWK (72.1%), HTML (16.4%), Config (11.5%) * 📚 Documentation: Text (60.0%), Markdown (40.0%) @@ -1419,7 +1397,7 @@ The architecture is remarkably simple: a single AWK script ([index.cgi](file:/// --- -### 62. dyndns +### 61. dyndns * 💻 Languages: Shell (100.0%) * 📚 Documentation: Text (100.0%) @@ -1442,7 +1420,7 @@ The implementation uses a two-tier security architecture: SSH public key authent --- -### 63. vs-sim +### 62. vs-sim * 📚 Documentation: Markdown (100.0%) * 📊 Commits: 411 diff --git a/about/showcase/debroid/image-1.png b/about/showcase/debroid/image-1.png index 0b85a152..d7cec344 100644 --- a/about/showcase/debroid/image-1.png +++ b/about/showcase/debroid/image-1.png @@ -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:4a3c577d-7bce-215c-29cc-06932ef0cfd5"> + <meta name="fetch-nonce" content="v2:8624b6e5-a58b-5e72-a90e-7876584e8ffd"> <meta name="current-catalog-service-hash" content="f3abb0cc802f3d7b95fc8762b94bdcb13bf39634c40c357301c4aa1d67a256fb"> - <meta name="request-id" content="BA94:1E5F37:A3EFF74:83B0E84:6999839C" data-pjax-transient="true"/><meta name="html-safe-nonce" content="13375c6e9739579ec839a82ca4cfcc93d514ee87ac0c1bdebcf3758a00e3bb78" data-pjax-transient="true"/><meta name="visitor-payload" content="eyJyZWZlcnJlciI6IiIsInJlcXVlc3RfaWQiOiJCQTk0OjFFNUYzNzpBM0VGRjc0OjgzQjBFODQ6Njk5OTgzOUMiLCJ2aXNpdG9yX2lkIjoiODA2NjYyMDE2MDY5MTA4NjM2IiwicmVnaW9uX2VkZ2UiOiJmcmEiLCJyZWdpb25fcmVuZGVyIjoiZnJhIn0=" data-pjax-transient="true"/><meta name="visitor-hmac" content="b725af58113ecb705891ed3202ee88d0524a44fc74642b4f926b73e59392c196" data-pjax-transient="true"/> + <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"/> @@ -310,10 +310,10 @@ </a> <div class="AppHeader-appearanceSettings"> <react-partial-anchor> - <button data-target="react-partial-anchor.anchor" id="icon-button-5888e2c3-2465-4dec-a02c-c2ace14b371f" aria-labelledby="tooltip-300a52a7-18dc-46eb-8527-2c01d2b0a9bc" 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-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"> <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-300a52a7-18dc-46eb-8527-2c01d2b0a9bc" for="icon-button-5888e2c3-2465-4dec-a02c-c2ace14b371f" 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-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> <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="HCfq0_164kaRHcGA48Yz0uDsVOuZwqtUCPymMsXkRQ1rJgT5-qJjCUJLtQB0B9yIbr2qMXsQ_WER_6raTT0k_g" 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="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"> <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-81bdbc98-4751-43d5-a8ef-0ce51f3390c9" 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-120bdb6f-6ddb-46b7-a894-783c4c7aedd7" 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-81bdbc98-4751-43d5-a8ef-0ce51f3390c9" hidden="hidden"> + <div class="FormControl-inlineValidation" id="validation-120bdb6f-6ddb-46b7-a894-783c4c7aedd7" 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="ICMY1tTMMwWQTBbYaSoFIil7QmNy9UkY+t08j9OqdoZ7m1CymxOu84ThP8uybeFooLaqTgktgjObchzbGPB8dA==" /> + <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==" /> <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="OYy7JnFqJOWfdW9cR6752+uXFZw1nOf4rlKj3pRlslBB5FKteHRCD1jICsGpFQwwN4TwoUAOz4s9VA621QnfhA==" /> + <!-- '"` --><!-- </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==" /> <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="5poeJIsCpqBTL+JriWY9pr4OoAmLntfjjvxSaEcj9/2SheGm7F1x4iG7txEsGT4HqcIu226ySTQvzzzas/1Z+g==" /> + <input type="hidden" data-csrf="true" value="jRIcRYoCu3pZxVmP7GfCeo05Vet/nabQY500faaLUDNrn9WtZwwBrMiGf1pBif/E+SPFvJbekLbb5+p0DSCTSw==" /> </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="5vIa83w6T2K9dvydGaiFKfjSswo71d8iCH+UQGsuJhqVk4j8GSxOtrqUt8o6ji5bY574SBTReojd/9v4QdyHig==" /> <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="1QcTcEijHrIIQo0koksHxg39ZzTl1PamKfw7KhxJsFQXba7qjFnrjy4GJddcUO6EeIOdzbLrJ8MVe7tMkB+9Ug==" /> <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_eb65" hidden="hidden" /> -<input class="form-control" type="hidden" name="timestamp" value="1771668380596" /> -<input class="form-control" type="hidden" name="timestamp_secret" value="f27cd8ee30973ff2d8623b7b6a1f838af7a523cb89aa9bd6e1bc9866514e8748" /> +<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 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-849cabbe-eb6c-4a52-966c-0d487203e6f4" aria-labelledby="tooltip-132c571b-6283-43a5-84b2-fe6f0461556e" 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-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"> <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-132c571b-6283-43a5-84b2-fe6f0461556e" for="icon-button-849cabbe-eb6c-4a52-966c-0d487203e6f4" 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-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> <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-bd5999c5-8333-4a7b-a10c-bd4bfa38c9e4" aria-labelledby="tooltip-1f050b5b-5c23-42b7-860c-c3dbdd6b6606" 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-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"> <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-1f050b5b-5c23-42b7-860c-c3dbdd6b6606" for="icon-button-bd5999c5-8333-4a7b-a10c-bd4bfa38c9e4" 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-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> diff --git a/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.gmi b/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.gmi index 846ad8da..052703e6 100644 --- a/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.gmi +++ b/gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.gmi @@ -294,6 +294,7 @@ Context is what the agent *knows*; commands and skills are what the agent *does* Other related posts: +=> ./2026-02-22-taskwarrior-autonomous-agent-loop.gmi 2026-02-22 Taskwarrior as an autonomous AI agent loop: 48 tasks in one day => ./2026-02-14-meta-slash-commands-for-prompts-and-context.gmi 2026-02-14 Meta slash-commands to manage prompts, skills, and context for coding agents (You are currently reading this) => ./2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.gmi 2026-02-02 A tmux popup editor for Cursor Agent CLI prompts diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index b32194a8..1bf49c68 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,12 +1,503 @@ <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> - <updated>2026-02-21T11:20:07+02:00</updated> + <updated>2026-02-21T23:07:08+02:00</updated> <title>foo.zone feed</title> <subtitle>To be in the .zone!</subtitle> <link href="gemini://foo.zone/gemfeed/atom.xml" rel="self" /> <link href="gemini://foo.zone/" /> <id>gemini://foo.zone/</id> <entry> + <title>Taskwarrior as an autonomous AI agent loop: 48 tasks in one day</title> + <link href="gemini://foo.zone/gemfeed/2026-02-22-taskwarrior-autonomous-agent-loop.gmi" /> + <id>gemini://foo.zone/gemfeed/2026-02-22-taskwarrior-autonomous-agent-loop.gmi</id> + <updated>2026-02-21T23:07:07+02:00</updated> + <author> + <name>Paul Buetow aka snonux</name> + <email>paul@dev.buetow.org</email> + </author> + <summary>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.</summary> + <content type="xhtml"> + <div xmlns="http://www.w3.org/1999/xhtml"> + <h1 style='display: inline' id='taskwarrior-as-an-autonomous-ai-agent-loop-48-tasks-in-one-day'>Taskwarrior as an autonomous AI agent loop: 48 tasks in one day</h1><br /> +<br /> +<a href='./taskwarrior-autonomous-agent/ior-flamegraph.png'><img alt='Example ior flamegraph showing I/O syscall activity by process, file path, and tracepoint' title='Example ior flamegraph showing I/O syscall activity by process, file path, and tracepoint' src='./taskwarrior-autonomous-agent/ior-flamegraph.png' /></a><br /> +<br /> +<span>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.</span><br /> +<br /> +<a class='textlink' href='https://ampcode.com'>Ampcode — the AI coding agent used for this project</a><br /> +<br /> +<h2 style='display: inline' id='table-of-contents'>Table of Contents</h2><br /> +<br /> +<ul> +<li><a href='#taskwarrior-as-an-autonomous-ai-agent-loop-48-tasks-in-one-day'>Taskwarrior as an autonomous AI agent loop: 48 tasks in one day</a></li> +<li>⇢ <a href='#what-is-ior-and-what-does-it-do'>What is ior and what does it do</a></li> +<li>⇢ ⇢ <a href='#what-is-a-syscall'>What is a syscall</a></li> +<li>⇢ ⇢ <a href='#what-is-ebpf'>What is eBPF</a></li> +<li>⇢ ⇢ <a href='#what-ior-traces-and-why'>What ior traces and why</a></li> +<li>⇢ <a href='#the-problem-writing-a-full-test-suite-by-hand'>The problem: writing a full test suite by hand</a></li> +<li>⇢ <a href='#before-and-after'>Before and after</a></li> +<li>⇢ <a href='#how-the-project-taskwarrior-skill-works'>How the project-taskwarrior skill works</a></li> +<li>⇢ ⇢ <a href='#skillmd--the-entry-point'>SKILL.md — the entry point</a></li> +<li>⇢ ⇢ <a href='#00-contextmd--project-scoping-and-global-rules'>00-context.md — project scoping and global rules</a></li> +<li>⇢ ⇢ <a href='#1-create-taskmd--creating-tasks-with-full-context'>1-create-task.md — creating tasks with full context</a></li> +<li>⇢ ⇢ <a href='#2-start-taskmd--fresh-context-per-task'>2-start-task.md — fresh context per task</a></li> +<li>⇢ ⇢ <a href='#3-complete-taskmd--the-quality-gate'>3-complete-task.md — the quality gate</a></li> +<li>⇢ ⇢ <a href='#4-annotate-update-taskmd--progress-tracking'>4-annotate-update-task.md — progress tracking</a></li> +<li>⇢ ⇢ <a href='#5-review-overview-tasksmd--picking-the-next-task'>5-review-overview-tasks.md — picking the next task</a></li> +<li>⇢ <a href='#the-reflection-and-review-loop'>The reflection and review loop</a></li> +<li>⇢ <a href='#measurable-results'>Measurable results</a></li> +<li>⇢ <a href='#a-real-bug-found-by-the-review-loop'>A real bug found by the review loop</a></li> +<li>⇢ <a href='#gotchas-and-lessons-learned'>Gotchas and lessons learned</a></li> +<li>⇢ ⇢ <a href='#cost'>Cost</a></li> +<li>⇢ ⇢ <a href='#syscall-wrappers-on-amd64'>Syscall wrappers on amd64</a></li> +<li>⇢ ⇢ <a href='#task-granularity-matters'>Task granularity matters</a></li> +<li>⇢ <a href='#how-to-replicate-this'>How to replicate this</a></li> +</ul><br /> +<h2 style='display: inline' id='what-is-ior-and-what-does-it-do'>What is ior and what does it do</h2><br /> +<br /> +<span>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.</span><br /> +<br /> +<a href='./taskwarrior-autonomous-agent/ior-logo.png'><img alt='I/O Riot NG logo' title='I/O Riot NG logo' src='./taskwarrior-autonomous-agent/ior-logo.png' /></a><br /> +<br /> +<a class='textlink' href='https://codeberg.org/snonux/ior'>I/O Riot NG on Codeberg</a><br /> +<a class='textlink' href='https://codeberg.org/snonux/ioriot'>The original I/O Riot (SystemTap)</a><br /> +<br /> +<span>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.</span><br /> +<br /> +<h3 style='display: inline' id='what-is-a-syscall'>What is a syscall</h3><br /> +<br /> +<span>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.</span><br /> +<br /> +<span>For example, when a program calls <span class='inlinecode'>open("/etc/passwd", O_RDONLY)</span>, it triggers the <span class='inlinecode'>openat</span> 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."</span><br /> +<br /> +<span>There are hundreds of syscalls in Linux. The I/O-related ones that ior traces include:</span><br /> +<br /> +<ul> +<li><span class='inlinecode'>openat</span>, <span class='inlinecode'>creat</span>, <span class='inlinecode'>open_by_handle_at</span> — opening files</li> +<li><span class='inlinecode'>read</span>, <span class='inlinecode'>write</span>, <span class='inlinecode'>pread64</span>, <span class='inlinecode'>pwrite64</span>, <span class='inlinecode'>readv</span>, <span class='inlinecode'>writev</span> — reading and writing data</li> +<li><span class='inlinecode'>close</span>, <span class='inlinecode'>close_range</span> — closing file descriptors</li> +<li><span class='inlinecode'>dup</span>, <span class='inlinecode'>dup2</span>, <span class='inlinecode'>dup3</span> — duplicating file descriptors</li> +<li><span class='inlinecode'>fcntl</span> — manipulating file descriptor properties</li> +<li><span class='inlinecode'>rename</span>, <span class='inlinecode'>renameat</span>, <span class='inlinecode'>renameat2</span> — renaming files</li> +<li><span class='inlinecode'>link</span>, <span class='inlinecode'>linkat</span>, <span class='inlinecode'>symlink</span>, <span class='inlinecode'>symlinkat</span>, <span class='inlinecode'>readlinkat</span> — creating and reading links</li> +<li><span class='inlinecode'>unlink</span>, <span class='inlinecode'>unlinkat</span>, <span class='inlinecode'>rmdir</span> — removing files and directories</li> +<li><span class='inlinecode'>mkdir</span>, <span class='inlinecode'>mkdirat</span>, <span class='inlinecode'>chdir</span>, <span class='inlinecode'>getdents64</span> — directory operations</li> +<li><span class='inlinecode'>stat</span>, <span class='inlinecode'>fstat</span>, <span class='inlinecode'>lstat</span>, <span class='inlinecode'>newfstatat</span>, <span class='inlinecode'>statx</span>, <span class='inlinecode'>access</span>, <span class='inlinecode'>faccessat</span> — file metadata</li> +<li><span class='inlinecode'>fsync</span>, <span class='inlinecode'>fdatasync</span>, <span class='inlinecode'>sync</span>, <span class='inlinecode'>sync_file_range</span> — flushing data to disk</li> +<li><span class='inlinecode'>truncate</span>, <span class='inlinecode'>ftruncate</span> — resizing files</li> +<li><span class='inlinecode'>io_uring_setup</span>, <span class='inlinecode'>io_uring_enter</span>, <span class='inlinecode'>io_uring_register</span> — async I/O</li> +</ul><br /> +<h3 style='display: inline' id='what-is-ebpf'>What is eBPF</h3><br /> +<br /> +<span>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.</span><br /> +<br /> +<span>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 native speed. 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.</span><br /> +<br /> +<span>ior uses eBPF to attach to the entry and exit tracepoints of every I/O-related syscall. When any process on the system calls <span class='inlinecode'>openat</span>, for example, the kernel fires the <span class='inlinecode'>sys_enter_openat</span> 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 <span class='inlinecode'>sys_exit_openat</span> 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.</span><br /> +<br /> +<h3 style='display: inline' id='what-ior-traces-and-why'>What ior traces and why</h3><br /> +<br /> +<span>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 <span class='inlinecode'>.ior.zst</span> 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.</span><br /> +<br /> +<span>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 <span class='inlinecode'>/sys/fs/cgroup/memory.stat</span>, or that your database is doing thousands of <span class='inlinecode'>fsync</span> calls per second on its WAL file. Traditional tools like <span class='inlinecode'>strace</span> can show you this too, but <span class='inlinecode'>strace</span> uses ptrace which has significant overhead and slows down the traced process. eBPF-based tracing is orders of magnitude faster.</span><br /> +<br /> +<h2 style='display: inline' id='the-problem-writing-a-full-test-suite-by-hand'>The problem: writing a full test suite by hand</h2><br /> +<br /> +<span>The ior project needed a comprehensive test suite at two levels:</span><br /> +<br /> +<ul> +<li>Unit tests in <span class='inlinecode'>internal/eventloop_test.go</span> — 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.</li> +<li>Integration tests in <span class='inlinecode'>integrationtests/</span> — these launch a real <span class='inlinecode'>ioworkload</span> binary that performs actual syscalls, start ior with real BPF tracing against that process, wait for it to finish, and then parse the resulting <span class='inlinecode'>.ior.zst</span> file to verify that the expected tracepoints were captured. These require root and a running kernel with BPF support.</li> +</ul><br /> +<span>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. Writing all of this by hand would take days.</span><br /> +<br /> +<h2 style='display: inline' id='before-and-after'>Before and after</h2><br /> +<br /> +<span>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.</span><br /> +<br /> +<span>After: I front-loaded about 48 tasks into Taskwarrior with detailed descriptions and file references, 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.</span><br /> +<br /> +<span>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.</span><br /> +<br /> +<h2 style='display: inline' id='how-the-project-taskwarrior-skill-works'>How the project-taskwarrior skill works</h2><br /> +<br /> +<pre> + ┌──────────────────────────────────────────────────┐ + │ │ + │ task add "implement open_test.go" +agent │ + │ task add "implement close_test.go" +agent │ + │ task add "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) │ + │ │ + └──────────────────────────────────────────────────┘ +</pre> +<br /> +<span>The skill lives in <span class='inlinecode'>~/.agents/skills/project-taskwarrior/</span> and consists of a <span class='inlinecode'>SKILL.md</span> 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.</span><br /> +<br /> +<h3 style='display: inline' id='skillmd--the-entry-point'>SKILL.md — the entry point</h3><br /> +<br /> +<span>Every Ampcode skill has a <span class='inlinecode'>SKILL.md</span> with YAML frontmatter (name, description, trigger phrases) and an overview. This is what the agent sees first when it loads the skill:</span><br /> +<br /> +<pre> +--- +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. +</pre> +<br /> +<span>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 <span class='inlinecode'>00-context.md</span> + <span class='inlinecode'>1-create-task.md</span>. Completing one? Load <span class='inlinecode'>00-context.md</span> + <span class='inlinecode'>3-complete-task.md</span>. This keeps context lean.</span><br /> +<br /> +<h3 style='display: inline' id='00-contextmd--project-scoping-and-global-rules'>00-context.md — project scoping and global rules</h3><br /> +<br /> +<span>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 <span class='inlinecode'>+agent</span>):</span><br /> +<br /> +<pre> +# 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. +</pre> +<br /> +<h3 style='display: inline' id='1-create-taskmd--creating-tasks-with-full-context'>1-create-task.md — creating tasks with full context</h3><br /> +<br /> +<span>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:</span><br /> +<br /> +<pre> +# 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. +</pre> +<br /> +<h3 style='display: inline' id='2-start-taskmd--fresh-context-per-task'>2-start-task.md — fresh context per task</h3><br /> +<br /> +<span>This ensures each task gets a clean slate — no carry-over from previous work:</span><br /> +<br /> +<pre> +# 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. +</pre> +<br /> +<h3 style='display: inline' id='3-complete-taskmd--the-quality-gate'>3-complete-task.md — the quality gate</h3><br /> +<br /> +<span>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:</span><br /> +<br /> +<pre> +# 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. +</pre> +<br /> +<h3 style='display: inline' id='4-annotate-update-taskmd--progress-tracking'>4-annotate-update-task.md — progress tracking</h3><br /> +<br /> +<pre> +# 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 +</pre> +<br /> +<h3 style='display: inline' id='5-review-overview-tasksmd--picking-the-next-task'>5-review-overview-tasks.md — picking the next task</h3><br /> +<br /> +<pre> +# 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 +</pre> +<br /> +<h2 style='display: inline' id='the-reflection-and-review-loop'>The reflection and review loop</h2><br /> +<br /> +<span>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.</span><br /> +<br /> +<span>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.</span><br /> +<br /> +<span>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.</span><br /> +<br /> +<h2 style='display: inline' id='measurable-results'>Measurable results</h2><br /> +<br /> +<span>Here is what one day of autonomous Ampcode work produced:</span><br /> +<br /> +<ul> +<li>About 6 hours of autonomous work (16:13 to 22:03)</li> +<li>48 Taskwarrior tasks completed</li> +<li>47 git commits</li> +<li>87 files changed</li> +<li>12,012 lines added, 1,543 removed</li> +<li>18 integration test files</li> +<li>15 workload scenario files (one per syscall category)</li> +<li>93 test scenarios total (happy-path and negative)</li> +<li>13 syscall categories fully covered: open, read/write, close, dup, fcntl, rename, link, unlink, dir, stat, sync, truncate, and io_uring</li> +</ul><br /> +<h2 style='display: inline' id='a-real-bug-found-by-the-review-loop'>A real bug found by the review loop</h2><br /> +<br /> +<span>During the negative test implementation for <span class='inlinecode'>close_range</span>, the review loop uncovered a real bug in ior's event loop. The <span class='inlinecode'>close_range</span> handler was deleting file descriptors from the internal <span class='inlinecode'>files</span> 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.</span><br /> +<br /> +<h2 style='display: inline' id='gotchas-and-lessons-learned'>Gotchas and lessons learned</h2><br /> +<br /> +<h3 style='display: inline' id='cost'>Cost</h3><br /> +<br /> +<span>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.</span><br /> +<br /> +<h3 style='display: inline' id='syscall-wrappers-on-amd64'>Syscall wrappers on amd64</h3><br /> +<br /> +<span>Go's <span class='inlinecode'>syscall</span> package on amd64 silently delegates to <span class='inlinecode'>*at</span> variants. <span class='inlinecode'>os.Open()</span> calls <span class='inlinecode'>openat</span>, <span class='inlinecode'>os.Mkdir()</span> calls <span class='inlinecode'>mkdirat</span>, <span class='inlinecode'>os.Stat()</span> calls <span class='inlinecode'>newfstatat</span>. The agent kept writing tests expecting <span class='inlinecode'>enter_open</span> when the kernel actually sees <span class='inlinecode'>enter_openat</span>. 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.</span><br /> +<br /> +<h3 style='display: inline' id='task-granularity-matters'>Task granularity matters</h3><br /> +<br /> +<span>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.</span><br /> +<br /> +<h2 style='display: inline' id='how-to-replicate-this'>How to replicate this</h2><br /> +<br /> +<span>The recipe:</span><br /> +<br /> +<ul> +<li>Use Taskwarrior (or any task tracker the agent can query via CLI).</li> +<li>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.</li> +<li>Front-load tasks with detailed descriptions and file references. Each task must be self-contained.</li> +<li>Tag tasks so the agent only works on its own tasks and does not touch anything else.</li> +<li>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.</li> +<li>Enforce a quality gate: compilation, tests, negative tests, and dual sub-agent review before marking done.</li> +<li>Use flat-rate pricing if you plan to run autonomously for hours.</li> +</ul><br /> +<span>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.</span><br /> +<br /> +<a class='textlink' href='https://taskwarrior.org'>Taskwarrior — command-line task management</a><br /> +<br /> +<span>Other related posts:</span><br /> +<br /> +<a class='textlink' href='./2026-02-22-taskwarrior-autonomous-agent-loop.html'>2026-02-22 Taskwarrior as an autonomous AI agent loop: 48 tasks in one day (You are currently reading this)</a><br /> +<a class='textlink' href='./2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.html'>2026-02-02 A tmux popup editor for Cursor Agent CLI prompts</a><br /> +<a class='textlink' href='./2023-07-17-career-guide-and-soft-skills-book-notes.html'>2023-07-17 "Software Developers Career Guide and Soft Skills" book notes</a><br /> +<br /> +<span>E-Mail your comments to <span class='inlinecode'>paul@nospam.buetow.org</span> :-)</span><br /> +<br /> +<a class='textlink' href='../'>Back to the main site</a><br /> + </div> + </content> + </entry> + <entry> <title>My desk rack: DeskPi RackMate T0</title> <link href="gemini://foo.zone/gemfeed/2026-02-22-my-desk-rack.gmi" /> <id>gemini://foo.zone/gemfeed/2026-02-22-my-desk-rack.gmi</id> @@ -695,6 +1186,7 @@ mage test <br /> <span>Other related posts:</span><br /> <br /> +<a class='textlink' href='./2026-02-22-taskwarrior-autonomous-agent-loop.html'>2026-02-22 Taskwarrior as an autonomous AI agent loop: 48 tasks in one day</a><br /> <a class='textlink' href='./2026-02-14-meta-slash-commands-for-prompts-and-context.html'>2026-02-14 Meta slash-commands to manage prompts, skills, and context for coding agents (You are currently reading this)</a><br /> <a class='textlink' href='./2026-02-02-tmux-popup-editor-for-cursor-agent-prompts.html'>2026-02-02 A tmux popup editor for Cursor Agent CLI prompts</a><br /> <br /> @@ -18345,178 +18837,4 @@ http://www.gnu.org/software/src-highlite --> </div> </content> </entry> - <entry> - <title>'Slow Productivity' book notes</title> - <link href="gemini://foo.zone/gemfeed/2024-05-01-slow-productivity-book-notes.gmi" /> - <id>gemini://foo.zone/gemfeed/2024-05-01-slow-productivity-book-notes.gmi</id> - <updated>2024-04-27T14:18:51+03:00</updated> - <author> - <name>Paul Buetow aka snonux</name> - <email>paul@dev.buetow.org</email> - </author> - <summary>These are my personal takeaways after reading 'Slow Productivity - The lost Art of Accomplishment Without Burnout' by Cal Newport.</summary> - <content type="xhtml"> - <div xmlns="http://www.w3.org/1999/xhtml"> - <h1 style='display: inline' id='slow-productivity-book-notes'>"Slow Productivity" book notes</h1><br /> -<br /> -<span class='quote'>Published at 2024-04-27T14:18:51+03:00</span><br /> -<br /> -<span>These are my personal takeaways after reading "Slow Productivity - The lost Art of Accomplishment Without Burnout" by Cal Newport.</span><br /> -<br /> -<span>The case studies in this book were a bit long, but they appeared to be well-researched. I will only highlight the interesting, actionable items in the book notes.</span><br /> -<br /> -<span>These notes are mainly for my own use, but you may find them helpful.</span><br /> -<br /> -<pre> - ,.......... .........., - ,..,' '.' ',.., - ,' ,' : ', ', - ,' ,' : ', ', - ,' ,' : ', ', - ,' ,'............., : ,.............', ', -,' '............ '.' ............' ', - '''''''''''''''''';''';'''''''''''''''''' - ''' -</pre> -<br /> -<h2 style='display: inline' id='table-of-contents'>Table of Contents</h2><br /> -<br /> -<ul> -<li><a href='#slow-productivity-book-notes'>"Slow Productivity" book notes</a></li> -<li>⇢ <a href='#it-s-not-slow-productivity'>It's not "slow productivity"</a></li> -<li>⇢ <a href='#pseudo-productivity-and-shallow-work'>Pseudo-productivity and Shallow work</a></li> -<li>⇢ <a href='#accomplishments-without-burnout'>Accomplishments without burnout</a></li> -<li>⇢ <a href='#do-fewer-things'>Do fewer things</a></li> -<li>⇢ <a href='#work-at-a-natural-pace'>Work at a natural pace</a></li> -<li>⇢ <a href='#obsess-over-quality-'>Obsess over quality </a></li> -</ul><br /> -<h2 style='display: inline' id='it-s-not-slow-productivity'>It's not "slow productivity"</h2><br /> -<br /> -<span>"Slow productivity" does not mean being less productive. Cal Newport wants to point out that you can be much more productive with "slow productivity" than you would be without it. It is a different way of working than most of us are used to in the modern workplace, which is hyper-connected and always online.</span><br /> -<br /> -<h2 style='display: inline' id='pseudo-productivity-and-shallow-work'>Pseudo-productivity and Shallow work</h2><br /> -<br /> -<span>People use visible activity instead of real productivity because it's easier to measure. This is called pseudo-productivity.</span><br /> -<span>Pseudo-productivity is used as a proxy for real productivity. If you don't look busy, you are dismissed as lazy or lacking a work ethic.</span><br /> -<br /> -<span>There is a tendency to perform shallow work because people will otherwise dismiss you as lazy. A lot of shallow work can cause burnout, as multiple things are often being worked on in parallel. The more you have on your plate, the more stressed you will be.</span><br /> -<br /> -<span>Shallow work usually doesn't help you to accomplish big things. Always have the big picture in mind. Shallow work can't be entirely eliminated, but it can be managed—for example, plan dedicated time slots for certain types of shallow work.</span><br /> -<br /> -<h2 style='display: inline' id='accomplishments-without-burnout'>Accomplishments without burnout</h2><br /> -<br /> -<span>The overall perception is that if you want to accomplish something, you must put yourself on the verge of burnout. Cal Newport writes about "The lost Art of Accomplishments without Burnouts", where you can accomplish big things without all the stress usually involved.</span><br /> -<br /> -<span>There are three principles for the maintenance of a sustainable work life:</span><br /> -<br /> -<ul> -<li>Do fewer things</li> -<li>Work at a natural pace</li> -<li>Obsess over quality</li> -</ul><br /> -<h2 style='display: inline' id='do-fewer-things'>Do fewer things</h2><br /> -<br /> -<span>There will always be more work. The faster you finish it, the quicker you will have something new on your plate.</span><br /> -<br /> -<span>Reduce the overhead tax. The overhead tax is all the administrative work to be done. With every additional project, there will also be more administrative stuff to be done on your work plate. So, doing fewer things leads to more and better output and better quality for the projects you are working on.</span><br /> -<br /> -<span>Limit the things on your plate. Limit your missions (personal goals, professional goals). Reduce your main objectives in life. More than five missions are usually not sustainable very easily, so you have to really prioritise what is important to you and your professional life.</span><br /> -<br /> -<span>A mission is an overall objective/goal that can have multiple projects. Limit the projects as well. Some projects need clear endings (e.g., work in support of a never-ending flow of incoming requests). In this case, set limits (e.g., time box your support hours). You can also plan "office hours" for collaborative work with colleagues to avoid ad hoc distractions.</span><br /> -<br /> -<span>The key point is that after making these commitments, you really deliver on them. This builds trust, and people will leave you alone and not ask for progress all the time.</span><br /> -<br /> -<span>Doing fever things is essential for modern knowledge workers. Breathing space in your work also makes you more creative and happier overall.</span><br /> -<br /> -<span>Pushing workers more work can make them less productive, so the better approach is the pull model, where workers pull in new work when the previous task is finished.</span><br /> -<br /> -<span>If you can quantify how busy you are or how many other projects you already work on, then it is easier to say no to new things. For example, show what you are doing, what's in the roadmap, etc. Transparency is the key here. </span><br /> -<br /> -<span>You can have your own simulated pull system if the company doesn't agree to a global one: </span><br /> -<br /> -<ul> -<li>State which additional information you would need.</li> -<li>Create a rough estimate of when you will be able to work on it</li> -<li>Estimate how long the project would take. Double that estimate, as humans are very bad estimators.</li> -<li>Respond to the requester and state that you will let him know when the estimates change.</li> -</ul><br /> -<span>Sometimes, a little friction is all that is needed to combat incoming work, e.g., when your manager starts seeing the reality of your work plate, and you also request additional information for the task. If you already have too much on your plate, then decline the new project or make room for it in your calendar. If you present a large task list, others will struggle to assign more to you.</span><br /> -<br /> -<span>Limit your daily goals. A good measure is to focus on one goal per day. You can time block time for deep work on your daily goal. During that time, you won't be easily available to others.</span><br /> -<br /> -<span>The battle against distractions must be fought to be the master of your time. Nobody will fight this war for you. You have to do it for yourself. (Also, have a look at Cal Newport's "time block planning" method).</span><br /> -<br /> -<span>Put tasks on autopilot (regular recurring tasks).</span><br /> -<br /> -<h2 style='display: inline' id='work-at-a-natural-pace'>Work at a natural pace</h2><br /> -<br /> -<span>We suffer from overambitious timelines, task lists, and business. Focus on what matters. Don't rush your most important work to achieve better results.</span><br /> -<br /> -<span>Don't rush. If you rush or are under pressure, you will be less effective and eventually burn out. Our brains work better then not rushy. The stress heuristic usually indicates too much work, and it is generally too late to reduce workload. That's why we all typically have dangerously too much to do.</span><br /> -<br /> -<span>Have the courage to take longer to do things that are important. For example, plan on a yearly and larger scale, like 2 to 5 years.</span><br /> -<br /> -<span>Find a reasonable time for a project and then double the project timeline against overconfident optimism. Humans are not great at estimating. They gravitate towards best-case estimates. If you have planned more than enough time for your project, then you will fall into a natural work pace. Otherwise, you will struggle with rushing and stress.</span><br /> -<br /> -<span>Some days will still be intense and stressful, but those are exceptional cases. After those exceptions (e.g., finalizing that thing, etc.), calmer periods will follow again.</span><br /> -<br /> -<span>Pace yourself over modest results over time. Simplify and reduce the daily task lists. Meetings: Certain hours are protected for work. For each meeting, add a protected block to your calendar, so you attend meetings only half a day max.</span><br /> -<br /> -<span>Schedule slow seasons (e.g., when on vacation). Disconnect in the slow season. Doing nothing will not satisfy your mind, though. You could read a book on your subject matter to counteract that.</span><br /> -<br /> -<h2 style='display: inline' id='obsess-over-quality-'>Obsess over quality </h2><br /> -<br /> -<span>Obsess over quality even if you lose short-term opportunities by rejecting other projects. Quality demands you slow down. The two previous two principles (do fewer things and work at a natural pace) are mandatory for this principle to work:</span><br /> -<br /> -<ul> -<li>Focus on the core activities of your work for your obsession - you will only have the time to obsess over some things.</li> -<li>Deliver solid work with good quality.</li> -<li>Sharpen the focus to do the best work possible.</li> -</ul><br /> -<span>Go pro to save time, and don't squeeze everything out that you can from freemium services. Professional software services eliminate administrative work:</span><br /> -<br /> -<ul> -<li>Pay people who know what they are doing and focus on your stuff. </li> -<li>For example, don't repair that car if you know the mechanic can do that much better than you. </li> -<li>Or don't use the free version of the music streaming service if it interrupts you with commercials, hindering your ability to concentrate on your work.</li> -<li>Hire an accountant for your yearly tax returns. He knows much more about that stuff than you do. And in the end, he will even be cheaper as he knows all the tax laws.</li> -<li>...</li> -</ul><br /> -<span>Adjust your workplace to what you want to accomplish. You could have dedicated places in your home for different things, e.g., a place where you read and think (armchair) and a place where you collaborate (your desk or whiteboard). Surround yourself with things that inspire you (e.g., your favourite books on your shelf next to you, etc.).</span><br /> -<br /> -<span>There is the concept of quiet quitting. It doesn't mean quitting your job, but it means that you don't go beyond and above the expectations people have of you. Quiet quitting became popular with modern work, which is often meaningless and full of shallow tasks. If you obsess over quality, you enjoy your craft and want to go beyond and above.</span><br /> -<br /> -<span>Implement rituals and routines which shift you towards your goals:</span><br /> -<br /> -<ul> -<li>For example, if you want to be a good Software Engineer, you also have to put in the work regularly. For instance, progress a bit every day in your project at hand, even if it is only one hour daily. Also, a little quality daily work will be more satisfying over time than many shallow tasks.</li> -<li>Do you want to be lean and/or healthy? Schedule your daily walks and workouts. They will become habits over time.</li> -<li>There's the compounding effect where every small effort made every day will yield significant results in the long run</li> -</ul><br /> -<span>Deciding what not to do is as important as deciding what to do. </span><br /> -<br /> -<span>It appears to be money thrown out of the window, but you get a $50 expensive paper notebook (and also a good pen). Unconsciously, it will make you take notes more seriously. You will think about what to put into the notebooks more profoundly and have thought through the ideas more intensively. If you used very cheap notebooks, you would scribble a lot of rubbish and wouldn't even recognise your handwriting after a while anymore. So choosing a high-quality notebook will help you to take higher-quality notes, too.</span><br /> -<br /> -<span>Slow productivity is actionable and can be applied immediately.</span><br /> -<br /> -<span>E-Mail your comments to <span class='inlinecode'>paul@nospam.buetow.org</span> :-)</span><br /> -<br /> -<span>Other book notes of mine are:</span><br /> -<br /> -<a class='textlink' href='./2025-11-02-the-courage-to-be-disliked-book-notes.html'>2025-11-02 "The Courage To Be Disliked" book notes</a><br /> -<a class='textlink' href='./2025-06-07-a-monks-guide-to-happiness-book-notes.html'>2025-06-07 "A Monk's Guide to Happiness" book notes</a><br /> -<a class='textlink' href='./2025-04-19-when-book-notes.html'>2025-04-19 "When: The Scientific Secrets of Perfect Timing" book notes</a><br /> -<a class='textlink' href='./2024-10-24-staff-engineer-book-notes.html'>2024-10-24 "Staff Engineer" book notes</a><br /> -<a class='textlink' href='./2024-07-07-the-stoic-challenge-book-notes.html'>2024-07-07 "The Stoic Challenge" book notes</a><br /> -<a class='textlink' href='./2024-05-01-slow-productivity-book-notes.html'>2024-05-01 "Slow Productivity" book notes (You are currently reading this)</a><br /> -<a class='textlink' href='./2023-11-11-mind-management-book-notes.html'>2023-11-11 "Mind Management" book notes</a><br /> -<a class='textlink' href='./2023-07-17-career-guide-and-soft-skills-book-notes.html'>2023-07-17 "Software Developers Career Guide and Soft Skills" book notes</a><br /> -<a class='textlink' href='./2023-05-06-the-obstacle-is-the-way-book-notes.html'>2023-05-06 "The Obstacle is the Way" book notes</a><br /> -<a class='textlink' href='./2023-04-01-never-split-the-difference-book-notes.html'>2023-04-01 "Never split the difference" book notes</a><br /> -<a class='textlink' href='./2023-03-16-the-pragmatic-programmer-book-notes.html'>2023-03-16 "The Pragmatic Programmer" book notes</a><br /> -<br /> -<a class='textlink' href='../'>Back to the main site</a><br /> - </div> - </content> - </entry> </feed> diff --git a/gemfeed/index.gmi b/gemfeed/index.gmi index 47a398b8..05c2b917 100644 --- a/gemfeed/index.gmi +++ b/gemfeed/index.gmi @@ -2,6 +2,7 @@ ## To be in the .zone! +=> ./2026-02-22-taskwarrior-autonomous-agent-loop.gmi 2026-02-22 - Taskwarrior as an autonomous AI agent loop: 48 tasks in one day => ./2026-02-22-my-desk-rack.gmi 2026-02-22 - My desk rack: DeskPi RackMate T0 => ./2026-02-15-loadbars-resurrected-from-perl-to-go.gmi 2026-02-15 - Loadbars resurrected: From Perl to Go after 15 years => ./2026-02-14-meta-slash-commands-for-prompts-and-context.gmi 2026-02-14 - Meta slash-commands to manage prompts, skills, and context for coding agents @@ -30,6 +30,7 @@ Everything you read on this site is my personal opinion and experience. You can ### Posts +=> ./gemfeed/2026-02-22-taskwarrior-autonomous-agent-loop.gmi 2026-02-22 - Taskwarrior as an autonomous AI agent loop: 48 tasks in one day => ./gemfeed/2026-02-22-my-desk-rack.gmi 2026-02-22 - My desk rack: DeskPi RackMate T0 => ./gemfeed/2026-02-15-loadbars-resurrected-from-perl-to-go.gmi 2026-02-15 - Loadbars resurrected: From Perl to Go after 15 years => ./gemfeed/2026-02-14-meta-slash-commands-for-prompts-and-context.gmi 2026-02-14 - Meta slash-commands to manage prompts, skills, and context for coding agents |
