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
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
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.
Robię kolejny silnik do gier. Ale robię go w sposób inny niż zwykle. No bo zwykle, jak robię takie rzeczy (bo ja to już nie jeden silnik zrobiłem, nawet jeśli były to małe silniki), zajmuję się najpierw technicznymi aspektami takimi jak wydajne wyświetlanie grafiki w WebGL choćby. A teraz? No teraz właśnie uznałem, że techniczne aspekty mam już obcykane, bo nauczyłem się ich w poprzednich projektach. Teraz co robię? Ano zdbam o samą architekturę tego silnika. Żeby to dało się utrzymywać potem. Ogólnie zanim zacząłem pisać, to sobie rozpisałem to na kartce, jak to ma wyglądać, cały przepływ danych. I wygląda to mniej więcej tak: INPUT -> EVENT HANDLERS -> ACTION DISPATCHER -> STATE -> STATE DELTAS -> RENDERER Czyli najpierw jest input, jakieś zewnętrzne zdarzenie, które powoduje odpalenie kodu. Np. użytkownik wcisnął jakiś klawisz. Albo po prostu odpalił się czas na apdejt kolejnej klatki. Event handlery coś tam robią i następnie rozsyłają odpowiednie akcje (jak w
Komentarze
Prześlij komentarz