Jens Willmer

Gear Ratio Advanced: Velocity, Torque & Efficiency

Fri, 27 Jun 2025 21:21:00 +0000

This post builds on Gear Ratio Basics and explains how gear ratios affect speed (velocity), torque, and efficiency. Understanding these concepts helps you design gear systems that work the way you need them to.

🔄 Gear Ratio and Velocity

The gear ratio controls how fast the output gear turns compared to the input gear. The formula for calculating this is shown below:

\[\text{Gear Ratio} = \frac{\text{Input Speed}}{\text{Output Speed}}\]

For example, if your input gear rotates at 200 revolutions per minute (RPM) and you use a 2:1 gear ratio, you can calculate the output speed like this:

\[\text{Output Speed} = \frac{200\, \text{RPM}}{2} = 100\, \text{RPM}\]

This means the output gear turns at 100 RPM. A higher gear ratio slows down the output gear because the driven gear rotates fewer times for each turn of the driver gear. That’s how gear reductions let you decrease speed when needed, like in a robot’s drivetrain or a power tool’s gearbox.

💪 Gear Ratio and Torque

Gear ratios also affect torque, which is the twisting force transmitted through the gears. The relationship between gear ratio and torque is:

\[\text{Output Torque} = \text{Input Torque} \times \text{Gear Ratio}\]

For example, if your motor produces 1 newton-meter (Nm) of torque and you use a 3:1 gear ratio, you calculate the output torque like this:

\[\text{Output Torque} = 1\, \text{Nm} \times 3 = 3\, \text{Nm}\]

This means you get 3 Nm of torque at the output. By slowing the rotation, the gear system lets the same power apply more force. In practical terms, a gear reduction gives you more torque at the cost of slower speed, which is essential when you need to move something heavy.

⚠️ Direction Reminder

Whenever gears mesh, they change the direction of rotation. Every time you add a gear between the driver and the driven gear, the direction reverses again. For example, if you connect your driver gear to an idler gear, the idler reverses the direction, and the next gear will spin the opposite way compared to the driver. An idler gear does not change the gear ratio, but it flips the rotation direction once more. An even number of gears in the train means the output spins in the same direction as the input. An odd number of gears means the output spins in the opposite direction.

⚙️ Gear Efficiency

No gear system is perfectly efficient. Energy is lost through friction, heat, and flexing of materials, so it is important to understand gear efficiency. Spur gears usually operate at 95 to 98 percent efficiency for each gear mesh. Worm gears have much lower efficiency, often below 70 percent, because of the sliding friction that happens between the worm and worm wheel.

To calculate the total efficiency of a gear train with multiple stages, multiply the efficiency of each gear pair together. For example, if you have two spur gear pairs with 97 percent efficiency each, you calculate the total efficiency like this:

\[\text{Total Efficiency} = 0.97 \times 0.97 = 0.9409 \quad (\text{or } 94.1\%)\]

This means your gear train will deliver about 94.1 percent of the input power to the output. Lower efficiency means more heat and less useful power, which can become a problem in systems where energy savings or heat management are important.

✅ Summary

A higher gear ratio reduces the output speed but increases the output torque. Gears reverse rotation direction with each mesh, and the total number of gears in a train determines whether the output spins in the same or opposite direction as the input. Efficiency losses add up with every gear pair, so always include them in your calculations when designing a gear system.

What is Retrieval-Augmented Generation (RAG)

Tue, 20 May 2025 06:20:00 +0000

Large language models are impressive, but they’re limited by what they were trained on. They can’t access your internal documentation, stay current with new data, or reliably distinguish fact from fiction.

Retrieval-Augmented Generation (RAG) addresses this gap. It augments a language model by giving it access to external data at runtime. When a question is asked, the system first retrieves relevant information from a knowledge base—usually a vector database of semantically indexed chunks. Only then does the model generate a response, grounded in this retrieved context.

This enables more accurate, domain-aware, and verifiable answers without retraining the model. RAG effectively gives language models a dynamic memory—on your terms.

When to Use RAG

Retrieval-Augmented Generation is ideal when your application needs accurate, current, and domain-specific responses—but you don’t want to (or can’t) retrain the model.

Use RAG when:

Your data changes frequently. Traditional fine-tuning locks knowledge at training time. RAG lets you update answers by simply changing the underlying documents.
You need traceability. With RAG, every response is backed by retrievable content. Users (or auditors) can trace outputs to their original source.
Your knowledge is proprietary. Whether it’s internal policies, customer reports, or technical documentation, RAG can surface private data securely at inference time.
You want modular updates. By storing and referencing chunks with unique IDs, you can update individual pieces of content without retraining or reindexing everything.

