MySQL — это система управления базами данных с открытым исходным кодом, работающая на Windows, Linux и macOS. Ошибка «Command Not Found» возникает в тех случаях, когда система не может запустить службу MySQL, поскольку не находит исполняемый файл.
В этой статье мы разберем, как исправить эту ошибку в популярных операционных системах.
Когда код уже написан, половина багов уже не исправить. Парадокс? Нет — статическое тестирование. В этой статье разбираю, как находить дефекты ещё на этапе требований, почему «большой взрыв» интеграции — это путь в никуда, и зачем знать про заглушки, драйверы и уровни от компонентного до UAT.
ИИ-агенты для разработки быстро стали частью повседневной практики, но за внешней «магией» скрывается вполне конкретная архитектура: языковая модель, системный промпт, инструменты и цикл их вызова. В этой статье разберём, как это устроено на уровне механики – от токенов и контекста до вызова функций и режима рассуждения, – и почему именно эти детали определяют качество, стоимость и пределы таких систем. Это попытка посмотреть на агентный подход без иллюзий и понять, где заканчивается удобный интерфейс и начинается инженерия.
Когда бизнес-логика становится сложной, микросервисы из удобного инструмента превращаются в источник боли. Классические «сценарии транзакций» приводят к монструозным классам и распределённым транзакциям, которые невозможно поддерживать.
В этой статье разберу, как DDD и агрегаты помогают проектировать бизнес-логику так, чтобы она не разваливалась под нагрузкой. Покажу на реальном примере HR-сервиса:
▫️ почему объектные ссылки между сервисами — зло;
▫️ как одно правило «транзакция = один агрегат» меняет архитектуру.
Когда в 1С «просто тормозит», стандартные метрики и журнал регистрации почти бесполезны: они показывают факт, но не причину. Технологический журнал — один из немногих инструментов, который позволяет увидеть, что именно происходит внутри платформы: какие запросы реально выполняются, где возникают блокировки, и на каком участке кода уходит время. В этой статье — без лишней теории: как быстро включить техжурнал, что в нём действительно важно, и как за несколько минут находить медленные запросы и проблемные места в системе.
Привет, Хабр!
Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже.
Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил.
Продолжаем серию «Kotlin для новичков»! Сегодня разбираем самое сердце любого кода — управляющие конструкции: if, when, for, while.Вы узнаете, почему if в Kotlin — это не просто оператор, а выражение, как when заменяет целые лесенки else-if, и чем for по диапазонам лучше классического цикла. Реальные примеры и лучшие практики и история о том, как мы отрефакторили 300 строк спагетти-кода в 80 строк с помощью when и диапазонов. Читайте, чтобы писать чистый и понятный код на Kotlin.
Playwright — фреймворк от Microsoft для E2E-тестирования — был построен с нуля, чтобы решить именно эту проблемкую. В нем есть автоматические ожидания, изоляция через Browser Contexts и встроенный тест-раннер. Разберём, чем он отличается от Selenium и Cypress, и как писать тесты, которые не падают от ветра.
В этой статье мыпопробуем провести небольшое расследование, посвященное тому, как найти и обезвредить «тихого убийцу». В частности, мы на конкретных примерах разберём утечки памяти, фрагментацию дисков, проблему 95-го перцентиля и «зловещую тишину» в логах. А также, рассмотрим инструменты, которые не дадут производительности умереть незаметно.
Привет, Хабр!
PostgreSQL умеет блокировать строки (SELECT ... FOR UPDATE) и таблицы (LOCK TABLE). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение.
Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет.
Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.
Разрабатываете микросервисы и чувствуете, что бизнес-логика превращается в хаос?
В статье на примере простого UserService разберем, как три правила агрегатов DDD и асинхронные доменные события помогают навести порядок.
Обсудим, почему нельзя хранить объектные ссылки между сервисами, как спроектировать агрегат на Spring Boot
Дефекты — неизбежная часть разработки, но если они живут своей жизнью в чатах и трекерах, релизы превращаются в лотерею. В этой статье рассказываю, как выстроить системное управление дефектами: от жизненного цикла и сортировки до метрик вроде MTTR и SLA. Вы узнаете, чем серьёзность отличается от приоритета, почему «не воспроизводится» — это красный флаг для команды, и как метаданные дефекта экономят часы разработчиков.
Когда LLM перестаёт быть просто чат-интерфейсом и начинает сама планировать шаги, вызывать инструменты и общаться с другими агентами, ломаются и привычные способы контроля. В статье — о том, почему для агентных систем уже недостаточно мерить качество ответа, какие новые метрики нужны для оценки их работы и как меняются требования к безопасности, трассировке и эксплуатации таких архитектур.
Любой, кто хоть немного знаком с ИИ знает, что для эффективной работы искусственного интеллекта необходимы качественные данные. В результате 80% времени любого ML-проекта уходит не на подбор гиперпараметров и не на архитектуру нейросети, а на рутинный, выматывающий процесс — вылизывание данных. Мы собираем данные из множества устаревших систем, разбираемся с пустыми полями, убираем дубликаты, корректируем разметку. А после всего этого модель приходит ровно туда, куда мы её привели — шуму, смещениям и отравленным выборкам. В этой статье мы разберём основные проблемы, из-за которых все это происходит.
Привет, Хабр!
В Битрикс24 есть два инструмента автоматизации, которые как будто делают одно и то же. Роботы — настраиваются в CRM на стадиях воронки, срабатывают при переходе сделки между этапами. Бизнес-процессы — настраиваются в визуальном дизайнере, поддерживают ветвления, циклы, переменные и многоэтапные согласования.
Ответ на то, что использовать — очевиден не всегда, потому что возможности частично пересекаются: и робот может отправить письмо, и бизнес-процесс тоже. Но граница между ними большущая.
Разберём, чем роботы и бизнес-процессы отличаются по механике, и на конкретных сценариях покажем, где какой инструмент уместен.
В статье разобраны основные группы мероприятий, из которых состоит процесс тестирования. Вы узнаете:
▪️ чем отличаются тестовые условия от тест-кейсов,
▪️ зачем нужны таблицы решений и попарное тестирование,
▪️ как мониторинг и контроль помогают в общем процессе,
▪️ почему ретроспектива тестирования так же важна, как и планирование.
Материал будет полезен тестировщикам, разработчикам, тимлидам и всем, кто хочет выстроить процесс тестирования.
В командной работе есть парадокс, который раздражает сильнее, чем чужие ошибки. Ты объясняешь, и объясняешь все верно, но твой собеседник тебя не понимает, хоть ты тресни. Не его, разумеется. По столу например :)
Эта ситуация, в общем-то, не редкая и встречается почти повсеместно. Я собрала небольшой гайд по ясной коммуникации в работе про то, как этого избежать.
Даже опытные руководители пасуют перед сложными разговорами. Мы молчим, когда сотрудник делает что-то не так. Терпим, надеемся, что «само рассосётся». А потом удивляемся, почему команда живёт в стрессе, а люди уходят, так и не узнав, что от них хотели.
В этой статье — только практика:
▫️ Почему отсутствие обратной связи хуже, чем критика.
▫️ Как работают фреймворки SBI, COIN и радикальная откровенность на реальных примерах.
▫️ Пошаговый алгоритм подготовки к разговору, который не испортит отношения.
Статья будет полезна начинающим и практикующим тимлидам, а также разработчикам, которые планируют переход на руководящую позицию.
Логическая репликация в Postgres редко ломает прод внезапно — чаще она долго и методично копит проблему, пока replication slot удерживает всё больше WAL, потребитель отстаёт, а свободное место на диске начинает таять. В этой статье разбирается именно такая зона риска: как устроена работа replication slots, почему одних базовых настроек здесь недостаточно и какие практики реально помогают держать под контролем WAL, публикации, heartbeats, failover и мониторинг. Материал особенно полезен тем, кто работает с CDC, Debezium и production-инстансами Postgres, где цена ошибки измеряется уже не теорией, а стабильностью системы.
Одной из наиболее недооцененных сил при проектировании систем ИИ является задержка при выполнении вычислений. Когда инженеры говорят о производительности модели, они часто сосредотачиваются на точности, полноте данных и производительности обучения.
Но в производственных системах для пользователей огромное значение имеет время. Для них важно, чтобы система отвечала на их запросы достаточно быстро. Потому что даже самая умная система ИИ начинает сильно раздражать, если ответ на запрос пользователя приходит слишком поздно.
Именно поэтому задержка часто определяет архитектуру модели в большей степени, чем общее проектное решение.
