Forem: YMori

transform: translateY(0) Breaks position: fixed — A Hidden Trap in SPA Animations

YMori — Mon, 06 Apr 2026 09:55:09 +0000

The Bug

One day I got this bug report on my Next.js site:

Clicking a photo near the bottom of the gallery opens a lightbox, but it's completely black. Scroll up and the image is there.

A position: fixed; inset: 0 overlay was not covering the viewport — it was stuck at the top of the page. Browser bug? No. This is CSS working exactly as specified.

How to Reproduce

Two ingredients:

An ancestor element with transform set (even translateY(0))
A descendant with position: fixed

/* Page transition animation */
@keyframes page-enter {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: translateY(0); /* The culprit */
  }
}

.page-enter {
  animation: page-enter 0.35s ease both; /* both = keeps final values */
}

// Lightbox (descendant of .page-enter)
<div className="fixed inset-0 z-50 bg-black/90">
  <img src={photo.url} />
</div>

Near the top of the page, everything looks fine. Scroll down and open the lightbox — it renders at the top of the ancestor element, not the viewport.

Why This Happens — The CSS Spec

From MDN's position: fixed documentation:

The element is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property set to something other than none.

Ancestor's `transform`	`fixed` is relative to
`none` or unset	viewport (expected)
`translateY(0)`	that ancestor (broken)
`translateY(12px)`	that ancestor (broken)

translateY(0) is not the same as no transform. It's a transform that moves nothing — but the CSS engine still creates a new containing block.

The `animation-fill-mode: both` Trap

.page-enter {
  animation: page-enter 0.35s ease both;
}

both (forwards + backwards) keeps the final keyframe values after the animation ends. So transform: translateY(0) persists for the lifetime of the element.

The same applies to JavaScript inline styles:

// IntersectionObserver fadeIn component
<div style={{
  transform: visible ? "translateY(0)" : "translateY(16px)",
  // After visible=true, translateY(0) stays forever
}}>
  {children}
</div>

Blast Radius

Every fixed descendant of a transform-bearing ancestor is affected:

Lightboxes / modals
Toast notifications
Cookie consent banners
PWA install prompts
Progress bars
Scroll-to-top buttons

Bottom navs and sticky headers may not visibly break (they sit at viewport edges), but they are technically affected too.

The Fix

1. Use `transform: none` (Most Important)

@keyframes page-enter {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: none; /* Not translateY(0) */
  }
}

<div style={{
  transform: visible ? "none" : "translateY(16px)",
}}>

transform: none means "no transform is applied" — no containing block is created.

2. Use `createPortal` to Escape the DOM Tree (Defensive)

import { createPortal } from "react-dom";

function Lightbox() {
  return createPortal(
    <div className="fixed inset-0 z-50 bg-black/90">
      {/* ... */}
    </div>,
    document.body // Renders at body root — immune to ancestor CSS
  );
}

No matter what ancestors do, the overlay is not affected. This is a best practice for any viewport-covering overlay.

3. Do Both (Recommended)

Fix the root cause with transform: none, and add createPortal as defense-in-depth. If someone later adds a new transform ancestor, overlays still work.

Summary

Don't	Do
Use `translateY(0)` as animation end value	Use `transform: none`
Render `fixed` overlays deep in the DOM tree	Use `createPortal(document.body)`
Add animations without checking `fixed` elements	Audit `fixed` descendants when adding `transform`

translateY(0) and none look identical but behave differently. Miss this spec detail and every overlay on your site breaks the moment you add a page transition animation.

NPB 2021 Backtest: Could a Bayesian Model Predict Last-Place-to-Champion?

YMori — Tue, 24 Mar 2026 02:51:07 +0000

Introduction

In a previous article, I added Bayesian integration to my NPB prediction system. The 8-year backtest showed "97% probability of beating Marcel." But how did it perform in the worst year for predictions?

2021 was NPB's biggest upset: both Yakult (CL) and Orix (PL) went from last place to champions. I ran a full backtest with 25 new foreign players individually projected using FanGraphs and Baseball Savant data.

GitHub: npb-2021-backtest
Main model: npb-prediction

Team Standings: Predicted vs Actual

Central League

Team	Actual	Bayes (no foreign)	Bayes (with foreign)	Foreign Effect
Yakult	73W (1st)	69.5W (4th)	70.7W (4th)	+1.2W (Santana, Osuna)
Hanshin	77W (2nd)	72.8W (2nd)	72.6W (2nd)	-0.2W
Giants	61W (3rd)	83.1W (1st)	84.3W (1st)	+1.2W (Smoak, Thames)

Pacific League

Team	Actual	Bayes (no foreign)	Bayes (with foreign)	Foreign Effect
Orix	70W (1st)	64.5W (6th)	62.0W (6th)	-2.5W (worse)
SoftBank	60W (4th)	77.6W (1st)	76.2W (1st)	-1.4W

MAE: 10.4 wins → 10.7 wins. Foreign player predictions slightly worsened accuracy.

Foreign Player Predictions vs Actual

Accurate Predictions (average MLB players)

Player	Team	Pred OPS	Actual OPS	Diff
Kevin Cron	Carp	.703	.701	-.002
Jose Osuna	Swallows	.683	.694	+.011
Cy Sneed	Swallows	ERA 3.53	ERA 3.41	-0.12

Major Misses (extreme players)

Player	Team	Pred OPS	Actual OPS	Diff
Mike Gerber	Dragons	.862	.352	-.510
Mel Rojas Jr.	Tigers	.867	.663	-.204
Domingo Santana	Swallows	.713	.877	+.164

Gerber had an MLB wOBA of .127 (49.3% K rate) — the model over-regressed toward the mean, predicting .862 OPS when the actual was .352.

Santana was predicted from 84 PA in 2020 (COVID-shortened). His career .757 OPS would have been more predictive.

What Actually Drove the 2021 Standings

Yakult's Championship Run

Player	2020	2021	Change
Tetsuto Yamada	OPS .766	OPS .885	+.119
Domingo Santana	—	OPS .877	New signing
Noboru Shimizu	ERA 3.54	ERA 2.39	-1.15

Orix's Championship Run

Player	2020	2021	Change
Yutaro Sugimoto	OPS .695	OPS .931	+.236 (HR King at 31)
Hiroya Miyagi	—	ERA 2.51 (147IP)	20-year-old, 13 wins
Yoshinobu Yamamoto	ERA 2.20	ERA 1.39	-0.81 (Sawamura Award)

Sugimoto and Miyagi's breakouts were impossible to predict from past data. This is a structural change, not a statistical fluctuation.

Giants Collapse (Predicted 84.3W → Actual 61W)

Sugano (ERA 1.97→3.19), Sakamoto (OPS .844→.657), Maru (OPS .899→.775) — three stars declining simultaneously. The Bayesian model trusted their skill metrics and predicted even higher than Marcel.

Key Findings

