29. srpna 2013

Gradle tutorial: tasky (pokračování)

V minulém díle Gradle tutorialu jsme si vystřihli rafinované Hello world a řekli jsme si něco o základním stavebním prvku každého build skriptu - Task, to je to, oč tu běží. A ruku na srdce, milý čtenáři, jistě jsi zvědavý, kam nás naše povídání zavede. Protože to zajímavé teprve přijde.

Závislosti mezi tasky

Tasky téměř nikdy nestojí samostatně. To není nic moc překvapivého. Známe to z Antu, známe to z Mavenu, bylo by divný, kdyby to Gradle dělal jinak. Když si například vezmeme klasický Maven build lifecycle, tak vypadá nějak takhle:
  1. zpracuj resources,
  2. zkompiluj třídy,
  3. zpracuj test-resources,
  4. zkompiluj třídy testů,
  5. spusť testy,
  6. vytvoř archiv,
  7. atd.
Tyto jednotlivé úkony (v Mavenu nazývané goals) na sebe logicky navazují a jsou na sobě implicitně závislé. Implicitně znamená, že nemusím závislost jednotlivých tasků (goals) explicitně uvádět - Maven "už to nějak ví", jak si ty tasky má seřadit. Magie? Ne, "někdo" mu to řekl.

Podobné je to i v Gradlu. Některé tasky už mají závislosti definované, většinou je to v rámci nějakého pluginu. Třeba u Java pluginu (o kterém si budeme povídat v příště) vytváří závislosti cyklus, který je velmi podobný tomu Mavenímu. Velkou výhodou Gradlu je, že závislosti mezi tasky se definují velmi jednoduše a navíc nad nimi máme programovou kontrolu.

Závislost tasku se dá definovat buď pomocí property nebo metody dependsOn. Způsob zápisu se může podobat tomu, který známe z Antu, čili přímo při definici tasku:
task first << { task ->
    println "  Working on the ${task.name} task"
}

task second(dependsOn: first) << { task ->
    println "  Working on the ${task.name} task"
}
Anebo můžeme využít nespoutanosti Groovy a závislost definovat v podstatě na libovolném místě:
task third << { task ->
    println "  Working on the ${task.name} task"
}

third.dependsOn second 
Vzhledem k tomu, že zde máme závislost tasků third -> second -> first, výstup by při spuštění tasku third měl vypadat následovně:

Závislost tasků

Zajímovou možností je definovat závislosti tasku dynamicky. Vstupem do metody dependsOn totiž může být closure, jedinou podmínkou je, aby vracela objekt typu Task, nebo kolekci Tasků.
task fourth << { task ->
    println "  Working on the ${task.name} task"
}

fourth.dependsOn {
    tasks.findAll { task -> task.group.equals('sequence') }
}
V uvedeném výpisu je task fourth závislý na všech tascích projektu, které jsou seskupeny pomocí vlastnosti group.

Zdrojový kód na Bitbucketu: 02_TaskDependencies/build.gradle

Přeskočení tasku

Ať už jste agilní vývojáři, kteří milují dynamické prostředí, nebo jste naopak vyznavači petrifikovaného zadání, jedno je jisté - chtěná, či nechtěná, stejně přijde nějaká změna. A tak, jakkoliv je náš pracovní lifecycle vymazlený, bude do něj potřeba zasáhnout. Někdy třeba jen dočasně.

Dynamická práce s tasky může být dost komplexní a vydala by na samostatný článek. My se v rámci tutorialu podíváme na část, která je k dispozici out-of-the-box a sice na způsoby, jak zajistit "nevykonání" naplánovoného tasku.

(Při psaní příkladů pro tuto část jsem měl rozvernou náladu, takže v této sekci bude naším průvodcem jeden z hrdinů mého dětství, klokan Skippy :-)

První ze způsobů, jak přeskočit task, je využití metody onlyIf, pro kterou můžeme definovat predikát. Akce v tasku (a tím pádem i task samotný) jsou vykonány pouze tehdy, pokud je predikát vyhodnocen jako true.
task skippy << {
    println 'I\'m happy, so I jump!'
}

skippy.onlyIf { project.isHappy == 'true' }
V tomto příkladu je task skippy vykonán pouze tehdy, pokud je projektová property isHappy nastavena na true. Pokud takovou property v build skriptu nemáme definovanou, nevadí - přidáme si ji z příkazové řádky pomocí přepínače -P, např. -PisHappy=true.

Přeskočení tasku pomocí metody onlyIf

Další možnost, jak nevykonat task, nebo jeho část, je vyhodit výjimku StopExecutionException. To způsobí, že je zastaveno vykonávání aktuálního tasku a je spuštěno vykonání toho následujícího. Tato výjimka přeruší pouze daný task, build pokračuje dál.
task exceptionalSkippy << {
    if (project.isHappy == 'false') {
        throw new StopExecutionException()
    }

    println 'I\'m happy, so I jump!'
}
Jak je vidět na následujícím výstupu, task exceptionalSkippy nebyl přeškočen (jako v předešlém příkladu), ale byl normálně spuštěn a pak byl někde "uvnitř" přerušen.

Přerušení tasku pomocí StopExecutionException

Třetí možností, jak rozhodnout o vykonání tasku je použití property enabled - task tak můžeme vypnout, nebo zapnout.

V následujícím příkladu máme dva tasky. Task disabledSkippy (který nám řekne, jestli Skippy bude skákat) závisí na tasku skippyMood (který nám oznámí Skippyho náladu). Task skippyMood má možnost vypnout task disabledSkippy.
task skippyMood << {
    if (project.isHappy == 'false') {
        disabledSkippy.enabled = false

        println 'I\'m not happy :-('
    } else {
        println 'I\'m happy :-)'
    }
}

task disabledSkippy << {
    println 'I\'m happy, so I jump!'
}

disabledSkippy.dependsOn skippyMood

Přeskočení tasku pomocí property enabled

Zdrojový kód na Bitbucketu: 03_SkipTask/build.gradle

Task rules, dynamické generování tasků

Už jsem párkrát naznačoval cosi o dynamičnosti Gradle, pojďmě se tedy podívat na něco konkrétního. Co kdybychom potřebovali větší množství tasků, které dělají v podstatě to samé, akorát se to "to" liší nějakými parametry. Můžeme takovou potřebu řešit pomocí principů objektového programování, třeba. kompozicí. To může být docela otrava, hlavně správa a přetestovávání takových tasků.

Co si takhle potřebné tasky nechat dynamicky vygenerovat? Právě od toho jsou tady task rules.
def environments = [
    'DEV': ['url': 'http://dev:8080'],
    'SIT': ['url': 'http://sit:9090'],
    'UAT': ['url': 'http://uat:7001']]

tasks.addRule('Pattern: deploy<ENV>') { taskName ->
    if (taskName.startsWith('deploy')) {
        task(taskName) << {
            def env = taskName - 'deploy'

            if (environments.containsKey(env)) {
                def url = environments[env].url

                println "Deploying to ${env} environment, url: ${url}"
            } else {
                println "Unsupported environment: ${env}"
            }
        }
    }
}

Příklad spuštění jednotlivých task rules

Vzhledem ke své povaze jsou task rules uvedeny v samostatné sekci při výpisu tasků pomocí příkazu gradle tasks:

Výpis pravidel (rules) příkazem gradle tasks

Zdrojový kód na Bitbucketu: 04_TaskRules/build.gradle

Asi v tom bude nějakej háček

Jedním z nejčastějších problémů u tasků, se kterým se můžeme zpočátku setkávat, je záměna konfigurace a definice tasku. Definici tasku už známe - používali jsme ji celou dobu. V rámci definice přidáváme do tasku jednotlivé akce, které jsou pak vykonány během exekutivní fáze. Jen pro připomenutí, akce můžeme do tasku přidat metodami doFirst a doLast a daleko nejčastěji se používá operátor << který je aliasem pro metodu doLast.

Konfigurace tasku slouží... ehm, ke konfiguraci tasku. Podstatné je, že konfigurace je vykonána v jiné fázi buildu. A proběhne pokaždé, i když zrovna daný task nespouštíme. Task lze nakonfigurovat několika způsoby, ten "problematický" má stejnou syntaxi jako definice tasku, pouze je bez << operátoru.
task foo {
    // some task configuration here
}
V následujícím výpisu task pitfall prvně "nakonfigurujeme" a následně do něj přidáme akci.
task pitfall { task ->
    println "Printed from task ${task.name} configuration."
}

