Luke J. Li

Czasem po prostu musisz skompletować sobie własny stack technologiczny, dojść do tego, które narzędzia lubisz, a które narzędzia uważasz za ułomne. Jeśli chodzi o framework do obsługi DOMu, to wybieram ReactJS . Prosta i elastyczna biblioteka do tworzenia komponentów. Obecnie też testuję Redux (biblioteka do obsługi stanu aplikacji w ReactJS) wcielająca w mniejszym lub większym stopniu założenia Flux), chociaż zaczynam dostrzegać ograniczenia związane z tym w jaki sposób Redux jest powiązany z Reactem. Nie wiem czy nie będę musiał napisać własnego bindingu (już tłumaczę, że Redux jest uniwersalną i prostą biblioteką i nie wymaga do działania Reacta. Natomiast jego twórca dostarcza specjalne bindingi do tego, żeby połączyć Redux z Reactem . Niestety jak dla mnie te wiązania nie są za bardzo jeszcze dopracowane pod kątem założeń. A przynajmniej nie sprawdzają się w aplikacji, którą robię). Zawiodłem się na Angularze . Miałem okazję pracować z nim dłużej i głębiej i okazuje się, że

Czasem trzeba się wziąć za projekt, który od jakiegoś czasu leży odłogiem. Czasem się nie chce. Co można w takim razie zrobić? Oto moje techniki: 1) Sprawdzanie historii Gita. Otwórz terminal, zmień katalog na ten, w którym siedzi projekt i wpisz te komendy 'git status' 'git diff' (w przypadku kiedy status nie będzie czysty) 'git log' (jakie zostały dodane ostatnio commity i kiedy to było? Wow. To już miesiąc?) 'git show' (Ja napisałem ten kod? Co ja miałem w głowie?) To skłoni cię do przemyślenia, co się ostatnio działo w projekcie (jeśli nie lubisz terminala, możesz również użyć jakiejś graficznej nakładki np. Sourcetree ), oraz czy wszystko (być może sprzed iluś tygodni) jest zakomitowane jak należy. 2) otworzenie projektu w IDE/edytorze To zawsze dobry początek. Mając otwarte IDE/edytor zawsze możesz od niechcenia nawet coś zakodować. Bez otwartego edytora byłoby to trudne. 3) przemyślenie "jaka jest pierwsza rzecz, którą należy t

Znacie pewnie te artykuły z portali internetowych, w których są publikowane poważne raporty poważnych instytutów na temat zarobków programistów. Przeciętny programista języka X zarabia tyle i tyle złotych. Absolwenci Politechniki Warcładańskiej zarabiają średnio o 30% więcej niż ich koledzy z Uniwersytetu Jagiwarszawskiego. programiści z min. 5 latami doświadczenia zarabiają o x procent więcej niż programiści poniżej 5 lat doświadczenia. I inne tego typu rzeczy. Wiecie co o nich myślę? Że są to bzdury. Próby włożenia w ciasne foremki całego rynku. Tysiące programistów, każdy z nich ma inny poziom, inne umiejętności, inną umiejętność sprzedania, a oni to biorą i spłaszczają do suchych liczb. To jest chore. To się nie sprawdzi. Tak samo, jak nie da się oceniać skilla programisty po tym ile linijek kodu produkuje w ciągu godziny, tak samo nie da się oszacować zarobków programisty po tym, jaką szkołę skończył, czy po tym, jaki język programowania zna. Ani nawet po latach do

Strony internetowe to przeszłość. Teraz liczą się aplikacje. Możliwości obecnych technologii webowych są bardzo duże. W zasadzie większe niż to co można znaleźć w internecie. Większość serwisów wykorzystuje może jakieś 10% tego co jest możliwe technologicznie . - można teraz w przeglądarkach robić przyspieszone sprzętowo aplikacje 3D. Jednak póki co prawie nikt w sensowny sposób nie wykorzystuje tego. W sensowny czyli nie "animowane efekciarskie intro 3d na stronę", a coś w stylu trójwymiarowej mapy, interaktywnego trójwymiarowego modelu miasta czy budynku, trójwymiarowych wizualizacji danych, czy coś innego co faktycznie mogłoby posłużyć do czegoś więcej niż jako kolorowy gadżet. Chociaż - ignorowanie grafiki 3D obecnie można jeszcze zrozumieć, ponieważ na starszych komputerach może ona nie pójść (niektórzy użytkownicy nawet WebGLa nie muszą wcale mieć). - No ale nie trzeba sięgać do 3D. Bo nawet w zakresie grafiki 2D mamy dzisiaj mnóstwo możliwości . Canvas. SVG.

