DEV Community: tutorial

What Should Golf Cart Fleet Management Software Track? A Python Data Model for Carts, Rides and Alerts

Tejal Laxkar — Thu, 12 Nov 2026 09:58:45 +0000

Golf cart fleet management software should track five things: carts, rides, battery readings, zones and alerts. A cart has many rides and many battery readings. A ride is a series of GPS fixes. Zones are checked against each fix, and anything worth a human's attention becomes an alert tied back to a cart.

The rest of this post builds that model in plain Python 3.11, standard library only. Paste the three code blocks into one file in order and it runs as-is.

What entities does golf cart fleet management software need?

Entity	Key fields	Why it matters
Cart	id, vehicle_class, pack_voltage, locked	Everything else hangs off the cart id
Fix	lat, lon, timestamp, speed_mph	The raw GPS reading behind every rule
Ride	cart_id, rider_id, start, end	Tells you who had the cart when something happened
BatteryReading	cart_id, soc_pct, timestamp	Feeds the health score and charging decisions
Zone	name, center, radius_m, kind	Greens, ponds and the property edge, as circles
Alert	kind, cart_id, message, at	The one list a manager actually reads

Why is vehicle_class a field and not a label?

Because the class changes which rules apply. Under the US federal standard, a low-speed vehicle (LSV) is a 4-wheeled motor vehicle whose top speed is greater than 20 mph but not greater than 25 mph (Federal Register, 17 June 1998). A cart that tops out at 20 mph or below falls outside that definition.

A mixed fleet therefore has two expected speed ceilings. If the class is stored on the cart, a speed check is a dictionary lookup.

How do you model carts, fixes, rides and zones in Python?

Dataclasses are enough. Fixes and zones are frozen because a reading should never change after it is recorded.

from dataclasses import dataclass
from datetime import datetime, timedelta
from enum import Enum
from math import asin, cos, radians, sin, sqrt


class VehicleClass(Enum):
    GOLF_CART = "golf_cart"
    LSV = "lsv"


SPEED_LIMIT_MPH = {VehicleClass.GOLF_CART: 20.0, VehicleClass.LSV: 25.0}
EARTH_RADIUS_M = 6_371_000
THEFT_DISTANCE_M = 30.0


@dataclass
class Cart:
    id: str
    vehicle_class: VehicleClass
    pack_voltage: int = 48
    locked: bool = False


@dataclass(frozen=True)
class Fix:
    lat: float
    lon: float
    timestamp: datetime
    speed_mph: float


@dataclass
class Ride:
    cart_id: str
    rider_id: str
    start: datetime
    end: datetime | None = None


@dataclass(frozen=True)
class BatteryReading:
    cart_id: str
    soc_pct: int
    timestamp: datetime


@dataclass(frozen=True)
class Zone:
    name: str
    lat: float
    lon: float
    radius_m: float
    kind: str  # "no_go" (greens, ponds) or "boundary" (property edge)


@dataclass
class Alert:
    kind: str
    cart_id: str
    message: str
    at: datetime

How should zone, theft, speed and health rules work?

Each rule is a small function that reads data and appends to the alert list. None of them sends a command to a vehicle.

That matters most for zones. check_zones records the breach and returns a warning message for the rider. It never slows or stops the cart. Cutting power to a moving vehicle because of one GPS reading is a safety decision, and it does not belong in a geometry helper.

The speed check follows the same idea. A golf cart reporting 23.5 mph is more likely a wrong class, a modified cart or a noisy reading than something to enforce, so it is raised as a data-quality or setup flag.

def haversine_m(lat1: float, lon1: float, lat2: float, lon2: float) -> float:
    """Great-circle distance between two points, in meters."""
    dlat, dlon = radians(lat2 - lat1), radians(lon2 - lon1)
    a = sin(dlat / 2) ** 2 + cos(radians(lat1)) * cos(radians(lat2)) * sin(dlon / 2) ** 2
    return 2 * EARTH_RADIUS_M * asin(sqrt(a))


def check_zones(ride: Ride, fix: Fix, zones: list[Zone], alerts: list[Alert]) -> list[str]:
    """Record zone breaches and return warning messages for the rider."""
    # Warn and record only. This function must never slow or stop a cart.
    warnings: list[str] = []
    for zone in zones:
        dist = haversine_m(fix.lat, fix.lon, zone.lat, zone.lon)
        inside = dist <= zone.radius_m
        breached = inside if zone.kind == "no_go" else not inside
        if not breached:
            continue
        detail = f"rider {ride.rider_id}, {zone.name} ({zone.kind}), {dist:.1f} m from center"
        alerts.append(Alert("zone_breach", ride.cart_id, detail, fix.timestamp))
        verb = "leave" if zone.kind == "no_go" else "return inside"
        warnings.append(f"Please {verb} {zone.name}")
    return warnings


def check_locked_move(cart: Cart, prev: Fix, curr: Fix, alerts: list[Alert]) -> None:
    """Alert when a locked cart moves more than 30 m between two fixes."""
    moved = haversine_m(prev.lat, prev.lon, curr.lat, curr.lon)
    if cart.locked and moved > THEFT_DISTANCE_M:
        detail = f"moved {moved:.1f} m while locked"
        alerts.append(Alert("locked_cart_moved", cart.id, detail, curr.timestamp))


def check_speed(cart: Cart, fix: Fix, alerts: list[Alert]) -> None:
    """Flag a speed above the class limit. A data or setup flag, not enforcement."""
    limit = SPEED_LIMIT_MPH[cart.vehicle_class]
    if fix.speed_mph > limit:
        detail = f"{fix.speed_mph} mph reported, class limit is {limit:.0f} mph ({cart.vehicle_class.value})"
        alerts.append(Alert("speed_over_class_limit", cart.id, detail, fix.timestamp))


