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

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

Plug and pray play

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

Несмотря на то, что люди были специальными, по нынешним меркам все было организовано довольно просто. Любой самостоятельный компонент компьютера (процессор, память, шина, порты ввода/вывода и т. д.) поставлялся с кипой бумажной документации, в которой описывалось, какие интерфейсы используются, какие адреса, прерывания необходимы для работы того или иного устройства. Если возникали конфликты адресов/прерываний, то, как правило, в устройстве были переключатели, позволявшие в определенных пределах менять настройки. А когда это не помогало, то специальные люди не чурались паяльника и разрешали конфликт, так сказать, «по месту».

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

Мы тестируем медицинское оборудование, поэтому знаем, какие требования закон предъявляет к процессу тестирования. Каждый протокол теста — это документ, который контролирующий орган может проверить.

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

На протяжении истории люди придумывали различные подходы и приёмы, как разрабатывать более качественные и поддерживаемые приложения. В этой статье я бы хотел рассказать о такой методологии разработки, как BDD (Behaviour Driven Development). Но прежде чем перейти непосредственно к гвоздю программы — небольшое вступление.

Думаю, большинство разработчиков согласятся с мыслью о том, что покрытый юнит-тестами код лучше, чем непокрытый. Действительно, тесты позволяют эффективно следить за работоспособностью кода, вовремя отлавливать нерабочие изменения. А ещё из наличия юнитов обычно следует то, что код разбит на логические модули и каждый класс/функция имеет одну зону ответственности (привет SOLID). Тот, кому доводилось писать тест на большую функцию с несколькими зонами ответственности знает, что тесты на такую функцию обречены быть хрупкими и падать при малейшем изменении. Это заставляет задуматься о том, чтобы не писать всё "в одной портянке", а писать гибкий код поделённый на модули. С таким кодом, как правило, приятнее работать, т.к. приходится держать в уме меньше информации.

В какой-то момент люди сделали вывод, что раз код хороший если он тестируемый, тогда давайте мы сначала напишем тесты на этот код, а уже потом сам код. И так придумали методологию...

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

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

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

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

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

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

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

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

Современная веб-разработка требует эффективных инструментов, способных справляться с высокими стандартами производительности и пользовательского опыта. В этой статье мы рассмотрим Next.js, мощный JavaScript-фреймворк и новаторское решение для создания современных веб-приложений на основе React, созданный компанией Vercel. Узнаем, как он помогает разработчикам создавать высокопроизводительные, масштабируемые и SEO-дружественные веб-приложения. Мы также глубоко погрузимся в его функциональность, рассмотрим особенности, такие как серверный рендеринг и генерация статических сайтов, и предоставим примеры использования. Давайте разберем, как Next.js становится ключевым инструментом в современной веб-разработке, обеспечивая идеальный баланс между разнообразием функций и оптимальной производительностью.

На Хабре очень много статей от инженеров самого разного уровня: от джунов до сеньоров. Но обязательно ли изначально быть техническим специалистом, чтобы попасть в мир IT? Так ли легко бросить наработанный опыт и кардинально сменить профессию? Поделюсь личным опытом. В этой статье я хочу рассказать свою историю успешного перехода из преподавательской деятельности в IT. Ключевую роль в ней сыграла компания «Аурига».

Я по образованию преподаватель иностранных языков. До Ауриги работала по специальности в языковой школе и подрабатывала репетитором. Если не брать в расчёт лето, доход на тот момент был выше среднего по городу. Карьерные перспективы в школе – рост до старшего преподавателя, а через несколько лет (возможность, но не гарантия) до руководителя филиала. Можно было расти и в сторону выбранной специализации. Школа организовывала как внутреннее обучение, так и компенсировала полностью или частично затраты на прохождение курсов и сдачу международных экзаменов.

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

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

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

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

Рецензирование тестовой документации — это процесс оценки и проверки таких артефактов тестирования, как планы тестирования, тест кейсы и другие связанные документы. 

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

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

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

• Для сотрудника: возможность перенять опыт, обратная связь, реальные кейсы;

• Для ментора: опыт наставничества / обучения, возможность восполнить свои пробелы в знаниях, борьба с синдромом «самозванца» (все-таки если ты учишь – значит твои знания и опыт кому-то нужны);

• Для компании: передача опыта и знаний внутри компании, обученные сотрудники;

и многое другое.   

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

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

В процессе тестирования пользовательского интерфейса мы распознаем его на скриншотах тестируемого устройства.

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

Почему тестировщик не пригласил Pytest на свой день рождения? Потому что он боялся, что тесты падут и вечеринка закончится с ошибкой 404 – "Файл не найден"!

Pytest – это один из наиболее популярных фреймворков для написания тестов на Python. Он известен своей простотой в использовании, обширным сообществом и широким спектром функциональности. Однако, даже если вы являетесь опытным пользователем Pytest, вероятно, вы не используете все его функции. 

В этой статье мы рассмотрим топ малоизвестных, но полезных функций Pytest.

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

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

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

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

Управление глобальным состоянием

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

Балансировщик нагрузки (Elastic Load Balancer, далее ELB) – часто используемый элемент при проектировании архитектуры в AWS. Цель – эффективное распределение запросов между имеющимися инстансами, а так создание/удаление новых в рамках Auto Scaling group.

В этой статье я бы хотел рассмотреть самый новый вид балансировщика из представленных в AWS – Gateway Load Balancer (далее GWLB).

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