Na zakończenie cyklu wpisów o rozmowach rekrutacyjnych będzie odmiana: tym razem będzie pozytywnie. Opowiemy sobie w tym odcinku jak powinna (i jak czasem wygląda) właściwa, pozytywna rozmowa o pracę na stanowisko programisty. 1.   Rozmowa powinna dać coś obu stronom . Najlepiej by było, gdyby po rozmowie kandydat został zatrudniony. Wtedy wiadomo: win-win. Jednak jeśli tak z jakichś powodów kandydat nie zostałby zatrudniony (albo sam by zrezygnował ze współpracy), nie wszystko stracone. Dalej można wyciągnać jakąś obopólną korzyść. a) Kandydat może nauczyć się czegoś nowego. Nie znał algorytmu sortowania? To po wyjściu z rozmowy już będzie znał. Nie słyszał nigdy o frameworku X? To na rozmowie usłyszy i przegoogluje sobie w domu o co chodzi z X. Mylił się w pewnej sprawie? To na rozmowie zostanie naprowadzony na lepsze podejście. Oczywiście przy założeniu dobrej woli rekrutera i chęci do dawania feedbacku. Nie ma nic gorszego niż rekruter, który tego feedbacku nie kwapi

Kontynuując serię wpisów o rozmowach rekrutacyjnych dla programistów - to niektóre rozmowy o pracę są tak żenujące, że aż człowiekowi chce się zakończyć taką rozmowę i wyjść z sali. Ale ciągnie bo przecież głupio tak wychodzić w połowie. Nawet jeśli wiadomo, że z tej mąki chleba nie będzie.  Niestety nigdy nie wyszedłem jeszcze w trakcie rozmowy, co uważam za swój osobisty błąd. Naprawdę, szkoda czasu i nerwów na pewnego typu rozmowy. O jakich to żenujących sytuacjach mówię? Jak poznać takie sytuacje? No więc... Jeśli rekruterzy zaczynają przy tobie liczyć pieniądze  (sumy w sensie, nie papierki, ale na jedno wychodzi) i zastanawiają się czy będzie ich stać na biurko dla ciebie (nie mówiąc już o komputerze),  i gdzie postawią to biurko, bo przecież tak mało miejsca mają, to raczej nie jest dobrze. Ja rozumiem, że kryzys i januszowe firmy informatyczne ledwo przedą, ale bez jaj. Zresztą zawsze można kogoś wynająć zdalnie. Programista pracujący zdalnie może pracować na swoim

Jest to kontynuacja / rozwinięcie poprzedniego postu. Co jeśli jesteś na rozmowie o pracę i usłyszysz głupie pytanie? Nie odpowiadaj na nie. To znaczy: odpowiadaj (musisz przecież coś powiedzieć, a nie zamilczeć jak grób), ale odpowiadaj na inne pytanie, niż ci zadali. Zwykle głupie pytania są symptomem, że pytający chce o coś zapytać, ale nie wie dokładnie o co i to ty musisz się domyślić o co on chce zapytać, być może poprosić o doprecyzowanie pytania. Ew. też odbić całkowicie piłeczkę i polać wodę na inny temat ale jednak tak ciekawie opowiadać, że rekruter zapomni o co pytał wcześniej. Można też asertywnie odmówić odpowiedzi na pytanie i zmienić temat. Różne są taktyki. Czasem również da się (i trzeba) odpowiedzieć wprost na pytanie, ale to dalej nie oznacza wcale, że dane pytanie jest mądre. Ale przejdźmy do konkretów - jakie to są głupie pytania na rozmowach? 1. pytania tak ogólne, że nie da się na nie opowiedzieć krótko i konkretnie. Np. "opowiedz coś o swoic

To będzie nietypowy post na temat błędów jakich należy unikać na rozmowach o pracę dla programisty. Czemu nietypowy? Bo nie znajdziecie tutaj typowych porad w stylu "bądź kumaty" albo "bądź kulturalny", "nie spóźniaj się", "spróbuj się dowiedzieć czegoś więcej o firmie, do której aplikujesz". O tym piszą wszędzie. A ten blog ma być wyjątkowy. Gotowi? No to jedziemy. Dobór punktów wynika z moich osobistych doświadczeń i błędów, jakie zdarzało mi się popełniać... 1. P róby mądrego odpowiadania na głupie pytania Rekrutujący to tylko ludzie. Czasem się więc zdarza, że nie umieją sensownie poprowadzić rozmowy i zadają szablonowe, acz nie za mądre pytania. Błędem jest przyjmowanie piłeczki i silenie się na sensowną odpowiedź. To zwykle nic nie da. Choćby dlatego, że osoby, które zadają tak głupie pytania i tak nie zrozumieją mądrej odpowiedzi. Szerzej o dziwnych pytaniach rekruterów w kolejnym poście.  Stay tuned ;) 2. Podawanie za niskic

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 Monoka

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

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.