Jeśli istnieją dwa sposoby: szybsze i lepsze, czyni to lepsze.
Możesz odważnie wybrać.
Budżet: 100 UAH Termin: 1 dzień
Ja robię.
Budżet: 200 UAH Termin: 3 dni
Przygotowuje się do pisania scenariusza.
Делать алгоритм нереально, слишком много вариаций, формулой не обойдешься, а вот если бы не нa google декодировать, а на сайте, все было бы довольно просто
Игорь, смотрите с такой стороны
Надо короткий айдишник вводить в таблицу, дальше в таблице короткий айдишник декодируется обратно в исходный длинный и подставляется в формулу. Формула собирает значения с нескольких ячеек и превращает их в ссылку. Дальше при нажатии на эту ссылку идет передача данных в определенный сервис, в том числе и длинного id.
Теперь, может есть вариант декодировать это все не в google docks а на каком-то серверном приложении. Например в гуглдоксах формула собирает данные и формирует все туже ссылку, которая содержит короткий id. По нажатию на ссылку информация поступает в приложение, декодирует в ссылке короткий id на длинный, делает такую ссылку как нужно и делает по ней переход.
Что скажите?
Спасибо!
По нажатию на ссылку информация поступает в приложение. Приложение декодирует в ссылке короткий id на длинный, то есть, делает такую ссылку как нужно и делает по ней переход.
по скайпу к сожелению сейчас не могу
если что - почта vabz собака bk ру
пример запроса
www . google-analytics.com/collect?v=1&tid=UA-477854-1&cid=1223916595.1366127334&t=pageview
код который нужно кодировать - cid=1223916595.1366127334
ссылка может состоять еще и из других параметров.
прикрепляются через &параметр= в конце
Смотрите, если сделать так.
Сделать определенное приложение и разместить в папке сайта.
Дальше в любом месте можно составлять ссылку с необходимыми параметрами и делать по ней переход (excel, гугл док, блокнот..... и т.д.)
Ссылка будет примерно вида:
www. domain.com/decoding/cid=BTR789&..... остальные параметры
При переходе по ссылке информация поступает в приложение в папке сайта.
Оно берет cid=BTR789 кодирует обратно в длинный код, и склеивает с
www .google-analytics.com/collect?v=1&tid=UA-477854-1& и остальными параметрами.
То есть, получает полноценную нужную ссылку и делает по ней переход.
Только нужно сделать возможность изменять строку www . google-analytics.com/collect?v=1&tid=UA-477854-1&. По сути она статическая, но для разных сайтов будет разная.
Что скажите?
мне сложно сказать, я не знаю сколько времени будет занимать разработка.
предлагайте цену
по последнему получается что нужно:
1) скрипт который ставиться на каждую страницу сайта, кодирует передаваемое в него значение, и дает возможность выводить это значение на страницу
2) скрипт, который устанавливается на отдельную страницу, парсит всю ссылку по которой перешли на эту страницу, конвертирует ее по описанному алгоритму и делает по ней переход (типа клик)
Если нет никакой общей части у всех ID и никакого алгоритма создания этих идентификаторов, то есть все ID абсолютно уникальные, и изменяются не только последние разряды, то самый простой алгоритм - это перевод в другую систему счисления. Например с основанием 36 (можно взять больше, но из-за обилия символов будет каша)
1223916595.1366127334 будет выглядеть, как K8OS37.MLCULI
12239165951366127334 , как 2KZJQ8H8N1Q8S
Проще никак. Как видите, тоже не удобоваримое.
Если же анализировать все поступающие идентификаторы, то сложность алгоритма возрастет на порядок и это будет не одна формула, а куча функций.
Роман,
Общей части нет. Абсолютно уникальные.
Находил идентичные задачи, там предлагали кодировать в систему счисления 62. Типа использовать еще регистр букв и доп символы. С допсимволами может быть каша, как вы говорите, а вот с регистром думаю терпимо. Не нашел такого конвертера, поэтому не знаю какая длинна укороченного варианта получится. Даже 7-м символов было бы не плохо.
Что вы имеете ввиду : "если же анализировать все поступающие идентификаторы, то сложность алгоритма возрастет на порядок и это будет не одна формула, а куча функций."
На сайте генерится один id при заходе на сайт с одного браузера.
То есть кол-во id равно кол-ву уникальных заходов на сайт.
А декодироваться и отправляться в составе ссылки такие id будут еще реже.
кстати вот ссылка
https://ptrofimov.wordpress.com/2011/04/15/%D1%81%D0%BE%D0%BA%D1%80%D0%B0%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D1%81%D1%8B%D0%BB%D0%BE%D0%BA-%D0%BF%D0%B5%D1%80%D0%B5%D0%B2%D0%BE%D0%B4-id-%D0%B2-62-%D1%80%D0%B8%D1%87%D0%BD%D1%83%D1%8E-%D1%81/
Роман, есть еще один вариант. Вместо кодирования можно генерить свой код и складывать это все в таблицу-сравнений. Дальше из нее же извлекать.
Но в таком случае нужно установить время жизни свзяки "короткий код - длинный код".
Длинный код берется из cookie. Их срок жизни 24 мес после последнего захода на сайт.
Можно например добавить в таблицу поле с последним обращением, или обновлением куки. При нехватке комбинаций использовать самое старое.
Такое реально сделать?
Да, именно по такому принципу и работают сервисы коротких ссылок. Вы немного опередили меня. ) Я тут ломал голову на счет "анализа id".
В любом случае либо таблица соответствий, либо каша из половины символов юникода (даже при системе счисления с основанием 62 не получится 7 символов), либо больше семи знаков.
С идеей использования БД не все так гладко, там довольно непростой механизм, как кажется на первый взгляд. Да и нагрузку на базу лишнюю давать нежелательно.
Есть идея одного алгоритма без использования БД и соостветствий, который в конце концов должен будет привести к строке длиной не более заранее заданного количества знаков, но вопрос в том, насколько ресурсоемкая это задача - возможно будет много итераций и это будет нагружать процессор. Я еще не знаю, что лучше - пока одни только наброски.
по нагрузке на бд: добавление значений - зависит от кол-ва заходов на сайт (может быть 100, может быть 100 тыс в сутки). Но нужно учитывать только факт захода, а не весь сеанс. За длительное время размер базы может быть несколько миллионов, а то и десятков миллионов строк....
по кол-ву знаков в коротком коде 6 было бы отлично (без !"№;%:?*()_ и т.д. желательно )))))
ок, если сможете что-то предложить - пишите!
Я в общем-то когда-то делал подобное задание. Алгоритм очень прост был. С использованием БД 2 и несколько обращений к БД
Witam wszystkich, potrzebujemy stworzyć stronę internetową do organizacji wydarzeń i sprzedaży biletów. Możliwe opcje na gotowym szablonie, frameworku lub wasza propozycja. Preferowane, abyście mieli doświadczenie w tworzeniu stron internetowych do sprzedaży biletów. Przykłady stron prześlemy w prywatnych wiadomościach. W razie potrzeby stworzymy prototyp. Jeśli wcześniej pracowaliście nad tworzeniem podobnych stron, proszę o przesłanie przykładów w prywatnych wiadomościach. Szczegóły omówimy w prywatnych wiadomościach. Dziękuję i miłego dnia!
Co liczymy w projekcie: Zrealizowany PnL, ROI i Wskaźnik Wygranych dla portfeli kryptowalutowych - jak rentowny był portfel w handlu danym tokenem w wybranym okresie. Na jakich danych: historia transakcji on-chain portfela (swapy, przelewy tokenów) + cena rynkowa tokena w momencie każdej transakcji. Główne źródło danych - Moralis: dwa wywołania podczas początkowego załadowania portfela - natywne przelewy ETH i wszystkie przelewy tokenów ERC-20. Z czym porównujemy: Nansen.io - bierzemy jako wzorzec, porównujemy nasze obliczone metryki z tym, co pokazuje Nansen dla tych samych portfeli w tym samym okresie. Problem: nasze liczby znacznie różnią się od Nansen, i nie do końca rozumiemy, według jakich zasad część działań portfela powinna być klasyfikowana dla celów PnL. Należy poprawić obliczenia Zrealizowanego PnL, ROI i Wskaźnika Wygranych, aby zgadzały się z Nansenem. W zgłoszeniu proszę napisać: - doświadczenie w podobnych zadaniach - doświadczenie z Nansen - doświadczenie z Moralis - doświadczenie z DeFiLlama - doświadczenie z artykułami na temat operacji kryptowalutowych - przybliżony koszt i terminy poprawek
Strona działa na frameworku Next.js (opartym na React). Trzeba zrealizować wszystkie punkty zgodnie z TŻ. TŻ jest dołączone w pliku. Oczekuję na propozycje.
Strona do oceny: https://copy.eurobrands-shop.de/ Zadanie: naprawić błędy frontendowe na poziomie motywu Magento 2 / motyw Amasty: CSS/LESS/JS, mobilny, RTL, minicart, rozwijane menu językowe, przesunięcie układu/CLS. Format pracy: - bez lokalnego uruchamiania Magento; - praca przez DevTools + źródła motywu; - poprawki w plikach CSS/LESS/JS/template motywu; - wynik: diff / commit / archiwum zmienionych plików; - wdrożenie i budowa po naszej stronie; - praca przez bezpieczną transakcję; - NDA do przekazania źródeł/dostępów. Co należy sprawdzić i ocenić: 1. RTL / wersja arabska: - telefon w nagłówku wyświetla się niepoprawnie; - przesunięcia elementów w nagłówku, minicart, wishlist/konto, strona produktu; - marginesy, kierunek, unicode-bidi, pozycjonowanie. 2. Nagłówek: - rozwijane menu językowe; - koszyk/wishlist; - obszar kliknięcia ikon. 3. Minicart: - niestabilnie otwiera się na niektórych stronach; - sprawdzić Konsolę / Sieć / Nasłuchiwacze zdarzeń / dane klienta / z-index / nakładkę. 4. Mobilny: - etykiety koszyka/wishlist są zbyt duże; - blok Kategorii jest ściśnięty/obcięty; - mobilne menu / Menu-Konto. 5. Strona produktu: - przesunięcie układu / CLS obrazów; - Dodaj do koszyka / Ilość / BOX / PALLET w RTL. 6. Wishlist/konto: - /wishlist/ - /mwishlist/ - zakładki, przycisk Wstecz, przepełnienie liczników. Problemowe URL: - https://copy.eurobrands-shop.de/alpro - https://copy.eurobrands-shop.de/producers - https://copy.eurobrands-shop.de/wishlist/ - https://copy.eurobrands-shop.de/mwishlist/ W odpowiedzi napisz: 1. Czy masz doświadczenie z frontendem Magento 2? 2. Czy masz doświadczenie z RTL? 3. Ile godzin potrzebujesz na pierwszy etap? 4. Jaka jest cena? 5. Kiedy możesz zacząć? 6. Jakie dostępności są potrzebne? 7. Czy jesteś gotów pracować przez bezpieczną transakcję i podpisać NDA? Ważne: potrzebny jest konkretny wynik — poprawki lub techniczne wyjaśnienie dla każdego punktu: naprawione / nie reprodukuje się / nie jest problemem frontendowym.
Opis zamówienia: Poszukujemy doświadczonego frontend-dewelopera/specjalisty od OpenCart do optymalizacji szybkości ładowania strony (kategorie i karty produktów) zgodnie z wymaganiami Google Core Web Vitals. O projekcie: * CMS: OpenCart. * Specyfika: Strona działa w trybie katalogu (brak koszyka i składania zamówienia). * Zakres: 2900 pozycji. * Część serwerowa: Już zoptymalizowana (działa na OpenLiteSpeed). * Stos: Prace prowadzone są wyłącznie z kodem szablonu, modyfikatorami i frontendem. Bez pracy z bazą danych. Co należy zrobić (Zadanie techniczne): 1. Opóźnione ładowanie skryptów (Delay JS): * Problem: Zewnętrzne skrypty analityczne (GTM, Google Tag) blokują główny strumień na urządzeniach mobilnych przez około 4,3 sekundy. * Zadanie: Skonfigurować opóźnione uruchamianie tych skryptów. Skrypty powinny aktywować się ściśle po pierwszej akcji użytkownika (pierwsze przewinięcie, dotknięcie ekranu lub ruch myszą). * Ważne: Zbieranie statystyk, analityka i działanie reklamy muszą pozostać w pełnym zakresie. 2. Poprawa metryki CLS (Stabilność układu): * Problem: Strona "skacze" i przesuwa się podczas ładowania obrazków. * Zadanie: W plikach stylów lub szablonu motywu sztywno wpisać atrybuty HTML width i height dla wszystkich obrazów produktów w katalogu (listach) oraz kartach produktów. * Cel: Zarezerwować miejsce pod obrazki w drzewie DOM do ich faktycznego załadowania, aby uniemożliwić przesunięcie treści. Sprawdzić, aby responsywność (CSS) nie została uszkodzona. 3. Optymalizacja krytycznej ścieżki (LCP): * Zadanie: Wpisać dla głównego (najważniejszego) obrazu produktu na pierwszym ekranie tag fetchpriority="high". To da przeglądarce polecenie ładowania głównego zdjęcia produktu w priorytetowy sposób. Wymagania wobec wykonawcy i warunki przyjęcia: 1. Bez zbędnych modułów: Praca wykonywana jest czystym kodem/modyfikatorami, bez instalowania dodatkowych zewnętrznych lub płatnych wtyczek optymalizacyjnych. 2. Bezpieczeństwo i układ: Ponosisz pełną odpowiedzialność za układ. Po wprowadzeniu poprawek wizualne wyświetlanie strony na urządzeniach mobilnych i PC, a także funkcjonalność (filtry, przełączanie zdjęć w galerii, menu) muszą pozostać bez zmian. 3. Kryterium oddania pracy (DoD): Przedstawienie zrzutu ekranu oraz linku do żywego testu raportu Google PageSpeed Insights (dla wersji mobilnej). Wskaźnik wydajności nie może być niższy niż 75 punktów, a metryka CLS — nie więcej niż 0,1 (w zielonej strefie). Poprawki wprowadzać należy wyłącznie przez modyfikatory (OCMOD) lub kopię motywu, aby nie nadpisać aktualizacji jądra. W odpowiedzi proszę podać: 1. Czy miałeś doświadczenie w konfiguracji Delay JS właśnie dla GTM na OpenCart? 2. Termin realizacji zadania. 3. Koszt pracy.