•  

    Zaczynam nowy projekt dla #devopsiarz - trackowanie linków, które dla Was zamieszczam, aby wiedzieć, w co najczęściej klikacie (i zamieszczać tym samym więcej "lepszych" dla Was linków). Nawet sobie już domenę sprawiłem w promocji biedronkowej, także nie ma odwrotu ( ͡° ͜ʖ ͡°). Generalnie chodzi o to, że klikacie w devopsiarz.link/acbde i ten adres "przenosi" do właściwego linku jednocześnie zbierając dla mnie info, że "devopsiarz, ktoś użył tego linka X razy". Oczywiście ktoś musi tam do systemu linki słać, najlepiej autoryzowany, a system je "zbierać" i to też winno być obsługiwane, najlepiej "taśmowo".

    Projekt jest backendowy (na razie), z wykorzystaniem #rustlang i cockroachdb. Tyle ze stacku wiem na ten moment. Na początek #eventstorming - zanim napiszemy jakikolwiek kod, prześledzimy jak ten system ma działać, co powinien robić, gdzie mogą wystąpić jakieś problemy. Spróbuję odkryć te błędy zanim na nie wpadnę podczas wpisania kodu (albo jeszcze później). Na pewno główne relacje planuję dla mojej listy mailingowej i na stronie https://devopsiarz.pl, nie są wykluczone jakieś live na YT - muszę jeszcze to przemyśleć, jak to zrobić, aby nie zanudzić.

    Jeśli chcecie zobaczyć taki gównoprojekt rozwijany na #backend od zupełnych podstaw, ciekawi Was jakie problemy mi się literalnie zwalą mi na głowę podczas pracy nad nim lub nawet chcecie znajdować babole np. w moim eventstormingu to zapraszam do zapisu do mojego mailingu lub do obserwowania #devopsiarz - tutaj jedynie większe podsumowania/skróciki będę wrzucał.

    Oczywiście wraz z rozwojem projektu coraz więcej z #devops trzeba będzie w nim robić, więc nie tylko samo kodowanie.

    #rustlang, ale ponieważ ja super biegły w nim jeszcze nie jestem, to jest możliwy failback do #golang, ale będę się starał tego uniknąć jak tylko się da, bo chcę w końcu coś większego w nim napisać.

    PS Jak twierdzisz, że to prosty projekt to zapraszam do śledzenia, bo sam po pierwszym testowym eventstormingu jestem rozwalony co tam trzeba wziąć pod uwagę.

    #programowanie #technologia #software

    •  

      @devopsiarz: będziesz uzasadniał jakiś wybór tego stacku? Wygląda trochę jak micro google analytics

    •  

      @davoid: myślę, że uzasadnianie mnie nie ominie. Co do GA, to super na GA się nie znam, ale to zupełnie coś innego w zasadzie działania. Są serwisy SaaS, które oferują taką "usługę", często odpłatnie, ale nie spełniają moich potrzeb jak je testowałem.

    •  

      @devopsiarz: stack brzmi jak armata na muchę.

    •  

      @devopsiarz: Ja mam taki wniosek nieformalny co do linków: dawaj najpierw opis, a pod nim link, bo teraz dajesz na odwrót i źle się te mailingi czyta

    •  

      @Hauleth: skąd wniosek? Przeczytałeś z grubsza jak apka ma działać i już to wiesz? ( ͡° ͜ʖ ͡°)

      Rust, bo chcę się go douczyć + jego rozbudowane typowanie, statyczną binarkę, wydajność też mi nie zaszkodzi (cache to nie będzie coś zewnętrznego ala redis, tylko jakiś strukt/hashmapa w Ruście). Cockroach, bo mam bazę w 1 binarce, łatwy deploy, w razie czego pięknie się skaluje (kosztem wydajności, ale po to cache), a wsparcie dla ACID jest wystarczające dla potrzeb takiego projektu.

      // edit: być może to jest armata na muchę, nie wiem, ale chętnie poznam argumenty

    •  

      @Cesarz_Polski: serio piszesz o mailingach, czy masz na myśli stronę/wykop? Bo w mailingu prędzej jest opis przed linkiem ( ͡° ͜ʖ ͡°)

    •  

      @devopsiarz: Tak, o mailingach z zestawieniem. Dostaję w takiej samej formie jak masz na stronie, czyli link i dopiero opis

      . . . kliknij, aby rozwinąć obrazek . . .

      źródło: IMG_5712.PNG

    •  

      @devopsiarz: bo URL shortner to najprostsza rzecz pod słońcem. Tutaj masz to w 1 pliku Rubiego, co napisałem jakiś czas temu. Możnaby to zrobić nawet bez DB jak się uprzeć (składować dane zwyczajnie w plikach), ale to by było trochę jak pisanie prostej DB samodzielnie.

      +: leoha
    •  

      @Hauleth: rozumiem, ale w wymaganiach u mnie jest jeszcze:

      1) cache, także lista zablokowanych - nie chcę przecież, by ktoś mi ciągle pukał do endpointa i marnował CPU na zbyt wiele requestów lub marnował CPU, jak wylądował na liście zablokowanych

      2) trackowanie linków (przykład: unikalność na podstawie linkcode+ip na 24h), trackowanie user agent. Dobrze unikalność mieć konfigurowaną, jak się okaże, że inna metodyka może być lepsza

      3) limity - jak np. jakiś adres ip LUB kombinacja linkcode (bo przecież z powodu DoS, różne ipeki mogą ten sam link requestować) przegnie z ilością requestów per jednostkę czasu - na listę zablokowanych na jakiś czas. Inaczej co złośliwi będą stale "pukać" do serwera i tracić zasoby

      4) listę linków przygotowuję finalnie w pliku *.md - używasz hugo to prawdopodobnie wiesz, chcę taki plik wysłać systemowi, by system "pozamieniał" mi automatycznie normalne linki na trackowane, oczywiście rozróżniając czy już jakieś ma, czy link jest działający (nie zwraca 404 czy np. 50X), czy omyłkowo tam trackowanych już nie wsadziłem, czy któryś link w zestawieniu już wcześniej się nie pojawił (też ważne), i finalnie, w odpowiedzi, zwrócił mi *.md z linkami trackowalnymi gotowego do publikacji w różnych miejscach. A tu z kolei dobrze by było, gdyby zwracał jeszcze (na żądanie) wersję dla subskrybentów (pełna lista), na stronę (mniejsza lista), wykop (jeszcze mniejsza lista).

      5) Autoryzacja, w końcu tylko ktoś zautoryzowany powinien móc *.md wysyłać, a nie pierwsza lepsza osoba, która znajdzie usługę. Ale załóżmy, że mi kod/hasło wycieknie, wtedy dobrze by było pomyśleć, aby generator wyjściowego md nie zrobił jakiegoś RCE na serwerze jak dostanie złośliwego *.md

      6) Coś co jeszcze wyjdzie na eventstormingu, a czasem "ciekawostki" wychodzą - stawiam dolary przeciw orzechom, że nawet jakby brać jedynie wyłącznie samą funkcjonalność skracania linka, to Twój super prosty program pominął sporo edge cases, a to ma być wystawione w świat, a nie siedzieć sobie na githubie i się prezentować. Zapuściłeś jakiś fuzzer http, który sobie robił jaja na tych endpointach u Ciebie, czy zaufałeś funkcjom bibliotecznym, że na pewno dobrze wszystko parsują?

      Także obstawiam przy stwierdzeniu, że taki system, jest prostszy do opisania niż do zaprojektowania i napisania.

    •  

      nie chcę przecież, by ktoś mi ciągle pukał do endpointa i marnował CPU na zbyt wiele requestów

      @devopsiarz: fail2ban

      trackowanie linków (przykład: unikalność na podstawie linkcode+ip na 24h), trackowanie user agent. Dobrze unikalność mieć konfigurowaną, jak się okaże, że inna metodyka może być lepsza

      @devopsiarz: to też można tutaj dodać w parę chwil. Albo używając Postgresa i HyperLogLog, albo dodając Prometheusa czy inny system monitoringu.

    •  

      @devopsiarz: dziwne ze najpierw wybieracie stack technologiczny a pozniej "przesledzimy jsk to ma dzialac". Od dupy strony troche. Technologie dobiera sie do wymagan a nie odwrotnie.

    •  

      @Hauleth: z całym szacunkiem, ale jeśli piszesz tylko o swoim kodzie, do którego tu zalinkowałeś, to właśnie dodałeś co najmniej 1 lub 2 technologie ekstra do najprostszej rzeczy pod słońcem, cytując Ciebie, a to bez żadnej weryfikacji, czy w ogóle mają w tym wypadku sens. I w ten lajtowy sposób, zaadresowałeś jedynie (tu załóżmy, że dobrze) 2 wymagania z iluś tam wymienionych przeze mnie.

      @leoha: nie "wybieracie", a "wybieram", bo projekt robię sam, więc mam ten komfort, że mogę sobie stack wybrać. Ponieważ chciałem coś takiego napisać w Ruście, w celach szkoleniowych, to tak Rust znalazł się w stacku, ale mam dobre argumenty dlaczego akurat Rust. Jakby moim celem było zrobienie go jak najszybciej i najprościej, wówczas Rusta zamieniłbym jedynie na Pythona i to zasadniczo tyle zmian by było (CockroachDB jest wystarczająco prosty i przyjemny). Oczywiście możemy dyskutować tu nt. architektury i dlaczego, Twoim zdaniem, to było od dupy strony - nie odżegnuję się. Ale dokładniej będę omawiał jak będę robił relację z przebiegu projektu.

      A jakbym pracował w obcym projekcie, to dostosowałbym się pod stack danego projektu i wymagania zespołu, tu chyba sprawa jest jasna. Wtedy byśmy "wybierali".