pitfall << { task ->
    println "Printed from task ${task.name} execution."
}
Když se podíváme na spuštění tasku pitfall, všimněte si, kdy proběhl "konfigurační" výpis. Ještě před začátkem spuštění tasku (tedy před vykonáním obsažených akcí).

"Vizualizace" konfigurační a exekuční fáze tasku

Druhým častým problémem s tasky bývá následující chyba:
Cannot add task ':exists' as a task with that name already exists.
Což znamená, že se snažíme definovat task, který už je definován někde jinde. Problém bude buď v chybné syntaxi, anebo v praxi daleko častěji, pokud pracujeme s projektem, kde používáme plugin, který task stejného jména již obsahuje. Obdobou téhož je, když si do projektu natáhneme antovské tasky (jeden z budoucích dílů tutorialu) a opět, dané jméno tasku už je použito.

Pokud řešíme druhý případ (duplicitní název/definice tasku), můžeme task explicitně předefinovat. Nemusím zdůrazňovat, že bychom měli vědět co a proč to děláme. Pokud máme buildovací skripty plně v rukou, bude tento problém indikovat chybu v designu buildu. Ovšem v případě, že se potýkáme s nějakým legacy buildem (staré Ant build soubory), může být redefinice tasku nutností.

Task lze předefinovat pomocí property overwrite:
task exists << {
    println 'primary task definition'
}

task exists(overwrite: true) << {
    println 'overwritten task definition'
}

Redefinice tasku pomocí property overwrite

Zdrojový kód na Bitbucketu: 05_TaskPitfalls/build.gradle

Zdrojové kódy

Zdrojové kódy k dnešnímu dílu jsou k dispozici na Bitbucketu. Můžete si je tam buď probrouzdat, stáhnout jako ZIP archiv, anebo - pokud jste cool hakeři jako já :-) - naklonovat Mercurialem:
hg clone ssh://hg@bitbucket.org/sw-samuraj/gradle-tutorial

Co nás čeká příště

O tascích by se dalo povídat ještě dlouho. Ale protože jsem příznivcem hesla better is enemy of done, tasky dnešním dílem opouštíme a příště se podíváme, jak Gradle řeší Java vývoj.

Tento článek byl původně publikován na serveru Zdroják.

Související články


Související externí články

17. srpna 2013

Zdravý programátor

Pokud čtete alespoň polovinu odborných knih, toho co já, asi vám nebude neznámé nakladatelství The Pragmatic Programmer. Pravda, schopnost (spíš posedlost) přečíst kvanta knih jsem získal v minulém století, tak možná už to není tak in.

Takže, i pokud knížky nečtete, ale jste vývojář, který se nebojí v hospodě třísknout do stolu a zvolat na celý lokál: já jsem programátor, kdo je víc?, měla by vám něco říkat jména Andy Hunt a Dave Thomas. Pořád nic? Dobře, dávám vám poslední šanci: The Pragmatic Programmer. Bible softwarového inženýrství. Ano, napsali ji ti dva pánové. A ano, oni založili i to vydavatelství.

Proč se o tom tak vykecávám? Protože tohle parádní vydavatelství si zaslouží trochu promotion. Četl jsem od nich už šest knih a všechny byly skvělé, pokaždé 5 hvězdiček. Takové kvalitě se, s výjimkou Manningu, žádné další nakladatelství ani nepřibližuje. Takže, pokud váháte, jestli od nich něco koupit, anebo jste je doposud vůbec neznali - vřele doporučuju.

Memento mori

Pryč jsou doby, kdy stačilo, aby byl programátor pragmatický. Dnes musí být ještě navíc zdravý. Že by diktát New Age? Ne, jenom realita.

Programátoři (podobně jako rockeři či jazzmeni) vedou ve velké většině dosti nezdravý způsob života. Dokud je člověk mladý, tak to nějak jde. Ale jak začne oťukávat třicítku, tak mu tak nějak dojde, že není nesmrtelný a začnou se ozývat různé bolístky. A tady by měl každý zůstat ostražitý...

Jinak můžete dopadnout, jako já před pár lety - svoji programátorskou vášeň (10-12 hodin u počítače, včetně víkendů) jsem krutě zaplatil - vyhřeznutou plotýnkou. Plotýnka nabořená v míše je kritická věc (můžete třeba ochrnout) a zcela spolehlivě vás odradí od práce s počítačem - nejen, že nemůžete sedět, nemůžete ani ležet, ani stát. Všechno hrozně bolí.

No, vzhledem k tomu, že teď čtete tenhle článek, tak to asi dobře dopadlo. Vysekal jsem se z toho - s pomocí dobré víly a hlavně vlastním úsilím, jsem slezl chirugovi z lopaty a dnes žiju běžný život jako "předtím". Opět vášnivě programuji (i když rozumně - snažím se dodržovat XP Eight-Hour Burn), své děti vyhodím bez problémů metr nad hlavu, běhám, plavu atd. Všechny tyto věci mi doktoři zakazovali. (A pak jim věřte. ;-)

The Healthy Programmer

Kniha The Healthy Programmer od Joea Kutnera sice nenabízí tak srdceryvný příběh, jaký jste právě dočetli :-)  Nabízí ale něco jiného - jak se takovým problémům vyhnout. Knihu dobře vystihuje její podtitul: Get Fit, Feel Better, and Keep Coding. Nejdůležitější je to poslední - Keep Coding - protože jestli chcete programovat (nebo dělat cokoliv jiného na počítači) ještě za 10 let, budete s tím muset něco udělat. Čas, biologie a mechanika jsou neúprosné a pracují proti vám.

Zdroj The Healthy Programmer
Jádro knihy vám neprozradí nic nového, prostě: jezte zdravě, cvičte, dávejte si pozor (a pečujte) na oči, záda a zápěstí, buďte aktivní atd. Co je ale na knize unikátní, je způsob, jak jsou tyto věci vysvětlovány a jak byste k nim měli přistupovat.

Kniha totiž radí přistupovat ke svému zdraví agilně. Pro daný aspekt si udělat test a pak iterativně refaktorovat danou kvalitu, až test projde. Dostane se i na Pomodoro a kaizen. Všechny změny jsou malé a postupné. Smyslem není jen vyřešit váš aktuální problém (nadváha, bolesti zad či hlavy, únava apod.) a upozornit na (závažná) rizika, která se s vývojářským životním stylem pojí, ale hlavně najít systém, který pro vás bude udržitelný po zbytek vašeho (programátorského) života. A taky vás bude bavit.

Všechny věci, které autor doporučuje jsou podepřeny vědeckými studiemi. Pokud někde korelace není prokazatelná, tak na to upozorní. Kniha obsahuje obrovskou sumu referencí, na vědecké články a další literaturu. Abych pravdu řekl, tolik odkazů jsem v publikaci ještě neviděl.

Zakončil bych prvním citátem, který jsem si podtrhnul. Myslím, že knihu velmi přesně charakterizuje.

"Agile processes are characterized by an iterative and incremental approach to development, which allows us to adapt to changing requirements. The method you use to stay healthy shouldn't be any different."

4. srpna 2013

Kontrakt místo pohovoru, je to reálné?

Největším pracovním tématem posledního čtvrt roku je pro mne vytváření týmu. Potřebuji sestavit skupinu 10 vývojářů. Zatím je přijata cca třetina lidí a ta težší část mě teprve čeká - vytvořit týmovou kulturu a tým zapracovat a rozpohybovat.

Posleního čtvrt roku žiju pohovory. Dělám technická interview, dosti podobná tomu, co jsem před časem popsal v článku Jak dělám Java pohovor. Je to pro mne živé a přitažlivé téma - kromě toho, že je to (téměř) každodení zkušenost, tak sleduju různé články na internetu. Většinou v angličtině. K dnešnímu postu mě ale inspiroval článek, který je... ve slovenštině.

Riki Fridrich navrhuje v článku Kontrak namiesto pohovoru alternativu ke klasickému výběrovému řízení - místo pohovoru si kandidát střihne maličký projekt. Riki nepřichází s ničím novým - před rokem o tom psali Jeff Atwood, Jon Evans, letos Nelly Yusupova a Tommy Morgan. Takže to je myšlenka, která rezonuje. Minimálně na internetu.

V čem je problém?

