Abstract ideas in programming
Jan. 13th, 2019 11:30 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mtbcI like excuses to have to think about the code I am writing. Last week I spent a couple of days working on a script for deleting the data of users of our demo server. There is no suggestion that one should keep one's precious data on the server: it is simply for trying the system out and occasionally its disk gets rather full. In deciding which users' data to delete I wondered if I could at least construe the question multi-criterially and have the script make Pareto-optimal choices.
As for what those multiple criteria might be: for a user they could be how long it is since they last used their demo account, how much disk space their data takes and how many inodes it takes. Another criterion for a deletion plan might be how many users the plan affects. For such plans, if a user is to have their data deleted then the plan could target all the users they Pareto-dominate: where that other user logged in even longer ago or uses even more resources without being better on any count. Nearly twenty years ago I designed a nice GUI for navigating tradeoffs among that kind of plan: in being designed to accommodate the Apple Macs that back then had but one mouse button it accidentally anticipated the finger-on-touchscreen interfaces of today.
The cleanup of accounts on the demo server was just one of the side projects I looked at while others make large changes to the body of server code I would otherwise have worked on; it does not warrant a full design treatment and advanced interface. Still, the script that I did draft at least has the property of: if it deletes a users' data then there is no untouched user who logged in longer ago and uses more of the resources that must be reclaimed.
I greatly appreciate opportunities to think mathematically about my work. For a software development post I once interviewed an older person who made my shortlist. It is fine if applicants are old as long as they remain sharp in conversation and, while I now forget the details, they were able to speak intelligently about an interesting programming problem that they solved using results from number theory. Alas, they have since been taken by cancer.
As for what those multiple criteria might be: for a user they could be how long it is since they last used their demo account, how much disk space their data takes and how many inodes it takes. Another criterion for a deletion plan might be how many users the plan affects. For such plans, if a user is to have their data deleted then the plan could target all the users they Pareto-dominate: where that other user logged in even longer ago or uses even more resources without being better on any count. Nearly twenty years ago I designed a nice GUI for navigating tradeoffs among that kind of plan: in being designed to accommodate the Apple Macs that back then had but one mouse button it accidentally anticipated the finger-on-touchscreen interfaces of today.
The cleanup of accounts on the demo server was just one of the side projects I looked at while others make large changes to the body of server code I would otherwise have worked on; it does not warrant a full design treatment and advanced interface. Still, the script that I did draft at least has the property of: if it deletes a users' data then there is no untouched user who logged in longer ago and uses more of the resources that must be reclaimed.
I greatly appreciate opportunities to think mathematically about my work. For a software development post I once interviewed an older person who made my shortlist. It is fine if applicants are old as long as they remain sharp in conversation and, while I now forget the details, they were able to speak intelligently about an interesting programming problem that they solved using results from number theory. Alas, they have since been taken by cancer.
