[19:38:47] o/ mdholloway do you use a GUI diff program with git? i'm using meld because i love GUIs and it's open source but i didn't know if you knew of something better (here's how i have it configured https://github.com/niedzielski/dotfiles/blob/master/home/stephen/.gitconfig#L55 and #L70) [19:39:29] niedzielski: i don't, but i'll check it out! [19:40:37] mdholloway: i find it invaluable. like, i have to view a diff through several different lenses (command line, GUI, and then the web interface) before i really feel good about a patch [19:40:54] mdholloway: anyway, if you come across something better than meld, please shoot me a note! [19:42:11] niedzielski: will do! i'll do some looking around and check out meld for sure. sometimes i find myself pushing to gerrit just to get a better look at a big patch than i can from the command line, but better to do it locally [19:43:14] mdholloway: i do the same thing but having a third has been really helpful for me, especially in personal repos that i don't want to do the diligence of a full blown pull request [22:47:46] niedzielski: sorry for the runaround on that news testing patch. of course you're right that testing prod isn't useful at all, at least for dev purposes. one question i should have asked up front: any reason you need to test against a specific historical date? [22:48:06] would just testing against the current results of /page/news work as well? [22:48:27] mdholloway: np thanks for the help! some of the restbase stuff is still foreign to me [22:49:02] mdholloway: i was hoping to fix the test to a specific date since always using the latest might be a bit flaky (for example, a really newsworthy day) [22:49:59] mdholloway: i can try using today's date and we can see how it does tho [22:50:09] niedzielski: yeah, that makes sense. (i was thinking of changing that one flaky most-read test to yesterday for that reason.) [22:50:50] niedzielski: another option is to get known should-be-good content and save it as a json file and keep the test fully local; we do that in a couple of other spots. [22:51:50] mdholloway: that seems ideal to me but i wasn't sure how to feed it through the entire system (T151091) [22:51:50] T151091: Convert one test to use mocked data - https://phabricator.wikimedia.org/T151091 [22:52:46] * mdholloway digs for a good existing example [22:57:40] niedzielski: for some reason I thought we had more of that going on in the content service; i guess i had it confused because we've been doing more of it in the app! I guess we don't have any great examples but the most we're doing now with static files is in /test/features/most-read/page-filtering.js [22:59:42] niedzielski: i've actually found that, at least for this service, the setup makes it very easy to test in a sort of black-box fashion (i.e., the right stuff comes out when you hit URL X) [23:00:05] inputs and outputs, in other words. but actually not quite as easy to test what goes on in between [23:00:51] mdholloway: thanks, i'll give it a shot [23:03:14] niedzielski: cool. one thing you'll probably find useful if you don't know it already is the RESTBase endpoint for getting a page's parsoid HTML: https://{lang}.wikipedia.org/api/rest_v1/page/html/{title} [23:04:11] mdholloway: thanks, that was useful. i used it for all the selector changes [23:27:10] niedzielski: any issues with me +2ing https://gerrit.wikimedia.org/r/#/c/324007/ ? [23:27:47] jdlrobson: (peeking now) [23:29:38] jdlrobson: it still seems weird to me to specify eslint-config-node-services as a dependency, add a .eslint config, and not specify eslint itself as a devDependencies but it's probably ok [23:29:50] jdlrobson: no other objections! :] [23:30:27] :) [23:30:31] that will be fixed soon niedzielski [23:30:56] jdlrobson: okok :] [23:31:42] mobile-sections-lead en San Francisco should have a lead object with a geo property: 23:28:02 HTTPError: 504: internal_http_error [23:31:57] yeyyaaa... gateway time out [23:32:02] what did we break ? :)