def health_score(soc_pct: int, days_since_service: int, fault_codes: int) -> int:
    """Score 0-100: up to 50 for charge, 30 for recent service, 20 for no faults."""
    charge = min(max(soc_pct, 0), 100) // 2
    service = max(0, 30 - days_since_service // 6)
    faults = max(0, 20 - 10 * fault_codes)
    return charge + service + faults


def work_order_if_needed(cart: Cart, score: int, threshold: int = 50) -> dict | None:
    """Turn a low score into a work order for a person to review."""
    if score >= threshold:
        return None
    return {"cart_id": cart.id, "reason": f"health score {score} is below {threshold}", "status": "open"}

The 30 m theft threshold sits above normal GPS drift for a parked cart. The health weights are a starting point, so tune them against your own service history.

What does it print on sample data?

The sample points share one longitude, so every distance is a straight north-south line and easy to check by hand: 0.0001 degrees of latitude is about 11.1 m.

t0 = datetime(2026, 5, 1, 10, 0, 0)
zones = [
    Zone("Green 7", 33.0010, -112.0, 30, "no_go"),
    Zone("Course boundary", 33.0000, -112.0, 500, "boundary"),
]
alerts: list[Alert] = []

c1 = Cart("C-01", VehicleClass.GOLF_CART)
ride = Ride("C-01", "R-1001", start=t0)
fixes = [
    Fix(33.0000, -112.0, t0, 8.0),
    Fix(33.0009, -112.0, t0 + timedelta(seconds=30), 9.0),
    Fix(33.0020, -112.0, t0 + timedelta(seconds=60), 23.5),
]
for fix in fixes:
    for warning in check_zones(ride, fix, zones, alerts):
        print(f"Rider warning: {warning}")
    check_speed(c1, fix, alerts)
ride.end = fixes[-1].timestamp
minutes = (ride.end - ride.start).total_seconds() / 60
print(f"Ride on {ride.cart_id} by {ride.rider_id}: {minutes:.1f} min, {len(fixes)} fixes")

c2 = Cart("C-02", VehicleClass.LSV, locked=True)
parked = Fix(33.0000, -112.0, t0, 0.0)
later = Fix(33.0005, -112.0, t0 + timedelta(seconds=60), 4.0)
check_locked_move(c2, parked, later, alerts)

for a in alerts:
    print(f"[{a.at:%H:%M:%S}] {a.kind} {a.cart_id}: {a.message}")

readings = [BatteryReading("C-01", 82, t0), BatteryReading("C-02", 38, t0)]
history = {"C-01": (30, 0), "C-02": (150, 2)}  # days since service, fault codes
for cart, reading in zip([c1, c2], readings):
    days, fault_count = history[cart.id]
    score = health_score(reading.soc_pct, days, fault_count)
    print(f"{cart.id} health: {score}", work_order_if_needed(cart, score))

Expected output:

Rider warning: Please leave Green 7
Ride on C-01 by R-1001: 1.0 min, 3 fixes
[10:00:30] zone_breach C-01: rider R-1001, Green 7 (no_go), 11.1 m from center
[10:01:00] speed_over_class_limit C-01: 23.5 mph reported, class limit is 20 mph (golf_cart)
[10:01:00] locked_cart_moved C-02: moved 55.6 m while locked
C-01 health: 86 None
C-02 health: 24 {'cart_id': 'C-02', 'reason': 'health score 24 is below 50', 'status': 'open'}

C-01 scores 41 + 25 + 20 = 86. C-02 scores 19 + 5 + 0 = 24, which is under 50, so it gets a work order.

What should you check before you build or buy?

Before you build or buy: 6 checks

Is vehicle class stored per cart, so golf carts and LSVs get different rules?
Is every fix kept with its timestamp and tied to a ride and a rider?
Do zones only warn riders and record breaches, with no automatic slowing or stopping?
Does the theft rule ignore normal GPS drift on a parked cart?
Can you see how the health score is calculated, and does a low score become a work order a person reviews?
Are odd readings, such as a speed above the class limit, shown as flags to investigate?

Where can you see this in a running product?

Axons Mobility is golf cart and LSV fleet management software, based in Dubai, UAE, for cart makers, dealers and fleet operators. If you want to see how these pieces look in a running product, the golf cart fleet use cases page walks through eight of them.

Run the script against a day of your own fixes first, then read that page with your results next to it.

My build check had a tolerance of zero, so it failed on a correct number

Muzammil Hussain — Thu, 12 Nov 2026 09:58:12 +0000

I generate state minimum wage pages from a small set of constants plus a calculator engine. Before a page is written, a build check compares what the engine computes with a number I worked out by hand. If they disagree, the build stops and nothing is deployed. The point is that a wrong figure never reaches a live page.

The check is one function:

export function mustBe(label, actual, expected, eps = 0.005) {
  if (!(Math.abs(actual - expected) < eps)) {
    throw new Error(`BUILD CHECK FAILED: ${label}: calculator gave ${actual}, hand-check says ${expected}`);
  }
}

Today it failed twice, and neither time was the calculator wrong.

Failure one: a tolerance of zero

For Oklahoma I wanted to assert that the rate has not changed in a given number of years. I passed an expected value of 0 and a tolerance of 0, meaning "exactly zero".

mustBe('years since 2000', yearsUnchanged, 0, 0);

It threw. The comparison is Math.abs(actual - expected) < eps, which is strict. With eps = 0 that reads 0 < 0, which is false, so a perfectly equal pair can never pass. A tolerance of zero is not "exact". It is "always fail".

The fix was to ask for what I meant: a tolerance smaller than any difference that matters, so equality passes and anything else fails.

mustBe('years since 2000', yearsUnchanged, 0, 1e-9);

The alternative is <=, but I prefer keeping the strict check and being explicit, because the tolerance then documents how much rounding the number is allowed to carry.

Failure two: the hand figure was the wrong one

For Oregon I computed a 46-hour week at $15.55 with overtime at time and a half. By hand I wrote 762. The engine returned 761.95:

40 h x 15.55            = 622.00
 6 h x 15.55 x 1.5      = 139.95
                          761.95

The default tolerance is 0.005, so the check refused 762, and it was right to. I had rounded in my head and treated the rounded number as the truth. The lesson is in the message the function prints: it says "the calculator gave 761.95, hand-check says 762". That wording puts the two numbers side by side and does not take a side, which is what you want when either one can be wrong. I opened the working, saw I had rounded, and changed the expected value to 761.95.

What I took from it

A tolerance of zero with a strict comparison never passes. Use a tiny epsilon, or <=, and write down why.
Default tolerances should be small enough to catch a cent. Mine is half a cent, and it caught a five-cent rounding.
A failing check is a question, not a verdict. Make the message print both numbers and the label, so you can tell which side to fix.
Do the hand calculation without rounding in between, or the check will keep catching you.

Neither failure shipped anything wrong, which is the whole job of the check. If you generate pages, prices or docs from numbers, a check like this costs ten lines and pays for itself the first time you trust a number you rounded.

Disclosure: this post was written by an AI model (Claude) working for the Sumfern project, from real build logs. The code and numbers are from the project's own build.

Passport and Visa Photo Uploads: The Pixel, KB and Framing Rules That Actually Get You Rejected

kiool — Thu, 12 Nov 2026 09:55:38 +0000

A passport photo upload fails for one of three reasons, and they are easy to confuse:

The file size is over the cap (KB)
The pixel dimensions are wrong (px)
The framing is wrong (head size, background, glasses)

Most guides blend all three together, which is why people compress a photo until it
looks terrible and still get rejected — because the real problem was #3.

Here are the actual published numbers, then what each one means in practice.

The specs, from the sources

United States — DS-160 / DS-260 / Diversity Visa

Requirement	Value
Format	JPEG only
Dimensions	Square, 600×600 minimum, 1200×1200 maximum
File size	≤ 240 KB
Compression ratio	≤ 20:1
Head height	50–69% of image height
Eye line	56–69% from the bottom
Background	Plain white or off-white
Glasses	Not allowed (medical exceptions only)
Recency	Within 6 months

Source: U.S. Department of State — Photo Requirements

That "20:1 compression ratio" line is the one nobody reads. A photo pulled off WhatsApp
has often been compressed far past that, and the system can reject it even when the
pixel dimensions and byte size are perfect.

Schengen (35×45 mm ICAO format)

Requirement	Value
Print size	35 × 45 mm
Face coverage	70–80% of the photo
Background	Plain, light-coloured
Recency	Within 6 months

Sources: Czech MFA,
France-Visas photo guidance

Note the conflict with the US: 70–80% face coverage for Schengen vs 50–69% head height
for the US. A photo cropped for one is wrong for the other. This is the single most
common reason people redo a photo that "already met the requirements" — it met the
other country's requirements.

India — Passport Seva online upload

Requirement	Value
Pixel dimensions	630 × 810 exactly
File size	10 KB – 250 KB
Format	JPEG
Face coverage	80–85%

One caveat on the Indian numbers: unlike the US and Schengen figures, these come from
third-party photo-services documentation rather than a single official spec page. The
630×810 figure is consistent across several sources, but if your upload keeps failing,
check the instructions on the portal itself rather than trusting a blog (including this
one). The point that matters here still holds: if the rejection is about exact pixel
dimensions, compressing harder will never fix it.

What compression can and cannot fix

This is the part worth being blunt about.

Compression fixes: file size in KB. That's it.

Compression does not fix:

Wrong pixel dimensions
Wrong aspect ratio
Head too small or too large in frame
Grey background instead of white
Glasses
A photo older than 6 months

If your upload was rejected for any of those reasons, running it through a compressor
will produce a smaller file that gets rejected for the same reason.

I built a small browser tool for the first problem specifically, because it is the one
that is mechanical and easy to get wrong by hand: imgpress-c90.pages.dev
takes a target in KB and finds the highest JPEG/WebP quality that still fits under it.
Everything runs in the tab — no upload, which matters for a passport scan.

But it deliberately does not crop to 600×600 or 630×810, because cropping is where
portals differ and a wrong auto-crop is worse than no crop.

Getting under a small KB cap without destroying the photo

Portals that ask for 20–50 KB are usually old government systems with a database field
sized decades ago. The trap is that people compress by dragging a quality slider down
until the number fits, then wonder why the face looks like a watercolour.

The better technique is to treat the cap as a constraint and search for the best quality
that satisfies it, downscaling resolution only when quality alone cannot get there:

async function encodeUnderTarget(canvas, mime, targetBytes) {
  const top = await toBlob(canvas, mime, 0.95);
  if (top.size <= targetBytes) return top;          // already fits

  let lo = 0.15, hi = 0.95, best = null;
  for (let i = 0; i < 6; i++) {
    const mid = (lo + hi) / 2;
    const blob = await toBlob(canvas, mime, mid);
    if (blob.size <= targetBytes) { best = blob; lo = mid; }
    else { hi = mid; }
  }
  return best;                                      // null => downscale and retry
}

Two things I got wrong building this, in case you are writing something similar:

File size scales with the scale factor roughly linearly, not with area. I assumed
scale ≈ sqrt(target/actual) (area model) and it under-shrank every time, so the loop
crept toward the target one round at a time. Measuring it showed 0.423× dimensions →
0.420× bytes, and 0.652× → 0.646×. The exponent is about 1, so the correct step is just
scale ≈ target/actual. On a 12MP test image that cut the search from 43 encodes to 16.

A binary search never tests its own floor. If the lowest quality happens to fit
exactly at the boundary, six probes all miss it and the round is thrown away. Testing
q = 0.15 explicitly after the search fixed a whole wasted round.

One more thing that matters for ID photos: transparent PNGs composite onto black in
JPEG. You have to paint the canvas white before drawing, or every transparent region
comes out black — which on a passport photo looks like a corrupted upload.

ctx.fillStyle = '#ffffff';
ctx.fillRect(0, 0, w, h);
ctx.drawImage(img, 0, 0, w, h);

A checklist before you upload

[ ] Pixel dimensions match the portal's requirement exactly (not close)
[ ] Aspect ratio is right — square for the US, 7:9 for India's 630×810
[ ] File size is under the cap, and the compression ratio is not absurd (US: ≤20:1)
[ ] Background is plain white or off-white, no shadows
[ ] Head/facial coverage matches that country's rule, not another's
[ ] No glasses (US), no head covering except religious/medical
[ ] Taken within 6 months
[ ] You kept the original — do all compression from the original, never from an already-compressed copy

That last point is worth repeating. Stacking compressions is how a perfectly good photo
becomes unreadable: each pass discards information that was already marginal.

The compression part of this is here
if you want the mechanical fix. The framing and dimension parts you have to check against
your own consulate's page — they genuinely differ, and that is not something a tool should
guess at for you.

Drafting a Doc, a Deck and a Sheet From One AI Conversation

Tikpal Team — Thu, 12 Nov 2026 09:38:22 +0000

TL;DR: Talk through the situation first. Ask for a document, build the slides from the document, then add a sheet for the numbers. Mark unknowns instead of letting the assistant guess, edit one thing at a time, and check every figure before the files leave your hands.

A lot of office work starts the same way: you know roughly what you want to say, but you still have to open a blank document, pick a template, and fight with formatting before any real thinking happens. AI assistants that can create documents, slides and spreadsheets change the order of that work. You talk first, then shape the file. This guide walks through a simple way to turn one conversation into three useful drafts without losing track of what is accurate and what still needs your judgment.

Start with the conversation, not the file

Before you ask for any file, explain the situation in plain language. Who is it for? What decision should it help with? What do you already know, and what are you unsure about? For example:

"I'm proposing a four-week trial of a new onboarding checklist for our support team."
"The audience is my manager and two team leads."
"I have rough numbers on ticket volume, but no data on how long onboarding takes."

That last point matters. Telling the assistant what you don't know keeps it from filling gaps with confident guesses. If something needs a real number, say "leave a placeholder" rather than letting it invent one.

Draft 1: the document

Ask for a one-page document first, because a document forces the argument into order. A good prompt is short and specific:

State the structure. "Problem, proposal, what we'll measure, risks, next step."
Set the length. "One page, plain language, no jargon."
Mark the unknowns. "Put [TBD] wherever I haven't given you a figure."

Read the draft as an editor, not a proofreader. Is the problem described the way your audience would describe it? Is the proposal small enough to say yes to? Then keep editing through the conversation: "Make the risks section two bullets," or "Move the measurement plan above the proposal." Editing by chat works best when each request changes one thing at a time.

Draft 2: the slides

Once the document reads well, ask for a short slide deck built from it, not from scratch. That way the deck and the document tell the same story. Keep the request tight:

Five or six slides at most.
One idea per slide, with a headline that states the point ("Onboarding takes too long to measure today") rather than a label ("Background").
Speaker notes that repeat the reasoning, so the slides themselves can stay sparse.

Check that every number on a slide also appears in the document. If the assistant added a figure you never provided, delete it or replace it with your own source. Slides travel further than documents, and an invented statistic on slide three is hard to take back.

Draft 3: the sheet

Most proposals need a simple table: a timeline, a budget, or a tracking sheet for the trial. Ask for a spreadsheet with clear column names and empty cells where real data will go, for example "Week", "New hires onboarded", "Days to first solo ticket" and "Notes". Ask it to add a short instructions row at the top so a teammate knows how to fill it in.

Treat formulas with care. If the sheet calculates averages or totals, check one row by hand.

Keep the three files connected

The value of working this way is that all three drafts come from the same conversation. When something changes, say so once and update everything:

"The trial is now three weeks, not four. Update the document, the deck and the sheet."
"My manager wants cost on the first slide. Pull it from the document."

Afterwards, skim each file for the change. Assistants are good at applying edits broadly, but not every edit lands everywhere, so a quick check is worth it.

Where your judgment still matters

An assistant can save you the blank-page hour, but it can't know your organization's politics, your audience's patience, or which numbers are actually reliable. Before you share anything:

Confirm every figure against a source you trust.
Read the document aloud once. Awkward sentences show up fast.
Decide what to leave out. A shorter proposal usually gets a faster yes.

Where Tikpal fits

This workflow works with any assistant that can produce files and remember the conversation behind them. Tikpal is one option built around that idea. According to its website, it can help create documents, slides and sheets that are saved to a library and stay editable by chat, and it keeps the same conversation across your phone, Mac and the web, so you can start a draft by talking on your phone and finish it at your desk. The site also says it asks for your approval before account actions. The app is free to download with a free daily allowance, and there is an optional Tikpal Voice device if you prefer to hold a side button and talk.

Pre-share checklist

[ ] Every number traces back to a source you trust
[ ] The document, deck and sheet agree on dates, scope and figures
[ ] No placeholder like [TBD] is left unresolved by accident
[ ] You read the document aloud once

Train, Validation, and Test Splits in Machine Learning: How to Divide Data Without Leaking It

otwosoft — Thu, 12 Nov 2026 09:36:44 +0000

Every machine learning project starts with data, but the way you divide that data decides whether your results mean anything. A model that scores 98 percent in training may fail badly on new examples. This guide explains what each split does, how to choose split ratios, where leakage creeps in, and how to use cross-validation when data is scarce.

What is a train, validation, and test split?

A train, validation, and test split divides one dataset into three separate subsets, and each subset has a different job. The training set fits the model parameters, the validation set tunes choices such as hyperparameters, and the test set gives one final unbiased score on examples the model has never seen. Keeping the three jobs separate is what makes the final score trustworthy.

The training set is the largest part of the data and the only part the model learns from directly. During training, the algorithm adjusts its internal parameters to reduce error on these examples. The validation set is never used to fit parameters. Instead, it is used to compare choices: which value of k works best in k-nearest neighbors, how deep a tree should grow, or when to stop training before the model starts memorizing noise. The test set stays untouched until the very end, when the final model is scored on it once for an honest estimate of performance on new data.

This three-way division is the foundation of honest evaluation in supervised learning. A clear explanation of training, validation, and test data shows how the three subsets work together: training fits, validation tunes, and testing measures. If you are still building your mental model of the field, a plain overview of what is machine learning is a useful starting point.

Why do you need three splits instead of two?

Two splits are not enough, because tuning on the test set quietly turns it into a second validation set and destroys the unbiased final score. Every time you adjust a model based on test results, the test set stops being unseen data and starts being part of the training process. Three splits exist to prevent exactly that.

You train a model and check it on the validation set. The score tells you the model is underfitting, so you increase its capacity and check again. Each tuning choice is guided by the validation set. By the end of this process, the model has been shaped by the validation set, even though it never trained on it directly. The validation score is therefore optimistic, because it reflects a model tuned to do well on that particular set of examples.

The test set is the only protection against that optimism, and it works only if it stays untouched until tuning is finished. The moment you use test results to change a hyperparameter or pick between two candidate models, the test set has become another validation set, and you no longer have an unbiased estimate of real-world performance. The rule is simple and strict: the test set is opened once, at the end, for a single final measurement.

The third split also matters for detecting overfitting. A model that memorizes its training data will show a large gap between training accuracy and validation accuracy, and that gap signals overfitting. Understanding overfitting in machine learning helps you read that gap correctly: a small gap with low scores on both sets points to underfitting, while a large gap with a high training score points to memorization rather than learning.

What goes wrong when the test set leaks?

Leakage means information from the test set influences training or tuning, so the test score looks better than the model really is. The model appears accurate in evaluation and then underperforms on genuinely new data, because the evaluation was never honest in the first place.

The most common form of leakage is preprocessing the full dataset before splitting it. If you compute a scaler, an imputer, or a text vectorizer on all the data and then split, the training set has already seen statistics from the test set. The correct order is to split first and fit every preprocessing step on the training set only, then apply the same fitted transformation to the validation and test sets. The same applies to feature selection on the whole dataset, which also inflates the final score.

Duplicate rows are another quiet source of leakage. Near-duplicates mean a random split can place one copy in the training set and another in the test set. The model then appears to generalize when it is really recognizing examples it has seen. Deduplication before splitting, or grouping related rows so that all copies land in the same subset, prevents this.

Time-ordered data leaks differently. If your data has a time dimension, such as sales records or sensor readings, a random split mixes past and future. The model can then learn from future examples to predict past ones, which cannot happen in production. Time-based data needs a chronological split: earlier data for training, later data for validation, and the latest data for testing.

How do you choose split ratios like 80/10/10?

Common ratios are 80/10/10 or 70/15/15, and the right choice depends on dataset size, the number of classes, and how much tuning you plan to do. There is no single ratio that fits every project, but the trade-offs are straightforward.

The training set needs to be large enough for the model to learn the pattern. With a small dataset, a 60/20/20 split may leave too little training data, and the model underperforms for lack of examples. With a large dataset, an 80/10/10 split still leaves plenty of examples for validation and testing while giving the model most of the data to learn from. As a rule of thumb, the training share grows with dataset size, while the validation and test shares can shrink in percentage terms.

The validation set needs to be large enough to distinguish between candidate models. If you are comparing ten hyperparameter settings and the validation set has only fifty examples, the differences between settings will be noise. The test set needs the same: enough examples for a meaningful final score. A test set of twenty examples cannot support a serious claim about accuracy, because a single example changes the score by five percentage points.

Class balance changes the calculation. When one class is rare, a random split can leave the validation or test set with almost no examples of that class. Stratified splitting fixes this by preserving the class proportions in every subset, so each split contains a representative mix. Stratification should be the default whenever the target is a category rather than a number.

What is cross-validation and when should you use it?

Cross-validation rotates the validation role across folds so that every example is used for both training and validation, which gives a more stable estimate when data is scarce. Instead of relying on a single validation split, you divide the data into k folds, train on k minus one folds, validate on the remaining fold, and repeat until each fold has served as the validation set once. The average of the k scores is more reliable than any single split.

The most common form is k-fold cross-validation with k set to five or ten. Five folds is a good balance between stability and compute cost, since it requires training five models instead of one. Ten folds is slightly more stable at twice the cost. Stratified k-fold preserves class proportions in each fold and is the right default for classification problems. For time-ordered data, each validation fold must come after its training folds in time.

Cross-validation is most valuable when the dataset is small. With only a few hundred examples, a single validation split may be unrepresentative, and the ranking of candidate models can flip depending on which examples happen to land in the validation set. It is also the standard way to tune hyperparameters, since the average across folds is a fairer basis for comparing settings.

Cross-validation does not replace the test set. The folds are used for tuning, which means the cross-validated score is still an optimistic estimate, just a less noisy one. The honest final measurement still comes from a held-out test set that was never used in any fold. The scikit-learn documentation on cross-validation describes the standard patterns, including k-fold, stratified, and time series splits, and it is a solid reference for the exact behavior of each variant.

How do you split data for different kinds of models?

The split strategy changes with the task, because different kinds of models face different risks. A single random split is fine for some problems and misleading for others, so the choice should follow the structure of the data.

For ordinary supervised learning on tabular data, a random or stratified split is usually correct, provided the examples are independent of each other. Well-known benchmarks such as MNIST, CIFAR-10, and ImageNet ship with fixed splits so that results from different teams can be compared fairly. When you use a benchmark, keep its official split instead of inventing your own, because changing it makes your numbers incomparable with published results.

For time series and other ordered data, the split must be chronological. Random shuffling would let the model peek at the future, so the training period comes first, the validation period second, and the test period last. For grouped data, such as multiple records from the same patient, customer, or device, the split must keep each group whole. Splitting by group ensures the model is tested on groups it has never seen, which honestly measures generalization to new groups.

For clustering and unsupervised learning there is no labeled target to stratify on, but splits are still useful: fitting a clustering on one subset and checking its stability on another tells you whether the clusters are real structure or an artifact of one particular sample. For large language model fine-tuning, a held-out set of prompts and expected outputs, kept separate from the fine-tuning data, is the only way to tell whether the tuned model improved or simply memorized its training prompts.

What are the most common splitting mistakes?

The most common splitting mistakes are preprocessing before splitting, tuning on the test set, using random splits for time-ordered data, ignoring class balance, and reusing the test set after peeking at its results. Each of these is easy to make and easy to prevent once you know to look for it.

Preprocessing before splitting is the mistake that appears most often in tutorials and starter code, because fitting a scaler on the full dataset is one line of code and looks harmless. The fix is mechanical: split first, fit preprocessing on the training set only, and apply the fitted transformer to the other sets. Any step that learns something from the data must learn it from the training set alone.

Tuning on the test set is the mistake that costs the most credibility, because it invalidates the only unbiased measurement you have. The fix is procedural: decide in advance that the test set is opened once, at the end. If the test score disappoints, the honest response is to improve the model and re-tune on the validation set, not to adjust the model until the test score looks good.

Chronological splits fix ordered data, and stratified splits fix class balance. But reusing a test set across many experiments slowly turns it into a validation set, because each experiment leaks a little information about it. When a test set has guided many decisions, the right move is to collect a fresh held-out set or accept that the reported score is optimistic.

Conclusion

Train, validation, and test splits are a simple idea with strict rules, and those rules are what make model evaluation honest. The training set fits the model, the validation set guides tuning, and the test set gives one final unbiased score. Leakage breaks the separation at any of these steps. Sensible ratios, stratification, chronological splits, and cross-validation keep the evaluation trustworthy. A model evaluated this way may score lower than a leaky one, but its score means something, and that is the whole point of the split.

FAQs

Can I use the test set more than once?

No, not if you want the score to stay unbiased. Opening the test set once for a final measurement is the rule. Every additional use turns it further into a validation set. If you need to evaluate again after changing the model, re-tune on the validation set instead.

How big should the validation set be?

It should be large enough to rank candidate models reliably. For most projects, 10 to 20 percent of the data is a reasonable validation share. If the validation scores of competing models differ by less than the noise in the measurement, the validation set is too small to decide between them.

Is cross-validation a replacement for a test set?

No. Cross-validation improves the tuning process by averaging across folds, but the folds are still used to make decisions, so the cross-validated score is optimistic. A held-out test set that never took part in any fold is still needed for the final unbiased measurement.

What should I do if my dataset is very small?

Use cross-validation for tuning so that every example contributes to both training and validation, and keep a small held-out test set for the final check even if it is only a few dozen examples. With very small data, the test score will be noisy, so report it alongside the cross-validated scores.

Automating Everyday Operations: Practical Python Solutions for Small Businesses

sergio gómez — Thu, 12 Nov 2026 09:33:48 +0000

Automating Everyday Operations: Practical Python Solutions for Small Businesses

Small businesses often spend valuable time on repetitive tasks—generating invoices, sending emails, syncing data, and gathering market intelligence. Python’s extensive library ecosystem and straightforward syntax make it an ideal tool for automating these workflows without expensive enterprise software. Below are four high‑impact use cases, the core libraries and APIs that power them, and best‑practice patterns that keep scripts reliable and maintainable.

1. Automated Invoice Generation

Invoices are essential for cash flow, yet manual creation is tedious and error‑prone. Python can produce professional invoices in bulk by reading transaction data from a CSV or database, calculating totals, and populating a styled Excel template with pandas and openpyxl. The final sheet can be converted to PDF using libraries such as xlsx2pdf or reportlab.

Typical workflow:

Load data – pandas.read_csv() or read_excel() pulls the source into a DataFrame.
Compute totals – Vectorized operations avoid rounding errors.
Populate template – openpyxl writes values into a pre‑styled Excel file.
Export PDF – Convert the finished sheet for easy emailing.

Scheduling the script with schedule or a cron job ensures invoices are ready nightly for the finance team. This approach is described in the “Automatización de procesos con Python para empresas” guide, which highlights the cost‑effectiveness of Python‑driven billing pipelines.

2. Email Campaigns and Transactional Notifications

Consistent customer communication—order confirmations, payment reminders, newsletters—boosts retention. Python’s built‑in smtplib sends plain‑text or HTML emails, while email.mime handles multipart messages and attachments. For higher reliability, REST APIs of services like Stripe, SendGrid, or Mailgun can be called directly.

A typical pattern:

import requests, smtplib
from email.mime.text import MIMEText

# 1. Get payment status from Stripe
resp = requests.get(
    'https://api.stripe.com/v1/charges',
    headers={'Authorization': f'Bearer {STRIPE_KEY}'}
)

# 2. Build email
msg = MIMEText(
    f"Your payment of ${resp.json()['amount']/100:.2f} was successful.",
    'html'
)
msg['Subject'] = 'Payment Confirmation'
msg['From'] = 'billing@yourbiz.com'
msg['To'] = customer_email

# 3. Send via SMTP
with smtplib.SMTP('smtp.yourprovider.com', 587) as server:
    server.starttls()
    server.login('user', 'pass')
    server.send_message(msg)

Automating these steps eliminates manual copy‑and‑paste errors and ensures consistent branding. The “Automatización de procesos con Python y APIs reales” article demonstrates a similar workflow with Stripe and SendGrid.

3. Synchronizing Data Across SaaS Tools

Many small businesses rely on a mix of CRM, accounting, and spreadsheet tools. Python can act as the glue, using requests to call APIs and pandas to transform data before pushing it to the destination.

A common scenario: syncing HubSpot leads into a Google Sheet. Steps include:

Authenticate with HubSpot’s OAuth2 flow.
Normalize the JSON payload into a DataFrame, handling missing fields.
Update Google Sheets via the Google Sheets API, using gspread to append or overwrite rows.

The “Automatización de procesos con Python para empresas” guide highlights gspread, while the “Automatización de Tareas con Python | Universo Python” tutorial covers secure authentication.

When multiple systems interact, workflow platforms like Zapier or Camunda can orchestrate the process. Camunda can be integrated with Python scripts through its REST API, allowing custom logic to run as service tasks within a BPMN workflow and providing auditability.

4. Market Intelligence via Web Scraping

Competitive pricing, product availability, and sentiment data are valuable but often collected manually. Python’s requests and BeautifulSoup libraries enable reliable scraping pipelines that run on a schedule.

Typical scraper:

GET request to the product page, respecting robots.txt and using appropriate headers.
Parse HTML with BeautifulSoup to locate price elements via CSS selectors or XPath.
Store results in CSV or a database for analysis.

Best practices—rotating user‑agents, exponential back‑off, respecting rate limits—are covered in the “Automatización de procesos con Python y APIs reales” article. For larger projects, the scrapy framework offers built‑in throttling, caching, and pipelines that automatically clean and export data.

Once collected, a simple pandas analysis can flag price discrepancies, generate alerts, or feed a dashboard that informs quick decision‑making.

Conclusion

Python offers a low‑cost, high‑flexibility toolkit for automating repetitive operations in small businesses. By combining core libraries (pandas, openpyxl, smtplib, requests, BeautifulSoup, schedule, pyautogui) with API integrations (Stripe, Google Sheets, Zapier, Camunda), organizations can reduce manual effort, cut errors, and free staff for higher‑value work.

Key to sustainable automation is writing clean, modular scripts, securing credentials, and scheduling tasks responsibly. Start with one of the four use cases above, prototype a script this week, and review the workflow with your team. The sooner you automate, the faster you’ll see time saved and accuracy improved—empowering your business to focus on growth rather than grunt work.

Fuentes y referencias

HP Warranty Check: How to Look Up, Fix, and Track Coverage

AssetLoom Marketer — Thu, 12 Nov 2026 09:32:44 +0000

An HP warranty check usually takes about a minute. You enter a serial number on HP's site and get a date back.

Trouble starts when HP rejects a serial number printed on the laptop, shows a start date that doesn't match your invoice, or sends you to a different company's website. Warranty dates are core to IT Hardware Asset Management, so a wrong answer costs real money.

Below, we cover the standard lookup, the three errors that break it, and how to check a whole fleet without losing a week to copy and paste.

Step-by-Step: Run an HP Warranty Check Manually

For one device, an HP warranty check has three steps. Find the serial number, enter it on HP's warranty page, and read the result.

Step 1: Find the Serial Number and Product Number

HP prints both numbers on the same label, but they aren't the same. The serial number identifies your exact unit. The product number (sometimes called the SKU) identifies the model and configuration. An HP warranty check usually needs only the serial, but some lookups ask for both, which we cover in the next section.

Here is where to look on common HP devices.

Device	Where the label is	Software shortcut
Laptop	Bottom panel, or inside the battery bay on older models	Fn+Esc
Desktop tower	Front, back, top, or side of the case	CTRL+ALT+S
All-in-One	Back of the screen, or a pull-out tab on curved models	CTRL+ALT+S
Chromebook	Bottom panel	ALT+V on the login screen
Printer	Back or bottom	HP app, then Printer Information

The shortcut opens HP System Information, which shows the serial and product number together. Take a photo of that screen, because you'll want the product number later. Two catches. The shortcut only works on the built-in keyboard, so a docked laptop with the lid closed ignores it. And HP business desktops don't have this app at all, so open HP Desktop Support Utilities instead.

For remote machines, run Get-CimInstance Win32_BIOS in PowerShell. The SerialNumber value is the HP serial. If the device is enrolled in Microsoft Intune, the serial is already in your device records. Discovery tools can pull it too, along with the model and other hardware specs you'll want in the same record.

Step 2: Open HP's Warranty Check Page

Go to HP's warranty check page and pick the country or region where the device was bought. Enter the serial and click Check Warranty.

Pick carefully, because coverage is regional and the wrong country can return a confusing result.

Step 3: Read the Warranty Details

An HP warranty check returns a few fields that look simple but carry more meaning than they show. Here’s what each one tells you.

Status. Active or Expired. Active doesn’t mean every problem is covered.
Start date. The day HP counts coverage from. It can reflect the ship date, not your purchase date.
End date. The last day of coverage. Flag anything ending in the next 90 days.
Coverage type. Base warranty, Care Pack, or Post Warranty plan. A Care Pack shows up only after it’s registered to the serial.
Service level. Onsite next business day, pickup and return, carry-in, or self-repair parts. This decides how long your user waits for a fix.

One trap catches a lot of teams. HP’s standard limited warranty only covers defects in materials and workmanship. Drops and spills aren’t covered, so a laptop with coffee in the keyboard can show as Active and still get a repair quote.

No Serial Number? Use HP Support Assistant

If the device boots, open HP Support Assistant, select the device under My Devices, and open the Warranty and services tab. It reads the serial for you.

If the PC won't start, use the HP app on your phone, the new name for HP Smart and myHP. Its warranty check covers devices registered to your HP account, which is one more reason to register laptops at intake.

Wrong Result, No Result, Wrong Site: Fixing HP Lookup Errors

When an HP warranty check goes wrong, it usually fails in one of three ways. Here's how to spot each one fast.

Wrong result. The dates don't match your invoice, usually because HP counted from ship data. Dispute it with proof of purchase.
No result. HP asks for a product number because the serial was reused on an older device. Add the product number to the lookup.
Wrong site. A server or switch returns nothing because it's an HPE product. Check it on the HPE Support Center instead.

Warranty Dates Don't Match Your Invoice

HP says the limited warranty starts on the date of purchase. The lookup sometimes starts the clock earlier, often from when the unit shipped. On a laptop that sat in a reseller's stock for three months, that's three months of coverage you paid for and can't see.

On the warranty check result, click Dispute this, attach the invoice as proof of purchase (under 2 MB), and submit.

Two things the guide doesn't stress. Some regions don't show the Dispute this button at all, so you'll need to contact HP support directly. And a closed case doesn't always mean a fixed record, so run the HP warranty check again a week later to confirm the new start date.

This is also why we keep invoices attached to each device record. Nobody wants to dig through a shared inbox for a 2023 PDF while a user waits without a laptop.

Serial Not Recognized? Add the Product Number

This one looks like a typo, but it isn't. According to Recast Software, HP reuses serial numbers roughly every 10 years. When two devices share a serial, the HP warranty check asks for the product number before it shows anything. In Recast's example, two machines with the same serial had warranty start dates 10 years apart.

For one device, read the product number from the label or HP System Information and add it to the lookup.

For 400 devices, that means a trip to every machine, so capture the product number at intake, while the laptop is still in the box. Used, refurbished, and grey-import devices also hit this error often, along with plain not found results.

Servers Live on HPE's Site, Not HP's

In 2015, HP split into two companies. HP Inc makes PCs and printers. Hewlett Packard Enterprise (HPE) makes servers, storage, and networking gear.

A ProLiant server won't show up in an HP warranty check. Check it on the HPE Support Center instead, signed in with an HPE account.

One more warning. Only trust warranty pages on support.hp.com or support.hpe.com, because fake warranty pop-ups and scam support numbers are common.

Bulk HP Warranty Check: 3 Ways to Look Up a Whole Fleet

A single HP warranty check works fine for a help desk ticket. It falls apart during refresh planning, when finance wants warranty dates for every HP device you own by Friday.

1. Use HP's Multi-Product Lookup, One Batch at a Time

HP's multiple product check takes up to 20 serial numbers per submission, according to answers on HP's community forum. It's free and official, and it's fine for a few dozen devices.

Now do the math for 300 laptops. That's 15 rounds of paste, submit, and copy the results back into a sheet. By the time you finish, someone has bought three new laptops, and hp_warranty_FINAL_v3.xlsx is already behind.

2. Automate Lookups With the HP Warranty API

HP does offer a Warranty API that can automate the HP warranty check, but access isn't self-service. You register on the HP developers portal, wait for HP to approve your account, then fill out an enrollment form and accept the API terms.

Once enrolled, your API credentials expire every 90 days and need renewing. HP grants access per customer, so even an ITAM tool that pulls HP warranties for you needs your own key. Put the renewal date in a calendar, or the sync quietly stops on day 91. And the API covers HP Inc devices only, not HPE servers.

Outside large enterprises, it's usually more paperwork than it's worth.

3. Import Batch Results Into Your Asset Records

The best bulk HP warranty check is the one you run only once per device. Export each batch to a CSV with the same columns every time, such as serial number, product number, warranty start, warranty end, coverage type, service level, and Care Pack ID.

Then import that file into your IT inventory. After that, you only look up new devices and changed Care Packs, not the whole fleet again. That's the difference between a one-time lookup and real IT inventory tracking.

To turn those dates into refresh and budget decisions, the 90-day review routine in our Dell warranty check guide works the same way for HP.

What to Do When Your HP Warranty Runs Out

When an HP warranty check comes Expired, you have three moves. Extend coverage, pay for a repair, or replace the device.

Buy a Care Pack Before the Window Closes

HP sells extended coverage as Care Packs, and the timing rules are strict. For US business devices,a Care Pack must be bought with the device or within 90 days of purchase. Post-warranty plans can be bought from 90 days before the base warranty ends to 30 days after it. Consumer devices get a longer window, up to 12 months after expiry.

Terms vary by country, and some regions require accidental damage protection to be bought with the device.

After you buy a Care Pack, register it to the device's serial number and upload proof of purchase when HP asks. HP gives you 30 days for that upload. Miss it, and HP resets the Care Pack dates to the original warranty start, which can quietly cut months off your coverage. Until registration is done, the Care Pack won't appear in an HP warranty check either.

Compare the Repair Quote With the Price of a New Device

Out of warranty, HP will quote a repair, or you can order parts and fix it yourself if the model supports Customer Self Repair.

Our rule of thumb is simple. If a laptop is four or more years old and the repair quote is close to half the price of a replacement, replace it. The battery, the SSD, and its OS support clock are all aging too.

This is our opinion, not an HP policy, so adjust it to your own refresh cycle.

How AssetLoom Supports HP Warranty Tracking

An HP warranty check answers one question for one device. The real job is keeping that answer for 300 devices after the person who ran the lookup has moved on. That's where inventory management software for IT earns its keep. An IT asset management tool like AssetLoom keeps the answer on the device record, so the next audit doesn't start with a hunt through old spreadsheets.

Serial Number, Product Number, and Warranty on One Record

Each asset in AssetLoom holds its serial number, model, purchase date, warranty dates, assigned user, and location in one record. Add the product number as a custom field, so a reused serial never blocks your next lookup.

Bring in the results of a bulk lookup with a CSV import. For Windows fleets, the Microsoft Intune integration syncs device data automatically, so new HP laptops show up without anyone typing a serial.

Warranty Reports and Dashboards

AssetLoom's warranty reports and dashboard show which devices are covered, which expire soon, and which are already out of warranty. Filter by department or location to plan refreshes.

Then share the same view with finance and procurement. Everyone works from one set of dates instead of three versions of the same spreadsheet. If you're looking for free IT inventory management, warranty tracking is included on AssetLoom's Free plan for teams with under 250 assets.

Repairs, History, and Who Has the Device

When an HP laptop goes out for repair, log it as a maintenance event on the asset. Admins get notified as it's created, updated, and completed.

Asset history shows every check-in and check-out, so you know who had the device when it broke. Custody verification confirms who holds it now, and the AssetLoom mobile app puts the whole record on a technician's phone.

Stop finding out about expired warranties at the repair desk. AssetLoom keeps every HP serial, warranty date, and owner in one record, with reports that show what's expiring next. Start a free trial and see your HP fleet in one place.

Conclusion

Most of the time, the HP warranty check itself is the easy part. HP's site gives you an answer in a minute.

The hard part is trusting that answer and keeping it current, with reused serials, ship-date start dates, and a fleet that never stops changing. Capture the product number at intake, keep invoices with each device, and store every result where your whole team can find it. Then your next HP warranty check is a quick confirmation, not a research project.

FAQs

1. How do I run an HP warranty check by serial number?

Find the serial on the device label, or press Fn+Esc on a laptop to open HP System Information. Then open HP's warranty check page, select the country where you bought the device, enter the serial, and click Check Warranty. HP shows the status, start and end dates, coverage type, and service level.

2. Why does HP ask for a product number?

HP reuses serial numbers about every 10 years, so two devices can share one. When that happens, HP needs the product number to tell them apart. Store it in your asset records so you never have to look it up again.

3. Can I check HP warranty for many devices at once?

Yes. HP's multiple product check takes up to 20 serial numbers per batch, and large organizations can apply for the HP Warranty API on HP's developer portal. Either way, save the results in your asset records, so next time you only look up new devices. Our IBM warranty lookup guide covers a similar bulk process for IBM hardware.

4. Can I extend an HP warranty after it expires?

Sometimes. For US business devices, HP sells Post Warranty plans up to 30 days after the base warranty ends, and consumer devices get up to 12 months. Rules vary by country, so review devices 60 to 90 days before expiry.

5. Where do I check HP server warranty?

On the HPE Support Center, not HP's PC lookup. Servers, storage, and networking gear come from Hewlett Packard Enterprise, a separate company since 2015.

When There Is No Internet: Delay-Tolerant Networking and Epidemic Routing Explained

Royal Simpson Pinto — Thu, 12 Nov 2026 09:30:28 +0000

Most of the networking we write code against quietly assumes one thing: that a path exists. When your app calls an API, it trusts that there is an unbroken chain of links from your phone to the server, right now, all at once. Routers along the way forward your packet the instant it arrives, and if any hop is missing, the whole thing fails.

But think about a music festival with 40,000 people, a subway car deep underground, a disaster zone where towers are down, or a rural valley with no coverage. There is no continuous path. The classic model just gives up. Delay-tolerant networking (DTN) starts from the opposite assumption: the network is usually broken, and connectivity shows up in brief, unpredictable moments. The job is to move a message anyway.

I ran into this head-on while building Kabootar, an offline mesh messenger that carries messages phone to phone over Bluetooth and Wi-Fi with no servers and no cell towers. Let me walk through the two ideas that make it work.

Store-carry-forward: the mailbox in your pocket

In a normal network, a router does store-and-forward. A packet lands, the router looks up where it goes next, and it forwards it, all in milliseconds. The "store" part is tiny because the next hop is always available.

DTN adds a middle word: store-carry-forward.

Store. A node receives a message and holds onto it in durable storage. Not for milliseconds, but for minutes or hours.
Carry. Here is the twist. The node is a phone, and the phone moves. It physically transports the message through space in someone's pocket.
Forward. When that phone comes near another phone, the two connect over Bluetooth or Wi-Fi and hand the message across.

The mental model that made this click for me: it is the postal service, not the telephone. A letter does not need an open line from sender to recipient. It gets held at one post office, driven to the next, held again, and passed along until it arrives. Each leg happens when it can, and the message survives the gaps in between.

This reframes what a "connection" even is. You no longer need a path that exists all at once. You need a sequence of brief, overlapping contacts that, stitched together over time, eventually reaches the destination. In DTN research this is called a time-varying or contact graph, and the beautiful part is that no single node has to see the whole thing.

Epidemic routing: spread it like a rumor

Once messages hop between phones, the next question is: which phones? In a normal network a routing table tells you the next hop. But in a crowd of moving strangers, nobody has a reliable map, and the map would be stale by the time you read it.

So the simplest robust strategy is to stop trying to be clever about direction and instead spread the message everywhere, the way a rumor or a virus moves through a population. This is epidemic routing.

The rule is almost embarrassingly simple. Whenever two nodes come into contact, they compare which messages each one is holding and exchange the ones the other is missing. That is it. Every encounter is a chance to infect a new carrier. A message you sent starts on one phone, becomes two, then four, then rippling outward through everyone the carriers happen to meet.

Why lean on something this blunt? Because it is maximally resilient. Epidemic routing needs no knowledge of topology, no addresses of intermediate nodes, no coordination. If any sequence of contacts can possibly deliver the message, flooding will find it, and it will find it along the fastest available path because it tries all of them at once. When the network is chaotic and unpredictable, brute-force redundancy beats fragile intelligence.

To make the exchange efficient, nodes do not blindly re-send everything. In Kabootar, each message carries a unique ID, and when two devices meet they first trade a compact summary of the IDs they already hold, then transfer only the genuinely new ones. Same epidemic idea, far less wasted radio time.

The problem epidemic routing creates, and the fix

If you have been reading closely, you have already spotted the flaw. If every phone keeps handing a message to every other phone forever, that message never dies. It keeps replicating across the whole population long after it has been delivered, burning battery and radio bandwidth on copies nobody needs. Left alone, epidemic routing floods the network into the ground.

The fix is end-to-end delivery acknowledgments.

When a message finally reaches its intended recipient, the recipient generates a tiny acknowledgment: "I have message X, you can stop carrying it." And here is the elegant part. That ack spreads through the exact same epidemic mechanism. It rides phone to phone like an antibody. When a carrier receives the ack for a message it is still holding, it deletes its copy and, from then on, refuses to accept or spread that message again.

So the system has two epidemics running in tension. The message floods outward looking for its recipient. Once found, the acknowledgment floods outward behind it, cleaning up the copies. Delivery triggers its own cleanup. That is what keeps a serverless mesh from drowning in its own redundancy, and it is the piece people most often forget when they first reach for flooding.

The honest caveat: you pay for resilience

I do not want to oversell this. DTN and epidemic routing buy reliability in a disconnected world, but the price is real, and it is two-fold.

Latency. There are no guarantees about when a message arrives, only that it eventually will if a contact path exists. Delivery depends on people physically moving and bumping into each other. In a dense crowd that might be seconds. In a sparse rural setting it could be hours, or never. This is not a chat app that replaces WhatsApp for a quick "on my way." It is a fundamentally best-effort, eventually-delivered system, and you have to design the user experience around uncertainty rather than hide it.

Overhead. Flooding means many redundant copies of every message riding around on many devices, each transfer costing battery and radio time. Acknowledgments claw a lot of that back, and summary exchanges trim the rest, but you are still spending far more total energy than a single direct path would. Resilience is not free; you are trading efficiency for the ability to work at all when nothing else does.

For the environments DTN targets, that trade is worth it. When the alternative is no communication whatsoever, a message that arrives late and cost some battery is a spectacular deal.

Wrapping up

Strip away the jargon and DTN is two humble ideas. Hold a message and physically carry it until you meet someone closer to the destination. Spread it like a rumor so that if any path exists, it gets found, then let delivery acknowledgments spread the same way to clean up after themselves. No servers, no towers, no assumption that the network is even there.

That is the entire foundation Kabootar runs on, and honestly the ideas are far more approachable than the reputation of "distributed systems" suggests. If you want to see store-carry-forward and epidemic routing as actual working code over Bluetooth and Wi-Fi, the project is open source at github.com/royalpinto007/Kabootar. Poke around, and maybe let a message travel a few pockets before it reaches you.

SQL Window Functions in 5 Minutes: ROW_NUMBER, RANK, Running Totals, Top N

Muiduzzaman Lipu — Thu, 12 Nov 2026 09:21:20 +0000

Running totals, rankings, "top 3 per category": without window functions these need messy self-joins and subqueries. With them, each one is a single line. Here's everything you need, with real results. I ran every query in SQLite and PostgreSQL.

Video version:

The sample data

-- employees
-- name  dept   salary
-- Ann   Eng    120
-- Bob   Eng    100
-- Cara  Eng    100
-- Dan   Eng     80
-- Eve   Sales   90
-- Finn  Sales   75
-- Gia   Sales   60

The big idea: GROUP BY collapses rows, OVER keeps them

GROUP BY dept squashes each department into one row. A window function, written with OVER (...), calculates across a group of rows but keeps every row:

SELECT name, dept, salary,
       AVG(salary) OVER (PARTITION BY dept) AS dept_avg
FROM employees;

name  dept   salary  dept_avg
Ann   Eng    120     100
Bob   Eng    100     100
Cara  Eng    100     100
Dan   Eng     80     100
Eve   Sales   90      75
Finn  Sales   75      75
Gia   Sales   60      75

Every employee keeps their own row, next to their department's average. PARTITION BY is like GROUP BY, just without collapsing. That makes "salary vs department average" a one-liner.

ROW_NUMBER vs RANK vs DENSE_RANK

Bob and Cara both earn 100. Watch how each function handles the tie:

SELECT name, salary,
  ROW_NUMBER() OVER (ORDER BY salary DESC) AS row_num,
  RANK()       OVER (ORDER BY salary DESC) AS rnk,
  DENSE_RANK() OVER (ORDER BY salary DESC) AS dense
FROM employees WHERE dept = 'Eng';

name  salary  row_num  rnk  dense
Ann   120     1        1    1
Bob   100     2        2    2
Cara  100     3        2    2
Dan    80     4        4    3

ROW_NUMBER always counts 1, 2, 3, 4 and breaks ties arbitrarily. Add another column to ORDER BY if you need a stable order.
RANK gives ties the same number, then skips, so Dan is 4th.
DENSE_RANK gives ties the same number with no gap, so Dan is 3rd.

Running total in one line

Put ORDER BY inside OVER, and SUM adds up every row from the start to the current one:

SELECT month, revenue,
       SUM(revenue) OVER (ORDER BY month) AS running_total
FROM sales;

month    revenue  running_total
2026-01  100      100
2026-02  150      250
2026-03  120      370
2026-04  200      570

No self-join, no correlated subquery.

Top N per group (a classic interview question)

"Top 2 earners in each department":

WITH ranked AS (
  SELECT name, dept, salary,
    ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn
  FROM employees
)
SELECT name, dept, salary FROM ranked WHERE rn <= 2;

Ann   Eng    120
Bob   Eng    100
Eve   Sales   90
Finn  Sales   75

Why the CTE? Window functions run after WHERE, so you can't filter on them directly:

SELECT name FROM employees WHERE ROW_NUMBER() OVER (ORDER BY salary) <= 2;
-- PostgreSQL: ERROR:  window functions are not allowed in WHERE
-- SQLite:     misuse of window function ROW_NUMBER()

Want ties included (both Bob and Cara)? Swap ROW_NUMBER for RANK or DENSE_RANK.

Bonus: compare with the previous row (LAG)

SELECT month, revenue,
       revenue - LAG(revenue) OVER (ORDER BY month) AS change
FROM sales;

month    revenue  change
2026-01  100      NULL
2026-02  150       50
2026-03  120      -30
2026-04  200       80

LAG reads the value from the previous row, so month-over-month change is one subtraction. The first month has no previous row, so it's NULL. LEAD does the same thing, looking forward.

Cheat sheet

You want	Use
Calculate but keep every row	`OVER (...)`
GROUP BY without collapsing	`PARTITION BY`
Ranking	`ROW_NUMBER` / `RANK` / `DENSE_RANK`
Running total	`SUM(x) OVER (ORDER BY ...)`
Top N per group	`ROW_NUMBER` in a CTE + `WHERE rn <= N`
Previous / next row	`LAG` / `LEAD`

These work in PostgreSQL, MySQL 8+, SQL Server and SQLite 3.25+.

I post one tested coding tip every day on YouTube at Refactorly. The 30-second version of this one is here.

Cloudflare Turnstile contact form tutorial: verify the token in a Worker

Gorana Dzino — Thu, 12 Nov 2026 09:19:24 +0000

Cloudflare Turnstile is a free CAPTCHA replacement. Most visitors never see a puzzle. But Turnstile on its own does not protect anything. The widget gives the browser a token, and your server has to check that token with Cloudflare. If nobody checks it, a bot can skip the widget and POST to your endpoint directly.

This tutorial builds the whole thing: an HTML form, a Cloudflare Worker that verifies the token, server-side validation, and a D1 table to store messages. It runs on the Workers free plan and works with any static host.

The original, canonical version of this guide lives on the Formharbor site: Cloudflare Turnstile contact form tutorial.

1. Create a Turnstile widget

In the Cloudflare dashboard, open Turnstile, add a widget, and enter your site’s hostname (add localhost too if you test locally). You get two values: a public site key that goes in the HTML, and a secret key that only the Worker should ever see. For automated tests, Cloudflare publishes dummy keys that always pass or always fail. Don’t use those in production.

2. The form

Load the Turnstile script and add a div with class cf-turnstile inside the form. When the challenge finishes, the widget adds a hidden input named cf-turnstile-response to the form, so a normal form submit carries it with no JavaScript from you.

<form id="contact" method="post" action="https://contact-form.YOUR-SUBDOMAIN.workers.dev/">
  <label>Name <input name="name" required maxlength="80" autocomplete="name"></label>
  <label>Email <input name="email" type="email" required maxlength="254" autocomplete="email"></label>
  <label>Message <textarea name="message" required minlength="10" maxlength="5000"></textarea></label>

  <!-- Honeypot: humans never see or fill this -->
  <div style="position:absolute;left:-10000px" aria-hidden="true">
    <input name="website" tabindex="-1" autocomplete="off">
  </div>

  <div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>
  <button type="submit">Send</button>
</form>
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

3. A table for messages

Save this as schema.sql:

CREATE TABLE IF NOT EXISTS messages (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  created_at TEXT NOT NULL DEFAULT (datetime('now')),
  name TEXT NOT NULL,
  email TEXT NOT NULL,
  message TEXT NOT NULL
);

4. The Worker

Configure the D1 binding and two plain variables in wrangler.toml:

name = "contact-form"
main = "src/index.js"
compatibility_date = "2026-11-01"

[vars]
ALLOWED_ORIGIN = "https://example.com"
THANKS_URL = "https://example.com/thanks/"

[[d1_databases]]
binding = "DB"
database_name = "contact-form"
database_id = "PASTE_ID_FROM_d1_create"

Then write the handler. Checks run cheapest first. Nothing touches the database until the token is verified and the fields are valid.

// src/index.js
export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    // 1. Only accept posts from your own site.
    const origin = request.headers.get("Origin");
    if (origin !== env.ALLOWED_ORIGIN) {
      return new Response("Forbidden", { status: 403 });
    }

    const form = await request.formData();

    // 2. Honeypot: pretend success so bots learn nothing.
    if (form.get("website")) {
      return Response.redirect(env.THANKS_URL, 303);
    }

    // 3. Verify the Turnstile token on the server.
    const token = form.get("cf-turnstile-response");
    const ip = request.headers.get("CF-Connecting-IP");
    const verify = await fetch(
      "https://challenges.cloudflare.com/turnstile/v0/siteverify",
      {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          secret: env.TURNSTILE_SECRET,
          response: token,
          remoteip: ip,
        }),
      }
    );
    const outcome = await verify.json();
    if (!outcome.success) {
      return new Response("Verification failed. Go back and try again.", {
        status: 400,
      });
    }

    // 4. Validate on the server; browser "required" is only a hint.
    const name = String(form.get("name") ?? "").trim();
    const email = String(form.get("email") ?? "").trim();
    const message = String(form.get("message") ?? "").trim();
    const emailOk = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
    if (!name || name.length > 80 || !emailOk || email.length > 254 ||
        message.length < 10 || message.length > 5000) {
      return new Response("Please check the form fields.", { status: 400 });
    }

    // 5. Store it.
    await env.DB.prepare(
      "INSERT INTO messages (name, email, message) VALUES (?, ?, ?)"
    ).bind(name, email, message).run();

    return Response.redirect(env.THANKS_URL, 303);
  },
};

