Luke J. Li

WebStorm jest jak demokracja . Jest to najgorsze IDE do JavaScriptu, ale nic lepszego nie wymyślono. Dlatego z niego korzystam na codzień. Jednak fakt, że z niego korzystam wcale nie zmniejsza jego wad. Otóż bez względu na to, co będą powtarzać jak małpy wasi znajomi frontendowcy dopijający resztki kawy - WebStorm wcale taki fajny nie jest. Ten program ma mnóstwo niedociągnięć / wad, które mnie osobiście wkurwiają. Jakie są to wady? Za co go nie lubimy? - Za to, że niby jest pełno opcji, ale i tak ciężko je znaleźć , nawet dowiedzieć się, że jakaś opcja istnieje. Opcje są w Webstormie gdzieś poukrywane. Za dużo tego jest, żeby znaleźć potrzebną akurat rzecz w całym gąszczu innych (i nie mówcie mi o distraction free mode, bo to do czego innego zupełnie służy) - Za wymyślanie własnego pokręconego nazewnictwa (np. to co jest nazywane "snippetem" w innych edytorach, to w Webstormie ma nazwę "live template". Niby po angielsku, ale jakoś inaczej (może Czesi nie znają...

Zmieniło mi się podejście do edytorów. Kiedyś - gedit, Notepad++. Albo inny lekki edytor. Atom ostatnio (dalej z niego korzystam). Jednak w końcu uległem modzie i zakupiłem licencję na Webstorma, który stał się moim głównym edytorem. (chociaż wspomagam się Vimem czy Atomem). Webstorm nie jest idealny, w zasadzie niby mówi się o nim IDE, ale w przypadku JavaScriptu ciężko o IDE z prawdziwego zdarzenia, więc jest to IDE na pół gwizdka. W dodatku z pluginami bieda. Albo nie umiem znaleźć. W każdym razie WebStorm raczej pluginami nie grzeszy. I ciężko napisać swoje, bo się je pisze w... Javie. Więc WTF.  Jeszcze Javy mam się uczyć? Tym niemniej Webstorm jest jednak bardzo porządnym programem a jego wersja 10 jest już w miarę inteligentna. Potrafi wykrywać np. nieużywane zmienne i je wyświetla innym kolorem, co mnie cieszy. Dzięki temu od razu wiem czego nie używam. Tylko niektóre motywy graficzne w wersji podstawowej są dość mało kontrastowe (obecnie korzystam ze zmodyfikowanego Mo...

Nie lubię gotowców. Sprawiają, że człowiek ma 5 razy więcej roboty. Mimo, że obiecują co innego. Mnóstwo czasu zajmuje często: szukanie gotowca rozgryzanie jak on działa (dużo gotowców jest trudnych w obsłudze) ewentualna modyfikacja, kiedy okazuje się, że nie jest to, czego oczekujemy i trzeba czasem duuużo się nakodzić i dużo bardziej okrężną drogą niż by się to robiło samemu. a często natrafiamy na ścianę i okazuje się, że coś trzeba robić od nowa, i że dany gotowiec się okazuje być słaby (często się to okazuje po fakcie, kiedy już włożyliśmy w to masę pracy) Dlatego zwykle staram się najpierw rozwiązać jakiś problem samemu, a szukanie gotowców uważam za ostateczność. Nie zrozumcie mnie źle. Często korzystam z frameworków czy przydatnych bibliotek. Przez gotowce mam na myśli raczej: gotowe kawałki kodu, które bardzo łatwo jest napisać samemu , i w zasadzie można je napisać samemu, i należałoby chyba, o ile nie ma szczególnych powodów, żeby użyć gotowca. ...

Powiedzmy, że chcesz zostać programistą i szukać pracy w jakiejś firmie. Co oprócz samego programowania powinieneś poznać, jeśli chodzi o umiejętności techniczne? (Wiele rzeczy z tego jest uniwersalnych, chociaż nie ukrywam, że piszę głównie pod kątem programisty JavaScript / frontendowca). system wersjonowania plików . Polecam Git , gdyż jest on najpopularniejszy. Duże prawdopodobieństwo, że jak pójdziesz gdzieś do pracy, będą tam korzystać właśnie z Gita. Ponadto: znając Gita będziesz mógł założyć konto na Githubie (portalu dla programistów do trzymania kodu) i poudzielać się w projektach open source. Generalnie po co to jest? Cóż, zdarzyło ci się: zepsuć coś w aplikacji, że potem żałowałeś że nie zrobiłeś backupu? robić backup co godzinę i mieć na dysku katalogi w stylu Aplikacja_14_01_2015_przedsniadaniem, Aplikacja_14_01_2015_popoludniu, Aplikacja_14_01_2015_wieczorem? że chciałeś poeksperymentować i do tego celu musiałeś przekopiować cały swój projekt w inne miejsce n...

Nie ma dobrego IDE do JavaScriptu. Nawet napisałem na ten temat artykuł: All JavaScript IDE suck.

Więc kontynujemy tutorial. Oto kolejna, długo wyczekiwana część. Poprzednie części: Krok 0 - przygotowania Krok 1 - ładowanie obrazków Krok 2 - wyświetlanie obrazków na Canvasie, podstawowa animacja Krok 3 - obsługa klawiatury Krok 4 - wystrzeliwanie pocisków Po ich zrobieniu powinniście widzieć coś takiego: Jeśli tego nie macie, możecie ściągnąć paczkę zip z przerobionymi 4 poprzednimi krokami. Czyli mamy statki ufo, mamy rakietę, możemy nią sterować strzałkami oraz strzelać za pomocą spacji. Brakuje jednak jeszcze czegoś. Efektu. Statki ufo powinny się rozwalać, inaczej nie ma to żadnego sensu. I teraz tak. Żeby rozwalać statki musimy jakoś wykryć zderzenie (ang. collision detection) między naszym pociskiem, a tak zwanym "ufem". Czyli w każdej klatce będziemy przelatywali przez obiekty i sprawdzali czy żaden z nich się nie zderza z innym. Jeśli się okazuje, że tak odpowiednio zaregujemy (np. zniszczymy statek kosmiczny). Jak jednak wykryć taką kolizję? Jes...

opublikowałem jedną z moich poprzednich gier - strzelanie do wiedźmy. Shoot the Witch jest to na razie pierwszy mój submit do Kongregate i pierwszy ogólnie na platformę grową. Zobaczymy co z tego wyjdzie.