Date: 30 January 2026
Category:
Back when I was a kid, I remember the tamagotchi craze hitting my school. They're the pocket sized virtual pets you had to keep alive and everyone had one. You had to take it to school on the sly, or it would die if you left or at home.
Fast forward many years, I saw one in the shop and thought my kids would love that. It's wasn't a Tamagochi, just a cheap immatation, but thought it couldn't be that different.
So I took them back home and handed them over to the kids, they were opened and I was pretty disappointed. I remember starting with an egg and the little creature evolved based on how well you looked after it. These however, were much more simplified. You picked what animal you wanted from the start and that was it.
The biggest gripe was that one of the three buttons was a reset button. There were a few times when this button was accidentally pressed and all progress was lost. This was devastating for small children.
This got me wondering, how difficult it would be to create my own virtual pet? Take in mind that I've never done any electrical work... ever.
I'm any case, I thought it could be fun to document my struggle!
Ideas
The main things which I think are important are the form factor and battery life. There's no point having a small portable item if the battery only lasts a few hours. To help minimise mattery consumption, I would need to use low powered components.
I quite like the idea of them being able to interact with one another. If both of the girls had one, it would be nice if they could use the devices to play with each other. My main thought is battling like Pokemon.
I did a little research into this and found out about Digimon virtual pets. They were created by the same company which created tamagotchis but could battle each other. I remember them being a thing when I was a kid, but I don't remember any of my friends having one. The main down point to the Digimon was that you had to connect them together to battle, which meant you needed to know someone else who also had one.
I really like the idea of using the Nintendo 3DS streetpass type functionality where if you were near someone else with a 3DS, your games could exchange data in some way... so for example, you'd be able to see their Mii character in one game, or they might give you an item in another game. I'd want to use this mechanic so if you walked past someone with one, they would passively battle in the background. I don't know how possible this would be with the hardware.
Hardware
I think the hardware I need is somewhat minimal. I'd need a microcontroller, a screen, and a few buttons.
Microcontroller
I had originally started looking at the Raspberry PI Pico 2 W as I had used a few of their other boards before. While doing research I found out about the ESP32 chip and some of the boards were about half the size of the Pico. Being how small the project will be, I didn't think I'd need the extra ports.
Screen
I opted for a basic OLED screen, purely because power consumption was minimal and it would be easier/quicker to draw things for it.
Purchase
I totally cheaped out and went with AliExpress in the end. I wasn't sure how well this was all going to go, so I didn't want to spend 4 times the amount buying from someplace more local. The grand total was... (drumroll please!) £6.58, which got me:
ESP32
OLED display
Buttons
Breadboard
No idea how well these will work together, but looking forward to trying it out!
Date: 26 July 2025
Category: Icon Pusher
Anyone using the IconPusher app may have noticed that there's not been an update recently, the main reason for this is Google being difficult.
So to explain this, a couple of years ago Google changed their policy with how developers can access app details. By default now, the app can only get permissions of the app itself and system apps.
If we want to gain access to other installed apps, we now need to add in a new permission into the config to allow it.
With this change, every update to the app I've submitted has been rejected, requiring me to submit an appeal explaining why my app needs this permission to be enabled.
While annoying, it was generaaly fine, my updates still got published, although somewhat delayed.... until last year anyway.
The last update I tried to publish was rejected as usual, and I sent my appeal explaining why the permission to grant access to all apps was required.... then.... my appeal was rejected.
Apparently, the Icon Pusher app, with the sole function of accessing installed apps to submit to the site, doesn't qualify for needing the permission of accessing all the installed apps!
After sending multiple messages to Google, explaining why this permission is required, I gave up.
Soooo, I had been putting this off for ages, and I've recently received an email from Google threatening to delist the app if it's not updated.
Hopefully, I'll have more luck updating the app this time.
If not, I'll have to just start uploading releases for people to download.
Date: 25 July 2025
Category: Linux
I've recently been setting up a new server and ran into a file permissions issue I hadn't encountered before, and it took me hours to figure out.
So I've been setting up IconPusher on the new server, the API runs as a WAR file over Jetty9 which takes the uploaded app icons and puts them in the directory for the img subdomain.
However, once this was running on the new server, no matter what I tried, I was given a 'read only filesystem'.
I checked the usual suspects of directory permissions, Apparmor and SELinux... everything looked as it should be.
What I did in the end was to check the Jetty service to see what conditions were in effect. to do this I ran the command:
sudo systemctl cat jetty9
and this highlighted the issue:
Under the Security section was this line:
ProtectSystem=strict
So now I knew this was the cause, I could whitelist the directory I'm writing to.
This can be achieved by entering the following command:
sudo systemctl edit jetty9
And then entering the following:
[Service]
ReadWritePaths=/path/to/my/directory
This creates a new file at /etc/systemd/system/jetty9.service.d/override.conf so it can be modified here if preferred.
After adding this you need to reload the daemon:
sudo systemctl daemon-reload
And the jetty9 service:
sudo service jetty9 restart
Then you can check that the change is in effect with the following:
sudo systemctl cat jetty9
Date: 7 July 2025
Category: Icon Pusher
Not a huge amount to see in the latest update, but hopefully the general experience will be improved.
The API was upgraded to use KTOR v3.2.1 from v2.3.10, which involved a number of updates to get working.
The main reason for this change was to hope it addresses a rare issue where the API would randomly die without warning.
There was also a lot of restructure on the front end of the website, to help improve general performance.
Date: 11 May 2024
Category: Icon Pusher
Icon pusher was something I whipped up back in 2020. For those who don't know (the majority I imagine), icon pusher is a utility for icon pack developers to get the app details and icons they need to create their packs.
The idea of some hefty QOL changes have been on the cards for a while but have only recently been worked on. The main of which is the ability to select multiple apps at once and being able to download all the data in one go. On the original version of the site, to get the data for multiple apps you would have to go back & forth between all the apps, copying all the XML data and download each icon individually. While this did the job, it was pretty inconvenient.
Version 2.0 of the website is currently available as a beta version. While it's mostly there functionality wise, there are a few pieces which still need tidying up.