Azure Jane Lunatic (Azz) 🌺 (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
azurelunatic) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_dev2011-03-16 06:57 am
azurelunatic) wrote in dw_dev2011-03-16 06:57 am
Entry tags:
Code tour: 2011 March: 10th to 16th
And, another week, another code tour! This one has 9 bugs, most of them back-end. Six of these are by exor674, two by wyntarvox, and one by fu, who was busy reviewing many of the rest as well!
There are actually only three user-facing things here:
Notifications of edited comments will show up differently in the inbox, in a way that should make more sense.
A weird styles pluralization problem with hour/hours will get fixed.
Only spamwhackers will see this one: if there's already a sysban (that you can see) in place, it will show up in the spam report.
Details, bad geeky jokes, and dodgy analogies continue below the cut.
Bug 3559: DW::Request::Standard doesn't implement $r->read
Category: Routing/TT, things most users won't see
Patch by:exor674
Description: DW::Request::Standard is a back-end thing that's pretty much only used for testing right now. It was missing a thing called $r->read, which worked OK in real life, but was making the tests unhappy. There was a hacky workaround to make the tests happy. This replaces the hacky workaround by putting $r->read into DW::Request::Standard where the tests expect it to be. If we actually use this for anything besides testing, there will have to be more work, but this is better for now.
Bug 3526: Need function to set current site scheme in DW::SiteScheme
Category: Misc Backend, things most users won't see
Patch by:exor674
Description: You know how you can set the site skin you would like to use, in case a lot of red and dilute red (IT'S NOT PINK, DAMMIT, my inner artist roars) is not your thing? (There's also pale purples (and here there's some pink!), muted greens, a light-on-dark in two flavours, and a dark-on-light that's also very minimalist and non-graphical browser friendly.) But in any case, that's the front end -- it's handled better on the back end now.
Bug 3089: *proplist ids increasing very rapidly
Category: Misc Backend, things most users won't see
Patch by:exor674
Description: There are various mysterious things on the back end called "properties" (props, for short) of various types that hold data about people's accounts. For example, there are userprops, which hold things like whether you would like your account to come up in the list of random accounts that random people can give paid time to. They are organized in tables, with the property name, other descriptive things, your setting, and an arbitrary number for indexing purposes. Unfortunately, there was a problem with the arbitrary number infu's testing installation. Previously, normally, the number was going up by a few hundred at a time. Then it started going up by a few thousand. Big numbers are harder to shove around, so this caused some worry, but fortunately it was only in fu's testing installation. She traced it to the version of MySQL database software being used, and certain specific conditions. Then exor674 wrote a patch. This is a case where having people with slightly different development environments saved a headache for the whole site down the road.
Bug 3082: Customizable sysban notes for Spam Reports (open)
Category: Misc UI/Frontend, fun tools to smack spammers
Patch by:exor674
Description: Short version: a tool to make the life of a spamwhacker easier. Long version: This requires some knowledge of the lifecycle of the spammer, and the tools we use to zap 'em.
1) The spammer spams a user.
2) The user deletes-and-reports the comment.
3) The comment, and some data for context, like the server time when the spammer left it, and the server time when the user reported it, are put in a little report and given to the spamwhackers. (SPAMWHACKERS, REPRESENT!)
4) Spamwhackers confirm that it is actual spam and not an accidental/mistaken report of non-spam.
5) Spamwhackers take appropriate action. This is accompanied by a log note containing the spamwhacker's name, the server time, and occasionally a quip about the spam. ("It's awesome! If my life lacks existential meaning, I can duck in, whack some spam, and feel like I have purpose again!" ~rydra_wong "Oil painting reproductions? Oh Neal. Peter won't be happy when he hears about this." ~azurelunatic)
6) Spamwhackers close the report and go on about their days.
7) Occasionally, there are some reports about spammers that show up after the initial report has been closed. When this happens, it would make sense to have the log note from the original handling show up on that page, wouldn't it? That's what this patch does.
Bug 3517: Remove references to nonexistent (ljcom-only) phonepost tables in code inherited from livejournal
Category: Misc Backend, things most users won't see
Patch by:fu
Description: LiveJournal has phone posts. If Dreamwidth ever does get locally stored audio posts, we will have to re-invent theweasel wheel (or adapt code from somewhere else), as LiveJournal's implementation is proprietary and not part of the Open Source part of the project. However, other parts of the inherited code mention tables that belong in the phonepost stuff, that therefore we don't have. This time it was pauamma pointing out the offending bits of code and holding them still while fu wielded the code-machete.
Bug 3135: $timespan since entry when hovering over comments datetime is hardcoded to plural form
Category: Style System, making things make sense
Patch by:wyntarvox
Description: OH BOY, IT'S A WYN!!! It's always nice to see names you thought were lost in the depths of time, though actually he had patches in last week too. (Other contributors, if you were helping out, but life attacked, and you wanted to come back, but thought it might be weird after such a long time? Totally not weird. You're more likely to get the OH MY GOD IT'S YOU; HOW THE HECK ARE YOU DOING?!?! glomping rather than accusatory stares.) So anyway, the problem was that instead of "1 hour since entry / 2 hours since entry", there was the hilariously not-bug-free-English "1 hours since entry / 2 hours since entry". There's actually a pre-existing function that decides whether something being counted is pluralized or not in English, and this uses that. Hooray!
Bug 3479: edited comment notifications in the DW inbox
Category: Inbox/Notifications, making things make sense
Suggested by:ratcreature
Patch by:wyntarvox
Description: There are nine bugs in this code tour. This is the seventh one. Which makes this bug Seven of Nine! Which is good, for it is Borg-like in its actual complexity. Now comment edits as they appear in the inbox will show up as a shorter notice that the comment was changed, which is good when someone takes a few rounds to phrase themselves just right; the full text of the edited comment will still be emailed. The fun part was apparently figuring out how it should be done on the back end. It is handled sort of like a separate subscription, but the subscription-to-edited-comments is tied to the subscription-to-new-comments in such a way that it does not burn an extra subscription, and there won't be a separate checkbox.
Bug 3539: Make sure method is GET/POST ( unless the controller handles more )
Category: Routing/TT, things most users won't see
Patch by:exor674
Description: This bug was resolved last code tour, but there was a moment of concern about problems with the patch after it was deployed to a development environment, so the bug was re-opened. Happily, those problems turned out to be just needing to re-start the web server service, so the bug was closed again without incident.
Bug 3564: Fix remaining failing tests.
Category: Misc Backend, things most users won't see
Patch by:exor674
Description: More stuff to fix more tests. There are three things of note done in this one, but they're all pretty subtle.
1) Some of the various other back-end upgrades made it possible to remove a thing called 'webreq.t', soexor674 got out the code-machete; this one's invisible to most users.
2) When building an Atom feed of a journal or community, the author of the entry is now shown in proper format. This is very good! And now the test is changed to go along with it. The previous change will be noticed by people looking at atom feeds; this test change will be invisible to most users.
3) There's a tool called the usermover, which ... moves users! People who are familiar with LiveJournal database architecture will possibly recall how users there are on different database clusters, and may even remember their favorite or least favorite clusters. (They used to have South Park characters; now they have meat and meat-substitutes.) We have clusters too; ours are named after stars right now. Organizing the user-holding databases into clusters makes it so no matter how many users we get, the databases holding user data are always small enough for our servers to handle. Have an analogy: imagine handing eight grocery bags to eight bouncing kids, so the kids can carry the bags into the kitchen. Unless the kid with the bag with the eggs trips over something, you're probably good. Now imagine attempting to carry all eight grocery bags yourself. Some of you will be able to do it just fine, but depending on the size and weight of the grocery bags and your particular ability level, you may not actually be able to do this in one trip, or at all, or not this week. [Code tour pauses for a half-hour field trip to wikipedia.] ... Right, so we use clusters, and the usermover is a tool that can move users between clusters, in a way similar to how when too many heavy cans have been stuffed in one bag, you can take some out and put them in another bag, so whoever's carrying it will have an easier time. Now, the blobcache. In database terms, "BLOB" stands for "Binary Large OBject", because database designers actually do have a sense of humor. This is big chunks of stuff that don't fit into smaller data types. [Insert comparison between smallish grocery sacks and those great big blue IKEA bags here.] We use the blobcache table for keeping track of big chunks of arbitrary data, like logs of database migrations and so forth. Because of the way the blobcache table was labeled, the usermover started to get worried about it. (If you like, have a mental image of a kid hauling grocery bags, where one of the grocery bags is labeled that it should belong both in the kitchen and in the garage.) This part of the patch tells the usermover to chill out about the blobcache table. This one is invisible to most users.
And that's it for another week!
exor674, two by wyntarvox, and one by fu, who was busy reviewing many of the rest as well! There are actually only three user-facing things here:
Notifications of edited comments will show up differently in the inbox, in a way that should make more sense.
A weird styles pluralization problem with hour/hours will get fixed.
Only spamwhackers will see this one: if there's already a sysban (that you can see) in place, it will show up in the spam report.
Details, bad geeky jokes, and dodgy analogies continue below the cut.
Bug 3559: DW::Request::Standard doesn't implement $r->read
Category: Routing/TT, things most users won't see
Patch by:
exor674Description: DW::Request::Standard is a back-end thing that's pretty much only used for testing right now. It was missing a thing called $r->read, which worked OK in real life, but was making the tests unhappy. There was a hacky workaround to make the tests happy. This replaces the hacky workaround by putting $r->read into DW::Request::Standard where the tests expect it to be. If we actually use this for anything besides testing, there will have to be more work, but this is better for now.
Bug 3526: Need function to set current site scheme in DW::SiteScheme
Category: Misc Backend, things most users won't see
Patch by:
exor674Description: You know how you can set the site skin you would like to use, in case a lot of red and dilute red (IT'S NOT PINK, DAMMIT, my inner artist roars) is not your thing? (There's also pale purples (and here there's some pink!), muted greens, a light-on-dark in two flavours, and a dark-on-light that's also very minimalist and non-graphical browser friendly.) But in any case, that's the front end -- it's handled better on the back end now.
Bug 3089: *proplist ids increasing very rapidly
Category: Misc Backend, things most users won't see
Patch by:
exor674Description: There are various mysterious things on the back end called "properties" (props, for short) of various types that hold data about people's accounts. For example, there are userprops, which hold things like whether you would like your account to come up in the list of random accounts that random people can give paid time to. They are organized in tables, with the property name, other descriptive things, your setting, and an arbitrary number for indexing purposes. Unfortunately, there was a problem with the arbitrary number in
fu's testing installation. Previously, normally, the number was going up by a few hundred at a time. Then it started going up by a few thousand. Big numbers are harder to shove around, so this caused some worry, but fortunately it was only in fu's testing installation. She traced it to the version of MySQL database software being used, and certain specific conditions. Then exor674 wrote a patch. This is a case where having people with slightly different development environments saved a headache for the whole site down the road. Bug 3082: Customizable sysban notes for Spam Reports (open)
Category: Misc UI/Frontend, fun tools to smack spammers
Patch by:
exor674Description: Short version: a tool to make the life of a spamwhacker easier. Long version: This requires some knowledge of the lifecycle of the spammer, and the tools we use to zap 'em.
1) The spammer spams a user.
2) The user deletes-and-reports the comment.
3) The comment, and some data for context, like the server time when the spammer left it, and the server time when the user reported it, are put in a little report and given to the spamwhackers. (SPAMWHACKERS, REPRESENT!)
4) Spamwhackers confirm that it is actual spam and not an accidental/mistaken report of non-spam.
5) Spamwhackers take appropriate action. This is accompanied by a log note containing the spamwhacker's name, the server time, and occasionally a quip about the spam. ("It's awesome! If my life lacks existential meaning, I can duck in, whack some spam, and feel like I have purpose again!" ~rydra_wong "Oil painting reproductions? Oh Neal. Peter won't be happy when he hears about this." ~azurelunatic)
6) Spamwhackers close the report and go on about their days.
7) Occasionally, there are some reports about spammers that show up after the initial report has been closed. When this happens, it would make sense to have the log note from the original handling show up on that page, wouldn't it? That's what this patch does.
Bug 3517: Remove references to nonexistent (ljcom-only) phonepost tables in code inherited from livejournal
Category: Misc Backend, things most users won't see
Patch by:
fuDescription: LiveJournal has phone posts. If Dreamwidth ever does get locally stored audio posts, we will have to re-invent the
pauamma pointing out the offending bits of code and holding them still while fu wielded the code-machete. Bug 3135: $timespan since entry when hovering over comments datetime is hardcoded to plural form
Category: Style System, making things make sense
Patch by:
wyntarvoxDescription: OH BOY, IT'S A WYN!!! It's always nice to see names you thought were lost in the depths of time, though actually he had patches in last week too. (Other contributors, if you were helping out, but life attacked, and you wanted to come back, but thought it might be weird after such a long time? Totally not weird. You're more likely to get the OH MY GOD IT'S YOU; HOW THE HECK ARE YOU DOING?!?! glomping rather than accusatory stares.) So anyway, the problem was that instead of "1 hour since entry / 2 hours since entry", there was the hilariously not-bug-free-English "1 hours since entry / 2 hours since entry". There's actually a pre-existing function that decides whether something being counted is pluralized or not in English, and this uses that. Hooray!
Bug 3479: edited comment notifications in the DW inbox
Category: Inbox/Notifications, making things make sense
Suggested by:
ratcreaturePatch by:
wyntarvoxDescription: There are nine bugs in this code tour. This is the seventh one. Which makes this bug Seven of Nine! Which is good, for it is Borg-like in its actual complexity. Now comment edits as they appear in the inbox will show up as a shorter notice that the comment was changed, which is good when someone takes a few rounds to phrase themselves just right; the full text of the edited comment will still be emailed. The fun part was apparently figuring out how it should be done on the back end. It is handled sort of like a separate subscription, but the subscription-to-edited-comments is tied to the subscription-to-new-comments in such a way that it does not burn an extra subscription, and there won't be a separate checkbox.
Bug 3539: Make sure method is GET/POST ( unless the controller handles more )
Category: Routing/TT, things most users won't see
Patch by:
exor674Description: This bug was resolved last code tour, but there was a moment of concern about problems with the patch after it was deployed to a development environment, so the bug was re-opened. Happily, those problems turned out to be just needing to re-start the web server service, so the bug was closed again without incident.
Bug 3564: Fix remaining failing tests.
Category: Misc Backend, things most users won't see
Patch by:
exor674Description: More stuff to fix more tests. There are three things of note done in this one, but they're all pretty subtle.
1) Some of the various other back-end upgrades made it possible to remove a thing called 'webreq.t', so
exor674 got out the code-machete; this one's invisible to most users. 2) When building an Atom feed of a journal or community, the author of the entry is now shown in proper format. This is very good! And now the test is changed to go along with it. The previous change will be noticed by people looking at atom feeds; this test change will be invisible to most users.
3) There's a tool called the usermover, which ... moves users! People who are familiar with LiveJournal database architecture will possibly recall how users there are on different database clusters, and may even remember their favorite or least favorite clusters. (They used to have South Park characters; now they have meat and meat-substitutes.) We have clusters too; ours are named after stars right now. Organizing the user-holding databases into clusters makes it so no matter how many users we get, the databases holding user data are always small enough for our servers to handle. Have an analogy: imagine handing eight grocery bags to eight bouncing kids, so the kids can carry the bags into the kitchen. Unless the kid with the bag with the eggs trips over something, you're probably good. Now imagine attempting to carry all eight grocery bags yourself. Some of you will be able to do it just fine, but depending on the size and weight of the grocery bags and your particular ability level, you may not actually be able to do this in one trip, or at all, or not this week. [Code tour pauses for a half-hour field trip to wikipedia.] ... Right, so we use clusters, and the usermover is a tool that can move users between clusters, in a way similar to how when too many heavy cans have been stuffed in one bag, you can take some out and put them in another bag, so whoever's carrying it will have an easier time. Now, the blobcache. In database terms, "BLOB" stands for "Binary Large OBject", because database designers actually do have a sense of humor. This is big chunks of stuff that don't fit into smaller data types. [Insert comparison between smallish grocery sacks and those great big blue IKEA bags here.] We use the blobcache table for keeping track of big chunks of arbitrary data, like logs of database migrations and so forth. Because of the way the blobcache table was labeled, the usermover started to get worried about it. (If you like, have a mental image of a kid hauling grocery bags, where one of the grocery bags is labeled that it should belong both in the kitchen and in the garage.) This part of the patch tells the usermover to chill out about the blobcache table. This one is invisible to most users.
And that's it for another week!
no subject
It's hot here.
no subject
also Bug 3539: yay! I'm glad that's fixed!
no subject
Smelling.. Bug 3564, it's resolved yay!
no subject
Bug 3135 makes me wonder how I get to see $timespan since entry at all, because it would be quite useful but I don't see it when I hover over anything here, for instance. Is it only in some styles?
no subject
no subject
no subject