This matters because coding agents will happily walk you straight into the dumb zone. A modern agent burns through tokens fast. A few file reads, a long debug session, a sprawling test run, and you're at 100k before lunch. Meanwhile vendors keep advertising windows of 200k, 1M, even 2M, as if those numbers represented a usable working set. They don't. Studies like RULER and Chroma's report on context rot show that effective context is a fraction of the advertised number, and that performance degrades gradually as you fill the window.

Large context windows are mostly a marketing number. The architectures behind them work, but they paper over a problem the underlying attention mechanism doesn't really solve. The number on the box gets bigger every release. The usable part doesn't keep up.

Modern agents are getting smart about this. Tools like Claude Code now auto-compact: when the session gets long, the agent summarizes the history and starts fresh. That helps. But auto-compaction kicks in after you've already spent time in the dumb zone, and the summary is itself produced by a model that's already degraded. Better than nothing, but I'd rather avoid the situation altogether.

What I do is open a new session and pass it a spec I wrote myself. That's a much higher signal handoff than any automated summary, because I get to decide what matters going forward. It's the breadcrumb approach applied to agents. Leave an artifact that the next session, or the next person, can pick up cleanly.

You can take this further. Projects like obra/superpowers and mattpocock/skills structure entire agent workflows around small, named artifacts. PRDs, plans, skills, sub-agent handoffs. Each one is a way to keep the working session in the smart zone by deliberately moving information out of the session into something the next session can read.

So I treat my context window like a budget. I assume only the first chunk is really working for me, and everything I can move out of the live session and into a written artifact is one less thing for attention to fight over.

The Open5e node provides access to 12 different D&D 5e resources through the Open5e API. Each resource supports three operations:

• Get Many: Retrieve multiple items with optional filters and pagination
• Get: Retrieve a single item by its identifier (slug or key)
• Search: Search for items by name or description

Example Workflows

1. Random Encounter Generator

Create random encounters by fetching monsters filtered by challenge rating:

1. Add an Open5e node to your workflow
2. Select Resource: Monster
3. Select Operation: Get Many
4. In Filters, add:
   • Challenge Rating: 5
   • Document Source: wotc-srd
5. Toggle Return All ON to get all matching monsters
6. Connect to a Function node to randomly select 3-5 monsters
7. Format the output as needed (Discord message, email, etc.)

2. Spell Lookup Bot

Build a Discord bot that looks up spell information:

1. Use a Discord Trigger node to listen for commands
2. Add a Function node to extract the spell name from the command
3. Add an Open5e node:
   • Resource: Spell
   • Operation: Search
   • Search Term: ={{ $json.spellName }}
4. Add a Function node to format the spell details
5. Send the formatted spell info back to Discord

3. Item Database Search

Search for magic items and weapons by name:

1. Add an HTTP Request trigger or Form trigger to accept search queries
2. Add an Open5e node:
   • Resource: Magic Item (or Weapon)
   • Operation: Search
   • Search Term: ={{ $json.query }}
   • Limit: 10
3. Format and return the results

Contributing

This is my first n8n community node. Contributions are welcome! Please feel free to submit a Pull Request or open an issue if you encounter any issues.

Brains are pattern recognition machines.

I seek structure, sometimes meta-structure.

I try to structure how I structure things.

Projects, stories and adventures often only become apparent when they are in the past.

They evolve naturally, organically. Starting a project can result in something completely different. Is there a structure in that?

I am trying to find structure again.

Life is chaotic, and that's okay.

I had this on my mind for quite some time. I'm trying to cope with chaos in my life. I like chaos, and I like turning chaos into order. But often, that does not work and I get frustrated.

Projects - no matter if programming, writing, planning an event or woodworking - are inherently chaotic. There is no structure in the concept of a "project". I want to think of a project as the sum of threads of actions towards a goal, and life is the sum of every project you ever started. I try to find a way to capture and grasp these "threads" - like commits on different branches of a code repository. On projects other than programming, this utterly fails.

I have to keep telling myself to be fine with the fact that life does not follow a structure. My personal takeaway is learning to recognize when I am seeking structure as a response to anxiety vs. when I'm doing it because it's actually useful.

Am I alone with this? Does this resonate with anyone out there? I'd love to hear from you.

• MacOS
• VSCode
• Vim Extension

The Issue

Long-pressing j or k (think "down" or "up" in Vim) only results in one down or up action, instead of continuous scrolling.

The Fix

In a terminal, run the following command:

defaults write com.microsoft.VSCode ApplePressAndHoldEnabled -bool false

Original post: https://stackoverflow.com/a/44010683

Additional tip

In the MacOS settings, set "Key Repeat Rate" and "Delay Until Repeat" to the highest setting to be able to scroll much faster.

<img width="478" height="92" alt="Image" src="https://github.com/user-attachments/assets/7bf85853-377d-4727-a5c8-2766f2794e8a" />

Lately, I was wandering if parts of the scientific method could more often be applied to every day life. There are many different resources out there explaining the scientific method, often with examples of how to apply it outside of an academic environment. The core method is always the same (in this case, taken from sciencebuddies.org):

1. Ask a Question
2. Do Background Research
3. Construct a Hypothesis
4. Test Your Hypothesis by Doing an Experiment
5. Analyze Your Data and Draw a Conclusion
6. Communicate Your Results

Related: To prove something is true, try disproving it first

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you’re done you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

Because creating a custom entity was not quite so straight forward as I'd hoped, I wanted to share how I did it.