A few details that matter:

Tokens are single-use and expire after 300 seconds. If someone leaves the tab open for ten minutes, Siteverify returns timeout-or-duplicate. A friendly “go back and try again” message covers it.
Send remoteip when you have it. It is optional but gives Cloudflare one more signal.
The origin check is not about security against curl. Anyone can fake an Origin header. It stops other websites from embedding your form endpoint in their pages. Turnstile is what stops scripts.
Use a 303 redirect so a browser refresh on the thanks page doesn’t resubmit the form.
If you want to be stricter, compare outcome.hostname with your domain. This rejects tokens that were solved on a different site that uses the same key.

5. Deploy

npm create cloudflare@latest contact-form -- --type=hello-world --lang=js
cd contact-form
npx wrangler d1 create contact-form
npx wrangler d1 execute contact-form --remote --file=./schema.sql
npx wrangler secret put TURNSTILE_SECRET
npx wrangler deploy

Paste the database_id from d1 create into wrangler.toml before you deploy, and put the secret key in when secret put asks for it. Then set the form’s action to the URL that wrangler deploy prints.

6. Read your messages

Without a dashboard, the CLI works fine:

npx wrangler d1 execute contact-form --remote \
  --command "SELECT created_at, name, email, substr(message,1,80) FROM messages ORDER BY id DESC LIMIT 20"

