Mohamed Ajab.
Built to be explored.

What I built

• Built workspace-separated author and editor workflows, with revision history and scheduled publishing.
• Kept the public page on its approved revision while new edits remain private.
• Handled competing edits with version checks and database transactions.

Python · Django · Django REST Framework · PostgreSQL · Docker

Evidence & limits

The repository records 76 PostgreSQL tests, concurrency checks and browser verification. A visitor-isolated demo runs the actual workflow.

Server-rendered Django keeps the application straightforward. SQLite is useful locally, but PostgreSQL is needed to exercise the row-locking and concurrency behaviour.

What I built

• Made retries return the original payment, while conflicting requests are rejected.
• Used verified identity tokens and tenant-scoped permissions to separate organisations.
• Built a React operations interface with sign-in, payment creation and journal exports.

Java 21 · Spring Boot 4 · PostgreSQL 17 · Redpanda · React 19

Evidence & limits

Database integration tests and architecture checks exercise the payment flow. The repository explains authentication, transaction boundaries and remaining risks.

An outbox keeps payment changes and pending events in one transaction. Publishing is at least once, so downstream consumers still need to handle duplicates.

What I built

• Persisted events before workers attempt delivery.
• Added signed requests, retry delays and dead-letter inspection.
• Used database leases so competing workers can coordinate.

Python · FastAPI · SQLAlchemy · PostgreSQL · HMAC

Evidence & limits

PostgreSQL concurrency checks exercise competing workers. Tests and source make the delivery states and recovery behaviour inspectable.

At-least-once delivery favours eventual delivery over a promise of no duplicates. Stronger secret storage and DNS pinning remain production-hardening work.

What I built

• Tracked file hashes and business identifiers to detect repeat input.
• Separated invalid records with reasons instead of silently discarding them.
• Recorded run status and counts alongside committed data.

Python · SQLite · SQL · pytest

Evidence & limits

The project exposes ingestion logic, rejection evidence and tests in a compact Python and SQLite codebase.

The current file-hash constraint also blocks an unchanged failed file from being retried. Automated recovery is a next step, not a completed feature.

What I built

• Modelled order-line detail rather than treating each order as one product.
• Separated transformation and SQL views from presentation.
• Documented measures and a dashboard wireframe for analysing customer behaviour.

Python · SQLite · SQL · Power BI modelling

Evidence & limits

The repository includes the Python/SQLite pipeline, SQL models and DAX definitions. The dashboard is a design artifact, not a claimed live Power BI deployment.

The pipeline rebuilds its data rather than incrementally updating it. Inner joins can remove unmatched records, which matters when interpreting totals.

What I built

• Built a FastAPI and JavaScript interface with progress, cancellation and restart recovery.
• Added manual identity corrections and review before statistics are counted.
• Kept the last good outputs when a later processing job fails.

Python · FastAPI · JavaScript · OpenCV · YOLO · ONNX Runtime

Evidence & limits

The repository records exploratory clip checks and a validation workflow. Player labels are manual; the ball detector uses a credited third-party pretrained model.

One worker avoids sharing model state across sessions, at the cost of throughput. The application is local-only and does not claim validated full-match or physical 3D accuracy.