Luke J. Li

Tworzę nowe narzędzie do JSa. Będzie ono pomagało debugować programy. Założenie jest takie, żeby śledzić wszystko co się w programie dzieje (np. która funkcja została wywołana z jakimi parametrami i co zwróciła) a potem tworzyć z tego interaktywne raporty w formacie HTML.  Przy czym realizacja do końca tego założenia wiąże się z wyzwaniami - ciężko śledzić wszystko co się dzieje, i też nie ma sensu raportować wszystkiego (chyba, żeby wymyślić jakiś sprytny system filtrów/wyszukiwania, który pozwoliłby pokazywać użytkownikowi jedynie relewantne informacje). Tym niemniej już coś widać, już można z tego korzystać. Na razie jest to testowane tylko na aplikacjach NodeJS, i trzeba pół-ręcznie instrumentować kod (wygooglujcie: code instrumentation), ale i tak cieszę się z efektów: W razie czego klikajcie tutaj: San Escobar - powerful HTML logging for NodeJS applications

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 archit...

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.cr...

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...