wtorek, 30 maja 2017

Dlaczego warto tworzyć notatki z kodu?

Dlaczego warto tworzyć notatki z kodu?

Jednym z największych nieporozumień edukacji, jest moim zdaniem nakazywanie uczenia się różnych rzeczy na pamięć. Zdawanie egzaminów, nie ma nic wspólnego ze zwykłym życiem i pracą, ponieważ sprawdzają ono jedynie wykutą wiedzę. Nie ma to żadnego sensu, bo wiedza ta nie jest utrwalana i szybko wylatuje z głowy.
Praca programisty wymaga przyswajania ogromnych zasobów wiedzy i sprawnego korzystania z nabytych wiadomości. Na podstawie własnych doświadczeń mogę jednak stwierdzić, że prawie nigdy, nie wiąże się ona z zapamiętywaniem dużych fragmentów kodu, który następnie trzeba wklepać do programu 1:1. Jeśli umiesz to zrobić, super, jednak znacznie lepiej jest wiedzieć, z jakiego źródła skorzystać, by znaleźć dobre rozwiązanie. Tak - zwykle jest to Stack.
Można jednak ułatwić sobie pracę przy często powtarzanych czynnościach programistycznych i tworzyć własne "notatki" z kodu, które odpowiadają na często zadawane pytania. Przykładowo - front-end deweloper, może zapisać sobie na początku kariery, jak ustawić box-sizing: border-box dla wszystkich elementów na stronie lub jak wyzerować marginesy bez sięgania po reset.css. Znalezienie takich informacji trochę trwa, natomiast jeśli mamy je pod ręką w jakimś systemie, możemy łatwo je znaleźć lub się nimi podzielić. Przyznam się, że kiedyś notowałem sobie sposoby na rozwiązanie różnych problemów front-endowych w … zwykłym pliku ODT, co oczywiście, miało mnóstwo wad.

Codepen - my z niego wszyscy

Jedna z najbardziej przełomowych rzeczy dotyczących front-endu z ostatnich lat. Wśród założycieli CodePena jest między innymi twórca CSS Tricks, Chris Coyier. Przechodząc do rzeczy - Codepen jest wykorzystywany głównie do tworzenia niewielkich elementów stron WWW. Użytkownik może tworzyć własne "peny", czyli zintegrowane okienka z edytorem i podglądem HTML. Aplikacja jest na tyle mądra, że rozpoznaje bez problemu SCSS, transpiluje różne nadzbiory JS, umożliwia łatwe dodawanie innych bibliotek i dzielenie się kodem. Obsługuje też bezproblemowo Emmeta.
Masz pomysł na rozwiązanie jakiegoś problemu w HTML i CSS? Odpalasz Codepen i za sekundę możesz już pracować, a gotową pracą, podzielić się z kolegami. Możesz nawet załączyć swój pen na stronie WWW, lub pobrać projekt i rozwijać go lokalnie.
Istnieje kilka innych systemów o podobnym działaniu, jednak nie są one tak rozbudowane i dopracowane, jak Codepen. (Ostatnie zdanie może być stronnicze).
Alternatywy - https://jsfiddle.net/

Gist

Gist oferuje zupełnie inną filozofię - pozwala na dzielenie się fragmentami kodu w różnych formatach i nie wyświetla w żaden sposób ich zawartości. Można go porównać do systemu notatek, które dzięki darmowej aplikacji GistBox, można przegladać jeszcze wygodniej. Gists są połączone z Githubem.
Taka forma dzielenia się kodem jest bardzo wygodna, gdy nie ograniczasz się do technologii front-endowych. Gists sprawdzają się na przykład, gdy chcesz odświeżyć sobie wiedzę z jakiegoś zagadnienia - możesz wtedy przeglądnąć swoje wcześniej zapisane notatki, lub zajrzeć do notatek stworzonych przez inne osoby. W pracy dewelopera pojawiają się też nudne, powtarzalne taski (na przykład podłączanie strony WWW do bazy danych) i takie zadania, można zapisać sobie w notatkach i następnie z nich skorzystać.

Jeszcze jedna rzecz na temat zapamiętywania w programowaniu

