Не надо вводить никого в заблуждение: они отсекают только тех, кто заработал меньше 500$ с одного клиента, и в письме они доходчиво объяснили, что им слишком сложно обслуживать большое количество мелких заказов. Для тех, кто заработал больше 500$ с одного клиента ничего не меняется, те же 10%, плюс появляется стремление удерживать клиента, потому что с 10000$ комиссия становится всего 5%.
Плюс вы считать не умеете: не 12000$, а 11050$
Не соглашусь: если вы говорите точно, что этот метод должен вернуть SomeClass, то он уже не просто МОЖЕТ, а ДОЛЖЕН вернуть его. И если у метода нет такой возможности, то это исключительная ситуация. Так же как и при передаче параметра в функцию, если вы передадите null вместо SomeClass, то получите «Argument 1 passed to some_func() must be an instance of SomeClass, null given».
Если вы добавляете строгости своему коду, то нужно ее соблюдать, а если хотите null, то не надо закладывать строгость.
Мне интуитивно понятен именно такой подход, не понимаю полустрогости.
ой, да ладно вам дуться. Вот на гитхабе ребята более самокритичны относительно хаков https://github.com/search?q=ugly+hack&ref=reposearch&type=Code&utf8=%E2%9C%93
не, начинать надо с языка, исходники которого легко читать с гитхаба и смотреть как на нем вообще пишут, не углубляясь в магию. А Си — это магия указателей и макросы, язык грязных хаков. Чтобы легко читать на си придется развить внутренний препроцессор и резолвер указателей.
Абсолютно согласен с Fesor, в юнит-тестах вы должны были все замокать иначе получается, что вы заодно тестируете Guzzle и чужой API. Тест перестает проверять конкретный юнит, и проверяет всю цепочку.
Ой-ой, это зачем это? Надо просто писать миграции, которые не ломают обратную совместимость. А тяжелые миграции обычно накатываются аккуратненько заранее, перед релизом.
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.
Не согласен, это именно песчинка. Обычно слабое место — это поиск и сортировка данных, а отказываться от удобства и ясности в коде ради пары десятков милисекунд… ну тогда не php надо использовать.
Спасибо, сразу не приметил.
Тем не менее цитата с первой страницы теста: «Measurement is highly specific». И дальше разъяснение, что тест не учитывает вообще никакой специфики языка и меряет лишь производительность игрушечной программы. Это также легко понять если посмотреть в исходники.
Теперь понятно, почему в условиях конкурса "«Эталонный» бенчмарк является восхитительной тайной."
Самое интересное в этом бенчмарке, что в нем не показано, какой код против какого тестируют. То есть получаем 9 попугаев в вакуме. Что-то здесь не так.
Я действительно не понимаю в каком месте node уделывает php в производительности, киньте, плз, ссылку. Я не фанат php, я люблю scala. Мне просто интересны реальные тесты производительности, а гугл таких тестов не дает.
Плюс вы считать не умеете: не 12000$, а 11050$
Я понял, вам надо это https://wiki.php.net/rfc/nullable_types
Ну я не против, если в таком виде, но предпочитаю очевидную строгость.
Если вы добавляете строгости своему коду, то нужно ее соблюдать, а если хотите null, то не надо закладывать строгость.
Мне интуитивно понятен именно такой подход, не понимаю полустрогости.
> По архитектуре — это один из самых передовых вариантов
В этом месте не очень понятно, что передового в сборке php без opcache?
И тут сразу виден недостаток инструмента: он позволяет накатить все сразу, и не дает размазать миграцию по времени, чтобы не положить сервера БД.
Тем не менее цитата с первой страницы теста: «Measurement is highly specific». И дальше разъяснение, что тест не учитывает вообще никакой специфики языка и меряет лишь производительность игрушечной программы. Это также легко понять если посмотреть в исходники.
Теперь понятно, почему в условиях конкурса "«Эталонный» бенчмарк является восхитительной тайной."