Re: [Wikitech-l] performance guidelines - need good and bad examples
On 05/08/2014 01:27 AM, Sumana Harihareswara wrote: I think I've articulated our key performance principles, and am looking for good and bad examples. Our performance guidelines will be a set of values/principles, each one with a good example and a bad example drawn from our own experience. Here's the list: https://www.mediawiki.org/wiki/Performance_guidelines#General_performance_principles Please feel free to paste links on the talk page, saying whether it's a good or bad example - I will add prose and explanation. I'll also be gathering examples on Friday at the Zurich hackathon. I want to polish this and get it approved during the hackathon. (I'm still cleaning up the detailed explanation of each principle.) RfC we can use to discuss larger questions: https://www.mediawiki.org/wiki/Requests_for_comment/Performance_standards_for_new_features These guidelines are a lot more readable and helpful now, but I still need help with good and bad examples for: Choose the right persistence layer for your needs: Redis job queue, MariaDB database, Swift file store, or memcached cache. Wikimedia uses and depends heavily on many different caching layers, so your code needs to work in that environment! (But it also must work if everything misses cache.) And I need the *code* for good and bad examples of: Users should have a smooth experience; different components should render progressively. Preserve positioning of elements (e.g. avoid pushing content in a reflow). -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Help with Bug 61900 - Invalid Ogg file: Stream Undecodable
Dear all, is anyone here at the hackathon in Zurich who can help us with moving forward on this bug? https://bugzilla.wikimedia.org/show_bug.cgi?id=61900 It's strange to see files display fine if accessed directly like https://commons.wikimedia.org/wiki/File:Treadmill-Exercise-Induces-Neutrophil-Recruitment-into-Muscle-Tissue-in-a-Reactive-Oxygen-Species-pone.0096464.s002.ogv or after download but not via their file pages on Commons, like https://commons.wikimedia.org/wiki/File:Treadmill-Exercise-Induces-Neutrophil-Recruitment-into-Muscle-Tissue-in-a-Reactive-Oxygen-Species-pone.0096464.s002.ogv . Any pointers appreciated. Thanks, Daniel -- http://www.naturkundemuseum-berlin.de/en/institution/mitarbeiter/mietchen-daniel/ https://en.wikipedia.org/wiki/User:Daniel_Mietchen/Publications http://okfn.org http://wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help with Bug 61900 - Invalid Ogg file: Stream Undecodable
Might be an issue with the JavaScript decoder/player process that is used on wiki. While direct access and downloaded relies on other methods On Saturday, May 10, 2014, Daniel Mietchen daniel.mietc...@googlemail.com wrote: Dear all, is anyone here at the hackathon in Zurich who can help us with moving forward on this bug? https://bugzilla.wikimedia.org/show_bug.cgi?id=61900 It's strange to see files display fine if accessed directly like https://commons.wikimedia.org/wiki/File:Treadmill-Exercise-Induces-Neutrophil-Recruitment-into-Muscle-Tissue-in-a-Reactive-Oxygen-Species-pone.0096464.s002.ogv or after download but not via their file pages on Commons, like https://commons.wikimedia.org/wiki/File:Treadmill-Exercise-Induces-Neutrophil-Recruitment-into-Muscle-Tissue-in-a-Reactive-Oxygen-Species-pone.0096464.s002.ogv . Any pointers appreciated. Thanks, Daniel -- http://www.naturkundemuseum-berlin.de/en/institution/mitarbeiter/mietchen-daniel/ https://en.wikipedia.org/wiki/User:Daniel_Mietchen/Publications http://okfn.org http://wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; 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] Advice needed for MediaWiki-Vagrant problem
Vagrant 1.6 changed the order of steps Vagrant performs on initialization: it now evaluates the project's Vagrantfile after loading plugins and parsing command-line arguments. This means that the various subcommands provide for role management no longer work, since the relevant plugins are loaded from the top of Vagrantfile, which is now too late a stage to be loading plugins. Loading plugins from Vagrantfile was always a bit of a hack, but it was a good hack that allowed us to bridge over a complicated plugin packaging process and provide a tailored Vagrant experience right from 'vagrant up'. I'd like to fix this without adding steps to the installation process, but I'm not sure how. I spent a few hours bashing my head against this problem earlier today and didn't get anywhere. I would really welcome a creative solution. The relevant bug is https://bugzilla.wikimedia.org/show_bug.cgi?id=65066 , originally reported by Robert Vogel. Ori ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Roadmap and deployment update - week of May 12th
Hello and welcome to the latest edition of the WMF Engineering Roadmap and Deployment update. The full log of planned deployments next week can be found at: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_May_12th A quick list of notable items... == Tuesday == * MediaWiki deploy ** group1 to 1.24wmf4: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf4 == Wednesday == * Enable VisualEditor on Commons as a Beta Feature ** https://www.mediawiki.org/wiki/VisualEditor ** https://www.mediawiki.org/wiki/Beta_Features == Thursday == * MediaWiki deploy ** group2 to 1.24wmf4 (all Wikipedias) ** group0 to 1.24wmf5 (test/test2/testwikidata/mediawiki) * MediaViewer ** Will be enabled on Wikimedia Commons ** https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Timeline Thanks and as always, questions and comments welcome, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] recent changes stream
I've fiddled around with this a bit:
On my Ubuntu system, I simply got a library: sudo pip install
socketio-client
Then made this Python script:
---
from socketIO_client import SocketIO, BaseNamespace
class RecentChangeNamespace(BaseNamespace):
def on_connect(self):
self.emit('subscribe', ['enwiki'])
def on_change(self, data):
print(data)
socketIO = SocketIO('rcstream.wmflabs.org') # This host seems to be sending
the same example entries at the moment, obviously we should get an actual
RC stream from it or a production host later
socketIO.define(RecentChangeNamespace, '/rc')
socketIO.wait()
---
And it prints entries to console like this (Python just prints out objects
in a way that kind of looks like JSON):
{u'comment': u'', u'wiki': u'enwiki', u'type': 0, u'title': u'Main Page',
u'timestamp': 1398993841, u'server_script_path': u'/w', u'namespace': 0,
u'server_url': u'http://en.wikipedia.beta.wmflabs.org', u'length': {u'new':
585, u'old': 580}, u'user': u'Alice', u'patrolled': True, u'bot': False,
u'id': 9, u'minor': True, u'revision': {u'new': 9, u'old': 8}}
It's so much nicer. Sorry Petr, I think this is much more suitable than the
mess that is connecting to IRC and parsing everything. I definitely want to
see this replace the IRC feed entirely (with the obvious reasonably long
deprecation period).
Alex
On 5 May 2014 10:29, Petr Bena benap...@gmail.com wrote:
Given the current specifications I can only support this change as
long as current IRC feed is preserved as IRC is IMHO, as much as evil
it looks, more suitable for this than WebSockets.
I am not saying that IRC is suitable for this and I know that people
really wanted to get rid of it or replace it with something better,
but I just can't see how is this better.
On Mon, May 5, 2014 at 10:37 AM, Daniel Kinzler dan...@brightbyte.de
wrote:
Am 05.05.2014 07:20, schrieb Jeremy Baron:
On May 4, 2014 10:24 PM, Ori Livneh o...@wikimedia.org wrote:
an implementation for a recent changes
stream broadcast via socket.io, an abstraction layer over WebSockets
that
also provides long polling as a fallback for older browsers.
[...]
How could this work overlap with adding pubsubhubbub support to existing
web RC feeds? (i.e. atom/rss. or for that matter even individual page
history feeds or related changes feeds)
The only pubsubhubbub bugs I see atm are
https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=38970%2C30245
There is a Pubsubhubbub implementation in the pipeline, see
https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FPubSubHubbub.
It's
pretty simple and painless. We plan to have this deployed experimentally
for
wikidata soon, but there is no reason not to roll it out globally.
This implementation uses the job queue - which in production means
redis, but
it's pretty generic.
As to an RC *stream*: Pubsubhubbub is not really suitable for this,
since it
requires the subscriber to run a public web server. It's really a
server-to-server protocol. I'm not too sure about web sockets for this
either,
because the intended recipient is usually not a web browser. But if it
works,
I'd be happy anyway, the UDP+IRC solution sucks.
Some years ago, I started to implement an XMPP based RC stream, see
https://www.mediawiki.org/wiki/Extension:XMLRC. Have a look and steal
some
ideas :)
-- daniel
___
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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