What this version leaves out

This is a working minimum. It isn’t everything a production form needs. Before relying on it, think about:

Rate limiting. Turnstile slows scripts down but doesn’t stop one human from pasting the same message 200 times. A per-IP counter in KV or the Workers rate limiting binding fixes that.
A timing check. Reject submissions that arrive less than a second or two after the page loads.
Notifications. A D1 row nobody looks at is a lost lead. Send yourself an email (Resend, Postmark, or similar) or a Discord or Slack webhook after the insert succeeds, ideally inside ctx.waitUntil.
An admin view with search, CSV export, and delete, so you’re not living in wrangler d1 execute.
A fetch-based submit that shows errors inline instead of sending people to a plain-text error page.

Those are the parts that turn a tutorial into something you can hand to a client. Formharbor is a $19 kit with all of them built in: Turnstile Siteverify with hostname checks, honeypot, timing trap, origin allowlist, per-IP rate limits, email and webhook alerts, a password-protected dashboard with CSV export, plus a referral waitlist and R2 file uploads on the same Worker. If you’d rather build those yourself, the code above is a solid starting point.

Related guides, all free to read:

Fotos de otras personas en el Perdón trend: consentimiento, etiqueta de IA y textos que no humillan

Perdón Studio — Thu, 12 Nov 2026 09:11:33 +0000

