Droga do pierwszej pracy #4 - Nauka i projekty

Jeśli ktoś nie jest na bieżąco z historią opisywaną w tej blogowej serii to ostatni post zakończyłem na tym, że pomimo prób złapania się na staż jako Java developer nie otrzymałem żadnej odpowiedzi a programistyczny kolega został stażystą jako frontendowiec w krakowskiej firmie, do której niedługo później również dołączyłem.

Jak już wspomniałem, przez długi czas zajmowałem się produkcją muzyki elektronicznej. Pisałem również recenzje muzyczne na mój poprzedni blog i aktywnie działałem na polskich forach internetowych poświęconych produkcji. Nie ma ich wiele, ich poziom niekiedy woła o pomstę do nieba, tak więc postanowiłem założyć swoje własne, wraz z internetową ekipą z poprzedniego. Oczywiście jak to w życiu często bywa, świetlane plany podboju polskiej sieci spełzły na niczym, ponieważ w ciągu kilkunastu miesięcy zarejestrowało się niecałe 500 użytkowników. Chwilę prowadziłem też bloga o produkcji muzyki, jednak z różnych względów nie byłem w stanie pisać ciekawej treści w miarę regularnie, a na pomoc ze strony reszty ekipy nie można było liczyć. Niemniej jednak hermetyczne środowisko złożone w głównej mierze ze stałych bywalców forum sprawiło, że poznałem masę ciekawych ludzi, z którymi kilka razy spotkałem się na żywo.

Dlaczego o tym piszę? W momencie, kiedy wspominany tutaj niejednokrotnie kolega (jeśli czytasz to pozdrawiam) został stażystą, zacząłem uczyć się tworzenia stron internetowych. Informacje jakie posiadałem na ten temat jeszcze ze szkoły średniej były prehistoryczne, tak więc przede mną stało morze technologii, frameworków, nowych zasad i trendów. Zgrało się to w czasie z wakacyjną przerwą między semestrami i postanowiłem, że zamiast pójść do pierwszej lepszej pracy zainwestuje większość dostępnego czasu w naukę z nastawieniem, że w ciągu roku znajdę pracę jako front end developer.

Odnalazłem gigantyczne pokłady materiałów dostępnych w sieci, za darmo. Nigdy nie byłem zwolennikiem jakichkolwiek kursów, bowiem sądzę, iż każdy z odpowiednią ilością samozaparcia i determinacji jest w stanie nauczyć się czegoś z darmowych źródeł, o ile nie jest to budowanie silników rakiet dla SpaceX. Zacząłem pisać proste strony z szablonów znalezionych w necie. Nie używałem do tego Photoshopa - większość rzeczy kodowałem “z palca” bądź z obrazka. Nauczyło mnie dbałości o szczegóły i umiejętności zauważania niuansów bez korzystania z narzędzi edytora graficznego. Postanowiłem zrobić swój pierwszy “duży” projekt. Duży w cudzysłowiu, ponieważ tak naprawdę koncept jest bardzo prosty, ale w porównaniu ze swoimi dotychczasowymi pracami wyglądał na dosyć skomplikowany. Ten projekt to quiz muzyczny, gdzie odsłuchujemy losowe wybrane fragmenty wcześniej załadowanych przez FTP utworów, w formacie MP3. Połowa z nich jest zakodowana w bitrate 128kbps, połowa w 320kbps. Naszym zadaniem jest odgadnąć czy słuchamy utworu w niskiej czy wysokiej jakości.

Jako, że nigdy nie wstydzę się swoich starych projektów, na których uczyłem się technologii podam link.

http://reverb.pl/quiz

Jeżeli miałbym pokazać komuś jak wygląda kod od strony backendu to najpierw musiałbym to przepisać zachowując jakiekolwiek standardy, których siłą rzeczy wcześniej nie znałem. Nie ma tam frameworku, nie ma obiektowości, wszystko pisane było jednym ciągiem, nie ma tam biblioteki do obsługi requestów, a jedyną paczką jest znaleziona w odmętach internetu paczka do czytania informacji ID3 z tagów MP3, która służy do wyciągania informacji na temat bitrate. Od strony frontu interakcja z userem i serwerem to ciąg callbacków i funkcji anonimowych w handlerach eventów. Największym problemem oprócz callback hell jaki napotkałem podczas pisania tego projektu był mechanizm sesji, a konkretnie jak zachować informacje o wyniku usera. Nie chciałem tego robić po stronie frontu ponieważ myślałem, że ktoś mógłby podstawić sobie wartości debuggerem w przeglądarce. Odezwałem się do internetowego kolegi na swoim forum, który nakierował mnie mniej więcej w jaki sposób należy to ogarnąć.

