Бэкенд

Асинхронное логирование давно считается “очевидной оптимизацией”: вынесли запись в отдельный поток — и всё стало быстрее.

Но если копнуть глубже, оказывается, что это не совсем так.

В предыдущей статье я разбирал производительность популярных C++ логгеров и показывал реальные цифры:
👉 https://habr.com/ru/articles/1012874/

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

В этой статье разберёмся, почему async logging не делает логирование быстрее само по себе, и что на самом деле происходит внутри:

Вы только что стали тимлидом? Поздравляю. А теперь вопрос: вы ещё пишете код или уже управляете людьми? Если второй вариант, а в голове всё ещё «я сделаю быстрее сам» — вы в ловушке.

В этой статье:

‣ разбираю, почему делегирование — главный навык руководителя, как не скатиться в микроменеджмент и вырастить команду, которая справится без вас;

‣ даю пошаговый алгоритм, матрица зрелости задач, реальный кейс и схемы.

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

Привет, Хабр! Меня зовут Анастасия Черникова, я занимаюсь разработкой компиляторных технологий и инструментов на базе LLVM в Синтакоре.

Неопределенное поведение (undefined behavior, UB) по-разному выглядит с точки зрения компилятора и разработчика. Для первого оно, как правило, открывает дополнительные возможности для оптимизации. Для программиста же UB может стать проблемой, особенно если оно остается незамеченным и не учитывается при разработке.

В этой статье рассмотрим подход к поиску UB с использованием статического анализа. В качестве примера я использую clang-tidy: сначала разберу, как устроены существующие чекеры и как работают AST matchers, а затем покажу, как расширять их и добавлять собственные проверки, если стандартных возможностей оказывается недостаточно.

Нас с ребятами в OpenIDE уже какое-то время спрашивают, как написать свой плагин. И вот пришла пора рассказать, как это делается.

Представьте логиста, у которого перед глазами 400 разных коробок и 8 машин. У него есть Excel, калькулятор и два часа времени. Я решил, что это несправедливо, и написал веб-сервис на Django, который делает это мгновенно. Внутри: 3D MaxRects, полная свобода вращения (6 осей) и учет суровой реальности — от очередности выгрузки до предельной нагрузки на нижние ряды.

Для тех, кто предпочитает один раз увидеть: вот 3-минутное демо работы интерфейса и визуализации на Three.js

https://youtu.be/JP80ESX0YiQ

Привет, Хабр! Мы — Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать.

Приветствуем любую обратную связь! (づ ◕‿◕ )づ

Всем привет!

Если вы хоть раз пытались нормально вкатиться в разработку Telegram-ботов, то почти наверняка сталкивались с одной проблемой: информации в интернете много, но она какая-то рваная. То есть где-то вам сразу дают библиотеку, заставляя писать код и даже не объяснив, как бот вообще работает.

В особых сценариях (например разработка userbot) смешивают воедино Telegram Bot API, Telegram API (да, это разные вещи!), api_id, api_hash, token, chat_id, webhook и еще десяток терминов.

А где-то вообще показывают “hello world”, который фактически-то работает, но только ты ступишь на шаг вперед, так всё начинает разваливаться, ведь понимания практически 0.

В этой статье моя цель - разобрать всё это нормально и по-человечески, объяснив как использовать Telegram Bot API для создания ботов.

На связи Сергей Скирдин, технический директор компании «Белый код». Поставил себе цель — сделать обзоры на шины данных из реестра отечественного ПО. Сегодня в обзоре продукт MARS (Система маршрутизации и протоколирования).

С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 20+ разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина. 

В Bitrix24 автоматизация часто превращается в отдельный проект: приложения, OAuth, лишняя инфраструктура. Хотя многие задачи — создание сделок, уведомления, реакции на события — можно закрыть намного проще. Вебхуки дают прямой доступ к API через один URL и позволяют быстро связать CRM с внешними сервисами. Разберёмся, как это работает, где реально помогает и где начинаются ограничения.

Всем привет, меня зовут Николай Голубев, я — техлид из компании HFLabs. Эта статья написана по мотивам моего выступления на конференции Saint HighLoad++.

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

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

Сегодня (2026.04.01) прошло ровно 9731 день с тех пор, как сообщество Python узнало об изъяне в работе со строками.

Это было так давно, что у Python еще не было мажорных версий (для холиваров приходилось использовать PHP).

Так давно, что еще не существовало ни pythonchallenge.com, ни его прародителя notpron.com - легендарных убийц времени программистов.

Это было в прошлом тысячелетии. А именно - 1999 году, когда, согласно летописям, реализовали тип string. В том же году ведущий разработчик Jim Fulton опубликовал исследование, где без купюр указал на проблему.

