SoftWare Samuraj

V létě jsem psal o tom, jak na mne nečekaně spadla implementace Kanbanu (post Kanban z čistého nebe). Turbolence na projektu mě mezitím zavály jinam, nicméně aby moje investice nepřišla nazmar, udělám si jakési lesson learned.

Co je to Kanban?

Protože tenhle článek je hlavně o implementaci Kanbanu, uvedu pouze krátkou definici pro neznalé. Odkazy pro další informace o Kanbanu najdete v článku Kanban z čistého nebe.

Takže. Kanban je metoda pro limitování rozpracované práce (work-in-progress), která vychází z Lean developmentu a je definovaná pěti základními principy:

Vizualizuj workflow.
Limituj rozdělanou práci.
Měr a spravuj flow.
Udělej procesní politiky explicitní.
Používej modely pro rozpoznání příležitosti ke zlepšení.

Obecně o projektu

Úkolem daného projektu bylo dodat sadu webových služeb (cca 60 business služeb). Daná technologie je z hlediska Kanbanu nepodstatná. Služby by měly splňovat základní SOA pradigmata - být autonomní, volně propojené (loose coupled), s velkou granularitou (coarse-grained). Implementované služby byly zasazeny do klasické middleware architektury, která vypadala velmi zhruba takto:

Vývoj služeb byl trekován v JIRA: co služba, to (GreenHopper) user story. Z hlediska projektu (Kanbanu) byly všechny dodávané služby unifikované - jejich dodávka se sestávala vždy ze stejných kroků, což Kanbanu (ale stejně tak třeba i Scrumu) vyhovuje. Jednotlivé kroky byly v JIRA vedeny jako technické subtasky dané user story.

Kontrakt. Definice WSDL a příslušných XSD schemat.
Mock. Jednoduchá implementace služby bez orchestrace, business logiky a volání backendů, tak aby frontendové komponenty měly vůči čemu vyvíjet.
Implementace. Plná implementace služby včetně orchestrace, volání backendů, číselníkových překladů atd.
Unit testy. Unit testy validací, orchestrace, business logiky, fault handlingu apod.
Dokumentace. Jednak sebepopisná dokumentace kontraktu, jednak model orchestrace služby v CASE nástroji.
Continuous Integration. Build, deployment, unit testing a undeployment v CI nástroji.

Dodávka služby končila nasazením služby na SIT (System Integration Test) prostředí.

Něco málo o týmu

Na projektu jsme začínali dva. Pak to bez varování vyskočilo až na neúnosných 17 lidí, aby se to po nějakém čase ustálilo na rozumných 10 vývojářích.

Tým byl tvořen z 90 % seniorními vývojáři, z nichž všichni se s Kanbanem setkávali poprvé. Lidé v týmu byli přátelsky a pozitivně naladěni a naštěstí se nenašel žádný kverulant, který by se metodiku snažil sestřelit.

Implementace 5 principů Kanbanu

Následujících pět sekcí je gró tohoto článku, aneb jak jsme se vypořádali s implementací jednotlivých principů Kanbanu.

1) Visualize Workflow

Vizualizuj workflow. Workflow jsme měli ve dvou provedeních, ve vztahu master-slave. "Pravda" byla v issue tracking nástroji JIRA, kde jsme používali agilní plugin GreenHopper (jeho Kanban část). JIRA byla mým hlavním nástrojem pro řízení týmu.

Elektronický JIRA Rapid Board

JIRA má pro klasický Kanban Board vlastní název - Rapid Board. Vstupem do něj je běžný JIRA filtr, v obrázku výše jsou vyfiltrované pouze technické subtasky.

Obrazem elektronického workflow v JIRA byl fyzický Kanban Board, vytvořený z whiteboardu a lepicích lístečků. Každý člen týmu měl za úkol synchronizovat své úkoly v JIŘe s fyzickou tabulí.

Fyzický Kanban board

Podobně jako v JIŘe byly vyfiltrovány pouze technické subtasky, tak i na fyzické tabuli byly jenom subtaskové lístečky. Subtasky z jedné user story se v sekci Done lepily na sebe a když byla user story kompletní, nahradily se lístečky lístkem jiné barvy, který reprezentoval danou user story.

2) Limit Work-in-Progress

Limituj rozdělanou práci. Nastavení správného počtu úkolů, které mohou být v jednu chvíli rozpracovaný, je jedním z nejtěžších úkolů v Kanbanu. Hodně tady může napomoct teorie front a samozřejmě empirické zkoušení, testování a měření.

V Kanbanu se někdy nastavuje pouze horní limit, já jsme nastavil horní i spodní a sice spodní limit byl počet vývojářů (velikost týmu mínus teamleader) a horní limit na dvojnásobek vývojářů. Každý vývojář tak musel mít přiřazený minimálně jeden úkol, ale maximálně mohl mít rozpracovaný pouze dva tasky.

3) Measure and Manage Flow

Měr a spravuj flow. Flow se v Kanbanu typicky zobrazuje pomocí diagramu Cumulative Flow, což dokáže i JIRA. Na obrázku níže představují barvy jednotlivé sekce ve flow: oranžová - To Do, modrošedá - In Progress, zelená - Done.

Diagram má dva důležité rozměry. Horizontální délka dané sekce (nebo sekcí) říká, jak dlouho byl průměrně úkol v odpovídajícím stavu. Pokud vezmu například oranžovou a modrošedou barvu (= To Do + In Progress), říká mi tím diagram, jak (průměrně) dlouhý čas uběhl od zadání tasku do JIRy po jeho implementaci. Pokud bych vzal pouze úkoly ve stavu In Progress, dostávám velocitu tasku - jak dlouho trvala implementace úkolu.

Vertikální délka dané sekce říká, kolik bylo úkolů v dané sekci v určitý čas. V případě tasků v In Progress by to mělo odpovídat limitům WIP.

Ideálním stavem pro Kanban je, pokud je "tloušťka" tasků v In Progress (šedomodrá) více méně konstantní a rovnoměrně rostoucí. Alarmujícím příznakem je zvětšující se sekce To Do, což znamená, že se nám fronta začíná zahlcovat.

Diagram Cumulative Flow v JIRA

Tolik teorie. V praxi tady vidím (u sebe) dluh, protože jsme nedokázali měřit velocitu týmu. JIRA sice umí vytvořit diagram kumulativního flow, ale neumožňuje s těmi daty nijak pracovat, tj. nejsem schopen spočítat, kolik tasků je tým schopný udělat např. za týden (velocita týmu) a jak průměrně dlouho trvá implementace úkolu. (Kdybych se mýlil a věděli byste, jak tyto údaje z JIRy dostat, dejte mi, prosím, vědět v komentářích.)

Inkriminované údaje by se daly například spočítat v Excelu, ale ten se mi nechtělo ručně vést, takže jsem na jejich zjištění rezignoval a pouze vizuálně kontroloval diagram, jestli nedochází k nějakým extrémním výkyvům.

Co se týká správy flow, průběžně jsem ho měnil podle zpětné vazby od týmu a také podle vlastní úvahy, jak jsem nad ním přemýšlel a pracoval s ním. Jako příklad můžu uvést nové stavy Blocked, In Test, nebo To Review.

[update 13. 2. 2013] V komentáři jsem dostal odkaz na výborný obrázek, kde je Cumulative Flow diagram krásně vysvětlený:

Jak rozumět diagramu Cumulative Flow (zdroj Paul Klipp)

[/update]

4) Make Process Policies Explicit

Udělej procesní politiky explicitní. Procesní politiky jsme měli v podstatě pouze dvě, jednu z nich nepsanou. Ta definovala jak a kdo je zodpovědný za jednotlivé tasky v průběhu flow. Ačkoliv vznikl její model (viz další bod), nebyl do týmu v daném čase publikován.

Kromě toho existoval na týmové wiki dokument s Definition of Done (DoD) pro jednotlivé technické subtasky. Tento dokument byl na wiki z toho důvodu, že jak už jsem psal výše, jednotlivé user story byly unifikované, takže nebylo potřeba uvádět DoD pro každý subtask do JIRy, ale dal se použít jeden centrální dokument vůči kterému šlo úkoly validovat.

5) Use Models to Recognize Improvement Opportunities

Používej modely pro rozpoznání příležitostí ke zlepšení. Tenhle ten princip jsem dosti dlouho ignoroval, protože jsem nevěděl jak ho uchopit a z počátku mi přišly daleko důležitější první tři principy Kanbanu. Nicméně, jeden model jsem nakonec vystřihnul. Jeden obrázek je za tisíc slov, takže jak fungovalo "samoobslužné" zpracování tasků:

