Бэкенд

В своей прошлой статье: «статья», я описал примеры из реальной работы, когда ИИ-инструменты повышают продуктивность разработчика и помогают командам быстрее закрывать таски.

Однако, к сожалению, я хочу признать, что до этой статьи я написал целую серию постов, где разбирал тему проектирования публичного API, которая не нашла какого-то интереса со стороны читателей. И с учётом анализа айтишного поля в инфопространстве сейчас есть лишь две темы, которые обсуждают люди: «Смерть айтишной профессии (в том числе массовые увольнения)» и ИИ-связанные темы. И я решил подумать, а почему это происходит.

«Смерть айтишной профессии» обсуждать не будем, ибо это тема для дум-скроллеров, поговорим про ИИ.

ИИ — потенциальный gamechanger

Если мы предполагаем, что навыки написания кода у ИИ будут развиваться с такой же скоростью, как они развивались после появления ChatGPT, то в какой момент изучение айтишного инструментария станет бесполезным?

TL;DR. Один «безобидный» foo.GetAsync().Result в middleware способен превратить ASP.NET Core, державший 50k RPS с p99 = 40 мс, в сервис с 12k RPS и p99 = 4 с — при CPU 8 %.

Виноват не сам blocking call, а hill-climbing — фидбэк-луп в ThreadPool, в недрах которого живёт дискретное преобразование Фурье. Разбираем по исходникам CoreCLR, почему это вообще возможно, воспроизводим эффект на ~80 строках кода и разбираемся, почему SetMinThreads — не решение, а анестезия.

Когда я начал поднимать PostgreSQL через Docker для своих проектов, всё выглядело просто: описал сервис в docker-compose.yml, запустил контейнер - база доступна.

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

«Ты кнопкодав с многолетним опытом смузихлёбства» — примерно так сейчас звучит позиция рынка в адрес опытных разработчиков. Венчурные деньги уходят в AI-first, штаты сокращаются, джуны уверены, что знают лучше. Я руководил отделом из 30 человек и наблюдал это изнутри.

Это не нытьё про «раньше было лучше». Это попытка честно разобраться, что происходит с профессией — через личный эксперимент.

Статья о том, как получить наблюдаемость (observability) в приложении с минимальным кодом, а бонусом получить структурированные логи с типизированными шаблонами, автоматическую корреляцию со спанами OpenTelemetry, всё это с помощью набора библиотек, которые я называю CleverBrush Framework.

Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.

Я расскажу как шифрование можно организовать на уровне протокола brec и ни в коем случае не буду затрагивать те самые принципиальные решения, влияющие на безопасность (как передавать, куда передавать, отправлять ли, и хранить ли чувствительные данные вовсе). Иными словами нас интересует инструментальная сторона вопроса.

Каждый, кто программирует с агентами (Claude Code, Codex и т.д.), знает: перед тем как приступить к задаче, агент исследует проект. Это кажется логичным, естественным и закономерным, ведь люди делают так же. Обычно говорят: «агент наполняет контекст».

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

- задача определена в общем виде (кто знает, что имел в виду автор)
- пути исследования не детерминированы (в общем виде не используется специфика фреймворка)
- используются базовые инструменты (read, grep, cat, find)

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

В Anthropic быстро осознали эту проблему и вынесли всю описанную работу в Explore sub-agent. В результате основной agent ставит задачу промптом, Explore выбирает путь исследования, а результат формирует в виде отчета. Проблему чистоты основного контекста они, конечно, решили. Но что с качеством такого анализа?

Наблюдая за работой Explore и видя, как агент, используя «примитивные» инструменты, в агонии пытаясь отыскать недостающее или, наоборот, пропускает важные сведения о проекте, невольно ловишь себя на мысли: «Как так вышло, что последние 10 лет развития индустрии инструментов прошли мимо agent?» А может, это человечество свернуло не туда?

Ксения Прокофьева, руководитель отдела разработки C3D Converter, C3D Labs, рассказывает об обновлениях и перспективах развития модуля C3D Converter.

До недавнего времени модуль C3D Converter поддерживал только стандартные форматы обмена данными — SAT, STEP, Parasolid и пр. С 2020 г. началась активная работа с проприетарными форматами: изначально с использованием сторонних решений. А начиная с 2023 г. началось развитие собственных разработок (рис. 1).

В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. 

Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки.

Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов.

Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками.

Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.

Если ваша CMS или CRM умеет отправлять email‑копию о новом заказе на произвольный адрес — этот гайд для вас. InSales, RetailCRM, МойСклад, WooCommerce, Битрикс, самописная система — без разницы. Инфраструктура одна и та же. Ссылка на гитхаб с полным мануалом по установке на русском в конце статьи.

Поводом написать стало то, что неделю назад приложение InSales было удалено из App Store и пуши о заказах пропали сразу. Таким образом мы пропустили несколько заказов, но благо они не сорвались полностью, хотя небольшой неприятный осадок остался.

Первая мысль при поиске решения — n8n или Make. Но зарубежные no‑code платформы сейчас работают в России нестабильно из‑за замедлений и блокировок трафика. Строить критическую бизнес‑инфраструктуру на том, что может лечь в любой момент — плохая идея.

Задача: автономная система, работающая внутри РФ, без постоянного сервера, с доставкой уведомлений в Telegram за секунды. Решение — Yandex Cloud Serverless, т.к он не боится блокировок, имеет очень щедрые лимиты, благодаря чему функция работает полностью бесплатно. К тому же сервис очень гибок в настройке и улучшении.

