8. května 2013

Gradle, moderní nástroj na automatizaci

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

Gradle? Co to je?

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

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

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

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

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

Je opravdu tak dobrý?

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

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

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

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

Související články

4. května 2013

Cesta samuraje, rok druhý

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

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

Jak to bylo

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

Celkové skóre za minulý rok je 31 publikovaných článků. Silnými tématy byly jednak technické věci, zastoupené nejčastěji prolínající se trojicí SOA, integrace, messaging a jednak věci personální - téma pohovorů. Technická témata byla daná hlavně projektově, kde jsem vytěžil několik článků o Oracle SOA SuiteWLST 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

29. dubna 2013

Perforce best practices

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

17. dubna 2013

Vytvoření JMS Bridge na WebLogicu

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

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

4. dubna 2013

Geek, který zapadne

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


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.

25. března 2013

Oracle EDN, implementace EDA

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).
<?xml version="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-definition name="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:
<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns: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:element name="simpleMessage">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="timestamp" type="xsd:dateTime"/>
        <xsd:element name="status">
          <xsd:simpleType>
            <xsd:restriction base="xsd:string">
              <xsd:enumeration value="ON"/>
              <xsd:enumeration value="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

9. března 2013

Oracle SOA certifikace

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