The community around Pebble was naturally disappointed, to the point that a group of enthusiasts (who called themselves “the Rebble Alliance”), found a way to keep their watches alive by building their own replacement of the online services and app store, and scraped all of the existing watch apps and faces before the official ones were shut down. But ultimately, our devices ended up dying of old age.

Then last year, Pebble’s original author announced that they were resurrecting the project: and there was much rejoicing! Production took a while, but as of today you can buy a brand new Pebble watch. And whatsmore: they imported all of the old archive of apps and faces rescued by Rebble into the new app store, which are still compatible with the new watches. A success story in digital preservation!

Recently, there was a official app-making contest which served as the perfect excuse to build a couple of apps ourselves.

One of the apps we've build: a Neko wristmate

Neko wristmate

Mar built a watchface (ie, an app whose purpose is to run as the main display of the device) featuring an animated Neko screenmate mascot, alongside the time and date. The Neko will play around for a bit, and fall asleep after a while. It will wake up on a tap event (eg, when you tap the watch or do a wrist-turn movement).

• Pebble app store.
• Source code.

80% battery charged

Javi built an app that triggers on charging, and will notify the user when the charge level reaches 80%. This way you can choose to interrupt the charge before reaching 100%, which is useful for preventing long term battery capacity degradation.

• Pebble app store.
• Source code.

Implementation details

Pebble apps used to be non-trivial to build back in the day. They need to be coded in C, and although the SDK provides a lot of helpers, building something minimally complex (eg, with animations, or interactions) was cumbersome and error prone.

Today this process is a lot easier if you enlist your AI agent of choice as a helping hand. We’ve built ours using Claude and the official Pebble-development skill.

Even if you use a clanker for the heavy lifting, it’s a good idea to manually go though the official tutorial first, which helps you familiarize with several low-level pebble concepts that ure useful to know when designing your apps.

An important point to consider is that there are a lot more Pebble models now that there were back in the 2010s, each with different characteristics. For example: different screen resolutions, colored or black-and-white displays, or the newest model even has touch support. The SDK designates each of them as a platform with a codename (see the relevant docs).

In our case, we initially created our apps with our watch model as the target platform (flint for Pebble 2 Duo), and afterwards added tweaking for others, with the help of Claude. You can use the provided emulators in the SDK to test how it would look in each different platform.

More than just apps

Pebble is under very active development at the moment, so the landscape is changing very quickly with new and exciting capabilities. There’s a cloud IDE with integrated SDK and emulators, new models with touch capabilities and compatible with apps developed in JS, and there’s a companion smart-ring that is currently in the works.

But the best part of it is that this time absolutely everything is open sourced, even the firmware and hardware schematics. This is great news, as it allows the community to get involved in ways other than simply writing apps, but also guarantees that this time pebble will not go away as easily as before, even if the Core Devices company ceases its operations.

We’re very excited about the Pebble comeback and their new direction, and if our time allows we’ll continue to develop more apps for the platform in the future.

That’s all very romantic, but impractical: vinyls are expensive to buy (and more so now that they have turned into collector’s items), and let’s be real, they don’t have the best sound quality (although some people actually prefer it that way).

So, we invented our own solution: minilos. A device that uses mini vinyl records as triggers to play digital music from a speaker. Read on for all the details about the implementation.

First prototype, with Raspberry Pi

If you’ve been following our blog closely, you’ll notice a lot of similarities with another project we’ve shown you before: the NFC floppy disk launcher. Indeed, minilos follows exactly the same approach, only applied to music.

We did a first version of this project several years ago actually. At that time, we played music at home through a Google smart speaker, casted from Spotify. The process was kind of a PITA, since it involved opening the Spotify app on the phone, searching for the music you want to listen to, and then casting to the speaker, and praying that it works.

At some point we discovered some cute coasters on Aliexpress in the shape of mini vinyl records, and we thought, wouldn’t it be cool to play music from these instead?

And thus, we devised a system to bridge both ends: we sticked NFC tags into the mini-vinyls, and used a Raspberry Pi running a python script to read them, match each tag with a spotify album ID, and then tell the Spotify API to play it in our Google Speaker. We made a little plywood case to enclose the RPi, and place the minilo on top - so it all felt like you were playing an old-school record.

The full code and BOM for this version are on Github.