Moim zdaniem, nauka na pamięć przez wykuwanie nie ma sensu. Jeśli zapamiętałeś daną rzecz, to znaczy, że często z niej korzystasz i jest ona dla Ciebie potrzebna - jak na przykład znajomość gridu Bootstrapa. Gdy musisz sięgać do notatek, takich, jak Gists czy zaglądać na forum, to też ok - widocznie, dana rzecz nie ma kluczowego znaczenia. Zamiast zapamiętywać fragmenty kodu, które są w zasięgu jednego kliknięcia myszą, skup się na ważniejszych rzeczach. Będzie to poznanie, co robi dany fragment kodu, oraz zrozumienie ogólnych konceptów, które przydają się w programowaniu. Ucz się, jak coś działa, a wtedy, zawsze sobie poradzisz.

poniedziałek, 29 maja 2017

Garść inspiracji na ten tydzień #4


  1. Brad Traversy radzi jak radzić sobie z depresją przy programowaniu. Moja rada - więcej wychodzić z domu, nie pracować na "remocie", a będzie ok.
  2. W tym tygodniu dokonałem delikatnego redesignu bloga. Style wbudowane w Blogger są słabe nawet na poziomie typografi. Gdy edytuję kolejne posty, chce mi się cytować Ojca Chrzestnego - zobacz, co oni (blogger) zrobili z moim synem (postem).
  3. Inspiracje z zakresu designu nadchodzą z każdej strony. Człowiek szuka informacji na temat sportowego łowienia uklei i wpada na taką piękną stronę. Świetna robota.
  4. Na YT znalazłem kilka motywujących nagrań na tematy okołoprogramistyczne- dobry trop podsunęło mi forum 4programmers. Musisz obejrzeć przynajmniej to nagranie Wojciecha Suligi na temat rynku pracy.

  5. Książki - zacząłem naukę wzorców projektowych z książki Head Firsta + z książki na temat wzorców dopasowanej do potrzeb JS. Na potrzeby nauki udało mi się też zainstalować IDE do Javy i napisać w nim Hello World :) 
  6. Z sukcesów programistycznych - udało mi się stworzyć pierwszą (samodzielną) aplikację MEAN - możecie ją obejrzeć tutaj i poniżej. Pozdrawiam.

W czym pisać - kompleksowy poradnik dla piszących

Pisanie przynosi wiele satysfakcji, a dla coraz większej rzeszy ludzi, stanowi źródło dochodu. Po napisaniu kilku e-booków, niezliczonej ilości tekstów na blogi i strony internetowe (w pewnym okresie normą było dla mnie powyżej 30 000 znaków dziennie), chciałem podjąć temat tego, w czym pisać.
Jest coraz więcej formatów plików, a rozbudowane procesory tekstu (nie mylić z edytorami tekstu), pozwalają na wygodne napisanie obszernej książki, sformatowanie jej i zapisanie do pliku PDF. Jednocześnie, takie rozwiązanie nie jest najlepsze, bo nie pozwala w pełni skupić się na tworzeniu tekstu. "Bogate" edytory, nie są też najlepsze, przy tworzeniu tekstów do sieci.

sobota, 27 maja 2017

Backstopjs - testy regresyjne dla front-endu

Ile razy podczas tworzenia stron internetowych, byłeś w sytuacji, gdy poprawki wprowadzone w jednym miejscu, pojawiały się niechcący w innym? Jeśli edytujesz elementy i klasy globalne, do takiej sytuacji dochodzi dość często.

Gruntowne testowanie front-endu jest męczące i wymaga otwarcia kilkudziesięciu podstron oraz ich wizualnego przejrzenia na różnych rozdzielczościach. Dodatkowo, człowiek nie jest dość dobry, jeśli chodzi o wychwytywanie niewielkich zmian, które mogą pojawić się, na przykład po zmianie marginesów.

"Czyż nie byłoby cudownie, gdyby istniała możliwość przetestowania całej strony lub aplikacji, bez konieczności żmudnego przeglądania każdej podstrony?"

niedziela, 21 maja 2017

Garść inspiracji na ten tydzień #3

Witam z cotygodniową listą ciekawostek/nowości/rzeczy wartych do nauczenia we front-endzie.

