[Wikitech-l] Making our software simple and effective

[Rob Lanphier]

Hi folks,

One thing we're trying to do as we schedule WikiDev '16 is make sure
that sessions are solving for one of five problems.  One of the
problems I've been trying to figure out how to articulate I think I've
finally got some wording around, and I'd like your thoughts.

The question: "how do we simultaneously optimize the following
conditions? 1) make software development more logical and obvious for
all Wikimedia contributors, 2) make Wikimedia software more useful and
reliable for the Wikimedia sites"

This is an expression of a balancing tradeoff that I think we've
implicitly made over the years, but I think it's time to make
explicit.  Ideally, new ideas should make both better, but sometimes
we need to sacrifice one to make big gains in the other.  Does that
question capture an important idea?

A lot more detail in Phab here:


Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WMF Discovery/Editing/Reading Showcase 20151214

[Derk-Jan Hartman]

I have to say, there is some awesome stuff in there. Nice work everyone !

DJ

On Fri, Dec 18, 2015 at 12:33 AM, Adam Baso  wrote:

> Here's video from the Discovery/Editing/Reading Showcase on
> 14-December-2015. Enjoy!
>
> Commons
> https://commons.wikimedia.org/wiki/File%3ADiscoverbb_edit.webm
>
> YouTube
> https://www.youtube.com/watch?v=U48o_TZLmbY=162
>
> In this edition:
>
>   * Interactive charts & graphs
>
>   * Guided formula (Extension:Math) dialog
>
>   * Cross-wiki notifications
>
>   * Showing user's preferred languages in Portal top10 wikis.
>
>   * A better type-ahead on portals
>
>   * Geo search over a bounding box
>
>   * Single edit tab
>
>   * Wiktionary popup in Android app
>
>   * Fuzzy autocomplete on wiki
>
> -Adam
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Sharing JS code between NodeJS and browser

[Yuri Astrakhan]

For JS gurus - what is the best way to share JavaScript library code
between the NodeJS and browser?  The shared library will need to use
$.extend()-like functionality, URL parsing and reconstructing, and logging.

How should the code be organized? What are the recommended tools to
automate the process?

Thanks!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sharing JS code between NodeJS and browser

[Daniel Friesen]

On 2015-12-18 8:41 AM, Trevor Parscal wrote:
> Be careful when doing this with NPM modules, as their contents are subject
> to change, and only their index file is configured and trying to
> automatically know the paths and inclusion order is more of a mad science
> than an art. Your best bet would be hard-coding and using very specific
> versions in your package.json to protect from unexpected changes dues to
> subtle NPM module version differences.
npm modules are modules, not scripts. Even if you knew their execution
order you can't just "include" them in any order at all.

Using browserify to build a standalone script with a UMD that exposes a
global might be the best bet.
Though you'll have to be wary of requiring a module that pulls in a
bunch of dependencies.

> As for needing some $.extend, URL parsing and reconstructing, and logging.
> I'm assuming you mean taking client code to the server where jQuery and
> common browser functionally might not be present. There are many NPM
> modules that provide shims for these things, including full-on server-side
> jQuery. Usually the differences are subtle if any. Members of the Paraoid
> team are very familiar with this space and are probably good people to talk
> to about this.
URL - Built in to node. Browserify comes with a browser compatible
version of the module for when you require('url') it.

extend:
- lodash.merge (as part of lodash or the dedicated 'lodash.merge' module)
- Some people use xtend or extend
- There is also a new native Object.assign built into ES6, which you
could include a simple polyfill for

Logging varies very much by what you need. So there's wilson, debug, and
a bunch of others.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sharing JS code between NodeJS and browser

[Trevor Parscal]

ResourceLoader is happy to ring files to the client from anywhere below the
base path you set when creating a file module. If that base path js the
root of the extension then you can just put the shared js code in a folder
accessible by both node.js and ResoriceLoader, maybe a /lib folder or
something.

Be careful when doing this with NPM modules, as their contents are subject
to change, and only their index file is configured and trying to
automatically know the paths and inclusion order is more of a mad science
than an art. Your best bet would be hard-coding and using very specific
versions in your package.json to protect from unexpected changes dues to
subtle NPM module version differences.

As for needing some $.extend, URL parsing and reconstructing, and logging.
I'm assuming you mean taking client code to the server where jQuery and
common browser functionally might not be present. There are many NPM
modules that provide shims for these things, including full-on server-side
jQuery. Usually the differences are subtle if any. Members of the Paraoid
team are very familiar with this space and are probably good people to talk
to about this.