Как ни странно, она не решена до сих пор.

Это - третья статья цикла про функцию ограничения скорости обработки запросов в ASP.NET Core. Она содержит концептуальное (т.е. раскрывающее состав и взаимодействие частей функции друг с другом) описание классов универсального компонента ограничения скорости .NET. Функция ограничения скорости обработки запросов в ASP.NET Core, которая является предметом рассмотрения всего цикла, базируется именно на этом универсальном компоненте. В этой статье я собираюсь завершить описание универсального компонента ограничения в .NET: описать входящие в его состав базовые (неселективные) ограничители.

Предупреждение: если вам не требуется или не интересно просто для себя (как это интересно мне) разбираться, как устроена и работает функция ограничения скорости обработки запросов в ASP.NET Core, то эта статья, скорее всего, покажется вам длинной и занудной. Потому что в ней рассказывается о весьма специфических подробностях, знание которых совершенно не требуются для того чтобы просто взять и начать использовать в своей программе функцию ограничения скорости обработки запросов ASP.NET Core. Для использования этой функции, скорее всего достаточно будет изучить примеры - или из первой статьи цикла - руководства по использованию, или вообще из документации на сайте Microsoft. В таком случае вам, наверное, читать эту статью не стоит. Но, возможно, и в этом случае вам стоит хотя бы заглянуть в приложения к ней. Там я, в качестве иллюстрации к основному материалу статьи, описал сделанные мной компоненты, позволяющие использовать функцию ограничения скорости нестандартным способом: возможно, вы найдёте применение одному из таких компонентов в своей программе. Компоненты эти оформлены в виде библиотек классов .NET, так что для их использования уже сейчас можно взять их в исходном виде и добавить в свое решение (solution). Причем, при описании каждого компонента я постарался вынести в начало их описания пример его использования - так, чтобы для использования компонента не требовалось читать остальной текст приложения, где написано как он устроен и работает.

Ну, а если вам пришлось разбираться (потому что эта функция не работает так, как вы ожидали) или, как мне, просто захотелось разобраться для себя, как работает функция ограничения скорости обработки запросов в ASP.NET Core - читайте дальше.

Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.

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

Новый фреймворк тестирования Testo готов к испытаниям.

В статье: причины появления Testo; его фичи в краткой форме и в примерах; быстрый старт; что дальше.

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

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

Я провел фундаментальное исследование, проанализировал натальные карты Гвидо ван Россума, Страуструпа и прочих, и составил первый в мире точный гороскоп языков программирования.

И результат меня поразил...

Читая новости я начинаю что-то подозревать. СМИ пишут, что треть разработчиков пишут код с ИИ, а в Отечестве — три четверти отечественных разработчиков (по данным Яндекса), а в Anthropic, говорят, некоторые инженеры вообще не пишут код. А статистика это подтверждает и говорит, что за шесть месяцев доля коммитов Claude Code на GitHub выросла с 0,7% до 4,5% (по состоянию на март 2026).

В интернете на эту тему разворачиваются статьи о том, как LLM изменят программирование и теперь код создаётся сам:

— «Writing code is cheap now»
— «Code is cheap. Show me the talk»
— «Code is cheap now. Software isnt»

Контекст нового мира вокруг меня таков, что не использовать ИИ нельзя (?). Иногда его начинают использовать из любопытства. Иногда, чтобы быть «на передовой». Иногда он рекомендуется к использованию. Иногда он рекомендуется очень настойчиво. В общем, как сказал Райан Даль, создатель NodeJS, «эпоха, когда люди писали код, закончилась»

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

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

Экспорт Telegram в Obsidian, создание локальной базы знаний и общение с ней с помощью чата LLM. Рассмотрим экспорт данных Telegram в заметки Obsidian с полной поддержкой медиафайлов, форматирования, группировки по дням и AI-интеграции для умного поиска. В конце статьи бонус для вашего кодинг АИ-агента.

Всем привет!

Эта статья больше веха для себя, чем полезная информация для кого либо, но если вам близка тема парсинга API-ответов, то думаю вам будет интересно.

Что получилось

От базовой версии получилось ускориться в 4 раза, отставание от wplake/typed сократилось до "всего лишь" x2, если вам критична скорость вам к wplake/typed, если вам критична читаемость выбирайте sbwerewolf/language-specific.

Это интервью Гвидо ван Россума с core‑разработчиком Python Бреттом Кэнноном, в котором они обсудили начало и развитие карьеры Бретта как программиста и активного участника сообщества разработчиков Python, развитие самого языка, сложность управления большим сообществом, кризис PEP 572 >:=, выход Гвидо на пенсию в 2018 г. и к чему это привело.