Stack feedback

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