- Trevor

On Friday, December 18, 2015, Yuri Astrakhan 
wrote:

> For JS gurus - what is the best way to share JavaScript library code
> between the NodeJS and browser?  The shared library will need to use
> $.extend()-like functionality, URL parsing and reconstructing, and logging.
>
> How should the code be organized? What are the recommended tools to
> automate the process?
>
> Thanks!
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Sharing JS code between NodeJS and browser

[Yuri Astrakhan]

Trevor and Daniel, thanks for your reply.

How would you structure the code that is to be shared?  Should it be a
separate NPM package, referenced from the extension package.json via git
url, and have a small file in the extension's lib/ dir with a oneliner -
 "require('...')"  that browserify could pick up? And have a script command
in package.json to build that file?

There are many implementations of URL parsing - from mw.Url to
require('url').  They differ slightly, but that is not the main problem -
how should the shared code use the right one?  Should they be passed as
functional function params? Should there be some "lib init" that sets lib's
global functions?

On Fri, Dec 18, 2015 at 8:22 PM, Daniel Friesen 
wrote:

> On 2015-12-18 8:41 AM, Trevor Parscal wrote:
> > Be careful when doing this with NPM modules, as their contents are
> subject
> > to change, and only their index file is configured and trying to
> > automatically know the paths and inclusion order is more of a mad science
> > than an art. Your best bet would be hard-coding and using very specific
> > versions in your package.json to protect from unexpected changes dues to
> > subtle NPM module version differences.
> npm modules are modules, not scripts. Even if you knew their execution
> order you can't just "include" them in any order at all.
>
> Using browserify to build a standalone script with a UMD that exposes a
> global might be the best bet.
> Though you'll have to be wary of requiring a module that pulls in a
> bunch of dependencies.
>
> > As for needing some $.extend, URL parsing and reconstructing, and
> logging.
> > I'm assuming you mean taking client code to the server where jQuery and
> > common browser functionally might not be present. There are many NPM
> > modules that provide shims for these things, including full-on
> server-side
> > jQuery. Usually the differences are subtle if any. Members of the Paraoid
> > team are very familiar with this space and are probably good people to
> talk
> > to about this.
> URL - Built in to node. Browserify comes with a browser compatible
> version of the module for when you require('url') it.
>
> extend:
> - lodash.merge (as part of lodash or the dedicated 'lodash.merge' module)
> - Some people use xtend or extend
> - There is also a new native Object.assign built into ES6, which you
> could include a simple polyfill for
>
> Logging varies very much by what you need. So there's wilson, debug, and
> a bunch of others.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] What Wikimedia Research is up to in the next quarter

[Dario Taraborelli]

Hey all,

I’m glad to announce that the Wikimedia Research team’s goals

for
the next quarter (January - March 2016) are up on wiki.

The Research and Data
 team
will continue to work with our volunteers and collaborators on revision
scoring as a service  adding
support for 5 new languages and prototyping new models (including an edit
type classifier
).
We will also continue to iterate on the design of article creation
recommendations
,
running a dedicated campaign in coordination with existing editathons to
improve the quality of these recommendations. Finally, we will extend a
research project we started in November aimed at understanding the behavior
of Wikipedia readers

, by combining qualitative survey data with behavioral analysis from our
HTTP request logs.

The Design Research
 team
will conduct an in-depth study of user needs (particularly readers) on the
ground in February. We will continue to work with other Wikimedia
Engineering teams throughout the quarter to ensure the adoption of
human-centered design principles and pragmatic personas
 in our
product development cycle. We’re also excited to start a collaboration

with
students at the University of Washington to understand what free online
information resources (including, but not limited to, Wikimedia projects)
students use.

I am also glad to report that two papers on link and article
recommendations (the result of a formal collaboration with a team at
Stanford) were accepted for presentation at WSDM '16 and WWW ’16 (preprints
will be made available shortly). An overview on revision scoring as a
service
 was
published a few weeks ago on the Wikimedia blog, and got some good media
coverage

.

We're constantly looking for contributors and as usual we welcome feedback
on these projects via the corresponding talk pages on Meta. You can contact
us for any question on IRC via the #wikimedia-research channel and follow
@WikiResearch  on Twitter for the latest
Wikipedia and Wikimedia research updates hot off the press.

Wishing you all happy holidays,

Dario and Abbey on behalf of the team


*Dario Taraborelli  *Head of Research, Wikimedia Foundation
wikimediafoundation.org • nitens.org • @readermeter

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l