#hypothes.is

<chdorner> @nick: I see you already switched over redis. anything I can help?

<nick> was just about to leave a note here

<nick> ``` $ sudo lsof -itcp:6379 -nP COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME redis-ser 7804 redis 4u IPv4 3514471 0t0 TCP *:6379 (LISTEN) ```

<nick> ^^ that's on the old db server

<nick> no more connections there

<nick> so, I threw away the machine

<nick> brought up a new one

<nick> fixed a couple of silly manual steps in the machine provisioning process while I was there

<nick> (you no longer need to add the ansible user manually, or partition EBS volumes manually)

<chdorner> but the old db machine is still running right? for nsq

<nick> yes

<nick> I threw away the db-new machine

<nick> and reprovisioned it

<chdorner> ah, right. sure

<nick> fixed a couple of bugs in the redis role

<nick> so that one is done

<nick> as you can see I had to restart all the services that talk to redis, because switching DNS over wasn't enough -- they hold open persistent connections

<nick> so, I'm about to go and have a shower and then take Django for a walk

<nick> if you want to switch over NSQ and/or MySQL, that would be awesome

<chdorner> will do

<chdorner> how do I make wordpress restart?

<chdorner> for the DNS change to have any effect

<chdorner> do we have a ansible deployment playbook for it?

<nick> yep!

<nick> just `ansible-playbook -i hosts wordpress.yml` and accept the default docker image tag

<nick> Right, I'm off for a bit. I'll miss the catch-up meeting today and will be back online after midday.

<wyan> Morning humans!

<sheetaluk> Good morning @wyan !

<nick> ^ this is looking awesome @robertknight

<robertknight> @nick: Thanks. I'm just in the process of putting up a 'discussion' PR as @seanh suggested yesterday so we can discuss the design/direction etc.

<nick> so much awful code being deleted :)

<robertknight> Now I understand the old threading implementation, I don't think it is necessarily awful - I might have done something similar a few years ago, but I do think a more modern architecture will offer a lot of advantages.

<nick> No, I'm afraid the deepCount directive was objectively awful.

<nick> ;)

<nick> (And I don't think there's anything wrong with the jwz threading algorithm -- I'm assuming you've preserved most of that in the reimplementation?)

<robertknight> A simplified version, based on my understanding of what we need - and that's something I need to check assumptions about.

<robertknight> Specifically, I'm assuming that we can rely on annotations having IDs and having an array of IDs of their parents, ordered from furthest to nearest ancestor. Some of the parent IDs might not exist, in which case the nearest-available ancestor is used. The part of jwz I haven't implemented is anything related to mail message subjects, since annotations don't have subjects or an equivalent.

<chdorner> ^^ Trying to switch the NSQ configuration on staging to the new db instance

<chdorner> changed the hostname back to nsqd.svc... - switching back the config in staging now

<chdorner> and, for production

<robertknight> @seanh: I'm just reading through your Direct Linking email from Friday. Was it you last week who asked a question about why Bouncer was separate from the web service?

<nick> @chdorner: nsq stats are reported by nsq itself

<nick> you just need to point nsqd at the local statsd instance

<nick> -statsd-address

<nick> if you still have the old machine around you can copy the config

<nick> http://nsq.io/components/nsqd.html

<chdorner> it is: `statsd_address = "127.0.0.1:8125"`

<chdorner> and statsd is running

<chdorner> according to `ps`

<nick> how is nsqd running?

<chdorner> with the nsq role that was already in the playbooks

<nick> ah ok

<chdorner> it points at the correct config file

<nick> ok, so looks like stats aren't even making it to statsd

<chdorner> ah

<chdorner> global prefix in the statsd conf is still set to `db-new`

<nick> ah, right

<nick> yep, if you change the hostname you'll need to rerun ansible

<nick> nice

<chdorner> looks better now

<seanh> robertknight: " I'm assuming that we can rely on annotations having IDs and having an array of IDs of their parents, ordered from furthest to nearest ancestor" <- I _think_ you probably can rely on that

