В первой части мы подготовили среду для легковесной разработки под STM32. Пора приступить к экспериментам.

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

«О чем это я?» или вместо предисловия.

Эта статья, каких уже наверняка много на этом ресурсе, о личном опыте работы тим-лидом, написанная непосредственным участником событий и обладателем этой несчастливой роли. В ней поговорим о рабочих моментах/вопросах и способах их решения.

В тексте, как бы сам не любил этого, используются профессиональные жаргонизмы, которые являются прямой фонетической калькой с англоязычных слов. Сделано это умышленно и намеренно, чтобы сократить количество «букаф» и обеспечить передачу смысла максимально коротким путем (как водка – сразу в мозг!).

Чего в статье нет: «золотых правил идеального тим-лида», детально-пошаговых инструкций по разрешению конфликтов и прочей нравоучительной нудятины.

Как всем известно, в настоящее время одним из популярных микроконтроллеров у любителей электроники, являются микроконтроллеры семейства STM32. Оно и не удивительно: богатая переферия, обилие различных статей о программировании среде STMCube завлекают все больше и больше хоббийных разработчиков.

Когда автор начал знакомиться с микроконтроллерами STM32 после долгой работы с семейством Atmega/Attiny, он так же как и все начинающие, использовал IDE (это был неторопливый Eclipse) и пользовался CMSIS + SPL/HAL. И эта связка была работоспособна. Но душа моя, почему-то испытывала дискомфорт от рабочего
окружения. Eclipse на ноутбке не радовал отзывчивостью, изучение исходников
стандартных библиотек не всегда гладко ложилось в моей голове с содержимым даташита на микроконтроллер. Но все это было терпимо.

Но вот я замахнулся на самый сложный и полезный интерфейс - USB. С первого взгляда все было просто - куча примеров кода для HAL, как сделать USB микрофон или CDC устройство. Но стоило лишь поставить цель реализовать композитный девайс сочетающий в себе аудиоустройство и CDC) как ты вступал в темный лес.

Структура STMовской USB библиотеки была нелогична, и опять же, очень плохо
совмещалась с официальной спецификацией USB. Я штурмовал этот «USB пик»
несколько лет, периодически забрасывая, пока не наткнулся на упоминание о
том, что прошивка микроконтроллера что отвечает за работу с USB в SDR трансивере
HackRF написана с помощью некой библиотеки libopencm3. Изучение документации, приятно порадовало мой глаз. Изучение исходников - радовало максимальной близостью к регистрам. И я решился сменить HAL/SPL на libopencm3. Единственная проблема в том, что в сети ГОРАЗДО меньше статей и руководств для начинающих, как подготовить среду разработкию. 90% информации ты находишь сам, копаясь в образцах чужого когда на GitHub, и вчитываясь в официальную документацию не забывая заглядывать в даташит. Данный путь закалаяет характер, но совсем не то, что хочется для быстрого старта и быстрого результата.

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

В статье будем отталкиваться от функционального тестирования методом черного ящика.

Для конкретики рассмотрим пару требований с моего текущего проекта, в котором я занимаюсь мануальным тестированием медицинских устройств.

Итак, начнем!

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

