Староверы и вайб кодеры друг друга никогда не поймут, пока не начнут обсуждать области применимости. Одним не понятно как можно вайбкодить сложные системы, другим не понятно зачем сайты-визитки вручную оптимизировать на ассемблере. По факту и то, и другое полная ерунда, и никто в здоровом уме ей не занимается. Но это не главное, главное - каждый день на словах отменять революцию!
Не хочется называть компании, да и "замена" не получается одномоментно, у всего есть своя инерция. Но по направлениям, например, распознавания документов, семантический поиск, генерация фото и видео для продуктов и т.д. Раньше для этого нужно было дорогое оборудование, либо свои МЛ-модели, технологии или большой штат с дорогими специалистами. Сейчас же достаточно обертки над популярным моделями, а качество порой может быть не только не хуже, но и лучше, смотря какая область применения. Конечно, это в первую очередь касается малых и средних компаний, корпорации в силу инерции могут пользоваться и старым софтом, тупо потому что переход на новый может быть слишком дорогим.
Есть у меня ощущение, что подобные статьи это попытка инженеров спорить с рекламой. Выглядит так же странно, как если бы статьи были о том, что стиральные порошки не все пятна могут отстирать, а по телеку-то сказали что все, безобразие! Каждую неделю вирусится по статье в стиле "а ЛЛМ то оказывается может и ошибки делать, надо с ними осторожнее", и в комментах "ого, а я думал это я один заметил, надо же какие мы наблюдательные, а вот openai в своей рекламе так хвастались, но мы их на чистую воду вывели". А потом путем исчерпывающих умозаключений приходят к тому, что это инструмент, который нужно использовать в правильных местах и с умом. Ну ничего себе, статье лайк неглядя! А дальше в комментах куча когнитивных искажений уровня "если я заметил ошибку у ЛЛМ, то я король и на всем многообразии технологии надо ставить крест, я бы таких ошибок ТОЧНО не сделал". И это все напоминает какую-то бесконечную оду самолюбию и доказательство самим себе почему людей нельзя заменить не только сейчас, но и вообще никогда и никого. Ну, может кого-то да, но меня точно нет, я же ошибки ЛЛМ заметил. А по факту заменяют не столько сотрудников, сколько целые компании: стартапы схлопываются пачками, потому что каждые полгода у ИИ появляются фичи, которые просто делают продукт целой компании ненужным и экономически бессмысленным.
Можно сразу на прикладном примере. Вот у вас в компании документация есть, предположим. Есть актуальная, а есть устаревшая. Есть полная и точная, а бывает и наоборот. Вот её кто-то должен прочитать, обновить и промаркировать, старую удалить. Это и будут верифицированные данные. А то, о чем вы говорите - проблема скорее надуманная, LLM эти концепции отлично отделяет и не путается.
Почему же нет? Телефон при съёмке может быть направлен под определенным углом к поверхности земли, и от этого фото должны зависеть (например земля по ногами или верхушки деревьев). А вот температуру модели обычно degrees не называют
Я поискал по нашим статьям и, пожалуй, специальных материалов на эти темы у нас нет, но касаемо этих вопросов ответы такие: - Делаем E2E тестов атомарными и быстрыми. В этом случае тесты, разумеется, уже не будут E2E, правильнее теперь их называть UI-тестами. Атомарность могут обеспечить всего 2 вещи: дизайн тест кейсов и ускоренная подготовка данных. Например, вместо E2E сценария, где пользователь обычным образом регистрируется, логинится и начинает работать с веб-приложением, тест кейс должен предполагать минимальное число действий, чтобы получить нужный результат. Для этого кроме сокращения числа необязательных и длительных степов, мы еще и по максимуму стараемся перенести их на сторону API. Стандартных инструментов здесь, как правило, недостаточно, поэтому на бэкенде бывает нужно написать дополнительные тестове эндпоинты, которые помогут создать ускоренную регистрацию, логин, и подготовку аккаунта. Это самые затратные шаги. Идеально, если после логина сразу же произойдет редирект в нужную вью с подготовленным для теста состоянием. Тогда оставшаяся UI часть теста представляет из себя пару кликов и проверку, в нашем случае эта часть длится 2-3 секунды для подавляющего числа тестов. - Про демо-страницы так подробно рассказать не смогу, т.к. я сам не фронтендер, но мы используем архитектуру микро-фронтендов, которая уже стала де-факто стандартом в индустрии, по этому запросу гуглится огромное количество статей. Далее на демо-странице должно быть замокано все взаимодействие с внешней частью страницы, дополнительно могут быть добавлены переключатели состояния элементов страницы, т.к. в реальности они определяются именно внешними элементами. Очень удобно, когда эти параметры являются параметрами URL, тогда можно просто по ссылке получить нужное состояние страницы.
Надеюсь, ответил :) Если у вас остались более специфичные вопросы - милости прошу в ЛС
Отличный вопрос! Дело в том, что наши UI-тесты очень далеки от Е2Е тестов, они атомарны и очень быстры, для каждого теста все подготовки данных делаются через API-запросы, а средняя длина сценария после логина и загрузки страницы составляет 1-3 секунды. Кроме того, мы стараемся по минимуму работать с полноценным веб-приложением, большинство тестов работают с облегченными демо-страницами или плейбуками.
Для того, чтобы билд с упавшими тестами ушел в продакшен, каждый упавший тест должен быть проверен ответственными, но в нашем случае это суммарно несколько десятков тестов в день перед каждым деплоем, что не такая большая проблема.
Насчет отключения тестов действительно, может звучать опасно, но здесь стоит определить, насколько тест должен быть нестабильным, чтобы было очевидно, что вреда он приносит больше, чем пользы. Иначе каждый работающий с тестом человек в компании будет разбираться с уже известной проблемой.
Что касается 100 стабильных билдов и затем внезапные падения - тоже хороший вопрос. Для этого у нас есть отдельный маленький сервис, который работает в билдах для мерджа в RC (там ожидается, что ветки проверены и багов уже быть не должно). Если тест с хорошей статистикой внезапно сломался и упал во всех сборках несколько раз подряд, ответственные сразу получают нотификацию.
Мой вопрос возник именно отсюда. Со статьями согласен, процент не очень хороших статей достаточно велик, и модерация часто страдает. Но для себя я заметил, что намного лучше осваиваю материал, если смотрю видео на ютубе где все те же мысли из книг наглядно анимированы. По паттереам пытался читать знаменитую банду четырех, и ничего скучнее в жизни своей не видел (не значит, что книга плохая, это абсолютно субьективно, head first еще более-менее). Причем есть куча источников, где те же самые паттерны объяснены намного более наглядно и с отличными примерами, и все это не книги. И после этого довольно странно было бы на собесе получить минус карандашиком за то, что "не читаю книг".
Очень странно и скомкано выглядит последний пункт про книги. Хотелось бы подробностей, почему вы считаете, что книги это лучший из возможных форматов получения знаний? Чем хуже курсы, статьи или видео?
В аналитике речь не об "угадываниях", а о вероятностях. У нас есть статистика, которая показывает определенную тенденцию, выводы из этого можно сделать разные. И гарантий, разумеется, эти цифры не дают.
В заголовке про Россию ничего и не сказано. Кроме того, в России и не было массовых сокращений, наоборот - нехватка специалистов и соответствующий рост зарплат.
Курсы порой стоят слишком дорого и оценить их качество практически невозможно. Имхо намного лучший вариант - разбираться самому, в работе именно этот навык пригодится и никогда не устареет. А если хочется быстрее выучиться, то проще и дешевле найти себе ментора и общаться с ним только на нужные тебе темы.
До использования Allure Test Ops мы пользовались Allure Report, то есть привычка развешивать аннотации для степов и классов в компании уже была. Тем не менее, даже если бы пришлось внедрять систему сейчас, мы могли бы передавать в степ преобразованное имя java-метода, используя те же листенеры, эту же логику мы сейчас используем, чтобы не приходилось вручную писать имя теста. А что касается самих листенеров, мы используем кое-какие из JUnit5 (там вместо листенеров экстеншены) или AspectJ (который идет вместе с Allure, и хоть это и не совсем листенер, но суть в контексте та же) для того, чтобы, например, автоматически прокидывать методы с @BeforeEach как самостоятельные степы.
Староверы и вайб кодеры друг друга никогда не поймут, пока не начнут обсуждать области применимости. Одним не понятно как можно вайбкодить сложные системы, другим не понятно зачем сайты-визитки вручную оптимизировать на ассемблере. По факту и то, и другое полная ерунда, и никто в здоровом уме ей не занимается. Но это не главное, главное - каждый день на словах отменять революцию!
Не хочется называть компании, да и "замена" не получается одномоментно, у всего есть своя инерция. Но по направлениям, например, распознавания документов, семантический поиск, генерация фото и видео для продуктов и т.д. Раньше для этого нужно было дорогое оборудование, либо свои МЛ-модели, технологии или большой штат с дорогими специалистами. Сейчас же достаточно обертки над популярным моделями, а качество порой может быть не только не хуже, но и лучше, смотря какая область применения. Конечно, это в первую очередь касается малых и средних компаний, корпорации в силу инерции могут пользоваться и старым софтом, тупо потому что переход на новый может быть слишком дорогим.
Есть у меня ощущение, что подобные статьи это попытка инженеров спорить с рекламой. Выглядит так же странно, как если бы статьи были о том, что стиральные порошки не все пятна могут отстирать, а по телеку-то сказали что все, безобразие! Каждую неделю вирусится по статье в стиле "а ЛЛМ то оказывается может и ошибки делать, надо с ними осторожнее", и в комментах "ого, а я думал это я один заметил, надо же какие мы наблюдательные, а вот openai в своей рекламе так хвастались, но мы их на чистую воду вывели". А потом путем исчерпывающих умозаключений приходят к тому, что это инструмент, который нужно использовать в правильных местах и с умом. Ну ничего себе, статье лайк неглядя! А дальше в комментах куча когнитивных искажений уровня "если я заметил ошибку у ЛЛМ, то я король и на всем многообразии технологии надо ставить крест, я бы таких ошибок ТОЧНО не сделал". И это все напоминает какую-то бесконечную оду самолюбию и доказательство самим себе почему людей нельзя заменить не только сейчас, но и вообще никогда и никого. Ну, может кого-то да, но меня точно нет, я же ошибки ЛЛМ заметил. А по факту заменяют не столько сотрудников, сколько целые компании: стартапы схлопываются пачками, потому что каждые полгода у ИИ появляются фичи, которые просто делают продукт целой компании ненужным и экономически бессмысленным.
Можно сразу на прикладном примере. Вот у вас в компании документация есть, предположим. Есть актуальная, а есть устаревшая. Есть полная и точная, а бывает и наоборот. Вот её кто-то должен прочитать, обновить и промаркировать, старую удалить. Это и будут верифицированные данные. А то, о чем вы говорите - проблема скорее надуманная, LLM эти концепции отлично отделяет и не путается.
Да не в моралфожности тут дело, просто жить то хочется. Мощный ИИ это кладезь техногенных катастроф
Исчерпывающее исследование, после такого можно сразу делать далеко идущие выводы
Почему же нет? Телефон при съёмке может быть направлен под определенным углом к поверхности земли, и от этого фото должны зависеть (например земля по ногами или верхушки деревьев). А вот температуру модели обычно degrees не называют
Я поискал по нашим статьям и, пожалуй, специальных материалов на эти темы у нас нет, но касаемо этих вопросов ответы такие:
- Делаем E2E тестов атомарными и быстрыми. В этом случае тесты, разумеется, уже не будут E2E, правильнее теперь их называть UI-тестами. Атомарность могут обеспечить всего 2 вещи: дизайн тест кейсов и ускоренная подготовка данных. Например, вместо E2E сценария, где пользователь обычным образом регистрируется, логинится и начинает работать с веб-приложением, тест кейс должен предполагать минимальное число действий, чтобы получить нужный результат. Для этого кроме сокращения числа необязательных и длительных степов, мы еще и по максимуму стараемся перенести их на сторону API. Стандартных инструментов здесь, как правило, недостаточно, поэтому на бэкенде бывает нужно написать дополнительные тестове эндпоинты, которые помогут создать ускоренную регистрацию, логин, и подготовку аккаунта. Это самые затратные шаги. Идеально, если после логина сразу же произойдет редирект в нужную вью с подготовленным для теста состоянием. Тогда оставшаяся UI часть теста представляет из себя пару кликов и проверку, в нашем случае эта часть длится 2-3 секунды для подавляющего числа тестов.
- Про демо-страницы так подробно рассказать не смогу, т.к. я сам не фронтендер, но мы используем архитектуру микро-фронтендов, которая уже стала де-факто стандартом в индустрии, по этому запросу гуглится огромное количество статей. Далее на демо-странице должно быть замокано все взаимодействие с внешней частью страницы, дополнительно могут быть добавлены переключатели состояния элементов страницы, т.к. в реальности они определяются именно внешними элементами. Очень удобно, когда эти параметры являются параметрами URL, тогда можно просто по ссылке получить нужное состояние страницы.
Надеюсь, ответил :) Если у вас остались более специфичные вопросы - милости прошу в ЛС
Отличный вопрос! Дело в том, что наши UI-тесты очень далеки от Е2Е тестов, они атомарны и очень быстры, для каждого теста все подготовки данных делаются через API-запросы, а средняя длина сценария после логина и загрузки страницы составляет 1-3 секунды. Кроме того, мы стараемся по минимуму работать с полноценным веб-приложением, большинство тестов работают с облегченными демо-страницами или плейбуками.
Для того, чтобы билд с упавшими тестами ушел в продакшен, каждый упавший тест должен быть проверен ответственными, но в нашем случае это суммарно несколько десятков тестов в день перед каждым деплоем, что не такая большая проблема.
Насчет отключения тестов действительно, может звучать опасно, но здесь стоит определить, насколько тест должен быть нестабильным, чтобы было очевидно, что вреда он приносит больше, чем пользы. Иначе каждый работающий с тестом человек в компании будет разбираться с уже известной проблемой.
Что касается 100 стабильных билдов и затем внезапные падения - тоже хороший вопрос. Для этого у нас есть отдельный маленький сервис, который работает в билдах для мерджа в RC (там ожидается, что ветки проверены и багов уже быть не должно). Если тест с хорошей статистикой внезапно сломался и упал во всех сборках несколько раз подряд, ответственные сразу получают нотификацию.
Много вы книг читали, где примеры на нескольких языках одновременно?
Мой вопрос возник именно отсюда. Со статьями согласен, процент не очень хороших статей достаточно велик, и модерация часто страдает. Но для себя я заметил, что намного лучше осваиваю материал, если смотрю видео на ютубе где все те же мысли из книг наглядно анимированы. По паттереам пытался читать знаменитую банду четырех, и ничего скучнее в жизни своей не видел (не значит, что книга плохая, это абсолютно субьективно, head first еще более-менее). Причем есть куча источников, где те же самые паттерны объяснены намного более наглядно и с отличными примерами, и все это не книги. И после этого довольно странно было бы на собесе получить минус карандашиком за то, что "не читаю книг".
Очень странно и скомкано выглядит последний пункт про книги. Хотелось бы подробностей, почему вы считаете, что книги это лучший из возможных форматов получения знаний? Чем хуже курсы, статьи или видео?
В аналитике речь не об "угадываниях", а о вероятностях. У нас есть статистика, которая показывает определенную тенденцию, выводы из этого можно сделать разные. И гарантий, разумеется, эти цифры не дают.
В заголовке про Россию ничего и не сказано. Кроме того, в России и не было массовых сокращений, наоборот - нехватка специалистов и соответствующий рост зарплат.
Забавно, что trick перевели как "способ", в итоге получаем 5 способов делать несвязные вещи.
Курсы порой стоят слишком дорого и оценить их качество практически невозможно. Имхо намного лучший вариант - разбираться самому, в работе именно этот навык пригодится и никогда не устареет. А если хочется быстрее выучиться, то проще и дешевле найти себе ментора и общаться с ним только на нужные тебе темы.
Ого, это что же получается, в IT не только шарить надо, так ещё и работать придется, а не только зарплату получать? Ну уж нет, тогда это не подходит
Минус карандашиком за кликбейт в названии, а в остальном спасибо за хорошую статью, слишком много популизации адекватности на собесах не бывает
До использования Allure Test Ops мы пользовались Allure Report, то есть привычка развешивать аннотации для степов и классов в компании уже была. Тем не менее, даже если бы пришлось внедрять систему сейчас, мы могли бы передавать в степ преобразованное имя java-метода, используя те же листенеры, эту же логику мы сейчас используем, чтобы не приходилось вручную писать имя теста. А что касается самих листенеров, мы используем кое-какие из JUnit5 (там вместо листенеров экстеншены) или AspectJ (который идет вместе с Allure, и хоть это и не совсем листенер, но суть в контексте та же) для того, чтобы, например, автоматически прокидывать методы с @BeforeEach как самостоятельные степы.