Multi-Agent Orchestrator — гибкая и мощная платформа для управления несколькими AI-агентами и обработки сложных разговоров.
GitHub Repo - https://github.com/awslabs/multi-agent-orchestrator
На заре появления LLM пользователям приходилось просто копировать свой код в текстовое окно, чтобы ИИ могла его обработать. Естественно, такой подход быстро всех утомил, и разработчики начали искать свои способы загрузки данных в модель. У этого подхода была серьезная проблема — каждому приходилось изобретать велосипед заново.
Именно поэтому появился протокол MCP (Model Context Protocol) — универсальный способ дать искусственному интеллекту доступ к нужным данным, неважно где они хранятся — на компьютере пользователя или же в интернете.
При проектировании интеграций через Kafka или другие брокеры сообщений можно столкнуться с проблемой зависимых сообщений в разных очередях/топиках.
Давайте изучим эту проблему подробнее и проанализируем, как ее можно решить с помощью паттернов проектирования Dead Letter и Inbox.
Верите ли вы в настоящую любовь? И я сейчас не про то мимолетное увлечение, когда прям с первого взгляда «искра, буря, безумие», а про выстроенную годами усилий, литрами пота и крови любовь. Лично я – верю! И хоть на новой работе я больше не использую XWiki, но время от времени так и хочется провести с ней удивительные мгновения и поделиться новым опытом с дорогими читателями.
На этом лирическое отступление завершается и мы переходим к практической части.
В данной статье мы расширим функции популярной opensource замены Confluence (со слов разработчиков) и добавим в XWiki возможность совершить телефонный звонок пользователю прямо из браузера, по нажатию всего одной кнопки на боковой панели.
Поможет нам в этом простой и доступный инструмент для работы с IP телефонией – Exolve WebSDK. Именно с помощью данной JavaScript (TypeScript) библиотеки мы будем совершать звонки. Кстати, новые пользователи могут протестировать МТС Evolve бесплатно, в рамках тестового баланса, в том числе и Mobile SDK, пусть и с некоторыми ограничениями (подробнее см. в документации).
Приемы, которые мы используем при внедрении Exolve WebSDK в XWiki, также будут полезны при подключении других сторонних JS библиотек. Поэтому надеюсь, что статья будет интересна не только тем, кто интересуется IP-телефонией, но и фанатам XWiki.
Продолжаем рассказывать, как идет портирование КОМПАС-3D на Linux (начало здесь). Сегодня речь про API и с вами Владимир Кузнецов, инженер‑программист по прикладным интерфейсам КОМПАС-3D.
До начала разработки нативной Linux‑версии КОМПАС-3D у нас был API экспортных функций, API5 и API7 под Windows. Когда возникла необходимость поддерживать КОМПАС на нескольких операционных системах, было принято решение создать кроссплатформенный API, который бы работал как на Windows, так и в ОС Linux. Рабочее название такого API — KsAPI.
Каждый стартап рано или поздно сталкивается с необходимостью обработки платежей онлайн.
В эпоху SaaS, PaaS, IaaS и других «As a Service» инициатив (их число постоянно растет), многие полагаются на бизнес модель платных подписок, так как она обеспечивает возможность регулярно в автоматическом режиме собирать платежи с пользователей и дает лучшую прогнозируемость финансовых потоков.
На рынке сейчас много поставщиков продуктов для решения данной задачи, однако есть среди них один, чьи продукты обычно рассматривают в первую очередь. Я говорю о Stripe.
В этой статье я хочу предложить читателю технический взгляд на решение проблемы обработки онлайн подписок с помощью языка программирования Scala и фреймворка Akka в распределенном серверном приложении для Кубернетиса.
Kubernetes действительно поражает своими могучими возможностями к расширению. Вы наверняка уже знаете про operator-паттерн, а также фреймворки kubebuilder и operator-sdk с помощью которых можно его реализовать. Если вкратце, то они позволяют расширять ваш Kubernetes через определение кастом-ресурсов (CRDs) и написание дополнительного контроллера, который будет выполнять вашу бизнес-логику для реконсиляции и управления этими ресурсами. Этот подход широко изучен, а в интернете можно найти огромное количество информации о том, как написать такой оператор.
Однако это не единственный метод расширения Kubernetes API. Так, для более сложных кейсов, например реализации императивной логики, сабресурсов и формирования ответов на лету, можно рассмотреть механизм API aggregation layer, который поддерживается в Kubernetes. В рамках aggregation layer можно разработать свой собственный extension API server и бесшовно интегрировать его в общий Kubernetes API.
В этой статье мы разберем, что такое API aggregation layer, для решения каких задач его стоит использовать, когда его использовать не стоит и как мы использовали эту модель для реализации собственного extension API server в платформе Cozystack.
Здравствуйте, друзья! Меня зовут Константин, я python backend developer из компании «Окенит». Сегодня я хочу рассказать свое видение проблемы новичка при ознакомлении с принципами SOLID, описанными в книге «Стерильная Архитектура» Робина Мартерта.
За свой десятилетний опыт я часто был свидетелем ситуации, когда молодые разработчики, желая сделать свой проект как можно более открытым для расширения и редактирования, превращали его в груду нечитаемого и неподдерживаемого кода при попытке использовать у себя все рекомендации Матушки Роба. Отсюда вопрос: «Почему, при следовании советам более опытного разработчика, код стал только хуже?».
Ответ на этот вопрос пришел ко мне очень быстро. Из‑за описания и без того абстрактных вещей чересчур абстрактными словами и примерами, Робин Мартерта вместо упорядочивания знаний, наводит хаос в умы читателей. Во избежание этой ситуации я решил написать данную статью, где коротко расскажу о наборе принципов SOLID, для чего они нужны и, главное, как применять эти принципы в жизни. Начнем по порядку, с буквы «S». И так, что же она значит?
Привет, Хабр! Представим ситуацию: вы клиент. Разговор с менеджером завершен, он предложил вам что-то полезное — услугу, продукт или подписку — и, допустим, вы соглашаетесь: «Почему бы и нет, отличная идея». Менеджер записал ваше согласие и обещал напомнить вам через месяц. Звучит просто.
Но вот в реальности ни один менеджер не помнит про сотни обещаний клиентам. И здесь на помощь приходит автоматизация. В этой статье рассмотрим, как построить систему автоматического напоминания, которая избавит менеджеров от лишней работы и увеличит количество сделок, которые могли бы улетучиться.
Привет, Хабр! Пол года назад на AnalystDays #18 я рассказывал про API-контракты, и доклад вызвал большой интерес у аудитории. Пока видео не опубликовали, решил адаптировать материал в формат статьи.
Это перевод статьи от Philipp Acsany
В этой третьей части серии вы узнаете, как:
• Работать с несколькими таблицами с взаимосвязанной информацией в базе данных
• Создавать связи «один ко многим» в базе данных
• Управлять связями с помощью SQLAlchemy
• Сериализовать сложные схемы данных со связями с помощью Marshmallow
• Отображать связанные объекты в клиентском интерфейсе
Содержание
• Введение
• Построение собственного голосового помощника
• Настройка Raspberry Pi
• Подключение микрофона, клавиатуры и мыши
• Аспекты питания
• Реализация кода
• Обнаружение слова активации
• Распознавание речи и преобразование в текст
• Использование Chat API
• Преобразование текста в речь
• Тестирование и оценка производительности
• Заключение
В последние годы наблюдается всплеск интереса к разработке в области искусственного интеллекта и инновационных проектов. С появлением Chat API, передовой языковой модели, стало заманчивым создание персонального голосового помощника, превосходящего существующие решения, такие как Google Assistant или Amazon Echo. В этой статье мы рассмотрим процесс создания собственного голосового помощника с использованием Raspberry Pi, Chat API и нескольких дополнительных компонентов.
Не кажется ли вам, что декларативная конфигурация и программирование инфраструктуры не так уж хороши, как их расхваливают?
Я достаточно долго занимался декларативной конфигурацией в Kubernetes: размышлял о ней, работал с kubectl apply, KRM, kustomize, Google Cloud Config Sync, kpt, porch, ... В то же время параллельно развивалась декларативная автоматизация — эта работа велась в Google, где на протяжении многих лет широко использовалась декларативная конфигурация. При этом вне Google появился Terraform, и на этом лоскутном одеяле также возникло множество других инструментов.
Что же такое декларативная конфигурация, в каких случаях она хороша, и как к ней подступиться?
## TL;DR
TypeSpec умеет генерировать спецификации в форматах OpenAPI v3.0.0, Protobuf, JSON Schema.
В статье приведен базовый пример генерации спецификации, но возможности TypeSpec покрывают все потребности любого проекта. В том числе за счет возможности расширения своими библиотеками.
Всем привет! Меня зовут Иван Чечиков. В этой статье я расскажу о своем пет-проекте - Android приложении, которое может идентифицировать нежелательные входящие звонки.
Подробности – под катом.
В мире интеграций REST API на сегодняшний день занимает по праву свое почетное, королевское место. Сегодня мало какой проект или продукт обходится без стандартных HTTP-методов и документации к ним.
Но если для REST API уже всемирную славу приобрел Open API со своей Swagger-документацией, которая внедряется практически повсеместно и является по праву, так сказать, золотым стандартом, то для брокеров сообщений и, в целом для асинхронного взаимодействия, в большинстве случаев дела обстоят далеко не так однозначно.
В данной статье я хотел бы подробнее остановиться на довольно молодом типе спецификации для асинхронного взаимодействия - AsyncAPI, который, на мой взгляд, имеет огромный потенциал и все шансы на массовое применение в будущем.
На некоторых порталах, в том числе и здесь, уже косвенно поднималась тема AsyncAPI и вызывала у авторов, как правило, смешанные чувства. Описывали преимущества и недостатки, приводили некоторые примеры. Справедливо отметить, что AsyncAPI, конечно же, не идеален.
Но если посмотреть на это с другой стороны: удобно ли будет разработчику читать ТЗ и другую документацию касаемо разработки интеграции по асинхрону, слепленную из кусков текста, таблиц, рисунков, непонятных ссылок и т.д.? Одно дело, если разработчик находится на проекте с самого начала и знает все тонкости и может сам что-то додумать. Но если человек придет на проект уже через один, два или более лет после начала проекта и увидит тонны макулатуры, которую как-то нужно читать и анализировать, то вот тут начинаются трудные времена.
Привет! Меня зовут Максим Соколов, я — аналитик в команде “Управление доступностью товаров и категорий”. В нашей команде была выделена отдельная подгруппа, которая создавалась специально под новый продукт-фичу для селлеров. Сразу стало понятно, что для реализации нового функционала требуется разработка нового микросервиса. Командой разработки было принято решение интегрироваться по gRPC, но мне до конца не было понятно, почему выбор именно такой. И тут я решил разобраться подробнее!
До этого я занимался анализом доработок по уже существующему функционалу, поэтому не задавался вопросом, почему выбран тот или иной путь реализации API. Но здесь-то всё с нуля, а специалисту, который дебютирует в этом выборе, становится ещё трудней.
Могу сказать, что выбор технологии для проекта — задача непростая, требующая совместного участия разных участников технической команды: аналитик, разработчик, тимлид, архитектор.
На свете много статей про проектирование API, в которых описаны архитектурные стили, протоколы, технологии. Информации — огромное количество, иногда она даже противоречивая, поэтому новичку тяжело подступиться к теме.
В этой статье я хочу дать точку входа для джун/мидл системных аналитиков, которые хотят разобраться в межсервисной интеграции. Мы пройдёмся по HTTP, REST, RPC и gRPC, разберёмся в их значениях. Выясним, почему эти аббревиатуры появляются, когда происходит проектирование API, и попробуем понять, когда и что следует применять.
Также по ходу статьи буду оставлять ссылки на хорошие (по моему мнению) статьи для более глубокого погружения в поднимаемые темы.
Всем привет! У платформы МТС Exolve есть сообщество, которое часто делится полезными гайдами от прокачки своих серверов до открытия ворот по SMS. Наиболее интересные и подробные решили размещать в нашем хабе.
В этом гайде пользователь объясняет, как можно написать простого Telegram чат-бота на NodeJS, который будет пересылать все входящие сообщения в SMS, используя Exolve SMS API.
Большое количество специалистов в области IT используют переводчики текста в своей работе, и я тому не исключение. Достаточно часто в вакансиях Системного администратора можно встретить требуемый навык - "чтение технической документации на английском языке", но, не всегда такая документация может быть очевидной в полной мере, даже имея базовый уровень английского языка, и как мне кажется, тут нечему стесняется. Для перевода текста чаще всего используется браузер, а также десктопные приложения, я же расскажу про альтернативу таким решениям, для перевода текста прямо в консоли Linux или Windows.
Как создать асинхронный API для мониторинга курсов валют на Python? В этом практическом руководстве мы разработаем сервис на FastAPI с интеграцией APScheduler, который будет отслеживать курсы USD и EUR в банках России. Вы узнаете, как реализовать асинхронный парсинг данных, настроить планировщик задач и развернуть приложение в облаке. Проект включает систему аутентификации, фильтрацию данных и REST API — идеальный пример для изучения современной веб-разработки на Python.
