Opracowanie stron rejestracyjnych i udostępniania dla nowego projektu

Я профессиональный 3D-дизайнер, создаю высокодетализированные рендеры памятников и мемориальных комплексов (вертикальный формат 9:16). Мои клиенты — это владельцы цехов и мастерских, которым нужен удобный цифровой каталог моих макетов для показа своим розничным покупателям. Что мне нужно:Подобрать оптимальную платформу и собрать лёгкий, быстрый веб-апп (каталог), который будет идеально смотреться на смартфонах и корректно открываться на компьютерах. Ключевые требования к каталогу: Дизайн: Максимальный минимализм. Тёмная тема (чёрный фон), крупная вертикальная картинка (пропорции 9:16), под ней только название/артикул макета. Никаких длинных описаний. Управление базой: Мне нужна максимально простая система добавления новых макетов (идеально — через привычные Google Таблицы или очень удобную внутреннюю БД). Я должен просто загрузить картинку и вписать артикул, не ломая вёрстку. Интеграция к клиентам (Самое важное): Каталог должен легко внедряться на сайты моих заказчиков-цеховиков (у кого-то WordPress, у кого-то самопис). Нужно продумать элегантный способ встраивания: через Iframe (чтобы каталог работал прямо внутри их страницы) или через правильную настройку кнопки-ссылки. Что я уже пробовал: Тестировал Glide и Adalo. В Adalo получился нужный визуал (9:16 на чёрном фоне), но управление внутренней базой данных и возня со ссылками на Google Диск оказались слишком неудобными для постоянной работы. Плюс есть сомнения по поводу правильного встраивания Iframe в чужие сайты так, чтобы он не разъезжался на широких мониторах. От вас жду в отклике: На какой платформе (Adalo, Glide, Bubble, Webflow, Glide + Airtable или что-то другое) вы предлагаете это реализовать и почему? Как будет решён вопрос с хранением тяжёлых картинок (рендеров)? Как вы предлагаете технически встраивать этот каталог на сторонние сайты моих клиентов? Ищу специалиста, который закроет эту техническую боль под ключ, чтобы я мог спокойно заниматься 3D-моделированием.

Strona internetowa jest już uruchomiona i działa. Główne zadanie to zrozumienie obecnej struktury projektu, sprawdzenie jakości realizacji, naprawienie znalezionych problemów technicznych oraz pomoc w dalszych zmianach.Główna technologia Next.js 15 React 19 TypeScript Tailwind CSS Zod Redux Toolkit W projekcie mogą być również używane: Prisma JWT-uwierzytelnianie Stripe Mailgun Google APIs Vercel lub Netlify FunctionsGłówne zadania przeprowadzenie audytu istniejącego projektu; ocena struktury i jakości kodu; naprawa błędów i rozwijanie obecnej funkcjonalności; poprawa renderowania po stronie serwera i szybkości ładowania stron; sprawdzanie poprawności wyświetlania strony na urządzeniach mobilnych; praca z formularzami, częścią administracyjną i zewnętrznymi integracjami; wnoszenie technicznych zmian SEO; wspieranie i stopniowe ulepszanie istniejącej strony.Co jest dla nas ważne dobre doświadczenie w pracy z Next.js, React i TypeScript; umiejętność rozumienia cudzych kodów; zrozumienie SSR i specyfiki Next.js App Router; uwaga na wydajność i jakość realizacji; umiejętność wyjaśniania znalezionych problemów i proponowania zrozumiałych rozwiązań; samodzielność i staranna praca z działającą stroną. Na pierwszym etapie należy zapoznać się z projektem, przeprowadzić audyt techniczny i zaproponować listę priorytetowych zmian. Po tym możliwa jest stała praca nad dalszym rozwojem strony.

