Должно - да. Но в реальности зрелость сильно плавает: где-то есть только чек-листы и ручные прогоны, где-то частичная автоматизация и стенды «по вызову», а полностью выстроенный контур с автотестами/метриками встречается реже, особенно в "железных" проектах: это долго и очень дорого. Собственно, статья и описывает целевое состояние и поэтапный roadmap к нему, а не «как у всех сегодня».
Про внутреннюю кухню Beget не скажу, я не являюсь их техническим сотрудником :)
Сборка "из кубиков" - это в идеальном варианте, когда необходим максимально быстрый time-to-market без серьезных изменений в продукте. Но при этом необходимо видеть и зону ближайшего развития в своем продукте, куда и за счёт чего пойдет развитие и насколько придется пересматривать свою текущую инфраструктуру, набор технических решений и т.д.
О да, и за примерами даже далеко ходить не нужно. Ярчайший пример - Wi-Fi aka 802.11. Там очень много проблем вызвано избыточностью ради обеспечения совместимости со старыми устройствами.
Круг проблем может постепенно сужаться по мере развития инфраструктуры, стандартизации подходов. Не думаю, что продукты с четким сроком выхода типа продукции Apple испытывают с этим серьезные сложности.
Насчёт определять куда - это очень амбициозно для среднего и малого бизнеса, и скорее удел китов индустрии, крупных вендоров с реальным влиянием и чьи интересы учитываются. Тем более в России, где мы во много должны обходиться тем что есть и что доступно.
Вам бы ко мне на работу устроиться злым редактором :) но тут чувствуется несовпадение каких-то ваших ожиданий которые вы почему-то мне тут предъявляете. Можно было бы и дополнить статью ответами на ваши вопросы, потому что под "подливой" вашего открыто демонстрируемого хейта и мнимого чувства превосходства со знанием "УЖ Я ТО ЗНАЮ КАК НАДА!" - но не буду ибо уже наступил в г-но отвечая на ваш "комментарий".
Не уподобляясь стилю повествования автора предыдущего комментария я постараюсь проясить почему написано именно так. Многие вещи в этой статье объясняются с такой позиции, что человек уже знает что-то про программирование на Python и я не ставил себе задачи писать исчерпывающий мануал для абсолютных новичков объясняя что такое...и по списку.
Что вам делать - учить uv, или еще чего - решайте сами. Знающий и умеющий по умолчанию понимает значение этих утилит в контексте использования Python и Pytest.
И на этом, пожалуй, в ввиду неконструктивности вашей болтовни дальнейший диалог именно с вами не испытываю желания продолжать. Всего вам хорошего :)
Насчет "сначала протестировать варианты использования", а компоненты подбирать потом? Подход разумный, но в чистом виде опасен: физические ограничения и сроки поставок быстро "догоняют". Рабочий компромисс - это двухпоточная стратегия:
Фиксируем ключевые пользовательские сценарии, критерии приёмки и "пользовательский портрет". Далее пишем автотесты, эмуляторы периферии и "золотые" наборы данных. Это позволяет нарастить кодовую базу и проверять гипотезы независимо от конкретного чипа.
Для всего, что несёт жёсткие риски (радиочасть, питание/тепло, дефицитные микросхемы), выбираем 1–2 реальных кандидата уже на EVT, держим тонкий HAL и тесты интерфейсов. Иначе велика вероятность, что "готовая" кодовая база упрётся в нестыкуемость железа или lead-time.
То есть начинать с тестирования сценариев конечно правильно, но компоненты с высокими рисками (наличия и поставки) всё равно нужно "приземлять" уже на этапе EVT и сразу оборачивать их стабильным интерфейсом, с рассчётом под вариант замены. Тогда и долговечность, и скорость развития не будут противоречить друг другу.
- MVP - минимально жизнеспособный продукт: самый маленький набор функций для проверки гипотезы ценности. - EVT - Engineering Validation Test: проверка инженерного прототипа, что архитектура и ключевые характеристики достижимы. - DVT - Design Validation Test: доводка дизайна под серийное производство, подтверждение требований/стандартов. - PVT - Production Validation Test: валидация массового выпуска на линии (качество/повторяемость).
Про долговечность и нефункциональные требования. Если задача - заключается в том чтобы работало годами, то это должно быть не просто нефункциональное требование, а по сути бизнес-правило с формальной политикой совместимости, которое должно быть заложено в продуктовой и бизнес-логике.
Но в данном случае стоит так же держать в голове, что продукты и компонентная база развивается, появляются новые и более точные способы измерений и порой держать старое доброе становится просто нецелесообразно.
Про «чистый софт». Да, ту же стратегию можно применять без "примеси" железа, сама стратегия по сути и содержанию в ключевых аспектах не отличается от принципов управления качеством программного продукта. Флоу тут вполне себе стандартный, как и с софтом: включать QA с этапа обсуждения требований и архитектуры, после тестировать по рискам (критичные пользовательские сценарии первыми); далее строить пирамиду тестов (unit / интеграционные / e2e); а после завести CI/CD с автотестами и метриками качества релиза.
Всё как везде :) только у каждого вида продукта своя специфика...
По моему достаточно планировать задачи на неделю и спрашивать о выполнении и не выполнении. Понимать диапазон возможного движения КПД и факторов от этого зависящих. И обсуждать результаты, а не ходить и писать каждый час о том, что делал.
В моем случае я давал HR-ам мною составленную анкету с списком 20 вопросов касаемо будущей должности, был ли опыт там, сям, что умеет, не умеет. Чему готов учиться и так далее. И уже после этого по результатам просмотра анкеты этой и резюме в совокупности было понятно - подходит кандидат или нет, какой процент белых пятен есть и можно ли его потом дообучить если пробелы не критичные.
А симметричность канала соблюдена? Условно, что точка-то "доорётся" до клиента, а вот "слабоорущий" клиент доорётся до точки? Обычно для таких кейсов делают бэкхол точка-точка для точек доступа, а они уже в соответствии с максимально допустимым EIRP дают в своей зоне, где канал связи до абонента остаётся симметричным и не возрастает количество перепосылок трафика.
Ну и если говорить об антеннах - лучше покрывать территорию секторными антеннами, а не омнями.
Должно - да. Но в реальности зрелость сильно плавает: где-то есть только чек-листы и ручные прогоны, где-то частичная автоматизация и стенды «по вызову», а полностью выстроенный контур с автотестами/метриками встречается реже, особенно в "железных" проектах: это долго и очень дорого. Собственно, статья и описывает целевое состояние и поэтапный roadmap к нему, а не «как у всех сегодня».
Про внутреннюю кухню Beget не скажу, я не являюсь их техническим сотрудником :)
Сборка "из кубиков" - это в идеальном варианте, когда необходим максимально быстрый time-to-market без серьезных изменений в продукте. Но при этом необходимо видеть и зону ближайшего развития в своем продукте, куда и за счёт чего пойдет развитие и насколько придется пересматривать свою текущую инфраструктуру, набор технических решений и т.д.
О да, и за примерами даже далеко ходить не нужно. Ярчайший пример - Wi-Fi aka 802.11. Там очень много проблем вызвано избыточностью ради обеспечения совместимости со старыми устройствами.
Круг проблем может постепенно сужаться по мере развития инфраструктуры, стандартизации подходов. Не думаю, что продукты с четким сроком выхода типа продукции Apple испытывают с этим серьезные сложности.
Насчёт определять куда - это очень амбициозно для среднего и малого бизнеса, и скорее удел китов индустрии, крупных вендоров с реальным влиянием и чьи интересы учитываются. Тем более в России, где мы во много должны обходиться тем что есть и что доступно.
Вам бы ко мне на работу устроиться злым редактором :) но тут чувствуется несовпадение каких-то ваших ожиданий которые вы почему-то мне тут предъявляете. Можно было бы и дополнить статью ответами на ваши вопросы, потому что под "подливой" вашего открыто демонстрируемого хейта и мнимого чувства превосходства со знанием "УЖ Я ТО ЗНАЮ КАК НАДА!" - но не буду ибо уже наступил в г-но отвечая на ваш "комментарий".
Не уподобляясь стилю повествования автора предыдущего комментария я постараюсь проясить почему написано именно так. Многие вещи в этой статье объясняются с такой позиции, что человек уже знает что-то про программирование на Python и я не ставил себе задачи писать исчерпывающий мануал для абсолютных новичков объясняя что такое...и по списку.
Что вам делать - учить uv, или еще чего - решайте сами. Знающий и умеющий по умолчанию понимает значение этих утилит в контексте использования Python и Pytest.
И на этом, пожалуй, в ввиду неконструктивности вашей болтовни дальнейший диалог именно с вами не испытываю желания продолжать. Всего вам хорошего :)
Этим инструментом не пользовался, я присмотрюсь :) спасибо
Ух, круто когда кому-то материалы помогают :) спасибо вам!
Да, точно, спасибо! Сейчас поправлю в статье
Я обычно юзаю последнюю стабильную версию :) не встречал такой, в которой этой функциональности нет
Да, я во многом для себя писал эту шпаргалку, а потом решил поделиться с остальными :) спасибо
Насчет "сначала протестировать варианты использования", а компоненты подбирать потом?
Подход разумный, но в чистом виде опасен: физические ограничения и сроки поставок быстро "догоняют". Рабочий компромисс - это двухпоточная стратегия:
Фиксируем ключевые пользовательские сценарии, критерии приёмки и "пользовательский портрет". Далее пишем автотесты, эмуляторы периферии и "золотые" наборы данных. Это позволяет нарастить кодовую базу и проверять гипотезы независимо от конкретного чипа.
Для всего, что несёт жёсткие риски (радиочасть, питание/тепло, дефицитные микросхемы), выбираем 1–2 реальных кандидата уже на EVT, держим тонкий HAL и тесты интерфейсов. Иначе велика вероятность, что "готовая" кодовая база упрётся в нестыкуемость железа или lead-time.
То есть начинать с тестирования сценариев конечно правильно, но компоненты с высокими рисками (наличия и поставки) всё равно нужно "приземлять" уже на этапе EVT и сразу оборачивать их стабильным интерфейсом, с рассчётом под вариант замены. Тогда и долговечность, и скорость развития не будут противоречить друг другу.
- MVP - минимально жизнеспособный продукт: самый маленький набор функций для проверки гипотезы ценности.
- EVT - Engineering Validation Test: проверка инженерного прототипа, что архитектура и ключевые характеристики достижимы.
- DVT - Design Validation Test: доводка дизайна под серийное производство, подтверждение требований/стандартов.
- PVT - Production Validation Test: валидация массового выпуска на линии (качество/повторяемость).
Про долговечность и нефункциональные требования. Если задача - заключается в том чтобы работало годами, то это должно быть не просто нефункциональное требование, а по сути бизнес-правило с формальной политикой совместимости, которое должно быть заложено в продуктовой и бизнес-логике.
Но в данном случае стоит так же держать в голове, что продукты и компонентная база развивается, появляются новые и более точные способы измерений и порой держать старое доброе становится просто нецелесообразно.
Про «чистый софт». Да, ту же стратегию можно применять без "примеси" железа, сама стратегия по сути и содержанию в ключевых аспектах не отличается от принципов управления качеством программного продукта. Флоу тут вполне себе стандартный, как и с софтом: включать QA с этапа обсуждения требований и архитектуры, после тестировать по рискам (критичные пользовательские сценарии первыми); далее строить пирамиду тестов (unit / интеграционные / e2e); а после завести CI/CD с автотестами и метриками качества релиза.
Всё как везде :) только у каждого вида продукта своя специфика...
Где купить? :) Сколько стоит? Гербера, схематики, трассировки не open source?
По моему достаточно планировать задачи на неделю и спрашивать о выполнении и не выполнении. Понимать диапазон возможного движения КПД и факторов от этого зависящих. И обсуждать результаты, а не ходить и писать каждый час о том, что делал.
Я в Москве, к сожалению (
В моем случае я давал HR-ам мною составленную анкету с списком 20 вопросов касаемо будущей должности, был ли опыт там, сям, что умеет, не умеет. Чему готов учиться и так далее. И уже после этого по результатам просмотра анкеты этой и резюме в совокупности было понятно - подходит кандидат или нет, какой процент белых пятен есть и можно ли его потом дообучить если пробелы не критичные.
А симметричность канала соблюдена? Условно, что точка-то "доорётся" до клиента, а вот "слабоорущий" клиент доорётся до точки? Обычно для таких кейсов делают бэкхол точка-точка для точек доступа, а они уже в соответствии с максимально допустимым EIRP дают в своей зоне, где канал связи до абонента остаётся симметричным и не возрастает количество перепосылок трафика.
Ну и если говорить об антеннах - лучше покрывать территорию секторными антеннами, а не омнями.
И это круто, что такие сложные штуки стали гораздо доступнее для широкого круга энтузиастов
Хм. А почему бы мне не оформить перевод этой статьи...выглядит как крутое и исчерпывающее исследование