Some Code Stuff.


Monolite is a simple, type-safe, Structural-Sharing library.

It was originally written for usage in Redux reducers, but can be used anywhere you want to preserve an object immutability.

ImmutableJS is not able to infer type on sub-state-trees as it uses strings to define sub-tree to update:

state.set(['some', 'nested', 'property'], 42);

Monolite, on its side, uses accessor functions to get the target node of the state tree to update:

set(state, _ =>, 42);

This allows TypeScript to do static analysis and completion on the sub-state type, and type of the updated value.

The library uses ES6 Proxies under-the-hood to analyze the accessor function. These functions, though, can be statically resolved, using a Babel Plugin, permitting to target older browsers not supporting Proxy.


ReturnOf was a workaround solution permitting type inference on function returns in TypeScript.

Getting the return type of a function is something particularly interesting, in case of Redux Action Creators or React-Redux containers, to prevent code duplication, for example.

I had also opened a proposal on TypeScript static type inference, enabling a static-only solution for return type inference.

TypeScript 2.8 finally introduced Conditional Types, and added a new ReturnType using a new infer keyword.


WhenSwitch adds Ruby-like case/when statements in JavaScript, through a single when function.

Ternary expressions become too much nested when handling too much cases, and switch statements are error-prone and block-only, WhenSwitch enables simple function conditional flows, as expressions:

const getDrinkPrice = drink =>
    .is('Coke', 1.5)
    .is('Pepsi', 1.8)

This is useful for conditional components in React for example:

    .is('Hello', () => <HelloPage />)
    .is('World', () => <WorldPage />)
    .else(() => (
      <Page404 />

JavaScript not being lazily evaluated though, it adds some overhead on expressions, needing to wrap them in thunks.

Another issue is with TypeScript: The goal here was to have something completely type-safe, but as it was impossible at the moment to define generic type guards, I left this library as it was, and for now only use it for simple cases.

Kay Theme

Kay Theme picture

Kay is my personal code editor theme.

It was designed to be colored, with an 80’s-inspired color palette, without losing focus on code.

Comments and all non-code text are nearly invisible. It also includes a Light Theme.

Redux Electron Global Dispatch

This library provides a simple way to have Redux actions globally dispatched through all processes of an Electron application, thanks to a middleware.

It permits to define easily which actions will be dispatched globally, by configuring the middleware:

    action => action.type === 'INCREMENT'

Or if using the default already-specialized middleware, just define actions with a global property set to true:

const globalIncrement = x => ({
  global: true,
  type: 'INCREMENT',
  payload: x

React Electron

Just a proof-of-concept, but already in production usage in PandaNote.

React Electron provides a simple driver for BrowserWindow declaration in Electron, using React.

    { => (
        onClose={() =>

No more manual management of window properties, all is reactive. Needs to be re-written with a cleaner API though.

42 GraphQL

42 GraphQL was a Façade of the 42 REST API, using GraphQL.

42 REST API was very slow and not easily understable.

The idea here was to wrap it in a GraphQL Schema, and cache resources in a Redis cache for faster responses.

GraphQL permits to reduce heavily number of REST API calls, as server response maps the client query, which resulted in a really fast API.

This was done without access to the database, only upon the public REST API.

42 Scalizer

When creating exercises for the 42 JavaScript Piscine (a 2-week programming bootcamp), I had to create validation scales using a Yaml Schema really difficult to change once written:

  • 100 points were dispatched between each exercise manually.
  • Each exercise had to be numbered by its index by hand.

If an exercise was modified or added anywhere, this had to be done again for all exercises.

42 Scalizer was a simple CLI permitting to automatically harmonize exercise points, and allowing float values.

It also used a much more simple schema, permitted exportation to the legacy format for compatibility, and visualized points progression in a simple chart.

VSCode ClangComplete

When VSCode opened third-party extensions I took a look at their Language Server implementation.

C/C++ Completion was not offered at this time, so I dediced to port the simple Clang Complete, respecting the VSCode Language Server architecture.

VSCode 42 Header

A VSCode extension for 42 Students.

42 projects need to include a 42 header in all source files. This extension provides this header, with automatic refresh on save.


CUT is for C Unit Testing.

It was an attempt to create a simple way to write unit tests for C programs.

It included CutRun, a CLI written in Ruby in charge of compiling and running automatically the tests.

This permitted to reduce need of test-specific configuration in the project. Comment-based directives could be added in top of test files, to provide more compilation flags to CutRun.

The idea was to try to offer a programming experience close from what could be found with Jest in the JavaScript world.

The project was abandonned as I was not sure of the architecture and I was not programming anymore with C at the time.


Kuji was a simple library for NodeJS, simplifying asynchronous tasks.

It was a more generic version of a previous MongoDB-specific library MongoAsyncMultiRequest.

Its goal was to easily create a control-flow graph for asynchronous tasks, by providing dependencies between them. This permitted to optimize the execution timeline.

It was abandonned once I realized that the graph feature, which was the real added-value, was already included in Async as auto.


Zappy is a game composed by three programs:

  • A Server, written in C, emulating a map containing different resources.

  • An AI, written in CoffeeScript/NodeJS, connecting to the server, and trying to evolve by taking resources which permits it to level up.

    Elevation is only permitted after a group incantation. AI need to group themselves on the same cell before being able to do the incantation.

    The tricky part is that AI are not able to know locations nor level of other AI on the map.

    All they are able to do is to broadcast a sound saying that they are waiting for other AI for elevation incantation, which permits to know in which direction AI has to go to find others.

    Each new AI is a fork of its parent.

  • A Graphic Visualizer, written in NodeWebkit/ThreeJS, which shows in real-time what happens on the map.

All inter-process communication was achieved through TCP.


RayTracer was 42 first-semester Graphics final group project.

The imperative was to create a basic raytracer with some simple geometric shapes.

We decided to differentiate from other projects on the UX, by adding an embedded editor usable with mouse/keyboard, a post-render adjustable diaphragm, and some other commands.

This implied performance optimization, so we decided to make the renderer asynchronous from the scene-edition events, and to use multithreading for faster computation.

All this project was written in pure C, upon our LibFt and a subset of LibX called MiniLibX.


FdF was 42 first Graphics project.

It’s a basic rasterizer, which takes a map of altitudes as input, and needs to render a 3D view of it.

No helper library are allowed, so each part (color blend, line-drawing, antialias, camera, projection…) had to be recoded from scratch.

My project added as bonuses:

  • Antialiased lines
  • Movement blur
  • Parallel/One-point perspective switch
  • Adjustable perspective point.

All this project was written in pure C, upon our LibFt and a subset of LibX called MiniLibX.


42 first project.

LibFt is a recode of a subset of the C Standard Library, which is the first building block of all other C projects at 42.

Usage of LibC is prohibited in 42 C Projects, so each project needs to use only functions from our own LibFt.

With the time, multiple functions were added, to include Color Manipulation, Data-Structures, Trigonometry, Infinite Numbers, Hash Function, and a basic Test Framework.


Sudoku picture

This Sudoku was my first C project, when at Faculty of Science of Luminy.

The subject was to create a Sudoku Solver, with a simple graphical interface, using a simple Façade library for LibX/Win32 named EZ-Draw.

Skeleton of the project was given with most of code structure, with program state already defined, the goal was to add a simple back-tracking algorithm to check if the user-given grid was valid and solve it if possible.

My project added a grid generator, with multiple available levels, and some work has been done on the UI to have something responsive and clean.