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

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-разработке, поэтому видел довольно много проектов, которые в какой-то момент своего развития получили ворох проблем из-за того, что неграмотно управляли своими зависимостями.

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

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

В прошлой статье я писал об EasyUI — библиотеке, реализующей графический интерфейс для одно-страничных Web-приложений. Эту библиотеку наша команда использовала при разработке Web-интерфейса для одного маленького, но очень умного устройства. С момента начала реализации проекта прошло довольно много времени, появилось много новых технологий и решений. Об одном из них я и хочу поговорить в этой статье.

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

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

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

В статье я хотел бы поделиться своим опытом написания инсталлятора для Windows с использованием инструмента Windows Installer XML Toolset (далее - Wix). К сожалению, несмотря на всю мощь данного инструмента, его использование сильно осложняется куцей документацией, старенькими кукбуками, вялыми ветками форумов и вытеснением .msi и .exe пакетов контейнеризацией. Однако, сегодня продолжают активно развиваться и создаваться программные продукты требующие развертывания на виндовой машине с использованием традиционных установочных пакетов.

На сегодняшний день BPMN является одним из самых распространенных методов описания бизнес-процессов, которые сегодня уже «понятны» как бизнес-пользователям, так и программным продуктам, предназначенным для работы с бизнес-моделями. Т.е. этот язык описания также является стандартом для создания исполняемых алгоритмов в управлении бизнесом.

О том, что такое BPMN, написано много. Но практически вся информация, которую можно найти в Интернете, ориентирована на специалистов, которые ранее сталкивались с BPMN или другим стандартом моделирования бизнес-процессов. Предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она все чаще используется для описания бизнес-процессов организации.

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

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

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

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

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

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

Введение:

Плюсы микро-фронтенд архитектуры

• Автоматизация CI /CD. Поскольку каждое приложение интегрируется и развертывается независимо, это упрощает CI/CD. Так как все модули разделены, то не нужно беспокоиться обо всем приложении при внедрении нового модуля. Если в коде модуля есть ошибка, CI/CD прервет весь процесс сборки.
  Гибкость команд разработчиков. Многочисленные команды могут разрабатывать и развивать информационные системы, работая по отдельности.
• Единая ответственность. Каждая команда микро-фронтеда на 100% фокусируется на функциональности своего микро-фронтенд приложения.
• Возможность повторного использования. Микро-фронтенд приложение может быть повторно использовано несколькими командами в разных системах.
• Технологический агностицизм. Архитектура микро-фронтенд не зависит от технологии. Возможно использовать компоненты, разработанные на разных фреймворков веб-разработки (React, Vue, Angular и т.д.).
• Простой порог входа в систему. Небольшие модули легче изучать и понимать новым разработчикам, входящим в команды, чем монолитную архитектуру с огромной структурой кода.

В комментарии к моей предыдущей статье, «Какие задачи не решаются bat-файлами?», предположили, что на bat-файлах не получится написать Doom. Насчет Дума я пока не уверен, а вот тетрис у меня получился.

Бат-файлы ведут свою историю со времен MS-DOS. Новые фичи добавлялись с сохранением обратной совместимости. Из-за этого многое в языке bat-файлов, как мы увидим далее, нелогично и неудобно.

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

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