Entries this day: played-pop-pop-chaos-with-rancidpony today-at-work

played pop pop chaos with rancidpony

18:29 Tuesday 01 September 2015 JST

A couple days ago I noted someone burst a bubble on Pop Pop Chaos, so I joined the fun! It seemed s/he was only interested in bursting bubbles, not creating them, so I created some, and then joined the fun and we just popped alll the bubbles. The white ones kept coming back, as they do, but then after a while I created a bunch of blue bubbles in a row, so he'd (be more likely to) know it wasn't computer-generated bubbles, well.. not algorithm generated,.. well, anyway, then blam! he made a bunch of yellow bubbles, and raced up the leaderboard and then suddenly vanished! I was like O_o what happened?

I found houston:admin, which perfectly augmented the app with DB admin skillz. Perfect! I discovered what happened: in his flurry of creates, rancidpony won a race with the server and created more bubbles than he had points to create!

His point value went negative and he promptly vanished from the high score list, because that's how I was distinguishing my account (which always has permissions to create, despite its score of -2300 or something.

So I retooled the logic which populates the leaderboard to say admin cannot join, but negative score people are welcome. So rancidpony has -35 points and is halfway up the leaderboard!

AND rancidpony is credited with finding a bug. Thanks!

today at work

18:38 Tuesday 01 September 2015 JST

Satomi came down at the perfect time; I had just finished and committed a set of changes for a new process for the AB site. They want new data added to the historical primary tables, gleaned from data in the secondary tables (basically log tables).

Basically things in the primary table can be active or inactive. We have a log of when they were activated and deactivated. The cycle of (in)active toggles can spans years at times, or could just be days.

Each month I take a snapshot of the primary data for doing trend reports. Now, the snapshots obviously know if their rows are active or inactive at the time of the snapshot, but they don't know how long they had been (in)active at the time of the snapshot.

That's what my new code needs to do. Go back and look at the log, calculate the ranges of (in)activity, and fill in the newly-created blanks in the historical snapshots. Fun!

Fortunately, it's a DB table "log" so there's no text parsing required. But I do have to deal with objects being set to inactive or to active multiple times in a row. something like this, for item number 5, (but with a lot more data haha):

5  inactive 2004-03-06
5  active   2004-08-28
5  inactive 2006-11-12
5  active   2007-07-28
5  active   2007-09-24
5  inactive 2009-06-21
5  active   2010-04-03