Stejně jako v loňském roce jsme se i letos vypravili nasbírat nové vědomosti a zkušenosti na zahraniční vývojářské konference. První konferencí, kterou jsme letos navštívili, byla dvoudenní WeAreDevelopers ve Vídni. Na několika stagích jsme měli možnost poznat novinky a trendy ve vývojářském světě. Vzhledem k obsazenosti konference bylo někdy takřka nemožné dostat se na zvolenou stage. V tomto článku se rádi podělíme o témata, která nás na konferenci zaujala, ať už se jedná o témata historická jako engine k původnímu Doomovi nebo témata čistě vývojářská.

Zájem o konferenci je vidět na fotce, kterou jsme pořídili před samotnou registrací:

11

The Early Days of Id Software: Programming Principles

Obsahem této přednášky byl náhled do minulosti firmy Id Software. S produkty této firmy se setkala většina z nás ať už vědomě nebo nevědomě. Produkty této firmy jsou totiž počítačové hry – Doom, Catacomb 3D, Heretic, Hexen, Quake apod. Přednášejícím byl jeden ze zakladatelů této firmy, John Romero.

Prezentoval nám možné praktiky vývoje v jejich době a jejich postupné strategie. První strategií, kterou se tato firma ubírala, bylo vynalezení engine, který bude znovupoužitelný pro více her. Proto byl vynalezen engine pro hru Doom a tento engine byl znovupoužit ve hrách jako Heretic, Hexen, Wolfenstein a dalších. Druhým záměrem této společnosti bylo vynalézt hru přímo na míru daným možnostem. Tak vznikla hra Quake.

Něco málo z historie o jejich principech

Zálohování probíhalo tradičně formou disket – každý vývojář měl svoji disketu a vždy své změny prezentoval z této konkrétní diskety. Na team leaderovi bylo “namergování” změn a opět předání aktuální verze. Před odchodem si každý svou práci nutně zálohoval – v době nestabilních disket stačilo málo a data byla ztracena. V pozdější době, s příchodem Subversion a Git, tak preferovali Subversion s vysvětlením, že Git je spíše pro tým, který spolupracuje vzdáleně. K tomu bych rád ještě zmínil, že pracovali v seskupení 9 lidí (4x Designer, 3x Programátor a 2x Artists). Aby měl tým o všem přehled při debugování, je třeba zmínit, že v té době vývojáři nevytvářeli žádné funkce.

 

Updating Mobile Apps Without The App Store

Na téma Updating Mobile Apps Without The App Store přednášel Sani Yusuf, zakladatel společnosti Haibrid, propagátor frameworku Ionic a velký fanoušek filmu Avatar.

Jeho prezentace byla zaměřena na problematiku distribuce aktualizací pro mobilní aplikace, která je hlavně v případě iOS aplikací poměrně zdlouhavá. Jako řešení tohoto problému vyzdvihoval právě Ionic. Jedná se o framework, pomocí něhož lze psát hybridní aplikace. Hybridní aplikace jsou vytvářeny obecně a lze je použít kdekoliv (na jakékoliv mobilní platformě), na rozdíl od nativních aplikací, které jsou stavěny přímo pro danou platformu a jsou s ní svázány. To má své výhody, ale i nevýhody. Hybridní aplikace běží v tzn. WebView, jedná se tedy v podstatě o webovou stánku, která se tváří jako mobilní aplikace. S tím jsou spojeny výkonnostní i implementační problémy.

Ionic je framework založený na AngularJS, hybridní aplikace je tedy vytvářena pomocí HTML, CSS a Javascriptu. Ionic dále aplikaci poskytuje přístup k nativním službám telefonu, jakou jsou například geolokace, fotoaparát, push notifikace nebo TouchID.

Velkou výhodou tohoto přístupu, kromě multiplatformního použijí, je právě jednoduchost a rychlost distribuce aktualizací pro vaši aplikaci. Tím, že aplikace je v podstatě webová stránka, nepodléhá aktualizace žádnému procesu schvalování. Jednoduše po vytvoření změny nebo opravy ve své aplikaci se aktualizace nahraje na server a každému uživateli při jejím spuštění přijde upozornění o nové verzi a možnost ji okamžitě stáhnout.

Refactoring CSS Without Losing Your Mind

Obecně platí, že refactoring je jedna z věcí, do které se nikdy nikomu moc nechce. Jednak tomu může být z důvodů nepřehlednosti, kdy nevíme, zda daná část již byla refactorovaná či nikoliv, anebo i z pohledu toho, že jde o značnou časovou investici. Vývojář totiž neztrácí jen čas tím, že přepisuje stávající kód, ale zároveň i ztrácí čas, který mohl strávit vytvářením nových funkcí. S tím, jak si tento problém alespoň trochu zpříjemnit v oblasti CSS, mluvil Harry Roberts, který momentálně pracuje jako konzultant v oblasti Front-end aplikací. O jakých zjednodušeních a postupech tedy Harry mluvil?