RAG is especially useful for:

Internal support agents
Developer or product documentation assistants
Compliance and legal tools
Systems needing multilingual or version-aware responses

If your app needs dynamic answers with real references, RAG is the right foundation. It’s not just a theoretical model—real systems are using it to solve hard problems today.

Real-world systems already use this architecture to great effect. For instance, Mem0 implements a memory layer built on RAG. It retrieves semantically indexed memory entries—rather than relying on fragile prompt chains—enabling consistent, personalized responses over time.

At the infrastructure level, vector search engines like Qdrant power these retrieval systems. Qdrant supports hybrid filtering, payload scoring, and fast nearest neighbor search, making it ideal for large-scale, production-grade RAG systems.

Preparing Data for Ingestion

To make RAG work reliably, your content must be structured for retrieval and usable by a language model. This isn’t about dumping documents into a vector database—it’s about shaping the content so the model can reason over it effectively.

Start by extracting clean content from your sources. Remove layout artifacts, navigation elements, and anything irrelevant to the actual information. You want concise, plain-language text that reflects what a human would read to understand the topic.

Next, normalize the language. Rewrite content — especially code snippets, config files, or logs — into complete, natural sentences. Instead of embedding a raw string like user_limit: 250, convert it to “The maximum number of users allowed is 250.” The goal is natural language that the model can easily process and use in a response.

Every chunk should include descriptive metadata. This includes values like the source URL, section title, date, author, product or version, and any tags or classifications you use internally. Metadata can be stored separately or embedded into the text depending on your system design, but it must be consistent and queryable.

Finally, and critically, assign a unique and stable ID to every chunk or document. This lets you update or delete specific entries later without affecting the rest of your dataset. It’s essential for keeping your index maintainable over time.

RAG is only as good as the data it retrieves—so preparing your content with care is the foundation for everything that follows.

Improving Retrieval with Context

Once your data is clean, natural, and enriched with metadata, the next step is making it retrievable in a meaningful way. This is where context comes in. A single paragraph or sentence often lacks enough information on its own to match a user’s query effectively. By embedding context into each chunk, you improve both recall and precision during retrieval.

Inspired by Anthropic’s contextual retrieval approach, one method is to prepend a short description that explains what the chunk is about. For example, instead of storing:

“The system will reject login attempts after 5 failed tries.”

You might store:

“From the user authentication section of the security policy: The system will reject login attempts after 5 failed tries.”

This extra framing helps the embedding model encode why this text matters and where it belongs. It also improves match quality for more abstract or high-level questions like “What are our login security rules?”

Context can come from:

Section headings or document structure
File paths or category tags
Summaries or topic labels
Manual annotations (if scale allows)

In addition to prepending context to text, you can enrich your vector index with structured metadata. Many systems support hybrid search—combining vector similarity with keyword filters. For example, you can restrict results by audience (developer), language (de), or document type (release_notes).

The key idea is: make the meaning explicit. Give the system as much information as possible, up front, to help it retrieve the right content later.

Conclusion: Why RAG Matters

RAG brings structure, memory, and accountability to generative systems. It bridges the gap between static models and real-world knowledge — without the overhead of retraining.

To recap:

Use RAG when your data changes often, needs to stay private, or must be cited.
Prepare your data with clean, readable language and real metadata.
Track unique IDs for each entry so your dataset stays maintainable.
Add contextual information to each chunk to improve retrieval precision.

Done right, RAG systems are more flexible than fine-tuning, more trustworthy than standalone LLMs, and more adaptable to your evolving needs.

If you’re building AI systems that need to be smart and reliable, RAG isn’t just an option—it’s the standard.

Docker Networking Pitfalls

Sun, 02 Feb 2025 21:15:00 +0000

Docker networking is powerful but can be confusing, especially when dealing with communication between the host machine and Docker containers. Many developers assume that network behavior inside a Docker network works the same as on the host, leading to unexpected issues. In this post, we’ll explore common pitfalls when running services with Docker Compose and how to handle them correctly.

The Basics: Host vs. Docker Network

Docker Compose creates an isolated network for services to communicate. Each container gets a unique DNS name corresponding to its service name in docker-compose.yml. However, the way networking works inside Docker is different from how it works on the host machine.

Host Perspective (External Access)

When accessing a service from the host machine (outside Docker), you must use localhost and the mapped port:

curl http://localhost:8080  # Accessing a container-bound service via a mapped port

You cannot use Docker-internal DNS names (such as service_name) or host.docker.internal from the host machine.

Docker Container Perspective (Internal Communication)

Containers within the same Docker network can refer to each other by service name:

curl http://app-store:5000  # Works inside Docker

