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

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

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

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

The Company

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

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

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

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

Projects

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

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

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

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

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

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

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

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

Technologies

Konečně se dostávám k tomu, co je na tomhle článku asi nejzajímavější. Jaké technologie tady používáme? Náš hlavní technologický stack je postavený nad Java EE. Pokud je to podstatné, uvádím v následujícím přehledu verzi komponenty, ta v závorce je pro starší projekty, ta před závorkou pro nové projekty.

• JBoss AS 7 (5) jako aplikační server,
• Vaadin jako frontend,
• EJB 3.1 (3.0) a CDI pro business logiku,
• JPA 2.0 (1.0)/Hibernate pro perzistenci,
• JMS/HornetQ pro messaging,
• JAX-WS pro SOAP webové služby.

Kromě těchto "mainstream" technologií se u nás můžete setkat minoritně s Grails a ještě minoritněji se Springem. A pak s celou kupou dalších, většinu open source, věcí, které jsou specifické per projekt. Z hlavy mě napadá třeba JasperReports, nebo Dozer.

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

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

Pros

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

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

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

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

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

Cons

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

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

Who?

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

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

How much?

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

Interview

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

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

Conclusion

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

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

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

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

Official Ad

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

• Java Developer at Gemalto
• Technical Leader at Gemalto

Team Geek, team leader se srdcem

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

Team Geek

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

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

Tři pilíře srdce

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

HRT (zdroj Team Geek)

Šest kapitol kolaborativní nirvany

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

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

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

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

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

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

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

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

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

Závěrečná myšlenka

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

Související články

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

Gradle tutorial: tasky

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

3 informace na úvod

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

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

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

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

Instalace a verze Gradlu

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

Verze Gradlu

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

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

Projekty a tasky

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

Definice Gradle projektu (projekt 00_HelloWorld)

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

Hello, world!

Nevím, jak vy, ale já když se učím něco nového (jazyk, framework, nástroj), tak si vždycky rád napíšu Hello world. Jak vypadá Hello world v Gradlu?

task hello << {
    println 'Hello, Gradle!'
}

Příklad spustíme příkazem

gradle hello

Výstup by měl vypadat nějak takhle:

Výstup tasku hello

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

gradle hello -q

Zrojový kód na Bitbucketu: 00_HelloWorld/build.gradle

Jaké tasky jsou k dispozici?

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

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

Výpis tasků

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

gradle tasks --all

Gradle GUI

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

Gradle GUI

Syntaxe tasku

Nejčastěji se budeme setkávat s definicí tasku, která byla uvedena v příkladu Hello world, čili:

task myList << {
    println 'middle point'
}

Na této syntaxi je nejzajímavější operátor <<, který je aliasem pro metodu doLast. Stejný výsledek dostaneme zápisem:

task myList {
    doLast {
        println 'middle point'
    }
}

Když máme metodu doLast, tak nepřekvapí, že máme i obdobnou doFirst. K čemu tyto metody slouží? Umožňují nám "dekorovat" již definovaný task - metoda doFirst přidává nové akce na začátek seznamu akcí a metoda doLast dělá totéž na konci seznamu akcí daného tasku. Každý task tedy můžeme postupně rovíjet a obohacovat jeho chování. V jednoduchém build skriptu to asi nebude potřeba, ale v hierarchii skriptů (multi project) už to může být zajímavé.

task myList << {
    println 'middle point'
}

myList {
    doLast {
        println 'last point'
    }
}

myList {
    doFirst {
        println 'first point'
    }
}

Výstup "dekorovaného" tasku myList

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

Zdrojové kódy

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

hg clone ssh://hg@bitbucket.org/sw-samuraj/gradle-tutorial

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

Protože tasky jsou pro Gradle stěžejním konceptem, budu se jim věnovat i v příštím díle. Tři hlavní okruhy by měly být:

• závislosti mezi tasky,
• dynamické generování tasků - task rules
• a "běžné" problémy, se kterými se můžeme při definici tasků setkat.

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

Související články

• Gradle, moderní nástroj na automatizaci

Související externí články

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