Model flow

Barvy v obrázku odpovídají jednotlivým stavům v diagramu cumulative flow (To Do, In Progress, Done). Pokud přišel požadavek na novou službu, team leader jej rozpadl na jednotlivé subtasky (kontrakt, mock atd.) a zadal je do JIRy, kde je zprioritizoval.

Vývojáři si potom sami brali prioritní tasky a implementovali je. Hotové úkoly, ve stavu Done, pak reviewoval team leader.

Zlepšení flow, které mne díky tomuto jednoduchému modelu napadlo (ale už jsem neměl čas je zrealizovat) je přesunutí Review na roli vývojáře. Podobně, jako si vývojáři sami brali nové tasky, brali by si sami i tasky na review.

Jak se totiž v praxi ukázalo, Review bylo úzkým hrdlem flow. Jeden člověk (team leader) bude těžko zvládat dělat review a ještě držet agendu 10-15 lidí v týmu. Což je logické, byť to nemusí být na první pohled zřejmé.

Pravidelné týmové aktivity

Samotný Kanban neřeší další týmové náležitosti, ale pro lepší dokreslení řízení projektu je tady taky uvedu.

Denní stand-up

Ráno jsme dělali klasický stand-up meeting. Nepoužívali jsme Scrumovské: "co jsem dělal včera a co budu dělat dneska?" Protože Kanban je zaměřený na flow a odstraňování jeho překážek, zněla otázka:

Co budu dneska dělat a co mi v tom brání?

Týdenní code review

Jednou týdně, v pátek, probíhalo code review, kdy se procházely kontrakty, implementace služeb, unit testy, zkrátka věci definované v Definition of Done. Review probíhalo (s celým týmem) check-outem z verzovacího systému, procházení kódu v IDE a jeho promítání na stěnu, tak aby to viděl celý tým.

Týdenní design review

Jednou týdně, ve středu, probíhalo design review, kdy se procházely návrhy orchestrací služeb, jejich implementací apod. Review probíhalo (s celým týmem) u whiteboardu, kde se ručně kreslilo zadání a diskutoval design.

Shrnutí

Jak už jsem psal v úvodu, Kanban byl pro mne novinka a z počátku jsem k němu přistupoval opatrně. Přece jenom, pár zmršených implementací Scrumu už jsem viděl a Kanban je něco ještě daleko novějšího.

Nicméně, snažil jsem se k tomu přistoupit zodpovědně a myslím, že se nám Kanban podařilo naimplementovat rozumně, korektně a funkčně.

Pokud bych to měl nějak celkově shrnout, myslím, že Kanban je životaschopný způsob, jak řídit vývojářský tým. Je vhodný nejenom pro supportní typy tasků (jak se obvykle traduje), ale i pro vývoj nových funkčností a systémů. Ve velmi dobré symbióze funguje Kanban s vývojem middlewarových služeb, protože požadavky na nové a úpravu stávajících služeb se jaksi přirozeně frontují.

Pokud bych tedy měl někdy v budoucnu volnou ruku ve výběru metodiky, o Kanbanu bych velmi vážně uvažoval.

Související články:

Pokud nějaká aplikace používá JMS zdroje, bývají tyto zpravidla externí. (Výjimkou je JMS broker embeddovaný uvnitř aplikace.) Tyto externí zdroje bývají často vytvořeny na aplikačním serveru, ve kterém je většinou JMS server už obsažen. Pokud naše aplikace používá např. JMS fronty, musí je "někdo" na daném JMS serveru vytvořit. Ten někdo je na vývojovém a někdy i testovacím prostředí vývojář, na dalších prostředích už to bývá administrátor.

Podle daného aplikačního serveru se JMS zdroje dají buď naklikat v nějaké administrátorské konzoli, nebo je potřeba poeditovat/vytvořit nějaké konfigurační soubory. Třetí možností je tyto zdroje nějakým nástrojem naskriptovat. V případě aplikačního serveru WebLogic je takovým nástrojem WebLogic Scripting Tool (WLST).

Jak už jsem psal v minlém zápisku o mazání dat z MDS, WLST je v Jythonu napsaný nástroj pro správu WebLogic serveru, který funguje ve dvou režimech - offline a online. V online režimu se WLST připojuje k běžícímu WebLogicu a operuje nad stromem jeho MBeans. Pro správu JMS zdrojů je potřeba používat WLST online.

Distributed Queue

Věc, kterou jsem potřeboval vyřešit, bylo vytvoření distribuované fronty ve WebLogicovém clusteru. Cluster byl velmi jednoduchý - admin server a dva nody (managed servery). Vzhledem ke clusteru bylo potřeba vytvořit logickou frontu, která by měla stejný JNDI (jako na vývojovém prostředí s jedním nodem) a zastřešovala by fronty na jednotlivých nodech. Na WebLogicu je toto řešeno distribuovanými destinacemi (queue/topic). Pokud si to neumíte představit, distribuovaná fronta funguje v podstatě jako klasický load balancer.

Distribuovaná fronta (WebLogic Administration Console)

Členové distribuované destinace (WebLogic Administration Console)

WLST a JMS

Použití WLST je po krátké praxi poměrně intuitivní a jednoduché. Zpočátku může dělat problém se orientovat ve struktuře (stromech) MBean. V tomto může napomoci celkem slušná dokumentace: navigace MBeans, Javadoc a MBean reference. Pak už stačí jenom lehké základy Pythonu.

V následujícím skriptu je několik věcí, které můžou trochu ztížit čtení/pochopení skriptu, takže ještě kratičká legenda:

Target. Cílové umístění zdroje, nebo aplikace, např. server, cluster, JMS server ad. V případě deploymentu (aplikace) tím říkám, na které nody/clustery chci aplikaci nasadit.
SubDeployment. Mechanismus pro seskupení a umístění JMS zdrojů. V rámci subdeploymentu říkám, na které cíle (targets) chci dané zdroje nasadit. Může to být libovolná kombinace, nebo podmnožina.
cmo. Proměnná, která reprezentuje "aktuálně spravovaný objekt" (current management object). Je to vlastně MBeana, která má momentálně "focus". Tak, jak se prochází stromem MBean, tak se tato proměnná automaticky mění.

# properties
user = 'weblogic'
password = '<password>'
server = 't3://<host>:7001'
subDeploymentName = 'EVMJMSServers'
queuePath = 'JMSResource/SOAJMSModule/UniformDistributedQueues/'
queueName = 'EVM_DLQ'
jndiPrefix = 'jms/b2b/'
loadBalancing = 'Round-Robin'

# connection
connect(user, password, server)

# edit mode
edit()
startEdit()

# get targets
s1 = getMBean('/JMSServers/SOAJMSServer_auto_1')
s2 = getMBean('/JMSServers/SOAJMSServer_auto_2')

#
# create a SubDeployment
#
cd('/JMSSystemResources/SOAJMSModule')
# delete an old SubDeployment
if cmo.lookupSubDeployment(subDeploymentName):
    delete(subDeploymentName, 'SubDeployment')
# create a new SubDeployment
cmo.createSubDeployment(subDeploymentName)
subDeployment = cmo.lookupSubDeployment(subDeploymentName)
subDeployment.setTargets([s1, s2])

#
# create a ldistributed queue
#
resource = cmo.getJMSResource()
# delete an old queue
ref = getMBean(queuePath + queueName)
if ref != None:
    cd('JMSResource/SOAJMSModule')
    delete(queueName, 'UniformDistributedQueue')
# create a new queue
resource.createUniformDistributedQueue(queueName)
distributedQueue = resource.lookupUniformDistributedQueue(queueName)
distributedQueue.setJNDIName(jndiPrefix + queueName)
distributedQueue.setLoadBalancingPolicy(loadBalancing)
distributedQueue.setSubDeploymentName(subDeploymentName)

# save and finish
save()
activate()
disconnect()
exit()

Související články

Odstranění metadat z MDS

Dneska to bude jen taková variace na minulé téma (vytvoření JMS zdrojů pomocí WLST), aneb jak na WebLogicu vytvořit JDBC datasource pomocí skriptovacího nástroje WLST (WebLogic Scripting Tool).

Podstatné věci o WLST jsem zmínil v uvedeném postu, takže je tady už nebudu opakovat a eventuálně vás pro doplňující informace odkazuji tam.

#
# properties
#
user = 'weblogic'
password = '<password>'
server = 't3://<host>:7001'
dsName = '<datasource>'
dsPath = '/JDBCSystemResources/' + dsName + '/JDBCResource/' + dsName
clusterName = 'soa_cluster'

# connection
connect(user, password, server)