But if a container needs to communicate with a service running on the host machine, it must use host.docker.internal:

curl http://host.docker.internal:3000  # Works inside Docker to reach host

Common Pitfalls and How to Solve Them

Pitfall 1: Trying to Access a Container Using Service Names from the Host

❌ Incorrect:

curl http://app-store:5000  # Won't work from the host machine

The app-store service name is only resolvable inside Docker’s internal network.

✅ Correct:

curl http://localhost:5000  # Use localhost + mapped port from the host

This works if the port is correctly mapped in docker-compose.yml:

docker-compose.yml:
services:
  app-store:
    ports:
      - "5000:5000"

Pitfall 2: Using `localhost` Inside a Container to Reach Another Container

❌ Incorrect:

curl http://localhost:5000  # Won't work inside a container

Inside a container, localhost refers to itself, not other services in the Docker network.

✅ Correct:

curl http://app-store:5000  # Use the service name inside Docker

Pitfall 3: A Container Trying to Access a Host Service Without `host.docker.internal`

❌ Incorrect:

curl http://localhost:3306  # Won't work inside Docker

Since localhost inside a container refers to the container itself, this won’t connect to a host service.

✅ Correct:

curl http://host.docker.internal:3306  # Correct way inside Docker

Pitfall 4: Web Applications Generating Incorrect URLs

Web applications often generate links for users dynamically based on their environment. If the application is running inside a Docker container, it may generate links using internal Docker service names, which are not accessible to users.

❌ Incorrect:

<a href="http://web-service:8080">Click here</a>  <!-- Won't work for the user -->

✅ Correct:

Ensure the application differentiates between:

Internal URLs (used by services within Docker, such as web-service:8080)
External URLs (used by users, such as localhost:8080 or a domain name)

Understanding `host.docker.internal` Availability

host.docker.internal is a special hostname that resolves to the host machine’s IP address from within a Docker container. However, its availability depends on the operating system:

Platform	Availability	Notes
Windows	✅ Available	Works out of the box
Mac (Intel & M1/M2)	✅ Available	Built-in since Docker Desktop 18.03
Linux	❌ Not Available	Requires manual setup via `extra_hosts`
WSL 2	✅ Available	Works with Docker Desktop
iOS	❌ Not Available	No official support

For Linux users, a workaround is required:

docker-compose.yml:
services:
  my-service:
    extra_hosts:
      - "host.docker.internal:host-gateway"

This maps host.docker.internal to the host gateway.

Visualizing the Networking Model

Source	Destination	Works?	Solution
Host → Container	`localhost:port`	✅	Use mapped port in `docker-compose.yml`
Host → Container	`service_name`	❌	Won’t resolve
Container → Container	`service_name`	✅	Works within the same Docker network
Container → Host	`localhost`	❌	Refers to itself
Container → Host	`host.docker.internal:port`	✅	Works correctly
Web App → User Link	`service_name:port`	❌	Won’t work for users
Web App → User Link	`localhost:port`	✅	Use proper externally accessible URLs

Key Takeaways

Overview of the communication flow

Use localhost:port to access Docker services from the host.
Use service names for inter-container communication inside Docker.
Use host.docker.internal for Docker-to-host communication (if supported).
Linux requires manual configuration for host.docker.internal.
Mapped ports are crucial for external access.
Ensure web applications generate URLs users can actually reach.

By keeping these rules in mind, you can avoid common networking pitfalls when using Docker Compose. Share this guide with your colleagues to clarify how Docker networking works and improve debugging efficiency!

Interactive Motion Extraction with JavaScript

Sun, 13 Oct 2024 19:15:00 +0000

Motion Extraction in Action: Real-time Video Processing with JavaScript

In this blog post, we’ll explore a motion extraction technique inspired by an approach presented in this YouTube video by Steve of CodeParade. Steve’s work showcases impressive concepts in image processing, and this implementation applies similar ideas using JavaScript to manipulate video frames in real time. You can interact with the code embedded below or visit the GitHub gist for the complete snippet.

How Motion Extraction Works

Motion extraction refers to isolating differences between frames in a video or stream. This technique can be useful in scenarios like surveillance, where detecting motion helps trigger specific events, or for analyzing movements in sports or other activities.

This example utilizes the following core steps:

Frame Capture: We take snapshots of a video feed (from the camera or an uploaded file).
Color Inversion: Each frame is inverted to enhance the contrast between motion and background.
Motion Detection: By comparing consecutive frames, we cancel out parts that remain static, highlighting only the regions that exhibit change (motion).
Display: The processed frame is displayed, and the effect is repeated in intervals to create continuous motion detection.

Users can adjust parameters like resolution and delay to experiment with the results.

