Luke J. Li

Gry w przeglądarce jest to raczej hobbystyczna działka. Owszem, są firmy, które zarabiają na grach przeglądarkowych, czasem jakaś oferta pracy jest, ale powiedzmy sobie szczerze - to nie jest pewna ścieżka kariery. Jest to nisza, na dodatek niezbyt doceniana czy szanowana (a szkoda, bo wymaga często dużych skilli). Więc jeśli twoją motywacją jest to, że robienie gier jest ciekawe i chcesz po prostu je robić, to bardzo zachęcam... ...ale jak chcesz oprzeć na tym swoją karierę i znaleźć pracę, to raczej sugerowałbym znaleźć sobie inne, bardziej rynkowe zajęcie. Jednak tworząc gry przeglądarkowe łapiesz parę rzeczy, które mogą ci się przydać poza gamedevem: WebGL (i biblioteki obsługujące go takie jak Three.js) - w WebGL można robić różne wizualizacje czy demka, co czasem jest poszukiwane na rynku... chociaż rzadko i ciężko się dostać, bo jest duża konkurencja, więc również odradzam opieranie na tym swojej całej kariery, bo się przejedziesz. Tym niemniej fajnie to wygląda...

Programowanie jesienią ma wymiar pewnej takiej zadumy. Ciemno, zimno i ponuro. Gorące napoje takie jak kawa czy herbata albo kakao są pite. Siadasz pod kocykiem i piszesz kody magiczne jak te, o których marzyłeś wiele lat temu, ale których nie umiałeś wtedy jeszcze napisać, gdyż twoje umiejętności były daleko niższe niż te, które są dzisiaj. Jednak ponuro. I ta ponurość jest potęgowana przez ogólną listopadową aurę, która kojarzy mi się z jakimiś wycieczkami do muzeum. Nie wiem, czemu tak. Taki mam nastrój. Ale teraz mamy październik, nastrój póki co grobowy. Chandler z Przyjaciół umarł. Tyle wspaniałych chwil z tym serialem. Super postać. Wiem, że to już nie jest o programowaniu, ale warto wspomnieć. Z kodzeniem natomiast jest taki problem, że jak się zacznie, to ciężko skończyć. Okazuje się, że problemy są bardziej złożone, niż pierwsze przybliżenie. Motywacja spada, bo poczucie możliwości powodzenia spada. Można brnąć dalej, niczym po kałużach, jak masz dobre buty. Może do c...