# edit mode
edit()
startEdit()

#
# delete an old JDBC resource
#
if cmo.lookupJDBCSystemResource(dsName):
    delete(dsName, 'JDBCSystemResource')

#
# create JDBC resource
#
cmo.createJDBCSystemResource(dsName)
# set datasource name
cd(dsPath)
cmo.setName(dsName)
# set JNDI name
cd(dsPath + '/JDBCDataSourceParams/' + dsName)
cmo.setJNDINames(['jdbc/' + dsName])
# set driver
cd(dsPath + '/JDBCDriverParams/' + dsName)
cmo.setDriverName('oracle.jdbc.xa.client.OracleXADataSource')
cmo.setPassword('<password>')
cmo.setUrl('jdbc:oracle:thin:@<host>:1521:<SID>')
# set username
cd(dsPath + '/JDBCDriverParams/' + dsName + '/Properties/' + dsName)
cmo.createProperty('user')
cd(dsPath + '/JDBCDriverParams/' + dsName + '/Properties/' + dsName + '/Properties/user')
cmo.setValue('<user>')
# set targets
cd('/JDBCSystemResources/' + dsName)
cmo.setTargets([getMBean('/Clusters/' + clusterName)])

# save and finish
save()
activate()
disconnect()
exit()

Související články

Nedávno jsem psal o tom, jak dělám Java pohovor já. Bylo to napsáno z pohledu toho, kdo zná kontext, ví, jak by měl vhodný kandidát vypadat a také mmj. určuje pravidla, jak bude pohovor probíhat.

Aktuálně mám několik čerstvých zkušeností z opačné strany interview, tak bych se chtěl podělit o své dojmy. Na (Java) pohovoru jsem nebyl již několik let, v podstatě od "krize", kdy jsem si testoval stav trhu :-) a musím říct, že to byla zajímavá profesní zkušenost.

Budu diskrétní, takže nebudu prozrazovat konkrétní zadání a ani nebudu jmenovat jednotlivé firmy. Pro lepší představu pouze uvedu, že ve všech případech šlo o nadnárodní korporace, kde je běžným komunikačním jazykem angličtina. Také se budu věnovat pouze technickým kolům pohovorů, tzn. že různé HR a psychologické srandičky si odpustím.

No, a protože moje paměť je děravá a výběrová, zaměřím se pouze na signifikantní rysy daného pohovoru. Taky vynechám takové ty běžné věci, jako je probírání projektů nad CV.

Co bych předeslal, že měly všechny pohovory společné:

nikde po mně nechtěli vidět můj kód,
nikde po mně dopředu nechtěli nějakou specifickou přípravu
a nikde po mně (naštěstí) nechtěli psaní testů.

Algoritmy na white boardu

Tohle byla taková algoritmová klasika - měl jsem (za předpokladu, že neexistují Java Collections) naimplementovat spojitý seznam. S povděkem jsem si vzpomněl na školní předmět Algoritmy a datové struktury a i po těch cca šesti letech vydoloval celkem slušnou implementaci.

Implementace probíhala na whiteboardu, doplňovaná diskuzí. Debata byla uvolněná a nebazírovalo se na termínech. Výhodou whiteboardu je, že kromě kódu se dají kreslit různé pomocné schématka apod., nad kterými se dá dále diskutovat. A je to takové agilní :-)

Závěr: tohle je celkem příjemná metoda pohovoru, která ale staví na více méně fixních a teoretických znalostech. Navíc tam není moc prostoru pro invenci. Schválně, kolikrát už jste (v Javě) implementovali nějaký základní algoritmus a kdy jste naposledy vymysleli nějakou novou metodu sortování? Nicméně, pokud člověk nepřijde nabiflovaný algoritmy, dá se touto metodou sledovat, jak uvažuje a dobírá se řešení.

Checklist technologií

"Jak dlouho máte zkušenost s J2EE?"
"8 let."
Jak dlouho máte zkušenost s JSF?"
"Rok a půl."
"Musíme to zaokrouhlit na celý roky."
"OK, tak rok."

Na začátku tohohle interview byl seznam asi patnácti technologií, kdy jsem měl říct, jak dlouhou s nima mám zkušenost. Zkušenost musela být vyjádřená v celých rocích. Pak jsme jednotlivé technologie procházeli pomocí kontrolních otázek.

Např. u Java Core to byl vztah metod equals a hashCode. U JPA tři způsoby dotazování (JPQL, Criteria API a native SQL) apod. Platné byly pouze zkušenosti z projektů. Např. to, že mám Flex certifikaci a navrhoval jsem architekturu, kde byl Flex jako frontend, nic neznamenalo (člověk by řekl, že aspoň jednooký mezi slepými králem).

Závěr: pro mne jednoznačné nejhorší zkušenost - člověk je jenom souhrnem aktuálních znalostí, vůbec se nepočítá s nějakým potenciálem, schopností řešit problémy, vymýšlet řešení apod. Navíc ten checklist mi přijde hrozně zavádějící: když jsem Spring Security použil na dvou projektech v délce cca 3 let, ale čisté práce na něm bylo maximálně 3 týdny (konfigurace plus nějakej ten custom handler) - jak dlouhou zkušenost mám s touto technologií?

Algoritmy a rozhraní

Na tomto pohovoru jsem dostal dva příklady. První se týkal "jistého" vyhledávacího algoritmu, implementovaného pomocí dvou zanořených cyklů (mmch. jediný kód, byť na papíře, který jsem na pohovorech viděl). Měl jsem určit, jestli algoritmus pracuje vždy správně, jaká je jeho složitost, jak by se dal optimalizovat, jaká bude jeho složitost po optimalizaci atd.

Druhý příklad se týkal návrhu rozhraní a ev. jeho implementace. Zadání bylo (schválně) velmi volné a strohé, aby podnítilo přemýšlení a diskuzi. Požadavek byl pro mne lehce cizokrajný a příslušná (zevrubná) diskuze mne celkem obohatila (i když výsledné řešení bylo celkem konformní).

Závěr: tohle interview se mi profesně líbilo nejvíc - šlo nejvíc do hloubky, testovalo jak znalost algoritmů, tak přemýšlení nad nejednoznačným problémem. Čili otestovalo jak základní znalosti, tak myšlenkový potenciál.

Moje otázky

Na všech pohovorech jsem se hodně ptal a strávili jsme mýma otázkama poměrně dost času. Měl jsem vždycky připravenou stejnou sadu otázek:

Jaká je struktura společnosti?
Jak velké je oddělení, kde bych pracoval?
Jaký je budoucí kolekiv?
Kdo bude můj šéf a uvidím ho na některém kole pohovoru?
Jak vypadá moje budoucí pracoviště?
Jakým způsobem jsou vedeny projekty?
Jaké se používají metodiky?
(obligátní) Jaké se používají technologie?
Jaké podpůrné technologie se používají (Continuous Integration, Issue Tracking, Version Control)?
Funguje nějaký osobní rozvoj (školení atd.)?
Jak budou vypadat další kola pohovoru?

Mmch. před časem psal o otázkách při pohovoru Banter.

Závěr

Moje dojmy z pohovorů jsou samozřejmě subjektivní a zpětná vazba je většinou minimální - člověk se většinou dozví, jestli byl celkově úspěšný nebo ne, ale nedozví se podrobnosti. Proto se můžu ve svém náhledu mýlit. Protože nastavení pohovoru a jeho vyhodnocení je v rukou tazatele.

Související články

Jak dělám Java pohovor

Tak už jsou tomu dva roky, co jsem si koupil Kindle. A tak jako loni, i dnes si udělám malou inventuru, co vše mi z odborné četby prosvištělo čtečkou. Už pouhým okem je vidět, že jsem toho přečetl sotva polovinu oproti loňsku. Můžou za to tři faktory:

Narodilo se nám druhé dítě. Jak jsem četl někde na (českém) internetu: Jedno dítě, žádný dítě. Dvě děti, moc dětí. Je to pravda.
Cca na polovinu se mi zkrátila doba cesty do práce. A odborné věci čtu převážně v MHD.
Koupil jsem si PlayStation a jako fanoušek série The Elder Scrolls jsem nemohl aktuální počin Skyrim nechat ležet ladem.

Očekávám, že příští rok budu mít na čtení zase více času, protože 1) s dětmi už jsme se časově jakž takž sžili, 2) od května mi cesta do práce bude trvat o dost dýl a konečně 3) Skyrim jsem už prochodil skrz naskrz, takže se budu moci věnovat produktivnějšímu odpočinku.

