Marta Bąk, Marketing i Biznes: Od jak dawna blogujesz i co Cię skłoniło do takiej aktywności?
Bartłomiej Dybowski, Na Frontendzie: Swoją przygodę z blogowaniem rozpocząłem pod koniec 2012 roku od założenia bloga o nazwie „burczu-programator”. Byłem wtedy programistą .NET (C#), który w tamtym okresie, po zmianie pracy, znów mocniej się rozwijał (u poprzedniego pracodawcy trochę się zasiedziałem i niestety odbiło się to na moich postępach). Poza tym była to też zmiana technologiczna: aplikacje desktopowe (WinForms) zamieniłem na aplikacje web (ASP.NET MVC).
Blog był więc moim pomysłem na utrwalenie nowo zdobywanej wiedzy, a przy okazji sposobem na podzielenie się nią z innymi. Niedługo po rozpoczęciu blogowania wziąłem się za przygotowania do zdobycia certyfikatu Microsoft – MCSD 70-480: Programming in HTML5 with JavaScript and CSS3. W ramach nauki postanowiłem wszystkie wymagane zagadnienia opisać na blogu, dzięki czemu w krótkim czasie powstało prawie 30 nowych wpisów. Z tego co wiem, pomogły one wielu osobom zdać ten egzamin, a przy okazji rozkręciły nieco popularność bloga. To napewno podniosło moją motywację do dalszego pisania i pewnie po części dzięki temu blog, już pod nazwą „Na Frontendzie”, przetrwał aż do dziś…
Niedawno przenosiłeś bloga z WordPressa. Dlaczego zacząłeś używać Jekyll? Co Ci pomogło podjąć taką decyzję i czy jesteś zadowolony z tej zmiany?
WordPress i Jekyll to dwa zupełnie różne podejścia do zarządzania treścią. W pierwszym z rozwiązań mamy do czynienia z typowym CMS’em – mamy możliwość zalogowania się do systemu poprzez przeglądarkę, dodawanie treści odbywa się za pomocą wbudowanego edytora on-line, wygląd bloga możemy zmienić instalując specjalnie przygotowane motywy, a do rozszerzania możliwości strony służą tysiące dostępnych wtyczek.
W Jekyllu sprawa wygląda zupełnie inaczej – jest to narzędzie do generowania statycznych stron. Treść tworzymy za pomocą składni Markdown, która tłumaczona jest na HTML. Wynikowe strony, po prostu wysyłamy na serwer – nie ma potrzeby posiadania bazy danych itp. Kod strony możemy trzymać w systemie kontroli wersji (na przykład na GitHubie), więc jest bezpieczny.
Uważam, że WordPress to świetny system do blogowania – na pewno wiele ułatwia, szczególnie „nie-technicznym” osobom, a możliwości jego konfiguracji i dostosowywania do własnych potrzeb są ogromne. Ma też jednak swoje wady: źle dobrany szablon i zbyt duża ilość wtyczek potrafią skutecznie „zamulić” bloga przez co ładuje się o wolno i jest to słabe doświadczenie dla odwiedzających. Może to też skutkować niższymi pozycjami w wyszukiwarce Google.
Niestety wszystkie te, wyżej wymienione problemy dotknęły też mojego bloga. Początkowo postanowiłem więc, że stworzę swój własny szablon dla WordPressa, tak aby zrobić wszystko optymalnie oraz zminimalizować konieczność użycia wtyczek. Niestety, praca z kodem WordPressa nie należy, jak dla mnie, do przyjemnych – kod PHP wymieszany z HTML to rozwiązanie dość „old-schoolowe” i niezbyt dobre. To sprawiło, że zacząłem myśleć o alternatywach, a z Jekyllem zetknąłem się już wcześniej – na tym silniku oparty był blog firmowy jednego z moich wcześniejszych pracodawców – decyzja więc była prosta.
Zmiany na pewno nie żałuję – wygląd bloga stworzyłem od zera, dzięki czemu mogłem go dobrze zoptymalizować i mam nad nim teraz pełną kontrolę. Jeśli chcę coś zmienić to wystarczy, że pobiorę źródła z GitHuba, wyedytuję odpowiednie pliki HTML czy CSS i wyślę zmiany na serwer. Poza tym, posty i tak pisałem z użyciem składni Markdown, a następnie przenosiłem je do WordPressa, teraz więc odpadł mi ten dodatkowy krok… Z informacji jakie otrzymuję, większość czytelników również jest zadowolona ze zmiany.
Jak zaczęła się Twoja przygoda z frontendem? Co byś poradził osobie, która chce dopiero zacząć i jest przerażona, bo słyszała, że wszystko się szybko zmienia, a poza tym jest sporo frameworków?
Jeśli chodzi o front-end to u mnie była to zmiana stopniowa. Tak jak napisałem powyżej, na początku kariery byłem programistą .NET. Najpierw zajmowałem się aplikacjami desktopowymi, a następnie przeszedłem do aplikacji webowych, z użyciem technologii ASP.NET MVC. Pracując z aplikacjami webowymi byłem tzw. „full-stackiem” tzn., że tworząc nową funkcjonalność zajmowałem się nią od bazy danych poprzez wszystkie warstwy pośrednie, aż do kodu odpowiedzialnego za wyświetlanie interfejsu użytkownika.
Dzięki temu mogłem poznać wszystkie aspekty pracy programisty i to właśnie wtedy poczułem co tak na prawdę najbardziej mnie „kręci” w programowaniu. Prawda jest taka, że w SQL doszedłem do pewnego poziomu, którego bez wysiłku juz bym nie przeskoczył, konfiguracji webserwisów WCF również nie przeprowadzałem z wypiekami na twarzy… Zauważyłem za to, że największą satysfakcję daje mi praca nad czymś, czego efekty mogę od razu zobaczyć w sposób wizualny. Poza tym naprawdę polubiłem JavaScript, w którym zacząłem się specjalizować (ku uciesze innych członków zespołu, którzy cieszyli się, że nie muszą zajmować się tymi zadaniami).
Kolejny krok to już zmiana pracy – u obecnego pracodawcy nie miałem takiej możliwości, więc aby zajmować się tylko logiką po stronie klienta musiałem zatrudnić się gdzie indziej, jako front-end developer (przy okazji zacząłem pracować zdalnie – na tym również mi zależało).
Jeśli chodzi o poradę dla początkującego – zawsze powtarzam, że przede wszystkim należy bardzo dobrze poznać język, w przypadku front-end developera jest to JavaScript (oraz HTML i CSS). Jeśli będziesz dobrze znać ten język, żaden framework nie będzie Ci straszny, ponieważ będziesz dobrze rozumieć co się dzieje i jak działają poszczególne jego funkcje. Zresztą napisałem na ten temat wpis blogu.
Jak znaleźć odpowiedniego mentora do nauki programowania?
Wydaje mi się, że warto aby mentorem był ktoś większym doświadczeniem, kto będzie umiał poprowadzić podopiecznego, czasem zadać mu jakieś zadanie i potem je ocenić, a przede wszystkim będzie potrafił nakierować na właściwe rozwiązanie danego problemu.
Jeśli mamy szczęście mieć doświadczonego programistę wśród rodziny lub przyjaciół to myślę, że warto poprosić go o pomoc. Wydaje mi się jednak, że jeśli nie mamy tego komfortu to warto po prostu zadawać pytania na przykład na specjalnie do tego celu stworzonych grupach na Facebooku. Jest tam wiele osób, które mogą być pomocne i z czasem być może któraś z nich zgodzi się pomóc w szerszym zakresie?
Część osób wybiera branżę IT tylko ze względu na możliwość zarobku. Przychodzi do Ciebie młoda osoba, tuż po skończeniu LO i mówi, że chce zarabiać minimum 6 000 złotych miesięcznie. Jakie technologie powinien mieć przyswojone i czym powinna się cechować osoba, która będzie warta te 6 000 złotych na rynku pracy?
6k miesięcznie to już raczej nie Junior tylko „Mid”. Zakładając, że rozmawiamy o front-end developerze, taka osoba, poza tym że bardzo dobrze zna JavaScript, HTML i CSS, ma też doświadczenie z jakimś frameworkiem JS (mniej ważne z jakim konkretnie, bo jeśli radzi sobie z jednym to poradzi sobie też z innymi). Oprócz tego, co także wynika z doświadczenia, potrafi korzystać z narzędzi takich jak, na przykład, system kontroli wersji, IDE itp.
Osoba, które nie jest już Junior Developerem powinna też, moim zdaniem, być dość samodzielna. Nie oczekuje prowadzenia „za rękę”, potrafi sama rozwiązywać część problemów, umie znaleźć odpowiedź w dokumentacji, a jeśli szuka odpowiedzi w internecie to nie przekopiowuje bezmyślnie kodu ze Stack Overflow tylko wie co robi i odpowiednio dostosowuje znalezione rozwiązanie do swoich potrzeb. Natomiast jeśli prosi bardziej doświadczone osoby o pomoc to widać, że starała się zrozumieć problem i wie o co zapytać.
Napisałeś ciekawy wpis na temat stosowania code review. Zastanawiam się natomiast, na ile jego stosowanie w zespole, może być konfliktogenne?
Ten wpis jest już dość stary ale wciąż aktualny. Code review to dobry sposób zarówno na utrzymanie jakości kodu, jak i naukę od bardziej doświadczonych programistów. Osobiście nie spotkałem się z sytuacją aby wywoływało to konflikty.
Wydaje mi się, że w zespołach, które praktykują przeglądy kodu każdy rozumie po co się to robi. Wszyscy pracują przecież nad jednym projektem i powinno im zależeć aby jego jakość była jak najwyższa. Jeżeli więc ktoś komuś zwraca na coś uwagę to nie robi tego złośliwie, żeby „dowalić”, tylko po to by kod całego projektu był po prostu lepszy. Code review nie ma się co bać – wręcz przeciwnie! To doskonała okazja do nauki dla młodych programistów – możliwość pokazania swojego kodu komuś z większym doświadczeniem, dowiedzenie się co robi się nie tak i jakie ma się braki jest, moim zdaniem, nieoceniona!
Czego Ci mogę życzyć w życiu zawodowym?
Ostatnio staram się iść w kierunku nauczania – prowadzę szkolenia oraz tworzę kursy on-line… Więc może sukcesów na tym polu?
Wywiad powstał:
Coders Lab
Łącząc doświadczenie edukacyjne ze znajomością rynku pracy IT, Coders Lab umożliwia szybkie i efektywne zdobycie pożądanych kompetencji związanych z nowymi technologiami. Skupia się się na przekazywaniu praktycznych umiejętności, które w pierwszej kolejności są przydatne u pracodawców.
Wszystkie kursy odbywają się na bazie autorskich materiałów, takich samych niezależnie od miejsca kursu. Dzięki dbałości o jakość kursów oraz uczestnictwie w programie Career Lab, 82% z absolwentów znajduje zatrudnienie w nowym zawodzie w ciągu 3 miesięcy od zakończenia kursu.
Zostaw komentarz