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