Luke J. Li

Czego się nauczyłem w 2021? No właśnie, ten post to będzie takie małe podsumowanie. No to jedziemy. Poznałem trochę Rusta. Na tyle pewnie się w nim czuję, że mógłbym zrobić w tym jakaś prostą apkę. Ale pewnie nie na tyle, żeby przejść rekrutację na Rust developera Poznałem różne techniki renderingu 3D, nauczyłem się kodzić w czystym WebGL, zrobiłem prosty silnik 3D. Poznawałem również nowe techniki renderingu i tworzenia różnych efektów używając biblioteki Three.js. Poznałem wiele zagadnień z matematyki. Zarówno tej potrzebnej do grafiki 3D, jak i ogólnie matematyki na poziomie studiów. Poznałem również wiele zagadnień z fizyki, wszedłem w temat symulacji fizycznych. No ale dopiero liznąłem temat tak naprawdę i ten cel będę realizował jeszcze w przyszłym roku. Porobiłem wiele prototypów gier i toolingu do nich, więc wiem już, jak pewne rzeczy zaimplementować, których nie umiałem zaimplementować wcześniej Liznąłem trochę Golanga Wzmocniłem swoją wiedzę backendo

Oferty pracy w IT (a pewnie i w innych branżach) są pisane w specyficzny sposób. Nie pisze się prawdy, a pisze się nieprawdę i ubiera w ładne słowa. W tym poście omówię pewne występujące w ofertach naciągane formułki i co one w zasadzie mogą oznaczać w rzeczywistości. zarobki zależne od umiejętności/doświadczenia Jest to oczywista ściema. Zarobki głównie zależą od tego, ile sobie wynegocjujesz, a nie od tego, ile umiesz. Oczywiście, jak masz duże umiejętności/doświadczenie, to masz lepszą pozycję do negocjacji. Ale tylko tyle. Możesz puszyć piórka i wołać dużo, ale to i tak tylko potencjał, pozycja negocjacyjna, musisz jeszcze przekonać kogoś, żeby ci tyle dał i że faktycznie warto ciebie zatrudnić, a nie kogoś tańszego. A "wynagrodzenie zależne od umiejętności" brzmi trochę jak szukanie pretekstu, żeby komuś zapłacić mniej. atrakcyjne wynagrodzenie Jak widzę taki zwrot i brak widełek, to od razu mi się czerwona lampka włącza "oo, pewnie mało płacą, skoro ni

Nauka programowania to nie jest coś takiego, że się nauczysz raz i już. No nie. Raczej to przychodzi falami. Nauczysz się czegoś i czujesz się nauczony. A potem się okazuje, że gówno, że nic wcale nie umiesz, więc się douczasz, żeby znowu umieć. Proces nauki to taka sinusoida, a raczej ileś sinusoid połączonych ze sobą, jednak z tendencją wzrostową. Coś jak ten wykres . Czyli na dłuższą metę czujemy, że nasze umiejętności idą w górę, ale na krótką metę są wzloty i upadki (albo lotki i łopatki ). Czasem czujemy, że się cofamy, mimo, że strzałka czasu idzie cały czas do przodu. Co zrobić w takim razie? Jak zachować normalność i odpowiednią perspektywę? Oto garść tipów: Pamiętaj, że twój "upadek" to tylko lokalne minimum . Czyli w dłuższej perspektywie idziesz w górę, a jedynie doświadczasz pewnych fluktuacji skilla. Wyobraź sobie, że to takie kursy walut, że może jakaś waluta iść ogólnie w górę, ale jednak jej kurs będzie się wahać na krótką metę. Czasem je

Programowanie to nie jest zajęcie dla wszystkich. Tylko nieliczni mogą nimi zostać. I to jest jeden skrajny pogląd, jaki można usłyszeć. Programiści jako elita narodu. Mamy też podejście skrajnie odmienne, lansowane przez twórców bootcampów - każdy się nadaje na programistę. Nawet kasjer, co to wczoraj jeszcze skanował kajzerki. Nawet pracownica magazynu, która wczoraj jeszcze jeździła na wózku widłowym. Czyli totalny egalitaryzm. A jak jest naprawdę? Po pierwsze trzeba zwrócić uwagę na to, kto mówi i po co. Z jednej strony mamy ludzi, którzy są przeświadczeni o wyjątkowości swojego zajęcia. To nic, że na codzień klepią rzeczy nie tak wcale wyjątkowe, jak klepanie formatek w React, pisanie wywołań do API czy kod na zasadzie kopiuj->wklej->modyfikuj. I tak uparcie będą twierdzić, że są niezastąpieni i wyjątkowi. Z drugiej strony mamy bootcampy, które zarabiają na drogich kursach, więc w ich interesie jest twierdzić, że każdy może zostać programistą. Łowią sobie klientów.

