
Однажды я внедрил в своей команде подход разработки через API-first. Все было классно, мы описывали API спецификации в файле, запускали генерацию, публиковали артефакты в репозиторий, но... это было не удобно.
О создании API
Однажды я внедрил в своей команде подход разработки через API-first. Все было классно, мы описывали API спецификации в файле, запускали генерацию, публиковали артефакты в репозиторий, но... это было не удобно.
Друзья, привет! Меня зовут Ларионов Александр. Я работаю системным аналитиком. Совместно с Лабораторией инноваций Московской биржи мы изучали вопрос применения AI в системном анализе.
Когда я впервые столкнулся с задачей внедрения AI-ассистентов в процессы работы системного аналитика, то отреагировал скептически. Поводов было немало: большинство материалов на эту тему представляли собой восторженные отзывы вроде «AI автоматизирует рутину» или «machine learning улучшает принятие решений». Однако, при ближайшем рассмотрении, эти фразы распадались на абстрактные утверждения. Попытки уточнить у авторов конкретные кейсы или сценарии применения их инструментов для системного анализа сводились к общим фразам: «Обучите модель на ваших данных — и она всё поймёт».
Скептицизма добавляло и то, что сама роль системного аналитика строится на работе в условиях высокой неопределенности. В этой специальности регулярно сталкиваются с неоднозначными требованиями, непонятной бизнес-логикой, конфликтующими приоритетами, быстро меняющимися требованиями. Это противоречит глубинному принципу современных AI-моделей — обучению на конкретных, четко структурированных данных. Машине сложно оперировать «чувством здравого смысла» или «интуитивным пониманием бизнес-процессов», которые так важны для аналитика.
Как же убедиться, что AI полезен для нашей профессии, когда в поиске реальных кейсов находишь информационный вакуум? Я решил переосмыслить подход и начать экспериментировать самостоятельно. За основу я взял самые распространённые задачи, с которыми сталкиваются системные аналитики, в том числе и мы в Лаборатории инноваций Московской биржи.
Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишите, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда почему мы разбиваем проект по слоям, а не по фичам (эндпоинтам)?
Это видно в часто используемых нынче архитектурных подходах: Layered, Clean Architecture, Onion, и так далее. Не буду выделять что-то конкретное и объясню общую разницу в подходах:
Vertical Slice Architecture (VSA) строится вокруг каждого отдельного feature-слайса (эндпоинта, как самый простой пример), а не на вокруг слоев.
То есть, если код относится к конкретному эндпоинту, мы не размазываем его по всему проекту в папках Commands/Services/Repositories/DTOs и т.п., а кладем в одно место, там где и будет находиться эндпоинт
Главный принцип - уменьшаем связанность между слайсами (фичами), увеличиваем связанность внутри слайса
В пригороде далекого города Нью-Дели жил простой индийский паренек со сложным именем Чандракант. Любил он маму, Кришну и общаться с волшебными говорящими грибами.
Независимо от того, работаете ли вы с локальными системами, облачными решениями или сторонними сервисами, ключевые вопросы остаются одними и теми же: какой пользовательский или клиентский опыт вы хотите предложить? И как согласовать с этим опытом вашу стратегию интеграции?
В этом справочном материале рассматриваются базовые шаблоны для аутентификации, поллинга, запросов и других аспектов, которые помогут вам оценить потребности в интеграции и подойти к проектированию, разработке и сопровождению API-интеграций наиболее эффективно с точки зрения вашего бизнес-кейса.
А вы никогда не задумывались, почему, с одной стороны, у нас появляются всё более крутые и мощные инструменты для разработки? На бэкенде мы можем делать микросервисы, писать офигительные SPA-приложения — но при этом будто бы сама программа становится всё хуже и хуже.
Каждый раз происходит одна и та же история: мы хотим сделать как лучше, но код в итоге всё равно превращается во что-то странное и не поддерживаемое.
Откуда берётся эта эрозия программного обеспечения? Почему так выходит, что новые технологии не только не помогают, но иногда даже мешают нам писать качественные программы? Почему, когда мы стараемся делать хорошо — получается плохо?
И главное — что с этим делать?
Очередной раз разрабатывая и оптимизируя архитектуру не вполне стандартного проекта, для чего у AI, ожидаемо, нет готового шаблона, а только «лоскутки» чужих решений, решил зафиксировать свой ход мыслей и последовательность этапов в решении нестандартной задачи. Чтобы абстрактную программистскую «чуйку» зафиксировать в более чёткий и осознанный «свод правил».
Представьте, что у вас есть некая система, которая работает определённым образом. У неё есть свой API, свои архитектурные принципы, рекомендуемые подходы к разработке и т.п. С другой стороны, у вас у самого есть видение своего будущего проекта, его архитектуры и того, как бы вы хотели управлять функционалом, предоставляемым «некой системой». Видение есть, а вот уверенности, что так можно – нету. Вот, делюсь своим подходом, как я поступаю в таких ситуациях.
Недавно мне пришла идея воссоздать механику Reddit внутри Telegram.
Телега — отличная и популярная платформа для общения и ведения блогов, но, на мой взгляд, это ужасное место для создания настоящих сообществ.
До этого я никогда не писал ботов или мини-аппов. У меня был только некоторый опыт в веб-разработке. Давно хотел разобраться, как всё это работает... И вот появилось немного свободного времени, звёзды сошлись и я запилил свой мини-Реддит в Телеге :)
Привет, меня зовут Саша Ковалёва. За последние пару лет я: переехала из Владивостока в Москву, освоила SQL, устроилась в IT-компанию без профильного образования и выросла до тимлида. Сейчас продолжаю работать с базами данных в компании, которая разрабатывает low-code BPM-систему, а в свободное время занимаюсь вокалом и реслингом.
В этой статье я расскажу, как искала свой путь в IT-сфере и по каким материалам училась. Надеюсь, мой опыт будет полезен тем, кто начинает карьеру в IT.
Разбираемся, в каких сценариях «Аврора» уже превосходит Android: безопасность, кастомизация, импортозамещение — и где системе ещё есть куда расти.
Привет! Меня зовут Ольга и я QA-специалист SimbirSoft. На данный момент моя специализация сопрягается с тестированием платформы «1С».
Идея статьи появилась, когда ко мне обратился коллега с вопросом: что такое интеграционное тестирование «1С». Готовясь ко встрече с ним, я поняла, что это очень важный этап в работе с программой для QA-специалиста. Статья поможет на этапе изучения интеграционного тестирования платформы понять, что нужно учесть при планировании тестирования, подсветить возможные узкие места и предотвратить появление критичных багов. Расширить знания QA-специалиста в платформе «1С» в целом и возможности ее интеграции в частности.
Также статья будет полезна для SDET специалистов, тимлидов или PO проектов, где присутствует эта платформа.
Какие ИИ-модели набирают популярность, а кто теряет доверие пользователей? Весной 2025-го платформа Poe раскрывает неожиданные повороты в гонке LLM: OpenAI и Google вырываются вперёд, Anthropic сдаёт позиции, а новые игроки заходят в генерацию видео и аудио.
Сначала — REST API. Затем — gRPC. ChatGPT по силам перевести твой Rest API в gRPC и интегрировать в проект за пару минут. Но если ты всё ещё веришь в силу ручной настройки и хочешь понять, как работает gRPC в Spring Boot на базовом уровне — эта статья для тебя.
В прошлом году, просматривая пул-реквесты по поводу компилятора Rust, я обратил внимание на #126013. В нём к некоторым пакетам компилятора добавлялась проверка unreachable_pub. Естественно, меня это заинтересовало, так как на тот момент я о такой проверке не знал. Но, разобравшись с её описанием, я тем более удивился, так как эта проверка показалась мне абсолютным нонсенсом! Поговорив об этом с авторами пул-реквеста, я осознал, что, пожалуй, достаточно странно представляю себе, как устроена видимость в Rust. Как минимум, я воспринимал её не «так, как она была задумана».
Эта тема показалась мне достаточно интересной, чтобы раскрыть её в блоге. В этой статье я коротко объясню, как именно работает видимость в Rust, а потом опишу два достаточно разных способа её использовать. Если вы знаете, как в Rust устроена видимость, можете смело пропускать введение и переходить к главной теме. Оговорюсь, что в этом посте я просто вывалил различные мысли на данную тему, скопившиеся у меня, так что не ожидайте найти здесь каких-либо супер-откровений :).
Современные компании всё чаще сталкиваются с необходимостью интеграции IP-телефонии и CRM-систем для улучшения управления клиентскими коммуникациями. Такая интеграция позволяет автоматизировать ключевые процессы, минимизировать человеческий фактор и ускорить обработку обращений.
Модуль интеграции Itgrix надежный инструмент интеграции IP-телефонии Asterisk и CRM-систем для оперативной работы со звонками.
С его помощью вы получите полный контроль над телефонными коммуникациями, сохраните гибкость настройки вашего оборудования и интегрируете данные в удобную CRM-систему для повышения эффективности продаж и клиентского сервиса.
Когда мы решили вывести на прод Telegram‑мини‑приложение для «капельных» (drip) TON‑платежей, довольно быстро стало ясно: обычный CRUD‑фронт тут не выживет. Сразу накрыла волна специфичных задач — от гранулярного онбординга в Web‑App до борьбы с ограничениями API‑ключей и тонкостей работы с TON SDK во встроенном браузере Telegram. Каждый шаг требовал не только кода, но и аккуратного выбора архитектурных приёмов, иначе продукту грозили дубли запросов, «белые экраны» и несогласованность состояний.
В этой статье я разобрал пятнадцать самых характерных «боевых» сложностей, показал, каким паттерном мы их укрощали, и какой антипаттерн поджидал за поворотом. Это не академический список, а выжимка из коммитов и ночных дебаг‑сессий, которая поможет тем, кто строит похожие интеграции между Telegram, TON и React.
No-code платформы – мощный тренд 2025 года, позволяющий создавать приложения и автоматизировать процессы компании с минимальным привлечением программистов.
В прошлой части статьи мы говорили о пушах в harbor, в этой же статье мы разберемся другие методы с которыми работает его webhook.
Keycloak - это мощная open-source платформа для аутентификации и авторизации, которую используют даже банки и крупные корпоративные клиенты для защиты своих приложений и данных.
В статье на реальном примере (FastAPI + Python) простым языком объясню, как Keycloak помогает упростить управление доступом и почему его принципы универсальны для любого бэкенда, независимо от выбранного языка программирования
Всем привет! У платформы МТС Exolve есть сообщество, которое часто делится полезными гайдами от прокачки серверов до создания своих приложений. Наиболее интересные и подробные продолжаем размещать в нашем хабе. В этот раз изучим возможности автоматических SIP-звонков.