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

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

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

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

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

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

В этой статье я сконцентрирую внимание на открытом стандарте 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 и выходные на то чтобы сделать прототип…