Dzisiaj jest taka moda, że każdy chce zostać programistą. No dobra, ale po chuj? I to pierwsze pytanie, jakie warto sobie postawić. Po kiego grzyba chcę zostać programistą. Omówmy sobie więc potencjalne powody i czy mają one sens. 1. Dla hajsu To rozsądna odpowiedź, bo programiści faktycznie mogą dobrze zarabiać. Jednak musisz wiedzieć, że nie od razu tak jest. Najpierw zarabiasz jakieś biedne grosze. I żeby zarabiać więcej, najłatwiej jest zmieniać często pracę, w międzyczasie douczać się na własną rękę, a także ćwiczyć przechodzenie rozmów rekrutacyjnych (to sztuka sama w sobie). Do dużych hajsów zwykle ludzie dochodzą latami. A niektórzy wcale, jeśli utknęli w słabej pracy, a mieszkają w małym mieście i jest to jedyna informatyczna firma w całej okolicy (na szczęście dzięki pandemii jest powszechna praca zdalna, więc to już nie powinno stanowić problemu, żeby wziąć i poszukać pracy w firmie z dużego miasta albo z innego kraju nawet). 2. Żeby robić ciekawe rzeczy Pro

Jak znasz dobrze jakiś język, staje się on komfortowy dla ciebie. Jak JavaScript dla mnie. Choć nie będę udawał, że znam go całego. Bo co to znaczy "znać język programowania"? Czy znam wszystkie szczegóły implementacji V8 czy innych silników JSa? No nie. Czy znam wszystkie z kilkuset przeglądarkowych API i różnych obiektów, które można utworzyć ? Też nie. Czy już używam wszystkich najnowszych ficzerów w języku? Kto by na tym nadążył... Jednak pisanie w JS dla mnie jest łatwe. Jest moją strefą komfortu. Potrafię bardzo szybko w nim pisać, z prędkością światła refaktorować, usuwać błędy bez czytania komunikatów, ogólnie czuję ten język. Wpadam również na proste rozwiązania rzeczy, które inni programiści piszą bardzo naokoło i bez sensu. Myślę, że gdybym zrobił trochę dodatkowego researchu, tak, by odrobinę uzupełnić i pogłębić swoją wiedzę, to mógłbym pisać książki o JS. I może tak zrobię. Tylko, że nie wiem, czy jest sens pisać kolejną książkę o samym JavaScript jako jęz

Ogarnianie większego projektu jest trudne. Wchodzisz w projekt robiony przez kogoś innego, dość słabo napisany. Ciężko zrozumieć, o co chodzi. Dokumentacja jest szczątkowa. Zwykle jest jakiś przegląd architektury z lotu ptaka, ale już konkretów obsługi jakiegoś wewnętrznego API ciężko się doszukać. Owszem, w modułach widać jakieś JSDoc, ale zwykle są to informacje kompletnie bez znaczenia, ot nazwy i znaczenie parametrów w danej funkcji. Coś, co i tak już dostarcza TypeScript, jeśli jest w projekcie, więc nie ma potrzeby pisać tego w adnotacjach. Ale gdyby mimo braku dokumentacji, był to projekt dobrze napisany? No nie bardzo, 2 pierwsze literki z SOLID idą się zwykle jebać pierwsze . Moduły odpowiadają często za ileś różnych rzeczy, a żeby coś zmienić, trzeba bezpośrednio modyfikować już napisane, długie pliki. Okej, czasem nie jest tak źle, chociaż dobrze też nie jest. Jeśli widzisz gdzieś drobiny sensu, np. poszanowanie zasad projektowych, to okazuje się, że zostaje to okupion

