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

• Management za zavřenými dveřmi
• (Ne)funkční tým
• Manažerem humorně a kousavě

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

• Gradle, moderní nástroj na automatizaci

Související externí články

• Build Script Basics (Gradle User Guide)
• More about Tasks (Gradle User Guide)
• Task (Gradle DSL Reference)

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?

@sw_samuraj Ad Joelův test, ano, je 13 let starý, ale co místo něj. http://t.co/zbupwRXQKs ho stále používá.
— Luboš Račanský (@banterCZ) May 23, 2013

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."

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 už 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í.

Noise to Signal Cartoon

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

• Jak dělám java pohovor
• Jak dělají java pohovor jinde
• Geek, který zapadne

Související externí články

• Lester and Rothman: Do You Need a Portfolio?

Mercurial, jak nastavit P4Merge jako nástroj pro vizuální merge a diff

Mercurial je výborný distribuovaný verzovací systém (DVCS). Je free a má spoustu zajímavých vlastností. Perforce (P4) je centralizovaný verzovací systém. Má převážně komerční licenci a výborné nástroje na mergování a branchování. Co můžou mít tyto dva systémy společného?

P4Merge

P4Merge je grafický nástroj pro merge a diff. Je jednou ze silných zbraní P4. Já jsem ho vždycky rád používal. Jeho výhodou je, že akceptuje parametry z příkazové řádky, takže jej lze použít i mimo rámec P4 a to buď úplně samostatně, nebo jako externí nástroj z jiné aplikace. Třeba Mercurialu :-)

Diff pomocí P4Merge

Podle toho, kolik parametrů se zadá na příkazové řádce, se spustí buď diff (2 parametry), nebo merge (3-4 parametry). Každý parametr je cesta k porovnávanému souboru.

Parametry příkazové řádky P4Merge

P4Merge sice není open source, ale je free, takže nic nebrání jeho zakomponování do jiného nástroje.

Konfigurace Mercurialu

Mercurial neobsahuje nástroj na vizuální merge. Pokud je potřeba zmergovat konfliktní změny a žádný nástroj není nakonfigurovaný, tak Mercurial vloží do sloučeného souboru mergovací značky (takový to <<<<<<<<<<< something). To asi nechceme :-)

Mergovacích nástrojů existuje spousta, každý si určitě vybere. Já jsem si oblíbil P4Merge - přece jenom, když něco s oblibou používáte dva roky, tak vám to trochu přiroste k srdci. Jak teda Mercurialu podstrčíme P4Merge?

Konfigurace merge nástroje je v souboru ~/.hgrc v sekci [merge-tools]:

[merge-tools]
p4.priority = 60
p4.premerge = True
p4.executable = p4merge
p4.gui = True
p4.args = $base $other $local $output
p4.binary = False

[extensions]
hgext.extdiff =

[extdiff]
cmd.p4diff = p4merge
cmd.meld = meld

Jak je vidět, nastavil jsem si kromě merge nástroje i externí diff. Takže když pustím příkaz hg p4diff file1 file2, spustí se mi také P4Merge, tentokrát jako diff nástroj.

Merge pomocí P4Merge

Je to opravdu taková idyla?

Není. Abych byl maximálně spokojený, chybí mi (zatím) dvě věci. Jednak bych rád, abych mohl provést hromadný merge - Mercurial totiž dělá to, že pro každý mergovaný soubor sekvenčně spustí P4Merge. A já bych chtěl např. hromadně přijmout příchozí, nebo své změny. Což je věc, kterou P4 normálně umí. Ale asi je to zajištěno přes P4V klienta.

Druhá vada na kráse je, že P4Merge neumí diff více souborů (např. příkaz hg p4diff -r 12:tip). Takže ho nemůžu použít pro vizuální diff mezi revizemi. To je důvod, proč mám v souboru .hgrc jako další externí diff nástroj Meld, který diff adresářů umí.

Meld, vizuální diff mezi revizemi

Máte nějaké tipy na používání P4Merge, nebo jiného vizuálního nástroje na merge v Mercurialu? Budu rád, když se podělíte o své zkušenosti v komentářích.

Související články

• Perforce best practices

Gradle, moderní nástroj na automatizaci

Gradle je nástroj na automatizaci. Potřebujete udělat build, mít Continuous Integration, zprovoznit deployment, generovat dokumentaci, připravit release, dojít nakoupit a vyvenčit psa? Gradle je to pravé pro vás! Gradle je něco jako Ferrari, Land Rover a Mini Cooper v jednom. A funguje to.

Gradle? Co to je?

Gradle je nástroj na automatizaci. Čehokoliv. Zmáčknete tlačítko a vypadne banán :-)  Nejčastější využití asi bude na build nějakého projektu. Ale není potřeba se svazovat jen touto představou - jakmile potřebuju něco zautomatizovat, můžu na to použít Gradle (třeba na generování a odesílání měsíčních výkazů).