Co bych tak řekl o Kindlu samotném? Je to fantastická čtečka a já, jako nelítostný čtenář, se jí ani po dvou letech nedokážu nabažit. Je tak skvělá, že já, Linuxák, jsem se rád a dobrovolně upsal Amazonímu DRM. Nicméně kupuju i DRM-free knihy, zejména z produkce Pragmatic Programmer a Manning.

Když už jsme u kupování - všechny knížky kupuju, nebo si nechám koupit od zaměstnavatele. Čas od času se mě totiž někdo, jako vyhlášeného čtenáře, ptá, kde se dají sehnat knížky zadarmo. Odborné legálně téměř nikde. Peníze, které utratím za odborné knížky, beru jako investici do svého vzdělání. A můžu potvrdit, že se to bohatě vrátí.

No a na jakém stroji náš hrdina své dechberoucí, ekvilibristické, čtenářské kousky předvádí? Začínal jsem s modelem Kindle 3 (dnes Keyboard), který se ale chvilku po skončení (americké roční) záruky odebral do křemíkového nebe - nepřežil cestu v batůžky mé dcery. Obratem jsem zakoupil aktuální novinku Kindle Touch (už se neprodává), který mi zatím věrně slouží.

Po cca 3/4 roku s Touchem nechápu, jak jsem mohl být nadšený z nedotykového Kindlu. Nicméně pokud pominu uživatelsky ne úplně povedený Kindle 4 (dárek pro manželku), musím říct, že už leta jsem se nesetkal s něčím tak ergonomickým, jako je (libovolný) Kindle. Všechna čest inženýrům ze Seattlu.

Tak a teď konečně ten seznam:

SOA Patterns - kniha se SOA sice koliduje, ale jde převážně o vzory z oblasti distribuovaných systémů. Ale jelikož u Manningu málokdy vyjde slabý počin, stojí i tato kniha za přečtení.
SOA Governance in Action - další počin od Manningu a tentokrát trefa do černého. Výborný úvod do tématu SOA Governance. Kniha uvádí do kontextu a nabízí okamžitě implementovatelné postupy governance, jako je verzování, lifecycle služeb, security, BAM atd.
Oracle SOA Suite 11g Handbook - 800stránková bichle na téma "co všechno jste chtěli vědět o SOA Suite, báli jste se zeptat a na školení vám to neřekli". Knihu rozhodně doporučuji jako kvalitní zdroj k danému tématu.
Oracle SOA Infrastructure Implementation Certification Handbook - certifikační guide. Celkem slušný úvod do SOA Suite pro někoho, kdo vůbec neví o co jde. Plus sada testovacích otázek a odpovědí ke každému tématu/technologii.
Kanban - ultimátní kniha o Kanbanu. Pokud si chcete Kanban nastudovat opravdu do hloubky, tohle je ten pravý opus.
Kanban for Skeptics - pokud si chcete přečíst knihu o Kanbanu a utratit za ni 0-5 $, tak tahle není špatná.
Lean from the Trenches: Managing Large-Scale Projects with Kanban - skvělá kniha o implementaci Kanbanu a jeho propojení se Scrumem. Nedoporučuji ji jen já, ale třeba taky Mary Poppendieck.
Behind Closed Doors: Secrets of Great Management - pokud na vás spadnou manažerské povinnosti a moc o tom nevíte (nebo to děláte špatně ;-) tak tohle není špatný počin.
Technical Blogging - kniha, která vás provede vším, co obnáší blogování na světové úrovni. A ještě na tom vyděláte (i když ne třeba peníze). Zajímavé jsou kapitoly o sociálních sítích.

Pokud bych měl uvedený seznam nějak zhodnotit, tak v podstatě všechny knihy ze seznamu byly project-driven, takže hlavně SOA a Kanban. Z výše uvedených časových důvodů jsem se nedostal k mnoha dalším tématům, která mne prostě zajímají, ale na projektu je aktuálně nevyužiju; což doufám, že se do budoucna zlepší.

A co vy? Jak jste na tom se čtením? Máte nějaké dobré tipy? Budu rád, když se o ně podělíte v komentářích.

Související články

Půlrok se sešel s půlrokem a já jsem si vystřihnul další certifikaci. Tentokrát jsem chtěl něco, čím bych zakončil své roční působení na projektu a důstojně :-) tak završil trnitý proces získávání znalostí o nové technologii: Oracle SOA Suite.

Okolnosti tomu chtěly, že jsem se zrovna trefil do přelomu, kdy Oracle jednu SOA certifikaci nahrazuje jinou. Aktuální certifikace, která je k dispozici od letošního ledna, se jmenuje Oracle SOA Suite 11g Certified Implementation Specialist. Já, protože jsem se ke zkoušce přihlásil již dříve, jsem nyní obdržel certifikaci Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert. Uff! To je titul :-/

Každopádně, co je nám po jménu? Podstatné je, jestli se obě zkoušky od sebe nějak obsahově liší. Liší? Ano, ale pouze drobně - v nové certifikaci přibylo pouze něco málo o governance, deploymentu a monitoringu, ale gró zůstává stejné: jednotlivé komponentní technogie (viz Exam Topics).

Jak dlouho jsem se na certifikaci připravoval? Přípravě přímo na zkoušku jsem věnoval cca 3 týdny - přečetl jsem si guide (viz dále) a prošel testovací otázky. Ale obecně jsem k certifikaci studijně směřoval téměř celý rok. Za jeden z podstatných zdrojů vědomostí totiž považuji přímou zkušenost s technologií - 7 měsíců intenzivního "programování".

Kniha

Vývoj samotný z učedníka mistra neudělá. Primárním zdrojem informací jsou pro mne knihy, takže od nich jsem začal: hned z počátku práce na projektu jsem si koupil knihu Oracle SOA Suite 11g Handbook.

Jde o 800stránkový opus a pokud to někdo myslí se SOA Suitou vážně, tak rozhodně tuto knihu doporučuji - obsahuje vyčerpávající sumu témat (daleko přesahující rozsah zkoušky), které umožní pochopit principy, které za SOA Suitou stojí a provede návrhem, vývojem, testováním a provozem jednotlivých komponent a technologií. Ještě jednou: vysoce doporučuji!

Školení

Školení obvykle v portfoliu přípravných zdrojů nemám, tentokrát se mi ovšem naskytla příležitost, tak jsem ji využil a absolvoval školení hned tři:

Oracle SOA Suite 11g Implementation Bootcamp
Oracle Service Bus 11g
Oracle BPM Suite 11g Implementation Bootcamp

Školení nebyla špatná. Probíhala formou labů, takže si člověk mohl věci prakticky vyzkoušet. Tematicky školení zkoušku více méně pokrývala (s výjimkou BPM, který v certifikaci není) a umožnila mi trochu jiný pohled na věc, než byl třeba v knize, nebo jsem sám získal praxí. Z pohledu certifikace nejsou školení nutností, ale příjemným bonusem - stejné informace se dají získat i jinde a levněji :-)

Certifikační guide

Krátce před zkouškou jsem pořídil knihu Oracle SOA Infrastructure Implementation Certification Handbook, což je certifikační guide zaměřený na původní zkoušku (1Z0-451). Co se týká obsahu, kniha je slušným, velmi lehkým úvodem do SOA Suite. Jako studijní materiál je nedostačující. Co je na ní cenné, je sada testovacích otázek a odpovědí ke každému tématu, plus závěrečný test (také s řešením).

Závěr

Pokud vezmu v potaz svoji celoroční "přípravu", tak pro mne certifikace splnila (opět) svůj hlavní účel - motivační prostředek pro sebevzdělávání. Tak jako u jiných zkoušek i nyní mě certifikace přinutila podívat se do hloubky i na témata, která nutně (projektově) nepotřebuju a umožnila mi tak lépe pochopit celý kontext dané technologie.

Kecám, nepřinutila - já to dělám rád ;-)

Související články

SOA Suite je zajímavou kompilací technologií, které, poskládány dohromady, stojí na architektonickém principu SCA (Service Component Architecture). Patří sem například implementace BPELu, business rules a human tasků. A jednou z těchto technologií je i Event Delivery Network (EDN), což je implementace paradigmatu Event Driven Architecture (EDA).

Event Driven Architecture

Even Driven Architecture (EDA) může být alternativou, nebo doplňkem k Servisně orientované architektuře (SOA). Ale EDN se netýká pouze SOA - tento architektonický princip najdeme i uvnitř GUI frameworků, jako je Java Swing, nebo Apache (dříve Adobe) Flex.