Szukamy doświadczonego programisty Embedded do stworzenia energooszczędnego oprogramowania dla urządzenia noszonego (format: pas piersiowy) do monitorowania stanu psychofizjologicznego. Projektowanie schematu zostało zakończone, rozwój będzie prowadzony na bazie płytki deweloperskiej (Development Kit) z późniejszym przeniesieniem na niestandardową płytkę.Stos i baza sprzętowa:MCU: Nordic Semiconductor nRF52840 lub nRF5340.Środowisko programistyczne: nRF Connect SDK / Zephyr RTOS (wyłącznie C/C++).Peryferia:Optyczny czujnik pulsu (PPG) — komunikacja przez I2C.6-osiowy czujnik inercyjny (IMU akcelerometr + żyroskop) — komunikacja przez SPI.Sterownik silnika wibracyjnego (LRA 1030) — sterowanie przez PWM.Zewnętrzna pamięć SPI Flash do cyklicznego logowania.Zakres pracy według etapówEtap 1: Uruchomienie, sterowniki peryferiów i telemetria BLECel: Ożywić sprzęt, skonfigurować stabilne zbieranie danych i ich przesyłanie na smartfon/PC.Konfiguracja pracy szyn I2C i SPI z wykorzystaniem DMA (Direct Memory Access) w celu odciążenia procesora.Pisanie/integracja sterowników dla PPG i IMU (konfiguracja częstotliwości próbkowania, buforów FIFO czujników).Rozwój niestandardowego profilu BLE (usługa GATT) do przesyłania surowych danych z czujników w czasie rzeczywistym.Podstawowa inicjalizacja PWM do sterowania silnikiem wibracyjnym LRA (uruchomienie testowych wzorców wibracji).Etap 2: Warstwa algorytmiczna (DSP i wielopoziomowa logika sprzężenia zwrotnego)Cel: Zrealizować matematyczne przetwarzanie sygnałów bezpośrednio na chipie (Edge Computing) oraz logikę reakcji urządzenia.Realizacja algorytmów filtracji artefaktów ruchu: oczyszczanie sygnału PPG z wykorzystaniem danych z akcelerometru (IMU).Wydobycie interwałów R-R (HRV) z oczyszczonego sygnału PPG.Realizacja 4-poziomowej logiki stabilności systemu:Poziom Dryfu: Śledzenie płynnych zmian HRV i oddechu.Poziom Predykcji: Obliczanie matematycznego trendu na pogorszenie stanu.Poziom Mikro-korekcji: Generowanie ledwo zauważalnych wzorców wibracji na silniku LRA przy wykrywaniu docelowego wzorca danych.Poziom Sprzętowego resetu: Realizacja logiki bezpieczeństwa (wysokointensywny impuls wibracyjny przy krytycznych wskaźnikach).Etap 3: Oszczędność energii, logowanie i odporność na awarieCel: Przygotowanie urządzenia do autonomicznej pracy z miniaturową baterią i zapewnienie stabilności „24/7”.Głęboka optymalizacja zużycia energii. Przełączanie MCU w tryb uśpienia (System ON/OFF) między cyklami pomiarów. Procesor powinien budzić się tylko na przerwania z buforów FIFO czujników lub timera.Pisanie odpornej na awarie systemu plików w zewnętrznej pamięci SPI Flash (np. LittleFS) do autonomicznego cyklicznego zapisywania logów.Konfiguracja sprzętowego timera watchdog (Watchdog Timer) w celu zapobiegania zawieszaniu się oprogramowania.Wymagania wobec wykonawcy:Doświadczenie w komercyjnej produkcji dla chipów Nordic (nRF52/nRF53) od 3 lat.Pewna znajomość Zephyr RTOS i narzędzi debugowania (Segger Embedded Studio / VS Code, J-Link).Zrozumienie zasad działania cyfrowej filtracji sygnałów (DSP) i pracy z niskim zużyciem energii (Low-Power design).Posiadanie własnego zestawu deweloperskiego (nRF52840-DK lub podobnego) do rozpoczęcia pracy jest mile widziane.Format pracy:Płatność etapowa (Milestones) z dokumentacją wyników na GitHubie. Proszę podać swoją stawkę godzinową lub przybliżoną wycenę kosztów i terminów dla każdego z trzech etapów.

Potrzebny specjalista od Wix do stworzenia strony według makiety Figma. Jest gotowy projekt strony w Figma. Należy go jakościowo zrealizować w Wix, maksymalnie przestrzegając makiety. Wymagane: przenieść projekt z Figma do Wix; zaadaptować wszystkie strony; ustawić wersje desktopową i mobilną; zapewnić poprawne wyświetlanie na różnych urządzeniach. Preferowani wykonawcy z doświadczeniem w pracy z Wix. Proszę przesyłać portfolio z zrealizowanymi projektami.

Ogólne informacje Konieczne jest opracowanie prostej, minimalistycznej systemu webowego, którego głównym celem jest prowadzenie bazy klientów, tworzenie zapisów na wizyty oraz automatyzacja procesu potwierdzania wizyt przez SMS, wysyłanie jednorazowych linków przez API z samego serwisu. Projekt jest realizowany etapami. Na pierwszym etapie konieczne jest wdrożenie jedynie podstawowej funkcjonalności (MVP), aby system mógł być używany w rzeczywistej pracy. Po uruchomieniu i przetestowaniu będzie stopniowo rozszerzany o nowe moduły.Podstawowa funkcjonalność pierwszego etapu autoryzacja użytkowników; baza klientów; tworzenie i edytowanie zapisów; lista zapisów (lub prosty kalendarz); przełączanie między punktami sprzedaży; integracja z operatorem SMS przez API; wysyłanie SMS z dowolnym tekstem lub linkiem do potwierdzenia wizyty; potwierdzenie lub anulowanie wizyty przez klienta za pomocą jednorazowego linku; wyświetlanie statusu potwierdzenia bezpośrednio obok zapisu klienta. Na początkowym etapie zamiast pełnoprawnego kalendarza dopuszcza się użycie prostego wykazu zapisów według dni. Każdy dzień powinien zawierać chronologiczny wykaz rezerwacji z podaniem czasu, imienia klienta, usługi, pracownika oraz statusu potwierdzenia. W przyszłości ten wykaz można będzie zastąpić pełnoprawnym kalendarzem bez zmiany struktury systemu. W systemie powinna być możliwość przełączania się między punktami sprzedaży. Każdy punkt sprzedaży ma własną listę zapisów (lub kalendarz), ale wszystkie korzystają ze wspólnej bazy klientów.