Luke J. Li

Redux. Biblioteka, która sporo namieszała w świecie frontendu. Czemu? Co w niej takiego jest? W zasadzie nic czego nie byłoby gdzie indziej: kolejna biblioteka realizująca architekturę flux polecaną dla Reacta kolejna biblioteka do emitowania i nasłuchiwania eventów (powszechnie używany był wcześniej choćby EventEmitter z NodeJS) kolejna implementacja wzorca CQRS kolejna biblioteka, która wykorzystuje koncepcję reducerów z programowania funkcyjnego kolejna implementacja event sourcingu (czy może raczej biblioteka, w której można w bardzo prosty sposób zastosować event sourcing). ( Czemu jednak zdobyła taką popularność? Szczęśliwy traf i fajne demo. Fakt, że powstało to w ekosystemie Reacta , który był gorącą biblioteką w 2015 Prostota . Redux jest prosty w użyciu, opiera się na prostych zasadach (jeden stan na całą aplikację, wysyłanie komunikatów przez funkcję dispatch, zmiana stanu w reducerach, uaktualnienie komponentów o dane). Przemyślana architektu

Zmieniło się trochę. W skrócie: Silnika gier już nie robię, bo pobawiłem się w międzyczasie Unreal Engine 4 i doszedłem do wniosku, że po co robić coś co będzie i tak słabsze od UE4? (tudzież od Unity i podobnych rzeczy). Owszem, mógłbym zrobić coś lepszego od Phasera, Kiwi czy innych webowych silników, ale jednak powiedzmy sobie szczerze - webówka to jest przedszkole. Te wszystkie nasze frameworki webowe to takie zabawki. Prawdziwe rzeczy jeśli chodzi o silniki gier/edytory robi się na desktopie (przy czym teraz się to wszystko miesza - UE4 ma opcję eksportu do HTML5, Unity chyba też). Za to robię to, co planowałem już od dwóch lat, czyli własne IDE do JavaScriptu . Zrobiłem już kilka wersji, przepisywałem od nowa, teraz wreszcie doszedłem do jakiejś tam stabilności, i niedługo wypuszczam to w kosmos. To znaczy w internet. Na tym poziomie nie będzie to raczej IDE, ale edytor, w stylu Atoma czy VSCode. Natomiast będę szedł tym w stronę IDE (prawdopodobnie bardziej inteligentn

Po raz kolejny czytam, że ktoś uważa jakoby klasy w ES6 były jakąś super zmianą, która z JavaScriptu czyniła w pełni obiektowy język. This is wrong on some many levels... JavaScript był obiektowy już dawno . Może nie w pełni obiektowy i dalej nie jest w pełni obiektowy w takim stopniu jak Python (choćby dlatego, że w JS liczby nie są prawdziwymi obiektami tak do końca - w Pythonie są), jednak jest obiektowy enough, prawie wszystko jest obiektem (łącznie z funkcjami - w wielu niby to obiektowych językach funkcja nie jest obiektem), można stosować polimorfizm, kompozycję, dziedziczenie, enkapsulację danych (przez domknięcia). Owszem, klasy są pewną formalizacją patternów, które użytkownicy już dawno stosowali. Jeśli ktoś stosował składnię typu: function Foo() {... } Foo.prototype.meth = function () { }; to pewnie się ucieszy, że używając klas składnia jest prostsza. Klasy ukrócą również partyzantkę, że każdy framework tworzy własną implementację pseudoklas (React.createClass

Zmieniło się trochę. Nie tylko robię edytor, ale i cały silnik do gier w JavaScript (nastawiam się na 2D). Dlaczego? Cóż, zacząłem robić ten edytor na frameworku Phaser, co początkowo dało mi kopa. Phaser ma bardzo dobre wsparcie, dużo przykładów i świetne community. Na każdy problem mogłem znaleźć szybko odpowiedź w necie. Phaser posiada również dużo przydatnych ficzerów do obsługi sprajtów (częściowo wziętych z biblioteki Pixi). Więc mogłem zrobić szybko mój prototyp edytora . Problem jednak w tym, że Phaser to framework, więc tak jak każdy framework - ogranicza . Ciężko zrobić coś większego, dopasować to pod swoje potrzeby. Dlatego postanowiłem zrobić własny silnik, dopasowany do moich potrzeb. Czy to nie jest porywanie się z motyką na słońce i niepotrzebne odkrywanie Ameryki? Nie. Zrobienie pewnych rzeczy samemu jest często o wiele prostsze niż walka z frameworkiem-kobyłą. Robiąc własny silnik mogę również wszystko kontrolować, wprowadzać tam taką architekturę oraz wz

Wrzuciłem prototyp edytora do sieci. // I've uploaded prototype of my HTML5 game editor. However don't expect too much, this is early stage of development and the project is still evolving.

Nie tylko robię własną wtyczkę do edytora , ale również od jakiegoś czasu zacząłem robić swój własny edytor. Póki co będzie to edytor gier. A później się zobaczy. Na razie to co widać, to edytor poziomów - wyklikujesz sobie, gdzie mają być położone które elementy. W ten sposób możesz zbudować murek, postawić samochód w określonym miejscu itp. Dzisiaj też zacząłem robić coś w rodzaju inspektora obiektów. Po kliknięciu obiektu masz po lewej stronie jego właściwości (np. współrzędne położenia). Niektóre z tych właściwości można zmieniać (pewnie można będzie zmieniać wszystkie, no ale nie od razu Kraków zbudowano). Jak widzicie, inspektor pokazuje również kod źródłowy funkcji odpowiedzialnych za zachowania obiektów: Tutaj mamy funkcję onUpdate, która definiuje to, co obiekt robi przy każdej aktualizacji (która następuje około 60 razy na sekundę). W innych obiektach mogą być różne inne funkcje, które będą się odpalać przy określonym zdarzeniu (np. onClick = co obiekt ma robić ja

Zapraszam do obejrzenia/pobawienia się: http://hex13.github.io/atom-lupa/

Struktury danych są najważniejsze. Powinny być zuniformizownane na poziomie co najmniej projektu. Czyli np.: - Załózmy, że mamy komponent w React (Angular itp.), który przyjmuje na wejściu listę obiektów do wyświetlenia. Jeśli w jednym komponencie właściwość ta nazywa się "items" to w drugiem tak samo powinna się nazywać (czyli nie np. `list` albo `listItems` ale właśnie `items`. Oczywiście jest to arbitralne. Ważne, żeby wszędzie było tak samo. - Jeśli nie jest możliwe zuniformizowanie właściwości, warto zadbać o pewnego rodzaju adapter. Adapterem może być np. Higher Order Component w React. Np. https://jsfiddle.net/69z2wepo/46661/ Może to być również funkcja dostępowa (geter, selektor), np. https://jsfiddle.net/yw3mz5on/ Jeśli to możliwe, to należy zachowywać spójność w strukturach danych na poziomie więcej niż jednego projektu. Ponieważ: - większa reużywalność poszczególnych komponentów, modułów, funkcji. - większa intuicyjność - tworzymy "efekt platfo

Zrobiłem niedawno wtyczkę do Atoma, która wyświetla po boku listę funkcji oraz innych elementów w kodzie, i pozwala po tej liście nawigować, i wyszukiwać. Opisałem to także szerzej w artykule na Medium: https://medium.com/@hex13code/lost-in-code-created-tool-for-finding-way-out-700d96ef8c31 Sama wtyczka jest do ściągnięcia tutaj: https://atom.io/packages/atom-lupa

Czym jest doświadczenie? Mit: doświadczenie to przesiedziane dupogodziny w biurze . Wystarczy pójść do jakiejkolwiek pracy i klepać przez 5-10 lat jakieś templatki, wklejać kod z netu, i ma się tego ekspa. Jest się później "seniorem" w nagrodę za wytrwałość. Nigdzie indziej niż podczas pracy na etacie nie można zdobyć "doświadczenia". Freelancing się nie liczy, bo nie jest to prawdziwa stała praca w biurze. Doświadczenie w open source jest niepoważne, bo nikt za nie nie płaci. Własne projekty są niepoważne, bo człowiek je robi sam dla siebie. Rzeczywistość: "lata doświadczenia"(dupogodziny) a bycie doświadczonym to dwie odmienne rzeczy. Doświadczony programista to taki, który zetknął się z różnymi problemami, nauczył się je skutecznie rozwiązywać (a jeśli nie nauczył się ich rozwiązywać, to przynajmniej nauczył się, które rozwiązania problemów są słabe i potrafi wyciągać wnioski z wcześniejszych błędów), pracował w różnych technologiach, prz

Waterfall - wszystkie decyzje są podjęte z zewnątrz, programiści to tylko robociki, które realizują plan. Agile - nikt niczym nie zarządza, każdy robi co chce i kiedy chce. Scrum - trochę jak sekta - zebrania na stojąco, ceremonie, osoba, która ma tytuł mistrza. Wszystko to pozornie ma służyć planowaniu programowania, ale i tak chodzi głównie o zabawę. Extreme programming - polega na programowaniu w parach, więc pracodawca płaci dwa razy więcej pieniędzy za to samo.

Wpierw mamy Twittera . Po zarejestrowaniu należy wybrać sobie paru znanych programistów JS (np. autorów open source'owych bibliotek) i kliknąć przycisk follow . Potem zobaczyć kogo oni śledzą i klikać w kolejne profile. Jak zobaczymy profil z ciekawymi tweetami, to znowu klikamy follow .  W ten sposób budujemy sobie bazę osób, które śledzimy. Jeśli interesuje nas ReactJS, to możemy przeczytać artykuł Dana Abramova na temat tego kogo warto śledzić na Twitterze: https://medium.com/@dan_abramov/my-react-list-862227952a8c#.pfsws5xsj Dalej mamy Hacker News .  https://news.ycombinator.com/ Na głównej stronie pojawiają się różne rzeczy, nie tylko związane z JS, więc możemy użyć wyszukiwarki (wpisując np. JavaScript, ReactJS albo inne hasło nas interesujące i sortujemy po najnowszych). No i ogólny protip: na tego typu stronach jak HackerNews, czy Reddit itp. opłaca się oglądać nie tylko wiadomości najbardziej popularne (defaultowo się pojawiają), ale też przejść do filtrowania po najno