Luke J. Li

Oto absurdy rekrutacyjne, których doświadczyłem w tym roku: 7h robienia zadania domowego (trzeba było prostą apkę w Node.js zrobić), potem feedback, który nawet nie był słowny, ale punktowy. Firma oceniała kandydatów wg punktów. U mnie zabrakło im obsługi błędów (ale nie napisali, że to ważne), więc miałem mniej punktów, więc wypad XD Śmieszne to jest, bo pokazuje ogólne myślenie podczas oceniania, czyli "nie zrobiłeś czegoś? Pewnie tego nie umiesz. Mamy kandydatów, którzy to napisali, oni umieją". Zadanie domowe z tworzenia gier w Pixi.js. Nawet to ciekawe na początku było, bo potrzebowałem googlać, jak się robi pewne rzeczy z Pixi.js. Więc sam skorzystałem na tym. Jednak nie kontynuowałem tego zadania, ponieważ po 2 godzinach owszem, ruszyłem temat i może po 4h by mi się udało zrobić "jakoś" to zadanie. Jednak w wymogach było napisane, że wymogiem jest duża jakość kodu i sensowne podzielenie tego wszystkiego na klasy. Myślę, że jakbym chciał to dobrze zapro

Więc lecimy: lanie wody w CV. Jak napiszesz CV, to odłóż to na dzień i przeczytaj na świeżo. Czy na pewno nie powrzucałeś tam informacji, które są całkowicie nieadekwatne do stanowiska pracy? Jeśli aplikujesz na backendowca, to czemu wpisujesz obsługę Photoshopa w skillach? Czemu w każdym punkcie doświadczenia powtarzasz tę samą formułkę? W jednym miejscu "na rzeczonym stanowisku byłem odpowiedzialny za implementację apek w React", w drugim "na rzeczonym stanowisku byłem odpowiedzialny za implementację apek w Node.js"? Szum informacyjny. przyznanie się do niewiedzy HRom . Rekrutacje w IT zwykle odbywają się tak, że najpierw rozmawiasz z osobą nietechniczną, która nie ma pojęcia o programowaniu, a ma tylko za zadanie zrobić screening, czy się nadajesz na rozmowę o pracę. I załóżmy, że na danym stanowisku wymagana jest technologia X, którą słabo znasz. Błędem jest mówienie "a bo ja słabo znam tę technologię". Lepiej powiedzieć, że ją ogarniasz. Za

Zakodziłem swojego taska. Zakomitowałem i pusznąłem na serwer. Dałem merdż rekłesta. No i czekam. Nie wiedziałem, co ze sobą zrobić, więc wyłączyłem wifi w kompie, żeby włączył się dinozaur. Zacząłem grać. Tak mnie to wciągnęło, że aż pół godziny spędziłem na tym. Nagle stuka mnie w ramię kolega senior. - Czemu nie odpisujesz? Wysłałem ci wiadomość. - A no bo ja, no wiesz, wyłączyłem internet, żeby pograć w dinozaura. - Do tego nie musisz wyłączać internetu. Wystarczy wejść na chrome://dino - rzekł senior i byłem pod wrażeniem jego wiedzy. - O, nie wiedziałem tego! - No to jak masz jakiś problem, to pytaj. - To ty masz jakiś problem, bo przyszedłeś. - A, no tak. No bo dałeś mi tego merdż rekłesta, tak? Ale tam w ogóle nie ma napisanych testów. - A od kiedy muszą być pisane testy? - Od kiedy zmieniliśmy definiszyn ow don. Wcześniej rzeczywiście nie pisaliśmy testów, bo nie było tego w DoD. - A co to są testy i jak się je pisze? - może i głupie pytanie, ale nigdy wcześniej

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

Hej! Będzie to seria wpisów (a w zasadzie już jest to seria wpisów, bo już to zacząłem pisać). W każdym razie będę tu omawiał różne ciekawostki jeśli chodzi o stringi w Ruście. Np. dzisiaj omówimy sobie, w jaki sposób można napisać funkcję, która konwertuje takiego stringa "foo_bar_baz" na takiego: "fooBarBaz" Czyli zamieniamy z notacji snake case na camel case. Taka zabawa. A więc zaczynamy. napiszemy sobie funkcję main oraz sygnaturę naszej funkcji: fn main() { println!("{}", to_camel_case("foo_bar_baz_qwerty")); } fn to_camel_case(s: &str) -> String { } Jak widać jest to funkcja, która pobiera wycinek stringa ( string slice ) i zwraca stringa o typie String (chodzi o to, że potrzebujemy stworzyć nowego stringa i go zaalokować na starcie, dlatego zwracamy String, a nie &str). Dalej, stworzymy również wspomnianego już Stringa i go zwrócimy (na razie jest pusty). Możemy to zrobić poprzez `return out;`. Ale powiedzmy,

