Статья посвящена завершению поддержки ingress-nginx и рассматривает это событие не просто как необходимость заменить один Kubernetes-компонент на другой, а как повод пересмотреть архитектуру маршрутизации в Kubernetes-платформе. В статье показано, как со временем простой Ingress превращается в набор NGINX-specific annotations и накопленного технического долга, который сложно поддерживать и объяснять. Так же разбираются возможности Gateway API, разделение ответственности между Platform-командой и разработчиками, а также подходы к миграции существующей инфраструктуры. Особое внимание уделяется аудиту текущих Ingress, постепенному внедрению новой модели и отказу от массовой миграции ради миграции. Основная идея статьи — не просто перенести сотни Ingress в HTTPRoute, а использовать изменения для построения более понятной, управляемой и масштабируемой Kubernetes-платформы.

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

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

410 вариантов писем, сотня микросервисов и до 15 файлов, которые приходилось править ради одной нотификации. Добавление письма превратилось в квест: создай компонент, подключи, опиши параметры, зарегистрируй — и молись, что ничего не забыл.

Мы устали и автоматизировали это. Теперь описываем контракт письма в OpenAPI, а CLI генерирует весь boilerplate — от NestJS-артефактов до React-компонента с типизированными пропсами. Часы работы сжались до минут.

Меня зовут Денис, я фронтенд-разработчик в ЮMoney. В этой статье расскажу, почему мы пришли к кодогенерации, как устроили процесс и что в нём изменилось для разработчиков, дизайнеров и тестировщиков. Материал будет полезен тем, кто работает с React, NestJS или TypeScript и хочет перестать писать однотипный код вручную. Особенно если поддержка UI-компонентов и API-слоя отнимает время, которое лучше потратить на реальную логику.

Привет! Меня зовут Максим Месилов, я один из мейнтейнеров BITRIX24 PHP SDK.

У Битрикс24 большой REST API: через него разработчики подключают внешние сервисы, работают с CRM и создают приложения для Marketplace.

С API можно работать напрямую, но тогда появляется повторяющаяся техническая работа: авторизация, вызовы методов и обработка ответов. Каждый раз писать это заново неудобно, поэтому вокруг API постепенно появился PHP SDK — библиотека, которая берёт на себя базовую работу с платформой и даёт разработчику привычный интерфейс на PHP.

Сегодня рассказываю, как PHP SDK для Битрикс24 вырос из pet-проекта в официальный инструмент, зачем он нужен в эпоху AI-кодинга и почему SDK становится нижним слоем для разработки приложений и интеграций вокруг Битрикс24.