180 new lolslackbot users

I just set up lolslackbot for Learning Fives Session 2. Some 180 new users. Kind of an exciting day for me, before I only had 30 or so users.

My test infrastructure continues to pay off in spades. All sorts of firsts today. First time running with users a new region (Latin America). First time where I got a game where all 10 people were in my cohort I was tracking. Etc. And AFAICT it all worked as intended. Really no problems running it other than some scutwork and some unintended consequences.

The scut work is I still have no UI for administering users in my system. I spent half of today writing 150 lines of Python + tests to set up the new users. I have to create entries in five tables: People, Groups, Channels are all primary data entities, I also have “GroupMembership” and “Subscriptions” which are basically tables joining IDs from other tables. And all this crap is injected with command line tools. I do have scripts to at least populate them from CSV and JSON datafiles, it’s not raw SQL, but it’s close.

I really need a proper web GUI for editing these data entities, regrettably in Django, and I’m still dragging my feet on taking that leap. I have an idea for a new product I can do in Django though, a quick spike for something related to the existing code

The unintended consequences is I neglected to account for how unusual this first run would be after the import. Basically I was catching up, getting info on past games those 180 new users played. It took 15 minutes to download 10 match records for each of my 180 new users. And then that generated 177 messages which it immediately delivered, in a few cases spamming 10+ messages to a Slack channel. Those messages were all correct in some sense, but in retrospect it would have been better to suppress the past and only start delivering new messages instead. Oops.

2 thoughts on “180 new lolslackbot users

  1. I hope you get around/have the time/inclination to write in more detail about the practical and architectural issues with this thing since there is surprisingly little in that space. There’s a great deal out there about ‘single-threaded python program’ and on the other end of the spectrum ‘that wasn’t enough so we wrote a django or a tornado’. There’s a huge space in between where nobody is going to write a tornado (or twisted or whatnot) but also isn’t exactly a synchronous script. All sorts of concurrency, sequencing, parallelism, transactionality and so forth bugbears live there in a odd, little-discussed python twilight.

  2. Sadly I’m still in single threaded Python land, and it’s a big problem. The obvious thing is for me to parallelize the initial “use the API to check all 200 users” thing and I still plan to get around to it, probably using asyncio. My other problem is I painted myself into a corner using sqlite which doesn’t work well with concurrent writers. Moving to asyncio won’t trigger that, but adding a web view for editing will.

Comments are closed.