От трейдера в хедж-фонде до продакт-оунера в Финаме: как искать «альфу», собирать портфели и зачем нужны хитрые ордера
Представляем новый выпуск подкаста.
Наш гость - Эмиль прошел путь от финансового инженера в Швейцарии до трейдера в алгоритмическом хедж-фонде, а теперь руководит развитием TradeAPI в Финаме. В этом интервью мы разбираем:
что такое финансовый прайсинг и как ищут рыночную неэффективность («альфу»)
как работает алгоритмический хедж-фонд изнутри и почему там ценят бесконфликтность больше, чем гениальность
переход из трейдинга в продукт: чем занимается продакт-оунер в финтехе и как общение с клиентами формирует новый функционал
что такое TradeAPI, кому он нужен и какие «хитрые ордера» появятся в будущем
может ли ИИ заменить трейдера, почему бэктесты часто врут и стоит ли бояться, что вашу стратегию украдут
учеба в Швейцарии, работа ассистентом профессора и почему лучшие знания получаются не на лекциях, а в личном общении.
Полезно для всех, кто интересуется финансами, финтехом, трейдингом и карьерой в IT-продуктах.
Многие используют подход API First в проектировании систем, но зачастую даже не задумываются, что порождают таким образом сервисы с анемичными доменными моделями, проектируя по сути REST-обертки над базой данных с отсутствием какой-либо бизнес-логики.
API First и Богатая доменная модель не являются взаимоисключающими понятиями, если правильно выстроить процесс и архитектуру.
Главная проблема: API First фокусируется на контрактах внешнего мира, что часто приводит к созданию DTO/Model классов, которые являются чистыми структурами данных без поведения (анемичная модель).
API First — это про контракты, а не про реализацию. Не позволяйте инструментам кодогенерации диктовать структуру вашей доменной модели!
Правильный workflow:
1. API Design First: Создайте/обновите OpenAPI спецификацию.
2. Генерация DTO: Сгенерируйте или создайте классы для API‑контрактов.
3. Projection First: Спроектируйте доменную модель независимо от DTO, фокусируясь на поведении и инвариантах.
4. Создание Mapping Layer: Напишите преобразователи между DTO и Domain Objects.
5. Реализация Application Service: Тонкий слой, который координирует работу домена.
Стек технологий, который помогает:
— MapStruct: Для автоматизации маппинга между DTO и Domain — JUnit 5: Для тестирования доменной логики — OpenAPI Generator: Для автоматической генерации DTO из спецификации — ArchUnit: Для проверки архитектурных правил (например, запрет на анемичные модели)
// ArchUnit тест, проверяющий, что в доменных классах есть поведение
@ArchTest
static final ArchRule domain_models_should_have_business_methods =
classes()
.that().resideInPackage("..domain..")
.and().areAnnotatedWith(Entity.class)
.should().containAnyMethodsThat(
DescribedPredicate.describe(
"have business methods",
method -> !method.getName().startsWith("get") &&
!method.getName().startsWith("set")
)
);
Создатель архитектурного стиля RESTРой Филдинг — считает, что REST-архитектура должна соответствовать пяти обязательным ограничениям. У него довольно жёсткая позиция, что если API не выполняет хотя бы одного ограничения, то это не RESTful API. И тут ничего не поделаешь, как автор идеи считает, так и правильно. Далее я буду говорить, что api REST или не REST именно по Филдингу.
Но шутка в том, что хотя каждый уважающий себя бекендер знает про REST, почти никто не делает RESTful API. Но не потому что это недостижимый идеал, а потому что REST для апи, почти никому не нужен.
В смысле не нужен? А вот так, давайте взглянем на модель зрелости REST сервисов Леонарда Ричардсона. На первом и втором уровне находятся ресурсы и http-глаголы, вещь полезная, я понимаю их пользу и ничего против них не имею. А вот на третьем уровне мы видим hypermedia controls, о котором я бы хотел поговорить подробнее.
Гипермедиа как средство управления состоянием приложения или HATEOAS. Благодаря этому ограничения клиент и сервер могут развиваться независимо друг от друга, а вся необходимая информация о том, что можно делать ресурсом, содержится в ответе этого ресурса. В общем, классический сайт. Мы открываем главную или какую-нибудь другую страницу и переходим между страницами. На страницах есть ссылки на другие страницы и формы для редактирования. Вот что говорит сам автор:
«REST API следует вводить без каких-либо предварительных знаний, кроме начального URI и набора стандартных типов данных. Все переходы состояний приложения должны определяться исходя из представлений или пользовательских манипуляций с ними, полученных клиентом от сервера»
— Рой Филдинг, Архитектурные стили и проектирование сетевых архитектур программного обеспечения.
Для меня это звучит так: вот у нас сайт, соответствующий принципам REST архитектуры, тогда он может отдавать свои ресурсы в разных представлениях — например, в виде html или json. HTML — это обычная веб страница, а json содержит только данные, без визуала. Нетрудно понять, что REST клиент для json представления выглядит не очень привлекательно.
Филдинг предполагал, что сервер может менять контракт как захочет, а клиент сможет его понять на основании гипермедиа. Вы встречали таких клиентов? На самом деле они есть, но про них мало кто знает. На практике в API HATEOAS не нужен ни программисту, ни программному клиенту. Программисту нужно описание контракта, с чем прекрасно справляются OpenAPI/Swagger, желательно автогенерённые из кода. А клиенту нужен четкий контракт, как создать товар или показать ленту. И меньше всего клиент хочет, чтобы контракт менялся, и тем более не хочет поддерживать средства обнаружения и подстройки под изменённый контракт.
В итоге перед программистом встаёт дилемма:
Не делать HATEOAS. Но тогда его апи нельзя называть RESTful.
ДелатьHATEOAS. Но тогда ему нужно будет "напихать ссылок" в ответы своего апи и поддерживать их просто чтобы называться RESTful. При этом, эти ссылки никто не будет использовать.
В итоге мы живём в мире, где бэкенд часто разрабатывают с использованием принципов REST, но при этом почти не существует RESTful апи. А те, что существуют, имеют пародийное название REST-like API или pragmatic REST. А 2-й уровень зрелости REST звучит так, как будто мы остановились на полпути к идеалу. Но ведь это не идеал: 3-й уровень зрелости часто бессмысленен или даже вреден.
На практике, все насколько смирились с ситуацией, что ослабили значение термина и называют api RESTful, даже если оно только частично следует принципам REST.
А было бы круто, если бы кто-то придумал новый, хороший термин для архитектурных практик, которые бы взяли всё лучшее и полезное из REST применительно к современным Web-api. Тогда бы начинающие бэкендеры сразу осваивали актуальные подходы, а не книги Филдинга из 2000-х, как я когда-то.
Как войти в нужную дверь: API-ключ и как с ним работать
API-ключ — это уникальный набор символов, который подтверждает, что запрос к API отправлен авторизованным приложением. Он помогает управлять доступом, считать обращения и защищать данные.
Чтобы использовать API-ключ, нужно:
Получить его в личном кабинете сервиса.
Добавить в запрос — обычно в заголовке Authorization.
Следить за безопасностью: не хранить ключ в коде и регулярно менять.
В Рег.облаке запустили облачные серверы с ИИ-ассистентом
В Рег.облаке стало доступно новое локальное решение для запуска и управления языковыми моделями LLM. Облачный сервис разворачивается за несколько минут и работает в изолированном окружении: данные и доступ полностью контролируются пользователем.
Что входит в образ:
Ollama — фреймворк для запуска и управления LLM-моделями;
Open WebUI — веб-интерфейс для работы через браузер;
предустановленные модели Gemma 3, DeepSeek и Grok, с возможностью подключения моделей из Ollama и Hugging Face.
Основные возможности:
интеграция через API во внутренние сервисы;
подключение документов и баз знаний для контекстных ответов;
параллельный запуск и сравнение нескольких моделей;
плагины Open WebUI для работы с файлами и данными;
работа с конфиденциальной информацией без передачи в публичные сервисы.
ИИ-ассистент доступен в конфигурациях с CPU и GPU. Для работы с несколькими моделями рекомендована конфигурация с NVIDIA A5000 (24 ГБ), 16 vCPU и 64 ГБ RAM. Заказать и протестировать сервер с ИИ-ассистентом можно уже сейчас на сайте Рег.облака.
Работа с Bluetooth Low Energy (BLE):основные протоколы и практические советы.
Почему BLE до сих пор “ТОП”? Потому что даёт годами работать от батарейки -“таблетки”, держит связь в шумной среде и уже давно вышел за рамки «умных браслетов». Ниже - короткая, но практичная шпаргалка: что в BLE за что отвечает, где производительность «прячется», и на чём чаще всего спотыкаются.
BLE-стек делится на две большие части: - GAP - «как знакомимся и подключаемся»: роли Central/Peripheral, сканирование, реклама (advertising) и параметры соединения. - GATT/ATT - «как обмениваемся данными после подключения»: сервисы, характеристики, дескрипторы и операции чтения/записи/уведомлений. (PunchThrough, cardinalpeak.com)
Основное - по делу: 1) Реклама и роли Legacy vs Extended Advertising: в Bluetooth 5 появилась расширенная реклама(Extended) и Periodic Advertising - удобно для «маячинга» и многоприёмников без подключения. (Novel Bits)Роли: Peripheral «светится» и ждёт подключения; Central сканирует и подключается. Это — GAP-уровень. (Punch Through)
2) Скорость, дальность и каналыPHY 1M - базовый; 2M PHY - больше скорость; Coded PHY (S=2/S=8) - для дальности и шумных сред; итоговый выбор - компромисс «скорость/дальность/надёжность». (RIOT Summit) Для широковещания и энергосбережения в BLE 5.4 усилили «витаминку» для ESL/маячков: PAwR (Periodic Advertising with Responses), EAD (Encrypted AdvertisingData) и пр. - полезно для систем с множеством датчиков и электронных ценников. (Bluetooth Technology Website, silabs.com)
3) Пропускная способность: где «лежит» throughputATT MTU и Data Length Extension (DLE) увеличивают полезную нагрузку пакета (вплоть до ~251 байта данных на пакет) — ключ для высокой реальной скорости. (Punch Through, devzone.nordicsemi.com) Настраивайте интервал соединения, slave latency и supervision timeout под задачу: меньше интервал — ниже задержка и выше пропускная способность, но больше расход батареи. Для потоков «почти-реального времени» ориентируйтесь на уведомления (см. ниже) и 2M PHY (если качество радио позволяет). Практические потолки зависят от хоста/ОС — тестируйте на целевых телефонах/ПК. (devzone.nordicsemi.com)
4) GATT-модель и событияNotify vs Indicate: оба «толкают» данные от сервера к клиенту; Indicate требует подтверждения на уровне протокола (надёжно, но медленнее), Notify — без подтверждения (быстрее, меньше оверхеда). Всегда добавляйте CCCD для (де)активации уведомлений. (Сообщество NXP, Thesis Pte Ltd, Reddit)Дизайн GATT: группируйте характеристики логически, минимизируйте количество сервисов и «глубокие» иерархии — это ускоряет discovery и упрощает кросс-платформенное поведение. (cardinalpeak.com)
5) Безопасность и приватностьLE Secure Connections (ECDH) — базовый стандарт для шифрования.Privacy: используйте RPA/Filter Accept List, а в BLE 5.4 — EAD для шифрованной рекламы (актуально для «маячков» с приватными данными). (Bluetooth Technology Website)
6) Мобильные ОС: подводные камниAndroid 12/13+: нужны runtime-разрешения BLUETOOTH_SCAN/CONNECT/ADVERTISE(диалог Nearby devices). Без них сканирование/подключение просто не начнётся.(Android Developers) iOS: в фоне реклама и сканирование ограничены — обычные рекламные PDU из бэкграунда не шлются; для сканирования в фоне задавайте конкретные UUID и включайте соответствующие background-моды. (Stack Overflow, Apple Developer)
7) Стек и инструментыДля «железа»: Zephyr Bluetooth Host (широко применим на MCU), NimBLE (легковесный стек от Apache Mynewt), BlueZ (Linux). Выбор стека влияет на доступность фич (DLE, Coded PHY, Periodic Adv). (docs.zephyrproject.org, Argenox)
8) Новшества, на которые стоит поглядыватьBLE 5.4 (PAwR, EAD) — для массовых устройств-«полок» и защищённой рекламы. (Bluetooth Technology Website) Core 6.0: уточнения по таймингу кадра/интервалам в изохронных потоках (актуально для LE Audio/ISO). Если делаете аудио через BLE — изучите. (Bluetooth Technology Website)
За 5 лет, что я проектирую API, вывела для себя шесть базовых принципов, которых стараюсь придерживаться:
Проектировать для потребителя
Ориентироваться на потребности клиентов API, а не на простоту реализации или устройство базы данных. Об этом, кстати, подробно написано в отличной книге Лоре Арно “Проектирование веб-API”.
Учитывать интересы всех клиентов. Не забывать, что могут появиться новые клиенты.
Сложную логику реализовывать на сервере. Искать баланс между универсальностью API и нагрузкой на клиента, исходя из реалий проекта.
Проектировать понятные API-схемы
Наименования и структуры должны быть максимально прозрачными, ясными и лаконичными.
Избегать обобщающих наименований, типа “flag”. Описывать в названии, какой бизнес-смысл несет этот параметр или метод. Например, флаг с признаком пустой упаковки можно назвать “isEmpty”.
Человек при прочтении схемы должен без дополнительной документации понять, зачем нужен этот API и что он делает.
Отдавать адекватные текстовые коды ошибок, из которых будет однозначно понятно, что поправить в запросе для успешного его выполнения. Например, отдавать не 400 BAD_REQUEST, а 400 PRODUCT_NOT_FOUND.
Принять конвенции и придерживаться их
Использовать везде либо snake_case, либо camelCase, либо kebab-case, не менять правила от метода к методу.
Стандартизировать формат ошибок - во всех методах отдавать их в одинаковой структуре.
Если это HTTP, то зафиксировать, в каких случаях какие коды ответов будут возвращаться. Например, иногда возвращается всегда 200, а потребители ориентируются только на тело ответа.
Договориться о формате версионирования API.
Стандартизировать типы данных: формат дат, UUID и пр.
Думать о безопасности, производительности и надежности
Использовать аутентификацию, авторизацию и ACL. Разграничивать доступ на уровне конкретных методов и даже параметров.
Сначала писать документацию, а только потом разрабатывать. Такой подход минимизирует количество ошибок и проблем с API.
Помечать изменения тегами задач и, при необходимости, цветом.
Описывать логику работы методов/топиков/очередей. При необходимости добавлять диаграммы последовательности и маппинги данных.
Мониторить и анализировать
Понимать, какие методы как часто вызываются и как быстро работают. Как быстро обрабатываются сообщения в очередях и топиках, какое их количество и размеры. Это важно для принятия решений о дальнейших доработках API.
Смотреть в консоли разработчика на проде, как быстро отрабатывают те или иные запросы и т.д.
По возможности настраивать системы мониторинга и алертинга. Это помогает прогнозировать рост нагрузки и отслеживать эффективность системы.
У каждого API‑проектировщика со временем появляется свой набор правил. Было бы интересно сравнить — добавляйте свои пункты в комментариях.
Другие мои материалы можно почитать в телеграм-канале breakfront.
Привет, Хабр! Попробуйте решить задачу. Особенно интересно будет бэкенд-разработчикам, которые работают с микросервисной архитектурой и регулярно сталкиваются с неожиданным поведением инфраструктуры.
Условие
В компании «Доки.Онлайн» выкатили обновление: теперь пользователи могут загружать PDF-файлы с отсканированными договорами. Все работало отлично в локальной среде — разработчик протестировал загрузку больших файлов, убедился, что API обрабатывает их корректно, и спокойно отправил изменения в продакшн.
Но радость была недолгой. На боевом сервере при попытке загрузить файл система выдавала ошибку 413 Request Entity Too Large. Причем происходило это до того, как пользователь получал какой-либо отклик от самого приложения.
Разработчик Геннадий Завров начал искать причину. Он проверил логи всех четырех компонентов системы:
фронтенда;
API Gateway (определяет, в какой микросервис послать запрос);
микросервиса загрузки файлов;
микросервиса обработки документов.
Во всех логах пусто, будто никакого запроса и не было. Ни один сервис даже не попытался начать обработку файла.
Геннадий начал подозревать сетевые сбои, перегрузку API Gateway и баг в коде фронтенда. Однако простые тесты с маленькими файлами работали стабильно. Проблема проявлялась только при загрузке чего-то «потяжелее».
В какой-то момент он задал себе вопрос: а точно ли запрос доходит до приложений?
Задача
Почему при загрузке большого файла система возвращает ошибку 413, если сами сервисы даже не видят входящий запрос? Кто может остановить запрос еще до бэкенда?
Делитесь своим ответом в комментариях. А посмотреть полное решение можно в Академии Selectel.
Как устроен ваш цикл разработки приложений? Проверяются ли API на наличие уязвимостей до их публикации? И есть ли вообще для этого процесса какая-то методология?
Вместе с экспертом команды Вебмониторэкс, участвующим в совместной работе с ИСП РАН, подробно разберём, как выстроить эффективный процесс тестирования API, и чем отличаются различные его виды.
Когда? 23 апреля в 14:00
Спикер: Динко Димитров, руководитель продуктового направления, Вебмониторэкс
REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль взаимодействия между клиентом и сервером через HTTP. Он определяет принципы построения API, обеспечивая стандартизированный и эффективный обмен данными между различными системами.
GET-запросы не должны что-то сохранять, удалять или изменять. Нельзя менять какие-либо данные на стороне сервера при GET-запросе. Почему? GET-запросы часто кешируются на стороне клиента.
POST запросы для загрузки/создания сущностей, PUT для изменения в сущности, а PATCH - для мелких изменений в сущности.
Наименование эндпоинтов. Должен присутствовать единый стиль, и желательно во множественном числе, ибо это более лаконичнее. Например, эндпоинт /users. Можно и единственное число использовать, но обосновано.
Иерархия. Нужно соблюдать единую иерархию для построения запросов. Конструкции /users/1/friends/3/items/4 будет неудобно использовать разработчикам клиентских приложений. Нужно избегать такую иерархию, нужно конкретно указывать что нам нужно, не перезагружать данными.
Соблюдайте версионирование API. Допустим: /api/v1/get_all_users и /api/v2/get_all_users. При выходе новой версии не всегда разработчики готовы переписать логику клиентских приложений, и для этого нам нужно разделять версии API
Чувствительные данные. Очень важный момент. Например, передача различных паролей в Query-параметрах запрещено, только в теле запроса.
Из 6 вытекает 7е правило: не логируйте персональные и прочие секретные данные. Было несколько случаев, когда из-за логирования параметров утекали данные пользователей.
Расширение ответов. Во-первых, не передавайте массивы в самом верхнем уровне ответа. JSON-ответ от сервера не должен быть массивом, только словарь (ключ-значение). Если мы будем возвращать список, в будущем нам будет неудобно расширить ответ сервера, добавив дополнительные параметры. А также иногда в API разработчики делают обязательные параметры, например помимо самих данных параметр success и error, чтобы клиентское приложение могло понять, что произошла ошибка, или наоборот, успешно выполнилось.
Работа с датой и временем. Есть два метода - использование Unix Timestamp (количество секунд прошедших с 1 января 1970 года). Это в какой-то степени более удобно для машины, но менее удобно для клиентского разработчика. И второй метод как раз делает формат даты и времени более понятным - это ISO 8601 (2025-04-05T12:00:00.100Z). Этот метод более удобный, т.к. мы понимаем дату и часовой пояс, точное время.
Бонусное правило, лично мое. Относится не только к REST API, но и в принципе к программированию. Пишите код так, как будто эта поэма, книга. Попробуйте сами поработать со своим API, будто вы его не писали. Разделение ответственности, единая точка отказа, Don't Repeat Yourself и даже Keep It Simple, Stupid. Все это конечно-же вариативно.
[RFC] Открытый формат обмена данными об условиях кешбэка COIN
Многие банки и финансовые организации предлагают своим клиентам программы лояльности и/или кешбэк, тем самым повышая интерес к своим банковским/финансовым продуктам и поощряя клиентов за совершение покупок/оплату услуг. К сожалению нет определённого стандарта представления подробной информации об условиях, которые необходимо выполнить для получения вознаграждения/кешбэка (например, количество или общая сумма покупок или определение принадлежности торговой точки к той или иной категории (например, фастфуд или рестораны)).
Необходимо разработать и согласовать специальный общий и открытый формат обмена данными об условиях кешбэка и программ лояльности банков и финансовых организаций, который могли бы использовать как сами банки и финансовые организации, а также их клиенты и другие компании, которые могли бы разработать дополнительные сервисы по обработке и представлению данных об условиях кешбэка в удобном, доступном и наглядном виде.
Предлагаемое название для подобного формата "COIN" (Cashback (details) Open Interchange - открытый обмен данными о кешбэке).
В качестве формата хранения данных предлагается JSON. Прототип формата опубликован в репозитории.
Демо-сервис базовых возможностей использования формата COIN Кашевар-онлайн
Приглашаю вас на весеннюю сессию вебинаров! Мы подготовили много экспертного контента и готовы поделиться с вами актуальной информацией о текущем состоянии и развитии рынка, а также современными подходами к защите веб-приложений и API.
Основные темы вебинаров:
• Защита веб-приложений (WAF)
• Защита интеграций между сервисами (API Security)
• Тренды развития рынка защиты веба
• Безопасная разработка
Для кого:
CISO
ИБ-специалисты
ИТ-специалисты
DevOps
Приготовьтесь к морю полезной информации, лучшим практикам и встрече с ведущими экспертами отрасли. Мы расставим все точки над «и».
Вы можете зарегистрироваться как на всю сессию сразу, так и на любой отдельный вебинар.
Теперь при заказе конфига можно тут же сгенерировать команду для инструмента автоматизации, — Terraform, cURL или twc-cli. Вот краткий обзор каждого из них:
Terraform. Помогает быстро разворачивать серверы, сети и управляемые сервисы в облаке.
сURL. Утилита для управления ресурсами в облаке через API с помощью HTTP-запросов.
twc-cli. Через терминал создает виртуалки, настраивает сети, кластеры и базы данных.
Чтобы сгенерировать команду, просто нажмите на кнопку рядом с «Заказать» → выберите один из способов автоматизации → скопируйте и вставьте команду в терминал или в файл.
Новая фича пока доступна только для виртуалок, но скоро раскатаем и на остальные облачные сервисы.
Как мы сокращали количество запросов по фичам в API
Контекст: я отвечаю за разработку конструктора Telegram-приложений. Начинались мы как конструктор кликеров (еще до хомяка). Со временем эволюционировали в конструктор курсов, сообществ, визиток, мероприятий и любых других приложений
Одна из основных сущностей в коде — это BotUser. То есть пользователь, который появился в приложении (зашёл хотя бы раз), имеет имя и Telegram ID
За ~полгода проекта у нас добавилось много фич, привязанных к пользователю. Практически все сопоставляются 1 к 1 по ключу User ID. Например, квизы, бонусные дни, купленные страницы, купленный карточки апгрейдов, тариф и т.д.
Раньше для каждой новой фичи мы добавляли новый запрос в API с фронтенда. И вот мы заметили, что на каждый заход пользователя стало уходить >10 запросов в API ⚠️.
Примерно вот так:
GET /users/user
// Response
{
"tgUsername": ...,
"tgId": ...,
...
}
GET /users/features/quizzes/completed
// Response
{
"completedQuizzes": ...,
}
GET /users/features/pages/bought
// Response
{
"boughtPages": ...,
}
GET /users/features/rates/rate
// Response
{
"userRate": ...,
}
При этом, на каждый запрос мы проверяли авторизацию. В Telegram это делается с помощью хеша от Telegram + проверка подписи токеном бота
Следовательно, на каждый запрос мы делали JOIN пользователя, брали бота (сущность Bot) из кэша и мэтчили подпись (+ логгировали). Это лишняя нагрузка
Сейчас подсобрали все фичи в один запрос. Теперь, на каждый заход пользователя получается только один GET /app/account/data, который возвращает данные пользователя вместе с данными фичей:
не подгружаем связанные сущности, где не нужно (one-to-one, one-to-many);
если подгружаем сущности, всегда делаем это одним JOIN'ом (а не бегаем по 2-3 раза в БД, как любит делать Hibernate);
берём общие часто запрашиваемые данные из кэшей.
Это позволило снизить нагрузку на сервер и БД. К посту прикрепляю график загрузки части наших серверов по CPU до и после оптимизации.
---
Если вам понравился пост или оказался полезным, поставьте, пожалуйста лайк ❤️. Это мотивирует делиться опытом из разработки. И, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами.
Наша линейка продуктов ПроAPI, основанная на собственной концепции к управлению и защите API, уже успела себя хорошо зарекомендовать. Однако задача ИБ-специалистов – постоянно быть на шаг впереди злоумышленников. Сегодня у нас есть идеи, как усилить безопасность и противостоять новым вызовам, мы хотели бы узнать ваше мнение относительно их.
По ссылке ниже мы предлагаем пройти небольшой опрос, который займет не более 10 минут. https://t.me/wmx_xdrbot
Мы благодарны каждому, кто найдет время ответить на наши вопросы. В конце анкеты обязательно укажите, как с вами связаться, чтобы мы смогли отправить небольшой подарок.
Разработчикам мобильных и WEB-приложений (и не только) весьма и весьма пригодится готовая коллекция для Postman. В коллекцию добавлены endpoint для REST API Joomla, с параметрами и примерами запросов.
Коллекция составлена трудами французского Joomla-разработчика Alexandre J-S William ELISÉ.
Я очень радовался 14.08.2024 из‑за выхода очередного релиза Телеграм, в котором они анонсировали подписки за звезды, потому что это сильно облегчало мое взаимодействие с клиентами: они один раз подписываются и далее не имеют проблем с повторными платежами, вместо этого звезды тихонько списываются у них с счетов. В этом посте я расскажу, как прикрутил подписку в звездах к своей Telegram Mini App (TMA).
Вот как выглядит глазами клиентов списание звезд в пользу вашей аппы. Заметьте, никаких предупреждающих писем, как у Stripe, например.
При каждом снятии звезд клиент получает подобное сообщение
Свои подписки можно посмотреть у себя в профиле. Это выглядит так:
Для получения подтверждения оплаты счета вам нужно добавить в ваш webhook (allowed_updates) подписку на pre_checkout_query. После этого вы начнете получать update c данным полем и структурой.
Когда вы получаете такой апдейт, вам нужно отреагировать на него в течение 10 секунд: принимаете или отклоняете (например, если этот счет уже был оплачен и другие краевые условия).
Данная структура также позволяет вам понять, что было оплачено в рамках счета, путем чтения поля payload (которое было записано при создании счета).
На мое удивление сообщение об оплате встроено в существующий объект Message, так что не нужно дополнительно подписываться на новые источники данных. Вместо этого, мы просматриваем все message в поисках поля successful_payment или refunded_payment и записываем в статистику (для возможного возврата в том числе).
Обратите внимание! В структуре SuccessfulPayment есть параметр is_first_recurring, и я думал, что он True для первого платежа подписки и False для последующих, но! в последующих его просто нет (это допустимо, так как это необязательный параметр).
На этом все, как только вы начали получать successful_payment, вам не нужно больше делать ничего, чтобы клиент продлил подписку.
P.S. Вы всегда можете обновлять срок подписки при получении данного сообщения, читая поле subscription_expiration_date. Если successful_payment перестал приходить, то и подписка не обновится.
Ваш Дима из TG Defender, защита вашего Telegram канала от наплыва ботов на стиле.
Привет,Хабровчане ! Неожиданно решился на создание этой публикации – пусть она окажется полезной для кого-то из вас. Представьте ситуацию: рабочий день позади, включаем компьютер, запускаем музыкальное сопровождение и... прямо в кресле дивана нас уже сморит Морфей. Пробуждение же наполняет осознанием неразрешимой дилеммы – выключить ПК или переключить трек? Особенно когда репертуар оставляет желать лучшего!
Вот и приходится преодолевать себя, чтобы добраться до компьютера.
Так вот, в качестве решения этой проблемы разрабатываю приложение для Android с небольшим сервером на PC (начало только под Windows).
Основной фишкой станет регулировка яркости экранов, удаленное отключение ПК, переключение треков в плеере.
Телефонное приложение будет максимально чистым: без рекламы, подписок или дополнительных платежей.
Я – инженер(технарь), а не профессиональный программист, так что обещаю уделять больше внимания техническим моментам .
Все будет сделано в меру моих умений и возможностей. Благодарен за внимание! По мере продвижения работы буду дополнять этот пост новыми деталями.
А какого функционала не хватает вам ?
Пока все в стиле демо
Сделал ещё несколько дэмок . 2 приложения на kivymd (python3) связь с сервером http запросами ,но вес приложения уменьшить не удалось . Попробовал на flutter спасибо Гуглу ,ии и другу разработчику ,связь. с сервером с помощью протокола mqtt.
