Playing with rxjs

This will be a very short post. Nobody read blogs nowadays. The WP API I was using to make this blog shiny no longer works, and it has now reverted to a sad-looking late ’10s template. I might sort it out in the next few days, but again, I suspect that the audience is… limited, at best.

In any case, in the early Summer I have left a long-running project where I was using rxjs a lot. In order to check if I still remember this library after a very long holiday, I have written this skeletal game:

It’s really nothing special: you have to make all the tiles disappear by clicking on the pair of the same colour. They move, so it gets a bit difficult towards the end, but this isn’t exactly a hard / engaging game. I just wanted to check if the pairing rxjs + @react/rxjs is still familiar to me. I am pleased to say it is.

Le radoteur

One of the most curious episodes of my life: I was 18 or 20 when during a holiday I found in a Parisian bouquiniste an used copy of Théorie du bordel ambiant by Roland Moreno; I read it and was so enthused (it’s a riot, believe me — it would cheer anyone up) that I wrote him a fan mail. He did answer, and a long correspondence ensued for several years, til it was sadly cut short by his untimely demise.

Roland Moreno was an inventor, credited in the francophone world as the main creator behind the smart card. His role in this is not without controversy (a good friend of mine who was in the same industry says “he made a prototype the size of a washing machine”) but there is no doubt that his contribution, and the rewards he reaped, were huge. However, his vivacious and keen intellect wasn’t guided by notions of importance or monetisation: he loved making things, even apparently pointless things like the Matapof, featured in Sautet’s Les choses de la vie. Among his many inventions, surely le radoteur is among the minimal and minor, but heck, it’s fun. It’s an algorithm to invent new words, starting from a series of “model words”, and he used it in the 60s to create new medicines names for a pharmaceutical company. The algorithm is described in detail in the Théorie. It’s very simple but I can attest it works still pretty well, the more if informed by a vast and consistent vocabulary.

I have written a Typescript version of it, mostly because I wanted to use it myself and other versions I found around were impractical or buggy. It’s minimalist but effective, it was fun to make and a lovely memory of an exhilarating episode of my early youth.

Displaying a list of users from an API with typescript, hooks, and redux-toolkit

I use redux a lot, but i had never really tried redux-toolkit before. It took me a while to overcome the impression “oh look, data flying everywhere” and to recognise the familiar redux patterns — especially in the wildly terse createSlice.

What can I say about it? It’s wonderfully succinct compared to the boilerplate-dense standard redux experience. It’s darn clever to use a Proxy to encapsulate the object in draft state.

However, I am not convinced. Do I really need an opinionated library in case me or someone else in my team decides to slap an api call in a reducer? That would never pass a code review, anyway. And the library is so unconvinced that devs understand immutability that it makes it invisible, encouraging — heck, forcing — us to do something as horrid-looking as


because immutability will be taken care of away by it, out of sight. Well, hmm, no, I suspect it’s not for me; although it may have its place in a team of redux-haters. Who am I to judge? 🙂 I won’t probably use it tho.

EDIT: a few months later and… once you get used to its admittedly quirky API (notably, the distinction between reducers and extraReducers feels awkward), it’s actually pretty neat to use. It drastically reduces the amount of boilerplate and duplication that affects normal Redux, and having Immer to handle immutability becomes really comfortable really quickly. So, I have been using it, with satisfaction.

The shoemaker always wears broken shoes

Six years since I last updated my website. In any sense: the temporary template remains there, I didn’t write any new posts. Well, I have been busy. Many many things have been going on in towers. Somewhat, this little job always fell at the bottom of my priorities’ list.

So today I thought it may be the day that I actually do something about it. Except that… well, I fell into a rabbit hole of meditations about React functional vs class components, and hooks and race conditions and…

You can imagine where this is going. The temporary website is still here. I really didn’t do much, but I put together this gist about using hooks to manage state in a tiny dynamic image gallery. It’s only a demonstration — nothing prod-worthy. But I hope someone finds it useful.

One day I will update this website… soon! 🙂



