Re: [Wikitech-l] Declaring methods final in classes
Hey, My understanding is that mocking final methods and types is a limitation that is not specific to just PHPUnit, or indeed to PHP itself. Mockery, another established PHP mock object framework, relies on a workaround for mocking final methods and types that prevents testing code with type constraints or instanceof checks[1]. On the JVM, the popular mocking framework Mockito similarly has to rely on instrumentation to provide support for this use case[2]. Personally, I do not have enough context to judge whether there is added value in declaring those methods in e.g. WANObjectCache as final. It may have been intended to explicitly prevent subclassing and overriding by extension code, although this is just a guess. A question that could be posed is whether these benefits are worth the tradeoff in terms of reduced testability. What do you think? —— [1] http://docs.mockery.io/en/latest/reference/final_methods_classes.html [2] https://static.javadoc.io/org.mockito/mockito-core/3.0.0/org/mockito/Mockito.html#39 Máté Szabó SOFTWARE ENGINEER +36 30 947 5903 WIKIA sp. z o.o. z siedzibą w Poznaniu, ul. Abp. A. Baraniaka 6 Sąd Rejonowy Poznań – Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 254365 NIP: 5252358778 Kapitał zakładowy: 50.000,00 złotych > On 27 Aug 2019, at 20:56, Daimona wrote: > > Personally, I don't like these limitations in PHPUnit and the like. IMHO, > they should never be a reason for changing good code. And sometimes, > methods have to be final. I don't know about the specific case, though. > > Anyway, some time ago I came across [1], which allows mocking final methods > and classes. IIRC, it does that by removing the `final` keywords from the > tokenized PHP code. I don't know how well it works, nor if it could degrade > performance, but if it doesn't we could bring it in via composer. > > > [1] - https://github.com/dg/bypass-finals > > > Il giorno martedì 27 agosto 2019, Aryeh Gregor ha scritto: > >> I see that in some classes, like WANObjectCache, most methods are declared >> final. Why is this? Is it an attempt to optimize? >> >> The problem is that PHPUnit mocks can't touch final methods. Any ->method() >> calls that try to do anything to them silently do nothing. This makes >> writing tests harder. >> >> If we really want these methods to be marked final for some reason, the >> workaround for PHP is to make an interface that has all the desired >> methods, have the class implement the interface, and make type hints all >> refer to the interface instead of the class. But if there's no good reason >> to declare the methods final to begin with, it's simplest to just drop it. >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > -- > https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy > "Daimona" is not my real name -- he/him > ___ > 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] Declaring methods final in classes
Personally, I don't like these limitations in PHPUnit and the like. IMHO, they should never be a reason for changing good code. And sometimes, methods have to be final. I don't know about the specific case, though. Anyway, some time ago I came across [1], which allows mocking final methods and classes. IIRC, it does that by removing the `final` keywords from the tokenized PHP code. I don't know how well it works, nor if it could degrade performance, but if it doesn't we could bring it in via composer. [1] - https://github.com/dg/bypass-finals Il giorno martedì 27 agosto 2019, Aryeh Gregor ha scritto: > I see that in some classes, like WANObjectCache, most methods are declared > final. Why is this? Is it an attempt to optimize? > > The problem is that PHPUnit mocks can't touch final methods. Any ->method() > calls that try to do anything to them silently do nothing. This makes > writing tests harder. > > If we really want these methods to be marked final for some reason, the > workaround for PHP is to make an interface that has all the desired > methods, have the class implement the interface, and make type hints all > refer to the interface instead of the class. But if there's no good reason > to declare the methods final to begin with, it's simplest to just drop it. > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- https://meta.wikimedia.org/wiki/User:Daimona_Eaytoy "Daimona" is not my real name -- he/him ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Declaring methods final in classes
I see that in some classes, like WANObjectCache, most methods are declared final. Why is this? Is it an attempt to optimize? The problem is that PHPUnit mocks can't touch final methods. Any ->method() calls that try to do anything to them silently do nothing. This makes writing tests harder. If we really want these methods to be marked final for some reason, the workaround for PHP is to make an interface that has all the desired methods, have the class implement the interface, and make type hints all refer to the interface instead of the class. But if there's no good reason to declare the methods final to begin with, it's simplest to just drop it. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Train] 1.34.0-wmf.20 status update
Hi! # TLDR 1.34.0-wmf.20 is at group 0, but blocked https://phabricator.wikimedia.org/T220745 # Blockers Train will not move forward until the following tasks are resolved or removed from blockers: * DefaultPreferencesFactory.php: Global default '' is invalid for field incubatortestwiki-code https://phabricator.wikimedia.org/T231029 * TraditionalImageGallery.php: Argument 2 passed to MediaWiki\BadFileLookup::isBadFile() must implement interface MediaWiki\Linker\LinkTarget, bool given https://phabricator.wikimedia.org/T231340 * BadFileLookup.php: Argument 2 passed to MediaWiki\BadFileLookup::isBadFile() must implement interface MediaWiki\Linker\LinkTarget or be null, boolean given https://phabricator.wikimedia.org/T231353 * File '/srv/mediawiki/php-1.34.0-wmf.20/skins/MinervaNeue/resources/resources/skins.minerva.personalMenu.icons/userSandbox.svg' does not exist https://phabricator.wikimedia.org/T231358 # Resolved Following tasks have been resolved: * ServiceContainer.php: Circular dependency when creating MobileFrontend service "AMC.UserMode > AMC.Manager > FeaturesManager > UserModes > AMC.UserMode" https://phabricator.wikimedia.org/T231014 * LegacyHandler.php: PHP Warning: Host lookup failed [-10002]: Unknown error -10002 https://phabricator.wikimedia.org/T231025 * L10n cache is completely broken https://phabricator.wikimedia.org/T231183 I would like to thank everybody that helped resolve train problems, and especially pmiazga (Piotr Miazga), hashar (Antoine Musso) and Simetrical (Aryeh Gregor). # Removed from blockers Following task were removed from train blockers: * /w/api.php... ErrorException from line 0 of : PHP Notice: Unable to unserialize ... Size of serialized string ... exceeds max https://phabricator.wikimedia.org/T231071 * ApiQueryContentTranslation.php: PHP Notice: Trying to get property 'translation' of non-object https://phabricator.wikimedia.org/T231284 * RevisionBasedEntityLookup.php: Revision 363395998 belongs to M77688146 instead of expected M81625979 https://phabricator.wikimedia.org/T231276 The tasks are still not resolved, so any help is appreciated. I would like to thank for hashar (Antoine Musso) for investigating the issues and removing the tasks from blockers. # Log spam Additionally, I've found this errors in logs, but since they are not new, they are not blocking the train. * Assert.php: Bad value for parameter $responses: must have as many responses as requests https://phabricator.wikimedia.org/T231023 * Assert.php: Bad value for parameter $oldContent: must be a TextContent|null https://phabricator.wikimedia.org/T231084 * WikibaseClient.php: PHP Notice: Undefined index: https://phabricator.wikimedia.org/T231089 # mediawiki-new-errors I would also like to thank Krinkle (Timo Tijhof) for creating mediawiki-new-errors dashboard. I've found all of the problems using it. The dashboard is far from empty. Feel free to use it to find and report problems. https://logstash.wikimedia.org/goto/b65b808294695129cef5f26257e1f944 Željko On Tue, Aug 27, 2019 at 11:42 AM Željko Filipin wrote: > I would like to thank everybody that worked on resolving train blockers. > These tasks are now resolved. > > * L10n cache is completely broken > https://phabricator.wikimedia.org/T231183 > > I've found more problems that are blocking the train from even starting. > > * RevisionBasedEntityLookup.php: Revision 363395998 belongs to M77688146 > instead of expected M81625979 https://phabricator.wikimedia.org/T231276 > * ApiQueryContentTranslation.php: PHP Notice: Trying to get property > 'translation' of non-object https://phabricator.wikimedia.org/T231284 > > Any help in resolving the tasks is greatly appreciated. > > Thank you, > > Željko > > On Mon, Aug 26, 2019 at 8:07 PM Željko Filipin > wrote: > >> The 1.34.0-wmf.20 version of MediaWiki is blocked. >> >> https://phabricator.wikimedia.org/T220745 >> >> The new version is not deployed anywhere yet. It will not be deployed >> until these issues are resolved: >> >> * ServiceContainer.php: Circular dependency when creating MobileFrontend >> service "AMC.UserMode > AMC.Manager > FeaturesManager > UserModes > >> AMC.UserMode" https://phabricator.wikimedia.org/T231014 >> * DefaultPreferencesFactory.php: Global default '' is invalid for field >> incubatortestwiki-code https://phabricator.wikimedia.org/T231029 >> * /w/api.php... ErrorException from line 0 of : PHP Notice: Unable to >> unserialize ... Size of serialized string ... exceeds max >> https://phabricator.wikimedia.org/T231071 >> * L10n cache is completely broken >> https://phabricator.wikimedia.org/T231183 >> >> Once these issues are resolved train can start. >> >> Additionally, I've found this errors in logs, but since they are not new, >> they are not blocking the train. >> >> * Assert.php: Bad value for parameter $responses: must have as many >> responses as requests https://phabricator.wikimedia.org/T231023 >> * Assert.php: Bad value for parameter $oldContent: must
[Wikitech-l] Discovery Weekly Update for the week starting 2019-08-05
Hello, This is the weekly update from the Search Platform team for the week starting 2019-08-05. As always, feedback and questions are welcome. == Discussions == === Search === * Erik discovered that Prometheus was not collecting cloudelastic metrics...so, he defined cloudelastic as a cluster in hieradata [0] * The team worked on fixing documentation of boolean operators [1] and you can read about it. [2] * We needed to help get cloudelastic working with the request streams that we need, so, we fixed LVS IPv6 addresses [3] * There was a spike of errors on eventlogging events that needed to be addressed [4] * We evaluated druid+turnilo+superset for search metrics going forward and found it to be reasonable; so, now we'll build a superset dashboard for search satisfaction 'did you mean' metrics [5] * Erik finished yup the work to initialize CirrusSearch on cloudelastic [6] * *borked* — Icinga check defined from LVS configuration for cloudelastic and now fixed- cloudelastic checks for all ports have been generated on icinga. However, only IPv4 checks were generated and this is Ok for now. If there's need to generate IPv6 checks, please reopen this task [7] * David found an issue where labweb mw hosts were unable to contact any of the elasticsearch clusters and fixed it [8] === Wikidata Query Service === * Stas added support for SDC MediaInfo URIs in WDQS [9] * Stas moved DCAT-AP namespace to https://dcatap.wmflabs.org/ [10] [0] https://phabricator.wikimedia.org/T229937 [1] https://phabricator.wikimedia.org/T228925 [2] https://www.mediawiki.org/wiki/Help:CirrusSearch/Logical_operators [3] https://phabricator.wikimedia.org/T224324 [4] https://phabricator.wikimedia.org/T229614 [5] https://phabricator.wikimedia.org/T229268 [6] https://phabricator.wikimedia.org/T220625 [7] https://phabricator.wikimedia.org/T229621 [8] https://phabricator.wikimedia.org/T230994 [9] https://phabricator.wikimedia.org/T229608 [10] https://phabricator.wikimedia.org/T228297 Subscribe to receive on-wiki (or opt-in email) notifications of the Discovery weekly update. https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly The archive of all past updates can be found on MediaWiki.org: https://www.mediawiki.org/wiki/Discovery/Status_updates Interested in getting involved? See tasks marked as "Easy" or "Volunteer needed" in Phabricator. [1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R [2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R Yours, Chris Koerner (he/him) Community Relations Specialist Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator monthly statistics - 2019-07
On Tue, Aug 27, 2019 at 5:59 PM Zppix wrote: > Why are we receiving this now? > Because i ran it after https://gerrit.wikimedia.org/r/c/operations/puppet/+/532711 for https://phabricator.wikimedia.org/T231320 and mail delivery is delayed a bit. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator monthly statistics - 2019-07
Why are we receiving this now? -- Devin “Zppix” CCENT Volunteer Wikimedia Developer Africa Wikimedia Developers Member and Mentor Volunteer Mozilla Support Team Member (SUMO) Quora.com Partner Program Member enwp.org/User:Zppix **Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. ** > On Aug 27, 2019, at 9:32 AM, communitymetr...@wikimedia.org wrote: > > > Hi Community Metrics team, > > This is your automatic monthly Phabricator statistics mail. > > Accounts created in (2019-07): 290 > Active Maniphest users (any activity) in (2019-07): 967 > Task authors in (2019-07): 521 > Users who have closed tasks in (2019-07): 293 > > Projects which had at least one task moved from one column to another on > their workboard in (2019-07): 312 > > Tasks created in (2019-07): 2573 > Tasks closed in (2019-07): 2403 > Open and stalled tasks in total: 42433 > > Median age in days of open tasks by priority: > > Unbreak now: 2 > Needs Triage: 522 > High: 944 > Normal: 1139 > Low: 1552 > Lowest: 1531 > > (How long tasks have been open, not how long they have had that priority) > > Active Differential users (any activity) in (2019-07): 12 > > To see the names of the most active task authors: > * Go to https://wikimedia.biterg.io/ > * Choose "Phabricator > Overview" from the top bar > * Adjust the time frame in the upper right corner to your needs > * See the author names in the "Submitters" panel > > TODO: Numbers which refer to closed tasks might not be correct, as > described in https://phabricator.wikimedia.org/T1003 . > > Yours sincerely, > Fab Rick Aytor > > (via community_metrics.sh on phab1003 at Tue Aug 27 14:32:03 UTC 2019) > > ___ > 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] Phabricator monthly statistics - 2019-07
Hi Community Metrics team, This is your automatic monthly Phabricator statistics mail. Accounts created in (2019-07): 290 Active Maniphest users (any activity) in (2019-07): 967 Task authors in (2019-07): 521 Users who have closed tasks in (2019-07): 293 Projects which had at least one task moved from one column to another on their workboard in (2019-07): 312 Tasks created in (2019-07): 2573 Tasks closed in (2019-07): 2403 Open and stalled tasks in total: 42433 Median age in days of open tasks by priority: Unbreak now: 2 Needs Triage: 522 High: 944 Normal: 1139 Low: 1552 Lowest: 1531 (How long tasks have been open, not how long they have had that priority) Active Differential users (any activity) in (2019-07): 12 To see the names of the most active task authors: * Go to https://wikimedia.biterg.io/ * Choose "Phabricator > Overview" from the top bar * Adjust the time frame in the upper right corner to your needs * See the author names in the "Submitters" panel TODO: Numbers which refer to closed tasks might not be correct, as described in https://phabricator.wikimedia.org/T1003 . Yours sincerely, Fab Rick Aytor (via community_metrics.sh on phab1003 at Tue Aug 27 14:32:03 UTC 2019) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Looking for a senior full-stack developer (Contractor) for Scribe (Wikimedia-funded project)
Hello everyone, We are looking for a senior full-stack developer to work with us as a contractor on Scribe. Scribe is a Wikimedia Foundation funded software and research project. We are building a tool to support newcomer Wikipedia editors in creating new articles in under-resourced languages (e.g. Arabic, Hindi). The project is open-source and will be integrated on low-resource Wikipedias so you will be working on a great cause of making knowledge accessible to everyone. Plus your work will have great visibility and impact on the community. *You:* We are looking for a senior software engineer contractor to realize the Scribe project in a part-time position for 9 months starting on the 14th of October. You will work remotely with us. We are looking for someone with *3+ years of experience in Full-stack development and community-focused applications*. *Your future team:* The project leads are Lucie and Hady, researchers in Computer Science. So you will be part of our three-person team and able to influence the project itself. Lucie is a PhD researcher at the University of Southampton and TIB Hannover. She previously worked at Wikimedia Germany. Hady holds a PhD in Natural Language Processing and Machine Learning and currently works as a researcher in Naver Labs Europe. We live in France and Germany/UK respectively, so we are used to working remotely and effective communication. *How to apply: * *Make sure to read the full job description here:* https://meta.wikimedia.org/wiki/Scribe/Job Then drop us an email (scribe.wikime...@gmail.com) showing your interest in the project with your *CV* and *portfolio attached*. We also appreciate *any other kind of information in any format* that shows your relevant experience, creativity and problem-solving skills. Note: Interviews will be scheduled on a first come first served basis until the position gets filled, so please consider to submit your profile as soon as possible. Looking forward to hearing from you, Lucie-Aimée Kaffee and Hady Elsahar -- Lucie-Aimée Kaffee ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wednesday: Technical Advice IRC Meeting
Sorry for cross-posting! Reminder: Technical Advice IRC meeting this week **Wednesday 3-4 pm UTC** on #wikimedia-tech. Questions can be asked in English! The Technical Advice IRC Meeting (TAIM) is a weekly support event for volunteer developers. Every Wednesday, two full-time developers are available to help you with all your questions about MediaWiki, gadgets, tools and more! This can be anything from "how to get started" over "who would be the best contact for X" to specific questions on your project. If you know already what you would like to discuss or ask, please add your topic to the next meeting: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting Hope to see you there! -- Raz Shuty Engineering Manager Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world, in which every single human being can freely share in the sum of all knowledge. That‘s our commitment. Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Train] 1.34.0-wmf.20 status update
I would like to thank everybody that worked on resolving train blockers. These tasks are now resolved. * L10n cache is completely broken https://phabricator.wikimedia.org/T231183 I've found more problems that are blocking the train from even starting. * RevisionBasedEntityLookup.php: Revision 363395998 belongs to M77688146 instead of expected M81625979 https://phabricator.wikimedia.org/T231276 * ApiQueryContentTranslation.php: PHP Notice: Trying to get property 'translation' of non-object https://phabricator.wikimedia.org/T231284 Any help in resolving the tasks is greatly appreciated. Thank you, Željko On Mon, Aug 26, 2019 at 8:07 PM Željko Filipin wrote: > The 1.34.0-wmf.20 version of MediaWiki is blocked. > > https://phabricator.wikimedia.org/T220745 > > The new version is not deployed anywhere yet. It will not be deployed > until these issues are resolved: > > * ServiceContainer.php: Circular dependency when creating MobileFrontend > service "AMC.UserMode > AMC.Manager > FeaturesManager > UserModes > > AMC.UserMode" https://phabricator.wikimedia.org/T231014 > * DefaultPreferencesFactory.php: Global default '' is invalid for field > incubatortestwiki-code https://phabricator.wikimedia.org/T231029 > * /w/api.php... ErrorException from line 0 of : PHP Notice: Unable to > unserialize ... Size of serialized string ... exceeds max > https://phabricator.wikimedia.org/T231071 > * L10n cache is completely broken > https://phabricator.wikimedia.org/T231183 > > Once these issues are resolved train can start. > > Additionally, I've found this errors in logs, but since they are not new, > they are not blocking the train. > > * Assert.php: Bad value for parameter $responses: must have as many > responses as requests https://phabricator.wikimedia.org/T231023 > * Assert.php: Bad value for parameter $oldContent: must be a > TextContent|null https://phabricator.wikimedia.org/T231084 > * WikibaseClient.php: PHP Notice: Undefined index: > https://phabricator.wikimedia.org/T231089 > > Thank you for your help resolving these issues! > > -- Your humble train toiler, Željko > > > > > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
