Doom Engine

Wyobraź sobie, że dostajesz w pracy zadanie skonstruowania czegoś zupełnie nowego. Czegoś, co jeszcze nie do końca wiadomo jak ma działać, ale musi być zrobione. Inżynier z mojej miejscowości Mieczysław Bekker pracował na przykład w latach 60tych nad łazikiem księżycowym dla Nasa. Co za zadanie.

30 lat później niewielkie studio produkujące gry o nazwie ID Software wymyśliło sobie, że zrobi grę, jakiej nie widział świat. Miała być to strzelanka 3D, ale oferująca znacznie lepszą grafikę i dynamiczniejszą grafikę, niż ich poprzednia gra, Wolfenstein 3D. Mały problem - silniki gier oferujące takie możliwości, wtedy jeszcze nie istniały. John Carmack podjął się wyzwania stworzenia własnego silnika, nazwanego id Tech 1. Tą grą był Doom.

Głównym założeniem tego silnika, było to, że renderował on widok 3D z widoku 2D, uwzględniając informację o wysokości. Gra jest podzielona na oddzielne mapy, w których pomieszczenie nie może znajdować się nad innym pomieszczeniem. Jest to ograniczenie, ale jego wynikiem jest to że widok podglądu mapy jest bardzo czytelny. 

Gracz nie ma możliwości skakania, poruszania głową i celowania w górę czy w dół, co może nieco przeszkadzać na początku współczesnym graczom. Wynika to z ograniczeń silnika. Jednocześnie, Doom nie jest grą 2-wymiarową, ponieważ uwzględnia wysokość w wielu sytuacjach. Przykładowo, więksi wrogowie nie mogą przejść przez za małe drzwi, a wrogowie latający aby zaatakować gracza, muszą zmienić wysokość lotu. Albo wystrzelić fireballa :) Żeby było ciekawiej, to wysokość eksplozji jest nieskończona, a same eksplozje i zasięg ich rażenia, są kwadratem a nie kołem.

Założenia i ograniczenia sobie, ale jak to wszystko zostało "zakodowane"? John Carmack znalazł badanie naukowe na temat Binary space partitioning, techniki renderowania obrazu w wydajny sposób i zaimplementował je w grze. 

 

Json Driven UI / Server driven UI

Co by się stało, gdyby kod frontendowy aplikacji można było by generować lub pisać w formie JSON?Przykładowo, każda podstrona aplikacji mogła by być pobierana jako osobny plik konfiguracyjny, który zostanie załadowany do kompilatora i z niego, odtworzone zostaną sekcje oraz logika. 

Obecnie widoki robimy tak, że pobieramy dane z serwera i czasem mapujemy je na widoki niemal 1:1, a czasem, po prostu wstawiamy je w już istniejące komponenty.  

Przykładem może być komponent tabelki. 

I Don't get it

 

Gromadzenie wiedzy w Google Keep

Najważniejszym ograniczeniem podczas nauki jest według mnie brak jasnej wizji. Ucząc się po trochę różnych tematów jako junior, prawdopodobnie nie nauczymy się żadnego z nich na tyle dobrze, by móc zrobić w nim coś konkretnego. 

Przykładowo, uczymy się na raz Pythona, PHP i JS, wszystko nam się miesza i nie wiemy, jakie akcje podjąć jako następne. Do tego dochodzą coraz to nowe tematy - może uczyć się sieci, a może ai.

Z czasem zmienia się to i gromadzimy kapitał wiedzy, który pozwala na w miarę łatwe zrobienie w technologiach X, Y i Z wszystkiego co wymyślimy sami, albo klient. Pozostaje jednak problem nauki nowych rzeczy. 

Ostatnio testuję nowy sposób na naukę. Zadeklarowałem sobie, że w Google Keep będę trzymał jedynie zadania, które nie są bazą wiedzy. Bazę wiedzy buduję w Obsidianie, chociaż zastanawiam się, czy nie lepiej robić to w Anki albo pytać na bieżąco LLM :)

 

 Następnie robię sobie karteczki dotyczące technologii, które chcę powtarzać lub się ich uczyć od zera. To jest mój punkt odniesienia. Zapisuję sobie w nich pytania, które nachodzą mnie podczas nauki lub w czasie wolnym ;) Jeśli wpada mi do głowy nowy temat, wrzucam kolejną zgrubną kartkę do Google keep. Śledzę w nim też progres nauki z materiałami. Dzięki temu, mogę łatwiej śledzić postęp i wiem, czego jeszcze chciałbym się nauczyć i jakie problemy rozwiązać.

