Практика — лучший способ глубокого понимания теории. Рассмотрим на примере, как работают веб-сервисы с протоколом SOAP, для чего нужен WSDL и как он связан с XML-документом в теле POST-запроса.
Привет, Хабр! Меня зовут Илья Волынкин, я CTO платформы МТС Exolve. Когда мы говорим про VoIP-телефонию, первая ассоциация — Asterisk. Это open-source ПО захватило рынок и его аналоги не так популярны. На True Tech Day я рассказал про наш опыт с FreeSwitch — инструментом, решающим гораздо более масштабные задачи.
Благодаря ему мы смогли построить платформу, которая позволяет реализовывать сложные сценарии, добавлять разные модули (например, с AI под капотом), и собирать себе системы телефонии по принципу Lego. Под катом: рассказ про то, как сейчас усложнилась инфраструктура для звонков, какие есть варианты реализации VoIP и как это может развиться в будущем.
Краткий разбор моего опыта обучения на Яндекс.Практикуме и как я решил поменять свою жизнь и выбрать другую дорогу личностного и профессионального развития.
Мне кажется, что уже есть сотни разных статей на эту тему, но каждый раз мне чего-то не хватало. Поэтому я решил написать свою статью, в которой покажу, как я реализую авторизацию и аутентификацию в своих проектах. Это именно гайд: вы можете взять готовый код и адаптировать его под свои нужды. В рамках статьи будут использоваться Ory Hydra и Ory Kratos, Apache APISIX в качестве API Gateway и несколько микросервисов на Golang. Всё это будет работать в Docker, чтобы вы могли легко запустить и поиграться.
Так почему же Contract First оказался не так хорош на практике?
Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.
В этой статье мы расскажем, как создать собственного Telegram-бота, который интегрируется с amoCRM и распределяет уведомления о событиях в CRM, в зависимости от ролей пользователей. Система позволяет сотрудникам получать уведомления в том формате, который соответствует их обязанностям: отдел продаж видит сумму сделки и стадию, администраторы получают подробную информацию, а обычные пользователи – краткое сообщение о новой сделке. Такой подход способствует сокращению времени реакции на новые лиды, упрощает контроль за сделками и снижает необходимость постоянного ручного мониторинга CRM-системы.
Наш пример будет состоять из двух приложений. Базы данных PostgreSQL и скрипта бота.
Хорошо спроектированные и качественно документированные API — это удовольствие в работе.
Сегодня индустриальным стандартом де-факто стал OpenAPI, который предлагает методологию: сначала проектируем интерфейс API, а уже потом строим вокруг него остальную систему. Такой подход помогает сделать API понятным, стабильным и удобным для всех участников разработки.
Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?"
В этой статье я хочу ответить на этот вопрос: пройдемся от основ, преимуществ, недостатков, и закончим нюансами работы и проблемами, которые обязательно возникнут при миграции с контроллеров на Minimal API в крупном проекте.
А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом.
Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.
Однажды я внедрил в своей команде подход разработки через 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 сдаёт позиции, а новые игроки заходят в генерацию видео и аудио.