Gradle ve skutečnosti není automatizační nástroj - je to jazyk pro automatizaci. Je to Domain Specific Language (DSL), který nám umožňuje popsat to, co chceme zautomatizovat. Nepřekvapí, že Gradle je založený na Groovy (jestliže byl Groovy v něčem úspěšný (oproti svým konkurentům z oblasti dynamických JVM jazyků), tak je to právě jeho využití ve sféře DSL).

Výchozí těžiště Gradlu leží v buildování. V tomto směru na něj lze nahlížet jako na nástroj další generace v linii Ant -> Maven -> Gradle, přičemž ze svých předchůdců si bere (a kombinuje) to nejlepší: z Antu jeho sílu a flexibilitu, z Mavenu konvence, dependency management a pluginy.

Jádro Gradlu samo o sobě toho moc neumí - zkuste si po instalaci pustit příkaz gradle tasks. Distribuce Gradlu ale obsahuje sadu standardních pluginů, takže out-of-the-box je k dispozici podpora pro Javu, Groovy, Scalu, Web, OSGi aj. Další funkčnosti jsou k mání přes komunitní pluginy.

Tak jako spousta skvělých věcí v životě i Gradle je zadarmo - je k dispozici s licencí Apache License, Version 2.0.

Je opravdu tak dobrý?

Pokud jste se s Gradlem ještě nestkali, možná jste na pochybách, jestli má smysl se jím vůbec zabývat. Vždyť přece buildujeme Mavenem/Antem, tak na co další další nástroj? Třeba vás přesvědčí, že mezi uživatele Gradlu patří např. Spring, Hibernate, Grails, Software AG, nebo LinkedIn.

Dalším důvodem, proč u Gradle zpozornět je, že byl již podruhé uveden v prestižním(?) přehledu ThoughtWorks Technology Radar. V tom aktuálním z října 2012 je Gradle umístěn v sekci Trial, což znamená "Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk."

Konkrétně o Gradlu a buildovacích nástrojích je zde napsáno: "Two things have caused fatigue with XML-based build tools like Ant and Maven: too many angry pointy braces and the coarseness of plug-in architectures. While syntax issues can be dealt with through generation, plug-in architectures severely limit the ability for build tools to grow gracefully as projects become more complex. We have come to feel that plug-ins are the wrong level of abstraction, and prefer language-based tools like Gradle and Rake instead, because they offer finer-grained abstractions and more flexibility long term."

[update 7. 6. 2013] Aktuálně vyšel nový ThoughtWorks Technology Radar (květen 2013), kde se Gradle posunul do sekce Adopt, čili: "We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects." [/update]

My Way

O Gradlu jsem se dozvěděl v roce 2009, kdy jsem byl na přednášce CZJUGu v tehdejším Sunu (R.I.P.). Měl jsem to štěstí, že přednášejícím byl Hans Dockter - zakladatel a leader Gradlu (Hansova původní prezentace je v archivu CZJUGu).

Gradle se mi tehdy zalíbil. Vyzkoušel jsem ho a použil na pár vlastních drobných Java a Groovy projektech. Gradle byl tehdy ve verzi 0.8 a když se podíváte na historii verzí, je vidět, že to byla velmi čerstvá záležitost.

Mezitím urazil Gradle dlouhou cestu: 7. května vyšla verze 1.6 a osobně si myslím, že Gradle je dostatečně zralá technologie pro nasazení do enterprise prostředí. Nejsou to plané řeči - na posledním projektu jsem zvažoval, na čem postavit release management a po zralé úvaze, kdy ve hře byl kromě Gradlu také Maven, Ant, čisté Groovy a shell skripty, jsem zvolil právě Gradle jako řešení, které nejvíce vyhovovalo dané situaci a bylo dostatečně robustní, srozumitelné a rozšiřitelné, aby fungovalo i po mém odchodu z projektu.

Právě při přípravě release managementu tohoto projektu jsem se musel do Gradlu důkladně ponořit, protože jsem musel vyřešit některé ne úplně triviální záležitosti. Abych nabyté vědomosti nějak zúročil, uspořádal jsem rozlučkovou přednášku o Gradlu ve svém bývalém zaměstnání. Přednáška je k dispozici na SlideShare:

Tutorial

No a abych nabyté vědomosti ještě více zúročil :-)  rozhodl jsem se napsat o Gradlu tutorial, který budu na svém blogu postupně publikovat. Jednak bych si formát tutorialu rád vyzkoušel, ale hlavně bych se chtěl o své zkušenosti podělit. Právě sdílení informací je jedna z věcí, které mne (jako seniorního vývojáře) baví.

Pokud se již nemůžete dočkat první lekce, můžete si čekání ukrátit instalací Gradlu. V tutorialu budu používat nejaktuálnější verzi 1.7, která je dostupná v nočních buildech, ale můžete použít i stabilní verzi.

