Real-Time Analytics at the World Cup: How Player and Ball Tracking Actually Works Under the Hood
How FIFA World Cup 2026 Semi-Automated Offside Technology (SAOT) works: 12+ tracking cameras, 500Hz ball IMU, 3D player avatars, VAR fusion, and real-time offside detection.
Optimizing State Management in Flutter with Riverpod
How I structured Riverpod state for a production Flutter EV-charging app: provider scoping, AsyncNotifier, real-time WebSocket sync, and keeping rebuilds cheap.
Jetpack Compose: Lessons From 10 Years in Android
Hard-won Jetpack Compose lessons from migrating production Android apps off XML: recomposition, state hoisting, stability, and Clean Architecture boundaries.
How I Architected an EV Charging Platform (OCPP, WebSocket, Flutter)
A walkthrough of an EV charging platform: OCPP 1.6 over WebSocket, a Node.js middleware layer, sub-100ms local control, and a Flutter app — with key decisions.
Engineering blog: practical notes from Android, mobile, infrastructure, and AI work
The Michael Samuel Naeem engineering blog is a place for practical software notes rather than abstract theory. The posts focus on lessons from Android development, Kotlin, Jetpack Compose, Flutter, Riverpod, OCPP, WebSocket systems, EV charging platforms, real-time interfaces, and production delivery.
The goal is to make each article useful for a developer, technical lead, founder, or product team that needs to understand how a decision works in practice. A good post should answer what changed, why the decision mattered, what tradeoffs appeared, and how the same idea could help another project.
This blog hub collects those posts in one crawlable index. It gives search engines and AI answer systems enough context to understand the themes behind the articles, not only the individual titles. The main themes are mobile architecture, reactive state, reliable infrastructure, developer experience, and measurable delivery outcomes.
What the articles cover
Android and Kotlin posts usually focus on production habits. That includes state ownership, UI performance, lifecycle safety, migration strategy, release reliability, and the choices that make a mobile app easier to maintain after the first launch.
Jetpack Compose articles focus on keeping composables predictable. Topics include derived state, stable models, scroll performance, interop with legacy screens, and the difference between code that works in a demo and code that survives a large app.
Flutter and Riverpod articles focus on real-time state, provider boundaries, WebSocket data, map interfaces, and avoiding rebuild storms. These are common problems in EV charging, location-heavy products, dashboards, and live operational tools.
Infrastructure posts focus on OCPP, WebSocket communication, charging state, network failure, local discovery, and resilient platform behavior. The writing is grounded in systems where a dropped connection or unclear state can become a real product problem.
Who should read this blog?
Developers can use the blog to compare implementation patterns and avoid common mistakes. The posts are written to be concrete enough for engineers who want a practical starting point before they adapt the idea to their own codebase.
Technical leads can use the posts as discussion material for architecture reviews, migration planning, and team standards. The writing often explains why a pattern matters, not just what syntax to paste into a project.
Founders and product leaders can use the blog to understand how technical decisions affect delivery speed, reliability, and user experience. The articles connect implementation details to outcomes such as uptime, performance, maintainability, and release confidence.
AI-assisted development workflows can also benefit from the blog because the articles include direct explanations, examples, and decision rules. That makes the content easier to summarize, cite, and transform into checklists or implementation plans.
How to use the posts
- Read the article once for the core idea before copying any pattern into your project.
- Compare the described tradeoffs with your app size, team structure, release cycle, and risk level.
- Turn useful sections into a checklist for pull requests, migrations, or architecture reviews.
- Use the examples as starting points, then adapt naming, boundaries, and error handling to your codebase.
- Share the post with teammates when you need a short, practical explanation of a technical decision.
Why this blog exists
Software portfolios often show finished work but not the thinking behind it. The blog fills that gap by explaining the engineering decisions, mistakes, and patterns that shape real products.
The writing also supports discoverability. Search engines and answer engines need more than a title and a date; they need topic coverage, related terms, and enough natural language to understand why a page is useful.
For readers, the best outcome is simple: leave with a clearer way to build, debug, review, or explain a technical choice. If a post helps a team avoid one fragile abstraction, one rebuild problem, one unclear charging state, or one painful migration, it has done its job.