Вы предлагаете просто добавлять еще больше конфигов заранее, когда это еще не нужно, кстати может поэтому они у вас и разрастаются.
Автовайринг отлично работает, и если у вас только одна реализация сервиса, не вижу смысла прописывать ее вручную, например когда у вас появится еще одна реализация, это может быть замена текущей, а не вторая, тогда все просто, удаляете предыдущую и все работает без правки конфигов. Если же добавляется новая реализация и вы используете две, то тогда вы например можете одну реализацию прописать на интерфейс, как по умолчанию, а вторую прокинуть вручную в нужные классы, в отличии от того что предлагаете вы, это намного уменьшит конфиги.
Классы вместо аргументов, таже проблема, вы увеличиваете конфиги, когда это не нужно, и в моей практике классы для которых нужно 2 сервиса с разными аргументами встречаются намного реже, и опять же когда это понадобиться можно использовать такой вариант и стить останется одинаковый: App\Service\SiteUpdateManager:
arguments:
$adminEmail: 'manager@example.com'
Интерфейс вместо реализации: опять же смотрите первый пункт, интерфейс позволяет очень легко менять реализацию, либо устанавливать реализацию по умолчанию
Не совсем понятны тезисы, они работают для обоих типов компаний. У второго типа компаний тоже есть определенный бюджет, и чем больше расходы - тем меньше доходы, так что каждому постоянно повышать себе зп тоже не получится.
По поводу увольнения тоже самое, если ты уволишься, проект продолжит жить и тебе найдут замену, во вротом типе компаний иногда это даже проще, т к могут быть уже готовые на замену люди.
По поводу того что может не остаться задач, это почти нереально, тут скорее проект могут закрыть/сократить из-за других причин, так же кстати как и в продуктовых компаниях, не стоит их рассматривать как единое целое, там внутри тоже все разбито на проекты и направления, которые могут стать неактуальными и их тоже закроют.
На втором типе компаний тебе просто найдут другой проект, что иногда даже и хорошо, т к считается, что менять домен и технологии раз в пару лет очень даже помогает. Но в любом случае, никакого страха нет, ты знаешь что просто найдешь другую компанию и скорее всего с более высокой зп.
Вовлеченность в проект в любом случае должна быть назависимо от компании, так проще, приятнее и интереснее работать. В продуктовых компаниях, при хорошей прибыли могут дать существенно лучше годовую премию, чем на галлерах, но это по моему опыту, иногда могут быть исключения в любую из сторон.
Мне четвертые в целом нравились, но все равно больше в третьх играл, в 4ых только для разнообразия, когда 3и приедались. Но в целом игра была хорошая на фоне всех игр того времени, возможно ожидали большего...
Проверял win 10, edge: загуглил 4 популярных месенджера и firefox, гугл не справился только с телеграмом, был на втором месте, в остальных случаея первые одна или неск ссылок офф сайты. Поисковые запросы на русском.
Яндекс же справился только с firefox, в остальных случаях один раз второй результат или намного ниже…
Когда человеку нечего сказать — он переходит на личности, епам — это в большинстве своем аутсорсовая компания, погуглите что это такое, вкратце мы пользуемся теми сервисами и технологиями, которые предоставляет заказчик, агрегатор логов подключен к десяткам проектов, которые в сумме генерят, может и террабайты информации, поэтому в логах мы немного ограничены, возможно все это связано и с расходами, утверждать не буду, т к этим занимаются другие команды и у нас туда очень ограниченый доступ.
Что качается xdebag'a, я сам не понял каким боком логи его заменяют, но это были ваши слова
В общем я так понимаю дискусии у нас с вами не вышло, удачи и будьте немного сдержанее…
да, спасибо что подметили, действительно если писать в 2 таблицы или более разница в 1.5-2 раза в пользу асинхрона, т е получается в нем есть смысл при большой записи в несколько таблиц…
1. Как вы можете судить хреново я сделал тест или нет, если вы даже не удосужились понять что я тестировал. Тестировал я определенную задачу, а не пытался написать код при котором асинхронный вариант будет быстрее. И как подметили выше, при добавлении данных, пусть даже множеством запросов одну таблицы я прироста не получу, надо взять хотя бы две, что я проверил и убедился если взять 2-4 таблицы, то асинхранный код получается в 1.5-2 раза быстрее, из этого я могу сделать вывод что если мне надо добавлять много данных в одну таблицу в асинхроне нет смысла, в 2 и более, стоит задуматься, но тут тоже не все так просто, но здесь хотя бы есть смысл рассмотреть асинхронный вариант
2. Вы не можете писать логи на все, в больших приложениях они будут в сутки генерировать гигабайты информации, зачастую даже агрегаторы логов просто не смогут их нормально отображать, более того у вас не всегда может быть прямой доступ к файлам логов (аггрегаторы не в счет) и придеться постоянно у кого то просить тебе его сбросить, ну и копаться в гигабайтных файлах, такое себе удовольствие. Ну и все равно на все логи не напишите…
Так вы наверное меня неправильно поняли, я о том и говорю, что в большинстве случаев для хттп запросов у нас есть curl_milti если нужна асинхронность, случаев когда нужна именно асинхронность другого типа, не так много.
По поводу вашего примера либо он не очень информативен, либо так никто делать не будет. У меня будет на странице 10 аякс запросов, и при выполнении каждого я уже увижу эту информацию на странице, я не буду все делать в одном запросе, даже при наличии асинхронности это не очень удобно, в вашем же случае итоговый результат все равно будет ждать выполнения самого медленного запроса, чтобы все это потом отрендерить.
1. Я понимаю, но я написал код который хоть немного приближен к большинству реальных задач, ваш посыл я понял, если мне надо будет выполнить 1000 хттп запросов, потом 100к инсертов в базу, не зависящих от этих запросов и потом посчитать какую-то сложную логику, не зависящую от всего вышеперечисленного, то запустив это асинхронно я получу прирост, это конечно да, но где вы такие задачи видели? не говоря уже о том что если они не зависят друг от друга кто их будет синхронно запускать? я не говорю что их вообще нет, просто их процент очень мал…
2. я согласился что тут на любителя
3. имелось ввиду то, что при выборе писать асинхронно или нет надо учесть что будут проблема с дебагингом, не важно что это и в других языках, конкретно на твоем проекте они будет, и стоит ли тот прирост производительности если он будет, отсутствия дебагинга.
4. Дело не в том что если нет из коробки это кафно, а в том что когда есть из каробки намного удобнее. Меншее количество сторонних библиотек тоже плюс. Тем более многие крупные компании не любят внедрять сторонние библиотеки, очень сложно с этим, но даже если внедряют, то берут определенную версию, ложат себе в репу, какой нибудь отдел инф безапасности все это проверяет, и потом исп новые версии будет не так просто. Это все в целом явл минусом, но не для всех
В целом мой посыл что асинхрон это хорошо, но в реальных проектах не много где применим, и уж тем более проектов где прям все писать асинхронно, еще намного меньше…
1. Понимаю что скорее придирка, но все же, если мы возьмем гипотетический пример дисковой операции, в которой в синхроне у нас файл пишеться с максимальной скоростью на диск, то в асинхроне вы не получите никакого прироста, даже наоборот.
Ну и я привел найболее частые операции: это работа с базой и отправка хттп запросов. В первом случае у нас профита никакого нет, во втором он есть, но в пхп из коробки есть скажем так асинхронный курл, поэтому надобности в дополнительных библиотеках нет.
2. По мне даже на простом примере видны небольшие отличия, на реальном коде их будет еще больше, но ок, пусть будет на любителя.
3. Мой посыл был в том, что учитывая этот минус, надо думать, а стоит ли оно того, а не думать, ну раз везде так, значит надо использовать.
4. имелось ввиду, что пдо есть из коробки, а чтобы исп возможности хотя бы пдо в асинхроне, нам надо установить amphp/amp и amphp/mysql
p.s. на самом деле синтетика плюс минус такая же, просто у человека было больше времени и он оформил код получше и с исп ооп, но работа с той же базой, на том же уровне и он навесил очень много операций и сложно судить что именно ускоряет. Не могу утверждать, но могу предположить что прирост именно за счет асинхронной работы с очередями, сообщения быстрее добавляются и быстрее обрабатываюся. Исходя из этого можно сделать вывод, если у вас паблишится десятки тысяч или даже сотни тысяч соообщений в час, вы получите более менее неплохой прирост, если же пару тысяч в сутки, то не имеет смысла…
Чтобы не было недопониманий, опишу свою позицию, я не против асинхронного кода, но в моей практике было немного зачад, где асинхрон действительно можно было бы применить и он давал ощутимый прирост, но я уверен случаи его использования есть, но скорее их не так много, как синхрона. Также я вижу немного основных недостатков асинхронного кода:
1. Он не всегда быстрее
2. Сам код менее понятный и простой
3. Более сложен для дебага
4. На данный момент требует дополнительных библиотек
ПОэтому ради присроста процентов в 10, если это не очень критичный к производительности код, учитывая все минусы я бы не использовал асинхрон, лично мое мнение, никому не навязываю…
опять же оказалось не все так радужно, заменив код в синхроне на многопоточный curl (curl_multi_exec), он оказался быстрее асинхронного варианта примерно в 2-2.5 раза, все файлы доступны в репе выше, нужно всего лишь подставить свой яндекс апи кей, который можно получить бесплатно…
не знаю насколько вы были правы, т к весь код был из примеров асинхрона, в любом случае сейчас немного поправил код, и он скорее всего выполняется асинхронно, т к поля инкремент в базе и в пхп не совпадают, до этого совпадали в обоих вариантах с пдо и с ahphp, что в принципе ожидаемо.
Но время выполнения не изменилось, я бы даже сказал увеличилось на 5-10%
кстати написав код, на отправку 100 запросов на яндекс трансдейт апи, и намеренно добавив задержку в 0.25 сек к каждому запросу, а потом инсерт результатов в базу, ожидаемо асинхрон выполняется примерно в 1,5 раза быстрее.
но если задержку не добавлять, то асинхрон примерно раз в 7 быстрее…
возможно код не самый оптимизированный, но максимально простой и похожий, из примеров, до этого не работал с асинхронными библиотеками, может чего-то упустил github.com/asmdk/ahphp_db_compare
Попробовал проверить вставку 100/10000 записей с помощью pdo и amphp, пдо оказался ровно в 2 раза быстрее, практически самый простой код, понятное дело что скорее вего будет выйгрышь на параллельных тяжеловесных операциях, но в целом асинхрон не всегда в плюс…
Меня больше волнует следующее, в прошлом году, я мог исп приложение убер в германии и италии, сейчас при запуске, просит обновиться, как я понимаю до убер бай, но мне не нужер локальное, мне нужно интернациональное приложение. Так вот вопрос, если я не буду обновлять смогу я исп убер в других странах? Или все равно нет?
Помню делал что-то похоже, но для НБ Республики Беларусь, только попроще без графиков, но не помню то ли желания, то ли времени нехватило, чтобы все до ума довести и выложить в стор, но вы молодец, не отступили на пол пути)
Самую либимаю сложно выделить, частоиспользуемые, не считая конечно самого редактора, поиска, переходов, автодопления и т д, это наверное дебагер и интеграция с различными вцс
Вы предлагаете просто добавлять еще больше конфигов заранее, когда это еще не нужно, кстати может поэтому они у вас и разрастаются.
Автовайринг отлично работает, и если у вас только одна реализация сервиса, не вижу смысла прописывать ее вручную, например когда у вас появится еще одна реализация, это может быть замена текущей, а не вторая, тогда все просто, удаляете предыдущую и все работает без правки конфигов. Если же добавляется новая реализация и вы используете две, то тогда вы например можете одну реализацию прописать на интерфейс, как по умолчанию, а вторую прокинуть вручную в нужные классы, в отличии от того что предлагаете вы, это намного уменьшит конфиги.
Классы вместо аргументов, таже проблема, вы увеличиваете конфиги, когда это не нужно, и в моей практике классы для которых нужно 2 сервиса с разными аргументами встречаются намного реже, и опять же когда это понадобиться можно использовать такой вариант и стить останется одинаковый:
App\Service\SiteUpdateManager: arguments: $adminEmail: 'manager@example.com'Интерфейс вместо реализации: опять же смотрите первый пункт, интерфейс позволяет очень легко менять реализацию, либо устанавливать реализацию по умолчанию
Не совсем понятны тезисы, они работают для обоих типов компаний. У второго типа компаний тоже есть определенный бюджет, и чем больше расходы - тем меньше доходы, так что каждому постоянно повышать себе зп тоже не получится.
По поводу увольнения тоже самое, если ты уволишься, проект продолжит жить и тебе найдут замену, во вротом типе компаний иногда это даже проще, т к могут быть уже готовые на замену люди.
По поводу того что может не остаться задач, это почти нереально, тут скорее проект могут закрыть/сократить из-за других причин, так же кстати как и в продуктовых компаниях, не стоит их рассматривать как единое целое, там внутри тоже все разбито на проекты и направления, которые могут стать неактуальными и их тоже закроют.
На втором типе компаний тебе просто найдут другой проект, что иногда даже и хорошо, т к считается, что менять домен и технологии раз в пару лет очень даже помогает. Но в любом случае, никакого страха нет, ты знаешь что просто найдешь другую компанию и скорее всего с более высокой зп.
Вовлеченность в проект в любом случае должна быть назависимо от компании, так проще, приятнее и интереснее работать. В продуктовых компаниях, при хорошей прибыли могут дать существенно лучше годовую премию, чем на галлерах, но это по моему опыту, иногда могут быть исключения в любую из сторон.
Мне четвертые в целом нравились, но все равно больше в третьх играл, в 4ых только для разнообразия, когда 3и приедались. Но в целом игра была хорошая на фоне всех игр того времени, возможно ожидали большего...
Яндекс же справился только с firefox, в остальных случаях один раз второй результат или намного ниже…
Что качается xdebag'a, я сам не понял каким боком логи его заменяют, но это были ваши слова
В общем я так понимаю дискусии у нас с вами не вышло, удачи и будьте немного сдержанее…
2. Вы не можете писать логи на все, в больших приложениях они будут в сутки генерировать гигабайты информации, зачастую даже агрегаторы логов просто не смогут их нормально отображать, более того у вас не всегда может быть прямой доступ к файлам логов (аггрегаторы не в счет) и придеться постоянно у кого то просить тебе его сбросить, ну и копаться в гигабайтных файлах, такое себе удовольствие. Ну и все равно на все логи не напишите…
По поводу вашего примера либо он не очень информативен, либо так никто делать не будет. У меня будет на странице 10 аякс запросов, и при выполнении каждого я уже увижу эту информацию на странице, я не буду все делать в одном запросе, даже при наличии асинхронности это не очень удобно, в вашем же случае итоговый результат все равно будет ждать выполнения самого медленного запроса, чтобы все это потом отрендерить.
2. я согласился что тут на любителя
3. имелось ввиду то, что при выборе писать асинхронно или нет надо учесть что будут проблема с дебагингом, не важно что это и в других языках, конкретно на твоем проекте они будет, и стоит ли тот прирост производительности если он будет, отсутствия дебагинга.
4. Дело не в том что если нет из коробки это кафно, а в том что когда есть из каробки намного удобнее. Меншее количество сторонних библиотек тоже плюс. Тем более многие крупные компании не любят внедрять сторонние библиотеки, очень сложно с этим, но даже если внедряют, то берут определенную версию, ложат себе в репу, какой нибудь отдел инф безапасности все это проверяет, и потом исп новые версии будет не так просто. Это все в целом явл минусом, но не для всех
В целом мой посыл что асинхрон это хорошо, но в реальных проектах не много где применим, и уж тем более проектов где прям все писать асинхронно, еще намного меньше…
Ну и я привел найболее частые операции: это работа с базой и отправка хттп запросов. В первом случае у нас профита никакого нет, во втором он есть, но в пхп из коробки есть скажем так асинхронный курл, поэтому надобности в дополнительных библиотеках нет.
2. По мне даже на простом примере видны небольшие отличия, на реальном коде их будет еще больше, но ок, пусть будет на любителя.
3. Мой посыл был в том, что учитывая этот минус, надо думать, а стоит ли оно того, а не думать, ну раз везде так, значит надо использовать.
4. имелось ввиду, что пдо есть из коробки, а чтобы исп возможности хотя бы пдо в асинхроне, нам надо установить amphp/amp и amphp/mysql
p.s. на самом деле синтетика плюс минус такая же, просто у человека было больше времени и он оформил код получше и с исп ооп, но работа с той же базой, на том же уровне и он навесил очень много операций и сложно судить что именно ускоряет. Не могу утверждать, но могу предположить что прирост именно за счет асинхронной работы с очередями, сообщения быстрее добавляются и быстрее обрабатываюся. Исходя из этого можно сделать вывод, если у вас паблишится десятки тысяч или даже сотни тысяч соообщений в час, вы получите более менее неплохой прирост, если же пару тысяч в сутки, то не имеет смысла…
1. Он не всегда быстрее
2. Сам код менее понятный и простой
3. Более сложен для дебага
4. На данный момент требует дополнительных библиотек
ПОэтому ради присроста процентов в 10, если это не очень критичный к производительности код, учитывая все минусы я бы не использовал асинхрон, лично мое мнение, никому не навязываю…
Но время выполнения не изменилось, я бы даже сказал увеличилось на 5-10%
но если задержку не добавлять, то асинхрон примерно раз в 7 быстрее…
github.com/asmdk/ahphp_db_compare
если $_GET['limit'] будет равно нулю, то $value будет равно 10, но я хочу, чтобы было 0, в этих случаях empty не подходит, а isset — да