1 Prawdziwym odkryciem tego tygodnia było dla mnie Backstop.js, aplikacja umożliwiająca skuteczne testowanie front-endu stron WWW. Dzięki niemu, możesz zapisać sobie wygląd poszczególnych podstron i następnie, porównać je w stosunku do wprowadzonych zmian.

2 Jakby brakowało wam jeszcze testowania wizualnego, polecam rozszerzenie do Chrome o nazwie Look Alike. Działa podobnie jak Backstop.js, ale uruchamia się je z poziomu przeglądarki. Przydatne, gdy chcemy sprawdzić, czy nasze zmiany nie zepsuły czegoś na produkcji. Koniec z nieoczekiwanymi zmianami na stronach i telefonami od klienta o 20 w piątek, że coś się zepsuło :)

3 Polecam też ciekawą konferencję na temat Internet of Things, która jeszcze bardziej utwierdza mnie w przekonaniu, że nie potrzebuję czajnika z Wi-Fi.

4 Z ciekawostek - jeśli kod JS ma komentarz "Super safe equal height column", powinna zapalić Ci się czerwona lampka. Przy wolnym internecie, nawet rozwiązania "super safe" mogą wyglądać jak kupa i warto im zapewnić fallback. Kolumny o równej wysokości możesz zrobić na przykład w ten sposób.

5 Rozpocząłem prace e-bookiem na temat testowania CSS - będzie dostępna na blogu oraz przez GitHuba.

6 Polecam książeczkę "Jeszcze wydajniejsze witryny WWW" - autorami są takie znakomitości, jak Nicholas Zakas czy Douglas Crockford. Szczególnie ciekawy jest rozdział dotyczący pisania szybkiego CSS.

wtorek, 16 maja 2017

Todo list before push

Todo list before push. For health and successfull development.

  • Check every point on your client/manager brief. Is every feature was implemented and every bug fixed?
  • Open every webpage, that can be affected with code and check - if there is no errors, you can countinue. Did you work with disabled cache and other plugins, for example Stylish?
  • Go to the Git and check your changes. If there is a change to do refactor, do this. Are your all CSS changes sits on good places?
  • After refactoring, check your webpage once more, to get confidence, that there is no errors.
  • If your changed something on production/local server, be confident, that this changes was synchronized. Especially for the pictures, that you are load.
  • After deploy, check your changes on production server.
  • If your fucking up something, take the responsibility.
Lista rzeczy do zrobienia przed pushem. Dla Twojego bezpieczeństwa.
  • Sprawdź jeszcze raz wszystkie zadania, które miałeś zrobić. Czy wszystko na pewno działa?
  • Otwórz podstrony, na których Twoje zmiany mogły spowodować ewentualne błędy. Przy projektach innych, niż one-page, często tworzę listę wszystkich podstron, aby móc potem z niej skorzystać.
  • Upewnij się, że wyłączyłeś cache i takie dodatki do przeglądarki, jak na przykład Stylish.
  • Zrób code review, na przykład za pomocą narzędzia Diff w Gicie. Upewnij się, że Twoje zmiany w CSS, są w odpowiednich plikach i miejscach.
  • Jeśli robiłes refactoring, upewnij się raz jeszcze, że Twoje zmiany niczego nie zepsuły.
  • Gdy Twoje zmiany dotyczyły lokalnego lub zewnętrznego serwera, upewnij się, że są one zsynchronizowane. Dzięki temu będziesz miał mniej nerwów przy deployu. Zwróć szczególną uwagę, na zdjęcia - czy na pewno są w odpowiednim miejscu?
  • Po deployu, sprawdź swoje zmiany na serwerze produkcyjnym.
  • Jeśli coś zepsułeś - napraw.

piątek, 12 maja 2017

Garść inspiracji na ten tydzień #2

Witam po przerwie
W tym tygodniku trochę nowych materiałów do polecenia, a szczególnie:
Jeśli masz jakieś sprawdzone materiały na temat programowania, daj o nich znać w komentarzu !!!
Kamil 

wtorek, 9 maja 2017

Niesamowity trick w CSS - !important bez !important

Front-endowcy go nienawidzą - dzięki temu prostemu trickowi, możesz nadać jakiemuś elementowi większą specyficzność, bez wyszukiwania selektorów. Wystarczy powielić nazwę klasy.

