DEV Community: Abdeldjalil Hebal

Debugging Data Pipelines: From Memory to File with WebDAV

Abdeldjalil Hebal — Sat, 03 May 2025 15:18:34 +0000

Debugging complex data pipelines often involves keeping track of short-lived data--things like Excel buffers, normalized inputs, chart images, and transformed data frames. \
You could log some JSON and start guessing: "Was it the parser in the transform step with the off-by-one error?" But what if you could... just open it in a UI?

This post outlines a setup that turns transient data into inspectable artifacts, with almost zero friction, improving (my) the developer experience dramatically.

The Problem: Poor Debugging Experience

Suppose you are working on a complex data-heavy system, like a business intelligence platform called Pie.

You need to debug its internal data processing pipelines--how data changes from stage to stage, from start to finish.

The QA team might benefit from checking some specific pieces of information that are otherwise hard to validate end-to-end. Your PM might ask you to send them the actual Excel file and formulas being used, so you have to generate a file*, copy it, and email it. This might happen more than once as business requirements and implementation change.

This becomes a recurring pain point with poor developer experience.

(* There might be no file or even file-like thing. You may be working with data frames (Pandas or Polars), event streams, and whatnot.)

The Solution: A Poor Man's Google Drive for Debug Data

The Concept

The ideal approach would be to automatically export the in-memory data as a file and upload it to Google Drive, making it easy to open on Google Sheets, for example.

Up until recently, my crude approach was to write data as .tsv in a local folder when running on my machine. I would open it using LibreOffice Calc or import it into Google Sheets since they support .tsv.

After going down one too many rabbit holes--and nearly building a content repository just to debug Excel files--I stumbled onto a simpler, more streamlined approach:

Treat in-memory data as a file, upload it to a WebDAV server, and inspect with Filestash.

The Architecture

Main components and protocols

This setup combines the following core technologies:

WebDAV Server: Stores debug data files
Filestash: Provides a web UI to browse files (think: minimalist Google Drive)
Collabora Online: Embedded in Filestash to preview office files (think: web LibreOffice)

Why WebDAV?

