10. března 2017

Jak dělám Java pohovor IV: Java workshop

Zcela bezkonkurenčně nejčtenějším zápisem na mém blogu je opus magnum Jak dělám Java pohovor. Jeho čtenost je řádově vyšší, než u zbytku veškerých textů. Ten článek už je skoro pět let starý a neodpovídá (mojí) realitě.

Věci, které za to stojí, se snažím vylepšovat, takže je v důsledku dělám jinak. A pokud máte to štěstí, že si můžete vybírat lidi k sobě do týmu, tak by vám na tom mělo záležet. Hodně. A tak si ty poslední tři, čtyři roky říkám, že bych měl svůj zápis zaktualizovat. Jak tedy dělám pohovor dnes?

Agenda Java interview

Agenda pohovoru zůstala hodně podobná:
  1. Představím se já.
  2. Prostor pro otázky kandidáta a/nebo představení společnosti, business domény, našeho oddělení a projektů.
  3. Diskuze nad kandidátovým projektem.
  4. Review kandidátova kódu.
  5. Java workshop
Drobnou změnou je bod číslo 3, diskuze nad kandidátovým projektem. Velkou a stěžejní změnou je pak titulní Java workshop.

Diskuze nad kandidátovým projektem

Dříve jsem v tomto bodě probíral kandidátovo CV, ale postupně se to vyvinulo v diskuzi nad konkrétní zkušeností. Přijde mi to zajímavější a přínosnější, než diskuze nad "suchou historií".

(Mimochodem, kandidáti mají neuvěřitelně zažitou historizaci svojí praxe. I když jim opakovaně explicitně zdůrazníte, že nechcete slyšet chronologicky odříkanou pracovní zkušenost, většinou vás naprosto ignorují a spustí naučený kolovrátek. Hanba vám HR a head-hunteři!)

V dnešní době se tedy ptám na projektovou zkušenost ve stylu:

"Mohl byste mi popsat Váš poslední, nebo poslední úspěšný projekt? Zajímají mě hlavně technické aspekty - mohl byste mi popsat a ideálně namalovat architekturu, či design vašeho vybraného projektu? Dále by mě zajímalo, jak byl projekt řízen, jaké role se na něm podílely a jaká byla Vaše role? Co třeba nějaké disciplíny SW inženýrství? Release management? Source code management? Issue tracking?"

Většinou se mi podaří kandidáta (přátelsky) přimět k namalování nějakého schématu na whiteboard. To má dva aspekty. Jednak se nad vizualizovanou architekturou/designem dobře diskutuje. A jednak poznáte, jak je na tom kandidát ohledně schopnosti vysvětlit technické věci, znalost modelování, uvědomění si "big picture", kontextu daného projektu a spoustu dalších věcí.

Ilustrační příklad whiteborard architektury

Java workshop

Když jsem pozměněnou podobu interview vymýšlel, chtěl jsem něco, co bude co nejblíž způsobu, jakým bych chtěl, abysme v týmu pracovali. Tedy: komunikovali spolu a uměli diskutovat nad kódem a designem. A samozřejmě... psali kód, ideálně s unit testy.

Začínám tím, že si s kandidátem sedneme vedle sebe a předložím mu - podle vybraného příkladu - následující obrázek (pro nadcházející odstavce, považujme za dané zadání návrhový vzor Observer):

Class diagram návrhového vzoru Observer

Zeptám se kandidáta, jestli zná UML a daný návrhový vzor. Pokud ano, tak ať jedno, druhé, či oboje vysvětlí. Pokud ne, řeknu nevadí a obojí vysvětlím já. Tahle část trvá krátce, většinou tak do pěti minut a jejím hlavním smyslem je porozumět zadání. A teď přijde to hlavní.

Otevřu notebook a... ukážu kandidátovi "skeleton" projektu natažený v IDE. Vypadá to nějak takhle:

Skeleton Java projektu v IDE

Jak je vidět na obrázku, i na UML diagramu výše, v projektu jsou dvě rozhraní a dvě implementační třídy. Ty konkrétní třídy "implementují" metody z interfaců, ale jsou prázdné. Čili, jde to zkompilovat, ale nic to nedělá.

Rozhraní a jeho prázdná implementace

Malá vsuvka, pokud vás to napadlo - v tom IDE to mám připravený v Eclipse a v IntelliJ IDEA. Dřív jsem to měl připravený i pro NetBeans, ale pak jsem to přestal udržovat - za ty čtyři roky mi na pohovor nepřišel nikdo, kdo by chtěl v NetBeansech dělat.

Zpátky k projektu. Kromě produkčního kódu jsou tam připravený - opět prázdný - třídy pro testy. Pokud by vás zajímalo, jak přesně ten startovní projekt v IDE vypadá, podívejte se na můj repositář na Bitbucketu: https://bitbucket.org/sw-samuraj/hiring/overview

Vysvětlím kandidátovi strukturu projektu a řeknu něco jako:

"Takže, tady máme prázdný projekt (pro návrhový vzor Observer) a zkusíme si ho naimplementovat. Pokud znáte, nebo jste dělal nějakou reálnou implementaci tohoto vzoru, můžete zkusit udělat ji. Anebo můžeme zkusit naimplementovat ten vzor jako takový, dejme tomu ukázkový příklad.

Záleží jen na Vás s čím začnete, jestli s implementací, nebo s testy a já jsem tady proto, abych Vám pomohl v případě problému. A v průběhu toho, jak budete psát, se Vás budu ptát na některé aspekty Vašeho kódu.

V projektu můžete cokoliv změnit, je zde jen jedno pravidlo - nesmíte nijak upravovat interfacy."

A je to. Kandidát začne psát, já se dívám, občas se na něco zeptám. Když se nám to zadrhne, jemně kandidáta navnadím, nebo popostrčím. Občas něco do kódu napíšu i já sám.

Každý kandidát je naprosto jiný. Někdo to celé vystřihne za půl hodiny i s pěknými unit testy. Někdo za stejnou dobu stačí vyrobit jednu metodu, která přidává prvky do kolekce. V průměru strávím touhle částí zhruba 40-50 minut.

A je to. Interview krátce zakončím a rozejdeme se.

Jak workshop vyhodnotit?

V momentě, kdy workshop skončí, už mám většinou jasno, jestli chci mít kandidáta v týmu, nebo ne. Někdy jsem na pochybách a je lepší se na to vyspat, nebo prodiskutovat s někým nezúčastněným.

Jinak vás asi zklamu - neprozradím vám žádné tajemství, jak z té cca hodiny programování udělat výsledek. Pro mne to byla dlouhá cesta, během které jsem mířil k jakémusi ideálu. Proto nepotřebuju nějaký checklist, abych věděl, jestli tam - s kandidátem - jsme, nebo ne.

Pokud vám minulý odstavec nedává smysl, nebo mu nerozumíte a přesto byste chtěli vědět, jak worshop vyhodnotit, zkuste se inspirovat těmihle aspekty:
  • Jak kandidát komunikuje? Během vysvětlování zadání a během programování.
  • Jak efektivně pracuje v IDE? (Na oblíbené IDE se ptám ještě před pohovorem, takže by to neměl být stresující faktor, že programuju v něčem nezvyklém.)
  • Jak hezky/čitelně/čistě/efektivně píše kód?
  • Jak designuje/strukturuje metody, třídy, testy?
  • Jak píše testy? Jestli vůbec. A kdy? Předtím, potom, zároveň?
  • Zajímají vás nějaké seniornější aspekty? Klidně se můžete ponořit do věcí, jako je specifická implementace některého Java API, nebo třeba do Reflection API (fakt, vyplyne to úplně přirozeně).
  • Chcete si ověřit znalost konkrétní verze Javy? 6, 7, 8? Žádný problém, jde to.
  • Jak kandidát komunikačně a znalostně reagoval na navržené alternativy?
