Re: [Wikitech-l] ResourceLoader, now in trunk!
2010/9/7 Platonides platoni...@gmail.com: I see. It would have to be a hook into the resource loader. You don't need a hook in the server-side PHP part of the resource loader, as determining which modules to load on that side is already supported. The Gadgets extension's PHP code could inspect variables like $wgTitle-getNamespace() and determine whether to load a certain gadget or not. This is easy as far as the resource loader goes, but it does mean the server has to make this decision based on information in the gadget's code or the gadget definition page. This is significantly less flexible than allowing a gadget to just provide a JS function that returns true or false, but the fact that the decision has to be made client-side makes it a bit trickier. It's still very much doable, although the way I proposed is a little bit hacky and we may want to have the client-side loader support this better. Or did you mean a hook into the client-side loader? Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
2010/9/7 Dmitriy Sintsov ques...@rambler.ru: Do browsers support streamed and combined (archive-like) gz-encoded content? Then probably minifying will not be neccessary. Minification makes a shocking difference: remember that it's not just whitespace being stripped, it's comments as well. For example, in /trunk/extensions/UsabilityInitiative/js we have: plugins.combined.js: 259281 bytes plugins.combined.min.js: 142565 bytes plugins.combined.js.gz: 65569 bytes plugins.combined.min.js.gz: 32740 bytes So not only is the minified JS roughly half the size in both the compressed and the uncompressed cases, it actually /compresses better/ (3.95x vs. 4.35x). Also, it would be great if these high-level JS-libraries like jQuery actually were ported into DOM API level (native browser's implementation instead of extra JS layer). However, these questions are to FF/IE/Opera developers... I definitely think this is the future, provided it's implemented reliably cross-browser. Also, you'd probably want to have a fallback library for browsers that have no or incomplete (e.g. missing a jQuery feature that's newer than the browser) native support. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
On 07/09/10 17:44, Roan Kattouw wrote:
2010/9/7 Dmitriy Sintsov ques...@rambler.ru:
Do browsers support streamed and combined (archive-like) gz-encoded
content? Then probably minifying will not be neccessary.
Minification makes a shocking difference: remember that it's not just
whitespace being stripped, it's comments as well. For example, in
/trunk/extensions/UsabilityInitiative/js we have:
plugins.combined.js: 259281 bytes
plugins.combined.min.js: 142565 bytes
plugins.combined.js.gz: 65569 bytes
plugins.combined.min.js.gz: 32740 bytes
So not only is the minified JS roughly half the size in both the
compressed and the uncompressed cases, it actually /compresses better/
(3.95x vs. 4.35x).
Note that the advantage of minification is somewhat inflated due to
the nature of the source. There seems to be a because we can element
to it: because the developers are so impressed by the concept of
minification, they write excessively verbose and excessively many
comments. For example:
// create the span wrapper for the matched text
var spannode = document.createElement( 'span' );
spannode.className = 'highlight';
// shave off the characters preceding the matched text
var middlebit = node.splitText( pos );
// shave off any unmatched text off the end
middlebit.splitText( pat.length );
// clone for appending to our span
var middleclone = middlebit.cloneNode( true );
// append the matched text node to the span
spannode.appendChild( middleclone );
// replace the matched node, with our span-wrapped clone of the
matched node
middlebit.parentNode.replaceChild( spannode, middlebit );
Or a doc comment:
/**
* This plugin provides a generic way to add suggestions to a text box.
*
* Usage:
*
* Set options:
* $('#textbox').suggestions( { option1: value1, option2: value2 }
);
* $('#textbox').suggestions( option, value );
* Get option:
* value = $('#textbox').suggestions( option );
* Initialize:
* $('#textbox').suggestions();
*
* Options:
*
* fetch(query): Callback that should fetch suggestions and set the
suggestions property. Executed in the context of the
* textbox
* Type: Function
* cancel: Callback function to call when any pending asynchronous
suggestions fetches should be canceled.
* Executed in the context of the textbox
* Type: Function
* special: Set of callbacks for rendering and selecting
* Type: Object of Functions 'render' and 'select'
* result: Set of callbacks for rendering and selecting
* Type: Object of Functions 'render' and 'select'
* $region: jQuery selection of element to place the suggestions below
and match width of
* Type: jQuery Object, Default: $(this)
* suggestions: Suggestions to display
* Type: Array of strings
* maxRows: Maximum number of suggestions to display at one time
* Type: Number, Range: 1 - 100, Default: 7
* delay: Number of ms to wait for the user to stop typing
* Type: Number, Range: 0 - 1200, Default: 120
* submitOnClick: Whether to submit the form containing the textbox
when a suggestion is clicked
* Type: Boolean, Default: false
* maxExpandFactor: Maximum suggestions box width relative to the
textbox width. If set to e.g. 2, the suggestions box
* will never be grown beyond 2 times the width of the textbox.
* Type: Number, Range: 1 - infinity, Default: 3
* positionFromLeft: Whether to position the suggestion box with the
left attribute or the right
* Type: Boolean, Default: true
* highlightInput: Whether to hightlight matched portions of the input
or not
* Type: Boolean, Default: false
*/
I think it's ironic that this style arises in JavaScript, given that
it's a high-level language and relatively easy to understand, and that
you could make a technical case in favour of terseness. C has an
equally effective minification technique known as compilation, and its
practitioners tend to be terse to a fault. For instance, many Linux
kernel modules have no comments at all, except for the license header.
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
2010/9/7 Tim Starling tstarl...@wikimedia.org: Note that the advantage of minification is somewhat inflated due to the nature of the source. There seems to be a because we can element to it: because the developers are so impressed by the concept of minification, they write excessively verbose and excessively many comments. For example: [...] I think it's ironic that this style arises in JavaScript, given that it's a high-level language and relatively easy to understand, and that you could make a technical case in favour of terseness. C has an equally effective minification technique known as compilation, and its practitioners tend to be terse to a fault. For instance, many Linux kernel modules have no comments at all, except for the license header. I don't think terseness is a good thing necessarily. Some comments are unnecessarily verbose, yes (your first example, for instance), but I think Javadoc-style comments for non-trivial functions are essential, and class/file/interface comments describing an interface other code can interact with (your second example) are also very useful. Both, especially the former, are used throughout MediaWiki's PHP code, and the JS code is no exception. I also don't think that the verbosity you mentioned is caused by a because we can mentality, but rather by the authors themselves: 2 of the 3 main authors of UsabilityInitiative have a habit of writing verbose comments, both in JS and in PHP. (I remember you criticizing PHP code written by Trevor in July 2009 for containing comments verbose to the point of almost insulting the reader's intelligence.) However, clear and adequately complete documentation should not be confused for excessive verbosity. I agree that your second example is a long doc comment, but I don't think it's excessive for what it's supposed to be documenting (the interface to .suggestions(), which takes 12 arguments of various types and with various semantics, allowed values and default values). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
Hi, On Tue, Sep 7, 2010 at 9:44 AM, Roan Kattouw roan.katt...@gmail.com wrote: Also, it would be great if these high-level JS-libraries like jQuery actually were ported into DOM API level (native browser's implementation instead of extra JS layer). However, these questions are to FF/IE/Opera developers... I definitely think this is the future, provided it's implemented reliably cross-browser. Also, you'd probably want to have a fallback library for browsers that have no or incomplete (e.g. missing a jQuery feature that's newer than the browser) native support. Please, no. The various browsers all have their problems with standards even now, and I don't expect they'd get a jquery (or whatever JS framework) clientside implemented without having all sorts of problems. Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - test run configuration data
Hi, Great, that there is some further discussion and progress in Selenium testing going on. However, up to now I have been following the manual at [1] which Markus Glaser has updated recently but which now is out-of-date. I have figured out some of your changes and almost got the framework working. But still, SimpleSeleniumTestSuite/SimpleSeleniumTestCase do not work due to a call_user_func_array() error. Apparently, some methods cannot be found. I was wondering whether it would be possible to update the manual at [1] if there are any changes to the framework concerning its usage. Regards, Benedikt -- Karlsruhe Institute of Technology (KIT) Institute of Applied Informatics and Formal Description Methods (AIFB) Benedikt Kämpgen Research Associate Kaiserstraße 12 Building 11.40 76131 Karlsruhe, Germany Phone: +49 721 608-7946 Fax: +49 721 608-6580 Email: benedikt.kaemp...@kit.edu Web: http://www.kit.edu/ KIT - University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association -Original Message- From: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Mark A. Hershberger Sent: Tuesday, September 07, 2010 5:15 AM To: Wikimedia developers Subject: Re: [Wikitech-l] Selenium Framework - test run configuration data Dan Nessett dness...@yahoo.com writes: Last Friday, mah ripped out the globals and put the configuration information into the execute method of RunSeleniumTests.php with the comment @todo Add an alternative where settings are read from an INI file. So, it seems we have dueling developers with contrary ideas about what is the best way to configure selenium framework tests. I'm opposed to increasing global variables and I think I understand Tim's concern about configuring via a PHP file. I plan to start work on reading the configuration from an INI file (*not* a PHP file). Either approach works. But, by going back and forth, it makes development of functionality for the Framework difficult. I agree. The idea I was pursuing is to encapsulate configuration in a Selenium object that (right now) RunSeleniumTests.php will set up. Platonides suggestion of a hook to provide configuration is also doable. Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ 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] Selenium Framework - test run configuration data
Dan Nessett dness...@yahoo.com writes: Either approach works. But, by going back and forth, it makes development of functionality for the Framework difficult. I should also point out that what I was planning to do was not hidden. I wrote about these changes in my weekly report the Monday before I committed them (http://bit.ly/cqAcqz) and pointed to the weekly report from my Ohloh, Twitter, Identi.ca and Facebook accounts. Granted, this is not the same as posting to the mailing list, and for that I apologize. Looking back in the archives on gmane, it looks like you are very interested in MW testing. Since this is a large part of my focus currently as well, perhaps we should coordinate our work? Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - test run configuration data
On Mon, 06 Sep 2010 23:15:06 -0400, Mark A. Hershberger wrote: Dan Nessett dness...@yahoo.com writes: Last Friday, mah ripped out the globals and put the configuration information into the execute method of RunSeleniumTests.php with the comment @todo Add an alternative where settings are read from an INI file. So, it seems we have dueling developers with contrary ideas about what is the best way to configure selenium framework tests. I'm opposed to increasing global variables and I think I understand Tim's concern about configuring via a PHP file. I plan to start work on reading the configuration from an INI file (*not* a PHP file). Either approach works. But, by going back and forth, it makes development of functionality for the Framework difficult. I agree. The idea I was pursuing is to encapsulate configuration in a Selenium object that (right now) RunSeleniumTests.php will set up. Platonides suggestion of a hook to provide configuration is also doable. Mark. I am pretty much agreeable to any solution that remains stable. One thing that may not be obvious is there may be configuration data over and above that specified on the RunSeleniumTests command line. For example, it is inconvenient to have to start up the selenium server before running RunSeleniumTests. (In the past I have frequently executed RunSeleniumTests only to get an error because I forgot to start the server). I supplied a patch to Markus recently that adds two options to the command line, one to start the server and the other to stop it (the patch supplies functionality only for *nix systems, which is probably why Markus has not committed it - there needs to be similar support for Windows). This functionality requires a directory path to the selenium server jar file. This is not something that a tester would normally supply on a command line. It is a system, not a test run parameter. So, I hope the INI file processing you are working on will allow the specification of such data. -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - test run configuration data
I would be happy to coordinate with you. Up to this point I have been working with Markus Glaser and that has gone pretty well. But, I would welcome more discussion on issues, architecture and implementation strategy for the Framework as well as making sure anything I do fits in with what others are doing. Regards, Dan --- On Tue, 9/7/10, Mark A. Hershberger m...@everybody.org wrote: From: Mark A. Hershberger m...@everybody.org Subject: Re: Selenium Framework - test run configuration data To: Wikimedia developers wikitech-l@lists.wikimedia.org Cc: Dan Nessett dness...@yahoo.com Date: Tuesday, September 7, 2010, 8:04 AM Dan Nessett dness...@yahoo.com writes: Either approach works. But, by going back and forth, it makes development of functionality for the Framework difficult. I should also point out that what I was planning to do was not hidden. I wrote about these changes in my weekly report the Monday before I committed them (http://bit.ly/cqAcqz) and pointed to the weekly report from my Ohloh, Twitter, Identi.ca and Facebook accounts. Granted, this is not the same as posting to the mailing list, and for that I apologize. Looking back in the archives on gmane, it looks like you are very interested in MW testing. Since this is a large part of my focus currently as well, perhaps we should coordinate our work? Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - test run configuration data
Hi all, I suggest we have one static class variable Selenium::$settings which is set up as an array. This array would be filled in some init function from whatever sources we decide on. Then, internally, the configuration mechanisms would not change anymore, and we could use the init method to fill the settings from globals (as is) or ini files (as Mark propses). Those who use the framework, however, would not have to rewrite their code. Regards, Markus Markus Glaser Social Web Technologien Leiter Softwareentwicklung Hallo Welt! - Medienwerkstatt GmbH __ Untere Bachgasse 15 93047 Regensburg Tel. +49 (0) 941 - 56 95 94 92 Fax. +49 (0) 941 - 50 27 58 13 www.hallowelt.biz gla...@hallowelt.biz Sitz: Regensburg Handelsregister: HRB 10467 E.USt.Nr.: DE 253050833 Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von dan nessett Gesendet: Dienstag, 7. September 2010 17:20 An: Wikimedia developers; Mark A. Hershberger Betreff: Re: [Wikitech-l] Selenium Framework - test run configuration data I would be happy to coordinate with you. Up to this point I have been working with Markus Glaser and that has gone pretty well. But, I would welcome more discussion on issues, architecture and implementation strategy for the Framework as well as making sure anything I do fits in with what others are doing. Regards, Dan --- On Tue, 9/7/10, Mark A. Hershberger m...@everybody.org wrote: From: Mark A. Hershberger m...@everybody.org Subject: Re: Selenium Framework - test run configuration data To: Wikimedia developers wikitech-l@lists.wikimedia.org Cc: Dan Nessett dness...@yahoo.com Date: Tuesday, September 7, 2010, 8:04 AM Dan Nessett dness...@yahoo.com writes: Either approach works. But, by going back and forth, it makes development of functionality for the Framework difficult. I should also point out that what I was planning to do was not hidden. I wrote about these changes in my weekly report the Monday before I committed them (http://bit.ly/cqAcqz) and pointed to the weekly report from my Ohloh, Twitter, Identi.ca and Facebook accounts. Granted, this is not the same as posting to the mailing list, and for that I apologize. Looking back in the archives on gmane, it looks like you are very interested in MW testing. Since this is a large part of my focus currently as well, perhaps we should coordinate our work? Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ 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] list of proposed fundraising stimuli (was Re: fundraising...)
Just to be clear, we are not doing fundraising earmarks for the 2010 fundraiser. As I mentioned earlier, this was discussed earlier in the year and ruled out for the current fundraiser. Any such plan would need thorough discussion, both with the community and the WMF. In addition, we usually start planning our testing methodology and analytics goals 4 or 5 months ahead of the fundraiser so that development can be completed well before the fundraiser begins. That said, I think earmarks are definitely an idea that should be discussed for the future. Did you have any thoughts on the objections that I listed in the previous email? Right now the Foundation is generally opposed to the idea of fundraising earmarks, so we would need to address those objections before we start talking about any implementation details. Thanks for the R links. The research and analytics people here are very big fans of R. The links you sent look like they could be useful for us. Ryan Kaldari On 9/4/10 3:26 PM, James Salsman wrote: It's great to see that donor logs are going in to a database instead of just a text file, but multiple regression in SQL is absurdly difficult because of the limitations of SQL, so I still recommend R, in particular: http://cran.r-project.org/web/packages/RMySQL/RMySQL.pdf and http://wiener.math.csi.cuny.edu/Statistics/R/simpleR/stat006.html I will ask Arthur Richards for data coding formats. I predict that multiple response checkboxes will do better than the more constraining radio buttons, but there is no reason that they should not be measured as any other independent variable. It is probably a lot more important to measure the number of earmarks offered: 0-26. There is plenty of reason to believe that showing 26 options will have a slight advantage over 25, but I can't see the test results from the Red Cross (they measure the things which increase donations of blood much more carefully than money, at least in their publications that I've been able to find.) Don't forget the control case where no donor selections are offered. Optimization requires measurement, and it is easy to measure offering a lot of options up front. Do you think that variations on the disclaimer should also be tried? I think there is reason to believe something terse might result in more donations, e.g.: These options are advisory only. and/or The Wikimedia Foundation reserves the right to override donor selections, cancel any project, and use any funds for any purpose. and/or All donations are discretionary, these options are offered for polling purposes only. or some combination. What does Mike Godwin think a good set of disclaimers to test might be? I conflated the proposed stimulus list down to 25 non-default items and enumerated them with letters of the alphabet so that everyone would understand that it is feasible to test additional proposals as well. I have not yet surveyed the Village Pumps or mailing lists for additional stimulatory ideas but I hope people who have or who see anything missing will suggest at least five more. Translations would be great, too. (default) Use my donation where the need is greatest. A. Auction the order of search failover links to search engine companies. B. Broaden demographics of active editors. C. Compensate people who submit improvements to the extent that they are necessary and sufficient. D. Display most popular related articles. E. Enhance automation of project tasks. F. Enhance site performance in underserved geographic regions. G. Enhance visualizations of projects and their editing activity. H. Establish journalism awards, expense accounts and compensation for independent Wikinews reporters, fact checkers, photographers and proofreaders. I. Establish secure off-site backup copies. J. Establish simple Wikipedias for beginning readers in languages other than English. K. Improve math formula rendering. L. Increase the number of active editors. M. Increase the number of articles, images, and files. N. Increase the number of unique readers. O. Make it easier for people to add recorded audio pronunciations. P. Obtain expert article assessments. Q. Obtain reader quality assessments. R. Perform external code reviews. S. Perform independent usability testing. T. Produce regular snapshots and archives. U. Retain more active editors. V. Strengthen Wikimedia Foundation financial stability. W. Support a thriving research community. X. Support an easier format to write quiz questions. Y. Support more reliable server uptime. Z. Support offline editing. ___ 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] fundraising earmarks for code review, image bundle dumps, search failover auction, Wikinews independence, bugzilla queue maintenance etc.
My contributions for audio recording uploads are not ready because they depend on the upload redesign and client-side Flash. I am still waiting to hear from anyone why the current state of Flash is any less closed than that of Java. I am willing to give the benefit of the doubt that people have simply not researched the situation with Adobe's current public documentation and license along with the state of Haxe and Gnash, but in the mean time I can wait for the upload redesign before I take up that issue in earnest. I'm also trying to raise money for Gnash developers to make that particular hurdle a complete non-issue. I would love to see Flash/Gnash support on Commons, but as far as I know, it isn't currently in the development pipeline (and as you said, their is still lingering cultural resistance to anything Flash-related, despite the emergence of projects like GPLFlash and Gnash). If you want to use Flash for uploads in the meantime, you can set-up an uploading front-end on the toolserver. I have a Flash-based uploading front-end for Commons on there myself that I use for doing multi-file uploads. Ryan Kaldari On 9/6/10 1:43 PM, James Salsman wrote: Tim Starling wrote: I meant the code: CentralNotice, DonationInterface, GeoLite, ContactPageFundraiser, the Drupal extension, etc. What remains to be done on those projects? The only unassigned bug of any immediately apparent consequence on any of those keywords I was able to find is bug 24682 which looks like it might have a patch already described in it. I didn't think you were a committer. My contributions for audio recording uploads are not ready because they depend on the upload redesign and client-side Flash. I am still waiting to hear from anyone why the current state of Flash is any less closed than that of Java. I am willing to give the benefit of the doubt that people have simply not researched the situation with Adobe's current public documentation and license along with the state of Haxe and Gnash, but in the mean time I can wait for the upload redesign before I take up that issue in earnest. I'm also trying to raise money for Gnash developers to make that particular hurdle a complete non-issue. Perhaps there are Mediawiki users other than the Foundation who would not be opposed to the use of Flash for microphone audio upload? Best regards, James Salsman ___ 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] ResourceLoader, now in trunk!
Tim Starling wrote:
On 07/09/10 17:44, Roan Kattouw wrote:
2010/9/7 Dmitriy Sintsov ques...@rambler.ru:
Do browsers support streamed and combined (archive-like) gz-encoded
content? Then probably minifying will not be neccessary.
Minification makes a shocking difference: remember that it's not just
whitespace being stripped, it's comments as well. For example, in
/trunk/extensions/UsabilityInitiative/js we have:
plugins.combined.js: 259281 bytes
plugins.combined.min.js: 142565 bytes
plugins.combined.js.gz: 65569 bytes
plugins.combined.min.js.gz: 32740 bytes
So not only is the minified JS roughly half the size in both the
compressed and the uncompressed cases, it actually /compresses better/
(3.95x vs. 4.35x).
Note that the advantage of minification is somewhat inflated due to
the nature of the source. There seems to be a because we can element
to it: because the developers are so impressed by the concept of
minification, they write excessively verbose and excessively many
comments. For example:
// create the span wrapper for the matched text
var spannode = document.createElement( 'span' );
spannode.className = 'highlight';
// shave off the characters preceding the matched text
var middlebit = node.splitText( pos );
// shave off any unmatched text off the end
middlebit.splitText( pat.length );
// clone for appending to our span
var middleclone = middlebit.cloneNode( true );
// append the matched text node to the span
spannode.appendChild( middleclone );
// replace the matched node, with our span-wrapped clone of the
matched node
middlebit.parentNode.replaceChild( spannode, middlebit );
Or a doc comment:
/**
* This plugin provides a generic way to add suggestions to a text box.
*
* Usage:
*
* Set options:
*$('#textbox').suggestions( { option1: value1, option2: value2 }
);
*$('#textbox').suggestions( option, value );
* Get option:
*value = $('#textbox').suggestions( option );
* Initialize:
*$('#textbox').suggestions();
*
* Options:
*
* fetch(query): Callback that should fetch suggestions and set the
suggestions property. Executed in the context of the
*textbox
*Type: Function
* cancel: Callback function to call when any pending asynchronous
suggestions fetches should be canceled.
*Executed in the context of the textbox
*Type: Function
* special: Set of callbacks for rendering and selecting
*Type: Object of Functions 'render' and 'select'
* result: Set of callbacks for rendering and selecting
*Type: Object of Functions 'render' and 'select'
* $region: jQuery selection of element to place the suggestions below
and match width of
*Type: jQuery Object, Default: $(this)
* suggestions: Suggestions to display
*Type: Array of strings
* maxRows: Maximum number of suggestions to display at one time
*Type: Number, Range: 1 - 100, Default: 7
* delay: Number of ms to wait for the user to stop typing
*Type: Number, Range: 0 - 1200, Default: 120
* submitOnClick: Whether to submit the form containing the textbox
when a suggestion is clicked
*Type: Boolean, Default: false
* maxExpandFactor: Maximum suggestions box width relative to the
textbox width. If set to e.g. 2, the suggestions box
*will never be grown beyond 2 times the width of the textbox.
*Type: Number, Range: 1 - infinity, Default: 3
* positionFromLeft: Whether to position the suggestion box with the
left attribute or the right
*Type: Boolean, Default: true
* highlightInput: Whether to hightlight matched portions of the input
or not
*Type: Boolean, Default: false
*/
I think it's ironic that this style arises in JavaScript, given that
it's a high-level language and relatively easy to understand, and that
you could make a technical case in favour of terseness. C has an
equally effective minification technique known as compilation, and its
practitioners tend to be terse to a fault. For instance, many Linux
kernel modules have no comments at all, except for the license header.
-- Tim Starling
This brings up a question, what's the comparison between unminified,
minified, just stripping comments, and their gzipped versions?
Does minified+gzipped provide any significant size savings over simple
commentstripped+gzipped?
If not, then there's something to say about that since only erasing
comments would still make debugging somewhat doable since you should be
able to get a good enough line number to use find with some nearby code
to track down where the bug is. (You also won't run into server-side js
syntax-error issues due to needing to minify actual code)
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
[Wikitech-l] Incremental dumps on download
Hi all, I was wondering if there are any plans to provide incremental dumps (ie. the diff between each dump and the previous one) at download.wikimedia.org. It seems to me that such diffs would help save bandwidth because mirrors could stay up to date by downloading the diffs and applying them rather than downloading the whole dump each time. I am new here, so I hope that this mailing-list is the correct place for this kind of suggestions. If I am wrong, please tell me. Regards, -- Antoine Amarilli ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
On Mon, Sep 6, 2010 at 10:59 PM, Dmitriy Sintsov ques...@rambler.ru wrote: Do browsers support streamed and combined (archive-like) gz-encoded content? Then probably minifying will not be neccessary. Currently this is only readily obtainable by just concatenating the files. HTTP pipelining would negate most of the point of resource combining if it actually worked in practice, but it tends to break in hard-to-catch ways due to transparent proxies that don't support it correctly. Opera reportedly does pipelining with some sort of heuristic or fallback behavior so it works reliably. Firefox supports pipelining, but it's off by default because of the problems it causes: https://bugzilla.mozilla.org/show_bug.cgi?id=264354 Another proposal in the making to allow this sort of combining more easily is Resource Packages, a Mozilla proposal: http://people.mozilla.com/~jlebar/respkg/ This is supposed to make it into the next Firefox after 4.0 last I heard. Resource packages are easy to deploy (meaning no web server changes required), but they have to be maintained manually, and have other inherent limitations. The medium-to-long-term development that's expected to address this problem is SPDY, a proposal by Google: http://www.chromium.org/spdy/spdy-whitepaper The major drawback is that it not only requires considerable server-side changes, it also doesn't work with HTTP proxies. In the end, it will probably be usable only over SSL, but that might not be such a big issue with DNSSEC finally becoming a reality -- the root zone has been signed, .com and .net will be within a year, and people are thinking about how to use DNSSEC to allow HTTPS without having to pay a CA for a certificate: http://www.imperialviolet.org/2010/08/16/dnssectls.html But SPDY has major advantages, basically being a rewrite of the HTTP wire format for performance, while preserving HTTP semantics (so applications will still be given the same headers, etc.). So, yes, this problem is being worked on. :) None of it will obsolete minification, though, as Roan points out. Also, it would be great if these high-level JS-libraries like jQuery actually were ported into DOM API level (native browser's implementation instead of extra JS layer). This is not going to happen. jQuery is way too complicated to be a reasonable target for interoperable implementation. Furthermore, part of the goal of jQuery is to be a compatibility layer so that all browsers look the same even across many years of releases, and this isn't possible if it's native, so some extra layer will always be needed. Instead, implementers work on making popular libraries like jQuery work faster and better, including moving select features to a native implementation when that will improve performance a lot (e.g., querySelector()). However, these questions are to FF/IE/Opera developers... Don't forget Chrome and Safari. I'm not a web browser developer, but I work with web standards a lot, so I'm fairly informed on this sort of thing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database drivers
On Sun, Sep 5, 2010 at 22:56, Tim Starling tstarl...@wikimedia.org wrote: It would be great if the maintainers of the less-commonly used DBMSes could write up development guides and put them in phase3/docs. These guides could describe relevant differences in SQL syntax compared to MySQL, and explain how to write schema files. I have a reference table for the MySQL, Postgres, and DB2 data types in the current schema on the wiki: http://www.mediawiki.org/wiki/Manual:IBM_DB2#SQL_data_types It's somewhat hard to predict what the important differences in SQL syntax would be. Is there anything specific that comes to mind? If not, I can just write MySQL/DB2 differences up as I encounter them Would it be useful to link to the reference documentation for things like CREATE TABLE, ALTER TABLE, ALTER COLUMN, etc in the short term? http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r927.html Regards, Leons Petrazickis http://lpetr.org/blog/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Regression suite? Was: Re: Database drivers
On Fri, Sep 3, 2010 at 12:19 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Fri, Sep 3, 2010 at 2:44 PM, Chad innocentkil...@gmail.com wrote: Given those criteria, I think that the following have full support in MediaWiki: * MySQL * SQLite * PostgreSQL In practice, though, SQLite and PostgreSQL are more likely to break than MySQL, right? If so, we should make this clear in the installer UI. Or are they really about as well-supported as MySQL these days, minus a moderate lag in schema updates for pgsql? Ideally, we could run test suites by default on all available DBs instead of just on the one the wiki currently uses. In particular, SQLite currently uses the same schema as MySQL and is available in PHP by default, plus it doesn't require any setup (providing admin login, etc.), so it would be great if we could run SQLite tests right now whenever people run tests. It would be great if people could set up pgsql to automatically run too, but that would require manual setup. This is the kind of thing automated tests are really helpful for. (But that's kind of tangential.) Out of curiosity - what regression test suites are in use to QA MW builds? Thanks... -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Database drivers
On Sun, Sep 5, 2010 at 10:56 PM, Tim Starling tstarl...@wikimedia.org wrote: It would be great if the maintainers of the less-commonly used DBMSes could write up development guides and put them in phase3/docs. These guides could describe relevant differences in SQL syntax compared to MySQL, and explain how to write schema files. I got them started in r72533. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - test run configuration data
On Tue, 07 Sep 2010 17:39:19 +0200, Markus Glaser wrote: Hi all, I suggest we have one static class variable Selenium::$settings which is set up as an array. This array would be filled in some init function from whatever sources we decide on. Then, internally, the configuration mechanisms would not change anymore, and we could use the init method to fill the settings from globals (as is) or ini files (as Mark propses). Those who use the framework, however, would not have to rewrite their code. Regards, Markus Markus Glaser Social Web Technologien Leiter Softwareentwicklung Hallo Welt! - Medienwerkstatt GmbH __ Untere Bachgasse 15 93047 Regensburg Tel. +49 (0) 941 - 56 95 94 92 Fax. +49 (0) 941 - 50 27 58 13 www.hallowelt.biz gla...@hallowelt.biz Sitz: Regensburg Handelsregister: HRB 10467 E.USt.Nr.: DE 253050833 Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani -Ursprüngliche Nachricht- Von: wikitech-l-boun...@lists.wikimedia.org [mailto:wikitech-l-boun...@lists.wikimedia.org] Im Auftrag von dan nessett Gesendet: Dienstag, 7. September 2010 17:20 An: Wikimedia developers; Mark A. Hershberger Betreff: Re: [Wikitech-l] Selenium Framework - test run configuration data I would be happy to coordinate with you. Up to this point I have been working with Markus Glaser and that has gone pretty well. But, I would welcome more discussion on issues, architecture and implementation strategy for the Framework as well as making sure anything I do fits in with what others are doing. Regards, Dan --- On Tue, 9/7/10, Mark A. Hershberger m...@everybody.org wrote: From: Mark A. Hershberger m...@everybody.org Subject: Re: Selenium Framework - test run configuration data To: Wikimedia developers wikitech-l@lists.wikimedia.org Cc: Dan Nessett dness...@yahoo.com Date: Tuesday, September 7, 2010, 8:04 AM Dan Nessett dness...@yahoo.com writes: Either approach works. But, by going back and forth, it makes development of functionality for the Framework difficult. I should also point out that what I was planning to do was not hidden. I wrote about these changes in my weekly report the Monday before I committed them (http://bit.ly/cqAcqz) and pointed to the weekly report from my Ohloh, Twitter, Identi.ca and Facebook accounts. Granted, this is not the same as posting to the mailing list, and for that I apologize. Looking back in the archives on gmane, it looks like you are very interested in MW testing. Since this is a large part of my focus currently as well, perhaps we should coordinate our work? Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l This seems like a reasonable strategy to me. Dan -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
I made seven suggestions. Only one was about actually dissolving the office, and I acknowledged that it might be extreme. What about the others? Why does the private IRC chat need to exist, for example? Why can't we have clear official statements that everything should be as public as possible and that volunteer developers should be treated as peers? Why can't teleconferences be replaced by public-logged IRC chats? Are these also too extreme? Aryeh, I think many volunteer and more casual developers share your concern. I in principle agree with your proposals, although of course no-one can be forced to abandon private communication, and private means of communication are always going to exist. I have raised similar concerns about volunteers not knowing what is going on by not being on secret channels of communication, in person, to a couple of members of staff during last two wikimanias and developer meetings, and I had the feeling they agreed with me. The community needs to be nurtured, and I think all new employees of the WMF need to be aware of it, and at first interview informed that they will *need* to interact with the community and with volunteer developers. I think many programmers who have worked in programming companies are too used to just talking and listening to their team leaders and no-one else. It should be made clear that this is not how things (should) work in WMF, and this should be an official position from however is hiring. Or maybe it is utopia and we do need to have a more stereotypical corporate setup, but I really hope not because wikipedia is fueled by enthusiasm. Finally, speaking as a volunteer who is not on any secret IRC channels, mailing lists or payrolls I want to share my experience in WMF software development. Back in 2006 I wanted to make search better, and if then it wasn't for Tim Starling to give me shell access and a couple of test servers to play with, I think we would not have the new search, or at least not developed by me. An act of kindness, but also a sign that a core developer cares about what a relatively unknown volunteer is trying to do and achieve. As for code review, I know the foundation knows how important this task is, and that it is no 9-5 job, but one that requires an extremely dedicated person with a great knowledge of the mediawiki codebase and ability to comment on virtually every programming issue. The foundation better pay this person well and not just hope for someone to fill in this place in their spare time. Cheers, Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Regression suite? Was: Re: Database drivers
George Herbert wrote: Ideally, we could run test suites by default on all available DBs instead of just on the one the wiki currently uses. In particular, SQLite currently uses the same schema as MySQL and is available in PHP by default, plus it doesn't require any setup (providing admin login, etc.), so it would be great if we could run SQLite tests right now whenever people run tests. It would be great if people could set up pgsql to automatically run too, but that would require manual setup. This is the kind of thing automated tests are really helpful for. (But that's kind of tangential.) Out of curiosity - what regression test suites are in use to QA MW builds? Thanks... We have the parser tests and a few phpunit tests. There is also some support for Selenium tests. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Incremental dumps on download
Antoine Amarilli wrote: Hi all, I was wondering if there are any plans to provide incremental dumps (ie. the diff between each dump and the previous one) at download.wikimedia.org. It seems to me that such diffs would help save bandwidth because mirrors could stay up to date by downloading the diffs and applying them rather than downloading the whole dump each time. I am new here, so I hope that this mailing-list is the correct place for this kind of suggestions. If I am wrong, please tell me. Regards, This mailing list is not bad, but you have a more specific one at https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l The idea is not bad, but we would probably need to roll out a custom diff script to ensure it keeps memory usage low (that's not necessarily hard). But if we were going to do that, we could as well provide the differences in xml format instead for easy appliying. The result of appliying a diff xml to an existing wiki is straghtforward, but what to do with removed pages? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] fundraising earmarks for code review, image bundle dumps, search failover auction, Wikinews independence, bugzilla queue maintenance etc.
On Fri, Sep 3, 2010 at 5:05 PM, James Salsman jsals...@gmail.com wrote: Are there any reasons not to allow donors to earmark categories? I feel an instinctive and passionate loathing for this proposal. However, instinct and loathing are not very positive grounds on which to argue a position, as I once tried to explain to a large bloke in a pub as he repeatedly punched me in the face. So I shall try to rein in my passions and argue with the logic of an automaton. Firstly, such earmarking would turn a donation into a kind of popularity vote. The populace decides what the priorities are. Voting can be very good, we are all democratic now, but voters must be informed citizens. I believe the current percentage of Wikipedia visitors that edits rather than stopping at just consuming the material is something like 0.01%. I would assume that the great majority of donors are readers of articles and have never been anywhere near a mailing list like this one, or looked at Meta-Wiki, or even visited our proposals pages, or the strategy wiki, or really given much thought about the fact that a Foundation runs Wikipedia. They may not even know it's a charity. You are proposing that this unthinking and uninterested mass present us with a few shakes of the Magic 8 Ball that the WMF will then feel bound by? Secondly, you state that perhaps 30 options for earmarking could be presented to a potential donor, when I believe it's been shown that users interact with things at a proportion inverse to the number of options; the donation interface should be as clean and unintimidating as possible or we are in danger of alienating people right on the cusp of acting as we would hope and wish. Finally, we've just had an extensive Strategy process and the community was involved. Regardless of what you think of the outcomes (for me, I was disappointed that what came out was painted in broader strokes than I had imagined and would have liked), if we were to now say actually, forget all that. Forget Strategy happened. Let's direct our energies according to the flighty whims of someone who'd never asked themselves a pertinent question until seeing a humungous list of radio buttons pop up on their screen and clicked one of the first four cos it sounded like a good thing and four is the limit of their Twitterised attention span. The Strategy Process was the community's way of influencing priorities. Those priorities will need to be funded by the donations. This ship has sailed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9/7/10 4:15 PM, Robert Stojnic wrote: The community needs to be nurtured, and I think all new employees of the WMF need to be aware of it, and at first interview informed that they will *need* to interact with the community and with volunteer developers. Just FYI, this was the most-stressed topic during my interviews at the WMF. So I don't think it's a matter of the WMF not being aware of the topic. I think many programmers who have worked in programming companies are too used to just talking and listening to their team leaders and no-one else. This is true, but we are trying not to hire this sort of person. Off the top of my head I would guess at least 75% of the developers here had significant open source experience before being hired, many with Wikimedia projects. -- Neil Kandalgaonkar ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
I am both a long-time community member and a new WMF paid developer (in the SF office) so I think I'm in a unique position to clear up some misconceptions. First of all, all this talk of secret listservs and IRC channels is malarkey. Yes, there are private listservs and IRC channels. All of them are private for very specific and well-established reasons. Most of them are only used in very specific circumstances (for example if there was a security breach that needed to be discussed privately) and tend to be very low traffic. They are not the places where important decisions are made. Secondly, the idea that developers here in the office don't interact with the community is absurd. The developers here interact with the community constantly. We discuss community opinion and ideas, we talk with community members all day long on IRC, listservs, and on-wiki. I'm amazed that the developers here ever get anything done considering how much time they spend documenting what they are working on and interacting with the community about it. The problem is they can't interact with everyone everywhere: Code Review, IRC, listservs, the Tech Blog, meta, Signpost, etc. So no matter what, someone is going to feel like they are out of the loop. The WMF is extremely interested in new developers interacting with the community, indeed they try to hire developers from within the community when possible. The notion that the foundation is hiring corporate drones who are only going to listen to their task masters is completely unfounded. Yes, there have been situations where the foundation has been given grant money for very specifically defined projects and those projects have been implemented without adequate community involvement. Everyone (including the foundation) knows that that's not how we want to do development in the future. As has been discussed throughout the past year, the foundation wants to move away from accepting any money with strings attached and away from relying on grants in general. Hopefully, if this year's fundraiser goes well, we won't have to worry about these issues in the future. Ryan Kaldari On 9/7/10 4:15 PM, Robert Stojnic wrote: I made seven suggestions. Only one was about actually dissolving the office, and I acknowledged that it might be extreme. What about the others? Why does the private IRC chat need to exist, for example? Why can't we have clear official statements that everything should be as public as possible and that volunteer developers should be treated as peers? Why can't teleconferences be replaced by public-logged IRC chats? Are these also too extreme? Aryeh, I think many volunteer and more casual developers share your concern. I in principle agree with your proposals, although of course no-one can be forced to abandon private communication, and private means of communication are always going to exist. I have raised similar concerns about volunteers not knowing what is going on by not being on secret channels of communication, in person, to a couple of members of staff during last two wikimanias and developer meetings, and I had the feeling they agreed with me. The community needs to be nurtured, and I think all new employees of the WMF need to be aware of it, and at first interview informed that they will *need* to interact with the community and with volunteer developers. I think many programmers who have worked in programming companies are too used to just talking and listening to their team leaders and no-one else. It should be made clear that this is not how things (should) work in WMF, and this should be an official position from however is hiring. Or maybe it is utopia and we do need to have a more stereotypical corporate setup, but I really hope not because wikipedia is fueled by enthusiasm. Finally, speaking as a volunteer who is not on any secret IRC channels, mailing lists or payrolls I want to share my experience in WMF software development. Back in 2006 I wanted to make search better, and if then it wasn't for Tim Starling to give me shell access and a couple of test servers to play with, I think we would not have the new search, or at least not developed by me. An act of kindness, but also a sign that a core developer cares about what a relatively unknown volunteer is trying to do and achieve. As for code review, I know the foundation knows how important this task is, and that it is no 9-5 job, but one that requires an extremely dedicated person with a great knowledge of the mediawiki codebase and ability to comment on virtually every programming issue. The foundation better pay this person well and not just hope for someone to fill in this place in their spare time. Cheers, Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
