From 0ce3503b77445fb1a87fb54ce50454a500560fe9 Mon Sep 17 00:00:00 2001 From: Jakub Zych Date: Tue, 17 Feb 2026 23:49:54 +0100 Subject: [PATCH] Stack feedback --- docs/conversations/stack_feedback.md | 129 ++++++++++++++++++++++++++ docs/conversations/stack_feedback2.md | 67 +++++++++++++ 2 files changed, 196 insertions(+) create mode 100644 docs/conversations/stack_feedback.md create mode 100644 docs/conversations/stack_feedback2.md diff --git a/docs/conversations/stack_feedback.md b/docs/conversations/stack_feedback.md new file mode 100644 index 0000000..5a51c55 --- /dev/null +++ b/docs/conversations/stack_feedback.md @@ -0,0 +1,129 @@ +logging: absolutnie żadnego kurwa slf4j, logging robimy przez scribe z bindingiem scribe dla slf4j, absolutnie wykurwisty performance, konfigurowalność w kodzie zamiast w gównoxmlu, brak chorych reguł resolve'owania konfiguracji, just works + +caching ok + +config: hocon, owszem, ale przez moją bibliotekę do konfiguracji: https://github.com/lbialy/jig główny argument jest taki, że obsługuje reading & writing, łącznie z komentarzami, zdecydowanie poprawi nam temat discoverability i zrozumienia konfiguracji dla llmów, mam nad tym 100% kontroli też co jest winem bo możemy dodawać ficzury jakie potrzebujemy + +json: wyłącznie jsoniter-scala, jedyna libka która nie jest niedojebana, możliwe że będziemy musieli zrobić swój wrapper na nią, pracowałem nad nim i dotarłem do jakichś 75% done, autor jest WYBITNYM akustykiem, to najszybsza libka do jsonów na JVMie bo gość chodzi i sprawdza jakie instrukcje dla cpu wypluł jvm i odcina od tego + +hashing: tu sytuacja jest względnie prosta, to co jest w jdk jest z reguły good enough, jak performance jest konieczny to bouncy castle przez jni + + +email: tu z kolei sytuacja jest trudna, dla emaili najważniejsze to jest mieć dobry interfejs i wiele bindingów, w tym najważniejsze pewnie to AWSowy sender itp, jakarta email to trochę legacy shitlib, nie wiem czy jest sens się bić z nią, to javowy soft i ma javowe failure modes, emaile są zbyt istotne żeby się martwić dziwnymi nullpointerexception z gównokodu + +admin frontend to nie moja działka natomiast w pełni się zgadzam z generowaniem bindingów do TSa z tapirowych definicji endpointów, co więcej robiłem to już i mam do tego szablon + +możemy mieć 1:1 do api i wykrywanie dryfu, projekt rnd który aktualnie wciąż prowadzę (Yaga latająca na Besom) to dosłownie to - statyczna weryfikacja że usługi się ze sobą zepną poprawnie po deploymencie, mam know how jak to zrobić zarówno w fast dev loop jak i w gwarantowanych deploymentach) + + +template engine to jak faktycznie chcesz zachować Twiga to pebble nie jest zły, do Scalate bym się nie zbliżał bo to japoński abandonware, ile razy wchodzę w interakcje z tamtą stroną community, jest to dziwne, to jak rozmowy z peonami w fel hordzie, robią rzeczy ale no jak bici niewolnicy + +japońska scala to ogólnie strasznie dziwny świat, ludzie tam są dosłownie zerg drones w korpo + +pebble by zachował Ci to co znasz plus potencjalnie możliwość reloadowania bez rebuildów aplikacji ale to jest do zbadania, pebble jako wtyczka do springa ma swoje java enterprise idiosynkrazje - np szuka szablonów na classpath resources path + +jak już wspominałem to nie jest optymalne bo classpath jest statyczny bez osgi więc musiałbyś restartować usługę, kosztowne w devloop, można iść pogadać z perplexity albo nawet https://deepwiki.com/PebbleTemplates/pebble + + +i zapytać czy możemy go używać jako file-based templating system i czy jak ładuje z plików to może robić hot reloady + +jak nie może to możemy my zrobić autoreloading na watcherze plików i przeładowywać cały system szablonów na zmianie w plikach + +cli: absolutnie i w żadnym wypadku nie ładujemy się ani w scopta (śmietnik, dużo głupich założeń, daleko od best practices) ani w decline (bardzo złożone, ekstremalnie elastyczne funkcyjne gówno, fajne, bardzo je lubię i jakbym miał robić naprawdę pogięte CLI to pewnie best choice ale LLMy się pojebią w tym jak używać tej mocy), użyjemy case-app od alexa archambault, alex jest ziomkiem, to francuski akustyk, dogadalibyście się Kuba (pomijając to że nie da się zrozumieć co mówi przez ciężki francuski akcent) bo to typ od getting shit done HOWEVER, oryginalny autor scala-cli, najebał tak dużo ficzurów że Piotrek, który to maintainuje ma trochę lipton + +case-app generuje automatycznie helpa, dostajesz parsowane case classy + +bardzo bardzo ładne narzędzie, z czasem pokochałem je całym serduszkiem + +co do testów - munit, żadnego scalatest, scalatest jest wiecznym generatorem migren dla nas, jego autorzy to leśne dziadki robiące absolutnie koszmarne rzeczy w buildzie, nie ufam tej bibliotece już w ogóle, rugpullowali nas regularnie + +ostatni rugpull to to że wydanie tej samej wersji dla scali-jvm i scali-native zawiera inne symbole w paczce bo mają jakieś kurwa build macros wykluczajace subpaczki które się im nie kompilują + +ffs zamiast naprawić wyjebują chirurgicznie części libki i na jednej platformie coś działa, a na innej dostajesz linkage errors + +dzbany + +co do testów to tu jest trochę otwartej przestrzeni żeby zrobić rzeczy naprawdę dobrze, ja jestem zdecydowanym zwolennikiem testowania integracyjnie z LLMami + +do tego używa się dużo testcontainers-scala + +przykładowo testy na postgresa to absolutnie must + + +co do jeszcze http + +on tam kombinuje z jakims summer-surf pod temat http + +ale my mamy temat http ogarnięty fantastycznie w stacku vl/sml + +tapir jest biblioteką do endpointów zbudowaną na wspólnym DSLu do http libki klienckiej http która się nazywa sttp + +sttp będzie naszym klientem http na 200% bo to najlepsza rzecz na naszym rynku + +sttp i tapir ogarniają sesje, cookies, streaming, http auth + +ale nie ogarniają jwt, jwt to osobny temat, w ostatnim projekcie komercyjnym (kotlin) pisałem jwt, nie ma w scali aktualnie dobrego rozwiązania do jwt ale to co używaliśmy w springu było good enough, myślę że możemy to bezpiecznie wpieprzyć + +11:17 + +co do tego: + +SLF4J is already a logging facade. Wrapping a facade with another facade adds zero value. Just use SLF4J + Logback directly. Direct SLF4J usage +to mogę tylko powiedzieć że to jest taka rada jakby Ci kolega powiedział "jasne, będziemy wbijać sobie w chuja gwoździe, wszyscy tak robią, to jest proste, po prostu będziemy wbijać w chuja gwoździe. bezpośrednio" + + +no i zostaje temat summer-lagoon + +tu jest kurwa pole do popisu i moim zdaniem to jest showstopper + +problem jest taki, w javie i php jesteś przyzwyczajony do flow: + +$user = User::findByName("ten jebany retard"); +$user->firstName = "Raziel"; +$user->save(); +w javie to działa ciut inaczej (jak Doctrine w Symfony) + +co oznacza generalnie że piszesz coś takiego: + +@Transactional +HttpResponse onPostTwojaStara(HttpRequest req) { +User user = UserRepository.findByName(req.body.name); +user.setFirstName("Raziel"); +return HttpResponse.success(); +} +tutaj @Transactional otwiera Unit of Work, ono śledzi mutacje na encji i na zamknięciu tej metody generuje UPDATE'y i wpierdala je w transakcji do bazy + +ale ani tamto pierwsze ani tamto drugie nie zadziała w Scali + +nie zadziała bo w Scali nie mutujemy pól na klasach + +to robi dużo dziwnych problemów + +przykładowo relacje w php w Eloquent są dynamicznymi metodami i dynamicznymi mutowalnymi polami + +relacje będą najtrudniejsze do zamodelowania + +same zmiany na pojedyńczych encjach są proste + +transact: +val user = UserRepo.findByName("ten jebany retard") +UserRepo.save(user.copy(firstName = "Raziel")) + +260 +11:24 +ale w scali da sie chyba User.findByName("Raziel").update(firstName = "raziel").save() + +lucas +11:25 +nie bo nie możesz save wjebać na case classa chyba że zrobisz to jako głupi proxy method na implicit repo + +Nowe Wiadomości +w sensie w Eloquent na klasie Model jest statyczne pole $dbEngine czy jakoś tak + +i przy boocie frameworka cała hierarchia klas Model dostaje ustawiony wstrzyknięty silnik skonfigurowany do bazy danych + +konstruktor Model robi dużo dziwnej magii żeby zachować tę relację poprawną i dlatego możesz zawołać $user->save() + +260 +11:26 +przyklad dobralem zeby byl jak najbardziej phpowy, save w takiej formie musialby byc extensionem i using UserRepo pewnie. Opcja save na repo tak jak podales wyzej IMO spoko, te copy robi update ladnie \ No newline at end of file diff --git a/docs/conversations/stack_feedback2.md b/docs/conversations/stack_feedback2.md new file mode 100644 index 0000000..f094756 --- /dev/null +++ b/docs/conversations/stack_feedback2.md @@ -0,0 +1,67 @@ + +12:09 + + + + + + + +nie no: +| HTTP Server | Tapir + JDK HttpServer | Tapir gives type-safe endpoint definitions with auto-generated OpenAPI docs. JDK HttpServer with Executors.newVirtualThreadPerTaskExecutor() is the lightest possible server | +| --- | --- | --- | +netty based server, jdk http server to jest zabawka do devserverów + +co do migracji + +to też mam zbadane + +flyway odpada + +flyway niestety nie ma rollbacków we free wersji + +musimy użyć liquibase + +połowa zabawy z octoberem/winterem to to że można jednym poleceniem zrzucic ostatnią migrację i naprawić rzeczy + +12:14 +haha, kuba, nie możesz mu tak po prostu wpierdalać tego, on jest za głupi, np jwt nie są ze springa lol, jest libka do nich javowa dobra, którą użyłem w springowym projekcie i działało + + + +1 odpowiedź +Obserwowane +Ostatnia odpowiedź 5 minut temu +w ogóle zbędne śmieci tam powrzucał z moich anegdot, to kto jest autorem libki nie ma znaczenia, zbędne tokeny xD + +oslo pozytywne powinny być zwroty bez jakichś "No Jakarta Mail", po co mu to, ma mieć tylko jasne wybory + +ten plugin system co on proponuje w docu nie zadziała, jak by to miało działać, jako git submodules? + +do pluginów proponuję zrobić osobny subprojekt w summer-*, nazwać go np summer-party + +w nim zdefiniujemy wersjonowane interfejsy dla pluginów oraz resolution system + +to musi być runtime based + +stosunkowo proste to będzie z service loaderem + +ale musisz mieć wspólny interfejs bo wtedy możesz zapobiec rozjazdowi + +ogólnie to fajnie byłoby zrobić registry pluginów prywatne i ekstrachować wtedy z publikowanych artefaktów wersje interfejsu żeby wiedzieć co można do jakiej wersji cmsa dodać + +moduł Queue ogólnie to on nie zrozumiał wcale, to że jvm ma długo działający proces wcale nie oznacza, że można trzymać kolejki nagle in-memory, Queue module w laravelu zapina do rozmaitych rozwiązań kolejkowanie poza aplikacją z uprzejmym założeniem, że kolejka jest persystentna, to jest moduł do spychania ciężkiej pracy do back office żeby na hot path http nie robić takich tasków, musi być jednakże gwarancja że coś co zostało wypchnięte na kolejkę nie zniknie i zostanie eventually wykonane + +moduł Queue musi mieć ładne interfejsy i do nich zapniemy rozmaite drivery do kolejek + +jakieś activemq czy nawet tabela w postgresie na start + +tzn napisał że persistence via postgres lub redis, good enough + +pagination ma dwie strony + +jedna to jest built-in pagination support w october/database rozszerzający laravelowe wsparcie dla pagination + +druga to jest wsparcie dla pagination w szablonach i api + +zacząłem robić draft tego jak widzę w ogóle pracę z bazą danych