Určitě vás napadne něco dalšího.

Co už nedělám

S odkazem na původní článek, bych vypíchnul věci, od kterých jsem upustil. V první řadě, už se nevrtám v CV. Ani před pohovorem, ani během. Životopis si většinou jen rychle proběhnu před phone screenem, jestli mě tam něco nezaujme - třeba jestli má kandidát zkušenost s (business) analýzou, architekturou, team leadingem apod. Prostě nějaký přesah za vývojařinu.

A potom, už nedávám hlavolam. I když tahle část bývala celkem zábavná, tak jsem ji odstranil - když jsem před těmi čtyřmi lety nově definoval, jak bych chtěl pohovor pojmout, zaměřil jsem se na to, aby to bylo co nejbližší denní realitě. A tam prostě vývojáři mechanické hlavolamy neřeší. (Čest výjimkám.)

Jak dál?

Pohovor tímto způsobem dělám poslední čtyři roky a musím přiznat, že po té době je to pro mne už příliš velká rutina. Chce to změnu. Zatím čekám na inspiraci. Je možné, že tenhle článek čtete v přelomovém období - takže jestli se někdy potkáme spolu na pohovoru, dost možná, že bude vypadat jinak.

No dobře, Java. Ale co .Net?

Z minulých dvou let mám zajímavou zkušenost. Poprvé v životě mě potkalo štěstí, že jsem se stal mentorem. Jako tím opravdovým, kdy se vztah mentor-mentee "samovolně", organicky vytvoří. Pikantní na tom je, že můj mentee není Javista... je to .Neťák!

No. Kromě jiného jsme spolu řešili také .Net pohovory. Z dnešního pohledu to vlastně nebylo nic těžkého - vzali jsme můj Java pohovor, vytvořili .Net workshop a bylo to.

Podstatné je, že to výborně fungovalo a dnes tak máme úspěšný nový .Net tým. Zkušenosti zkrátka občas přijdou ze strany, odkub byste to nečekali.

Předešlé díly


Související články

27. února 2017

Programátor -> Vývojář -> Software Engineer

Source: Wikipedia
Jak léta jdou, přemýšlím kontinuálně o cestě, kterou jsem urazil a kam směřuju. Jeden takový pohled na část takové cesty naznačuje titulek.

Dneska už jsem na té cestě dál - jsem v bodě, kdy už pár let "stavím" týmy. A byť nehledám lidi, kteří jsou mým odrazem - naopak, mám rád diverzitu a plánovaně, podvratně :-) ji aplikuju - podvědomě vybírám lidi, kteří na podobnou cestu aspirují a berou ji jako součást týmové kultury.

Téma je pro mě zajímavé - jak čistě myšlenkově, tak i prakticky. Pokud pracujete s týmy, tak kromě těch technických věcí, řešíte taky záležitosti jako rozvoj lidí, jejich vzrůstající finanční očekávání, ohodnocení jejich technické a jiné seniority atd.

Zároveň nebudu skrývat, že ne vždy se to podaří - přesvědčit, inspirovat lidi, že tohle je ta správná cesta. Občas vidíte potenciál, ale nepovede se vám dostat daného člověka z jeho bubliny. A někdy se prostě jen mýlíte a chybujete.

Korintským

Asociace, která mi naskočila, když jsem začal o tématu přemýšlet, pochází, možná překvapivě, z Bible - Pavlova listu Korintským. Je to taková ta pasáž, co se čte vždycky na svatbách... ale nebojte, nebudu vás zahrnovat láskou ;-) mám na mysli jinou větu:

Dokud jsem byl dítě, mluvil jsem jako dítě, myslel jsem jako dítě, měl jsem dětské názory; když jsem však dospěl, s dětinskými věcmi jsem se rozloučil.1. Korintským 13:11

Co mně přijde podstatné na tomhle citátu, je ten přechod - opuštění určité formativní fáze a přechod do další. A i když s tím občas bývají problémy, nejde o odvrhnutí předešlé fáze, naopak, ta by měla být integrována.

(A jen pro jistotu, protože vím, jak jsou lidi chytlavý - výběrem citátu jsem nechtěl říct, že – obecně – třeba programátoři jsou dětinští. Jasně, že občas jsou, ale není to generalizace. Ale což, ať si každý odnese, co potřebuje.)

Model

Jednoduchý model, který popisuje naše téma, vypadá jako tři soustředné kruhy. A tak jako cibule, krystal, či perla, rostou postupně schopnosti našeho hypotetického programátora.

Skill model

Programátor

Znáte termín code monkey? Je to většinou nelichotivý termín, i když občas se k němu někdo hrdě hlásí (většinou nápisem na tričku). Mě se líbí definice z Urban Dictionary, která dobře vystihuje, co si pod termínem programátor představuju já:

"A programmer who isn't actually involved in any aspect of conceptual or design work, but simply writes code to specifications given."

Programátor je pro mne člověk, který - s ohledem na svou senioritu - dobře rozumí úzce vymezené technické oblasti. Hranice je zpravidla definována daným programovacím jazykem a v dnešní době také stále více nějakým přidruženým frameworkem. Cokoliv za algoritmy, technickými aspekty jazyka a lokální kompilací (je-li potřeba), je mimo oblast zájmu a zodpovědnosti programátora - jeho práce končí komitem do verzovacího systému.

Taková úzce vymezená specializace nemusí být na škodu - záleží, jaká je vaše doména, role v týmu, rozsah projektu ad. Na druhou stranu, moderní softwarový vývoj vyžaduje daleko komplexnější spektrum schopností a mít v týmu "pouhého" programátora pak často znamená více zatížit ostatní členy týmu a  přenést na ně část činností, jež u programátora "padají pod stůl".

Vývojář

Vývojář je už o úroveň dál. Že dobře rozumí svému programovacímu jazyku, je samozřejmost. Stejně tak dobře ovladá sadu souvisejících knihoven a frameworků, jež tvoří jeho technickou doménu.

Jako velmi volný příklad si představme mlhavý termín Backend Developer. Umí asi nějakou "business logiku", řekněme v případě Javy někdo s CDI/EJB, nebo Spring+AOP+Transakce, plus nějakou tu persistenci, tudíž JPA/Hibernate/MyBatis/JDBC. A trošku té security.

Takže to je samozřejmost. Ale je to ještě něco navíc - větší, či menší povědomí, jak to spolu souvisí, nejen interně, ale i za hranice toho "backendu". Plus troška "toho designu" a zase - jak na úrovni kódu, tak na úrovni komponent.

No a pak... pozvolné přibližování se k oblasti SW inženýrství: vědět něco o buildování, možná i nějaký ten release management, něco praxe a teorie testování (aspoň unit a functional), source code management, issue tracking, atd.

To hlavní, co odděluje vývojáře od programátora? Schopnost vidět v technické oblasti "big picture".

Software Engineer

A co SW inženýr? Ovšem, je to dobrý vývojář. Ale ovládá také většinu souvisejících oblastí, potřebných pro kvalitní a moderní vývoj softwaru:

Ale v první řadě - a to už je moje velmi subjektivní spekulace - rozumí byznisově tomu, proč daný úkol dělá a proč ho dělá daným způsobem (což je, vzhledem k mé zkušenosti, velmi, velmi vzácné). Přece jenom, je to inženýr a jeho prvotním úkolem je řešit problémy. Reálné problémy.

Jediná cesta?

Na internetu a v knihách se vedou dlouhé diskuze, co je a co není SW inženýrství, ba, jestli vůbec něco jako SW inženýrství existuje. Moje zkušenost je, že na každém projektu je potřeba vždy a znova vybudovat terminologii. Význam a kontext konkrétního termínu se neustále proměňuje a podstatné je, abyste si s kolegy v týmu rozuměli.

Pro mne je software inženýr období a stav, kam jsem se dostal po téměř 20 letech programování. Šel jsem po výše naznačené cestě. Ta vaše bude zcela určitě jiná. O cestě, co jste urazili můžete vyprávět, ale zkušenosti jsou jenom vaše.

Je to realistické?

Samozřejmě, život není o zjednodušujících modelech a ideálních okolnostech. Skutečný svět je špinavý, divoký a ne-soustředný. V realitě tak vidíme spoustu prolínání vyše řečených rolí, jež se častokrát mění v čase i v rámci krátkého období, jako je třeba iterace, nebo projekt. A pak, existuje spoustu odlišností, jež nejsou výjimkami, ale spíše úplně jinými koncepty a přístupy. Diverzita života se mi vždycky líbila.

11. prosince 2016

Merge dvou tabulek v Pythonu

Aktuálně studuju na Coursera kurz Introduction to Data Science in Python a jak se to někdy hezky sejde, naskytla se mi v práci možnost to rovnou použít v praxi.

Rozhodně nejde o nic světoborného - prostě potřebuju dát dohromady dvě tabulky, trochu pošolichat data a udělat hierarchický index. Asi by to šlo udělat i v něčem jiném a možná jednodušeji. Ale Python mám rád a je to zábava si trochu zablbnout.

Následující zápisek je zdokumentování postupu, který by se mi mohl někdy v budoucnu hodit. Pokud jste někdo větší borec v Pythonu - tj. nepíšete v něm jen jednou za pár let, jako já - budu rád, když mi poradíte nějaké zlepšení.

O co jde?

Určitě jste se s tím už setkali. Máte určitý nástroj, od kterého byste čekali celkem jednoduchou funkcionalitu a on ji, z nějakého důvodu, nemá. Takže skončíte u exportu dat a nějaké externí úpravy.

To je náš výchozí bod - máme dvě vyexportované tabulky, formát souboru v tomhle případě nehraje roli. Může to být CSV, Excel atd. Ty naše dvě vypadají takhle:

Tabulka CSD.csv

Tabulka RQS.csv

Co je pro nás podstatné, obě tabulky mají vzájemnou vazbu přes sloupec "Related issues", který odkazuje na identifikátor záznamu v druhé tabulce (sloupec "#"). Co není na první pohled zřejmé, záznamy v tabulce CSD (zelené záhlaví) mají vazbu 1:N na záznamy v tabulce RQS (červené záhlaví). Pro úplnost, vazba je obousměrná, nás ale zajímá jen směr CSD -> RQS.

No a potřebovali bychom z toho dostat tabulku, která vypadá takto (barevné rozlišení je pro přehlednost, který data kam patřily):

Výsledná tabulka matrix.xlsx

Povšimněte si v prvních dvou sloupcích hierarchického indexu ("CSD ID", "RQS ID"), který vyjadřuje vazbu 1:N.

Jak na to?

To, kolem čeho se točí výše zmíněný kurz a co jsem pro manipulaci s tabulkami použil, je knihovna pandas - open source nástroj pro datové struktury a datovou analýzu. Na svých stránkách píšou, že je easy-to-use a opravdu se s tím pěkně pracuje.


Základním elementem v pandas je DataFrame, ekvivalent dvourozměrného pole (se spoustou vychytávek). První krok je, převést naše tabulky do DataFrame. pandas mají spoustu možností, jak načíst externí data, my použijeme metodu read_csv:
import pandas as pd

csd = pd.read_csv('CSD.csv')
rqs = pd.read_csv('RQS.csv')
Zpracovávaná tabulka může být rozsáhlá, co do počtu sloupců, a protože výpis DataFramu na konzoli se defaultně zalamuje, může se hodit příkaz pro vypnutí této možnosti:
pd.set_option('display.expand_frame_repr', False)
Data máme načtená, můžeme je začít upravovat. První na řadě je tabulka CSD. Potřebujeme udělat následující úpravy:
  • Rozdělit data ze sloupce "Subject" do dvou samostatných sloupců pomocí oddělovače " > ".
  • Smazat sloupce, které v cílové tabulce nepotřebujeme.
  • Přejmenovat sloupce, aby v cílové tabulce dávali větší smysl.
csd[['CSD ID', 'Contract chapter']] = csd['Subject'].str.split(
        ' > ', expand=True)
csd.drop(['Category', 'Subject',
    'Assigned To', 'Target version',
    'Release', 'Related issues'], axis=1, inplace=True)
csd = csd.rename(columns={'Status': 'CSD status'})
Navíc uděláme jednu operaci, kterou budeme potřebovat později - přidáme si nový sloupec "numeric ID", podle kterého cílovou tabulku později setřídíme.
csd['numeric ID'] = csd['CSD ID'].str.replace('-', '').map(int)
Obdobné úpravy uděláme na tabulce RQS a můžeme se pustit do spojování. pandas nabízejí metodu merge, která funguje obdobně jako SQL join.
matrix = csd.merge(rqs, left_on='#',
        right_on='Related issues', how='left')
Dalším krokem je vytvoření hierarchického indexu:
matrix.set_index(['CSD ID', 'RQS ID'], inplace=True)
Následně setřídíme novou tabulku podle sloupce "numeric ID", který jsme si dočasně přidali v rámci úprav tabulky CSD. Sloupec po setřídění odstraníme. Smyslem téhle eskapády je setřídit tabulku numericky podle sloupce, kde jsou string hodnoty.
matrix = matrix.sort_values(by='numeric ID')
matrix.drop('numeric ID', axis=1, inplace=True)
Teď si ještě seřadíme sloupce, abychom se v cílové tabulce dobře orientovali:
cols = ['Contract chapter', 'CSD status',
        'Redmine ID', 'RQS description',
        'RQS status', 'Related issues']
matrix = matrix[cols]
A pozor! Finální příkaz... zapíšeme do Excelu, resp. jiného výstupního formátu. Máme hotovo.
matrix.to_excel('matrix.xlsx')

Kompletní skript

Celý skript je k dispozici na Bitbucketu jako snippet: matrix.py.

Jak nainstalovat pandas?

Nejjednodušší způsob, jak nainstalovat pandas a další spřízněné knihovny (třeba NumPy a dokonce i samotný Python) je package manager Miniconda. Stačí stáhnout instalátor pro váš operační systém a pak nainstalovat pandas příkazem:
conda install pandas

30. listopadu 2016

GeeCON Prague 2016, den 2

Zúčastnil jsem se dvoudenní Java vývojářské konference GeeCON Prague. Možná se mýlím, protože nemám potřebný rozhled a informace, ale GeeCON mi přijde jako momentálně nejlepší Java konference v Praze - má mezinároní spíkry (všechny přednášky v angličtině), slušné renomé a odpovídající podporu sponzorů.

Pokud máte tip na jinou Java/vývojářskou konferenci (obdobného rozsahu), dejte mi vědět v komentářích, ať vím, kam vyrazit příští rok.

Pátek

O prvním dni konference jsem se rozepsal v článku GeeCON Prague 2016, den 1. Dnes budu pokračovat druhým, pátečním dnem, který se mi celkově líbil víc. Což může být subjektivní - mě udělaly radost dvě výborné přednášky o Clojure, z nichž jedna pro mne byla vrcholem celého GeeCONu.

A kromě Clojure zde byla také výborná přednáška o Microservices a pokračování tématu Graal/Truffle.

How to Bake Reactive Behavior into Your Java EE Application

Přednáška Ondreje Mihályi (@OMihalyi) o reaktivním programování (RP) mne moc neoslovila, i když nebyla špatná. Přiznám se, poslední dva tři roky jsem nesledoval aktuální trendy, takže jsem možná vedle, ale tyhle rective* záležitosti mi přijdou jako momentální hype.

V úvodu přednášky mi chybělo nějaké "zorientování se" pro ty z nás, co nejsme v reactive doma. Uvítal bych nějaké diagramy, který daný design osvětlí. A naopak bych oželel "programování ve slidech" (powerpoint programming).

Jinak měl Ondrej rozumný přístup - používat RP tam, kde to má smysl a pomocí refactoringu ho aplikovat na stávající design. Toho se týkalo také demo: na počátku byla aplikace (tuším nějaké vyhledávání letů) napsaná v JSF a JAX-RS, v níž se sekvenčně, ve vláčku, volali tři webové služby.

Během refactoringu došlo na zapojení WebSocketů a Event Busu v Payara Micro. S tou Payarou jsem to moc nepobral - zrovna tady bych ocenil nějaký komponent diagram. Odnáším si z toho, že Payara tam byla hlavně kvůli CDI Event Busu. Pokud to tak bylo, tak v realitě by stálo za to tam mít něco event-minimalistic, případně použít služby aplikačního serveru (pokud je poskytuje).

One VM to Rule Them All

Přednáška Jakuba Podlešáka (@japod) a Jana Štoly pokračovala v tématu čtvrteční key note - Graal VM a Truffle. Pánové to měli sladěný nejen tematicky, ale i outfitem, zkrátka bylo hned jasný, kdo dělá v Oracle Labs:

Obsahově byla přednáška zajímavá, ale pro mne ne moc záživná - přece jenom, kompilery a podobná havěť byly pro mne na škole jen nutné zlo. Takže byť stromy jsou velmi zajímavá algoritmická struktura, tak vytváření a manipulace AST velká zabava není.

Kluci se v prezentaci střídali, což trochu rozbilo plynulost a soudržnost. Začali prezentací Graalu a tím, jak rychle v něm běží jazyk R. Zkrátka R jako Rychle :-) Pak bylo něco o symbióze R a JavaScriptu (import funkce z jednoho jazyka do druhého).

A pak přišlo to AST... teda Truffle. Přiznám se, že po těch pár týdnech se mi toho už dost vykouřilo z hlavy a to i když se dívám do mind mapy (viz níže), kterou jsem si psal. Takže v krátkosti, viděli jsme jak napomoci parsování pomocí anotace @Specializaction a parametru guards. Pak tam bylo taky něco o optimalizaci a partial evaluation. No, a víc už vám k tomu neřeknu.

Thirty Months of Microservices. Stairway to Heaven or Highway to Hell?

Jednoznačně největší show celého GeeCONu. Holanďan Sander Hoogendoorn (@aahoogendoorn) to umí pořádně rozjet! Už jenom to, že jako cizinec je schopný do své prezentace naprat několik (smysluplných) slidů z A je to!

Sander začal obligátním "monoliths are bad", aby pak pokračoval bojovými zkušenosti z implementace microservis. V jedné větě by se jeho příspěvek dal shrnout: "microservices are not easy".

Sanderovi zkušenosti se  dají shrnout do následujících bodů:
  • Microservices require evolutionary architecture.
  • Start with guiding principles - implement business process, avoid transactions, components own their own data/storage.
  • RESTfulness is not easy - Postel's Law, have conventions (e.g. URI).
  • Testing - everything, fail quickly, automation, contract testing (JBehave).
  • DevOps is not easy - Infractructure as Code.

Hlavní poselství přednášky? Tak samozřejmě rozumné "microservices are not for everyone". Rozumné proto, že cca poslední 3 roky se s microservices roztrhl pytel - prostě klasický hype (naštěstí už to opadá) - a opět to není žádná silver bullet.

TDD: That's not What We Meant

Zklamáním pro mne bylo vystoupení Steva Freemana (@sf105). Steva mám zapsaného jako spoluautora frameworku jMock, bohužel, dnes už mrtvého, který jsem měl hodně rád (verzi 2). A také jako spoluautora oceňované knihy Growing Object-Oriented Software Guided by Tests. Takže jsem čekal hodně.

Steve byl jeden z mála nativních anglických speakerů (je z Londýna) a jak to tak někdy bývá, nebylo mu vůbec rozumět. Mám na akcenty docela ucho, ale řeknu vám, zlatý irský, nebo skotský akcent :-)

Zklamaný jsem byl hlavně proto, že Stevova přednáška byla nudná, unylá. A přitom tam bylo pár skrytých rubínů a smaragdů. Třeba o profláknuté slavné knize Kenta Becka Test Driven Development:

"It's worth re-reading. Nothing much there for the 1st read. But, so much there... after couple of years!"

Steve hodně kritizoval praktiku, kdy se testy dělají jen na oko - "Look, we have tests!". Nazýval to "Test-Driven Theatre".

Nejvíc se mi líbil tenhle slide:


Doing Data Science with Clojure: the Ugly, the Sad, the Joyful

Přednáška Simona Belaka (@sbelak) pro mne byla příjemným překvapením. Prezentaci jsem si vybral hlavně proto, že mám pro Clojure slabost (i když ho už pár let zanedbávám).

Simon mluvil o Clojure hlavně ve vztahu k Data Science. Proč je Clojure v této doméně ideální jazyk? V Data Science jsou různé oblasti, požadavky a většina používaných jazyků je řeší jenom částečně.

Infrastruktura se dá dobře řešit v Pythonu, nebo ve Scale. Modelování zase v R, nebo (opět) v Pythonu. Pak tu máme čištění a přípravu dat. A nakonec - a zde Clojure exceluje - manipulace se strukturou. A Clojure pokrývá všechny tyto aspekty. No a samozřejmostí (u všech jmenovaných jazyků), je Live Programming, které poskytuje REPL.

Dalším silným argumentem pro použití Clojure v Data Science je horká novinka: clojure.spec. Upřímně, neřeknu vám, co to je - budu si to muset pořádně nastudovat. Podle Simona se to dá použít na "dotazovatelný popis dat" (queryable data descriptions) a ve spojení s Apache Kafkou (distributed streaming platform) je to husto-krutý. Opět nevím, o čem píšu, je to na mne moc raketová věda. Teda datová.

Na závěr byly dvě zajímavé otázky z publika. Zaprvé, jak je na tom Clojure s unit testy. Odpověď - Clojure není TDD-oriented. Což mimochodem říkal už tvůrce jazyka Rich Hickey, který daleko radši debugguje. Mnohem vhodnější je spec.

