Sprawdź najbliższe Patoszkolenie👇
💣💣💣 [15.10.2024] Modelowanie Danych 💣💣💣
Spotify: 4900 dashboardów w 2023 roku. Absurd czy potrzeba? Scrum vs Kanban - stres i adaptacyjność. Refaktoryzacja długu technicznego. Uczyć się czy przepisać kod? OpenAI, Microsoft, Google - konkurencja gigantów. AI, LLM, atom - kontrowersje i wyzwania. Pragmatic Engineer radzi. Grafy w Google Spanner.
Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: protopia.tech
Linki i ciekawe znaleziska:
Szymon Warda: Cześć. Słuchacie Patoarchitektów. Prowadzą, Szymon Warda…
Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka na Patoarchitekci.io lub gdzieś tu na dole, w zależności w czym i gdzie nas słuchacie lub oglądacie.
Szymon Warda: Dobrze Łukaszu, chyba chwalimy się jeszcze szkoleniami tak naprawdę?
Łukasz Kałużny: Tak, więc wszystkie szkolenia na Patoarchitekci.io/szkolenia. Najbliższe Twoje to Modelowanie Danych.
Szymon Warda: Tak, czyli generalnie zerknięcie jak dobrać bazę danych tak naprawdę i dobrać model, jak dane są przechowywane do odpowiedniej bazy, ale też w ogóle jak myśleć o tym, że z danych jednak wszystko wynika. Tak że powinno być ciekawie. Pobawimy się różnymi bazami danych, zobaczymy jak podejść i jakich problemów unikać. Tak że zapraszam, zobaczymy. Poprzednia edycja cieszyła się sporym powodzeniem, więc zobaczymy.
Łukasz Kałużny: Jestem ciekaw jak tym razem pójdzie. No i przypominając wpadajcie również na Discorda, do którego znajdziecie link w opisie, gdzie możecie zobaczyć pewne rzeczy zza kulis i przedpremierowo lub też dodać swój głos. Dobra, to co wykopałeś?
Szymon Warda: Bo ja mam link, którego tutaj nie pokazywałem, to link z tej serii. I mam do Ciebie pytanie. Dashboardy są fajne, no nie? Jak myślisz, ile dashboardów wyprodukował Spotify w 2023 roku?
Łukasz Kałużny: Wiesz co, dobra, rzucę, że jeden dziennie, czyli coś koło 300, 350.
Szymon Warda: 4900.
Łukasz Kałużny: What?
Szymon Warda: Spotify dla kontekstu ma 6000 pracowników, wszystkich, nie tylko IT, wszystkich. Wyprodukowali 4900 dashboardów w roku 2023. Więc to brzmi absurdalnie jak to tylko możliwe. I w tym momencie Spotify ma problem z ilością dashboardów. To jest moment, kiedy się robi interwencję.
Łukasz Kałużny: Wiesz co, gdzie, bo nie widzę akurat tego linka nigdzie.
Szymon Warda: Już Ci go daję, teraz już Ci go wklejam w nasze linki, proszę bardzo. Artykuł jest ciekawy, bo poza tym absurdem jaki jest na start, to omawia też całkiem ciekawe rzeczy, bo wprowadzili poziomy dojrzałości tych dashboardów i wprowadzili bardzo proste, naprawdę proste, ale ja często widzę, że one są łamane, zestawy, co dashboard powinien mieć. Tam podzielili generalnie na różne oceny. Czyli low nie spełnia takich podstawowych założeń typu, że ma obecnie zatrudnioną osobę, która to utrzymuje, itd. Potem jest high, że spełnia takie podstawy typu, że utrzymuje to osoba, która obecnie pracuje w Spotify. I Golden to jest tak zwane vital signs i spicy dashboard design checklist. I ten checklist jest dość ciekawy, bo w ogóle wychodzi z tego, że 80% dashboardów spełnia ten najwyższy poziom. Czyli 80% dashboardów jest utrzymywanych przez aktualnie zatrudnioną osobę, co jest dobrym wynikiem. To jest bardzo.
Łukasz Kałużny: Ale ja teraz powiem jedną rzecz złośliwie zupełnie. Oglądając systemy, bo to są dashboardy BI-owe. To są dashboardy, które mają prezentować dane. I to jest na zasadzie widzimy, sorry, to jest nazwa trochę: dajmy self-service i pozwólmy, żeby każdy mógł zobaczyć dashboard. Prawdopodobnie, wiesz, jak na to patrzę i słyszę, to prawdopodobnie ten śmietnik, bo nie bójmy się użyć tego słowa przy takiej ilości dashboardów, to jest śmietnik.
Szymon Warda: Tak, to jest śmietnik i co więcej, koszt utrzymania ich będzie naprawdę duży. I dla mnie ryzyko jest takie, że będą wprowadzały w błąd tak naprawdę. Ale olejmy ten element, że tych dashboardów jest o rząd albo dwa rzędy wielkości za dużo, bo to w ogóle nie podlega dyskusji. Jeden dziennie to już byłoby dużo.
Łukasz Kałużny: Dlatego wiesz, stąd, że jeden dziennie poszedł na proda, to jest i tak dużo.
Szymon Warda: Ale ta lista jest dość ciekawa, którą opublikowali. Na przykład, idziemy przez takie fajniejsze punkty, użycie kolorów, które są zrozumiałe dla osób inaczej postrzegających kolory. Moje doświadczenie jest takie, że osoby właśnie inaczej postrzegające kolory, jest ich dość zauważalnie sporo w społeczeństwie, więc to nie jest takie rzadkie. Więc to jest fajne. Legendy, żeby były. Kolejna opcja moja ulubiona, dodanie tak zwanych banów, czyli big as numbers, czyli ważne liczby powinny być duże i łatwo widoczne. I to jest super rzecz. Dalej idziemy, peer review dla kwerend zasilających wyniki. To jest też świetny pomysł.
Łukasz Kałużny: Tak, wiesz co, ja patrzę na to, okej, to jest bardzo fajna checklista, jak popatrzymy. Patrząc się na te dwie rzeczy, czyli vital signs i spicy checklist, świetnie pokazuje, co powinien zawierać dashboard, jak powinniśmy na niego patrzeć.
Szymon Warda: Tak, fajnie. Zresztą masz tam jasny tytuł, opis użytych metryk, wyjaśnienie metryk, pokazywanie informacji, co się tam dzieje, definicje metryk. To jest mega prosta lista podstaw, co powinien spełniać dashboard, który można bez problemu wdrożyć w dowolnej organizacji i gdzie większość dashboardów tej listy nie spełnia.
Łukasz Kałużny: Tak, to jest prawda.
Szymon Warda: Dlatego bardzo mocno polecam ten link.
Łukasz Kałużny: Tak, to jest prawda. I to jest zawsze ciekawe, jak ktoś mówi o takich liczbach. Spotify jest o tyle ciekawy, że faktycznie są data driven w pewnych obszarach ze względu na całe algorytmy rekomendacji. Jakość czyszczenia tych danych prawdopodobnie jest ponadprzeciętna, ich użyteczność i jestem ciekaw, znając wszystkie syfy, które widziałem takie w życiu, jak wygląda data, jak bardzo te KPI i metryki rozbiegają się z rzeczywistością, to co reszta rozumie w firmie przy takiej ilości danych.
Szymon Warda: Wydaje mi się, że jeszcze jest jeden powód, system rozliczeń w branży muzycznej. Obliczanie tantiemów, czyli komu za co się płaci. Nie płaci się tylko artyście. Płaci się generalnie artystom grającym, płaci się wytwórniom i tam są przeróżne procenty na różnych umowach, itd.
Łukasz Kałużny: Wiem, tylko pytanie, czy to są dashboardy czy automaty? Tego nie wiesz.
Szymon Warda: To są automaty, na pewno.
Łukasz Kałużny: Pewnie w dashboardach może masz drill-downy do takich rzeczy, jakieś zestawienia. Tylko pytanie, czy to jest, i widzisz, teraz robimy zabawę, czy to są dashboardy czy raporty?
Szymon Warda: Wydaje mi się, że jedno i drugie tak naprawdę tutaj wchodzi w grę.
Łukasz Kałużny: Że definicja została wymieszana ze sobą.
Szymon Warda: Prawie na pewno tak, bo jak mówiłem o tableau, to tam też raportowe rzeczy można robić drill-downem i można robić jedno i drugie. Ale link jest ciekawy. Naprawdę ta lista jest całkiem niezła, warto rzucić okiem na nią. Dobra, co Ty masz tam?
Łukasz Kałużny: Dobra, to idziemy z luźną rzeczą. Czyli czemu Scrum nas stresuje?
Szymon Warda: Bo wprowadza zapiernicz.
Łukasz Kałużny: No właśnie i to jest świetna rzecz, jak popatrzymy całość. Jest piękny jeden graph, który pokazuje poziom stresu. W Waterfall raz na sześć miesięcy był miesiąc stresu. W zależności jak miałeś release.
Szymon Warda: Wydaje mi się, że w Scrumie to jest to, że… Tam są dwa tryby. Albo jest stres po to, żeby faktycznie dowieźć to, co obiecaliśmy, bo nam wyszły rzeczy, których nie przewidywaliśmy. To jest jedna opcja. Albo druga opcja, nie stresujemy się w ogóle i dla taska tworzymy kolejnego taska, który opisuje co nam właściwie wyszło. I never ending story właściwie kolejnych tasków, które dochodzą, dochodzą, dochodzą, dochodzą. A główny cel biznesowy, czyli zrobienie funkcjonalności, cały czas jest nieosiągnięty.
Łukasz Kałużny: Tak, on sobie idzie. Jest piękny rysunek, który pokazuje, że poziom stresu w Scrumie, to jest takie trochę anegdotyczne oczywiście, ale fajnie pokazuje, obrazuje to, co można zobaczyć, że on tak sobie wzrasta i im bliżej faktycznego release’u, pokazania tego światu, etc. Bo większość, kurde używa tego Scruma i słyszę, że wydaje raz na trzy miesiące. Nie ma czegoś takiego, że feature po sprincie idzie do użycia.
Szymon Warda: Są, ale jest to rzadko, bo są organizacje, które faktycznie tak robią. Ale zgodzę się, że to rzadko. Rozmawialiśmy przed nagraniem, Kanban, dobry Kanban naprawdę jest najbardziej realny, dobrze zarządzany, jest trudniejszy w utrzymaniu, trudniejszy w zarządzaniu, żeby dalej robić duże rzeczy, ale jestem fanem Kanbana od dość dawna.
Łukasz Kałużny: Raczej patrząc się teraz, ważna rzecz, bo o tym my sobie rozmawialiśmy zakulisowo i warto to też głośno powiedzieć, przez Kanban rozumiemy pełne podejście do Kanbana. Nie to, że to jest tak jak było. Scrum wypaczył też Agile w ogóle i te wszystkie toole wypaczyły pojęcie Kanban do boardów. To jest też ważne, że wypaczyły do bordów. A przez Kanban… Dlaczego preferujemy na przykład, skąd takie nasze przemyślenie? To w Kanbanie, tam jest coś takiego jak ilość limitów na danym boardzie, swimlane, które mówią na danej kolumnie ile może być na przykład tasków w in progress, ile w review i innych tego typu rzeczach. I złotą zasadą, która tam panuje, jest to, że nieważne jak się pali, nie wolno, jeżeli skończyło się capacity na danej kolumnie, nie wolno nic tam dorzucić.
Szymon Warda: Tak i w tym momencie przerzucasz na inne kolumny, które blokują. I w Kanbanie to jest też ważne, że on się skupia na optymalizacji całego procesu. Czyli to nie jest, że napieprzamy taski, ale to jest to, że patrzymy czemu nam to idzie wolniej, bardzo ładnie widzimy, gdzie mamy przestoje, gdzie mamy te miejsca węższe, szersze, gdzie nam idzie lepiej, itd. Kanban bardzo ładnie pokazuje wiele rzeczy. Więc to jest cały proces. To nie jest tylko typ boardu, który sobie wybieramy na Jira czy gdziekolwiek indziej.
Łukasz Kałużny: I jest wymagający dla teamliderów i managerów, dla osób zarządzających zespołem czy projektem z jednego powodu, blokery widać jak na dłoni. I powinno się blokery usuwać i nie rozbijać tasków. Druga rzecz, nie wspiera multitaskingu tak naprawdę, jak popatrzymy. To jest bardzo przyjemne, że ma dawać z drugiej strony osobie realizującej focus.
Szymon Warda: Dla mnie jest jeszcze jeden element. Dużo trudniej realizuje się duże taski, takie ciągnące się tak naprawdę. Kanban jest super fajny dla drobnicy i wtedy on jest bardzo intuicyjny, niewiele trzeba się wysilać, po prostu gra. Wymaga faktycznego ustalenia w zespole, grupie, itd., sytuacje co robimy z rzeczami większymi, czy je odkładamy i jak to w ogóle się dzieje.
Łukasz Kałużny: Tak, najbardziej trudna, to powiedziałbym, że jest priorytetyzacja zadań w backlogu. Wtedy w ogóle przy Kanbanie to jest temat rzeka, jak ustalić priorytety taskom w backlogu. Ale to, co powiedziałeś, zobacz, że w Agile, w Scrumie, przy tych wszystkich krzykaczach Agile’owych, tak to nazwijmy, że przecież user story ma być małe i skończone. I po dziś dzień widać kwiatki na zasadzie, że żeby złożyć coś w feature to jest rozbite na rekord. Widziałem po 10, 15 user stories, żeby złożyć jeden feature. Nie mówię tutaj, że to ma być jakiś epic i inne rzeczy, tylko że feature był tak przekombinowany, że był rozbity. Więc to jest też takie powiedzenie sobie czy jesteśmy w stanie dobrze projektować.
Szymon Warda: I polecamy chyba spróbowanie Kanbana, takie realnie doczytanie czym on jest i spróbowanie w zespołach, bo to mogą być fajne wyniki.
Łukasz Kałużny: Jeszcze dorzucę, w utrzymaniówce dość ciekawie się sprawdza.
Szymon Warda: Tam jest w ogóle maksymalnie intuicyjny. To nawet bezdyskusyjnie, tak. Dobra, ja kontynuuję moją serię pod tytułem: “kto wpisał ten tytuł”? I tym razem doczepię się do chyba jednego z najbardziej poważanych przez nas blogerów, mianowicie do Pragmatic Engineer. I on dał taki artykuł: Paying down tech debt, further readings. I tam jest takie zdanie wyboldowane i to jest bardzo ważne: Reducing tech debt as you go is also a great way to learn a new codebase. Tłumacząc na polski: redukowanie długu technicznego jest super sposobem, żeby nauczyć się nowego kodu. Co tam się w ogóle dzieje. I ok, i teraz jak to rozumiem? Że generalnie dajemy sobie nową osobę i mówimy mu: teraz to weź zrefaktoryuj ten kod, bo to się z reguły na tym kończy. To brzmi jak coś, co jest często realizowane i brzmi jak piękny przepis na absolutną porażkę, bo nie znając tej części domenowej, to będzie wymyślanie, pisanie systemu na nowo. Na pewno nie będzie redukcja długu, będzie zaciąganie innego długu, mniejszego, większego, innego. Ale to się nie zmieni. Dalej się tłumaczy co prawda, że chodzi mu o wiedzę niedomenową i chodzi mu o samo spłacanie długu technicznego, niczego więcej. Moje pytanie jest takie, czy to jest w ogóle realne? Czy można przemigrować część długu technicznego nie znając domeny na zupełnie nowym kodzie? Wydaje mi się, że to jest pomysł szalony.
Łukasz Kałużny: Rozumiem refaktoring po tym jak zaciągnęło się dług, na zasadzie walić to, dowieźmy. I zaczyna się techniczne sprzątanie.
Szymon Warda: Ale czy totalnie nową osobę w danej domenie nie rozumiejącą domeny? Bo dla mnie dalej nie.
Łukasz Kałużny: Naprawdę, jeżeli masz śmietnik, to być może, powiem to, sam z tego mam polewę, ale wiesz, jednym z takich tasków w ogóle to jest pytanie, co oni tam rozumieją przez to dokładnie, bo te przykłady tutaj, tak jak rzuciłem okiem, są różne na ten wpis. Czy dług technologiczny to może brak najważniejszych testów, unit testów w całym kodzie i innych takich rzeczy?
Szymon Warda: Ale nie znając domeny to dorzucisz test na zasadzie generalnie, czy po dodaniu elementów do listy, element się dodał? To się zgadzamy. Testy muszą jakąś tam wartość generować, a nie po prostu być testami. Posiadanie dużej ilości testów jest ujemną wartością, jeżeli one nie mają czegoś…
Łukasz Kałużny: Bądźmy szczerzy co do rynku. Większość developerów ma w dupie swoją domenę biznesową. Znacząca większość.
Szymon Warda: Większość, ale trafiają się ludzie, którzy się tym absolutnie fascynują i oni mają znowu w dupie rzeczy techniczne tak naprawdę. Ich interesuje domena. I mega fajnie z takimi ludźmi się współpracuje, bo oni się zmieniają szybko w takich ekspertów, ale też często odchodzą od programowania.
Łukasz Kałużny: Tak i teraz takie założenie się, że nauka domeny przez refaktoring, sorry, nie, tutaj, pod tym względem. I wiesz, i teraz jest pytanie, co tam jest pod spodem? Czy to jest prosta domena, czy może faktycznie coś normalnego? I teraz redukowanie kodu, raczej refaktoring tego kodu, diabli go wiedzą, w zależności co jest do zrefaktorowania, bo to jest takie duże. To zależy.
Szymon Warda: Mam kilka uwag, bo to w ogóle się skupiło na tym, że właściwie chodzi o przepisywanie systemu na nowo, to już w ogóle w tym kierunku idziemy. Ale tam jedna sugestia faktycznie dla mnie była ciekawa, żeby jak już te projekty się rozhuśtają, ten nowy system ze starym, to żeby ludzie pracowali nad jednym i nad drugim projektem równolegle. I to jest fajny pomysł, którego ja z reguły nie widuję. Z reguły właśnie widuję rzecz odwrotną tak naprawdę, że są developerzy nowego systemu, są developerzy starego systemu i potem tych developerów starego systemu przerzuca się na nowy system. A to fajnie jest takim mieszaniem wiedzy biznesowej i jak to w ogóle działa i zapoznaniem się z kodem. Więc to mi się naprawdę podoba.
Łukasz Kałużny: Tylko wiesz co, spowalnia mocno.
Szymon Warda: Spowalnia, zgadza się, ale pomysł jest dobry. Pomysł jest do rozważenia.
Łukasz Kałużny: To brzmi dobrze w kontekście rozwiązań SAS-owych, produktowych. W przypadku takiego zwykłego enterprise’u, no to nie widzę tego.
Szymon Warda: No możliwe. Też zależy trochę od podejścia organizacji takich systemów, bo ten Enterprise Enterprise’owi nierówny, jak on wygląda. Zobaczymy. Dobra, idziemy dalej. Co tam masz?
Łukasz Kałużny: Dobra, lecimy sobie. Dzień bez OpenAI i LLM byłby dniem straconym. Czyli lecimy z OpenAI. To jest bardzo krótki news, który był do przewidzenia, że się pojawi. Sądziłem, że szybciej się pojawi. Mianowicie OpenAI zaczyna wędrówkę w kierunku for profit.
Szymon Warda: Ze swoją bardzo dziwną strukturą organizacyjną.
Łukasz Kałużny: Raczej tak, tranzycję struktury, to jest bardzo ważne, for profit structure. Czyli oni zaczynają, bo była bardzo dziwna struktura gdzieś tam wokół zrobiona, w szczególności dealu z Microsoftem, gdzieś obok inne takie elementy. I teraz jest pomysł, że pora zacząć na tym porządnie zarabiać.
Szymon Warda: Czeka powoli na to.
Łukasz Kałużny: To jest ciekawe, bo być może wyjdą po bańce na rynek mocno, że to jest być może bardzo dobry moment, bo bańka troszeczkę pryśnie i wyjdą jako tech stabilny, a nie coś co wpadło, bo teraz wszystko ma AI-a, jak wiemy i potem jest to openAI-em z tyłu, ewentualnie modelem opensource’owym.
Szymon Warda: Tak, ale jak wcześniej trochę nie zgadzałem się z tym, że te opensource’y gonią, albo inne inne firmy zaczynają gonić, to obecnie już bym powiedział, że tak, gonią. OpenAI już nie odstaje od rynku aż tak bardzo mocno.
Łukasz Kałużny: Ja specjalnie nawet nie wrzuciłem, tam pojawił się teraz ten model GPT 1/0 z takim sposobem rozumowania, tak zwanym łańcuchem myśli, chain of thoughts, że ma wbudowany sposób interpretacji promptów, że nie trzeba tego rozbijać na małe, prowadzić tej dyskusji, tylko rzekomo ma za jednym. I kurde, nie jest to nic nowego, bo dało się na przykład Anthropica i Cloude zmusić do pewnego rodzaju działania już wcześniej w ten sposób.
Szymon Warda: O tym właśnie mówię, OpenAI już nie odstaje od konkurencji tak bardzo mocno jak odstawiał powiedzmy na start tego roku.
Łukasz Kałużny: Wyznacza nadal kierunki. Z perspektywy developer friendly, tak to nazwijmy.
Szymon Warda: Jest jedną z organizacji, które wyznaczają kierunek. Już nie tak bardzo, że wszyscy tylko próbują nadążyć.
Łukasz Kałużny: Ale łatwo przeciągnąć kartę do API.
Szymon Warda: Tu bym się zgodził. Dobra, jak Ty zacząłeś temat AI, to ja jeden kolejny. Wydawało mi się, że po tym jak Apple przerobił AI na Apple Intelligence, to wydawało mi się, że już nie przebijemy poziomu absurdu i zmian podpinania się pod różne skróty. Ale teraz Hugging Face z Nvidią się dogadali i teraz co prezentują? Jest teraz interface as a service. Czyli mamy IAS, już zupełnie co innego może w tym kontekście oznaczać. Taka krótka informacja.
Łukasz Kałużny: Inference as a service
Szymon Warda: Inference, tak, as a service. No moglibyśmy sobie dać już spokój z tymi różnymi podmiankami.
Łukasz Kałużny: Tylko wiesz co? To nie, to nie nowe, bo chyba MS z AWS-em, bo to, przepraszam, nie, wcześniej był model as a service, musieli się wyróżnić, właśnie.
Szymon Warda: Model jeszcze nie był używany, MAS.
Łukasz Kałużny: MAS był, właśnie MAS był, a inferencing as a service nie.
Szymon Warda: No właśnie, tym niemniej generalnie lekko mnie to poirytowało, że kolejne skróty są przejmowane.
Łukasz Kałużny: Dobra. Drugie luźne, powiązane, jak jesteśmy przy GenAI-u, kilka miesięcy temu wrzucaliśmy, nabijaliśmy się z ogłoszenia o pracę. Było to nabijanie się, ale stwierdzenie, że ma sens. Microsoft szukał kogoś od elektrowni atomowych na program managera programu nuklearnego w Microsofcie. No i teraz Microsoft podpisał 20-letnią umowę na kupowanie prądu, całego prądu z amerykańskiej elektrowni atomowej.
Szymon Warda: A czy pamiętasz co to za elektrownia i czemu ona jest słynna?
Łukasz Kałużny: Bo miała jedyny wypadek, był tam w ciągu całej kariery elektrowni w Stanach.
Szymon Warda: Three Mile Island, generalnie faktycznie miała wypadek. Czy to jest ważne? Oczywiście nie będzie aktywny… Bo elektrownie składają się ze swoich core’ów. Ten core, który miał problem, nie będzie wykorzystywany. Ale wydaje mi się, że dobór elektrowni nie jest najlepszy.
Łukasz Kałużny: Jest fatalny. Pod tym względem nie jest najlepszy. Jest fatalny.
Szymon Warda: Tak, ale tak mówiąc bardzo poważnie, to ostatnio natknąłem się na raport, który pokazywał ilość zużytej energii w tym roku kontra zeszły rok. Wzrosty są między tak niskie 40 a wysokie powiedzmy do 60%, nawet więcej z roku na rok. Różnice użycia energii są absurdalnie wysokie.
Łukasz Kałużny: Wiesz co, jedno mnie ciekawi, jak to się rozkłada na trenowanie i serwowanie AI vs kopanie bitcoinów, ethernów i innych shitcoinów?
Szymon Warda: Wydaje mi się, że to głównie się rozchodzi jednak o AI-e tak naprawdę. Bo już cały ten peak krypto, na razie chyba jesteśmy w okolicy zera, że jest w miarę stabilnie, że już fortuny nie można zbijać.
Łukasz Kałużny: Dobra.
Szymon Warda: Dobra, to ja ostatni, bym zamykał, bo jeden artykuł, który mnie ucieszył w ogóle. Google dodał API graphowe, tak to trzeba nazwać, do swojego spannera, czyli dość fajnej bazy rozproszonej. Generalnie naprawdę fajna baza. Ale co mnie tu ucieszyło? To jest to, że po Neo4j użyli takiej składni a’la cypherowej. Nie jest to składnia apache’owa, którą jest ten Gremlin, który jest słaby, nie oszukujmy się. Ale składnia jest fajna i to wygląda mega dobrze.
Łukasz Kałużny: Ale jak ma się ten, bo wiesz, ja akurat orłem nie jestem w graphowych, żeby pamiętać składnię i jak to wygląda, jak to ma się do Neo4j?
Szymon Warda: Otwórz link, to wygląda jak żywcem wzięte z Neo4j’a, z tą różnicą, że oni zrobili taki myk, to jest ciekawe, oni umożliwili połączenie SQL-a, bo są zwykłe joiny, ze składnią typowo Neo4j’ową.
Łukasz Kałużny: Okej, widzę. Czyli z jednej strony ładujesz graph, a z drugiej strony go jeszcze SQL-ujesz.
Szymon Warda: Jeszcze go SQL-ujesz. Więc podejście wygląda fenomenalnie, że tak powiem, bo łączy się się dwie rzeczy właśnie problematyczne. To jest to, że na bazach graphowych mega ciężko robi się agregacje duże, to one są do wyszukiwania.
Łukasz Kałużny: Kurde i mam teraz Szymon jedno tylko pytanie.
Szymon Warda: No.
Łukasz Kałużny: Jak bardzo to siądzie?
Szymon Warda: No właśnie, gdyby nie to, że to jest na Spannerze i chwalą się, że tam powiedzmy tryliony, itd., to wydaje mi się, że to może być niezłe. Wiadomo, po co to jest. Pod AI-a, pod bazy…
Łukasz Kałużny: Pod knowledge graphy i inne takie rzeczy. Nie, bo wiesz, ja patrzę po prostu bazy graphowe są wolne.
Szymon Warda: Nie, nie są wolne. Bazy graphowe są wolne jeżeli się źle je wykorzystuje.
Łukasz Kałużny: I nauka optymalizacji pod myślenie graphowe, to jest jak z programowaniem funkcyjnym.
Szymon Warda: Tak i przypomnę Ci naszą rozmowę z osobą, którą powinniśmy zaprosić do odcinka.
Łukasz Kałużny: Tak.
Szymon Warda: Dużo się zmieniło też, one były dużo wolniejsze kiedyś. Teraz naprawdę chodzą ładnie, dają radę. Można powiedzieć, że jak wcześniej były bardziej do rzeczy raportowych i analityki, to teraz przy tych wynikach, które ja widzę ostatnio, to nawet bym powiedział, że przy takich procesach transakcyjnych dałoby radę to używać.
Łukasz Kałużny: Dobra, to zobaczymy. Szymon ma na myśli Jarka Pałkę, więc dajcie znać czy chcielibyście go posłuchać, bo pewnie ma trochę ciekawych anegdot ze świata i okolic Javy.
Szymon Warda: Ja chcę z nim porozmawiać generalnie, więc nie wiem czy będziemy brali zdanie zewnętrzne pod uwagę.
Łukasz Kałużny: Spoko. Dobra to trzymajcie się, miłego dnia.
Szymon Warda: Tyle. Hej.