Github po raz kolejny zdominował Patoarchitektów! Zobacz, czym ich zaskoczył w tym tygodniu.
Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Cześć! Słuchacie Patoarchitektów. Prowadzą Szymon Warda
Łukasz Kałużny [ŁK]: i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io/51.
SW: Dobrze, to zacznijmy od… Nie możemy pominąć chyba największego shitstormu, jaki się dzieje na jedynej słusznej platformie (śmiech), czyli od Elona. Dzieje się dużo.
ŁK: Tak. Dobra. Dzisiaj wybrane, bo Elon poszedł ratować świat, czyli Twittera i zajął się technologią tam, gdzie nie powinien, i ludźmi, którymi nie powinien. Patrząc z perspektywy, bo ludzie od Tesli, która softwaru nie ma najlepszego w paru miejscach i można…
SW: Znaczy, ma zupełnie inny software.
ŁK: Ma zupełnie inny software, a ich infrastruktura (patrząc po tym, co wypływa anonimowo na Reddicie co jakiś czas…) do najlepszych nigdy nie należała, tylko była bardzo posklejana na taśmy.
SW: Tak. I nie jest client fancy. To nie jest coś, do czego normalni ludzie mają dostęp. To jest bardzo, bardzo, bardzo ważne.
ŁK: Tak. Specyficzne i dużo rzeczy jest wykonywanych lokalnie w samochodach, które zupełnie inaczej działają.
SW: Tak.
ŁK: No dobra. No i zaczynają naprawiać Twittera. I co mi się spodobało?
SW: Nie. Przede wszystkim zaczęli od tego, że… Elon kazał drukować linie kodu pod review. (śmiech)
ŁK: Tak, tak.
SW: To było najbardziej spektakularne.
ŁK: Tak, ale już przejdźmy do tego tweeta. (Spróbuję go potem podlinkować, bo część jest już pousuwana, ale screeny w Internecie zostały). Elon stwierdził, że jest ok. 1200 mikroserwisów, co równa się mniej więcej, że tyle przechodzi requesty, które potrafią polecieć do [niezrozumiałe]. W to już nie wierzę, bo dla mnie to już jest trochę bullshit. 1200 mikroserwisów? Jak najbardziej tak. Jest to liczba, w którą jestem w stanie uwierzyć, że przez tyle lat obrosło to wokół Twittera.
SW: Tak, ale jak spojrzysz na dowolną dużą organizację, jak policzysz wszystkie serwisy czy end-pointy potencjalnie, czy to będą mikroserwisy czy tak dalej, tak to będzie wyglądało.
ŁK: Tak. Tak będzie wyglądało. Najlepsze jest określenie, że 20% z nich jest potrzebne. Zaraz przejdziemy sobie do naszego dowcipu z tym związanego. I faktycznie – jestem ciekaw, ile z tego jest tak na prawdę potrzebnych do tej części, którą dostarcza biznes, czyli reklamy, użytkownik etc. Ile z tego jest potrzebne? I to jest ciekawe. Jest jeden tekst, który, przepraszam, mi się spodobał, i bardziej do projektów, które nie są mikroserwisami, tylko nanoserwisami, pikoserwisami: Microservise bloatware. Jest to piękne określenie, które bym zabrał. Nie wiem, czy pasuje do Twittera, ale idealnie pasuje do rzeczy, które oglądamy.
SW: Zgodzę się z tym. Pamiętam historię Ubera – swojego czasu miał podejście, że nie będą robili refaktoringu serwisów, tylko będą po prostu tworzyli nowe. Bo żeby coś mogło polegać na tym serwisie… Im się, de facto, nie opłacało robić review czy warto go zmieniać, czy on jest jeszcze w ogóle używany.
ŁK: Mhm. Tak.
SW: I obstawiam, że to samo jest w Twitterze.
ŁK: Pewnie tak jest. Tylko wiesz co… Porównam to do modelu Google, o którym szeroko jest wiadomo. Tam za to jest dość szeroko mierzone, które linie są używane i automatycznie latają PR-y na wykasowanie nieużywanych rzeczy. Więc to są dwa różne światy.
SW: Zgodzę się, tylko że Google jest dużo większą organizacją, ma dużo bardziej stabilny dochód. Znaczy – ma dochód. O, może tak.
ŁK: Tak. (śmiech) Ma dochód. Tak. I ma dużą grupę produktową, która dynamicznie się rozwija w różnych kierunkach.
SW: I ma dość mocny zamordyzm. W pozytywnym tego słowa znaczenia. W sensie: w Google musi być kadencja wydawnicza i masz się zonboardować na nowszą wersję. Częściowo ich rozumiem, bo usuwanie trupów z szafy jest cholernie kosztowne i zajmuje masę czasu. Nikt się tym nie chce zająć, nie ma poparcia w organizacji, więc to się zbiera. Oczywiście – ten cały bloatware, wszystkie trupy z szafy, gdzie mamy jedno wykorzystanie albo nawet nie wykorzystanie serwisu, to nas spowalnia z czasem. Więc to trzeba czyścić. Ale to jest cholernie drogie w robieniu – usuwanie serwisów i kodu jest naprawdę kosztowe.
ŁK: Zawsze się śmieję i porównuję, że w pewnym momencie dorastasz do tego, że nie solid tylko kod, który jest łatwy do usunięcia jest najlepszy.
SW: Tak. Znaczy… To jest wartość takich właśnie serwisów. Dlatego lubię określenia mikro, że można coś wywalić czasami.
ŁK: Tak. I idąc dalej. To, co przy wywalaniu krąży, że przestało EMV działać i nie można się w Twitterze zalogować. To tak właśnie przy okazji sprzątania. Zaraz zobaczymy, jak to będzie wyglądać, bo zwalnianie ludzie po ilości napisanych linii kodu, no nie przekłada się i trzeba… Elon chyba nie wie, jaka jest dobra… nie dobra metryka do patrzenia na wydajność. Kto, ile kodu naklepie.
SW: Wydaje mi się, że Elon się od tego wszystkiego odbije bardzo mocno. To nie jest człowiek, który by się uczył na swoich błędach albo brał pod uwagę innych ludzi.
ŁK: Tak, tak, tak, tak.
SW: A tu masz zupełnie inny biznes niż SpaceX, zupełnie inny biznes niż Tesla. Więc to się źle skończy. Wydaje mi się, że Twitter może skończyć się na tym, że jednak Elon go sprzeda za dużo mniejsze pieniądze, albo po prostu Twitter się zamknie.
ŁK: No, zobaczymy. Patrząc na to… Wokół tego były problemy nie technologiczne, tylko jak to spiwotować, udochodowić. A zajął się tym, co w teorii przenosi z innych biznesów, zamiast tą częścią, z którą był od zawsze problem z Twitterem.
SW: Tak.
ŁK: I przy okazji: drugi link o mikroserwisach, który dość fajnie (bo oczywiście wszyscy muszą się teraz wypowiadać, jak to bywa na Twitterze)… Fajna rzecz jest tutaj rzucona. Przechodzenie od monolitu aplikacji serwisu do mikroserwisu – powinniśmy dość rozsądnie przechodzić. Zwykle monolit na początku ma najbardziej sens właśnie na całą otoczkę technologiczną, która jest wokół. I będzie w wielu przypadkach najprostszy, kiedy startujemy.
SW: Mnie się bardzo mocno podoba jedna rzecz. Takie spojrzenie, jak się patrzy na historię, z punktu widzenia ekonomii. Mikroserwisy mają cholerny sens z punktu widzenia ekonomicznego jak firma zaczyna nagle dużo onboardować ludzi.
ŁK: Tak.
SW: Łatwiej jest wrzucić ludzi na konkretne, osobne serwisy, nawet większą liczbę nowych ludzi niż nagle zonboardować 30 osób do jednego monorepo. Tu będzie chaos kompletny.
ŁK: Tak. Standardowe powiedzenie: tu pizza team.
SW: Tak, tak, tak. Ale to właśnie wynika z ekonomii: firmy nagle musiały się mocno rozwijać. Amerykanie fajnie mówią: follow the money. Tu naprawdę ma to sens. I nie wrócimy do monolitu. Nie ma opcji, żebyśmy wrócili do monolitu. Na poziomie seniorów itd. Ludzie, którzy mówią, że wracamy do monolitu, to są ludzie, którzy już wyklepali ileś tam lat w tym biznesie i widzą, umieją go opanować. Ta ogromna liczba juniorów, którzy są potrzebni, i midów nie wróci do monolitu. Nie ma to po prostu żadnego sensu. Trzeba znaleźć środek – faktycznie. Wywalić słowo mikro z tych stałych mikroserwisów.
ŁK: Tak, tak. Raczej nie idź w nano i piko, bo często… Przepraszam, ale jak oglądam niestety te usługi, to często jest to nie wiadomo jak pocięte. To jest to, co zawsze mówimy: że nie wiadomo jak jest zamodelowane. I ktoś ciął funkcjonalnością techniczną, a nie skupił się na pocięciu tego biznesowo. I potem wychodzą takie różne fajne kwiatki.
SW: Tak.
ŁK: Dobra, Szymonie, to co? Temat główny odcinka.
SW: Tak. Github Universe. Czyli konferencja Github. Trochę produktowa, ale też ciekawa z punktu widzenia, co się w sumie dzieje w największym zbiorze…
ŁK: Repozytorium…
SW: …na świecie.
ŁK: …chciałem powiedzieć. Tak. Największym repozytorium. Dobra. Jakie jest Twoje pierwsze odczucie? Zanim przejdziemy do ogarniania newsów.
SW: Wydaje mi się, że Github jak nigdy znalazł super model na biznes. Mam wrażenie, że Github nie będzie zarabiał na subskrypcjach na trzymaniu kodu. Zresztą tym bardziej, że dużo się zrobiło darmowej. Teraz już rozumiemy, czemu Github już parę lat temu stwierdził, że możecie mieć darmowego private Trip – nie musicie płacić. Bo ktoś stwierdził, że nie będą zarabiać na hostowaniu, bo to nie jest biznes. Biznes na hostowaniu, to taki biznes, gdzie będą się ścigali, kto zrobi to taniej. Czyli to jest martwy biznes. Tylko stwierdzili, że będą robili inteligencje wokół tego wszystkiego. I wszystkie narzędzia – to widać po całym code searchu, copilocie, o którym będziemy trochę więcej mówili, to widać po … wszystkim, co właściwie robi Github. Od CodeQL-u…
ŁK: Tak.
SW: Ewidentnie po prostu korzystają z [niezrozumiałe]. Repo to jest źródło nauczania, do ściągania wiedzy i obserwacji, a produkty jako takie będą budowane na bazie tego kodu, który tam będzie.
ŁK: Raczej już w niektórych kręgach Git=Github=używanie jego. Tak po prostu jako stos technologiczny.
SW: Tak. W open source i publicznych bardziej rzeczach. W korporacjach to jest różnie.
ŁK: Różnie, ale to też sobie przejdziemy do [niezrozumiałe]. Mam jedno wrażenie z naszej wcześniejszej dyskusji, że występowanie im nie idzie. Jeżeli chodzi o te główne części. W sensie… Przyjemności oglądania, sorry – prościej by było przeczytać announcement na blogu niż to obejrzeć.
SW: Ciężko to się ogląda. Strona wygląda jak strona do Appla, gdzie kiedyś te prezentacje Appla były jeszcze fajne, teraz już nie. Ale po prostu, tak… Ciężko się to ogląda. Naprawdę.
ŁK: Dobra. Lecimy z pierwszym.
SW: Copilot. Generalnie najważniejsza rzecz. Ogłosili, że to jest 55% wzrostu produktywności. Oczywiście to są liczby włożone między produktowe i reklamowe. Jeżeli Copilot wypali i będzie chodził dobrze (a ewidentnie w tym kierunku to idzie), to jeżeli Github będzie chargował 5000 dolarów miesięcznie za Copilota (a będzie on miał wydajność na poziomie powiedzmy 150-200%), to cena 5000 miesięcznie (absurdalna teraz), będzie miała sens. I to jest super pomysł Githuba.
ŁK: Więc, tak… Ogólnie patrząc, Copilot idzie… Jako użytkownik Copilota… Nie płacę za niego, więc mogę się wyrazić, jak mi się pracuje z nim nie płacąc za niego. Na prawdę z miesiąca na miesiąc widać, że modele, które są wykorzystane pod spodem działają coraz lepiej. I coraz lepiej podpowiadają… Nie jest to już durne copy-paste kodu, jak bym wpisywał po prostu, podpowiadał mi to, czego szukam na Stack Overflow, tylko faktycznie potrafi rozsądnie w codebasie zacząć uzupełniać to. Więc od tej strony idzie. I patrząc na ogłoszenie, najważniejszy dla mnie z całości jest bardzo ważny przekaz, że to jest dla biznesu.
SW: Tak
ŁK: Zwiększamy produktywność twojego dewelopera. Czyli nikt nie mówi, że AI będzie za ciebie kodował, tylko zaczynamy zwiększać produktywność dewelopera.
SW: Tak. To jest fajna opcja. Dzięki temu, że kierują to do biznesu, osoba prywatnie nie zapłaci tych kilku tysięcy miesięcznie, ale biznes - zapłaci bez problemu. I będą szczęśliwi, bo Copilot nie chodzi na urlopy, nie choruje itd.
ŁK: Tak. Przepraszam, Szymon, że zrzucę Twoją hiperbolę: to kosztuje (przy płatności z góry za rok) 100 dolarów.
SW: Tak, wiem.
ŁK: Więc żeby słuchaczom nie wyszło przez tę hiperbolę, że Copilot taki drogi. Copilot kosztuje stówę rocznie.
SW: Łukasz, ale… Ja ich hiperbolizuję, bo dla dużych organizacji płacenie kilku tysięcy miesięcznie będzie miało sens, jeżeli on [program] będzie poprawny.
ŁK: Tak. tak. Patrząc, jak to jest sprzedane, że to jest po prostu twój kolega do kodowania w parze… To jest mega przekaz w tym miejscu.
SW: Tym bardziej, jeżeli mówimy o pracy zdalnej (a trochę to się jeszcze utrzyma), to Copilot adresuje jeden z większych problemów tak naprawdę: że często mamy dużo kodu, który po prostu trzeba wyklepać. Nie jest ani trudny, ani skomplikowany, ani ryzykowny, po prostu trzeba go wyklepać, żeby klej, który klei konkretne moduły albo wypełnienie zapytania do bazy czy cokolwiek innego działał. Taki nudny kod, który po prostu zajmuje czas. Kod, nad którym nie myślimy, po prostu go klepiemy. I [niezrozumiałe] właśnie adresuje to. Czyli zmniejszy zapotrzebowanie na juniorów. To może być niesamowita zmiana na rynku. To się nie stanie dzisiaj, nie stanie się to jutro, ale powiedzmy w ciągu 5 lat… Jestem ciekawy, jak to będzie wyglądało.
ŁK: No. Dobra. Idąc do drugiego eksperymentu, nad którym się zastanawiałem na początku… No sorry, mieliśmy polewkę, jak się zdzwoniliśmy przed tym… Czyli „Hey, Github!”, napisz mi kod.
SW: Łukasz (śmiech), jak często dyktujesz SMS-y? Powiedz mi.
ŁK: Nie dykt… Znam ludzi, którzy dyktują albo wysyłają od razu wiadomość głosową. Ja nie należę do tych osób.
SW: Głosową się zgodzę. To jest super. Ale dyktowanie do… [niezrozumiałe]? Nie.
ŁK: I teraz jedna rzecz. „Hej, Github!” to taki eksperymencik Githuba. Zrobili własnego asystenta do pisania kodu – możecie głosowo powiedzieć, co ma wam wyklepać. Bazuje to pod spodem na Copilocie połączonym z OpenAI Codex, czyli specjalną wersją modelu GTP3, który wszędzie jest szumnie ogłaszany, że zastąpi dziennikarzy i inne te sprawy. Ale wiesz co… Jedna rzecz w kontekście Copilota mnie teraz naszła… Będzie to oznaczało, że „Hey Github!” i mówienie… Rozumiem, możemy się śmiać, ale z tego, jeżeli dobrze napiszesz komentarz i nazwiesz zwienne, to ten model naprawdę dużo ci wygeneruje. To, co powiedziałeś o generowaniu. Od tej strony, to jest… Świetny początek drogi tego eksperymentu do zwiększania produktywności.
SW: Dla mnie to dyktowanie jest dobrym kierunkiem do [niezrozumiałe].
ŁK: Tak.
SW: Do typowo deweloperskiej pracy, jaką większość z nas realizuje, to nie chwyci. Do slow code – super opcja.
ŁK: Dobra. Następna usługa: Codespaces.
SW: Tak. Ja tu mam jedną ważną uwagę, która mnie naszła. Zdajesz sobie sprawę… Na rynku amerykańskim bardzo mocno popularne są chromebooki. Dlaczego? Google przez jakiś czas, może parę lat temu, twierdziło, że chromebooki są dużo tańsze i wpychał je mocno do edukacji.
ŁK: Chromebooki do edu, tak, dokładnie.
SW: I teraz ludzie, którzy się na chromebookach wychowali, idą do pracy i na czym chcą pracować? Na chromebookach. To jest to, że Codespacesy właśnie są wykorzystane w edukacji, są pchane do edukacji. To jest świetny interes, który Github robi, który im, de facto, buduje bazę użytkowników za 10 lat.
ŁK: Tak, dokładnie. Dobra. Lećmy sobie… Codespaces to hostowane workery do dwóch usług - zaraz sobie do tego przejdziemy. W sumie już do trzech usług. Workery do tego, żeby mieć stację deweloperską w chmurze przez przeglądarkę, łącząc się ze swojego visual studio call, nie trzymane u nas. Czyli cały compiute jest w Githubie i… Co to daje? Z jednej strony nie musimy mieć gotowej stacji, środowisko zawsze działa, bo jest jego definicja pod spodem (tak zwane Dev Containers). I znowu jako użytkownik tego rozwiązania na co dzień, uważam, że jest to genialna rzecz.
SW: Jest super.
ŁK: Tak. Jest genialną rzeczą. I…
SW: Jedna rzecz odnośnie compliance. Czasami dalej spotykam się z takimi sytuacjami, że jakiś klient mówi, że OK, deweloperzy nie mogą mieć admina lokalnie.
ŁK: I to rozwiązuje problem lokalnego admina. Czy innych opcji… Bo sam koncept, jeżeli pójdziemy do jakichś dużych firm: Facebooka czy Google, oni od dawna kodują na tego typu rozwiązaniach wewnętrznych przez przeglądarkę. Więc to nie jest żadna nowość, że nie mają u siebie niczego na stacji poza szczególnymi przypadkami.
SW: Tak.
ŁK: I to, co powiedziałeś: compliancowo - Github Codespaces docelowo ma też scenariusz dla banków i innych instytucji, żeby zrobić prosty onboarding pilnowanie tego kodu.
SW: Tak. To, co mnie w tym wszystkim zastanawia, to po pierwsze: mamy duży łańcuch legasy, od tego zacznijmy i tam tych nie uruchomisz. I że wymaga takich… Sam Codespaces nam niewiele da. Bo to jest jedynie, że możemy sobie kodować. Ale też lokalnie odpalamy to wszystko. I to jest też super push przez firmę-matkę, nazwijmy to, czyli Microsoft, do tego, żeby to zautomatyzować i mieć całego IA w chmurze. Żeby po prostu było, że robię commit i testuję nie lokalnie, tylko wszystko odpalam na moim środowisku chmurowym.
ŁK: Tak, dokładnie. Bo wcześniej to się nazywało Visual Studio Codespaces. One były w ramach Azure DevOpsa, gdzieś tam i Azura obok wcześniej istniały. Patrząc się, pierwsze to, co powiedziałeś z chromebookami. Wcześniej Codespaces były płatne. W tym momencie nawet przy darmowym koncie (to jest bardzo istotne, nawet przy koncie zwykłym – free), dostajemy 60 godzin Codespaces na podstawowym workerze za free. To jest taki największy announcement tej części.
SW: Generalnie, jeżeli chodzi o rozdawnictwo, w sensie o darmowe tiry, Github jest bardzo hojny. Bo też weźmy też np. ilość minut na agentach Githubowych.
ŁK: Jest dużo.
SW: Jest bardzo dużo. To nie jest dużo. Jest bardzo, bardzo dużo tak naprawdę.
ŁK: Dobra. Następna rzecz z tych newsów, to jest partnership z JetBrains. Czyli można… Jeżeli mamy subskrypcję na JetBrains, można ją podłączyć i odpalać poprzez Codespaces jetbrainsowe środowisko. W wielu kręgach, nie oszukujmy się, to taki mały game challenge.
SW: Tak, jest to ułatwienie. I to, co jest fajne, właśnie… Bo ty mówisz o JetBrains, jeszcze jest JupyterLab sammy, czyli do całego ML-a. I jeszcze wspierają środowiska, które mają GPU.
ŁK: Znaczy private preview.
SW: Tak. Private preview jest , tak.
ŁK: Tak, jest private preview w zapowiedzi. To będzie powodowało ciekawy kierunek.
SW: Tu się może to rozbić, ponieważ licencje na GPU, które mogą być wykorzystywane w serwerowniach są dużo wyższe.
ŁK: Pamiętaj, skąd biorą te GPU. One stoją w Azure, więc cena też będzie… Inaczej pewnie to dograją.
SW: Tak. Ale… Nie obstawiam, żeby to była okazja. Nazwijmy to delikatnie tak.
ŁK: Znaczy bardziej… Wiesz co, znowu patrząc się pod korpo - taniej wziąć w wielu wypadkach wirtualkę w Cloudzie w GPU niż dostarczyć taką stację człowiekowi. I ściągać na niej…
SW: W skali całej organizacji.
ŁK: Tak.
SW: Tak, może tak być.
ŁK: Albo ściągnąć dane i inne rzeczy.
SW: Dobrze. Projects. Mnie tu jedna rzecz ucieszyła: markdown wszędzie.
ŁK: (śmiech)
SW: I to jest taka Jira, mogą się z tego dużo nauczyć. To jest po prostu mega, mega fajne. I tam jeszcze było ogłoszenie ciekawe, że będzie lepsze używanie z telefonów.
ŁK: Mobilki. Wiesz co, nie używam. To, co chciałem powiedzieć, to jest fajny kierunek… To jest atak na Jirę. Taki od strony prowadzenia projektów. Ten Github Project. Teraz taki…
SW: Ale daleko im strasznie.
ŁK: Daleko, daleko, bo zupełnie jest inaczej. To też trzeba sobie powiedzieć, ta sama była wada w Azure DevOps – patrzą per inicjatywa/projekt, a nie per organizacja. To jest rzecz, która w Jira wielokrotnie wygrywała – mamy szeroki zasięg, a nie mały scope.
SW: Tak. GH projects jest fajny. Do małych rzeczy to naprawdę jest fajna usługa. Jak próbowałem cokolwiek powyżej małego zrobić, to dość szybko zaczynał się robić pierdolnik. I tutaj dla mnie wygrywa Azure DevOps. Bez dwóch zdań. Takie przynajmniej jest moje odczucie – jest dużo, dużo lepiej, powiedzmy sobie, że jest bardziej enterprisowy.
ŁK: Tak. Przy czym teraz można zobaczyć, że pokazały się jakieś dashboardy z planowaniem i innymi rzeczami, więc to się… Inaczej – widać, że mocno się rozwija do przodu. Jakby tam ekipa od Azure boardsów zaczęła wreszcie pracować z tym.
SW: Tak.
ŁK: Bo to jest taki wygląd. Plus mobile, o którym wspomniałeś. Z telefonu to jest akurat…
SW: Nie widzę w tym wartości.
ŁK: Ja też… Znaczy, wiesz co, niektórzy zerkają na to. Mnie cieszy, ale to przy Github Actions sobie do tego przejdziemy, bo mnie akurat ta jedna rzecz czasem cieszy. Więc Project… Inaczej: na plus, ale do projektów, a nie do organizacji.
SW: Tak. Do opensoursowych rzeczy tak naprawdę to będzie tam działało super. Jak teraz super działa. Do organizacji…
ŁK: Albo jeżeli organizacja buduje projekt. Jeżeli masz, budujesz produkt i inne rzeczy, siedzisz no to będzie się to spisywać w niektórych miejscach.
SW: …dalej wybrałbym w tym momencie Azure DevOps-a. Jak mam być szczery. Mimo wszystko.
ŁK: Azure boards. Może tak. Bo oni starają się ten DevOps odkleić od tej nazwy.
SW: Dobra, może być. Actions. Co mnie tu ucieszyło? Dużo mocniejsze runnery. To jest bardzo fajna wiadomość, bo runnery Githubowe, które były normalnie…One są bardzo fajne w ogóle, wykorzystanie, działanie - super. Trochę były wolnawe. Nie urywały szaleństwa, bym powiedział.
ŁK: Tak, więc duże… Dobra. Dla mnie od strony, tak… Lecąc po kolei, to od strony security…
SW: Ale czekaj jeszcze.
ŁK: Tak?
SW: Te Actions. Importer.
ŁK: Ja mówię właśnie… Poczekaj, właśnie chcę przed Importerem. W Github Actions teraz oprócz dużych workerów, druga rzecz, która będzie leciała, to zafiksowane zestawy adresów IP. Czyli Github będzie mówił, z jakich adresów IP to lata. Więc to jest taka rzecz - może się wydawać pierdołowata, ale przy wielu set up’ach…
SW: To jest ważne.
ŁK: Tak. To jest dość istotne, że wiemy, skąd się ktoś do nas łączy i co ogląda. Więc to taki z pierdół security wokół tego. No i teraz przejdźmy do czegoś, co oboje zaznaczyliśmy w swoich notatkach, czyli Github Actions Importer.
SW: Czyli opcja, że odpalamy aplikacje, którą obecnie Github wystawiał w Docker, i ona nam np. takiego Jenkins przerabia na Github Actionsy. I to jest ciekawy ruch, bym powiedział, bo to jest z reguły główny blocker, żeby przejść z jakiegoś CI/CD na inny CI/CD
ŁK: Żeby zacząć przepisywać. I patrząc na waiting liście mamy oczywiście Azure DevOps-a postawić (śmiech). Muszą spróbować jakoś wreszcie zabrać ludzi. Chociaż na pieniądzach jakoś tego nie widzę. Circle CI, GitLab, Jenkins i Travis CI. Czyli mamy ileś najpopularniejszych rozwiązań rynkowych, z których już teraz w private preview (bo znowu jest wait list), mamy możliwość zaimportowania i zobaczenia, jak zrobić Github Actions z tej definicji, która jest aktualnie w naszym built systemie.
SW: Co mnie zaciekawiło… Nie ma tam TeamCity. No…
ŁK: No.
SW: Ciekawy ruch.
ŁK: Wiesz co… Ale TeamCity wbrew pozorom poza światem .NET-owym chyba nie ma…
SW: Istnieć
ŁK: Tak, chyba nie ma. Bo najczęściej spotkałem TeamCity jednak w światku .NET-owym.
SW: Tak. Mimo że JetBrains jest taki bardzo mocno znowu Javowy, no ale… Jest tak dobrze.
ŁK: Tak. Dobra. Co ty masz następne na liście?
SW: CodeQL. I to znowu… Kolejny produkt… Do czego to jest w ogóle? Do analizy kodu. Coś taki…
ŁK: Statycznych
SW: Statycznych, tak.
ŁK: I pod względem bezpieczeństwa. Teraz to istotne, że pod względem bezpieczeństwa. W tym momencie.
SW: Tak. Ale! Dla mnie to jest kolejny znak, w którym kierunku produktowo idzie Github. Mają bazę kodów. Ogromną bazę kodów, ale też PR-ów, fixów i commitów całych, i na bazie tego mają możliwość alternatywy dla Snyka, SonarQube itd. Dla tych narzędzi… Do budowania takich narzędzi potrzebna jest baza wiedzy. Oni tę bazę mają i są jej właścicielami.
ŁK: Tak. Łącząc to z Copilotem. To też jest ciekawe. Bo zaproponuj automatyczny refactor na podstawie, przykładowo rozbić… Dla mnie to jest zawsze… SonarQube zawsze ładnie pokazuje tę złożoność cyklomatyczną, że nasz kod jest zbyt złożony. I druga sprawa: Cognity flote, czyli automatyczna propozycja PR-a do kodu, który jest przekombinowany.
SW: Tak, tak. Znaczy… Mają tę bazę i to ewidentnie będzie to, na czym będą robili pieniądze. To jest… CodeQL wygląda nieźle. Na chwilę obecną to jeszcze nie dorównuje alternatywom, ale jak najbardziej wydaje mi się, że za rok, dwa, trzy to będzie już… raczej będzie.
ŁK: Właśnie jestem ciekaw. Bo to jest ta jedna brakująca rzecz przy Githubach, która by w tej platformie idealnie pasowała: automatyczna [niezrozumiałe] analiza kodu.
SW: Tak i to będzie. Jak najbardziej. To będzie. I to właśnie będą te płatne części.
ŁK: No zobaczymy za ile. Dobra, dalej… Code Search.
SW: Code Search. I Code Search w końcu wygląda, działa lepiej. Bo Code Search w Githubie nie był idealny, nazwijmy to delikatnie. Działał. OK, działał nieźle. Wyniki jakie prezentował: o Boże, to było słabe.
ŁK: No. Jestem użytkownikiem preview już od jakiegoś czasu, i tak… Świat się zmienia. Przy czym jest prościej, o tak. Bo jak teraz, w tym co macie zazwyczaj dostępne do wyszukiwania, ten search, to była jedna z największych wad Githuba, jak chcemy coś konkretnego znaleźć. Wiemy, czego szukamy, a wyniki dostajemy wokoło.
SW: I mało czytelny. Ciężko jest wybrać kontekst dokładnie, który się wybiera, i widzieć czy faktycznie ten wynik to jest to, czego szukaliśmy. Więc to się odmienia.
ŁK: Tak.
SW: To są głównie zmiany UI-owe. Ale naprawdę się przydadzą.
ŁK: Tak. To więc… Tutaj duży plus. Akurat pierdoła z bardzo dużym plusem.
SW: Dobrze. U mnie kolejna rzecz, która zwróciła moją uwagę – wzrost użycia języków. I teraz tak… Największy wzrost zaliczył co? HCL.
ŁK: HCL z terraformem. (śmiech)
SW: 60% wzrostu prawie. 60. To są absurdalne wartości.
ŁK: Tak, 56%, żeby być dokładnym.
SW: Tak.
ŁK: Patrząc się, to jest procentowo względem tego, co było wcześniej. To też troszeczkę po ilości commitów. Bo to jest istotne.
SW: C, ma się doskonale. Plus 23% użycia.
ŁK: Tylko pamiętaj, że tam leci Kernel Linuxowy i inne rzeczy wokół tego. Więc to też jest takie…. Dla…
SW: Wiem. Ale spójrz też na inną rzecz. Raz: 51%. Więc to jest… Języki niskopoziomowe, bo C i Rust to są języki niskopoziomowe, dalej mają się bardzo dobrze.
ŁK: Znaczy, wiesz co… Bo ja ciągle mam gdzieś w zapleczu te linki, aby zebrać o dyskusji, porzućmy C/C++, które się pojawiają. Coraz bardziej. W szczególności od firm, które wytwarzają. Przejdźmy wreszcie na Rusta, żeby pozbyć się tych problemów, które wynikają z bezpieczeństwa i z tego, co można skopać w C/C++. Więc ciągły wzrost Rusta mnie nie dziwi, bo to jest idealny język do zastąpienia tego.
SW: Tak, ale zobaczmy. Rust ma 207 000k.
ŁK: Comitów, tak.
SW: A C ma 1 milion. Wzrost jest… Jeden ma 51, drugi ma 23% wzrostu.
ŁK: Tam były linie czy commity. Linie?
SW: Linie, tak wydaje mi się.
ŁK: Linie, linie chyba, tak. Dobra, no to już… Pozostawmy to.
SW: Ale też co dla mnie jest ciekawe. Po prostu wiecznie nieśmiertelny Python cały czas zalicza wzrost. To jest język, który jak… Język, który jak przestanie być wykorzystywany, to wydaje mi się, że świat się skończy. Po prostu, co by się nie działo. Od bardzo wielu lat Python zawsze ma powolny, stabilny wzrost.
ŁK: (śmiech) To jest najlepszy drugi język, poza mobilkami.
SW: Tak.
ŁK: (śmiech)
SW: Ale też, co ciekawe też, nie ma JavaScriptu. Jest TypeScript.
ŁK: No. A to tak. To jest mocno ciekawe, że to poszło w tą stronę. Dobra. Ja jeszcze taki…
SW: A jeszcze jedna rzecz. Lua. Wzrost o 34%.
ŁK: Nie wiem, o co chodzi.
SW: Język głównie skryptowy.
ŁK: Nie wiem, o co chodzi. Ja poza home automation i engnes, lua nie dotykałem.
SW: To samo. To jest…. To jest skryptowy język do konfiguracji. Jeszcze jest w Reddicie. Do konfiguracji jakichś tam podsystemów, skryptów różnych. Więc jestem ciekawy, z którego produktu wynika użycie Lua. Bo tego już nie namierzyłem.
ŁK: Dobra. Ja jeszcze 2 pierdoły. Zapomniałem o Armach, architekturze Army w Github Actions. To jest dość istotne, że ten tooling też już nadgania resztę świata. I druga rzecz z newsów, które jest też dla mnie, będą bardziej dokładne tokeny personal acces. Tokeny, które przy jakichś toolach czy innych rzeczach wykorzystujemy, że pozwoli teraz już na robienie tego na bardzo granularnych per repozytorium. Bo personal acces token miał tę wadę… w uproszczeniu czy na poziomie organizacji wydanie tokena tylko do konkretnego repo, co uprości sprawę. Bo dla mnie, jak mam użyć PAT-a to zawsze patrzę na niego trochę z przerażeniem, ze względu na szerokość zasięgu.
SW: PAT-y miały fajną granularność, jeżeli chodzi o Actions. Tam faktycznie miały nieźle. I były bardzo nierówne. Gdzie nie gdzie właśnie, co mówisz, że po prostu dawałeś dostęp zawsze do wszystkiego, z drugiej strony czynności były bardzo, bardzo granularne.
ŁK: Tak.
SW: Też mnie to cieszy, jak najbardziej.
ŁK: Więc to jest z tych newsów. Trochę pominęliśmy coś, co zobaczymy, w którym kierunku pójdzie, bo jest też pokazane coraz bardziej Github Enterprise w Cloude. Coraz bardziej się wyłania gdzieś tam w całości. Czyli…
SW: Można postawić własny serwer Githuba
ŁK: Nie, nie, nie. Hostowany przez nich. Github Enterprise
SW: Tak.
ŁK: Cloude. Czyli nie swój lokalny Guthub Enterprise, który stawiacie u siebie, tylko u nich hostowana instancja SaaS-owa. I ciekawostką jest to, że z założenia nie trzeba czekać, bo wszystkie ficzery wjeżdżają razem z AI w publicznym Githubie. To jest też ciekawostka. No i najważniejsza… To są audilogi lub parę zabawek mocnych do OPsecurity naszego set up’u.
SW: To jak już mówimy o pierdołach, które nam się przypomniały. Dla mnie jeszcze jedna rzecz: skala Githuba. 94 miliony deweloperów. Tak twierdzą, więc pewnie bardziej chodzi o konta i tak dalej.
ŁK: Albo aktywnych użytkowników. To też można w ten sposób, gdzieś w okolicach tego patrzeć.
SW: To jest dużo.
ŁK: Tak.
SW: To jest naprawdę dużo.
ŁK: Jestem ciekaw jakby wziąć… bo pewnie mają taką statystykę, ile tam jest np. commitów albo zacomitowanych linii kodu w ciągu ostatniego roku do prywatnych i publicznych repo. Bo to byłoby ciekawszą statystyką. Nie aktywny użytkownik, który klonuje, tak jak uczestnicy na warsztatach. Albo forkuje. Tylko którzy używają. Jak by to wyglądało. Tej metryki jestem bardzo ciekaw.
SW: Ja bym strzelał, że 94 to jest bardziej po prostu ludzie, bo chcieli mieć maxa. Bo wiadomo - chwalimy się w tym momencie. Ale to nawet… Gdyby to było 50 milionów, czyli dużo, dużo niżej, to dalej jest kolosalna liczba.
ŁK: No, sporo.
SW: Dobrze. Tyle chyba, Łukaszu. Kończymy?
ŁK: Kończymy.
SW: Trzymajcie się. Hej!
ŁK: Trzymajcie się. Na razie.