Jak už napovídá název, vše se v této architektuře motá kolem událostí. Událost je v EDA first-class citizen. Vlastně je to jediný citizen (obyvatel). Ale co to vlastně ta událost je? Událost je v podstatě zpráva, podobně jako zpráva má hlavičku a tělo. V hlavičce jsou samozřejmě meta-data, např. jméno a typ zprávy, timestamp apod. Zásadní rozdíl je v obsahu těla události (payload), ten bývá zpravidla velmi malý a měl by obsahovat pouze popis faktu, který událost instancoval. Někdy payload ani být nemusí - pokud je událost určitého typu, stačí pouze vědět, že nastala.

A jak taková událost zapadá do architektury? Dalším významem akronymu EDA by mohlo být: Extremely Decoupled Architecture. Události, které nejsou nijak svázány s konkrétním producentem, jsou publikovány do nějaké centrální generické infrastruktury. Producenti publikují události stylem fire-and-forget a vůbec se nestarají o to, kdo je jejich konzumentem.

Konzumentem je pak kdokoli, kdo se zajímá o výskyt určitého typu události. Pro konzumenty je původ události neznámý - neví kdo ji publikoval, oni se pouze dozvědí, že nastala. Na konzumentovi pak leží veškerá zodpovědnost za správné business zpracování události. S tím souvisí i to, že příjemce může konzumované události filtrovat.

Event Driven Architecture (barvy představují typy událostí)

Z předešlého komponentového diagramu vyplývá několik věcí. Jednak že v EDA existují v podstatě jen dva základní komponenty - Event Coordinator, který si můžeme představit jako jakýsi "event bus" (podle vzoru service bus) pro události, který se stará o publikování událostí, přihlášení (subscription) konzumentů apod.

A pak jednotlivé uzly (nody). Ty mohou fungovat buď jako producenti událostí (Node 3), nebo jejich konzumenti (Node 2, Node 5), anebo obojí (Node 1, Node 4). Každý node může publikovat nebo přijímat více typů událostí. Že jeden typ události může být konzumovaný více nody asi nikoho nepřekvapí (oranžová událost konzumovaná Nody 1 a 4). Daný typ události ale může taky být publikovaný více producenty (fialová událost publikovaná Nody 3 a 4).

To by, myslím, mohlo stačit, jako takový velmi lehoulilinký úvod do EDA a teď se podíváme na jednu její konkrétní implementaci.

Event Delivery Network

Event Delivery Network (EDN), která je součástí SOA Suite, je infrastruktura (postavená na JMS), která poskytuje deklarativní způsob definice událostí, jejich publikování a registraci jejich konzumace. Tři hlavní entity, se kterými pracuje jsou producent událostí, konzument událostí a události samotné.

Definice události

Události jsou v EDN definované názvem a typem a jsou uloženy v souboru s příponou edl. Tento soubor může být umístěný buď v rootu projektu, nebo v MDS (MetaData Services repository).

<?xmlversion="1.0"encoding="UTF-8"standalone="yes"?>
<definitions
xmlns="http://schemas.oracle.com/events/edl"
targetNamespace="http://sw-samuraj.cz/events/SimpleEvent-v1">
<schema-import
namespace="http://sw-samuraj.cz/events/simpleMessage-v1"
location="xsd/simpleMessage-v1.0.xsd"/>
<event-definitionname="SimpleEvent">
<content
xmlns:sim="http://sw-samuraj.cz/events/simpleMessage-v1"
element="sim:simpleMessage"/>
</event-definition>
</definitions>

Definice události

Typ je popsán pomocí XSD:

<?xmlversion="1.0"encoding="UTF-8"?>
<xsd:schemaxmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sim="http://sw-samuraj.cz/events/simpleMessage-v1"
targetNamespace="http://sw-samuraj.cz/events/simpleMessage-v1"
elementFormDefault="qualified">
<xsd:elementname="simpleMessage">
<xsd:complexType>
<xsd:sequence>
<xsd:elementname="timestamp"type="xsd:dateTime"/>
<xsd:elementname="status">
<xsd:simpleType>
<xsd:restrictionbase="xsd:string">
<xsd:enumerationvalue="ON"/>
<xsd:enumerationvalue="OFF"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

Typ události definovaný v XSD

Publishers

Producentem události může být buď BPEL proces, nebo Mediator. V případě Mediatoru je publikování události přímočaré - v definici akce se místo invoke zavolá raise s patřičnou události.

Publikování události v Mediatoru

Graficky pak vypadá kompozitní aplikace s publikujícím Mediatorem takto:

Mediator event publisher (kompozitní aplikace)

U BPEL procesu je situace maličko složitější. Vzhledem k tomu, že BPEL je otevřený standard, do kterého události nepatří, řeší to SOA Suita (standardním) BPEL extension. Událost se tak dá publikovat pomocí rozšíření z aktivity Invoke.

Publikování události v BPELu z aktivity Invoke

BPEL event publisher (kompozitní aplikace)

Všimněte si, že jak v případě Mediatoru, tak BPELu končí implementace publikování události na dané komponentě. Kdyby totéž bylo implementováno pomocí messagingu, musel by být v kompozitní aplikaci definován ještě JCA adaptér s pevně uvedenou destinací. Tohle u EDA/EDN není potřeba.

Subscribers

Konzumentem události může být opět buď Mediator nebo BPEL komponent.

Subskripce události v Mediatoru

Mediator event subscriber (kompozitní aplikace)

Podobně jako u publikování i u konzumace událostí si BPEL vypomáhá rozšířením, tentokrát v rámci aktivity Receive.

Subskripce události v BPELu v aktivitě Receive

BPEL event subscriber (kompozitní aplikace)

Monitorování událostí

Asi trochu překvapí, že již publikované, ale ještě nezkonzumované události nelze nikde vidět. Alespoň ne standardními nástroji. V podstatě lze vidět pouze "historický otisk" událostí. Něco jako: tudy kráčely dějiny :-)

Cestu události lze vidět v Enterprise Manageru:

Audit trace události (Enterprise Manager)

V uvedeném logu publikuje Mediator Publisher událost, která je konzumována dvěma konzumenty: Mediator Subscriber a BPEL komponent BpelSubscriber. Zároveň je vidět, že Enterprise Manager loguje celou cestu události - ačkoliv jsou producent a konzumenti události od sebe odděleni a vůbec o sobě nemají povědomí, v audit logu je to zaznamenáno jako jeden souvislý tok události.

BPEL nebo Mediator?

Na základě čeho se rozhodnout, kterou komponentu použít pro konzumaci/publikování události? Jednodušší a přímočařejší je použití Mediatoru. Koneckonců to doporučuje i sám Oracle. BPEL má jedinou výhodu - jako konzument může události korelovat. Čili pokud je reakcí na nějakou událost jiná událost a obě dvě jsou zpracovávány stejnou kompozitní aplikací, tak jejich korelace je možná pouze v BPEL procesu.

Závěr

Event Delivery Network (EDN) je standardní součástí SOA Suity a nabízí out-of-the-box implementaci Event Driven Architecture (EDA). Pokud nepotřebujeme robustní a konfigurovatelné messaging řešení, může být EDN vhodnou, rychle provozovatelnou alternativou.

Rozhodně bych ale EDN nedoporučoval použít pro kritické části systému. Byť je postavena na prověřené JMS platformě, její možnosti z hlediska konfigurace, provozování, monitoringu atd. jsou velmi omezené - berte jak to je, nebo nechejte být.

Související články

Image courtesy of Ambro / FreeDigitalPhotos.net

Tento článek je překladem originálu Being the Geek Who Fits, který byl publikován v březnovém čísle časopisu PragPub Magazine. Článek byl poskytnut s laskavým svolením Andyho Lestera.

This article is a translation of the original Being the Geek Who Fits, which has been published in the March issue of the PragPub Magazine. The article has been provided with a kind permission of Andy Lester.

Absolvovali jste několik kol pohovorů na tuhle zajímavě vypadající práci a právě jste dostali nabídku. Peníze jsou slušné, takže řeknete "ano", správně? No, možná ne.

Řekněme, že jdete na schůzku naslepo a věci se vyvíjejí dobře. Jste spolu na večeři a ona se vás ptá na všechno možné, aby zjistila, jaká jste osobnost a jaké máte plány do budoucna. Prostě takové ty věci. Pak spolu jdete na další schůzku, ale tentokrát si s sebou přivede svého bratra a rodiče. Všichni čtyři vás začnou bombardovat otázkami o vašem životě. Potom, po několika hodinách, vám řekne: "Rozhodla jsem se, že jsi pro mě ten správný partner. Pojďme se vzít." Řekli byste právě v tuto chvíli ano? Byli byste blázni, ne?

