Hello Mobile fans :)
Florian and and myself earlier created a draft for a Mobile Newsletter:
https://www.mediawiki.org/wiki/Mobile/Newsletter -- it is currently a bit
outdated since it has been around for a while. Given the comments on phab
ticket. https://phabricator.wikimedia.org/T93529, it is likely that this
needs to be streamlined with other newsletters, however, meanwhile the
coordination, please check and let me know:
1. What would be the best approach to create it --agree on sections (new
features, testing, etc) where volunteers, PMs and CL add details to?
2. This format is too detailed? Too brief? What else do we need to see on
a newsletter for mobile?
Obviously, it has to be made mobile friendly, as well. :)
Comments, suggestions, thoughts?
Many Thanks!
Moushira
I did a quick spike [1] to work out how Gather could stop depending on
MobileFrontend.
Essentially problems come into 2 categories:
1) Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see
any major blockers here).
I think to fix this we simply need to provide Gather as a desktop beta feature.
This is tracked here: https://phabricator.wikimedia.org/T95227 and I
see no issues with doing this.
2) frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses
a library that was built around the same time as OOJSUI. Migrating
MobileFrontend to use OOJSUI is a big task and although has happened
somewhat (the codebase now uses OOJS for class inheritance) it is by
no means complete.
Gather current depends on a variety of MobileFrontend modules which
mainly include: API, overlay, user and user setting code, EventLogging
schema code, notifications code. We also have a method
mw.mobileFrontend.require and mw.mobileFrontend.define for defining
modules. OOJS ui does this differently writing class names to the OO
global variable object.
==The long term fix===
... is obviously to migrate all the code to OOJS UI which I believe
would require the following steps:
* https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
* Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. -
https://phabricator.wikimedia.org/T66565
* Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something
akin to https://phabricator.wikimedia.org/T67008
* EventLogging Schema.js should be ported to oojs ui and moved into core.
* We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix==
We could split out the frontend library MobileFrontend uses to allow
us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code
into its own project just like oojs ui and slowly rewrite it there
till it is pure oo js ui. This would take everything in the
javascripts/common/ folder except application.js and bundle it into
one file.
We could include this as a submodule in both projects, both extensions
conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Hey y'all,
As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team
picked up a spike to investigate what data, if any, we were logging around
site speed [0], given the existence of the mobile graphs over at WMF stats
[1].
After a little poking around I found that all of the NavigationTiming data
that's collected by the eponymous extension is already separated out into
desktop and mobile series in Graphite [2]. Any or all of these series can
be graphed in gdash by defining our own graphs [3].
With this in mind I've closed the tasks to design and implement our own
event logging for site speed as invalid – don't you just love it when
work's already done for you?
Furthermore, if we find, some time in the future, that we want do refine
the data that's being collected, then we have a clearly defined workflow:
design the schema with the help of analytics, instrument the schema, and
then define a graph. You'll note that only the first step requires
collaboration (i.e. synchronisation) with another team. Woo!
–Sam
[0] https://phabricator.wikimedia.org/T95296
[1] https://gdash.wikimedia.org/dashboards/frontend/
[2] https://graphite.wikimedia.org – have a good look around frontend -
navtiming
[3]
https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/…
FYI. I just fixed the alpha build for the Android app. (
http://android-builds.wmflabs.org/)
It had issues with the java-mwapi dependency. It was most likely cause by
one of the recent labs outages (the team Maven repo, which hosts only this
library, is also on tool labs).
More details on https://phabricator.wikimedia.org/T96102.
Bernd
It really saddens me how very few engineers seem to care about browser
tests. Our browser tests are failing all over the place. I just saw this
bug [1] which has been sitting around for ages and denying us green tests
in Echo one of our most important features.
How can we change this anti-pattern?
Dan Duval, would it make sense to do a survey as you did with Vagrant to
understand how our developers think of these? Such as who owns them... who
is responsible for a test failing... who writes them... who doesn't
understand them.. why they don't understand them etc...?
[1] https://phabricator.wikimedia.org/T72298
On Thu, Mar 26, 2015 at 5:54 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote:
> On Thu, Mar 26, 2015 at 3:38 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> > The lack of replies from any mobile team members seems to suggest I'm the
> > only one watching this. In that case I'd rather we split up the big
> > MobileFrontend job into various jobs based on certain features. How can
> we
> > get more people caring about browser tests? Naming and shaming?
>
> We have a couple projects in the works that will hopefully help.[1][2]
> They don't go so far as to name and shame (we'll leave that up to you
> :), but they should promote more ownership over browser tests, better
> communication of failure, and analysis of failure over time and by
> test function (feature vs smoke vs regression).
>
> If many of these browser tests are serving as regression/smoke tests,
> it might be worthwhile to not only separate them out, but to remove
> some of the layers of abstraction to make tests more maintainable. I
> often try to think about tests in terms of a value-to-debt ratio (i.e.
> "How likely is it that I'll have to fix or refactor this test down the
> road and is it worth it?") and, while I find quite a bit of value in
> Cucumber for the sake of acceptance(-esque) testing (it keeps me
> mindful of the UX),[3] it introduces quite a bit of debt in its layers
> of abstraction and indirection (it's always a red flag when you have
> to grep to find your test implementation). Even its creators believe
> the value of Cucumber lies in its collaboration/planning capacities,
> not in its function as a test runner.[4]
>
> It's entirely possible, as of the 1.0.0 release, to use MW-Selenium
> without Cucumber, so perhaps we could experiment with simple RSpec
> examples for these types of tests.
>
> Tooling aside, there are broader discussions that need to take place
> among those that are practicing or have practiced TDD/BDD in the
> organization and how we might (or might not) promote theses practices
> among others. I'll be trying to form such a group next quarter (will
> it be a 'guild'?, a 'league'?, no need for tough decisions just
> yet[5]), so let's maintain a dialogue on that front if you're
> interested and willing.
>
> [1] https://phabricator.wikimedia.org/T88706
> [2] https://phabricator.wikimedia.org/T89375
> [3]
> https://gerrit.wikimedia.org/r/#/c/196492/10/features/role_settings.feature
> [4]
> https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaborat…
> [5] https://www.youtube.com/watch?v=6KSiyaqnZYs
>
> > Practically, the current big job [1] we have has far too many false
> > positives and it is just noise to me. I was paying attention to the smoke
> > tests [2] but I was told that was an upstream bug and haven't been
> watching
> > it since. Any idea why that has been failing recently? Nothing has broken
> > here...
> >
> > [1]
> >
> https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
> > [2]
> >
> https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
> >
>
> Have you tried to reproduce these failures by executing the tests
> locally, against either Beta or your local MW? I'll be in the office
> tomorrow if you want advice on how to best go about it.
>
> Dan
>
> --
> Dan Duvall
> Automation Engineer
> Wikimedia Foundation
>
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
Hey y'all,
Anyone know what powers, or more correctly what *should* power, the
MediaWiki: MobileFrontend dashboard [0]? I'm hoping that it's data from the
NavigationTiming extension but I've been known to be wrong.
–Sam
[0] https://gdash.wikimedia.org/dashboards/mobext/
Dear Android app friends,
Around an hour ago I pushed out a new release for the beta app, so it
should be available fairly soon.
Changes for beta / 2015-04-10 [1] include:
* Show local page titles in language list entries of 'Read in other
languages'
* ShareAFact: correctly align WP wordmark for RTL
* Fix issue with moving the first paragraph in some articles
* Fix missing period at the end of first sentence in some articles
* Hide search bar on saved pages and history sections if none exist
* Fix issue where ToC onboarding screen was not shown but the ToC was
when visiting subsequent pages
* Make enter key submit request when the user is filling in a captcha
Enjoy,
Bernd
[1] This is versionCode 100! Yeah!
*tl;dr: The programming language used to develop new features by our iOS
app engineering team is changing from Objective C to Swift at some point in
the near future.*
When making a native app, the language you have to implement the app in is
chosen by the third party responsible for the platform. For iOS apps, Apple
chose Objective C to be the language the app is written in. Objective C is
a... very strange language. It has a lot of quirks that slow down
development.
To solve the above problem, you can now write apps in a new language called
Swift. Notably, Swift has features that make it less error prone and more
concise than Objective C, which should increase our velocity of feature
development. Swift is also much more readable and in-line with other
languages, which lowers the barrier of entry (which is currently very high
with Objective C).
Importantly, Objective C and Swift can live alongside each other. So, when
we "switch to Swift" we do not need to rewrite all of our existing code
from Objective C to Swift. Instead, we can just start developing new
features using Swift, and slowly rewrite the old code from Objective C into
Swift as time allows.
On the downsides, Swift is only supported on iOS 7 and above. iOS 6 only
represents around 5% of our user base, and we can pin iOS 6 users to the
last version of the app we released before we used Swift. We need to decide
what the last set of features we're want in that build are before we switch.
Here are our next steps:
- Evaluate more concretely whether Swift actually fits our needs or not.
[Engineering]
- Decide last set of features for our iOS 6 build. [Product/Design]
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation