Испытательный срок для вас шутка какая-то? Ревью кода тоже шутка?
Вы нанимаете человека для решения конкретных задач. Если он решает эти задачи, отвалите от него. И научитесь нормально собесы проводить, а то многие взяли моду с листочка читать, когда сами в теме не шарят и даже уточняющих вопросов дать не могут, которые реальный опыт проверят.
Спасибо за внимательное чтение, но склонна с вами не согласиться.
Статья вводная и упрощенная, она ориентирована на людей, которые только начинают. Упрощения здесь допущены сознательно (да и уровень сложности, как вы видите, указан простой). Статья, может, и поверхностная, но человек с околонулевым опытом, по крайней мере не сойдёт с ума, при знакомстве с новыми терминами и сможет уже дальше копать в более техническую сторону.
Мои слова о том, что разница только в том, как доставляются события, подразумевают разницу в прикладном уровне использования апи. Здесь речь об архитектурных различиях не идёт.
На счёт дешевизны вебхуков - это также вопрос формулировки. Вебхуки снижают сетевую нагрузку. Если мы уже говорим про инфраструктуру с тысячами пользователей, там уже да, действительно другие факторы добавляются, но это не тот кейс.
По ингресам, может это ответ не со всем по методичке, но думаю это вопрос вкуса. Я, правда, не слышала, чтобы с апи гейтвея переходили на ингресы, обычно наоборот происходит. В целом они решают похожие задачи, но гейтвей просто имеет чуть больше фич
независимый деплой не единственная цель микросервисов. И я вам как раз как QA могу сказать, что никто никогда не будет тестировать все комбинации всех версий микросервисов :D это нереалистичный сценарий) но помимо этого он еще и избыточный, если мы налаживаем адекватные процессы и используем адекватные инструменты (как раз backward compatibility, тестирование контрактов и т.д.)
на самом деле я отчасти с вами даже согласна, потому что сейчас действительно в тренде повально юзать микросервисы там где надо и там где не надо, но говорить о том, что они не нужны в принципе, это все равно что говорить, что капельницы не нужны потому что сельские терапевты их регулярно назначают по приколу "чтобы сосудики почистить"
На счет коммуникации - имеет место быть неоднозначная формулировка, я имела ввиду коммуникацию внутри команды одного сервиса.
На счет всего остального: мне кажется, вы описываете какую-то идеальную картинку) ну либо мы не до конца понимаем друг друга. Команда команде рознь, не в каждой команде адекватно формализуются и соблюдаются контракты. То же про версионирование - давайте смотреть правде в глаза, во-первых не каждая команда может себе позволить его нормально поддерживать, во-вторых не в каждой команде нормально выстроены процессы по его обеспечению, а магическим образом оно само, к сожалению, не настраивается
Мне нравится ваш комментарий с точки зрения вещей, которые еще можно рассмотреть и добавить в статью, но с точки зрения критики микросервисов как таковых - это же всего лишь инструмент, который можно реализовать совершенно по разному. Логично, что у него есть свои недостатки и свои преимущества. Никто его не идеализирует (по крайней мере такой цели не стояло)
С другой стороны, я могу по пальцам пересчитать случаи, когда на последних моих двух проектах требовалось деплоить несколько сервисов одновременно из-за версионирования. Можно сказать, что для стартапов и относительно новых проектов проблема на первых этапах не так актуальна, как для зрелых проектов, но если взять какой нибудь амазон или нетфликс, у которых тоже микросервисы, так они и деплоятся независимо, и совместимость у них тестируется нормально, и брейкинг ченджес между версиями не наблюдается (вроде)
Ну и да, логично, что микросервисы независимости сами по себе не дают, но независимость это результат работы команды, а не свойство архитектуры из коробки само по себе.
Добрый вечер, большое спасибо за подробную обратную связь! Статья действительно больше обзорная (но про GPT было обидно, да)) и задумывалась как собеседовательный чек-лист без глубокого погружения, а не исчерпывающий материал по теме.
Что касается практической реализации, думаю не будет лишним сделать отдельную статью по тому же CB. Собственно, глубокий практический разбор каждого упомянутого паттерна тянет на собственную статью, потому что при попытках уместить все в одну получится талмуд.
К слову сказать более подробный материал, в том числе ответы на ваши вопросы, вы можете услышать на открытом уроке, ссылка есть в статье, подключайтесь)
Я лично не считаю что подобные обзоры бесполезны или вредны, при подготовке к собеседованиям имхо они служат хорошей точкой входа, в том числе на вводном уровне. Понятно же, что одной единственной прочитанной статьи не хватит для прохождения собеседования даже на уровень стажера.
Да, в английском “props” действительно множественное, но в русском это слово прижилось как отдельный термин — по тому же принципу, как “чипсы” или “шорты”. Так что “пропсы” звучит нормально для React-сообщества и давно стало частью профессионального сленга. В том числе если вы откроете официальную документацию реакт, вы увидите, что там используются именно пропсы. Даже в английском форму prop используют редко в живой речи или коде
Еще не видела ни одной статьи на тему "Готовьтесь, всё подешевеет")) как будто в текущих реалиях вообще нельзя допускать мысль, что что-то подешевеет или хотя бы останется на том же уровне
Ну оземпик так смело прописывать в качестве волшебной таблетки для похудения идея сомнительная. Ничего лучше дефицита калорий + умеренные силовые тренировки еще не придумали
Имхо смысл статьи заключается в том, чтобы посмотреть, как работают основные фичи React с точки зрения практического использования, а не с точки зрения их внутренней реализации) да и на случайный набор примеров она, по моему мнению, не катит.
Для новичков (да и не только) весьма полезно, поскольку как раз рассматривает основные фичи
Упс, дефект перевода! Держала в голове, что нужно это убрать, и под конец забыла. Но в оригинальной статье можно посмотреть интерактивные демо, они отличные)
не думаю, что такие статьи собирают кучу плюсов, хотя бы потому что все видят эти паттерны и минусуют) А на счет длинных тире не согласна - я именно текстовые какие-то работы пишу в ворде, гораздо приятнее тире вместо дефисов видеть + ворд автоматически подставляет тире вместо дефиса в тексте. Но да, есть еще супер длинные тире, вот их я даже хз как ставить, а нейронка проставляет
В какой момент хабр превратился в филиал одноклассников?) И как можно "входить в айти" даже номинально не ознакомившись с тем, как обучается нейросеть и на каком объёме текстов. Теории заговоров какие-то.
Информация
В рейтинге
381-я
Откуда
Ростов-на-Дону, Ростовская обл., Россия
Дата рождения
Зарегистрирована
Активность
Специализация
Инженер по автоматизации тестирования, Инженер по ручному тестированию
Испытательный срок для вас шутка какая-то? Ревью кода тоже шутка?
Вы нанимаете человека для решения конкретных задач. Если он решает эти задачи, отвалите от него. И научитесь нормально собесы проводить, а то многие взяли моду с листочка читать, когда сами в теме не шарят и даже уточняющих вопросов дать не могут, которые реальный опыт проверят.
Я не знаю кто вообще в здравом уме полезет делать бизнес из тг канала)
да, кстати, вы, кажется, прочли статью невнимательно, поскольку в ней есть диаграммы как для шорт, так и для лонг поллинга) ну либо вы их перепутали
Спасибо за внимательное чтение, но склонна с вами не согласиться.
Статья вводная и упрощенная, она ориентирована на людей, которые только начинают. Упрощения здесь допущены сознательно (да и уровень сложности, как вы видите, указан простой). Статья, может, и поверхностная, но человек с околонулевым опытом, по крайней мере не сойдёт с ума, при знакомстве с новыми терминами и сможет уже дальше копать в более техническую сторону.
Мои слова о том, что разница только в том, как доставляются события, подразумевают разницу в прикладном уровне использования апи. Здесь речь об архитектурных различиях не идёт.
На счёт дешевизны вебхуков - это также вопрос формулировки. Вебхуки снижают сетевую нагрузку. Если мы уже говорим про инфраструктуру с тысячами пользователей, там уже да, действительно другие факторы добавляются, но это не тот кейс.
динамический анализ это один из методов реверс инжиниринга и поскольку статья вводная и "для самых маленьких", то это вполне корректно)
Разумеется не предлагаю, когда есть тот же ngnix)
По ингресам, может это ответ не со всем по методичке, но думаю это вопрос вкуса. Я, правда, не слышала, чтобы с апи гейтвея переходили на ингресы, обычно наоборот происходит. В целом они решают похожие задачи, но гейтвей просто имеет чуть больше фич
независимый деплой не единственная цель микросервисов. И я вам как раз как QA могу сказать, что никто никогда не будет тестировать все комбинации всех версий микросервисов :D это нереалистичный сценарий) но помимо этого он еще и избыточный, если мы налаживаем адекватные процессы и используем адекватные инструменты (как раз backward compatibility, тестирование контрактов и т.д.)
на самом деле я отчасти с вами даже согласна, потому что сейчас действительно в тренде повально юзать микросервисы там где надо и там где не надо, но говорить о том, что они не нужны в принципе, это все равно что говорить, что капельницы не нужны потому что сельские терапевты их регулярно назначают по приколу "чтобы сосудики почистить"
На счет коммуникации - имеет место быть неоднозначная формулировка, я имела ввиду коммуникацию внутри команды одного сервиса.
На счет всего остального: мне кажется, вы описываете какую-то идеальную картинку) ну либо мы не до конца понимаем друг друга. Команда команде рознь, не в каждой команде адекватно формализуются и соблюдаются контракты. То же про версионирование - давайте смотреть правде в глаза, во-первых не каждая команда может себе позволить его нормально поддерживать, во-вторых не в каждой команде нормально выстроены процессы по его обеспечению, а магическим образом оно само, к сожалению, не настраивается
Мне нравится ваш комментарий с точки зрения вещей, которые еще можно рассмотреть и добавить в статью, но с точки зрения критики микросервисов как таковых - это же всего лишь инструмент, который можно реализовать совершенно по разному. Логично, что у него есть свои недостатки и свои преимущества. Никто его не идеализирует (по крайней мере такой цели не стояло)
С другой стороны, я могу по пальцам пересчитать случаи, когда на последних моих двух проектах требовалось деплоить несколько сервисов одновременно из-за версионирования. Можно сказать, что для стартапов и относительно новых проектов проблема на первых этапах не так актуальна, как для зрелых проектов, но если взять какой нибудь амазон или нетфликс, у которых тоже микросервисы, так они и деплоятся независимо, и совместимость у них тестируется нормально, и брейкинг ченджес между версиями не наблюдается (вроде)
Ну и да, логично, что микросервисы независимости сами по себе не дают, но независимость это результат работы команды, а не свойство архитектуры из коробки само по себе.
Добрый вечер, большое спасибо за подробную обратную связь! Статья действительно больше обзорная (но про GPT было обидно, да)) и задумывалась как собеседовательный чек-лист без глубокого погружения, а не исчерпывающий материал по теме.
Что касается практической реализации, думаю не будет лишним сделать отдельную статью по тому же CB. Собственно, глубокий практический разбор каждого упомянутого паттерна тянет на собственную статью, потому что при попытках уместить все в одну получится талмуд.
К слову сказать более подробный материал, в том числе ответы на ваши вопросы, вы можете услышать на открытом уроке, ссылка есть в статье, подключайтесь)
Я лично не считаю что подобные обзоры бесполезны или вредны, при подготовке к собеседованиям имхо они служат хорошей точкой входа, в том числе на вводном уровне. Понятно же, что одной единственной прочитанной статьи не хватит для прохождения собеседования даже на уровень стажера.
Зуб даю, в этой статье без ИИ не обошлось
Но мысль хорошая :)
Там не длинное тире, там среднее какое-то (в ворде)
Да, в английском “props” действительно множественное, но в русском это слово прижилось как отдельный термин — по тому же принципу, как “чипсы” или “шорты”. Так что “пропсы” звучит нормально для React-сообщества и давно стало частью профессионального сленга. В том числе если вы откроете официальную документацию реакт, вы увидите, что там используются именно пропсы. Даже в английском форму prop используют редко в живой речи или коде
Еще не видела ни одной статьи на тему "Готовьтесь, всё подешевеет")) как будто в текущих реалиях вообще нельзя допускать мысль, что что-то подешевеет или хотя бы останется на том же уровне
Ну оземпик так смело прописывать в качестве волшебной таблетки для похудения идея сомнительная. Ничего лучше дефицита калорий + умеренные силовые тренировки еще не придумали
Мне одной кажется, что все эти поколения в целом одинаковые, просто лозунги-кричалки взяли разные?
Имхо смысл статьи заключается в том, чтобы посмотреть, как работают основные фичи React с точки зрения практического использования, а не с точки зрения их внутренней реализации) да и на случайный набор примеров она, по моему мнению, не катит.
Для новичков (да и не только) весьма полезно, поскольку как раз рассматривает основные фичи
Упс, дефект перевода! Держала в голове, что нужно это убрать, и под конец забыла. Но в оригинальной статье можно посмотреть интерактивные демо, они отличные)
Спасибо что заметили :)
не думаю, что такие статьи собирают кучу плюсов, хотя бы потому что все видят эти паттерны и минусуют) А на счет длинных тире не согласна - я именно текстовые какие-то работы пишу в ворде, гораздо приятнее тире вместо дефисов видеть + ворд автоматически подставляет тире вместо дефиса в тексте. Но да, есть еще супер длинные тире, вот их я даже хз как ставить, а нейронка проставляет
В какой момент хабр превратился в филиал одноклассников?) И как можно "входить в айти" даже номинально не ознакомившись с тем, как обучается нейросеть и на каком объёме текстов. Теории заговоров какие-то.