Zkuste se zamyslet, jak často lidé přijímají pracovní nabídku na základě toho, že je někdo pár hodin griloval a pak jim bylo řečeno, že byli shledáni adekvátními.

Akceptování nabídky od zaměstnavatele je začátek dlouhého vztahu. Je to vztah, kdy strávíte víc hodin v kanceláři, než trávíte bdělí se svým partnerem. Měli byste se ujistit, že to je pro vás ta pravá práce.

Dělání vaší práce, to je pouze polovina vašeho života v zaměstnání. Stejně tak, jako vás šéf hodnotí podle vaší práce a spolupráce s ostatními, byste i vy měli hodnotit společnost podle vaší práce a toho, jak společnost funguje vůči vám. Potřebujete posoudit firemní kulturu.

Firemní kultura není o lidech. Ale lidi jsou její součástí. Pokud je například někdo, koho jste potkali u pohovoru pitomec, tak tam nejspíš nebudete chtít pracovat. Nicméně, to nemusí být dobré kritérium, protože lidé přicházejí a odcházejí a ten pitomec už může být příští týden v jiném zaměstnání. Kultura je konzistentnější. V tomto případě není problémem ten pitomec, ale firemní kultura, která pitomce toleruje.

Většina vašeho porozumění firemní kultuře bude pocházet z rozhovorů během přijímacího řízení. Pamatujte, že interview není výslech, kde jsou kandidátovi kladeny otázky a jinak by měl zůstat zticha. Je to konverzace mezi potenciálními kolegy, kteří diskutují business potřeby organizace a jak by kandidát mohl tyto potřeby naplnit a také, jak by kandidát do organizace zapadl. Oba, kandidát i organizace si musí vzájemně sednout, jinak je tento vtah odsouzen k zániku.

Nedělejte si úsudek o kultuře na začátku přijímacího procesu. Detailní otázky byste si měli schovat, až dostanete nabídku ke spolupráci. Většina vašeho času a energie během přijímacího procesu by měla být zaměřena na získání nabídky. Pokud selžete v získání nabídky, tak vůbec nezáleží na tom, jaká je firemní kultura.

Jakmile ale máte nabídku, rozložení sil se mění ve váš prospěch a nyní je správný čas kulturu detailně prozkoumat. Ptejte se, potkejte se s lidmi a snažte se co nejvíc pozorovat.

Ptejte se

Tady je několik otázek, na které byste, jak budete postupně poznávat společnost, asi rádi znali odpovědi. Uvědomte si, že nejlepší cesta, jak získat odpovědi, nemusí být přímá otázka. Tazatel nezjišťuje, jestli jste pracovitý otázkou "Jste pracovitý?", protože odpověď bude samozřejmě "Ano". Budou ho zajímat příklady, které ilustrují vaši pracovní morálku. Obdobně, když budete chtít vědět, jak společnost řeší krize, zeptejte se, kdy naposled skončil nějaký projekt špatně. Můžete se na tuto otázku zeptat více lidí, ne pouze přijímajícího manažera.

V těchto otázkách používám slovo skupina ve smyslu samostatná pracovní skupina v rámci oddělení, ale tyto otázky lze aplikovat také na úrovni oddělení nebo společnosti. Taky si uvědomte, že žádná z těchto otázek by neměla implikovat, že jeden způsob práce je lepší než druhý. Například úzce provázaný tým není lepší nebo horší než skupina nezávislých pracovníků. Pouze vy rozhodujete, jestli je to kultura, jejíž chcete být součástí.

Pracovní otázky

První věc ke zvážení, vzhledem ke kultuře, jsou otázky o tom, jak věci fungují, o firemních hodnotách, o tom, jaký je každodenní život.

Jak úzce provázaná je skupina? Kolik práce se dělá týmově a kolik individuálně?
Jaké jsou pracovní hodiny? Jak často je potřeba pracovat mimo tyto běžné pracovní hodiny? Je tento extra čas považován za součást práce, nebo je na něj nahlíženo jako na dodatečné úsilí?
Co skupina oceňuje na ostatních? Co váš nový šéf oceňuje na skupině, nebo oddělení? Čeho si společnost cení na svých zaměstnancích?
Jsou nepodařené projekty součástí života? Nebo jsou důvodem k vyhazovu?
Jak tým/oddělení/společnost řeší krize?
Jak vypadá vnitrofiremní komunikace? Jsou zde striktně vymezené informační kanály, nebo jsou zaměstnanci podněcováni, aby mluvili s ostatními odděleními napřímo?
Je skupina otevřená změnám a novým technologiím? Nebo preferují stabilitu známého prostředí?

Vztahové otázky

Další část je ještě mlhavější, přemýšlení o tom, jak si lidi rozumí a jaké mají vztahy. (Nenechte se splést, máte vztah s každou osobou, se kterou přijdete do styku a to dokonce i když si myslíte, že jste jenom kodér s očima přilepenýma na obrazovku. Dokonce i přímé vyhýbání se vztahům s ostatními je v podstatě vztahem.)

Jaké jsou vztahy ve skupině? Mají se lidé navzájem rádi, nebo jsou vztahy striktně pracovní? Jsou lidé přáteli i mimo skupinu, nebo jsou pracovní a domácí vztahy oddělené?
Je ve skupině dynamika, která přesahuje práci, kterou je potřeba udělat? Chodí skupina společně na obědy? Jsou zde pravidelné páteční hospody? Víkendové výlety na lezeckou stěnu? Budete divný, když nepůjdete lézt s nimi?
Jaká je v oddělení fluktuace? Jak často se tým obměňuje? Přijdete do zavedeného týmu, který je už roky spolu?
Jsou ve skupině nějaké vůdčí osobnosti, ať už formální, či neformální? Nebo jsou si všichni rovni?
Kritizují členové týmu navzájem svoji práci? Nebo dělá každý věci po svém?

Život společnosti

Důležité je také porozumět kultuře společnosti jako celku a jak do ní skupina, k níž se připojíte, zapadá.

Jak bude hodnocena vaše výkonnost? Je vaše hodnocení založeno pouze na vaší výkonnosti, nebo zahrnuje i vyhodnocení celého oddělení, nebo celé společnosti?
Jsou zaměstnanci odměňováni i jinak než finančně? Jak? Pizza party? Cadillac Eldorado? Sada steakových nožů? Jsou zde bonusy, od čeho se odvíjejí? Od výkonu vašeho týmu? Celé společnosti?
Jak je tým přijímán zbytkem oddělení? Jak je oddělení přijímáno zbytkem společnosti?

Opět, tyto otázky nejsou seznamem, který si odškrtáte na interview. Jsou výchozím bodem pro zvažování otázek, během vašeho poznávání společnosti, pro kterou byste pracovali.

Další cesty, jak pozorovat kulturu

Jsou i další, méně přímé způsoby, jak získat přehled o firemní kultuře a jsou občas informačně daleko přínosnější. Jeden z takových způsobů je nahlédnout do manuálu zaměstnanců. Požádejte o to přijímajícího manažera. Dejte si čas si ho pročíst. Je to tlustý šanon plný specifických regulací, jako třeba kde v kóji můžete mít pověšený obrázky? Nebo druhý extrém, kdy vůbec nemají stanovenou politiku docházky a říkají pouze "dokud máš hotovou práci, je všechno v pořádku"?

Mají kulturu rozpoznávání? Já mám emailovou složku nazvanou "Pochvalné zmínky", kde shromažďuji všechno, co hezkého, o mně nebo mém týmu, řekl někdo ze společnosti. Spousta těchto zmínek je od vyššího managementu, kde děkují mé skupině za úspěšný projekt. Má přijímající manažer podobný archiv? Zeptejte se, jestli můžete vidět nějaké aktuální ukázky.

Požádejte o návštěvu kanceláří během pracovního dne. Co vidíte? Jsou lidé spokojení? Mají hlavy zabrané do práce, nebo probírají věci jako tým? Je tu spousta kójí, nebo mají kanceláře? Jsou tam veřejná místa pro spolupráci? Je to sterilní, upnuté prostředí, nebo po sobě lidé střílejí z dětských pistolek?

Nedívejte se pouze na skupinu, kde budete pracovat. Navštivte třeba účtárnu, nebo zákaznický servis. Vypadají, že jsou tam šťastní?

A konečně, porozhlídněte se na internetu. Začněte s firemní stránkou a blogem. Například i jen zběžné přečtení GitHub blogu dává jasně najevo, že hodně kultury se točí kolem společenského pití. Možná najdete blog současných nebo bývalých zaměstnanců, kde může být nějaké vodítko. Hledejte na LinkedIn profily těch, kdo ve společnosti pracovali. Možná zjistíte, že lidé, kteří tam pracovali, odchází do jednoho roku.

A poslední poznámka: bez ohledu na to, co jste zjistili o kultuře a jak skvěle daná práce vypadá, nikdy neakceptujte nabídku okamžitě. Počkejte minimálně 24 hodin, abyste se ujistili, že je to to nejlepší pro vás. Jste emocionálně vypjatí, nastartovaní a to není dobrý rámec pro finální rozhodnutí. Lepší je trochu poodejít a podívat se na situaci z nadhledu. A je to o to zásadnější, pokud máte v životě ještě něco dalšího, co je podstatné.

Když dostanete nabídku, řekněte "Mockrát děkuji, jsem tímto výsledkem velmi potěšen. Samozřejmě, nyní potřebuji trochu času, abych nabídku zvážil. Jaký čas se vám zítra hodí, abychom si promluvili?" Nebojte se, že by svoji nabídku stáhli. Každá rozumná společnost to pochopí. Pokud by vás tlačili do okamžitého rozhodnutí, je to varovné znamení.

Andy Lester vyvíjí software přes dvacet let, jak v business oblasti, tak na webu v rámci open source komunity. Léta strávená proséváním životopisů, pohovorováním nepřipravených kandidátů a také vlastní nerozumná kariérní rozhodnutí, ho dohnaly k napsání jeho netradiční knihy o nových způsobech hledání zaměstnání. Andy je aktivním členem open source komunity a žije v oblasti Chicaga. Bloguje na petdance.com a je k zastižení na emailu andy@petdance.com.

Andy Lester has developed software for more than twenty years in the business world and on the Web in the open source community. Years of sifting through résumés, interviewing unprepared candidates, and even some unwise career choices of his own spurred him to write his nontraditional book on the new guidelines for tech job hunting. Andy is an active member of the open source community, and lives in the Chicago area. He blogs at petdance.com, and can be reached by email at andy@petdance.com.

Související odkazy

Související externí odkazy

Otázky u pohovoru (Banter bloguje)
Jak si (ne)zruinovat životopis (Dagblog)

Pokud jste na svém blogu (ne firemním) publikovali článek se souvisejícím tématem (pracovní pohovory, CV apod.), napište mi do komentářů, rád vás odkážu.

Messaging bridge je šikovné řešení, pokud potřebujeme distribuovat zprávy mezi několika messaging systémy. Potřeboval jsem vytvořit JMS bridge na WebLogicu a protože jsem si oblíbil WebLogic Scripting Tool (WLST), tak jsem si napsal skript.

Nicméně dnes, vás milí čtenáři, nechci odfláknout pouhým WLST skriptem, ale podíváme se na téma trochu zeširoka. Prvně si zasadíme JMS bridge do kontextu Enterprise Integration Patterns (EIP), pak se podíváme, jak jde bridge naklikat ve WebLogic konzoli. A samozřejmě vás neochudím o to WLST :-)

Messaging Bridge

Nebyl bych to já, kdybych se nevytasil s nějakým patternem. Tak tady je - Messaging Bridge, jak je definován v EIP. (Věty kurzivou jsou citacemi z knihy Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.)

Messaging Bridge řeší následující problém: "How can multiple messaging systems be connected so that messages available on one are also available on the others?" Integrační vzory řeší problémy obecně. V tomto případě jde o to, jak dostat zprávy z jednoho systému na jiný. Např. jak dostat zprávy z WebSphere MQ na MSMQ. Nebo JMS. Nebo TIBCO Randevouz. Nebo... Jasný, ne? Odkudkoliv kamkoliv.

Messaging Bridge tedy je "a way for messages on one messaging system that are of interest to applications on another messaging system to be made available on the second messaging system as well."

Protože většinou neexistuje způsob, jak propojit dva různé messaging systémy, propojují se jednotlivé, odpovídající kanály na daných systémech. "The Messaging Bridge is a set of Channel Adapters ... where each pair of adapters connects a pair of corresponding channels. The bridge acts as a map from one set of channels to the other and transforms the message format of one system to the other."

Vzor Messaging Bridge (zdroj EIP)

JMS Bridge

JMS bridge je speciální variantou Messaging bridge, který má několik omezení, nebo spíše možná zjednodušení. Tři hlavní jsou:

Propojuje pouze JMS systémy (různých dodavatelů).
Zprávy netransformuje (protože pracuje pouze s JMS zprávami).
Zprávy z jednoho (zdrojového) systému přeposílá na jiný (cílový). Čili nečiní je pouze dostupnými, ale provádí routing/forwarding.

JMS bridge běžně poskytují všichni dodavatelé JMS systémů, např.:

HornetQ (JBoss)
ActiveMQ (Apache)
WebLogic (Oracle)

Zajímavým atributem u JMS bridge je Quality of Service (QoS), který říká, v jakém modu budou zprávy přeposílány:

At most once - nanejvýš jednou. Toto je nejbenevolentnější mod. Zpráva buď dorazí (maximálně jednou), anebo taky ne. A nám to tak vyhovuje.
Duplicates OK - duplicity jsou v pořádku. V tomto modu jsou zprávy potvrzeny, že dorazily na cílový systém. Může se stát, že stejná zpráva nám dorazí ve více instancích, ale to je v pořádku - řekli jsme přece, duplicity jsou OK. Výhodou je, že se žádná zpráva neztratí.
Exactly once - přesně jednou. Toto je nejvíc striktní mod, který nám nejen zaručuje, že každá zpráva dorazí na cílový systém, ale taky že tam dorazí právě jednou. Takový závazek není jen tak a zajistí nám ho JTA, čili distribuovaná transakce.

WebLogic JMS Bridge

Vytvoření JMS bridge na WebLogicu je otázkou chvilky, stačí mít připraveny správné ingredience. Co budeme potřebovat?

URL (a credentials) zdrojového serveru,
URL (a credentials) cílového serveru,
JNDI JMS adapteru (transakční, nebo netransakční)

eis.jms.WLSConnectionFactoryJNDIXA
eis.jms.WSLConnectionFactoryJNDINoTX

JNDI Connection Factory,
JNDI JMS destinace (fronty),
Quality of Service

Exactly-once
Duplicate-okay
Atmost-once

Pak už stačí jen naházet to do hrnce, zamíchat, podusit... a proklikat se průvodcem. Protože těch obrazovek ve wizardu je zbytečně moc, ukážu jenom screenshoty konečného stavu.

Pokud chceme použít transakční mod Exactly once, je dobré ještě před vytvářením bridge deployovat transakční adaptér jms-xa-adp.rar - vyhneme se tak zbytečným restartům (adapteru či WebLogicu). Adapter najdeme mezi knihovnami WebLogicu a nasazujeme ho jako aplikaci.

Nasazený resource adapter jms-xa-adp.rar (ve struktuře Deployments)

Bridge se sestává ze dvou destinací (zdrojové a cílové):

Definice JMS (source) destination

a samotného bridge:

Definice JMS bridge

Že nám bridge funguje, poznáme podle jeho stavu (záložka Monitoring) a taky doporučuju si nějakou zprávu cvičně přeposlat. Světe div se, ale transakce můžou zlobit.

Stavy JMS bridgů (záložka Monitoring)

WLST

No a máme tady velké finále, ke kterému jsem nenápadně, ale cílevědomě směřoval. Takže tady je: WLST v celé své pythoní kráse :-)

#
# properties
#
user = 'weblogic'
password = 'welcome1'
server = 't3://sandman:7001'
# source credentials
sourceJmsUser = 'weblogic'
sourceJmsPassword = 'welcome1'
sourceURL = 't3://sandman:7003'
# target credentials
targetJmsUser = 'weblogic'
targetJmsPassword = 'welcome1'
targetURL = 't3://sandman:7004'
# JMS servers
servers = ['SourceServer']
targets = []
# queues
queues = [
'EVM_EVE_CMS',
'EVM_EVE_FC',
'EVM_EVE_GEN',
'EVM_EVE_PTS',
'NTF_PARTY',
'NTF_PRODUCT']
adapterJNDI = 'eis.jms.WLSConnectionFactoryJNDIXA'
connectionFactory = 'jms/sws/SWSConnectionFactory'
qualityOfService = 'Exactly-once'
jndiPrefix = 'jms/sws/'

# connection
connect(user, password, server)

# edit mode
edit()
startEdit()

# get targets
for server in servers:
    targets.append(getMBean('/Servers/' + server))
print'\nTargets:', targets, '\n'

#
# create bridges
#
print'\n### Create bridges:\n'
for queue in queues:
    bridgeName = queue + '_bridge'
    sourceName = queue + '_source'
    targetName = queue + '_target'