Revision, with ESPHome and domotics

The device worked just nicely, but after some time, we started progressively incorporating domotics into our home, to the point where most of our devices are now connected with a Home Assistant instance. And it turns out we could migrate the logic of the device into different parts of our domotics system.

First, we replaced with Raspberry Pi with an ESP32 board running the ESPHome firmware. This way, with just a bit of config (describing a pn532 NFC component, and a text sensor), we can continuously read from the NFC and publish to a HA entity:

text_sensor:
  - platform: template
    id: last_tag
    name: "Last NFC Tag"

pn532_i2c:
  update_interval: 2s
  on_tag:
    then:
      - lambda: |-
          ESP_LOGI("pn532", "Tag scanned: %s", x.c_str());
          id(last_tag).publish_state(x);
  on_tag_removed:
    then:
      - lambda: |-
          ESP_LOGI("pn532", "Tag removed");
          id(last_tag).publish_state("None");

Last NFC Tag value now accessible from HA

Then, our Node-RED instance has a workflow that monitors that entity, and triggers when its value changes.

Set playlist is a custom function that contains the mapping between NFC ids and Spotify album ids:

function translate (payload) {
    node.warn(`Reading minilo ID ${msg.payload}`)
    switch(msg.payload){

        case '04-59-4A-3A-BC-2B-80': return '3ai8NgXP53ehLXGcA839CF'; 
        case '04-5C-4A-3A-BC-2B-80': return '37i9dQZF1DZ06evO0ENBD2'; 
        case '04-FB-7F-72-5D-67-80': return '2uQmaiOrGukfHhZAm15x4K'; 
        case '04-EA-7D-72-5D-67-80': return '1SwyMhnJyMEvpel7ystCEB'; 
        case '04-2C-C9-6A-28-73-81': return '0lWFpTETkmMBmy5xt1Ujtv'; 
        case '04-20-C9-6A-28-73-81': return '7fxPnuKXtJ3STCfWcqTLup'; 
        case '04-5B-4A-3A-BC-2B-80': return '2P5BwSSmpZUgOBLLuSbZzB'; 
        default: 
            node.warn(`Missing minilo ID ${msg.payload}`)
            return null 

    }

}
const playlist = translate(msg.payload)
msg.payload = playlist
return msg;

Then our self-hosted MusicAssistant instance gets called to play the Spotify album in our Google Speaker (both have been previously configured there as providers [1][2]).

It works just the same from an end user perspective, but updating the mapping to add new minilos is now easier, and it integrates seamlessly with other automations (eg, stop the music when we leave home).

Form factor

The original wooden box was not very elegant, but the mini-vinyl coasters came with an equally cute holder base in the shape of a record player. The ESP32 board was small enough the fit underneath, so we did just that, and now it serves as the device case.

To craft the minilos themselves, we just conceal the NFC tag underneath a sticker that serves as the record label. We use a GIMP template to adapt the label image to the correct size for the minilo stickers, and then we print it into glossy sticker paper. Then we print it on glossy sticker paper, concealing the NFC tag under the label.

Each minilo needs a dummy read first, to obtain the NFC id, and then we need to update the mapping function in Node-RED for it to trigger the right music the next time it’s played.

Future

This setup works well for us, since it’s neatly integrated with our home system, but is not easily replicable, and it has too many moving parts. So we would like to rework this project to turn it into a standalone device, without the need of a Google Speaker, Spotify, or domotics - stay tuned!

If you enjoyed this post, you’ll also appreciate its cousin project: the NFC floppy disk game launcher.

We used to just keep a list in Obsidian with movie ideas as they came along, but as the list grew longer it became difficult to manage. Also, often other parents ask for recommendations on which movies we’ve watched and liked, but we had to rely on our memory to recall them.

So, we’ve built an app to manage both usecases: Pizza&Peli.

Named after the way we call our movie sessions at home 🍕

It’s a Django app that uses scraped metadata from iMDB, and allows to keep track of the upcoming and previously shown movies in our home sessions. We self-host it in our home server, and pop it up every time we have a new idea for a movie to add to the list, and also to keep of what movies we’ve watched and when.

The source code is on Github. Currently it’s an MVP, but we plan to add more features, like trailers, PG rating, or multiple accounts (so we can use it to keep track of our grown-up movie sessions too).

