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

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

Разберем реальный кейс, где попытка сделать «идеальное» техническое задание привела к увеличению сроков проекта почти в два раза.

Как тестировать микросервисы, чтобы не было мучительно больно на проде? Разбираем пирамиду тестирования, интеграционные тесты с Testcontainers, контракты с Pact и нагрузочные испытания. Расскажу, какие практики реально работают в крупных проектах...

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

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

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Понятие контейнер сейчас активно применяется в контексте Docker и аналогичных решений по контейнеризации. Однако, в языке C++ контейнеры существуют уже очень давно и являются фундаментальной частью Standard Template Library (STL). Они предоставляют готовые реализации наиболее часто используемых структур данных, избавляя разработчика от необходимости писать их с нуля.

Контейнеры C++ можно разделить на несколько основных категорий. Последовательные контейнеры (Sequence Containers) хранят элементы в линейной последовательности, при этом порядок элементов определяется позицией добавления. Ассоциативные контейнеры (Associative Containers) автоматически сортируют элементы по ключу. При этом, они обеспечивают достаточно быстрый поиск (O(log n)). Неупорядоченные ассоциативные контейнеры (Unordered Associative Containers) хранят элементы в хеш-таблицах. Обеспечивают поиск в среднем за O(1). Адаптеры контейнеров (Container Adapters) предоставляют ограниченный интерфейс поверх других контейнеров.

В рамках данной статьи мы будем говорить об использовании библиотеки Ranges для работы с контейнерами.

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

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

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

Моделирование домена — это не про UML-диаграммы и не про красивые ER-модели. Это про то, как перестать тратить месяцы на переписывание кода и начать говорить с бизнесом на одном языке. В статье — разбор DDD без воды: Ubiquitous Language, Bounded Context, тактические паттерны (Entities, Value Objects, Aggregates) и реальный пример кода на Java. Заходите — будет практично!

Акторы в Swift решают проблему гонок данных. Cам по себе актор гарантирует, что к его состоянию обращается только одна задача одновременно. Никаких мьютексов, семафоров, очередей — компилятор сам следит.

Звучит неплохо. Но есть подвох, и он называется повторный вход (reentrancy). Актор защищает от одновременного доступа, но не защищает от того, что состояние изменится между двумя вашими обращениями к нему.

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

Что если переход на локальную инфраструктуру (вроде Ollama) это решение, которое не просто поможет сэкономить, но изменит саму динамику разработки?

Управляемые блокировки в 1С. Механизм выглядит простым (объект БлокировкаДанных, три метода — добавить, установить значение, заблокировать), а на практике поведение отличается от ожидаемого настолько, что в типовых конфигурациях до сих пор находят ошибки, связанные с блокировками.

В PostgreSQL есть фича, про которую знают далеко не все, хотя она существует с незапамятных времён. Advisory locks — пользовательские блокировки, которыми управляет не БД, а ваше приложение. PostgreSQL только хранит их состояние и разруливает конкуренцию. А вы решаете, что именно заблокировать и когда отпустить.

Зачем это нужно? Вы строите распределённую систему, несколько инстансов приложения работают с одной базой, и вам нужно гарантировать, что определённую операцию выполняет только один инстанс одновременно. Классический ответ — Redis с SETNX или Consul/ZooKeeper. Но если у вас уже есть PostgreSQL — зачем тащить ещё одну зависимость?

Если вы попробуете загуглить, кто такой продакт-менеджер, вы получите красивую, но неоднозначную картинку. Стратег, лидер, аналитик, мини-сео. А еще, если открыть 10 вакансий от 10 разных компаний, то вы увидите 10 разных ролей.

Так кто же это такой? Давайте разберемся в этом вопросе подробнее.

Создать реплику PostgreSQL на базе в 1 TiB — задача, где быстро выясняется, что NVMe и сеть в 75 Гбит/с сами по себе ничего не гарантируют: упираешься в инструмент, который копирует данные в один поток. В статье разбираемся, как обойти этот потолок с помощью pgBackRest и параллельной передачи, какие настройки реально влияют на скорость, где легко потерять порядок величины на «мелочи» вроде хранилища под spool, и почему в PostgreSQL 18 внезапно стало лучше — но недостаточно.

Статья к открытому уроку курса QA Automation Engineer про начало разработки тестов на языке Java которая погружает в основы синтаксиса.

В Python хватает инструментов для работы с временными рядами, но обычно приходится жонглировать тремя-четырьмя пакетами с разными API. Darts — библиотека, которая собирает всё в одном месте: статистические модели, градиентный бустинг, нейросети — и работает по знакомой схеме fit() / predict(). Сегодня разберём её подробно: что умеет, где удобна, как использовать в задачах.

В 1970 году 512 бит памяти были инженерным компромиссом, а ожидание «своего» бита — нормальной частью работы системы. В этой статье — разбор микросхемы Intel 1405 с фотографиями кристалла, вскрытого вручную, и подробным анализом того, как устроен регистр сдвига на уровне транзисторов и поликремниевых дорожек. Заодно посмотрим, почему такая память оказывалась дешевле статического ОЗУ, как она применялась в Datapoint 2200 и зачем для неё понадобился отдельный мощный драйвер тактовых сигналов. Это взгляд внутрь эпохи, когда архитектурные решения буквально были видны под микроскопом.

Если вы пишете на Solidity больше полугода, вы наверняка уже сталкивались с прокси-контрактами. Если нет — сталкивались, просто не знали об этом: почти каждый серьёзный протокол на EVM использует какой-нибудь прокси-паттерн. Uniswap, Aave, OpenSea — все они. А в основе всех прокси лежит один опкод — DELEGATECALL.

Уже вышла Java 25 — самая свежая версия, которую все хотят попробовать. Но ставить ли её новичку? Или взять проверенную Java 21 LTS? В этом гайде — пошаговая установка Java на Windows с картинками, разбор различий между версиями, настройка JAVA_HOME и PATH ориентирован для начинающих разработчиков, изучающих Java