Zaprvé, při refactoringu bychom si měli vždy vybírat malé části projektu – nikdy bychom se neměli věnovat velkým částem, které nám zaberou více než několik hodin či dní. Člověk potom ztrácí přehled, kolik času už na aktuálním úkolu ztratil a kolik ztratí, než úkol dokončí. Občas, když už ztratíme přehled, je „git reset –hard origin/master“ jediným řešením, a to dosti bolestivým.

V případech, kdy je potřeba, abychom měli v produkční verzi najednou refactorovaný kód i legacy kód, doporučuje využití defence.css, díky kterému můžeme zaručit čitelnost a funkčnost daných stránek. Jako příklad, kdy chceme mít i vizuální přehled nad tím, co již bylo upraveno, mluvil Harry o přidání k hotovým třídám prefix „.RF-*“ a následném přidání stylu [class*=”rf-”] { outline: 5px solid green; }, který nám na stránce ohraničí elementy, které již jsou hotovy.

Poslední věcí pak bylo shame.css. Tento soubor slouží pro všechny styly, které se nám nepovedlo udělat bez hacků, !important nebo jiných záležitostí, které nejsou zrovna příkladem čistého kódu. Shame.css nám tedy umožňuje udržet všechny tyto styly na jednom místě a automaticky nám tak vytváří todo list. Za zmínku stojí i „all: initials“ který nám daný styl oprošťuje od všech dědičných stylů.

Paint the Web with CSS

O kreslení s CSS mluvila Eva Lettner, která je zaměstnána jako Frontend Developer ve firmě ChillBill z Vídně. Kreslení v CSS jí slouží jako relax a způsob, jak se seznámit s novinkami ze světa CSS. V prezentaci nejprve nalákala částí obrázku vytvořeného pomocí CSS, následně ukázala jak vytvořit základní tvary a vysvětlila pseudo elementy. Po představení potřebných základů přešla k samotné tvorbě obrázku.

Obrázek představoval jednoduchou hlavu zombíka složenou z pár základních tvarů. Krok za krokem s námi prošla styly jednotlivých elementů, vysvětlila triky použité pro animování a představila další obrázky. V samotném závěru prezentace Eva Lettner zhodnotila použití CSS obrázků na produkci a zmínila alternativu. Samotné obrázky, animace a další možnosti malování s CSS je možné shlédnout v celé přednášce na YouTube.

9

Model-Minded Development

Přednášku o důležitosti modelu při vývoji software nám na konferenci naservíroval George Fairbanks. George pracuje jako softwarový inženýr pro Google. Disponuje zkušenostmi z akademické půdy i komerční praxe, kde navrhoval systémy pro velké firmy.

Přednáška se zaměřovala na dvě hlavní témata – model a teorie. První část přednášky patřila modelu. Software může být jen tak dobrý, jak dobrý je jeho model. Model a jeho symboly jsou totiž to, co stojí mezi softwarem a reálným světem. Pokud něco není zaneseno v modelu, software o tom jednoduše neví. Najít dobrý model však vůbec není jednoduché, je to balancování mezi jednoduchostí a přesností. Pokud model obsahuje příliš mnoho detailů, je komplikovaný a tím pádem těžký na pochopení. To pak zvyšuje riziko chyb. Příliš jednoduchý model nám naopak nemusí umožnit zachycení všech případů, se kterými potřebujeme pracovat. Propracovaný a složitější model bychom měli použít pro kritická místa aplikace, kdežto méně kritické oblasti by se měly uchylovat spíše k jednodušším modelům.

Druhým pilířem přednášky byla myšlenka od Petera Naura popisující, že programování není pouze o vytváření kódu a dalších souvisejících textů, ale spíše o budování teorií. Tyto teorie se vytváří nejprve v hlavách vývojářů. Pro přežití softwaru v čase je kritické, aby se co nejvíce z těchto teorií přeneslo z hlav vývojářů do kódu. Budování softwaru je totiž ve většině případů týmová práce. Pokud z týmu někdo odejde a teorii si odnese s sebou v hlavě, nastává problém. Jak ale ověříme, že se teorie přenesla v dostatečné míře do kódu? Ideální nástroj pro to je code review. Pokud se díváme na cizí kód, musíme si položit otázku: proč tento kód funguje správně? Když jsme schopni si na ni odpovědět, teorie se přenesla. Pokud se musíme jít zeptat kolegy, abychom pochopili proč kód dělá to, co se od něj čeká, znamená to, že část teorie je stále jen v hlavě kolegy.

Monorepos in the Wild