Average MLB players predicted well (Cron .703 vs .701 actual)
Extreme players over-regressed (Gerber .862 vs .352) → need regression limits
Single-year small samples mislead (Santana's 84 PA in 2020) → use career stats
Bad MLB pitchers stay bad in NPB (Sparkman 6.02→3.88 pred→6.88 actual)
2021 was driven by Japanese player breakouts, not foreign players

Conclusion

Individual foreign player projections improve accuracy for "average" players but carry risk for extreme cases. In 2021, Japanese player breakouts and collapses determined the standings — foreign player predictions had minimal impact (MAE +0.3 wins).

This is a personal hobby project. There may be oversights in data collection and verification.

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records
FanGraphs — MLB wOBA/K%/BB%
Baseball Savant — MLB Statcast
Baseball Reference — MLB/MiLB stats

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction App

YMori — Mon, 23 Mar 2026 21:48:12 +0000

Introduction

I've been running a personal NPB (Japanese pro baseball) prediction app:

Dashboard: npb-prediction.streamlit.app
GitHub: npb-prediction

It used Marcel projections (3-year weighted average) and ML (XGBoost/LightGBM). Decent, but I wanted better accuracy. After adding Bayesian corrections, the predicted standings changed significantly.

Terms

Term	Meaning
Marcel	Predict next year from weighted average of past 3 years
Bayesian	Combine prior knowledge with data. Gives uncertainty estimates
CI	Credible interval — range where the true value falls with 80%/95% probability
OPS	On-base + Slugging. Overall batting metric
ERA	Earned Run Average. Runs allowed per 9 innings
MAE	Mean Absolute Error. Average prediction miss. Lower = better

Problems with the Previous Approach

Problem 1: All Foreign Players Treated as "Average"

Marcel needs 3 years of NPB data. First-year foreign players have none, so all 24 of them were treated as league-average. Dalbec (Giants, .355 wOBA in MLB) and Hummel (BayStars, .240 wOBA) were calculated identically.

Problem 2: Skill Metrics Ignored

Marcel averages past results directly. Two players with OPS .800 might have very different K% and BB% profiles, which affects how stable their performance will be next year.

Problem 3: No Uncertainty

"Maki's OPS: .812" gives no sense of how much it might vary. The difference between .750-.870 and .790-.830 matters a lot for team projections.

What Changed with Bayesian Integration

Foreign Players: Average → Individual Predictions

Built a model to convert MLB/KBO stats to NPB projections. For example, a .350 wOBA MLB hitter maps to approximately .350 × 1.235 = .432 NPB-equivalent wOBA.

All 24 players' names and prior-league stats were individually web-verified (guessing English names from katakana is surprisingly error-prone).

Foreign hitter examples:

Player	Team	Prior wOBA	NPB Pred OPS	80% CI
Sano	Dragons	.370	.760	.632–.889
Seymour	Buffaloes	.365	.735	.607–.863
Dalbec	Giants	.355	.725	.577–.884
Hummel	BayStars	.240	.694	.530–.849

Foreign pitcher examples:

Player	Team	Prior ERA	NPB Pred ERA	80% CI
Quijada	Swallows	3.26	2.76	1.28–4.24
Hjelle	Buffaloes	3.90	3.34	1.05–5.59
Cox	BayStars	8.86	3.36	1.82–4.85

Players with poor prior-league stats get pulled toward league average (Bayesian regression effect), but with wider CIs = lower confidence.

Japanese Players: K%/BB%/BABIP Corrections

Three models combined into a final prediction:

Model	Weight	Notes
Marcel	35%	Strong baseline, especially for pitcher ERA
Bayesian correction	40%	K%/BB%/BABIP/age adjustment on top of Marcel
ML	25%	XGBoost/LightGBM

Did Accuracy Improve?

8-year backtest (2018–2025, predict each year and compare to actual):

Metric	Marcel MAE	Bayesian MAE	Improvement prob.
Hitter wOBA	0.05023	0.04980	97.1%
Pitcher ERA	1.23008	1.22241	97.1%

Small improvement, but consistent — 97% probability of beating Marcel across 8 years.

Historical Marcel Accuracy for Context

Overall (8 years × 12 teams = 96 team-years):

Metric	Value
Wins MAE	6.4 wins
Avg rank error	1.42 positions
Exact rank rate	18%
Within 1 rank	65%

Recent examples of Marcel misses:

Year	Team	Actual	Predicted	Miss
2025	Swallows (CL)	57W (6th)	72W (4th)	+15
2024	SoftBank (PL)	91W (1st)	75W (2nd)	-16
2024	Buffaloes (PL)	63W (5th)	78W (1st)	+15

Patterns:

Overestimates bottom teams, underestimates top teams (regression to mean)
Can't predict collapses (2024 Buffaloes: defending champions → 5th place)
Foreign player impact not captured when all treated as average

How Did the 2026 Standings Change?

Central League — Tigers Runaway Disappears, 4-Team Deadlock

Team	Marcel	Bayesian	Diff	P(Pennant)
Tigers	80.1W (1st)	71.5W (1st)	-8.6	26.0%
Giants	70.7W (3rd)	71.1W (2nd)	+0.4	20.2%
Dragons	68.8W (5th)	71.0W (3rd)	+2.2	21.2%
BayStars	71.3W (2nd)	70.7W (4th)	-0.6	20.2%
Carp	70.4W (4th)	69.1W (5th)	-1.3	12.3%
Swallows	64.3W (6th)	61.2W (6th)	-3.1	0.1%

Tigers dropped from 80.1W to 71.5W (-8.6). Skill corrections pulled them down. Giants at 71.1W even after losing Okamoto to MLB. Four teams within 0.8 wins — Tigers 26%, Dragons 21%, Giants 20%, BayStars 20%. Swallows at 61.2W (78% last place) after Murakami's MLB departure.

Pacific League — Lions Surge

Team	Marcel	Bayesian	Diff	P(Pennant)
Hawks	80.5W (1st)	81.3W (1st)	+0.8	47.9%
Fighters	76.8W (2nd)	79.1W (2nd)	+2.3	27.2%
Buffaloes	73.8W (3rd)	77.5W (3rd)	+3.7	17.6%
Lions	68.6W (4th)	74.9W (4th)	+6.3	7.1%
Eagles	65.5W (5th)	66.7W (5th)	+1.2	0.1%
Marines	67.1W (6th)	64.9W (6th)	-2.2	0.1%

Lions +6.3 wins — foreign player projections offsetting Imai's MLB departure.

Summary

Problem	Before	After
Foreign players	All league-average	24 individual projections from prior-league stats
Skill metrics	Not used	K%/BB%/BABIP corrections on Marcel
Uncertainty	None (point estimates)	80%/95% credible intervals on every prediction
Team standings	Single number	10,000 Monte Carlo sims with pennant probabilities
Accuracy	Marcel MAE 0.050	0.0498 (97% probability of improvement)

The accuracy gain is modest, but "foreign players are no longer invisible," "MLB departures are reflected," and "every prediction comes with uncertainty" meaningfully changed the standings picture. The CL went from "Tigers runaway" to a four-team deadlock.

Caveat: Data Limitations

During this work, I discovered that players who moved to MLB (Murakami, Okamoto) were still included in the team simulation — the roster filter only existed in the Streamlit display layer, not in the CSV generation pipeline. Fixed and regenerated, but there may be other oversights I haven't caught.

This is a personal project without professional-grade QA. The data is best treated as automated model output, not authoritative predictions.

Dashboard: npb-prediction.streamlit.app
GitHub: github.com/yasumorishima/npb-prediction

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction System

YMori — Mon, 23 Mar 2026 20:55:48 +0000

Introduction

In a previous article, I documented my journey adding Bayesian regression (Stan/Ridge) to my NPB (Japanese pro baseball) prediction system.

Previous article: Beyond Marcel: Adding Bayesian Regression to NPB Predictions

That work lived in a separate experiment repository (npb-bayes-projection). This article covers adding those pieces into the main app — a 7-phase process that touched 19 files and added 4,087 lines.

GitHub: npb-prediction
Live dashboard: npb-prediction.streamlit.app

Before: Point Estimates Only

Marcel (3-year weighted avg) → ML (XGBoost/LightGBM)
    ↓                              ↓
  Point estimate               Point estimate
    ↓
Pythagorean Win% → Team standings

Problems:

No uncertainty quantification
24 new foreign players treated as league-average (wRAA=0)
Marcel and ML run independently — no ensemble
Team standings are a single number with no confidence interval

After: Bayesian Ensemble + Monte Carlo

Layer 1: Marcel (unchanged)
    ↓
Layer 2: Stan Bayesian correction
  - Japanese: Ridge correction via K%/BB%/BABIP/age
  - Foreign: Prior-league stats × league-specific conversion (Stan v2)
    ↓
Layer 3: ML (XGBoost/LightGBM)
    ↓
Layer 4: BMA (Bayesian Model Averaging)
  - Marcel 35% + Stan 40% + ML 25%
  - 80%/95% credible intervals on every prediction
    ↓
Monte Carlo 10,000 draws → Team win distributions
  - P(pennant) / P(Climax Series) / P(last place)

The 7 Phases

Phase 1: Japanese Player Bayesian Inference

The key design decision: Stan does not run at inference time.

cmdstanpy is heavy to install and won't fit on a Raspberry Pi 5 (4GB RAM). Instead, I pre-compute posterior parameters into posteriors.json during training (in GitHub Actions), then sample with NumPy at runtime.

# posteriors.json structure (hitter example)
{
  "japanese_hitter": {
    "beta": [0.152, -0.089, -0.245, -0.003],
    "sigma_residual": 0.06215,
    "feature_names": ["K_pct", "BB_pct", "BABIP", "age_from_peak"]
  }
}

# Runtime sampling (milliseconds, not seconds)
z = (features - scaler_mean) / scaler_std
correction = beta @ z
samples = marcel_value + correction + rng.normal(0, sigma, size=5000)
ci_80 = np.percentile(samples, [10, 90])

Phase 2: Foreign Player Stan v2 Predictions

The most labor-intensive phase. I had to web-verify all 24 foreign players individually:

Katakana name → correct English name
Origin league (MLB / KBO / independent)
Most recent season stats

Lesson learned: Never guess English names from katakana.

Over 10 of my initial 28 guesses were wrong:

NPB Name	Initial Guess	Correct
Dalbec	Spencer Torkelson	Bobby Dalbec
Jerry	Sean Gerry	Sean Hjelle
Lucas	Josh Lucas	Easton Lucas

I also misidentified 4 Japanese draft picks (with katakana names) as foreign players. The rule: verify every single entry via web search before committing.

Phase 3: Monte Carlo Team Simulation

Player-level uncertainty propagates to team-level through 10,000 independent simulations:

for sim in range(10000):
    for team in teams:
        rs = sum(sample_hitter_runs(h) for h in team.hitters)
        ra = sum(sample_pitcher_runs(p) for p in team.pitchers)
        rs, ra = apply_park_factor(rs, ra, team)
        wins[team][sim] = 143 * rs**1.83 / (rs**1.83 + ra**1.83)

Foreign players get 1.5x sigma (wider uncertainty since they have no NPB data).

Phase 5: API Integration

Three new FastAPI endpoints:

Endpoint	Description
`/predict/hitter/{name}`	Bayesian OPS + 80%/95% CI (added to existing)
`/predict/foreign/{name}`	Foreign player Stan v2 projections (new)
`/standings/simulation`	Monte Carlo team standings (new)

Phase 6: Streamlit Integration

The largest phase — added ~370 lines to the 1,669-line streamlit_app.py:

Bayesian CI bars on existing prediction pages (Plotly overlay bars for 80%/95% intervals)
Team Simulation page (new) — fan chart + probability table
Foreign Players page (new) — prior-league stats + NPB projection with CI

Phase 7: BigQuery Integration

Added 8 tables (25 → 33 total): Bayesian predictions, foreign player data, simulation results, and conversion factors.

Technical Decisions

posteriors.json vs. cmdstanpy at runtime

	posteriors.json	cmdstanpy runtime
Inference speed	NumPy only (ms)	Stan call (seconds)
Memory	Few KB	Hundreds of MB
Updates	Annual retraining via GitHub Actions	Fit every time

For a system running on RPi5 with 4GB RAM, this was the only viable option. With annual data updates, there's no need to re-fit on every request.

BMA Weight Rationale

Marcel 35% + Stan 40% + ML 25% was determined by 8-year LOO-CV:

Stan correction improved Marcel 97.1% of the time (bootstrap)
ML matched Marcel on hitter OPS but underperformed on pitcher ERA
The 3-model BMA was more robust than any single model

The Full-Width Space Trap

Marcel CSVs used full-width spaces (U+3000) in player names while sabermetrics CSVs used half-width spaces. This caused 237 of 463 players to fail matching until I normalized with a player_join column.

Results

Metric	Value
New files	12 (2 Python + 10 data)
Modified files	7
Lines added	+4,087
BigQuery tables	25 → 33
Streamlit pages	7 → 9
Foreign players individually projected	0 → 24

The system moved from point estimates to probability distributions. "The Giants have a 42.6% chance of winning the pennant" is more useful than "The Giants are projected to win 74 games."

Takeaways

Moving experiment code into an app has its own challenges, distinct from the experiments themselves:

Data quality matters more than model quality. Incorrect foreign player names/stats would have propagated through the entire pipeline
Design for your runtime constraints. posteriors.json lets a 4GB RPi5 do Bayesian inference
Uncertainty visualization needs thought. CI bars, fan charts, and probability tables each communicate different aspects of the same distributions

Phase 4 (automated Stan retraining pipeline) remains for next season. But the prediction system now runs Bayesian ensemble predictions end-to-end, from individual players to team championship probabilities.

Dashboard: npb-prediction.streamlit.app
GitHub: github.com/yasumorishima/npb-prediction

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records

5 Pitfalls of Grafana + BigQuery — When Your Dashboard Shows Nothing

YMori — Sun, 22 Mar 2026 05:37:11 +0000

Introduction

I built 7 Grafana dashboards (70+ panels) on Grafana Cloud with BigQuery as the data source. Along the way, I hit multiple issues where queries returned data through the API but panels showed nothing in the UI.

Here are the 5 pitfalls I encountered and how to fix them. Verified on Grafana 13 + BigQuery datasource plugin.

1. Non-ASCII Column Aliases Need Backticks

Symptom

Syntax error: Illegal input character

Cause

If you use non-ASCII characters (e.g., Japanese, Chinese) in column aliases, they must be wrapped in backticks.

-- Fails
SELECT team AS チーム, HR AS 本塁打 FROM ...

-- Works
SELECT team AS `チーム`, HR AS `本塁打` FROM ...

This also applies to mixed ASCII + non-ASCII aliases like K率 and references in GROUP BY / ORDER BY clauses.

2. BigQuery Datasource Doesn't Support `format: "time_series"`

Symptom

error unmarshaling query JSON to the Query Model: invalid format value: time_series

Fix

Always use format: "table". For time series data, return a TIMESTAMP column named time — Grafana auto-detects it.

SELECT CAST(date AS TIMESTAMP) AS time, value FROM ...

3. Historical Data in Timeseries Panels Shows "Data outside time range"

Symptom

Panel displays "Data outside time range" with a "Zoom to data" button.

Cause

Timeseries panels filter by the dashboard time range (e.g., "Last 6 hours"). Historical data from 2015–2025 falls outside this range.

Fix

Use barchart panels for historical aggregations. Return the year as a string:

SELECT CAST(year AS STRING) AS year, value FROM ...

4. Extra fieldConfig Properties Can Break Barchart Rendering

Symptom

Barchart panel is completely blank. No error message. Query returns data when tested directly.

Cause

In Grafana 13, adding color, decimals, unit, or custom.axisLabel to fieldConfig.defaults can silently prevent barchart rendering.

// Broken — renders nothing
"fieldConfig": {
  "defaults": {
    "color": {"fixedColor": "#5470c6", "mode": "fixed"},
    "decimals": 0,
    "unit": "none"
  }
}

// Works
"fieldConfig": {
  "defaults": {},
  "overrides": []
}

Start with minimal config, verify it renders, then add properties one at a time.

5. Panels Inside Expanded Row's `panels` Array Are Invisible

Symptom

Panels exist in the dashboard JSON but don't appear in the UI.

Cause

Grafana row panels have two modes:

Collapsed (collapsed: true): child panels stored in the row's panels array
Expanded (collapsed: false): child panels must be top-level siblings after the row. The row's panels array must be empty.

If collapsed: false but the panels array still contains panels, those panels are invisible.

// Broken — panels inside expanded row are hidden
{
  "type": "row",
  "collapsed": false,
  "panels": [{"type": "barchart", "title": "Hidden Panel"}]
}

// Fixed — panels at top level after the row
{"type": "row", "collapsed": false, "panels": []},
{"type": "barchart", "title": "Visible Panel"}

Also check gridPos.y — if a panel's Y position is above its row header, it won't appear in the expected section.

Conclusion

Grafana + BigQuery is a powerful combination, but building dashboards via the API exposes issues you'd never encounter through the UI editor. The hardest to debug: "query is correct but panel is blank." Hope this saves you some time.

Moving an NPB Prediction System to BigQuery — BQML and Cloud Run on the Free Tier

YMori — Sun, 22 Mar 2026 00:34:23 +0000

Background

I've been running an NPB (Japanese professional baseball) player performance prediction project for over a year.

→ Previous articles:

The setup was: GitHub Actions fetches data → trains models → saves CSVs → Streamlit displays results. Data lived in CSVs, the API ran on a Raspberry Pi 5 Docker container, and analysis was done in local Python.

I added Google BigQuery to centralize the data, run SQL analysis, compare BQML accuracy against Python ML, and deploy the API to Cloud Run. Everything fits within GCP's free tier.

→ GitHub: https://github.com/yasumorishima/npb-prediction

Why BigQuery

Pain points with the CSV-based setup:

Full re-fetch every run — The annual pipeline re-downloads all data from scratch. No incremental updates
Cross-analysis was tedious — JOINing hitter stats with park factors meant writing pandas merge code every time
Wanted SQL access — Quick queries like "wRC+ TOP 10" or "age curve peak" required writing Python each time
Wanted to try BQML — How far can SQL-only ML go compared to Python?

Architecture

GitHub Actions (Annual Pipeline)
  ├── Data fetch (baseball-data.com / npb.jp)
  ├── Marcel projections
  ├── ML projections (XGBoost / LightGBM)
  ├── load_to_bq.py → BigQuery 25 tables
  ├── bqml_train.py → BQML 4 models
  └── Cloud Run deploy (on master merge)

BigQuery (npb dataset)
  ├── Raw data: 15 tables
  ├── Predictions: 4 tables
  ├── Metrics: 6 tables
  ├── BQML: 4 models
  └── Analysis views: 10

Display layer
  ├── Streamlit Cloud (dashboard)
  ├── Cloud Run API (serverless)
  └── Raspberry Pi 5 API (always-on)

Loading Data to BigQuery

load_to_bq.py loads CSV files into BigQuery.

RAW_TABLE_MAP = {
    "npb_hitters_2015_2025.csv": "raw_hitters",
    "npb_pitchers_2015_2025.csv": "raw_pitchers",
    "npb_batting_detailed_2015_2025.csv": "raw_batting_detailed",
    "npb_sabermetrics_2015_2025.csv": "sabermetrics",
    # ... 25 tables
}

NPB data has column names like K%, BB%, HR/9 which BigQuery doesn't accept. The loader sanitizes them:

new = new.replace("%", "_pct")
new = new.replace("/", "_per_")
new = re.sub(r"[^a-zA-Z0-9_]", "_", new)

All tables use WRITE_TRUNCATE (full replace) on each run, so schema changes are handled automatically.

BQML: ML with SQL Only

BigQuery ML lets you build features with SQL window functions and train models with CREATE MODEL.

Training View (Feature Engineering)

CREATE OR REPLACE VIEW `npb.v_batter_train` AS
WITH base AS (
  SELECT player, season, OPS, wOBA, K_pct, BB_pct, Age, PA, ...
  FROM `npb.raw_hitters`
  WHERE PA >= 100
),
lagged AS (
  SELECT
    player, season,
    LAG(OPS, 1) OVER w AS OPS_y1,
    LAG(wOBA, 1) OVER w AS wOBA_y1,
    LAG(OPS, 2) OVER w AS OPS_y2,
    LAG(OPS, 1) OVER w - LAG(OPS, 2) OVER w AS OPS_delta,
    LAG(Age, 1) OVER w - 27 AS age_from_peak,
    POW(LAG(Age, 1) OVER w - 27, 2) AS age_sq,
    OPS AS target_ops
  FROM base
  WINDOW w AS (PARTITION BY player ORDER BY season)
)
SELECT * FROM lagged WHERE OPS_y1 IS NOT NULL;

The same lag features, deltas, and age curves I had in Python, reimplemented as SQL window functions.

Model Training

CREATE OR REPLACE MODEL `npb.bqml_batter_ops`
OPTIONS(
  model_type = 'BOOSTED_TREE_REGRESSOR',
  input_label_cols = ['target_ops'],
  max_iterations = 200,
  learn_rate = 0.05,
  early_stop = TRUE
) AS
SELECT OPS_y1, wOBA_y1, K_pct_y1, BB_pct_y1,
       age_from_peak, age_sq, OPS_delta, ...
FROM `npb.v_batter_train`;

4 models total:

Model	Target	Type
`bqml_batter_ops`	Next-year OPS	Boosted Tree
`bqml_batter_ops_linear`	Next-year OPS	Linear Regression
`bqml_pitcher_era`	Next-year ERA	Boosted Tree
`bqml_pitcher_era_linear`	Next-year ERA	Linear Regression

BQML vs Python ML Accuracy

Same data, same evaluation period, MAE comparison.

Batter OPS MAE (lower is better)

Model	MAE
BQML Boosted Tree	.0642
Python (XGBoost)	.063
Python (LightGBM)	.066
Marcel	.063

Pitcher ERA MAE (lower is better)

Model	MAE
BQML Boosted Tree	.909
Python (XGBoost)	.93
Python (LightGBM)	.92
Marcel	.78

BQML performed comparably to Python ML. For pitcher ERA, both fall short of Marcel (0.78) — an ongoing challenge for ML approaches.

BQML uses more features (park factors, DIPS metrics, Marcel weighted averages), which may contribute to its Boosted Tree performance.

Analysis Views

10 views for my own analysis use:

View	Purpose
`v_batter_trend`	Player OPS/wOBA trends by season
`v_pitcher_trend`	Player ERA/WHIP trends + FIP approximation
`v_team_pythagorean`	Team win% vs Pythagorean expectation
`v_sabermetrics_leaders`	wRC+ leaderboard by season
`v_marcel_accuracy`	Marcel historical accuracy validation
`v_age_curve`	NPB-wide age curve (OPS × age)
`v_park_effects`	Park factor impact analysis
`v_data_coverage`	Season-by-season data coverage
`v_data_quality`	Per-table NULL/missing value summary

For example, checking "2025 wRC+ TOP 10" or "age curve peak" now takes SQL instead of writing pandas code.

-- Example query from my environment
SELECT player, team, season, wRC_plus, wOBA, OPS
FROM `npb.v_sabermetrics_leaders`
WHERE season = 2025
ORDER BY wrc_rank
LIMIT 10;

Cloud Run Deployment

Deployed the existing FastAPI to Cloud Run.

FROM python:3.12-slim
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["uvicorn", "api:app", "--host", "0.0.0.0", "--port", "${PORT:-8080}"]

Merging to master triggers automatic deployment via Artifact Registry.

The same API runs on both the Raspberry Pi 5 Docker container and Cloud Run.

Free Tier Usage

Everything runs within GCP's free tier.

Resource	Free Tier	Usage	% Used
Storage	10 GB/mo	~5 MB	0.05%
Queries	1 TB/mo	~22 GB	2.2%
Cloud Run	2M requests/mo	minimal	≈0%

Daily BigQuery usage monitoring with projected month-end pace is sent to Discord.

GitHub Actions Pipeline

The annual pipeline (annual_update.yml) now includes BigQuery loading, BQML training, and Cloud Run deployment.

Step 1: fetch_npb_data.py       → Scrape hitter/pitcher stats
Step 2: fetch_npb_detailed.py   → Detailed batting stats (for wOBA)
Step 3: pythagorean.py          → Standings + Pythagorean win%
Step 4: sabermetrics.py         → wOBA/wRC+/wRAA calculation
Step 5: marcel_projection.py    → Marcel projections
Step 6: ml_projection.py        → ML projections + model save
Step 7: git commit & push       → Auto-commit data/
Step 8: load_to_bq.py           → Load all data to BigQuery  ← NEW
Step 9: bqml_train.py           → BQML train & evaluate      ← NEW

BQML steps use continue-on-error: true, so BigQuery issues don't break the Python ML pipeline.

Takeaways

BQML accuracy was comparable to Python. Writing features as SQL window functions takes getting used to, but views make them reusable
Analysis views are quietly useful. SQL replaces pandas for routine queries
At ~40,000 rows, free tier usage is negligible
Having the API on both Cloud Run and RPi5 means one can go down without losing service

Monitoring the Strait of Hormuz Blockade with Open AIS Data and a Raspberry Pi

YMori — Sun, 15 Mar 2026 23:57:21 +0000

Data scope disclaimer: All data in this article comes from aisstream.io's terrestrial AIS receivers. Coverage in open water (mid-strait) is limited; satellite AIS would provide a more complete picture. All figures are from mid-March 2026 and the situation is evolving daily.

What This Is

In March 2026, shipping through the Strait of Hormuz — through which roughly 20% of the world's oil passes — was reported to be severely restricted. I built a monitoring system to observe this using free AIS (Automatic Identification System) data and a Raspberry Pi 5.

This post covers the system architecture, the analytics pipeline, and what the data shows within the limitations of terrestrial AIS coverage.

Repository: yasumorishima/hormuz-ship-tracker

Auto-generated snapshot (every 6 hours). Shows gate line positions, transit IN/OUT stats, and vessel type distribution. Note the concentration around UAE ports and the near-empty strait center.

AIS Data

AIS is a maritime safety system where vessels automatically broadcast their position, speed, course, name, and type over VHF radio. It's mandatory for international vessels over 300 gross tonnage.

aisstream.io aggregates terrestrial AIS receiver data worldwide and streams it via a free WebSocket API. This is the data source for this project.

Architecture

aisstream.io (WebSocket)
  → Collector (AIS receiver + land filter + SQLite)
  → Analytics Engine (gate-line transit detection + vessel classification)
  → FastAPI + Leaflet.js + Chart.js (dashboard)
  → matplotlib (6-hourly snapshot → GitHub auto-push)

Two Docker containers run 24/7 on a Raspberry Pi 5: the main collector/API and a snapshot cron job.

What the Data Shows

67% Anchored Ratio (mid-March 2026)

Of ~290 monitored vessels, about 67% were stationary (speed < 0.5 knots). In a typical port area, this ratio is usually around 30–40%. The elevated value is notable.

35 Vessels Waiting 6+ Hours (mid-March 2026)

Vessels that haven't moved for over 6 hours are counted as the "waiting fleet." About 35 vessels met this criterion, with 11 stuck for over 24 hours.

Waiting fleet flags (estimated from MMSI MID):

Flag	Count
Panama	9
Marshall Islands	3
UAE	3
Kuwait	2
Others	1 each

Panama and Marshall Islands are open registries — commonly used by large commercial ships and tankers. Seven tankers were among the waiting fleet.

Near-Zero Strait Transits on Terrestrial AIS (mid-March 2026)

A virtual gate line across the narrowest point of the Strait of Hormuz detects vessel crossings automatically. Only 1 transit was detected in 24 hours.

Important caveat: this only reflects what aisstream.io's terrestrial AIS receivers can capture. Coverage in mid-strait open water is limited. News reports indicate some vessels (Turkish, Indian, Saudi-flagged) have been allowed limited passage — these may not appear in terrestrial AIS data. "No data" does not equal "no ships." This caveat applies to all figures in this article.

Traffic Concentrated Around UAE Coast (mid-March 2026)

Most data clusters around Dubai, Jebel Ali, and Fujairah. Three gate lines capture port approach traffic:

Gate	Inbound	Outbound
Dubai / Jebel Ali Approach	20	9
Fujairah Approach	0	7
Strait of Hormuz	0	1

Dubai inbound significantly exceeds outbound. Fujairah shows only outbound traffic — likely vessels departing after bunkering (refueling).

Technical Implementation

Gate-Line Transit Detection

Virtual gate lines (line segments) are defined at the strait and port approaches. For each vessel, consecutive position reports are checked for intersection with each gate using computational geometry:

def segments_intersect(p1, p2, p3, p4):
    d1 = cross_product(p3, p4, p1)
    d2 = cross_product(p3, p4, p2)
    d3 = cross_product(p1, p2, p3)
    d4 = cross_product(p1, p2, p4)
    if ((d1 > 0 and d2 < 0) or (d1 < 0 and d2 > 0)) and \
       ((d3 > 0 and d4 < 0) or (d3 < 0 and d4 > 0)):
        return True
    return False

Direction (INBOUND/OUTBOUND) is determined by the sign of the cross product relative to the gate vector. Same-vessel crossings within 6 hours are deduplicated.

Data-Driven Situation Assessment

All dashboard text is auto-generated from data patterns. The system classifies the situation level based on strait transits, anchored ratio, and waiting fleet size:

if strait_transits == 0 and anchored_pct > 40:
    return {"level": "critical", "title": "Strait Transit Suspended"}
elif 0 < strait_transits <= 5:
    return {"level": "elevated", "title": "Limited Strait Transit"}
else:
    return {"level": "normal", "title": "Monitoring Active"}

When conditions normalize, the UI automatically shifts to normal mode — no hardcoded crisis messaging.

MMSI → Flag Mapping

Since aisstream.io's metadata doesn't reliably include country codes, flags are derived from the first 3 digits of the 9-digit MMSI number (Maritime Identification Digits). The system maps 100+ MIDs to countries.

Destination Normalization

AIS destination fields are free-text and wildly inconsistent (DUBAI, AE DXB, AEDXB, DMC DUBAI, etc.). Over 40 variants are mapped to canonical port names.

4-Day Data Analysis Update (March 18)

After 4 days of continuous collection (43,000+ position records, 384 unique vessels), several new insights emerged.

Traffic Density Heatmap

Left: Full Gulf hexbin density. Right: Zoomed strait with AIS dead zone. Bottom: Port area, flag state, and vessel type breakdowns.

Metric	Value
Clean positions	36,000
Anomalous (filtered)	7,300 (17%)
Unique vessels	384
Strait crossings confirmed	0
Dubai / Jebel Ali gate crossings	61

Timelapse — 24 Hours of Vessel Movement

24-hour vessel movement animation. Positions are linearly interpolated between data points, with land-crossing prevention.

AIS Data Quality: What the Anomalies Actually Are

About 17% of positions contained anomalous data. Two distinct patterns were identified:

Anomaly	Count	Cause
Speed = 102.3 kn	~3,200	AIS protocol "not available" sentinel (10-bit 0x3FF)
Speed 40–99 kn	~4,100	Coastal receiver decode errors

The ~48 kn cluster was particularly interesting: on 2026-03-16 at 07:00 UTC, 4 vessels simultaneously appeared at the same coordinates in the strait with identical speeds. This was a single receiver malfunction — no ships were actually there. These anomalies had produced 41 false transit detections, which were eliminated by filtering positions with speed >= 40 kn.

The dashboard now shows anomalous vessels with red dashed markers and a "DATA QUALITY WARNING" popup.

Browser-Based Replay

The /replay endpoint provides a Leaflet.js animated replay with play/pause, speed control (0.25x–16x), timeline scrubbing, and keyboard shortcuts.

Limitations

Terrestrial AIS coverage: Free aisstream.io data comes from shore-based receivers. Open-water coverage (mid-strait) is limited
AIS speed 102.3 knots: The "not available" sentinel value (0x3FF). Must be filtered
Speed 40–99 kn receiver glitches: Coastal receiver decode errors produce phantom positions. Transit detection filters speed >= 40 kn
Collection period: Ongoing collection. Longer-term trend analysis requires further accumulation

Summary

Using aisstream.io's free API and a Raspberry Pi 5, this system continuously collects and analyzes vessel traffic across the entire Persian Gulf. After 4 days, 43,000+ positions have been collected, with heatmap visualization, timelapse animation, and data quality analysis fully implemented.

Statistics are auto-updated every 6 hours.

Live Statistics (auto-updated) / Repository

Data source: aisstream.io / Land polygons: Natural Earth

I Built a WBC Quarterfinal Scouting App with MLB Statcast Data

YMori — Fri, 13 Mar 2026 16:58:40 +0000

What I Built

A Streamlit scouting dashboard for the WBC 2026 Quarterfinal: Japan vs Venezuela.

App: https://wbc-qf-jpn-ven.streamlit.app/
GitHub: https://github.com/yasumorishima/wbc-scouting

For the pool round, I built 30 team-level dashboards (20 teams). But quarterfinals are head-to-head matchups — you want to know "which pitch type is effective against this batter?" and "which zone has the highest opponent BA against this pitcher?" in one place.

5-Tab Structure

🎯 Tab 1: Matchup Preview

Venezuela's predicted starting lineup (9 batters) table, an alert for Machado (NPB player, no Statcast data), and a bench/pinch-hit candidates table.

Each batter expands into a full scouting report:

6 key metrics (AVG/OBP/SLG/OPS/K%/BB%) with MLB average comparison
Radar chart (5-axis, MLB average line overlay)
Zone heatmaps (3x3, 5x5) — BA and xwOBA by zone, split by vs LHP/RHP
Spray charts — split by vs LHP/RHP

Platoon splits (OPS/AVG/K%/BB% side by side)
Pitching plan — overall + vs LHP + vs RHP. Auto-generated from pitch type whiff rates, zone-level BA, count-split OPS, and platoon data
Defensive positioning — auto-generated from spray angle, ground ball rate, and exit velocity, split by pitcher handedness
Pitch type performance table (BA, SLG, Whiff%, Chase%)
Count-based performance (color-coded: green=hitter ahead, red=behind, amber=even)

At the bottom, there's a full analysis section for the starting pitcher (Ranger Suárez, LHP) with hitting approach (as LHB/RHB), arsenal table, movement chart, location heatmaps, platoon splits, and pitch selection by count — all in collapsible expanders.

📋 Tab 2: Game Plan

Statcast data organized by game phase:

Team weakness detection — batters with K% ≥ 22.4% (MLB avg), BB% < 8.3%, or platoon OPS gap ≥ 80 pts, auto-extracted with player names and values
Innings 1-3 vs Suárez (starter) — Batting: SP's K%/BB%/Whiff%/velocity and pitch mix. Pitching: per-batter AVG/K%/BB% grouped by lineup position (#1-3, #4-6, #7-9)
Innings 4-5 (2nd time through or bullpen transition) — Batting: bridge reliever stats. Pitching: MLB league-wide trend (opp OPS rises 15-20% on 2nd time through) plus batter classification by K% and BB%
Innings 6+ (high-leverage) — Batting: closer/setup K%/Whiff%/Chase%/velocity with pitcher type classification. Pitching: platoon matchup data for batters with significant splits, full per-batter stat line
Pinch-hit candidates — bench player AVG/OPS/K%

Every piece of text is driven by MLB Statcast numbers only. No coaching instructions — just data.

⚔️ Tab 3: Lineup Scouting

Team batting radar chart at the top (AVG/OBP/SLG/K%/BB%, 5-axis, MLB average line overlay). Below that, a full roster table and a dropdown selector for individual player analysis (metrics, scouting summary, pitching plan, defensive positioning, radar chart, zone heatmaps, spray charts, etc.).

🎱 Tab 4: Starting Pitcher Analysis

Ranger Suárez's pitching data. Metric cards (avg velocity, avg spin, whiff%, chase%, put away%, opp avg, etc.) and scouting summary, plus collapsible expanders for:

Hitting approach (as LHB / as RHB)
Arsenal table (velocity mph/km/h, break, whiff%, put away%) + movement chart
Pitch location heatmap + platoon splits
Pitch selection by count (donut charts) + count-based performance

🔥 Tab 5: Bullpen Scouting

Bullpen overview (all relievers' ERA, K%, velocity in one info box), then a dropdown selector for individual reliever analysis. Same structure as Tab 4 (metric cards, scouting summary, hitting approach, arsenal, heatmaps, count analysis).

Technical Highlights

Dynamic text generation from raw Statcast data

Six generator functions compute per-player analysis from pitch-by-pitch data:

Function	Purpose
`generate_player_summary()`	Batter scouting summary (strengths/weaknesses)
`generate_pitcher_summary()`	Pitcher scouting summary
`generate_pitching_plan()`	How to pitch to a batter (pitch types, zones, counts, platoon)
`generate_hitting_plan()`	How to hit a pitcher (hittable pitches, zones, counts)
`generate_defensive_positioning()`	Infield/outfield shift recommendation from spray data
`generate_sp_pitch_analysis()`	Starting pitcher's pitch-by-pitch analysis

Each function calculates stats from raw Statcast data and outputs only items that cross statistical thresholds:

# Example: identify the pitch type with highest opponent BA
hittable = sorted(
    [p for p in pt_stats if p["ba"] is not None],
    key=lambda x: x["ba"], reverse=True
)
if hittable and hittable[0]["ba"] >= 0.250:
    h = hittable[0]
    lines.append(
        f"- **Highest opp BA pitch:** {h['label']}"
        f" (BA .{int(h['ba']*1000):03d})"
    )

MLB average as baseline for every stat

A raw number like "SLG .476" is meaningless without context. Every stat shows the MLB average alongside it:

K% 28.3% (MLB avg 22.4%)
BB% 6.1% (MLB avg 8.3%)

Handedness-aware zone names

"Inside" and "outside" flip depending on batter handedness. _zone_names_for_bats() automatically adjusts zone labels so "inside high" is always correct relative to the batter's stance.

Glossary built into every section

Every stat has a ? tooltip (Streamlit's help parameter) showing its definition and MLB average. Count displays include a reading guide ("Balls-Strikes" format) with color legend (🟢 hitter ahead, 🔴 hitter behind, 🟡 even).

Data Source

Baseball Savant Statcast data (2024-2025 MLB regular season)
Retrieved via pybaseball

I Built a WBC 2026 Scouting Dashboard with MLB Statcast Data

Cross-Repo README Sync with GitHub Actions — Push vs Pull Pattern

YMori — Tue, 10 Mar 2026 10:57:17 +0000

The Problem

When you manage multiple GitHub repositories, you often want to display stats from one repo in another — for example, showing contribution counts in your profile README.

Manually updating these numbers is error-prone. Lists get out of sync, numbers become stale, and you forget to update after changes.

This article covers how to build cross-repo README sync with GitHub Actions, and a key architectural decision that saves you from permission headaches.

Two Approaches: Push vs Pull

Push: Source repo writes to target

Source repo → (PAT) → Update target repo's README

Requires a Personal Access Token (PAT)
Fine-grained PATs can unexpectedly return 403 even with correct permissions
PAT management overhead (rotation, scope, etc.)

Pull: Target repo reads from source

Target repo → (GITHUB_TOKEN) → Read source repo's README via API
            → (GITHUB_TOKEN) → Update own README

No PAT needed — GITHUB_TOKEN always has write access to its own repo
Public repo data is readable without any token
Just add a workflow to the target repo

Verdict: Pull wins. It eliminates PAT management entirely.

Implementation

1. HTML Comment Markers

Mark the auto-updated sections in your target README:

## Stats

<!-- STATS_START -->(10 PRs / 5 Merged)<!-- STATS_END --> across 3 repositories.

Only the content between markers gets replaced — everything else stays untouched.

2. Python Sync Script

import base64
import re
import subprocess
import sys
from pathlib import Path

README = Path(__file__).resolve().parent.parent / "README.md"


def run(cmd: list[str]) -> str:
    result = subprocess.run(cmd, capture_output=True, text=True, timeout=120)
    return result.stdout.strip()


def fetch_source_readme(owner: str, repo: str) -> str | None:
    """Fetch README via GitHub API (no token needed for public repos)."""
    output = run([
        "gh", "api",
        f"repos/{owner}/{repo}/contents/README.md",
        "--jq", ".content",
    ])
    if not output:
        return None
    return base64.b64decode(output).decode("utf-8")


def replace_marker(text: str, marker: str, replacement: str) -> str:
    """Replace content between HTML comment markers."""
    pattern = rf"(<!-- {marker}_START -->).*?(<!-- {marker}_END -->)"
    return re.sub(pattern, rf"\1{replacement}\2", text, flags=re.DOTALL)


def parse_stats(source_text: str) -> dict:
    """Extract stats from a markdown summary table."""
    m = re.search(
        r"\| \*\*Total\*\* \|.*?\| \*\*(\d+)\*\* \| \*\*(\d+)\*\*",
        source_text,
    )
    if not m:
        return {}
    return {"total": int(m.group(1)), "merged": int(m.group(2))}


def main():
    source = fetch_source_readme("your-org", "your-source-repo")
    if not source:
        print("Failed to fetch source README", file=sys.stderr)
        sys.exit(1)

    stats = parse_stats(source)
    if not stats:
        print("Failed to parse stats", file=sys.stderr)
        sys.exit(1)

    readme = README.read_text(encoding="utf-8")
    readme = replace_marker(
        readme, "STATS",
        f"({stats['total']} PRs / {stats['merged']} Merged)",
    )
    README.write_text(readme, encoding="utf-8")
    print(f"Updated: {stats['total']} PRs / {stats['merged']} Merged")


if __name__ == "__main__":
    main()

3. Workflow

name: Sync README Stats

on:
  schedule:
    # Run after the source repo's update schedule
    - cron: '30 9 * * 1'
  workflow_dispatch:

permissions:
  contents: write

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Sync stats from source repo
        env:
          GH_TOKEN: ${{ github.token }}
        run: python scripts/sync_stats.py

      - name: Commit and push if changed
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add README.md
          if ! git diff --cached --quiet; then
            git commit -m "docs: sync stats $(date -u +%Y-%m-%d)"
            git push
          fi

Common Pitfalls

PAT 403 Errors

With the push approach, Fine-grained PATs can return 403 even when configured with "All repositories" and "Contents: Read and write":

remote: Permission to user/repo.git denied to user.
fatal: unable to access '...': The requested URL returned error: 403

The GitHub Contents API (-X PUT) also returns 403. Rather than debugging token permissions, switching to the pull approach is the most reliable fix.

Cron Timing

If your source repo updates at 09:00 UTC on Mondays, schedule the sync workflow for 09:30 or later:

# Bad: same time as source → may fetch stale data
- cron: '0 9 * * 1'

# Good: after source update completes
- cron: '30 9 * * 1'

Marker Design

Use unique marker names per section to avoid collisions:

<!-- PROJECT_STATS_START -->...<!-- PROJECT_STATS_END -->
<!-- BADGE_COUNT_START -->...<!-- BADGE_COUNT_END -->

The replace_marker function only touches content between markers, so the rest of your README is safe.

Summary

Principle	Description
Use pull, not push	Place the workflow in the target repo, use GITHUB_TOKEN
HTML comment markers	Isolate auto-updated sections from manual content
Stagger cron schedules	Run sync after the source has finished updating
Single Source of Truth	One canonical data source, everything else pulls from it

This pattern works for any cross-repo data sync — contribution stats, package versions, badge counts, or anything else you want to keep consistent across repositories.

Optimizing Marcel Projection Weights for NPB — Grid Search + Bootstrap Validation

YMori — Sat, 07 Mar 2026 23:43:19 +0000

Background

The Marcel projection system is a simple but effective player performance forecasting method created by Tom Tango. It uses a weighted average of the last 3 seasons plus regression to the mean.

GitHub: https://github.com/yasumorishima/npb-marcel-weight-study

I've been using these default parameters in npb-prediction (blog post), but they were originally calibrated for MLB data:

Parameter	Meaning	Original (Tango's values)
w0 / w1 / w2	Weights for N-1 / N-2 / N-3 seasons	5 / 4 / 3
REG_PA	Regression strength (hitters)	1200
REG_IP	Regression strength (pitchers)	600

Are these optimal for NPB (Nippon Professional Baseball)? I ran a comprehensive grid search to find out.

Study Design

Grid Search

Target	Search Space	Combinations
Hitters	w0(3-8) × w1(1-5) × w2(1-4) × REG_PA(6 values)	720
Pitchers	w0(3-8) × w1(1-5) × w2(1-4) × REG_IP(5 values)	600

Evaluation

Cross-validation: 2019–2025 (7 years)
Two scenarios: with 2020 (COVID-shortened season) / without 2020
Metric: MAE (Mean Absolute Error)
Data: 3,780 hitter rows / 3,773 pitcher rows (2015–2025)
Runtime: ~4.5 hours on GitHub Actions

Results: Hitters

OPS MAE — Top 5 (with 2020)

Weights	REG_PA	OPS MAE
8/4/3	2000	.06142
7/3/3	2000	.06142
7/5/1	2000	.06143
8/5/1	2000	.06145
4/3/1	1200	.06146

Previous (5/4/3, REG_PA=1200): .06227 — ranked 224th out of 720

Improvement: .06227 → .06142 = 1.37% MAE reduction

Optimal Weights Differ by Metric

Metric	Best Weights	REG_PA	MAE
AVG	3/2/4	1500	.02160
OBP	7/3/3	1500	.02449
SLG	4/3/1	1000	.04200
OPS	8/4/3	2000	.06142

AVG favors the N-3 season (stability), while SLG minimizes it (recency). The optimal parameters align with each metric's characteristics.

Results: Pitchers

ERA MAE — Top 5 (with 2020)

Weights	REG_IP	ERA MAE	WHIP MAE
4/5/2	800	.68171	.13065
3/4/1	800	.68172	.13103
3/4/1	600	.68228	.13068
3/4/2	800	.68304	.13099
3/3/2	800	.68312	.13118

Previous (5/4/3, REG_IP=600): .69105 — ranked 75th out of 600

Improvement over previous: 1.35% (with 2020) / 1.53% (without 2020)

Bootstrap Validation

300 bootstrap resamples to test if the improvement is statistically significant.

Hitter OPS (optimal 8/4/3 reg=2000 vs previous 5/4/3 reg=1200):

Statistic	Value
Mean improvement	0.00084
95% CI	[0.00022, 0.00147]
best > default	99.7%
p-value	0.003

The lower bound of the 95% CI is above zero — statistically significant (p < 0.01).

Key Findings: NPB vs MLB

Hitters: Strong N-1 Bias + Stronger Regression

Feature	Previous	NPB Optimal
N-1 (most recent) weight	5	8
N-3 weight	3	1–3
Regression (REG_PA)	1200	2000

The simultaneous increase in both w0 and REG_PA seems contradictory but is actually coherent:

w0=8: Emphasize the N-1 season in the weighted average
REG_PA=2000: Pull extreme performances back to the mean more aggressively

In NPB data, this "trust trends but don't trust extremes" combination proved optimal.

Pitchers: N-2 Season is Most Predictive

Feature	Previous	NPB Optimal
N-1 (most recent) weight	5	3–4
N-2 weight	4	4–5
N-3 weight	3	1–2
Regression (REG_IP)	600	800

The most striking finding: w1 (N-2 season) is larger than w0 (N-1 season). This contradicts the conventional assumption that the most recent season is always most important.

Incorporating the N-2 season helps smooth out temporary fluctuations.

Recommended Parameters

Target	Weights	Regression	Evidence
Hitters	8/4/3	REG_PA=2000	Bootstrap p=0.003
Pitchers	4/5/2	REG_IP=800	Optimal for both ERA and WHIP across scenarios

These parameters will be applied to npb-prediction.

Reproducibility

Code and all result CSVs are available at npb-marcel-weight-study.

Summary

The conventional Marcel weights (5/4/3) are not optimal for NPB
Hitters: strong N-1 weight (w0=8) + stronger regression (REG_PA=2000)
Pitchers: N-2 season is more predictive than N-1 (most recent)
Bootstrap test confirms significance at p=0.003

Marcel is simple, but there's room for improvement when you calibrate parameters to your league.

Data sources: baseball-data.com / npb.jp
GitHub: https://github.com/yasumorishima/npb-marcel-weight-study

Can Statcast Data Improve MLB Player Performance Predictions? — Beating Marcel with LightGBM

YMori — Fri, 06 Mar 2026 22:53:28 +0000

Introduction

This article is a continuation of my NPB Bayesian prediction series. Along the way, I reached a conclusion:

"Without tracking data like Statcast, we can't break through the next wall."

In my NPB project, I added Bayesian regression (Stan/Ridge) on top of Marcel projections. At the player level there was consistent improvement (p=0.06), but at the team level the gains disappeared. The reason: Marcel's 3-year weighted average is already accurate for high-PA regulars, leaving no margin for improvement using only aggregate stats like K%/BB%/BABIP.

MLB has Statcast. This article tests whether Statcast tracking features can beat Marcel.

GitHub: https://github.com/yasumorishima/baseball-mlops
Streamlit: https://baseball-mlops.streamlit.app/

What is Marcel?

Marcel is a simple projection system from the 1980s: weighted average of the past 3 years (weights 5:4:3) + regression to the mean + age adjustment. Despite its simplicity, it's remarkably accurate — especially for regular players with large sample sizes.

Data & Features

Source: pybaseball (FanGraphs + Baseball Savant)
Target: MLB batters (PA≥100) / pitchers (IP≥30)
Period: 2015-2024 (training), 2025 (evaluation)

Batter Features (38)

Category	Features
Statcast	EV, Barrel%, xwOBA, Sprint Speed, Launch Angle, EV95%
FanGraphs	HardHit%, Contact%, O-Swing%, SwStr%
1-year lag delta	wOBA change, xwOBA change, K% change, BB% change, Barrel% change
2-year trend (v7)	2-year wOBA direction (rising/falling)
Engineered (v7)	age_from_peak (distance from peak age 29), park_factor, team_changed, pa_rate
Interaction	age × (xwOBA − wOBA) — luck sensitivity by age
Stacking	lgb_delta (LightGBM OOF residual)

Pitcher Features (35)

Category	Features
Statcast	K%, BB%, Whiff%, CSW%, SwStr%, Barrel%, EV
Stuff	Stuff+, Location+, Pitching+, Velo, Spin Rate
1-year lag delta	xFIP change, K% change, BB% change, K-BB% change
2-year trend (v7)	2-year xFIP direction
Engineered (v7)	age_from_peak, park_factor, team_changed, ip_rate, FIP-ERA gap
Interaction	age × K-BB%
Stacking	lgb_delta

The park factor work from the NPB series was carried over into baseball-mlops as a park_factor feature — the same methodology, now applied to MLB stadiums.

Model

Three models combined:

Marcel (baseline): 3-year weighted avg + regression to mean + age adjustment
LightGBM: Optuna 1000-trial hyperparameter optimization (time-series expanding-window CV)
Bayes correction (ElasticNet): Predicts Marcel residuals using Statcast features, adds 80% CI
- Recency Decay: samples weighted by 0.85/year (recent seasons count more)
- LightGBM OOF predictions used as stacking feature
Ensemble: Marcel×31% + LightGBM×33% + Bayes×36% (auto-weighted by inverse MAE)

Backtest Design

2025 is a strict holdout — never seen by Optuna or CV:

2015-2019: Initial training
2020-2024: Time-series expanding-window CV (Optuna tuning)
2025:      Strict holdout (no leakage)

Results

2025 Strict Holdout

	Marcel MAE	ML MAE	Improvement
Batter wOBA	0.0331	0.0291	+12.1%
Pitcher xFIP	0.5038	0.4837	+4.0%

CV results (batter 0.0281 / pitcher 0.521) are consistent with holdout — no overfitting detected.

Year-by-Year Backtest

Year	Batter ML	Marcel		Pitcher ML	Marcel
2020	0.0359	0.0371	✓ +3.2%	0.595	0.618	✓ +3.7%
2021	0.0293	0.0317	✓ +7.6%	0.542	0.553	✓ +1.9%
2022	0.0296	0.0330	✓ +10.3%	0.578	0.569	✗ -1.5%
2023	0.0277	0.0303	✓ +8.7%	0.535	0.559	✓ +4.3%
2024	0.0280	0.0333	✓ +16.0%	0.509	0.522	✓ +2.5%
2025	0.0291	0.0331	✓ +12.1%	0.484	0.504	✓ +4.0%

Batters: 6/6 wins. Pitchers: 5/6 wins (2022 loss likely due to limited training data — only COVID-shortened 2020-2021).

Why Does Statcast Help?

The Bayes (ElasticNet) model predicts Marcel's residuals using Statcast features. Larger coefficients = more information Marcel is missing.

Batters

Feature	Coef	Interpretation
Max EV	+0.0046	Peak hitting power — Marcel can't see this
Contact%	+0.0040	Finer skill signal than K% alone
BB%	+0.0038	Additional plate discipline information
xwOBA	+0.0037	Luck-removed true hitting ability

Pitchers

Feature	Coef	Interpretation
Pitching+	-0.0892	Overall stuff quality → lower future xFIP
K%	-0.0631	High strikeout rate outperforms Marcel forecast
SwStr%	-0.0346	Swing-and-miss ability
Stuff+	-0.0279	Velocity + movement + spin combined

Marcel's ERA/xFIP carries luck components. Statcast's stuff metrics (Stuff+/Pitching+) reflect skill stripped of luck, which is why they add predictive signal.

MLOps Pipeline

Every Monday JST 11:00 (GitHub Actions cron)
  ↓
fetch_statcast.py (pybaseball → Statcast CSV)
  ↓
train.py (LightGBM + Optuna 1000 trials + Bayes correction)
  ↓
W&B Model Registry (MAE comparison → auto-promote "production" tag)
  ↓
FastAPI (polls W&B every 6h → auto-loads latest model)

The FastAPI server polls W&B every 6 hours and automatically loads the new model when the production tag is updated — no container restart needed.

Looking Ahead: NPB Hawk-Eye

NPB installed Hawk-Eye tracking in all 12 stadiums in 2024. Once data becomes publicly available (expected 2026+), this pipeline can be transplanted directly.

baseball-mlops	NPB Hawk-Eye version
pybaseball	NPB Hawk-Eye API
EV / Barrel% / xwOBA	Equivalent metrics
MLB Marcel	NPB Marcel
LightGBM + Bayes	Same architecture

Summary

	NPB Bayesian project	baseball-mlops (MLB)
Data	K%/BB%/BABIP (aggregate stats)	Statcast (tracking)
Marcel improvement	Marginal (p=0.06)	+12.1% (batters) / +4.0% (pitchers)
Year-by-year wins	—	Batters 6/6, Pitchers 5/6

The reason Statcast works: Marcel's 3-year weighted average can't see contact quality or pitch stuff. Exit velocity, barrel rate, and Stuff+ directly measure those dimensions that aggregate stats miss.

Data: Baseball Savant / FanGraphs via pybaseball

Did Adding Stadium Correction Improve My NPB Baseball Predictions? — A Full Backtest Comparison

YMori — Thu, 05 Mar 2026 08:34:08 +0000

Introduction

This is a follow-up to my NPB (Nippon Professional Baseball) standings prediction series. I added park factor correction to the existing Marcel+Stan Bayesian system and ran a full backtest (2018–2025, 96 team-seasons) to measure the impact.

GitHub: npb-bayes-projection

Key Terms (for first-time readers)

Term	Meaning
Marcel method	Predicts next year's stats using a weighted 3-year average (weights: 5:4:3, recent years weighted higher)
Bayesian prediction (Stan)	Estimates probability distributions from data, capturing uncertainty in predictions
Park factor	Measures how much a stadium inflates or suppresses scoring. 1.0 = neutral; >1.0 = hitter-friendly; <1.0 = pitcher-friendly
Pythagorean win%	Estimates win% from runs scored (RS) and allowed (RA): `RS^1.83 / (RS^1.83 + RA^1.83)`
MAE	Mean Absolute Error — average prediction miss. Lower is better
80% CI	80% confidence interval — the range where actual values fall 80% of the time

Why Park Factor Correction?

Marcel predicts player stats from their past 3 years. The problem: those stats embed the home stadium's environment.

Vantelin Dome (Chunichi Dragons): PF_5yr = 0.844 → heavily pitcher-friendly
ES CON Field (Nippon Ham): PF_5yr = 1.147 → hitter-friendly

A Vantelin pitcher's ERA looks better partly because of the park. Using those raw stats to project team runs allowed (RA) will underestimate RA compared to a neutral stadium.

The correction formula

# (PF + 1.0) / 2.0 = average of home and away
# Players play half games at home, half away
pf_factor = (PF_5yr + 1.0) / 2.0
rs_adjusted = rs_raw / pf_factor   # normalize runs scored to neutral park
ra_adjusted = ra_raw / pf_factor   # normalize runs allowed to neutral park

Results (2018–2025, 96 team-seasons)

Win MAE didn't change — here's why

Metric	No correction	5yr avg PF	Change
Win MAE	6.41	6.41	±0.00
Win Bias	+2.69	+2.70	+0.01
80% CI coverage	86.5%	87.5%	+1.0%

MAE didn't move at all. The reason is structural:

After correction: RS_adj = RS / factor,  RA_adj = RA / factor
Pythagorean: RS^exp / (RS^exp + RA^exp)

When you divide both RS and RA by the same factor, the ratio is preserved. Pythagorean win% depends on the ratio — so win predictions barely change.

The 80% CI coverage improved from 86.5% to 87.5%. Removing the park bias makes the prediction distribution slightly more reliable, even when the point estimate stays the same.

RS and RA accuracy improved significantly

Metric	No correction	5yr avg PF	Change
RS MAE (runs scored)	101.1	74.8	-26.3
RA MAE (runs allowed)	97.5	73.0	-24.5

The absolute-value accuracy of run predictions improved substantially. This doesn't directly affect win predictions, but it matters for player valuation and roster construction analysis.

Year-by-year breakdown

Year	Win MAE (no PF)	Win MAE (5yr PF)	Change
2018	6.18	6.18	±0.00
2019	3.90	3.90	±0.00
2020	6.27	6.28	+0.01
2021	10.33	10.33	±0.00
2022	5.13	5.12	-0.01
2023	6.88	6.89	+0.01
2024	6.69	6.71	+0.02
2025	5.90	5.90	±0.00

The 2021 spike (MAE = 10.33) reflects Yakult and Orix going from last place to champions — an exceptional event unrelated to park factors.

Single-Year PF vs. 5-Year Average: Which Is Better?

I tested two variants of park factor:

Single-year PF: calculated from one season only — higher noise
PF_5yr: 5-year rolling average with renovation breakpoints — smoother

Metric	No PF	Single-year PF	5-year avg PF
Win MAE	6.41	6.41	6.41
RS MAE	101.1	74.8	74.8
RA MAE	97.5	73.0	73.0
80% CI coverage	86.5%	86.5%	87.5%

RS/RA accuracy improved equally with both. The only difference is CI coverage — single-year PF is too noisy to improve the prediction interval. The 5-year average's smoothing is what improves reliability.

Focus: Nippon Ham and ES CON Field Opening (2023)

In 2023, Nippon Ham moved from Sapporo Dome to ES CON Field — a brand-new ballpark.

Year	Single-year PF	5yr avg PF	Predicted W	Actual W	Error
2022 (last at Sapporo)	0.949	0.967	68.2	59	+9.2
2023 (ES CON opens)	0.969	0.969	65.4	60	+5.4
2024	1.212	1.089	69.0	75	-6.0
2025	1.271	1.147	73.4	83	-9.6

Opening year (2023): single-year and 5-year PF happen to match (0.969). The 5-year average was still dominated by Sapporo Dome data.

2024–2025: the gap widens. ES CON is clearly hitter-friendly (PF > 1.2), but the 5-year average is still held down by Sapporo Dome history. Win predictions don't change between methods — confirming the structural argument above.

Summary

Finding	Result
Win MAE	No change (structurally cannot change)
RS/RA MAE	-26 / -25 runs improvement
80% CI coverage	+1.0% (5-year average only)
Single-year vs. 5-year PF	Same accuracy; 5-year wins on CI reliability

The unchanging win MAE isn't a failure — it's by design. The Pythagorean formula preserves the RS/RA ratio when both are scaled by the same factor.

Park factor correction improves prediction interval reliability and absolute run accuracy, which matters for player analysis even when the win total doesn't shift.

As ES CON and renovated stadiums like Vantelin Dome (2026: HR wing) and Rakuten Mobile Park (2026: fence moved in) accumulate data, the gap between single-year and 5-year PF will grow. That's when the choice of smoothing method will matter more.

Forem: YMori

transform: translateY(0) Breaks position: fixed — A Hidden Trap in SPA Animations

The Bug

How to Reproduce

Why This Happens — The CSS Spec

The animation-fill-mode: both Trap

Blast Radius

The Fix

1. Use transform: none (Most Important)

2. Use createPortal to Escape the DOM Tree (Defensive)

3. Do Both (Recommended)

Summary

NPB 2021 Backtest: Could a Bayesian Model Predict Last-Place-to-Champion?

Introduction

Team Standings: Predicted vs Actual

Central League

Pacific League

Foreign Player Predictions vs Actual

Accurate Predictions (average MLB players)

Major Misses (extreme players)

What Actually Drove the 2021 Standings

Yakult's Championship Run

Orix's Championship Run

Giants Collapse (Predicted 84.3W → Actual 61W)

Key Findings

Conclusion

Data Sources

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction App

Introduction

Terms

Problems with the Previous Approach

Problem 1: All Foreign Players Treated as "Average"

Problem 2: Skill Metrics Ignored

Problem 3: No Uncertainty

What Changed with Bayesian Integration

Foreign Players: Average → Individual Predictions

Japanese Players: K%/BB%/BABIP Corrections

Did Accuracy Improve?

Historical Marcel Accuracy for Context

How Did the 2026 Standings Change?

Central League — Tigers Runaway Disappears, 4-Team Deadlock

Pacific League — Lions Surge

Summary

Caveat: Data Limitations

Data Sources

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction System

Introduction

Before: Point Estimates Only

After: Bayesian Ensemble + Monte Carlo

The 7 Phases

Phase 1: Japanese Player Bayesian Inference

Phase 2: Foreign Player Stan v2 Predictions

Phase 3: Monte Carlo Team Simulation

Phase 5: API Integration

Phase 6: Streamlit Integration

Phase 7: BigQuery Integration

Technical Decisions

posteriors.json vs. cmdstanpy at runtime

BMA Weight Rationale

The Full-Width Space Trap

Results

Takeaways

Data Sources

5 Pitfalls of Grafana + BigQuery — When Your Dashboard Shows Nothing

Introduction

1. Non-ASCII Column Aliases Need Backticks

Symptom

Cause

2. BigQuery Datasource Doesn't Support format: "time_series"

Symptom

Fix

3. Historical Data in Timeseries Panels Shows "Data outside time range"

Symptom

Cause

Fix

4. Extra fieldConfig Properties Can Break Barchart Rendering

Symptom

Cause

5. Panels Inside Expanded Row's panels Array Are Invisible

Symptom

The `animation-fill-mode: both` Trap

1. Use `transform: none` (Most Important)

2. Use `createPortal` to Escape the DOM Tree (Defensive)

2. BigQuery Datasource Doesn't Support `format: "time_series"`

5. Panels Inside Expanded Row's `panels` Array Are Invisible