Všemi výše uvednémi články prosvítají dvě základní myšlenky:
  1. Pracovní pohovory jsou neefektivní.
  2. Nejlepším způsobem, jak si (z několika úhlů) otestovat nového vývojáře, je zadat mu malý, ale reálný projekt.
Riki jde u druhého bodu ještě dál, když říká, že "to je budoucnost najímání seniorních ajťáků".

Jsou pracovní pohovory neefektivní?

Pracovní pohovory jsou tak neefektivní, jak neefektivní si je každý udělá. A to platí pro obě strany. Říct, že pracovní pohovor je neefektivní, je stejné, jako říct, že neefektivní je třeba Scrum. Nebo psaní unit testů. Nebo kontinuální integrace. Mám pokračovat?

Všechny právě zmíněné "činnosti" jsou nástroje, které nám pomáhají v naší práci. Je přece na nás, jestli je budeme používat efektivně (a správně). A je velmi důležité si uvědomit, že všechny tyto nástroje fungují v určitém kontextu (moje oblíbené slovo :-)

Myslíte si, že např. softwarový projekt bude úspěšný jen proto, že "nasadím" nějaký z těchto nástrojů? Já nevím jak vy, ale já už jsem viděl dost špatných implementací Scrumu (mmch. je zajímavý, že zainteresovaní vývojáři to většinou vidí, jako úspěch, i když projekt šel do kytek).

Podobné je to i s pracovním pohovorem. Není to žádná stříbrná kulka. Pohovor, to je jen taková "kvalifikace do závodu". Co v člověku opravdu je, se ukáže teprve během zkušební doby. Jak říká Rands, až teprve po 90 dnech budou obě strany vědět, na čem jsou. Neexistuje žádná zkratka.

Takže, ať už děláte takový skvělý pohovor jako já ;-) nebo jedete v obvyklé korporátní nudě, pořád je to jen jeden stupínek na dlouhé cestě. Pohovor bude tak efektivní, jak efektivní si ho uděláte - ať už jste kandidát, nebo zaměstnavatel.

Projekt místo pohovoru?

Je to hezká myšlenka. Místo příkladu do šuflíku - opravdový projekt. Místo programování na tabuli/papír - programování v oblíbeném IDE. Místo akademických algoritmů - reálný problém. Místo stresující nudy - práce, která baví. OK, myšlenka je to inspirativní. Co ale musíme udělat, aby byla proveditelná?

Nastavení prostředí. Aby kandidát mohl začít na něčem vyšívat, musí si nachystat nástroje. Jak dlouho mu to může trvat? Třeba je firma tak vyspělá, že nejenom že má build (nebo dokonce release) na jeden klik. Dokonce má na jeden klik i nastavení prostředí. Takový ty věci, jako vývojový (aplikační/webový) server, potřebné pluginy do IDE (ve správných verzích), všechny závislosti pro build, deploy a běh aplikace atd.

Řekněme, že tohle všechno je na jeden klik a když to bude hodně komplexní, tak to bude trvat maximálně 30 minut (berme, že konektivita pro stahování artefaktů je v dostatečné kapacitě). Build je taky na jeden klik a opět, když to bude hodně komplexní, tak dejme tomu 10 minut. Takže včetně uvaření kafe, za hodinu je kandidát připraven vyvíjet.

Mno. Zrovna jsem tenhle týden dostal od kandidáta na pohovoru otázku, jak dlouho u nás trvá příprava prostředí pro vývoj. A upřímně jsem odpověděl, že když jsem si rozcházel projekt, na kterém teď vypomáhám s nějakými change requesty, trvalo mi to tři dny. Ten projekt je specifický a má to svoje objektivní důvody. Ale je to realita, která se čas od času přihodí.

Obecně, moje zkušenost (v oblasti enterprise Javy) je, že rozchození projektu trvá řádově man days. Nevím, možná je to extrémní situace. Když jsem před 10 lety programoval v PHP, tak jsem si: 1) zkopíroval z disku zdrojáky, 2) hodil je na Apache (mod_php) a 3) a začal bastlit ve Vimu, tak to mohlo trvat tak 20 minut. (Teď trochu kecám - tehdy jsem bušil ve Slackwaru a celý LAMP jsem si kompiloval ze zdrojáků. Takže i s přípravou serveru to trvalo o dost dýl. Ale dejme tomu, že to zanedbáme.)

Máte zkušenosti z jiných domén? Jak dlouho trvá nastavit prostředí v Ruby? V Pythonu? V Erlangu? V Androidu? Myslím reálné business projekty.

Sdílení artefaktů. Kandidát bude potřebovat s firmou sdílet nějaké artefakty. V první řadě, bude potřebovat někde získat zdrojový kód. A zpátky komitovat svoje změny. Co nějaká dokumentace, Wiki? Nějaké konfigurační artefakty, které nejsou přímo součástí aplikace?

Pokud jste na GitHubu (nebo jiné, obdobné hostingové službě), máte vyhráno. Nejste na GitHubu? A safra! Kdo bude s vaším kandidátem řešit problémy s konektivitou, nastavením práv apod.? Nejde o to, že by to bylo složité (zatím to vždycky fungovalo ;-) a kandidát by si s tím neuměl poradit. Problém je, že to "žere" čas, který má kandidát na projekt.

Sdílení informací. Kolik artefaktů, vyjma aplikace samotné, vám na projektu vzniká? Jste agilní a máte jich minimum? Znalosti a kontext se sdílí v týmu hlavně orálně (stand-upy, statusy atd.)? Nebo máte naopak hodně formálních artefaktů? Věci jako specifikaci, analytický model, guide lines atd.

A teď. Kolik času kandidátovy zabere, aby vstřebal alespoň nutné minimum, které mu umožní na projektu začít?

Znalost technologií. Třeba firma dělá v něčem křišťálově čistém - víš, nevíš. Abych pravdu řekl, nic takového mě nenapadá. Děláte v JavaScriptu? Kolik frameworků znáte opravdu dobře? Děláte v PHP? Totéž. Pokud bych vzal v potaz doménu Java frontend frameworků, tak pravděpodobnost, že kandidát zná, či má zkušenosti právě s tím vaším, je tak 10 %. OK, pokud dělal s (nějakým klonem) JSF, tak se to může blížit i 50 %.

Moje frontendová zkušenost za cca 8 let v Javě? Co projekt, to jiný framework. Pokaždé se to učíte znova a znova. Když to vezmu chronologicky: Servlety, HTMLB (zná to někdo?), Wicket, RichFaces, Vaadin.

U backendových technologií to není tak divoký, ale stejně. Celkem běžně potkávám na pohovorech lidi, kteří třeba 5 let dělali v JDBC a ani nezavadili o JPA, nebo něco podobného.

Takže jaká je pravděpodobnost, že kandidát bude technologicky sedět na potřeby firemního produktu? Pokud to nebude 80-90 %, co s tím? Jak dlouho se bude nové technologie učit? Nebo si oživovat ty staré (třeba přes dvě, tři nekompatibilní verze)? Jaký to bude mít vztah k našemu projektu?

Je to reálné?

V předešlé sekci jsem načrtnul některé z problémů (jistě ne jediných), které by bylo potřeba vyřešit, aby byl "přijímací" projekt proveditelný. Všechno jsou to technické záležitosti, v podstatě jenom prerekvizity. Už jenom u těchto předpokladů mám vážné obavy, že by se jejich splnění mohlo vejít do pár hodin, maximálně jednoho dne. Ale dejme tomu, že by to šlo.

Další sadou výzev bude nastavení firmy a její kultura. Kandidát by ideálně měl dostat za svůj projekt zaplaceno. Kde se ty peníze ve firmě vezmou? Některé společnosti fungují striktně nákladově - vezmou se ty peníze z budgetu projektu? Nebo z nějaké režijní činnosti? Kdo za to bude odpovědný? Jakým způsobem se budou ty náklady vyúčtovávat? V maličkým startupu nad tím můžeme mávnout rukou. Ve větší firmě to bude show-stopper.

