Каждому своё. Мне после двух лет начало сильно не нравится в Питере:
Почти нет солнца и постоянно дождливая погода, без витамина Д впадаешь в тоску и грусть
Жизнь дороже на 20% примерно, если не на все 50.
По началу было очень классно кататься на метро, а потом стало раздражать перемещение под землей
Коммунальщики города очень плохо работают, зимой вынужден пробираться сквозь кучи неубранного снега (и еще посматриваешь вверх, чтобы лепнина с сосульками не убила)
Единственный магазин с натуральными продуктами – ВкусВилл, свежие овощи/фрукты поди найди еще в этом городе, про клубнику вообще молчу. Скорее всего будет напичкана антибиотиками, чтобы пережила транспортировку.
Если не хочешь жить в бетонных джунглях (девяткино, кудрово) вынужден платить за жилье от 40-50к, когда в том же Краснодаре за эту цену можно жить в центре города в новом доме с хорошим ремонтом.
Ну а так конечно город прикольный, но нам разработчикам то что. Вид с окна всегда одинаковый где бы ты ни был, а пару месяцев жары можно и дома потерпеть. Тут хотя бы кондиционер в помещении это стандарт де-факто, в отличие от Питера.
Согласен с вами, наверно стоило бы сказать "по возможности стоит избегать" или "в зависимости от вашей ситуации". Потому что, конечно же, бывают случаи когда удобно отправить синхронный запрос, все зависит от контекста приложения и ваших потребностей)
В том то и дело, что клиенту результат о том, что "событие добавлено в ленту" не нужен, это происходит автоматически и клиент об этом может и не знать)
В первом случае же никто не обращается за данными, скорее один сервис посылает их сам в Ленту, когда произошло какое-то событие. Ну и события тоже конечно хранятся)
Если лента уже асинхронная, то и воркер хорошо бы сделать таким же, чтобы можно было шарить готовые функции между ними) А так наверно не критично конечно)
В целом, неплохое предложение по дальнейшему развитию, ну и выглядит как вариант 4) Мне показался достаточным 3-й вариант, когда воркер просто смотрит в БД, но, все мы знаем, что лучший код еще не написан)
У нас нагрузки разные, лента запускается на трех подах, worker на двух, плюс еще у ленты соединение к БД на пулах, а у worker-а нет. Ваш подход не предлагает такой гибкости в настройке)
На мой взгляд нужно стремиться к асинхронному подходу из-за этих причин:
1) Увеличиваете длительность работы эндпоинта, а от этого замедляется система в целом, клиент долго ждет ответ от сервера и так далее снежным комом
2) Если вдруг по каким-то причинам лента приляжет на короткий промежуток времени и будет невозможно отправить событие туда, то оно просто потеряется. Чтобы этого не допустить можно добавить ретраи в код, но это еще больше увеличит длительность работы эндпоинта, замедлит систему и опять снежный ком)
Вы серьезно спрашиваете это на собеседовании? У вас настолько низкий уровень кодовой базы, что приходится понимать где киррилическая Н, а где H? Как эти вопросы определят, что кандидат способен разрабатывать промышленные продукты? Может вы и про black не слышали?
Думаю, что стоит отказываться от код ревью, когда его эффективность начинает стремиться к 0. Я согласен, что возможно ревьюер, который по опыту не превосходит автора решения может найти какую то опечатку, но возможно стоит задуматься о том, что времязатраты на это не очень оправданы.
То же самое касается и конфликтов, если они очень сильно тормозят feature delivery, тогда, кажется, стоит пересмотреть процессы в команде.
Если это какой то очень чувствительный функционал, из за которого будет "оппечатка на проде", то конечно его стоит просмотреть дополнительно.
Я больше имел в виду ситуацию когда у вам нужно например добавить новое поле на выдачу для фронта из БД. На такие вещи не стоит тратить время ревьюера.
Хорошее замечание, и в целом справедливое. Но есть большой минус такой проверки, это ее бесполезность для предлагаемого решения. При таком подходе мы уже преследуем другую цель - обучение младших сотрудников, потому что скорее всего единственный конструктив, который сможет привнести младший разработчик - это сказать о том, что ему что то не понятно.
Если вам хочется назначать на ревью джуна, который будет смотреть код более опытных коллег, то я бы просто добавил его как еще одного ревьюера к привычному флоу.
Удаленно можно работать + тут офисы крупных компаний. Напомню, что Магнит родом из Краснодара.
спасибо за статью!
Каждому своё. Мне после двух лет начало сильно не нравится в Питере:
Почти нет солнца и постоянно дождливая погода, без витамина Д впадаешь в тоску и грусть
Жизнь дороже на 20% примерно, если не на все 50.
По началу было очень классно кататься на метро, а потом стало раздражать перемещение под землей
Коммунальщики города очень плохо работают, зимой вынужден пробираться сквозь кучи неубранного снега (и еще посматриваешь вверх, чтобы лепнина с сосульками не убила)
Единственный магазин с натуральными продуктами – ВкусВилл, свежие овощи/фрукты поди найди еще в этом городе, про клубнику вообще молчу. Скорее всего будет напичкана антибиотиками, чтобы пережила транспортировку.
Если не хочешь жить в бетонных джунглях (девяткино, кудрово) вынужден платить за жилье от 40-50к, когда в том же Краснодаре за эту цену можно жить в центре города в новом доме с хорошим ремонтом.
Ну а так конечно город прикольный, но нам разработчикам то что. Вид с окна всегда одинаковый где бы ты ни был, а пару месяцев жары можно и дома потерпеть. Тут хотя бы кондиционер в помещении это стандарт де-факто, в отличие от Питера.
Живу в Краснодаре, 2 года жил в СПб и часто бывал в Мск, разница действительно ощущается в обеспеченности)
Согласен с вами, наверно стоило бы сказать "по возможности стоит избегать" или "в зависимости от вашей ситуации". Потому что, конечно же, бывают случаи когда удобно отправить синхронный запрос, все зависит от контекста приложения и ваших потребностей)
В том то и дело, что клиенту результат о том, что "событие добавлено в ленту" не нужен, это происходит автоматически и клиент об этом может и не знать)
В первом случае же никто не обращается за данными, скорее один сервис посылает их сам в Ленту, когда произошло какое-то событие. Ну и события тоже конечно хранятся)
Если лента уже асинхронная, то и воркер хорошо бы сделать таким же, чтобы можно было шарить готовые функции между ними) А так наверно не критично конечно)
В целом, неплохое предложение по дальнейшему развитию, ну и выглядит как вариант 4) Мне показался достаточным 3-й вариант, когда воркер просто смотрит в БД, но, все мы знаем, что лучший код еще не написан)
У нас нагрузки разные, лента запускается на трех подах, worker на двух, плюс еще у ленты соединение к БД на пулах, а у worker-а нет. Ваш подход не предлагает такой гибкости в настройке)
На мой взгляд нужно стремиться к асинхронному подходу из-за этих причин:
1) Увеличиваете длительность работы эндпоинта, а от этого замедляется система в целом, клиент долго ждет ответ от сервера и так далее снежным комом
2) Если вдруг по каким-то причинам лента приляжет на короткий промежуток времени и будет невозможно отправить событие туда, то оно просто потеряется. Чтобы этого не допустить можно добавить ретраи в код, но это еще больше увеличит длительность работы эндпоинта, замедлит систему и опять снежный ком)
Я правильно понимаю, что если будет использоваться фильтр, из-за которого нужно приджоинить таблицу к запросу, то все равно все сведется к if-ам?
Вы серьезно спрашиваете это на собеседовании? У вас настолько низкий уровень кодовой базы, что приходится понимать где киррилическая Н, а где H? Как эти вопросы определят, что кандидат способен разрабатывать промышленные продукты? Может вы и про black не слышали?
152-ФЗ есть у множества провайдеров, тот же Selectel например, и независимые дата центры на территории России. В общем, маркетинг видимо повлиял)
А чем обусловлен выбор именно Яндекс.Облака?
Привет! Спасибо за вопрос, я в статье подробно описал почему не использовали средства полнотекстового поиска в PostgreSQL.
Думаю, что стоит отказываться от код ревью, когда его эффективность начинает стремиться к 0. Я согласен, что возможно ревьюер, который по опыту не превосходит автора решения может найти какую то опечатку, но возможно стоит задуматься о том, что времязатраты на это не очень оправданы.
То же самое касается и конфликтов, если они очень сильно тормозят feature delivery, тогда, кажется, стоит пересмотреть процессы в команде.
Поддерживаю такой подход, он в целом не идет в разрез с тем, что написано в статье, а даже расширяет эффективность код ревью.
Если это какой то очень чувствительный функционал, из за которого будет "оппечатка на проде", то конечно его стоит просмотреть дополнительно.
Я больше имел в виду ситуацию когда у вам нужно например добавить новое поле на выдачу для фронта из БД. На такие вещи не стоит тратить время ревьюера.
Хорошее замечание, и в целом справедливое. Но есть большой минус такой проверки, это ее бесполезность для предлагаемого решения. При таком подходе мы уже преследуем другую цель - обучение младших сотрудников, потому что скорее всего единственный конструктив, который сможет привнести младший разработчик - это сказать о том, что ему что то не понятно.
Если вам хочется назначать на ревью джуна, который будет смотреть код более опытных коллег, то я бы просто добавил его как еще одного ревьюера к привычному флоу.