The app was developed as an experiment to code with the aid of claude code, which allowed for a much faster development than if it would have been written from scratch. I’ve kept a log of the evolution of the app, with prompts and screenshots.

However, contributing into an existing project is always daunting. Specially when it comes to popular projects, with a huge codebase and thousands of participants - such as the Django project, for example. It’s hard to know where to start, how to proceed, and how to get your changes accepted. For all the years I’ve been working as a software engineer, contributing to open source is something that has always been on my wishlist, but never got to achieve.

But as it turns out, Django has an amazing community and runs a periodic program to help aspiring contributors along their journey into their first contribution to the project: the Djangonauts program. I joined session 5, running October-November 2025.

Similarity to the Coconauts name purely coincidental 😬

Ready for takeoff

The program is whimsically themed around a space mission, so I’m following the same convention through this post. Djangonauts (which are the participants who want to become contributors) are placed into teams leaded by a Captain and a Navigator (which are respectively, experienced members of the community and stablished contributors, whose role is to guide the Djangonauts along their journey). Each team is focused around a Django subproject: there are teams for the Django framework itself, but also for the debug toolbar, Django Girls or in my case, my team was working on Django CMS.

The spirit of the program is that of low-structured guidance and support from senior members of the community to aspiring ones, and between the Djangonaut peers themselves. During the program, each Djangonaut is expected to achieve a contribution into their assigned projects, even if it’s a small one - as more important than the contribution itself, is the experience of the contribution process and the integration into the community.

Start the engines

The first week of the program is used to familiarise ourselves with the project - Django CMS is not as popular as it’s big brother, and none of the Djangonauts in the team were acquainted with it. So the first thing to do was spending some time going through tutorials, documentation and setting up a sample project before we do any hacking.

Going through a project onboarding with a contributor mindset is extremely valuable: it’s only the first time that you go through the introductory materials that you get to experience them with fresh eyes, and are able to evaluate it’s effectiveness. So simply going through this learning process, before writing any code, allowed to identify some areas where the documentation was confusing. And as new contributors, we’re encouraged to fix it!

The process of making a change to an Open Source process, even it it’s in the docs, goes through discussion and collaboration with the existing project maintainers. They need to evaluate your change and guide the direction to be taken. So the first step is to raise tickets for the issues that you encountered. Those tickets (or issues, as Github calls them) might give way into pull requests implementing the proposed changes - which might not necessarily be implemented by the same person! Publishing a ticket/issue helps current and future contributors become aware of a bug, a possible enhancement, or even feature ideas, and is in essence another useful way of contributing to open source, without writing any code.

For example, later during the program, we discovered a bug in Django CMS. I raised a ticket reporting it, and our navigator promptly pushed a fix.

Launch!

And now comes the time to really get started: our navigator offered a curated list of tickets that are approachable for newcomers into the project, and we are to pick one and start hacking.

This is perhaps the biggest barrier of entry for aspiring contributors in most OS projects - when you are lacking the project context, most tickets won’t even make any sense to you. And here’s where community and curation come to the rescue: many projects use tags for their issues, which can be used for example to tell apart features, from bugs, from documentation. Or a common pattern is to use them to mark tickets that are friendlier to new contributors, with names such as “easy pickings” or “good first issue”.

In my case, I went for a bug ticket, which was marked as “easy pickings”. The ticket had a very clear description on how to reproduce the bug, with even screenshots included - so I settled into doing just that.

And sure enough, reproducing the bug locally was pretty straightforward. But then discovering the source of the bug was a different matter… It turned out to be a tricky one, rather than an easy picking! It required plenty of discussion with our navigator to be able to triage the bug, and decide on a solution - which does not fix the source of the bug, but at least is an UI improvement.

These changes were implemented and raised as a feature pull request. The pull request had a bit of back and forth to get the automated CI system to give it the green light, as well as a passing review from our navigator, which helped make sure the changes were backwards compatible and wouldn’t break existing instances of djangocms. Moving fast and breaking things is not the way of open source!

Success!

Once again, the key takeout is that collaboration with a project maintainer was essential during the process.

Work as a crew

