Написать на Python скрипты для свапов на dex в сети L1

Разрабатываем real-time интеграцию с внешним сервисом Тренер. Отправляем структурированные снимки состояния, получаем рекомендации и показываем их всплывающим пузырём. Задача — стабильная и полная передача данных для корректной работы Тренера. Ищем разработчика для цепочки: обработка данных → HTTP-коммуникация → overlay. Нужны люди с такими навыками Python хорошо, Java база, API HTTP/JSON-APIs Проект готовый на 90% но есть некоторые несотыковки

Коротко Нужна программа на Python, которая запускается у меня на ПК (Windows) и делает faceless-видео формата «закадровый голос + сменяющийся видеоряд из фото и клипов» — как исторические документалки на YouTube (пример прикреплю отдельно). Я ввожу тему → программа пишет сценарий, озвучивает, подбирает под каждый кусок текста видео/фото из бесплатных архивов, склеивает → выдаёт готовый MP4. Только для меня. Без сайта, без пользователей, без продажи. Один пользователь — я. Как работает (по шагам) 1. Ввод. Открывается простое окно. Я ввожу тему ролика и выбираю голос озвучки из списка (**список голосов подтягивается автоматически из ElevenLabs по API** — доступные на моём аккаунте). Жму «Создать». (Второй режим: вставить готовый сценарий вместо генерации.) 2. Сценарий. Программа через LLM API (OpenAI/Anthropic, ключ в настройках) пишет сценарий по теме, заданной длины. 3. Разбивка на сцены. LLM делит сценарий на сцены и для каждой возвращает: текст сцены; тип визуала: видео или фото; поисковый запрос (развёрнутая фраза, что должно быть в кадре); пометку «highlight» + оценку важности 1-10 (для интро, см. ниже). 4. Озвучка. Текст отправляется в ElevenLabs API выбранным голосом → аудио. Под длину аудио каждой сцены режется видеоряд. 5. Подбор видео/фото — из бесплатных источников по API (см. список ниже). Под каждый источник запрос формируется по-своему (для точности). Если в одном не нашлось — пробует следующий. 6. Проверка (максимум 3 шага на сцену). Шаг 1: программа берёт первый найденный вариант (видео/фото) по запросу. Шаг 2: отправляет кадр в LLM — «подходит под сцену?». Подходит → стоп. Шаг 3 (если не подходит): программа переключается на поиск фото (по точному запросу фото найти проще, чем видео, — так гарантированно попадаем по смыслу) и берёт его с усиленным движением (зум + панорама). Больше 3 шагов на одну сцену не делать — это экономит бюджет LLM и гарантирует, что кадр в тему. 7. Сборка через ffmpeg/moviepy: клипы и фото под тайминг озвучки, фото оживляются зумом (эффект Кена Бёрнса), голос поверх, простые переходы. Выход: MP4 1920×1080. Правила видеоряда (важно — за это отвечает программа) Первые 60 секунд — интро-тизер: нарезка самых эффектных клипов из всего ролика (берутся сцены с высшей оценкой важности, где есть видео) под отдельный текст-вступление от LLM («в этом видео вы узнаете…»), кадры без пояснений, как интрига. Потом переход и основная часть. Чередование: видео-вставка минимум каждые ~6 секунд, нельзя много фото подряд. Доля видео: не меньше ~40% времени — живые клипы, остальное — фото с зумом. Длина кадра: 4-6 секунд (и фото, и видео). Не мельтешить, не держать статику долго. Для чисто исторических тем, где видео нет — фото с усиленным движением (зум + панорама). Источники (все бесплатные, с API) Современное видео+фото: Pexels, Pixabay. Историческое / архивное (public domain): Wikimedia Commons, Archive.org,Library of Congress, Europeana, NASA, Smithsonian Open Access,Flickr Commons, openverse. Каждый источник — отдельный модуль, легко добавить новый. Использовать только public domain / свободные лицензии с правом коммерческого использования. Никакого парсинга чужих YouTube/сайтов, кусков фильмов, картинок «из гугла».Уникальность подбора Чтобы видео не совпадали с чужими: брать случайный клип из топ-выдачи (не первый), вести базу уже использованных (не повторять), опционально — лёгкая обработка клипа (кроп/зеркало/ скорость). Опции (вкл/выкл в настройках) Субтитры (вшить или отдельным .srt). Фоновая музыка. Обработка клипов для уникальности. Разрешение/формат, длина видео, доля видео, глубина поиска.Технические требования Python. Модульная структура (источники и LLM — через сменные модули, чтобы легко заменить или добавить). Все API-ключи — в файле настроек, не в коде. Простое окно (GUI на выбор исполнителя — Tkinter/PyQt), запуск двойным кликом. README с инструкцией, понятные логи, комментарии в коде.Что даю я API-ключи (ElevenLabs, LLM, где нужна регистрация — оформлю). Платное оплачиваю сам. Примеры видео-референсов (прикреплю) и примеры тем для тестов.Приёмка (готово, если) Запускаю → окно → ввожу тему, выбираю голос → «Создать» → получаю готовый MP4. Видеоряд по смыслу текста, чередование видео/фото, интро-тизер 60 сек, озвучка поверх. Работает минимум с 6 бесплатными источниками, с fallback между ними. Проверка кадров через LLM: макс. 3 шага на сцену (нашли → LLM проверил → если нет, фото с движением как верняк). Уникальность: рандомизация + база использованного. Только легальные источники. Есть README, запускается с нуля.Передача результата Весь исходный код — в открытом виде (все файлы), без обфускации + собранная рабочая версия. Я могу сам запустить из исходников по инструкции (README: установка, ключи, запуск). Код должен быть чистым, прокомментированным и понятным, чтобы **любой другой программист мог продолжить работу** над ним, если понадобится (не привязка к автору). Все права на код после оплаты — мои.Управление местом на диске (важно) Программа не должна забивать диск. Реализовать: После сборки видео все промежуточные файлы (скачанные клипы, временные куски, аудио-нарезки) автоматически удаляются — на диске остаётся только готовый MP4. Лимит на кэш (параметр в настройках, напр. 5 ГБ): при превышении старые скачанные файлы удаляются автоматически (сначала самые старые). Папку для готовых видео и для временных файлов я задаю в настройках. Показывать, сколько места занято, и кнопка «очистить кэш» вручную.Прошу указать в отклике Примеры похожих работ (ffmpeg/moviepy, работа со стоковыми/архивными API, ElevenLabs/LLM). Предложение по GUI. Использует ли решение базу данных (какую и зачем) — или хватает локальных файлов. Срок и стоимость.

