[02:57:13] <josephine_l>	 Hi Nicolas_Raoul and niedzielski-afk :)
[02:58:10] <Nicolas_Raoul>	 Hi!
[02:58:49] <josephine_l>	 What do you think of the results Nicolas_Raoul ?
[02:59:14] <niedzielski>	 o/
[02:59:43] <josephine_l>	 Hi niedzielski :)
[02:59:52] <niedzielski>	 hello :)
[03:00:40] <josephine_l>	 I'm wondering if I can start trying to implement the fuzzy search now?
[03:00:52] <josephine_l>	 Method A looks very promising
[03:03:34] <Nicolas_Raoul>	 I have been testing the app quite a lot, nearby categories are extremely useful! It finds at least one right category most of the time.
[03:05:04] <josephine_l>	 Nicolas_Raoul, same here :) I'm really glad we did that.
[03:05:26] <Nicolas_Raoul>	 Yes, for fuzzy search method A would be great, just like my recent "le puy" vs. "Le Puy" hardship shows.
[03:06:03] <josephine_l>	 Cool. I'll get started on method A then.
[03:06:21] <josephine_l>	 Nicolas_Raoul, niedzielski, I've been looking at how the app currently handles the category search
[03:06:49] <josephine_l>	 It uses an API call in AsyncTask that does
[03:06:51] <niedzielski>	 josephine_l: hm for the wikipedia app we do a prefix search and then a fulltext search if nothing turns up
[03:06:53] <josephine_l>	             try {
[03:06:53] <josephine_l>	                 result = api.action("query")
[03:06:53] <josephine_l>	                         .param("list", "allcategories")
[03:06:53] <josephine_l>	                         .param("acprefix", filter)
[03:06:53] <josephine_l>	                         .param("aclimit", SEARCH_CATS_LIMIT)
[03:06:54] <josephine_l>	                         .get();
[03:06:56] <josephine_l>	             } 
[03:07:22] <josephine_l>	 niedzielski, ah, this one uses a prefix search too I think :)
[03:07:36] <josephine_l>	 But I'm not sure what the best way to extend it with Method A is, especially since it's in AsyncTask
[03:07:47] <josephine_l>	 So I don't think we can get Volley working with the existing code
[03:07:59] <niedzielski>	 (checking :)
[03:08:21] <josephine_l>	 niedzielski, thanks! Line 179 of CategorizationFragment :)
[03:09:35] <niedzielski>	 hm, yeah this isn't very nice
[03:10:41] <josephine_l>	 niedzielski, haha, yeah...
[03:13:11] <niedzielski>	 josephine_l: hm i think i would just update the query that's there (currently using MWApi)
[03:13:44] <josephine_l>	 niedzielski, sorry, what do you mean by 'update'? As in, just add another call to AsyncTask?
[03:14:32] <niedzielski>	 josephine_l: no i don't think you need to make another call since that query is already in doInBackground (the background thread)
[03:16:00] <josephine_l>	 niedzielski, ah, okay. So in the doInBackground method, after doing the prefix search and going through the loop where the node values are added to 'categories'
[03:16:18] <josephine_l>	 Then I do the Method A call and add more values to 'categories'?
[03:16:42] <josephine_l>	 Or you mean replace it entirely?
[03:16:51] <josephine_l>	 Since Method A seems to work better than just prefixes?
[03:19:22] <Nicolas_Raoul>	 prefixes is useful for people who know the name of the category in advance, but is much less useful for the others, so I would not be against removing it if really necessary.
[03:19:36] <niedzielski>	 josephine_l: it might be nice to leave both in so the user has more options and just order the method A results first. the query could appear before or after the existing prefix search
[03:21:12] <josephine_l>	 niedzielski, Nicolas_Raoul, this updates as the user types right? Is it okay to have 2 consecutive API calls in that process or will it slow it down too much?
[03:22:03] <Nicolas_Raoul>	 doing both requests is best indeed if it is OK network-wise. How about starting to show the first results before waiting for both queries to complete? and then show the rest when it arrives. It could cause misclicks though.
[03:22:30] <niedzielski>	 josephine_l: you could call publishProgress() after the first query (assuming both queries appear in the same async task)
[03:22:55] <niedzielski>	 this task could use a little refactoring :)
[03:24:55] <josephine_l>	 niedzielski, Nicolas_Raoul - haha, okay. So basically put Method A calls in the same method as prefix call, but before it, and call publishProgress() in between to show results?
[03:25:19] <josephine_l>	 Hrm but I think publishProgress() can't populate the list of cat suggestions right? And yeah, it might cause misclicks
[03:25:30] <niedzielski>	 josephine_l: that's what i was thinking. i should mention that this is very cludgey :) normally these requests would be well separated
[03:26:16] <Nicolas_Raoul>	 why not launch both HTTP requests at the same time, in parallel?
[03:27:48] <niedzielski>	 josephine_l: why can't the ui be updated onProgressUpdate? onPostExecute could do an add instead of a replace on the result set
[03:28:16] <niedzielski>	 Nicolas_Raoul: that would be the best approach but that code is pretty messy
[03:28:50] <josephine_l>	 niedzielski, oh, okay! Yeah I probably just need to read up on AsyncTask more.
[03:30:38] <josephine_l>	 Nicolas_Raoul, I could try to learn how to if needed. Not sure how easy it is to do that without Volley.
[03:33:30] <josephine_l>	 Or alternatively, I could go with the consecutive method 1st, see if it works ok performance-wise, then try to refactor to parallel if needed?
[03:34:37] <Nicolas_Raoul>	 http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CountDownLatch.html seems to do the trick (rendezvous after launching several threads)
[03:38:10] <josephine_l>	 Nicolas_Raoul, is this to solve the mis-click problem?
[03:38:24] <niedzielski>	 Nicolas_Raoul: that would work. i don't normally use latches except for testing but it would probably be less cluttered
[03:39:50] <Nicolas_Raoul>	 it is to easily throw several threads and then wait for all to finish. Waiting for all to finish means no misclicks, but that also means that results only start showing after the slowest request has returned (which can be considered OK, actually, no problem).
[03:40:22] <josephine_l>	 Nicolas_Raoul, ah, okay, got it.
[03:40:47] <josephine_l>	 niedzielski, Nicolas_Raoul - to run in parallel, does the method here look okay? http://stackoverflow.com/questions/13910508/running-parallel-asynctask
[03:41:14] <niedzielski>	 josephine_l: i htink you can just use Utils.executeAsyncTask
[03:41:18] <josephine_l>	 Apparently AsyncTask works differently pre and post API 11
[03:41:37] <niedzielski>	 it covers the api differences
[03:42:06] <josephine_l>	 niedzielski, okay, thanks :)
[03:42:49] <josephine_l>	 I assume I should be adding the results to a Set instead of an ArrayList as well?
[03:43:01] <josephine_l>	 To prevent duplicates being added
[03:44:23] <niedzielski>	 that sounds fine to me
[03:44:54] <niedzielski>	 depending on the implementation, you might lose category order
[03:45:31] <josephine_l>	 niedzielski, does the order matter?
[03:45:50] <niedzielski>	 josephine_l: if prefix is giving worse results than method a, probably
[03:46:18] <Nicolas_Raoul>	 order is nice to keep if possible. Users will memorize that recent categories are at the bottom
[03:46:31] <niedzielski>	 josephine_l: i think i used LinkedHashSet in the past
[03:46:49] <josephine_l>	 Nicolas_Raoul, I could be wrong but I thought niedzielski meant just between method A and prefix? Recent cats would show up before you even type
[03:47:05] <niedzielski>	 ^ that's what i meant :)
[03:48:06] <Nicolas_Raoul>	 Ah, OK!
[03:48:40] <josephine_l>	 niedzielski, so if I used LinkedHashSet it would keep the order?
[03:48:53] <josephine_l>	 But if they are running in parallel...
[03:48:55] <Nicolas_Raoul>	 By the way, eliminating duplicates between Recent and Nearby (and pre+Fuzzy) would be a nice thing to do, as we discussed yesterday
[03:50:02] <josephine_l>	 Nicolas_Raoul, yeah. Do you think I should fix the recent/nearby duplicates now, or after we get Phase 2 implementation up?
[03:50:05] <niedzielski>	 josephine_l: LHS keeps the order http://docs.oracle.com/javase/6/docs/api/java/util/LinkedHashSet.html
[03:50:42] <niedzielski>	 josephine_l: duplicate inserts wouldn't change the order. unique inserts would be added to the tail
[03:50:51] <niedzielski>	 from the docs: "Note that insertion order is not affected if an element is re-inserted into the set."
[03:51:01] <josephine_l>	 Oh, thanks niedzielski !
[03:53:00] <josephine_l>	 Okay, so in summary I would use executeAsyncTask to run the parallel method A request, then use the CountDownLatch to ensure that both threads finish, and add the results from both threads into a LinkedHashSet
[03:56:46] <niedzielski>	 josephine_l: i think you want to add the results from method A to the UI when available as an intermediate step
[03:57:22] <josephine_l>	 niedzielski, hmm, wasn't the use of CountDownLatch intended to prevent results being shown until both threads have finished?
[03:57:46] <josephine_l>	 Otherwise the user might try to tap that and end up misclicking when the results update?
[03:58:16] <niedzielski>	 josephine_l: oh, hm. i think if you keep the order of the first result set, you won't have that misclicking problem
[03:58:30] <niedzielski>	 josephine_l: we do the same thing in the wikipedia app to provide "infinite scrolling"
[03:58:46] <josephine_l>	 niedzielski, oh, okay. Do we still need CountDownLatch in that case?
[03:59:58] <niedzielski>	 josephine_l: er, i guess not if you don't need the results of the database query already in doInBackground()
[04:02:04] <josephine_l>	 niedzielski, hm, also this assumes that Method A would finish faster than prefix right? Sorry, bit confused :)
[04:03:54] <niedzielski>	 josephine_l: i propose you wait for the results of method A but not the prefix search, even if prefix comes in sooner. that way you get the most relevant results first without the UI changing order.so the method A tasks updates the ui as soon as it returns, the prefix task waits until method A is done
[04:04:13] <niedzielski>	 josephine_l: and that waiting might be the count down latch
[04:05:05] <josephine_l>	 niedzielski, ah, okay! So onProgressUpdate() for Method A thread only, and CountDownLatch for prefix thread only?
[04:06:36] <niedzielski>	 josephine_l: i don't think we'll need the onprogressupdate after all since method a will now be in a separate task :) just use onPostExecute. using the CDL to wait on method A sounds right since you can't show those results until method A comes back
[04:07:16] <josephine_l>	 niedzielski, oh, gotcha, thanks! :)
[04:09:46] <josephine_l>	 niedzielski, Nicolas_Raoul - okay, I'll read up more on AsyncTask (I'm not really familiar with it yet unfortunately) and try to get the outline up asap. I'll resolve the 'look for API' and 'test API' tasks since we have decided on an API yeah?
[04:12:11] <niedzielski>	 josephine_l: that sounds good to me
[04:13:10] <josephine_l>	 Thanks niedzielski :) Anything you or Nicolas_Raoul would like to add?
[04:14:20] <niedzielski>	 josephine_l: nothing on my end :)
[04:20:20] <josephine_l>	 Okay, I'll head off for a bit then :) Bye niedzielski !
[04:20:30] <niedzielski>	 josephine_l: seeya! :)
[09:31:53] <phuedx>	 hullo
[09:32:11] <phuedx>	 g'mornafterevening
[09:33:10] <joakino>	 morning phuedx 
[09:36:07] <phuedx>	 o/
[10:04:32] <barbarar>	 Hi everybody, good morning from Berlin. I'm putting a time today to wikipedia iOS app, I was able to compile and run the project. bgerstle_afk when you are free we could chat about my contributions expectations.... for the moment I will go through the project code, checking the coding standard is applied, just to get familiarized with the code
[10:09:12] <joakino>	 barbarar: iOS folks will come online in a few hours, bgerstle_afk is in EST I think
[10:09:18] <joakino>	 barbarar: thanks for taking the time! :D
[10:09:40] <barbarar>	 cool, thanks joakino
[10:13:50] <barbarar>	 is there any open source UML tool that WMF uses to document?
[10:20:23] <joakino>	 not that I know of (I don't know much though)
[10:29:35] <barbarar>	 oki, thanks, I was looking for some open source ... I used ArgoUML but it was some years ago
[16:16:02] <dbrant>	 niedzielski: mdholloway|afk: quick huddle in batcave?
[16:16:17] <niedzielski>	 dbrant: sure, omw
[16:16:29] <mdholloway>	 on my way
[16:35:39] <FlorianSW_>	 phuedx: https://gerrit.wikimedia.org/r/#/c/264947/ if you fix the composer errors, I'm happy to test and merge :D
[16:41:12] <phuedx>	 FlorianSW: see ps2
[16:41:33] <FlorianSW>	 phuedx: hehe :) I'll take a look :)
[16:51:46] <phuedx>	 thanks for your review FlorianSW 
[16:52:13] <FlorianSW>	 np, I'll fix DerivativeContext now, assuming that it needs to be fixed :P
[17:30:48] <joakino>	 dr0ptp4kt: bd808: what happened at kickoff with last sprint? it's full of cards in progress. should we move them to current sprint?
[17:39:18] <mhurd>	 jgirault:
[17:39:18] <mhurd>	 https://en.m.wikipedia.org/w/api.php?action=query&continue=&exchars=525&exintro=1&exlimit=24&explaintext=&format=json&pilimit=24&piprop=thumbnail&pithumbsize=640&prop=extracts%7Cpageterms%7Cpageimages&titles=Bruce%20Kingsbury%7CMartin%20Luther%20King%2C%20Jr.%7CGlenn%20Frey%7CMartin%20Luther%20King%2C%20Jr.%20Day%7CThe%20Revenant%20%282015%20film%29%7CUFC%20
[17:39:18] <mhurd>	 Fight%20Night%3A%20Dillashaw%20vs.%20Cruz%7CDavid%20Bowie%7CSteven%20Avery%7CDirty%20Deeds%20Done%20Dirt%20Cheap%20%28song%29%7CBernie%20Sanders%7CStar%20Wars%3A%20The%20Force%20Awakens%7CBlue%20Monday%20%28date%29%7CJava%20%28programming%20language%29%7CMaking%20a%20Murderer%7CPeyton%20Manning%7CAlan%20Rickman%7CDominick%20Cruz%7CSean%20Penn%7CAdam%20Driver
[17:39:18] <mhurd>	 %7CDeaths%20in%202016%7CHugh%20Glass%7CList%20of%20Super%20Bowl%20champions%7CEagles%20%28band%29%7CAngie%20Tribeca&wbptterms=description
[17:40:29] <mhurd>	 jgirault: https://gist.github.com/montehurd/f57d05c30db416fca637
[17:44:12] <mhurd>	 jgirault: ^ i updated it with some comments
[17:44:29] <jgirault>	 mhurd: awesome o/
[17:51:36] <joakino>	 spaam
[17:51:51] <bd808>	 joakino: I think we moved the card forward that people said they were going to work on in this sprint. As I recall there were several that we decided to leave open for now...
[17:51:56] * bd808 looks at borads
[17:54:26] <bd808>	 joakino: After looking at the sprint 63 board I think we did talk about all the left behind cards and left them on purpose. We can run it down again in the standup if we get through other triage
[17:55:18] <bd808>	 I put a boackport of the fix for T123821 in for swat this evening -- https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=261815&oldid=261766
[17:55:20] <joakino>	 bd808: i thought we cleaned boards after we used them, shouldn't we remove the sprint board from those tasks then?
[17:56:11] <bd808>	 joakino: we could do that, yes. I have been leaving the past sprint board open until it is empty but not removing things myself
[17:56:33] <joakino>	 bd808: ok, i'll raise the issue in standup
[17:56:38] <bd808>	 sounds good
[18:49:10] <dbrant>	 dr0ptp4kt: jdlrobson: mtg?
[18:54:55] <phuedx>	 bd808: are you down for shepherding that backport?
[18:57:22] <bd808>	 phuedx: yeah I think I can babysit it (assuming swat doesn't run too long)
[18:57:28] <phuedx>	 cool
[18:57:39] <bd808>	 also sorry for missing most of standup folks
[18:58:00] <bd808>	 I missed the ping from my calendar (dog ate my homework)
[19:12:12] <jdlrobson>	 bgerstle_lunch: so the problem with the pageview API is there are too many edge cases
[19:12:26] <jdlrobson>	 and without context results can be confusing
[19:12:36] <jdlrobson>	 for instance https://en.wikipedia.org/wiki/Bruce_Kingsbury has been top viewed page for 3 days and i have no idea why
[19:13:21] <jdlrobson>	 I would recommend some post processing for anything production ready 
[19:34:43] <bgerstle>	 jdlrobson: interesting. is there a list of these problems anywhere?
[19:35:20] <bgerstle>	 jdlrobson: for the "Kingsbury problem" did you limit the query to user pageviews only?
[19:37:42] <joakino>	 there's JS on the mac app store? https://i.imgur.com/bJAEHvI.png
[19:38:04] <joakino>	 NaNNaNNaNNaN
[19:38:23] <phuedx>	 batman!
[19:38:24] <bgerstle>	 joakino: oh yeah, and i think the iOS app store
[19:38:39] <bgerstle>	 joakino: but i would be surprised if that part was JS
[19:39:02] <joakino>	 it's webviews all the way down
[19:46:01] <joakino>	 bgerstle: apple is the king of UX https://i.imgur.com/qTHo2n3.png
[19:46:03] <joakino>	 PRF
[19:58:37] * bgerstle_mtg joakino: dr0ptp4kt jdlrobson can haz priority plz: https://phabricator.wikimedia.org/T123580
[19:58:59] <bgerstle_mtg>	 joakino: lol
[20:00:54] <jdlrobson>	 bgerstle_mtg: What do you mean by user pageviews only? 
[20:01:23] <jdlrobson>	 it's diffuclt to distinguish bots/users from what I understand so API doesn't do a good job of that
[20:01:34] <bgerstle_mtg>	 jdlrobson: i thought that was part of the API at some point
[20:01:36] <bgerstle_mtg>	 maybe not
[20:03:46] <jdlrobson>	 Just take a look through http://top.hatnote.com/
[20:04:20] <jdlrobson>	 Things also hang around a long time. Bowie's still in top ten, Star Wars 7 was top for 2 weeks
[20:04:28] <jdlrobson>	 so after a while they lose that freshness
[20:04:57] <jdlrobson>	 All it takes is someone with a popular website to link to our article and they spike and it's not clear why. Would be useful to be able to access referers
[20:05:06] <bgerstle_mtg>	 yeah, there's a ticket for that: https://phabricator.wikimedia.org/T123442 (poorly worded, i think)
[20:05:08] <jdlrobson>	 e.g. Featured on the <a>New York times</a>
[22:46:23] <ebernhardson>	 is mailing mobile-l@lists.wikimedia.org sufficient for contacting both mobile web and apps?
[22:51:46] <niedzielski>	 ebernhardson: i think so. i'm an android dev and i'm on it
[22:54:19] <ebernhardson>	 niedzielski: perfect, thanks. mail sent
[23:18:11] <HaeB>	 dr0ptp4kt: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Reading_and_Advancement,_October_2015#Reading
[23:49:52] <kaity_>	 hey niedzielski are you still around?
[23:50:04] <niedzielski>	 kaity_: yep :)
[23:50:30] <kaity_>	 niedzielski: do you know where I can find user requests for features?
[23:51:26] <kaity_>	 niedzielski: from playstore reviews and such. not sure if we pull them out to put into a list somewhere?
[23:51:44] <niedzielski>	 kaity_: i think florian and dbrant usually add them as phabricator tickets. i'm not sure they have a tag though. i know dbrant regularly combs the play store reviews in particular
[23:52:25] <kaity_>	 niedzielski: ok cool
[23:53:57] <niedzielski>	 kaity_: i'll fwd you the most recent digest (prior to your addition on the android mailing list)
[23:55:41] <niedzielski>	 kaity_: ok, i just resent it to the same list which should add you automatically. let me know if you don't get it
[23:56:04] <kaity_>	 niedzielski: got it. Thanks!
[23:56:13] <niedzielski>	 \o/
[23:58:52] <kaity_>	 niedzielski: these reviews are killing me, so funny
[23:59:34] <niedzielski>	 kaity_: i agree! :)