Should I walk or run through rain to get less wet?

Answer

In still air, run. When it’s windy, move with the rain, not against it.

Over the same route in steady vertical rain, running does not increase the total amount striking your front. Running reduces the time available for rain to land on your head and shoulders.

Illustration conditions: the same route, the same posture, uniform steady rain falling vertically, and no wind. Run only when the surface, visibility, traffic, weather, and your physical condition make running safe.

Figure 1. In steady vertical rain with no wind, walking and running over the same route cross the same volume of rainy air at the front. Running shortens the time in the rain, so less rain lands on the head and shoulders. In wind, move with the rain’s sideways drift rather than against it.

Why running helps in still air

Rain hitting your front

Walking and running over the same route carry the front of your body through the same volume of rainy air. Running encounters that rain faster but completes the route in less time. The fixed-route total remains the same.

Rain falling from above

Rain continues falling on your head and shoulders for as long as you remain outside. Running shortens that exposure time, so less rain can land from above.

What changes when there is wind?

Wind changes the answer. A headwind adds rain at your front. A tailwind reduces front wetting and can shift the rain impact to your back when the rain’s sideways drift is faster than you. When your route allows, move in the same direction as the rain’s sideways drift rather than against it. Matching the rain’s sideways speed and direction removes the front-or-back contribution along your route. Running rather than walking shortens your time in the rain, so less rain lands from above.

In still air, run. When it’s windy, move with the rain, not against it.

Important limit: Real rain contains drops of different sizes, and gusts continually change their sideways motion. “Move with the rain” is therefore a practical direction rule—not one precise speed that can match every drop.

What else affects how wet you get?

This explanation counts direct rain striking your body. It does not predict exactly how much water clothing, hair, or shoes retain. Actual wetness also depends on posture, clothing absorption, runoff, evaporation, puddle splash, changing rainfall, turbulence, and nearby buildings or trees.

Safety comes first. Walk when wet pavement, poor visibility, traffic, lightning, ice, stairs, uneven ground, or your physical condition make running unsafe.

Bottom line: In still air, running reduces the rain from above without increasing the fixed-route amount striking your front. In wind, move with the rain rather than against it.

Conflict disclosure: Jan Barani is affiliated with BARANI DESIGN Technologies, a manufacturer of meteorological instruments. This person-wetting explanation is manufacturer-neutral and contains no product-performance claim.

BARANI Open Sourced Kafka Streaming Manifests for IoT Data Infrastructure

BARANI meteo innovations open sourced kafka data streaming architecture

At BARANI, accurate environmental measurement does not stop at the sensor. Our weather stations and meteorological sensors generate data that must move reliably from the field into systems where it can be stored, transformed, analyzed, and acted on. That requires more than hardware. It requires dependable data infrastructure.  

Today, we are open sourcing part of that infrastructure: our Kafka Platform Manifests repository.

The repository contains Kubernetes manifests for a Kafka-centered streaming platform built around Strimzi and related services. It is designed as a single, structured open-source repository with component directories for Kafka, Schema Registry, ksqlDB, Kafka Bridge, Debezium Connect, and Camel Connect.  

This is not a release of our business-specific stream-processing logic. Instead, it shares the deployment patterns, component wiring, and infrastructure manifests that can help teams build and operate similar streaming data platforms. The repository defines Kafka topics, ingestion paths, supporting services, and example CDC and webhook ingestion components, while keeping production application logic outside the public repository.  

Why we are sharing this

IoT and environmental monitoring systems generate continuous streams of data. For us, this means handling telemetry, webhook payloads, device-related events, database changes, and downstream processing stages in a way that is repeatable and maintainable.

But this challenge is not unique to BARANI. Nonprofits, NGOs, environmental protection organizations, research teams, citizen-science projects, municipalities, smart city teams, and resilient city initiatives often face the same need: they collect valuable environmental data from sensors, field devices, databases, and partner systems, but need reliable infrastructure to move that data where it can be analyzed and acted on.