# delete an old bridge
    ref = getMBean('/MessagingBridges/' + bridgeName)
if ref != None:
        cd('/MessagingBridges')
        delete(bridgeName, 'MessagingBridge')
# delete an old source destination
    ref = getMBean('/JMSBridgeDestinations/' + sourceName)
if ref != None:
        cd('/JMSBridgeDestinations')
        delete(sourceName, 'JMSBridgeDestination')
# delete an old target destination
    ref = getMBean('/JMSBridgeDestinations/' + targetName)
if ref != None:
        cd('/JMSBridgeDestinations')
        delete(targetName, 'JMSBridgeDestination')
# create a new source destination
    cd('/')
    cmo.createJMSBridgeDestination(sourceName)
    cd('/JMSBridgeDestinations/' + sourceName)
    cmo.setAdapterJNDIName(adapterJNDI)
    cmo.setConnectionFactoryJNDIName(connectionFactory)
    cmo.setConnectionURL(sourceURL)
    cmo.setDestinationJNDIName(jndiPrefix + queue)
    cmo.setUserName(sourceJmsUser)
    cmo.setUserPassword(sourceJmsPassword)
print'Source:', cmo
# create a new target destination
    cd('/')
    cmo.createJMSBridgeDestination(targetName)
    cd('/JMSBridgeDestinations/' + targetName)
    cmo.setAdapterJNDIName(adapterJNDI)
    cmo.setConnectionFactoryJNDIName(connectionFactory)
    cmo.setConnectionURL(targetURL)
    cmo.setDestinationJNDIName(jndiPrefix + queue)
    cmo.setUserName(targetJmsUser)
    cmo.setUserPassword(targetJmsPassword)
print'Target:', cmo
# create a new bridge
    cd('/')
    cmo.createMessagingBridge(bridgeName)
    cd('/MessagingBridges/' + bridgeName)
    cmo.setSourceDestination(getMBean('/JMSBridgeDestinations/' + sourceName))
    cmo.setTargetDestination(getMBean('/JMSBridgeDestinations/' + targetName))
    cmo.setStarted(true)
    cmo.setQualityOfService(qualityOfService)
    cmo.setTargets(targets)
print'Bridge:', cmo, '\n'

# save and finish
save()
activate()
disconnect()
exit()

Související články

Po více jak dvou letech se končí moje soupoutničení s verzovacím systémem Perforce (P4). Z počátku nebylo naše soužití zcela harmonické. Ale poté, co jsem přijal pravidla hry (které P4 nastavuje) jsem si tento systém oblíbil. A nyní bych se chtěl o své zkušenosti podělit.

Počáteční rozčarování a zklidnění

Srážka nepřipraveného vývojáře s P4 může být dost nepříjemná a frustrující. Vývojáři mají dost často rutinní zkušenost s SVN a podobnými nástroji. P4 má v některých aspektech jinou filozofii, která (z hlediska třeba SVN) nemusí být intuitivní. Když člověk nepochopí principy, které se za tím skrývají, může dopadnout podobně, jako evropský řidič v Anglii (Irsku, Austrálii, ...) - nadává, jak to "ty pitomý Angláni blbě vymysleli".

Pokud se člověk rozhodne nepřijmout filozofii P4, tak může skončit jako někteří z mých kolegů, kteří pořád trousí hlášky o "debilním Perforsu". Holt rok je asi příliš krátká doba na to, naučit se to pořádně ;-)

Mě zkušenost naučila číst (v) dokumentaci. Rád totiž dělám věci správně a (dobrá či dokonce kvalitní) dokumentace mi přijde jako efektivní způsob jak zjistit, jak věci fungují. A navíc si člověk zbytečně nepřenáší zlozvyky odjinud. Takže než s P4 bojovat, přijde mi lepší přijmout jeho pravidla hry. On se vám za to odvděčí a rozkvete vám pod rukama :-)

Možná teď čekáte, že napíšu něco o té filozofii a o věcech, které jsou "jinak". Ale nenapíšu. Nechci se pouště do nějaké srovnávací studie, kterou by to asi skončilo. Prostě jen teď uvedu, jak P4 používám já.

Typický lifecycle

Následující lifecycle mi vykrystalizoval během těch dvou let používání a osvědčil se mi, jako účinný prostředek proti některým nástrahám P4.

Check Out (Ctrl+E) konkrétního projektu (nebo jeho části) do nového changelistu (Alt+N -> Alt+C).
Editace zdrojových kódů.
Na changelistu, který chci komitovat: Revert Unchanged Files .
Na adresáři, který jsem původně checkoutoval: Reconcile Offline Work a přidat eventuální soubory do changelistu.
Kontrola souborů v changelistu. Pokud byly soubory modifikované, tak Diff Against Have Revision (Ctrl+D).
Submit (Ctrl+S -> Alt+S) .

Z tohoto seznamu bych vypíchnul body 3 a 4. Revert Unchanged Files je důležitý, aby se nekomitovaly nezměněné soubory. Reconcile Offline Work zajistí přidání (Mark for Add

) nových souborů do changelistu.

Changelisty

Changelist je v P4 seskupením souborů, které chci komitovat. Já si vytvářím nový changelist pro každý kousek práce, typicky jedna položka v issue tracking systému. Novému changelistu pak nejčastěji dávám popis ve stylu: <issue ID>; <issue name>, <description>. Např.: SWS-12; Gradle tutorial, Jetty initial implementation.

Pending Changelists

Na záložku Pending Chagelists, která zobrazuje moje chagelisty, se přepnu klávesovou zkratkou Ctrl+1, nebo ikonou

.

P4 nabízí také tzv. default changelist, který ale používám pouze v jediném případě - pokud v changelistu potřebuju mít něco, co nechci komitovat a později to revertnu. Pokud bych to náhodou přesto potřeboval, vždy se to dá převést do jiného changelistu. Důvod, proč něco nekomitovat a mít to v changelistu je prostý - pokud si natáhnu do lokálního workspace nějakou revizi z depotu, P4 všechny soubory nastaví na read-only. A to může některým editorům vadit. Takže to šupnu do defaultu.

Shelved Files

Aneb soubory na poličce. Někdy mám něco rozpracovaného, ale nechci to ještě komitovat. Zároveň ale nechci, aby úpravy byly pouze u mne na lokálním počítači. Tak je přesunu z changelistu do poličky na serveru.

Shelved Files

Bookmarks

Souborová struktura v rámci daného depotu může být velmi rozsáhlá (na aktuálním projektu je to přes 10 000 souborů). Proto jsem si oblíbil záložky (Bookmarks) s nastavenými klávesovými zkratkami.

Bookmarks

Klávesové zkratky

P4 má výborného grafického klienta: P4V. A tak jako u každé grafiky, i zde se hodí (a efektivitě napomůžou) klávesové zkratky. Tyhle jsem si oblíbil:

Get Latest Revision: Ctrl+Shift+G
Check Out: Ctrl+E
Submit: Ctrl+S -> Alt+S
Revert Files: Ctrl+R
Diff Agains the Have Revision: Ctrl+D
Next Diff (P4Merge): Ctrl+2
Previous Diff (P4Merge): Ctrl+1
Close (P4Merge): Ctrl+W
Pending Changelists: Ctrl+1
Submitted Changelists: Ctrl+2
Skok na zazáložkovaný soubor/adresář: Ctrl+Shift+1 (až n)
Skok do file browseru z daného adresáře/souboru: Ctrl+Shift+S

K dokonalé spokojenosti mi chybí absence dvou zkratek: Revert Unchanged Files a Reconcile Offline Work.

Závěr

Myslím, že dobrá znalost (aktuálně používaného) verzovacího systému patří ke ctnostem každého vývojáře. Za ty dva roky jsme se s P4 docela skamarádili a pokud bych ho někdy v budoucnu zase potkal, tak se rozhodně nebudu zlobit.

A co vy, máte nějakou oblíbenou P4 vlastnost? Nebo vás naopak na něm něco rozčiluje? ;-)

Související články

Externí odkazy

Perforce: High-Level Software Version Management Best Practices

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

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

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ář.

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

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

Související externí články

Lester and Rothman: Do You Need a Portfolio?

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

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
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.

Coding standards (for code clarity)
Design/code reviews
Configuration/version management
One-click build (private and public)
Continuous integration
Automated unit tests
Automated acceptance tests
Stop if the tests don't pass
System testing with each iteration
Stress testing (application- and system-level)
Automated release/install packaging
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."

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)

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

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:

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:

Pracovní pohovory jsou neefektivní.
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

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