#hypothes.is

<robertknight> nick: So, a bit more progress on Via. I have a variant at http://via.robertknight.me.uk/ (currently hosting a Docker container from https://github.com/hypothesis/via/tree/replace-... ) which replaces Wombat with a minimal rewriter that turns `document.cookie` into a stub and disables password fields in forms. This is actually usable on some of the more crap-laden news sites under Edge that http://climatefeed.org|clim

links to, unlike Via. Profiling the JS shows that the client-site rewriting is pretty expensive.

<robertknight> I also did some research wrt. your question about whether rewriting links was actually necessary, or whether a `base` tag would suffice.

<robertknight> These are stats on proportions of absolute, relative and same-host-as-the-page absolute links on the 200 most recently annotated URLs: https://docs.google.com/a/hypothes.is/spreadshe...

<robertknight> It looks like absolute URLs pointing to the same host (or even page) are very common and in cases I think we would want to support - like navigating between chapters of an online book.

<robertknight> https://github.com/robertknight/via-tests (analysis tools)

<robertknight> (Thanks for the intro to the `gb` tool btw. So much better than screwing around with `$GOPATH`)

<nick> I'll be there in 2m!

<seanh> robertknight: nick So `isSidebar` is passed into the annotation directive on `$scope`. The directive's link function then saves that on the controller as `ctrl.isSidebar` and that's what the templates access. Is there any point in doing this? The templates can simply access `isSidebar` from the scope. It might be kind of nice if everything the templates access is `vm.*` and they never access other top-level things in scope. But apart from that I ca

reason for it

<nick> @seanh: the main reason to expose things only on the controller rather than the scope is that the scope is prototypally inherity

<robertknight> seanh: There is an advantage to accessing everything on 'vm' or an isolate scope in that you can 1) re-use a component in another place and 2) easily see where data used in the component comes from. For components near the top of the tree that are inherently more app-specific, this is less important.

<nick> > easily see where data used in the component comes from

<nick> this

<seanh> Ok, I'll continue with copying it onto the controller then. I'll just do it once when the controller is instantiated, instead of in a `$observe()` over the scope

<seanh> Oh wait

<seanh> "There is an advantage to accessing everything on 'vm' _or an isolate scope_"

<seanh> It's already an isolate scope

<nick> at which point it's a question of consistency

<seanh> Yes I said `$scope` sorry I meant the directive's isolate scope

<nick> there's only one way of getting parameters into a directive

<nick> and that's on the scope

<nick> but there's all kinds of internal state that you might want to expose to a template

<nick> so if your template is reading from scope it then ends up reading from both scope and the controller (AKA viewmodel)

<nick> if you want to be clear and consistent then I think it's a good habit to get into for the template (at least in larger directives) to only interact with the controller instance

<robertknight> seanh: In Angular 1.3+, there is a facility to automatically connect the two - http://blog.thoughtram.io/angularjs/2015/01/02/...

<nick> :+1:

<nick> @wyan: how are you getting on with the sqlalchemy? It's very different from ActiveRecord (or at least was when I last used AR, which was... a while ago) but I hope you will come to love it. It's one of my all-time favourite pieces of software. :)

<wyan> :)

<wyan> it got me a bit by surprise to have to write an `.all` method by hand, but getting on with it :)

<wyan> I'm basically following the other bits as a reference (badges in particular seems to be kind of similar)

<seanh> robertknight: Ok, take a look at https://github.com/hypothesis/h/pull/2761 when you're ready

<nick> @wyan: does `.query.all()` not do what you want?

<wyan> er… now that I think of it that's all the `.all()` method does :)

hypothesis/h#9199 (2728-refactor-annotation-controller - 3d3e30b : Sean Hammond): The build was fixed.

Change view : https://github.com/hypothesis/h/compare/b34415b...

Build details : https://travis-ci.org/hypothesis/h/builds/94614511

<nick> Heh, ok.

<nick> I think for simple stuff it's totally ok to treat the `query` property as public API.

<nick> of course, if it's getting complicated, then it's worth wrapping that up in a method on the model class...

<wyan> is there an equivalent to `rails console` to play around with objects on a REPL?

<nick> yep

<nick> `pshell conf/development.ini`

<wyan> cool, thanks!

<wyan> that's my next bit, getting familiarised with how to access the columns so that I can display them

<nick> that should, I think, be reasonably familiar to you

<nick> model instances just have properties which expose the column values

<nick> `group.creator`, `group.name`, etc.

<wyan> oh cool!

<wyan> do properties get handled by accessors behind the curtains? or are they more like just plain variables?

<nick> yep, they're dynamic attributes and can do lazy loading, etc.

<nick> `foo.password = "wibble"` can hash the password, and so on.

<wyan> cool!

<nick> they're also kind of magical because they're defined as class attributes

<wyan> I should probably be grabbing a python book to get up to date with these things :)

<nick> and sometimes get used as class attributes

hypothesis/h#9202 (2728-refactor-annotation-controller - 712c9aa : Sean Hammond): The build was fixed.

Change view : https://github.com/hypothesis/h/compare/3d3e30b...

