Budżet: 1500 UAH Termin: 2 dni
Mam doświadczenie w pracy z parsowaniem i FastAPI, nie widzę nic skomplikowanego w waszym zadaniu.
Cześć, jest parser, oto jego kod:
https://github.com/0-EternalJunior-0/-autonewsparser
Programista gdzieś zniknął, a my musimy wprowadzić w nim poprawki. Przede wszystkim upewnić się, że jest skonfigurowany do automatycznego parsowania wiadomości według określonego kryterium, ponieważ teraz sprawia wrażenie, że parsowanie uruchamiane jest wyłącznie na polecenie. Jeśli automatyczne parsowanie nie jest skonfigurowane - trzeba je skonfigurować. Projekt jest uruchomiony na naszym serwerze, dostęp do niego damy wykonawcy.
Po drugie, oto lista zadań (do poprawy) od naszego programisty dotycząca API:
---
Nowe wymagane komendy API:
1.
Potrzebna jest komenda do zapytania N artykułów według dowolnego zapytania WHERE
można nazwać dowolnie, typ POST
dane wejściowe:
{
“where”:{
“field1”:”value1”,
“field2”:”value2”,
“field3”:”value3”
},
“limit”:10
}
wartość limit może być dowolna, ale można ją ograniczyć czymś, na przykład 100… jeśli limit nie zostanie podany - zwracać 1 artykuł (domyślnie)
w where mogą być przekazywane dowolne pola, wartości są zapisywane w string (dla uniwersalności)... mam nadzieję, że “1” i 1 przy zapytaniu do bazy danych będą tym samym, i nie spowodują błędu… przed złożeniem zapytania należy sprawdzić wszystkie przekazane parametry where pod kątem istnienia w tabeli, na przykład, za pomocą
SHOW COLUMNS FROM articles
lub
DESCRIBE articles
i jeśli jakieś pole nie istnieje, zwrócić błąd
na podstawie danych formułowane jest zapytanie do Bazy Danych w postaci
SELECT * FROM articles WHERE field1=’value1’ AND field2=’value2’ AND field3=’value3’ LIMIT 10
wszystkie parametry WHERE są łączone przez AND
i wszystkie wyniki ze wszystkimi polami są zwracane w odpowiedzi na zapytanie API… nie trzeba usuwać żadnych pól z odpowiedzi, trzeba zwrócić wszystkie, jakie są
2.
Potrzebna jest komenda do dowolnej edycji artykułu według id
można nazwać dowolnie, typ POST
dane wejściowe:
{
“set”:{
“field1”:”value1”,
“field2”:”value2”,
“field3”:”value3”
},
“id”:1
}
przed złożeniem zapytania należy sprawdzić wszystkie przekazane parametry set pod kątem istnienia w tabeli, na przykład, za pomocą
SHOW COLUMNS FROM articles
lub
DESCRIBE articles
i jeśli jakieś pole nie istnieje, zwrócić błąd
należy również zablokować przekazywanie id w sekcji set, i zwrócić błąd, jeśli tam zostanie wykryte id
“set”:{
“id”:”2”
},
to jest wyraźny błąd, id nie można zmieniać
na podstawie danych formułowane jest zapytanie do Bazy Danych w postaci
UPDATE articles SET field1=’value1’, field2=’value2’, field3=’value3’ WHERE id=1
w odpowiedzi na zapytanie API wystarczy zwrócić kod 200 przy udanej operacji, i inny kod z opisem błędu, jeśli coś poszło nie tak
WAŻNE:
Będę dodawać pola i indeksy do tabeli articles, dlatego potrzebne jest, aby obie komendy działały z dowolnymi polami, obecnymi i przyszłymi, a nie były ograniczone do obecnej struktury tabeli.
---
Po trzecie, trzeba zrozumieć, jak działa komenda usuwania, czy artykuły, które zostały usunięte komendą, nie będą ponownie parsowane.
Proszę przejrzeć kod. Nie ma potrzeby pisać parsera od zera, jeśli to konieczne.
Zaloguj się lub zarejestruj się, żeby zobaczyć oryginałBudżet: 1500 UAH Termin: 2 dni
Mam doświadczenie w pracy z parsowaniem i FastAPI, nie widzę nic skomplikowanego w waszym zadaniu.
Budżet: 1000 UAH Termin: 3 dni
Gotowy, aby się tym zająć.
Ale trzeba doprecyzować szczegóły zamówienia, piszcie!
Zrealizuję skryptem w pythonie.
Budżet: 2500 UAH Termin: 1 dzień
cześć. jestem gotów wprowadzić poprawki od razu. napisz proszę na priv, omówimy szczegóły i od razu mogę zacząć
Budżet: 2000 UAH Termin: 5 dni
Cześć, zajmowałem się tworzeniem parserów w różnych bibliotekach, proponuję przejść do wiadomości prywatnej w celu omówienia szczegółów realizacji oraz omówienia terminów i ceny.
Budżet: 2000 UAH Termin: 5 dni
Cześć! Zajmę się kodem, sprawdzę, czy automatyczne parsowanie jest ustawione, a jeśli nie — dodam. Dopracuję API według waszej listy: zrealizuję zapytanie N artykułów z filtrowaniem oraz edytowanie artykułu po ID z uwzględnieniem dynamicznej struktury bazy danych. Również przeanalizuję logikę usuwania, aby uniknąć ponownego parsowania usuniętych artykułów. Jestem gotów zająć się tym w najbliższym czasie i bez zbędnych pytań wykonać, piszcie, omówimy szczegóły
Budżet: 5000 UAH Termin: 7 dni
Cześć. Mam doświadczenie z Pythonem. Jestem gotów do współpracy. Proszę o kontakt.
Budżet: 1500 UAH Termin: 2 dni
Dobry wieczór
jestem gotów zająć się twoją pracą
Pisz, chętnie pomogę w twoim zadaniu
Zrobię to szybko i solidnie
Dzień dobry! Należy wykonać dwa zadania: 1. Opracować parser produktów z zewnętrznej strony (10–40 tys. pozycji, marketplace) z zachowaniem zorganizowanych danych w MySQL do późniejszego wyświetlenia w WordPressie. 2. Zainstalować i skonfigurować n8n na VPS, a także zorganizować przetwarzanie treści AI: konfiguracja promptów, przeredagowanie tekstów, przetwarzanie obrazów, optymalizacja SEO i sprawdzanie tekstów pod kątem detekcji AI. Można oszacować koszt realizacji zarówno całego projektu, jak i każdego zadania osobno. .
Trzeba wykonać parsowanie z kanałów Viber (Łączna liczba - 49 kanałów, około 80 tys. subskrybentów).
Dzień dobry. Potrzebny parser według słów kluczowych z wyświetlaniem wyników przez bota Telegram. Jak to ma działać: Automatyczne wyszukiwanie na 4 stronach według słów kluczowych, które czasami się zmieniają. Zapytania są wysyłane co kilka minut. Słowa są ładowane w formie pliku .txt. TG powinien zawierać przyciski: uruchom bota, zatrzymaj bota, pobierz plik (pobiera plik z aktualnymi słowami kluczowymi), załaduj plik (ładuje edytowany plik z nowymi słowami). Bots powinien ignorować wcześniej znalezione wyniki, tzn. nie wskazuje tego samego ogłoszenia dwa razy. Wynik przychodzi do bota w formie linku z zdjęciem, ale wystarczy też sam link. P.S. wyszukiwanie na stronach bez API, VPS na 6TB i 50 IP już są dostępne. Po szczegółowe informacje proszę kontaktować się na PW.
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.