Ну тогда прошу прощения за неточность. Я изначально с 3м классом тут был, так что говорю по прикидкам. А так, если кому интересно, есть специальные порталы, чтобы прикинуть свою зп на руки: https://www.brutto-netto-rechner.info/
Уважаемые коллеги.
Не могу пройти мимо и не оставить в комменте под этим постом свой мыслеляп.
Я уже 5 лет работаю в Германии, в Берлине, и хочу сразу дать ряд комментариев по теме:
1) Хороших и толковых разрабов не хватает!!! ВЕЗДЕ!!! (вот именно так, капсом и с восклицательными знаками). Хайринг идет с бешенной интенсивностью, а людей всё равно не хватает. Такая же ситуация с крупными компаниями типа FB, Google, Amazon и тп. Вот только там всё куда "интереснее". Порог вхождения — колоссальный из-за сложности интервью, а фактически, ты как инженер работаешь над тупейшими задачами в рамках 10-15летних лигаси монолитов (Amazon Shop не является клиентом AWS, чтобы вы знали). Практически всё — кастомное, любое изменение ведет за собой лютую бюррократию. Так что не всё так радужно.
2) Бабки. Тут, дамы и господа, я вас разочарую. Да, в Европе средняя зп 65к в год. Вот только давайте чуть разъясню. В России, когда выкладывается вакансия, зарплата дается в гросс (т.е. чистыми зп гросс — 13% подоходного). В Германии налоги платит сам сотрудник. Т.е. зарплата в 65к в год (брутто), при 1 налоговом классе (привет прогрессивная шкала налогообложения), превратиться в 32-33к в год, что поделить на 12 будет ~2700. Из них вы ещё заплатите за аренду, воду, электричество и тп в районе 1000-1200, а на остальное будете жить. Посчитайте сами свои Московские доходы и сравните =)
3) Безопасность, социум, культура. Ребята. "Везде хорошо, где нас нет!" Так говорится в одной поговорке. Надо стремиться к тому, чтобы было "Везде хорошо, где мы есть."
Тут тоже огромное количество как сложностей, так и радостей. В абсолюте же, всё +- одинаково. Просто каждому человеку — свой удобный набор плюсов и минусов.
Согласен с предыдущим постом. Можно еще загнаться и сделать федерптивный кластер. Наши девопсов таким занимаются, поднимая единый энв на AWS и частном провайдера одновременно
личный проект — однозначно (на нем же отрабатываю фишки из рабочих проектах)
каждый день перед обедом (за полчаса где-то) хожу на турники неподалеку от работы. 5 подходов творят чудеса с аппетитом и с ментальной усталостью. Так же на работу и с работы передвигаюсь на велосипеде (~10 км дороги в одну сторону)
выгорание ловил пару раз, когда делал ремпейдж на работе + на личном проекте. Здорово помогает неделя отпуска без программирования с шашлыками
а по поводу ежедневной разрядки — игры с двухлетней дочерью + катки в Overwatch (оп-па, рекламка!)
Довольно неплохая презентация за исключением одного. Лектор крайне предвзят и слишком саркастичен в отношении многих аспектов многих языков (конечно по большей части php).
И, пожалуй, некие нотки надменности присутствуют. Хотя, скорее всего, я ошибаюсь.
Я сильно извиняюсь, вылезая из глубокого бекенда я был немного удивлён тем, что в фронтендовом js до сих пор нет единого стандарта композиции приложения и импорта/ленивой подгрузки файлов! Неужели всё так печально?
ну, ИМХО, это путь «по глубокому внутреннему миру». Всё-таки в микросервисы нужно выделять отдельные бизнес-компоненты и уже их «общать» друг с другом. А тут, получается, вы пилите самого юзера на микросервисы. Имеет ли это смысл? Возможно. Всё зависит от задач.
«Кто онлайн», по идее, должен быть статусом пользователя, а не отдельной сущностью. А друзья пользователя — это бридж-таблица many-many к юзерам. Ну это если работа идет в рамках единой БД.
Скорость. С подпроцессами можно было обрабатывать пакеты по 20-30 entity одновременно. Соответственно на 8 потоках это 160-240 величин секунд за 5-10. С очередями получилось бы медленнее.
Возможно. Но давайте оставим такие решения на суд кодревью. Так или иначе, никто из комментаторов того кода не видел. А смысл обсуждать то, что не видели — практически нулевой.
Данная статья не об оптимизации, как я писал ниже.
Это даже не руководство. А просто мой личный опыт реализации работы компоненты на конкретном примере.
И нацелен он был не на умудрённых опытом кавалеристов с овер-9000ным уровнем скилла, а на людей ищущих примеров реализации асинхронности в php.
Спасибо большое за ценную обратную связь.
На досуге попробую решить проблему утечки памяти на описанном примере.
По теме хочу сказать лишь одно. Ребят, тема не «Оптимизация работы проекта с помощью асинхронного выполнения PHP скриптов» и не «Руководство по асинхронному выполнению PHP скриптов». Поэтому как-то неприятно, что ли, получилось.
Эта статья была создана исключительно ради того, чтобы на живом примере показать, как с помощью описанных компонент можно реализовать асинхронность. Причиной тому стало то, что ранее я с подобным опытом не сталкивался, поэтому решил поделится.
Если же у вас такого опыта более, чем достаточно — я очень вам завидую.
Но сарказм в данном случае не самое архитектурно красивое решение.
С одной стороны, да, было принято такое решение.
С другой стороны, не стали делать это лишь потому, что вариант с распараллеливанием был наименее затратным для одноразовой команды.
И ещё один момент)))
Жуть как хотелось попробовать (=
Действительно сложно отрицать несостыковку в показателях. Но скорее всего я просто поймал момент смены процессов или это баг самого htopa.
В качестве пруфа я и выложил реп. Можно потестить на своей тачке.
По поводу оптимизации.
Да, для каких-то постоянных решений, особенно которые будут закладываться в ядро системы, я бы ни в коем случае не стал бы такое использовать. И все тяжелые скрипты нужно переписывать и разносить логику.
Данный же случай — скорее исключение. Нужно было написать одноразовую команду по сбору своеобразного «среза» с текущего состояние БД.
В лоб не получилось. С оптимизацией, имхо, было бы гораздо больше геморроя.
По поводу постскриптума.
Да, суть уловил верно. Это своеобразный рецепт по использованию. Подобных решений я, к сожалению, не встречал. Решил, что некоторым может быть полезно.
Инфа ~2 летней давности. Знакомый устроился в амазон и как-то разговаривали про инфраструктуры. Собственно всё)
Ну тогда прошу прощения за неточность. Я изначально с 3м классом тут был, так что говорю по прикидкам. А так, если кому интересно, есть специальные порталы, чтобы прикинуть свою зп на руки: https://www.brutto-netto-rechner.info/
зависит от города. Я живу в Берлине и мои траты выглядят как раз примерно так.
Уважаемые коллеги.
Не могу пройти мимо и не оставить в комменте под этим постом свой мыслеляп.
Я уже 5 лет работаю в Германии, в Берлине, и хочу сразу дать ряд комментариев по теме:
1) Хороших и толковых разрабов не хватает!!! ВЕЗДЕ!!! (вот именно так, капсом и с восклицательными знаками). Хайринг идет с бешенной интенсивностью, а людей всё равно не хватает. Такая же ситуация с крупными компаниями типа FB, Google, Amazon и тп. Вот только там всё куда "интереснее". Порог вхождения — колоссальный из-за сложности интервью, а фактически, ты как инженер работаешь над тупейшими задачами в рамках 10-15летних лигаси монолитов (Amazon Shop не является клиентом AWS, чтобы вы знали). Практически всё — кастомное, любое изменение ведет за собой лютую бюррократию. Так что не всё так радужно.
2) Бабки. Тут, дамы и господа, я вас разочарую. Да, в Европе средняя зп 65к в год. Вот только давайте чуть разъясню. В России, когда выкладывается вакансия, зарплата дается в гросс (т.е. чистыми зп гросс — 13% подоходного). В Германии налоги платит сам сотрудник. Т.е. зарплата в 65к в год (брутто), при 1 налоговом классе (привет прогрессивная шкала налогообложения), превратиться в 32-33к в год, что поделить на 12 будет ~2700. Из них вы ещё заплатите за аренду, воду, электричество и тп в районе 1000-1200, а на остальное будете жить. Посчитайте сами свои Московские доходы и сравните =)
3) Безопасность, социум, культура. Ребята. "Везде хорошо, где нас нет!" Так говорится в одной поговорке. Надо стремиться к тому, чтобы было "Везде хорошо, где мы есть."
Тут тоже огромное количество как сложностей, так и радостей. В абсолюте же, всё +- одинаково. Просто каждому человеку — свой удобный набор плюсов и минусов.
Спасибо, я всё)
Извиняюсь, писал поздно вечером с телефона. Моя тупость недосмотрела за тупостью автодополнятора (=
Согласен с предыдущим постом. Можно еще загнаться и сделать федерптивный кластер. Наши девопсов таким занимаются, поднимая единый энв на AWS и частном провайдера одновременно
У меня такой список методов-помощников:
Но! Этот код выглядит мило)))
И, пожалуй, некие нотки надменности присутствуют. Хотя, скорее всего, я ошибаюсь.
Тем не менее, спасибо за интересный материал))))
Спасибо.
Данная статья не об оптимизации, как я писал ниже.
Это даже не руководство. А просто мой личный опыт реализации работы компоненты на конкретном примере.
И нацелен он был не на умудрённых опытом кавалеристов с овер-9000ным уровнем скилла, а на людей ищущих примеров реализации асинхронности в php.
На досуге попробую решить проблему утечки памяти на описанном примере.
По теме хочу сказать лишь одно. Ребят, тема не «Оптимизация работы проекта с помощью асинхронного выполнения PHP скриптов» и не «Руководство по асинхронному выполнению PHP скриптов». Поэтому как-то неприятно, что ли, получилось.
Эта статья была создана исключительно ради того, чтобы на живом примере показать, как с помощью описанных компонент можно реализовать асинхронность. Причиной тому стало то, что ранее я с подобным опытом не сталкивался, поэтому решил поделится.
Если же у вас такого опыта более, чем достаточно — я очень вам завидую.
Но сарказм в данном случае не самое архитектурно красивое решение.
С одной стороны, да, было принято такое решение.
С другой стороны, не стали делать это лишь потому, что вариант с распараллеливанием был наименее затратным для одноразовой команды.
И ещё один момент)))
Жуть как хотелось попробовать (=
UPD
Кстати. Решено всё было исключительно при помощи средств php. Symfony Process Component базируется на функции
proc_open()Действительно сложно отрицать несостыковку в показателях. Но скорее всего я просто поймал момент смены процессов или это баг самого htopa.
В качестве пруфа я и выложил реп. Можно потестить на своей тачке.
По поводу оптимизации.
Да, для каких-то постоянных решений, особенно которые будут закладываться в ядро системы, я бы ни в коем случае не стал бы такое использовать. И все тяжелые скрипты нужно переписывать и разносить логику.
Данный же случай — скорее исключение. Нужно было написать одноразовую команду по сбору своеобразного «среза» с текущего состояние БД.
В лоб не получилось. С оптимизацией, имхо, было бы гораздо больше геморроя.
По поводу постскриптума.
Да, суть уловил верно. Это своеобразный рецепт по использованию. Подобных решений я, к сожалению, не встречал. Решил, что некоторым может быть полезно.
Еще раз спасибо за дельный отзыв ;)