О проекте: Мы запускаем B2B-сервис сквозной аналитики и управления рекламными кампаниями для таргетологов и медиабаеров. Продукт будет работать с официальным Meta API. Главная техническая сложность и фокус проекта — виртуозная работа с лимитами Facebook, маршрутизация трафика между пулом наших приложений и жесткая система защиты инфраструктуры от блокировок серых рекламных аккаунтов. У нас уже есть подробное техническое задание, описана архитектура баз данных, логика балансировщика и требования к интерфейсам. Ищем исполнителя, который возьмет это в реализацию под ключ (бэкенд + фронтенд дашбордов). Что предстоит сделать (Ключевые задачи): Интеграция с Meta API: Настроить авторизацию пользователей и регулярный асинхронный парсинг статистики рекламных кабинетов. Запросы должны отправляться исключительно пакетами для экономии лимитов. Система авто-отвязки кабинетов: Написать модуль, который непрерывно мониторит статусы рекламных аккаунтов. Если кабинет улетает в бан, система должна автоматически отозвать токен доступа в течение 60 секунд, чтобы защитить наше приложение от санкций Meta. Инфраструктура прокси: Реализовать туннелирование всех запросов к API через пул SOCKS5. Обязательна жесткая привязка конкретного токена пользователя к статичному IP-адресу. Умная маршрутизация: Создать алгоритм, который будет распределять привязываемые рекламные кабинеты между несколькими нашими приложениями Facebook в заданных пропорциях для снижения рисков. Разработка интерфейсов: Создать клиентский дашборд со сводной таблицей статистики и продвинутую админ-панель для ручного управления лимитами пользователей, привязками к приложениям и пулом прокси. Ожидаемый стек технологий: Бэкенд: Python, FastAPI. Асинхронные задачи: Celery, Redis. Базы данных: PostgreSQL (или ClickHouse для статистики, на ваше усмотрение). Фронтенд: Vue.js или React (можно использовать готовые UI-библиотеки и шаблоны дашбордов, упор на функциональность, а не сложный дизайн). Требования к исполнителю: Уверенный опыт работы с Meta Graph API и Marketing API. Вы должны понимать, как работают скользящие лимиты, как читать заголовки загруженности и как работать с токенами. Понимание специфики арбитража трафика. Слова «биллинг», «бан рекламного кабинета», «бизнес-менеджер» и «фарм» не должны вызывать у вас вопросов. Опыт построения асинхронных парсеров и работы с прокси-серверами на уровне сетевых запросов. Готовность работать по четкому техническому заданию и сдавать проект поэтапно. Условия: Формат сотрудничества: Проектная работа (с возможностью перехода на долгосрочную поддержку и доработку новых модулей). Бюджет: Обсуждается индивидуально на основе вашей оценки технического задания. Оплата: Поэтапная, привязанная к контрольным точкам. Как откликнуться: В сопроводительном письме обязательно укажите ваш опыт работы с Meta API, прикрепите ссылки на похожие проекты (или опишите их функционал, если они под NDA) и напишите ориентировочную вилку цен и сроков на разработку подобной системы с нуля. Отклики без описания релевантного опыта работы с Facebook API рассматриваться не будут.