Také nemůžu nezmínit věc, která mi přijde velmi kritická - součinost firmy s kandidátem. Zdá se mi to, nebo se furt nikdo nepoučil, že přidáním lidí na projekt se vývoj zpomalí (Brook's law)? Pokud přijímáme jednoho kandidáta, (časové) náklady na součinost se v běžné práci ztratí. Pokud ale potřebujeme najmout tým lidí - a neříkám, že najednou - znamená to zasekat se v podpoře kandidátů na půl roku dopředu. Na full time. To si nedovedu představit. A to mám se zaškolováním lidí na projektech, řekl bych, celkem bohaté zkušenosti.

A pak nám zbývá poslední, esenciální ingredience. Kandidát. Chápu, že když chce někdo dělat pro firmu svých snů, udělá pro to opravdu hodně. Doplňte si dle svých preferencí Google, Twitter, ThoughtWorks, GitHub, Stack Overflow, Apache, Canonical... já nevím, co ještě. Takže když vám taková firma zadá vstupní projekt, rádi ho uděláte a ještě to budete považovat za čest.

Jenže, kolik takových firem je? Jedno promile? Co ty ostatní, kde pracuje 90 % těch vývojářů, co nejsou špičkový? Ruku na srdce, kolik z vás by šlo do týdenního projektu (byť placeného) s nejistým výsledkem?

Aby kandidáti do něčeho takového šli, museli by změnit svůj mindset. Nedávno jsem v článku Měl by mít vývojář portfolio? psal o tom, že na pohovorech chci vidět kandidátův kód. Nemám srovnání, ale odhaduju, že jsem v tomhle spíš výjimka. Je to vidět i na přístupu kandidátů - někteří jsou tím dost zaskočeni. Někteří dají do placu kód, který není zrovna oslnivý. A zlomek jich tento požadavek prostě ignoruje.

Takže můj pocit je, že pro majoritu vývojářů by psaní vstupního projektu bylo příliš velkým myšlenkovým veletočem.

Závěr

Myslím, že myšlenka dát vývojáři místo pohovoru projekt, je zajímavá. Ale realizovatelná tak v jednom procentu případů. Velmi specifických případů. Asi půjde o nějaký startup, kde to nebude problém procesně a technicky. V případě kandidáta půjde asi o excelentního bušiče kódu, který zrovna šťastně odpovídá technologickému nastavení firmy. A práce bude pro kandidáta tak zajímavá, že mu to za ten projekt bude stát. To je dost výjimečná konstelace.

Související články


Související externí články

22. července 2013

Hledám do svého týmu Java vývojáře

[UPDATE] Ačkoliv by to mělo být zřejmé z data článku (2013), pro jistotu to v úvodu zdůrazním: tento inzerát již není platný. Nechávám jej zde z historických a studijních ;-) důvodů. [/UPDATE]

Dnešní post bude jiný, než jste na tomto blogu zvyklí - rozhodl jsem se "jít tomu štěstíčku trochu naproti" a publikovat zde pracovní inzerát. Proč? Protože hledám lidi k sobě do týmu. A myslím, že pokud to někoho osloví, bude to lepší, než čekat, koho mi najde HR oddělení, nebo pošle nějaká agentura. Zkrátka, vytvářím si vlastní příležitost.

Tenhle post se bude lišit ještě v jednom ohledu. Když píšu, snažím se vždy maximálně odstínit od svého zaměstnavatele, nebo projektu, kde právě pracuji. Dnes budu naopak velmi konkrétní, nebo chete-li upřímný (v rámci možností :-)

The Company

Pracuji ve společnosti Gemalto. Už z webu můžete poznat, že jde o korporaci. Ano, je to tak - celosvětově máme 11.000+ zaměstnanců, head quarter sídlí ve Francii. Gemalto se zabývá bezpečností a jednotlivé divize pokrývají oblasti finančních služeb, telco, identity a goverment.

V Praze na Brumlovce má Gemalto vývojové centrum, zvící cca 300 zaměstnanců, které reflektuje uvedené divize a které má na starosti dodávání SW části našich řešení. Já jsem jedním z koleček v divizi governance, která má na starosti klienty z oblasti EMEA - našimi zákazníky jsou vlády z oblasti Evropy, Blízkého východu a Afriky (můžu vás uklidnit, pro českou vládu nic neděláme :-)

Naše vývojové oddělení má kolem 45 lidí (vývojáři a testeři) a chceme se rozrůst o cca 10 dalších vývojářů (= můj tým). Řekl bych, že nabírání lidí je v našem případě pozitivním signálem - práce je dost a ještě nějaký čas bude. Mmch. pražská pobočka Gemalta během tzv. "krize" neustále rostla, takže to může naznačit jistou perspektivnost našeho segementu.

Gemalto je společností mezinárodní nejenom strukturou, ale i obsahem - v našem oddělení je cca 2/3 Čechů a Slováků, zbytek tvoří cizinci posbíraní různě po Evropě. Asi nepřekvapí, že nejsilnější "menšinou" jsou Francouzi. Nicméně oficiálním komunikačním jazykem je angličtina.

Projects

To co dodáváme (teď už mluvím o našem oddělení) našim zákazníkům - vládám - jsou elektronické dokumenty: pasy, ID karty (občanky), řidičáky, povolení k pobytu (resident permit), volební průkazy (doména Afriky) apod.

Dodávkou může být komplexní řešení, které umožní dané vládě si kompletně produkovat daný typ dokumentu, nebo jenom jeho část. Záleží projekt od projektu. Pokud bych měl načrtnout dodávané řešení pomocí tří kostiček, vypadalo by takto:


Kostičky Enrolment a Quality Center nás nemusí zajímat, ;-)  protože jsou napsaný v .NETu. Jen pro představu, Enrolemnt je o "narolování" dat, které budou umístěny na výsledném dokumentu. Může jít o napojení na nějaký národní registr, nebo např. fyzické snímání otisků prstů. Quality Center je, hm, kontrola kvality. Takže třeba kontrola, že to, co je vytištěno na dokumentu je také zapsáno na čipu.

Nenechte se zmást, že na Javu zbyla jenom kostička Issuance. Javisté tvoří 2/3-3/4 našeho týmu, takže se jedná o docela rozsáhlé řešení, které se většinou skládá z několika aplikací. A co kostička Issuance řeší? Má na starosti věci jako validaci a preprocesing dat, různé kryptografické záležitosti (třeba PKI) a hlavně správu a samotnou produkci dokumentů.

Jak jsou projekty veliké? Jejich délka se pohybuje od 6 měsíců do 2 let a podílí se na nich od 3 do 20 lidí (všech rolí). To jsou nějaké mezní hodnoty, takže většina projektů se pohybuje někde mezi nimi a má "rozumnou" velikost.

Podstatná informace je, jak jsou projekty řízeny. Vzhledem k tomu, že jsme korporace a pracujeme pro vlády, je to jasné - je to čistokrevný vodopád. Interně si ale bereme z agilních metodik to použitelné, takže například děláme code a design review, máme kontinuální integraci apod. Míra se projekt od projektu liší. Osobně si myslím, že je to lepší přístup, než jsem zažil za poslední tři roky v bankingu - lhaní si do vlastní kapsy, že "to děláme agilně", aby se pak projekty běžně zpožďovaly o rok a víc (true stories). To se nám nestává.

Zatím nezaručenou informací a příslibem do budoucna je, že bych chtěl pokračovat v používání Kanbanu. Tohle zatím nemůžu slíbit, ale budu se snažit, abychom to opravdu používali a nebylo to jen plácnutí do vody. Kanban má oproti třeba Scrumu tu výhodu, že není v protikladu k vodopádu a do korporátního prostředí velmi dobře zapadne.

Poslední důležitá informace - naši vývojáři cestujou. Služební cesty jsou krátkodobé, většinou je to tak kolem dvou týdnů na začátku projektu (sbírání požadavků, workshopy apod.) a obdobně na konci projektu (instalace, integrace, školení apod.). Takže pokud se chcete podívat do zahraničí, kam byste nejspíš na dovolenou nejeli (třeba Saudská Arábie, nebo do Irska), tak u nás máte možnost. Samozřejmě, že respektujeme vaše preference, takže pokud třeba máte malé děti, vždy se to dá individuálně nastavit.

Technologies

Konečně se dostávám k tomu, co je na tomhle článku asi nejzajímavější. Jaké technologie tady používáme? Náš hlavní technologický stack je postavený nad Java EE. Pokud je to podstatné, uvádím v následujícím přehledu verzi komponenty, ta v závorce je pro starší projekty, ta před závorkou pro nové projekty.
  • JBoss AS 7 (5) jako aplikační server,
  • Vaadin jako frontend,
  • EJB 3.1 (3.0) a CDI pro business logiku,
  • JPA 2.0 (1.0)/Hibernate pro perzistenci,
  • JMS/HornetQ pro messaging,
  • JAX-WS pro SOAP webové služby.
Kromě těchto "mainstream" technologií se u nás můžete setkat minoritně s Grails a ještě minoritněji se Springem. A pak s celou kupou dalších, většinu open source, věcí, které jsou specifické per projekt. Z hlavy mě napadá třeba JasperReports, nebo Dozer.

Buildujeme Mavenem (rád bych zkusil prosadit upgrade na Gradle). Na verzování zdrojáků používáme Mercurial, takže pokud chcete zkusit něco stejně skvělého, jako je Git, ale uživatelsky kompaktnější ;-)  tak to bude příjemná zkušenost. Na kontinuální integraci používáme Jenkins a na metriky Sonar(Quebe). Issue tracking Redmine.

Java IDE je na vás, běžná je tady svatá trojice E/I/N. Kupodivu, dost lidí tady dělá v NetBeans (asi to sem dotáhli přebehlíci ze Sunu ;-)  Pokud se ukáže, že to s námi myslíte vážně, rádi vám koupíme Ideu. Největší borci samozřejmě dělají ve Vimu (no dobře, to je vtip... ve Vimu dělám jenom já).

Pros

Tak v první řadě, budete dělat s nejlepším team leaderem široko daleko. Jsem skromný a myslím to vážně.

Doména ve které Gemalto podniká je hodně zajímavá. Pokud vás nudí telco nebo banking, zkuste securitu! Když se tak vyprofilujete, může být kryptografie vaším dením chlebem. A i  pokud ne, tak security záležitosti tady budete potkávat daleko častěji než v jakékoliv jiné doméně.

O krátkodobém cestování už jsem mluvil. Co je opravdu zajímavé, Gemalto poskytuje tzv. stáže - můžete na dva tři roky vycestovat do zahraničí a pracovat v jiné pobočce někde ve světě (tahle možnost přesahuje výše zmíněnou oblast EMEA). Gemalto vám při tom pomůže s relokací.

Jako (skutečný, ne pouze softwarový) polyglot bych ze standardních benefitů vypíchnul výuku jazyka v pracovní době - angličtina nebo francouzština.

Věc, která se obtížně popisuje, ale já ji považuji za velmi cennou. V našem oddělení panuje důvěra a respekt a pracují tady fajn lidé. Vůbec, lidi, které jsem potkal na přijímacím pohovoru (kolega team leader a můj šéf) jsou jedním z důvodů, proč jsem se rozhodl pro práci tady. A během další spolupráce jsem si to jen potvrdil.

Cons

Co vám mám povídat? Je to korporace. Máme tady procesy, komunikační šumy a některý věci jsou zkrátka na dlouho.

Také některé věci/procesy ještě nejsou nastavený, nebo úplně ideální. Do značné míry je to dáno rychlostí, jakou pražská pobočka v uplynulých letech vyrostla - dělaly se projekty a na procesy/metodiky/guidelines nebyl čas. Jde o věci jako třeba jednotný issue tracking. Nebo větší míra automatizace. Jsou to věci, které bych rád prosadil pomocí týmové kultury.

Who?

Momentálně hledáme seniornější vývojáře. Pokud jste absolvent, musím vás zklamat. Pokud jste junior, "máte jiskru v oku" a jste opravdu dobrý (= přesvědčíte mě na pohovoru), máte šanci.

Důležitá informace je, že bereme pouze zaměstnance. Kontraktory nám firemní politika zapovídá.

How much?

Otázka peněz je delikátní. Tak pojďme do toho. Jsme názoru, že každý by měl znát svou cenu. Bavíme se o rolích Java vývojáře a technical leadera. Takže pokud nepřešvihnete naše stropy pro tyto role, tak dostanete, co si řeknete. A říct si můžete, vzhledem k vaší senioritě, standardní plat Java vývojáře v Praze. Na rovinu říkám, že vás nebudeme přeplácet. Ale nebudeme vás ani vykořisťovat :-)  A jinak, mám velmi přesnou představu, co byste v rámci vaší seniority měli umět.

Interview

Přijímací pohovor má tři kola. Prvně bude phone screen, cca 30 min. Následující technické kolo budete dělat se mnou a bude probíhat formou, kterou jsem už popisoval. Změnily se tam dvě věci (časem o tom napíšu) - jednak už nedávám hlavolam a pak, část podíváme se na můj kód je mnohem "praktičtější" ;-)

Poslední kolo je pohovor s mým šéfem a s někým s HR.

Conclusion

Nabízím vám slušnou práci, za slušné peníze. U mne v týmu. Není to práce pro každého - pro někoho je show-stopper, že to je enterprise, pro někoho absence Springu, pro někoho...

Ale pokud jste s výše uvedeným OK a vzájemně si sedneme (vy mně jako vývojář a my vám jako firma), myslím, že by nás to mělo společně hodně bavit.

Pokud to chcete zkusit, můžete začít tím, že pošlete na můj firemní email svoje CV v angličtině: vit.kotacka@gemalto.com.

Pokud by vás něco zajímalo, zeptejte se v komentářích, nebo mi napište na Twitter, či LinkedIn.

Official Ad

Pokud přesto všechno, co jsem napsal, chcete mrknout na oficiální inzerát, nebo okouknout takové ty standardní firemní benefity:

17. července 2013

Team Geek, team leader se srdcem

Pryč jsou doby, kdy geekové a hackeři kutili něco v jeskyních a ven vycházeli jen když potřebovali vyklidit navršené krabice od pizzy. Dnešní geekové se myjou, češou, umí si sami objednat v restauraci a... pracují v týmu.

Team Geek

Jsou různé způsoby, jak vést lidi a jeden z nich je založený na důvěře. Je to způsob, který mi vyhovuje a který praktikuju poslední tři roky, co se potýkám s rolí team leadera. Je to způsob, který vykrystalizoval spolu s hnutím Open source a poslední dobou, podobně jako agilní metodiky, si úspěšně prohryzává cestu do srdcí otrokářských korporací.

Necháte si občas poradit od zkušenějších? Pokud jste, nebo máte aspiraci být team leaderem, možná byste ocenili nahlédnutí do kuchyně pánů Briana Fitzpatrika a Bena Collins-Sussmana, kteří o tomto tématu napsali knihu Team Geek s podtitulem A Software Developer's Guide to Working Well with Others. A je to dobrá kniha. Není se co divit - oba patří mezi zakládající členy projektu Subversion, později pracovali v Googlu a posledních pět let se věnují přednášení o sociálních vztazích mezi vývojáři. Pár jejich přednášek je k vidění na YouTube.

Tři pilíře srdce

Tři hlavní principy, na kterých staví poselství knihy, jsou označeny anglickou zkratkou HRT (vyslovuj jako heart) - Humility, Respect, Trust. Čili pokora, respekt a důvěra. Kolem těchto základů pak postupně nabalují jednotlivé komunikační sféry. Začínají u nejdůležitější postavy, team leadera, aby se postupně přes tým, spolupracovníky a organizaci dostali až k uživatelům.

HRT (zdroj Team Geek)

Šest kapitol kolaborativní nirvany

Kniha je rozdělena do šesti kapitol, které částečně kopírují narůstání kontextu, ve kterém se každý tým pohybuje a částečně řeší praktické problémy, se kterými se team (leader) může setkat:

1. The Myth of the Genius Programmer
Myslíte si, že Linus Torvalds napsal Linux úplně sám? Samozřejmě, že ne. Ale z určité vzdálenosti to tak může vypadat. Souvisí to s lidskou potřebou mít hrdiny (nebo mýty?). A hrdinové přece nedělají chyby.

Proč je v knize tahle kapitola? Protože druhou stranou touhy po dokonalosti je strach ukázat selhání, který vyvěrá z nedostatku sebe-důvěry a hlavně  - důvěry v rámci určitého prostředí. V takovém kontextu se těžko buduje fungující tým.

2. Building an Awsome Team Culture
Jednoduchá rovnice: úžasný tým má skvělou kulturu. Jak ji ale vybudovat? A hlavně udržet? Kromě "komunikačních vzorců úspěšných kultur" :-)  je zajímavé si přečíst, jak formování kultury napomáhají věci jako issue tracking, nebo code review pro každý komit. Plus spousta dalších.

3. Every Boat Needs a Captain
Kniha propaguje typ leadera, který slouží svému týmu, tzv. servant leader. Jak takový člověk vypadá, je popsáno pomocí leadership antipatternů a patternů.

4. Dealing with Poisonous People
Pokud má tým silnou kulturu, může se stát, že se mu "jedovatí" lidé buď úplně vyhnou, nebo se aspoň přizpůsobí natolik, aby byli snesitelní (a kulturu nekazili). Pokud nemáme to štěstí, musíme to nějak řešit (jinak sklouzneme do jednoho z antipatternů z minulé kapitoly). Někdy to přes všechnu snahu "prostě nejde". Nic naplat, jak ví každý zahradník, shnilé ovoce je potřeba vyhodit. Čím dřív, tím líp.

Tohle je jedna ze silných kapitol, která pomůže s řešením těchto nepříjemných - a nelehkých - záležitostí. Důležitá je také proto, že připomíná jednu podstatnou věc - team leadeři se často rekrutují ze seniorních vývojářů, kteří se mnohdy zaměřují na technickou stránku věcí a naopak hodně (až zcela) ignoruj lidskou stránku (členů) týmu.

5. The Art of Organizational Manipulation
Manipulace, to zní ošklivě, že jo? Někdo tomu říká politika, někdo sociální inženýrství, autoři tomu říkají organizační manipulace. Váš tým nežije ve vzduchoprázdnu a ať chcete nebo nechcete, jako team leadeři se budete potýkat s prostředím okolo vás. A mimochodem, jedním z vašich úkolů je váš tým odstínit od toho šílenství, které vládne "tam venku".

6. Users Are People, Too
To je další věc, kterou vývojáři neradi slyší. Že existují taky nějací uživatelé (nejčastěji zmiňovaní s despektem), kteří používají "náš" software. Nedejbože, abychom s nima museli komunikovat. Pokud se ale na věc podíváme rozumně, může nám to otevřít nové perspektivy na design našeho projektu. Google by mohl vyprávět.

Závěrečná myšlenka

Četl jsem už několik knih o team leadingu/managementu. Většinou to dopadlo tak, že jsem si cizí zkušeností potvrdil, k čemu jsem došel už předtím intuitivně. Ale pokaždé to bylo inspirativní a umožnilo mi to posunout se o kus dál. Tahle kniha není výjimkou. A pokud zvažujete svoji první knihu o team leadingu, tak tohle určitě nebude špatná volba.

Související články

8. července 2013

Gradle tutorial: tasky

Vítejte u prvního dílu tutorialu o automatizačním nástroji Gradle. Filozoficko-marketingovou masáž jsme si odbyli v minulém článku, takže je čas si vyhrnout rukávy: let's get our hands dirty!

3 informace na úvod

Asi nejdůležitější informací je: co by mělo být přínosem tohoto tutorialu? Gradle má velmi pěknou dokumentaci (User Guide, DSL Reference, Javadoc/Groovydoc), tak proč psát ještě tutorial? Důvody jsou dva. Jednak dokumentace ne vždy pomůže při řešení praktických věcí - dotazů je plný Stack Overflow, a jednak některé věci nejsou úplně ve stavu, v jakém bych je chtěl používat. Jako příklad můžu uvést Jetty: Gradle obsahuje out-of-the-box Jetty plugin, který ale používá Jetty ve verzi 6. Což je verze, která je deprecated. Pokud tedy chci používat nějakou stable verzi (7-9), musím to udělat jinak. Tutorial by tedy měl řešit praktické věci v aktuálních verzích použitých nástrojů.

Druhou informací je scope tutorialu. Ten by měl odpovídat mojí přednášce na SlideShare, plus něco navíc. Základní zaměření odpovídá mým potřebám, tedy na co Gradle používám já. Pokud byste si rádi přečetli o nějakých dalších tématech, dejte mi vědět v komentářích - rád tutorial přizpůsobím vašim potřebám. Tutorial by měl zahrnovat hlavně Java vývoj: tj. Java, unit testy, web, metriky kódu, multi projekty, kontinuální integraci, integraci s Antem. Předstupněm závěru by byl jednoduchý, ale reálný projekt - webová služba na JAX-WS a úplné finále by obstarala case study (opět reálný projekt).

Poslední informace je praktická. Ke každému dílu budou k dispozici zdrojové kódy build skriptů, které budu postupně publikovat na Bitbucketu. Zdrojové kódy v repozitáři budou obohacené o komentáře, takže budou (doufám) použitelné i samostatně.

Bitbucket je Mercurial (a Git) hosting, který funguje obdobně jako známější GitHub. Že jsem zvolil Mercurial a ne třeba populárnější Git je, dejme tomu, srdcová záležitost. (A pak, toho Gitu už je všude trochu moc ;-)

Instalace a verze Gradlu

Instalace Gradlu je jednoduchá ve stylu stáhnout-rozbalit-přidat bin do PATH-spustit. Prerekvizitou je JDK 1.5+. Pro přesný postup vás odkážu na stránky dokumentace: Installing Gradle. Funkčnost instalace ověříme příkazem gradle -v.

Verze Gradlu

V rámci tutorialu budu používat verzi 1.7 z nočního buildu. Předpokládám, že tutorial bude zdrojem informací i v budoucnu, ne jenom v čase publikování, tak si chci podržet iluzi, že takto vydrží být aktuální alespoň o něco déle. Může se sice stát, že některé funkčnosti, které popisuji se mohou ve stabilních releasech chovat trochu jinak (např. výstupy na konzoli), nicméně většina příkladů byla původně vyvinuta pro (stable) verzi 1.5 a ve verzi z nočního buildu funguje bez úprav, takže nepředpokládám problémy :-)

Pokud byste u příkladů narazili na nekompatibilitu mezi verzemi, dejte mi, prosím, vědět v komentářích.

Projekty a tasky

Dva základní koncepty, na kterých jsou Gradle build skripty postaveny jsou projekt a task. Koncept projektu by nám měl být familiární, např. z IDE. Zjednodušeně, projekt představuje nějaký komponent, který potřebujeme sestavit: JAR/WAR/EAR/ZIP archiv apod. Projekt je prezentován souborem build.gradle v root adresáři projektu.

Definice Gradle projektu (projekt 00_HelloWorld)

Projekt definuje související množinu tasků. Task je atomická jednotka práce, kterou můžeme spustit v rámci buildu. Každý task může obsahovat množinu akcí. Akce už je nějaká konrétní věc, kterou chceme provést: výpis na konzoli, přesun souboru, kompilace, spuštění jiného tasku atd.

Hello, world!

Nevím, jak vy, ale já když se učím něco nového (jazyk, framework, nástroj), tak si vždycky rád napíšu Hello world. Jak vypadá Hello world v Gradlu?
task hello << {
    println 'Hello, Gradle!'
}
Příklad spustíme příkazem
gradle hello
Výstup by měl vypadat nějak takhle:

Výstup tasku hello

Výstup je možná trochu ukecaný - kromě výpisu našeho textu je tam label daného tasku (:hello) a informace o úspěšnosti vykonání tasku. Pokud chceme kompaktnější výstup, můžeme spustit task s přepínačem -q. Gradle pak vypisuje (ve skutečnosti loguje) pouze to, co jsme poslali na standardní výstup (println) a zprávy se severitou error.
gradle hello -q
Zrojový kód na Bitbucketu: 00_HelloWorld/build.gradle

Jaké tasky jsou k dispozici?

Nejčastějším uživatelem Gradlu bude vývojář. Ale může se taky stát, že ho bude spouštět tester, nebo analytik, nebo... (nedejbože ;-) projekťák, či slečna asistentka. Pamatujete? Automatizace.

Tyto ostatní role se asi nebudou chtít vrtat v kódu build skriptu, aby zjistily, co že to má dělat apod. Jako dělaný speciálně pro ně je příkaz gradle tasks, který vypíše seznam tasků, které jsou k dispozici.

Výpis tasků

V závislosti na verzi Gradlu se výpis může lišit. Pokud nevidíte nějaký task, který byste vidět měli, zkuste příkaz spustit s přepínačem --all:
gradle tasks --all

Gradle GUI

Graficky orientovaní jedinci možná ocení práci s grafickou verzí Gradlu, která se spouští příkazem gradle --gui. Zde je také vidět přehled tasků. Ty se navíc dají rovnou spouštět, je vidět jejich výpis na konzoli atd.

Gradle GUI

Syntaxe tasku