I ended up using the input_number integration (which seems to come with Home Assistant) and defined an entity that I could reference through the API:

`yaml

configuration.yaml

inputnumber: easyfitnessauslastung: name: EasyFitness Auslastung initial: 0 min: 0 max: 100 step: 1 `

After reloading the configuration, the entity was ready to be written to.

As mentioned, I'm using a self-hosted instance of n8n on a Raspberry Pi to automate this. Using their Home Assistant Integration, you can simply address the new entity and update its state. And just like that, I was able to add a new Gauge to my dashboard!

I always stayed away from TeamViewer, because I was never really sure if that had a free plan, and the possibility of finding out mid-session that they don't have one was reason enough to save the hassle of yelling the installation instructions through the phone.

I remember hearing about RustDesk in a podcast a couple of years ago. The host claimed it to be a hassle-free open source replacement for TeamViewer, but by the time the next IT-support session arrived, I already forgot about it. Until yesterday!

Yesterday, I just didn't get enough information to be useful. I just needed a way to remotely access the computer, and that's then I remembered the promise of RustDesk. Going in blind, I quickly installed the client on my laptop and sent a mail with the instructions to my family member:

1. Click here (a download link to the executable file)
2. Press the windows key
3. Type "rust" (to search for the file)
4. Press enter
5. Tell me the ID and the onetime password on the screen

These instructions are fool-proof! And sure enough, they worked. I logged in and debugged the issue. No paywall, no corporate bullsh**, just a simple client that just works as intended out of the box. I was delighted to see that the plan has worked out. Going forward, Rustdesk will be my primary choice for remote IT support.

If you're interested: for some reason the browser window on their screen was resized to a tiny box near the edge of the screen, so whenever they clicked a bookmarked link on their desktop, instead of "nothing happening", they just didn't see the page opening in the browser.

TL;DR

Use RustDesk instead of TeamViewer for a free and easy way to access your family's computer remotely.

` diff --git a/lib/ui/screens/detail/components/body/eventbody.dart b/lib/ui/screens/detail/components/body/eventbody.dart index d19d70a..1a61380 100644 --- a/lib/ui/screens/detail/components/body/eventbody.dart +++ b/lib/ui/screens/detail/components/body/eventbody.dart @@ -3,6 +3,7 @@ class EventBody extends StatelessWidget { final EventDetails details; @@ -18,35 +19,43 @@ class EventBody extends StatelessWidget {

@override Widget build(BuildContext context) => Column( - crossAxisAlignment: CrossAxisAlignment.stretch, - children: [ - EventInfoView( - location: details.location, - start: details.start, - end: details.end, - certified: details.certified, - paid: details.paid, - points: null, // Already shown in app bar + crossAxisAlignment: CrossAxisAlignment.stretch, + children: [ + EventInfoView( + location: details.location, + start: details.start, + end: details.end, + certified: details.certified, + paid: details.paid, + points: null, // Already shown in app bar + ), + const SizedBox(height: 24), + Html( + data: details.description, + style: { + 'body': Style( + margin: Margins.zero, ... } `

But do you spot what has ACTUALLY been changed? In a real world scenario, it probably took you a while before you realised that it's the result of formatting the entire file. Nobody cares about whitespace when reviewing code. Or rather, your brain should not take the burden of having to care about that. That's what linters are for!

Let's look at the same diff with the --ignore-all-space (shorthand -w) flag activated:

diff --git a/lib/ui/screens/detail/components/body/event_body.dart b/lib/ui/screens/detail/components/body/event_body.dart index d19d70a..1a61380 100644 --- a/lib/ui/screens/detail/components/body/event_body.dart +++ b/lib/ui/screens/detail/components/body/event_body.dart @@ -3,6 +3,7 @@ class EventBody extends StatelessWidget { final EventDetails details; @@ -29,6 +30,14 @@ class EventBody extends StatelessWidget { points: null, // Already shown in app bar ), const SizedBox(height: 24), + Html( + data: details.description, + style: { + 'body': Style( + margin: Margins.zero, + ), + }, + ), Text(details.description, style: context.theme.textTheme.body2Regular), if (details.registrationUrl != null || details.programUrl != null) const SizedBox(height: 16), if (details.registrationUrl != null) ...[

Huh, so it's NOT just a formatted file. All whitespace changes have been stripped out, and you only see the changes that are relevant for the review. Neat!

Many tools also support ignoring whitespace. GitLab let's you disable Show whitespace changes in the merge request diff viewer. VSCode has the diffEditor.ignoreTrimWhitespace setting. So, if you want to make this the default in your tools, chances are there's an option for only showing relevant changes.

A bit of a sloppy post, but I hope this is useful to someone. Happy code reviewing!

If you build a feature into your app, you've generated an output, and therefore value. But what if you bang your head against the wall and don't make any progress? Write about it. Write about your challenges, document what you've learned and share it with your peers. Not reaching a set goal doesn't mean failure. It's an opportunity to create value in a way you didn't anticipate.

If you're out on a run and a thought pops into your head, record a memo on your phone, or better yet: keep a tiny notebook with you at all times. Thoughts slip in and out of our heads at a very rapid pace. Capturing thoughts, even if you don't share them with anyone else, is a great way to generate value out of thin air.

If you're into crafty hobbies like woodworking, painting or baking, you likely know how important it is to finish a project. No matter how good or bad the outcome is, every finished project is an artifact that you can look back at later and see the progress you've made.

Output always means value, even if it's not immediately apparent. Just keep on laying down those breadcrumbs.