Build details : https://travis-ci.org/hypothesis/h/builds/94614667

<nick> like `session.query.filter(Group.name == 'foo')`

<nick> but then they can also be used as method attributes like `group.name`

<nick> and you can even write your own so-called "hybrid attributes" that do similar things: http://docs.sqlalchemy.org/en/latest/orm/extens...

<nick> but that's pretty dark magic and hopefully for most day-to-day uses of sqlalchemy you won't need to worry about all that

<seanh> Trying to find out if there's a good way for `AnnotationController` to register a function to be called when the user logs in

<robertknight> seanh: A USER_CHANGED event is broadcast when that happens, and you have access to that in the link function, so one option would be to listen for that event (in the link function) and call some method on the controller in response.

<seanh> Ah, the `USER_CHANGED` event

<seanh> Yes :)

<seanh> It's already used in `AnnotationController`, in fact

<seanh> What confused me is that the line of code that saves highlights on login is not in the `USER_CHANGED` event function, rather it's in a `$scope.$watch()` of `AnnotationController`'s own private `model` object.

<seanh> It looks like on `USER_CHANGED` `AnnotationController` sets `model.user`, which triggers a watch on `model.user` which saves any highlights!

<seanh> It actually seems to have access to `USER_CHANGED` in the controller, via `$scope`

<robertknight> So, ignoring any technical issues, what is the user-facing effect of the changes you're thinking of?

<robertknight> As far as highlights are concerned

<seanh> No user-facing changes

<seanh> I may make a github issue with screencasts, pointing out how completely borked out behaviour is with respect to creating annotations, replies and highlights while logged out

<seanh> But I won't try to fix it yet as I don't know what to fix it to

<seanh> I'm just trying to make the code that implements the current behaviour less insane

<seanh> To a large extent what's gone in `AnnotationController` seems to have been an event-based approach to programming

<seanh> For example, someone wanted to implement auto saving of highlights on login

<seanh> How could they do that?

<seanh> Well, on login, `model.user` changes, so just put a `$watch()` on model and put the save on login code in there

<seanh> I've found lots of these - bits of code in watch and observe functions etc that don't need to be

<seanh> Oh man, it's _really_ difficult to make changes around highlights to `AnnotationController`. Whether or not a given annotation is a highlight if fuzzy. There is `vm.isHighlight()` which says it's a highlight if it's not a reply and it has not text or tags. But that returns `true` for new annotations as well (before the user has had time to enter anything). Then there is `model.$highlight` which is true the first time an `AnnotationController` is i

for a new highlight, but not when one is initialized for an existing highlight retrieved from the server. When initializing an `AnnotationController` we want to automatically save the annotation to the server if it's a new highlight and the user is logged in. We also want to open the annotation editor if it's a new annotation (not a highlight) or an existing annotation (not a highlight) that was being edited (before the user eg moved to a different group,

back).

<seanh> Of course, you can also edit highlights, and either enter some text or not and then move to another group or not

<seanh> It's really sort of impossible to say whether something is a highlight or is an annotation, n

<seanh> under all circumstances

<seanh> And yet the way our UI is designed, it demands different behaviour in many places for highlights and annotations

<seanh> Hmm, maybe fixing `isHighlight()` to try and make it always give the "right" answer will help

hypothesis/h#9204 (2728-refactor-highlight-saving - fb2a1e0 : Sean Hammond): The build failed.

Change view : https://github.com/hypothesis/h/commit/fb2a1e0d...

Build details : https://travis-ci.org/hypothesis/h/builds/94646033

<seanh> Whew, https://github.com/hypothesis/h/pull/2762

<seanh> Off to lunch now, then I'll try to write tests for that, I didn't intend to go down this rabbit hole with the highlight saving code but I may as well finish the job now

<wyan> This is beginning to look good https://www.evernote.com/l/AEYe_GPdlLhLHpLASWcq...

<nick> @wyan: awesome! looking very good indeed

<wyan> it's being fun to learn a completely different set of frameworks ^_^

hypothesis/h#9206 (w/groups-report-in-admin-dashboard - 33a71ca : Alice Wyan): The build passed.

Change view : https://github.com/hypothesis/h/commit/33a71ca8...

Build details : https://travis-ci.org/hypothesis/h/builds/94663498

<nick> oh man

<nick> I think I've just worked out why we keep getting emails from people totally confused by the activation process

<nick> for reasons that are unknown to me (although probably Horus-related) both account activation and password resets use the same field in the database

<nick> so if you: 1) create a new account 2) ignore your activation email 3) reset your password

<nick> then you've just put your account in a state where it can never be activated

<nick> *facepalm*

<nick> we need to fix this pronto

<nick> @judell: See above ^. Are you happy that I should create a card for this and put in the current sprint?

<nick> Okay, it's time for me to head to choir, so I'll catch y'all later.

<wyan> o/

<lenazun> https://trello.com/c/q8UdNnTa/198-activation-an...

<nick> Thank you so much @lenazun!

<nick> I have no idea how we'd survive without you corralling us :)

<lenazun> pretty sure you’d be just fine, but with less emojis in your lives