Привет, Хабр!

Сегодня разберёмся, почему попытка «избавиться от ? любой ценой» приводит к проблемам, и как жить с этим вообще жить.

Привет, Хабр! Меня зовут Катя, я лидирую Gramax, open source-платформу для управления технической документацией. Однажды мы с коллегами утонули в хаосе рабочих документов: без версий, без согласований, без истории принятых решений. Это подтолкнуло нас к созданию Gramax — инструмента, который интегрирует документацию в процесс разработки, делая его прозрачным и управляемым.

В этой статье расскажу, как Gramax помогает на каждом этапе разработки ПО. Как перейти к документированию в подходе Docs as Code и шагнуть дальше — к Everything as Code.

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

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

Приветствую читателя этой статьи. Я студент, учусь по направлению «Приборостроение», но большую часть времени занимаюсь программированием. Все таки это меня привлекает больше. Задумывался по поводу смены ОС на Arch Linux, но пока отложил эту затею в долгий ящик. Смотрел различные ролики на YouTube и заметил, что многие пользователи ставят себе Polybar, в котором можно легко настраивать информацию, выводимую на нечто похожее на Панель задач в Windows. Тогда я подумал «А почему бы не сделать такое в винде?!» и сразу начал гуглить что к чему. Попытался найти готовые аналоги, но ничего не впечатлило, поэтому решил написать свою программу на C++.

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

Приветствую!

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

Поэтому я решил здесь в данном блоге (Habr идеальное место для этого) собрать в кучу как свои мысли так и свой опыт. А также опыт других людей которые также использовали данный инструмент в своей работе или просто как хобби.

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

Привет! Меня зовут Александр, я SDET-специалист в SimbirSoft. В этой статье я расскажу, как можно покрыть разрабатываемую часть проекта автотестами на ранних этапах его разработки, если в команде отсутствуют аналитики и присутствуют задокументированные требования только по основному функционалу. Эта статья будет интересна как джунам, так и техническим специалистам middle и выше, а также руководителям команд (team leads) и техническим лидам (tech leads).

Я поделюсь тем, как в такой ситуации были настроены процессы в нашей команде. Мы работаем над проектом с утвержденной микросервисной архитектурой с внутренними и внешними сервисами. Команда работает по Scrum-методологии и состоит из тимлида, разработчиков сервисов, QA и SDET-специалистов. От заказчика поступила лишь основная информация о том, что должен делать продукт и на каких платформах его можно будет использовать. Именно эта информация и была задокументирована в виде требований.

У любого процесса есть своё бутылочное горлышко. Если разобрать его на одной стадии процесса, оно непременно появится на другой. Но одно бутылочное горлышко может соответствовать максимальной эффективности команды, а другое будет тормозить поставку вашей ценности заказчику. При этом заранее угадать на старте проекта, где будет ваше бутылочное горлышко — очень сложно.
Мы расскажем, как искали путь выхода из подобной ситуации. Почему при достаточном соотношении QA и DEV-инженеров в команде у нас сформировалось бутылочное горлышко на стадии тестирования. Как обсуждения пирамиды тестирования и распределения зон ответственности за качество продукта помогли избавиться от недоверия в команде и ускорить поставку ценности.

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

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

Привет Хабр! Меня зовут Олег, я являюсь действующим QA Engineer в компании Intelsy. Это моя вторая статья после этой (тут могла бы быть ваша реклама), уж очень понравилось делиться информацией и получать обратную связь от читателей! Статья для тех, кто хочет улучшить процессы поставки кода в прод или понять, где можно сэкономить время! Постараюсь немного раскрыть эту тему, поделиться своим мнением (которое ни в коем случае не претендует на звание "истина в последней инстанции"), и да, по традиции помним "у каждого своя кухня". Надеюсь прочтение будет интересным и полезным!

В современных IT-командах границы между ролями стираются: разработчики пишут тесты, DevOps внедряют мониторинг, а тестировщики всё чаще участвуют в процессах, выходящих за рамки классического QA. Один из самых спорных вопросов — должен ли QA инженер заниматься релиз-менеджментом?

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

 В этой статье мы разберём:

· Почему QA идеально подходит для управления релизами?
· Плюсы и минусы
· Как внедрить релиз-менеджмент в обязанности тестировщика
· Почему отдельная роль релиз-менеджера часто избыточна
· Какие инструменты и метрики использовать для успешного контроля выпусков

 1. Что такое релиз-менеджмент и почему QA должен в нём участвовать?

Релиз-менеджмент — это комплекс процессов, связанных с планированием, подготовкой и развертыванием новой версии продукта. Он включает:

Привет! Без лишнего: в статье расскажу про атаки на кэш-память в процессорах семейства ARMv8. Подробно изучил их для совершенствования безопасности KasperskyOS: познакомлю с теорией и практикой, механизмами работы и способами митигации. Также кратко расскажу, как мы тестировали каждый способ атаки на KasperskyOS, какие из них оказались неприменимы, какие могут представлять угрозу и как микроядро с подобными угрозами справляется. Если интересно гранулярно погрузиться в типологию атак на кэш — добро пожаловать!

...которая работает на первых Android-смартфонах в мире, компьютерах из 90-х и даже Mac'ах! Часть 2.

Иногда у меня лежит душа просто взять и написать какую-нибудь небольшую игрушку с нуля, без использования готовых движков. В процессе разработки я ставлю перед собой интересные задачки: игра должна весить как можно меньше, работать на как можно большем числе платформ и использовать нетипичный для меня архитектурный паттерн. Недавно я начал писать ремейк классических «танчиков» и в рамках серии статей готов рассказать о всех деталях разработки трёхмерной игры с нуля в 2025 году. Если вам интересно узнать, как работают небольшие 3D-демки «под капотом» от написания фреймворка до разработки геймплея и тестов на экзотических устройствах — жду вас под катом!

В одной небольшой инструкции и двух видео посмотрим, как собрать свой собственный компьютерный стол. Но не просто стол, а стол‑корпус для ПК.

Что это вообще такое? Идея проста: берем все комплектующие компьютера и встраиваем их прямо внутрь конструкции. Мониторов возьмем, скажем, три. Сабвуфер не забудем, конечно же. Вуаля! Системного блока теперь как бы и нет. Но что еще важнее — всё становится очень круто тюнинговать!

Осторожно! Под катом множество вдохновляющих иллюстраций.

Привет, Хабр!

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

У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт».

Привет, Хабр!

Если у вас в команде код-ревью — это унылое ожидание и пассивно-агрессивные комментарии уровня «не по канону», значит, что-то пошло не так. А если ревью не просто тормозит, но ещё и убивает мотивацию — то вы откладываете техдолг не только в коде, но и в культуре.

Статья Галины Шайдуровой

Психология тестировщика: почему критическое мышление – это суперсила

Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.

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

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

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

Кульминация цикла о функциональщине в Android! Сегодня изучаем чистые функции — ещё один важный принцип функционального программирования.

Учтём контекст и познакомимся с сопутствующими терминами, раскрывающими суть чистых функций. А ещё обсудим место концепции Dependencies Injection в функциональном программировании. В общем, вперёд за новыми знаниями!

Чистая архитектура — не просто модный термин, а способ держать код в узде по мере роста Android-приложения. В этой статье — подробный разбор того, как выстроить работу с UseCase’ами: от базовой интеграции в ViewModel до сложных кейсов с несколькими провайдерами и платежными системами. Разберёмся, как применять принципы SOLID на практике, не скатываясь в оверинжиниринг — и при этом не жертвовать гибкостью архитектуры.

Многие пользуются YouTube, Netflix, но не подозревают о ключевых опенсорсных программах типа ffmpeg, которые работают на бэкенде этих сервисов. Похожая ситуация с нейронками, где многие знают программу Ollama для локального запуска моделей на CPU. Но мало кто понимает, что это всего лишь простенькая оболочка вокруг опенсорсной библиотеки llama.cpp на С, которая и делает инференс. Автор этой библиотеки, талантливый разработчик Георгий Герганов, мало известен широкой публике.