Pamiętacie pewnie Winampa (no przecież to portal dla starych ludzi, to musicie pamiętać). Winamp przeszedł na open source, ale ktoś napisał bardzo gównianą licencję która nie pozwala na bardzo wiele podstawowych rzeczy w świecie open source, ale w tym, uwaga, na forkowanie repozytorium XD
W ten sposób uniemożliwili dostarczenie jakichkolwiek zmian bez łamania licencji XD
Rozpętała się piękna gównoburza, polecam wziąć popcorn i przejrzeć issues i pull requesty (również te zamknięte).
Niestety już usunęli zapis o zakazie forkowania (ciekawe czy złamali przy tym licencję), ale dalej wiele rzeczy jest zakazanych xd
widać, że noe potrafią w opensource, ale i tak mało firm decyduhe się na taki krok. Gdyby każda gra przechodziła na open source po 20 latach to retro gaming byłby dużo przyjemniejszy na nowych kompach. Już pomijając kompatybilność z systemem
Zajmuję się analityką internetową - zbieram i raportuję dane o tym, jak ludzie przeglądają strony internetowe.
Przez ostatnie kilka miesięcy pisałem sobie rozszerzenie do #chrome, które wizualizuje dane o klikniętych na stronie elementach - tzw "heatmapa", czy też "clickmapa".
Była to okazja żeby mieć sporo niecodziennych wyzwań do rozwiązania, i pomyślałem że się nimi podzielę. Ponieważ sporą część tego co musi być zrobione miałem w głowie i nie porywało mnie robienie jej, do stworzenia części kodu użyłem #chatgpt i #github #copilot , co też przyniosło ciekawe doświadczenia.
Są to totalnie geekowskie wynurzenia ale mam nadzieję znaleźć odrobinę przestrzeni gdzie mógłbym też zyskać może jakiś feedback na temat tego rozwiązania
Całość opiera się na zbieraniu selektorów CSS klikniętych elementów, a później pobieraniu tych danych i wizualizowaniu ich.
Sama komunikacja z zewnętrznym serwisem w Chrome Extensionie to już jest ciekawy fikoł, bo można to robić tylko z konkretnego kontekstu - service workera (a.k.a. background.js) - wymaga to przerzucania danych w odpowiednie miejsce (np. do otwartego taba przeglądarki), bo nie można ich pobrać "gdzie się chce"
Wizualizacja klikniętych elementów to fragment w którym mocno wspomagałem się AI - ChatGPT dobrze był w stanie zrozumieć o co mi chodzi i uwzględnić wymagania, ale jego sposób pracy potrafił się wahać z tygodnia na tydzień. W końcu przerzuciłem się na GitHub CoPilot ponieważ sugeruje na podstawie całego otwartego w #vscode projektu i bieżącego miejsca w kodzie. Czasem jak kulą w płot, ale zaoszczędził mi mnóstwo czasu. W sumie cały algorytm wizualizacji to jego dzieło którego staram się sam nie ruszać jedną z rzeczy, które AI rozwiązało jest kolejność renderowania elementów na podstawie sprawdzenia, który jest czyim dzieckiem, tak, aby nie było później zwizualizowanych elementów, których nie da się kliknąć.
Największym problemem, nad którym dumałem jak memiczny Pablo Escobar przez 1,5 miesiąca odkładając całość w kąt, było jak skonstruować toolbar wyświetlający się po kliknięciu danego elementu. No nie mogłem tego sobie dobrze wymyśleć biorąc pod uwagę to co chciałem zrobić, czyli doklejać go do już istniejącego elementu i pozwalać mu się rozwijać na obszar poza tym elemente. Z pomocą też pewnego wieczora przyszło AI, ale do rozwiązania o co je poprosić musiałem dotrzeć sam.
Nadawanie odpowiedniej kolorystyki w zależności od ilości kliknięć na dany element jest czymś co muszę jeszcze dopracować. Pierwsza wersja opierała się na przypisaniu natężenia jednego koloru, teraz już mam 2 kolory. Wymyśliłem sobie żeby dzielić skalę pomiedzy tymi 2 kolorami na liczbę kolorów odpowiadającą ilości elementów do pokolorowania, ale to nie daje wyraźnych wizualnie efektów, więc wprowadziłem dodatkowy model który elementy z największą ilością kliknięć doboostowuje na podstawie tego, które mają miejsce w datasecie (bo jest on posortowany od najbardziej klikanych elementów)
Potrafią się też zdarzać uszkodzone dane z niewłaściwymi, urwanymi selektorami CSS - trzeba je w miarę możliwości oczyszczać i wizualizować na najbliższym elemencie
Niektóre elementy na stronach, gdy są kliknięte, potrafią zwracać inne selektory np zawierające klasę "active". Żeby te dane łączyć (chociaż chyba mi to jeszcze nie do końca działa ) też zrobiłem dedykowaną temu funkcjonalność.
Problem, którego jeszcze nie rozwiązałem: przy używaniu google translate, mogą się zmieniać wykrywane selektory CSS klikniętych elementów, bo jest w nich dodatkowo umieszczany tag <font> albo i dwa
Popełniłem też sporo mniejszych, czeskich błędów przy obsłudze dość złożonego API - tym lepiej miałem okazję się go nauczyć
GitHub CoPilot dobrze się u mnie zadomowił. Zrobiłem kilka zrzutów które chcę zmontować w filmik o nim, gdzie mam przykłady i dobrych i kiepskich jego zachowań. Czasem trzeba go lekko szturchnąć w odpowiednim kierunku, i potrafi dużo pomóc, ale czasem jest zupełnie bezużyteczny i kręci się w kółko jak 5 latek
No i taka robota. Mi się bardzo przyda w mojej codziennej pracy. Jak coś, to extension współpracuje z analityką Piwik PRO, która ma dwie zalety - jest robiona w Polsce i jest darmowa do 500 tys. eventów miesięcznie ( ͡° ͜ʖ ͡°) #toniejestreklama, może się komuś przyda, a samo rozszerzenie tu: https://logbaker.com , a filmik mam nadzieję że się osadzi: https://www.youtube.com/watch?v=wJSYjGRO5YM
Jeśli ktoś ma pytania dot. developmentu chrome extensiona też chętnie odpowiem na tyle ile wiem
pytanie zasadnicze: co cię motywowało do tworzenia własnego rozwiązania?
Gotowych rozwiązań do heatmap było sporo (nie robię w tej branży od wielu lat, toteż na bieżąco już nie jestem) i głównym problemem była ich ociężałość. Ale nie wspomniałeś o gotowcach w ogóle, toteż jestem ciekaw czy krojenie żadnego gotowca nie byłoby "bardziej".
Druga rzecz to selektory.
Jak zbierasz dane dot. selektorów obejmujących całą szerokość lub wysokość widocznego
@VonTrupka motywacja do stworzenia własnego rozwiązania była taka, że już tej platformy używałem, a rozwiązanie w niej zawarte nie było wystarczające. A nie chciałem do samych heatmap zaprzęgać zawsze kolejnego rozwiązania, skoro to już mam działające. Oczywiście, jest wiele rozwiązań, ale każde ma swoje wady i zalety oraz koszty. A tutaj wiem dokładnie jakie dane przetwarzam i co chcę z nimi zrobić
Jest jeszcze aspekt prywatności przetwarzania danych - dla wielu firm istotny - a przy niektórych rozwiązaniach potrafi to być bardzo niejasne (patrz: MS Clarity). Piwik ma to dobrze ograne dzięki anonimizacji.
Co do selektorów - jeśli element ma całą wysokość lub szerokość viewportu, to jest zbierany tak samo (np body) - i na nim też są wizualizowane kliknięcia, najczęściej te nieintencjonalne - jeśli dobrze rozumiem o co pytasz ale z defaulta ignoruję wizualizowanie kliknięć na tych elementach właśnie z tego względu - nie mają znaczenia dla analizy tych faktycznie interaktywnych elementów, zaburzają ją
założyłem defaultowo self hosted rozwiązania, chmurowatość to dla mnie ostateczność
przy czym i tak prędzej odpuściłbym 3rd party hosted niż go użył
tzn ogólnie rzecz biorąc i afair liczone były współrzędne kursora podczas wywoływania eventu i normalizowane względem - hgw, jak to określić - rozmiarów strony lub głównego kontenera.
I tutaj pytanie moje dotyczyło selektora elementu który ma dużą szerokość lub wysokość a jest w zasadzie pusty. No jeszcze wypadałoby uściślić jakiego typu selektory i czy są unikatowe, bo w przypadku klas to odróżnienie klikniętego elementu tylko na tej podstawie byłoby ... trudne
nie miał się kiedy #github wy⁎⁎⁎ać na plecy tylko tuż przed tym, gdy pozostało mi pobrać zaktualizowaną bibliotekę, puścić na serwer, zamknąć wszystko wpizdu i iść spać ヽ(｀⌒´メ)ノ
Well, the rules for getting a GitHub PR merged by @torvalds are here, so it is not impossible: #17 (comment). Just very uncommon. It only happened 10 times.
No Linux PRs have ever been merged via GitHub. What happened here is that a random person submitted a branch that was already sent to Linus via a mailing list PR.
This is the real (non-GitHub) PR. The timestamp is Sun, 31 Mar 2024 1011 UTC. @ammarfaizi2 then opened this GitHub PR at 12:37 UTC, a couple hours later, using the exact same commit hash, even though he is neither the commit author nor the person making the PR. Then when Linus merged this (again, not involving GitHub at all) into mainline, and this mirror was updated to include the merge commit, GitHub marked the PR as merged since the commit that this PR was attempting to merge was, in fact, merged (this is a GitHub feature that works as long as the commit hash is identical, and included in a subsequent merge commit). At no point was GitHub involved in the process with the actual kernel community, and as far as I can tell @ammarfaizi2 is just a random who had nothing to do with the commit, nor the real PR, or anything else.
Anyone can do this by running ahead of Linus on any non-GitHub kernel pull request and opening a PR here. It's just a stupid trick to make it look like Linus merged your PR via GitHub, even though that never actually was the case.
You can submit Linux kernel changes to upstream maintainers from GitHub-hosted branches, I've done so myself. But it's via mail PR, and GitHub in that case is just treated as an arbitrary Git hosting site. The GitHub web interface PRs are never used.
@Deykun Lol ale opcja xD. Coś czuje, że teraz będzie więcej takich bo każdy by chciał mieć swojego commita do jądra Linuxa i pewnie GitHub to zaraz zateguje.
instalujesz na serwerze lub serwerach i można wyklikać sobie setup aplikacji. Bazy danych, redisy, inne komponenty, zintegrować od razu z git repo by był automatyczny deployment. Polecam zainstalować sobie na jakiejś vm’ce lub lxc.
Małe projekty zazwyczaj robię w TDD. Czyli najpierw piszę testy bo wtedy gdy piszę testy to od razu wiem czego od programu oczekuję, a potem gdy mam nawet 15 min wolnego czasu to naprawiam kod aby przechodIł dany test.
Przy większych projektach zazwyczaj mi się to nie sprawdza bo za dużo czasu idzie na przepisywanie testów gdy koncepcja się zmienia, ale piszę testy gdy coś implementuję. Gdy test testuje moją apkę zamiast (robić to manualnie) to wiem, że zrobi to tak samo za każdym razem
@dotevo akurat w rust pisanie testów tak mi jakoś bardzo dobrze podchodzi. Ale to prawda jak koncepcja się szybko zmienia albo to POC to testowanie czasem bywa bez sensu
Zdecydowanie zawiedziecie się na tej książce, jeśli sądzicie, że znajdziecie w niej rozwiązania najczęstszych problemów związanych z kluczami do repozytoriów. Zatem jeśli masz problem np. z dostępem do githubowego repo, mimo pozornie poprawnie skonfigurowanego klucza, to lepszym pomysłem jest przeszukanie Stacka i dokumentacji, aniżeli lektura tej książki.
Jeśli zaś ktoś poszukuje innych wrażeń z lektury, to nie oceniam (bo nie czytałem xD), może ta książka spełni takie oczekiwania.
Przepraszam, ale po prostu nie mogłem się powstrzymać, jak zobaczyłem ten tytuł. xD Może kogoś też to rozbawi.
Z okazji dostania z pracy dostępu do GitHub Copilota, uznałem że pobawię się językami, które znam tylko z grubsza.
Po dwóch latach klepania głównie Pythona i sieciowych konfiguracji, zacząłem robić Advent of Code w C++.
Ale to jest kwadratowy język xD Jakieś vectory, cout'y, standard outputy. Nie przypominam sobie kiedy ostatnio musiałem definiować typ jakiejś zmiennej przed inicjalizacją, a co dopiero długość listy (znaczy się tablicy).
Niemniej bawię się świetnie. Dobra opcja na odświeżenie sobie podstaw.
@lukmar ten język jest kwadratowy z zupełnie innych względów. Sam proces kompilacji potrafi być drogą przez mękę, a jeszcze standard, który bardziej przypomina rzeźbę z gówna niż nowoczesny i spójny język programowania.
@MostlyRenegade Myślę że takie niuanse bym odkrywał dopiero pracując przy produkcyjnym kodzie. Na to się nie zapowiada na razie. Ale generalnie myślę że warto wiedzieć "z czym to się je".
@lukmar a, i jeszcze bym zapomniał o j*baniu się ze wskaźnikami i ręcznym zarządzaniu pamięcią. Co prawda ostatnio jest w tym względzie progres, ale dotyczy w sumie tylko rzeczy względnie nowych lub napisanych własnoręcznie. Bo jak dostaniesz jakieś stare api, to masz przerąbane jak w ruskim czołgu.
@piotrb a no widzisz. Moje jedyne doświadczenie z C++ to był jeden semestr na studiach kilka lat temu. Tam nas nauczyli żeby wszystko robić na tablicach, więc w mojej głowie to zostało jako standard.
Teraz copilot podpowiada mi vectory, ale jakoś tak nadal intuicyjnie wracam do tablic. Rozumiem że nie powinienem?
Niemniej sporo prawdy w tym że jestem w bańce. Od jakichś dwóch lat 90% kodu jaki piszę to python. Żeby było śmieszniej, kiedy jeszcze w poprzedniej pracy pisałem głównie w C#, to broniłem się przed tym pythonem rękami i nogami xd
Polityka to nie programowanie. Zakładasz że wszyscy dążą do tego samego celu i kazdy robi jakas część a w cale nie jest. Każdy z nich robi wszystko bo chcą wszystko robić po swojemu
Każdy chce być masterem a slavey mogą się czasami z nimi zgodzić ale to nie ma żadnego znaczenia
@fewtoast szukałbym raczej rozwiązań z teorii gier. Programowanie to ćwiczenie we współpracy. Polityka niekoniecznie, bo cele bywają rozbieżne przez wartości, religie, wizje życia i funkcjonowania społeczeństwa.
Mam konto github, którego używam jako nośnika moich kodów.
Na głównym komputerze oraz na laptopie mam Visual Studio Code.
Github jest mi potrzebny, bo nigdy nie wiem na którym z dwóch komputerów będę mógł pisać - na głównym lub (w zastępstwie) laptopie, gdy żona ma jakąś robotę i główne biurko okupuje.
Udało mi się założyć repozytorium dla jednego z projektów, które się automatycznie zapisuje na githubie z poziomu obu komputerów. Dla obu musiałem utworzyć klucze ssh z pomocą jakiegoś poradnika z YT.
PYTANIE - chcąc założyć drugie repozytorium, gdzie będę pisał osobny kod (w praktyce na obu komputerach osobny folder) - czy muszę mieć osobny klucz ssh do tego repozytorium?
Czy ssh dotyczy komputera jako urządzenia, czy projektu?
@yourij Klucz publiczny w Githubie odnosi się jedynie do plika z kluczem prywatnym na komputerze. Jeśli nie mieszasz nic w kluczach/nie tworzysz nowych/nie modyfikujesz starych, to powinno działać to od razu w każdym projekcie
@yourij Klucz SSH to tak jakby Twój dowód osobisty, i potwierdzenie przed GitHubem że Ty to Ty. Skoro masz go poprawnie skonfigurowanego na GitHubie wzgledem obu komputerów, to możesz teraz trzaskać nowymi repozytoriami aż będzie huczało
@yourij Jak na przyszłość będziesz debugować takie rzeczy to spróbuj komendy ssh [email protected]. Powinieneś dostać informacje zwrotną że wszystko OK, ale w razie gdyby nie, to wystarczy że będziesz doklejał flagi -v aż nie znajdziesz czegoś przydatnego (np ssh -vvv [email protected] oznacza "very very verbose" czyli dużo informacji dokleja xD)
