Luke J. Li

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