Gdy to zobaczyłem, zbierałem szczękę z podłogi. Źródło - https://www.youtube.com/watch?v=WjP7TEKB7Uo

sobota, 6 maja 2017

Jak ogarnąć nową technologię w kilku krokach

Technologie stosowane przy tworzeniu stron www, nieustannie się zmieniają. Jako junior deweloper, możemy być przytłoczeni na przykład tym, że:
  • Zamiast zwykłego CSS, pisze się w jakimś Sassie (czy to król) i następnie się to kompiluje
  • Zamiast załączyć jQuery po bożemu z CDN, instaluje się go jakimś NPM-em
  • Zamiast dziubać strukturę strony w html, wklepuje się jeden znak w Emmecie i generuje nam niestworzone rzeczy (tzn gotowy szablon html z body i head)
  • Zamiast stosować znaczniki html, pisze się w jakimś Pugu i to też działa
  • i tak dalej...

wtorek, 2 maja 2017

Najlepsze zamienniki dla konsoli Windows

Konsola Windows nie sprawdza się zbyt dobrze, jeśli chodzi o zaawansowane opcje tworzenia stron WWW. Jej jedyną zaletą jest to, że można ją włączyć w dowolnym folderze, klikając PPM + shift. W tym wpisie przedstawię alternatywne opcje dla podstawowej konsoli Windows.

Konsola GIT

Konsola wykorzystująca polecenia Linuxa (na przykład ls czy touch), a także posiadająca wbudowaną dystrybucję Vima. Skorzystasz w niej z SSH. Bardzo dobry zamiennik dla podstawowej konsoli Windows, z uwagi na to, że prawie każdy wykorzystuje Git-a. Można ją odpalić w dowolnym folderze z użyciem PPM. Wygodnym rozwiązaniem jest też ustawienie konsoli GIT jako domyślnej w swoim IDE, na przykład w Webstormie. Dzięki niej, można będzie także łatwiej tworzyć foldery i pliki.

poniedziałek, 1 maja 2017

Garść inspiracji na ten tydzień

1 – Z zainteresowaniem przejrzałem strony największych firm zegarkowych. Bardzo spodobała mi się strona czapek.com z piękną typografią oraz intro na stronie Grand Seiko. Warto zajrzeć, szczególnie dlatego, że te firmy sprzedają zegarki w cenach dobrych samochodów.

2 – Kontynuuję pracę z tutorialami Mariusza Jurczenki z YT na temat Angulara2. Są ciekawe, ponieważ uczą one podstaw, których brakuje przy innych tutorialach.

3 – Polecam też nagrania Clarissy Peterson na temat typografi na stronach RWD. Napisała ona także niezłą książkę na temat responsywnych stron.

4 – Zaskoczyło mnie nagranie na temat prawidłowego ustawiania wysokości linii oraz marginesów na stronie WWW, opublikowane przez Paqmind

5 – Warto zajrzeć także do tutoriala od Net Ninja na temat podstaw Reacta. Na razie udało mi się wypisać hello world :)

6 - … a także do świetnej książki Ethana Marcotte „Responsive Web Design”, którą sobie odświeżyłem.

7 – Zajrzałem także do frameworka front-endowego Foundation, który w praktyce przypomina mi Bootstrapa, z wyciętą klasą .container :)

8 - Blogger robi nadal wszystko, by tekst nie wyglądał w nim, tak, jak chcę.

Git cheatsheet

Git - lista mniej znanych, a bardzo przydatnych poleceń

git clean -fd - usuwa wszystkie zmiany (w tym utworzone pliki i foldery), które nie były skommitowane.
git reset --hard HEAD - usuwa nieskomitowane zmiany
git stash - pozwala zachować zmiany, które zrobiłeś bez ich commitowania.
git rm -r -f --cached (nazwa folderu) - gdy dodałeś do gita niepotrzebny folder (na przykład .idea lub node_modules) i chcesz go usunąć
git revert - gdy skomitowałeś kod i okazuje się, że trzeba wrócić do poprzedniego commita i wykasować inne. Uwaga - wiąże się z utratą danych.