Swiper JS stworzyć slider do swipe z paskiem postępu

Есть действующий 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.

Istnieje działająca platforma produkcyjna z katalogiem i automatycznym aktualizowaniem zewnętrznych ofert i cen. Stos technologiczny: — Node.js / TypeScript; — PostgreSQL; — istniejąca usługa odświeżania cen i cron; — oddzielny gotowy moduł walidacji i wyboru ofert w Pythonie; — staging i produkcja. Konieczne jest punktowe dopracowanie istniejącego pipeline'u odświeżania cen bez pełnego przepisywania backendu. OBOWIĄZKOWY ZAKRES 1. Integracja modułu Python — Moduł Python pozostaje oddzielnym komponentem; — zwraca zorganizowany wynik: oferty, wybrana oferta, statusy i flagi ryzyka; — Node.js waliduje wynik i wykonuje zapis w bazie danych; — przewidzieć obsługę błędów i częściowych/nieudanych uruchomień; — pipeline dziedziczony nie jest wyłączany do zakończenia QA. 2. Uruchomienie odświeżania według listy Dodaj uruchomienie: — po jednym slug/id; — po przekazanej liście slug/id. Możliwe CLI lub istniejące API serwisowe. Nowy interfejs użytkownika nie jest wymagany. 3. Tryb Shadow Nowe wyniki powinny być zapisywane oddzielnie i nie wpływać na produkcję do QA. Wymagane pola shadow: — cena; — ID wybranej oferty; — bezpośredni URL; — status oferty; — flagi ryzyka/QA; — checkedAt; — engineVersion. 4. Rozszerzenie istniejącej tabeli ofert Dodaj: — źródło; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — flagi ryzyka lub przechowywanie w istniejącym JSON; — unikalne ograniczenie dla ochrony przed duplikatami. Nie jest wymagane tworzenie nowego równoległego systemu ofert, jeśli istniejącą tabelę można bezpiecznie rozszerzyć. 5. UPSERT, STALE i transakcja DB Zamień obecną schemę DELETE → CREATE: — UPSERT istniejących i nowych ofert; — oferty, które nie występują w pełnym udanym snapshot, są przekazywane do STALE; — w przypadku błędu API, częściowego wyniku lub niedokończonego snapshot aktywne oferty nie powinny stawać się STALE; — aktualizacja ofert, metadanych wybranej oferty i pól shadow według jednego modelu odbywa się w ramach jednej transakcji DB; — w przypadku błędu wykonywany jest pełny rollback. 6. Bezpieczne odświeżanie kanoniczne Odświeżanie cen nie powinno zmieniać: — marki; — referencji; — modelu; — kolekcji; — nazwy/tytułu; — slug; — opisów; — obrazów; — pól SEO. Aktualizowane są tylko oferta, cena i dane shadow. 7. Zachowanie obecnej logiki cron Zachować: — istniejący cron; — rolling batches; — cooldown; — sprawdzenie PRICE_REFRESH_MIN_DAYS przed wywołaniem zewnętrznego API; — dziedziczony pipeline produkcyjny do zakończenia Shadow QA. 8. Audyt wyników Wystarczy jedna opcja: — kolumna shadow w istniejącej tabeli administracyjnej; lub — eksport CSV. Minimalne dane: — model/referencja; — cena produkcyjna; — cena shadow; — delta; — URL produkcyjny/shadow; — status; — flagi ryzyka; — checkedAt; — engineVersion. Nowy skomplikowany dashboard nie jest wymagany. 9. Staging i QA — migracje DB; — wdrożenie staging; — test dymny na 5 przekazanych modelach; — następnie Tryb Shadow na około 50 modelach; — naprawa błędów technicznych wykrytych podczas tych uruchomień; — krótka dokumentacja kontraktu Python → Node.js i procedura rollback. OPCJONALNIE OCENIĆ ODDZIELNIE Prosta promocja techniczna bez nowego UI: — promocja jednego modelu po slug; — promocja listy slug; — przeniesienie potwierdzonych wartości shadow do produkcji; — techniczna weryfikacja po rollout. WYNIK — Pull Request; — migracje DB; — działająca integracja Python → Node.js; — Tryb Shadow; — UPSERT, STALE i transakcyjne aktualizacje; — uruchomienie po slug/id; — wdrożenie staging; — wyniki testu dymnego; — krótka dokumentacja; — nie mniej niż 7 dni na poprawki błędów w zrealizowanym zakresie po akceptacji. W ODPOWIEDZI WSKAZAĆ 1. Stała cena za obowiązkowy zakres. 2. Oddzielny koszt mechanizmu promocji. 3. Termin. 4. Ocena godzin. 5. Kiedy gotowi do rozpoczęcia. 6. Doświadczenie z transakcjami PostgreSQL, migracjami i pipeline'ami wczytywania. 7. Jakie pytania należy wyjaśnić przed rozpoczęciem. 8. Czy wliczone są staging, QA, migracje i okres naprawy błędów. Szablonowe odpowiedzi bez konkretnej oceny nie będą rozpatrywane. Dostęp do produkcji na pierwszym etapie nie jest udostępniany. Praca zaczyna się od ograniczonego przeglądu kodu i stagingu.

