We have been dealing with
https://bugzilla.wikimedia.org/show_bug.cgi?id=62614 for far too long, and
it's causing serious problems for our automated browser tests. We need to
get to the bottom of this yesterday before it drives us all completely
insane, or at least more insane than normal.
*Chris S*, I gather from the bug report that you may have some
insights/experience to help get to the bottom of this that we are otherwise
lacking. *Would it be useful to sit down with Chris M and Jon (and whoever
else wants) to synchronously figure out WTF is going on here?* I fear this
bug will take years to get resolved if we otherwise asynchronously poke at
it from time to time.
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
FYI in case anyone missed this elsewhere. Keep this in mind if any
login-related bugs pop up around this.
---------- Forwarded message ----------
From: Greg Grossmeier <greg(a)wikimedia.org>
Date: Tue, Apr 8, 2014 at 1:54 PM
Subject: [Wikitech-ambassadors] Security precaution - Resetting all user
sessions today
To: Wikitech Ambassadors <wikitech-ambassadors(a)lists.wikimedia.org>
Yesterday a widespread issue in OpenSSL was disclosed that would allow
attackers to gain access to privileged information on any site running a
vulnerable version of that software. Unfortunately, all Wikimedia
Foundation hosted wikis are potentially affected.
We have no evidence of any actual compromise to our systems or our users
information, but as a precautionary measure we are resetting all user
session tokens. In other words, we will be forcing all logged in users
to re-login (ie: we are logging everyone out).
All logged in users send a secret session token with each request to the
site and if a nefarious person were able to intercept that token they
could impersonate other users. Resetting the tokens for all users will
have the benefit of making all users reconnect to our servers using the
updated and fixed version of the OpenSSL software, thus removing this
potential attack.
As an extra precaution, we recommend all users change their passwords as
well.
Again, there has been no evidence that Wikimedia Foundation users were
targeted by this attack, but we want all of our users to be as safe as
possible.
Thank you for your understanding and patience,
Greg Grossmeier
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
_______________________________________________
Wikitech-ambassadors mailing list
Wikitech-ambassadors(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
The Mobile App team had their monthly retrospective today. Notes,
further discussion, and
action items are below.
https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-April_…
Extra props to Adam Baso for helping with code review and feature work
on both the Android and iOS app.
= Further discussion items =
* Unsure about value of sign off column, atm seems to be a rush of
paperwork process stuff on fridays and mondays
* We haven't been doing any user testing to validate underlying issues
that we planned on doing months ago
* Too many meetings, I think. Perhaps experiment with longer sprints
to reduce overhead? Start with async default?
* Took a bit of time to get the builds. [Brion+Yuvi will follow up]
** Kenan can't get the Android alpha download to work +May too
Thanks team and all involved.
--tomasz
Pulling in our public mailing list to find what our international
mobile community would like most.
https://etherpad.wikimedia.org/p/MobileLanguageEngineering2014
Right now i think we need more review rather than development but i'm
sure others will jump in.
--tomasz
On Tue, Apr 1, 2014 at 7:57 PM, Alolita Sharma <asharma(a)wikimedia.org> wrote:
> Hi Kenan, Tomasz,
>
> We are in the process of discussing and prioritizing our team’s roadmap for
> the upcoming fiscal year. I want to ask you for your wishlist
> of language features
> you would like the language eng team to
> support
> your mobile projects.
>
> Add
> your simplest to wildest ideas for multilingual support for mobile in a
> GDoc and share them with me by April 15 :-)
>
> Let me know if you have any questions. Look forward to your wishlist.
>
> Thanks!
>
> Best,
> Alolita
>
> Alolita Sharma
> आलोलिता शर्मा
> Director of Engineering
> Internationalization & Localization
> Wikimedia Foundation
Is "MinervaPreRender" involved? I tried
function JZ(&$z){$z->data['page_actions']=array(); return true;}
$wgHooks['MinervaPreRender'][]='JZ';
but that didn't work.
Heads up that Shahyar from the Flow team met up with Juliusz and I to
discuss better code sharing and thus easier integration betwen Flow
and MobileFrontend. It seems we are doing various things in a similar
fashion and there is an opportunity to share code.
You can see Shahyar's notes below but the main areas that could do
with immediate consolidation are as follows:
* Both use client side templates but with different template
libraries. MobileFrontend has a method of serving these via
ResourceLoader. We recommended that we consolidate this code asap and
aim to push it into core, rather than have the situation where we are
both using our own code. We should make this template agnostic to fit
in with the ongoing RFC around client side templates. I cut a story
card to try and get this on MobileFrontend's radar -
https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1800
* Flow uses jquery microsize to auto expand a textarea when typing,
mobile has its own lightweight library to do this.
* Both Flow and MobileFrontend use a lightweight library to generate
user friendly last modified timestamps ( e.g. 3 days ago etc) - this
is much smaller than moment.js in core
* Both extensions use Class inheritance JavaScript model.
---------- Forwarded message ----------
From: Shahyar Ghobadpour <sghobadpour(a)wikimedia.org>
Date: Tue, Mar 25, 2014 at 2:34 PM
Subject: Mobile & Core Features front-end meetup technical notes
To: "Editor engagement list for the core E2 development team."
<e2(a)lists.wikimedia.org>
Cc: Juliusz Gonera <jgonera(a)wikimedia.org>, Jon Robson
<jrobson(a)wikimedia.org>, Tomasz Finc <tfinc(a)wikimedia.org>
Core Features met up with the front-end guys from Mobile, and we, in
Maryana's words, creeped on each others' code. This gave us a lot of
insight into how our teams have been doing things (spoiler alert: it's
very similar).
Here are my notes, from Flow's perspective on things:
Classes
Can extend objects
Call parents with .super
Notable classes:
EventEmitter
Binds events to objects, but is in fact just a wrapper for jQuery.Events
Overlay
M
Uses M.require to grab a constructor/class
Not big, just basically to make sure that the loading order is correct
and all requested modules actually exist
New ones added via M.define
Templates
Hogan
methods:
preRender
postRender
Most useful; adds logic to templates after the fact
Currently, they use this to find elements and bind (events) directly to them
mw.template implements template compiling, getting, adding
mw.template.add is called by resourceloader
Currently uses Hogan only, but could easily be changed to use
Handlebars (could even just overload mw.template.compile)
History State Management
Currently only implements hash change event
Android 2.3 and Android 4.0 do not correctly (how?) support history
API for adding more URLs to the history
Currently still in flux due to various issues
Would be worth combining efforts to make a better one
API
mw.api sucks, they wrote their own
Each API is subclassed
eg. editorApi implements its own special methods on top of Api
CSS
Has separate responsive styles for tablet and for phone
In individual files and loaded when needed, so as to not slow down the
base CSS with too many media queries
Might change; they may end up getting concatenated later on for simplicity
At 768px adjustment begins for media queries (to be standardized
between Mobile and Flow)
Misc
Custom micro.autosize.js
Automatically resizes textareas as you type
Only 600 bytes unminified
--Shahyar
The Page Object design pattern divides browser tests into three areas: the
controller, where the test is created (this is a description of the test):
the steps of the test, which are actions taken by the test (the steps are
verbs, actions, navigation from one place to another and checking on
status; and the page definitions, which are the nouns against which the
steps/actions/verbs are working.
In our implementation of the Page Object pattern:
* the Cucumber feature files are the story of the tests
* the steps.rb files are the verbs and actions
* the page.rb files are the nouns and the pages
If you know anything about Design Patterns, you may know that they are
discovered, not invented. Among people who do browser testing, the Page
Object design pattern is generally accepted to be the best known solution
for creating browser tests that are robust, readable, maintainable, and
that will scale to large numbers of tests.
In practice, that boils down to some rules that we need to follow, and one
of those rules is: *no element identifiers in steps files*. Page elements
like div and span that have identifiers of e.g. class: and css: need to be
managed in the page.rb files and *only* in the page.rb files.
Do not put page element identifiers into the steps of the test. This makes
the tests difficult to read, difficult to scale, and very difficult to
maintain.
Adhere to the Page Object design pattern: keep your page element
identifiers in the /support/pages/*page.rb files ONLY, and NOT in the
/step_definitions/*steps.rb files.