Необходимо разработать локальный Python-скрипт для автоматического заполнения Google Таблицы данными из внутреннего сервиса компании. Основная логика: 1. Подключиться к Google Таблице. 2. Найти строки, где заполнен ID, но отсутствуют два целевых значения. 3. Сформировать ссылку по шаблону: https://internal-service.example/item/{ID} 4. Получить два значения (через API, если он существует, иначе через Playwright). 5. Записать значения обратно в Google Таблицу. 6. Отметить строку как обработанную. 7. Продолжить обработку следующих строк. Требования: • Python • Google Sheets API • Приоритет использования официального API • При отсутствии API — Playwright • Без OCR, распознавания экрана и координат мыши • Конфиденциальные данные не должны попадать в логи • Конфигурация через .env • Тестовый режим (без записи в таблицу) • Не обрабатывать уже заполненные строки • Пакетная запись изменений в Google Sheets • Корректная обработка ошибок и повторных попыток Необходимо предоставить: - исходный код; - requirements.txt; - пример .env.example; - инструкцию по установке; - инструкцию по запуску; - краткое описание архитектуры. Перед началом реализации прошу: 1. Предложить архитектуру. 2. Перечислить необходимые доступы. 3. Задать уточняющие вопросы. 4. Указать стоимость, сроки и ориентировочное количество часов.

В рамках повышения уровня кибербезопасности нашей инфраструктуры нам необходимо отказаться от практики хранения «вечных» и статичных API-ключей, паролей и токенов интеграций в конфигурационных файлах (.env, appsettings.json, config.yaml) наших микросервисов. Бизнес-цель: Создать единую защищенную точку хранения конфиденциальных данных (секретов) с механизмом их автоматического обновления (ротации) во внешних системах по расписанию. Другие наши сервисы будут запрашивать актуальные токены «на лету» через API, что сведет к минимуму ущерб в случае компрометации любого из компонентов системы.Модель безопасности и шифрование (Crypto Core) В базе данных ни один секрет не должен храниться в открытом виде. При старте приложения в переменные окружения передается Мастер-ключ (Master Key). Если ключ отсутствует или имеет невалидную длину, сервис должен падать на этапе инициализации с понятной ошибкой в логах. Каждый секрет шифруется перед записью в БД с использованием этого Мастер-ключа. При запросе — расшифровывается в памяти и отдается в теле ответа.Аудит-логирование (Audit Trail) Любое действие с секретами (создание, чтение сервисом, успешная или неуспешная ротация) должно записываться в отдельный лог-файл audit.log (или отдельную таблицу в БД). Строгое табу: В аудит-лог категорически запрещено записывать сами значения секретов (ни в открытом, ни в зашифрованном виде).