Jednym z polskich kompleksów, jest perfekcjonizm objawiający się w niewłaściwych sytuacjach. Gdy przychodzi powiedzieć nam coś po angielsku, zdarza się nam zawiesić i zastanawiać się nad wyborem właściwego czasu, zamiast, po prostu mówić. Jest to o tyle trudne w pracy front-end developera, że od znajomości języka, może zależeć, czy dostaniemy pracę, czy też nie. W tym wpisie, będzie o tym, jak przekonać pracodawcę (a raczej dział HR) do tego, że znamy język wystarczająco dobrze.
Blog na temat programowania. Wszystkie materiały do nauki znajdziesz pod tagiem "materiały". Autor - Kamil Naja
wtorek, 27 czerwca 2017
poniedziałek, 26 czerwca 2017
Umbraco CMS - z czym to się je?
Praca front-end developera, to znacznie więcej, niż stylowanie prostych stron opartych na HTML lub tworzenie templatek do (znienawidzonego przez wielu) Wordpressa. Istnieje wiele mniej popularnych technologii, które mogą być wykorzystywane na przykład, do tworzenia blogów (jak Ghost CMS, oparty na JS), czy zaawansowanych stron WWW, jak Umbraco CMS.
niedziela, 25 czerwca 2017
Praca zdalna? Dziękuję, wolę na miejscu
Update z 2020 roku
Praca zdalna jest spoko, pod warunkiem, że
- masz dobre warunki do pracy w domu (2 monitory, cisza)
- masz już pewne doświadczenie w swojej technologii, a najlepiej w pracy z danym teamem.
Obecnie wydaje mi się, że podczas pracy zdalnej największym problemem jest bardzo duża ilość powiadomień np. z czatu firmowego. Dalsza część posta dotyczy lat "przedepidemicznych".
Jacek pracuje
zdalnie. Nastawił dziś budzik na 8.55 (zaczyna o 9), ale gdy ten
zadzwonił, podgłośnił laptopa i pomyślał – jeśli będą
jakieś taski, to ktoś zbudzi mnie, pisząc na Skype. Nie zauważył,
że był wylogowany. Wkrótce wylogowano go z projektu.
Jednym z powodów,
dla których ludzie uczą się programowania, jest możliwość pracy
zdalnej. Brzmi to świetnie – nie tracisz czasu na dojazdy, koledzy
nie patrzą Ci w ekran, a Ty nie musisz słuchać ich wywodów, na
temat zalet obiektowości.
wtorek, 20 czerwca 2017
Najciekawsze funkcje PHPStorm/Webstorm, które ułatwiają życie programisty
Cześć,
dzisiaj znowu trochę na temat PHPStorma/Webstorma, czyli świetnych narzędzi do pisania kodu. Wpis nie jest sponsorowany.
Środowiska programistyczne od Jetbrains, wyróżniają się prostą obsługą oraz wieloma dodatkowymi funkcjami, które ułatwiają życie programisty. Mogę zaryzykować stwierdzenie, że po zainstalowaniu PHPStorma/Webstorma, można od razu przystąpić do skutecznej deweloperki. Jeśli decydujemy się na korzystanie z Vima, zanim napiszemy jakiś kod, spędzimy pół dnia na konfigurowaniu, a w przypadku Sublime Text/Visual Studio Code czy innych, nowych edytorów, na instalowaniu wtyczek.
dzisiaj znowu trochę na temat PHPStorma/Webstorma, czyli świetnych narzędzi do pisania kodu. Wpis nie jest sponsorowany.
Środowiska programistyczne od Jetbrains, wyróżniają się prostą obsługą oraz wieloma dodatkowymi funkcjami, które ułatwiają życie programisty. Mogę zaryzykować stwierdzenie, że po zainstalowaniu PHPStorma/Webstorma, można od razu przystąpić do skutecznej deweloperki. Jeśli decydujemy się na korzystanie z Vima, zanim napiszemy jakiś kod, spędzimy pół dnia na konfigurowaniu, a w przypadku Sublime Text/Visual Studio Code czy innych, nowych edytorów, na instalowaniu wtyczek.
wtorek, 13 czerwca 2017
Czy polubiłeś się już z konsolą?
Tekst będzie o konsoli Windows i nie chodzi w nim o Xboxa.
Pierwszy dzień
kursu programowania. Wielkie nadzieje uczestników i równoczesny lęk
przed tym, co się wydarzy. Wykładowca mówi – a teraz odpalamy
konsolę. Miny uczestników rzedną, a każdy z nich zmienia się w
smerfa Marudę:
- Jak ja nie cierpię
konsoli!
sobota, 10 czerwca 2017
Typy programistów
Niezaangażowany
Programista z długim
stażem, który unika wszystkich zadań, nie mieszczących się w
jego zakresie odpowiedzialności. Na większość Twoich pytań
odpowiada nie wiem i nie próbuje pomagać w rozwiązywaniu
problemów. Gdy nie ma zadań, potrafi godzinami wpatrywać się w
ekran monitora. Nigdy nie zrobi nic, ponadto, co zostało mu zlecone.
Nauczył się jednego IDE i nie umie zrobić git pulla w inny sposób,
jak przez odpowiednią wtyczkę.
Nie dba o rozwój
zawodowy i potrafi przepracować w jednej firmie 20 lat (najchętniej
przy jednym projekcie w PHP 5.4). Uczy się frameworków, jeśli
musi, ale nie odróżnia wtedy AngularJS od Angular4.
wtorek, 6 czerwca 2017
Najgorsza rzecz w pracy front-end developera
Gdybym miał wybrać jedną rzecz, która najbardziej denerwuje mnie w pracy front-end dewelopera, byłoby nią stawianie projektów.
Wyobraź sobie taką sytuację - rozpoczynasz ochoczo pracę przy nowym projekcie, gdzie Twoim zadaniem jest szybkie dostylowanie kilku elementów. Oczami wyobraźni widzisz już, jak chwalisz się szefowi ukończoną i dobrze przetestowaną pracą. Zaczekaj, nie tak prędko.
Najpierw musisz postawić projekt, co wiąże się zwykle ze ściąganiem różnych podejrzanych programów, konfigurowaniem PHP (bo masz za nową wersję, a projekt manager uznaje tylko 5.3) czy dziesiątkami prób, pobrania kluczy SSH i połączenia się z repozytorium na SVN. Do tego trochę upierdliwej konfiguracji PHP, oczywiście za pomocą notatnika. Możesz mieć pewność, że inne projekty, które do tej pory działały, przestaną działać.
Przejdźmy do kolejnego punktu z poradnika "jak postawić projekt", a inaczej - jak rozwiązywać problemy, których wcale nie chcesz rozwiązywać.
Dodajmy do tego synchronizacja bazy danych (oczywiście zakończone 5 niepowodzeniami) oraz kilka failów, bo projekt nie wyświetla się w przeglądarce na localhost. Nie byłoby dziwne, gdyby przestał działać Ci Apache w pakiecie Xampp.
Osobny zestaw przygód oferuje stawianie projektów na Vagrancie, który to może na jednym komputerze działać doskonale, a na drugim wcale.
Stawianie projektu kończy się zwykle błagalnym wołaniem backend developera, który jako jedyny ogarnia, jak skłonić kod do działania. Gdyby jego zabrakło, kilkuletnie prace nad kodem można by wyrzucić do śmietnika, bo był on jedyną osobą, która umie zrobić deployment.
Po kilkukrotnym czyszczeniu cache i zmianie uprawnień chmod 777, możesz rozpocząć pracę … przepraszam - iść do domu, bo prace przygotowawcze zajęły cały dzień.
Moim zdaniem, znacznie lepsze podejście oferują projekty na Node.js, w których działanie developera ogranicza się, do walki z brakującymi zależnościami w NPM i wydaniem polecenia NPM Install.
Co jest w Twoim pokoju 101?
Pokój 101 to miejsce, w którym robią Ci te rzeczy, których najbardziej się boisz [1]. Dla jednego dewelopera, będzie to wielodniowe stawianie projektów, dla innego, zaś:
*1 - Rok 1984, Orwell
Najpierw musisz postawić projekt, co wiąże się zwykle ze ściąganiem różnych podejrzanych programów, konfigurowaniem PHP (bo masz za nową wersję, a projekt manager uznaje tylko 5.3) czy dziesiątkami prób, pobrania kluczy SSH i połączenia się z repozytorium na SVN. Do tego trochę upierdliwej konfiguracji PHP, oczywiście za pomocą notatnika. Możesz mieć pewność, że inne projekty, które do tej pory działały, przestaną działać.
Przejdźmy do kolejnego punktu z poradnika "jak postawić projekt", a inaczej - jak rozwiązywać problemy, których wcale nie chcesz rozwiązywać.
Dodajmy do tego synchronizacja bazy danych (oczywiście zakończone 5 niepowodzeniami) oraz kilka failów, bo projekt nie wyświetla się w przeglądarce na localhost. Nie byłoby dziwne, gdyby przestał działać Ci Apache w pakiecie Xampp.
Osobny zestaw przygód oferuje stawianie projektów na Vagrancie, który to może na jednym komputerze działać doskonale, a na drugim wcale.
Stawianie projektu kończy się zwykle błagalnym wołaniem backend developera, który jako jedyny ogarnia, jak skłonić kod do działania. Gdyby jego zabrakło, kilkuletnie prace nad kodem można by wyrzucić do śmietnika, bo był on jedyną osobą, która umie zrobić deployment.
Po kilkukrotnym czyszczeniu cache i zmianie uprawnień chmod 777, możesz rozpocząć pracę … przepraszam - iść do domu, bo prace przygotowawcze zajęły cały dzień.
Moim zdaniem, znacznie lepsze podejście oferują projekty na Node.js, w których działanie developera ogranicza się, do walki z brakującymi zależnościami w NPM i wydaniem polecenia NPM Install.
Co jest w Twoim pokoju 101?
Pokój 101 to miejsce, w którym robią Ci te rzeczy, których najbardziej się boisz [1]. Dla jednego dewelopera, będzie to wielodniowe stawianie projektów, dla innego, zaś:
- Rozmowa z klientem, zwłaszcza w obcym języku
- Uczenie się nowych technologii
- Praca w przestarzałych technologiach
- Praca z czymś, czego nie znamy (bardzo często jest to JS)
- Wypowiadanie się na forum publicznym w pracy, na przykład podczas daily scrum
- Mierzenie się ze zbyt trudnymi problemami
- NUDA
*1 - Rok 1984, Orwell
Subskrybuj:
Posty (Atom)