Nejčastěji se budeme setkávat s definicí tasku, která byla uvedena v příkladu Hello world, čili:
task myList << {
    println 'middle point'
}
Na této syntaxi je nejzajímavější operátor <<, který je aliasem pro metodu doLast. Stejný výsledek dostaneme zápisem:
task myList {
    doLast {
        println 'middle point'
    }
}
Když máme metodu doLast, tak nepřekvapí, že máme i obdobnou doFirst. K čemu tyto metody slouží? Umožňují nám "dekorovat" již definovaný task - metoda doFirst přidává nové akce na začátek seznamu akcí a metoda doLast dělá totéž na konci seznamu akcí daného tasku. Každý task tedy můžeme postupně rovíjet a obohacovat jeho chování. V jednoduchém build skriptu to asi nebude potřeba, ale v hierarchii skriptů (multi project) už to může být zajímavé.
task myList << {
    println 'middle point'
}

myList {
    doLast {
        println 'last point'
    }
}

myList {
    doFirst {
        println 'first point'
    }
}

Výstup "dekorovaného" tasku myList

Zdrojový kód na Bitbucketu: 01_Tasks/build.gradle

Zdrojové kódy

Zdrojové kódy k dnešnímu dílu jsou k dispozici na Bitbucketu. Můžete si je tam buď probrouzdat, stáhnout jako ZIP archiv, anebo - pokud jste cool hakeři jako já :-) - naklonovat Mercurialem:
hg clone ssh://hg@bitbucket.org/sw-samuraj/gradle-tutorial

Co nás čeká příště?

Protože tasky jsou pro Gradle stěžejním konceptem, budu se jim věnovat i v příštím díle. Tři hlavní okruhy by měly být:
  • závislosti mezi tasky,
  • dynamické generování tasků - task rules
  • a "běžné" problémy, se kterými se můžeme při definici tasků setkat.

Tento článek byl původně publikován na serveru Zdroják.

Související články


Související externí články

29. června 2013

Joel test, má ještě smysl?

Jste vývojáři? Pak už jste se možná někde setkali s Joelovým testem. Možná jste to zaslechli někde na internetu, možná se vás na to ptali na pohovoru (nebo vy jich) a možná jste to dokonce sami ve firmě zaváděli.

Joelův test je skvělý. Když jsem na něj cca před osmi lety narazil, bylo to pro mne jako zjevení. Měl jsem tehdy tři, čtyři roky zkušeností s PHP a začal jsem pronikat do enterprise Javy. A pracoval jsem ve společnosti, jejíž skóre v tomto testu bylo... ehm, nula.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Expozice

Jak říkám, bylo to pro mne zjevení. A výzva. Ze své pozice jsem toho nemohl formálně mnoho ovlivnit, nicméně se mi podařilo to skóre zvednout na 3. První, co jsem udělal, nechal jsem vytvořit virtuální server, rozchodil na něm Subversion repozitory, všechny své projekty jsem tam naimportoval a začal SVN denně používat. Hned jsem se cítil o moc dospělejší :-)

OK, takže máme Joelův test - stačí si to odškrtat, co ještě nemáme, tak zavedeme a hned je z nás světová firma. Asi tušíte, že mezi odškrtnutím položky a každodenní praxí může být nebetyčný rozdíl. Já bych ale chtěl poukázat ještě na jednu věc.

Joelův test je minimálně 13 let starý - Joel ho publikoval v roce 2000. Nevím, jak to připadá vám, ale já bych řekl, že za tu dobu se svět docela změnil. Já jsem se změnil. Joel se změnil (už nemá tolik vlasů, co míval). Ten test by se taky měl změnit.

Dnes se běžně setkávám s tím, že společnosti mají v testu kolem deseti bodů. Dvanáctku jsem nikdy nepotkal. A i kdyby - už jste v softvarovém vývoji viděli něco, co by nepotřebovalo zlepšit? Většinou toho bývá docela dost.

Nemám ambice, napsat novou verzi Joelova testu. Spíš bych se nad ním chtěl zamyslet. Bude to  takový rozpracovaný materiál - rozvrtám to a třeba se to někam vyvine.

Co mi na testu vadí

Joel Spolsky (zdroj Joel on Software)
Joel Spolsky je určitě autorita, které stojí za to naslouchat. Ale není nutné se vším souhlasit. Podobné je to i s jeho testem - ten prostě vyjadřuje (tehdejší) Joelovy preference (jak to dělat), priority (co dělat) a potřeby (ne všechny body jsou možné, nebo vhodné v každé doméně). Je docela možné, že Joel žije ve světě, který je vaší realitě velmi vzdálen: 5 Reasons Why Joel's Business (Probably) Isn't Like Yours.

Tím chci jen říct, že ten test je potřeba brát s rezervou. A pokud už se s tím někde veřejně chlubím, třeba firma, měl by to být jen střípek do mozaiky. Když mi někdo řekne, že mají v testu 12 bodů, tak mě nezajímá, že to mají, ale jak to dělají a hlavně kam to chtějí dál rozvíjet. Uvedu příklad.

Do you use source control? No, znáte někoho, kdo nepoužívá v softwarovém vývoji VCS? Je možné, že někdo takový existuje, ale mě to přijde podobný "standard", jako když má dnes každý mobilní telefon. Co mě bude bude u VCS zajímat je, co mají navíc - mají nějaké metodiky/guidelines (pro branchování, mergování, tagování, komentování atd.), nějaké propojení na další nástroje? Chápu, že se někdo cítí jako šampion, že používají Git. Ale že by mi z toho spadla čelist? Asi ne :-/

Kde zůstal agilní vývoj?

Joel svůj test publikoval v létě 2000. Půl roku poté byl publikován jiný dokument, který měl nesrovnatelně větší vliv na celou následující dekádu. A je platný podnes - Agile Manifesto. Věřím :-) že všichni čtenáři ví, co tím myslím. A jen pro jistotu - agilní vývoj existoval dávno před manifestem (např. Scrum Methodology byla publikována v roce 1995).

Zdá se mi to, nebo v Joelově testu mnoho z agilních technik není? Při troše dobré vůle se některé body dají interpretovat agilně. Třeba Do you fix bugs before writing new code? Ale když si přečtete Joelovu argumentaci, tak zjistíte, že se opírá o zkušenosti a manažerská rozhodnutí v Microsoftu při psaní Wordu.

Očekával bych, že něco z agilního vývoje by se mělo do testu promítnout. A když už ne v době jeho vzniku, tak alespoň později, kdy už byly jednotlivé techniky široce adoptovány.

Je to jediný test k dispozici?

Joel má štěstí, že je slavný a tak jeho test zná (a uctívá ;-) hodně lidí. Ale jsou i jiné testy. Například když jsme o tomhle tématu disputovali na Twitteru s Banterem, tak mě odkázal na The Rands Test.

Randse mám rád a jeho test má taky něco do sebe. I když je o něčem jiném. Ale pro SW engineera je stejně podstatný, jako ten Joelův.

Jiným příkladem obdobného testu je ten uvedný v knize Leading Lean Sotfware Development. Mary Poppendieck v něm radí, ať si jednotlivé "disciplíny" obodujete od 0 do 5. 0 znamená, že jste o ní nikdy neslyšeli a 5, že o ní můžete přednášet. Pokud máte z nějaké disciplíny 3 a méně, měli byste se zaměřit na to, jak se v ní zlepšit.
  1. Coding standards (for code clarity)
  2. Design/code reviews
  3. Configuration/version management
  4. One-click build (private and public)
  5. Continuous integration
  6. Automated unit tests
  7. Automated acceptance tests
  8. Stop if the tests don't pass
  9. System testing with each iteration
  10. Stress testing (application- and system-level)
  11. Automated release/install packaging
  12. Escaped defect analysis and feedback
Mary má svůj test zasazený do daleko širšího a hlubšího kontextu - test se nachází v kapitole Technical Excellence, což je jedna ze složek Lean Developmentu.

Kdyby člověk hledal, určitě najde nějaké další testy. Uvedl jsem jen ty, na které jsem narazil, aniž bych je nějak hledal. Pokud znáte nějaké zajímavé exempláře, budu rád, když je zmíníte v komentářích.

Joel test, má ještě smysl?

Má, samozřejmě, že má. Jenom je potřeba si uvědomit, že dobrý výsledek v něm není známkou nějaké výjimečnosti. Z mého pohledu je to (v dnešní době) jen checklist, že firma/projekt dosahuje v našem oboru běžného standardu.

