Как стать автором

Мой первый опыт в вайбкоде или универсальный инструмент для помощи в тестировании?

Давайте честно: каждый QA-инженер немного ленив в хорошем смысле слова. Нам не хочется тратить по 20 минут на рутину, которую можно автоматизировать. Мы постоянно ищем инструменты: один для Pairwise, второй для проверки MD5, третий для генерации данных.

В какой-то момент я понял, что мне нужно единое «окно», где будет всё. Так появился QA Helper Pro. Это мой первый серьезный опыт в разработке на Python. Весь проект написан на «вайбкоде» — когда ты просто хочешь, чтобы идея работала здесь и сейчас, а интерфейс был приятным и функциональным, я не говорю, что это идеальный инструмент, который правильно структурирован и реализован, но он работает и реально помогает в моей работе.

В этом посте разберем практический сценарий анализа защищенности в Active Directory. Также посмотрим на техники горизонтального перемещения и инструменты пентестеров.

Массовые отключения мобильного интернета в России в связи с атаками БПЛА стали насущной проблемой множества людей для которых 4G - единственный доступный способ выхода в сеть. В этой статье мы рассмотрим вариант решения при помощи 4G-роутера с направленной антенной.

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

Выведена формула, которая без погрешности (для чисел, кратных шести) находит разность между представлениями числа (x) в виде суммы двух составных чисел вида 6к-1 и 6к+1 и представлениями числа в виде суммы двух простых чисел вида 6к-1 и 6к+1 (h(n)).

Найден способ оценить нижнюю границу x и, следовательно, h(n). Для этого используется формула включений-исключений с коэффициентами.

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

Численная проверка показывает верность гипотезы при использовании в методе 10 простых чисел, для чисел, кратных 6, до 10 в 20, и метод распространяется и на большее значение с использованием новых простых.

Привет, Хабр! Мы часто говорим о проектировании ИИ и сложных систем. Но что, если применить наши инженерные методы к... походу за кефиром? Я решил написать об этом книгу. Это история про моего коллегу Тура Хайдала, его занудного ИИ‑помощника Платона и мир, который оказался немного более «кефирным», чем мы привыкли думать. Это одна из глав книги «Кефир и столб. Теория двух тел»

Привет! В этой статье я поделюсь конфигом для развертывания GitLab CE, который я собрал для своей команды. Когда я начинал, официальные гайды казались слишком общими: то почта не заводится, то Runner не видит сервер, то стандартные лимиты Nginx не дают запушить Docker-образ.

Я собрал "золотую середину": актуальная версия (18.10.0), настроенный SMTP для Gmail, готовый Runner и адекватные лимиты для артефактов. Этот конфиг мы успешно используем для хранения кода и автотестов.

Если вы хотите сразу перейти к делу — вот готовый docker-compose.yml, который мы используем в команде. Он уже содержит настройки SMTP, лимиты Nginx и подключённый Runner. Переменные окружения берутся из .env.

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

Мне захотелось вернуться к истокам: к быстрому, чистому и понятному интерфейсу. Так появился Gudex — проект, который вырос из идеи минимализма в полноценную платформу с real-time сообщениями, WebRTC-звонками, собственной платформой для ботов и зачатками внутренней экономики.

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

Всем привет! Сегодня я хочу поделиться своей историей создания первой игры, на которую я делаю серьезную ставку. Это не просто пет-проект, а попытка создать коммерчески успешный продукт, объединив в себе лучшее из того, во что я сам влюблен как игрок )

Многие пользователи при установке Odoo через Docker на Synology сталкиваются с тем, что страница управления базами данных или страница логина выглядит как «текст на белом фоне» без CSS‑стилей. В консоли браузера при этом видны ошибки 500 (Internal Server Error) для всех статических файлов.

Есть странный парадокс последних лет.

С одной стороны, инженеру всё труднее оставаться просто инженером. Уже мало «я написал, оно работает». Нужно уметь объяснить, зачем это нужно, кому это больно, почему именно так, чем это лучше альтернативы и почему за это стоит платить.

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

И теперь все встретились посередине.

Инженеры учатся продавать.
Продавцы надевают инженерную шкуру.
А ИИ доброжелательно помогает обеим сторонам выглядеть убедительнее, чем они есть.

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

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

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