The Djangonauts is not a solo mission: the spirit of the program is collaboration not only with your mentors, but also with the other Djangonauts. There’s a lot of diversity in the participants: not just in terms of geography of demographics, but also there’s people from very disparate backgrounds. There’s people who are already active members of the Python/django community, as well as people with very little exposure to the project, and there’s experienced developers alongside people who are newer to programming. Just like in open source projects in the wild, if you think about it!

The magic of open source is that every part of the process is open, and anyone can collaborate. So even if a ticket is mainly driven by one contributor, it doesn’t mean that others can’t lend a hand as well. As the famous quote goes: given enough eyeballs, all bugs are shallow - i.e., more people have a broader view.

Djangonauts are encouraged to “chip in” into their peer’s doings, not just to help, but also to learn further. Peeking into you peer’s tickets and pull requests is a great way to learn, but also gives you the necessary context to help them if they get stuck - via chat discussions or even live pair programming sessions.

There’s nothing stopping you from adding comments into other people’s pull requests in fact, to provide further help or feedback. Or even having multiple people collaborating by pushing code into the same branch (with prior coordination, to avoid conflicts!).

To infinity and beyond

We’re still halfway through the program, but already I feel like it’s been a rewarding experience. It taught me valuable etiquette and best practices that will guide my future open source efforts, and most importantly, it helped me break that first barrier of making my first successful code contribution to an open source project, which has given me the necessary confidence to keep going at it.

I’m really grateful to the Django community for their welcomeness and dedication - it comes to show that when you cultivate a great community, you grow a great project!

This is just the first mission, but I’m sure more adventures in Django an open source will follow! 🚀

At home, we get our Internet from a fiber connection, which, as it turns out, it’s just light pulses coming thru a cable down the street. And this is a single point of failure, ready to be attacked by unlikely adversaries…

Rats! These pesky critters happen to co-live in our neighborhood, and for mysterious reasons they love chewing on the fiber Internet cables - so light pulses no longer reach our home: the LED pilots fade out in our router, and despair looms, for we are now isolated from the digital world.

Our Internet provider eventually sends a technician to fix the broken cables and bring us back to civilization, but sometimes they take a few days (or even weeks!). They are nice enough to give us complimentary 100GBs of mobile data per day (ie 4G/5G), so we can get going with our lives as we wait.

But the problem escalates…

However, this solution is severely limited for our needs. We can only tap into this connection with a mobile phone, and use it to provide a WiFi hotspot using tethering. This is an acceptable solution if you just need temporary internet on a laptop to work, or a tablet to watch Netflix. But in our case, we don’t just use the internet for work and leisure: we need it for our house to function.

We’re the kind of geeks that are fond of domotics and home automations, and our house is riddled with smart devices to the point of ridiculous: we have around a hundred devices connected to our network, each of them with a fixed IP, integrated with Home Assistant, node-red, kuma, and more… They rely on a local DHCP server that lives in a secondary router, so when that router can’t get Internet, nothing works: we don’t have a doorbell, our blinds don’t roll, our garden doesn’t get watered, our heat pump does not trigger… Reconfiguring all this would be absolutely hellish.

Solution: the single responsibility principle

There was a simple solution to all this: we purchased a 4G router to act as an Internet gateway, in stead of our regular fiber router. This router works by inserting a SIM card, and connects to the Internet via the 4G network, like smartphones do, but other than that it acts like any regular router.

Because the responsibility of the main router in our case is limited to just be a dumb proxy for internet access, it’s completely replaceable: we can choose to use the fiber or 4G router as Internet provider as the need arises. The rest of the network setup remains intact, and our house can keep business as usual during the outage with zero effort.

In order to keep using my phone normally, I requested a multi-SIM to my network operator, so that I could have two SIM cards with the same account, one on my phone and another one on the 4G router.

The 4G connection is obviously not as good as the fiber, and we’re still limited to 100GB per day. But by cutting downloads and streaming we get a near-normal Internet experience until the fiber can get fixed.

If you dread spaghetti code, try spaghetti cables

Then we simply swap the entry routers again, and it’s as if nothing ever happened.

That is exactly what we’ve done: we’re built ourselves a retro PC, using a 386x case, but with a modern PC inside. On it, we’ve installed a fake floppy drive that loads games using NFC - but seemingly, it looks as if they are magically loading from the floppy disks. Read on to learn how!

In a nutshell

