Nasreddine Hanafi

Serves many simultaneous clients from a single thread using non-blocking I/O multiplexed with poll(), rather than spawning a thread per connection. That choice is the architectural centre of the project: threads cost memory and context switches, and they scale badly under high connection counts.

Single-threaded non-blocking I/O introduces its own difficulty. TCP delivers a byte stream, not discrete messages, so a request may arrive split across several reads and a response may only be partially written before the socket refuses more data. Every connection therefore carries its own state machine tracking how much of a request has been parsed and how much of a response remains to be sent.

• Non-blocking, single-threaded event loop with poll() readiness multiplexing
• Hand-written HTTP parser: request line, headers, body, Content-Length handling
• Per-connection state machines for partial reads and partial writes
• Virtual host routing by Host header
• CGI execution via fork/exec with piped stdin and stdout, and CGI environment setup
• Configurable routes, custom error pages, request body size limits
• Correct file descriptor lifecycle management

C++ · POSIX sockets · poll() · HTTP/1.1 · CGI

DEMONSTRATES — Socket programming, I/O multiplexing, protocol implementation from specification, and the practical realities of stream-based networking.

The parsing is the visible part; process orchestration is the substance. A pipeline like cat file | grep foo | wc -l requires forking a process per command, wiring their standard streams together with pipes and dup2, and closing every file descriptor that process doesn't need. Miss one write end and the downstream reader blocks forever, waiting for an EOF that never arrives. Each child must then be reaped with waitpid, or it becomes a zombie.

Signals add a second dimension. When a user presses Ctrl-C, the running child should die and the shell should survive — which means handling SIGINT differently in parent and child, and respecting the constraints on what is safe to do inside a signal handler.

A third subtlety: some builtins cannot run in a child process at all. cd, export and unset mutate shell state, and a child's mutations die with the child — so those execute in the parent.

The command line at the foot of this page is a small implementation of the same ideas: real argument parsing, quoted strings, a pipe operator between builtins, command history — over the content of this site instead of a filesystem. No process model to get right there, but the parsing problem is the same one.

• Tokeniser and parser handling single quotes, double quotes, escapes, and variable expansion
• Arbitrary-length pipelines via pipe() and dup2() with strict fd hygiene
• Input, output, append, and heredoc redirections
• Process creation and control with fork, execve, waitpid, including exit status propagation
• Signal handling that isolates the shell from its children
• Builtins executed in the parent where shell state must persist

C · POSIX · system calls · process management · signals

DEMONSTRATES — UNIX process model, file descriptor management, signal semantics, and parsing.

Layered deliberately. A Matrix library handles allocation and linear algebra. A Statistics library handles data analysis and feature scaling. A CUDA layer offloads matrix operations to the GPU. Gradient descent is implemented in multiple variants, and multi-class classification is handled through a one-vs-rest strategy.

Writing matrix operations by hand makes performance considerations concrete in a way library calls don't. Memory layout determines cache behaviour on the CPU and memory coalescing on the GPU. Kernel launch configuration determines occupancy. And for small matrices, the cost of moving data across PCIe can exceed the compute time the GPU saves — meaning GPU acceleration isn't unconditionally faster, and knowing when not to use it matters.

This project is in active development.

• Custom modular Matrix library with hand-implemented linear algebra
• Custom Statistics library for data analysis and feature scaling
• CUDA kernels for GPU-accelerated matrix operations
• Multiple gradient descent variants
• Multi-class classification via one-vs-rest
• Makefile-based modular build system

C++ · CUDA · GPU computing · linear algebra · machine learning

DEMONSTRATES — GPU programming, numerical implementation from mathematical definitions, library and API design, and performance reasoning.

For each pixel, a ray is cast from the camera through the image plane into the scene and tested analytically against every object — solving the quadratic for sphere intersection, and the corresponding equations for planes and cylinders. The nearest positive root is the visible surface.