Kafka is well suited for this kind of architecture because it gives teams a durable event backbone. Kubernetes gives us a practical way to deploy, version, and reason about that infrastructure as manifests. Strimzi then provides the Kubernetes-native operator layer for Kafka.

By publishing these manifests, we want to make our approach easier to inspect, adapt, and improve. More importantly, we want to give mission-driven teams a realistic starting point for building Kafka-based ingestion and streaming systems on Kubernetes.

Our hope is that this work can support organizations focused on climate resilience, environmental monitoring, conservation, disaster preparedness, sustainable agriculture, air-quality monitoring, water-resource management, smart city infrastructure, resilient city planning, and other projects that help protect our planet and strengthen communities.

Reliable environmental decisions depend on reliable environmental data. So do smarter, more resilient cities. By sharing part of our infrastructure openly, we want to help more teams spend less time rebuilding the same platform foundations and more time using data to understand, protect, and restore the natural world while building communities that are better prepared for the future.

What is included

The repository is organized into component directories, each with its own README and deployment guidance.  

Kafka core

The kafka/ directory includes raw Kubernetes manifests for a Strimzi-managed Apache Kafka cluster running in KRaft mode, plus an optional Kafka UI deployment. It includes manifests for the Kafka node pool, Kafka custom resource, Kafka user, Kafka rebalance resource, and Kafka UI.  

Schema Registry

The schema-registry/ directory contains manifests for deploying Confluent Schema Registry alongside the Kafka cluster. It includes deployment configuration, an in-cluster service on port 8081, and optional ingress with TLS and basic authentication.  

ksqlDB

The ksqldb/ directory contains manifests for a ksqlDB server, helper CLI pod, persistent volume claim, service, and optional ingress. This provides a foundation for querying and working with streams once data is flowing through Kafka.  

Kafka Bridge

The kafka-bridge/ directory includes manifests for deploying Strimzi Kafka Bridge, allowing HTTP-based access patterns where they are useful. The included manifests define the Kafka Bridge custom resource and optional ingress with TLS and basic authentication.  

Debezium Connect

The debezium-connect/ directory contains manifests for a Strimzi Kafka Connect cluster with the Debezium PostgreSQL connector, example topic definitions, an example PostgreSQL source connector, and least-privilege RBAC for reading database credentials from a Kubernetes Secret.  

Camel Connect

The camel-connect/ directory contains manifests for a Strimzi Kafka Connect cluster using the Camel Netty HTTP connector to receive webhook requests and publish them to Kafka topics. It includes connector resources, topics, services, ingress, network policy, an optional webhook logger, and a PlantUML topology source.  

How the pieces fit together

The baseline deployment order starts with Kafka, then optional platform services such as Schema Registry, ksqlDB, and Kafka Bridge, followed by integration components such as Debezium Connect and Camel Connect.  

That structure reflects a practical streaming architecture:

First, the Kafka cluster provides the event backbone.

Next, services such as Schema Registry and ksqlDB support schema management, stream inspection, and query workflows.

Finally, ingestion components bring data into Kafka from external systems. Debezium Connect is used for PostgreSQL change data capture examples, while Camel Connect is used for webhook ingestion examples.  

What you should customize before using it

These manifests are intended as a reusable starting point, not a one-command production deployment. The root README documents shared assumptions such as the kafka namespace, the kafka-kraft cluster name, the Kafka bootstrap service, SCRAM Secret name, placeholder ingress hosts under example.com, and node labels that satisfy affinity rules.  

Before applying the manifests in your own environment, review and replace ingress hostnames, image registry placeholders, Secret names and contents, storage classes and storage sizes, node labels and affinity rules, replication factors, and sizing defaults.  

Security-sensitive values are intentionally not committed. The repository is designed to avoid live secrets, and referenced secrets must be created separately in your Kubernetes cluster. Some manifests use SASL_PLAINTEXT as an internal example, with guidance to switch to TLS or SASL_SSL when encryption in transit is required.  

Why this matters for IoT and environmental data