Я называю набор практик для решения этой проблемы Project Hygiene — гигиена проекта. Это не отдельный промпт и не ещё один способ «правильно общаться с нейросетью». Это способ организовать проектную память, проверки и передачу состояния так, чтобы длинная работа с ИИ-инструментами не расползалась после нескольких сессий.

Привет, Habr!

Рутинные процессы после встреч, онбординг клиентов и сотрудников, подготовка follow‑up писем — это те задачи, которые редко выглядят сложными по отдельности, но в сумме создают постоянную операционную нагрузку и «расфокус» в работе команд.

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

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

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

Сейчас практически каждый день в мире происходят пуски ракет‑носителей с космическими аппаратами. Все эти аппараты несут самую разную полезную нагрузку: от широко известных всем оптико‑электронных комплексов для ДЗЗ до рентгеновских камер для изучения внутренностей других спутников. Я выделю несколько ключевых технологий, на которых сейчас в отрасли делается фокус и которые, на мой взгляд, кажутся интересными технологиями.

«Бизнесу это невыгодно!», «Мы не будем вкладывать в это ресурсы», «Зачем, оно и так отлично работает» — какие аргументы можно привести против всех этих высказываний?

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

Можно. Но есть моменты на которые важно обратить внимание и донести бизнесу.

Всех приветствую, меня зовут Владислав, я специализируюсь на мобильной безопасности Android‑приложений. На написание данной статьи меня «вдохновила» ситуация, с которой я столкнулся пару недель назад. В целях развития своих навыков и знаний в области ИБ — я активно изучаю чужие приложения с целью поиска уязвимостей (в рамках скоупа и закона, естественно). В связи с этим, хотел бы поразмыслить над темой оценки уязвимостей.

Обсудим тему и важность стакана в торговле (или orderbook, если так удобнее). В трейдинге это база — то, что необходимо знать в самом начале пути (это как изучать виды финансовых инструментов — не все пригодятся и не все будете использовать, но их знание необходимо для понимания происходящего). Неужели стакан — грааль?

До недавнего времени я спокойно пользовался Screenpresso. Меня всё устраивало: нажал Print Screen, выделил область, скриншот сохранился в папку. Никаких лишних кликов, редакторов и тормозов. Но в один день сервис просто перестал открываться – блокировка в России. Искать зеркала, настраивать прокси ради утилиты для скриншотов – такое себе. Я начал пробовать аналоги.

У меня в инфраструктуре мониторинг уже несколько лет стоит на Telegram‑ботах. Работало, работало — и перестало. Почему? Да кто ж его знает. Никогда такого не было, и вот опять. Боты молчат, сообщения приходят с задержкой или не приходят вообще, а ты сидишь и думаешь, что именно сломалось — связь или всё остальное. Мониторинг, который молчит именно тогда, когда что‑то сломалось — это, строго говоря, не мониторинг.

Начал думать, как это фиксить.

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

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

Я решил собрать свой вариант и назвал его AiRevit. Это не чатик с LLM поверх Revit. Тут вообще не предполагается использования такой архитектуры, которая бы основывалась на угадывании токена (нам не нужно ничего угадывать, нужно соблюдать строгие строительные правила). Это детерминированный pipeline, где текст сначала превращается в структурированный program_graph, потом в layout_solution, а уже потом в реальные элементы Revit через Dynamo и Python-скрипты. В репозитории это разложено на Node 3, Node 4 и Node 5, чтобы не было каши и чтобы каждый кусок отвечал за свою часть работы. (https://github.com/Rearks/AiRevit)

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

Интуитивно это воспринимается очень просто: есть «ничего», и в этом «ничего» вдруг возникают объекты. Это звучит как нарушение здравого смысла, и именно поэтому такая формулировка так популярна.

Проблема в том, что она объединяет разные физические эффекты в одну картину. Чтобы разобраться, нужно аккуратно разделить, о чём именно идёт речь, и перейти от образа «частиц в пустоте» к более точному описанию через поля.

Фактически, здесь происходит типичная для популярной науки подмена: удобная метафора начинает восприниматься как буквальное описание реальности.