Lighting uses the Phong reflection model: an ambient term approximating indirect light, a diffuse term following Lambert's law from the angle between surface normal and light direction, and a specular term producing highlights from the alignment of the reflected ray with the viewing direction. Shadows are determined by casting a secondary ray from each surface point toward each light and testing for occluders — which introduces the classic shadow acne artefact, where surfaces self-intersect at the ray origin, solved by offsetting along the normal by a small epsilon.

Bump mapping adds apparent surface detail without adding geometry. Rather than displacing the surface, the normal is perturbed from a texture before lighting is computed — so a geometrically flat surface responds to light as though it were textured.

• Analytic ray-object intersection for geometric primitives
• Phong shading with ambient, diffuse, and specular components
• Bump mapping via surface normal perturbation
• Shadow rays with epsilon offsetting
• Custom scene description file format and parser
• Vector and matrix mathematics implemented from scratch

                     -----------===                     
               -:::::::::::::::-----===+*               
            ::::...........:::::::----===++*            
         -::.................::::::-----===++*#         
       -::.....................:::::-----===++**#       
      ::..........          ...::::::----====++**#      
    -::........               ..:::::-----===+++**#%    
   -:::.......                  .::::-----===+++**##%   
  -:::.......                   .::::-----===+++***#%%  
  -:::......                     :::-----====+++***#%%  
 =-::::.....                    .::-----=====+++**##%%% 
 --:::::.....                  .::------====+++***##%%% 
 =--::::::....                .::-----=====++++***##%%% 
 =---::::::::..             .::------=====++++***##%%%% 
 ==---:::::::::::...   ..:::-------=====+++++***###%%%% 
 +==-----:::::::::::::::---------======++++****###%%%%% 
  +===------------------------=======+++++***###%%%%%%  
  *+====-------------------=======++++++****###%%%%%%%  
   *++=========----============++++++*****###%%%%%%%%   
    #*++++=================+++++++******###%%%%%%%%%    
      ***++++++++++++++++++++++******####%%%%%%%%%      
       ##*****+++++++++++********#####%%%%%%%%%%%       
         %###***************#######%%%%%%%%%%%%         
            %%################%%%%%%%%%%%%%%            
               %%%%%%%%%%%%%%%%%%%%%%%%%%               
                     %%%%%%%%%%%%%%                     

C · computer graphics · linear algebra · ray tracing

DEMONSTRATES — Applied linear algebra, computer graphics fundamentals, and translating mathematical models into working code.

The machine is stack-based: instructions push operands, pop them, and push results — the same execution model the JVM uses. The interesting design problem is type safety. Operands may be int8, int16, int32, float or double, are created dynamically at runtime from parsed text, and arithmetic between different types requires well-defined promotion rules. Creating the right concrete type from a runtime string is a factory problem; performing arithmetic across types without losing precision or silently overflowing is a design problem.

Error handling is split by phase. Malformed bytecode is a parse-time error caught before execution begins; stack underflow or division by zero is a runtime error. Each has its own exception hierarchy.

• Lexer and parser for a custom bytecode language
• Polymorphic, type-safe operand system with promotion rules
• Factory-based dynamic operand creation
• Stack-based execution engine
• Separated parse-time and runtime error handling with custom exception types

C++ · interpreter design · OOP design patterns · parsing

DEMONSTRATES — Interpreter and VM architecture, C++ object-oriented design, design patterns, and language processing.

Real-time multiplayer breaks the request-response model that most web applications are built on. The server must push state to clients continuously rather than waiting to be asked, and it must remain authoritative — a client that owns its own game state is a client that can cheat. WebSockets provide the persistent bidirectional channel; the server drives synchronisation on a tick.

• Real-time bidirectional communication over WebSockets
• Server-authoritative game state synchronisation
• Modular NestJS backend architecture with dependency injection
• User accounts, authentication, and match history
• Relational data modelling in PostgreSQL
• React frontend

TypeScript · NestJS · WebSockets · PostgreSQL · React

DEMONSTRATES — Real-time systems, fullstack architecture, and stateful backend design.