DEV Community: Hamdi LAADHARI

Put Your Docker Images on a Diet with Alpine Linux (2015)

Hamdi LAADHARI — Sat, 22 Aug 2026 09:13:11 +0000

Archival repost — originally published on my old blog on June 21, 2015, back when Alpine was still a dark-horse pick rather than the default. Already in English, lightly cleaned up for dev.to (fixed a few typos). Alpine did go on to become the mainstream slim-base choice — but it's not the automatic right answer anymore either: its musl libc trips up some native Node/Python modules, and DNS resolution has had known issues, which is why multi-stage builds and distroless images are now common alternatives for the same "smaller image" goal. My Dockerfiles and Docker Hub images are still up if you want to see what this looked like in practice.

Run docker images and you'll typically see images weighing several hundred MBs — even a simple container providing a single service ends up heavy. Why? Because the base images people reach for — Ubuntu, CentOS, Debian — are themselves very heavy.

Images based on BusyBox could have been an alternative, but they're too far from the full-featured Linux OSes we're used to, and building from BusyBox isn't straightforward — it often requires compiling from source.

Let me introduce Alpine Linux, a lightweight Linux distribution. Its popularity is growing fast in the Docker community. Once people discover it, they rebase their Dockerfiles onto it and are amazed how simple the switch was. I started using Alpine well before it became official on Docker Hub, building my own PHP/nginx/MariaDB containers instead of relying on the heavy official ones.

More and more images using Alpine as a base are showing up on Docker Hub. My own builds are public on Docker Hub — feel free to use and fork them on GitHub.

Supercharging Dev VMs with Vagrant and Ansible (2014)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:31:23 +0000

