Hey Tauhida,
Welcome onboard! Great to have you looking at TMH :-)
Alolita
On Tue, Apr 17, 2012 at 12:05 PM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> Welcome to the madhouse, Tauhida! It's great to have you :).
>
> On 17 April 2012 19:42, Chris McMahon <cmcmahon(a)wikimedia.org> wrote:
>>
>>
>>
>> Dr. Tauhida Parveen completed her PhD in Computer Science from Florida
>> Institute ofTechnology with a research focus in software testing and cloud
>> computing. She has over 10 years of teaching experience, as a teaching
>> assistant, instructor, and is now an adjunct faculty member in the
>> Department of Engineering Systems at Florida Institute of Technology.
>>
>> She is also an independent consultant specializing in software testing and
>> quality assurance, She has been a software test engineer at Millennium
>> Engineering and Integration, SAP, Yahoo!, Sabre Holdings, and Progressive
>> Auto Insurance.
>>
>> Tauhida will be helping to test the Timed Media Handler among other
>> projects. You’ll probably see her editing test charters on mediawiki.org
>> and filing bugs associated with many different projects.
>>
>> _______________________________________________
>> Wmfall mailing list
>> Wmfall(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
>
>
>
> --
> Oliver Keyes
> Community Liaison, Product Development
> Wikimedia Foundation
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
--
Alolita Sharma
Director of Engineering
Wikimedia Foundation
Guys,
I've updated Widgets extension to support latest version of
FlaggedRevisions, but no longer have repo access as MW moved to Git.
If somebody can patch the extension for me, I'll really appreciate that -
here's the diff (not much work):
Index: extensions/Widgets/WidgetRenderer.php
===================================================================
--- extensions/Widgets/WidgetRenderer.php (revision 114929)
+++ extensions/Widgets/WidgetRenderer.php (working copy)
@@ -137,7 +137,7 @@
if ( $widgetTitle && $widgetTitle->exists() ) {
if ( $wgWidgetsUseFlaggedRevs ) {
- $flaggedWidgetArticle = FlaggedArticle::getTitleInstance( $widgetTitle );
+ $flaggedWidgetArticle = FlaggableWikiPage::getTitleInstance(
$widgetTitle );
$flaggedWidgetArticleRevision = $flaggedWidgetArticle->getStableRev();
if ( $flaggedWidgetArticleRevision ) {
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/http://www.meetup.com/Web-Performance-NY/http://www.showslow.com/
Hey,
Two of my extensions, Maps and Semantic Maps, seem to have lost most of
their history during git migration (my other extensions are fine as far as
I can tell). I really would like them to have all the history and looked
into how to fix this a bit. Doing a "git svn co" of the code in SVN gave me
a git repo with all the history. So now my question is how I can either
push this history to the WMF hosted repo somehow, or replace the current
repo with the one I created myself. I'm not sure if the former is possible
in a sane way, and suspect I need help from someone with more gerrit
privileges for the later.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
As QA Lead for WMF, one of the things I want to do is to create an
institutional suite of automated cross-browser regression tests using
Selenium. I have two goals for this suite: first, to make it attractive
and convenient for the greater software testing community to both use the
suite locally and also to contribute to it. Second, to have the suite be a
useful regression test tool within WMF, tied to Beta Labs and controlled by
Jenkins.
For various reasons, I think the best language for this project is Ruby. I
realize that is a controversial choice, and I would like to explain my
reasoning. First let me address what I think will be the most serious
objections:
** Ruby gems are incompatible with Debian/Ubuntu apt packaging, making it
difficult or impossible to maintain Ruby code in production.
The selenium test suite is not intended to run on production servers.
There are two targets for this code. The first target is users' local
machines, including and especially Windows users. The second target is a
single dedicated headless Labs Ubuntu instance, controlled by Jenkins,
serving as a client to selenium-server, where selenium-server is running on
the various Windows etc. VMs that exist today on the WMF VPN.
** It's not PHP.
As of today, PHP has no complete or authoritative implementation of
selenium-webdriver/Selenium 2.0. That situation is unlikely to change any
time soon. This leaves a choice of Ruby or Python. For various reasons I
think Ruby is the superior choice.
** Design goals and their implementation.
In the interest of making this project as attractive as possible to the
greater testing community, I have defined a browser automation "stack",
using the most current and accepted practices for browser test automation.
The stack looks like this:
* Selenium-webdriver low-level "toolbox" API.
* Higher-level API for consistent access to pages and elements without the
user having to create their own handling for timeouts, exceptions, "stale
objects", multiple access criteria, etc.
* Modern, BDD-style assertions for pass/fail criteria (as opposed to xUnit
style assertions)
* "Page Object" design pattern in place and functioning out of the box
* Support for mobile emulators
* Institutional support for Jenkins integration
I submit that having these things in place and working when the user
downloads the suite is what will make this project attractive to the global
testing community.
Taking these point by point:
Even as I write this, the W3C is meeting in London to approve webdriver as
an internet standard, with Selenium 2.0 as the reference implementation of
that standard. This means that the selenium 2.0 API is only a fraction the
size of that of Selenium 1.0, and serves a very different purpose. The
selenium 2.0 API can be considered a "toolbox" from which higher-level APIs
are constructed. Both Ruby and Python have full implementation and support
for the Selenium 2.0 API.
At higher levels of the stack, the Python and Ruby communities take
different design approaches, with Python being more DIY/NIH and Ruby being
more shared and organized around communities of practice. This is what
makes Ruby so attractive as I implemented the rest of the stack.
Watir (Web Application Testing In Ruby) is a browser test project that
pre-dates Selenium itself. Watir provides an intuitive, thoughtful,
well-designed high-level API for access to pages and elements that the
native selenium-webdriver API does not. While historically Watir and
Selenium have been different projects, as of about 2010 watir-webdriver is
simply a wrapper for the low-level selenium API that preserves all of the
convenience and good design Watir has always had. Watir is in use today at
Facebook, The Gap, and many other places. Python has no such equivalent
high-level API.
Behavior Driven Development (BDD) style assertions are implemented in Ruby
with the Rspec library. This approach to assertions has been a generally
accepted standard in the Ruby community for some time. "The Rspec Book"
was published by Pragmatic Press in 2010. Python has no equivalent
BDD-style assertion library. In fact, Rspec takes advantage of Ruby's
affordance for metaprogramming, something not possible in Python.
"Page Objects" is a design pattern for browser testing that has become a
generally accepted practice in the browser testing community, with a lot of
momentum particularly in the last one or two years. Page Objects have
institutional support in Ruby with the 'page-object' gem, which supports
both watir-webdriver and selenium-webdriver syntax. Python has no such
institutional support for page objects, each Python project using page
objects implements the pattern locally, from scratch.
Some support for mobile emulators is provided by Ruby's
webdriver-user-agent gem, created by Alister Scott of Thoughtworks. This
gem piggybacks on either the watir-webdriver or selenium-webdriver APIs in
Ruby. I am unaware of any such mobile emulator support in Python.
Ruby selenium tests are run via 'rake', the Ruby version of make. Jenkins
has an officially supported plugin for rake.
Both Ruby and Python are viable choices for this project. The difference
is that Python would require a lot of custom infrastructure and
scaffolding, with all of the risk and maintenance that that entails, where
support for the elements of the "stack" in Ruby is already in place,
well-designed, and supported by the greater Ruby community. Not only does
this make maintenance of the stack for WMF purposes much simpler, it also
makes the project significantly more attractive to casual users in the
testing community who can get started with the suite immediately by simply
installing a few gems locally and reading some public documentation, rather
than having to face a daunting pile of custom code.
For reference and further research, I created a prototype of this project
that implements this stack here:
https://github.com/chrismcmahon/Page-Object-WMF-spike
Addendum: I am aware of two projects at WMF already using Selenium, one
with OmniTI for AFTv5, the other from Jeremy Postlethwaite. Since the
purpose of this project is to attract members of the global testing
community, and to provide an institutional regression test suite for
Mediawiki/Wikipedia, I see no reason to require individual WMF projects to
use this framework, although I suspect that individual WMF projects might
find this framework more convenient than other approaches.
In the last few days I've updated the Math extension's experimental MathJax
support to where it can actually be enabled by individual users. If all
goes well with review I'd love to get this deployed soon so the math-heads
can turn it on and check for lingering incompatibilities...
MathJax [http://www.mathjax.org/] is a client-side JavaScript library for
parsing TeX or MathML code and rendering it in just about any modern
browser -- it even works back to IE 6! -- using webfonts and HTML/CSS,
MathML, or SVG as available.
Here's a sample page on a test wiki, copied from en.wikipedia:
http://leuksman.com/mw/index.php/Alpha_compositing
This update to the extension builds on Nageh's work setting up an earlier
version of MathJax as a user script, plus some help from the MathJax devs
on their mailing list. Thanks guys!
Big advantages of this over our current server-side math rendering:
* font size & baseline match up with surrounding text for inline equations!
* subpixel antialiasing or high-dpi displays allow math to render more
sharply at default size
* scalable -- you can zoom in your browser and things stay sharp
* printable -- printed output also stays sharp (some browsers have font
issues with some modes; to be experimented with)
* in-browser zoom & copy-paste helpers
And of course:
* a strong open-source community maintaining it, who are happy to help us
with integration and any needed fixes
* it's not ocaml ;)
The additions to Math extension add a third 'MathJax' rendering mode which
users can opt in to at Special:Preferences. This replaces the older HTML
and MathML rendering modes that we already disabled in 1.19.
In the future when we've worked out the kinks, we can turn that into the
default, and continue to use it as a fallback renderer for non-JavaScript
browsers. (A nicer math edit/preview tool would be awesome too, especially
for confirming that things work in both renderers in the future!)
Revs that'll need to be reviewed & deployed:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/mathjax
WikiProject:Mathematics talk page section:
https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics#mathJa…
-- brion
Hi!
I would love to be able to manage my settings in one place - skins,
language, gender etc. - rather than having to guess which option is which
in a foreign language where I may even have chosen Cologne Blue in some
distant past...
I have found no way in the current setup to do so. Am I overlooking
something?
Regards,
Ole
--
http://palnatoke.org * @palnatoke * +4522934588
Hi everyone,
I’d like to introduce Chris Steipp, who starts today as our Senior
Security Engineer. Chris comes to us from Global Media Outreach,
where he served as their CTO. Before that, he worked at Novacoast,
doing security consulting. He went to school at Royal Hollaway in
Egham, UK (just outside London).
The Software Security Engineer was originally conceived as a means of
increasing our code review capacity. One bottleneck in our code review
process was when a specific security review was needed, because most
people aren’t as confident in themselves to perform a specific review
for security, nor confident in each other. That led to a situation
where we had one person (Tim Starling) who would be the bottleneck for
complicated security reviews. Now with Chris on board, we have
someone (else) whose job it is to do security reviews.
However, that won't be Chris's sole responsibility. A lot of Chris's
time will be spent designing and developing new features and enhancing
existing features of Wikimedia systems, with a particular focus on
features requiring expertise in security (such as improved HTTPS
support, better/different authentication features, and other handling
of sensitive data).
Chris is a friendly and enthusiastic teacher, and is planning to lead
secure development training for the organization.
Chris lives here in the SF Bay area with his (soon to be growing)
family. Please join me in welcoming Chris!
Rob
At the moment, in the Lua support extension we have been developing,
wikitext is output to the wiki via the return value of a function. For
example in wikitext you would have:
{{#invoke:MyModule|myFunction}}
Then in [[Module:MyModule]]:
local p = {}
function p.myFunction()
return 'Hello, world!'
end
return p
This is all nice and elegant and will work. There is an alternative
convention commonly used in scripting languages (and programming in
general for that matter), using a print function:
local p = {}
function p.myFunction()
print('Hello, world!')
end
return p
I would have been happy to leave it as Victor Vasiliev made it, i.e.
using return values, but I happened across a performance edge case in
Lua which made me think about it. Specifically, this:
function foo(n)
s = ''
for i = 1, n do
s = s .. toString(i)
end
return s
end
has O(n^2) running time. For 100,000 iterations it takes 5 seconds on
my laptop. Apparently this is because strings are immutable, so the
accumulator needs to be copied for each concatenation. It's very
similar to the situation in Java, where a StringBuffer needs to be
used in such an algorithm.
It's easy enough to work around, but the problem is obscure enough
that I think probably most of our users will not realise they need to
work around it until it becomes severe.
It would be possible to provide a print() function which does not
suffer from this problem, i.e.
function foo(n)
for i = 1, n do
print(i)
end
end
could run in O(n log(n)) time. Intuitively, I would expect that
providing such a print function would encourage a programming style
which would avoid at least some instances of repetitive concatenation.
The performance issue is probably no big deal, since most templates
are probably not going to be concatenating hundreds of thousands of
strings, and 5 seconds is still quicker than the time it takes most of
our featured articles to render at the moment. But like I say, it got
me thinking about it.
Does anyone have any thoughts on return versus print generally? Are
there other reasons we would choose one over the other?
-- Tim Starling