https://blog.wikimedia.org/2014/01/21/wikimedia-israel-winter-hackathon/
Thanks to the folks who put together this event! I would love to hear more
about the "Python script to create a PowerPoint presentation directly from
a Wikipedia article"...
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Thanks to some fantastic work by Erik Bernhardson[0], MediaWiki-Vagrant can
now run MediaWiki on HHVM. The setup runs HHVM behind Apache using FastCGI,
which is a close match to how we think we'll be running it in production.
It uses the 'hhvm-nightly' packages from Facebook, so you can test
MediaWiki core and extensions against cutting-edge builds.
To switch MediaWiki from PHP to HHVM, simply run 'vagrant enable-role
hhvm', followed by 'vagrant provision'. To switch back to PHP, run 'vagrant
disable-role hhvm' and reprovision.
Please try it out and FILE BUGS for any issues you encounter. This includes
not only provisioning failures (which should be reported under the
MediaWiki-Vagrant product in Bugzilla) but also any instances of PHP code
breaking under HHVM. There is now an 'hhvm' keyword in Bugzilla you can use
to tag your report.
Three cheers for Erik B., and for Facebook's Paul Tarjan, whose recent
packaging work makes this possible.
[0]: https://gerrit.wikimedia.org/r/#/c/105834/
---
Ori Livneh
ori(a)wikimedia.org
Following Rob's advice "If it doesn't make it to the mailing list it
didn't happen."
After a chat with Markus Glaser, Mark Hersberger, and Jared Zimmerman at
the Architecture Summit, we have decided to create a wiki page to define
the specifications of this project. Your ideas and feedback are welcome:
https://www.mediawiki.org/wiki/MediaWiki/Gallery_of_extensionshttps://bugzilla.wikimedia.org/show_bug.cgi?id=46704
While we have no idea where the resources to develop this project will
come from, we agree about its importance, and we think that defining a
plan is the obvious first step. Markus & Mark will lead this discussion
as part of their efforts improving MediaWiki as a product for third parties.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
inaugurate the era of ResourceLoader module storage -- an era which
will be marked by terrifying and hilarious new bugs, intermittent
client-side failures, and generally inexcusable disruptions to user
experience. Sounds exciting? Read on!
What is it?
-----------
"Module storage" refers to the use of localStorage in ResourceLoader
as an auxiliary to the browser cache. ResourceLoader, remember, is the
MediaWiki subsystem that delivers JavaScript and CSS to your browser.
One of its primary functions is to minimize the total number of
network requests that your browser needs to make in order to render
the page, and to make the remaining requests as slim as possible. One
of the ways ResourceLoader does this is by making a list of all the
different components your browser needs and then transmitting them in
bulk.
The downside of this approach is that a small update to MediaWiki's
code, touching perhaps one or two components, will often force the
browser to throw out (and re-retrieve) a bunch of unrelated modules
that did not change and did not ostensibly need to be re-retrieved.
This is because the browser cache operates on the level of network
requests; it is not intelligent enough to decompose a request into its
constituitive parts and to cache these parts separately from one
another.
Starting with the 1.23wmf2 branch, ResourceLoader will check if your
browser implements localStorage, a mechanism for storing structure
data. If it does, ResourceLoader will use it as an auxiliary cache,
capable of versioning individual components.
Why?
----
The primary goals are:
* Destabalize MediaWiki's front-end code, by coupling it to an
inconsistently-implemented and poorly-understood HTML5 API.
* Make debugging fun again, by adding another layer of caching to
MediaWiki. Yes!!
However, as with all new features, unintended side-effects are
possible. Specific concerns for module storage include the risk of
making the network footprint of page loads smaller, resulting in
improved latency.
But seriously,
--------------
* Module storage is enabled only if the underlying browser supports
localStorage (~89% of browsers in use, according to
<http://caniuse.com/#feat=namevalue-storage>). Users with older
browsers will not see a benefit, but they will not suffer a penalty
either.
* Module storage may or may not improve site performance. We need to
test it against a wide range of browsers and platforms to know for
certain. If it doesn't improve performance, we'll blame it on you,
your poor choice of browsers, and your uncooperative attitude, but
then we'll scrap it.
How can I test it?
------------------
Glad you asked! Module storage is enabled by default on the beta
cluster, and on test & test2 wikis. The simplest way you can help is
by being alert to to performance regressions and front-end code
breakage. If you know how to use your browser's JavaScript console,
you can get stats about module storage usage on the current page by
checking the value of 'mw.loader.store.stats'.
When the code is rolled out across the cluster, it will be disabled by
default, but you will be able to opt-in by manually setting a cookie
in your browser. I will follow up with the exact details. If module
storage proves stable enough for production use, we'll seek to asses
its utility by running a controlled study of some kind. If we can
demonstrate that module storage leads to a significant improvement in
performance, we'll enable by it default.
---
Ori Livneh
ori(a)wikimedia.org
Hi,
Here, its Nitin Agarwal, Software Developer and Programmer. I am currently
pursuing Computer Science and Engineering at International Institute of
Information Technology, INDIA.
I would like to Wikimedia as Web Developer and Systems Administrator
projects. I have gone through the
https://www.mediawiki.org/wiki/Starter_kitand installed and configured
mediawiki on my machine running at localhost.
I would like to work on the ongoing project works of Wikimedia and carry on
with the project through Gsoc 2014 and afterwards, become a regular
contributor to Wikimedia.
One can see my username as Wikimedia over here :
https://www.mediawiki.org/wiki/User:Nitinagarwal3006
Github : *https://github.com/NitinAgarwal <https://github.com/NitinAgarwal>*
IRC : nitinagarwal3006
--
*Nitin Agarwal*
Website : www.nitinagarwal.in
Ack, sorry for the (no subject); again in the right thread:
> For external uses like XML dumps integrating the compression
> strategy into LZMA would however be very attractive. This would also
> benefit other users of LZMA compression like HBase.
For dumps or other uses, 7za -mx=3 / xz -3 is your best bet.
That has a 4 MB buffer, compression ratios within 15-25% of
current 7zip (or histzip), and goes at 30MB/s on my box,
which is still 8x faster than the status quo (going by a 1GB
benchmark).
Trying to get quick-and-dirty long-range matching into LZMA isn't
feasible for me personally and there may be inherent technical
difficulties. Still, I left a note on the 7-Zip boards as folks
suggested; feel free to add anything there:
https://sourceforge.net/p/sevenzip/discussion/45797/thread/73ed3ad7/
Thanks for the reply,
Randall
Hi folks,
This is an attempt to summarize the list of RFCs that are listed under
this cluster:
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters#HTML_t…
...and possibly get a conversation going about all of this in advance
of the Architecture Summit.
The main focus of all of these RFCs is around HTML generation for user
interface elements. This category is not about wikitext templates or
anything to do with how we translate wikitext markup
"Template Engine" is Chris Steipp's submission outlining the use of
Twig. From my conversations with Chris, it's not so much that he's
eager to adopt Twig specifically so much as standardize on
*something*, and make sure there's usage guidelines around it to avoid
common mistakes. He's seen many attempts at per-extension template
libraries that bloat our code and often start off with big security
vulnerabilities. There are many extensions that use Twig, and it
seems to be a popular choice for new work, so Chris is hoping to
standardize on it and put some usage standards around it.
"HTML templating library" is Ryan Kaldari's submission, promoting the
use of Mustache or something like it. His main motivation is to have
a Javascript template library for front-end work, but is hoping we
choose something that has both Javascript and PHP implementations so
that any PHP template system implementation is compatible with what we
use for Javascript templating.
"MVC Framework" is Owen Davis's description of Wikia's Nirvana
framework, which has been central to all of the user-facing work
they've been doing for the past 2-3 years. As Owen points out in the
talk page for this, it's really view-controller rather than full MVC.
A big plus of adopting this RFC is that it would make it much more
likely that Wikia-developed extensions (of which there are many) would
be of greater use to the larger MediaWiki community, and would
generally help facilitate greater collaboration between Wikia and the
rest of us.
"OutputPage Refactor" is another submission from Owen Davis, which
isn't really about templating, so much as taking the HTML generation
code out of OutputPage. Wikia has been maintaining a fork of
OutputPage for quite some time, so they already have quite a bit of
experience with the proposed changes. This is clustered with the
templating proposals, since I imagine the work that gets factored out
of OutputPage would need to be factored into whatever templating
system we choose.
The first three seem somewhat mutually exclusive, though it's clear
our task is likely to come up with a fourth proposal that incorporates
many requirements of those three. The OutputPage Refactor proposal,
given some fleshing out, may not be controversial at all.
Where should we go from here? Can we make some substantial progress
on moving one or more of these RFCs over the next few weeks?
Rob
Hoi,
At this moment Wikipedia "red links" provide no information whatsoever.
This is not cool.
In Wikidata we often have labels for the missing (=red link) articles. We
can and do provide information from Wikidata in a reasonable way that is
informative in the "Reasonator". We also provide additional search
information on many Wikipedias.
In the Reasonator we have now implemented "red lines" [1]. They indicate
when a label does not exist in the primary language that is in use.
What we are considering is creating a template {{Reasonator}} that will
present information based on what is available in Wikidata. Such a template
would be a stand in until an article is actually written. What we would
provide is information that is presented in the same way as we provide it
as this moment in time [2]
This may open up a box of worms; Reasonator is NOT using any caching. There
may be lots of other reasons why you might think this proposal is evil. All
the evil that is technical has some merit but, you have to consider that
the other side of the equation is that we are not "sharing in the sum of
all knowledge" even when we have much of the missing requested information
available to us.
One saving (technical) grace, Reasonator loads round about as quickly as
WIkidata does.
As this is advance warning, I hope that you can help with the issues that
will come about. I hope that you will consider the impact this will have on
our traffic and measure to what extend it grows our data.
The Reasonator pages will not show up prettily on mobile phones .. so does
Wikidata by the way. It does not consider Wikipedia zero. There may be more
issues that may require attention. But again, it beats not serving the
information that we have to those that are requesting it.
Thanks,
GerardM
[1]
http://ultimategerardm.blogspot.nl/2014/01/reasonator-is-red-lining-your-da…
[2] http://tools.wmflabs.org/reasonator/test/?lang=oc&q=35610
Hello everyone,
It’s with great pleasure that I’m announcing that Sam Smith[1] has joined the WIkimedia Foundation as a Software Engineer in Features Engineering. He'll be working with the Growth team.[2]
Before joining us, Sam was previously a member of the Last.fm web team (web-slingers) where he helped to build the new catalogue pages, the Last.fm Spotify app, the new (the only) user on-boarding flow, and helped immortalise his favorite band (Maybeshewill) in most of their unit test cases. Before that he worked on everything from Java job schedulers, to Pascal windows installers, to Microsoft server sysadmining, to Zend Framework and symfony migrations. Ask him which was the was the worst—my money is on the PHP migration[3]. He received his Masters Degree in physics at the University of Warwick.
Sam is based in London (the capital of England, not the city in Ontario or the settlement the island of Kiribati). He lives in Surray Quays with his wife, Lisa, and his 19 month old son, George. His hobbies include juggling (he's juggled for 6 years), unicycling (one day he's going to attempt the distance record… one day!), climbing (specifically bouldering, he's actually really afraid of heights), coffee (it's not really a hobby, it's an obsession), and playing Lineage 1[4]. Ask him to do some unicycling up a boulder while drinking coffee and playing Lineage… now that would be juggling!
His first official day is today, Tuesday, January 21, 2013. (What? On time? He signed his contract last year, so I had a lot of time to prepare. Having said that, I didn't start this e-mail until this morning so balance has been restored to the force.)
Please join me in a not-belated welcome of Sam Smith to the Wikimedia Foundation. :-)
Take care,
terry
P.S. Because Jared is demanding we include a picture for new staff and contractors, here is one[5]:
[1] https://github.com/phuedx
[2] https://www.mediawiki.org/wiki/Growth
[3] http://www.codinghorror.com/blog/2012/06/the-php-singularity.html
[4] http://en.wikipedia.org/wiki/Lineage_(video_game)
[5] http://en.wikipedia.org/wiki/Heston_Blumenthalhttps://commons.wikimedia.org/wiki/File:Heston_Blumenthal_Chef_Whites.jpg
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
> For external uses like XML dumps integrating the compression
> strategy into LZMA would however be very attractive. This would also
> benefit other users of LZMA compression like HBase.
For dumps or other uses, 7za -mx=3 / xz -3 is your best bet.
That has a 4 MB buffer, compression ratios within 15-25% of
current 7zip (or histzip), and goes at 30MB/s on my box,
which is still 8x faster than the status quo (going by a 1GB
benchmark).
Trying to get quick-and-dirty long-range matching into LZMA isn't
feasible for me personally and there may be inherent technical
difficulties. Still, I left a note on the 7-Zip boards as folks
suggested; feel free to add anything there:
https://sourceforge.net/p/sevenzip/discussion/45797/thread/73ed3ad7/
Thanks for the reply,
Randall
On Tue, Jan 21, 2014 at 2:19 PM, Randall Farmer <randall(a)wawd.com> wrote:
> > For external uses like XML dumps integrating the compression
> > strategy into LZMA would however be very attractive. This would also
> > benefit other users of LZMA compression like HBase.
>
> For dumps or other uses, 7za -mx=3 / xz -3 is your best bet.
>
> That has a 4 MB buffer, compression ratios within 15-25% of
> current 7zip (or histzip), and goes at 30MB/s on my box,
> which is still 8x faster than the status quo (going by a 1GB
> benchmark).
>
> Re: trying to get long-range matching into LZMA, first, I
> couldn't confidently hack on liblzma. Second, Igor might
> not want to do anything as niche-specific as this (but who
> knows!). Third, even with a faster matching strategy, the
> LZMA *format* seems to require some intricate stuff (range
> coding) that be a blocker to getting the ideal speeds
> (honestly not sure).
>
> In any case, I left a note on the 7-Zip boards as folks have
> suggested: https://sourceforge.net/p/sevenzip/discussion/45797/thread/73ed3ad7/
>
> Thanks for the reply,
> Randall
>
>