Wchodzę w tematykę Eslinta. Uczę się go używać bardziej świadomie. Robić własne wtyczki i takie tam. A zaczęło się niewinnie. Od prób samodzielnej konfiguracji eslinta pod Reacta. Nie zastanawiałem się nad tym wcześniej, jeśli jakieś lintery były w projekcie, to były. Ale cholera, chcę robić dobrze, chcę robić profesjonalnie. Więc zacząłem rozkminiać konfigurację i co teraz polecają. Sprawdziłem eslint-plugin-react - chuja to sprawdza . No może tak się nie powinno pisać na poważnym blogu, ale takie moje pierwsze wrażenie, może mylne. A eslint-config-react-app lepszy? No nie, też nic to specjalnie nie sprawdza raczej. Sprawdziłem też AirBnB (reguły "airbnb", "airbnb/hooks"), ale tamtejsze reguły to już kompletnie są odklejone (i ostro krytykowane przez społeczność swoją drogą). Czepiają się o niemające znaczenia formatowanie, a taki kod uważają za poprawny w komponencie reactowym: export function Foo() { const [state, setState] = React.useState({ c: 1 ...

Obiektówka jest spoko, ale pewne rzeczy są nadużywane w kodach, które chcą uchodzić za obiektowe. Dziedziczenie. Jeśli nie zmusza cię język albo framework, to dziedziczenie zwykle nie jest specjalnie dobrym pomysłem. Powoduje większe związanie implementacji między klasami. Lepiej kompozycji użyć albo przekazywać referencje. Albo wydzielić interfejs i niech dwie klasy implementują ten sam interfejs. To zwykle wystarczy, żeby pozbyć się dziedziczenia. Gettery/settery - czasem się przydają, ale to nie znaczy, że każde pole w każdej klasie ma dostać getter i setter. Problem z getterami i setterami jest taki, że niszczymy hermetyzację pozwalając na to, żeby obiekty odczytywały/zapisywały bezpośrednio dane obiektu. Na tym etapie moglibyśmy równie dobrze zrobić wszystkie pola publiczne, bo na to samo wychodzi (i czasem wszystkie pola publiczne są okej! To, że piszemy OOP nie znaczy, że nie potrzebujemy czasem jakiegoś pojemnika na dane). Zależności między obiektami - podzielenie ap...

Lane. Czym jest lane? Uliczka. Alejka. Pas ruchu. Ale co to robi w React? I co to ma wspólnego z włóknem (fiber?) Patrzę na kod https://github.com/facebook/react/blob/2807d781a08db8e9873687fccc25c0f12b4fb3d4/packages/react-reconciler/src/ReactFiberLane.js i myślę . Są tam rozmaite zmienne. Zera i jedynki. To muszą być maski bitowe! Te alejki mają różne rodzaje. Ale i priorytety. Widnieje też na horyzoncie funkcja getNextLanes. Czym ona jest? export function getNextLanes(root: FiberRoot, wipLanes: Lanes): Lanes { Jak widzimy pobiera ona korzeń włókna oraz alejki w trakcie robienia. I zwraca alejki następne w kolejności. Wchodząc w nią, czujemy błogość nicnierobienia. Słówko idle się pojawia w zmiennych. Sprawdzamy, czy jesteśmy w środku renderowania, jeśli tak, to zmiana alejki może spowodować utracenie postępów. Więc róbmy tak tylko, jeśli nowe alejki mają priorytet wyższy. Dalej komentarz o splątanych alejkach. Przechodzimy dalej. Wokół panuje półmrok. Zbliż...

Światek JavaScriptu, frontendu to jedno wielkie FOMO. Nie uważasz przez chwilę, to się okazuje, że już są kolejne frameworki do nauczenia, biblioteki do obczajenia, wzorce do zrozumienia. Zeszłoroczne dobre praktyki okazują się już przestarzałe i teraz już należy robić inaczej. Można mieć na to wyjebane i robić swoje. I jest to podejście spokojnego programisty, który gdzieś tam klepie po firmach i ma fokus na dostarczanie tasków na produkcję, a nie na naukę frameworków dla frameworków. I to jest dobre podejście. Do czasu zmiany pracy. Bo wtedy się okazuje, że musisz się praktycznie od nowa uczyć masy rzeczy, frontend już jest inny, nie chcą cię już na rozmowach, bo nie znasz jakiejś tam nowej opcji w libce, która weszła akurat wtedy, jak byłeś zajęty pracą. Więc co robić? Można się uczyć na bieżąco nowości. Skąd jednak wiedzieć, czego się uczyć? Cóż, najświeższa wiedza jest na Twitterze (no dobra, czasem świeższa wiedza jest na Githubie, Discordach itp. no ale na Twitterze ta...

Znowu robię własny edytor. Ale tym razem edytor kodu. W sumie jeszcze takiego nie robiłem. Tzn. chciałem kiedyś zrobić własne IDE, ale wykorzystując gotowy widżet edytora (używałem wtedy CodeMirror). Jednak teraz idę dalej i chcę zrobić cały edytor kodu, tak żeby mieć nad wszystkim kontrolę. Na razie myślę, że to tak zrobię (to może się zmienić jeszcze): do trzymania tekstu w edytorze planuję użyć struktury danych zwanej "piece table", może dodatkowo każda linijka będzie miała osobną tablicę kawałków. Zobaczę. Zacznę to pisać w JS używając HTML/CSS do wyświetlania kodu. Nie będzie to docelowa technologia - planuję później stopniowo to przepisywać na Rust i wgpu. Docelowo będzie to apka desktopowa, natywna (żeby edytor szybko działał, bez jakichś Electronów), ale z możliwością odpalania jej również w przeglądarce (bo lepsza promocja - więcej osób wejdzie na stronę i potestuje sobie online, niż będzie ściągać cały edytor i instalować u siebie). Do renderi...