Pokud máte nějaké téma, které byste rádi v tutorialu viděli, napište mi a já se ho pokusím někam zařadit. No a samozřejmě budu rád za každý komentář.

[update 7. 6. 2013] Domluvil jsem se se serverem Zdroják, že budu (přednostně) tutorial publikovat i tam (seriál Gradle - moderní nástroj na automatizaci). Vzhledem k "publikační mašinerii" tak budou jednotlivé díly vycházet s většími prodlevami, než jsem původně počítal. Ale co to je z pohledu věčnosti? :-) [/update]

Související články

• ThoughtWorks Radar, zajímavé technologie

Cesta samuraje, rok druhý

Tak je to tady, SoftWare Samuraj má druhé narozeniny. A protože je hezké mít nějakou tradici, tak si teď jednu založím. Takže, roční rekapitulace. (Mimochodem, přiznanou inspirací mi v tomto byl N-tý rok Myšlenek Otce Fura.)

Takový souhrn lidé většinou píší k novému roku. Přiznám se, já nemám rád novoroční předsevzetí. Ale rekapitulace je trochu něco  jako lesson learned, takže věc jistě užitečná. Navíc, kolikrát si člověk (pro samou práci) ani neuvědomí, jakou cestu už urazil.

Jak to bylo

Když jsem se ohlížel zpět před rokem, neměl jsem ještě moc jasno, o čem bych chtěl psát, jak blog zaměřit. Taky jsem psal jen příležitostně. Mezitím jsem začal psát pravidelně. Poslední dobou jsem se ustálil na rytmu tři články za měsíc. Což mi časově vychází a doufám, že to vyhovuje i vám, mým čtenářům. Pozitivní je, že témat je stále dost, vyskakujou jako houby po dešti - mám jich běžně v zásobě kolem deseti a pořád neubejvaj. Dokonce musím čas od času některé i zahodit.

Celkové skóre za minulý rok je 31 publikovaných článků. Silnými tématy byly jednak technické věci, zastoupené nejčastěji prolínající se trojicí SOA, integrace, messaging a jednak věci personální - téma pohovorů. Technická témata byla daná hlavně projektově, kde jsem vytěžil několik článků o Oracle SOA Suite, WLST a Kanbanu. Personální témata byla v mém pracovním (nejenom projektovém) životě také často přítomna - dělal jsem desítky pohovorů na několika různých úrovních, plus inspirativní zkušenosti z team leadingu. No a tradičně živné téma pro mne byly samozřejmě (odborné) knihy.

Co cítím jako resty, zbylo mi několik témat z oblasti SOA governance, SOA designu a Perforce (P4). Možná se ještě k něčemu z toho vrátím (no, P4 asi ne).

Wind of Change

Jak to tak v životě chodí, jednou za čas přichází změna. Poslední projekt pro mne byl velmi intenzivním zážitkem. V tom pozitivním smyslu to byly technologie a částečně lidský faktor. V tom negativním to bylo projektové řízení. Ten negativní aspekt byl tak působivý, že se tento projekt pro mne stal katalyzátorem odchodu  - a to nejen z projektu, ale také z firmy, kde jsem pracoval 4,5 roku.

O tom projektu určitě něco napíšu, dost možná, že to bude i série článků (tak vydatný zdroj inspirace to byl ;-)  Ale nechám tomu nějaký čas - když člověk píše o negativních věcech, měl by od toho mít odstup. A taky si k tomu chci načíst nějakou literaturu.

Vizionářské okénko

[intermezzo] Víte, kdo byl (podle mne) nejlepší "počítačový" vizionář? Steve Jobs. Jsem linuxák a Steva jsem nikdy nežral. Ale to co dokázal je úctyhodné (hezky to sepsal třeba Petr Staníček).

A víte, kdo je (pro mne) nejhorší "počítačový" vizionář? Bill Gates. (OK, jsem linuxák... ale třeba Win 7, nebo MS SQL Server používám rád.) Chudák, tomu chlápkovi snad nikdy žádná předpověď nevyšla. A za ten jeho špílec "640K ought to be enough for anybody." by mu měli postavit pomník. (No, prej to možná neřek. Ale stejně je to dobrá hláška. A někdo ji říct musel.) [/intermezzo]

Já se samozřejmě s uvedenými pány nebudu srovnávat. Jen si trochu zavěštím, o čem byste si mohli přečíst v příštím roce. Některé věci budou přímo spjaté s mojí novou prací, takže bych čekal něco o security (zatím nemůžu být víc specifický konkrétnější), něco o verzovacím systému Mercurial a možná i nějaký JBoss 7. A opět team leading.

Mezi témata spjatá s prací volněji (anebo vůbec) patří nástroj na automatizaci Gradle, o kterém bych chtěl napsat tutorial a také bych se chtěl vrátit k Hadoopu (což se mi pořád ne a ne podařit). Tak uvidíme. O čem byste si rádi přečetli vy?

Související články

• Změna domény a malá rekapitulace
• Druhý rok s Kindlem