Robię sobie HelloWorldzik w Nest.js, żeby zobaczyć, o co cały szum. Bo podobno to jakiś nowoczesny framework w Node.js, który obudowuje Express/Fastify i na tym kładzie swoją architekturę. I wiecie co? Rzeźnia to jest . Ale o tym za chwilę. Na razie wspomnę o tym, że jest to napakowane wzorcami jak Angular (zresztą było to inspirowane Angularem). Ale żeby tylko. Wzorce projektowe wcale nie są trudne. Mam nawet wrażenie, że Nest.js mający opinię chyba trudnego frameworka, wydaje mi się tutaj dość łatwy pod kątem architektury (wcześniej czytałem dokumentację i w miarę przejrzyste to było). No dobra, to gdzie ta rzeźnia? W niepotrzebnej magii i opieranie wszystkiego o jakieś magiczne dekoratory i magiczny sposób, w jaki są wstrzykiwane rzeczy do klas. Przy czym starałem się zrozumieć i wykorzystać moc wstrzykiwania. Więc widząc sposób, w jaki deklaruje się route'y nawet się ucieszyłem, wygląda łatwo, mamy dekorator @Get i tam można dać ścieżkę, np. hello/:name, żeby kontrol

Wiecie, to takie coś, że ciągle wam się wydaje, że nie jesteście prawdziwymi programistami, a tylko udajecie. I później się boicie, że to się wyda. Idzie za tym zaniżone poczucie swojej wartości i kompetencji. Takie coś może mieć negatywne konsekwencje: W pracy boisz się czegoś spytać, bo wydaje ci się, że już powinieneś to wiedzieć, więc ci głupio Niektórzy robią bezpłatne nadgodziny, żeby się nie wydało, że nie wyrabiają z taskami (co uważam za głupotę) Na rozmowach o pracę zaniżasz swoje osiągnięcia, w rezultacie wychodzisz słabiej, niż mógłbyś Godzisz się na niskie stawki, bo czujesz, że nie zasługujesz na więcej. Boisz się aplikować wyżej (z juniora na mida, z mida na seniora itp.), bo przecież nie czujesz się jeszcze godny, boisz się, że się ośmieszysz itp. itp. Moje tipy? Spójrz na innych Skonfrontuj się z rzeczywistością Dostrzegaj i spisuj swoje osiągnięcia Poczuj się mniejszością Spójrz na innych. Myślisz, że inni są tacy dobrzy? Hmm... niektórzy pewn

Niby znam Node.js, ale ciągle się czegoś nowego dowiaduję. I tak niedawno dowiedziałem się, że: Node.js ma wątki. A nie miał przecież. Zawsze się mówiło, że jest jednowątkowy. Jakoś w tamtym roku jednak na jednej z rozmów rekrutacyjnych padło pytanie "czy Node.js jest jednowątkowy?". Powiedziałem, co wiedziałem, że "nie" . Patrząc na reakcję osób rekruterskich* już widziałem, że coś chlapnąłem. Dopytywali się "na pewno? Czyli nie ma wątków?" . I nie wiem, czy cieszyli się w duchu, że sam się wkopałem, czy może chcieli mi dać wskazówkę, żebym się wycofał z tej opinii? (niczym na egzaminie ustnym profesor pyta się studenta próbując go naprowadzić na właściwy kierunek). Ale później "wracając do domu" (w sensie zamykając kartę z rekrutacją w przeglądarce, bo na tym polega teraz "wracanie do domu z rekrutacji"), poczytałem sobie o tym i okazało się, że już od jakiegoś czasu Node.js owszem ma wątki. Patrzcie sami, to dowód: https