Daj znać w komentarzu, co o tym sądzisz. 

AI engineers now and then

 

Jak szybko znacząco poprawić swoją wiedzę w danym temacie?

Kilka lat temu dostałem nowy projekt w firmie. Sytuacja wyglądała tak, że frontend w Angularze robiło3 innych deweloperów, którzy mieli mniejsze doświadczenie. Projekt zawierał kilka technologii których jeszcze nie znałem, na przykład Spectatora, Ngrx i bardzo wymagające pokrycie testami.

Przed projektem poświęciłem kilka wieczorów na ogarnięcie tych strasznych technologii - no i co się okazało? Ano to, że...

• Spectator to po prostu ułatwienie testowania w Jest
• Ngrx to przeniesienie idei Reduxa którą znałem z Reacta, do Angulara
• Pokrycie testami można łatwo sprawdzać w Intellij Idea (który to intensywnie wtedy używałem)

Aby móc sobie radzić produkcyjnie (i produktywnie) z tymi technologiami, nie trzeba było lat doświadczenia. Wystarczyło przeczytać dokumentację i ogarnąć jakiś projekt, który ich używał. Co więcej, wymagana była chęć nauki, a o to teraz najtrudniej.  

Kompas, czyli rzeczy których nie potrzebujemy

Na początku filmu Lawrence z Arabii jest scena, kiedy główny bohater zostaje pozbawiony przewodnika. Gdy inny Beduin proponuje mu pomoc w drodze przez pustynię, Lawrence odmawia. Twierdzi, że poradzi sobie jedynie ze swoim kompasem.

Ta scena uderzyła mnie, ponieważ zauważyłem, że często zbyt bardzo polegamy na zewnętrznych pomocach, zamiast na naszym instynkcie. Arabowie podróżujący przez pustynię nie potrzebowali kompasu, ponieważ świetnie ją znali. Jeśli znasz się na tym co robisz, nie potrzebujesz zewnętrznych pomocy.

Antynauka

Wiedzy w Internecie mamy dzisiaj więcej niż kiedykolwiek, a ciągle przybywa. Niestety, ale z jej jakością jest coraz gorzej ;) Antynauka to marnowanie czasu, które daje wrażenie że robimy coś przydatnego dla rozwoju umiejętności. Przykłady:

* 90% filmów na YouTubie / 100% shortsów

* Szukanie skrótów / najlepszych materiałów na jakiś temat 

*  Robienie tych samych, powtarzalnych rzeczy bez analizy / refleksji

* Robienie rzeczy bez zrozumienia podstaw 

* Czytanie newsów na jakiś temat 

Vscode Copilot - wsparcie dla plików z promptami

Customize AI responses in VS Code

Copilot dodaje wsparcie dla plików z promptami, dzięki czemu będzie łatwiej dodawać reużywalne instrukcje dla różnych zadań. 

Problem wielorękiego jednorękiego bandyty

 

Ciekawe zagadnienie, które pozwala lepiej zrozumieć reinforcement learning. Wyobraźmy sobie, że jesteśmy w kasynie i mamy przed sobą kilka automatów do gry. Pociągamy za kolejne dźwignie automatu i z czasem odkrywamy, że niektóre z nich dają lepszą wypłatę niż inne. Celem jest uzyskanie jak najwyższej nagrody.

Problem polega na tym, czy mamy skupić się na eksploracji, czy na eksploatacji. Eksploracja to odkrywanie nowych dźwigni, natomiast eksploatacja, pozostanie przy tych, które dają dobre wyniki teraz. 

Eksploracja może prowadzić do tymczasowego zmniejszenia wygranych, a eksploatacja, do zmniejszenia szans na nowe wygrane. 

Problem można zastosować w wielu dziedzinach życia. Przykładowo, możemy uczyć się nowego języka programowania, ale czy nie lepiej jest pozostać przy tym, który już dobrze znamy? Lekarz może zlecić dobrze znaną terapię, albo wysłać pacjenta na mniej znaną i bardziej ryzykowną.  

