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.

Container Storage Interface (CSI)

Storage behavior used to be built into Kubernetes. The container storage interface (CSI) defines a unified interface to manage storage volumes, regardless of the orchestrator (as long as they implement the CSI). This makes it way easier for third-party storage providers to expose data to Kubernetes. If a storage provider implements this interface, orchestrators can use it to provision volumes to containers. Notable storage providers are:

• NFS
• Cinder (Openstack)
• Ceph
• AWS EBS

A full list of CSI drivers can be found here.

Container Runtime Interface (CRI)

The Container Runtime Interface (CRI) is an API that allows Kubernetes to use different container runtimes without needing to recompile the entire Kubernetes codebase. Before CRI, Kubernetes had a direct integration with Docker, making it difficult to use alternative container runtimes.

CRI defines the API between Kubernetes components (specifically kubelet) and container runtimes. This abstraction allows Kubernetes to support multiple container runtimes simultaneously, giving users the flexibility to choose the runtime that best fits their needs. Some popular container runtimes that implement the CRI include:

• containerd - The industry-standard container runtime that powers Docker and is maintained by the CNCF
• CRI-O - A lightweight runtime specifically designed for Kubernetes
• Kata Containers - A secure container runtime that uses hardware virtualization for stronger isolation

With CRI, switching between different runtimes becomes more straightforward, allowing operators to optimize for security, performance, or compatibility based on their specific requirements.

Container Network Interface (CNI)

The Container Network Interface (CNI) defines a standard for configuring network interfaces for Linux containers. Similar to CSI and CRI, the CNI was created to decouple Kubernetes from specific networking implementations, allowing for a pluggable architecture.

CNI plugins are responsible for allocating IP addresses to pods and ensuring proper network connectivity between pods, nodes, and external networks. They implement features like network policies, load balancing, and network security. Some popular CNI plugins include:

• Calico - Known for its performance, flexibility, and strong network policy support
• Cilium - Uses eBPF for high-performance networking and security
• Flannel - Simple overlay network focused on ease of use
• AWS VPC CNI - Integrates pods directly with Amazon VPC networking

Each CNI plugin has its strengths and is suitable for different use cases. For example, Calico excels at enforcing network policies, Cilium is optimized for performance and observability, while Flannel is valued for its simplicity.

Wrapping Up

One thing I've always admired about Kubernetes is its pluggable architecture. These standardized interfaces (CSI, CRI, and CNI) showcase how well-designed the system really is. Instead of building everything into the core, the Kubernetes team made the smart decision to create extension points that allow the community to innovate without touching the core codebase.

The great news? You don't have to swap out all these components or even understand them deeply to use Kubernetes effectively. While the array of options might seem daunting at first glance, most Kubernetes distributions (like EKS, GKE, AKS, or Rancher) come with sane defaults that work well out of the box. They've already made sensible choices about which storage, runtime, and networking components to include.

This pluggability is what makes Kubernetes so powerful for those who need it. Need a specific storage solution? Plug in a CSI driver. Want a more secure container runtime? Swap in a different CRI implementation. But for everyone else, the defaults will serve you just fine.

The beauty of this approach is that it gives you room to grow. Start with the defaults, and when you have specific requirements, the extension points are there waiting for you. That's the real magic of Kubernetes – it works great out of the box but doesn't limit your options as your needs evolve.