Reliable meteorological and IoT systems are built from multiple layers. Sensors must measure accurately. Connectivity must be dependable. Data pipelines must preserve events, handle scale, and support downstream analysis.

Open sourcing this repository gives developers, integrators, and infrastructure teams a clearer look at one way to build the data-streaming layer behind such systems. It also helps separate reusable infrastructure from proprietary product and domain logic.

That separation matters. The repository provides platform manifests, example wiring, validation commands, deployment order, and component-specific documentation. It does not expose the full production logic that transforms raw events into final domain outputs.  

License and contributions

The repository is released under the MIT License, with copyright attributed to BARANI DESIGN Technologies.  

We welcome careful review and useful contributions. The contributing guidance asks contributors to keep changes focused on manifests, examples, validation, and documentation; avoid committing secrets, internal hostnames, internal IPs, or private registry references; and validate changed YAML files before submitting.

Security-sensitive reports should not be opened as public issues. The security policy asks reporters to use private vulnerability reporting, a private security advisory, or another private maintainer channel before disclosing details publicly.  

Explore the repository

You can find the open-source Kafka streaming manifests on GitHub. Review the README, inspect the component directories, adapt the placeholders for your environment, and use the manifests as a starting point for your own Kafka-based IoT or streaming data platform.

Transparency Starts at the Sensor

Fix the instruments. Fix the forecast. Restore trust in climate warnings.

At MeteoExpo 2025 in Vienna, Jan Barani presented one of the most talked-about sessions at the Technology & Innovation Theatre — challenging the very foundations of today’s hydrometeorological measurement industry.

Our presentation, “Transparency Starts at the Sensor,” asks a simple but uncomfortable question:

How can we expect the world to trust our forecasts and climate warnings if the instruments we use to collect the data can’t be trusted themselves?

For too long, our industry has hidden behind laboratory certificates and “WMO-certified” marketing claims, while the quality of field measurements has quietly eroded.
From 3 °C temperature errors in official records to low-sampling ultrasonic anemometers that miss entire wind gusts, the credibility gap between data sheets and real-world truth is widening fastMET25_Technology & Innovation T…MET25_Technology & Innovation T….

Fix the Instruments, Not Just the Models

The presentation exposed how:

• “All-in-one” weather sensors combine incompatible measurements that disturb the very air they’re trying to measureMET25_Technology & Innovation T….

• Fan-aspirated radiation shields (FARS) distort measurement height and introduce thermal noise instead of removing itMET25_Technology & Innovation T….

• Low-power ultrasonics with 1 Hz or slower sampling rates can’t capture a 3-second gust and yet are still accepted in automatic weather stationsMET25_Technology & Innovation T….

• WMO’s own time-constant guidelines omit wind-speed context entirely, making the term meaningless in practical meteorologyMET25_Technology & Innovation T….

Rebuilding Credibility

If we want people to trust early warnings again, we must start with transparent instrumentation and open intercomparison testing.
The talk proposes a simple path forward:

• Proposal to implement Continuous WMO intercomparisons open to all manufacturers, funded by HMEI fees— not invite-only.

• Proposal to implement a wind-invariant constant and dimensionless response index to make temperature-sensor performance directly comparable across airspeeds.

• A call for “WMO certification through transparency”, where every sensor is verified in field conditions, not just in a chamber of a calibration laboratory.

Download the Full Presentation

The full slide deck — complete with illustrations, caricatures, and technical appendices — is available here:
👉 Download the PDF Presentation

About the Author

Jan Barani, founder and CEO of BARANI DESIGN Technologies, has spent over two decades challenging conventional thinking in meteorological instrumentation. His innovations — from the MeteoShield Pro to the MeteoHelix IoT Pro — have redefined field measurement accuracy across the globe.

At MeteoExpo 2025, his message was clear:

“Forecasts graded by the public on outcomes, not on calibration certificates, deserve better inputs. Let’s fix the instruments first.”

BARANI DESIGN Technologies is a manufacturer of professional weather stations