Arrazzo Specification

Ostatnio wpadłem na https://spec.openapis.org/arazzo/latest.html. Jest to powstający projekt, mający na celu stworzenie specyfikacji do jeszcze lepszego opisywania endpointów. Oprócz swaggera, oferuje ona bardziej szczegółowy opis, na przykład opisujący kolejność pobierania danych. Ciekawa inicjatywa, czekam kiedy pojawi się w szerszym użyciu :)

Przeuczenie (nadmierne dopasowanie) w rzeczywistości

Przeuczenie to negatywna sytuacja, kiedy zbytnio dopasowujemy się do czegoś. Niesie to za sobą konsekwencje. Kilka przykładów:

• Osoba, która nigdy nie opuściła rodzinnego miasta i stara się szpanować tuningowanym samochodem
• Pracownik robiący w tej samej firmie przez 20 lat w ten sam sposób, który zostaje zwolniony i ma pretensje do wszystkich o to, że świat poszedł do przodu
• Hejter, który siedzi na politycznym forum / Linkedinie i robi sobie hobby z komentowania rzeczywistości w coraz bardziej złośliwy sposób. W mniej bolesnej formie, są to osoby które żyją w jakiejś internetowej społeczności, która nie ma realnego znaczenia.
• Rodzina, która zaczyna mówić językiem coraz mniej zrozumiałym dla wszystkich wokół

Sposoby jak realnie poprawić jakość kodu

Używaj ESLint

ESLint to narzędzie do analizy statycznej kodu JavaScript, które pomaga wykrywać i naprawiać problemy w kodzie. Dzięki niemu można zautomatyzować proces sprawdzania zgodności kodu z określonymi standardami, co znacznie poprawia jego jakość. Konfigurując ESLint, warto dostosować reguły do specyficznych potrzeb projektu, aby maksymalnie wykorzystać jego możliwości.

Pracuj jak tatuażysta albo chirurg, czyli znowu o skupieniu

Jeśli masz trudności ze skupieniem się na 25 minut, pamiętaj, że tatuator podczas sesji skupia się na 6 do 10 godzin :)

Podobnie chirurg operujący pacjenta. Nie chcę nawet myśleć, jak bardzo musi się skupiać wspinacz zdobywający jakąś trudną górę.

Ze swojego doświadczenia przytoczę nieco mniej spektakularne przykłady. Kiedyś napisałem jednego dnia jakieś 30 tysięcy znaków, pracując jak szalony z techniką Pomodoro i słuchając Shakiry, która leciała w galerii w której wtedy urzędowałem. Raz udało mi się też zrobić jednego dnia 22 leki recepturowe. 

Co można zrobić by się lepiej skupić?

 Mój autorski sposób:

• Odstaw zbędną elektronikę, by nie widzieć powiadomień. Ustal sobie, o której godzinie sprawdzisz telefon. 
• Włącz sobie jakąś playlistę z muzyką do skupienia. Może to być na przykład muzyka z Sim City, jakieś low fi albo https://www.flowtunes.app/. Jeśli zamulasz, wybierz coś bardziej energetycznego. Staraj się nie słuchać niczego mocno angażującego. Przykładem jest dla mnie słuchanie nowej muzyki - nie mogę się często powstrzymać, by nie sprawdzić, co aktualnie leci i poczytać coś więcej na temat autora. Czasem jednak słucham Radio Swiss Classic.
• Zadbaj o dobre samopoczucie. Zjedz coś lekkiego, naszykuj swoje ulubione picie. Zawsze mam przy sobie wodę w butelce wielorazowego użytku i kawę / herbatę.
• Zapisuj sobie zadania w formie list todo i aktywnie dodawaj do nich nowe rzeczy.
• Side note - wydaje mi się że chirurg czy tatuażysta tak nie pracuje, anyway
  
• Pracuj :) 
• Jeśli robisz np. coś dla klienta albo dla innej osoby z zespołu (ach ta praca w korpo), to pytaj o feedback. Niepokój często powoduje prokrastynację. 
• Z czasem nawyk pracy wejdzie Ci w krew i będziesz czuł się niekomfortowo, gdy nie będziesz tego robił.
  

 Inspiracje

• https://www.gareth-evans.com/do-the-thing/