WebDAV is an HTTP-based standard with broad support across OS file managers (e.g., Windows Explorer or Mac's thing). It's simple to integrate¹, future-proof enough, and has many server implementations: Jackrabbit, Apache Server, and various standalone options.

I've always wondered what the hell was the deal with Apache Jackrabbit, WebDAV, CalDAV, etc. Now, they are starting to make sense.

Apache Jackrabbit is a low-level content repository—think of it as a headless CMS² that also supports WebDAV. I liked the idea of using it for its advanced features—node graphs, querying, tagging—but I couldn't get it running locally. And honestly, it was overkill. A simple WebDAV server would do, so I tried a few and settled on dufs. It's good enough for now. I might revisit Jackrabbit later if the extra features become useful.

See AEM Screens – REST API

Possible alternatives:

[ ] MinIO (S3-compatible local storage).
- I've tested MinIO. See /debug-drive-minio in the GitHub repo.
[ ] FTP (FTPS or SFTP).

Like, just check Filestash's WebDAV adapter

Why Filestash?

Searched "webdav" on GitHub, sorted by stars, and skimmed the top results. Filestash stood out. The missing piece I didn't know I needed—until I did.

Filestash serves a clean web UI to our storage backend—think: a minimalist, local Google Drive. It uses Collabora Online (think: web LibreOffice) to preview office files.

Try their demo (Documents > Office.xlsx).

Pros:

Clean and user-friendly interface.
The storage server (e.g. WebDAV or S3) needs to be accessible only to the backend server and Filestash server.
Meaning, that only Filestash needs to be exposed to the internet.

Cons:

No descending sort support.
LibreOffice Calc (and the web version) handles .csv and .tsv just fine, but Filestash opens them in a basic text viewer.
As far as I can tell, there's no UI option to change the default viewer or editor per file type.
You'd probably need to dive into plugin code (written in Go) and recompile it to get that working.
- Workaround: Just convert the .tsv to a proper Excel file.

Possible alternatives:

[ ] Nextcloud
- It uses either Collabora Online or OnlyOffice.
- Seems to be trying to do too much, but it's popular.

Implementation: Step by Step

To demonstrate the approach, I built a simplified proof-of-concept.

Scenario: Analytics Platform

Imagine you are developing an analytics platform called Pie.

Operation: Generate Excel files with pie charts from query parameters.

Steps:

Get labels and their associated values from the request.
Generate a pie chart image (in-memory).
Generate an Excel file with that chart (in-memory).
Send that file as a response.

Example:

Local version (run pie-generator-backend): http://127.0.0.1:3000/pie?a=10&b=20&c=70
Live version (deployed on Vercel): https://debugging-data-pipelines-demo.vercel.app/pie?a=10&b=20&c=70

It would generate an Excel file containing a pie chart:

Setting Up the WebDAV Server

Using dufs:

dufs --auth admin:admin@/:rw --allow-all

Writing Code for the Client

Using webdav:

import { createClient } from "webdav";

const client = createClient("http://192.168.100.11:5000/", { username: "admin", password: "admin" });

await client.putFileContents("/omega/deep/test.txt", "some text");

Setting Up Filestash

See Filestash install guide.

Basically, just use Docker Compose to set up Filestash and Collabora Online and link them together.

Making it Reusable

Instead of wiring the WebDAV logic directly into each task, I abstracted it into a helper:

async function saveToWebdav(filename: string, data: Buffer | string) {
  const client = createClient(WEB_DAV_URL, { username, password });
  await client.putFileContents(filename, data);
}

Everything runs in Docker, so setup -- whether local or remote -- is painless.
I added dufs to Filestash's docker-compose.yml`³, so everything starts together with a single command:

`sh
cd debug-drive

Sets up dufs WebDAV server, Filestash, and Collabora Online

sudo docker compose up -d

sudo docker compose down
`

Results

Login	Browsing logs	Previewing Excel

Big Wins

Simplifies debugging.
Better transparency and observability.
We can log the saved file's URL using any existing logging infrastructure (e.g. Datadog, Sentry, or OpenObserve).

Challenges and Considerations

File name conflicts:
Easily solvable: Each operation or job should use a unique prefix or folder. This should be a "Correlation ID" if it exists.
Otherwise, a random (preferably sortable) key would do, something like Snowflake ID or UUID v7.
Data retention policy:
When and how to delete old files/folders?
Apache Jackrabbit supports querying nodes and lets us specify custom metadata (e.g. "neverExpires" or "expiresOn" or whatever). That simplifies data manipulation.
Still, we could use simple deletion logic (e.g. older than 3 days) via a cron job.
How to send data to the server:
Options:
- [x] Install a WebDAV client (I mean, what's a new JS dependency).
- [ ] Use a WebDAV server that has a RESTful API: SFTPGo, for example.
- [ ] Use S3/MinIO. It works best if we only need a REST API.
Performance considerations:
- Each task generates only a couple of files.
- Overhead does not matter since we only use it for debugging locally. We might enable it in dev, but obviously not prod.
- Network overhead does not matter since the app backend and WebDAV servers are on the same "machine".

Conclusion

WebDAV + Filestash makes for a surprisingly elegant debugging solution for data-heavy applications.

As always, there's room for improvement:

We need proper data retention and cleanup mechanisms.
The Docker setup could use some DevOps care.
Access control should be tightened (Filestash only needs read access).

The experiment repo is available at https://github.com/djalilhebal/debugging-data-pipelines-demo

END.

WebDAV is so simple that you can create a client using any HTTP client. ↩
It's not a CMS itself, but you can build one on top of it. Adobe Experience Manager does this, exposing content via a RESTful API. ↩
The Docker Compose thing doesn't follow best practices and could be polished. I am not a DevOps engineer and even I can realize that. ↩

Debugging Complex SQL Queries: A Structured Logging Approach

Abdeldjalil Hebal — Tue, 04 Mar 2025 17:58:27 +0000

TLDR:

Use json_build_object to convert relations (tables or CTE/WITH clauses) to JSON.
Write a helper JavaScript function that abstracts the approach.

Background and problem

Imagine you are working on something exciting, colorful, and wonderful like a warehouse management system.

As the system evolves, new features, requirements, and processing logic keep expanding,
SQL queries start becoming more complex, so you resort to using WITH clauses to keep everything organized and maintainable. It works great.

However, when it comes to debugging intermediate steps/states/variables,
while in the application layer, you start reaching out to structured logging libraries like JavaScript's Pino or Golang's slog.

The idea

Postgres has advanced JSON support, so why not do something like the following?

JSON.stringify({
  data1: data1,
  data2: data2
});

In SQL, that would translate to:

SELECT json_build_object(
  'data1', data1,
  'data2', data2
)
FROM data1, data2;

Or, in a way to avoid cross joins and using JSONB (supposedly both are better for performance):

SELECT jsonb_build_object(
  'data1', (SELECT jsonb_agg(data1) FROM data1),
  'data2', (SELECT jsonb_agg(data2) FROM data2)
);

Example

Imagine your project manager assigns the following user story to you:

User Story: Inventory Reorder Alert

As a warehouse manager,
I need a report identifying products requiring immediate reorder based on low total stock quantities across all locations.

Requirements:

Use the provided sample data (locations: S1, S2, S3; products and quantities).

Calculate the total quantity per product across all locations.

Flag products as Reorder if total stock is below 50 units; otherwise, mark as Sufficient.

Display only products needing reorder in the final output.

Acceptance Criteria:

Output columns: product, stock_status.

Only include rows where stock_status is Reorder.

You could solve it using a single SQL query.

Notice that we are using CTEs and are only interested in Step 1 and Step 2.

-- Define raw data using the VALUES clause.
WITH raw_data(location, product, quantity) AS (
    VALUES
        ('S1', 'Cocoa beans', 40),
        ('S2', 'Cocoa beans', 10),
        ('S2', 'Sugar', 20),
        ('S3', 'Vanilla', 75)
),
-- Aggregation: Get total sum per product.
step1 AS (
    SELECT product,
           SUM(quantity) AS quantity
    FROM raw_data
    GROUP BY product
),
-- Transformation: Add a stock status based on total quantity.
step2 AS (
    SELECT
         product,
         quantity,
        CASE
            WHEN quantity < 50 THEN 'Reorder'
            ELSE 'Sufficient'
        END AS stock_status
    FROM step1
),
-- Filter
step3 AS (
    SELECT
        product,
        stock_status
    FROM step2
    WHERE stock_status = 'Reorder'
),
logged_steps AS (
    SELECT jsonb_build_object(
        'step1', (SELECT jsonb_agg(step1) FROM step1),
        'step2', (SELECT jsonb_agg(step2) FROM step2)
    ) AS json_payload
)
SELECT *
FROM step3, logged_steps

Better DX

We can reuse this logic with the help of query builders like Knex and its modify method.

Helper:

function withLoggedSteps(qb, ...relations) {
  qb.crossJoin('logged_steps');
  qb.select('logged_steps.json_payload');
  const pairs = relations
    .map(rel => `'${rel}', (SELECT jsonb_agg(${rel}) FROM ${rel})`)
    .join(', ');
  qb.with(
    'logged_steps',
    knex.raw(`SELECT jsonb_build_object(${pairs}) AS json_payload`)
  );
}

Usage:

knex
  .select('step3.*')
  .with('generated_data', '(VALUES ...)')
  .with('step1', '...')
  .with('step2', '...')
  .with('step3', '...')
  .from('step3')
  .modify(withLoggedSteps, 'step1', 'step2')
  .then(rows => console.log(rows));

Interactive demo

See: Live demo

Using:

PGLite in-memory embedded Postgres database.
Knex and a PGLite "driver"
- https://pglite.dev/docs/orm-support#knex-js
- https://github.com/czeidler/knex-pglite
Some REPL library (vue-live)

Performance Disclaimer

Let's be honest - in my day-to-day development, I'm typically working with small, filtered datasets.
Most of the time, I'm debugging queries for a specific product or a narrow time range.

So while these JSON logging techniques work wonderfully in my development environment, I haven't extensively tested them on massive datasets that might process millions of rows.

When you're in development mode, logging overhead is practically unimportant.
We're here to understand why our queries behave strangely and to figure out where your complex query goes wrong.

I am aware of alternative approaches like using RAISE NOTICE or inserting intermediate results into temporary tables. I have not tested them.

Conclusion

And there you have it, implementing JSON structured logging in SQL thanks to Postgres features.

Live demo

END.

Using SVG as a Camera (Danganronpa Back and Forth)

Abdeldjalil Hebal — Tue, 06 Feb 2024 13:05:00 +0000

I like SVG. I like Danganronpa. I tried to recreate a Danganronpa-like camera panning effect in SVG.

TLDR:
We can use SVG <symbol> and <use> elements to create a camera, similar to the ones you may find in video editors, game engines, and the like (After Effects, Unity, and Blender, to name a few).
The goal was to recreate a panning effect as seen in Danganronpa games or fan projects.

PS: This is not a step-by-step tutorial.

This is mostly a proof of concept.
I will provide a high-level overview, mention specific implementation details, and link to further readings.
I assume you are somewhat familiar with CSS animations and SVG.

The idea

Danganronpa panning effect

In official Danganronpa games and fan projects: Danganronpa F: Shattered Hope (made in After Effects), Project: Eden's Garden (made in Unity), and even some memes/remixes.

If I recall correctly, in Danganronpa 2, the following sequence happens:

At the start of the animation, blur all characters except the active speaker.
Move the camera to the active speaker.
At the end of the animation, unblur all characters.

We could try to recreate that.

We also could make it more like Danganronpa F:

Make it 2.5D (3D transforms of 2D sprites).
Add depth of vision effect.
Add motion blur effect.
Etc.

But let's focus on camera panning for now.

Danganronpa F tutorial

Danganronpa F: Cancel.
Notice that there are two cameras: A complete view of the stage and a close-up view of the active speaker (again, same stage).

One of Danganronpa F's creators made a video tutorial about it.
They use After Effects, but their techniques can be employed in other contexts, like Web technologies.

See Panning and Camera - Fanganronpa Tutorial (AE) | YouTube.

Essentially, they:

Set up the composition or world (background and characters).
Use a camera (Camera 1) to show the entire composition, covering the entire screen.
Draw a semi-transparent overlay.
Use another camera (Camera 2) to show a close-up view of the composition.
Update Camera 2's position (x, y, and z) to switch focus between characters... Panning.

Main layers and the main idea

Danganronpa V3: World.

Danganronpa V3: World + overlay.

Danganronpa V3: World + overlay + close-up camera + UI.
Notice that the girl wearing a hat (Himiko) is still visible behind the overlay.

Translating concepts

Naming things is hard. So, let's reuse terms commonly found in game dev: scene, UI, world, and camera. (These will be our variables or element IDs.)

They are comparable to concepts found in game engines (e.g. Unity or Ren'Py), video editing software (e.g. After Effects), or 3D animation software (e.g. Blender).

Elements:

The scene is the whole composition.
The world contains "game" objects (the background, characters, items, etc.).
The camera defines a viewport or perspective on the world.
The UI acts as an overlay on top of the world and includes textboxes and whatnot.

Pseudocode

<svg id="scene">
    <g id="world">
        <image id="background" />
        <image id="nagito" />
        <image id="hajime" />
    </g>

    <symbol id="camera" viewBox="...">
        <use href="#world" />
    </symbol>
    <use href="#camera" />

    <rect id="overlay" />

    <g id="ui">
        <text id="speaker">???</text>
        <text id="dialog">No, that's wrong!</text>
    </g>
</svg>

Impl details

Suppose this is our world and we want to change the camera focus from Nagito (blue rect) to Hajime (red rect):

To animate the symbol's viewBox, we could use GSAP or a similar library, but since the animation is basic, I decided to use only the <animate> element.

Alternating: SVG does not have something similar to CSS animation-direction: alternate. To recreate it, we have to define two animations and make each one start at the end of the other. To start this loop, we also set one of them (toHajime) to start at 0s in the document's timeline (i.e. once the document loads).

<!-- From Nagito to Hajime and then back to Nagito -->
<animate id="toHajime" begin="0s; toNagito.end" />
<animate id="toNagito" begin="toHajime.end" />

Delaying: We want the camera to pause for a brief moment (say, 1s) at each sprite before moving to the other.
Turns out, we can write something like toNagito.end + 1s to delay the execution of the animation, relative to another event.
We also use fill="freeze" to keep the animation's last frame's state, similar to CSS animation-fill-mode: forwards.

2.5D or 3D perspective: Sadly, SVG does not support 3D transforms. That's why everything is 2D.

Custom easing: Check oak's post.
Easing function used: easeInOutQuint (cubic-bezier(0.86,0,0.07,1)). See https://easings.co.

Conclusion

???

Takeaways:

Transferable knowledge and whatnot.
SVG is cool.

Check it live: https://djalilhebal.github.io/dr-back-and-forth/svg-ver
Source code: https://github.com/djalilhebal/dr-back-and-forth

Cropping videos with ffmpeg, but visually?

Abdeldjalil Hebal — Fri, 29 Dec 2023 17:22:32 +0000

There are many ways to skin a cat. The same thing can be said about editing videos.

This post is specifically about cropping.

By the end of it, you will learn about some challenges when dealing with multimedia on the Web, how to solve or avoid them, what ffmpeg and SVG can do, and how we could build a graphical video editor using these technologies.

The post follows the following plan:

How normal people do it.
My manual workflow.
My attempt at improving this flow and making it "semi-automatic".
Possible improvements to my attempt.
Existing solutions that already implement those possible improvements.
Conclusion.

Normal way

Just use a graphical video editor like Shotcut.

Manual approach

I often use a command-line program called ffmpeg.

Conveniently, ffmpeg has a filter called crop that is used to crop stuff:

ffmpeg -i in.mp4 -filter:v "crop=out_w:out_h:x:y" out.mp4

My usual workflow:

Take a snapshot:
Using VLC's snapshot shortcut: Shift + S.

But I have a habit of using the following instead: Menu or right click > V > V > S.

On Windows, the snapshot will be saved in ~/Pictures/.
Define parameters:
Using Inkscape:
Import the snapshot to a new document.
Draw a rectangle (hotkey: R).
Copy the rect's values: x, y, w, and h.

Cropping:
Using ffmpeg:
ffmpeg -i in.mp4 -filter:v "crop=607:1080:819:0" out.mp4
Done.

Why not use a proper (GUI) video editor?
Laptop too shit.

Also, this is not a huge issue since I hardly ever need to perform this.
Still, I thought I might as well try to automate it... or make it "semi-automatic" at least.

Semi-automatic approach

Let's write a simple web app that helps us crop stuff using ffmpeg: ffmpeg crop helper.

The idea is simple:

Display an img or video (the original media).
Display a resizable and moveable overlay (the crop mask).
Generate an output based on the overlay's size and position.

Dimensions problem

Let's consider an example with specific dimensions to illustrate a possible challenge.

Original image dimensions:

Original image width: 1000 pixels
Original image height: 800 pixels

Transformation:

The image is displayed on a webpage and is scaled down by 50%.

New image dimensions:

Scaled image width: 500 pixels (50% of 1000)
Scaled image height: 400 pixels (50% of 800)

Now, let's assume we want to define a crop area on this scaled image using traditional coordinate systems without considering scaling.

Traditional coordinates:

We want to crop a rectangular area starting from (100, 100) and with dimensions (300 x 200).

Challenge:

In the original coordinate system, the starting point (100, 100) refers to a location on the original image with dimensions (1000 x 800).
However, when the image is scaled down, the coordinate (100, 100) on the scaled image does not correspond to the same absolute location on the original image.

Meaning:

If we use the same coordinates without considering the scaling, our crop area will be misplaced, and the dimensions won't be accurate.

Also, keep in mind the size of the element (image in our example) may change dynamically due to the environment: screen rotation, styles added, etc.

Solution:

We need to convert values between coordinate systems. Geometry problem. Math. I can't be bothered with that.

Actual solution:

Instead, let's keep everything (the image and crop mask) in a shared coordinate system so we don't have to convert anything.
It should be able to scale freely.
That description kinda feels like SVG and its viewBox attribute. SVG is our canvas.

As for the original media, we can use the foreignObject SVG tag to embed an HTML video or img element. This is the original media.

A rectangle can be used to define the crop area.

Using SVG satisfies the need for a consistent coordinate system. With viewBox, we can define the coordinate system based on the original image dimensions, even when the image is scaled or transformed, ensuring accurate and consistent positioning of elements within the SVG canvas.

There is no building way to make an element (HTML or SVG) easily resizable and moveable. And, no, CSS resize attribute does not help much.

To build a decent UI, we need to create different event handlers (like at corners) and manage different mouse/pointer events.

I've done something similar in Java (Swing); it's bothersome and hard to get right; I don't wanna redo it again, so a crude solution will have to do... for now.

Let's just display various inputs and let the user change them.

Pseudocode

<form>
    Original file:
    <input type="file" accept="image/*,video/*" />

    Crop area:
    Width <input value="$out_w" type="number" min="0" max="$orig_width" />
    Height <input value="$out_h" type="number" min="0" max="$orig_height" />
    X <input value="$out_x" type="number" min="0" max="$orig_width" />
    Y <input value="$out_y" type="number" min="0" max="$orig_height" />
</form>

<svg viewBox="0 0 $orig_width $orig_height">
    <foreignObject class="crop-object">
        <img /> or <video />
    </foreignObject>

    <rect class="crop-mask" />
</svg>

<output>
    <code>
    ffmpeg
        -i in.mp4
        <b>-filter:v "crop=$out_w:$out_h:$out_x:$out_y"</b>
        out.mp4
    </code>
</output>

Some implementation details

Some implementation details (or problems) worth mentioning:

How do we know when the media has loaded?
How to get the original media's dimensions (intrinsic width and height)?

When:

For img: load event fires whenever the src resource loads.
It fires even if we set img.src = img.src.
For video: loadedmetadata event when the video's metadata is loaded. This includes its dimensions.

Intrinsic dimensions:

For img: .naturalWidth and .naturalHeight.
For video: .videoWidth and .videoHeight.

Why couldn't both img and video properties be called intrinsicWidth and intrinsicHeight? Web things, I guess.

Rough implementation

I built a rough implementation in Vue.

It works as described above and supports both images and videos.

Possible improvements:

Resize and move the crop area using a pointer (mouse).
Preview the output.
Drag and drop files.
Define presets (like common aspect ratios).
~~Automatically determine the file type (image or video).~~

It's unlikely that I implement them anytime soon. After all, this was just a proof-of-concept.

What concept? You ask. I'll answer that in a bit.

Existing solutions

There exist many projects that address the mentioned "possible improvements".

Other than dedicated video editors, some open-source projects serve as graphical user interfaces for ffmpeg:

Marco's clip is my favorite by far.

It also supports clipping, and compression, provides presets (aspect ratios), and allows the user to drag and drop the video file. And it works entirely in the browser.
Overall, its UX is epic.
Another one is Manfred's jib-FFmpeg, which is described as "Yet another graphical user interface for FFmpeg".
I haven't tried it, but it seems unmaintained and depends on react-image-crop.
react-image-crop and similar components let you define the cropping area for images, videos, or other elements.
It handles the conversion between coordinate systems (not sure about layout shifts).
We could use it.

Conclusion

Takeaway: There are many ways to solve a problem.

Also, FFmpeg and SVG are cool. JavaScript, not so much.

The goal of this project was to test the concept of using SVG to avoid coordinate transformation challenges while creating a video editor. The proof-of-concept works as expected.

If you are curious, you can check it:

Live: https://ffmpeg-crop-helper.vercel.app
Source code: https://github.com/djalilhebal/ffmpeg-crop-helper

Pronouncing names using TTS

Abdeldjalil Hebal — Tue, 12 Dec 2023 19:50:00 +0000

I'm Abdeldjalil. Go ahead, try saying my name. You probably don't know how to pronounce it, and that's fine.

Let's consider the diverse world of names out there.
Some are straightforward like Alice, while others might need a bit of explaining, like "Djalil, but the 'D' is silent".
And then there are those complex ones like Wriothesley. Wikipedia might tell you it's pronounced /ˈraɪəθsli/ (RYE-thes-lee), Genshin Impact might suggest /ˈraɪzli/ (RYZE-lee), but others just call him /ˈraɪ.oʊ/ (RAI-oh).
Wrio is super omega cool, don't you agree? Just look at him!

Let's refocus—

I'm the kind of person who loves diving into new concepts and words. Even when I'm offline, I rely on dictionaries (physical or some Wiktionary-based app) as my go-to resource to learn new terms, and this habit propelled me into learning IPA transcription to pronounce them properly.
Look at me, trying to romanticize a simple project that helps people pronounce names and stuff.

Let's just get into it.

Honestly?
Why make this thing?

To showcase that I can use cloud-y stuff like AWS or Google Cloud.

Ended up using Vercel and Azure because I ain't paying no money for this thing, but I want it to work "forever".

I even resorted to using Next.js when a simple page would do.

The things we do for recognition. :p

Naming it

This is the most important step—coming up with a name that captures the project's essence.

The goal was to make an IPA vocalizer with a focus on pronouncing names:
A name's pronunciation, vocalization, or sound = Name + Sound = Namae (Japanese for "name") + Ne (Japanese for "sound") = Namaene.

The name also draws parallels to Vocaloid, a singing voice synthesizer, and specifically characters like Miku Hatsune (First + Sound) and Len Kagamine (Mirror + Sound).

Perfect. Now, we just need to make it.

Building it

The premise is simple: Tell the TTS engine to read the IPA text and return the audio file to the user.

Synthesizing

Speech Synthesis Markup Language (SSML) is an XML-based markup language that lets you adjust text-to-speech output attributes such as pitch, pronunciation, speaking rate, and more.

The <phoneme> tag accepts pronunciation transcription in IPA:

  <phoneme alphabet="ipa" ph="ˈraɪzli">Wriothesley</phoneme>

Since we are specifying the word's pronunciation, we do not need to include it:

  <phoneme alphabet="ipa" ph="ˈraɪzli"></phoneme>

We can go further. Since the XML element contains no children, we can use a self-closing tag:

  <phoneme alphabet="ipa" ph="ˈraɪzli" />

Let's imagine we've written a generateSsml(ipa).

Next, we will call some TTS engine or service to speak the SSML.

Return the audio data ("speech production") with appropriate headers (mainly Content-Type), and let the client (e.g. browser) deal with it.

Choosing a TTS service

Requirements

This is what we are looking for:

Buzzwordy enough. It should be something listable on a LinkedIn Skills section (serverless, distributed, frameworks, blockchain, and can I fit WordPress somewhere?).
Free. We are not willing to pay anything.
Forever. It should work "forever".
IPA support, probably via SSML.

Options

Amazon Web Service (AWS)
- SSML? Yes.
  - Generating Speech from SSML Documents | Amazon Polly
- Free? Not really. Only "12 months free", not "free forever".
Microsoft Azure
- SSML? Yes.
  - Pronunciation with Speech Synthesis Markup Language (SSML) - Speech service - Azure AI services | Microsoft Learn
- Free? Yes, but is it enough?
  - Text to Speech / 0.5 million characters free per month. Speech Services Pricing
Google Cloud
- SSML? Yes.
- Free? Yes, enough.
  - Free per month / Standard voices / 0 to 4 million characters (https://cloud.google.com/text-to-speech/pricing)
  - Also, "new customers get $300 in free credits to spend on Text-to-Speech." (https://cloud.google.com/text-to-speech/)

In short, AWS seems cool and I like its voices (even since they were called Ivona), but I needed something that's more future-proof.

Both Microsoft and Google are fine, but having 4M characters per month seems more appealing than 0.5M.
Checking Google Cloud's TTS samples, I even liked their SDK (all request config in one object + you can just await the response).

So, Google Cloud it is... Or not.

For some reason, my credit card got declined, so I resorted to using Microsoft's services since I already had an account.

So, for now, Azure it is.

Using the service

In a perfect world, there would be a simple async function speakSsml(options) that resolves to the audio data as a Blob or an ArrayBuffer.
Google Cloud SDK does something similar to what we want:

const textToSpeech = require('@google-cloud/text-to-speech');

async function synthesizeSsml(ssml) {
  const client = new textToSpeech.TextToSpeechClient();

  const request = {
    input: {ssml: ssml},
    voice: {languageCode: 'en-US', ssmlGender: 'FEMALE'},
    audioConfig: {audioEncoding: 'MP3'},
  };

  const [response] = await client.synthesizeSpeech(request);
  // Do something with the audio data: response.audioContent
}

While in Azure's SDK, we need to wrap the call in a Promise:

import * as sdk from 'microsoft-cognitiveservices-speech-sdk';

async function synthesizeSsml(ssmlText) {
    const speechConfig = sdk.SpeechConfig.fromSubscription(process.env.SPEECH_KEY, process.env.SPEECH_REGION);
    speechConfig.speechSynthesisVoiceName = "en-US-JennyNeural";
    speechConfig.speechSynthesisOutputFormat = sdk.SpeechSynthesisOutputFormat.Ogg24Khz16BitMonoOpus;
    const synthesizer = new sdk.SpeechSynthesizer(speechConfig);

    return await new Promise((resolve, reject) => {
        synthesizer.speakSsmlAsync(ssmlText,
            function (response) {
                if (response.reason === sdk.ResultReason.SynthesizingAudioCompleted) {
                    resolve(response.audioData);
                } else {
                    reject(response.errorDetails);
                }
            },
            function (err) {
                reject(err);
            });

    });
}

Decent.

Now, let's imagine that the backend framework we will be using uses Fetch API interfaces, namely Request and Response.
That would be awesome since Response accepts a body of type ArrayBuffer, which is convenient for our use case.

A handler for GET /api/speak/?ipa={ipa} can be written like:

async function GET(request) {
  const {searchParams} = new URL(request.url);
  const ipa = searchParams.get('ipa');

  const ssml = generateSsml(ipa);
  const data = await speakSsml(ssml);
  const contentType = 'audio/ogg';

  return new Response(data, {
      headers: {
        'Content-Type': contentType,
        status: 200,
    });
}

We added a Content-Type header to help clients handle the response correctly.

Its value is set to audio/ogg because that's what we configured the SDK to return. By default, it uses some wav format, but you can change it to a few other formats like mp3 or ogg. Both of the mentioned alternatives use less space (they are compressed) and offer good quality. From my testing, ogg seems a bit better in terms of quality and size. But it ultimately does not matter whichever you pick.

Caching

Speaking of headers and optimization, to improve the user experience (latency) and in order not to exceed our quota, we can tell the client it should cache the result forever.

Let's add a Cache-Control header to the response.
The following says: Anyone (public) can cache it; it stays fresh for 1 year (31536000 seconds); no need to revalidate since it won't change (immutable) while it's fresh".

+    'Cache-Control': 'public, max-age=31536000, immutable',

Handling quota

Caching doesn't solve our issue. We must not exceed the quota.

For all providers I checked (meaning Azure and Google Cloud), you need to ensure you don't go above the free monthly quota!

Their Monitoring and Billing APIs are not good enough: We can (and probably will) be notified to pause our usage after we exceed the quota. We ain't paying nothing, not a single cent.
(For example, see Google's guide about stopping billing: "There is a delay between incurring costs and receiving budget notifications.")

We need to implement our own quota tracker.

What to count

Calculating the cost of each call differs from provider to provider, and even from service to service.

Tags: Some SSML elements (e.g. speak and mark) are omitted.

Whitespace is usually counted.

But what about the characters?

Azure specifically counts each Chinese character as 2 chars. Google Cloud says it counts each Japanese character as 1 character.
But what does that even mean?

Consider: The Japanese word for love is 愛, pronounced Ai, as in Ai Kotoba (Love Words feat. Hatsune Miku).
How many characters are there?

JavaScript encodes strings in UTF-16. The word's length is 1.
Azure says Chinese characters (and other multi-code ones) count as 2, so the word's cost is 2.
Google Cloud says each Japanese character is considered one character. Only hiragana and katakana? Does that include kanji ("Chinese characters")? Does 愛 count as 1 character?
愛 is a multi-byte character. Specifically, it is encoded in 3 bytes.

What about emojis if the user decides to send them for whatever reason?

The safest bet is to use the SSML text's length in bytes as character count, as Google Cloud docs suggest ("[...] the number of characters will be equal to or less than the number of bytes represented by the text.").

We could optimize this, but, for now, let's play it safe.

Using TextEncoder:

function countCharacters(ssmlText) {
    const textEncoder = new TextEncoder();
    // returns Uint8Array
    const encoded = textEncoder.encode(ssmlText);
    return encoded.length;
}

Where to keep track of the count

One thing is certain: We cannot* be sure how requests are going to be handled.
* Or should not or do not want to bother with.

Namaene may be deployed on some distributed, horizontally scalable platform. Or it might be running locally: Node executes requests concurrently.
Or both. You know, production vs dev.

In short, we need a way to keep track of the counter between isolated processes. Think: Transactions or similar atomic operations.

Redis sounds like a good solution.

Whena request arrives, generateSsml, countCharacters(/* in the */ ssmlText), then increment the counter like:

INCRBY totalCount requestCount

Resetting the counter

The monthly quota resets... every... month.

We need to reset our counter.
There are multiple options to do it, including:

A cron job.
Redis transactions.
Redis functions or scripts.
Do not reset anything.

The last option is appealing because it seems simple and overcomes some limitations:

INCRBY is op.

INCRBY has built-in handling of non-existent Keys.
This behavior can simplify the initialization process, especially when dealing with a new month.

It deals with overflows. The command will fail if its execution would cause an overflow.

All of this means we do not need to GET the current value and then increment it (a la double-checked locking).

Spoiler for the next section: Vercel KV (free/Hobby) also has a quota of 30k requests per month. What does "request" mean?... Let's not get into that.
At any rate, the fewer commands we use, the better.

Just use a different key each month (e.g. "counter:yyyy-mm"):

function getCurrentCountKey() {
    // "The timezone is always UTC" - toISOString on MDN
    const nowIso = new Date().toISOString();
    const yearMonth = nowIso.substring(0, 'yyyy-mm'.length);
    const counterKey = `counter:${yearMonth}`;

    return counterKey;
}

INCRBY counter:2023-12 500 increments the counter by 500 and then returns the new value.
Next month, the counter key will automatically change to counter:2024-01. INCRBY will not find this key, so it will be set to 0 before incrementing.

Having decided on this ~~lazy~~ practical approach, we can think of it as an opportunity to implement another important feature: Maintaining a historical record of monthly usage/counts.

To get a list of all counter keys (then iterate over them):

KEYS counter:*

A better approach might be to use hash commands: HINCRBY and HGETALL.
This is not of high priority.

Deploying

Having already tried Netlify (in 2020) and Vercel (recently), I decided to use Vercel mostly because I like their website's design—

I mean the UX and DX (docs, APIs, and all). Plus, they provide or are behind some of the technologies we ~~wanted to~~ use:

Serverless Redis
Serverless functions (e.g. the /api/speak handler)
Next.js (it uses Fetch API-based classes)

This is a rough sketch of what we ended up with:

GET /api/speak?voice={voice}&ipa={ipa}

Conclusion

This was a simplified overview of the project and some of the technical decisions I had to make.

It is far from perfect, but... I'm learning.

Feel free to explore the project's repo or try it live.

Thanks for reading.

— Djalil (PS: The D is silent.)

その名前をさあ、言ってごらんこのぼくの名前を！

Experiment: Playing a non-English visual novel through Google Translate's camera

Abdeldjalil Hebal — Sat, 30 May 2020 21:41:25 +0000

I'm a big fan of a video game series called Danganronpa--a Japanese visual novel about Hope and Despair, and a "robotic bear" forcing students to kill one another.

The other day I came across a trailer for a game which I was hooked on right away because, as Reddit user u/Little-Big-Smoke commented,

Have to admit, that trailer indeed screams "Neon Danganronpa"

After doing some research, I learned that it's called Zetsubou Prison (Despair Prison), developed by Studio Wasabi, and is available for Android, iOS, and Windows but only in Japanese and Chinese.

I desperately wanted to play it... and that's what I've done.

This post tries to follow this structure:

How I actually played it
What I tried
Two ideas for automating the process
Some conclusions

How I played it

Being a Linux user (Kubuntu v18.4), I ended up downloading Steam and using Steam Play (Proton v5) to run the game on PC.

For some reason, the Steam version provides only the Chinese version.

Anyway, I used Google Translate's instant camera translation functionality (on my Android phone) to read the screen. (One could say I played "through the looking glass." #funny 🤦)

Google Translate does a surprisingly well job in translating from Chinese to English.
A few translation mistakes were obvious but I "mentally fixed them" from the context.

Although Chinese and Japanese use the same characters (kanji) to write names, they differ in pronunciation. This is why I sometimes would switch to Japanese to learn the characters' names and then switch back to Chinese to continue reading dialogues.

And that's how I played the first chapter of Despair Prison... like a savage... and I enjoyed it.

Screenshots

Precious bois, from left to right: Rui, Shiro, and Kisuke.

Shiro: "Huh? What did you recall/think of?"

Shiro's introduction: "I'm Fuyutsuki Shiro! I look forward to your guidance/advice."	Shiro's profile: He seems like a best boi but a little suspicious.	Shiro's enjoying the situation

Tried: Screen translator apps

On Android.

Of the screen translator apps I tried, Tranit was the most promising one and which had the nicest UX.

Unfortunately, it didn't work in this game.

Since Tranit used Android accessibility features to read/translate the screen, I tried to use axe for Android to "debug" it but axe couldn't detect anything. I assume the game developers did what's equivalent to drawing using the Canvas API instead of using native and semantic elements.

Idea: Doppelganger.js

Why not recreate the "instant camera translation" thingie on the desktop?

This should be doable using Screen Capture API, Google Vision and Translate APIs, Electron, and maybe RobotJS.

This works best for Japanese and Chinese visual novels and text-focused JRPGs with sparse animations and non-animated sprites.

/**
 * Doppelganger.js
 * As in those doppelgangers we find in Despair Prison
 * Pseudo-code for a program that adds a live translation overlay for the desktop
 */

const electron = require('electron');
const robot    = require('robotjs');

const Vision    = require('@google-cloud/vision');
const Translate = require('@google-cloud/translate');
const toEnglish = (text) => Translate.translate(text, 'en');

// The overlay shoud support input forwarding (i.e. mouse and keyboard events)
// either manually (listen for these events and emulate them in the original window using RobotJS)
// or hopefully automatically (see https://www.electronjs.org/docs/api/frameless-window )
const overlayWindow = new electron.BrowserWindow({ transparent: true, frame: false });

// Actually, only update the overlay if there is a change in the capture stream
// this is better for performace and to respect the Google's limitations
while (true) {
  // Or maybe use https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capture_API
  const capture = robot.screen.capture();
  const textAnnotations = Vision.annotateImage(capture);
  const translatedAnnotations = textAnnotations.map(obj => ({
    ...obj,
    text: toEnglish(obj.text)
  }));

  // Update the "doppelganger" window's DOM with text elements that "overlay" on the original texts
  // (with the help of annotation's metadata like the bounding box)
  updateOverlay(overlayWindow, translatedAnnotations);
}

Idea: Emulate the Google Translate app

Trick the Google Translate app into translating the screen for us:

Configure the operating system to allow creating "virtual video devices" (the v4l2loopback project on GitHub).
FFmpeg: Record a specific window (question on Stack Overflow).
FFmpeg: Use the desktop (or just that specific window) as a "fake webcam" (answer on Super User).
Android Studio: Set that "fake webcam" as the camera in the Android emulator (answer on Stack Overflow).
Install Google Translate in the Android emulator (as a tablet or TV device, to have a large screen).
Open the game and Android emulator windows side by side.
- Or open them on different monitors (if you have).
- Or maybe turn the emulator window into an "overlay" (as in Doppelganger.js) by making the window transparent and click-through (question on Ask Ubuntu).
Enjoy(?)

Conclusion

So what did we learn?

Designing with accessibility and inclusivity in mind helps everyone. (Tranit issue)
"There's more than one way to skin a cat."
Solving problems is as fun as playing the actual thing.

I probably will not implement these solutions/ideas but I might update this post and add some diagrams to better explain them just because.

Thank you for reading.

References

Despair Prison's trailer on YouTube (WARNING: CONTAINS FLASHING IMAGES!)
Despair Prison on Steam
There's an open source project called Screen Translator (on GitHub and on Softpedia) which I haven't tried but seems okay.

ZeroMessenger: Improving Facebook Zero's messaging functionality

Abdeldjalil Hebal — Mon, 06 Apr 2020 19:32:42 +0000

Djezzy is an Algerian mobile network operator. Djezzy provides a zero-rated, text-only version of Facebook: Facebook Zero (0.facebook.com) or 0FB for short.

Some students (like myself) are practically poor and cannot afford real internet access so they end up relying on this service. What I'm presenting here is my attempt at making Facebook Zero a better shit.

Turning something like this:

... into something like this:

Disclaimer: This drafty post is a super simplistic explanation of how I wrote an incomplete project that used a discontinued service.
Still, I wanted to publish it since it might be useful to others...

Idea

After "studying" (i.e. using) Facebook Zero for over a year, I realized that the website is very predictable and has a RESTful-like "structure".

The idea is simple: If I can manipulate only texts then that's what I'm gonna do:

We treat Facebook Zero as if it were merely a messy database and an intermediate to exchange data.

So, to send a photo (or any file for that matter), first, convert it to text (base64) and send it as a text message.

On the other end of the wire, the recipient should convert it back to binary and view it.

Gathering data

As I have already intimated, 0FB pages are so predictable that a few document.querySelector lines allow us to obtain the necessary information to work with.

Profiles

These are the most important information we need: id, name, username, hasGreenDot (which signifies the user is active).

name is easily obtained using this simple statement:

const name = document.querySelector('#objects_container strong').innerText // 'Djalil Dreamski'

username, phoneNumber, and gender...

// Okay, suppose we are on a profile's info page (e.g. https://0.facebook.com/zuck?v=info)
// We can use these two lines to get the user's gender:
const rawGender = document.querySelector(`#root [title="Gender"]`).innerText.trim() // 'Gender\nMale'
const gender = gender.split('\n')[1].toLowerCase() // 'male'

// The above two lines can be used to get other (*useful*) pieces of information, like the `username`
// so let's turn it into a more general and less error-prone function:
function getAttr(attr, lowerCase = true) {
  const $container = document.querySelector(`#root [title="${attr}"]`)
  if ($container) {
      let text = $container.innerText.trim()
      if (lowerCase) text = text.toLowerCase()
      const val = text.split('\n')[1]
      return val
  } else {
      return ''
  }
}

// Now we can use it like this:
const username = getAttr('Facebook') // '/zuck'
const phoneNumber = getAttr('Mobile') // ''

id As far as I know, Facebook assigns an id (FBID) to each of its objects (profiles, groups, posts, messages, etc.). In every 'message-able' profile ("page" or "user") webpage, there exists a 'Message' button (a link, actually). We can use this link to get the profile's id. We can either look for a link whose text content consists of "Message", or whose URL starts with a specific prefix. I chose the latter approach:

// Supposing we're on a user's page, and that this user has a 'Message' button/link
const linkPrefix = 'https://0.facebook.com/messages/thread/'
const messageLink = Array.from(document.querySelectorAll('a')).find(a => a.href.startsWith(linkPrefix))
const [, id] = messageLink.match(/thread\/(\d+)/)
// If we were on 0.facebook.com/zuck, 'id' would be '4'

My id

We assume I'm already logged in. To get my id, we go to my profile page (/profile.php) and extract it from the "Registo de atividade" ("Activity Log") link.

We basically repeat the same work we did earlier with id but this time the link has this pattern: https://0.facebook.com/<MY_ID>/allactivity.

Note: Many pieces of code in my app are currently language-specific (only English works for now).
hasGreenDot was a little tricky at first as I couldn't just use a simple CSS selector that identifies it:
Apparently some parts of Facebook Zero pages get automatically minified/uglified
so some classes get renamed randomly (e.g. 'cg', 'rt', etc.).

One thing was sure: If the current page contains a greenDot, there will be a class in the 'style' tag, whose body contains nothing but this rule: {color:#6ba93e;}.

// We could use the above information to do this:
const styleHtml = document.querySelector('style').innerHTML
const hasGreenDot = styleHtml.includes('{color:#6ba93e;}')

// But since we will be using that approach in other places (and for other purposes),
// we actually use a method that retrieves the class's name if it exists.
function getClassName(rule) {
  const styleHtml = document.querySelector('style').innerHTML
  const escapedRule = rule.replace(/[{}().]/g, '\\$&') // This should do.
  const rRule = RegExp('\\.(\\w+?)' + escapedRule)
  const [, className] = styleHtml.match(rRule) || []
  return className || ''
}

// The following may be an empty string or (probably) a two-character name
// const greenDotClassName = getClassName('{color:#6ba93e;}')
// const hasGreenDot = !!greenDotClassName

Finally, we create a "public" function that gathers all of that information using the above snippets and then returns it.

This function will be attached to the ZeroWorker namespace (The purpose of this will be shown later).

// ZeroWorker is declared globally as `const ZeroWorker = {};`
ZeroWorker.getProfileInfo = function getProfileInfo() {
  // ...
  return { id, myId, name, username, hasGreenDot, gender }
}

Conversations

We can see a chat page's markup like this (at least this is what I recall):

<div> <!-- HEADER -->
  <strong>Name!</strong>
  <span>greenDot?</span>
  <span>statusText (e.g. "Active a few seconds ago")?</span>
  <a>Link to chat group info?</a>
</div>
<div id="messageGroup">
  <a id="see_older">See Older Messages</a>
  <div>
    <div>MESSAGE_BLOCK_1</div>
    <div>MESSAGE_BLOCK_2</div>
  </div>
  <a id="see_newer">See Newer Messages</a>
</div>

Each conversation has an id (cid) AKA thread id (tid).
- Group chats contain a 'cid'.
- Individual conversations contain the user's id and my id: cid=ID_X:ID_Y. My id is either ID_X or ID_Y... Having already obtained my id, the recipient's id is simply not-my-id.
- We can use the individual chat id to get more information about the recipient as shown in the Profiles section, using a link like /profile.php?fbid=<THEIR_ID>&v=info.
In each conversation, we can use the see_older and see_newer links to obtain timestamps of the last and first messages (respectively) in the target section.
Messages can be grouped together in what I call "message blocks"; they are created when a user sends multiple messages consecutively.
Each message block contains 'message ids' (mids).

Clicking on the Delete Selected link (on the bottom) shows a "Delete" button next to each message. This button is actually a link that contains the message's mids.

These attributes can be used to automatically update the conversation by fetching new messages and deduplicating repeated ones (for technical reasons, duplicates can appear when "scrolling" up and down).

As with profiles, using the mentioned specifications, we write a function that collects the needed data and returns it:

ZeroWorker.getChat = function getChat() {
  // ...
  return { name, messages, hasGreenDot, statusText, groupInfoLink, seeOlderLink, seeNewerLink }
}

As for sending messages, we use a simple function that performs the actions a user normally does:
Fill in a message and then click send (submit).

Again, we attach this method to the ZeroWorker namespace.

// This code should be self-explanatory.
ZeroWorker.sendText = function sendText(str) {
  const $form = document.querySelector('#composer_form')
  const $input = $form.querySelector('textarea')
  $input.value = str
  $form.submit()
}

Parts

Basically, it consists of three Promise-based parts: Messenger, Master, and Worker (in addition to "Broker").

ZeroMessenger.uml exported as image using WhiteStarUML.

ZeroWorker

A ZeroWorker (presented in the Gathering Data section) runs on iframes that are opened by Master. (ZeroWorker's scripts get automatically injected in 0FB iframes thanks to Chrome Extension API).

A Worker listens for orders, executes them, and finally sends a response to Master. ZeroWorkers and Masters communicate via cross-document messaging.

The following code shows how jobs are handled.
This is the reason we have been attaching everything to the ZeroWorker namespace: To dynamically access needed functions.

window.addEventListener('message', ZeroWorker.onOrder, false)

ZeroWorker.onOrder = function onOrder(event) {
  const job = event.data
  const response = ZeroWorker[job.fn](...job.args)
  // Add some useful 'metadata' that Messenger uses to keep its data consistent and up-to-date
  response._pageDate = Date.now()
  response._pageLink = window.location.toString()
  event.source.postMessage({job, response}, '*')
}

ZeroMaster

Actually just Master.

It spawns ZeroWorkers (i.e. iframes), sends orders (jobs) to them, then listens for responses.

A Master kill()s the Worker he spawned when they lose their raison d'être (i.e. the job is done).

Also, Master deals with actions that make the page reload (for instance, sending messages) and handles time-outing requests (happens often on shitty cell connections like mine).

const username = 'dreamski21'
const job = {fn: 'getProfileInfo', url: `https://0.facebook.com/${username}?v=info`}
const master = new Master(job)
master.getResponse().then( (res) => {
  console.info(`${res.name} is ${res.hasGreenDot? 'online' : 'offline'}`)
})
// Probably outputs: "Djalil Dreamski is offline"

As for how it works:

Master assigns a unique id to each job object.
It sends (posts) the job to the worker and starts listening for a response with that id.
When a response arrives, the promise is resolved with the response's data object (or rejected if something goes wrong).

class Master {
  // ...

  _launch() {
    return new Promise( (resolve, reject) => {
      const onMessage = (event) => {
        const data = event.data;
        if (data && data.job && data.job.id === this.job.id) {
          // Perfect, this is the event we were listening for.
          removeListener()
          if (data.response && !data.response.error) {
            resolve(data.response)
          } else {
            const err = (data.response && data.response.error) || 'Response err'
            reject({error: err})
          }
        }
      }

      const removeListener = () => window.removeEventListener('message', onMessage, false)

      // Start listening and then tell ZeroWorker to do the job
      window.addEventListener('message', onMessage, false)
      this._iframe.contentWindow.postMessage(this.job, '*')
    })
  }

}

ZeroMessenger

ZeroMessenger is the interface that interacts directly with the user.

Again, it abstracts ZeroMaster and ZeroWorker by providing dedicated classes and methods. For example:

class Message {
  // ...

  /**
   * Sends a text message.
   *
   * @param {string} id - Conversation id
   * @param {string} text
   * @returns {Promise<object>} "Zero Response" from ZeroWorker 
   */
  static async send(id, text) {
    // url = `https://0.facebook.com/messages/read?fbid=${id}&show_delete_message_button=1
    const url = Conversation.getChatLink(id)
    const job = {url, fn: 'sendText', args: [text], reloads: true}
    const res = await (new Master(job)).getResponse()
    return res
  }
}

And so on, we write classes Profile, Conversation, and sub-classes as shown in the UML class diagrams above.

These classes open different pages/links to do different things. For example, to get a user's info, you open their profile info page then invoke Worker (by specifying getProfileInfo as its job) to read and send that info to you.

Messenger contains all the other parts/classes and eases interaction between them. For instance, to distinguish between my id and another user's, Profile.getTheirId(url) needs to know my id which is stored in Messenger.moi.id.

As for dynamically updating the content, ZeroMessenger periodically checks Facebook Zero, the same way a user refreshes pages every few seconds. Really, the goal of this project was to mimic the user's actions + add photos.

By this point, I have created a good enough API for working with Facebook Zero; the rest is just a basic chat/instant-messaging app.

Once upon a time when nwjs used to be called node-webkit and when Object.observe was not deprecated, I wrote an APK Manager with a reactive view by observing 'data objects' and updating the DOM when changes occur. It was a fun and interesting project to work on... However, this time I decided to stop reinventing the wheel and use VueJS to handle reactivity, so I can focus on the app's logic.

ZeroBroker

This is actually my original idea: A "proxy bot" to send and receive binary data using only texts.

It's inspired by the TCP protocol and it works like this:

The bot logs in using my account and starts watching for incoming messages (including those I send to myself).

Receiving: If I receive a file (a photo for example), the bot should:
- Download it
- Convert it to text and then split it into messages
- Add metadata to those messages
- And finally, send those messages to my inbox.
Sending: If I want to send a file to someone:
- I simply select something and send it, as in any messaging app.
- ZeroMessenger reads the file and sends its textual representation to my inbox, in addition to some metadata (like whom it is sent to).
- ZeroBroker checks my inbox, collects those pieces, converts them to a binary file, then sends that file to the recipient as if it were sent directly by me.
- The Broker informs me of the progress by sending updates to my inbox. (Feels like talking to myself. Weird.)

I didn't finish it but I made Zerofy which lets you do half of the job "manually" (sending),
while the other half is done automatically (receiving).

Technicalities and Regrets

Each message can contain a little more than 2^16 characters, which is approximately 16KB. That requires the image's textual representation to be split into chunks and sent separately.
Making a simple/limited API for 0FB was tricky since Facebook adds a token named gfid (whose value is randomly generated) to some links and forms (probably in order to fight CSRF attacks). This means that some pages need to be opened in order to get the value of gfid before actually doing the desired actions: Sending and deleting messages, and changing my Active Status.
Facebook's HTTP response contains a header that tells the browser to not allow iframes. We simply intercept the response and remove this troublesome header.

Data is half processed by Worker and the rest is handled by Messenger/Master.
That's confusing. Only one of them should take the responsibility and do most of the work (preferably Messenger while Workers only gather raw data and "obey orders").

The way ZeroMessenger works is similar to crawlers (which Facebook tries to prevent), this necessitates that we mimic a browser. I could use libraries to grab pages (using axios), parse them and extract relevant info (using cheerio), compose requests and send them. This solution would be independent of the browser and work on Node, the possibilities would be limitless...

That wasn't what I did. Wanting to keep it simple and having used Google Chrome's Extension API before, I decided to use iframes and inject scripts into them. This is a bad approach since it's costly (needlessly rendering pages and loading images) and gives less control (like catching network errors and redirects and stuff).

Conclusions

And there you have it, Facebook Zero is a better shit.
You can check the source code on GitHub... and why not fork it and finish it...
JavaScript is amazing: It has simple yet powerful APIs that can be used to make complex projects.
VueJS is beautiful: Simple syntax and, as its website promotes it, "incrementally adoptable".
Nothing compares to learning by doing: In reality, this was a huge experimental project: VueJS, Promises and async/await, postMessage API, "parallelism", etc.

Thanks

I'd like to thank my friend Wanis R. for the help he provided (beta reading, beta testing, allowing me to use his real internet sometimes, etc.) and for his continuous support and encouragement.

2018-11 Update: Djezzy's Facebook Zero and Wikipedia no longer work. Sad.

DEV Community: Abdeldjalil Hebal

Debugging Data Pipelines: From Memory to File with WebDAV

The Problem: Poor Debugging Experience

The Solution: A Poor Man's Google Drive for Debug Data

The Concept

The Architecture

Why WebDAV?

Why Filestash?

Implementation: Step by Step

Scenario: Analytics Platform

Setting Up the WebDAV Server

Writing Code for the Client

Setting Up Filestash

Making it Reusable

Sets up dufs WebDAV server, Filestash, and Collabora Online

Results

Big Wins

Challenges and Considerations

Conclusion

Debugging Complex SQL Queries: A Structured Logging Approach

Background and problem

The idea

Example

User Story: Inventory Reorder Alert

Better DX

Interactive demo

Performance Disclaimer

Conclusion

Using SVG as a Camera (Danganronpa Back and Forth)

The idea

Danganronpa panning effect

Danganronpa F tutorial

Main layers and the main idea

Translating concepts

Pseudocode

Impl details

Conclusion

Further reading

Cropping videos with ffmpeg, but visually?

Normal way

Manual approach

Semi-automatic approach

Dimensions problem

Pseudocode

Some implementation details

Rough implementation

Existing solutions

Conclusion

Pronouncing names using TTS

Naming it

Building it

Synthesizing

Choosing a TTS service

Requirements

Options

Using the service

Caching

Handling quota

What to count

Where to keep track of the count

Resetting the counter

Deploying

Conclusion

Experiment: Playing a non-English visual novel through Google Translate's camera

How I played it

Screenshots

Tried: Screen translator apps

Idea: Doppelganger.js

Idea: Emulate the Google Translate app

Conclusion

References

ZeroMessenger: Improving Facebook Zero's messaging functionality

Idea

Gathering data

Profiles

Conversations

Parts

ZeroWorker

ZeroMaster

ZeroMessenger