Street of Code

By Street of CodeEducation Courses

Street of Code episodes

July 08, 2019Ep. 17 – OOP Part 1 (Intro)
Touto epizódou sa začína séria o OOP – objektovo orientovanom programovaní. Táto epizóda je iba úvodnou k celej sérii a povieme ti, o čom celá séria bude a skúsime načrtnúť, čo to OOP je a na čo sa používa.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/07/StreetOfCode-Ep17.mp3
00:00 – 01:24 Úvod
01:25 – 02:33 Programovacie paradigmy
02:34 – 04:50 Čo je objekt?
04:51 – 07:58 Procedurálne vs. objektovo orientované
07:59 – 10:47 Piškvorky objektovo vs. procedurálne
10:48 – 11:53 Procedurálne vs. objektovo orientované po druhé
11:54 – 15:09 Výhody dedenia
15:10 – 16:05 Záver
DISCLAIMER: OOP je jeden z programovacích štýlov. Nie je to jediná voľba a nie vždy ani najlepšia voľba programovacieho štýlu. My obaja programujeme hlavne objektovo a je to asi najčastejšie používaný štýl v praxi.
Paradigmy
Dve rozdelenia:
Imperatívne – povedz mi ako a čo mám urobiť a ja ti z toho dám výsledok
Deklaratívne – povedz mi čo chceš a ja ti to už nejako dodám
Procedurálne (imperatívne) – využíva procedúry (funkcie), ktoré majú nejaké parametre a dajú sa volať od hocikadiaľ
Funkcionálne (deklaratívne) – tiež využíva funkcie. Tieto funkcie sú však bližšie tým matematickým. Funkcionálne programovanie sa snaží vyhýbať zmenám stavu a meniacim sa dátam
Objektovo orientované (imperatívne) – využíva objekty, ktoré majú nejaké vlastnosti (premenné) a nejaké správanie (funkcie/metódy)
Procedurálne vs. Objektovo orientované
V procedurálnom si spravým štruktúru a funkcie, ktoré majú túto štruktúru ako prvý parameter
V objektovom si spravím classu a v nej mám k nej patriace funkcie
Procedurálne nemá dedenie, polymorfizmus, interfaces (rozhrania), …
Piškvorky v OOP
Reálny svet: Dvaja hráči, hracia plocha, ťahy, vyhodnocovacia logika (výhra/prehra)
Objekty: Player1, Player2, Board, Moves, WinLogic, Game
Dedenie
Dedenie je jednou z nemála výhod voči iným štýlom
4 classy: Vozidlo, Auto, Motorka, Autobus
Každá ma v sebe metódu VypočítajSpotrebu
Nezaujíma nás, s ktorým presne vozidlom pracujeme, dôležité je, že to určite má túto metódu
Záver
V ďalších epizodách sa pokúsime vysvetliť rozdiely medzi objektom, classou a inštanciou. Potom si prejdeme základné pojmy z OOP – dedenie, abstraktná trieda, rozhranie, enkapsulácia, atď. Neskôr prejdeme výhody a nevýhody OOP a ďalšie veci.
Užitočné odkazy
Jakubova hra, ktorá učí základné koncepty OOP
Stará dobrá Wiki
OOP pre 6 ročných
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
17 min
July 02, 2019 Ep. 16 – O nás, o živote ako takom
Keďže tento podcast ma byť niekedy aj o živote ako takom, tak sme sa rozhodli spraviť taký osobnejší podcast. Dozviete sa kto sme, kde sme vyrastali, kde bývame, čo robíme vo voľnom čase a mnoho ďalšieho.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/07/StreetOfCode-Ep16.mp3
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
35 min
April 28, 2019Ep. 15 – Clean Code Part 5 (System, Emergent Design)
5. časť série o Clean Code je zároveň aj poslednou a rozoberáme v nej kapitoly System a Emergent Design. Ako funguje mesto? Jeden človek všetko riadi? Keď nám prestane tiecť voda, tak nebudú ani odvážať odpad? Nie. Separation of Concerns. V druhej časti epizódy sa pobavíme o 4 pravidlách, ktoré nás privedú k dobrému dizajnu.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/04/StreetOfCode-Ep15.mp3
00:00 – 00:29 Úvod
00:29 – 03:27 Viete si predstaviť, že vybudujete sami mesto?
03:28 – 07:20 Separation of Concerns
07:21 – 11:03 Dependency injection
11:04 – 12:39 Separation of Concerns ako základ pre agilný vývoj
12:40 – 15:15 Aj pri agilnom vývoji treba myslieť trochu dopredu
15:16 – 16:34 4 Pravidlá pre Emergent Design
16:35 – 20:11 Pravidlo 1: Prechádzajú všetky testy
20:12 – Pravidlo 2: Duplikácia
Budujeme mesto
Pri malej dedine môže mať beh celej dediny na starosti jeden človek (jedna classa vie v malom programe riešiť všetko).
Separation of Concerns – každá jednotka v kóde je zodpovedná za svoju vec a nemieša sa do starostí niekoho iného (napr. ho nezaujíma ako vytvorí nejakú nadradenú classu – nevytvára ju).
Keď začíname systém budovať môžeme mať všetko pokope. Postupne ako nám táto “kopa” rastie začne byť čast na to, aby sme to pekne oddelili.
Dobrým príkladom Separation of Concerns je Dependency Injection – objekty, ktoré classa používa vytvára za nás framework (alebo niečo iné) a my to nemusíme v každej classe robit zvlášť
Agilný vývoj je vôbec možný hlavne vďaka práve Separation of Concerns. Tým, že je všetko oddelené, sa nám to oveľa ľahšie rozširuje alebo mení.
Keď ideme agilne, tak aj tak potrebujeme mať trochu víziu ako to má vyzerať v budúcnosti, aká veľká bude naša aplikácia a tak.
Emergent design
4 pravidlá, ktoré by mali spôsobiť, že nám vznikne dobrý design:
Prechádzaju všetky testy
Neobsahuje žiadnu duplikáciu
Vyjadruje úmysel programátora
Minimalizuje počet tried a metód
Prechádzajú všetky testy
Systém môže byť perfektne navrhnutý, ale pokiaľ neviem overiť, že naozaj funguje, tak je celý systém spochybnený
Keď zrazu neprechádza nejaký test, tak to treba čím skôr, rozumej hneď, opraviť
Keď vytvárame systém tak, aby bol testovateľný, tak zároveň nás to tlačí k tomu, aby naše triedy boli malé a jednoúčelové (SRP – single responsibility principle)
Previazaný systém sa tiež tažko testuje. Čím viac testujeme, tým viac musíme využívat princípy ako dependency injection, interfaces, aby sme toto previazanie znížili
Body 2 až 4 (v podstate refaktorovanie)
Vďaka bodu číslo 1 (máme testy) sa nemusíme báť, že refaktorovaním niečo pokazíme
Duplikácia – úplne rovnaké riadky, podobné riadky, ktoré sa dajú upraviť na totožne a vytiahnuť von, dva krát vyjadrím to isté, len inak
Vyjadruje úmysel programátora – čím väčší systém, tým je dôležitejšie jasne vyjadriť čo sme chceli kódom dosiahnuť. Dobré názvy, malé triedy a funkcie, keď používam DesignPatterny tak tak aj nazývam triedy. Najdôležitejšie je, sa o to vôbec pokúsiť. Nepovedať si, že však to funguje, skončil som.
Minimalizovanie počtu tried a funkcií – všetky princípy sa dajú preháňať a potom sa nám stáva, že máme milión malých tried, milión interfacov, milión malých funkcií, …. Pravidlo má však najnižšiu prioritu, ale treba byť naozaj opatrný pri preháňaní s dodržiavaním všetkých princípov (aj v tejto knihe).
Záver
Dá sa povedať, že keď budeš nasledovať týchto X princípov, tak z teba bude programátor? Ani nie len že dobrý, ale vôbec programátor? Nie. Musíš si to vyskúšať. Musíš si sadnúť za comp a programovať. Písať. Veľa. Čím väčšie veci v živote napíšeš tým viac skúsenosti budeš mať. Tieto princípy je naozaj potrebné vedieť brať s rezervou resp. vedieť kde je ten zlatý stred.
Kniha na Amazone
Blog Uncle Bob-a
Twitter Uncle Bob-a
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
31 min
March 18, 2019Ep. 14 – Clean Code Part 4 (Unit Tests, Classes)
V 4. časti série Clean Code rozoberáme Unit testy a Triedy. Čo sú to unit testy a načo ich potrebujeme? Ako mať testy čisté? Ako by mala vyzerať čistá trieda? Taktiež si prejdeme veľmi dôležité princípy ako Single responsibility principle, Cohesion, Open-Closed principle.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/03/StreetOfCode-Ep14-1.mp3
00:00 – 00:35 Úvod
00:36 – 04:51 Unit testy – čo to je a prečo ich chceme mať čisté
04:52 – 06:00 Výhody unit testov (Flexibilita v produkčnom kóde)
06:01 – 13:40 Čo robí testy čistými?
13:41 – 18:58 Akronym FIRST (fast, independent, repeatable, self-validating, timely)
18:59 – 21:53 Unit testy – záver, TDD (test driven development)
21:54 – 23:17 Classy, úvod – ako vyzerá bežná classa?
23:18 – 25:39 Enkapsulácia, čo to je a príklad
25:40 – 26:43 Triedy by mali byť krátke
26:44 – 31:37 Single responsibility principle
31:38 – 33:30 Cohesion (Súdržnosť)
33:31 – 35:30 Organizovanie pre zmenu, open-closed principle
35:31 – 37:12 Izolovanie od zmien
37:13 – Zrhnutie
UNIT TESTY
Unit test – Testovanie malej časti kódu (unitu) izolovaného od ostatných častí.
Testovaci kód je rovnako dôležitý ako produkčný a mali by byť na ňom uplatnené princípy clean code
Ak máme veľa produkčného kódu otestovaného, tak si môžeme dovoliť skúšať prerábať existujúci kód a zlepšovať ho, pretože nám testy hovoria, čo funguje a čo nefunguje. A to nám dáva flexibilitu.
Testy by mali byť krátke, čitateľné. Mali by robiť jednu vec a mať vhodný názov.
Jeden test by mal testovať jednu vec, resp. jeden koncept.
C# Tutoriál – Základy Unit Testovania (Gabov video-tutoriál)
Unit testing in C# – basics (Gabov blog)
TDD – Test driven development
Classes (Triedy)
Triedy sú nejako zorgazinované (najprv premenné a to tiež v poradí konštánt, public premenných a private. Potom máme konštruktor a za tým public metódy. Ak nejaká public metóda obsahuje v sebe private metódu, tak tá private metóda by mala byť v triede za tou public metódou.
Enkapsulácia – Využitie public, private, protected a package-private funkcie a premenné.
Single responsibility principle – Trieda by mala mať jeden dôvod pre zmenu.
NIE – DatabaseManager, v ktorom upravujeme produkty aj uživateľov
ÁNO – ProductManager, CustomerManager
Cohesion (Súdržnosť) – Čím viac je trieda súdržná, tým viac sú premenné a metódy vzájomne závislé a tvoria spolu logický celok. Ak trieda nie je súdržná, tak ju treba možno rozdeliť na viacero menších tried.
Organizovanie pre zmenu
Izolovanie od zmien
Dobrý článok (Hľadanie zlatej strednej cesty)

Kniha na Amazone
Blog Uncle Bob-a
Twitter Uncle Bob-a
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
39 min
February 26, 2019Ep. 13 – Clean Code Part 3 (Boundaries, Clean Concurrency)
V tretej časti série Clean Code rozoberáme Boundaries a Clean Concurrency. To znamená, že rozprávame o používaní knižníc tretích strán, o ich testovaní a o tom, ako sa dá čisto písať viac vláknová aplikácia, ako sa správať k vláknam, čo všetko pri tom treba vedieť a ako sa takéto aplikácie dajú testovať.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/07/StreetOfCode-Ep13.mp3
00:00 – 00:34 Úvod
00:35 – 01:15 Bound aries – úvod
01:16 – 04:30 Príklad – HashMap
04:31 – 06:50 Learning Tests
06:51 – 09:46 Používanie kódu, ktorý ešte neexistuje
09:47 – 10:48 Concurrency – úvod
10:49 – 11:48 Rodiely medzi jedno- a viacvláknovými aplikáciami
11:49 – 14:38 Performance viacerých vlákien
14:39 – 15:30 Viacvláknové programovanie je náročné
15:31 – 17:30 Kritické sekcie by mali byť čo najmenšie
17:31 – 19:07 Používanie klonovaných dát
19:08 – 19:47 Vlákna by mali byť čo najviac nezávislé
19:48 – 21:42 Know your library
21:43 – 22:42 Know your execution models
22:43 – 23:34 Kritické sekcie by mali byť čo najkratšie v2
23:35 – 25:11 Testovanie viacvláknových aplikácií
25:12 – 25:43 Konfigurácia
25:44 – 27:30 Rôzne platformi, rôzny výsledok
27:31 – 28:06 Nereprodukovateľnosť
28:07 – 29:18 Zhrnutie
Boundaries
Hranice medzi nasim kódom a kódom, nad ktorým nemáme kontrolu
Zredukovanie nežiadúcej funkcionality
Learning Tests – namiesto skúšania knižnice si na túto knižnicu napíšeme testy, čím sa naučíme ju používať a zároveň si ju aj otestujeme – Win/Win
Volania knižnice zaobalíme do vlastnej triedy, aby sme v prípade zmeny museli zasahovať do čo najmenej kódu
Predchádzajúci bod sa dá využiť aj pri tom, keď ešte nevieme, ako bude kód tretej strany vyzerať
Clean COncurrency
Concurrency je práca s viacerými vláknami
Jednovláknové aplikácie sa oveľa jednoduchšie debugujú
Súbežnosť nie vždy zlepšuje performance
Má relatívne veľký overhead
V kritických sekciách mať čo najmenej práce s dátami
Keď pracujeme s read-only dátami, tak si vieme vytvoriť ich kópie a až tie poslať do vlákien, aby sa neobmedzovali
Vlákna by mali byť čo najviac nezávislé
Know your library – možno môj jazyk ponúka lepšie možnosti ako spraviť thread-safe dictionary
Know your execution models – spoločné zdroje, mutex, vyhľadovanie vlákna, deadlock, livelock, producer-consumer, readers-writers, dining philosophers
Testovanie viacvláknového kódu je veľký problém
Kód je potrebné testovať vo viacerých scenáriách – 1 vlákno, 100 vlákien, Mac OS, Windows, spomalovanie
Na rôznych platformách sa môže viacvláknový kód správať úplne inak
Kniha na Amazone
Blog Uncle Bob-a
Twitter Uncle Bob-a
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
30 min
February 10, 2019Ep. 12 – Clean Code Part 2 (Komenty, Objekty a Error handling)
Druhá časť našej série o čistom kóde. Preberáme ďalšie kapitoly knihy Clean Code od Roberta “Uncle Bob” Martina. V tejto časti sa dozviete ako nepísať komenty, aký je rozdiel medzi objektami a dátovými štruktúrami (taktiež načo to je dobré). Na záver ešte stihneme prebrať kapitolu Error handling.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/02/Ep12.mp3
00:00 – 00:24 Úvod
00:25 – 01:10 Komenty
01:11 – 03:29 Dobré komenty
03:30 – 08:43 Zlé komenty
08:44 – 10:29 Objekty a dátové štruktúry
10:30 – 12:19 Abstrakcia
12:20 – 13:54 Procedurálne vs. objektovo orientované programovanie
13:55 – 16:05 Law of Demeter
16:06 – 17:42 DTO (Data transfer object)
17:43 – 18:20 Error Handling
18:21 – 23:48 Checked vs Unchecked Exceptions, kedy a ako používať
23:49 – 27:06 Nevracať ani nevkladať NULL do funkcií
27:07 – Záver
Komenty
Keď sa zamyslíme, tak väčšinou komentujeme vtedy, keď nevieme, aby náš kód hovoril za seba (resp. nevieme to lepšie naprogramovať)
Dobré komenty:
legálne komenty (podpis autora, copyright)
TODO komenty (na toto pozor ale)
Keď chceme vysvetliť, prečo sme sa rozhodli tak, ako sme sa rozhodli (pri nejakej business logike)
Dokumentácia (Java Doc napr.)
ZLÉ komenty:
komenty namiesto toho, aby sme funkciu nazvali výstižným názvom
zavádzajúce komenty – komenty časom klamú lebo kód sa mení, takže najlepší koment je žiadny koment
obvious komenty – String customerName // Name of the customer
zakomentovaný kód, ostatní sa ho potom boja vymazať alebo prepísať
Objekty a dátové Štruktúry
Objekty zverejňujú správanie ale schovávajú data. Štruktúry nemajú správanie a zverejňujú data
dátová štruktúra je trieda, ktorá má fieldy a gettre prípadne… nemá funkcie
objekt je trieda, ktorá mú funkcie, obsahuje chovanie
abstrakcia skrýva implementáciu
Law of demeter
DTO (data transfer object), class (bean) ktora obsahuje fieldy a getre
ERROR HANDLING
nepoužívať checked exceptions (Java)
checked vs unchecked exceptions (Java)
dať výnimkám kontext, resp. výstižný názov a správu v nej
vytvárať si vlastné výnimky je dobré
nevracať NULL vo funkciach
nedávať NULL ako parameter do funkcie
rovnováha medzi robustnosťou a čitateľnosťou
Kniha na Amazone
Blog Uncle Bob-a
Twitter Uncle Bob-a
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
28 min
January 31, 2019Ep. 11 – Clean Code Part 1 (Názvy, Funkcie)
Prvá časť našej série o čistom kóde. Preberáme v nej prvé kapitoly knihy Clean Code od Roberta “Uncle Bob” Martina. V prvej časti porozprávame niečo o tom, ako by mal programátor pomenovávať rôzne prvky v kóde. V druhej časti rozoberáme funkcie, ich odporúčanú dĺžku, počet parametrov a ďalšie veci.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/07/StreetOfCode-Ep11.mp3
00:00 – 00:48 Úvod
00:49 – 03:55 Názvy
03:56 – 05:29 Vyhľadateľné názvy
05:29 – 08:51 Mental mapping
08:52 – 09:40 Nesnažte sa byť vtipný v kóde
09:40 – 10:37 Názvy funkcií by mali byť slovesá
10:38 – 12:52 Jeden názov pre každý koncept
12:53 – 13:24 Funkcie
13:25 – 15:12 Dĺžka funkcií
15:13 – 16:07 Zhora dole
16:08 – 17:57 Jedna úroveň vnorenia v rámci funkcie
17:58 – 20:42 Koľko parametrov by mala mať funkcia
20:43 – 22:09 Funkcia by mala robiť jednu vec
22:10 – 23:30 DRY – Don’t repeat yourself
23:31 – 24:34 – Záver
Názvy
Názvy, ktoré odhaľujú zámer (grades namiesto list)
Vyhýbať sa skratkám – getNoKids() môže znamenať aj niečo iné ako getNumberOfKids()
Namiesto konštánt používať vyhľadateľné názvy
Mental mapping je zlo – nenechajme programátora rozmýšľať navyše
Nesnažte sa byť vtipný v kóde – iných programátorov to môže zmiasť
Názvy funkcií by mali byť slovesá, názvy premenných podstatné mená (výnimkou sú boolean premenné)
Spoločný názov pre každý koncept – keď raz get-ujeme customerov tak zákazníkov nebudeme fetch-ovať
Funkcie
Krátke a ešte kratšie
Zhora dole – súvisiace funkcie by mali nasledovať pekne za sebou
Telo if-ov a for-ov sa väčšinou dajú vytiahnuť do novej funkcie
Funkcia by nemala mať viac ako 3 parametre – ak má, tak je pravdepodobné, že nerobí jednu vec
Funkcia by mala robiť jednu vec a nemala by mať sideeffecty
DRY – Don’t Repeat Yourself – ak sa niečo v kóde opakuje, dajme to do funkcie/classy a budeme mať menej opravovania v budúcnosti
Tweet o getNoKids()
Kniha na Amazone
Blog Uncle Bob-a
Twitter Uncle Bob-a
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
25 min
January 31, 2019Ep. 10 – Úvodná epizóda ku clean code sérii
Clean Code od Robert C. Martina je naozaj úžasná kniha, plná dobrých rád a tipov pre každého programátora. Táto epizóda je iba krátkym úvodom k našej sérii podcastov, v ktorých pôjdeme podľa tejto knihy a budeme rozoberať práve čistý kód.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/01/StreetOfCode-Ep10.mp3
00:00 – 00:22 Úvod
00:23 – 01:27 Čo je clean/dirty code
01:28 – 03:36 Kedy vzniká zlý kód
03:37 – 04:32 Craftsmanship
04:33 – 05:09 O čom bude táto séria
Clean Code
udržiavateľný, čitateľný, ľahko pochopiteľný
dá sa testovať
Dirty Code
veľmi ťažko pochopiteľný
side-efekty
dlhé funkcie
nedá sa testovať
Kedy vzniká zlý kód
keď sa nestíha, ponáhla
keď ma prioritu rýchlosť
nevedomosť
Craftsmanship
zodpovednosť za naše “remeslo”
Kniha na Amazone
Blog Uncle Bob-a
Twitter Uncle Bob-a
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
6 min
January 20, 2019Ep. 9 – Deň programátora
Ako vyzerá deň programátora? Ako si vyberá úlohy a ako si robí svoju prácu?
Taktiež ti povieme ako vyzerá Gabov a Jakubov deň v práci. Na záver si povieme 6 najčastejších aktivít programátora.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/01/StreetOfCode-Ep9.mp3
00:00 – 00:27 Úvod
00:28 – 06:26 Ráno programátora a jeho produktivita
06:27 – 09:01 V čom spočíva práca programátora
09:02 – 13:17 Tasky/Úlohy programátora
13:18 – 16:52 Meetingy
16:53 – 14:01 Ako vyzerá náš deň v robote?
20:22 – 6 najčastejších aktivít programátora
RÁNO PROGRAMÁTORA
Prísť do roboty môže v podstate hocikedy od 6:00 do 9:30 (flexibilná pracovná doba)
Vo väčšine firiem je nejaká doba, napr. od 9 do 14 kedy by tam ľudia mali byť, ale či prísť skôr alebo neskôr to už je ta flexibilita
Ráno sme viac produktívny, preto napr. my (Kubo a Gabo) chodíme radšej skorej do roboty cca o 7:30
Po príchode do roboty ešte nejakú dobu (20min cca) pozeráme maily, čo je nové atď (Toto sa dá robiť prípadne aj pri raňajkách, ak si ich vezmete do roboty
V ČOM SPOČÍVA PRÁCA PROGRAMÁTORA?
Nie je to len programovanie
Väčšinu času programátor rozmýšľa
Taktiež debugovanie, navrhovanie kódu, prezeranie už existujúceho kódu (aby sme vedeli ako spraviť zmeny)
Analýza riešenia a googlenie
TASKY PROGRAMÁTORA
JIRA – nástroj na pre evidenciu úloh a bugov pri vývoji softvéru
Programátor si vyberá úlohy z JIRA systému a pracuje na nich
V úlohách je napísané čo treba urobiť
MEETINGY
Ak sa vo firme používa Scrum/Kanban, resp. agilný vývoj, tak tých meetingov bude pravdepodobne viac (Plánovanie, Retrospektíva, Demo atď)
V menších firmách (napr. tam kde robí Gabo) meetingy sú neformálne vo forme diskusie (bez prezentácie či dopredu zvolenej štruktúry)
Dôležitý je výstup zo stretnutia, aby sa pamätalo aj neskôr, o čom ste sa rozprávali a na čo ste prišli
6 NAJČASTEJŠÍCH AKTIVÍT PROGRAMÁTORA
Rozmýšľanie
Debugovanie
Plánovanie, analýza tasku
Navrhovanie nových úloh
Programovanie
Testovanie
Ako môže vyzerať zvyšok dňa programátora?
V epizóde 8 sme rozoberali, ako sa môže programátor zlepšovať. Vymenovali sme postupne aktivity, ktoré môže robiť po práci, aby zlepšoval svoje schopnosti programátora.
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
22 min
January 06, 2019Ep. 8 – Ako sa môže programátor zlepšovať
Ak chceš byť lepší programátor, tak by si na sebe mal stále pracovať. V tejto epizóde ti prezradíme nejaké spôsoby, ktorými sa vo voľnom čase môžes stať lepším programátorom.

Stiahnuť
https://wp.streetofcode.sk/wp-content/uploads/2019/01/StreetOfCode-Ep8.mp3
00:00 – 00:38 Úvod
00:39 – 05:23 Knihy
05:24 – 09:43 Side projects
09:44 – 11:24 Dokumentácia
11:25 – 12:40 Videá, podcasty
12:41 – 14:01 Konferencie
14:02 – 15:42 Code training stránky
15:43 – 15:51 Záver
Knihy ako zdroj znalostí
Oplatí sa vôbec čítať knihy?
Clean Code
Effective Java
Java Concurrency in Practice
Test Driven Development by Example
Introduction to Algorithms
Design Patterns: Elements of Reusable Object-Oriented Software
Side Projects
Fantastická vec na získanie aj praktických vedomostí, nie len teórie z kních
10000 hodín
Open source projekty
Dá sa vidieť veľký projekt, nie len jednosúborový
Netreba hneď prispievať, stačí si to len prejsť
Priespievanie je super, ale je to náročné
Dokumentácia
Naučí presne ako sa daný framework má používať
Väčšinou sa v dokumentácii píše aj prečo sú veci naprogramované tak ako sú
Videá, Podcasty
Video vie aj prakticky ukázať veci
Pohodlný spôsob
Podcasty – CodingBlocks
Learn2Code, PluralSight
Super youtube kanál
Konfrencie
Dajú sa pozerať aj videá z prednášok
Networking – ak je pre teba
Code training stránky
Super spôsob ako získať programátorské myslenie
Precvičenie algoritmov
Úlohy sa môžu objaviť aj na pohovoroch
Project Euler, CodeSignal, Codility, CodeForces
Viac epizód nájdeš na https://streetofcode.sk/podcast
Pridaj sa na Discord tu - https://streetofcode.sk/discord
16 min