<nick> so, @chdorner, the notification worker issue is unfortunate but probably not urgent, as Icinga will let us know if it happens again
<nick> details are in an email I sent to sr@ yesterday
<nick> if you want to go ahead with moving the database server into the VPC, that would be great
<seanh> Quick comment about the check-in hangout. This has been on my mind for a while: the hangout is called "standup" but iirc that's just because robertknight couldn't think of another name for it. It wasn't actually meant to be a standup as such, at least originally (and if we decided to turn it into one I must have missed that decision). It's cool to go round everyone in turn and make sure everyone gets a chance to say something if they want to. But I
concerned that it's turning into a de-facto standup which makes it not useful for what (iirc) we originally hoped it would be good for - which iirc was a chance for devs to say hi to each other in the morning and chat for a few minutes about random stuff in a better-than-text medium, both work and non-work (Plus we have #standup, so often the last thing I do at the end of the day is post what I just did and what I'm going to do next in #standup, then the f
do at the start of the next day is repeat the same information in Hangoutt..)
<nick> perhaps you and @wyan could sync up on that, and you could bring up a "support" box at the same time for us to run various things on (Slack-IRC mirror, deployer, etc.)?
<seanh> Anyways, I'm off for physio, just throwing that out there!
<nick> @seanh: I'm not sure how I feel about that.
<robertknight> seanh: You didn't miss any decision, the format of the morning, ah. check in has just evolved some structure. The current de-facto format works for me, but I'd like to hear other people's opinions
<nick> A "catch-up" sounds like a great way for noisy people (like me) to end up talking all the time, while other people feel obliged to sit on a call they don't get anything out of.
<nick> Whereas a standup at least serves a concrete purpose -- to identify and resolve blockers -- and ensures everyone has a voice.
<seanh> My opinion: I think more structure in that we go around person in turn now is probably good (dev team is way bigger now than when we started this hangout), but I think people have "automatically" fallen into giving standup-like reports and people have even started redirecting any non-standup talk to Slack, that to me is a little disappointing / I'm wondering what the point is a little bit. Just wanted to get everyone's thoughts on it anyway
<seanh> nick: I guess the thing is we have #standup, and when we originally discussed the need for a morning Hangout I (at least) specifically wanted a watercooler-like place where we could shoot the shit and not be kept on format or on topic. Currently every face-to-face Hangout we have is kept to format and topic, and rightly so because they all have specific aims. But I kind of wanted one that was not so specific and more about just improving dev team re
watercooler chat, fighting the remote working effect. "Everyone has a voice" <- totally hear this though
<seanh> Anyways, gotta run!
<wyan> I much prefer watercooler chat to be on slack, since I'm really bad at unstructured verbal conversation… maybe we need a #watercooler channel :)
<wyan> some hangouts conversation is nice, though, otherwise it can feel isolating
<conor> Loosening up the standup a little works for me. I’m not sure anyone is massively interested in what I have to say everyday anyway.
<nick> @conor: if you could maybe use your allotted time tomorrow to explain that image...
<conor> A terrifying image of “remote work"
<nick> lol
<robertknight> Quick thought - if several us of are going through the PR queue at the same time, it might be helpful if people could assign PRs to themselves when they start reviewing, to avoid a case that happened a couple of weeks back where one person merged the PR whilst someone else was still testing it.
<wyan> that sounds like a good idea – also perhaps marking PRs somehow (with some sort of WIP vs ready-to-merge signaling) so that it's easy to see which ones are ready to be reviewed – sometimes I'm not sure whether I should be reviewing a given one, and it's relatively easy to miss things in slack sometimes
<robertknight> @wyan: People are already using the `WIP` label for that I thought?
<robertknight> If something doesn't have the WIP label, I'm assuming it is ready to merge
<wyan> oh! I hadn't noticed the `WIP` label
<wyan> would a `t2.small` be enough for the `support` box?
<nick> I'd probably go with a `t2.medium`, mainly for the extra couple gigs of RAM
<nick> are you and @chdorner coordinating on this?
<wyan> pinging him
<chdorner> @nick: so we're going to have two new boxes then? `support` and `db`, and we use `db` for squid and redis, and the `support` for the deployer, and other stuff?
<sheetaluk> Hey guys, in `/h/h/groups/views.py` what do we mean when we talk about slugs?
<chdorner> @sheetaluk: check `/h/h/groups/models.py`, looks like we're using the `slugify` package for generating slugs from group names
<chdorner> I presume to put into the URL
<chdorner> so when you create a group with the name "Test Group" it will get the slug "test-group" and that one is used in the url: `https://hypothes.is/groups/xxxxxxx/test-group`
<sheetaluk> thanks @chdorner
<nick> @chdorner: yes
<nick> `db` → private subnet, `support` → public subnet with elastic IP
<chdorner> @wyan: ^^
<wyan> :+1:
<nick> and `db` can probably also be a smaller box than it currently is
<nick> i'll let you make a call on `t2.medium` or `t2.large`
<chdorner> @nick: what's the impact squid has on IO/CPU/RAM? I've never used it before
<wyan> any preferences on availability zones a vs b?
<nick> @wyan: whichever we have less stuff in currently :)
<nick> @chdorner: it's mainly CPU and network bound for us, as we're not using it as a cache but as a proxy
<nick> it currently runs on `http://web.int|web.int`, which IIRC is a compute-heavy machine, but I'm not sure how much load we actually generate at the moment
<wyan> guessing on the `hop-prod` VPC?
<chdorner> think so, yes @wyan
<wyan> where are we storing the key pairs?
<nick> @wyan, @chdorner: you're using ansible to bring up the machines, right?
<chdorner> I haven't started yet, but yes that's what I've had in mind
<chdorner> in the `machines.yml`
<nick> right
<robertknight> @chdorner: I added some comments on the CSP PRs. Let me know if you want to work on them or if you'd like either me or Sheetal to finish them off. The basic approach taken is fine.
<nick> in which case you won't need to worry about keypairs, @wyan. You'll use the `null` named keypair (for which the secret half has been discarded) and the ssh-key will be set by cloud-init
<wyan> oh ok
<chdorner> @robertknight: thanks, I will have a look at them a bit later today. There isn't really any rush to get these issues fixed, so it's better if you both are free to work on DL
<sheetaluk> Could somebody help me please? When I run make test, this is what I see:
<sheetaluk> Any idea what I've done? I'm on master, and stashed all my changes.
<sheetaluk> @nick: ^ Have you seen this before?
<nick> @sheetaluk: no, but that looks somehow like pip is missing from the tox virtualenv?
<nick> try blowing away `.tox` and rerunning?
<sheetaluk> ok
<sheetaluk> Ok.. that seemed to work, thank you
<sheetaluk> Also, how can I run a subset of tests, say h/groups/test/views_test.py
<nick> @sheetaluk: run `pip install factory-boy mock pytest` once in your dev env
<nick> then run `py.test h/groups/test/views_test.py`
<chdorner> or just `tox h/groups/test/views_test.py` that works as well (although you don't get all the speed benefit that you would get from Nick's solution)
<sheetaluk> thank you!
<nick> oh, right, yes
<nick> @chdorner's solution is probably actually better in the long run
<sheetaluk> thank you so much
<robertknight> @nick: Got a few moments for a couple of queries about Annotator and ranges?
<nick> @robertknight: ask away and I'll answer if I can :)
<robertknight> @nick: So @sheetaluk has been looking into showing the adder when activating H when there is a selection. The first approach she mentioned was using Range.getClientRects(), however that can apparently end up including content outside the visible text selection, eg: https://trello-attachments.s3.amazonaws.com/56c...
<robertknight> Looking at `guest.coffee` I see that when actually creating a highlight, the range is fed through a bunch of Annotator-provided functions to "normalize" the range.
<robertknight> Is this kind of task, filtering out non-text nodes from around a selection, something that Annotator already has code for that could be re-used?
<robertknight> When the 'Adder' is shown whilst H is already active, this isn't an issue because the adder can just be shown at a coordinate based on the mouse up event position.
<nick> why is `getBoundingClientRect` wrong?
<nick> I'm trying to understand the problem before I can work out if the solution you're proposing is the right one
<robertknight> I have not actually tested the PR yet - just about to start looking into that. I just wondered if any of the issues mentioned on the Trello card or PR sounded familiar.
<nick> right, but it says "Sometimes the bounding box includes non-text nodes"
<nick> which is not what that screenshot looks like
<nick> the screenshot makes it look like the margin is screwing things up
<nick> perhaps you could find out what the actual problem is?
<sheetaluk> @nick: @robertknight I was trying to position the adder consistently. The card initially said that we should place it at the end of the text selection
<sheetaluk> But that ended up including non-text selected areas, so I tried boundingBox. But it doesnt consistently show up like the medium adder does at a certain position. If there is xtra margin/non-text nodes the bounding box includes those nodes as well
<nick> what do you mean by boundingBox?
<robertknight> So from a user's point of view, the behavior we're after here is that the adder appears above the focus point of the selection (ie. where the user released the mouse)?
<nick> @chdorner: where did the CSP report URI come from? did you create your own account or did you use the one attached to mailto:sr@hypothes.is|sr@hypothes.is?
<nick> ah, right -- that's why I was looking at it
<nick> I didn't notice you'd already done that
<sheetaluk> @robertknight: yeah. above the text selection
<chdorner> @nick: I was fast :)
<robertknight> @sheetaluk: In that case, the approach that initially comes to mind is creating an empty Range whose start position is the `focusNode` and `focusOffset` of the selection and use `getBoundingClientRect()` on that.
<robertknight> I've not made any changes yet to the code that deals with ranges and selections, so I'm just making an educated guess here based on a cursory reading of the API docs.
<sheetaluk> @robertknight: let me try that. Do you know though if a focus node can be any node without visible text selection too?
<sheetaluk> I can try it
<robertknight> @sheetaluk: I don't know the answer to that I'm afraid.
<sheetaluk> ok. let me try that. Because if it isnt then we'll have the same problem
<robertknight> I'm out for the next couple of hours, but I've looked through all of the direct linking PRs open thus far and tagged them with the "Direct Linking" label. I'm probably going to look into direct links to replies or the http://Medium.com|Medium.com issue this afternoon, but as noted this morning, merging existing work takes priority so do feel free to poke me if there are updates on any of the PRs I've already looked at.
M-Ibrahim joined the channel
vannevar has quit
vannevar joined the channel
<robertknight> @seanh: Do you know if there is any support for, or need to support, replies to annotations having their own targets?
<robertknight> (Context - I'm currently looking into handling of direct links to replies)
<wyan> @nick: where do we keep `hypothes.is.` DNS root zone?
<nick> @wyan: do you mean where are our nameservers?
<wyan> @nick: yep… route53 doesn't seem to have it
<nick> @chdorner: only if all the relevant services are up and running and have data in them
<nick> @chdorner: and then tbh it should be, yes
<chdorner> right, will name it db-new in the meantime then
<seanh> There's also a fourth one but I've marked it as wip because its history is a bit of a mess as a result of extracting it out from the original one big pr, might be easier to merge the other three first https://github.com/hypothesis/h/pull/3153
<seanh> robertknight: I don't think replies need to have targets, no
<chdorner> @seanh: looking good. will start reviewing the PG pull requests tomorrow morning
<nick> @chdorner: just be aware that there are at least two `http://svc.hypothes.is|svc.hypothes.is` zones
<nick> oh, actually
<nick> sorry
<nick> you were asking about `http://db.int|db.int`
<nick> I'm about 90% sure that's safe, yes
<nick> nothing in config should be referring to anything in the `http://int.hypothes.is|int.hypothes.is` zone
<nick> it should all refer to stuff in `http://svc.hypothes.is|svc.hypothes.is`
<chdorner> I'm going for 100% safe until it's up an running :)