<seanh> robertknight: Someone asked me last week why bouncer was a separate service as well (I don't think I asked the question myself). But I've been wondering about it. I don't remember the reason, and I have to say I find myself questioning whether it's a good thing

<seanh> Of course developers like to build things in separate pieces. Clean slate. Keep everything nice and simple and separated. There's something to be said for that

<seanh> _But_ I think bouncer might actually be simpler and more capable if it were part of the main h app

<seanh> Excited to hear out that threading code getting a refactor by the way

<robertknight> seanh: I'm specifically thinking about providing good metadata for H pages for use in search results and social platforms that support OpenGraph or Twitter metadata.

<robertknight> and making that consistent between the Bouncer URL and the standalone HTML page for annotations

<seanh> You're thinking about adding metadata to the http://hyp.is|hyp.is pages you mean?

<seanh> Right

<nick> we could do that by improving the API and making bouncer use an API call rather than integrating on the database

<nick> which is the long-term goal

<nick> I don't think everything needs to be part of one monolithic application

<seanh> Yeah, a lot of the problems currently caused by bouncer being a separate service have to do with it reading Es directly. If it read the API, then h could stick stuff in those API responses for it (we would need a better API before we could do that..)

<seanh> There'd still be some template duplication though

<nick> which would have the advantage that then our API would be more useful for other people, too :)

<nick> I think bouncer does a pretty good job right now

<nick> and we'll continue to work out what the best approach is as we gather new requirements and agree to build them

<nick> given the original design for bouncer, I'm pretty happy with the approach we took

<robertknight> For reference, Conor has put together a spec for what the ideal display of a http://hyp.is|hyp.is link on FB, Slack etc. should look like

<robertknight> That uses a mix of OpenGraph data from the annotated page, plus metadata from the annotation itself

<nick> great :)

<robertknight> https://trello.com/c/QhQxef6M/474-improve-the-d...

<robertknight> It sounds like there is a bunch of work that needs to be done to enable that - worth discussing this afternoon?

<nick> yep, definitely

<nick> would you mind adding a section to the document I've just sent round?

<robertknight> Will do

<chdorner> the old db server is now successfully migrated to a new one in our vpc having some lunch now and then after will have a look at @wyan's playbook PR and then after that continue with setting up squid

Hey guys, It's Oli from WorldBrain. I just tested your direct linking feature and it is working great, very nice! Finally no interceptor screen for the annotation anymore!

Also feels very nice to use!

<robertknight> CaptainFiuture: Thanks for testing it Oli

<nick> Awesome. Glad you like it CaptainFiuture :)

<nick> ok, this is bizarre

<nick> `confirm()` and `alert()` are both broken in Chrome for me

<nick> on all pages

<nick> (but not in Incognito mode)

<lenazun> huh!

<lenazun> did you ever check that thingie saying prevent this page from creating additional dialogs?

<nick> I wondered that, but I'm pretty sure that's only supposed to persist for a session

<nick> okay, so I've disabled all extensions and restarted chrome and that appears to fi it

<nick> now to work out which one is the culprit

<nick> aaaaaand the winner is... https://vimium.github.io/

<wyan> I can't think of a decent vim vs emacs joke right now

<seanh> I can't believe you are not simply using Surf http://surf.suckless.org/

<wyan> ooooh, that sounds emacs-embeddable

<nick> and a pizza place!

<nick> @robertknight: PR moving templates out of `app.html` looks great

<nick> my only question is why we're defining the transform in code rather than in `package.json` alongside all other browserify transforms

<wyan> is our next meeting in 30min or in 1h30?

<nick> 22m :)

<wyan> ok – can't find this one on the calendar!

<nick> which is the direct linking planning meeting

<wyan> hence my confusion

<nick> @lenazun I'm guessing everyone is coming to this one?

<nick> maybe @lenazun thought that not everyone would want to attend?

<wyan> ¯\_(ツ)_/¯