В этой статье я сконцентрирую внимание на открытом стандарте IEEE 11073 Service-oriented Device Connectivity (SDC) (https://www.iso.org/standard/76538.html) и рассмотрю, зачем нужно ручное тестирование медицинских устройств, в том числе на нескольких примерах.

Использование библиотеки MediatR при реализации бизнес‑логики в проектах, реализуемых на базе.NET

На просторах интернета появились библиотеки, позволяющие упростить и ускорить построение бизнес‑логики разрабатываемого приложения. Одна из таких библиотек — MediatR. В данной статье я хочу описать небольшой пример из реального проекта. Проект, web приложение, предназначен для автоматизации некоторого бизнес‑процесса. В рамках данного проекта была реализована задача по согласованию, где использовался инструментарий библиотеки MediatR. Я не буду уделять особого внимания моментам, связанным с установкой и настройкой данной библиотеки в проекте, выделю только то, что необходимо для решения нашей задачи.

Доброго времени суток. Использование универсальных протоколов взаимодействия устройств уже давно является неотъемлемой частью разработки любого технического продукта в нашем мире. К сожалению, сфера здравоохранения находится сейчас в роли догоняющей, и эксперты только начинают рассматривать возможности использования общих методов коммуникации в своих продуктах. Так на возникающий спрос начинают появляться открытые стандарты взаимодействия, удовлетворяющие требованиям медицинской отрасли.

В этой статье Аурига поделится опытом разработки решений, направленных на использование подходов автоматизированного тестирования медицинских устройств в соответствии с открытым стандартом IEEE 11073 Service-oriented Device Connectivity (SDC), разработанным некоммерческой организацией OR.NET.

Одному моему знакомому из фирмы, выпускающей разнообразный мерч пришла как‑то в голову идея дополнить свою продукцию интерактивной графикой — навел телефон на майку/кружку/скетчбук и получил на экране дополнительную визуальную информацию для данного предмета в виде AR (Augmented Reality) графики поверх видео потока с камеры телефона.

И вот, у нас было несколько телефонов, питон, flask, keras, supervisord, gunicorn, AR.js и выходные на то чтобы сделать прототип…

Делай красиво, а некрасиво не делай.

Python — это язык программирования, уделяющий много внимания тому, как мы пишем код. Самый первый пункт Zen of Python, принципов разработки на Python от его BDFL: «Beautiful is better than ugly». Красивое лучше уродливого. Это само по себе простое и понятное утверждение, вынесенное на первое место в дзэне, напоминает нам простую истину — мы пишем код для людей, а не для машин. Машине для исполнения программы хватит нулей и единиц в бинарном файле, человек же куда более требователен.

Именно поэтому в разработке кода мы стараемся использовать все доступные средства, для того чтобы сделать его удобным для чтения и понятным человеку. В Python множество инструментов, которые могут помочь улучшить читаемость кода, и Context manager, о котором дальше пойдет речь, один из них.

Несколько лет назад Аурига по заданию известного медицинского стартапа разрабатывала решение, связанное с параллельной обработкой нескольких потоков видеоданных. Ключевой особенностью технического решения была скоростная передача и обработка большого потока видеоданных от драйвера, написанного на С++, в обработчик, написанный на Python.

В процессе разработки мы успели отрефакторить код, написанный математиками, перепробовать распространённые протоколы IPC и написать свой собственный, и дать полную нагрузку на 40-ядерный Xeon.

А ещё мы дебажили Windows.

В статье рассмотрена тема обработки ошибок в Spring Kafka, а так же основные параметры и настройки, которые необходимо учесть при настройке конфигурации.

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

Вот представьте себе – работаешь ты себе спокойненько обычным ручным тестировщиком стандартных аппликух, web-порталов, десктопов уже который год. И тут тебе звонят и говорят: «А не хотите ли…? Добро пожаловать в отдел автотестирования медицинских девайсов». Вот так чихуа-хуа, подумала я. Учитывая, что опыта в автотестированиии у меня не было от слова совсем, работы на медицинских проектах – 0. Понять, кто такой этот питон и чего там не так с его скриптом было невозможно. Технического образования тоже не имеется. Но тут внутри включилась та самая упертая….баран, который твердо заявил, что я буду не я, если не разберусь в этом всем.

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

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

React vs Vue vs Angular. Общее сравнение JavaScript фреймворков

В ходе развития веб-разработки 3 JavaScript-фреймворка стали хорошо известны всем front-end разработчикам: React, Vue и Angular.

React считается библиотекой пользовательского интерфейса, Angular - полномасштабным front-end фреймворком, предоставляющим собственные инструменты для всех связанных с разработкой веб-приложений функций, а Vue - прогрессивным фреймворком, реализованным как дополнительная разметка для HTML.

Все три фреймворка могут использоваться практически взаимозаменяемо для создания компонентных frontend-приложений с расширенными возможностями пользовательского интерфейса. Однако окончательный выбор зависит от требований проекта и предпочтений разработчика.

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

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

Squish - это платный инструмент для автоматического тестирования пользовательского интерфейса. Есть Squish для QT, Squish для Windows, для веба, для Java и iOS.

Во всех случаях тестовые сценарии - это скрипты на питоне или других скриптовых языках.

Рассмотрим следующие моменты при работе со Squish для QT на питоне:

• Настройка и запуск без Squish IDE.

• Real name, symbolic name и явные имена.

• Прокси-объекты и их сравнение.

• Suid на тестируемом приложении.

• Тестирование рендеринга с помощью скриншотов.

• Неудобство API Squish и работа без него: симуляция ввода, элементы списков и таблиц.

• Добавление методов в метаобъект для вызова через Squish.

Любите ли вы отзывчивые программы так, как люблю их я? Любовь эта привела меня к Колибри ОС - невероятно шустрой операционной системе, которая запускает программу до того, как вы осознаете, что кликнули по ней. И недавно у неё нашли уязвимость: ping of death.

Так получилось, что моя первая работа была связана с симуляцией компьютерных систем – от серверов до мобильных устройств. И там мы использовали симулятор Simics. Этой системой пользуются крупные производители железа для опережающей разработки драйверов.

Если бы только можно было использовать Simics для отладки любительской ОС...

Создание любого ПО сопровождается ошибками. Программисты ошибаются в выборе типов, ошибаются в реализации алгоритмов. Аналитики ошибаются в формулировке требований к ПО, и из этих ошибок рождаются ошибки в функционировании готового продукта. Любой (ну ладно, почти любой) производитель программных продуктов хочет обезопасить себя от ошибок в выпускаемом ПО. Для того чтобы избежать типовых ошибок придумали различные стандарты (типа MISRA C) и утилиты для анализа написанного кода (например, Lint). Но корректно написанный код - это половина проблемы, вторая половина - это насколько верно и полно код реализует требования к программе, и нет ли в программе того чего там быть не должно. Ответ на эти вопросы в свою очередь дает тестирование и проверка покрытия кода (например, gcov).

Иногда, в случае если программное обеспечение является частью системы, имеющей повышенные требования к безопасности, (например, в авионике), требуется доказать что весь код на уровне исполняемого образа программы корректен и не содержит «лишнего». Вот тут-то и приходится задействовать весь выше озвученный арсенал средств и засесть за анализ того что получилось из исходного кода.

Я уже больше 10 лет работаю в Web-разработке, поэтому видел довольно много проектов, которые в какой-то момент своего развития получили ворох проблем из-за того, что неграмотно управляли своими зависимостями.

Были проекты, которые страдали от того, что сторонние компоненты, которые они использовали, прекращали поддерживаться своими авторами. Были проекты, где лицензия не позволяла использовать библиотеку в коммерческих целях. Были проекты, где зависимости хранились вместе с исходным кодом, и в них были изменения, которые потом не позволяли их обновить.

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