Всем привет, меня зовут Денис Лимарев, я руковожу разработкой в одной из продуктовых команд Uzum Tezkor. В этой статье разберу несколько оптимизаций запросов к БД, которыми наша команда пользуется при разработке своих сервисов, и опишу подход к оптимизациям запросов в целом. В своих проектах мы используем PostgreSQL версии 14.15, поэтому все запросы я проанализировал на ней, и ваши результаты могут отличаться в зависимости от вашей версии.
Привет, Хабр! Меня зовут Владимир Добрынин, я ведущий разработчик в МТС Web Services. Наша команда занимается плагинами DevTools, которые упрощают и ускоряют создание софта, в том числе за счет сокращения рутинных операций.
У нас уже есть целое семейство внутренних инструментов. Один из них — DevTools Copilot, который непосредственно из среды разработки позволяет взаимодействовать с LLM в режиме чата. А теперь мы реализовали DevTools Code Review, который помогает проводить самостоятельное код-ревью. В этой статье расскажу, как работает плагин и чего мы с его помощью добились.
Peck - это мощный инструмент CLI, предназначенный для выявления ошибок формулировки или написания в вашей кодовой базе: имена файлов, имена классов, имена методов, имена свойств, документы и многое другое
💧 Условие задачи: «Аквариум» (Container With Most Water)
Представим, что нам дан массив целых чисел — например:
[1, 8, 6, 2, 5, 4, 8, 3, 7]
Каждое число в этом массиве символизирует высоту вертикальной стенки — как будто это столбец, воткнутый вертикально в пол. Все столбцы стоят на одной горизонтальной линии, то есть на «полу» (ось x), и находятся на равном расстоянии друг от друга.
📦 Теперь представим, что между этими столбиками можно налить воду — как будто мы смотрим на 2D-аквариум сбоку.
🧠 Цель задачи
Найти две такие стенки (столбцы), которые, если между ними налить воду (по нижней границе — полу), смогут удержать наибольшее количество воды.
💧 Объём воды между двумя столбцами рассчитывается так:
• Высота воды ограничена меньшей из двух стенок — потому что вода не может быть выше, чем самая низкая из них (иначе вытечет).
• Ширина — это расстояние между этими двумя столбцами (в индексах).
объём = (индекс_правой − индекс_левой) × min(высота_левой, высота_правой)
Массив: [1, 8, 6, 2, 5, 4, 8, 3, 7]
Индексы: 0 1 2 3 4 5 6 7 8
Столбцы (высоты): вертикальные стенки
Пол: горизонтальная база (ось x)
Вода: заливается между двумя стенками и держится на уровне самой низкой из них.
Забегая вперед скажу
2. Классическое решение и его недостатки
Обычно задача решается методом двух указателей с линейной сложностью. Однако этот подход не всегда даёт глубокую интуицию выбора стенок.
⸻
3. Предложенный подход
Я ввожу понятие энергоэффективной оценки каждой стенки:
При этом:
• Если стенка ближе к центру, её расстояние меньше — значит штраф за “удалённость” ниже.
• Высокая, но далёкая стенка будет “наказана” в оценке.
• Выбираются две стенки с максимальными result, а затем между ними вычисляется реальный объём воды.
⸻
4. Обоснование устойчивости (пример)
При наличии сильно асимметричного массива (например, левые элементы — [1, 2, 1], правые — [9, 8, 9]), алгоритм всё равно выбирает правые высокие значения, потому что они превосходят штраф и сохраняют высокий итоговый результат.
✔ Это делает алгоритм устойчивым к локальным аномалиям и не требует явно жёстких условий или вложенных циклов.
⸻
5. Заключение
Предложенный алгоритм демонстрирует новый взгляд на задачу через призму “выгодности” стенки, объединяя геометрическую и энергетическую оценку. Он сохраняет линейную сложность, но обладает дополнительной устойчивостью и хорошей визуальной интерпретацией.
Разница:
За более чем 10 лет в разработке я не раз сталкивался с проблемой недостаточной производительности сервисов. Особенно это заметно на Python – отличном языке для быстрого старта, с множеством библиотек и фреймворков. Однако, когда проект растёт, его производительности начинает не хватать, и проблемы с задержками превращаются в угрозу стабильности и пользовательскому опыту. В этом руководстве я поделюсь практическими решениями, основанными на реальных кейсах, чтобы помочь вам оптимизировать Django-сервис и значительно сократить время ответа на запросы.
Даже без сторонних библиотек в языке есть много встроенных инструментов, которые помогают лаконично обрабатывать данные, писать читаемый код и избегать лишних проверок и циклов.
В этой статье мы собрали конструкции, которые пригодятся как начинающим, так и более опытным разработчикам.
Привет, Хабр!
Не раз ловил себя на том, как в код-ревью всплывает одна и та же проблема: часть наших функций синхронные, часть асинхронные, а часть ведут себя как шрёдингеровские коты и делают вид, что синхронны, пока не дотронешься. В итоге в одном месте у нас try/catch, в другом .catch, где-то внезапно падает исключение, а в соседнем модуле молча утекает Promise. С появлением нативного Promise.try стало проще навести порядок и избавиться от разнобоя. Фича прошла процесс стандартизации в TC39 и включена в спецификацию ECMAScript 2026, при этом уже с января доступна в актуальных движках. Можно перестать спорить про обёртку из Promise.resolve().then и получить единый вход для sync/async с нормальной обработкой ошибок.
Real-time системы и протоколы — тема, которая меня давно интересовала. В рамках эксперимента я решил попробовать свои силы:
Работа с WebSocket для двунаправленной связи в реальном времени
Масштабирование соединений и оптимизация производительности
Разработка собственного протокола/формата передачи данных для надёжности и скорости
Уже в ноябре 2025 выходит Spring Boot 4 — масштабный релиз, построенный на фундаменте Spring Framework 7.0.0 и Jakarta EE 11. Это не просто очередное обновление, а важный этап в развитии всей Java-платформы: новые возможности для REST и безопасности, улучшенная работа с Kotlin и GraalVM, мощная поддержка облаков и нативных образов, а также инструменты для создания отказоустойчивых приложений.
🧠 Эта статья — больше, чем просто перевод: в ней собрано большое кол-во комментариев от экспертов Spring АйО.
Можно ли подключить сетевой диск к железному серверу за минуту, при этом не выключая его, сохраняя отказоустойчивость и не привлекая инженеров?
Я Беляков Алексей — Go-разработчик в Cloud.ru, в статье расскажу, как нам удалось это сделать. Сначала поделюсь кейсами, которые натолкнули на создание такой фичи, затем расскажу, как мы реализовали ее интеграцию со стороны сервиса Bare Metal, а в конце покажу, как всего за минуту можно расширить дисковое пространство физического сервера.
Привет, Хабр! Еще в C++23 появились «плоские» ассоциативные контейнеры: std::flat_set, std::flat_map и их многоключевые аналоги. Проще говоря, это полные аналоги обычных std::set и std::map, но реализованные иначе – через упорядоченный последовательный контейнер (по умолчанию std::vector). Зачем вообще понадобились эти штуки? Официальная причина – экономия памяти и выигрыш в производительности при чтении данных.
Привет, Хабр! Меня зовут Александр Митин. Я Java разработчик в компании ИТ-холдинг Т1 с 15 летним опытом, из которых последние 5 лет работаю в финтехе. Мой любимый стек — Java Spring. Я хочу рассказать такое AsyncAPI, как работать со спецификациями, какие есть инструменты и поделюсь нашим опытом перехода на подход API First в наших системах.
В этой статье рассматривается решение проблемы деплоя Telegram-бота Coreness, с подробный описанием проблем и решений. Вместо ручного копирования файлов, настройки зависимостей и миграций БД была создана система, которая делает всё автоматически.
Вам нужно создать сложный запрос к реляционной БД с изменяющимися параметрами?
В этой статье рассмотрим основные возможности Criteria API. Также рассмотрим более продвинутые вещи, например создание CTE и оконных функций, которые есть у Hibernate Criteria API. В статье много примеров, которые смогут помочь при написании запросов Criteria API на практике.
Всем привет! Меня зовут Александр Стерлигов, я руковожу проектным офисом в MWS Cloud Platform. Мы начали строить новое облако в 2023 году, и всего за год наша команда выросла со 150 до 520 человек.
Быстрый рост всегда приносит новые возможности, но вместе с ними приходят и серьёзные вызовы. Нужно не только расширять штат, но и превращать группы незнакомых людей в слаженные команды, сохранять управляемость и прозрачность процессов, избегая хаоса. Всё это при том, что перед нами стояла амбициозная цель — вывести в продакшен собственную облачную платформу. В Q2 2025 мы успешно запустили её фундаментальную часть — IaaS.
В этой статье я хочу поделиться нашим опытом: какие ошибки чаще всего совершают быстрорастущие команды, как выстраивать процессы, которые масштабируются вместе с организацией, и какие практики помогли нам сохранить эффективность даже при пятикратном росте.
Привет, Хабр!
Если вы собираете прототип на C++, то один файл с main.cpp иногда реально компилируется в рабочую утилиту. Библиотеки либо завозятся пакетным менеджером заранее, либо у вас есть header-only зависимость и всё взлетает. В Python долгое время это было болью: любой однофайловый скрипт, который требует requests или rich, уже тянет за собой виртуальные окружения, инструкции в README и локальные фичи.
Есть рабочий стандарт для нормальных однофайловых сценариев с зависимостями — PEP 723: вы объявляете зависимости прямо в комментариях, а раннер ставит всё сам и запускает в изолированной среде. В связке с uv получается неплохой такой способ делиться скриптами, в том числе для пвспомогательных задач. И да, у этой красоты есть нюансы безопасности, о них поговорим отдельно.
Бывает полезно проводить валидацию данных из формы ввода и на фронте и на бэке, например чтобы не гонять лишний запрос с заведомо "плохими" данными. Отсюда появляется задача написания двух одинаковых валидаторов для фронта и бэка.
Если фронт и бэк написан на одном языке (привет js+node), то мы можем напрямую использовать один код валидатора и там и там.
В остальных случаях (js+php, java, python, go, dotnet) есть проблема. Во-первых, придётся два раза писать примерно одно и то же на двух языках, во-вторых, нужно убедиться, что написанное работает одинаково. Особенно печальны случаи, когда фронт ошибочно зарезает данные, валидные с точки зрения бэка и логики приложения.
Привет, Хабр!
Вы, наверно, привыкли к стандартным HTTP-ответам – 200, 301, 404, 500 и т. д. А тут подкрался новый статус 103 – Early Hints. Это небольшой пинок браузеру: сервер шлет код 103 с заголовками Link: rel=preload ещё до того, как сформировал основной HTML. Пока бэкенд думает над ответом, браузер параллельно начинает грузить критические ресурсы (CSS, JS, шрифты и т. д.). Звучит просто, но эффект на производительность и LCP может быть весьма значительным.
Когда я начал работать с Asio и изучал документацию библиотеки, прочитал мнение, что доку писали «для роботов». Описание каждого концепта, функции или особенности приводится лишь однажды, без перекрестных ссылок и других удобных для разработчика деталей. Документация составлена так, что понять ее может разве что машина, «просканировав» текст целиком.
Я подумал, что было бы здорово написать статью, которая служила бы введением в библиотеку. Статью, которая помогла бы начать пользоваться Asio, даже если раньше вы с ней не работали. Что получилось, читайте под катом.
Всем привет, сегодня расскажу о том как на протяжении нескольких месяцев продумывал совместно с ии концепцию блокчейна нового поколения, что бы осознали как он будет прочитайте whitepaper
Whitepaper: Topological Blockchain (TGB)
Мы представляем Topological Blockchain (TGB) — блокчейн нового поколения, основанный не на традиционной криптографии, а на фундаментальных принципах алгебраической топологии. TGB моделирует леджер как динамическое топологическое пространство (симплексный комплекс), где транзакции — это математические узлы, а консенсус достигается через проверку топологических инвариантов. Этот подход решает трилемму блокчейна, обеспечивает устойчивость к квантовым атакам и радикально снижает энергопотребление, заменяя Proof-of-Work/Stake на Proof-of-Calculation — осмысленную вычислительную работу. TGB — это не просто эволюция, а революция, создающая математически доказуемо безопасную, бесконечно масштабируемую и адаптивную платформу для децентрализованной экономики будущего.