Key Features of the Code

Live or Uploaded Video: You can toggle between your camera feed and an uploaded video file.
Freeze Frame: This feature freezes one frame so that you will see all motion changes in respect to the frozen frame.
Inverted Color Blending: The code uses color inversion and blending between consecutive frames to cancel out static areas, highlighting only moving objects.

Freeze Frame Example

Imagine you activate the freeze-frame option, and at that moment, a grey background is captured, like in the image below:

Now, when you remove an object from the scene—such as a highlighting pen—the motion extraction process will clearly detect what has changed. In the following image, you can see the pen, which was removed, now highlighted by the motion extraction algorithm:

This technique is highly effective in identifying what has been removed or changed in the scene by comparing the captured freeze-frame with subsequent frames.

Try it Out

Here is the live version of the code, which you can interact with to test motion extraction:

For those who want to dive deeper into the code, you can check out the GitHub Gist.

Personal Docker Cheat Sheet

Thu, 19 Sep 2024 13:35:00 +0000

This is a personal reference for Docker commands that are not used often but frequently need to be looked up. Instead of searching every time, this list provides direct access to those less common yet essential commands.

Remove All Stopped Containers

docker rm $(docker ps -a -q)

Explanation: This command removes all stopped containers.
docker ps -a -q: Lists the IDs of all containers (stopped and running).
docker rm: Removes the listed containers.

Remove All Docker Images Not In Use

docker rmi $(docker images -q)

Explanation: This command removes all Docker images.
docker images -q: Lists the IDs of all images.
docker rmi: Removes the listed images.

Check Docker Disk Usage

docker system df -v

Explanation: Shows detailed information about Docker disk usage, including volumes, images, containers, and how much space they occupy.

Remove All Unused Volumes Except Specified Ones

Test Command (preview volumes to be deleted):

docker volume ls -qf dangling=true | grep -vE 'volume1|volume2'

Actual Removal Command:

docker volume ls -qf dangling=true | grep -vE 'volume1|volume2' | xargs -r docker volume rm

Explanation: This command removes all unused (dangling) Docker volumes except the specified ones.
docker volume ls -qf dangling=true: Lists all unused volumes.
- -q: Shows only the volume names.
- -f dangling=true: Filters to list only the volumes that are dangling (unused).
grep -vE 'volume1|volume2': Filters out the volumes you want to keep (replace volume1, volume2, etc.).
xargs -r docker volume rm: Passes the remaining volume names to docker volume rm and removes them. The -r option ensures the command is only run if there are volumes to delete.

Zero Downtime Deployment with Docker Rollout

Fri, 13 Sep 2024 14:40:00 +0000

This guide demonstrates a Zero Downtime Deployment using Docker Rollout, featuring an intentional failure, rollback scenario, and a successful rollout. Additional I demonstrate the use of a Traefik reverse proxy to expose the service ports.

Prerequisites:

Ensure you have:

Docker and Docker Compose installed.
Docker Rollout installed:

# Create directory for Docker cli plugins
mkdir -p ~/.docker/cli-plugins

# Download docker-rollout script to Docker cli plugins directory
curl https://raw.githubusercontent.com/wowu/docker-rollout/master/docker-rollout -o ~/.docker/cli-plugins/docker-rollout

# Make the script executable
chmod +x ~/.docker/cli-plugins/docker-rollout

Directory Setup

Create the following files in your working directory:

Dockerfile-1 (working version):

# Use the official NGINX base image
FROM nginx:latest

# Create a custom text file with "Hello World V1"
RUN echo "Hello World V1" > /usr/share/nginx/html/index.html

# Expose port 80 (the default NGINX port)
EXPOSE 80

Dockerfile-2 (intentional failure):

# Use the official NGINX base image
FROM nginx:latest

# Create a custom text file with "Hello World V2"
RUN echo "Hello World V2" > /usr/share/nginx/html/index.html

# Expose port 8080 (causing health check failure due to mismatch)
EXPOSE 8080

Note: Version 2 exposes port 8080, which will cause the health check to fail initially as it is configured to check port 80.

docker-compose.yml:

services:
  web:
    image: static-site:1
    restart: always
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:80 || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 2
      start_period: 5s
    networks:
      - my_network

  test:
    image: alpine
    container_name: test
    command: sh -c "apk add --no-cache wget && tail -f /dev/null"
    networks:
      - my_network

networks:
  my_network:
    driver: bridge

Build Docker Images

Build version 1:

docker build -t static-site:1 -f Dockerfile-1 .

Build version 2 (the failing one):

docker build -t static-site:2 -f Dockerfile-2 .

Run the Initial Version

Start the services using Docker Compose:

