I'm a machine learning engineer focused on shipping models that actually survive production: fast inference, clean data pipelines, and infrastructure that's been stress-tested rather than just deployed and hoped for.

• 🔭 Currently building: Project Omega — lightweight vision models with FastAPI serving and full observability
• 🌱 Currently deepening: Linux internals, container hardening, and offensive-security tooling (so I can find the holes before someone else does)
• 🧩 Core stack: PyTorch, FastAPI, Docker, Kubernetes, Linux
• 💬 Ask me about: model serving, ML infra, or reproducible training pipelines

No third-party widget APIs in this section — these four cards are drawn by my own generator (cards/), rendered from the live GitHub GraphQL API and committed straight back to this branch daily by .github/workflows/cards.yml, the same pattern as the snake.

Loss is the share of the year's contributions still owed at each week of the run — the curve converges only when I ship. The marker heartbeats while status reads "converging".

One sample per day; idle days hold the beam on the baseline. The sweep line scans every seven seconds.

The contribution year as a training run: loss is the share of the year's work still owed, and it converges only when I ship. The scope on the right samples one day at a time — idle days hold the beam on the baseline.

Every repo is a service on host github.com/mgkvibez — open if pushed in the last 30 days, filtered within 90, closed beyond that. Ports are stable hashes of the repo name.

Repos as models in a registry: version = stars, params = disk footprint, train loss = days since the last deploy. Loss drifts up while a repo sits idle.

Every repo is a service on host github.com/mgkvibez — open if pushed in the last 30 days, filtered within 90, closed beyond that. The registry frames them as models: version = stars, params = disk footprint, train loss = days since the last deploy.

Stats are rendered live by github-readme-stats — no local generation or workflow needed, so they're always current.

Auto-generated daily by .github/workflows/snake.yml. The snake starts electric blue and turns terminal green as it eats through the year — keyframe colours interpolated over its run, repainted after every regeneration.

Every repo is a skyscraper: height ranks commits (with codebase size and stars as tie-breakers), window lights track how recently it was pushed, the facade is tinted by its primary language, and the tallest tower wears the blinking beacon. Private repos rise as dark towers on the far edge — anonymous silhouettes, names only, no stats. The sky keeps real West African Time — sun by day, moon and stars by night, windows dimming at dawn — and the seasons pass through it: snow in winter, petals in spring, falling leaves in autumn. Re-rendered hourly, so a new repo gets its skyscraper within the hour.

A year of contributions, one cell per day. The four shades are quartiles of my own active days rather than fractions of the busiest one, and the legend prints the numeric range of every band — so the reading survives greyscale.

Left: share of code by tracked bytes, ranked, with the private count in the scope line rather than hidden. Right: the headline numbers and a 30-day sparkline — deltas come from the snapshot archive (history.jsonl), and stay absent until the archive is old enough to answer.

Left: the part of a year's work that involved somebody else — commits are the denominator, not a bar, because a shared axis would turn the collaborative measures into pixel slivers. Right: when in the week and the day the commits actually land, sampled from recent history; every stamp is UTC and the card says so.

Left: the long view — twelve monthly cells per year, shaded by the profile's own distribution. Right: the only derivative on the page — which way the language mix is moving. It needs a month of snapshots to have an honest "then", so until the archive is old enough it says exactly that instead of inventing one.

• Open an issue describing the bug or feature before sending a PR.
• Fork, branch off main, and include tests with any behavioral change.
• PRs are reviewed for reliability, test coverage, and clarity of design — not just "does it run."

• X: @mgkvibez
• Email: michaeloogwu58@gmail.com
• Found a real issue in one of my repos? Open an issue there directly — it's faster than DMs.