Hi, I'm Rabah.
I build useful software.

My first contribution focused on issue #711 in the Kotlin Multiplatform SDK. In an SDK, handling a failure is part of the public behavior: an error must not unexpectedly disrupt the application using the library. The work involved locating the relevant failure path in an unfamiliar codebase, making a targeted change, and adding regression coverage.

The SDK is used across Kotlin targets, so a test should protect the observable behavior, not depend on one internal implementation. I also worked on ConsoleExporter configuration, where configuration changes need to fit the SDK's existing conventions.

My pull requests provide the code changes and review discussion. They are better evidence of my decisions than a general description of open-source work.

AltCV starts from a structured profile containing the user's actual education, skills, and experience. A job posting supplies relevance signals, not new facts. That separation is central to the product: tailoring means selecting and reformulating existing information, not generating qualifications from scratch.

The user can import a CV or complete their profile, paste a job posting, review the tailored result, edit it, and export a PDF. Generated CVs and their associated applications can then be found again in the history and tracking flow. These steps matter because a CV is something the user must be able to verify and correct before sending.

I chose to keep the user in control of the final document rather than present automated output as unquestionably correct. The live site shows the product; I don't claim measured ATS improvements or generation accuracy without evidence.

The editor represents operations such as Source, Filter, Select, Join, GroupBy, and Aggregate as connected blocks. The backend's job is not to concatenate SQL fragments from the browser: it must validate the graph, translate it into a logical query representation, and then generate SQL for BigQuery.

The design uses a sequence of Common Table Expressions (CTEs) to represent transformation steps. This makes the generated query easier to inspect and reason about than a single deeply nested statement. A backend validation boundary is important because the frontend's graph cannot be trusted merely because it was created through a visual editor.

A syntactically valid BigQuery query can still scan too much data. The architecture therefore includes a dry run to estimate scanned bytes before execution, with the possibility of rejecting overly expensive queries. These are design requirements of an ongoing internal project; I am not claiming every stage is already deployed.

My assignment is to onboard web applications to Dynatrace and integrate OpenTelemetry instrumentation. That means working across the application teams and Dynatrace engineers so metrics, logs, and traces can be collected and presented in dashboards.

Metrics help reveal a trend, logs provide event-level context, and traces help follow a request through instrumented components. A useful dashboard should support an investigation rather than merely display every available signal. Selecting which telemetry to expose is therefore part of the engineering work.

This is an ongoing rollout, not a claim that all applications are instrumented. I cannot publish internal dashboards, instrumentation configuration, or operational data.

This tool automates retrieval of more than 40 GB of competitor-pricing data each day. The data comes from two specific sources on local servers, and the workflow covers multiple business scopes, including ICA, NATL, and medium-/short-haul markets.

The challenge isn't just processing a large volume once. The retrieval has to be repeated on schedule, across scopes, within a defined window. That changes how I think about the tool: each daily run is an operational dependency, not an ad-hoc script.

This is separate from the Visual Query Builder. The automation works with two local data sources; the query builder is designed to work across cloud-hosted sources in BigQuery. They relate to the same business domain, but solve different problems.

At NGE, I worked on a web interface for teams that needed to understand data flows between internal systems. The task combined frontend views with SQL queries that extracted the flow information those views needed to display.

A flow dashboard is only useful when its queries return information in a form people can navigate and interpret. My work included writing and refining SQL and building dynamic visualizations, alongside documentation and coordination with infrastructure and digital teams.

The underlying databases and system topology are internal. I can explain the type of problem and my responsibilities, but not expose the organization's architecture or data.