Hello,
I'd like to invite you to check out the newest version of Wikipedia Beta,
which will be available shortly on Google Play.
Changes in the latest version include:
* Add Link Preview dialog for some users
* Handle image map links in-app
* Make sure Share A Fact button works on all devices
* Fix sharing of images to Facebook app
* Increase "tap to expand" click area
* Remove "read next" prototype
* Fix text directionality consistency in Nearby
* Show "Read in other languages" only if article exists in other languages
* Fix language picker word wrap
* Add upside-down mode for newer devices
* Hide caption on "tap to expand" table when open
Enjoy!
Michael
Hey everyone…
The latest for iOS is live on the app store. You can download it here:
https://itunes.apple.com/us/app/wikipedia-mobile/id324715238?mt=8
We are continuing our quest to squash bugs and tighten up the screws, but
you’ll see a few new features in there as well.
This also represents our 3rd release in just over a month after a nearly 4
month drought - our release pipeline in full effect! Automated builds +
Crash Reporting + Phabricator Tasks FTW!
Please check it out if you get a chance and let us know what you think -
mailing list, in app feedback, or an app store review - all are appreciated!
Thanks for reading!
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation
MobileWebWatching schema has been active for some time now, I'm happy to
now reveal the results:
These are the number of clicks to the watchstar per funnel across the site
in stable:
page 61627
watchlist 1635
search 3105
nearby 279
and across all mobile modes:
page 63928
nearby 333
search 3357
watchlist 1890
As can be seen traffic to watchstars outside the current page is low. I
would suggest we therefore stop showing the watch star in search, nearby
results and Special:EditWatchlist and just focus on the funnel from the
page itself.
If interested I generated this data using:
select event_funnel, count(*) from MobileWebWatching_11761466 group by
event_funnel
It's also worth pointing out 8,025/12,964 ([1,2]) of the unique users using
the watch star had an edit count of 0.
[1] select count(distinct event_userId) from MobileWebWatching_11761466
where event_mobileMode = 'stable'
[2] select count(distinct event_userId) from MobileWebWatching_11761466
where event_mobileMode = 'stable' and event_userEditCount = 0
Replacing with mobile-l...
Who's best to make updates?
On Tuesday, May 12, 2015, Dan Andreescu <dandreescu(a)wikimedia.org> wrote:
> Sean,
>
> First, thanks for killing those queries.
>
> Second, I've cc-ed mobile tech to talk about this problem. This query is
> running periodically on a scheduler. It is re-computing all data every
> time it runs. The mobile folks developed logic in the scheduler to
> time-box some queries, but problems with Event Logging data and the
> incredibly frequent need to re-run after data outages and backfills has
> left this kind of monster query as the only sane option. So our current
> reality is that the only sane option is insane.
>
> Indexing these tables to make this insane query run is like the old "Why
> don't you turn in your crazy brother who thinks he's a chicken? I would,
> but I need the eggs." joke. Yes we do need the eggs, but no we're not
> going to get them from this query.
>
> Marcel wrote a new scheduler that handles failures much better and is much
> easier to work with in terms of re-runs. That's the only option to keep
> this kind of data generation alive. Until we get that running, we are
> going to cancel this and other non-timeboxed queries. This patch:
> https://gerrit.wikimedia.org/r/#/c/210364/ has mobile folks on it and
> Sean. Sean, if this problem happens again before we take action, just
> merge this patch and that will stop the bleeding.
>
> In the long run, we are trying to migrate this data to a scalable
> analytics platform where you can run queries like this and the system will
> cleverly re-compute only if the underlying data changes. Druid, Pipeline
> DB, etc. are candidates. The intermediate step to that will be moving the
> Event Logging pipeline to Kafka and Hadoop, which we are in the process of
> doing right now.
>
>
> On Tue, May 12, 2015 at 2:12 AM, Sean Pringle <springle(a)wikimedia.org
> <javascript:_e(%7B%7D,'cvml','springle(a)wikimedia.org');>> wrote:
>
>> I just killed 100+ 3-day unindexed research queries on dbstore1002.
>> All replication streams were lagging by nearly 1 day, and /tmp was
>> hundreds of GB.
>>
>> This seems similar to the problem from ~2 weeks ago, when old /tmp did
>> fill up. The queries were of the following form (but with some
>> variation). We need some indexing scheme for MobileWebEditing*
>> tables, or to come up with a new approach.
>>
>> SELECT
>> Month.Date,
>> COALESCE(Web.Web, 0) AS Web
>>
>> -- http://stackoverflow.com/a/6871220/365238
>> -- ... using MariaDB 10 SEQUENCE engine instead of
>> information_schema.columns
>> FROM (
>> SELECT DATE_FORMAT(
>> ADDDATE(CURDATE() - INTERVAL 30 - 1 DAY, @num:=@num+1),
>> '%Y-%m-%d'
>> ) AS Date
>> FROM seq_1_to_100, (SELECT @num:=-1) num LIMIT 30
>> ) AS Month
>> LEFT JOIN (
>> SELECT
>> DATE(timestamp) AS Date,
>> SUM(1) AS Web
>>
>> FROM (SELECT timestamp, wiki, event_username, event_action,
>> event_namespace, event_userEditCount FROM MobileWebEditing_5644223
>> UNION SELECT timestamp, wiki, event_username, event_action,
>> event_namespace, event_userEditCount FROM MobileWebEditing_6077315
>> UNION SELECT timestamp, wiki, event_username, event_action,
>> event_namespace, event_userEditCount from MobileWebEditing_6637866
>> UNION SELECT timestamp, wiki, event_username, event_action,
>> event_namespace, event_userEditCount from MobileWebEditing_7675117
>> UNION SELECT timestamp, wiki, event_username, event_action,
>> event_namespace, event_userEditCount from MobileWebEditing_8599025) as
>> MobileWebEditing WHERE
>> event_action = 'error' AND
>> wiki != 'testwiki'
>> GROUP BY Date
>> ) AS Web ON Month.Date = Web.Date;
>>
>> EXPLAIN:
>>
>>
>> +------+--------------+--------------------------+--------+---------------+---------+---------+------------+----------+----------------------------------------------+
>> | id | select_type | table | type |
>> possible_keys | key | key_len | ref | rows | Extra
>> |
>>
>> +------+--------------+--------------------------+--------+---------------+---------+---------+------------+----------+----------------------------------------------+
>> | 1 | PRIMARY | <derived2> | ALL | NULL
>> | NULL | NULL | NULL | 30 |
>> |
>> | 1 | PRIMARY | <derived4> | ref | key0
>> | key0 | 4 | Month.Date | 563154 | Using where
>> |
>> | 4 | DERIVED | <derived5> | ALL | NULL
>> | NULL | NULL | NULL | 56315405 | Using where; Using
>> temporary; Using filesort |
>> | 5 | DERIVED | MobileWebEditing_5644223 | ALL | NULL
>> | NULL | NULL | NULL | 1152600 |
>> |
>> | 6 | UNION | MobileWebEditing_6077315 | ALL | NULL
>> | NULL | NULL | NULL | 685212 |
>> |
>> | 7 | UNION | MobileWebEditing_6637866 | ALL | NULL
>> | NULL | NULL | NULL | 1528269 |
>> |
>> | 8 | UNION | MobileWebEditing_7675117 | ALL | NULL
>> | NULL | NULL | NULL | 1663281 |
>> |
>> | 9 | UNION | MobileWebEditing_8599025 | ALL | NULL
>> | NULL | NULL | NULL | 51286043 |
>> |
>> | NULL | UNION RESULT | <union5,6,7,8,9> | ALL | NULL
>> | NULL | NULL | NULL | NULL |
>> |
>> | 2 | DERIVED | <derived3> | system | NULL
>> | NULL | NULL | NULL | 1 |
>> |
>> | 2 | DERIVED | seq_1_to_100 | index | NULL
>> | PRIMARY | 8 | NULL | 100 | Using index
>> |
>> | 3 | DERIVED | NULL | NULL | NULL
>> | NULL | NULL | NULL | NULL | No tables used
>> |
>>
>> +------+--------------+--------------------------+--------+---------------+---------+---------+------------+----------+----------------------------------------------+
>>
>>
>> ---
>> DBA @ WMF
>>
>> _______________________________________________
>> Analytics mailing list
>> Analytics(a)lists.wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','Analytics(a)lists.wikimedia.org');>
>> https://lists.wikimedia.org/mailman/listinfo/analytics
>>
>
>
Hi all -
Max Semenik, now on Search & Discovery (he's been working on geo stuff for
a while), spoke with me earlier today about transferring Reading-oriented
extension components / API endpoints off his plate. I'll add the bullet
points to the Etherpad for the recurring APIs/Services meeting instance
tomorrow.
* API action=mobileview : the apps are heavy users of this endpoint.
* pageimages extension: Max noted that the algorithm needs improvement for
targeting the "best" image.
* featuredfeeds extension (RSS/Atom)
* TextExtracts is still an open question. Max said he can maintain it in
maintenance mode, if necessary. But if there's interest in Reading taking
over future work on this, that would be even better. Max noted the
persistence of the results is an area for improvement. Incidentally, some
people have been communicating about this stuff today.
Thanks.
-Adam
A while back we disabled the mobile uploads interface in mobile. It's been
sitting in our codebase dormant so people can enable it via user js if
necessary but it's broken a few times and doesn't seem to be getting the
attention it needs.
Given there is now an editing team and from what I understand UploadWizard
is being refactored into oojs ui (which will lead to it being less bulky
and more mobile friendly) I'd like to suggest we abandon the code in
MobileFrontend and help support that effort. Note this effort is likely to
take a long long time, since that extension suffers from much technical
debt and makes use of jquery ui, which is not available on mobile, so to
set expectations we're not going to be in a state where we can enable this
on mobile (if we wanted to which again is highly questionable) any time
soon (think in units of a year rather than weeks/months).
The downside of this is any 3rd parties who are using this uploads code
(it's turned on by default) will lose this feature and there is no
available alternative.
I've written a patch to remove it [1] but I just wanted to post this here
to give people the chance to voice any concerns/disagree with this approach.
Note: We can always restore the code later on if necessary. I argue this
will be easier than fixing/maintaining the existing code. Someone could
also put it into a separate extension if they wanted to use it.
See also: https://phabricator.wikimedia.org/T97169
[1] https://gerrit.wikimedia.org/r/#/c/210084/
Hi,
Kaldari asked yesterday on irc what the "Flag for later" button does on a
task on Maniphest.
After a few minutes of confusing googling (you can imagine the freaking
button appearing in thousands of bugs with the button...) I found that it
is like a favourites list, personal and hidden, with color coded categories.
Go to https://phabricator.wikimedia.org/flag/ while logged in and you will
see the items you have flagged for later.
Not sure what to use it for, but for example I've flagged a bug I created
that I was having difficulty finding everytime, for easy access.
If you think of other use cases or actually are using it for something, it
would be great to know.
Cheers.