As you can imagine, there’s nothing more to this than using retro facades to hide modern hardware: we replaced the innards of the floppy drive with an Arduino hooked to an NFC reader module; Then, each floppy disk has an NFC sticker, that when inserted in the drive gets it’s ID read.

The Arduino program is continuously reading for IDs, and sends them to the PC through the USB-serial port. On the PC, a python script runs in the background reading this port, and has a hardcoded list of NFC ids, each mapped to an execution command that gets run on a subprocess.

Hardware

We used an Arduino UNO, with an MFRC522 NFC/RFID module running at 13.56MHz, which supports ISO/IEC 14443 Type A cards, MIFARE, and NTAG formats and has a reading range of 1-3cm. And most importantly, there’s a community-maintained Arduino library for these modules.

The MFRC522 module needs to be positioned where it can reliably read NFC tags inside inserted floppy disks. However, we found that the metallic shell holding the disks in place was interfering with the readings, so we had to replace it with a more inert material - including the insertion/ejection button. We made a replacement structure out of LEGO building blocks - it was incredibly simple to put together and works like a charm!

<video width=”600” height=”400” controls style=”display: block; margin: 0 auto; text-align: center;>

Your browser does not support the video tag. </video>

The NFC is connected to the Arduino with the following pinage:

• VCC → 3.3V (important: not 5V!)
• GND → Ground
• RST → Digital Pin 9
• SS → Digital Pin 10
• MOSI → Pin 11 (SPI)
• MISO → Pin 12 (SPI)
• SCK → Pin 13 (SPI)

And the Arduino itself is connected to the computer via USB for both power and serial communication.

Software

The Arduino is running a script that continuously polls for NFC tags using the aforementioned MFRC522 library (needs installing as a prerequisite) and sends their unique identifiers via serial communication.

#include <SPI.h>
#include <MFRC522.h>
#include <Wire.h>

#define SS_PIN 10
#define RST_PIN 9

MFRC522 mfrc522(SS_PIN, RST_PIN);

void setup() {
  Serial.begin(9600);
  SPI.begin();
  mfrc522.PCD_Init();
  Serial.println("NFC Floppy Reader Ready");
}

void loop() {
  if (!mfrc522.PICC_IsNewCardPresent()) {
    return;
  }

  if (!mfrc522.PICC_ReadCardSerial()) {
    return;
  }

  // Send UID via serial
  for (byte i = 0; i < mfrc522.uid.size; i++) {
    Serial.print(mfrc522.uid.uidByte[i] < 0x10 ? "0" : "");
    Serial.print(mfrc522.uid.uidByte[i], HEX);
  }
  Serial.println();

  mfrc522.PICC_HaltA();
  delay(1000);
}

And the PC is running a Python script that monitors the serial port, mapping the NFC tag IDs to different followup commands, to launch the games or applications. Uses the pyserial library, which you’ll need to install too.

import serial
import subprocess
# Mapping NFC tag UIDs to games/applications
rfid_to_game = {
    "04a1b2c3": "wine ~/.wine/drive_c/Games/DoomII/doom2.exe",
    "05d4e5f6": "/usr/games/dosbox ~/Games/Commander_Keen/keen.exe",
    "06g7h8i9": "steam steam://rungameid/12345",
    "07j8k9l0": "/home/user/scripts/launch_emulator.sh"
}
try:
    arduino = serial.Serial('/dev/ttyUSB0', 9600, timeout=1)
    print("Connected to NFC Floppy Reader")
    
    while True:
        if arduino.in_waiting > 0:
            tag_id = arduino.readline().decode('utf-8').strip().lower()
            
            if tag_id in rfid_to_game:
                print(f"Launching game for tag: {tag_id}")
                subprocess.run(rfid_to_game[tag_id], shell=True)
            else:
                print(f"Unknown tag: {tag_id}")
                
except KeyboardInterrupt:
    print("Shutting down...")
finally:
    arduino.close()

This approach allows for maximun flexibility: a game can use wine, while another can run on DosBOX, or even if you need a sequence of commands, you can map to a custom shell script. The script spawns a subprocess shell to run the game launch command, and that’s it.

We’re using Ubuntu on the PC, so these commands are run in the default shell (bash). The script is setup to autoload at system startup using crontab. But we’ll leave all the details of the retro-pc for another post.

Creating Game Disks