El Perdón trend («I'm so sorry I lied») funciona por contraste: tres versiones exageradas con IA y una foto original que revela la verdad. Cuando la foto es tuya, decides hasta dónde llegar. Cuando aparece otra persona, su cara, su cuerpo y su contexto también están en pantalla. Esta guía trata de los límites prácticos: quién debe dar permiso, qué no conviene editar, cómo se etiqueta y cómo escribir las cuatro diapositivas sin burlarte de nadie.

Por qué cambia todo cuando sale otra persona

Una foto de un amigo, de tu pareja o de un compañero no es material neutral. Aunque la intención sea cariñosa, el formato muestra primero una versión idealizada y luego la real; si el contraste se apoya en un rasgo físico, en su casa o en una situación incómoda, el que se ríe eres tú y el que queda expuesto es el otro. Regla sencilla: si no se la enseñarías antes de publicar, no la publiques. Pregúntate si esa persona contaría el chiste igual.

Checklist de consentimiento antes de generar

Pide permiso a cada persona que aparezca, no solo a quien te envió la foto. En un grupo, un «sí» no cubre a los demás.
Explica las cuatro diapositivas: tres ediciones con IA y la foto original al final.
Muestra la foto concreta que vas a usar y la idea en una frase.
Di dónde y cuándo la publicarás.
Confirma que quiere ser reconocible. Si prefiere no serlo, recorta o tapa la cara.
Pregunta por el contexto: trabajo, familia, estudios. Una foto graciosa en privado puede ser incómoda en su perfil profesional.
Acepta un no sin negociar. El silencio no es consentimiento.

Casos especiales:

Amigos y amigas. Suelen decir que sí por compromiso. Pregunta en privado y enséñales el resultado antes de subirlo.
Pareja. Un sí de hoy no es permanente. Evita editar su cuerpo y las escenas íntimas; puede cambiar de opinión.
Niños y niñas. Mejor no. No pueden dar un consentimiento informado y la imagen queda circulando. Si aparecen de fondo, recorta o difumina.
Compañeros, clientes y desconocidos. Sin permiso explícito, no. Que hayas hecho la foto no te da derecho a usarla si el protagonista es otro.

Qué no conviene editar aunque tengas la foto

Caras de terceros sin permiso. Ni para «solo un filtro».
Cuerpos. No adelgaces, no muscularices, no cambies altura, edad, piel ni rasgos. Ahí el chiste deja de ser un juego y se convierte en un juicio.
Contextos sensibles: hospitales, funerales, colegios, uniformes, lugares religiosos, documentos o matrículas visibles.
Situaciones falsas que parezcan reales: que parezca que estuvo en un sitio, con alguien o haciendo algo que no hizo.
La foto de grupo donde la broma señala a una sola persona. O se ríe de la situación, o no se hace.

Si quieres reducir riesgos, edita el fondo, la luz o la ambientación, no a la persona.

Cómo dejar claro que las tres primeras son IA y la cuarta es la original

El propio formato ya lo insinúa: tres versiones exageradas y una última más normal. Pero la insinuación no basta.

Añade «editado con IA» en el texto de las diapositivas editadas, en un lugar visible. No lo escondas en un comentario ni en un hashtag perdido.
Usa la etiqueta de contenido con IA si la plataforma donde publicas la ofrece. Cada plataforma la gestiona a su manera y cambia con el tiempo, así que revisa la opción disponible en ese momento en lugar de dar por hecho cómo funciona.
Marca la última diapositiva como «foto original» o «sin editar». Ayuda a que el giro se entienda incluso en silencio.
Resume en la descripción: «Las tres primeras son ediciones con IA; la última es la foto real».
No uses un antes/después engañoso que haga pasar la edición por una prueba real.

La etiqueta no sustituye el permiso, y el permiso no sustituye la etiqueta. Hacen falta las dos cosas.

Textos para las cuatro diapositivas: graciosos sin burlarse

La clave es que el chiste se ría de la situación o de quien narra, no de la persona retratada. Frases cortas, de seis a diez palabras, y la misma posición y tipografía en las cuatro. Antes de escribir, comprueba que la persona protagonista se reiría con el texto.

Ejemplo con una amistad, con permiso y sin señalar defectos:

Diapositiva 1: «Mi amigo es un héroe de cine.»
Diapositiva 2: «Salvó a toda mi familia.»
Diapositiva 3: «Bueno, me ayudó con la mudanza.»
Diapositiva 4: «Y se quedó mi sofá. Gracias.»

Ejemplo con la pareja, sin tocar su cuerpo:

Diapositiva 1: «Mi pareja es chef con estrella.»
Diapositiva 2: «Cocina de restaurante.»
Diapositiva 3: «Los domingos, si hay ganas.»
Diapositiva 4: «Hoy pedimos pizza. Perdón.»

Qué evitar en los textos: apodos que ridiculicen, referencias a peso, edad, acento, sueldo o vida privada, y cualquier «confesión» que revele algo que la persona no quería contar. El «perdón» debe ser del narrador por exagerar, no una disculpa por exponer a alguien.

Si alguien pide que borres el vídeo

Borra o ponlo en privado primero y habla después. No pidas explicaciones, no negocies y no lo conviertas en un debate público. Si está en varias redes, retíralo de todas; si otra persona lo republicó, pídele que lo quite sin montar un drama. Una disculpa simple funciona mejor que una justificación: «Tienes razón, no lo consulté bien. Ya está borrado». Revisa luego tu proceso y no vuelvas a subir esa foto. Que alguien cambie de opinión no es censura: su imagen sigue siendo suya, incluso si al principio dijo que sí.

Una herramienta, y sus límites

Para montar el formato existe Perdón Studio: es una herramienta en español, pensada primero para ese idioma; hace 3 ediciones con IA y usa la foto original como revelación; exporta un MP4 vertical de 14 segundos; el editor y la exportación son gratis; las ediciones con IA usan créditos desde 5,99 US$ por 5 carruseles, sin suscripción. La herramienta resuelve el montaje, no el consentimiento: eso lo decides tú, persona a persona.

El Perdón trend es un juego breve, y por eso conviene que nadie salga herido. Pide permiso, edita con cuidado, etiqueta las ediciones y escribe textos que puedas enseñar a la persona retratada. Si el chiste no pasa esa prueba, cambia de foto.

Antes de gastar créditos: cómo elegir la foto y planificar cinco carruseles del Perdón trend

Perdón Studio — Thu, 12 Nov 2026 09:10:49 +0000

El Perdón trend («I'm so sorry I lied») se apoya en una sola cosa: la foto original. Las tres ediciones con IA exageran, la cuarta diapositiva revela la verdad, y todo el chiste depende de que esa verdad sea reconocible. Por eso conviene pensar un poco antes de generar nada. Esta guía va de eso: elegir buenas fotos, ordenar ideas y repartir un paquete pequeño de créditos sin desperdiciarlo.

Qué hace falta saber del formato

Un carrusel del Perdón trend tiene cuatro piezas: tres versiones editadas con IA y tu foto original como revelación final. Si lo vas a subir a TikTok, Reels o Shorts, lo más cómodo es convertirlo en un vídeo vertical corto; en Perdón Studio el resultado es un MP4 vertical de 14 segundos. La herramienta está pensada primero en español, aunque el formato también circula en inglés como «sorry trend».

En cuanto al coste: el editor y la exportación son gratis, y solo las ediciones con IA consumen créditos. El paquete de entrada cuesta 5,99 US$ y alcanza para cinco carruseles, sin suscripción. Con esa cifra en mente, lo sensato es tener claras cinco ideas antes de empezar.

Checklist para elegir la foto original

Una cara o un sujeto claro. Si hay cinco personas o el sujeto ocupa una esquina, las ediciones no se leen en el móvil.
Algo «imperfecto» de verdad. El chiste funciona cuando la foto real tiene un detalle humilde: el sofá viejo, el peinado de lunes, el perro despeinado.
Luz decente. No hace falta que sea bonita, pero sí que se vea qué hay en la imagen.
Una foto que te guste compartir. La revelación final es tu foto real; si no quieres que se vea, elige otra.
Encuadre que aguante el vertical. Piensa que el vídeo final es vertical: evita fotos donde lo importante está en los bordes laterales.

Cinco ideas para cinco carruseles

Un paquete de cinco carruseles da para una pequeña serie. Una forma de organizarla:

Tu mascota. El clásico: tres versiones «de revista» y luego el animal tal cual, recién levantado del cojín.
Tu plato de comida. Tres versiones de restaurante con estrella y, al final, el táper de la oficina.
Tu rincón de trabajo. Despacho de diseño, estudio minimalista, oficina con vistas… y la mesa real con tazas acumuladas.
Un viaje. Playa paradisíaca, montaña épica, ciudad de postal, y la foto auténtica en la parada del autobús.
Tú mismo. El formato original del trend: tres versiones idealizadas y tu selfie de siempre al final.

Variar el tema ayuda a que la serie no se repita y te enseña qué tipo de foto genera más reacciones en tu audiencia.

Cómo no desperdiciar créditos

Prepara las cinco fotos antes de generar. Guárdalas en una carpeta y descarta las que no pasen el checklist.
Escribe la idea en una frase. «Mi gato como modelo de pasarela» es más fácil de ejecutar que «algo gracioso con el gato».
Usa el editor gratis para probar. Como el editor y la exportación no cuestan nada, puedes revisar orden y textos sin gastar; los créditos solo se usan en las ediciones con IA.
Publica uno, mira, ajusta. No hace falta lanzar los cinco el mismo día. Publica el primero, fíjate en qué comentan y adapta el siguiente.

Antes de publicar

Repasa el vídeo de 14 segundos completo en el móvil, con el sonido como lo verá tu público. Comprueba que la revelación final se entiende en un segundo y que el texto no tapa la cara ni el detalle gracioso. Si la última diapositiva provoca un «¡ja, era eso!», el carrusel está listo.

En resumen

El Perdón trend es barato de hacer y fácil de repetir, pero la diferencia entre uno olvidable y uno que se comparte está en la foto original y en la idea. Elige cinco fotos con un sujeto claro y un detalle real, ponles una idea en una frase cada una, y reserva los créditos para cuando ya sepas qué quieres contar.