Добро пожаловать на очередной шабаш любителей испортить себе жизнь странным хобби! Репортаж с предыдущей вечеринки вы можете найти по ссылке. На ней мы практически «с нуля» создали модель начального уровня встраиваемого контроллера на базе RISC-процессора. Сегодня мы с вами будем добавлять ром ROM и попробуем обзавестись сравнительно несложной защитой памяти. И правда, что за встраиваемая система без ПЗУ? Прежде чем мы это сделаем, неплохо бы набросать некоторые детали конечной архитектуры нашей системы. Почему сейчас? Потому что ROM нужно будет разместить по каким-то адресам, как-то нужно будет управлять логикой защиты памяти, оставить что-нибудь «на вырост» и при этом где-то должно быть ОЗУ. Впрочем, описание будет небольшим ;-)

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

Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов. Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework

Привет, Хабр! Меня зовут Андрей и я программист. Как и многие, в свободное время я занимаюсь разработкой своих Pet-проектов.

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

Но иногда бывало и такое:  

• мне казалось что я пишу «в стол»;

• кризис идей;

• нет сил и желания закончить хороший проект;

• «стыдно» показать свой проект, «да кому он нужен», «это не портфолио» и т.д.

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

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

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

Вот, наконец, я и добрался до последней статьи, завершающей цикл мануалов, посвященных конвертации различных офисных документов в xml-файлы. На этот раз я поделюсь опытом получения «чистого» xml-файла из таблиц, сохраненных в формате ODS. 

Отвечая на вопрос «А зачем оно мне надо?» скажу, что ODS, кроме того, что является бесплатным форматом для электронных таблиц, разработанным индустриальным сообществом OASIS, еще и принят в качестве ГОСТовского стандарта в РФ. А это значит, что часть документов, опубликованных на порталах различных государственных и окологосударственных структур, которые, как им кажется, умеют в инновации, опубликованы именно в этом формате. Учитывая, что мануалов по причесыванию этой экзотики не так уж много (лично я не нашел, когда решал эту задачу), думаю, что кому-нибудь мой опыт поможет сэкономить время и нервные клетки.

Когда я смотрела фильм «Идиократия», момент с тестом на сообразительность показался мне нереальным. Ни за что не хотелось, чтобы показанные в фильме события могли оказаться правдой, но спустя несколько лет это случилось. Я стала тестировщиком, и моя работа сейчас выглядит примерно так, как показано на главной картинке. Наверно, именно так программисты видят тестировщиков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почти каждый айтишник рано или поздно сталкивается с проблемой нехватки знания из смежных областей. Например, фронт-разработчику вдруг необходимо проверить бэк-сервер и посмотреть, каким образом реализовано API. Или php-разработчику необходимо переделать дизайн кнопок на главной странице. Бывает и так, что программиста C++ Unreal Engine (это я) вдруг просят проверить разверстку 3D модели. Короче нет-нет, да придется изучить что-то, не относящееся к нашим прямым обязанностям (T-shaped специалисты же сейчас в тренде, да?)

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

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

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

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

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

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

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

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

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

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

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

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

Введение:

Не прошло и полугода со дня публикации моей предыдущей статьи про формирование чистого XML из офисного документа. В этот раз расскажу про формат Open Document Format (ODF) и как можно получить «причесанный» XML из текстовых документов с расширением .odt. В следующей статье покажу, как обработать .ods, и завершу данный цикл статей.

Часть 1. Настройка окружения для работы с libopencm3

Часть 2. Работа с GPIO, SPI, отладка проекта при помощи GDB

Часть 3. Работа с USART, прерываниями, I2C и таймерами

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

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

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