Joelův test také může být inspirací, pokud si chci podobný test vytvořit, s přihlédnutím ke svým potřebám (technologická/business doména, používané/zamýšlené nástroje a metodiky atd.). Určitě je to dobrý základ, na kterém se dá stavět.

Mám-li zhodnotit Joelův přínos historii :-)  tak spíš než za tento test, jsem mu vděčný, že založil Stack Overflow. Jeho test je výrazným počinem v historii našeho oboru. Ale jak říká Roy Batty: "All those moments will be lost in time, like tears in rain."

8. června 2013

Měl by mít vývojář portfolio?

Jednou z činností, které vás, jako seniorního vývojáře, mohou potkat, je dělání pohovorů s kanditáty, kteří by chtěli ve vaší firmě pracovat. Řekl bych, že je to docela zodpovědná (a zajímavá) činnost. Přece jenom, vybíráte své potencionální kolegy.

Přesto bývá (dost často) tento úkol pojat nekoncepčně a nahodile. Pohovor dělá, kdo má zrovna čas, zkouší se věci, které s prací přímo nesouvisí, v rámci firmy to každý dělá "trochu" jinak... Tak jako v jiných oblastech, i zde je známkou kvality konzistence.

Před časem jsem psal, jak dělám java pohovor já, kde jsem popsal postup, který používám cca poslední dva roky. (Teď se změnou zaměstnání jsem v něm provedl dvě úpravy, o kterých napíšu, až si to trochu "sedne".) Jedním z bodů, který po vývojářích vždycky chci, je, aby mi před pohovorem poslali ukázku svého (java) kódu dle vlastního výběru. Pojďmě se na to podívat trochu zevrubněji.

Proč chci ukázku kódu?

Kromě úvodní informační části pojímám interview jako diskuzi. Je to diskuze mezi mnou - team leaderem, či architektem - a potencionálním kolegou. Své názory umím hájit, ale nejsem autoritativní - myslím, že nejlepší řešení vyrůstají z kvalitní diskuze.

Kód, který mi kandidát pošle (a který pak spolu probíráme), je pro mne podkladem pro takovou diskuzi. V kódu si pomocí TODO označím místa, na která se chci zeptat. Jsou to místa, která mě nějak zaujmou - nejsou mi třeba jasný, jsou inspirativní, anebo je považuji za chybná. Nad tím pak diskutujeme.

Jak říkám, nejsem autoritativní, nemám dopředu připravený jedno řešení, které chci slyšet; takže pokud je kandidát schopen své řešení obhájit, je to skvělé. V pořádku je, i pokud přizná chybu, že něco není úplně OK, dneska by to udělal jinak apod. Špatným znamením je, pokud k tomu kandidát nemá co říct.

Je to podobný, jako bychom  byli spolu na projektu a diskutovali refactoring nějakého staršího kódu. Nebo dělali code review. Takže věc, kterou - pokud se staneme kolegy - budeme v budoucnu běžně dělat.

Dobré je, že nediskutujem nějaké moje řešení. Je to kandidátův přínos k diskuzi - on zná kontext kódu, on může poukázat na pěkný design, zajímavou implementaci, efektivní algoritmus. A nebo aspoň dobře odvedenou práci. Pamatujete? Je to kód dle vlastního výběru. Čili kandidát volí prostor k diskuzi. Protože nejde jen o tu diskuzi - také se ptám: Proč jste se rozhodl mi ukázat právě tento kód?

Ta otázka je důležitá. Občas lze narazit na kandidáty, kteří prostě "obcházejí pohovory". A stejně tak, jako nevěnují pozornost dané firmě (prostě jen hledají jakoukoliv práci), nevěnují pozornost ani kódu, kterým se prezentují. Přitom je to úžasná možnost představit se v dobrém/nejlepším světle a vystoupit z řady (jiných kandidátů).

Kde vzít kód?

Někdy se setkám s tím, že daný vývojář řekne něco ve smyslu: "Ale já žádný kód na ukázku nemám. A to co momentálně píšu na projektu, nemůžu/nesmím dát k dispozici třetí straně." To zdánlivě vypadá jako show-stopper. Ale není.

Já samozřejmě nechci, aby někdo porušoval NDA. To je neetické. Ale i v takové situaci se dají věci řešit. Když se chce. V první řadě, je dobré si zjistit, co je předmětem NDA. Moje osobní zkušenost je, že to vývojáři většinou nevědí. Zkrátka "něco" podepsali. V takovém případě je dobré se zeptat někoho, kdo to ví.


Já když jsem chtěl ve své diplomové práci použít část práce, kterou jsem dělal pro tehdejšího zákazníka, tak jsem se jednoduše zeptal firemního právníka. Ten se podíval do příslušné smlouvy a řekl: "jo, můžeš to použít, akorát uveď zdroj. A pro jistotu, udělej tyhle anonymizační kroky: ..."

Čímž je řečena jedna možnost, jak to řešit. Ať už jste podepsali cokoliv, nikdo vás nemůže zbavit autorství vašeho kódu. A pokud kód "dostatečně" zanonymizujete, neměl by nikdo nic namítat. Otázkou je, jak určit, kolik to je "dostatečně". Nevíte-li, máte "tvrdé" smlouvy, máte pochybnosti - konzultujte.

Další možností je napsat nový kód. Cože?! Mám napsat nový kód? Práce navíc?! Jo, přesně tak. Chcete tu práci. Nebo ne? Já prostě chci vidět na pohovoru váš kód. Pokud nemůžete využít předešlou, nebo následující možnost, je to také jedna z cest. Já vám umožňuji prezentovat kód dle vašeho výběru. Tak napiště něco, co vás baví. A nemusí toho být moc. Nějaký návrhový vzor, vychytaný algoritmus, vyřešený problém, co vás před časem zaujal? To je ono! Myslím, že byste si to mohli užít. Pokud ne, asi jste se minuli povoláním. V tom případě... nemám zájem.

Nejjednodušší samozřejmě je, pokud nějaký kód, který můžete ukázat, máte k dispozici. Možná ho máte na GitHubu, Bitbucketu, nebo doma v kredenci. Třeba máte archiv minulých projektů, nebo schované nějaké prototypy. Každopádně máte něco, co se dá rovnou vzít a ukázat. Za takový kód se asi nebude stydět - nechali jste si ho přece z nějakého důvodu, ne? A tím se dostáváme k jádru tohoto článku.

Měl by mít vývojář portfolio?

Pokud přijdete (jako vývojář) někam na pohovor a přinesete s sebou ukázku své práce, buďte si jistí, že jste minimálně vystoupili z řady ostatních uchazečů. Téměř nikdo to totiž nedělá. A pokud vaše úkázky za něco stojí (nebo jsou dokonce excelentní ;-)  je dost pravděpodobné, že jste ostatní kandidáty zastínili. To ještě neznamená, že to máte v kapse. Ale výrazně jste zvýšili svoji šanci na úspěch.

Řeknu vám svůj příběh. Když jsem se ucházel o práci  (java vývojáře) u svého minulého zaměstnavatele, byla to jediná firma, kterou jsem oslovil - líbila se mi a vybral jsem si ji jako místo, kde bych chtěl pracovat. Na pohovor jsem si (sám od sebe) přinesl ukázky svého kódu, screenshoty aplikací (tehdy jsem dělal hodně frontendů) a taky generovanou dokumentaci ke svým aplikacím. A krátce jsem svou práci u pohovoru představil. Nevím, jaký to mělo vliv na mé přijetí. Faktem je, že jsem dostal vyšší nástupní plat, než jsem si sám řekl.

Když jsem se ucházel o svou současnou práci, nepřinesl jsem si na pohor nic. (Ha!) Důvodem je, že jsem nehledal práci vývojáře. Resp. rád bych si trochu zakódoval (tak z 1/3), ale hlavně mě zajímala práce team leadera (vývojářů). A taky architekta. Takže místo ukázky kódu jsem dal na vrchol svého CV odkaz na svůj blog (kde o těchto věcech píšu) a u pohovoru jsem se snažil tyto témata prezentovat a čerpat z nich. Myslím, že to fungovalo :-)

Takže jaká je odpověď na titulní otázku? Je subjektivní a není jednoznačná. Ale já se kloním k názoru, že vývojář by portfolio mít měl. Za každého hovoří jeho práce. A ta není někde v CV nebo mezi slovy na pohovoru. Je v textovém souboru někde na disku. Je tam, nebo ne? ;-)

Související články


Související externí články