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.