Имхо, лучше посмотреть запись доклада, там и ссылки на инструменты есть, и интересные вопросы задают в конце, после которых суть, что именно было сделано, становится понятнее.
Если мы с автором поста решали одно и то же задание, то, на мой взгляд, это решение не полное решение задачи.
+1, из текста статьи:
Однажды, в качестве тестового задания на позицию PHP разработчика была предложена задача реализации сервиса проверки номеров паспортов граждан РФ на предмет нахождения в списке недействительных.
А в итоге была реализована библиотека, которая общается с редисом.
На мой взгляд, в задаче необходимо отказаться от промежуточного веб сервера, реализовав обработку подключений внутри своего сервиса, использовать персистентное HTTP подключение, а данные хранить в памяти процесса.
Имхо, http очень дорого в данном случае, и стоит использовать соединение на сокетах и какой-нибудь лёгкий бинарный протокол.
P.S. В статье ничего не написано про то, отдаёт ли реализация ответ за 1 ms, а это одно из основных требований.
Спасибо за обновление!
Наткнулся на багу в нативном JS: WEB-41429.
У меня так и не получилось добиться нормального автокомплита при использовании es6-модулей.
Из-за этой баги WebStorm получается совсем неюзабельным.
Исправьте, пожалуйста! Уже больше чем пол года прошло :(
И пишешь на бумажке: «Согласно пункту 14 152-го ФЗ прошу вести обработку персональных данных в бумажном виде». Я не знаю, как точно это в Белоруссии делается, но наверняка это делается. По российским законам вам не имеют права отказать на основании этого в услуге.
Не нашёл этого в 14й статье, ну и вообще нагуглить не смог. Если кто-то в курсе, о какой части 152-го ФЗ идёт речь, поделитесь, плз, цитатой или ссылкой.
Имхо, лучше использовать пакет, который активно поддерживается.
С другой стороны, в случае использования и проблем с cweagans/composer-patches можно стать одним из мейнтейнеров этого пакета. Т.к. cweagans/composer-patches проще, то делать в него вклад тоже должно быть проще.
Allan Paiste (я же правильно понимаю, о ком идет речь в «автор vaimo/composer-patches»?)
Да.
Вообще, добавление форка в Packagist не выглядит как хорошая идея.
Не могли бы вы раскрыть свою мысль?
Моя мысль была в том, что у Allan Paiste уже был hard fork, который он не собирался вливать в оригинал со своим именем в composer.json и своим уникальным функционалом. В данном случае просто напрашивается опубликовать пакет на Packagist.
Для меня, в первую очередь, автообнаружением патчей. Я очень не люблю править composer.json руками;
Согласен, я это как раз отметил как одно из преимуществ, но немного другими словами.
Не рассматривал, но на вскидку будут все те же проблемы, с форками, т.к. этап форк и его поддержки никуда не денется. Так же вопрос, а что если будет 2 библиотеки, в которых разные replace-ы на одну и ту же библиотеку. Скорее всего они будут не совместимы.
This allows you to fork a package, publish it under a different name with its own version numbers, while packages requiring the original package continue to work with your fork because it replaces the original package.
Про свои версии я не очень понял, в статье пункт на эту тему был "Сделать в своём форке phpunit/php-code-coverage, чтобы тег 7.0.8 ссылался на другой коммит. Это как минимум неочевидно, а как максимум — в Git неудобно работать с тегами, ссылающимися на разные коммиты с одним названием в разных удалённых репозиториях.".
А как вы считаете, какие преимущества у replace по сравнению патчами?
Точно, в js нет неймспейсов, есть модули, поэтому спокойно можно использовать разные версии одних и тех же библиотек.
Значит остаётся только небольшая трудность — подтягивать изменения в свой форк при обновлении оригинальной библиотеки. В общем проблема есть, но не такая острая.
Не знаю, как это будет работать для случая, когда вы используете зависимость, которая зависит от форка, при этом есть другие пакеты, которые зависят от оригинала. Не уверен, что там не будет проблем с тем, что бы определить, какую версию ставить.
Но даже если там оно как-то поставится, то в случае форка, его всё равно нужно будет при обновлении зависимости всегда обновлять форк. Патч же с большой вероятностью установится на следующую минорную версию.
В общем, я думаю в npm при использовании форков будут проблемы, подобные тем, что описаны в статье.
Мало занимаюсь js, поэтому не сталкивался с проблемой фикса зависимостей.
Так или иначе беглый гуглинг выдаёт patch-package. Т.е. с похожей проблемой в js сталкиваются.
Добавил пункт в статью, подробно не стал рассматривать, т.к. по количеству действий этот вариант не сильно отличается от тега альфа релиза.
Ещё раз спасибо!
Спасибо, искал, но не нашёл такую возможность.
Тем не менее по вашей ссылке:
Note: Inline aliasing is a root-only feature. If a package with inline aliases is required, the alias (right of the as) is used as the version constraint. The part left of the as is discarded. As a consequence, if A requires B and B requires monolog/monolog version dev-bugfix as 1.0.x-dev, installing A will make B require 1.0.x-dev, which may exist as a branch alias or an actual 1.0 branch. If it does not, it must be inline-aliased again in A's composer.json. Note: Inline aliasing should be avoided, especially for published packages/libraries. If you found a bug, try and get your fix merged upstream. This helps to avoid issues for users of your package.
Т.е. в каждом проекте всё равно нужно будет вручную прописывать алиасинг. Я рассмотрю подробнее эту возможность и возможно обновлю статью с учётом её.
У PHP, кмк, меньше всего преимуществ (именно для хайлоада, сам язык норм). И я написал почему, в предыдущих коментах.
В php давно есть API для выполнения параллельных curl-запросов, запросов в БД, которые можно использовать в стандартном php-fpm. Есть асинхронные фреймворки amphp, ReactPHP, которые правда накладывают ограничения на код (эти ограничения есть и в nodejs и в других языках).
Если в Badoo крутятся 100500 серверов, то переписав с PHP на Раст можно сэкономить кучу денег.
Нужно иметь ввиду, что в проектах с многолетней историей, вроде Badoo, уже написано очень много кода. Поэтому на переписывание этого кода нужно будет потратить кучу (большую) денег на разработчиков, а так же кучу времени, вместо выпуска новых фич. Как уже писали выше, перейти на PHP 7.4 с прелоадом проще. От себя добавлю, что это гораздо дешевле, экономит сервера (пусть в меньшей степени), и самое главное точно окупается.
Так или иначе в баду есть сервисы для которых php не очень подходит, и они написаны не на php.
Имхо, лучше посмотреть запись доклада, там и ссылки на инструменты есть, и интересные вопросы задают в конце, после которых суть, что именно было сделано, становится понятнее.
Но всё равно спасибо за конспект!
Я писал про данный случай — где требование 1мс и вроде речь шла про язык php.
+1, из текста статьи:
А в итоге была реализована библиотека, которая общается с редисом.
Имхо, http очень дорого в данном случае, и стоит использовать соединение на сокетах и какой-нибудь лёгкий бинарный протокол.
P.S. В статье ничего не написано про то, отдаёт ли реализация ответ за 1 ms, а это одно из основных требований.
P.P.S. Про экономию памяти было интересно :)
Спасибо за обновление!
Наткнулся на багу в нативном JS: WEB-41429.
У меня так и не получилось добиться нормального автокомплита при использовании es6-модулей.
Из-за этой баги WebStorm получается совсем неюзабельным.
Исправьте, пожалуйста! Уже больше чем пол года прошло :(
Спасибо конечно, но я писал, что не нашёл этого в 14й статье. Сейчас на всякий случай прочитал ещё раз, и опять же не нашёл.
Не нашёл этого в 14й статье, ну и вообще нагуглить не смог. Если кто-то в курсе, о какой части 152-го ФЗ идёт речь, поделитесь, плз, цитатой или ссылкой.
Имхо, лучше использовать пакет, который активно поддерживается.
С другой стороны, в случае использования и проблем с cweagans/composer-patches можно стать одним из мейнтейнеров этого пакета. Т.к. cweagans/composer-patches проще, то делать в него вклад тоже должно быть проще.
Да.
Не могли бы вы раскрыть свою мысль?
Моя мысль была в том, что у Allan Paiste уже был hard fork, который он не собирался вливать в оригинал со своим именем в composer.json и своим уникальным функционалом. В данном случае просто напрашивается опубликовать пакет на Packagist.
Согласен, я это как раз отметил как одно из преимуществ, но немного другими словами.
Не рассматривал, но на вскидку будут все те же проблемы, с форками, т.к. этап форк и его поддержки никуда не денется. Так же вопрос, а что если будет 2 библиотеки, в которых разные replace-ы на одну и ту же библиотеку. Скорее всего они будут не совместимы.
Про свои версии я не очень понял, в статье пункт на эту тему был "Сделать в своём форке phpunit/php-code-coverage, чтобы тег 7.0.8 ссылался на другой коммит. Это как минимум неочевидно, а как максимум — в Git неудобно работать с тегами, ссылающимися на разные коммиты с одним названием в разных удалённых репозиториях.".
А как вы считаете, какие преимущества у replace по сравнению патчами?
Как и обещал, вот ссылка на перевод https://badootech.badoo.com/php-xdebug-proxy-when-xdebugs-standard-capabilities-are-insufficient-49fe86943f12
Точно, в js нет неймспейсов, есть модули, поэтому спокойно можно использовать разные версии одних и тех же библиотек.
Значит остаётся только небольшая трудность — подтягивать изменения в свой форк при обновлении оригинальной библиотеки. В общем проблема есть, но не такая острая.
Не знаю, как это будет работать для случая, когда вы используете зависимость, которая зависит от форка, при этом есть другие пакеты, которые зависят от оригинала. Не уверен, что там не будет проблем с тем, что бы определить, какую версию ставить.
Но даже если там оно как-то поставится, то в случае форка, его всё равно нужно будет при обновлении зависимости всегда обновлять форк. Патч же с большой вероятностью установится на следующую минорную версию.
В общем, я думаю в npm при использовании форков будут проблемы, подобные тем, что описаны в статье.
Мало занимаюсь js, поэтому не сталкивался с проблемой фикса зависимостей.
Так или иначе беглый гуглинг выдаёт patch-package. Т.е. с похожей проблемой в js сталкиваются.
Привычка осталась с давних времён, когда по другому не умел)
Спасибо, поправил.
Добавил пункт в статью, подробно не стал рассматривать, т.к. по количеству действий этот вариант не сильно отличается от тега альфа релиза.
Ещё раз спасибо!
Спасибо, искал, но не нашёл такую возможность.
Тем не менее по вашей ссылке:
Т.е. в каждом проекте всё равно нужно будет вручную прописывать алиасинг. Я рассмотрю подробнее эту возможность и возможно обновлю статью с учётом её.
В php давно есть API для выполнения параллельных curl-запросов, запросов в БД, которые можно использовать в стандартном php-fpm. Есть асинхронные фреймворки amphp, ReactPHP, которые правда накладывают ограничения на код (эти ограничения есть и в nodejs и в других языках).
Нужно иметь ввиду, что в проектах с многолетней историей, вроде Badoo, уже написано очень много кода. Поэтому на переписывание этого кода нужно будет потратить кучу (большую) денег на разработчиков, а так же кучу времени, вместо выпуска новых фич. Как уже писали выше, перейти на PHP 7.4 с прелоадом проще. От себя добавлю, что это гораздо дешевле, экономит сервера (пусть в меньшей степени), и самое главное точно окупается.
Так или иначе в баду есть сервисы для которых php не очень подходит, и они написаны не на php.
В планах есть перевести эту статью на английский. Я скину сюда ссылку, когда переведём.
Спасибо за PR, это интересное решение. Мы, кстати, ждём твой ответ в комментариях к нему.
Да есть, но в случае закрытой сети он работать не будет. Например, если разработчик сидит за NAT-ом.