Соглашусь с мыслью. Безусловно, каждому свое и там и там есть свои плюсы/минусы, но встречал не раз на вид очень крутых разрабов после курсов, ответят на любой вопрос, пройдут собес чуть ли не на сеньера, знают нюансы в своей области, но шаг вправо/влево от идеальных условий и все ломается, простые баги не могут решать месяцами просто потому-что нет навыка "разбираться с неизведанным"
Еще забыли один тип программистов - эффективные гавнокодеры. Решающие все задачи в лоб с максимальным копи-пастом вместо постройки архитектуры. Отличаются тем, что дают бизнесу максимально быстро продукт плохого качества с технической точки зрения и терпимого внешне. Такие сотрудники ценятся по своему, часто собирают вокруг себя похожих и объединяются в гавнокод-команды.
Дело ведь не в том, что спрашивали, а чего нет. Все допускают ошибки и пишут порой неоптимизированный код, удивляет только то, что никто этого не заметил и не пофиксил
На мой взгляд, дело даже не в уровне знания языка, у нас профессия требующая умения учиться, это не такой уж и распространенный навык на самом деле, упадут зп в ит — учишь язык и пакуешь чемоданы, к тому же есть миллион профессий в т.ч. высокооплачиваемых на которые можно переквалифицироваться
У нас никого не уволили (по крайней мере из разработчиков), даже плохо работающих, несмотря на то, что с переходом на удаленку эффективность у многих сильно просела.
Более того, с начала карантина начал получать много сообщений от hr, субъективно раза в два больше чем в прошлом году.
Образование безусловно важно и ВУЗ простите не является обязательным его атрибутом. Автор пытается нас убедить, что количество хороших разработчиков без высшего образования настолько мало, что можно фильтровать резюме по этому параметру, что конечно противоречит его же высказыванию про отсутствие computer science в большинстве вузов.
Сильные разработчики без высшего образование не исключение, а нарастающая тенденция.
Справедливости ради путем хитрых манипуляций в zoom можно таки организовать p2p вызов на двоих и вот тут как раз наверное есть e2e, но это не точно. Если это так, то не вижу принципиальных отличий от той же телеги
В чем преимущество выбора инстанса по хешу от рандомного? Ведь в обоих случаях нода подписывается на все инстансы редиса. Если мысль в том, чтобы нода подписывалась на нужный инстанс редиса при коннекте пользователя, то проблема в том, что в реальной жизни когда клиентов будет сколь нибудь много, нода в конечном итоге подпишется все равно на все инстансы и каждое сообщение будет дублироваться на все ноды.
На мой взгляд эффективнее все же вести таблицу связей uid->nodeId в том же редис, где nodeId это уникальный ид ноды который генерится при запуске, нода подписывается на канал со своим id. При отправке сообщения очень просто достается nodeId используя uid, отправляется на конкретный канал ноды и это сообщение получает только та нода на которой подключен пользователь.
В заключении, хотелось бы заметить, что вы решаете проблему которая давно и довольно неплохо решена разработчиками редиса. redis cluster даст вам любую масштабируемость и отказоустойчивость которая вам нужна
Почему бы не совместить оба варианта? Когда точно знаешь что понадобятся некоторые поля указываешь как в mongoose populate и подгружаешь все что нужно одним запросом, но и фишка с await user.groups тоже остается
Поддерживаю все сказанное выше. Говоря о каких либо библиотеках где связность кода небольшая юнит тесты действительно оправдывают себя, но если мы говорим о бизнес-проекте с большим количеством взаимозависимых частей намного эффективнее писать интеграционные тесты. Жаль только мир охватил хайп unit-тестирования, как и со всяким хайпом инструмент используют везде не проводя анализ целесообразности писать тонны тестов с миллионом моков только лишь для того чтобы сказать — у нас 95% покрытие кода. Найдутся люди которые скажут что за зависимость модулей в аду отдельный котел, но непонятно как они строят проекты без зависимых частей, реальные проекты, а не вот мой синтетический проект с двумя моделями.
Все что сказано выше относится к проектам с <5 разработчиков/направление, думаю unit оправдывает себя в больших компаниях где над каждым модулем работает отдельная команда
Не меньше интересует как ведет себя хакинтош в плане стабильности, насколько геморно обновляться? Лично я пользуюсь маком не столько из за хкода, сколько из за стабильности и удобства разработки
Соглашусь с мыслью. Безусловно, каждому свое и там и там есть свои плюсы/минусы, но встречал не раз на вид очень крутых разрабов после курсов, ответят на любой вопрос, пройдут собес чуть ли не на сеньера, знают нюансы в своей области, но шаг вправо/влево от идеальных условий и все ломается, простые баги не могут решать месяцами просто потому-что нет навыка "разбираться с неизведанным"
Еще забыли один тип программистов - эффективные гавнокодеры. Решающие все задачи в лоб с максимальным копи-пастом вместо постройки архитектуры. Отличаются тем, что дают бизнесу максимально быстро продукт плохого качества с технической точки зрения и терпимого внешне. Такие сотрудники ценятся по своему, часто собирают вокруг себя похожих и объединяются в гавнокод-команды.
Дело ведь не в том, что спрашивали, а чего нет. Все допускают ошибки и пишут порой неоптимизированный код, удивляет только то, что никто этого не заметил и не пофиксил
Отсортировать, записать в файл и искать бинарным поиском. Почему нет ?
На мой взгляд, дело даже не в уровне знания языка, у нас профессия требующая умения учиться, это не такой уж и распространенный навык на самом деле, упадут зп в ит — учишь язык и пакуешь чемоданы, к тому же есть миллион профессий в т.ч. высокооплачиваемых на которые можно переквалифицироваться
У нас никого не уволили (по крайней мере из разработчиков), даже плохо работающих, несмотря на то, что с переходом на удаленку эффективность у многих сильно просела.
Более того, с начала карантина начал получать много сообщений от hr, субъективно раза в два больше чем в прошлом году.
Думаю, что на деле все сильно сложнее. Наверняка "ок" еще подписывается приватным ключем не говоря уже об ssl
Образование безусловно важно и ВУЗ простите не является обязательным его атрибутом. Автор пытается нас убедить, что количество хороших разработчиков без высшего образования настолько мало, что можно фильтровать резюме по этому параметру, что конечно противоречит его же высказыванию про отсутствие computer science в большинстве вузов.
Сильные разработчики без высшего образование не исключение, а нарастающая тенденция.
Справедливости ради путем хитрых манипуляций в zoom можно таки организовать p2p вызов на двоих и вот тут как раз наверное есть e2e, но это не точно. Если это так, то не вижу принципиальных отличий от той же телеги
В целом согласен, но с оговоркой что тесты должны быть интеграционными. От юнит тестов при более-менее большом рефакторинге толку ноль
Но ведь чем уже специальность, тем сложнее найти работника. Это ставит под вопрос "дешевизну" узкоспециализированных специалистов
В чем преимущество выбора инстанса по хешу от рандомного? Ведь в обоих случаях нода подписывается на все инстансы редиса. Если мысль в том, чтобы нода подписывалась на нужный инстанс редиса при коннекте пользователя, то проблема в том, что в реальной жизни когда клиентов будет сколь нибудь много, нода в конечном итоге подпишется все равно на все инстансы и каждое сообщение будет дублироваться на все ноды.
На мой взгляд эффективнее все же вести таблицу связей uid->nodeId в том же редис, где nodeId это уникальный ид ноды который генерится при запуске, нода подписывается на канал со своим id. При отправке сообщения очень просто достается nodeId используя uid, отправляется на конкретный канал ноды и это сообщение получает только та нода на которой подключен пользователь.
В заключении, хотелось бы заметить, что вы решаете проблему которая давно и довольно неплохо решена разработчиками редиса. redis cluster даст вам любую масштабируемость и отказоустойчивость которая вам нужна
Да, отлично, это я и имел ввиду
Почему бы не совместить оба варианта? Когда точно знаешь что понадобятся некоторые поля указываешь как в mongoose populate и подгружаешь все что нужно одним запросом, но и фишка с await user.groups тоже остается
Замечательная вещь, await user.groups просто гениально, надеюсь решение доростет до продакшена
Я отвечал не вам
Поддерживаю все сказанное выше. Говоря о каких либо библиотеках где связность кода небольшая юнит тесты действительно оправдывают себя, но если мы говорим о бизнес-проекте с большим количеством взаимозависимых частей намного эффективнее писать интеграционные тесты. Жаль только мир охватил хайп unit-тестирования, как и со всяким хайпом инструмент используют везде не проводя анализ целесообразности писать тонны тестов с миллионом моков только лишь для того чтобы сказать — у нас 95% покрытие кода. Найдутся люди которые скажут что за зависимость модулей в аду отдельный котел, но непонятно как они строят проекты без зависимых частей, реальные проекты, а не вот мой синтетический проект с двумя моделями.
Все что сказано выше относится к проектам с <5 разработчиков/направление, думаю unit оправдывает себя в больших компаниях где над каждым модулем работает отдельная команда
Конкретно в вашем случае может и нет смысла. Я пытался донести, что проблема была вовсе не в async await, а в неправильной обработке исключений.
Обернули бы этот await в try/catch и ошибка так же отлавливалась бы