Budżet: 200 USD Termin: 1 dzień
Witaj! Jestem gotów zrealizować ten projekt, mam duże doświadczenie w tworzeniu różnych aplikacji.
Budżet: 250 USD Termin: 13 dni
Cześć, Ivan! Realizacja API dla systemu "Borowe" — ważny krok w kierunku poprawy doświadczeń użytkowników. Specjalizuję się w integracjach odpornych na kryptowaluty API z systemami zewnętrznymi, zapewniając bezbłędną wymianę danych. Moja głęboka znajomość Go-langu i umiejętności w konfiguracji serwerów gwarantują optymalną pracę usług nawet przy dużych obciążeniach. Jestem pewien, że wspólnymi siłami możemy osiągnąć wysoki poziom automatyzacji i ewidencji. Z przyjemnością podzielę się swoim doświadczeniem w tworzeniu skalowalnych rozwiązań dla pomyślnego zakończenia twojego projektu. Porozmawiajmy szczegółowo o twoich zadaniach!
Budżet: 800 USD Termin: 12 dni
Cześć Ivan.
Sprawdziłem twój projekt Go, dokumentację API, bazę danych SQL i przewodnik integracji dla zautomatyzowanego systemu kontroli procesów Borovoye.
Zamierzam:
Zbudować usługę pobierania/umieszczania biletów przez API do Rekassa (uwierzytelnianie ID/token, przechowywanie pośrednie).
Obsługiwać zapytania z bramek obrotowych + walidacja dostępu.
Wdrożyć eksporty raportów (CSV/PDF) do punktów końcowych organizacji.
Moduły Go, bezpieczne dla współbieżności, gotowe do Dockera dla twojego serwera.
Nie wahaj się skontaktować ze mną.
Dzięki.
Revaz G.
Oferta, która wygrała- Zlecenia 36
- Ocena 5.0
- Ranking 15 973
Budżet: 400 USD Termin: 10 dni
Cześć Ivan,
Przejrzałem dokumentację twojego systemu biletowego Borovoe. Struktura twojego serwera Go jest czysta i widzę dokładnie, co należy zrobić - zintegrować API Rekassa, zająć się przechowywaniem biletów i zapewnić odpowiednią walidację dostępu dla bramek.
Dlaczego to zadziała ze mną:
Miałem do czynienia z systemami kontroli dostępu wcześniej. Krytyczną częścią nie jest tylko odbieranie biletów z Rekassa - chodzi o obsługę przypadków brzegowych, gdy bramki tracą połączenie, przychodzą zduplikowane wywołania webhooków lub występują opóźnienia w replikacji MySQL. Twoje kontrolery Z5R-W potrzebują niezawodnego trybu offline, a ja wiem, jak wdrożyć odpowiednie źródło zdarzeń, aby żadne zdarzenie dostępu nie zostało utracone.
Patrząc na schemat twojej bazy danych, tabele abonements_created i events są proste, ale dodam odpowiednie indeksowanie pól card i controller_sn dla szybszych wyszukiwań, gdy rozwiniesz się do tysięcy codziennych wpisów. Przepływ check_access przez chmurę do bramek wymaga starannego zarządzania czasem oczekiwania - nikt nie chce, aby turyści utknęli przy bramie.
Co dostarczę:
Działającą integrację Rekassa w twojej istniejącej bazie kodu Go, a nie przepisanie. Odpowiednie buforowanie dla scenariuszy offline. Czysty moduł raportowania, który rzeczywiście pokazuje znaczące dane, a nie tylko surowe zrzuty bazy danych. Wszystko przetestowane zarówno w scenariuszach testowych, jak i produkcyjnych.
Harmonogram: 5-7 dni na podstawową integrację, kolejne 3 dni na raporty i testowanie. Łącznie 400 dolarów.
Sam prowadzę systemy produkcyjne, więc rozumiem, że "działający" oznacza radzenie sobie z chaosem w rzeczywistym świecie, a nie tylko scenariuszami idealnymi. Gotowy do rozpoczęcia od razu.
Sprawmy, aby te bramki działały płynnie.
Revaz
Budżet: 350 USD Termin: 6 dni
Dzień dobry!
Przejrzałem archiwum z serwerem — struktura jest zrozumiała, backend na Go jest już przygotowany do rozszerzeń, są oddzielne moduły pod API, sprzęt i raporty.
Mogę zrealizować pełny kompleks integracji z Rekassa:
• pobieranie biletów przez ich API
• umieszczanie biletów na naszym serwerze pośrednim
• realizacja logiki dostępu dla bramki
• generowanie i wysyłanie raportów do odpowiedniej organizacji
• testowanie całego cyklu: “Rekassa → nasz serwer → bramka”
Orientacyjny koszt: 15 000 – 25 000 zł
Termin: 6–12 dni roboczych
( dokładniej powiem po otrzymaniu wymagań technicznych do raportów)
Dziękuję za udostępnienie archiwum — jestem gotów przystąpić po wyjaśnieniu szczegółów.
Budżet: 240 USD Termin: 1 dzień
Dzień dobry, jestem programistą Golang z 4-letnim doświadczeniem w pracy z Go, a także mam 8-letnie doświadczenie jako architekt w dużym handlu detalicznym.
Pisz, dogadamy się i zrealizujemy Twoje poprawki.
Stawka 30$/godzinę.
- Zlecenia 7
- Ocena 3.4
- Ranking -
Budżet: 500 USD Termin: 15 dni
Cześć.
Mogę zrealizować ten projekt, mam doświadczenie.
Zrobię w ustalonym terminie.
Budżet: 500 USD Termin: 15 dni
Cześć,
Usługa będzie rozwijana w Go z użyciem frameworka Gin i wdrażana na Ubuntu 22.04. Gin został wybrany ze względu na wysoką wydajność, minimalne obciążenie oraz solidne wsparcie dla opartych na JSON interfejsów API REST, co idealnie pasuje do wymagań komunikacji HTTP POST z Rekassa i wewnętrznymi interfejsami API. Usługa będzie współpracować z MySQL 5.7/8.0 w celu przechowywania biletów i dzienników zdarzeń. Obsługa offline będzie wspierana przez lokalne buforowanie i automatyczne ponawianie nieudanych żądań API. Bezpieczeństwo będzie zapewnione poprzez HTTPS dla wszystkich komunikacji.
Projekt będzie realizowany w podejściu fazowym:
Analiza wymagań i zaprojektowanie przepływu danych od zakupu biletu do weryfikacji dostępu.
Rozwój usługi backendowej w Go z użyciem Ginu do obsługi przyjmowania biletów, walidacji i przechowywania w bazie danych.
Integracja z serwerem Z5R-W w celu kontroli dostępu w czasie rzeczywistym, zwracając status przyznany lub odmówiony.
Implementacja automatycznego raportowania i rejestrowania zdarzeń dla SAK i raportowania organizacyjnego.
Przeprowadzenie testów i wdrożenie rozwiązania na Ubuntu z mechanizmami kopii zapasowej, monitorowania i ponawiania.
To podejście zapewnia niezawodny, łatwy w utrzymaniu i skalowalny system, który spełnia wszystkie wymagania techniczne i operacyjne. Użycie Ginu gwarantuje wysoką wydajność i efektywne przetwarzanie równoległych żądań, co jest kluczowe dla kontroli dostępu i procesów przetwarzania biletów.
Z poważaniem,
Jeo Vincent Carretas
Oferty ukryte
Aktualnie brak ofert
Aktualne zlecenia dla freelancerów w kategorii Parsowanie danych
Zadanie: jeden dashboard ze wszystkimi wskaźnikami biznesowymi — reklama, lejek, płatności, praca menedżerów, planowanie przychodu. Dane są pobierane automatycznie przez API. Zakres: tylko kierunek YCL (zatrudnienie w Europie). W Kommo są też inne kierunki — do magazynu trafiają tylko transakcje z lejek YCL (filtr według lejka/tagu ustalimy).1. Źródła danych (integracje) Kommo CRM — leady, transakcje, etapy lejka, odpowiedzialni, źródła, daty przejść między etapami (koniecznie zachować historię), przyczyny odmowy, pola niestandardowe transakcji (patrz p. 2). Stripe — płatności, kwoty, statusy (sukces/odmowa/zwrot), powiązanie z transakcją. Meta Ads — wydatki, wyświetlenia, kliknięcia, CPL, leady według kampanii (działa teraz). Google Ads, Reddit Ads, LinkedIn Ads — planowane; architektura — rozszerzalne konektory bez przeróbek rdzenia. SEO/organika— Google Search Console + GA4. Przeszły związek: źródło ruchu → lead w Kommo → płatność w Stripe (UTM, ID transakcji w metadanych Stripe — mechanikę zaproponować). 2. Obowiązkowe przekroje (pola transakcji w Kommo) Każda metryka musi być filtrowana/grupowana według: Obywatelstwo klienta (Kenia, Nigeria, Indie itp.). Status pobytu: mieszka w swoim kraju / ekspat (już przebywa w Europie). To dwa różne segmenty z różnym cyklem, konwersją i wartością transakcji. Kraj umiejscowienia / usługa: Polska, Serbia, Słowacja, Niemcy (ZAV). Menedżer, zespół, kanał ruchu, okres. Jeśli jakichś pól w Kommo brakuje — wykonawca wskazuje, jakie pola należy dodać, zamawiający dodaje.3. Lejek i wskaźniki wyprzedzające Dane w przekroju lejka, dla każdego etapu — podsumowujące i wyprzedzające (leading) metryki: Ruch → lead: leady, CPL według kanałów + dynamika wydatków/kliknięć dzień do dnia. Lead → kwalifikacja: konwersja + czas pierwszej odpowiedzi, kontakty/telefony do menedżera dziennie, leady bez odpowiedzi. Kwalifikacja → umowa/faktura: konwersja + wysłane oferty, zawieszone transakcje (dni na etapie powyżej normy). Faktura → płatność: płatności, średnia wartość transakcji + niezapłacone faktury, nieudane płatności. Podsumowanie: przychód, ROMI według kanałów, run rate do planu miesiąca. 4. Cykl transakcji Średni i medianowy cykl lead → płatność (punkt odniesienia biznesu ~4 tygodnie), trend cyklu w czasie. Rozkład cyklu według etapów (ile dni transakcja spędza na każdym etapie) — aby zobaczyć, który etap się wydłuża. Lista transakcji, które utknęły na etapie dłużej niż norma. Przekrój cyklu według segmentów: obywatelstwo, status pobytu, kraj umiejscowienia, menedżer. 5. Wczesne ostrzeżenie o spadku (kluczowy blok) Ponieważ cykl ~4 tygodnie, dzisiejsze leady = płatności za miesiąc. System powinien: Porównywać leady/kwalifikacje bieżącego tygodnia z średnią ruchomą (4 tygodnie) i przy odchyleniu w dół wydawać alert: „leadów −X%, przy cyklu 4 tygodnie oczekuj spadku płatności w tygodniu [daty]”. Budować prognozę płatności na 4 tygodnie do przodu z bieżącego pipeline'u: transakcje na każdym etapie × historyczna konwersja etapu × pozostały cykl. Podświetlać na czerwono tygodnie, gdzie prognoza jest niższa od planu — z zapasem czasu na reakcję. 6. Dopłaty i planowanie sprzedaży W karcie transakcji Kommo przechowywane są data i kwota planowanej dopłaty. System powinien: Zbierać kalendarz przyszłych dopłat: całkowita liczba oczekiwanych, według tygodni/miesięcy. Podświetlać przeterminowane dopłaty (data minęła, brak płatności w Stripe) — osobna lista do dociśnięcia. Liczyć plan miesiąca jako: plan − już opłacone − dopłaty zgodnie z harmonogramem = ile nowych sprzedaży potrzebnych (w pieniądzach i w sztukach transakcji przy średniej wartości transakcji). Harmonogram według tygodni: dopłaty + prognoza nowych płatności w stosunku do tygodniowego planu. 7. Praca menedżerów Dzienny przekrój dla każdego menedżera: kontakty/telefony, rozmowy, wysłane oferty, płatności — dla każdego dnia osobno, z wykresem za okres. Postęp realizacji osobistego planu w porównaniu z tempem miesiąca (na przodzie / w tempie / w tyle). Benchmarking z kolegami. 8. Wizualizacja i role „Sygnalizatory” (zielony/żółty/czerwony) w kluczowych metrykach w odniesieniu do norm/planu; skale postępu; wykresy trendów; adaptacja do urządzeń mobilnych. Role: CEO — wszystko; ROP — cały lejek i menedżerowie; team lead — swój zespół; menedżer — swoje wskaźniki i pozycja w stosunku do kolegów. 9. Raporty i AI Automatyczne raporty według harmonogramu (codzienne podsumowanie, tygodniowy raport) w dashboardzie i/lub komunikatorze. Zapytania w dowolnej formie („jak zmienił się CPL z Meta w ciągu 2 tygodni?”) — LLM nad magazynem. Alerty w strefie czerwonej oraz według zasad z p. 5–6. 10. Oczekiwania techniczne i etapowość Magazyn (PostgreSQL/BigQuery lub analog) + ETL: webhooks Kommo + okresowa synchronizacja (15–60 min). Frontend: niestandardowy lub narzędzie BI — zaproponować z uzasadnieniem; wymagania dotyczące ról, sygnalizatorów, prognoz i zapytań AI muszą być wykonalne. Etapy: (1) audyt i mapa metryk → (2) MVP: Kommo + Stripe + Meta, lejek, sygnalizatory, role → (3) cykl transakcji, wczesne ostrzeżenie, dopłaty i plan → (4) SEO, raporty AI, alerty → (5) nowe kanały reklamowe. Płatność etapowa, po każdym etapie — demo. W odpowiedzi proszę wskazać: podobne projekty (analiza przeszła), stack z uzasadnieniem, oszacowanie czasów i kosztów według etapów, miesięczny koszt posiadania (hosting, tokeny, licencje).
Potrzebny specjalista do zbierania i strukturyzowania otwartych informacji o sprzedawcach z marketplace'ów. Konieczne jest określenie możliwości automatycznego zbierania danych oraz utworzenie bazy sprzedawców. W odpowiedzi proszę podać: z jakimi marketplace'ami masz doświadczenie; jakie dane możesz uzyskać (nazwa sprzedawcy, link, kategorie, ocena, liczba produktów, inne dostępne pola); przykłady podobnych projektów.
Należy stworzyć bota Telegram do automatycznego wyszukiwania i monitorowania samochodów "BUY IT NOW" na aukcjach w USA (Copart, IAAI). Bot powinien działać w trybie automatycznym i wysyłać powiadomienia o nowych samochodach, które odpowiadają zadanym filtrom.Podstawowa funkcjonalnośćUstawienia filtrów: 1. Marka samochodu; 2. Model; 3. Rok produkcji (od/do); 4. Typ paliwa; 5. Pojemność silnika; 6. Przebieg; 7. Zakres cenowy; Funkcje bota: 1. Automatyczne monitorowanie nowych aukcji; 2. Sprawdzanie aktualizacji co 1-2 minuty; 3. Ochrona przed powtarzającymi się powiadomieniami (antyduplikat); 4. Możliwość dodawania i usuwania filtrów przez menu bota; 5. Zachowanie ustawień już istniejącego wyszukiwania samochodów. Format wiadomości: 1. Zdjęcie samochodu (4-zdjęcia); 2. Nazwa i numer aukcji; 3. Rok produkcji; 4. Przebieg; 5. Typ silnika i pojemność; 6. Cena buy it now; 7. Link do aukcji.
Wydobyć pełny katalog tych stron: https://svit-mebliv.ua/ https://kompanit.com.ua/ru https://amia.com.ua/ https://mebliromax.com.ua/ https://pehotin.com.ua/catalog/ https://www.sokme.ua/ru/ Wszystkie produkty muszą być połączone w jedną wspólną tabelę do importu do WP. Każdy produkt powinien być w dwóch językach (UA+RU). Są również produkty wariacyjne, które powinny być zachowane jako wariacje w podstawowej funkcjonalności WP. Import na stronę jest możliwy zarówno przez wtyczki, jak i rozwiązania niestandardowe, dlatego format tabeli może być omawiany