About me
evgeniimatveev
I build small production data & ML systems end to end — pipeline, model, dashboard, deploy, and the monitoring that tells me when it breaks. Everything below is live, not a mockup.
Ask me anything
Ask anything you need to know — my stack, a real incident, why I'm job searching, logistics. Grounded in my real work, not scripted.
★ ask in any language — RAG-grounded, not a chatbot scriptanswers in your language, pulled from 300+ real facts — 33 repos, incident postmortems, interview stories — via Vectorize + Workers AI, generated live by Claude (Haiku 4.5)
loading question count…
Live system status
manual snapshot, last verified 2026‑08‑18 — not a live feed, see infra.log for why
Projects
Incident postmortems
AttributeError. Traced it to one line: search_parameters.num_search_workers = 1 — a field that simply doesn't exist on the classic routing solver's RoutingSearchParameters proto in the pinned OR-Tools version (it belongs to CP-SAT's params, not this solver). Confirmed by enumerating the live proto's actual fields rather than trusting the earlier assumption, removed the line, verified the fix live within the hour.
src/cvrp_solver.py · commit a921d99 · view the real diff
@@ -149,12 +149,6 @@ def solve_cvrp(cvrp_input: CVRPInput, time_limit_s: int = 15) -> CVRPResult:
routing_enums_pb2.LocalSearchMetaheuristic.GUIDED_LOCAL_SEARCH
)
search_parameters.time_limit.FromSeconds(time_limit_s)
- # Force single-threaded search — OR-Tools otherwise auto-detects CPU count- # and runs that many parallel search workers, each holding its own solver- # state. Streamlit Cloud's free tier caps the container around ~1GB RAM,- # so multi-worker search on a multi-vCPU box was the likely cause of the- # native "Segmentation fault" crashes seen in production (2026-08-17).- search_parameters.num_search_workers = 1
solution = routing.SolveWithParameters(search_parameters)
Build your own route — click the stops in the order you'd drive them, then see how it stacks up against a real optimizer.
★ optimal route solved live via exact dynamic programming — not a canned answerConnectTimeout, common on a shared GitHub Actions runner — used to crash the entire twice-daily run, losing all 20 cities' data instead of just the one that failed.src/extract.py imports tenacity for that retry logic, but it was never declared in requirements.txt — every scheduled and manual pipeline run had been crashing on import, silently, for days. Surfaced only while testing an unrelated storage migration (HuggingFace Dataset → Cloudflare R2), not by anyone noticing the missing data. Fixed with a one-line dependency addition, verified against a real GitHub Actions run.
requirements.txt · commit f38883a · view the real diff
httpx>=0.27.0
+tenacity>=8.2.0
pandas>=2.2.0
duckdb>=0.10.0
boto3>=1.34.0
Infrastructure and monitoring
scripts/generate-uptime.mjs.the two AI pipelines that actually run this page, traced end to end — not illustrated from memory, see README.md for the full mermaid version
same Claude Haiku 4.5 model, two independent triggers — one answers you, one writes the log above
Skills
Build log
auto-generated daily by a GitHub Action + Claude, summarizing real commits across the repos above — not hand-written