Arguably, the most fun part of the project is creating the game collection. We used old floppy disks, and attached an NFC tag on the back of each of them - and of course, a sticker label on the front. We use a mini thermal printer for the stickers, which also give them a clunky retro feel.

For each disk, we’ll need to know the NFC tag ID so that we can add it to the hardcoded list on the python script. When the script reads an unknown tag, it prints the ID in the log, so we can copy and then paste it in the mapping list with the adequate command.

Final experience

The whole thing is mounted on an old 386x case, keeping the floppy drive frontal panel, so it looks completely inconspicuous. We have the experience of the look and feel of a retro-PC, with the games magically loading instantly. And with the convenience of a modern OS with emulators for installation and maintenance.

For reference, you can find the updated source code for this project on GitHub. We’d love to know if you build your own!

Hiring is a difficult problem, yet important to get right. Many developers are faced with the challenge of hiring other team members, without much clue into how to proceed, and end up just copying the well known rituals without stopping to analyse their effectiveness or implications. Often, this results in hindering both companies and candidates, especially those of under represented demographics.

In this talk I gave at EuroPython 2021, I share my experiences and personal opinions both as a candidate and as an interviewer, analyze the implications of popular hiring tactics, and discuss what I consider effective ones, in order to hire the right developers for your team with minimum hassle for both sides.

This talk is actually an updated version of the one I gave a year earlier at PyConES.

In this talk I gave at PyconES 2018 I discuss the basic theory around microservices architectures, and go over the common pain points that they bring, and how they often get you in the opposite direction than you intended with them.

We found an easy and cool solution, all you need is a phone (mainly an Android, but if you IOS, just replace the apps and locations with the IOS equivalent) and an image editor to paint your room in Virtual Reality.

Create your 360 picture

First, download the Google cardboard app for Android.

Open the app, (after a few configuration steps), and go to cardboard camera and take the picture by rotating the phone slowly.

The picture will be stored in sdcard/DCIM/CarboardCamera with a .vr.jpg extension. Copy that file into your computer.

Export _left and _right images

Although the image taken by the cardboard camera looks like a normal jpg image, it contains some metadata that allows the app to support VR.

Because of this, we need to export the .vr.jpg into two separate images using https://cctoolkit.vectorcult.com/#, this step is key to the whole process.

Upload your picture into that website and it will get splitted into two (one for each eye). Right click on the images and save them on your computer with _left and _right names.

Editing the VR picture

We used GIMP to edit the image, but you can use photoshop or any other image editor, just open both _left and _right images you exported before with it and you will see a plain wide image.

Now you can edit the images in any way you want, what I did was to use the different select tools to select just (and only) the walls on the room, then move it to another layer (for easier management) and then used the colourise tool to change the color.

You need to repeat this operation for both images. Once you’re done, save both images and be ready to combine them together again.

Generate new VR image

Go back to the same website as before https://cctoolkit.vectorcult.com/# and join both images this time, remember to keep the _left and _right names before uploading.

This will generate a new .vr.jpg page. Copy the image back on DCIM/CardboardCamera. If you did everything correctly, you will see both pictures (the new one and the old one) on the cardboard. If you upload a non-vr image, it won’t show on the app.

Click on the image and you will see it on VR. That’s it, enjoy.

The game is not yet finished, but because we are going to move to a different project, we thought about showing you a demo of what we’ve built so far.

Demo

This is a first look of the mechanics of the game

You can play this demo in here http://unity3d.coconauts.net/escaperoom-unlock/. Remember, it is not finished so it could be buggy and you will not be able to finish the level.

Level design

We copied the gameplay of the first level of the unlock game, with the same clues, same objects, similar text entries and even the similar wall textures.

The inventory system

We added to this game a new inventory wheel system, where you pick items and you use them on any other object in the scene using the right click, showing all the items you have on a wheel.

But of course, different items will have a different effect on the item you’re trying to use it on.

Conclussions

It takes a lot to generate the 3d models, implement the logic and replace the card-only mechanics into a 3D videogame; but the result is worth it.

I think, (now that we have proved the concept with a working level design) we could start building our own levels, adding more interactive puzzles (like the laptop one in our previous game).

However, we will pause this project for a while to start working on different stuff, but let us know if you have any interest on playing a game like this at some point in the future.

What do you think about the game? Your feedback is really valuable to us! so please let us know on the comments or on twitter.