A tiny nodejs module for development purposes: it parses json files and creates a server that responds to routes created on the basis of the json data, therefore simulating your real life REST api. It follows the conventions delineated on Wikipedia for Representational State Transfer and, oyez oyez, it’s stateful! So you can post or put new data and find them there at the next call. Until you restart the application, that is. There’s no database, and no external dependencies. The idea is that you use it to develop the front end while your service is not ready yet, and then you throw it away and it leaves no trace. For this very reason I’ve avoided even libraries that would have been nice to have in this particular instance, like when.js (admittedly my own version of when/parallel behaviour is, if simple, rather uncouth) and Express. But well, it’s fit for purpose and has full test coverage. Enjoy.


The bloat. Oh, how it irritates me.

I feel quite lonely in this. Yes, we compete over concision, can you write a state machine in 148 characters dude?, we try to keep the footprint of libraries within reasonable boundaries — but then we think nothing of including, dunno, lodash.js because in our project we use once .reduce and twice .map.

jQuery is a particular victim/accomplice in this: we add it without a second thought, even before we ascertain if it’s needed or not. Heck, we take for granted that we are going to need it at some point.

JQuery, Backbone, require and underscore/lodash: the bog standard frontend stack as of…hmm, last year? We include it in the space of a breath, offhandedly, without thinking.

Don’t take me wrong: they are wonderful tools. I especially love underscore/lodash. It’s expressive, and concise, and just damn useful. In fact, it’s so nice to have that we tend to use it all the time. Just in case.

And don’t get me started on what happens on the Node side. Express and Jade – lovely, lovely modules by the way – get usually required on the spot, followed by dozens of others of which we usually utilise 10% or less of the actual capabilities. Freed even from the concern of bandwidth occupation, we think there’s always time to remove. And we never remove anything, anyway.

But, you will ask (please do ask), what’s wrong in this? Module footprint is not a problem in node, and it’s less and less of a concern on the desktop. We are a bit fussed on mobile, and we look for smaller libraries for mobile orientated stuff (but the erosion has started there too… the first philistines objecting: but a lot of the times those mobile devices are used through wi-fi… jaja). On the whole, contending for not-so-scarce connectivity resources with bandwidth-hogging images, html, css, cookies and whatsnot, our concatenated, minified and compressed javascript files have a clean, light conscience, even with the odd one or two superfluous kb.

Screen Shot 2014-02-08 at 22.42.52

Still, the bloat is bad, in my honest but humble, please-don’t-troll-me opinion.

It’s a question of mental order. Un-utilised and under-utilised resources are, for all intent and purposes, a broken window. One of these famous broken windows that rot uses to gain access and fester. We don’t want broken windows. We want code that it’s un-broken-windowed, so squeaky clean that it’s almost antibacterial. Reducing the bloat increases cleanliness and order.

It’s a question of maintenance. We assume that whoever will maintain our code will know by heart every quirk and feature of our favourite browser stack, but this is seldom the case if we deviate from whatever is the cultural norm or fashion during the lifetime of the product (Spring/Summer 2013 will see the classic Mootools make a comeback..). This might be an argument for limiting the use of non-mainstream libraries, but we might not like the more traditional options, we might want to try something new… and we condemn our successor to be recruited through one of those unloving “Needs commercial experience of RandomObscureLibraryThatSeemedAGoodIdeaAtTheTime“. Less bloat means to incorporate abstractions in a manner that is (hopefully) more integrated to the fabric of our project. It means that our custom “extend” will have to be acknowledged and remembered, but not alongside several showelfuls of unused accompanying methods.

And, I don’t know you, but I really don’t like to learn new APIs if they don’t offer an alternate view on the traditional ways to accomplish an operation.

So, inspired by the brilliant which shows us how vanilla javascript is often all what we need, I’ve put together a collection of the methods that I use for quick, small toy projects: breve.js. It includes extend, mixin, custom event and very little else. I was tempted to leave it un-AMDfied to further reinforce the idea that, in reality, we need very little to weave our code, but then I relented because almost no project nowadays does without modular loading. I have also added a polyfill for requestAnimationFrame because the browser support is prodigiously limited, and I might add promises soon, although naked callbacks are seldom a problem in the kind of tiny projects breve.js is meant to be used in.

Please feel free to fork breve.js and remove stuff from it 🙂

Mini pong

Screen Shot 2014-02-06 at 15.34.37I am sure there’s a bazillion ports of Pong out there, but sometimes, as some Zen Master said once, one needs to do their own experience of something — and I had a couple of hours to spare.

It’s incredible how quick it is to write a primitive but perfectly playable game in Canvas, and how satisfying are tiny and self-contained projects.

The MiniPong on GitHub