Druhá otázka se týkala toho, jak se naučit Clojure. Odpověď mi přišla brilantní - na Clojure se dá dívat jako na funkce v Excelu. Takže v prvním kroku si zkusit problém "naimplementovat", či ukázat v Excelu a pak totéž jako funkci v Clojure. Jednoduché, geniální.

Clojure, clojure.spec and Beyond

Pozor, famfára, tum tu du dú!! A cena za nejlepší přednášku jde za Carin Meier (@gigasquid). Za mne jednoznačně a bez diskuze. Moc pěkně provedená, moc pěkně přednesená a zatraceně zajímavá.

Carin je autorkou knihy Living Clojure, dle svých slov píše v Clojure na denní bázi a Clojure v jejím podání je ten nejvíc cool a sexy jazyk, na který letos narazíte... víc cool & sexy už je jen clojure.spec. Ehm, použil jsem právě v jedné větě 4x slovo Clojure?!?

No, dost chvály. O čem že byla ta přednáška? Carin si vzala za základ dětskou knížku Doktora Seusse One Fish Two Fish Red Fish Blue Fish a pomocí clojure.spec se jala čarovat. Programy jako stvoření, která se geneticky vyvíjejí.

Kdo někdy trochu přičichnul k Lispu a podobné havěti, ví, že code is data and data is code. To není nic nového, ale clojure.spec to posouvá na úplně jinou úroveň - můžete si generovat specifikace, které vám generují data, která mohou generovat další specifikace, přitom se modifikují a generují...

A Carin to krásně umí podat. Část její přednášky si můžete přečíst na jejím blogu: One Fish Spec Fish.

Asi jste si všimli, že v popisu téhle přednášky dost bruslím. Je to tak. I když se podíváte do mind mapy níže, uvidíte, že jsem si toho moc nezapsal. Ze dvou důvodů. Už jsem říkal, že to byla nejlepší přednáška? Bylo by prostě škoda si u toho dělat zápisky. A pak, bylo tam toho tolik, že je to výživné ještě na měsíce studia. O teď mě omluvte - jdu generovat testovací data, která se rýmují. (Mimochodem, všimli jste si, že two se rýmuje s blue?)

New Java Literals for the Brave and True

Na přednášku Lukáše Křečana (@lukas_krecan) jsem dorazil pozdě, vlastně až cca v druhé půlce, protože jsem se v předsálí zakecal s Carin Meier o clojure.spec.

Takže jestli jsem to ze závěru pochopil, šlo o to, mít v Javě literály podobně jako ve Scale a Lukáš k tomu zneužil Javovské lambdy.

Budu teď trochu ošklivý, nebo upřímný - šel jsem se na přednášku podívat, abych viděl Lukáše na živo. Protože - ruku na srdce - Scala je mi dost ukradená.

Dirty Hacks with Java Reflection

Závěrečná key note Heinze Kabutze (@heinzkabutz) mě minula. Možná to byla únava, po dvou dnech intenzivního vstřebávání informací, možná přeplněná mozková kapacita, anebo, po vrcholné přednášce Carin Meyer, už nic nemohlo být zajímavé. Zkoušel jsem to, ale po 10 minutách jsem sjížděl Twitter a pak jsem se, ještě před půlkou, sbalil a šel domů.

To málo, co jsem v úvodu zachytil, byly klíčový slova Reflection, Java 9, Atomic a Concurrent.

Organizace

Tak, to byly přednášky. Nejen ty ale tvoří konferenci. Co organizace? Byl to můj první GeeCON a tak nemám s čím srovnávat. Jasně, srovnávat třeba s Google Developer Day by nebylo fér.

V první řadě musím vyzdvihnout lidi z GeeCON, že se do toho vůbec pouští. Na téhle fan bázi, kdy za váma nestojí velká firma, to musí být velmi náročné, postavené na spoustě entuziasmu. I proto jsem tolerantnější.

Organizaci přednášek se v podstatě nedá nic vytknout. Technika fungovala, časový rozvrh klapal a to je hlavní. Android aplikace s programem konference fungovala uspokojivě. Dostal jsem zadarmo jednu el. knížku od O'Reilly.

Pak už to byly více méně drobnosti - třeba hostesky by mohly znát heslo na WiFi, anebo tak nezmatkovat (a lépe informovat) s konferenčním tričkem.

Jednu velkou výhradu bych ale měl... catering. Koláčky ke svačině a džusy dobrý. Obědy docela slabota - dalo se to, ale hodně lidí nedojídalo. Ale kafe? To byl průšvih! Java konference a mizerný kafe?!? Do zákulisí samozřejmě nevidím. Co ale příště domluvit sponzoring s Doubleshotem?

Shrnutí

GeeCON je opravdu dobrá Java konference. Přednášky jsou zajímavé a aktuální. Rozsah je tak akorát a ambice odpovídají Praze. Pokud během roku nenarazím na něco zajímavějšího, rád se na GeeCON podívám znovu.

Mind Map

GeeCON Prague 2016 - Key Note, organizace a témata

GeeCON Prague 2016, den 2.

Související články

31. října 2016

GeeCON Prague 2016, den 1

Letos jsem to nevychytal co se týče školení - prostě jsem to úplně vypustil - a tak jsem si řekl, že se aspoň trochu zahojím na nějaké konferenci. A protože jsem už pár let po očku sledoval GeeCON, resp. jeho pražskou odnož, padla volba na něj.

A vybalím to na vás hned na začátku: Je to dobrá konference, stojí za to, na ni jít. Určitě mají (kluci polský) ještě co zlepšovat. Ale celkově je to přínosný - ať chcete držet prst na tepu doby (= bleeding edge), mít všeobecný přehled, co se v doméně děje, anebo najít inspiraci - to vše tady najdete v rozumně vyvážené symbióze.

Keynote

Keynote byly dvě - první sponzorská, do počtu, naštěstí jen 20minutovka a druhá, která se pro mne stala vrcholem dne.

Next Gen R&D: craft vs. chop-shop

Keynote Ondřeje Krajíčka (@OndrejKrajicek) ze sponzorujícího Y Softu byla krátká a... neinspirativní. Úplně jsem nepochopil souvislost mezi názvem a obsahem přednášky - možná v obsahu bylo něco o R&D, ale asi mi to uniklo. V podstatě šlo o to, že jako vývojáři jsme zároveň vědci, umělci i řemeslníci (scientists, artists/artisans, craftsmen) a že učednictví, jako způsob výuky, je s námi spousty (stovky) let.

Become a Polyglot by learning Java!

Keynote Jaroslava Tulacha (@JaroslavTulach) nejlépe shrnuje následující tweet:

Nadšení bylo na místě, takhle má prostě vypadat správná key note - nemusíte se nutně posadit na zadek, ale nějaký wov! moment by tam měl být. A to se tady podařilo.

Během 50 minut, představil Jaroslav dvě věci: Graal VM a Truffle. Graal je nová virtuální mašina, která se integruje s HotSpotem (prý stačí jen na classpath "upustit" Graal JAR), která umožňuje běh různých jazyků - JVM i ne-JVM (resp. ne jejich JVM, ale nativní implementaci), třeba JavaScript a Ruby.

Toho se týkala i všechna tři dema. V prvním šlo o zavolání Ruby metody z JavaScriptu (nebo naopak?). Druhé demo ukazovalo jakýsi cross-debugging: prostě debugguju, debugguju, jsem v Ruby, ještě chvilku debugguju a jsem v JavaScriptu. A vidím šechno, proměnný atd. Cool, hustý, hustokrutý. Třetí demo jsem myšlenkově trochu vypustil, ale myslím že šlo o Node.js.

