Software Craftsmanship Saturday vol. 89 – LoL, Fuchsia OS, Microsoft Build i #Snapocalypse

1. Jak zorganizować hybrydowy turniej gry online? Problemy twórców League of Legends.

Gra ktoś z czytających w League of Legends?

Jestem pewien, że tak. Mówimy w końcu o wciąż cieszącej się największą popularnością produkcji, przynajmniej na Twitchu. Przyznam, że mnie szał na LoL ominął. Jako fan Blizzarda, ze wszystkich MOBA zdecydowałem się zainwestować swój czas w ichniejsze Heroes of the Storm, co biorąc pod uwagę, że już w 2019 gra w zasadzie straciła wsparcie było dość kiepską decyzją z mojej strony. 

Kolejnym zjawiskiem, które trochę mnie jako gracza ominęło, to szeroko rozumiana scena turniejowa. O ile Awesome Games Done Quick zawsze znajdzie miejsce w moim kalendarzu i przyznam, że mając okazję być na Intel Extreme Masters w Katowicach całkiem wciągnąłem się w turniej Counter-Strike’a, ale jakoś na tym kończy się moja relacja ze sceną kompetetywną. Dlatego też nawet mnie samego dziwi fakt, że zaraz będę relacjonował Wam przebieg turnieju wspomnianego już League of Legends. Okazuje się, że organizatorzy tegorocznej, majowej edycja imprezy stanęła przed bardzo interesującymi wyzwaniami inżynierskimi.

O niedawnych powrotach do biur mówi się, że o ile praca zdalna była stosunkowo łatwa organizacyjnie, o tyle ta hybrydowa przynosi zupełnie nową, dodatkową warstwę wyzwań. Podobnie pewnie mruczą pod nosem członkowie Riot Esports Tech Team, którzy stanęli przed trudnym wyzwaniem. Ze względu na lockdown w Chinach, ichniejsze zespoły graczy nie mogły przyjechać na odbywające się w Korei Południowej rozgrywki sezonowe, przez co musieli odbywać swoje mecze w sposób zdalny. Ze względu na to, jak bardzo szybką grą jest LoL, sama potrzeba przesyłania pakietów (o stałym narzucie ~35ms vs 15ms on-site) przez sieć zapewniłaby ich przeciwnikom olbrzymią przewagę podczas wspólnej gry. Dlatego wspomniany już RETT zaczął szukać sposobu rozwiązania problemu. Z kilku możliwych opcji, które znajdziecie w oryginalnej publikacji opisującej zdarzenie, zdecydowano się na użycie narzędzia Latency Service Tool. Jest to oprogramowanie powstałe właśnie na potrzeby pandemii Covid-19, a które miało wprowadzić sztuczny ping dla tych graczy, którzy zdołali dotrzeć do Korei.

Latency Service nieustannie mierzy rzeczywiste opóźnienie sieciowe między każdym graczem a serwerem, a w razie potrzeby dostosowuje je, dodając opóźnienie w celu osiągnięcia docelowej wartości PINGa. Jest to rozwiązanie klient/serwer, starające się wprowadzić opóźnienie po obu stronach sieci w równym stopniu.

Niestety, tego typu rozwiązania charakteryzują się bardzo dużą ilością elementów ruchomych w ramach których “coś” może pójść nie tak. W wypadku wspomnianego turnieju “cosiem” była decyzja o tym, żeby część wspierać dwie różne topologie połączeń między graczami – zarówno w pełni lokalną (dla znajdujących się “w biurze), jak i taką z dodanym dodatkowym opóźnieniem, w wypadku meczy z Chinami. Hybrydowość okazała się być zgubna i okazało się, że gracze w Busanie skarżą się, że choć ich gra pokazuje niskie obciążenia pingu, to realnie wszystko jest powolne i ociężałe.

Po przetestowaniu skuteczności narzędzia do obsługi opóźnień Riot stwierdził, że chociaż udało się osiągnąć stabilne środowisko 35 milisekund dla graczy w Chinach, drużyny w Busanie grały z opóźnieniami rzędu 50-55 milisekund. Jak to się wydarzyło? Otóż ze względu na błędy w sposobie pomiaru rzeczywistego pingu, lokalni gracze otrzymywali nadmiarową karę. Całość skończyło się dużym chaosem organizacyjnymi, potrzebą powtórek meczów i łataniem infrastruktury jeszcze podczas turnieju. Problem został ostatecznie rozwiązany w iście hakerski sposób – sztucznie obniżono raportowany ping o 13 ms. Doprowadziło to do kuriozalnej sytuacji, że gracze w Chinach o realnym pingu 35 ms zaczęli na swoich HUDach obserwować, że opóźnienie wynosi 22s. Pozwoliło to jednak na kontynuowanie zawodów, mimo potrzeby powtórki kilku meczy.

