Создать электронный словарь терминов (маленькую базу данных)

Разработчик Odoo (Odoo 19 CE) Ищем соло-разработчика с реальным опытом для развития продукта (CRM/HMS в гостиничной сфере). У нас есть четко описанное техническое задание (ТЗ) и готовые базовые технические наработки. Все процессы структурированы, так что вы заходите на понятную и подготовленную техническую базу. ? Стек: Odoo 19 CE • Python • PostgreSQL • Docker • OCA. ? Основные задачи: Развитие продукта и реализация новых функций по ТЗ. Настройка интеграций и автоматизация процессов. ? Наши ожидания: Практический опыт работы с Odoo. Разработка исключительно через механизмы наследования (без правок ядра). Соблюдение принципов Pure Odoo и OCA First. ? Условия: Формат: Частичная занятость или проектная работа. Локация: Удаленно. Прозрачность: Быстрый старт — сразу после короткого знакомства открываем доступ к ТЗ и репозиторию. Если вас заинтересовала позиция, сразу просим предоставить развернутые ответы на такие вопросы: 1. Работаете ли вы с Odoo? 2. Есть ли у вас реальные проекты, которые вы можете показать в портфолио? Какие именно проекты или отдельные модули вы реализовали самостоятельно? 3. Есть ли успешные внедрения систем — CRM, чатов и т.д., в которых вы принимали участие? 4. Готовы ли вы работать с уже существующим проектом, поддерживать и развивать действующую CRM-систему с чатами, а не создавать все с нуля? 5. Какова ваша ставка или тариф: почасово или за проект?

Необходимо разработать локальный 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 (или отдельную таблицу в БД). Строгое табу: В аудит-лог категорически запрещено записывать сами значения секретов (ни в открытом, ни в зашифрованном виде).

Нужен специалист для написания парсеров, который сможет обходить CLOUDFRAME. Парсинг товаров происходит с сайтов с авторизацией. Есть 10+ доноров различной сложности, с разной степенью защиты. Парсинг товаров происходит с сайтов с авторизацией. Парсит данные в готовую базу данных Mysql + фотографии на сервер. Необходимо написать парсер в соответствии с задачами, описанными в техническом задании, и адаптировать данные к существующей базе данных для полноценной работы на сайте. ТЗ и пример донора по запросу. Десктопные парсеры и C# не рассматриваем.

Бот для зеркалирования позиций на Binance Futures (Python) Нужен бот, который читает мои позиции на Hyperliquid (публичный API) и Bitget Futures (мой ключ read-only) и пропорционально повторяет их на моем Binance USDT-M Futures через API. Логика: открытие, увеличение, частичное закрытие, полное закрытие — все зеркалится с настраиваемым коэффициентом размера. Поллинг 5–10 сек. Обязательная корректная обработка частичных закрытий и усреднений. Требования: уведомления в Telegram о сделках и ошибках; конфиг (пары, коэффициент, лимиты); деплой на мой VPS + инструкция; исходный код передается мне. Ключи ввожу сам. Этапы: 1) Hyperliquid→Binance, тест на малых суммах; 2) Bitget→Binance. Оплата через safe поэтапно. В отзыве укажите опыт с API бирж и как обработите частичное закрытие 30% позиции лидером