Доброго часу доби, є учбовий проект, https://reqres.in
Це сайт, для навчання написанню API тестування та UI тестування
Бажаю найняти особу, що має КОМЕРЦІЙНИЙ досвід, та за високими стандартами знає, як створити цей фреймворк
Результат буде складатися із 2 частин:
1. Створити фреймворк та викласти його на GitHub
2. Супроводити мене в ньому, щоб я зрозумів, що до чого
Наприклад, я створював самостійно API автоматизацію тестування та UI тестування для цього ж сайту, як частина учбового процесу на Python.
Зроблено:
1. у POM моделі (окремо локатори, окремо Base Page, окремо тести)
2. GitHub Action перевірка працездатності білда після його завантаження на GitHub (.yml)
3. Написав API 1.валідатор JSON схеми 2.пов'язав його із http хендлером 3. написав тести використовуючи хендлер
Те саме що я зробив із Python, мені треба зробити із JS на Cypress.
Загально покриття сайту тестами UI не потрібно, лише 2 метода у Бейс Пейдж, наприклад "visible", "clickable"
Для API по 1 прикладу на кожен із методів (get, post, put, delete, patch)
Прошу надати:
1. Посилання на ваш Git
2. Посилання на ваш Linked
3. Ціну, виконання проекта
4. Строки
Дякую, щасливих вам святкових днів.
Бюджет: 68800 UAH Срок: 7 дней
Добрый день, я могу помочь в создании структуры для тестирования на cypress, опыт в автоматизации на cypress 3 года,
HTTPS://github.com/Maksym-Bov
https://www.linkedin.com/in/maksym-bovsunivskyi-868335207
Это недоработанный плагин для After Effects: https://drive.google.com/drive/u/0/folders/1Nq9a672OK6ep9Com1lqelUhZxbx3_3f1 Это, если я правильно понимаю, CEP-плагин (Adobe Extension) для After Effects. Это HTML/JavaScript-панель через Adobe CSXS, которая взаимодействует с After Effects через ExtendScript. Целью было автоматизировать процесс создания видео в стиле "maze challenge", референс на YouTube GOALRUSH-f8x или аналог. Видео ручного монтажа: https://drive.google.com/file/d/1Ylzvax6w2JGDwaBqeCdbD49jh5wB5buY/view?usp=sharing Файл одного из проектов: https://drive.google.com/file/d/15vKd1L9VfHtDqK2wtLQdYEmDpH1d8Jvy/view?usp=sharing Кроме "багованности" системы через вайбкодинг (поэтому вайбкодеры мимо), не устраивали накладки такие детали (реальные правки): https://docs.google.com/spreadsheets/d/18Svc6GoQ34PgLe1HY7gNX5tPLH0Cpv9E4mfjCRBCMFU/edit?gid=0#gid=0 Нужно сделать систему, которая будет генерировать проекты в After Effects со всеми необходимыми компонентами видео, которые написаны в База.pdf, более детальная логика в виде фото, текстового документа и mind map для понимания всех возможных вариаций на диске: https://drive.google.com/drive/folders/1Uf4Pnw3SKmwpmhL7sjPZFnfAbN0arUjr?usp=sharing Еще более детально (с более углубленной описательной частью и ссылками на таймкоды в референсах) ТЗ будет фиксироваться в рабочей области проекта Конечный результат — это система, которая создает видео: от 40 секунд до 1 минуты, полностью уникальный контент каждое создание, без метаданных ИИ в файле видео, в нем должен быть понятный сюжет (ловушки, тупики, разные эмоции персонажей-знаменитостей в результате каких-то сюжетных поворотов в видео), саунд-дизайн под сюжет (крики и другие эмоции, взрывы и т.д.), стилистически не отличающиеся от видео референса с канала
Есть действующий production-сайт с каталогом товаров, карточками моделей и информационными страницами. Стек frontend: — Next.js; — React; — TypeScript; — существующая компонентная система; — staging и production environments. Есть согласованное визуальное направление и дизайн новой главной страницы. Необходимо внедрить его в существующий проект, адаптировать под desktop/tablet/mobile и привести все основные типы страниц сайта к единой обновлённой стилистике. Полный редизайн продукта и изменение бизнес-логики не требуются. ОБЯЗАТЕЛЬНЫЙ SCOPE 1. Новая главная страница — реализовать главную страницу по предоставленному дизайну; — сохранить существующую функциональность, ссылки и маршрутизацию; — корректно подключить согласованные секции и CTA; — использовать существующие данные и API; — предусмотреть корректное отображение динамического контента. Основные типы секций: — header/navigation; — hero; — информационные блоки; — карточки моделей/предложений; — аналитические или market insight блоки; — CTA-секции; — footer. Точный состав секций будет предоставлен выбранному исполнителю вместе с макетом. 2. Responsive Необходимо реализовать: — desktop; — tablet; — mobile; — промежуточные разрешения; — корректное поведение сеток, карточек, меню, кнопок и типографики; — отсутствие горизонтального скролла и визуальных конфликтов. 3. Типографика и общие стили — внедрить новые согласованные шрифты; — привести размеры, веса, line-height и интервалы к единой системе; — обновить стили кнопок, карточек, полей, бейджей и заголовков; — по возможности использовать общие design tokens или CSS variables; — не дублировать стили отдельно для каждой страницы без необходимости. 4. Унификация существующих страниц Проверить и привести к новой стилистике основные типы страниц: — каталог; — карточка модели / PDP; — информационные страницы; — header; — footer; — формы; — модальные окна; — существующие CTA; — loading / empty / error states, если они уже присутствуют в проекте. Речь идёт о визуальной унификации существующих компонентов, а не о полном индивидуальном редизайне каждой страницы. 5. Каталог Проверить: — сетку карточек; — изображения; — название, reference и цену; — фильтры и сортировки; — кнопки и ссылки; — desktop/mobile отображение; — loading и empty states; — отсутствие визуальных сдвигов при загрузке. 6. PDP Проверить: — галерею; — основной информационный блок; — цену и CTA; — аналитические секции; — таблицы и метрики; — About Watch; — desktop/mobile компоновку; — длинные названия, references и отсутствующие данные. Необходимо сохранить текущую функциональность и существующие контракты API. 7. Header и Footer — единая стилистика на всех страницах; — responsive navigation; — mobile menu; — корректные active/hover/focus states; — отсутствие расхождений между главной, каталогом и PDP. 8. Состояния интерфейса Для динамических блоков проверить: — loading; — empty data; — API error; — insufficient data; — отсутствующее изображение; — отсутствующая цена; — длинный текст; — мобильное отображение. Не требуется разрабатывать новую сложную бизнес-логику. Необходимо корректно визуализировать уже существующие состояния. 9. Качество и производительность — не ухудшить SEO и текущую индексацию; — сохранить корректные metadata и semantic HTML; — не создавать критических layout shifts; — оптимизировать изображения и шрифты; — учитывать reduced motion для анимаций; — проверить базовую доступность: focus states, contrast, keyboard navigation; — не подключать тяжёлые библиотеки без обоснованной необходимости. 10. Staging и QA — развернуть изменения на staging; — проверить основные типы страниц; — проверить desktop, tablet и mobile; — устранить визуальные и responsive-баги; — после приёмки выполнить production deployment; — обеспечить исправление багов по реализованному scope не менее 7 календарных дней после выкладки. РЕЗУЛЬТАТ РАБОТЫ — Pull Request с frontend-кодом; — реализованная новая главная; — responsive desktop/tablet/mobile; — единые шрифты, карточки и базовые UI-компоненты; — визуально согласованные каталог, PDP и информационные страницы; — staging deployment; — исправление найденных визуальных ошибок; — production deployment; — краткое описание изменённых компонентов; — 7-дневный bug-fix period после приёмки. ACCEPTANCE CRITERIA 1. Главная соответствует предоставленному дизайну. 2. Все секции корректно работают на desktop, tablet и mobile. 3. Header и footer единообразны на всех страницах. 4. Каталог и PDP визуально соответствуют новой системе. 5. Текущая функциональность сайта не нарушена. 6. API-контракты и backend-логика не изменены без согласования. 7. Нет горизонтального скролла и критических layout shifts. 8. Шрифты и изображения загружаются корректно. 9. Loading, empty и error states отображаются без поломки layout. 10. Изменения проверены на staging и развернуты в production. 11. Исправлены визуальные ошибки, обнаруженные при приёмке в рамках согласованного scope. ЧТО НЕ ТРЕБУЕТСЯ — разработка backend; — изменение бизнес-логики; — создание нового каталога или CMS; — разработка нового API; — полный редизайн каждой информационной страницы; — новые пользовательские функции, отсутствующие в макетах; — разработка сложной дизайн-системы с нуля; — создание нового проекта вместо доработки существующего; — изменение SEO-структуры без отдельного согласования. ТРЕБОВАНИЯ К ИСПОЛНИТЕЛЮ — уверенный Next.js / React / TypeScript; — опыт работы с существующими production-проектами; — качественная responsive-вёрстка; — опыт внедрения дизайна из Figma; — компонентный подход; — уверенная работа с CSS / CSS Modules / Tailwind или существующей системой проекта; — понимание Core Web Vitals; — Git / Pull Request workflow; — умение работать через staging. В ОТКЛИКЕ ОБЯЗАТЕЛЬНО УКАЗАТЬ 1. Fixed price за полный обязательный scope. 2. Срок выполнения в рабочих днях. 3. Оценку в часах. 4. Когда готовы начать. 5. Ссылки на 2–3 релевантных проекта на Next.js/React. 6. Есть ли опыт работы с каталогами, карточками товаров или аналитическими интерфейсами. 7. Что потребуется для точной оценки до начала работы. 8. Входят ли в цену: — staging; — responsive QA; — production deployment; — исправление багов; — 7-дневный bug-fix period. Шаблонные отклики без просмотра требований и без конкретной оценки рассматриваться не будут. Доступ к production на первом этапе не предоставляется. Работа начинается после ограниченного code review и разворачивается через staging.
Есть действующая 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.
Доброго дня , 1) обновить jQuery** до актуальной версии (3.x) с подключением jQuery Migrate 2) Тщательно протестируйте функциональность приложения 3) и устранить возможные ошибки чтобы скрипты все были совместимы между собой по версиям здесь нужно полностью переписыватьhttps://filtry.in.ua/assets/libs/libs.js под новую версию jquery так как там и бутстрап старый и много функций кастомных прописано
Описание: Необходимо создать JavaScript-скрипт для расширения Tampermonkey. Скрипт будет работать во внутренней рабочей CRM-системе.Логика работы: Скрипт должен считывать уникальный текстовый ID текущего активного диалога на странице (всего есть 5–10 различных ID). В зависимости от ID, скрипт берет соответствующую текстовую инструкцию (System Prompt) из настроек. Карта параметров по ID должна быть вынесена в отдельное удобное окно настроек скрипта. При появлении нового сообщения в окне чата, скрипт отправляет этот текст вместе с промптом через API OpenAI (модель gpt-4o-mini). Полученный ответ скрипт вставляет в поле ввода текста и инициирует отправку с рандомной задержкой в 20–45 секунд для имитации естественной работы оператора.Работа сугубо с текстом. Бюджет — 6000 грн. Жду предложений от разработчиков с опытом работы с OpenAI API и написанием скриптов автоматизации браузера.