Rekrutacje w IT są o tyle śmieszne, że firmy same się sabotują. Zobaczymy jak: Rekrutacje ciągną się zbyt długo , a potem albo kandydat się rozmyśla, albo sam je anulujesz. Czyli samozaoranie. Prowadzenie rekrutacji, żeby prowadzić rekrutację XD Wymagasz zbyt długiego stażu pracy w danych technologiach . Czyli to słynne wymaganie 5 lat w technologii, która istnieje od lat 2. Oczywiście zwykle nie jest to aż tak drastyczne. Tym niemniej jak odrzucasz kogoś, który przechodzi test techniczny, jednak ma w danej technologii tylko rok doświadczenia, a nie trzy, to znaczy to, że coś poszło nie tak z twoją karierą i lepiej byś się sprawdził jako kanar w autobusie (który musi przecież sprawdzać ważność biletów) niż rekruter czy osoba decydująca o wyniku rekrutacji. Uwalasz za rzeczy, których można się nauczyć w maks kilka godzin. Zauważyłem, że programiści, którzy się zasiedzieli w jakichś projektach, utracili kontakt z rzeczywistością i wydaje im się, że jak oni się uczyli jakiejś

Pogadamy teraz o architekturze na backendzie. Konkretnie o mikroserwisach. Na czym polegają mikroserwisy? Otóż na tym, że zamiast mieć jedną monolityczną apkę, ma się wiele różnych małych mikroapek. Jednak modularność to nie wszystko. Bo przecież apki mogą być podzielone na moduły i nie będzie się nazywać tego mikroserwisami. Jednak mikroserwisy biorą ideę modularności dalej, aż do Księżyca. Takie mikroserwisy mogą być na różnych serwerach (prawdziwych albo wirtualnych) i wszystko mają osobno. W monolitycznej apce jest jedna baza, to tutaj każdy mikroserwis może mieć swoją osobną bazę i osobne wszystko. Totalna izolacja. Mogą być pisane nawet w innych językach programowania. Tylko to rodzi problem komunikacji między mikroserwisami. Zamiast wywoływać funkcję, to trzeba się komunikować przez sieć z innymi mikroserwisami. Czyli wszystko musi być jakoś serializowane. Można przesyłać dane np. za pomocą REST i JSON, ale np. można też użyć gRPC, czyli taki binarny sposób przesyłania da

Kilka luźnych tipów (chcę je później zebrać w coś bardziej zorganizowanego, na razie tak tylko sobie piszę). kartka twoim przyjacielem. Jak chcesz, to możesz korzystać z apek do diagramów (będzie łatwiej się podzielić z innymi), anyway chodzi o to, żeby sobie rozrysować to wizualnie, co będziesz mieć w tej apce, jak będzie się to wszystko ze sobą wiązać i komunikować. pomyśl o rodzajach danych. - nie wiem, czy to dobre słowo, bo nie chodzi mi o typy danych. Napisałbym struktury danych, ale też nie chodzi mi o struktury danych typu drzewko, graf. Bardziej o to, jakie obiekty dziedzinowe będziesz mieć w apce reprezentowane przez jakieś obiekty. Np. w apce todo list możesz mieć: Task - pojedyncze zadanie z polami `text` czy `isDone` TaskList - lista tych zadań FilterCryteria - czyli które zadania mają być wyświetlane Project - np. "Zrobienie zakupów" to może być projekt, z zadaniami typu "kup mleko", "kup mięso" Niektóre z

Robię projekt w Rust. Będą fajerwerki, mówię mam. Dosłownie. To są fajerwerki. Pisane w Rust, skompilowane do WebAssembly i przez JSa przesyłane do WebGLa. I się renderują. Później powrzucam screeny, na razie musicie mi uwierzyć. Anyway, czego się nauczyłem do tej pory tworząc ten projekt? iteratory w Rust mogą być szybsze od zwykłej pętli iterującej po liczbie i . Ogólnie miałem taki problem, że iterując jednocześnie po dwóch tablicach (iteracja po i i odniesienie się do elementów z dwóch tablic o tym indeksie), wydajność takiego kodu była taka sama jak wydajność analogicznego kodu w JS. Jednak jak poszedłem po rozum do głowy i użyłem iter() oraz zip() żeby połączyć dwa iteratory, nagle zaczęło być szybciej. Okazuje się, że iteratory w Rust są tanie w użyciu. bindingi wasm-bindgen potrafią wyeksportować struktury z Rusta jako klasy JS. Więc można od strony JS po prostu robić new Foo i się utworzy instancja klasy z metodami. To jest nowe dla mnie, bo mogę utworzyć taką klasę i