Бюджет: 2000 UAH Срок: 4 дня
Готов обсудить подробности.
Задача интересная, с удовольствием взялся бы за ее выполнение.
Буду ждать Вас сообщение.
Ми вирішили створити власну соціальну мережу для студентів. Створена для цього інформаційна система містить інформацію про людей, їх стіну із повідомленнями та «лайками» цих дописів. Типовими для ІС є запити: • Виведіть допис, що тримав найбільшу кількість лайків. • Виведіть всі дописи, що написав користувач Х (Наприклад, Іванов І.І.) • Список топ 3 користувачів за кількістю лайків дописів на їх стіні. На етапі проектування були сформульовані наступні вимоги до ІС: користувач може писати дописи лише на своїй стіні. Забезпечте виконання цих бізнес-вимог. Розширене завдання В процесі впровадження ІС з’ясувалися наступні особливості: користувачі із задоволенням репостять записи інших людей. Існують навіть репости репостів. Можна лайкати репости. При цьому лайки зараховуються як автору так і репостеру. Для організації колективних сторінок додана можливість публікувати дописи на чужій стіні. Лайки при цьому зараховуються автору допису. Створіть сценарій міграції з прототипу на оновлену версію. Які зміни треба зробити у запитах з базового завдання? Створіть запити, які дадуть відповіді на наступні питання: • Імена користувачів, що публікували дописи на стіні користувача Х (наприклад, Іванов І.І.) • «Автор року» Користувач, який зробив найбільше дописів за рік (репости не враховуються). • «Бот» - користувач, який робить репости, але не робить дописи. Знайдіть «бота» який зібрав найбільшу кількість лайків. • Створіть рейтинг користувачів за показником "кількість лайків" / "кількість дописів " 17 Проаналізуйте план виконання одного з запитів
Бюджет: 2000 UAH Срок: 4 дня
Готов обсудить подробности.
Задача интересная, с удовольствием взялся бы за ее выполнение.
Буду ждать Вас сообщение.
Бюджет: 2000 UAH Срок: 4 дня
Здравствуйте. Могу реализовать такую систему. Имею опыт реализации подобных задач. Готов обсудить детали. Буду рад сотрудничеству.
Есть действующая production-платформа с каталогом и автоматическим обновлением внешних предложений и цен. Стек: — Node.js / TypeScript; — PostgreSQL; — существующий price refresh service и cron; — отдельный готовый Python-модуль валидации и выбора предложений; — staging и production. Необходимо точечно доработать существующий price refresh pipeline без полного переписывания backend. ОБЯЗАТЕЛЬНЫЙ SCOPE 1. Интеграция Python-модуля — Python-модуль остаётся отдельным компонентом; — возвращает структурированный результат: offers, selected offer, statuses и risk flags; — Node.js валидирует результат и выполняет запись в БД; — предусмотреть обработку ошибок и partial/failed runs; — legacy pipeline не отключается до завершения QA. 2. Запуск refresh по списку Добавить запуск: — по одному slug/id; — по переданному списку slug/id. Допустим CLI или существующий служебный API. Новый пользовательский интерфейс не требуется. 3. Shadow Mode Новые результаты должны записываться отдельно и не влиять на production до QA. Требуются shadow-поля: — price; — selected offer ID; — direct URL; — offer status; — risk/QA flags; — checkedAt; — engineVersion. 4. Расширение существующей таблицы offers Добавить: — source; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — risk flags либо хранение в существующем JSON; — unique constraint для защиты от дублей. Новую параллельную offer-систему создавать не требуется, если существующую таблицу можно безопасно расширить. 5. UPSERT, STALE и DB transaction Заменить текущую схему DELETE → CREATE: — UPSERT существующих и новых offers; — отсутствующие в полном успешном snapshot offers переводятся в STALE; — при API error, partial result или незавершённом snapshot активные offers не должны становиться STALE; — обновление offers, selected offer metadata и shadow fields по одной модели выполняется внутри одной DB transaction; — при ошибке выполняется полный rollback. 6. Canonical-safe refresh Price refresh не должен изменять: — brand; — reference; — model; — collection; — name/title; — slug; — descriptions; — images; — SEO fields. Обновляются только offer, price и shadow data. 7. Сохранение текущей cron-логики Сохранить: — existing cron; — rolling batches; — cooldown; — проверку PRICE_REFRESH_MIN_DAYS до вызова внешнего API; — legacy production pipeline до завершения Shadow QA. 8. Audit output Достаточно одного варианта: — shadow-колонки в существующей admin table; или — CSV export. Минимальные данные: — model/reference; — production price; — shadow price; — delta; — production/shadow URL; — status; — risk flags; — checkedAt; — engineVersion. Новый сложный dashboard не требуется. 9. Staging и QA — DB migrations; — staging deployment; — smoke test на 5 переданных моделях; — затем Shadow Mode приблизительно на 50 моделях; — исправление технических ошибок, выявленных во время этих прогонов; — краткая документация контракта Python → Node.js и rollback procedure. ОПЦИОНАЛЬНО ОЦЕНИТЬ ОТДЕЛЬНО Простой технический promotion без нового UI: — promotion одной модели по slug; — promotion списка slug; — перенос подтверждённых shadow values в production; — техническая проверка после rollout. РЕЗУЛЬТАТ — Pull Request; — DB migrations; — рабочая интеграция Python → Node.js; — Shadow Mode; — UPSERT, STALE и транзакционное обновление; — запуск по slug/id; — staging deployment; — smoke-test results; — краткая документация; — не менее 7 дней исправления багов по реализованному scope после приёмки. В ОТКЛИКЕ УКАЗАТЬ 1. Fixed price за обязательный scope. 2. Отдельную стоимость promotion-механизма. 3. Срок. 4. Оценку часов. 5. Когда готовы начать. 6. Опыт с PostgreSQL transactions, migrations и ingestion pipelines. 7. Какие вопросы нужно уточнить до начала. 8. Включены ли staging, QA, migrations и bug-fix period. Шаблонные ответы без конкретной оценки рассматриваться не будут. Доступ к production на первом этапе не предоставляется. Работа начинается с ограниченного code review и staging.
Необходимо разработать централизованную серверную систему сбора и хранения данных из Planfix, 1С, Meta Ads и Google Ads, а также веб-дашборд для их отображения и анализа. Все данные, история изменений, расчеты и агрегированные показатели должны храниться исключительно в серверной базе данных. Дашборд не должен хранить или дублировать бизнес-данные. Он должен получать необходимую информацию из серверной базы через API в соответствии с запросами пользователя и отображать ее в виде KPI, графиков, таблиц и детализированных отчетов.
Ищем для поддержки проекта на базе Yii , нужно вносить правки и доработки базы, частично есть связь с предыдущим исполнителем .....................
Необходимо сделать миграцию базы из CRM G-PLUS на MyChatBot Объем базы - 26 тыс. лидов 2 воронки - Кол центр и Отдел продаж со своими воронками Карточки лидов (кроме имени и номера) имеют много различных полей Лиды также имеют голосовые записи звонков. Их также нужно перенести От кандидата ожидаю ориентировочную сумму и сроки реализации
Создать дашборд для мониторинга и анализа эффективности сети локаций (филиалов) компании в Google Business Profile (GBP) через официальный Google Business Profile API. Обработка через Скрипт на базе Google Apps Script (привязать к Google Таблице). Запись данных в Google Таблицу (которая выступает как база данных для Looker Studio). Обновление: Ежедневно (с индикацией даты последнего обновления). Создать сервисный аккаунт Google Cloud Скрипт раз в сутки (триггер в 03:00 ночи) отправляет запрос к GBP API. Получает метрики за вчерашний день по каждой локации (locationId). Записывает данные в таблицу в плоском формате (строка = уникальное сочетание Дата + ID Филиала + Метрики). Карточки ключевых показателейНазвание карточкиМетрика GBPФормат динамикиПросмотры профиляImpressions (Search + Maps)Процент %, Sparkline (синий)ЗвонкиLocal Services Phone CallsПроцент %, Sparkline (зеленый)Переходы на сайтWebsite ClicksПроцент %, Sparkline (фиолетовый)Построение маршрутовDirection RequestsПроцент %, Sparkline (оранжевый)Средний рейтингAverage Review RatingАбсолютное изменение (например, +0.1), Sparkline (желтый)Новые отзывыNew Reviews CountПроцент %, Sparkline (бирюзовый)