I use Google Meet every day for (potentially hours of) online meetings at work, so it’s very easy to notice when things change and for example new features are available. Recently I’ve found a new “Call Control” section in the settings that promised a lot of fun, connecting USB devices to control my calls.
As someone who enjoys (or drawn to, or sort-of obscessed with) hacking on hardware, this was a nice call of action: let’s cobble together a custom USB button that can do some kind of call control1: say muting myself in the call, showing mute status, hanging up, etc.
This kicked off such a deep rabbit hole that I barely made it back up to the top, but one that seeded a crazy amount of future opportunities.
Over the last decade I seem to have been working in environments, where many engineers and engineering minded people spend time with programming puzzles and coding challenges. Let it be Advent of Code, Project Euler, Exercism, TopCoder, or Leetcode. I’ve tried all of these before (and probably a few more that I no longer remember), though with various amount of time spent all fired up, and then fizzled out. Recently I’ve picked up Leetcode, since from the above list that’s why I’ve spent the least amount of time with and others mentioned using it a way to relax and learn on weekends (suspend judgement on the wisdom of that for now).
Thus in the last two weeks I was solving problems, though not just any problems, but went in mostly for the Easy ones. These few dozen problems and short amount of time doesn’t give me a deep impression, but from past experiences I can still distill some lessons that help shaping future experiments.
The purpose of using the Easy problems is different from e.g. going all in for puzzle-solving fun, which is likely in the Hard ones. Rather than that, I think easy problems can be used for learning some new techniques, looking for common patterns, and becoming more polygot.
Protohackers is a server programming challenge, where various network protocols are set as a problem. It has started not so long ago, and the No 3. challenge was just released yesterday, aiming at creating a simple (“Budget”) multi-user chat server. I thought I sacrifice a decent part of my weekend give it a honest try. This is the short story of trying, failing, then getting more knowledge out than I’ve expected.
Definitely wanted to tackle it using Python as that’s my current utility language that I want to know most about. Since the aim of Protohackers, I think, is to go from scratch, I set to use only the standard library. With some poking around documentation I ended up choosing SocketServer as the basis of the work. It seemed suitable, but there was a severe dearth of non-dummy code and deeper explanation. In a couple of hours I did make some progress, though, that already felt exciting:
Figured out (to some extent) the purpose of the server / handler parts in practice
Made things multi-user with data shared across connections
Grokked a bit the lifecycle of the requests, but definitely not fully, especially not how disconnections happen.
Still it was working to some extent, I could make a server that functioned for a certain definition of “functioned”, as the logs attest:
I had received a (family) project brief recently. In Taiwan many credit/debit cards have various promotions and deal, and many of them depend on one’s monthly spending, for example “below X NTD spending each month, get Y% cashback”. People also have a lot of different cards, so playing these off each other can be nice pocket change, but have to keep an eye on whether where one is compared to the max limit (X). So the project comes from here: easy/easier tracking of where one specific card’s spending is within the monthly period. That doesn’t sound too difficult, right? Except the options for these are:
A banking website with CAPTCHAs and no programmatic access
An email received each day with an password-protected PDF containing the last day’s transactions in a table
Neither of these are fully appetizing to tackle, but both are similar to bits that I do at #dayjob, but 2. was a bit closer to what I’ve been doing recently, so that’s where I landed. That is:
Forward the received email (the email provider does it)
Receive it in some compute environment
Decrypt the PDF
Extract the transaction data table
Clean and process the tabular data
Put raw in some data warehouse
Transform data to get the right aggregation
I was surprised how quick this actually worked out in the end (if “half a weekend” is quick), and indeed this can be a first piece of a “personal finance data warehouse”.
In the course of pushing myself to write more on this blog, I’ve come across the #100DaysToOffload project. It’s super simple: write a 100 blogposts in a year in your personal blog to unlock the achievement. It seems like gamification done to the right level, as it’s not to strenuous (“write every day” would likely fail before lift-off), and not too lax (100 blogpost are still quite a stretch to go!). Thus it looked like the right too to trick myself into doing the thing I already wanted.
On the other hand, I’m one for meta-games, especially when I have doubts whether I stand a chance in the game itself, thus came the idea of do something around 100DaysToOffload that might also result in a blogpost. Hence came the “Hundred Days to Offload” WordPress Plugin idea: get a bit of coding in, make something useful to see if the game has been “won”, an also get one (or more) write-ups out of it.
Spoiler alert: it’s working now, very barebones, but to the point… that there’s a long way to go.
In the process, that took a couple of days over the weekend, I’ve revisited PHP, that I used to “play” with for projects before, though haven’t done anything serious, nor made it part of my Language of the Month series, so far. It was still quite interesting to revisit with more mature eyes of e.g. how good projects look like in the Python ecosystem (where I spend most of my time), and whether lessons learned there are applicable here.