Jeżeli jesteście ciekawi, jak przebiegał proces zarówno tworzenia oryginalnej architektury, jak i szukania problemu oraz aplikowania rozwiązania – Riot Esports Tech Team opublikował szczegółowy post-mortem do całej sytuacji (świetnie się go czyta).

Kończąc tą sekcję – jeśli chcecie dowiedzieć się, jak architektura klient-serwer w grach online, niedawno opublikowany artykuł How do Video Games Stay in Sync? An Intro to the Fascinating Networking of Real Time Games stanowi świetne wprowadzenie w temat. A jeśli jednak nie czujecie, że czytanie o topologii sieciowej to jest dobry plan na spędzenie weekendu, zawsze możecie włączyć sobie świetne “Arcane” na Netflixie, dziejące się w świecie wspomnianego LoL. Tam żadnych opóźnień nie uświadczycie, może poza początkowym buforowaniem.

Źródła

• Riot Games Tech Blog: Artificial Latency for Remote Competitors
• How do Video Games Stay in Sync? An Intro to the Fascinating Networking of Real Time Games.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Czy Fuchsia OS jest tak bezpieczna, jak twierdzi Google?

Ostatnio uzewnętrzniałem się trochę na temat mojego niedosytu po ostatnim Google I/O i tak patrząc na to retrospektywnie, dużą częścią mojego problemu z tą imprezą była chyba straszliwa nuda w temacie googlowskich systemów operacyjnych. Nowości z Androida były naprawdę żadne, a dodatkowo brakowało mi czegokolwiek dotyczącego Fuchsii. Ten nowy system operacyjny od Google rozwija się gdzieś mocno w tle, a twórcy co pewien czas rzucają w nas wystarczającymi strzępkami nowych buildów i szczegółów architektonicznych aby nie dało się tego Duke Nukem Forever systemów operacyjnych sklasyfikować jako Vaporware. I tak, wiem, że zasila już w tej chwili Google Nest Hub, ale to urządzenie ma poziom interaktywności automatu biletowego, więc po tym wdrożeniu naprawdę trudno wnioskować za wiele o tym, jak Fuchsia będzie się sprawdzała w realnym użyciu.

W świetle braku oficjalnych komunikatów, trochę jak narkoman na głodzie poluję na nowe publikacje w temacie. Dlatego dzisiaj mam dla Was analizę bezpieczeństwa googlowskiego systemu. Alexander Popov, zajmujący się na co dzień dbaniem o security jądra Linuxa postanowił przyglądnąć się temu, jak wygląda pod tym względem architektura i jej mikrokernel Zircon. Sam artykuł jest dość mocno hermetyczny i pełen naprawdę niskopoziomowych detali, ale na pewno przyda się każdemu, kto chciałby się Fuchsią pobawić – zawiera bowiem sporo wskazówek dotyczących uruchomienia całości, a także przegląd najważniejszych konceptów stojących za systemem operacyjnym.

A jak całość wygląda w kontekście wspomnianego już bezpieczeństwa? Alexanderowi udało się stworzyć rootkit, który był w stanie odpalić w systemie, jednak exploit nie pozwala na eskalację przywilejów. CVE-2022 prowadzi jedynie do błędu ujawniającego nadmiarowe informacje, który, choć stanowi pierwszy krok, sam w sobie nie jest możliwy do wykorzystania. Sam autor też traktuje całość jako eksperyment, który ma stanowić de facto zaproszenie do dalszych badań nad bezpieczeństwem Zircona.

Źródła

• A Kernel Hacker Meets Fuchsia OS | Alexander Popov

3. Co nowego zaprezentowano na Microsoft Build?

Wracając jeszcze raz do moich narzekań w kontekście ostatniego I/O, impreza Google jak co roku otwarła sezon konferencji deweloperskich. Już 6 czerwca odbędzie się WWDC od Apple, a w mijającym tygodniu zorganizowany został Microsoft Build. Jak zatem wypadł event twórców Azure i Windowsa? Microsoft jak zwykle wypuścił tak zwaną Book of News, czyli zbiorcze podsumowanie wszystkich ogłoszeń, ale ja skupię się na wybranych i najciekawszych z mojej perspektywy.

