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

3. března 2013

Druhý rok s Kindlem

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

25. února 2013

Jak dělají Java pohovor jinde

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