docker-compose up -d

This will start version 1 (static-site:1) of the web service.

Test the Initial Deployment

Verify that version 1 is running by executing wget inside the test container:

docker exec -it test wget -qO- http://web

You should see:

Hello World V1

Update the Web Service Version for Rollout

Before running Docker Rollout, update the image of the web service to version 2 in your docker-compose.yml file:

web:
  image: static-site:2
  # rest of the configuration remains the same

Important: Updating the version in the docker-compose.yml file is necessary before executing the rollout command to initiate the update.

Perform Zero Downtime Deployment with Docker Rollout

Run Docker Rollout to perform the zero downtime deployment:

docker rollout web --file docker-compose.yml

Observations During Rollout:

No downtime for the web service: The web service remains fully operational during the update process.
One container becomes unhealthy: Since version 2 exposes a different port (8080), the new version’s container will fail the health check, causing the deployment to fail.
Automatic rollback: Docker Rollout will automatically roll back to version 1, ensuring the service remains healthy.

Update the Health Check for a Successful Rollout

To observe a successful rollout, update the health check in the docker-compose.yml file to match port 8080, which version 2 is using:

healthcheck:
  test: ["CMD-SHELL", "curl -f http://localhost:8080 || exit 1"]
  interval: 10s
  timeout: 5s
  retries: 2
  start_period: 5s

Update the docker-compose.yml file with the health check for port 8080.
Run the rollout again with:

docker rollout web --file docker-compose.yml

Observations During Successful Rollout:

The service will now update successfully from version 1 to version 2, as the health check matches the correct port.
You should now see the new version output by running:

docker exec -it test wget -qO- http://web

Output:

Hello World V2

Setting up Traefik Reverse Proxy for HTTP Access

You can use Traefik to expose your services externally without needing to define specific ports or container names in your Docker Compose file. This is especially useful when working with the Docker Rollout plugin, as it imposes limitations similar to Docker Swarm, where ports or container names cannot be explicitly defined. Traefik simplifies this by handling service discovery and routing dynamically, allowing you to maintain external accessibility while supporting zero downtime deployments.

By routing traffic based on service labels instead of container specifics, Traefik enables seamless updates and rollbacks without requiring manual changes to the container’s network settings.

docker-compose.yml with Traefik added:

version: '3'
services:
  web:
    image: static-site:1
    restart: always
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:80 || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 2
      start_period: 5s
    networks:
      - my_network
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.web.rule=PathPrefix(`/`)"
      - "traefik.http.services.web.loadbalancer.server.port=80"

  traefik:
    image: traefik:v2.4
    command:
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
    networks:
      - my_network

  test:
    image: alpine
    container_name: test
    command: sh -c "apk add --no-cache wget && tail -f /dev/null"
    networks:
      - my_network

networks:
  my_network:
    driver: bridge

Summary

The Docker Rollout plugin enables near zero downtime deployments by updating service instances one at a time, ensuring that previous versions remain active until the new ones pass health checks. While the plugin strives to eliminate downtime, there is still a small possibility of downtime during the transition, as noted in Issue #21, which is currently being worked on and may be resolved in the future.

Additionally, using the restart: always policy is discouraged in favor of restart: unless-stopped, as outlined in Issue #25. This prevents conflicts with Docker Rollout’s management of container lifecycles during updates.

Key features of Docker Rollout:

Sequential updates: New instances are spun up one at a time, with health checks ensuring each instance is functioning properly before proceeding.
Health check validation: Only instances that pass their health checks are considered live, reducing the risk of introducing faulty versions.
Automatic rollback: In the event of a failure, Docker Rollout triggers a rollback to the last known good version, maintaining service stability.
Zero downtime goal: Though there may be brief downtimes in specific scenarios, Docker Rollout aims to keep services uninterrupted.
Flexible configuration: It supports custom timeouts, wait times, and health check parameters for diverse deployment needs.

Securely Expose Local Ports with Tailscale Funnel

Tue, 03 Sep 2024 15:35:00 +0000

When developing applications that need to interact with external services such as OAuth providers or webhooks, it’s often necessary to expose your local environment to the internet. Tailscale Funnel provides a quick, secure, and hassle-free method to do this, allowing any port on your local machine to be accessible over the internet with minimal configuration. This guide will walk you through setting up Tailscale Funnel to expose your application’s port, making it ideal for developers who need a temporary public endpoint for testing.

What is Tailscale Funnel?

Tailscale Funnel allows you to expose a local service running on your machine to the internet via HTTPS, leveraging Tailscale’s secure VPN. This feature is especially useful for scenarios where you need a public endpoint, such as testing OAuth callbacks, receiving webhooks, or sharing a development environment temporarily.