Od dawna mi chodzi po głowie, żeby zrobić język programowania. Nawet prototypy robiłem. Ale jednak czuję, że jest ten moment, kiedy chcę zrobić coś, co naprawdę będę w stanie wrzucić do sieci i żeby działało. No cóż. Mój język programowania będzie przeznaczony do tego, żeby móc skryptować środowisko-edytor do gier, które również zrobię. Język będzie miał prostą składnię: wyrażenia, czyli coś, co byście oczekiwali od takiego języka, np. żeby umiał liczyć 2 + 2 * 2, czy inne bardziej skomplikowane wyrażenia, z nawiasami, operatorami potęgowania, możliwością odwoływania się do zmiennych, wywołania funkcji itp. np. foo(10) + foo(bar)**2 silne typowanie zmiennych. możliwość przeładowania (overloading) własnych operatorów (żeby móc np. dodawać wektory za pomocą plusa: vec2(10, 20) + vec2(20, 30) ograniczone klamerkami ({}) bloki kodu. Tak zaimplementuję ify, pętle, funkcje itp. Każdy blok będzie mógł zwracać wartość (w Rust jest podobnie). wsparcie out of the box dla asynchroniczn

Niektórzy latają w kosmos, a ty co? A ja nic, ja tylko robię własną planetę. W Three.js Tylko nie mówcie, że wygląda jak wirus. Bo to jest planeta planetowa. No i wygląda prosto, ale musiałem się namęczyć z tym, żeby dało się po kliknięciu rysować te sześciany i rurki w taki sposób, żeby były obrócone zgodnie z powierzchnią kuli. I próbowałem na różne sposoby, a to kombinowałem, żeby brać normalne , dodać do pozycji i wywołać metodę lookAt, ale to jakoś nie działało w każdej sytuacji, czasem kąty były dziwne. Próbowałem też korzystać z obiektów THREE.Spherical, z kwaternionów, czego ja nie próbowałem. Kombinowałem też, jak wydobyć styczną do powierzchni. W końcu nastąpił u mnie paradigm shift. I zamiast rozglądać się na to, co widać gołym okiem, na samą powierzchnię kuli, postanowiłem zajrzeć do samego środka. Bo każda kula ma środek. I zrobiłem tak, że obiekty "patrzą" na środek kuli (mesh.lookAt(0, 0, 0) zakładając, że środek kuli jest w pozycji (0, 0, 0) I oto je

Zrobiłem video-slider w Three.js: https://hex13.netlify.app/videoslider.html Ładuje on videa, a potem renderuje do tekstur (używam WebGLRenderTarget i postprocessingu w Three.js), no i miesza w shaderze, tak, że przejście z jednego filmu odbywa się za pomocą efektów specjalnych. Takie tam. Choć ładnych kilka godzin nad tym spędziłem. Jest quasi tutorial do tego, ale to tylko ogólny opis techniki. Przydatne, ale skrótowe, trzeba dużo główkować samemu, żeby wyglądało i działało to dobrze, biorąc pod uwagę choćby cały boilerplate, jaki musiałem napisać w Three.js oraz kwestie typu usuwanie problemów z ładowaniem filmów czy obsługa eventów na różnych urządzeniach. Dało radę zrobić, ale szczerze mówiąc jeśli miałbym to zrobić coś podobnego kolejny raz, to wolałbym nie robić tego od zera, a mieć już jakiś szablon czy silnik do robienia sliderów/karuzeli, coś co już działa out of the box i jest już dobrze przetestowane i co wystarczy lekko dostosować, żeby działało i było fajne. No

W ramach nauki desktopienia w Rust (patrz poprzedni wpis) zrobiłem aplikację, w której można jechać myszą i będzie się kolorowe kółko przesuwać. Niesamowite! Po tylu latach programowania dalej cieszą proste rzeczy. Wyżej wymienioną rzecz wykonałem za pomocą biblioteki winit (która daje mi okienko i zdarzenia myszowe) oraz za pomocą biblioteki pixels mogłem ustawić wartości RGBA poszczególnych pikseli. Na razie robię to tak, że przelatuję przez wszystkie piksele i ustawiam dany kolor (zastanawiam się, czy nie można tego zrobić bardziej optymalnie, żeby tylko przelatywać przez niektóre piksele, te, które chcę zmienić?). Dokładnego kodu nie będę tu wrzucał, zresztą przykłady użycia tych bibliotek są łatwo dostępne w sieci.

Powracam do robienia apek desktopowych. Tym razem robię to w Ruście. Oto jest taka biblioteka winit , gdzie normalnie możesz sobie zrobić okno i odbiera ono różne eventy, np. myszowe i inne. No i zrobiłem sobie to okno. Później planuję użyć biblioteki pixels , żeby móc robić grafikę do tego, wstawiać piksele, czy co tam można robić w tych pikselach.

Lodash Zastanawiam się, czy ktoś tego używa w 2021 roku? Ja już dawno nie używam. To była dobra biblioteka z 7 lat temu, jak JS jeszcze wiele nie miał. Teraz natomiast jaka korzyść, skoro to wszystko w JS jest? Np. tablice w JS mają natywną metodę find czy inne oferowane przez Lodasha? No i dobre to było, kiedy nie było funkcji strzałkowych w JS, wtedy skróty lodashowe były może i bardziej poręczne niż pisanie function () { .... return ... } Lodash byłby również może lepszą biblioteką, gdyby... miał mniej funkcji. Nawet za czasów, kiedy używałem Lodasha, to wertowanie dokumentacji i szukanie odpowiedniej funkcji, która robi to, co chcę (po nazwach czasem ciężko się domyslić), zajmowało mi więcej czasu niż potrzebowałbym na napisanie takiej funkcji od zera. Czytając doksy, zastanawiam się "po co ktoś z tego zrobił funkcję". Np. funkcja _.drop, która zwraca wycinek tablicy pomijając n pierwszych elementów. Kurczę, to jest to samo, co arr.slice(n). Po co mam importować bibl

Robię grę w pociągi. Na razie wygląda tak: No i ogólnie jest to robione na canvas, co też jest spoko. Na canvasie fajnie się prototypuje. Mam mapę gry, gdzie jest pokazane, gdzie są tory. No i są pociągi, każdy pociąg ma listę torów, po których jedzie (te tory są oddzielne od torów na mapie. Ba, mogą nawet nie istnieć na mapie gry. To tylko informacja dla pociągu, żeby wiedział, po czym jedzie). Dobra, na razie póki co tyle. Jak to rozbuduję, to może wrzucę więcej info albo całą grę.

Robię nową stronę. Będę na niej wrzucał materiały o Three.js (a później i o innych technologiach), więc zapraszam, np. tutaj zrobiłem krótkie wprowadzenie/przykład, jak zacząć w Three.js: How to start with Three.js

Są to generatory. Naprawdę aż szkoda, że tak mało ludzi ich używa, bo to pozwala na zajebiste uproszczenie asynchronicznych interakcji. Trochę jak async/await, ale lepsze, bo bardziej elastyczne, masz więcej kontroli. Możesz nad wszystkim panować i zrobić sobie taki własny asynchroniczny framework, zrobić własne mikrowątki/korutyny rodem z Go, tylko, że w JavaScript. Aż smutne, że to wciąż mało popularne podejście. Poza Redux Sagą chyba się to nie przyjęło jeszcze na masową skalę w JS. A szkoda. Co do elastyczności to mam na myśli, że generatory są bardziej elastyczne w kwestii interpretowania danej komendy, bo można yieldować cokolwiek: const result = yield 123 oraz od strony funkcji wywołującej generator można to dowolnie interpretować. Czyli to nie jest tylko asynchroniczność, ale też komunikacja między korutynami. Czyli generatory pod kątem funkcjonalności są bardziej elastyczne niż async/await. Z drugiej strony rozwiązania oparte o promisy (async/await) w p

Zacząłem używać Notion . To taka aplikacja do organizacji notatek. Fajna, bo tworzysz coś, co przypomina takie tabele w arkuszu kalkulacyjnym albo wiersze w bazie danych. I możesz się odwoływać do innych tabel. Ogólnie fajna sprawa. Można się poczuć jakby się programowało, a to się pisze notatki. I można planować zadania. Nawet customowo można sobie zrobić todo listy. Np. zrobić kolumnę "TODO", a potem zrobić drugą tabelę, która pokazuje tylko dane z pierwszej tabeli, które mają zaznaczone TODO. No i pozapisywałem różne plany dotyczące programowania, też zebrałem różne informacje do kupy. Porobiłem szkice swoich przyszłych produktów, listę rzeczy do zrobienia. Ogólnie poczułem się produktywny. Planowanie wkręca. Ba! Nawet zacząłem estymować własne taski za pomocą ciągu Fibonacciego. Serio, zaczynam rozumieć PMów. W sumie estymacja to fajna sprawa, jeśli jesteś PMem (a właśnie nim jestem robiąc swój własny projekt). Gorzej jeśli jesteś programistą pracującym w zespo

Innym językiem, którego się uczę jest Go (zwane przez wielu Golang, żeby łatwiej było można wyszukać w Google). No ale co można w nim robić? Backendy różne. Mikroserwisy i różne takie. No bo JavaScript mi się znudził (a już szczególnie frontend), więc uczę się czegoś, żeby się móc "przebranżowić" xD A Go ma tę zaletę, że faktycznie już firmy w tym piszą komercyjnie (a w Rust to może za 5 lat się rozkręci rynek), no i projekty w Go to też zwykle webówka, więc coś, co jest mi bliższe niż programowanie systemowe (nawet jak będą oferty z Rusta, to przypuszczalnie będą wymagać doświadczenia w programowaniu systemowym i trzeba będzie pewnie się szargać z C++ przy okazji. No chyba, że WebAssembly i zaskoczy i będą szukać programistów JavaScript/Rust, kto wie). Anyway, to się uczę tych webów w Go. I ostatnio postanowiłem się nauczyć generowania tokenów JWT(JSON web tokens). No ale tutaj miałem problem, nie chciało mi to działać w Go, więc spróbowałem to zrobić w Node (bo Node lep

Uczę się o async/await w Rust. I to jest śmiesznie zrobione, że "futures" (rustowy odpowiednik promisów) się nie uruchamiają same! bo jak wywołasz funkcję asynchroniczną w JS, to ona zwraca promise i się uruchamia od razu. A w Rust tak nie ma! Nic się nie dzieje. Jak wywołasz funkcję asynchroniczną, to dostajesz "future" (tak jak w JS dostajesz "promise"), ale nic się nie uruchomi samo! No ale JS daje obietnice bez pokrycia, a Rust to język dla osób odpowiedzialnych, więc samemu trzeba zadbać o swoją przyszłość, tzn. o future. Samemu uruchamiasz w specjalny sposób, bo Rust ma być wydajnym językiem, a zrobienie tak, jak w JS, że gdzieś tam jest odgórnie ustalona pętla eventów, ktora odpala te promisy, byłoby narzutem wydajnościowym, na który nie wszyscy mogą sobie pozwolić. Jest o tym prezentacja Steve'a Klabnika: The Talk You've Been Await-ing for No i jest trochę zachodu w tym, żeby to zrobić w czystym Rust, więc powstały biblioteki takie

Robiąc swój silnik 3D, stwierdziłem, że tych obliczeń matematycznych nie ma zbyt wiele. Co nie znaczy, że należy je lekceważyć. Wystarczy, żeby mieć z jednym obliczeniem problem i już jest blokada. To było tak, że chciałem zamienić widok z typowego 3D (perspektywa) na widok izometryczny (używając projekcji ortograficznej). I myślałem, że to będzie drobnostka, w końcu biblioteka do macierzy glmatrix sama mi generuje macierz projekcji, jaką chcę. Schody zaczęły się, jak chciałem to potem zoomować, obracać, wykrywać kliknięcia myszy itp. Okazało się, że nie rozumiem, jak działa projekcja ortograficzna! Więc trochę w ciemno to robiłem, a frustracja narastała. Aż w końcu doznałem blokady i przerwałem prace nad projektem. Potem wróciłem do nauki Rusta i paru innych rzeczy, żeby cokolwiek robić konstruktywnego. Ale w końcu wróciłem do tamtego projektu gry (i silnika do niej), ale już bardziej fundamentalnie. Czyli zacząłem oglądać na Youtube materiały o macierzach, jak to dokładnie wygląda,

Więc tak, pisałem sobie ten silnik 3D i cóż, okazało się, że im bardziej się rozrastał, tym więcej miałem problemów z długiem technicznym (zrobiłem coś, co wyglądało fajnie w teorii, ale w praktyce, żeby coś dodać, musiałem trochę pohakować silnik) oraz też zacząłem odczuwać problemy z wydajnością. I tutaj na tym etapie zacząłem eksperymentować z użyciem WebAssembly - ponieważ w profilerze zobaczyłem, że dużo czasu CPU schodzi na liczenie macierzy, postanowiłem liczyć macierze w WebAssembly, używając Rust-a i biblioteki do macierzy pisanej w Rust. I co się okazało? Moja "optymalizacja" nie przyniosła oczekiwanych rezultatów. Być może dlatego, że i tak w JS musiałem iterować po obiektach i masę rzeczy innych robić, a w Wasm tylko liczyłem macierze. Zbyt duża część silnika polegała na (z konieczności) kiepsko napisanym JS, że Więc pomyślałem, że może trzeba jeszcze więcej obliczeń wrzucić do Wasm, najlepiej całe drzewko sceny tam zapisywać i robić tam wszystko, w JS tylko