Office Hours: Jul 1-7, 2016

[karzilla]

Time to get this rolling again!

The medium that I've chosen for scheduling office hours is a site called Sign Up Genius. It is pretty easy to use in my experience, and all of my kids' teachers use it for conferences, parties and such. You don't have to have an account on the site to sign up for time slots, which is pretty great - just give them your email address. They will send you a confirmation and a reminder, and nothing else. But if for whatever reason you have trouble claiming a time slot using that site, you can also comment here and I can take care of it for you.

I am only doing signups for a week at a time, because that's about how far in advance I can be fairly confident of my availability. Each week will start on Friday, and I'll post the signups for the following week on Tuesday or Wednesday.

Each signup slot is scheduled to run 90 minutes, but since they're non-adjacent, it's OK if we need to go longer. Anything Dreamwidth-related is fair game: we can talk about code you're writing, code you want to write but don't know how to proceed, code someone else wrote, or things that don't involve code at all (I hear such things exist). My only request is that you don't take more than two slots in a single week, to make sure there is enough of my time to go around. Of course, you're still welcome to catch me on IRC at other times if I seem to be around, and PMs are open 24/7. :)

Here's the link for my available meeting times for the seven-day period starting July 1:

http://www.signupgenius.com/go/4090D45AEAD2DAAF94-office2

Comments

[batrachian]

pretty sure i managed to make the signup thing happen (if not, let me know).

https://github.com/dreamwidth/dw-free/issues/1233 is the bug i'm staring at the moment, with eyes towards a) how to implement it without drastically increasing server load, and b) what to implement for customization hooks so as to let people tweak the appearance how they want.

[kareila]

For (a) probably the best thing to do is just store the last access time for that viewer/page combo in memcache, and do a numeric comparison with each comment's post time when displaying. For (b), use a new CSS class and maybe some new S2 style properties?

[batrachian]

If we're storing a thing, might as well just store a bool so we don't have to do datestamp calculations (unless i'm missing something). My concern is in sizing the database structure - allocating something that's (# of site comments)*(# of site users) is, um. Nonideal, especially since under typical scenarios i think the average comment will only need to track a smallish fraction of the total userbase - practically the definition of a sparse array.

[kareila]

Which is why I suggested storing one thing per user per entry, not per comment. :)

[batrachian]

And what if the user only loaded the first page of comments? I don't see any way around storing it on a per-comment basis.

(Plus, dealing with Newly Unscreened comments going purely by datestamp would be...messy, i think - it's my understanding that the datestamp indicated when the comment was posted, not when it was unscreened). The code is already figuring out whether or not the user can see the comment - let's use that rather than duplicating effort.)

[kareila]

I can guarantee you that retrieving a single stored value per entry, then using that value to calculate whether a comment is newer than that value, will be faster and use fewer resources than storing one value per comment.

If you go back and read the feature request again, it does not imply that we should highlight any comment that the user hadn't already seen, only the comments that were newly posted since the last time the page was loaded. It is intended to highlight newness, not unread-ness. Yes, there will be edge cases with unscreened comments and such, but i think that's a necessary performance trade-off.

[batrachian]

I wasn't sure how computationally expensive the datestamp bit was (though now that I think it through, i guess it's just one simple less-than comparison, isn't it). Still not sure that it'd do the Right Thing for entries with multiple pages of comments, though. e.g:

• Comment #65 posted at 10:00 - ends up on page 2


• User loads entry at 10:05, views page 1. "newness" data updated to 10:05 after loading page.


• User clicks to page 2 of comments at 10:10. Comment #65, being older than the stored value, is not marked as new

Discussion in the -suggestions entry included commentary about including newly-unscreened comments in this spec, and I think that it's entirely reasonable to do so - if the user hasn't seen the comment because it was screened, it might as well be new to them, and not marking because they "could have" seen it may cause more confusion.

[kareila]

Those are some good points. My main concern with including unscreened comments is that I don't think we store a datestamp when a comment is unscreened, so the data simply isn't there to use. You might be able to work through the pagination problem by adding the datestamp to the page arguments, but then you'd have to discard it on a refresh...

It definitely sounds like a more detailed spec should be discussed and agreed upon before diving into the implementation.

[batrachian]

Seems like, yeah.

(this is, of course, why i wanted to talk to folks - of the bugs I grabbed before last year's OSB, the simple ones are all already done now. XD)