Дослідження блокчейн технологій для забезпечення цілісності даних IT

Загальна інформація: Є Telegram-бот, написаний на Python (aiogram v3, aiohttp, MySQL, Redis). Це сервіс для взаємодії замовників та виконавців (профілі, проекти тощо). Необхідні навички: - Впевнений досвід з aiogram v3 (не v2!), asyncio, aiohttp; - Знання Telegram Bot API (вебхуки); - Досвід роботи з MySQL, Redis; - Уміння розбиратися в чужому коді; - Комунікабельність, відповідальність. Мені потрібно на поточній версії бота прямо на сервері виправити баг-проблему Проблема полягає в тому: Не функціонують повноцінно чати (Нори), має бути чистильник, який буде працювати за алгоритмом, але зараз він працює з багами, чистить не за графіком - Чат між замовником потрібен для обговорення з виконавцем робочих моментів. - Чати (нори вже всі створені, потрібно, щоб їх чистило і ставило в чергу - Юзер бот створює чати (парні нори, вони у нас вже є) і ставить їх в чергу, якщо в чаті здійснена угода, співрозмовники в ньому знаходяться (в одному чаті виконавець, в іншому чаті замовник); якщо ж чат закритий або там не було здійснено угоду і користувачі там не писали протягом 7 днів; бот видаляє звідти замовників або виконавців і ставить цей чат (нору) назад в чергу - Замовник може перейти в чат з будь-яким виконавцем, який відгукнувся на замовлення - Замовник і виконавець знаходяться в двох паралельних чатах, щоб не було можливості бачити прямий аккаунт співрозмовника і не було можливості йому написати напряму * Роботу чатів і все інше не змінюємо Головне, щоб виправлення не потягнуло за собою інших проблем

Система авто-сповіщень про поповнення складу аналітика. На 8n8. Невелика автоматизація для e-commerce. Раз на добу система рахує швидкість продажів по кожному товару й надсилає в Telegram, що пора замовляти (з рекомендованим обсягом) і на скільки днів вистачає залишку. Що робимо: Забір даних: KeyCRM API (історія замовлень) + залишки/замовлення з Rozetka (API або вивантаження) Зберігання в SQLite на моєму VPS (Contabo, Linux) Розрахунок середнього продажу, запасу в днях, точки замовлення ABC-аналіз: пріоритезація, який товар поповнювати першим (клас A — головні за виручкою — важливіші) Щоденний Telegram-бот + запуск по cron Усі пороги (термін постачання, страховий запас, цільовий запас) — у конфізі

Вітаю! Мені потрібно візуально кастомізувати систему InvenTree (open-source) для презентації проекту кав'ярні. Складний бекенд і інтеграція з касою (POS) не потрібні — важлива зовнішня переробка інтерфейсу, щоб показати різницю «Було / Стало». Стек проекту: Python (Django) + React (Mantine UI). Що потрібно зробити в інтерфейсі: Кастомний брендинг, Перейменування в боковому меню та таблицях, Очищення форм від інженерних полів, Налаштувати один рецепт «збирання» напою (наприклад, Капучино), щоб при ручному списанні зі складу наочно вираховувалися всі інгредієнти, додати функції у вигляді додаткових звітів, і пояснення принципів роботи зроблених змін. Всі конкретні деталі обговоримо особисто. Вимоги до виконавця: Досвід роботи з Django та React (Mantine UI). Здатність виконати завдання швидко — проект потрібен для презентації. Працюємо через Сейф (Безпечну угоду). У відповіді почніть зі слова «КАВА», щоб я бачив, що ви дочитали до кінця. Напишіть ваші терміни та ціну

Потрібно внести невелику правку в програму, яка формує замовлення для друку. Завдання: Ми додали в асортиментм'яке скло з принтом. У замовленнях назва принта буде виділена символами#...# для коректного розпізнавання. Приклад: Мяке скло, #Абстракція біла# 2.0mm, Форма: Прямокутник... Необхідно: якщо в тексті замовлення присутній фрагмент між символами#...#, програма повинна розпізнати його як замовлення з принтом; при формуванні PDF або аркуша для друку таке замовлення потрібновиділити окремим кольором (будь-яким помітним, узгодимо під час виконання); решта логіки роботи програми має залишитися без змін. Приклад замовлення додаю нижче для тестування.

Проект: Ми запускаємо 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 розглядатися не будуть.