При разработке и последующем производстве электроники неизбежно встаёт вопрос проверки собранных изделий. Если компания небольшая, а производство мелкосерийное, то в жертву рутине можно принести какого-нибудь начинающего специалиста, либо самого разработчика. Как правило, требуется проверить несколько напряжении, пару цифровых интерфейсов, световую, звуковую индикацию и т. п. Но предварительно в контроллер необходимо записать программу. В мелкой серии длительность тестирования особой роли не играет. Трудности начинаются, когда каждый месяц производится десяток тысяч изделий.

Вопрос в том, что прошивка устройства внешним программатором – это отдельная технологическая операция, требующая времени и оплаты. Столкнувшись с такой постановкой задачи, пришлось некоторое время повозиться, чтобы реализовать автономный SWD программатор в составе технологической оснастки. Все операции по проверке собранных печатных плат, включая программирование, объединяются в тестовую последовательность, а полное время проверок сводится к возможному минимуму. Надеюсь, что представленная информация облегчит дело тем самураям, которые решат пройти по схожему пути.

Разработчик Вася не смог включиться в работу утром. Потом еще был эмоциональный митинг с заказчиком, после которого снова активировалась прокрастинация. В итоге вместо восьми запланированных часов работы — три. Вася понимает, что дома придется доделывать рабочие задачи, и потому он снова забьет на свое (постоянно откладываемое) обучение.

Тут появляются авторы статьи, которую вы читаете, и предлагают попробовать пару интересных штук для эффективного включения. Мы пробуем замедлиться в два раза и еще пощелкать с десяток примеров устного счета. После митинга – вынести всю рефлексию на бумагу и «шлифануть» это активной прогулкой. Простые решения, которые в совокупности позволяют не терять время на «тупняк в монитор». 

Как мы подобрали эти решения и почему именно они? В целом, подобных приемов есть около четырех десятков, а конкретных техник – и того больше. Чтобы выйти на конкретные действия, которые нужны именно вам, мы создали простой инструмент, описанный далее в статье.

Всем привет!

Сложность сертификации

§3-8. Эксплуатация Эмоций

Я пытался работать над технической теорией, но постоянно засыпал. Затем я представил, что мой соперник, профессор Челенджер, собирается разработать точно такую же технику. Это вызвало всплеск злобного разочарования, которое блокировало на пару мгновений желание спать, позволяя мне дальше работать.

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Глава 15. Цифровые фильтры — 2

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Глава 14. Цифровые фильтры — 1

Введение

Терминология

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

«Цель этого курса — подготовить вас к вашему техническому будущему.»

Глава 6. Искусственный интеллект — 1

§3-3 Чувства, Боль и Страдание

«Когда он начал думать об этом, острый укол боли пронзил его как нож, и заставил дрожать каждую фибру его природы. Его глаза стали такими же глубокими как аметист, и сквозь них проявился легкий туман слёз. Ему казалось, что его сердца коснулась чья-то ледяная рука»
— Оскар Уайльд в книге «Портрет Дориана Грея».

За последнее десятилетие мы разработали и усовершенствовали несколько методов, которые позволяют дизайну баз данных эволюционировать параллельно с разработкой приложения.

Это очень ценное свойство гибких методологий. Методы опираются на применение непрерывной интеграции и автоматизированного рефакторинга к разработке баз данных, а также на тесное взаимодействие между разработчиками приложений и администраторами БД. Эти методы работают как в препродакшн и в уже стартовавших системах, в свежих проектах без легаси, так и в унаследованных системах.

В последнее десятилетие мы наблюдаем рост гибких методологий. По сравнению со своими предшественниками, они изменяют требования к дизайну баз данных. Одно из важнейших среди требований – идея эволюционной архитектуры. В гибком проекте вы предполагаете, что не можете заранее поправить требования системы. В результате, иметь детализированную, четкую стадию дизайна в начале проекта становится непрактично. Архитектура системы должна эволюционировать одновременно с итерациями софта. Гибкие методы, в частности, экстремальное программирование (XP), имеют набор методик, которые делают эту эволюционную архитектуру практичной.