Расскажу, что получилось, и дам полный гайд по настройке.

Привет, Хабр! Меня зовут Никита, я являюсь разработчиком в направлении SSL инфраструктурной команды биллинга в Timeweb Cloud. Сегодня я хочу рассказать, как мы наводили порядок в коде одного из наших микросервисов, почему отказались от лапши в контроллерах, и главное — почему мы решили выложить наш внутренний архитектурный фреймворк в Open Source. Если вы пишете на Python и хоть раз сталкивались с болью распределенных транзакций, отваливающихся внешних API и проблемой dual-write (двойной записи) — присаживайтесь поудобнее. Речь пойдет про наш open-source фреймворк python-cqrs (он же доступен на PyPI).

Привет, Хабр! Меня зовут Александр, я Java-разработчик в GlowByte. Работаю в практике управления рисками и комплаенс (Risk & Compliance). Хочу поделиться своим опытом и в целом рассказать о том, чем мы здесь занимаемся. А занимаемся мы автоматизацией систем управления рисками – от AML (противодействие легализации доходов) и операционных рисков до коллекшна (взыскание просроченной задолженности) и систем принятия решений.

Моё направление – как раз последнее: системы принятия решений (СПР). Если коротко, мы автоматизируем стратегии, где нужно в реальном времени перерабатывать кучу входных параметров, учитывать множество факторов и выдавать сложные, комплексные решения. Типичные примеры: оценка риска, предстраховые проверки, системы мониторинга, расчет резервов, расчет комиссионных вознаграждений страховым агентам и многое другое.

Чем это интересно? На выходе – не просто «да/нет», а полноценное управляемое бизнес-правило, которое можно быстро менять без переписывания кода.

В этой статье хочу поделиться опытом разработки backend API на Spring Boot-проекте, где нам пришлось много работать с OpenAPI-спецификацией, динамическими запросами и тестированием бизнес-логики.

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

Если и у вас есть желание написать какую-нибудь сложную абстракцию «на будущее» или применить новый паттерн просто потому, что вы его выучили — остановитесь на секунду.

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

Любопытный парадокс современной технологической культуры: чем сильнее индустрия твердит о рациональности, данных и критическом мышлении, тем чаще внутри нее возникают почти религиозные формы мышления. Например, культ «ИИ» или крипто-мессианство, биохакерские утопии, вера в «оптимизацию человечества», технократический элитизм и убеждение, что любая проблема — всего лишь ошибка, которую можно отдебажить. Особенно интересно последнее, ведь считается, что программист — это человек, защищенный от мифов самим устройством профессии, ведь он работает с логикой и формальными системами. А что выходит на самом деле? Разбираемся в статье, которая наверняка найдет отклик аудитории именно здесь, на Хабре. 

Пару дней назад я просматривал статьи в песочнице «Хабра» и наткнулся на статью парня от 2011 года, где с полным воодушевлением обсуждает открытие стартапа. После чего я открыл сайт, и он даже открылся (хотя если пробить информацию по налоговой базе, становится понятно, что какой-то коммерческой деятельности там уже давно нет). И это меня навело на мысль, что гараж, который строят за пару месяцев, стоит годами, а софт устаревает за несколько лет и уходит в небытие. У меня появился внутренний вопрос: «Стоят ли ваши усилия и профессионализм того, чтобы софт, написанный сегодня, ушёл в небытие через несколько лет?» Такой экзистенциальный вопрос профессионализма?

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

В данной статье будет описана структура PostgreSQL-базы данных и реализация данной задачи с помощью SQL в варианте PL/pgSQL. Реализация на Apache Spark будет описана в следующей статье.

В качестве примера будут созданы настройки распределения и входные данные для:

В этой статье я поделюсь опытом проектирования идентификаторов для крупной медицинской системы. Мы пройдем путь от простых автоинкрементов до UUID, ULID и в итоге создадим гибридное решение, которое оказалось лучше всех существующих подходов. Спойлер: идеальный ID — это не технология, а архитектура.

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

Зарплаты джунов в IT обычно невысокие. Работодатели ищут сотрудников с опытом от года даже на начальные позиции, а в вакансиях без опыта нередко предлагают 60-70 тысяч — довольно мало для тех, кто полгода потратил на обучение и вложил в него 100+ тысяч рублей.

Разброс между направлениями огромный. Джун в одной специализации стартует с 60 тысяч рублей, в другой — с 130 тысяч при том же уровне опыта.

Сегодня в статье разберём три самых высокооплачиваемых направления в IT для начинающих — SRE-инженерию, продуктовую аналитику и ML-разработку. Расскажем, чем занимаются специалисты, сколько можно получать и где учиться.

Есть в жизни вещи, которые приносят мне и радость, и печаль одновременно. Например, горький шоколад и markdown. Серьёзно, зачем он нужен? В половине случаев мы даже не используем этот язык целиком!

HTML — лучший язык программирования!

Вы наверняка слышали о людях, которые говорят, что из языков программирования знают только HTML. Да, все мы в этот момент закатывали глаза и пытались доказать, что HTML — это только язык разметки, а не программирования.

Да, наверно, мы правы, но у того, кто так говорит, есть то, чего нет у нас.

Нормальная жизнь.

[Примечание] Когда я говорю о markdown, то имею в виду конкретно CommonMark, если не указано иное. Дело в том, что это неоднозначная спецификация синтаксиса. Я люблю этот проект и ценю усилия разработчиков. Поломана не спецификация, а сам язык.