The problem (me)
I’m always finding new ways to avoid going through my WK reviews (and Japanese study in general). There’s always a side quest to project my laziness onto and i can be quite the artist when it comes to self sabotage so everything stagnated according to the plan for some time. But lately i’ve been in a bit of a slump, i just couldn’t come up with any good excuses anymore, my review pile had achieved equilibrium, every non-burned item I owned was ready for review, so the solution was simple.
I should make myself a pocket-sized WaniKani device so the friction is minimal and i have no excuse for not doing reviews more often!
Got my inspiration from this forum post here and a couple like it but this one has been on my mind for some time:
[Hardware] e-Paper flash card project
And that’s because my reaction to it was: that’s very cool, but why not hook 2 buttons to them and hook that up to the WaniKani API? I will never forgive you for what you made me do @jpmurphy.
I’ll present my take on this idea and i’ll continue the rambling after the pictures.
Enter: The TuftyKani
Temporary name but at this point i’m too tired to care about it.
It is an app for a Pimoroni Tufty 2350. That’s basically an electronic badge with bluetooth+wifi connectivity. I wanted to build the device myself with an E-Ink screen and a pi zero 2W but i was too intrigued by the Tufty so i bought it instead. They also have an E-ink but i went with the LCD for responsiveness and i think i’m pretty sure i made the right choice.
Features
- It fetches the review queue from WaniKani and caches them locally.
- After fetching the queue, reviews work offline too, updates are cached locally too.
- It displays meanings, readings and mnemonics in a scrollable screen.
- 2 buttons: Pass/Fail, plus one Stop button because review sessions can be stopped at any time.
- Flashcards have different colors based on their type (radicals - blue, kanji - pink, vocab -purple).
- If there’s internet connectivity it can push the updates to wanikani (it waits for rate limits and everything)
I’m pretty happy with it. It was a rollercoaster and i almost quit but i’m glad i didn’t because it’s so satisfying to carry this around and fidget with it while also feeling productive.
The rollercoaster
AKA: Me rambling, moaning and complaining for the remainder of this post
I chose the Tufty because i’ve never seen something like it and it looked so nice (and it is, don’t get me wrong). My other option was the Adafruit MagTag (though i think that one is a bit more limited but don’t quote me on that.). I wish i would’ve spent a bit more time thinking this through because I severely overestimated the RAM and flash storage on these small devices. Everything around us is in gigahertz, gigabytes and such and i kinda took that for granted.
Writing the UI was a pain
I placed my order and i had some time to kill while i was waiting for the device so i had a the full functionality built in the form of a CLI app. All was fine and dandy but when i started porting it to a GUI app everything became so tedious. I split the app into multiple files and i lost the ability to debug locally so I had to put the device into storage transfer mode, overwrite files, restart and start the app every time i had a change. I quickly gave up and got claude code on that and because i am also learning electronics and this was beginning to feel like a chore that was not letting me do that. It went much smoother after that and i mean, i already built the app and the first UI menus, i proved to myself everything i wanted to prove.
I couldn’t print japanese characters
I had issues printing kanji, hiragana and katakana and i couldn’t find a way to use fonts so i was on the verge of giving up. But i managed to fix this by (sit down, it’s ugly) creating separate png files for all kanji characters and chaining them together. It’s just as painful and disgusting of a solution as it sounds.
10 MB of nothing
My PNGs were all, idk, 20 ish bytes each? I really don’t remember but a small number nonetheless. The problem is that the filesystem was allocating memory in blocks or 4096 so each small file was taking a minimum of 4KB. So my kanji were filling up all of the board’s flash memory, and it got to the point where the code no longer fit on it. So i had to group them together in a handful of files. I also had to pre-fetch subjects from the WK api instead of having an option in the menu to do that on-demand (that was my first iteration) because the write-enabled partition was ~1MB and i needed to move it over to the read-only memory. Hope this all makes sense. If it doesn’t at least i hope i’m doing a good job with making it sound painful, because it was.
I think i struck somewhat of a balance between file size and performance and i am left with enough storage space on the device to fit other apps. It works, i haven’t had much time to test drive it but it seems to behave nicely. The board is nice and i’m sure most of my problems were just me not knowing better ways to optimize these things, as i’m not usually writing apps for embedded systems and i always have the privilege of never having to think about cpu usage, RAM or storage space for small text files.
It took me too much to write this post and i need to run, there’s definitely more to say but i hope you enjoyed my little project. 
I guess you can tell that i spent a lot more time in the first paragraphs and i started rushing towards the end but i’ll answer any replies when i come back.
I guess the moral of the story is: do your research before purchasing hardware for a random niched project, lest you end up like me. But hey, being stubborn enough carried me through this endeavour, maybe it works for you too.
Thanks for reading through whatever this was 