Z pewnością jedną z gwiazd konferencji był OpenAI Codex. Narzędzia deweloperskie oparte o AI dostały swój własny Keynote, a niektóre z dem okazały się być naprawdę robiące wrażenie. Bo jak inaczej można nazwać AI generujące model 3D układu słonecznego stworzony z użyciem biblioteki Babylon.js? Oczywiście, zawsze w takich wypadkach należy zadać sobie pytanie, na ile rzeczywiście mamy do czynienia z rozwiązaniem “general purpose”, a na ile dema są wybiórcze i pokazują po prostu szczytowe możliwości jakiegoś rozwiązania. O tym będziemy mogli jednak przekonać się samodzielnie, bo napędzany przez Codex Copilot zostanie udostępniony, zgodnie z zapowiedziami na tegorocznym Build, już w te wakacje. 

Sam Codex jest obecnie częścią Azure AI Service i ponad 70 aplikacj. Używany jest  min. przez Warp – bardzo ciekawego nowego gracza w świecie terminali, z którym sam obecnie eksperymentuje. Interesującym projektem wydaje się być też ​​Pygma, która ma na celu przekształcenie projektów z Figmy w wysokiej jakości kod. Więcej przykładów znajdziecie w poście OpenAI.

A jak już tak płynnie przeszliśmy na temat Azure, to nie mogę nie wspomnieć o udostępnieniu przez Microsoft nowych możliwości lokalnego developmentu dla programistów pracujących z chmuro-natywnymi bazami pochodzącymi z ichniejszej platformy. W skład tak zwanego Local development experience for Azure SQL Database wchodzą min. rozszerzenia do Visual Studio Code i Azure Data Studio oraz nowy emulator Azure SQL Database, który umożliwia programistom publikowanie i uruchamianie baz danych lokalnie, na skonteneryzowanym, wieloplatformowym emulatorze zapewniającym wierne odwzorowanie azurowych baz danych, umożliwiając uruchamianie i testowanie baz danych w trybie offline.  

Ostatnią z dużych i ciekawych (IMHO) zapowiedzi jest Projekt Volterra. Jest to Dev Kit – niewielki komputer stacjonarny w stylu Mac mini z procesorem ARM. Ma być używany w tworzeniu aplikacji wykorzystujących możliwości sztucznej inteligencji, a to wszystko dzięki wbudowanemu procesorowi neuronowemu (NPU) opracowanemu przez firmę Qualcomm. Dużo mówi się o tym, że wszystkie firmy technologiczne tworzą teraz wyspecjalizowane jednostki obliczeniowe, które zostają zamknięte za lock-inem chmur, dlatego ruch Microsoftu jest tutaj ciekawy. 

Muszę przyznać, że ogólne wrażenia z Builda mam dużo lepsze niż po zapowiedziach Google. Tym razem naprawdę czułem, że mam się z Wami czym podzielić, a tak naprawdę dotknąłem tylko wierzchołka góry lodowej. Osoby mocno zaangażowane w Azure albo technologie Microsoftu powinny przejść przez wspomnianą już Księgę Newsów, w której znajdą około setki większych lub mniejszych zapowiedzi.

Źródła

• Microsoft Build 2022 Book of News
• Powering Next Generation Applications with OpenAI Codex
• The Future of AI Development Tools – Events | Microsoft Docs
• Project Volterra: Everything you need to know about Microsoft’s ARM developer kit | Windows Central
• What is the local development experience for Azure SQL Database?

Bonus: Snapocalypse

Snapchat nie dowiózł wyników i zaczęła się rzeź. 

Główny zainteresowany spadł w czasie jednej sesji o 43%, a z rynku wyparowało… 135 miliardów powiązanych z firmami AdTechowymi, bo kiepskie wyniki Snapchata spowodowały wyprzedaż innych firm (aczkolwiek od pamiętnego wtorku rynek się odrobinę podniósł). Giełda jest nieco zabawna – z jednej strony rozumiem, czemu z powodu kiepskich wyników Snapa obrywa też Tesla, ale jednak musi to być frustrujące dla ludzi pracujących w firmach.

​​Ogólnie maj był strasznie brutalny dla firm technologicznych (a zwłaszcza ich pracowników). Mijający tydzień przywitał nas ogromnymi zwolnieniami w Klarnie, a potem już poszło z górki… Mam nadzieję, że czerwiec przyniesie trochę lepsze wiadomości dla branży.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

A na koniec… małe ogłoszenie! Wróciliśmy z Podcastem.

Będziemy spotykać się w co drugi poniedziałek, aby dyskutować o wszystkim, co wydarzyło się w świecie IT w ostatnich tygodniach. W pierwszym odcinku rozmawiamy razem z piszącym Frontendowe Czwartki Tomkiem, ale wraz z rozwojem formatu możecie spodziewać się lekkich modyfikacji składu w zależności od tematu.

Każdorazowo, wychodzimy poza oczywiste, nadając pojawiającym się nagłówkami szerszy kontekst (tak jak w naszym Weekly 😉).

🔈 Zapraszamy do słuchania! 🔈