Key Benefits of Tailscale Funnel

Quick Setup: The process is straightforward and quick, making it perfect for rapid testing and debugging.
Secure and Easily Disabled: Public access can be enabled or disabled with a single command, ensuring your local environment remains secure when not in use.
Automatic HTTPS and MagicDNS: Tailscale handles HTTPS provisioning and DNS management, simplifying the setup.

Prerequisites

To use Tailscale Funnel, you need the following:

Tailscale account: Sign up at Tailscale.
Tailscale client: Installed and running on your development machine.
An application running locally: Your application should be running on a specific port (e.g., localhost:5000).

Step-by-Step Guide to Set Up Tailscale Funnel

1. Install and Configure Tailscale

Make sure Tailscale is installed and configured on your machine:

Download and install the Tailscale client from Tailscale Downloads.
Log in to your Tailscale account using the Tailscale client.
Authorize your device in the Tailscale admin console.

2. Provision a Certificate for Your Device

To ensure your service is accessible over HTTPS, you need to provision a certificate for your device using Tailscale:

Open the DNS page in the Tailscale admin console.
Enable MagicDNS if it is not already enabled for your tailnet.
Under HTTPS Certificates, select Enable HTTPS.
To obtain a certificate on your machine run the following command in the terminal:

tailscale cert

This step is crucial as it enables secure connections to your public endpoint through HTTPS.

3. Configure Access Controls

To enable Funnel, you need to adjust your Tailscale network’s access control list (ACL) settings:

Open the Tailscale admin console and go to Access Controls.
Modify your ACL configuration to include the Funnel attribute:

{
  "nodeAttrs": [
    // Adds the "funnel" attribute to all devices in your network
    { "target": ["autogroup:member"], "attr": ["funnel"] }
  ],
  "acls": [
    // Allow all connections.
    { "action": "accept", "src": ["*"], "dst": ["*:*"] },
  ]
}

4. Enable Tailscale Funnel for Your Application

Now, enable Funnel to expose your application:

tailscale funnel <port>

This command will make your application accessible via a public URL over HTTPS.

4. Obtain and Test Your Public URL

Once Funnel is enabled, Tailscale generates a public URL for your service. It will be in the format:

https://<device-name>.ts.net:<port>

For instance, if your device name is my-laptop and your application is running on port 5000, the URL will be:

https://my-laptop.ts.net:5000

7. Use the URL for External Integrations

With your application now accessible online, you can:

Test OAuth callbacks: Configure your OAuth provider’s redirect URI to your Tailscale Funnel URL (e.g., https://my-laptop.ts.net:5000/callback).
Receive webhooks: Set the Funnel URL as the endpoint for services needing to send data to your application.
Collaborate easily: Share your development environment securely for team testing or demonstrations.

8. Disable Funnel When Done

After testing, you can easily disable Funnel to secure your environment:

Open your terminal or command prompt.
Run the command to disable Funnel:

tailscale funnel disable <port>

In addition to exposing your local development environment, Tailscale Funnel can be used to share files quickly over the internet. This is particularly useful when you need to send files directly from your device without using an external file-sharing service. Here’s how to use Funnel for file sharing:

tailscale funnel /tmp/public

This command will activate file sharing mode, and Tailscale will automatically generate a public URL for you.

UXG-Lite router and Vigor-167 modem configuration

Wed, 10 Jan 2024 20:10:00 +0000

I’m using the UniFi UXG-Lite as a router in my home network. It connects to my DrayTek Vigor 167 modem (previously Vigor 130). In this post I publish the settings to configure the two devices and describe how you can reach the modem once the setup is running.

Modem configuration

My configuration is Telekom specific. Especially the VDSL2 Tag 7 can be different depending on the provider. I configured it on the modem, but it can also be configured on the router. It does not make a difference. The Modem has a static IPv4 assigned: 192.168.0.1

MPoA Settings

PPPoE Settings

IPv6 Settings

WAN Settings

Physical Connection Overview

Router Configuration

The internet configuration on the router is a no brainer. Open the Internet settings and if you haven’t configured the VLAN ID on the modem you have to select it in the router. In the IPv4 configuration section you have to select PPPoE and input username and password that was provided by your ISP (Telekom).

Telekom username

The construction of the username is very cumbersome. Below is the format you have to generate:

Anschlusskennung: 111111111111
Teilnehmernummer: 222222222222 (12 digits) or 33333333333 (11 digits)
Mitbenutzerkennung: 0001

Teilnehmernummer with 12 digits example: [email protected]
Teilnehmernummer with 11 digits example: 11111111111133333333333#[email protected]
                                         11111111111133333333333\#[email protected]

Connecting to the Modem

Once everything is configured and in place the modem is not reachable anymore. On a UXG Gateway you can create the following configuration to make it work:

{
    "interfaces": {
        "pseudo-ethernet": {
            "peth0": {
                "address": ["192.168.0.2/24"],
                "description": "Access to Modem",
                "link": ["eth1"]
            }
        }
    },
    "service": {
        "nat": {
            "rule": {
                "5000": {
                    "description": "MASQ Modem access",
                    "destination": {
                        "address": ["192.168.0.1"]
                    },
                    "outbound-interface": ["peth0"],
                    "type": "masquerade"
                }
            }
        }
    }
}

However, the UXG-Lite does not have the option to configure it permanently. What you can do instead is to login to the UXG-Lite via SSH and add the routing for eth1 manually:

# Assign a Static IP to eth1
sudo ip addr add 192.168.0.2/24 dev eth1

# Bring the Interface Up
sudo ip link set eth1 up

# Add a static route
sudo ip route add 192.168.0.0/24 dev eth1

After that you can create a SSH tunnel to your UXG-Lite and setup a SOCKS5 proxy in your browser in order to reach the Modem.

Putty tunnel

Firefox SOCKS5 proxy

Revert the changes to the routes

This is not strictly necessary. After a reboot of the device the settings are lost. I also noticed that any modification to the WAN settings on the UXG-Lite will remove the route. However, if you like to manually remove it after you are done you can execute the following command:

sudo ip route del 192.168.0.0/24

Tiny Cube Satellite

Fri, 17 Jun 2022 12:10:00 +0000

A couple of months ago I found this tiny cube satellite build on the internet and was intrigued. So I started to source materials to build my own.

The only thing I wanted to do differently was to add a mountain base to it. I found a open source model of Monte Civetta and sliced it to fit my base.

Sadly I don’t have the source anymore. I remember it was quiet tricky to find. And the model was huge meaning that I had to reduce the mesh significantly before I even could start to modify it.

My printer required 9h to print the hollow(!) mountain in ABS after which I vapor smoothed it to get a really nice finish.

I bought a glass dome with a white wooden base and used some hard wax oil to make the base grey. The part of the base that will be covered by the mountain I plated with some aluminium foil to increase the reflection of the surface. The goal was to illuminate the mountain by the satellite once in a while.

Electronics and source code

I spent most time developing the code for the ATtiny85. The final breadboard design is in the picture below. The real breadboard looked way messier since I also attached my ISP and serial reader to it.

Breadboard

The bottom plus line of the breadboard is connected by a Schottky diode with the plus line on the top.

I flashed my Attiny85 with a clock speed of 1 MHz. I also experimented with lower clock speeds but ended up soft bricking one of my ATtiny85.

My next project will be to rescue the bricked ATtiny85 microcontroller by resetting the fuses. Below 1 MHz seams interesting but I think it will be too messy since the sleep does not work correctly anymore and you have to implement your won sleep. That also means that the code for the LED duration needs to be modified.

That said I am quite pleased with the 1 MHz clock speed since the microcontroller seams to always have enough battery left to light up. The code I ended up using on my ATtiny85 is hosted as a Gist on GitHub called CubeSat.ino. Feel free to comment on the code. I am by no means an expert in Arduino - I usually work with .NET.

The microcontroller uses the solar cells voltage to detect if it is day or night time. If it is night, it will run the glow effect once every ~10 minutes as long as the total voltage of the system does not go below a threshold that would prevent the LED from light up.

The glow effect can be seen in the following video. Please keep in mind that it had to be dark in order to trigger the effect. That means the video is a little bit noisy.

Soldering

I am usually not bad with soldering and know how to get a good joint. But the scale on the cube sat is tiny and I haven’t found any good clamp system that was not fiddley.

Most parts are floating in midair when you solder them or, in case of the cube, require you to solder 3 parts at once in a perfect angle.

My cube has a diameter of 15 mm and I use .8 mm round brass rods. I started by bending most of the edges of the cube out of one rod but I did not like the curved edges. That’s why I had to solder 3 legs at a time.

Long story short for a perfectionist the soldering part is a nightmare. And I am reluctant to post close-ups. If anyone has a good setup to solder a perfect cube - I’m looking at you Mohit Bhoite - then by all means enlighten me!

Bill of Materials (BOM)

Make sure you buy the ATtiny85 10PU version. Only that one can operate on very low voltage (starting at 1.8 Volt).

Electronics

SM141K04LV-ND MONOCRYST SOLAR CELL 123MW 2.76V
2085-TPLC-3R8/10MR8X14-ND 10F 3.8V T/H
ATTINY85V-10PU
SMD LED DIODES 3528 1210 WHITE
1N4148 DO-35 IN4148 AXIAL LEAD SWITCHING SIGNAL DIODE
100KΩ AND 10KΩ RESISTOR
.8 MM ROUND BRASS RODS

Base

2MM ACRYLIC ROD
ONE WAY MIRROR WINDOW PRIVACY FILM BLUE
GLASS DOME WITH WODDEN BASE 20CM
LIGNOCOLOR HARD WAX OIL ANTHRACITE GREY

Pictures

Cube Satellite Diorama

Satellite top view

Satellite close-up

Satellite close-up glowing in the dark

Satellite glow in the dark

Additional references

Server setup for the Amazon Container Registry (ECR)

Thu, 09 Sep 2021 12:51:00 +0000

We recently moved our docker images to the Amazon Container Registry (ECR). To access ECR in docker you need to install and configure the amazon-ecr-credential-helper. This post contains a short writeup on the necessary steps.

Installation

$ apt update
$ apt install amazon-ecr-credential-helper

Configuration

Set the AWS credentials:

$ mkdir ~/.aws
$ nano ~/.aws/credentials

[default]
aws_access_key_id=ABCDEFGABCDEFG
aws_secret_access_key=abcdefgabcdefgabcdefgabcdefg

Set the AWS default options (yours might be different):

$ nano ~/.aws/config

[default]
region=eu-north-1
output=json

Update the docker configuration (replace 1234567890 with your registry id):

$ nano ~/.docker/config.json

{
  "credHelpers": {
    "1234567890.dkr.ecr.eu-north-1.amazonaws.com": "ecr-login"
  },
  "credsStore": "ecr-login"
}

Jens Willmer

Gear Ratio Advanced: Velocity, Torque & Efficiency

🔄 Gear Ratio and Velocity

💪 Gear Ratio and Torque

⚠️ Direction Reminder

⚙️ Gear Efficiency

✅ Summary

What is Retrieval-Augmented Generation (RAG)

When to Use RAG

Preparing Data for Ingestion

Improving Retrieval with Context

Conclusion: Why RAG Matters

Docker Networking Pitfalls

The Basics: Host vs. Docker Network

Host Perspective (External Access)

Docker Container Perspective (Internal Communication)

Common Pitfalls and How to Solve Them

Pitfall 1: Trying to Access a Container Using Service Names from the Host

❌ Incorrect:

✅ Correct:

Pitfall 2: Using localhost Inside a Container to Reach Another Container

❌ Incorrect:

✅ Correct:

Pitfall 3: A Container Trying to Access a Host Service Without host.docker.internal

❌ Incorrect:

✅ Correct:

Pitfall 4: Web Applications Generating Incorrect URLs

❌ Incorrect:

✅ Correct:

Understanding host.docker.internal Availability

Visualizing the Networking Model

Key Takeaways

Interactive Motion Extraction with JavaScript

Motion Extraction in Action: Real-time Video Processing with JavaScript

How Motion Extraction Works

Key Features of the Code

Freeze Frame Example

Try it Out

Personal Docker Cheat Sheet

Remove All Stopped Containers

Remove All Docker Images Not In Use

Check Docker Disk Usage

Remove All Unused Volumes Except Specified Ones

Zero Downtime Deployment with Docker Rollout

Prerequisites:

Directory Setup

Build Docker Images

Run the Initial Version

Test the Initial Deployment

Update the Web Service Version for Rollout

Perform Zero Downtime Deployment with Docker Rollout

Observations During Rollout:

Update the Health Check for a Successful Rollout

Observations During Successful Rollout:

Setting up Traefik Reverse Proxy for HTTP Access

Summary

Securely Expose Local Ports with Tailscale Funnel

What is Tailscale Funnel?

Key Benefits of Tailscale Funnel

Prerequisites

Step-by-Step Guide to Set Up Tailscale Funnel

1. Install and Configure Tailscale

2. Provision a Certificate for Your Device

3. Configure Access Controls

4. Enable Tailscale Funnel for Your Application

4. Obtain and Test Your Public URL

7. Use the URL for External Integrations

8. Disable Funnel When Done

Nice to Know: Using Tailscale Funnel to Share Files

UXG-Lite router and Vigor-167 modem configuration

Modem configuration

Router Configuration

Telekom username

Connecting to the Modem

Revert the changes to the routes

Tiny Cube Satellite

Electronics and source code

Soldering

Bill of Materials (BOM)

Electronics

Pitfall 2: Using `localhost` Inside a Container to Reach Another Container

Pitfall 3: A Container Trying to Access a Host Service Without `host.docker.internal`

Understanding `host.docker.internal` Availability