Jestli jsem to správně pochopil, tak Truffle je nástroj na psaní vlastních jazyků, který pak můžou běžet v Graalu a rovnou mají dobrou performance. Co dobrou, jsou rychlý jak sviňa. To byla taky jedna z věcí, kterou Jaroslav předváděl/říkal - že Graal VM má lepší performance, než HotSpot (v případě Javy), nabo nativní implementace Ruby. Ukazoval to na prográmku, který implementoval Eratosthenovo síto.

Věc, která mě zaujala, když Jaroslav zmiňoval problematiku JVM a dynamických jazyků: vývojáři zaměřený na aplikace (např. NetBeans) preferují staticky typované jazyky. Naopak vývojáři zaměřený na data (např. astronomové) preferují dynamické jazyky. Na tom by něco být mohlo (i když pro mě to neplatí - vzdycky jsem dělal aplikace, a začínal jsem na dynamických jazycích, takže (ne)existenci typů neřeším).

Čtvrtek

Celkově hodnoceno, první den GeeCONu byl slabší, než ten následující - vyjma Graal/Truffle key note a přednášky o graph DB, šlo o průměrné přednášky. Ne nezajímavé a určitě ne ztráta času, ale přeci jen... slabší.

Who's Afraid of Graphs?

Přednáška Davida Ostrovskyho (@DavidOstrovsky) o grafových databázích pro mne byla toho dne nejzajímavější a nejpřínosnější. David je určitě velký fanoušek filmu Spaceballs, jímž vydatně špikoval demo, a filmů Mela Brookse. A taky se podílí na vývoji Couchbase, což je dokumentová NoSQL databáze. Nicméně tentokrát hovořil o "konkurenci".

Zajímavá byla hned úvodní myšlenka - NoSQL databáze jsou s námi cca 10 let. Relační DB zhruba 40 let. Ale grafy jsou s náma minimálně 300 let. Mimo jiné zmiňoval matematický problém Seven Bridges of Königsberg, kterým se zabýval Euler v 18. století.

David zmiňoval use casy pro využítí grafových databází a zároveň uvedl a hned zavrhl nejčastější případ - sociální sítě. K tomu hned za chvíli. Dalšími příklady užití jsou authorizace a herní ekonomiky (game economies). A obecně případy, kdy jde použít "statické dotazy".

Proč nepoužívat grafové databáze pro sociální sítě? Protože neškálují. Doslova "graphs don't scale". Procházet celý graf pro každý dotaz? To asi Facebook nedělá. Co s tím? David doporučoval dvě věci: Za prvé sharding. Sice to pořád neškáluje, ale je to lepší než nic. A za druhé, rozdělit data - mít grafová data v grafové databázi (např. Neo4j) a zbývající data v relační databázi (např. MySQL).

Velkou část přednášky věnoval David praktickým ukázkám několika grafových databází. Začal tou nejpopulárnější, Neo4j a jejím dotazovacím jazykem Cypher. Cypher má specifickou notaci, kdy používá ASCII art pro reprezentaci patternů. Pro koho je Cypher moc exotický, může zkusit OrientDB, která používá SQL-like dotazování.

Problematiku dotazování řeší také další nástroj: Gremlin, jazyk pro traversální dotazování grafů. Gremlin není svázaný s konkrétní databázovou implementací, ale pomocí blueprintů se může dotazovat nad libovolnou grafovou databází. Blueprint je analogie JDBC pro grafové databáze.

Poslední ukázka se týkala Elasticsearch, kdy David ukazoval live Twitter analýzu (Hillary vs. Trump). Bylo to na mě hodně rychlé a efektní. Co mě zaujalo, možnost vytvářet virtuální grafy on-the-fly, podle momentální potřeby, tedy bez toho, aby dané vazby v datech existovaly.

Ten Productivity Tips for Java EE and Spring Developers

U přednášky Simona Maplea (@sjmaple) ze ZeroTurnaround nepřekvapilo, že na závěr zpropagoval dva jejich nástroje, nicméně nebylo to nijak násilné a do konceptu to zapadalo.

Ohledně produktivity zmiňoval tři oblasti: komunikaci, správu tasků a nástroje. Komunikaci věnoval Simon minimum prostoru. V podstatě řekl, že komunikace je klíčová, mnohem náročnější, pokud je vzdálená (remote) a dobrým nástrojem pro distribuovanou komunikaci je Slack. Myslím si, že v reálném životě má největší přínos pro produktivitu právě komunikace, ale chápu, že se to na vývojářské konferenci špatně prezentuje.

Doporučení ohledně správy tasků je přímočaré:
  • Optimizing current tasks
  • Removing non-essential tasks
  • Retaining positive (process, activities, tools etc.)

Nejvíce prostoru věnoval Simon nástrojům a z nich nejvíce JBoss Forge. Tenhle nástroj mě zatím zcela míjel, takže jestli jsem to správně pochopil, jde o JBossí odpověď na scafolding. No, řekl bych, že v dnešní době celkem passé. Co mě trochu zarazilo - vzhledem k zaměření přednášky - že Simon v demu preferoval Maven před Gradlem. Buď si tu ukázku ulehčil, nebo tak trochu ztrácí na kredibilitě.

Další nástroje zahrnovaly Arquillian (JUnit-like testování v kontejneru), TomEE (Java EE extension/profil pro Tomcat), Spring Boot (RAD(?) ve Springu) a konečně v úvodu zmiňovaný JRebel a XRebel. Výčet sice hezký, ale asi nic, co by seniorního vývojáře překvapilo. Osobně mě to neinspirovalo si ani jeden nástroj vyzkoušet.

Shrnutí Simonovy přednášky znělo:
  • Care about your time
  • Don't lose sight of your goal
  • Explore productivity tools

Apache Cassandra: building a production app on an eventually-consistent DB

Oliver Lockwood se na úvod zeptal, kdo sleduje fotbal. A kdo sleduje Premier League. Oliver pracuje pro televizi Sky, která je držitelem licence na vysílání Premier League. Jak to spolu souvisí? Sky používá pro persistenci jejich Online Video platformy databázi Apache Cassandra.

Cassandra je NoSQL distribuovaná databáze pro správu velkých dat. Z úvodu si pamatuju, že jeden node (náhodně vybraný loadbalancerem) je pro daný příkaz řídící pro zbytek clusteru. Pro databázi se definuje replication factor, tj. kolik kopií záznamu chci mít na jednotlivých nodech. A že při synchronizaci vyhrává poslední zápis (last write wins).

K čemu není Cassandra dobrá? Pokud potřebujete komplexní dotazy, nebo něco jako RDBMS transakce. A co může být na Cassandře problematické? Synchronizace času mezi jednotlivými nody. Co s tím? Buď používat synchronizační timestamp na straně klienta, nebo se "časově citlivým" (time-sensitive) dotazům vyhnout.

Poslední část přednášky byla o rozvoji DB schématu. Ve Sky si na to napsali vlastní nástoj cqlmigrate, dostupný na GitHubu. Nástroj napomáhá automatizaci, může provádět přírůstkové změny na jednotlivých nodech.

Machine Learning by Example

Pro mne nejslabší přednáška tohoto dne. Téma prezentované Michałem Matłokou (@mmatloka) bylo sice zajímavý, ale asi nešťastně zpracovaný. Předně, věnoval příliš mnoho času úvodu do tématiky, což nejspíš bylo zbytečný - každý, kdo měl aspoň trochu podobný předmět na škole (u nás se to jmenovalo "Expertní systémy") se asi trochu nudil.