Dzień dobry, 1) zaktualizować jQuery** do aktualnej wersji (3.x) z podłączeniem jQuery Migrate 2) Dokładnie przetestować funkcjonalność aplikacji 3) i usunąć możliwe błędy, aby skrypty były ze sobą kompatybilne pod względem wersji tutaj trzeba całkowicie przepisać https://filtry.in.ua/assets/libs/libs.js pod nową wersję jQuery, ponieważ tam jest stary Bootstrap i wiele funkcji niestandardowych zapisanych

Opis: Należy stworzyć skrypt JavaScript do rozszerzenia Tampermonkey. Skrypt będzie działał w wewnętrznym systemie CRM.Logika działania: Skrypt ma odczytywać unikalny tekstowy ID bieżącego aktywnego dialogu na stronie (jest 5–10 różnych ID). W zależności od ID, skrypt pobiera odpowiednią tekstową instrukcję (System Prompt) z ustawień. Mapę parametrów po ID należy przenieść do osobnego wygodnego okna ustawień skryptu. Po pojawieniu się nowej wiadomości w oknie czatu, skrypt wysyła ten tekst wraz z promptem przez API OpenAI (model gpt-4o-mini). Otrzymaną odpowiedź skrypt wstawia w pole wprowadzania tekstu i inicjuje wysyłkę z losowym opóźnieniem od 20 do 45 sekund, aby zasymulować naturalną pracę operatora.Praca wyłącznie z tekstem. Budżet — 6000 zł. Czekam na oferty od programistów z doświadczeniem w pracy z OpenAI API oraz pisaniu skryptów automatyzacji przeglądarki.

Potrzebne jest opracowanie własnej usługi internetowej do automatyzacji pracy kawiarni i małych lokali gastronomicznych. Funkcjonalność produktu ma być podobna do Poster POS, ale z własnym designem, architekturą i kodem źródłowym. Kopiowanie kodu lub interfejsu Poster nie jest przewidziane. Planowane jest stworzenie pełnoprawnego komercyjnego produktu SaaS, z którego w przyszłości będą mogły korzystać różne kawiarnie na zasadzie subskrypcji.Na pierwszym etapie należy opracować MVP Podstawowa funkcjonalność: rejestracja i autoryzacja właściciela lokalu; tworzenie jednego lub kilku lokali; zarządzanie pracownikami i rolami; katalog produktów, kategorii i modyfikatorów; dodawanie rozmiarów, smaków i dodatkowych opcji; interfejs kasowy do realizacji sprzedaży; otwieranie i zamykanie zmiany kasowej; różne metody płatności; zwroty i anulowanie zamówień; ewidencja stanów magazynowych i odpisywanie towarów; podstawowa ewidencja magazynowa; historia sprzedaży; raporty dotyczące przychodów, towarów, zmian i pracowników; program lojalnościowy dla klientów; adaptacyjna praca na tablecie, laptopie i smartfonie; panel administracyjny właściciela usługi; plany taryfowe i ograniczenia zgodnie z taryfą.W przyszłości planowane jest aplikacja mobilna; integracja z terminalami płatniczymi; drukowanie paragonów; integracja z usługami fiskalnymi; dostawa i zamówienia online; rezerwacja stolików; rozszerzona analityka; API do integracji zewnętrznych; integracja z systemami księgowymi i CRM.Ważne wymagania system musi być zaprojektowany do pracy wielu niezależnych lokali; dane każdego klienta muszą być izolowane; należy przewidzieć skalowalność produktu; potrzebna jest bezpieczna praca z danymi finansowymi i osobowymi; kod musi być zorganizowany i nadający się do dalszego rozwoju; potrzebna jest dokumentacja techniczna; prawa do kodu źródłowego po zapłacie przechodzą na zamawiającego. Design w tym momencie jest nieobecny, dlatego należy osobno ocenić UI/UX design lub zaproponować gotowe rozwiązanie dla MVP.W ofercie proszę wskazać doświadczenie w tworzeniu SaaS, POS, CRM, ERP lub systemów księgowych; przykłady podobnych prac; proponowany stos technologii; skład zespołu; orientacyjną cenę MVP; czas realizacji; co dokładnie wchodzi w proponowaną cenę; koszt dalszego wsparcia; czy są gotowi pracować etapami z płatnością za każdy zakończony etap. Preferencje dla wykonawców lub zespołów, które już opracowały systemy kasowe, magazynowe, restauracyjne lub wieloosobowe SaaS.