Most of my work is monitoring and alerting. A service monitor for a production Linux estate, written against the JDK with no third-party dependency: thirteen protocol-aware checks, an alert engine whose hard part is suppression rather than detection, and ownership resolved from the machine's own Linux groups. It runs as the local monitoring service for that estate at 71 MB resident, 35 OS threads, no swap.
The rest splits between security tooling, wire protocols I would rather implement than import, and tools I actually use. A PostgreSQL client that speaks the frontend/backend protocol directly, SCRAM-SHA-256 included, because taking a driver would have ended the no-dependency claim. An offline client for my school's results portal that implements the evaluation règlement from the official text.
I am a third-year engineering student at ENSAM Meknès, in Electromechanical Engineering, Industrial Digitalization option, which is where the industrial-software half of the degree lives. My most recent internship was at COD Partner, where the monitoring work below was built. Earlier work on SMT production lines and AOI systems is where the defect-analysis dashboard comes from.
- Studying
- 3rd year · Electromechanical Engineering, Industrial Digitalization
- Internship
- COD Partner, service monitoring
- Based in
- Meknès, Morocco
- Bias
- Zero dependencies
Why the counters look quiet
Most of what I would want to show is not public, for four separate reasons. Some is covered by a confidentiality agreement: the monitoring work was built inside a company, against its estate, and the configuration alone is a map of an internal network and of who is on call for each part of it. Some is running in production right now, on machines that belong to someone else. Some is a product rather than a demonstration. And a good deal of it I simply use every day, which means it carries my data, my notes and my habits.
So the fair way to judge the private half is by what it does and what it is built from.