Archival repost — originally published on my old blog on April 30, 2014. Already in English, lightly cleaned up for dev.to (fixed a few typos and reworded one sentence about Ansible's learning curve that read backwards in the original). Vagrant was the default way to spin up local dev VMs before Docker ate that space — most teams now reach for containers instead, but if you do need full VMs (kernel-level testing, OS-specific work), the Vagrant + Ansible combo below still works exactly like this. My example project is still up on GitHub.

Vagrant was the de facto standard for managing development machines. It lets you spin up a multi-VM development environment in seconds. For more details, see Vagrant Up.

Vagrant isn't a provisioning tool itself — it leverages existing ones, like Puppet and Ansible. Ansible was the new kid on the block at the time. Its learning curve isn't too steep: you just write your playbooks in YAML, and it's DevOps-friendly.

Give it a try — clone my example project, vagrant-lamp-ansible, and get started.

Naming eZ Publish Web Transactions in New Relic (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:29:02 +0000

Archival repost — originally published on my old blog on October 5, 2013. Already in English, lightly cleaned up for dev.to. New Relic's PHP agent and API have evolved a lot since, but the underlying idea — naming transactions manually instead of dumping everything into one bucket — is still exactly how you'd solve this today. The ezpublish-newrelic extension is still up on GitHub and Packagist if you want to see the actual code.

When using the New Relic PHP agent with an eZ Publish stack, every profiled transaction shows up under /index.php. Not exactly helpful when you're trying to figure out what's actually making your app struggle.

New Relic provides a self-explanatory PHP API. It lets you send additional metrics and data alongside whatever the agent already gathers — including a custom transaction name.

The eZ Publish extension I wrote, ezpublish-newrelic, hooks into that API to track modules and their views under separate, meaningful transaction names instead of one big /index.php bucket.

The source is on GitHub and installable via Composer from Packagist — feel free to contribute.

Uninstalling BlueStacks from Mac OS X, the Undocumented Way (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:20:52 +0000

Archival repost — originally published on my old blog on May 28, 2013. Already in English, lightly cleaned up for dev.to (I quoted the space-containing path, which the original left unquoted — it would have broken in a real shell). BlueStacks has changed a lot since 2013, and macOS's security model has too (notarization, System Integrity Protection), so these exact paths almost certainly won't match a current install. The instinct — dig into ~/Library for the app's own bundled uninstaller — is still the right one if a modern macOS app leaves debris behind.

For some reverse engineering needs, I installed a full-featured Android environment called BlueStacks. I decided to remove it after playing with it for a couple of hours. I searched the web and found no up-to-date way of getting rid of it — BlueStacks is a pretty intrusive app.

After digging deep into ~/Library, I found out how.

Here's how

Open a terminal
cd "~/Library/BlueStacks App Player/Uninstall/Clear BlueStacks User Data.app/Contents/MacOS"
Run sh uHD-ClearUserData
Hit Delete in the confirmation popup

You're all set.

Revamping the Blog... Done (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:18:36 +0000

Archival repost — originally published on my old blog on May 27, 2013, right on the heels of the "in progress" post. Already in English, lightly cleaned up for dev.to. NodeJitsu shut down in 2015, so the hosting details here are historical only — the "ditch WordPress for a flat-file Node.js blog" idea still holds up fine today.

I'm done revamping the blog with Lectroid. This blog engine offers all the basic features you'd need. It's currently hosted on NodeJitsu on their cheapest plan. The frontend is fully responsive, built with Twitter Bootstrap.

So — what's your take on the new setup?

Revamping the Blog... In Progress (2013)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:15:33 +0000

Archival repost — originally published on my old blog on April 6, 2013, already in English (this was the post announcing the blog would go English-only going forward). Lightly cleaned up for dev.to. Pagodabox shut down in 2015, and Cloud9 IDE was acquired by AWS and rebuilt into something very different, so neither is usable the way described here — Lectroid, the Node.js blog engine, still exists as historical software.

From now on this blog will be held in English only. Despite not being a native English speaker, I find it easier writing in the language of Shakespeare. I'm writing this post to announce the upcoming blog revamp.

The blog was running WordPress with a full LAMP stack on my own dedicated server — a total overkill setup. On top of that, WordPress kept getting heavier release after release. I only needed a personal blog system, not a whole CMS engine.

I went with a lightweight Node.js-based blog engine that does only what I need. It's called Lectroid — no database required, posts are stored as markdown files.

I also decided to fully lighten up the dev process and give a PaaS a try. I played with a few of them for a couple of days and settled on Pagodabox, which fit my needs. I'll be using Cloud9 IDE and Git for versioning and deploying to Pagodabox. I'll keep you all posted.

eZ Publish's Native RSS Import: Making It Actually Import Media (2012)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:11:51 +0000

Archival repost — originally published on my old blog on July 20, 2012. Translated from French, lightly cleaned up for dev.to — I also fixed smart-quote encoding issues throughout the PHP code blocks that would have made them fail to parse. eZ Publish is now Ibexa DXP, but the kernel mechanism described here (and the "quick and dirty vs. extension hook" tradeoff) is unchanged.

eZ Publish lets you import content from an RSS feed into eZ Publish content objects without writing a single line of code. But that native feature doesn't import the media referenced in the <enclosure> tag:

<enclosure url="http://www.example.com/images/voiture.jpg" length="" type="image/jpeg"/>

I'll show you how to fetch that media (image, or any other file like PDF, DOC, or FLV) and insert it transparently into your eZ Publish content. This feature is a bit hardcoded in eZ Publish and isn't cleanly extensible out of the box. I'll show you the quick and dirty way to get there first, then the cleaner way — you decide how much time it's worth spending.

Quick and dirty implementation

Here are the core files affected by our changes:

The setObjectAttributeValue() function in cronjobs/rssimport.php (the PHP script called by cron to fetch new items from the RSS feeds configured in the back office)
The rssFieldDefinition() method in kernel/classes/ezrssimport.php

setObjectAttributeValue() handles fetching the different attribute types (text line, XML block), so that's naturally where we add handling for the ezimage attribute (this also works with ezfile). We add a case 'ezimage':

function setObjectAttributeValue( $objectAttribute, $value )
{
    //...
    switch( $dataType )
    {
        //...
        case 'ezimage':
        {
            $file = pathinfo($value);
            $image = eZHTTPTool::getDataByURL( $value );
            if ($image !== false)
            {
                $fp = fopen('/tmp/'.$file['basename'], 'wb');
                fwrite($fp, $image, strlen($image));
                fclose($fp);
                $objectAttribute->fromString( '/tmp/'.$file['basename'] );
            }
        } break;
        //...
    }
}

Once eZ Publish knows how to handle ezimage, we need to add Item – Enclosure – Url to the mapping <select>. That's the rssFieldDefinition() method:

case '2.0':
case '0.91':
case '0.92':
{
  return array( 'item' => array( 'elements' => array( 'title',
                                                      'link',
                                                      'description',
                                                      'author',
                                                      'category',
                                                      'comments',
                                                      'guid',
                                                      'pubDate',
                                                      'enclosure' => array( 'attributes' => array( 'url' ) ) ) ),
                'channel' => array( 'elements' => array( 'title',
                                                         'link',
                                                         'description',
                                                         'copyright',
                                                         'managingEditor',
                                                         'webMaster',
                                                         'pubDate',
                                                         'lastBuildDate',
                                                         'category',
                                                         'generator',
                                                         'docs',
                                                         'cloud',
                                                         'ttl' ) ) );
}

Cleaner implementation

Instead of editing the rssimport.php cron script directly, you can copy it into your own extension, make the ezimage changes there, and have that run instead of eZ Publish's default rssimport.php.

rssFieldDefinition() is called from another method in the same class, and there's a hook there that lets you extend the definition from classes living in your custom extensions. Here's the hook, inside fieldMap():

$fieldDefinition = eZRSSImport::rssFieldDefinition();

$ini = eZINI::instance();
foreach( $ini->variable( 'RSSSettings', 'ActiveExtensions' ) as $activeExtension )
{
    if ( file_exists( eZExtension::baseDirectory() . '/' . $activeExtension . '/rss/' . $activeExtension . 'rssimport.php' ) )
    {
        include_once( eZExtension::baseDirectory() . '/' . $activeExtension . '/rss/' . $activeExtension . 'rssimport.php' );
        $fieldDefinition = eZRSSImport::arrayMergeRecursive( $fieldDefinition, call_user_func( array( $activeExtension . 'rssimport', 'rssFieldDefinition' ), array() ) );
    }
}

So all we need is a class in extension/myextension/rss/ezrssimage.php with a method of the same name, rssFieldDefinition():

class ezrssimagerssimport
{
    static function rssFieldDefinition()
    {
        return array( 'item' => array( 'elements' => array( 'enclosure' => array( 'attributes' => array( 'url' ) ) ) ) );
    }
}

And declare that class in myextension/settings/site.ini.append.php:

[RSSSettings]
ActiveExtensions[]=ezrssimage

That's it for this one. If I ever find the time I'll package this as a proper extension and publish it on GitHub (unless someone beats me to it).

Let me know if you spot errors or improvements. The PHP snippets above are also up on this gist.

Custom ImageMagick Filters for eZ Publish Thumbnails (2011)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:08:12 +0000

Archival repost — originally published on my old blog on July 13, 2011. Translated from French, lightly cleaned up for dev.to. eZ Publish has since been rebranded/rebuilt as Ibexa DXP, but the image.ini filter mechanism and the underlying ImageMagick flags below are unchanged.

eZ Publish's default filters don't let you crop images down to precise dimensions. The image.ini config file lets you hook into eZ Publish anything the ImageMagick CLI tools can do.

Here are two filters that do the same job — crop and resize an image to an exact size — in two different ways. Use whichever fits your image aliases:

Filters[]=geometry/thumbnailize=-thumbnail "%1x%2^" -gravity center -extent %1x%2
Filters[]=geometry/thumbnailize2=-geometry %1x%2^ -gravity center -crop %1x%2+0+0 +repage

My First UWA Widget for Netvibes and iGoogle (2009)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:04:16 +0000

Archival repost — originally published on my old blog on January 18, 2009. Lightly cleaned up for dev.to (translated from French; I also dropped my personal TVRage feed hash from the example URL rather than repost a token — TVRage itself shut down years ago anyway). Netvibes and iGoogle are both long gone as platforms and the UWA widget format died with them, but the "aggregate a messy feed into something clean" approach still holds up.

Originally this project was meant for the same rabbit from my Nabaztag hack, but I ended up wanting to play with Netvibes' UWA widget framework instead. This widget shows the air times for the TV shows I watch regularly.

I'm a sucker for mashups, so instead of manually listing out every show, I used a service from TVRage. Once you created a TVRage account and added your favorite shows to it, TVRage gave you a personalized RSS feed of everything airing during the current week.

The feed was pretty messy — hard to work with, the items were inconsistent in structure — so aggregating it into the shape I wanted took more effort than expected.

Wanting to get the widget working as fast as possible, I wrote a small PHP5 API that aggregates the feed and sorts the data properly. You could also use the UWA/JS parser that Netvibes provided directly, and that's honestly the better approach — as it stood, the widget depended on an API I'd written and hosted on one of my own sites. But it didn't matter much: I wasn't planning to distribute the widget, so the PHP solution worked fine for my own use.

The widget takes three parameters: the tid and hash you'd find in your own personalized feed URL, and a third one pointing at my API.

Nothing about this stack survives today — Netvibes, iGoogle, TVRage, and UWA are all gone — but "aggregate a messy feed into a clean personal widget" is a shape I still reach for.

GreaseMonkey, or How to Enhance Your Web Experience (2008)

Hamdi LAADHARI — Fri, 21 Aug 2026 22:00:58 +0000

Archival repost — originally published on my old blog on December 21, 2008. Lightly cleaned up for dev.to (translated from French, and I fixed a smart-quote encoding issue in the code block that would have made it fail). GreaseMonkey itself has since been discontinued for Firefox — Tampermonkey and Violentmonkey are the modern equivalents — and Google's markup has changed completely since 2008, so the exact selectors below won't match today's page. The userscript technique itself still works exactly the same way.

GreaseMonkey is a Firefox extension that lets you take control of the web. You find a site interesting despite it being plastered with ads. Thanks to GreaseMonkey and a script that's just a few lines long, you can change the visual rendering of your favorite site however you want.

To illustrate, here's a small JS script I wrote — it removes the "Sponsored Links" that show up in Google search results. Knowing JavaScript is obviously a requirement, but so is knowing the DOM and/or XPath.

// ==UserScript==
// @name           Google Sponsored Links remover
// @namespace      http://www.laadhari.fr
// @description    remove google sponsored links from SERPS
// @include        http://www.google.com/*
// ==/UserScript==

(function() {
  var sidebarads = document.getElementById('mbEnd');
  var skyads = document.getElementById('tads');
  if (sidebarads) {
    sidebarads.parentNode.removeChild(sidebarads);
    }
  if (skyads) {
    skyads.parentNode.removeChild(skyads);
    }
  }
)();

Hopefully this convinces you to write your own scripts — if you do, consider sharing them on UserScripts.org in case they're useful to someone else. My Google Sponsored Links remover is up there, open to any criticism.

Hacking My Nabaztag: Reading MSN Messages Out Loud With a Talking Rabbit (2008)

Hamdi LAADHARI — Fri, 21 Aug 2026 21:57:22 +0000

Archival repost — originally published on my old blog on December 12, 2008. Lightly cleaned up for dev.to; most of the tech mentioned here (Nabaztag, MSN Messenger, Messenger Plus! Live) has long since been discontinued, but I'm keeping the content as-is for the history.

A week ago I got my hands on a Nabaztag:tag — one of the first "smart" connected objects, years before "smart speaker" was even a category. It was a Wi-Fi rabbit made by a French company called Violet: it moved its ears, lit up in different colors, and had a text-to-speech voice.

Violet shipped an API with it, so you could script your own rabbit and make it do all sorts of things. My idea: have the rabbit read out messages people sent me on MSN Messenger while I was away from my keyboard ("AFK" for the non-geeks), so I could still hear what my friends were saying without being in front of the screen.

The rabbit has a text-to-speech feature built in — send it some text through the API and it reads it back as soon as it receives it.

Wiring MSN events to the API

The last piece was getting MSN to trigger the API based on its own internal events. That's where Messenger Plus! Live came in. Everyone knew this MSN add-on for its UI tweaks, but fewer people knew it also shipped a scripting environment: you could write your own commands using the JavaScript engine embedded in the add-on. On top of the basic MSN events, Messenger Plus! Live exposed a whole set of extra event hooks, so all I had to do was implement the event handlers I cared about in my script.

Here's a short video of my first tests with NabKiller — that's the name I gave my rabbit:

Ideas I never got around to

A few things I planned to build on top of it:

Have NabKiller warn me as soon as a new episode of a show I was watching came out, and tell me whether subtitles were already available — or ping me the moment they were.
Give the rabbit some actual intelligence by hooking it up to a Pandorabot. Voldo was an example bot with that kind of AI at the time.

I like keeping this one around if only as a reminder that "smart home hack with a scripting API and a talking rabbit" predates the current wave of IoT and AI toys by over a decade.

Node.js SEA Just Got Way Simpler — Updating My node-sea Boilerplate for Node 26

Hamdi LAADHARI — Fri, 21 Aug 2026 01:38:05 +0000

A while back I put together node-sea, a small boilerplate showing how to package a TypeScript app into a Single Executable Application (SEA) with Node.js — no runtime install required on the target machine, just one binary.

I hadn't touched it in a while, so I went back to check if it still held up. Short answer: the concept is more relevant than ever, but the build process I wrote was already legacy. Node core absorbed most of it. Here's what changed.

Quick recap: what's a Node.js SEA

SEA lets you compile a Node app into a single native binary that runs without Node, npm, or node_modules anywhere in sight. Useful for CLIs you want to hand to someone who doesn't have Node installed, or just for shipping one file instead of a runtime + a tree of dependencies.

The old way

My original build-sea.js did this, by hand, in five steps:

// 1. Generate the blob
execSync('node --experimental-sea-config sea-config.json');

// 2. Copy the node binary itself
const nodePath = execSync('command -v node').toString().trim();
fs.copyFileSync(nodePath, 'dist/hello');

// 3. Strip its existing signature (macOS)
execSync('codesign --remove-signature dist/hello');

// 4. Inject the blob with an external tool
execSync('npx --yes postject dist/hello NODE_SEA_BLOB dist/sea/sea-prep.blob \
  --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 \
  --macho-segment-name NODE_SEA');

// 5. Re-sign it
execSync('codesign --sign - dist/hello');

That postject step was the annoying one — an external WASM-based tool you had to npx in, with a sentinel fuse string you copy-pasted from the docs and just trusted. It worked, but it wasn't exactly pleasant, and the Node.js team has since said openly that postject had become unmaintained with issues piling up.

What changed: `--build-sea`

Node 25.5 (January 2026) folded all of that directly into Node core, behind one flag:

node --build-sea sea-config.json

That's it. Blob generation, binary copy, and injection now happen internally — Node vendors the same binary-patching logic postject used to provide (via the LIEF library) instead of shelling out to an npm package. My entire build-sea.js shrank from five manual steps to one command plus the platform-specific codesign call:

execSync('node --build-sea sea-config.json', { stdio: 'inherit' });

if (process.platform === 'darwin') {
  execSync('codesign --sign - dist/hello');
}

sea-config.json changed slightly too — output now points straight at the final executable instead of an intermediate .blob file:

{
  "main": "./dist/bundled/bundle.js",
  "output": "./dist/hello",
  "disableExperimentalSEAWarning": true,
  "useCodeCache": true
}

That useCodeCache flag is new as well — it pre-compiles the bundle to V8 bytecode at build time, so the binary starts faster. One boolean, free win, no downside for a CommonJS bundle like this one (it does disable dynamic import(), worth knowing if your app uses it).

Before / after

	Old way	`--build-sea`
Steps	5 manual steps	1 command
External deps	`postject` via `npx`	none
Blob handling	you generate + inject it yourself	handled internally
Sentinel fuse	copy-pasted magic string	not your problem anymore
Codesigning	still manual (macOS/Windows)	still manual (macOS/Windows)

The catch: it's not on LTS yet

Here's the part that surprised me. I assumed --build-sea had landed on the current LTS by now, so I installed Node 24 "Krypton" (Active LTS as of today) to test — and the flag simply isn't there:

$ node --build-sea sea-config.json
node: bad option: --build-sea

Only --experimental-sea-config, the old blob-generation flag, is available on 24.x. --build-sea currently only exists on Node 26 (the Current release line). The silver lining: Node 26 is an even-numbered release, which means it graduates to Active LTS in October 2026 — a few weeks out at the time of writing. Still, if you're targeting LTS today, you're stuck with the manual flow for a little longer.

It's also worth noting SEA is still officially listed as Experimental (stability 1.1 – "Active development") in the Node.js docs, not Stable, despite what a few blog posts floating around now claim. It's functional and usable, just not API-frozen yet.

Wrapping up

I bumped node-sea to Node 26, rewrote the build script around --build-sea, and refreshed the dependencies (TypeScript, esbuild, commander) while I was at it — kept TypeScript on 5.9 rather than jumping to the new 7.0 Go-native compiler, since ts-node hasn't caught up to its programmatic API yet.

If you're maintaining anything that shells out to postject, this is your sign to simplify it. Repo's here if you want to see the whole thing end to end: github.com/killerwolf/node-sea.