Takže use casy - rozpoznání hlasu, detekce obličeje, analýza podvodů (fraud analysis), self-driving cars. Typy učení - supervised, unsupervised, semo-supervised a reinforcement learning. A citát z Alana Turinga.

A pak, bez nějakého přechodu, skok rovnou do dema, kdy jsem nepochopil, co se děje. Ukázka byla založená na použití nástrojů Apache Spark a Zeppelin, ale neptejte se mě, jak spolu souvisí. Demo bylo dlouhé a já jsem se v prvních 5 minutách ztratil, takže jsem zbytek přednášky protweetoval.

Definition of Done: Working Software in Production

Poslední čtvrteční prezentace (kterou jsem absolvoval) od Thomase Sundberga (@thomassundberg), byla přesně ten typ přednášky, který nesnáším:
  1. Vyberete si podle anotace,
  2. Přenáška začne
  3. Cca v půlce si říkáte, o čem to vlastně je,
  4. Podíváte se znovu (stále během přednášky) do anotace, abyste si připomněli, na co jste to šli
  5. a cca 5 minut po přednášce vám dojde, jak spolu souvisí titul a obsah.
  6. Jenže tu není žádný aha! moment, protože nic tak nového jste se nedozvěděli.

A přitom to vlastně tak špatná přednáška nebyla. Takže o co šlo? Continuous Delivery. A co že je tím DoD? Váš software v produkci. A teď, jak na to:
  • Převezměte kontrolu nad buildem - musí být triviální spustit build lokálně jedním příkazem.
  • Všechno verzujte - tady se to trochu rozjíždělo s tím, že dávali na produkci SNAPSHOTY (už se nepamatuju proč).
  • Automatizujte testování.
  • Procvičujte (practice) - prvně v testu, pak na produkci.
  • Perfect is not a place, it is a direction.
  • A hlavně: Začněte s málem a vydržte. Každé zlepšení se počítá.

No a pak vám s tím, samozřejmě, pomůžou nástroje. V Thomasově případě to byly: Git, Jenkins, Puppet, Gradle, RPM a JFrog.

Pátek

Vzhledem k tomu, že jsem se slušně rozepsal, rozlomil jsem článek ve dví. Mé dojmy z pátečního GeeCONu si můžete přečíst na odkazu GeeCON Prague 2016, den 2. (strpeníčko... dejte mi trochu času to napsat ;-)

Mind Map

GeeCON Prague 2016 - Key Note, organizace a témata

GeeCON Prague 2016, den 1.

Související články

4. října 2016

Software Engineering, má rozumné paralely?

Konstantou Software Engineeringu (SE) je jeho dynamika. Snad právě proto hledáme paralely a podobenství v jiných oblastech lidské činnosti - abychom lépe porozuměli jeho zákonitostem, uchopili jeho abstraktní nehmotnost a někdy ;-)  i jen našli pevnou půdu pod nohoma.

Nejčastějšími doménami, kam se sahá pro inspiraci a popis jsou: "klasická" architektura a stavebnictví (stavíme sofware), strojní výroba (vyrábíme software) a automobilový průmysl (procesní a automatizovaná výroba od designu po prodej). Tyto paralely jsou hodnotné, protože umožňují průmět, projekci něčeho obecně známého do něčeho, o čem někdy tušíme pouze fuzzy obrysy.

Auta, domy, nebo továrny?

Tak jak jsou tyto paralely přínosné, tak jsou zároveň zavádějící. Což není nijak překvapivé - architektura má za sebou tisíce let vývoje. První automobil vznikl někdy v 19. století. Pokud bychom tedy chtěli srovnávat softwarový vývoj s automobilovým průmyslem, bylo by adekvátnější, kdybychom to dělali s fází, kdy ještě nebyl průmyslem. Tedy v dobách, kdy byly zhruba jasné požadavky, ale každý je implementoval po svém.

Automobil Benz z r. 1885 (zdroj Wikepedia)

Tehdy ještě nebyla žádná standardizace. Postupně vznikala unifikace, normy, automatizace, globalizace. Tyhle tendence lze také vysledovat i v oblasti SE. Ale pořád to každý dělá tak nějak po svém.

Pokud máme k dispozici standardizované komponenty (třeba cihly), lze z nich skládat komplexní řešení. Ale nejen to - dá se také přesně spočítat (s rozumnou odchylkou) koncová cena, v návrhu se dají zohlednit jejich fyzické vlastnosti (např. stabilita cílového řešení) atd. Tohle všecno v SE chybí.

Marnost, samá marnost

Lidé z byznysu už dlouhá léta sní o tom, jak se bude software skládat z jednotlivých "krabiček" (= komponent), ale kromě marketérů, kteří se snaží taková řešení prodat, nejspíš nikdo nevěří tomu, že by to fungovalo.

Z mojí zkušenosti se nejdál v tomto směru dostaly nástroje a systémy z oblasti SOA (a nijak překvapivě, hlavně ty komerční). Do určíté úrovně (abstrakce, či návrhu) lze řešení vytvářet "taháním kostiček a šipek". Ovšem od této hranice níž nastává, námi vývojáři běžně zažívaná, realita - ty "kostičky" je potřeba naimplementovat a to už jsme na poli klasického softwarového vývoje.

Kompozitní aplikace v Oracle SOA Suite (zdroj Oracle)

Samozřejmě, hodně by zde pomohla znovupoužitelnost. Ale ruku na srdce - už jste někdy viděli, že by reusabilita fungovala na úrovni komponent? Já teda moc ne. Obvykle bývá problém v governance - dozvíte se, že to není pořeba, není to ve scopu projektu, verzování je zbytečná práce navíc, řešení (zpětné) kompatibility je moc náročné atd. Takže řekněme, že... znovupoužitelnost je hezký, ale teoretický koncept. Zatím. Oni se to lidi časem naučí. Tak jako se naučili stavět domy a auta.

Jiným problémem SE je, že se nezabývá jednou (byť třeba rozsáhlou) doménou, jako třeba stavebnictví, ale zasahuje v podstatě do jakékoliv oblasti. V takovém prostředí se pak velmi těžko extrahují nějaké principy, o které se lze opřít v příštích projektech. Proč asi agilní vývoj neslibuje nic konkrétního, ale spíš něco ve stylu "bude to kvalitní, budeme to neustále zlepšovat, ale nevíme přesně, co to nakonec bude" :-)

Vanitas vanitatum. Byť se někteří z nás věnují SE celý svůj produktivní život a pokud zůstanou zdravými programátory, tak snad i zbytek života; tak z hlediska pomíjivosti je SE stále ještě v dětských letech (ne-li v plenkách). Třeba se za sto let naši potomci a následovníci ohlédnou zpět a budou nás litovat, v jakých krutých a nestabilních podmínkách jsme budovali svá díla. A po dalších staletích, až vznikne nové vědecké odvětví - softwarová archeologie - budou vzdálené generace stát v úžasu nad tím, co jsme dokázali vytvořit holýma rukama. (Anebo taky ne.)

Má to smysl?

Pokud se kruhem vrátím zpátky na začátek - má smysl hledat pro SE nějaké paralely? Myslím si, že ano. Pomůžou s porozumněním komplexních řešení a problémů, na které lidská mysl není designovaná. Ale je potřeba to brát s rezervou... software zkrátka nemá čtyři kola.

