Программирование *

Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.

Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.

Многие разработчики привыкли везде ставить if-проверки, даже для условий, гарантированных кодом. Зачем проверять то, что не может нарушиться? Такие проверки создают шум в коде и мусор в релизе. Assert решает эту проблему: документирует допущения и исчезает из финальной сборки. В статье покажу все преимущества assert'ов и предостерегу от подводных камней их использования.

Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.

Уже начало ноября, и мои парсеры давно собрали свежие данные. Сегодня я поделюсь анализом обновления рейтинга и новостями проекта...

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

Сегодня расскажу о довольно узком, но довольно интересном моменты работы с Linux — о процессе с PID 1 и зомби-процессах. Когда запускаешь приложение в минимальном окружении и оно оказывается первым процессом, могут возникнуть небольшие сюрпрзики. Та же команда ps может показывать несколько процессов со статусом <defunct>. Эти дефекты и есть зомби-процессы. Столкнувшись с ними впервые, можно растеряться, ведь процесс уже завершился, а запись о нём всё торчит в таблице процессов. Как так, и главное, что с этим делать?

Давайте смотреть, почему появляются зомби, какую роль здесь играет процесс №1 (он же init), и как написать свой минималистичный init, который этих зомби убивает (то есть убирает) автоматически.

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

Некоторые считают Java раздутым монстром, а Rust — чемпионом производительности. Но что, если взглянуть на современную Java с Vector API и многопоточностью? 

В новом переводе от команды Spring АйО посмотрим на запуск масштабной симуляции частиц и сравним результаты. Правда ли, что бывалая Java всё ещё умеет удивлять? 

Сравнение performance-а языков всегда было холиварной темой. Рекомендуем расценивать статью как приглашение к конструктивной дискуссиии, а не как призыв к конкретному действию.

Команда разработчиков прислала мне на ревью свой API, в одной из частей которого множество поддерживаемых значений выражалось в виде трёх чисел:

• Минимального допустимого значения.
• Инкремента.
• Максимального допустимого значения.

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

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

Я указал, что эта архитектура искушает пользователя делить на ноль.

Недавно столкнулся с задачей: нужно было быстро перевести несколько сотен PNG-файлов в WebP для сайта, но делать это через онлайн-сервисы не хотелось — во-первых, передавать изображения куда-то сторонним серверам не очень удобно, а во-вторых, процесс обычно занимает заметное время.

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

Пока все учат ИИ, ИИ учит меня. Отбросив книжки, курсы и самодуров с YouTube, я нашёл более-менее продуктивный способ самообучения при помощи ИИ. Подробней об этом рассказываю в статье.

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

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

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

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

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI, для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит.

Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции.

Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль.

Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости.

Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

В этой статье я расскажу вам, как наша команда — «жыбий рыр» участвовала в хакатоне от DDOS‑GUARD

Рассмотрим, какой кейс мы выбрали, покажу, к какой реализации пришли и покажу наше решение, а в конце подведем итоги.

Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.

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

Сегодня рассмотрим решение одной непростой задачи, как в Django выдавать очень большие объёмы данных, например, выгрузку в CSV или потоковый JSON-формат NDJSON) так, чтобы сервер не ложился от нагрузки, а пользователи быстрее получали первые данные. Разберём, как использовать StreamingHttpResponse и генераторы (в том числе асинхронные) для стриминга больших ответов и поговорим нюансах.

В конце октября 2025 Anysphere представила Cursor 2.0 — крупное обновление AI-IDE с параллельными агентами и новой моделью Composer. Идея проста: вы ставите цели, а агенты пишут и проверяют код, тестируют и готовят диффы, а разработчик смещается к роли менеджера ИИ-процесса. В статье разбираемся, что именно появилось, на чем это работает и какие ограничения важно учесть.

Может ли Rust заменить C? Этот вопрос беспокоил меня много лет. Тем временем я успел написать upb — библиотеку C для работы с Protocol Buffers, и сейчас являюсь её техническим руководителем. Вполне понятно стремление обеспечить безопасность памяти в пределах всего программного стека — поэтому и возникла идея портировать upb на Rust.

Притом, что мне приятны базовые принципы Rust, я долгое время относился к этой идее скептически и сомневался, что, портировав upb на Rust, удастся сберечь её производительность и компактность кода, которые мы с коллегами так старались оптимизировать. На самом деле, исходно я собирался написать статью о том, почему именно применительно к upb языку Rust никогда не сравниться с C по производительности.

Но недавно я открыл для себя одну технику, которая заставила меня немного переосмыслить этот вопрос. Я назову её «Rust без паник». Притом, что этот метод определённо не нов, мне нигде не удалось найти подробного разбора, в котором бы рассказывалось, как именно этот метод используется и какие проблемы решает. Правда, интересная дискуссия по этому поводу велась в теме Enforcing no-std and no-panic during build, где есть ссылки на некоторые релевантные треды из почтовой рассылки, посвящённой разработке ядра Linux. Вот другой интересный тред: Negative view on Rust: panicking

Надеюсь, эта статья позволит заполнить данный пробел.

Команда Rust рада сообщить о новой версии языка — 1.91.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.

Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.91.0 вам достаточно выполнить команду:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.

Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.

Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите.

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

Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.