Přednášku o mono repozitářích si pro nás připravil Markus Oberlehner. Jak již název napovídá, přednáška se zabývala mono repozitáři, jejich výhodami, nevýhodami a případy užití. Pokud se řekne monolit, většina lidí si představí nějaký neudržitelný kus starého kódu. Toto nemusí platit u mono repozitářů, protože mít zdrojový kód v 1 repozitáři neznamená, že jej nemůžeme mít rozdělený do více projektů nebo modulů.

Mono repozitáře můžeme obecně rozdělit na 2 typy: Monstrous repos a Project repos. Monstrous repos je repozitář, v němž je uložen veškerý zdrojový kód společnosti – příkladem může být např. Facebook, který používá Mercurial a má v něm uloženo více než 50 GB a Google, který používá vlastní source control Piper, ve kterém má uloženo více než 90 TB. Project repos je repozitář, který obsahuje zdrojový kód vztahující se k projektu. Může obsahovat nesourodé projekty/technologie, např. webová aplikace, backend, android a iOS aplikace. Projektový repozitář se často používá u open source projektů, např. React, Babel, Ember, Symphony.

Jaké jsou výhody mono repozitářů?

  • mono repozitář je jediný zdroj pravdy (one source of truth)
  • je jednoduché sdílet a znovu používat kód v rámci jednoho repozitáře
  • velký refactoring, který zasahuje více projektů, je možné udělat jednodušeji 
  • jednodušší je taktéž kooperace s ostatními týmy

Přednáška by nebyla úplná, pokud by autor zmiňoval pouze výhody. Jaké jsou tedy nevýhody mono repozitářů?

  • při použití mono repozitáře se mnohonásobně zvětší komplexita zdrojového kódu
  • může nastat problém se škálováním samotného source control engine
  • může nastat problém s přístupovými právy pro jednotlivé projekty v rámci repozitáře (např. v gitu neřešitelné)
  • může nastat to, že se projekty zbytečně často překládají a automaticky testují – např. změna v projektu A vyvolává build v projektu B, který nutně s projektem nesouvisí. Zároveň ale systém, který se zabývá sestavováním projetu (Jenkins, Bamboo, Team City..), zaznamenal změnu v rámci repozitáře…

Things I Wish I Knew Before Starting React Native

Robert Prosenc z firmy 25th floor mluvil o výhodách a problémech s frameworkem React Native pro tvorbu mobilních aplikací. React Native je framework, který umožňuje vývoj mobilních aplikací pro platformy iOS a Android jednotným způsobem, za použití knihovny React a v jazyce JavaScript. React Native, na rozdíl od frameworku Ionic, přináší možnost tvorby skutečně nativních aplikací. Výsledná aplikace není pouze Web View s webovými komponentami, které jsou nastylovány tak, aby vypadaly jako nativní UI komponenty, ale je to aplikace, ve které je uživatelské rozhraní tvořeno opravdu nativními komponentami.

Hlavní výhoda oproti vývoji v nativních technologiích pro mobilní platformy (Java/Swift) je podstatné ušetření nákladů, protože jedna aplikace vyvíjená jedním týmem běží na obou hlavních mobilních platformách. Další zásadní výhodou je samotný React, jehož principy už na našem blogu popisoval Tom Jílek v článku Jak psát velkou aplikaci v Reactu.

Jako nevýhody frameworku oproti nativním technologiím zmiňoval Robert Prosenc programovací jazyk JavaScript, problémy s výkonem aplikace, častou změnu API a konfiguračních souborů.

Autoři:

Lukáš Rejha – The Early Days of Id Software: Programming Principles
Martin Tměj – Updating Mobile Apps Without The App Store
Michal Dvořáček – Refactoring CSS Without Losing Your Mind
Martin Meuer – Paint the Web with CSS
Tomáš Rejent – Model-Minded Development
Jaroslav Strouhal – Monorepos in the Wild
Tomáš Bambas – Things I Wish I Knew Before Starting React Native

Chceš s námi vyrazit na konference?

Všichni naši vývojáři mají možnost vycestovat na domácí i zahraniční konference a načerpat tak znalosti o novinkách, trendech a tématech, které hýbou světem. Přidej se k nám a vydej se s námi do Vídně, Krakova, Amsterdamu nebo kamkoliv jinam…

Aktuálně hledáme seniorní Java / JEE Developery do kanceláří v Hradci Králové, Brně, Bratislavě, ale i na home-office.

Zajímá tě něco jiného? Mrkni na všechny naše otevřené pozice a dej nám o sobě vědět, bez ohledu na to, zda máš rád front-end nebo back-end, jestli nějakou technologii umíš nebo ne. Pokud budeš ty sám chtít, dostaneš u nás příležitost naučit se, co tě zajímá nebo udělat něco výjimečného.

2