Související externí články

25. června 2015

Jak dělám Java pohovor III: phone screen

Technickému recruitingu se věnuji už nějaké čtyři roky. Je to činnost, která mě hodně baví a tak jako u jiných aspektů své práce, jsem si vypěstoval určitý postup. Zároveň se snažím věci pořád zlepšovat a korigovat, jak studiem, tak praxí.

Phone Screen

Jedna z věcí, ke kterým jsem došel a považuji ji za nutnost, je phone screen. Jediný případ, kdy ho nedělám, je buď že mám s daným člověkem přímou pracovní zkušenost, anebo jsme se předtím už osobně setkali - to se stává, pokud třeba někdo zareaguje na můj inzerát.

Poslední dobou si hodně čtu o agilním přístupu (i po těch letech se člověk pořád má co učit) a věc, která se mi stále vrací a furt si ji musím připomínat - každý mítink musí mít smysl. Fajn, jaký je tedy pro mne smysl phone screenu? Podívejme se, co stojí v soukromém samurajském slovníku:

Phone Screen: Je to první, krátký a efektivní kontakt s potencionálním kolegou, který zodpoví jedinou otázku - má smysl se osobně vidět a pokračovat ve vzájemném získávání informací?

Proč používám termín phone screen a ne třeba "telefonní pohovor"? Inu, to proto, že je to krátké a přesně to vystihuje svůj účel. Uznejte - "telefonní filtrování" zní blbě samo o sobě a poslat kandidátovi pozvánku s takovým předmětem by asi nebylo zrovna vstřícné. 

Struktura

Můj phone screen má vždy stejný začátek. Zavolám, představím se jménem a firmou a řeknu: "Tento phone screen by měl trvat 30 minut a projdeme si následující kroky:
  1. představím se já,
  2. představí se kandidát z hlediska technologií,
  3. technické otázky,
  4. kandidátovy otázky."
Pak si cca 30 minut povídáme, během té doby bedlivě sleduji čas, a po půl hodině rozhovor ukončím.

Pokud se podívám blíže na jednotlivé body:

Představím se já, tedy, znovu zopakuji svoje jméno, řeknu svoji formální pozici a krátce vysvětlím obsah své práce. Myslím si, že je to fér vůči kandidátovi - dát mu nějaký kontext, aby věděl, s kým asi tak mluví.

Představí se kandidát z hlediska technologií. Jediná informace, kterou o kandidátovi v tento moment mám, je zpravidla pouze jeho CV. Což je dost slabá a nevěrohodná informace. Požádám proto kandidáta, aby se mi představil z hlediska technologií. Zdůrazním, že mě nezajímá klasické "odříkávání" životopisu, stejně tak, jaký byl business význam projektů, nebo aplikací, na kterých se podílel. Co mě zajímá, je jeho současný technologicko-seniorní "snapshot".

Myslím, že je to celkem logické - nenajímám odborníka na nějakou business doménu, ani business analytika, ale vývojáře. Takže mě zajímají technologie, frameworky, architektura atd. Bohužel, lidé dost často tuto otázku ignorují a spustí naučený kolovrátek. Pokud se tak stane (pořád sleduju ten čas), vrátím je zpátky k původní otázce.

Technické otázky. Jedním z cílů předchozí části je zjistit kandidátovy silné technologické stránky. Říkám o sobě (ohledně pohovorů), že jsem hodný, ale spravedlivý. Takže se ho ptám na věci, o kterých říká, že je dobře zná. Samozřejmě, musím ty věci dobře znát i já. Ale vzhledem ke svému stáří a senioritě ;-) vždycky najdeme slušný průnik. Někdy se i kandidáta přímo zeptám: "Jaké jsou momentálně dvě Vaše nejsilnější technologie?".

No a pak začneme na povrchu, u triviálních a základních věcí a jdeme hloub a hloub, až se někde naše znalosti zastaví - narazíme na lokální minumum. Pokud se to stane, nebo se téma vyčerpá, nebo pokud přes veškerou snahu zůstaneme stále na hladině, přejdu k dalšímu (silnému) tématu.

Pro představu jak může tahle část vypadat, dejme tomu, kandidát říká, že dobře zná JPA, či Hibernate. Můžeme začít třeba otázkou "Na jakém principu tahle technologie funguje?", nebo "Jaký je vztah mezi JPA a Hibernate?".

Pak se podíváme na mapování pomocí metadat. Můžou to být otázky typu "Které dvě anotace/XML elementy jsou nezbytně nutné, aby framework mohl používat (POJO) třídu jako entitu?", či "Které anotace při mapování běžně používáte?". Podstatné je, že nevyžaduji přesné názvy, ale jestli kandidát rozumí o čem mluví a principům, na kterých to funguje.

A jdeme hlouběji - jaké mohou být vztahy mezi entitami, jaké jsou strategie pro získávání dat a která z nich je defaultní pro daný typ vztahu? Jak se řeší složené klíče? Na téhle úrovni složitosti často opustíme mapování entit a podíváme se na jiná zajímavá témata - přece jenom, děláme phone screen a času je málo.

Můžeme si popovídat třeba o EntityManageru, nebo o Session. Pokud nám to spolu klape, můžeme se dostat až k transakcím, nebo co to je PersistenceContext a PersistenceUnit. Někdy dokonce dojde i na lifecycle entit :-)

Ať už se dostaneme kamkoliv, je podstané, jak jsme si o tom popovídali. Už jsem zmiňoval, nejde mi o žádné odříkávání slovníkových dat a in-memory znalostí. Jde mi o porozumnění a rozsah, které by mělo odpovídat dané úrovni seniority. Jednotlivé otázky, jak úvodní, tak usměrňující vybírám intuitivně, nemám žádný mustr, podle kterého jedu.

Když se čas nachýlí, je prostor pro kandidátovy otázky. Kandidát mi věnoval cca 25 minut svého času a tak je fér mu otevřeně zodpovědět, co by ho zajímalo. Možná si říkáte, že 5 minut na otázky není moc, ale většinou to bohatě stačí - moje zkušenost je taková, že nadpoloviční většina lidí nemá žádné otázky, nebo tak jednu dvě. Pokud je někdo zvědavější a má otázek víc, i já mu (rád) věnuji víc času.

Zakončení

Jakmile jsou otázky za náma, zbývá říct už jen dvě věci - co bude následovat a rozloučení. Co následuje po rozhovoru? Za pomocí svých poznámek (viz dále) sepíšu jednoduché hodnocení s pozitivním, nebo negativním výsledkem, který se kandidát vzápětí dozví. Pozitivní skóre se rovná pozvání na osobní pohovor.

Jak si píšu poznámky

Když jsem s phone screeny začínal, psával jsem si poznámky přímo do vytištěného CV. Není to dobrý způsob - každé CV je jinak formátované, velikost bílých ploch na psaní je proměnlivá, je to neuspořádané atd. Jedinou výhodou je, že CV a poznámky jsou pohromadě.

Časem jsem ale zakomponoval lepší metodu - přímo během pohovoru si kreslím mind mapu. Stejnou metodu pak používám i u osobního pohovoru (Je to konzistentní a dobře se v tom hledá). Výhodou mind mapy je, že si daleko lépe připomenete, o čem jste si povídali. A taky to lépe vypadá. Navíc, mind mapa se mnou zůstane - zpracovaná CV vyhazuji, ale mind mapy si schovávám a archivuji.


Související články