W planach mam przepisanie projektu na coś, co ma ręce i nogi, z wykorzystaniem Laravela i Vue na froncie, z panelem do edycji utworów, przechowywaniem wyników i tak dalej. Wszystko oczywiście w ramach nauki i przypomnienia PHP, który w każdym momencie może przydać mi się do zleceń.

Po ukończeniu projektu i pochwaleniu się na forum odezwał się do mnie kolejny znajomy. Potrzebował on strony internetowej dla firmy budowlanej swojego ojca. Jak to często bywa - nie istniał żaden projekt graficzny oprócz logo, tak więc wszystko musiałem ogarnąć sam.

Poszukałem inspiracji na serwisach internetowych i z braku umiejętności postanowiłem wzorować się na jakimś randomowym szablonie pod Bootstrapa. Oczywiście nie przepisywałem kodu jak leci, bo nie na tym polega nauka, ale sprawdzałem z jakich klas korzysta twórca i co one robią. Nie czułem się dobrze w czytaniu dokumentacji nawet tak prostej jak ta Bootstrapowa, ale po jakimś czasie korzystałem tylko z niej. Po około dwóch miesiącach i licznych przerwach w pracy powstał kolejny projekt i pierwszy, na którym zarobiłem pieniądze.

http://dariuszkosterka.pl

Nie jest to szczyt designu, nie znajdziecie tam dobrych praktyk, ale jak na pierwszy projekt z prawdziwego zdarzenia i pierwszy kontakt z klientem poszło mi OK. Co najważniejsze - złapałem podstawy HTMLa, CSSa (co prawda w większości był to Bootstrap) a w poprzednim projekcie było to PHP i jQuery potwierdzone czymś, co stoi w sieci, działa i jakoś wygląda. W międzyczasie zacząłem kurs Free Code Camp, który daje solidne podstawy z czystego JavaScriptu, algorytmów i projektów w wybranej przez siebie bibliotece/frameworku. Stworzyłem większość z nich wrzucając je na swojego Codepena. Wydawało mi się, że było to wystarczająco aby znaleźć jakiś staż dla juniora, gdzie będę mógł zetknąć się z prawdziwymi problemami i uczyć się nowych rzeczy. Nie posiadałem strony portfolio ani konta na LinkedIn  i to był chyba największy błąd. Mimo tego linkowałem swoje projekty w CV lub w odpowiedziach na ogłoszenie.

Przez około 4 miesiące nie odezwał się nikt poza jedną firmą, której nazwy już nawet nie pamiętam, rekrutującą na staż na juniora. Zadanie polegało na zakodowaniu grida z salonami samochodowymi. Cztery rzędy i cztery kolumny boxów, w których znajdował się tytuł, zdjęcie, opis i gwiazdki ratingu. Co ciekawe - w pliku były wytyczne oceny tego projektu. Na pierwszym miejscu była czystość kodu, na drugim częstość i sensowności commitów na GitHube (!!!), później accessibility. Patrząc na to teraz - nie było to zadanie dla juniora, który z zasady nie miał styczności z pracą w firmie i nie zna zasad pisania czystego CSSa ani  tym bardziej workflowu w gicie, skoro wszystkie projekty robiłem sam. Nie wiem czy częstość commitów oznaczała commit raz na dzień czy co 20 minut.

Do projektu użyłem JADE (teraz Pug), ponieważ chciałem wyróżnić się na tle innych kandydatów. Zadanie oddałem w terminie, wszystko trzymało się kupy, responsywność również była na poziomie znośnym. Niestety otrzymałem wiadomość, że poszukują kogoś o większych umiejętnościach. Stwierdziłem, że pewnie nic nie umiem a wszyscy, którzy idą na staż do firm posiadają już 10 projektów komercyjnych, dwa portfolio i znajomość frameworków JavaScriptowych.

Zacząłem uczyć się Angulara, w którym zrobiłem jeden projekt w free code camp. Jednocześnie wysyłałem zgłoszenia na staże. W końcu stwierdziłem, że skoro pewnie jestem za słaby na poziom stażysty, pójdę na darmowe praktyki. Po wysłaniu zgłoszenia firma odezwała się na drugi dzień zapraszając na rozmowę. Na rozmowie jak to na rozmowie na staż, pytania z HTML i CSSa. Dostałem zadanie do wykonania - zakodowanie landing page z trójkątnymi sekcjami. Miałem na to tydzień, tak więc sporo czasu, a jeśli ma się na coś sporo czasu to prawie na pewno zostawi się to na ostatnią chwilę. Nie inaczej było w moim przypadku ale zadanie zostało zaakceptowane i od 3 stycznia 2016 roku zacząłem praktyki.

Zbliżam się do końca serii, bo w następnym poście napisze już o szybkiej zmianie praktyk na pierwszą pracę z prawdziwego zdarzenia jako front end.