Na druhou stranu je WT plný bahna a začátečníků, jako každá sociální síť může člověku vzít hodně času a nervů.

Já jsem postupem času zjistil, jak WT (a nejspíš i jakýkoliv crowdsourcingový server) používat tak, aby mi čas a peníze spíš šetřil:

1. write-only – používám WebTrh jen pro zadávání práce. Poměr, kdy já zakládám poptávku po práci vs. odpovídám na nějké téma je tak 95/5. Na WT nechoďte číst diskuze a najednou vám nebude vůbec jasné, co na něm lidem vadí. Hlavně proto, že tím, že začnete poptávat práci, nebudete vůbec potkávat „internetové podnikatele“ – to jsou totiž ti, kteří také poptávají práci, tzn. vy si sledujete jen svá témata a to, že 50 poptávek okolo vašeho inzerátu jsou hlavně MFA, katalogy, slevové servery, eshopy a dropshipping, vám může být jedno.
2. reference, reference, reference – ikdybych chtěl od někoho na WT jen zavázat tkaničky, chci reference, skvělé, na profi úrovni, spoustu, ihned, jinak ani neodpovídám.
3. vyberte si nejlepší a zeptejte se na „jejich nejlepší cenu“. Ptát se: „jaká je vaše nejvýhodnější nabídka“ nutí zájemce o práci smlouvat sám se sebou. Je v tom schované „tohle je nejlepší nabídka, lepší už nedáte, vybral jsem pár lidí se super referencemi a teď už jde jen o cenu, nemám čas se handrkovat“.
4. na nejlepší cenu se zeptejte i pár dobrých a levných. Tyto ceny se vám později budou hodit.
5. až vyberete toho, koho chcete, řekněte si o slevu 50 procent – a to dost nekompromisně. Ukažte mu reference všech těch, kteří tutéž práci nabídli za polovinu, byť mají třeba jen o trošku horší reference. Zároveň napište, že v jeho kvalitě to můžete mít od dalších lidí levněji (a i tyto reference mu ukažte). Nemusíte lhát, s výhradou použitelný (ikdyž neprofesionální) design pro vás na WT udělá kdekdo i zadarmo. Od jednoho začátečníka jsem dostal asi 6 ne úplně špatných grafických návrhů úplně zadarmo. Vítejte ve světě outsourcingu do Indie, akorát ta Indie umí skvěle česky a chodí na gympl!
6. až budete s někým spolupracovat delší dobu, jednou za čas jeho cenový odhad znovu podrobte stejným výběrovým řízením. Oni ti pracovníci nejsou blbí a ikdyž občas akceptují nižší cenu, aby získali stálého zákazníka, plíživě si budou cenu zvyšovat. Jednou za čas tímhle pošlete cenu na úroveň, kvůli které používáte právě WebTrh – místo, kde nabídka přesahuje poptávku několikanásobně!
7. když potřebujete něco hned, udělejte inzerát „práce na chvilku za 100 Kč“. Takové ty výběry šablony a instalace Wordpressu (jak myslíte, že jsem rozběhl foodist.cz?), přepisování dat, jednoduché úpravy textu, hledání zaměstnanců, procházení webů, mailing do Ameriky (u mě teď z několika důvodů aktuální)… můžete takhle zadat klidně 5 věcí, jít spát a ráno máte připravený web, napsané texty, nasazenou grafiku, rozeslané e-maily. Tihle lidi asi žijou v nějakém jiném časovém pásmu, obvykle není problém poptávat práci do 2 hodin od teď. Teď může být klidně 11 večer.

Před časem jsem se zmiňoval o crowdsourcin­gových webech, typicky TopMonks, Pikr.cz. Bojím se, že těch cca 5–20 procent, které si budou chtít brát z každé zakázky, nevyváží přínos bodování a přehledných projektů. Moc jim fandím, ale WT je těžká váha, čistý a neregulovaný kapitalismus s nulovými transakčními náklady!

Díky experimentům jsem přišel na to, jak:

• shodit 10 kil za 10 týdnů
• vyléčit bolavé klouby, které bolely snad 8 let
• omezit prokrastinaci
• zbavit se spousty strachů
• vybudovat mnohem větší disciplínu
• zjistil jsem, které 2 hodiny práce denně jsou skutečně důležité a přináší hodnotu a kterých zbývajících 6–10 hodin práce se dá useknout bez větších problémů
• nakopnout svůj mozek a zbavit se únavy
• zároveň zkrátit svůj spánek o hodiny denně
• kdy pracuju dobře a kdy se do práce nedonutím
• jak vstávat s naprostou radostí a pocitem v pátek „hurá víkend“ a v neděli večer „hurá bude pondělí“
• jak poznat, co se na člověka všechno tlačí a jaká svoboda je všechno to ze sebe shodit
• jak si změnit tlak z vysokého na dokonale učebnicový bez jakýchkoliv léků

A spoustu dalších věcí.

Každý z těch experimentů by byl asi na samostatný článek. Ale k čemu vás chci přesvědčit je, abyste sami začali experimentovat.

Je to jednoduché.

Nejdřív nasbíráte různé podněty z literatury (vědecké i populárně naučné nebo i z vlastní praxe). Vyslovíte hypotézu: „Když budu denně pít 2 litry čaje a místo piva víno, shodím za týden 1 kilo – ikdyž nic jiného nezměním a nechám si svůj další životní styl“. Pak se rozhodnu, jak dlouhý experiment bude. Obvykle mám experimenty od 1 týdne do 1 měsíce.

Potom, jakmile experiment zkončí, vyhodnotíte, zda fungoval a podle toho upravíte svůj život nebo zkusíte další experiment. Co se úpravy života týká – v posledním třičtvrtě roku zjišťuju, že dokážu žít nejen bez médií, zpráv, novin, ale postupně i bez RSS a postupně zjišťuju, že asi Twitter přepnu na write-only mód. Zjištěno experimentálně – o nic důležitého bych nepřišel.

Jaké experimenty jste zkoušeli?

Proč to řeším? V okamžiku, kdy člověk začne o něco usilovat, musí bojovat, lecčeho se vzdát a často tím úsilím trpí rodina, vztahy s přáteli a podobně. Někdy se to povede a člověk dosáhne úspěchu a jindy ne.

Pokud se rozhodnu něčeho dosáhnout, neodpustím si selhání a nevzdám to. Nikdy! Na druhou stranu jsou věci, v kterých selžu klidně a rád a nebudu mít na sebe sebemenší zlost. Sepsal jsem je do seznamu a třeba vás inspirují a posunou vaše žebříčky toho, kde je selhání v pořádku a kdy musíte vstát a jít dál.

1. práce, kterou chtějí ostatní, abyste dělali – největší ztráta času je agenda, kterou vám vnutí někdo jiný. Vše, co děláte, musí podporovat i vaše cíle. Je skvělé, pokud dojde k win-win situaci a vzájemně si pomůžete. Pokud máte dělat činnost, která pomůže jen tomu, kdo po vás něco chce a pro vás neplyne žádné přiblížení vašim cílům, vyvlékněte se z ní. Pokud v takové práci selžete, nevyčítejte si to.
2. práce, kterou „jsme vždy dělali takto“ – pokud už chcete dělat nějakou práci, pokorně poznejte, jak se dělá, ale nikdy, až do smrti, nepřestaňte se snahou způsob, jak se práce dělá, vylepšit. Důvodem, proč někteří lidé změnili svět tkvěl v tom, že jim „hranaté kolo přišlo nepraktické“ nebo „parní stroj moc pomalý“. Naučte se, jak se věc dělá teď a pokud najdete lepší způsob, udělejte vše pro to, abyste věc mohli dělat lepším způsobem.
3. poznejte své talenty a využijte jich – a naopak, pokud víte, že v něčem nejste dobří, omezte takovou činnost. Když budete trénovat to, v čem jste hrozní, budete přinejlepším průměrní. Když využijete svůj talent, budete skvělí! Věřím, že každý člověk by měl být v něčem nejlepší na světě, ikdyby to byla sebevětší obskurnost. Víte-li, že máte na danou věc talent, selhání netolerujte a zlepšujte se, dokud nedosáhnete vrcholu. Ve všem ostatním selhání tolerujte a nedělejte si komplexy.
4. nežijte život druhého – od dětství fandíte nějakému fotbalistovi, nemáte talent na fotbal? Fanděte mu, ale zapomeňte na: „nikdy nebudu tak dobrý jako on.“. On využil svůj talent do maxima. Vy nemáte jeho talent, vy máte talent svůj. Žít život druhých, myslet na to, že „on má talent na fotbal a já ne“, to je ztracený život. Takhle nebudete nikdy šťastní! Využijte své nejsilnější přednosti do maxima a kašlete na to, která hvězda je teď v módě.
5. nedělejte nic, co vás nemotivuje – podívejte se na své cíle. Chcete být zdravější, trávit víc času s rodinou, dělat lepší práci, poznat svět? Podívejte se na své úkoly. Udělejte několik úkolů, které k těmto cílům vedou a udržujte konečný cíl v hlavě. Pak si vezměte úkoly, které k těmto cílům nevedou. Cítíte ten rozdíl?
6. nepracujte nikdy, nikde a v žádném prostředí, kde dochází k nonstop vyrušení – ano, vyrušení je občas nutné. I vy občas vyrušíte ostatní. Pokud budete v prostředí, kde k vyrušení dochází ve vyšší frekvenci, než je běžná doba dokončení úkolu, změnte to prostředí. Habáte svou produktivitou a děláte tu největší chybu, kterou člověk, který se snaží něco dosáhnout, udělat může (snad kromě bodu 1 – dělání práce, která nevede k vašim cílům). Nevyčítejte si práci, kterou nestíháte kvůli vyrušení. Vyčítejte si, že se vyrušení nebráníte aspoň tolik, aby frekvence byla nižší, než je běžná doba 1 úkolu.
7. zbavte se nespolehlivých lidí – váš úspěch mnohdy nezávisí jen na vás, ale v mnoha odvětvích i na celém týmu (už někdo postavil jaderný reaktor v jednom člověku?). Pokud máte v týmu člověka, na kterého není spoleh, udělejte všechno pro to, aby ten člověk z toho týmu zmizel. Ti, kterým nejvíc záleží na tom, aby se projekt povedl, budou muset nejvíc suplovat práci nespolehlivého jednoho. Nespolehlivý člověk nemusí být zlý ani špatný, jen jsou jeho cíle a motivace odlišná. I já jsem byl této roli, kdy mé cíle byly odlišné. Změnil jsem tým a pomohl tak všem, stal se šťastnějším a produktivnějším. Jsou vaše cíle a motivace jiná než týmu? Nevyčítejte si to, změňte tým. Nestíhá váš tým a máte pocit, že se někteří nesnaží? Nevyčítejte si to, vyčítejte si, že tolerujete takové lidi ve svém týmu.

Poznámka k bodu číslo 1. Občas po vás budou chtít něco lidé a ta činnost vašemu cíli neprospěje. Ti lidé budou vaše rodina. Tady bod 1 neberte moc vážně a prostě pomožte. O to víc kašlete na samozvance, musíte mít přeci čas na ty důležité: na svou rodinu!

Zdrojový kód si můžete prohlédnout zde.

Na Radkovu kódu se mi nelíbí řada věcí, některé pochopitelné z důvodu jednoduchosti, druhé pro mě naprosto nepochopitelné.

Zkusil jsem je sepsat:

• návratová hodnota v proměnné $a? Proč? Mnohem lepší by bylo nějaké $responseData
• vracení stavu v poli stav v řetězci? V češtině? Myslím, že lepší by bylo vrátit error se zprávou (kvůli ladění) a errorCode, kde je číselný identifikátor chyby
• proč tolik magických konstant?
• proč chytání obecné Exception, když stačí konkrétní SoapFault?

K chybám, které i v jednoduchém kódu nemají co dělat, jsem přidal několik dalších úprav a aplikaci jsem postupně přepsal. Na Bitbucketu můžete vidět, jak jsem postupně kód přetvářel z původního na nový.

Cíle, které jsem si kladl jsou:

• testovatelný kód (při refaktoringu jsem udělal některé chyby proto, že jsem si testy nenapsal – ponaučení pro příště)
• čitelný kód
• oddělení MVC (a to tak, že pokud použiju vlastní request, response a controller, je funkcionalita použitelná v libovolném frameworku)
• použití Dependency Injection tam, kde to dává smysl
• oddělení stavu, kdy je odpověď OK a kdy je odpověď v nepořádku do samostatné logiky, ne jen přidat status do pole.
• znovupoužitelnost service
• pokud aplikace poroste, možnost šířit data napříč aplikací jako Company – objekt, který bude absorbovat práci s daty, nešířit aplikací pole (typické vyhnutí se Primitive Obsession, což je jeden z Code Smells)

Výsledkem je kód, který je sice delší, ale je daleko čitelnější, znovupoužitelnější a vhodný pro libovolný framework. Nehledě na to, že na něj jdou napsat testy (unit i integrační).

Výsledný kód:

<?php


class CompanyServiceException extends RuntimeException
{
        const CODE_SERVICE_NOT_AVAILALE = 1;
        const CODE_VAT_ID_UNKNOWN = 2;
}

class CompanyService
{
        const SERVICE_WSDL_URL = 'http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl';

        private function readFromSource($id, $country)
        {
                $soap = $this->createSoapClient();
                $params = array('countryCode' => $country, 'vatNumber' => $id);
                $result = $soap->checkVatApprox($params);
                return $result;
        }

        protected function createSoapClient()
        {
                return new SoapClient(self::SERVICE_WSDL_URL);
        }

        private function createCompany($result, $country)
        {
                if ($this->isTraderAddressAndNotCity($result)) {
                        $t = explode("\n",$result->traderAddress);
                        $traderStreet = $t[0];
                        $traderCity = $t[1];
                        $traderPostcode = $t[2];
                } else {
                        $traderStreet = $result->traderStreet;
                        $traderCity = $result->traderCity;
                        $traderPostcode = $result->traderPostcode;
                }

                return new Company($result->vatNumber, $country, $result->traderName, $traderStreet,
                        $traderCity, $traderPostcode);
        }

        private function isTraderAddressAndNotCity($result)
        {
                return !isset($result->traderCity) && isset($result->traderAddress);
        }

        function readByIdAndCountry($id, $country)
        {
                try {
                        $result = $this->readFromSource($id, $country);

                        if (! $result->valid) {
                                throw new CompanyServiceException("DIC {$country}{$id} nebylo nalezeno",
                                        CompanyServiceException::CODE_VAT_ID_UNKNOWN, $e);
                        } else {
                                return $this->createCompany($result, $country);
                        }
                } catch (SoapFault $e) {
                        throw new CompanyServiceException("EC neni dostupna",
                                CompanyServiceException::CODE_SERVICE_NOT_AVAILALE, $e);
                }
        }
}

class Company
{
        private $id;
        private $country;
        private $firma;
        private $ulice;
        private $mesto;
        private $psc;

        function __construct($id, $country, $firma, $ulice, $mesto, $psc)
        {
                $this->id = $id;
                $this->country = $country;
                $this->firma = $firma;
                $this->ulice = $ulice;
                $this->mesto = $mesto;
                $this->psc = $psc;
        }

        function toArray()
        {
                // dic = country . id
                return array(
                        'ic' => $this->id,
                        'dic' => $this->country . $this->id,
                        'firma' => $this->firma,
                        'ulice' => $this->ulice,
                        'mesto' => $this->mesto,
                        'psc' => $this->psc,
                );
        }
}

class Request
{
        private $data;

        function __construct(Array $data = array())
        {
                $this->data = $data;
        }

        function __set($name, $value)
        {
                $this->data[$name] = $value;
        }

        function __get($name)
        {
                if (array_key_exists($name, $this->data)) {
                        return $this->data[$name];
                }
        }
}

class JsonResponse
{
        private $data;

        function __construct($data)
        {
                $this->data = $data;
        }

        function send()
        {
                header("Content-Type: application/json; charset=UTF-8");
                echo json_encode($this->data);
        }
}

class CompanyServiceController
{
        private $companyService;

        function __construct($companyService)
        {
                $this->companyService = $companyService;
        }

        function run($request)
        {
                try {
                        $company = $this->companyService->readByIdAndCountry($request->id, $request->country);
                        $responseData = $company->toArray();
                } catch (CompanyServiceException $e) {
                        $responseData = array(
                                "error"=>$e->getMessage(),
                                "errorCode"=>$e->getCode(),
                        );
                }
                return new JsonResponse($responseData);
        }
}

//$request = new Request($_REQUEST):
$request = new Request(array("id"=>"8501074769", "country"=>"CZ"));
$controller = new CompanyServiceController(new CompanyService);
$response = $controller->run($request);
$response->send();

Lean startup je neprodejný

Jak je těžké zákazníkovi prodat Scrum s jeho iteracemi, ikdyž si zákazník dokáže spočítat cenu za bod a tím i zpětně náklady na vlastnost a tím dovede i ekonomicky kalkulovat! Je pro něj pořád méně pohodlné než fixed-price u běžného vývoje SW. Minimálně dokud nezjistí, že Scrumové týmy dodávají levněji a rychleji, je obtížné zákazníka převést na platbu po sprintech. Zákazník má sice nástroje, jak řídit náklady (zjistí, že vlastnost je obodována např. na 5 bodů a on ví, že náklady na bod jsou 2 tisíce Kč a tedy ví, že daná vlastnost musí stejných bankovek přinést minimálně deset.

Pokud Scrum je těžko prodejný, pak Lean Software Development je zcela neprodejný! Neexistují časové odhady. Vlastnost, ať už je velká nebo malá, má zprůměrovaný časový odhad a zprůměrovanou cenu. Chcete upravit pár textů nebo chcete přepsat objednávkový systém? Jedna cena. Já tohle považuju za noční můru, ve které je pro zákazníka ekonomicky racionální neustále velikost úkolu zvětšovat (abych ve sdíleném prostředí za fixní cenu za jednotku urval maximum hodnoty) a tím vést k tomu, že cena úkolu a doba zhotovení pořád poroste, protože tým toho bude stíhat pořád méně.

Toto neplatí pro startup nebo firmu, která vyvíjí sama pro sebe – tam totiž taková optimalizace padá. Na běžném trhu mi to ale připadá, jako mít firmu, kde řeknete 1 web = 50 tisíc, ať už budete chtít e-shop s exporty do účetnictví a skladovým hospodářstvím nebo běžnou firemní vizitku s pár texty a kontaktním formulářem.

V běžném štíhlém řízení se samozřejmě cenové odhady počítají. Štíhlé podniky se snaží o enormní efektivitu, s čímž se pojí to, že znají náklady až na úroveň halířů. Něco zprůměrovat a říkat, že se to statisticky vyrovná, to je špatné pochopení principu heijunka – vyrovnání výroby. Ve skutečnosti se při výrobě nikdy nic nevyrovná samo jen tak, ono se to vyrovná proto, že výrobu vědomě a řízeně vyrovnáme. Scrum má spoustu nástrojů, které vyrovnat výrobu umí (fixní backlog, ochrana týmu, fixní čas na vývoj, odstraňování překážek v roli Scrum Mastera, malé User Stories, bodování úloh, procesní řízení a zlepšování procesu, automatizace některých úkonů, jako je např. deployment). Obdobně má plno principů a postupů pro vyrovnávání výroby i tradiční štíhlé řízení – především ve striktní standardizaci výroby, kdy jsou některé úkony rozepsány s přesností na jednu vteřinu nebo pevným nastavením kadence, kdy všechna oddělení pracují stejným tempem a kdy nadprůměrně rychlá oddělení nemůžou fungovat rychleji dlouho, protože mu brzo dojdou díly z předchozího kroku a protože zásoby se udržují na minimální možné úrovni.

Backlog existuje tak jako tak

Zastánci Lean Software Developmentu argumentují, že Scrum je takový malý Waterfall. Že vznikají iterace místo toho, aby do procesu byly úkoly přidávány tak, jak po nich vzniká poptávka. Jak jsem zmiňoval v minulém článku, možnosti různých lidí doplňovat backlog vysokou frekvencí se dost liší. Od přímo project managera, kde bude v Leanu 1 úkol v backlogu až po zákazníka na pracovišti který může mít čas třeba jednou za 2 měsíce a ani ten Lean se nevyhne backlogu s klidně 80 položkami na vstupu.

Ve Scrumu se délka sprintu přizpůsobuje tomu, aby Product Owner stačil přichystat Stories, které pohromadě dávají smysl. Pokud potřebuje dvoudenní sprinty, ničemu to nevadí, Scrum se s tím dovede srovnat. Pokud nemůže častěji, než jednou za dva měsíce, i s tím se Scrum srovná, ikdyž pravděpodobně by si tým zavedl uvnitř „iterací pro zákazníka“ další menší iterace, aby měl šanci lépe poznávat svůj výkon v čase.

V originálním štíhlém řízení je backlog tak velký, jak velké jsou objednávky. Pokud zákazník deklaruje, že koupí miliardu automobilů, bude mít Toyota v backlogu miliardu položek. Umělá omezení na velikost backlogu jsou ve vývoji software běžná. U Scrumu proto, že tým musí každou User Story probrat a obodovat a kde je variabilita mezi návštěvní knihou a vybudováním API daleko větší, než když si zákazník objedná Priuse jednou modrého a podruhé zeleného s klimatizací. U Lean Software Developmentu je to proto, že trh je turbulentní a občas se opravdu může stát, že čekat 14 dni do konce sprintu může znamenat, že konkurence získá na trhu výhodu.

Kontinuální zlepšování nestačí

Zjednodušeně řečeno: Když potkáte amerického manažera, bude ho zajímat inovace – tedy výrazná změna, která skokem překoná konkurenci. Když japonského, bude ho zajímat kaizen – tedy postupné zlepšování po malých krocích. Postupné zlepšování je skvělé a je naprosto nezbytné pro zvyšování produktivity a kvality takovým tempem, že překoná konkurenci. Ale jak chcete do backlogu, kam můžete přidat jen 1 položku, zapsat, že chcete výrazně změnit architekturu? Abyste udrželi u skokové inovace kontext, musíte do backlogu dát všechny položky tak, aby to celé dávalo smysl. Jenže to v Lean Software Developmentu udělat nesmíte. Každá fáze má utažené limity na takovou úroveň, jaká je nejčastější – tedy na úroveň, kdy probíhá kontinuální zlepšování, kaizen.

I ve Scrumu se může stát, že se změna architektury nevejde do jednoho sprintu. Ale máte Product Backlog a z něj je celkový záměr snadno viditelný.

Zhodnocení

Mám-li to zhodnotit, je štíhlé řízení skvělé pro firmy, které vyvíjí dovnitř, které znají své směřování a které hlavně investují čas a úsilí pochopit i skutečné štíhlé řízení a principy, které za ním stojí a které se používají v továrnách. Bohužel co je dobré pro automobilku nebo továrnu na motory, je docela problematické ve světě software, kde je těžké navrhování, ne opakování. Některé z přenesených principů ale skutečně přináší hodnotu a je pravda, že praktické vyzkoušení v praxi podniku spíš pomůže než uškodí.

Scrum je metodika, která bude vyhovovat téměř všem. Její problém je ale v tom, že vyžaduje hluboké pochopení a stoprocentní podporu managementu. To má společné i s původním štíhlým řízením.

Úplně nejlepší, co si zatím umím představit, je kombinace všeho postavená nad Scrumem. Scrum je ekonomicky úspěšný a logický rámec, který by například bez omezení otevřených stories, vyrovnávání výroby a kratších sprintů nebyl zdaleka tak dobrý, jako když si tyto věci z Leanu odnese.

Pokud napíšu LS, „lean“ nebo „štíhlé řízení“, myslím Lean Startup. Původní metodika tak, jak je běžná například v Toyotě (Toyota Production System), není s Lean Startupem totožná.

V čem je tedy Lean Startup lepší než Scrum?

Menší backlog

V Lean Startupu je backlog velmi omezen. Na vstupu čeká minimum položek, které se musí udělat brzo. Neplánuje se „dlouho dopředu“ a řízení má možnost více ovládat obsah práce a ve spojení s častými releasy pravděpodobně i doručovat úspěšnější software. Vstupní přihrádka Kanban Boardu obsahuje právě tolik položek, aby nebyla úzkým hrdlem.

Vstupy plní ti, kdo jsou zodpovědní za produkt, obvykle jsou to project manažeři, product manažeři, zástupci zákazníka nebo u menších firem přímo majitel. Jejich časové možnosti se dost liší. Project manažeři přímo zodpovědní za tým mohou doplňovat kartičku denně, takže je na vstupu jen 1–2 kartičky. Vedení firmy se stará zároveň o obchod, dá se čekat, že doplní backlog třeba dvakrát týdně, to je např. 5 kartiček. Zástupce zákazníka může přijet rozhodnout tak jednou za dva týdny, to znamená, že naplní tak 20 kartiček, aby nebyl úzkým hrdlem. A pokud pracujete s korporací, jako jsou banky, pojišťovny, je běžná reakční doba 2 měsíce (tedy např. 80 kartiček).

Scrum by si z toho mohl vzít zkrácení sprintů na tak krátké, jak často má zákazník čas backlog doplnit. Tím získá zákazník maximální flexibilitu bez toho, aby byl obtěžován.

Ve skutečné štíhlé výrobě nic jako omezení vstupních kartiček neexistuje. Vezmou se všechny objednávky, zprůměruje se tempo přírůstku, promíchají se karty tak, aby se vyrábělo pro různé zákazníky v poměrech, v jakých objednávají a pracuje se.

Méně času s odhady

Ve Scrumu se stráví přibližně 1 den měsíčně časovými odhady. Zastánci Lean Startupu časové odhady nedělají – nebo je po nich minimálně metodika nevyžaduje. Na Kanban Boardu jdou kartičky a mají různou dobu od vstupu po release, zastánci LS ale věří, že po určitém množství hotových kartiček bude možné určit průměrnou dobu dokončení User Story.

Výsledkem by mělo být to, že ten 1 den měsíčně navíc se stráví prací, čímž se zvýší produktivita. Ano, je to tak. Když z auta odmontujete tachometr, přestane klást odpor a automobil taky trošku zrychlí.

Samozřejmě je zde otázka daná tím, že časové odhady obvykle nejsou při vývoji software nejpřesnější a nastává otázka, zda se tedy vyplatí je vůbec dělat.

Ve skutečných štíhlých výrobách (Toyota Production System, Six Sigma) se časové odhady opět dělají, stejně jako ve Scrumu. Podstatný rozdíl je v tom, že zatímco při programování je cílem maximální rychlost tvorby udržovatelného a otestovaného kódu (zkrátka čím dřív, tím líp), v tovární výrobě se propaguje systém tahu a tím pádem produkty vznikají takovým tempem, jakým jsou poptávány poté, co je vyrovnána výroba (heijunka). Časové odhady ve skutečně štíhlých výrobách slouží pro určení maximálního tempa výroby, které je ale poptáváno jen výjimečně. Po vyrovnání výroby je ve skutečně štíhlých výrobách nastavena kadence, tedy rychlost, jakou musí vznikat výrobky. Nutno podotknout, že v tomhle je průmysl napřed, nicméně jeho výhodou je, že i dost rozsekané User Stories mívají občas 8 hodin, zatímco v Japonsku stráví dělník s jedním dílem třeba 1 minutu času.

Scrum se z toho již částečně použil a úkoly jsou rozsekané na malé, což pomáhá vyšší přesnosti odhadů. Pojí se k tomu i rizika. O tom v dalším bodu.

Scrum hodně dělí úlohy

Nevýhodou Scrumu je, že hodně rozbité úlohy se sice dokončí brzy, otestují brzy a akceptují brzy, ale je obtížné sledovat kontext. Který úkol na kterém závisí. Který úkol nesmí vypadnout z backlogu, protože by ostatní User Stories nedávaly smysl.

Lean Startup žádná kritéria na velikost kartičky na Kanban Boardu nedává. Pokud daná práce dává smysl jen jako celek, posunuje se po Boardu vcelku a dělá se vcelku. Protože neexistují iterace, nevadí, pokud je úkol tak velký, že by v obdobném Scrumovém týmu byla práce přes délku sprintu.

Těžko říct, co by si z tohoto Scrum mohl odnést. Zvětšovat User Stories se mi v kontextu Scrumu ukázalo jako špatná praktika, která vede ke špatným časovým odhadům, obtížné kontrolovatelnosti práce a menší flexibilitě.

Skutečně štíhlé výroby mají úlohy rozdělené na přibližně jednominutové cykly, které jsou rozepsané do dalších 20 bodů. Továrna sice dostane objednávku: „vyrobit žlutý Prius s motorem X a výbavou Y“, ale procesy jsou tak standardizované, že se rozpadnou na tisíce malých úkonů. Skutečně štíhlá výroba tedy seká úkoly na ještě mnohem menší než Scrum (v LS uděláte třeba 1 úkol denně, ve Scrumu 2 menší, v Toyotě dělník udělá třeba 6000 standardi­zovaných úkonů denně). Mají ale podstatnou výhodu: výroba se v malých variacích neustále opakuje.

Omezení práce v procesu

Toto je vynikající bod, který školím, kudy chodím. V Lean Startupu existuje omezení, kolik úkolů smí být v dané fázi v určité chvíli. Obvykle je rovno počtu pracovníků, kteří za danou fázi zodpovídají + 1 za zablokované úkoly.

Tuto vlastnost jsme objevili nezávisle na Leanu jednoduše v praxi tak, že na konci sprintů končily třeba 4 rozdělané Stories. Jako Scrum Master jsem začal na koncích sprintů tlačit na dokončování úloh místo otevírání dalších a počet rozdělaných úloh na konci sprintů se redukoval na 0–1.

Lean (Startup i originál) toto dělení rozšiřuje na všechny fáze výroby. Je to určitý ekvivalent záměrného podzásobování některých částí podniku, aby se odhalila úzká hrdla výroby. Slova Taichi Ohna, jednoho z autorů Toyota Production System: „když klesne hladina vody (zásob), vynoří se kameny (úzká místa)“. Štíhlé výroby (Lean Startup i ty v Japonsku) pak v případě, že nějaký díl dojde, zastaví výrobu a přemýšlí, jak problém napravit (například lepší spoluprácí s dodavateli v systému just-in-time, automatickými podavači dílů, karta kanban je umístěna v zásobníku dílů výše a signál k doplnění pošle dřív). Obdobně pokud někde díly nedocházejí, znamená to, že dané místo je nadzásobeno.

Oddělení releasů od přelomů sprintů

Ikdyž to Scrum nikde nepřikazuje, je běžné, že releasy se dělají v průběhu sprintů. Do LS pošlete kartu release a on se stane. Praktika toho, proč se dělají ve Scrumu releasy méně často, je daná tím, že tým má volnost, v jakém pořadí úkoly dokončí, udělat tedy v průběhu sprintu release vyžaduje, aby byly hotové vlastnosti, které musí v release být. V tomto nabídí LS managementu vyšší úroveň řízení, což je částečně klad a částečně zápor.

Nejlepší praktikou, kterou můžete vidět, je Continous Delivery (někdy Continuous Deployment). V zásadě každý akceptovaný úkol je doručen ihned do produkce. Tento krok ale vyžaduje velké investice do infrastruktury a výborné otestování nejen samotného úkolu, ale celého systému, aby se zabránilo častým chybám (typicky upraví se jedno místo aplikace a rozbije se to někde úplně jinde).

Systém tahu

Systém tahu v originálním Lean začíná tím stylem, že podnětem pro práci je konkrétní objednávka. V okamžiku, kdy se objednávka v systému objeví, zamíchá se do stávajících objednávek, aby byla rovnoměrně zastoupena (víckrát zmíněná zásada heijunka). Pak se podle objemu objednávek nastaví kadence (počet úkonů na pracoviště a čas) a to až do té míry, kdy kadence odpovídá 100% vytížení.

V Lean Startupu je omezení na vstupu, objednávka tímto způsobem nevstupuje. Musí počkat, dokud se neuvolní první volný „slot“ na Kanban Boardu.

Další vývoj je už shodný s originálním štíhlým řízením. Pokaždé, když nějaké oddělení dokončí práci, dostane vstupy od předchozího oddělení. Nefunguje takzvaný systém „protlačování“ – rychlejší oddělení zahrnuje všechna pozdější oddělení spoustou dílů (vyžaduje skladování) a trpí nedostatkem vstupů od předchozích méně produktivních oddělení. Kadence celé výroby je synchronizovaná a díly plynou stejnoměrně. Nadvýroba je v systému tahu stejně tak chyba jako nedostatečná výroba. Nadvýroba je považována za plýtvání (muda), ve štíhlém podniku pracují všechna oddělení stejným tempem, aby se nikde nehromadilo víc výrobků, než je nezbytně nutné, pro další fázi.

Scrum by si z toho mohl vzít opět krátké sprinty, častou komunikaci se zákazníkem a vkládání úkolů do backlogu podle „financování“ týmu. Dvakrát větší objednávka (A) bude brát týmu proporčně více času, než menší (B). Výroba se tedy rozdělí na sled AABAABAAB.

Ve Scrumu ani Lean Startupu se tolik tým neřídí, je zároveň otázkou, jestli je to pro kontext vývoje software vůbec žádoucí.

Shrnutí

Lean Startup má Scrumu hodně co nabídnout. Sám jsem začal omezením práce v procesu, zjednodušováním časových odhadů a zkracováním délky sprintů začal praktikovat štíhlejší postup. Do budoucna bych určitě chtěl více práce udělat pomocí systému tahu.

Pokud něco vyrobím, je to můj majetek, pokud neurčí smlouvy, které jsem podepsal, něco jiného.
Mám neomezené právo určit, jak bude můj majetek používám, šířen a používán, pokud se toho práva dobrovolně nezbavím.
Můžu si najmout kohokoliv, aby moje právo vymáhal a nikdo nemá právo mě nutit nebo mi bránit v tom, abych si takového zástupce (ne)vybral.
Krádež je neoprávněné přemístění, používání nebo sdílení majetku v rozporu se smlouvou nebo bez smlouvy jako celku.
Pokud si do smlouvy dám pokutu třeba bilion za každé neoprávněné sdílení, pokud druhá strana na smlouvu přistoupí, je vše v pořádku a měla by zaplatit.

Autoři něco natočili. Část svých práv postoupili distributorům (ti film šíří do kin, televizí, po DVD) a ti za to platí autorům podíl. Sdílí oprávněně a podle smlouvy. Pokud smlouvu poruší, musí platit nemalou pokutu. Další část svých práv delegovali na firmy, které chrání autorská práva. Tyto firmy kontrolují reprodukci děl a případně vymáhají poplatek, který patří autorovi. Protože autor nedal „komukoliv“ právo dané dílo sdílet (pak by se vůbec s žádnou ochrannou institucí nepaktoval), má taková instituce plné ruce práce. A protože je obtížné zjišťovat, kdo práva autora porušuje, vede to k tomu, že ochranné svazy mají pravomoci podobné policejnímu státu. Je to škoda, ale jediná alternativa, kterou vidím, by bylo zavedení „preventivní pokuty“, což vidím jako ještě horší variantu. Kdyby ochranné svazy nedělaly svou práci, majitel autorských práv je může žalovat a vymáhat peníze po nich.

Zdravý rozum mi říká, že zástupci autorů jsou v právu.

Ale… zároveň si říkám, že je něco principiálně špatně, pokud je v desetimilionovém státě tím pádem 9 milionů kriminálníků. Zákon, který staví mimo zákon většinu svých občanů (kteří navíc stahování nevnímají jako nic nemorálního) a je prakticky nevymahatelný, by neměl existovat. Takový zákon je dobrý jen pro ty kriminalisty, kteří potřebují někoho nepohodlného za něco zavřít, nemají dostatek důkazů, tak ho chytnou alespoň za to, co se dá přišít skoro komukoliv.

Zdravý rozum říká, že zákon, který udělá z většiny občanů kriminálníky, je špatný.

Takže stahování musí zůstat legální. Na druhou stranu šíření nesmí být legální. U filmů je totiž problém v tom, že stáhnout si něco, nevyžaduje takové úsilí, jako ukrást Porsche. Přitom tržní cena 2000 stažených filmů je podobná, jako cena Porsche.

Pokud někdy něco natočím, chci, aby mé dílo lidi používali tak, jak bude uvedeno v distribučních podmínkách. Problém je ale v tom, že poměr tvůrců/konzumentů může být tak 1/1000 a protože v demokracii má „dav vždy pravdu“, vydaly se diskuze nesprávným směrem. Status quo je výhodný pro 1000 konzumentů a opomíná se, že ten 1 autor má absolutní právo říct, že nechce, aby na jeho film koukali lidi ve čtvrtek, pokud se jmenují Jiří, nosí trenýrky, mají na nose pihu nebo pokud si film stáhli z internetu. A konzumentovi, pokud se jim to nelíbí, nemají právo pravidla ignorovat, mají právo si natočit svůj film a nastavit si svá pravidla. A nebo ho sami začít sdílet volně kdekoliv, kdykoliv, komukoliv.

Takže mám velkou radost a spouštím svůj foodblog Foodist.cz.

Počítám, že budu psát jednou týdně článek, kde se zaměřím na:

• techniky vaření (jak volit suroviny, jak uvařit vejce do ztracena, jak uválet sushi)
• konkrétní recepty (osobně se zaměřuji hlavně na italskou kuchyni, ale nebude to podmínkou)
• časem i videa, kdy ukážu přímo v reálném čase, jak dané jídlo uvařit rychle a jednoduše
• osvěta v kuchyni (vyvrátit plno mýtů, které panují o některých jídlech a která v Česku jen málokdy dostanete správně udělaná)
• občas (výjimečně) napíšu nějakou tu recenzi na koupenou surovinu (třeba srovnám různá másla) nebo restauraci

Hlavním posláním webu je naučit lidi to, že vařit nemusí brát moc času a není dražší, než když si člověk koupí polotovar.

Vaření je mou vášní půl mého života a jsem šťastný, že jsem získal skvělý tréning jak doma, tak v zahraničí.

Chcete zůstat ve spojení? Sledujte mě na Twitteru (zatím účet pro všechny články i z IT a produktivity, časem nejspíš vznikne souběžně účet jen pro Foodist.cz) nebo si mě přidejte na Google Plus.

Současný stav

Základní škole je prvotní – nespecializovaná – přípravka na život. Rolí jakékoliv školy je vzdělávat a zároveň vychovávat. Žák se ve škole socializuje, učí se týmové hře, učí se učit, získává přehled o všem od gramatiky přes vztlak nebo datum vzniku Československého samostatného státu nebo co je to globule. Ve škole učí učitelé, to jsou vysokoškolsky vzdělaní lidé zhruba mezi 20 a 80 lety, kteří stojí čelem k žákům, píší na tabuli a žáci si opisují. Občas nějaký učitel použije pomůcky, například kazeťák, video, výukový software, mapu. Velmi vzácně vyjdou žáci ven. V podstatě jsou žáci mimo školu:

1. když je tělocvik
2. když jsou s přirodopisem na výpravě
3. když se fotí
4. když jdou k zubaři
5. když jedou na školní výlet

Žáci postupují po ročnících od 1. třídy až po 9.. Na začátku se učí číst, psát, počítat, ale i prvouce, tělocviku apod. Na konci už mají poznávačky rostlin a musí vědět spoustu faktů o spoustě míst a historických okamžiků. V 9. třídě má vyvrcholit znalost gramatiky a slovy naší tehdejší učitelky: „teď umíte gramatiku nejlépe v životě“. Vzhledem k tomu, že nikdo z nás nešel ani na učitelství češtiny, ani bohemistiku, ani žurnalistiku, měla úplnou pravdu.

Problém

Učivo na základní škole se dá rozdělit do dvou skupin. První jsou znalosti, které použijete v praxi. Těch není až tak moc. Je tam gramatika, cizí jazyk, trochu slohu, počty, nějaké základy v každém předmětu (bude míč naplněný vzduchem plavat? bude plavat, když místo vzduchu dám písek?). Druhá skupina jsou věci, které můžete a nemusíte použít.

I ty jdou rozdělit:

• příprava na střední školy: jeden půjde na průmyslovku a druhá na učitelku v mateřské škole. První musí znát ohmův zákon a když nebude umět pokrátit vzoreček, nezvládá školu od začátku. Druhý musí být vybavený všeobecnějším rozhledem a hudebním sluchem.
• obecné znalosti: v čele ČR stojí president. Hlavní město Japonska je Tokio. Lev patří do čeledi kočkovitých, rodu šelem.

Kde je problém? V první řadě v souběžnosti tří skupin (informací nezbytných, přípravy na SŠ a obecných znalostí). Jenže my musíme naučit hlavně to nezbytné, to se musí žák dozvědět co nejdřív (v tu chvíli bych mu dal klidně i volební právo, nezávisle na tom, že je mu tou dobou 11 let). Pak teprve se bude žák učit přípravu na střední školu a obecný rozhled. Tím, že studenti se naučí nezbytné brzo, je možné s nimi pořád opakovat, aby si téma velmi dobře zapamatovali. Není možné postavit na rovinu schopnost psát velká písmena s rovinou v čele ČR stojí president. 99 procent lidí se s vlivem prezidenta nikdy nesetká. Běžný člověk má kontakt s prezidentem maximálně tehdy, když píše ve vězení žádost o milost. Kdežto takové RPSN, s tím se každý za život potká několikrát.

Problém tedy je, že chybí důležitost informace. Problém je, že důležitá informace se netestuje víc, než nedůležitá. Problém je, že všechny známky jsou stejné.

Další problém je statická role učitele a žáka. Žák, který jen opisuje z tabule, si zapamatuje velmi málo. Tak málo, že si musí potom látku mnohokrát zopakovat, aby si ji pamatoval i o rok později.

Návrh

Já pevně věřím, že by si učitelé měli (nechat) udělat výzkum, jaké informace člověk v životě potřebuje. Tyto informace by se učily jako první.

Takže nejdřív se žák naučí celou gramatiku, počty, stoprocentně by měla v osnovách být finanční gramatika (prý bude). Žák musí ze školy odcházet s vědomím, co je RPSN, ikdyby nezbyl čas na to, co že je to hlavní město Japonska.

Způsob výuky musí zapojit žáky. Moje představa je (nevím, jestli by fungovala), že první ověření naučených znalostí by bylo přímo na konci hodiny. Další ověření by bylo za týden. Pak by fungovaly samozřejmě nějaké pololetní písemky a možná by se testovaly znalosti i z předchozích ročníků (v dějepise bych zahrnul vše od doby kamenné až po okamžik, kde právě studenti v učivu jsou). Žák, který by propadl, by tutéž zkoušku psal znovu příští školní den.

S tím se pojí to, že mnoho zkoušek by bylo na počítačích bez nutné účasti učitele. Učitelé by kontrolovali písemky v těch předmětech, které vyžadují pochopení a souvislosti (slohovka, matematický výpočet).

Další věc je, že každý student vyššího ročníku by v určitém okamžiku učil základy studenta nižšího ročníku. Učením se informace prohloubí a upevňuje.

Zmenšil bych objem naučených informací a jak vidíte, věnoval bych čas jejich upevnění. Další věc jsou nepovinné předměty. Někdo kolem 11–12 let by byla spousta předmětů volitelných. Všichni by už měli Fyziku základ a rozhodovali by se, jestli chtějí Fyziku I, II, III, IV, nebo jestli chtějí víc času věnovat Chemii I, II…, Každý žák by musel naplnit „volné sloty“ předměty.a

Role učitele by se také změnila. Studenti by používali víc IT, výukové programy, vysvětlovali by si témata navzájem. Učitelé by táhli vždy ty první, kteří naučí všechny ostatní, moderovali by diskuze a pomáhali by mladým studentům-učitelům. Plus by samozřejmě dál zpracovávali písemkový aparát.

Žák, který chce umět vše, by si mohl napsat víc modulů mimo volné sloty. Tyto moduly by už rodiče škole platili. Do škol by byli puštěni i lidé z praxe, kteří prošli nějakým kurzem, jak naučit učit starší studenty, s připraveným výukovým SW a připravenými testy. Následkem toho by bylo, že některé školy by jako volitelné předměty mohly vypsat třeba Právo I, II. Na toto by musela být návaznost na středních školách, kde by pak bylo Právo základ odpuštěno.

Vstup na střední školu

Střední školy by vyžadovaly určité moduly. Například průmyslovka by vyžadovala Fyziku I-IV, Chemii I-II, Matematiku I-IV. Pokud by žák stihnul splnit požadavky dřív, mohl by na střední školu už třeba z 8. třídy. Stejně tak by se mohl už třeba ze 3. ročníku dostat člověk na VŠ (ano, na vysoké by šli zaměření a talentovaní lidé už v 17 letech).

Přechod na učňák

Učňáky by vyžadovaly jen základ a max úroveň II z libovolných modulů. Výslekem je, že by na učňák mohlo dítě odejít už ve 12 letech. V 15 by dítě už šlo do praxe, začalo si vydělávat apod. 15 je dnes už dobrý věk. Spousta patnáctiletých je vyšších, než jejich učitelé. Kdo ví, jestli nejsou i silnější. Intelekt hodnotit odmítám, rozptyl je moc velký a srovnávat s učitelem (který musel udělat VŠ) by bylo nefér.

Přechod rovnou do praxe

Základní školu by bylo možné opustit v 11 letech. To je pořád dost brzo, když se na 11leté podíváte, víte, že pro praxi ještě nejsou připravení. Ti by nejspíš navázali na další krok, který zmíním jako Soustavné vzdělávání.

Soustavné vzdělávání

Plno absolventů by nastoupilo jen na poloviční úvazek. Zbytek času by se věnovali tomu, že by si na školách pořizovali další a další moduly. I ten, kdo odešel ze školy v 11 letech, by si po modulech mohl studovat a studovat, až by skončil jako inženýr. Stal by se jím třeba ve 30, ale díky spoustám a spoustám zkoušek by věděl všechno po cestě daleko lépe, než dnešní studenti, kteří se musí naučit na zkoušku a pár dní po zkoušce o tématu nic neví.

Další věc je, že já považuju pětidenní pracovní týden za přežitek. Pozůstatek otroctví a nevolnictví, který se přetransformoval do pracovní doby 6 dní v týdnu, 12 hodin denně, což se časem změnilo na 5/8. V budoucnu určitě uvidíme vývoj typu 4/6–7. Výsledkem by mělo být to, že zaměstnavatelé budou akceptovat kratší pracovní dobu (nevěřím, že někdo je schopen se soustředit 8 hodin, to spíš 3 hodiny z pracovní doby stojí lidi u kávovaru nebo brouzdají po sítích, i v továrnách jsou často zašívárny) výměnou za vyšší produktivitu a to, že se budou lidé ve volném čase dál vzdělávat a tak činit až do důchodu, někteří ještě déle.

Myšlenka je v knize Cashflow kvadrant opsána pohádkou. Její děj je ve docela blbý a dá se ve zkratce napsat takhle:

• Vesnice je odříznutá od vody.
• Dva lidé dostanou licenci nosit vodu z řeky.
• Jeden si hned koupí kbelíky a začne nosit.
• Druhý zmizí na několik měsíců.
• První vydělává plno peněz, protože nemá konkurenci. Celý den tahá vodu a je celkem bohatý.
• Najednou se objeví druhý, má investora, postaví potrubí a cena vody poklesne na 1/4.
• Navíc dodává vodu i o víkendu, kdy první si dával volno.
• První nadosmrti dře za málo peněz.
• Druhý rozšíří svou síť i na další vesnice a dožije zbytek života bez nutnosti pracovat bohatý.

Chápu, že Kiyosaki píše většinou pro lidi bez finančního vzdělání a navíc je to typická motivační literatura. Samotná představa schovaná za tím je ale trošku hlubší, když se nad tím člověk zamyslí.

Máme analogii: nosit kbelíky = dělat práci, při které prodávám svůj čas za X korun; stavit potrubí = budovat systém, který přináší hodnotu a vyžaduje jen malý fixní čas na údržbu.

Prošel jsem si své GTD a hledal jsem byť jediný úkol, který by měl vybudovat potrubí. Nenašel jsem ani jeden. Všechny pracovní úkoly se týkaly toho udělat výzkum trhu, získat zákazníky, udělat to nejlepší pro zákazníka a pak se starat o zákazníka, administrativa okolo nebo zakázkový vývoj.

Věc je ale složitější. V knize se píše o archetypu podnikatele, který vystavěl potrubí (kbelíky nosí podle knihy zaměstnanci a živnostníci) a sám může odjet na rok na dovolenou a podniku se bude dařit dál a pořád lépe. Já si myslím, že to je hloupost. Pokud se nebavíme o korporacích, ale běžných firmách o cca 10 lidech, kterýma projíždím, nestalo se mi nikdy, že by majitel podniku nepracoval minimálně stejně tvrdě, jako jeho nejlepší zaměstnanci. V tom se kniha mýlí: vybudovat firmu a mít zaměstnance ještě člověka nezbaví nutnosti nosit kbelíky. Ikdyž vedete lidi, nosíte kbelíky. Ikdyž školíte, nosíte kbelíky.

Když nad tím s odstupem času přemýšlím, jak jde stavět potrubí, leccos mi dochází.

Když zavedete Scrum, tým se začne řídit sám, nemusíte je vést: spousta kbelíků se odnese sama. Když zvolíte Product Ownerem někoho jiného, kdo taky pracuje samostatně (třeba project managera), celý projekt se začne řídit sám. Voilá, z podnikatele – nosiče vody – se stal podnikatel – stavitel potrubí. Věc bude složitější, ale věřím tomu, že cíl je dosažitelný.

Nebo když nechcete mít zaměstnance, je velký rozdíl mezi tím vyvíjet software pro někoho za hodinovou sazbu (nosit kbelíky) a vyvinout software, který pak budete prodávat, licencovat nebo nabízet. První je jednodušší, nemusíte umět prodej (dnes má schopný programátor práce nadbytek), nemusíte se starat o tolik faktur, nemusíte umět jednat s tolika cizími zákazníky a mohl bych pokračovat.

Na závěr chci říct, že nemusí být špatné stát se nosičem kbelíků. Celý život jím je většina lidí. I mnoho úspěšných podnikatelů jsou nosiči vody. Jakmile zemřou, jejich podnik se zhroutí. Ale oni měli celý život pocit, že skutečně něco dělají. Obdobně nemusí být dobré stát se stavitelem potrubí, kolik máme „internetových podnikatelů alá webtrh“, kteří hrnou jeden MFA web za druhým, prodávají a kupují domény a sází na lidskou hloupost, kolik máme podnikavců, kteří vykrádají texty z cestovatelských blogů a vkládají je na své weby s affiliate prodeji zájezdů. Buďte tím, kým být chcete, ale uvědomujte si příležitosti a rizika obou cest.

Zhruba před jedenácti lety jsem opustil svět Windows a začal používat Linux. V té době dost hard-core svět, kde i můj oblíbený Mandrake (dnes už Mandriva) vyžadoval dost zásahů do souborů v /etc/ a na všechno nebylo klikátko, jako dneska.

Těch 8 let na Linuxu determinovalo to, jak vlastně používám počítač a co chci nebo nechci.

Bylo pár pozitiv, která jsem zjistil a která ovlivnila to, co budu chtít i od OS X

• příkazová řádka je nesmírně užitečný a produktivní nástroj (Windows mají v roce 2012 příkazovou řádku horší, než měly UNIXy před 30 lety, takže nejspíš mi porozumí Linuxáci/UNIXáci)
• přestal jsem řešit viry, trojské koně
• celý systém je stavebnice, framework, který se dá použít a udělat z Linuxu pračku, kalkulačku, sálový superpočítač, databázový server, router, mobilní telefon
• všechno je podřízeno tomu, že systém je primárně nastaven jako server. Takže zapomeňte na vynucované restarty každých 10 dní.
• všechno je stabilní – to už dneska není nic až tak extrémního. Windows jsou stabilní systém a nemusí se (kromě updatů) restartovat téměř vůbec. V roce 2002 to bylo úplně jinak a vtipy na stabilitu software z Redmondu byly tou dobou daleko aktuálnější.
• balíčkovací systémy – to je úplná bomba, kterou by měl mít každý OS
• objevil jsem Emacs, luxusní textový editor, společně s VIMem jeden z nejsilnějších na planetě. Navzdory vtípkům na jeho adresu, jsem dokázal soubory editovat rychleji, než okolní vtipkující se svými PSPady vůbec tušili, že je možné.
• nekradu software. Ano, už víc než 10 let jsem neukradl žádný software.

Na druhou stranu nebylo všechno tak růžové. Našel jsem i věci, které mě štvaly:

• čekat na odpojení zařízení (flashky, externího disku, vysunutí DVD) je opruz, který mi vadí a nebaví mě
• vypadalo to hnusně. Ano, nenašel jsem Linux, který by vypadal super. Buďto to byly minimalistické Window Manažery, kde byl člověk rád, že mu to udělalo aspoň rámeček kolem okna. Na straně druhé byla přeplácaná KDEčka, Enlightment a Gnome, které vypadalo jako Windows 95. Když jsem na internetu našel screenshot pěkného Linuxu, bylo pod tím asi 8 programů, který si dotyčný musel nainstalovat a nastavit, aby to vypadalo tak hezky.
• použitelnost mnoha programů nestála za nic. Bylo vidět, že GUI aplikací často někdo dělal tak, že jen natahal inputy do okna, nalepil je na třídy a žádný test použitelnosti se nekonal. Situace byla před tou spoustou let tak hrozná, že spustit film s titulky bylo rychlejší z příkazové řádky, než z GUI.

Když jsem na podzim 2009 měl nějaké peníze na nový počítač, vycházel jsem z toho, že chci Linux nebo UNIX (stavebnice, příkazová řádka, balíčkovací systém), ale zároveň chci něco, co bude hezky vypadat, zvládne to používat i přítelkyně a nebude porod dělání některých základních věcí (jako třeba úprava grafiky, kterou jsem sice v GIMPu byl donucen ovládnout, ale pořád to nebylo to pravé ořechové). No a z toho mi vychází Mac OS X.

Pod kapotou OS X je Free BSD. Navzdory lžím, že OS X je uzavřený a nedá se nastavit, složka /etc/ je tam, kde jsem ji v Linuxu nechal (ano, naklikat se leccos nedá, ale na to už jsem z Linuxu zvyklý). Příkazová řádka je stejně dobrá, jako na Linuxu. Emacs je přenesený mizerně, nevadí, naučil jsem se používat VIM a jsem stejně spokojený. Na balíčkování jsem po macports a finku přešel na homebrew, který mě zatím nikdy nezklamal.

Později jsem objevil plno dalších benefitů:

• OS X má spoustu klávesových zkratek, trvá ovládnout je, ale dnes využívám víc zkratek, než kdy dřív.
• pokud chci software hezký, klikací, použitelný, většinou v AppStore najdu za pár dolarů existující. Pokud chci software zdarma, přes balíčkovací software si nainstaluju to, na co jsem byl v Linuxu zvyklý.
• OS X se programuje pomocí Objective-C. Ten jazyk je mi ohromně sympatický. Vlastně mi na něm vadí jen to, že se omezuje na C syntaxi.
• zdá se mi, že tvůrci webů a frameworků dnes používají hlavně OS X. Ať už se dívám na screencasty o PHP frameworcích, Ruby on Rails, nebo jiných technologiích okolo webu, nejčastěji potkávám systém OS X. Dokonce GIT, který je Linuxový a je určen primárně pro verzování kernelu, vidím ve screencastech demonstrovaný hlavně na OS X. Výsledkem toho je, že mám jistotu, že jejich kód je pro OS X odladěný a bude mi fungovat.

V posledním bodě musím vyzdvihnout vlastnost vývojářů pro OS X, kterou jsem jinde neviděl. Totiž určitou snahu o to, aby byly nástroje pěkné a zároveň funkční a vhodné právě na 1 konkrétní věc (byť ta věc může zahrnovat stovky úkonů). Nástroj je hotov ne tehdy, když se chová, jak má, ale když zároveň vypadá skvěle a do systému dobře zapadá. Na OS X jsem nezažil, že bych si stáhnul z AppStore software, kde vývojář jen „vyblil“ CRUD, nalepil ho na nějakou Cčkovou knihovnu a šel to prodat za 5 dolarů. Vždy tam byla přidaná hodnota (včetně klávesových zkratek).

Kdybych musel přestat používat OS X, návrat k Linuxu by byl pro mě těžký (k Windows nemožný). Z toho ostatně vyplývá něco, co na uživatelích OS X (a iOS) můžete vidět. Neohromíte nás tabulkami. Ikdyby jste nám nabídli 1 milimetr tenký netbook s výdrží 200 hodin, dvacetijádrovým procesorem a 64 gigabajty ramky, je to jen bezcený vrak, pokud na tom neběží OS X. Jen jedna věc je lepší než Macbook – novější Macbook.

Poznámka: pokud máte pocit, že vám OS X vnucuju, jděte pryč. Pokud máte pocit, že mi to musíte v komentářích nandat, jděte pryč. Pokud nechápete, že se jedná o subjektivně zabarvený slohový útvar a ne výčet faktů, jděte pryč. Za komentář všech ostatních budu vděčný.

Zato…

Kouzelné slovíčko. Čecháček. Nebo ještě lépe zaprděný čecháček. To jsem potkal už mnohokrát. Osobně i na internetu. U lidí sprostých i těch, u kterých bych to čekal nejméně.

Ano, Češi mají v dějinách jen pár velikánů. O to méně si jich kolikrát vážili (vzpomeňme na jméno Wichterle). A ano, nejsme velcí vojevůdci, umělci, nebo světově vyhlášení kuchaři.

Přesto mi přijde neskutečně stupidní odkazovat na čecháčkovství. Vlastnost, která se za tím má skrývat je neschopnost vidět za svůj dvorek, implicitní předpokládání, že jsou všichni jako Češi. Čecháčkovství je synonymem provincionalismu. V poslední době je hlavně označen za čecháčka každý, kdo nepřijímá nekriticky cokoliv, co přijde ze západní Evropy (což je paradoxně naprostý opak provincialismu).

Copak tohle je typicky česká vlastnost? Něco, čím můžete počastovat > 51 procent obyvatel? Doboha, lidi cestují víc než kdy v historii. Učí se jazyky. Koukají na zahraniční filmy. Denodenně vidí zprávy v televizi nebo na internetu z celého světu. Informace se na Twitteru šíří takovou rychlostí a Češi nejsou ušetřeni (vzpomeňme na nedávné protesty proti SOPA nebo řádení hackerské skupiny Anonymous). Většina lidí v ČR, které potkávám, má zájem poznávat různé kultury, dělat věci, které dělají lidé po celém světě. Češi rozhodně nejsou národem buranů, kterým stačí koza uvázaná u stromu za barákem.

Osobně nejsem vlastenec ani co by se za nehet vešlo. Dovedu si velmi snadno představit, že jsem se narodil o 100 km jižněji a už bych byl Rakušan. Nevnímám v národnostních kategoriích. Těch 100 km není nic, co by mělo člověka nadosmrti stigmatizovat. A třeba budu žít mimo ČR. A nebudu ani trochu litovat. Ale rozhodně nebudu na Česko kydat špínu.

Jooo, tam jsou čecháčci. Vesničani, kteří se cítí jak Švejkové, když to „Evropě osladí“.

Až vás někdo označí za čecháčka, poděkujte mu. Připomene vám, že na internetu nejsou jen slušní a chytří lidé. Až vás někdo označí za čecháčka proto, že nepřijímáte něco z EU, poděkujte ještě jednou. Řeknete tím narovinu: Mám svůj rozum, libo český/slovenský, ale nikdy jsem nezkrachoval, vždy jsem dodržoval pravidla, která jsem si sám stanovil, narozdíl od těch samozvaných rádců.

Nedávno jsem narazil na projekt Day Zero. Idea za projektem je v tom, že za 1001 dní si prožijete 101 zážitků. Těch 101 zážitků si můžete vymyslet sami, nebo si můžete na stránkách vybrat ze stovek tipů. 1001 dní je dost času na to, aby člověk skutečně dotáhl věc do konce, ikdyž některé navrhované úkoly jsou hodně náročné (udělat svou fotografii 365 dní v roce, naučit se cizí jazyk, oženit se), jiné jsou na chvilku a dají se zvládnout jakoby mimochodem (líbat se v dešti, sledovat východ i západ slunce v jeden den).

Someday/Maybe se hodí i pro pracovní záležitosti. Místo toho 101 seznam se hodí jen na zážitky. Těch ale mívám v SomMay nejvíc. Výhoda seznamu 101 je v tom, že místo pětiprocentní úspěšnosti využiju celý seznam úkolů. Výhoda je, že se jedná o koncentrovaný seznam zážitků.

Na odkazovaném webu Day Zero jsem si profil založil, naskládal jsem si tam něco přes 20 zážitků. Teď si jdu 2 vybrat na tento týden. Možná i vy najdete něco, co stojí za prožití.

• instaluju Flash, Skype, Google Chrome (používám jako duplicitní prohlížeč, protože se mi v něm lépe ladí Javascript), Things (GTD software), Pages (Word, ale jednodušší), Keynote (Powerpoint, ale lepší), Numbers (Excel, ale trochu divný), Dropbox (sdílení souborů), Day One (osobní deník), MacVim (jeden z nejlepších editorů na světě), Kindle (kdo by dnes ještě kupoval papírové knížky?), XCode, Last.fm (nekonečný zdroj hudby), Mercurial (verzovací software pro lidi 21. století), OmniGraffle Professional (neskutečně praktické udělátko vhodné na výkresy, prototypy, mind mapping a tunu dalších věcí), iTerm (vylepšená příkazová řádka), Open Office (pro případ nouze), Transmit (FTP klient), Pomodoro, Picassu, Quicksilver (super udělátko, pomocí kterého jde rychle dělat spoustu opakujících se činnosti, např. posílání mailů, zipování souborů, časované spouštění software atd.), Vlc, Sequel Pro (asi nejlepší mysql klient), homebrew (balíčkovací systém), mysqld (databáze, která umožnila úspěch firem jako Facebook nebo Twitter)
• vypnu zvuky v e-mailu, kde nastavuju zároveň kontrolu pošty každou minutu
• vypnu zvuky ve Skype
• synchronizuju kalendář s Google Cal
• stáhnu si poštu z GMailu
• nastavím si změnu klávesnice z CZ na EN na CMD-SHIFT-SPACE
• rozběhnu Apache (= povolid sdílení webu v Preferences), povolím PHP v httpd.conf
• přenesu si GTD do Things (komplet kromě Someday/Maybe, tam si dovedu brzo vymyslet plno dalších věcí)
• upravím příkazovou řádku na téma Homebrew
• rozběhnu vim a shell podle svých preferencí
  • mám MacVim se spoustou pluginů a vlastních nastavení
  • rozběhnu oh-my-zsh (spousta pluginů, barevných témat a vychytávek pro ZSH)
• stáhnu si dokumenty do školy
• zprovozním zálohování na lokální disk

Uf. Je toho dost, ještě že se OS X musí přeinstalovávat jen když si koupíte nový stroj.

Prošli jste si cestou od elektronu po JavaScript a měli byste rozumět úplně všemu, co se na počítači děje.

Nastoupíte do praxe a začnete se učit znovu. Hlavně proto, že v praxi jsou z nějakého důvodu věci často trochu jiné, než v akademickém prostředí, kde důležité bylo, aby to prošlo na přepínač -Wall -pedantic a zčásti i proto, že vysoká škola nemá prostor naučit všechny obory do hloubky.

První rok v praxi je člověk zase student. Nic moc neumí a nic moc neví. Druhý rok už rozumí běžným úkolům a ovládá je, přestože není žádný super architekt a každý týden zjišťuje, že dělá všechno špatně. Po nějakých třech letech praxe už dokáže vývojář pracovat samostatně na libovolných úkolech (byť je párové programování skvělé a sám ho praktikuju, ikdyž mám praxe násobně víc).

Kladu si otázku. Je po těch 3 letech v praxi nějak ve výhodě absolvent VŠ proti tomu, kdo šel pracovat rovnou po maturitě nebo se na školu po roce, dvou vykašlal?

Klady:

• největší klad vysoké školy: získáte inteligentní přátele na celý život
• máte matematické zázemí
• můžete pracovat na univerzálnějších problémech, protože znáte fyzikální děje, které jsou za tím, když se „čte čárový kód, digitalizuje se obraz, v obrazu se kód hledá, nalezený kód se posílá do ISu, ten to ukládá do databáze“. Člověk, který tu VŠ nemá, může rozumět všemu, ale nejspíš bude víc specializovaný, takže bude dobrý buď někde v oblasti čtení a parsování kódu, nebo v oblasti zpracování a uchování
• pokud už někoho téma baví, je výhodné mít učitele, který téma vysvětlí a dodá detaily a návaznosti na další obory

Zápory:

• je o 5 let starší
• spousta studentů nemá matematické ani fyzikální schopnosti už v průběhu studia. Potkal jsem plno studentů, kteří denně hráli Counterstrike, týden před zkouškovým všechno nahrnuli do hlavy a týden po zkouškovém už si pamatovali 10 procent. Opravdu bych nechtěl ležet v nemocnici, kde by mě naživu udržoval přístroj programovaný někým takovým!
• absolventi VŠ nastupují na juniorskou pozici, oproti stejně starým spolužákům, kteří jsou tou dobou už v seniorských pozicích.
• na vysokých školách se nenaučíte výrazně specializované informace. Někteří mají to štěstí zaprogramovat si v node.js, používat Mercurial a psát Behaviour Driven Development testy a organizovat týmový projekt pomocí Scrumu. Velká část studentů bude nezanedbatelnou část školy psát v C/C++, používat SVN, testy nebudou psát vůbec, maximálně v 1–2 předmětech (přestože není důvod nevyžadovat spustitelné testy od funkcionálního programování přes Javu až po shell).
• vysoká škola není svobodná. Argument, že „člověk se dozví hodně věcí“ je lichý. Všichni lidé v IT se denně učí a ti, kteří mají jen maturitu, nejsou vyjímkou. Nemožnost vybrat si obsah učiva je negativum, ne pozitivum.

Zhodnotíme-li to, je vysoká škola skvělá, pokud chcete rozumět skvěle teorii, budete spojovat více oblastí, které přesahují jednu specializaci, budete pracovat s technologiemi staršími než 5 let, nebo pokud chceme zůstat na VŠ a učit.

Pokud chcete dělat jednu konkrétní věc: informační systémy, e-shopy, 3D grafiku, rozpoznávání obrazu, programování jádra Linuxu apod. je daleko lepší těch 5 let věnovat specializaci. Za 5 let se můžete stát respektovanou autoritou v úzké výseči lidských vědomostí. A dokud člověk zůstane ve svém oboru a ostatní bere jen jako koníček, absolventi VŠ ho nikdy nedoženou.

Jak se rozhodnout? Pokud byste dnes rozhodovali, jestli jít nebo nejít na VŠ informatického typu, rozhodněte si:

1. chci dělat „doplň velmi konkrétní činnost“. Nejraději ze všeho o tom čtu. V tém svém X vidím velkou budoucnost a navíc mám pocit, že mám na X talent!
2. zajímají mě počítače jako celek. Vím, že mě baví X, Y, Z víc než A, B, C, ale rád se dozvím víc o celé abecedě.

Pokud jste si odpověděli a), studoval bych praxí. Začal bych co nejdřív pracovat (ať už na OSVČ nebo jakkoliv jinak) a snažil bych se dát si takovou metu, abych do 5 let skutečně v X podával výkony, jaké jsou na světové úrovni a díky kterému bude má práce globálně známá.

Pokud jste si odpověděli b), jděte na VŠ. Žádná jiná instituce vás kompletním pochopením počítače, matematiky, fyziky a dalších věcí okolo neprotáhne tolik, jako vysoká. Za 5 let, až budete ze školy odcházet, byste už měli vědět, jaké je vaše X, v kterém tušíte, že máte talent, který vás baví a kde cítíte, že bude velká budoucnost.

Ještě je tu jedna alternativa, kterou považuju za skvělou. V případě, že chcete získat rozhled, počítáte, že půjdete do praxe (zvažujete dokonce OSVČ nebo vlastní firmu), vystudujte k praxi ještě ekonomii.

Ekonomie a informatika do sebe až podezřele zapadá. Já poslední roky dělám mnohem víc informatiku než ekonomii. Přesto na VUT FIT byly přesně 3 předměty, které by se mi hodily do praxe (softwarové inženýrství, databáze a informační systémy, naprosto stupidní a začátečnickou tvorbu www zkusíme ignorovat). Na ekonomce se naučíte věci, které použijete v praxi mnohem víc. Ať už pochopení zákonů, daní, tak znalost řízení lidí (každopádně znalost ještě není schopnost), marketingu, procesů v EU a v neposlední řadě i mikroekonomii – tedy ekonomii, kterou potkáváme denně v praxi ve všech obchodech, službách a podobně. V praxi využijete potom třeba 10–15 předmětů. A zároveň máte možnost získat ty bonusy: rozhled, skvělé přátele na celý život.

Ekonomka má ještě jednu výhodu. Už nejmíň stokrát jsem slyšel programátory říkat, že se na to vys***u a půjdou pást ovce. Člověk, který vystuduje informatiku a pak dělá informatiku, když bude chtít opustit informatiku, se vrátí efektivně na úroveň, kdy měl jen maturitu. Absolvent ekonomie může dělat v mnoha oblastech, protože porozumění trhu a ekonomii se dá aplikovat snad v každé firmě.

Shnem si to: chcete být javascriptový ninja? Jděte do praxe! Chcete umět všechno a získat matematicko/fy­zikální background? Jděte na VŠ! Chcete do praxe, ale získat i výhody vysokoškolského studia? Zvažte kombinované studium informatiky nebo ekonomie.

Co má AutoFocus a SuperFocus společného?

• princip často a krátce – tedy nenutit se do práce na jednom úkolu dlouhodobě, v systému by člověk měl pořád něco dělat, ale jen to, co ho baví a když ho to bavit přestane, má jít na jiný úkol. Já osobně musím říct, že tento bod se mi nepovedl zavést. Když už začnu dělat nějaký úkol, snažím se ho dotáhnout do konce.
• princip podvědomí nad vědomím – výběr úkolů je nechán na podvědomí. Vybírá se úkol, který „vyčnívá“. Výsledkem by mělo být odbourání vnitřních bloků k práci.
• řízená prokrastinace – pokud se chci flákat, napíšu si úkol „brouzdat po soc.sítích“ a až se k němu dostanu, tak ho udělám a pak si vezmu další práci. Vybírám si úkoly, který mě budou bavit – tím pádem je prokrastinace omezena – člověk nemá takovou potřebu dělat něco jiného, pokud dělá úkol, který ho baví.

Čím se liší?

• máme 2 sloupce – vlevo jsou úkoly běžné, vpravo jsou úkoly urgentní
• pokud pracuju na úkolu a nedokončím ho úplně, sepíšu ho dolů. Nedělá se čára. Jakmile dojdu na další stránku, napíšu úkol na další stranu
• pokud pracuju na urgentním úkolu a nedokončím ho, škrtnu ho a napíšu na další stránku. Pokud je další stránka prázdná (ještě jsem se tam nedostal s běžnými úkoly), napíšu úkol na 1. stránku, kde je v pravém sloupci místo
• vybírám si úkoly na jedné stránce z levého i pravého sloupce
• na další stránku smím pouze tehdy, pokud jsem pracoval na všech urgentních úkolech na dané stránce
• při vložení 1. úkolu ve dni napíšu ke sloupci datum, ať vím, kdy se úkol v systému objevil

Statistika systému

Z toho mi vychází následující statistika:

Průměrný počet vložených (počítá se i znovuvložený) denně: 15
Průměrný počet zpracovaných (pracoval jsem na nich, ať už jsem je dokončil nebo ne) denně: 19.2
Dní k dokončení všech položek: 17.38

Kvůli SuperFocusu trochu zanedbávám GTD, proto nepočítám, že bych tento systém udržoval napořád. Dává mi ale dobrou informaci o tom, že si opravdu udržuji práci na cca 2 týdny dopředu (což souhlasí s tím, co doporučuju na Školení GTD). Kladu si experimentu hlavně otázku, kolik úkolů skutečně udělám a kolik jich přibývá. Zároveň mě zajímá, po kolika dnech bude zcela zpracovaný seznam z prvního naplnění, tedy jaký nejstarší úkol v systému budu mít. Tak trošku si říkám, jestli bych úkoly starší 17 dní neměl rovnou mazat.

A tady začíná náš příběh. Na začátku byly DVD vypalovačky pomalé (stejně jako zpočátku vypalovačky na CDčka). No a s časem se z DVD stal skvělý formát zálohování a výměny dat. DVD vypalovačka v každém domě. Dostatečný prostor hned na několik filmů. Vypalovací software se zjednodušil tolik, že ho zvládl ovládat snad každý.

A dnes, v roce 2012 mi DVD přijde jako mrtvá technologie. Ne kvůli nedostatku prostoru. Ale kvůli nebetyčné nepraktičnosti toho formátu. A taky kvůli internetu.

Když něco hledám a vím, že je to na DVD a na internetu, radši to znovu stáhnu. To platí především o software. Tu spoustu DVDček různých Linuxů někdy z 2005, 2008… bych mohl rovnou hodit do koše (rozuměj opravdu hodím).

Taky je DVD kravsky velké a citlivé na poškrábání. Kdo dnes u sebe nosí prázdné DVD? A mít je doma? Proč? Kolik jste za poslední 3 roky vypálili DVDček? Já přesně 2. Dnes roli výměnného média přebírají zařízení s Mass Storage. Kdejaký přívěšek na klíče, mobil, foťák, mp3 přehrávač dneska takhle funguje.

DVD je zmražené. Internet je flexibilní. Dneska pomocí S3 máme prakticky nevyčerpatelnou kapacitu. A můžeme ji sdílet, hledat v ní. Najít to správné DVD, to není vůbec praktické ani příjemné. Na data online se nepráší. Data online vám neohnou záda, když se budete stěhovat.

Začal jsem DVDčka přebírat a nahrávat je na disk, který jsem si k tomu účelu koupil. Slova „doživotní záruka“ mi vytanula v mysli přesně tolikrát, kolikrát ta DVDčka z roku 2005 nešla přečíst. Můj další notebook bude bez DVD mechaniky a data budu sypat na externí disk. Za víc než 2 roky byla pro mě mechanika jen zbytečná zátěž.

Bylo to před cestou do USA, kdy jsem se rozhodnul, že odmítám tahat se s cestovkou, nebo nedej bože s tím plastovým bazmekem na kolečkách, která se zpravidla urvou ve chvíli, kdy to člověk nejméně potřebuje. Když člověk uleví svým zádům, netahá za sebou půl domácnosti i s vanou a sousedkou, přestává být takový opruz i ta cesta. Do Ameriky jsem vyjel na 3 týdny s jedním baťohem. Popravdě, ikdybych tam jel na 5 týdnů, nevzal bych si nic navíc.

Nezbytnou podmínkou byl hotel s prádelnou, což naštěstí není v USA nic zvláštního.

Letos pojedu znovu a mám pro vás tipy, které sám plánuju aplikovat při cestování nalehko:

• na takové dovolené přečtu kolem 800 stran textu, pro tyto účely jsem si koupil Amazon Kindle – úspora 1 kg (a věřte, že jsem měl vloni sto chutí ty knihy po přečtení hodit do koše)
• velká část hygienických potřeb je jen zbytečná zátěž. Tuhý deodorant, zubní pastu apod. koupíte za pár dolarů na místě a před odjezdem je můžete zase vyhodit – úspora hlavně prostoru
• místo zrcadlovky si nejspíš někde půjčím kompakt. Umělecké fotky na dovolených moc nedělám a na tu běžnou dokumentární fotografii stačí malá krabička. – úspora tak 1 kg (se všemi objektivy, brašnou) a spousty prostoru
• oblečení stačí jen na 3 dny, pokud je v hotelu prádelna – úspora prostoru
• pokud plánujete výlet i do chladnějších míst, netahejte moc teplého oblečení. V secondhandu koupíte svetr za 3 dolary. Před odjezdem zpět do tepla ho můžet vyhodit.
• místo velkého notebooku povezu MacBook Air nebo iPad – úspora prostoru a 1 kg váhy

Výsledkem by mělo být to, že člověk srazí váhu celého zavazadla na nějaká 3 kila. A co si budeme povídat, s tím už se dá ujít pár desítek kilometrů.

Dozvíte se:

• co Scrum je, ale hlavně co Scrum není
• jaký je vztah Scrumu a agilního manifestu
• co je agilní manifest
• 5 tajemství úspěchu Scrumu
• 12 způsobů, jak implementaci Scrumu můžete pokazit

Omlouvám se, že občas odcházím z obrazu. Ve skutečnosti jsem v tu chvíli ani nevěděl, že se natáčí jen učitelský pultík.

Mám právo ve volbách rozhodovat o lidech, přestože ani nevím, že existují? Znám snad zájmy a potřeby všech?

Zná politik odpovědi na všechny potřeby? Pokud ano, je schopen jednat v souladu s fakty i přesto, že to poškodí jeho volební preference?

Dává státní hranice smysl? Není pro obyvatele Brna důležitější obyvatel bližší Vídně než Prahy? Jak se to stane, že někdo do země zarazí kolík a řekne: tady se o to nejlépe postará Parlament ČR a o 3 kilometry dál už bude úplně nejlepším správcem Parlament Rakouska?

Má smysl státní protekcionismus? Je správné cly zdražovat zboží a služby 95 procentům konzumentů pro zisk 5 procent lobbujících výrobců?

Má mít nějaká instituce právo vybírat na trhu subjekty a přidělovat jim peníze, které mezitím vzala jejich konkurenci?

Vyplatí se být v celoevropské instituci, která uživí 45 tisíc lobbistů prosazující zájmy několika procent zájmových skupin?

Je správné předpokládat, že občan je ovce, která o sobě nemá právo rozhodovat, ale jednou za 4 roky má zázračné procitnutí a je schopna si zvolit svého pasáčka?

Je spíš kapitalismus, nebo socialismus, když stát každoročně přerozdělí čtvrtinu HDP (ano, čtvrtinu všeho, co tu vyroste, smontuje se, vymyslí se atd.)? A je takový systém svoboda nebo totalita, pokud i obsah zbytku HDP je regulován tisíci předpisů, v kterých se nikdo nevyzná, které se neustále mění jak v ČR, tak v EU a kde je možné prakticky kohokoliv nepohodlného „za něco“ chytit?

Je správné, že má politik právo zadlužit příští generace pro současné vyšší preference?

Bylo víc válek mezi státy nebo válek občanských? Vyvolali víc válek představitelé moci nebo běžní lidé?

Existuje v ČR alespoň jeden člověk, který zná všechny právní předpisy natolik, že je schopný kdykoliv říct, zda jedná legálně nebo ilegálně?

Musí stát brát lidem peníze? Když byli schopni vlastním rozhodnutím a snahou peníze vydělat, nejsou snad zároveň schopni rozhodnout o tom, za co je utratí?

Opravdu musí bohatší platit vyšší daně? Vytváří přeci víc pracovních míst, kupují víc zboží a služeb, více investují. Nejsou daně nerovné jen proto, že stát už je tak velký a drahý, že by se jinam nezaplatil?

Pokud mluvíme o velikosti státu, bereme si do ruky tabulky, kalkulačky a statistiky a vypočítáváme, kdy se vyplatí jak velký stát. Zamysleme se ale nejdřív nad tím, zda je vůbec morálně správné vynucovat na lidech řád, který si nezvolili a který zasahuje mnohem dál, než za právo na ochranu lidského těla a majetku.

Súčto je systém, který vám umožňuje bleskově poskládat a poslat fakturu. Když jsem si měřil svou produktivitu na Fakturoidu a srovnával s SÚčtem, vycházelo mi SÚ levněji a lépe.

Jenže mezi verzi 1.0 a 2.0 došlo k několika změnám. Většinu z nich nevidím moc pozitivně:

• zmizela informace o tom, kolik mi má přijít peněz od všech zákazníků
• výpis seznamu faktur se najednou nevejde na 1280 monitor, aby nemusel systém zalamovat
• odstranili stránkování a součty částek v daném období – pro účely statistiky výborná věc, teď asi budu muset jít a všechny faktury si ještě dát do nějakého Excelu a postupně si je ta dopisovat
• není možné už ze seznamu faktur exportovat přímo PDFka (velmi praktické před odesláním účetní)
• kalendář mi ukazuje, které faktury BUDOU splatné a ty které BYLY a JSOU DNES už v přehledu nevidím. Takže hledat, co mi kdo má doplatit, budu muset dělat ručně. Ze seznamu. Z toho seznamu, který už není přehledný a úsporný.
• při vydávání nové faktury musím vytvořit nového partnera. Ikdyž vím, že to je nárazový obchod, který se pravděpodobně už nezopakuje.
• perliček v GUI je mnohem víc, už jsem je poslal e-mailem autorovi súčta

A teď je tu problém největší. Cena.

Nebudu dlouze rozebírat, že mi nastavili paušál 900 Kč měsíčně. Jen mě udivilo, že ho nastavili nejen mě, platícímu zákazníkovi, ale dokonce i těm, kdo mají súčto zdarma. Zajímalo by mě, kolik lidí si toho nevšimne a pak na fakturu budou smutně koukat a pak ještě smutněji zaplatí.

Co se opravdu nepovedlo, je celkové nastavení pricingu systému fakturace.

Totiž běžně se setkáte se třemi způsoby platby takovéhle služby:

• platíte za počet partnerů
• platíte za počet dokladů
• platíte za obojí

Platba za počet partnerů je ideální pro ty, kteří mají menší počet neustále se opakujících zákazníků. Může se stát, že takové zákazníky obsloužíte desetkrát měsíčně. Ale pořád je to jeden zákazník. Pro takové je ideální třeba Fakturoid.

Platba za počet dokladů je užitečná pro ty, kdo mají hodně zákazníků a fakturují je jen párkrát za rok (třeba 2–3krát). A mají hodně zákaznků, s kterými už nikdy další obchod neudělají. Pokud roste podnik, roste počet faktur a tak se musí zvýšit i paušál (připustíme-li, že se zákazníkem by určitou měrou měl růst i účetní systém). Pokud podnik zůstává konstantně velký, stejně roste počet partnerů. V prvním systému (fakurace podle partnerů) by byl člověk nucen neustále zvyšovat paušál a mít tedy dražší službu. V druhém způsobu zůstává cena konstantní. Pro tento druh podniku bylo ideální SÚčto 1.0.

Jak vidíte, jedná se o dva rozdílné segmenty, na které nejde cílit naráz.

A tak se dostáváme ke kombinaci. To je naprosto katastrofální varianta, kde náklady na službu vždy porostou (roste buď počet partnerů nebo faktur). Co se stane? Podíváte se do statistiky využití služby a uvidíte třeba: počet využitých uživatelů 10 %, počet využitých faktur 7 %, počet využitého prostoru pro přílohy 0 %, počet využitých partnerů 95 %. A tak uděláte upgrade a máte ještě menší využití uživatelů, faktur, prostoru, zkrátka služeb, které nepotřebujete. Přesně tohle je nové SÚčto 2.0.

Ještě počkám na odpověď súčta jak na GUI, tak na strukturu cen. Pokud se věc nedostane alespoň do stavu z verze 1.0., nejspíš zkusím buď Flexibee, kde za 199 Kč měsíčně budu mít úplné učetnictví nebo plnou verzi Fakturoidu bez limitů za 300 Kč.

Koncentrace

Asi nejdůležitější vlastností je schopnost koncentrovaně pracovat na jednom tématu a to tak dlouho, dokud není dokončené. Bez schopnosti koncentrace může být člověk sebechytřejší, jeho síla se roztříští.

Stojí za to poznamenat, že třeba Einstein byl tak zabrán do vědy, že jeho rodinný život tím velmi trpěl. Přišel o ženu. Později se oženil se svou sestřenicí Elsou, kde odzačátku vztah vedl ne k vášni, ale spíš ke klidné domácnosti.

Orientace na výsledky

Když se zeptáte velké spousty mladých lidí, řeknou vám, že co nevidět už budou bohatí, slavní a úspěšní. Potkáte je za dva roky a zeptáte se, jak se jim to daří. Jsou pořád na stejném místě. Potkáte je za dva roky… později ty lidi potkáte po spoustě let a oni jsou zklamaní. Celý život „věděli“, že budou úspěšní a nakonec uplynula spousta času a oni mají pocit, že výsledky nejsou vidět.

Tihle lidé se jednoznačně neorientují na své výsledky. Nejsou na sebe kritičtí. Nevidí, v čem je jejich 80/20 (kterých 20 procent jim přináší 80 procent úspěchu, z kterých 20 procent pramení 80 procent nespokojenosti). Dokud člověk nevidí, které části jeho chování přináší výsledky, může zrychlovat pouze jako celek. A to má vliv jen do určité doby – dokud nevyhoří.

Je potřeba poznat svou realitu. Je nutné vytěžit z ní to nejlepší, co se daří. Vůbec nevadí pracovat jen 3 hodiny denně, pokud víc času na těch 20 nejcennějších procentech strávit nejde.

Poznat svůj výkon a zvyknout si na vyšší

Lidé jako Donald Trump nebo Marc Zuckerberg jsou výjimky. Běžný člověk není připraven na to zmilionnásobit svůj majetek. Cesta k úspěchu vede k tomu, že vyděláváme X a musíme si zvyknout na X * 1.5. Pak na X * 1.5 * 1.5 a tak dále. Abychom mohli vydělat víc, musíme si umět uvědomit co má cenu více peněz.

Totéž platí i ve vědě nebo hudbě. Když začínáte skládat, nejdřív se vám nebude moc dařit. Pak budete průměrní. A když budete neustále růst, budete skvělí. Musíte znát měřítko, zaměrit se na výsledek a mít koncentraci výsledek zlepšovat.

Co GTD a práce přidělená šéfem? Jak se GTD hodí k zaměstnání?

Tohle je otázka, která padne vždycky. Ano, GTD je life-changer, změní vám život. Výrazně člověka posouvá a vede ho k tomu vzít život do svých rukou. Jenže jak se to pojí se zaměstnáním? Každý člověk, který začne dělat GTD zjistí, že některou svou roli pravděpodobně zanedbává. Není tak dobrý rodič, nebo partner, nebo kolega, nebo team leader, nebo programátor, nebo obchodník, jak by měl. Zkrátka některé role plní špatně. Getting Things Done člověka dovede k tomu, že pokud je workoholik, přestane jím být. Pokud mu práce překáží, posune se ke kratšímu úvazku. Pokud zároveň vidí, že svou práci nezvládá, vede ho k tomu doplnit si kvalifikaci. Ne všechny kroky, které udělá člověk začínající s GTD, se musí nadřízeným líbit. Z dlouhodobého pohledu jsou ale lepší šťastní a úspěšní zaměstnanci než vyhořelé trosky.

Jak se GTD srovná s rodinou?

Velmi dobře. GTD není systém, kde si naplánujete bloky času, ve kterých bude na děti čas 18:00–20:00 a pak zpět ke strojům. GTD je velkou měrou o tom dostat z hlavy problémy, závazky, ujasnit si priority. Když pak budete s rodinou, víte, jaké máte povinnosti a víte, že je zvládáte nebo co musíte obětovat. Je to racionální rozhodnutí a tím pádem čas strávený s nejbližšími pro vás nebude naplněný skrytými výčitkami „kolik jsem toho mohl stihnout“. V GTD vždy víte, jestli máte nebo nemáte na práci něco opravdu urgentního. GTD je vhodné i pro ty, kteří pracují z domu. Tam je nutné občas rodinu odmítnout. Jinak by přeci byli nejlepšími rodiči nezaměstnaní.

Jak pracovat pomocí GTD v týmu?

Getting Things Done má 2 postupy práce v týmu. Podrobně je vysvětluji na školení. První je vhodný do týmu 1 velmi zkušeného a několika méně zkušených podřízených a druhů do firmy, kde jsou všichni velmi vyspělí. Oba způsoby jdou kombinovat tam, kde pracují zkušení i méně zkušení kolegové. Tam, kde se setkají dva lidé používající GTD je otevřená cesta k tak produktivní spolupráci, jakou firma zatím nezažila.

Kolik času mi GTD bude brát?

GTD mi bere 10 minut denně a asi 30 minut každou sobotu. Zezačátku byly ty časy i dvojnásobné. Mohly být i větší, než jsem se naučil říkat Ne. Pevně věřím, že těch 90 minut týdně mi ušetří tak půl úvazku jinak naprosto zbytečné práce, kterou se rozhodnu nedělat (přestože můj příjem to vůbec nesníží) a místo ní se můžu věnovat rozvoji kreativity nebo sportu.

Jak se hodí GTD k dlouhodobým projektům

Dlouhodobé projekty jsou zlo. Někdy ale nevyhnutelné zlo. GTD nebrání nijak dlouhodobým cílům, přestože já sám je moc nedoporučuji. V Getting Things Done postupně dojdete k tomu, že si projekty rozdělíte do menších. Že vás bude motivovat vidět dílčí výsledky a menší cíle po cestě. Zjistil jsem, že to je opravdu posilující vidět, že 10 malých projektů už je někde venku a lidé na to koukají a posílají náměty a odpovědi.

Zajímá vás víc o GTD? Zeptejte se v komentářích nebo na Google Plus.

Na druhé straně je PHP neobyčejně produktivní jazyk. Je dynamický. Je to hlavní jazyk webu. PHP je jazyk, v kterém za 20 minut uděláte objednávkový formulář. PHP je jazyk, kde během 2 dní můžete vybudovat fungující business. Sedmnáctiletý kluk, který programuje 3 měsíce, napíše v PHP e-shop, který mu může vydělávat slušné peníze. Napíše ho rychle. Multimiliardový Groupon začal naskinovanou šablonou ve Wordpressu.

Zdrojáky, které si obvykle stáhneme, nebývají hezké. Jsou ale funkční a nejspíš už někomu vydělaly spoustu peněz.

Na jedné straně si ohromně vážím čistého kódu, správně použitých návrhových vzorů. Na straně druhé je pro mě ještě víc podstatné doručit na trh výsledek rychleji než konkurence. Právě v tom dává PHP obrovskou konkurenční výhodu. Nevěřím, že na webu je jazyk, v kterém by se dělaly weby rychleji. Akcelerace oproti PHP je možná jen dobře zvoleným frameworkem.

V čistém Ruby bez frameworku, v čistém C# bez .NETu nebo v čistém JS/node.js bez frameworku se vám bude web dělat neobyčejně špatně. V PHP budete produktivní i bez frameworku. To, kolik má PHP kvalitních open source frameworků (a pravda ne až tak kvalitních) CMS, e-shopů, diskuzních fór apod. mohou ostatní jazyky jen závidět.

Ikdyž je PHP škaredé a často mě naštve, je to kladivo, kterým jsem zamlátil všechny hřebíky hodně rychle. Jsem rád, že dělám právě s ním. Je to i komunitou lidí okolo PHP. Postrádá namyšlenost tak blízkou komunitám okolo jiných jazykům. Nepostrádá dotahování projektů do konce.

Napadlo mě, že bych mohl něco udělat jinak.

Zkusit víc dárků vyrobit místo kupování.
Zkusit udělat takovou večeři, kvůli které nezemře žádné zvíře.
Ozdobit stromeček sušeným ovocem, perníčky.
Vyrobit si z papíru vlastní betlém.
Jít na Štědrý den místo koukání na pohádky rozdávat jídlo potřebným.
Zavolat přátelům a známým, které jsem dlouho nepotkal a popřát jim hezké svátky.
Zasadit, koupit nějaké živé květiny, které doma zůstanou i poté, co vánoční stromek odejde.

Vánoce jsou zvláštní svátek. Na jedné straně se k sobě lidé chovají lépe, tak, jak by se k sobě měli chovat celý rok. Na straně druhé je z Vánoc svátek prodejců, e-shopů a bohužel i lichvářů. Čas, který jsme mohli strávit s blizkými věnujeme kupováním dárků.

Vám, milí čtenáři, přeju hezké Vánoce strávené s těmi, které máte rádi, bujarý konec roku a úspěšný start do Nového!

Je to tak pohodlné. Vlastně nemusíte být ani zkušený programátor, abyste pak mohli dělat weby. V Rails to po týdnu tréningu zvládne snad každý. Něco podobného se dá říci i o CakePHP, Symfony nebo mnoha jiných frameworcích.

Jenže já jsem přesvědčený, že tento postup je špatný a vede k několika patologickým jevům:

• controllery by měly být definované podle use-cases, ne podle toho, jaký model zrovna tahám nebo ukládám. Nebo to připadá divné jen mně, že ArticlesController akce viewArticle pracuje s Article jednou, pak tahá z Category, Comment?
• API by mělo být také definované pomocí use-cases. Kolikrát jde poskládat to, co chci, pomocí více dotazů na CRUD. Například 1 dotaz na seznam objednávek, vyfiltruju si v aplikaci nové objednávky a pak dělám dotazy na jednotlivé položky objednávky. Je skvělé, že takhle udělám cokoliv, ale přenáší se spousta zbytečných dat a dělá se mnoho requestů. Mít API orientované na use-case (tady "vyfiltruj i s produkty objednávky od data XYZ) vyžaduje znát use-cases, které uživatelé skutečně dělají.
• každá aplikace má mnoho různých workflow, ta workflow nemusí být navázatelná na slovesa v CRUD. Řetěz rozepsat článek (Create Article) – odevzdat článek (Deliver Article) – schválit článek editorem (Approve Article) – publikovat článek (Publish Article) se dá popsat jako Create Article – Update Article – Update Article – Update Article. V první variantě víte, co se děje. V druhém případě netušíte nic.

Vím, že CRUD ještě dlouho bude s námi. Stejně jako singleton, Flash, nebo špagetový kód. Ale pojďme začít mluvit o tom, jestli je CRUD technika, která uživateli a vývojářovi víc přidává nebo bere.

To nejlepší, co můžeme pro Havla udělat, pevně věřím, je praktikování těch skvělých věcí, které dělal.

Neohnout záda

Občan Havel neohýbal záda. Psal a šířil samizdat za totalitního režimu. Zavřeli ho. Z vězení psal články, které by ho do vězení znovu dostaly, kdyby tam už nebyl.

Máme-li sny, které považujeme za zásadní, bojujme za ty ideály. Co můžeme ztratit? On do toho šel s vědomím, že má pramalou sílu proti tisícům a tisícům byrokratů, stbáků, špiclů, policajtů a vojáků. Přesto, Obamovskou češtinou, on se stal tou změnou, kterou stát potřeboval.

Byl pravdivý

Václav Havel nebyl lhář. U něj jste dostali přesně to, co jste čekali. Ve světě neuvěřitelného politikaření, vyměňování hlasů (vy nám protlačíte X a my vám schválíme Y) to nebylo časté.

Buďte autentičtí. Řekněte lidem okolo, co si myslíte, kdo jste, jaké máte sny, o jaký svět usilujete. Nebuďte někým nebo něčím, protože se to čeká.

Byl idealista

Největší výhradou proti Havlovi bylo jeho idealistictví. Dnes se to nenosí. S pádem totalitního režimu se některá slova postavila na úroveň tabu. Tak například slovo ideologie je dnes synonymum vymývání mozku. Postupně i slovo idealismus. Idealista je dnes vnímán jako člověk-bambula nevhodný pro reálný život. Takže tu máme svět, kdy prosíme politiky, aby byli apolitičtí, aby hledali efektivní a ne politická rozhodnutí. A když se někdo názorově liší od průměrné masy, je mu vyčítáno, že je „řízen ideologií“ a ať se rychle zařadí do průměru „neideologického neidealistického“ davu. Dříve se nesmělo vybočovat od oficiální ideologie. Dnes nesmíte mít žádnou ideologii.

Ideologie Václava Havla mi neseděla. Jeho idealismus mi seděl velice. Měli bysme sami více koukat do budoucnosti, hledat cesty, kterými se chceme vydat. Chce to odvahu se svým idejím nezpronevěřit, když jde do tuhého, nebo když máte naopak možnost „lehce nemorálním chováním“ vydělat balík a získat místo na výsluní. Pokaždé, když člověk udělá kompromis sám se sebou, nedává ránu tolik ostatním, jako sám sobě.

Na konec připojím pár citátů, které řekl pan Havel a které vysvětlují to, co jsem se v článku pokusil předat.

• Naděje je stav ducha, který dává smysl našemu životu.
• Lhostejnost k druhým a lhostejnost k osudu celku je přesně tím, co otevírá dveře zlu.
• Domnívám se, že politik může říkat pravdu a žít v souladu se svým svědomím. Já se o to alespoň snažím.
• Falšovatelé historie svobodu národa nezachraňují, ale ohrožují.
• Porozumět si neznamená přizpůsobit se jedni druhým, ale pochopit navzájem svou identitu.

Já se pokusím vysvětlit, co vlastně marketing je. Čerpám z rozhovorů s lidmi z marketingu, knih a vysokoškolských přednášek.

Pokud mám marketing definovat: „Marketing je činnost orientovaná na zákazníka, komunikaci, jeho vztah k firmě, na orientaci produktů a služeb takovým způsobem, aby se maximalizovala vnímaná hodnota pro zákazníka.“

Občas se setkávám s výrokem: „Marketing je všechno.“ Je na něm hodně pravdy. V podstatě všechno, co se týká zákazíka a co může ovlivnit jeho spokojenost, je marketing.

Pokud reklama motivuje zákazníka koupit nebo nekoupit zboží/službu, je marketing. Úplně stejně je marketing, jestli zboží přijde brzo nebo pozdě. Jestli je hezky zabalené. Jestli si užije už rozbalování výrobku. Jestli má firma dobrou pověst. Jestli používání výrobku dává uživateli pocit výlučnosti. Nebo naopak pocit prověřenosti a kvality. Jestli má zákazník pocit, že koupil správně a své koupě nelituje.

Pak existuje termín, který hodně napovídá, co marketing je: „firma orientovaná na zákazníka“. Hodně se liší od jiných přístupů. Firmy jsou obvykle zaměřené na náklady (jistá úroveň kvality, minimální možná cena při dané kvalitě), nebo kvalitu (jistá daná cena, maximální možná kvalita při dané ceně). Firma orientovaná na zákazníka nemá fixní cenu ani kvalitu, obojí je proměnná. Produkt/služba se upravuje tak, aby maximalizovali vnímanou hodnotu pro poměr ceny, výkonu, balení, designu, reklamy a v podstatě všeho, co přijde do kontaktu se zákazníkem. Cena není nejnižší, ale je taková, že ji zákazník vnímá jako férovou. Kvalita není nejvyšší, ale zákazníka uspokojí. Balení nemusí být nejhezčí, ale je hezké a praktické. Design výrobku nemusí být od předního designera, ale musí být dobrý a použitelný.

Záměrně se vyhýbám slovu moderní (design, balení). Firma orientovaná na zákazníka totiž nejdřív definuje, kdo je její zákazník a jaká je hodnota, kterou hledá. Tu hodnotu zjišťuje různě (focus groups, marketingovými výzkumy, z účetnictví, benchmarking – tedy porovnávání s konkurencí nebo jinými svými výrobky/službami). Můžete mít zákazníka, který nechce moderní, ale prověřený design. Firma může přidat hodnotu tím, že výrobek bude vypadat retro. Třeba hnědý satelit na dřevěné roubence – jen malá změna, která může přinést hodnotu.

Jako zákazníci bychom měli chtít marketingem řízené dodavatele. Znamená to, že dodavateli řekneme, co nás pálí, jaký je náš problém a dodavatel se tím bude zabývat a zkusí vymyslet ne nejlevnější ani nejkvalitnější řešní, ale takové, které ze všech stran přidává hodnotu, kdy bude příjemné s firmou komunikovat, kdy se můžeme spolehnout, že výrobek/službu skutečně řeší náš problém a není jen hezký. Kdy máme jistotu, že reklamace se vyřeší rychle. Kdy máme jistotu, že nebudeme muset reklamovat každý druhý výrobek, který si koupíme. Kdy máme jistotu, že nám dodavatel naslouchá.

Jako dodavatelé bychom měli chtít být marketingově orientovanou firmou. Tedy orientovaní na zákazníky. Výsledkem je, že nabízíme po všech stranách ohromnou službu. Když zákazník zkusí odejít k jinému dodavateli, najednou mu začnou chybět spousty služeb okolo. Dobrý pocit, správný manuál, zaškolení, rychlost expedice, zvyklá úroveň kvality. Protože na všechny ty věci okolo dodavatelé nemyslí, sice to můžou nabídnout, ale zákazník si o to musí říct explicitně a ještě ho to bude stát víc.

Marketing je, když je zákazník spokojený.

I finanční analýza může být zajímavá a důležitá při rozvoji podnikání. Já jsem si vymyslel (byť určitě nejsem první člověk na světě) svůj ukazatel ROT. Return on Time.

Na straně čitatele najdete celkový zisk z klientů za rok, na straně druhé počet dní za rok u klienta. Pokud fakturujete menší objemy, musíte to sloučit do celých dní. Já už teď žádného zákazníka nenechávám koupit si „půl dne“. Prodávám sedmihodinové bloky práce a u ní si eviduju ROT.

Evidence ROT znamená, že sleduji, jestli částka za den není podprůměrná v celkovém srovnání.

Do hry navíc vstupují takzvané indexy. Indexy se dělí na bazické a řetězové. Dnes nás budou zajímat ty řetězové. V podstatě se dá říci, že řetězový index je funkce, ve které hodnota pro rok (nebo měsíc) je závislá na předchozím období a všechny hodnoty závisí na prvním roce.

Tedy řeknu, že chci hypoteticky (!!!) růst 30 procent ročně na 1 den u klienta. Následuje rozvoj, který do budoucna budu plánovat.

1. rok: 2 tisíce Kč
2. rok: 2600 Kč
3. rok: 3380 Kč
4. rok: 4394 Kč
5. rok: 5712 Kč

Tento ukazatel mi hodně otevřel oči. Ze všeho nejvíc vypovídá o jedné věci: dvakrát si rozmyslíte, než dáte slevu. Zejména pokud ta sleva míří pod cílovou částku. Velmi důležité na ROT je to, že počet dní, kdy můžeme pracovat, je omezený. Počet dní, kdy můžeme vydělat víc, omezen není. Respektive – co nám brání vydělat milion za den?

Tento ukazatel hraje velkou roli i pro podnikatele, který má více firem. Musí velmi dobře rozhodnout, kterému podniku věnuje větší pozornost podle toho, kde cítí velkou návratnost na malý vložený čas.

Já jsem rád, že jsem začal podnikat právě v takové době. Ve skutečnosti je období krizí příležitostí. Vyčistí se trh. Podniky si daleko více hlídají kvalitu. Víc než kdy se firmy snaží o to, aby vynaložily každou korunu dobře.

Firmy, které v té době ode mě objednaly školení, jsou pro mě inspirací. Pokud podnik i v takové době neomezí vzdělávání zaměstnanců, vnímám takovou firmu jako někoho, kdo se rozhodl vyjít z krize s vyšším podílem na trhu. O to víc mě těší, že většina těch firem jsou mí zákazníci dodnes. Všem se daří, byť kolikrát museli udělat velká rozhodnutí, změnit zákaznický segment nebo způsob práce.

Krize je příležitost pro silné a ohebné. Protože, když ocituju klasika: „Když klesne hladina, ukáže se, kdo plaval nahý.“. Období krize, věřím, se bude ještě mnohokrát opakovat, prezident Obama si jen za neskutečný balík peněz koupil oddychový čas a skutečnou příčinu krize – agentury Freddie Mac a Fannie Mae – dále fungují. Žádný další takový balík na další oddálení ale už USA nemá. Něco podobného se dá říci i o Evropské Unii, nikdo nemá dost peněz na sanování Itálie, Španělska, ona ani ekonomika Francie nebo Německa nezvládne všechno a jen čas ukáže, jestli Sarkozy s Merkelovou neplavou poslední dva roky nazí.

Mé předpovědi zní strašlivě. A nejspíš i padne mnoho tradičních podniků, které na světě máme klidně přes 80 let. Jenže skutečně je potřeba to vnímat jako možnost získat větší podíl na trhu. Trhy, které byly nějak rozdělené mezi přízeň zákazníků a kde se podíly měnily v řádech jednotek procent, se můžou posouvat o desítky procent v řádu měsíců. Podniky, které jen závisí na dotacích, budou muset uhnout těm, kteří se bez nich obejdou. Firmy, které jsou založené na intelektu, vzdělaných lidech, důvěře v zaměstnance, vysoké produktivitě a kvalitě, přežijí a vyjdou silnější.

Je to i na vás, s čím spojíte svůj život. Jestli věříte své firmě, jestli do ní vidíte a na vlastní kůži jste zažili, jestli firma v krizi jen redukovala náklady, nebo bojovala o větší prostor na trhu.

Výsledkem je, že člověk udělá ohromné množství práce, pracuje v tempu, jaké mu vyhovuje a dělá si přestávky, kdy se mu to hodí. Ve chvíli, kdy před člověkem trčí úkol a on se ho nedonutí dělat ani pomocí Autofocusu, tam lze prostě nastartovat minutku a říct si, dám tomu 1 pomodoro.

Teď k systému Autofocus samotnému. Trochu jsem ho zjednodušil, ale benefit systému přetrvává.

1. napíšete si určitý počet úkolů (autor doporučuje 25–35 řádek, já sám jsem zredukoval hodně svou práci jen na tu nejdůležitější, takže spíš mívám na den 7–15 úkolů)
2. pod úkoly uděláte čáru
3. vyberete si úkol ze seznamu nad čarou a pracujete na něm, dokud vás úkol baví
4. když úkol dokončíte, škrtnete ho
5. když jste úkol nestihli dokončit, sepíšete ho pod čáru
6. vyberete si další úkol nad čarou a opakujete kroky 4 a 5
7. když vás napadne další úkol, napíšete ho pod čáru
8. když se rozhodnete nějaký úkol nedělat, škrtnete ho (já k němu ještě píšu Xko)
9. když vám zbývají úkoly, které se nemůžete dokopat dělat, škrtnete je, ty, které chcete, přeformulujete a sepíšete pod čáru
10. uděláte novou čáru pod úkoly, tím vám vzniká nový seznam aktuálních úkolů a pod novou čáru zase sepisujete nedokončené úkoly a jedete pořád dál

Takový systém má výhody:

• uděláte zhruba dvojnásobný objem práce
• nepotřebujete žádný software, stačí kus papíru a tužka
• práce je zábavnější, každý úkol člověk dělá, dokud ho baví
• je to ohromně jednoduchý systém
• s prokrastinací se jednoduše vypořádám tak, že „kouknout na twitter/číst články“ sepíšu pod čáru a až si vyřídím současnou frontu, můžu si to jako úkol vzít. Obvykle už nemám chuť a tak místo toho opravdu déle pracuji
• Pomodoro umí být pěkně vyčerpávající (člověk se uvnitř pomodora nesmí jít ani napít, zajít si na záchod), Autofocus člověka tak nevysaje

Má ale i nevýhody:

• nedonutí vás do úkolů, které se vám vůbec nechcou dělat (na to je pomodoro)
• neumí se srovnat s urgentními úkoly
• jen tak mazat úkoly, protože je nechcete dělat, můžete když děláte na sebe, těžko ale, když budete někde zaměstnaní
• staví na jednu rovinu úkoly ohromně důležité s podružnostmi. Já sám to řeším tak, že si k důležitějším úkolům dělám vykřičníky a dávám na ně důraz při vybírání a nedopustím jejich smazání při přechodu na další sekci

Pokaždé, když nejsem spokojený s tím, kolik toho udělám, nasadím na nějakou dobu Autofocus. Obvykle udělám mnohem víc práce, než bych od sebe čekal, mám mnohem menší nutkání urvat se a jen tak číst články nebo něco takového.

Být minimalistou znamená odstraňovat odpad. Odstraňovat plýtvání.

Plýtvání je když:

• věnuju čas nečemu, co přináší méně hodnoty, než by mi přineslo něco lepšího (pokud chci být s rodinou 8 hodin a v práci 4 a jsem s rodinou 4 a v práci 8, musím poměry obrátit)
• kupuju věci, které mi přinesou hodnotu menší, než mi přináší současný majetek nebo mít dál hotovost
• zaplňuju prostor věcmi, když čistý prostor měl hodnotu a ta byla vyšší než nově zaplněné místo

Být minimalistou znamená optimalizovat to, co dělám, co vlastním a kolik prostoru mi to zabírá. V tuto chvíli je pro mě cestou k minimalismu toto:

1. napíšu si činnosti, které chci opravdu hodně dělat (tak třeba školit, cestovat, být kreativní, číst, vařit, tancovat a poznávat lidi a kultury)
2. napíšu si nejmenší možný objem činností, který mi věci přinášející hodnotu umožní
3. napíšu si seznam věcí, které potřebuji
4. všechno ostatní (majetek, činnosti) eliminuju a věnuju se 1. co nejvíc a 2. co nejméně

Samozřejmě minimalismus je jen pól. Potřeby se mění. Občas člověk musí nechat některé věci přebujet, aby byl schopný vybrat to nejlepší. Třeba při hledání toho, jakým způsobem mě bude bavit být kreativní, jsem si nakoupil spoustu malovátek, voskovek, štětců, dokonce triangl. Teď už vím, že mi stačí tvrdý papír, popisovač a fotoaparát. Zbytek můžu rozdat. Když se budu chtít naučit jazyky, asi taky nejdřív zkusím plno postupů, knih a pak budu teprve redukovat a nechám si jen to, co opravdu hodně ocením a co mi pomáhá.

Pokaždé, když mi nějaký majetek pomáhá k činnosti, kterou chci nebo musím dělat, nemá smysl ji vyhazovat.

Všechno tohle zní strašně jasně. Přitom lidé se tím neřídí! Mají domy plné bordelu, dělají věci, které je nebaví a myslí si, že když si toho koupí ještě víc, udělá je to šťastnějšími.

Minimalismus má zajímavé přesahy do štíhlého řízení, toho, jak budete jednat se suvenýry z dovolené a dost neobvyklým způsobem ovlivňuje i vztahy k lidem okolo vás. O tom zase někdy příště.

Doba se změnila. Teď už mám snad všechny hračky, které můžou zvyšovat člověku produktivitu.

Rychlost, jakou jsem schopen dělat většiny úkonů, se zvedla třeba pětinásobně. Nebo i desetinásobně. Jenže stejným tempem se nezvýšila produktivita.

Dřív jsem něco udělal, uložil a čekal. Během čekání jsem se vztekal a říkal jsem si, jak moc bych udělal, kdyby to bylo hned. Dnes mám nástroje, kde to je hned. A zjistil jsem jednu věc. Prostě není možné pracovat nonstop bez zastavení po neomezenou dobu.

Vždycky se zastavím protože:

• nastane okamžik, kdy si další krok musím promyslet
• vyrušení, hlad, potřeba se protáhnout
• mám příliš mnoho otevřených oken a musím je pozavírat
• propadnu prokrastinaci
• jsem vyčerpaný

Ve chvíli, kdy člověk necítí urgenci „musí to být dřív, než to je“, snadno se unaví nebo prostě věnuje čas něčemu, co vůbec nepomáhá splnění úkolu. A po chvíli se těžko člověku vrací do pracovní „nálady“.

Možná je v tom to, že si člověk odpočinul při tom nekonečném čekání, než SVNko vykoná všechny hooky, než Apache přechroupe stránku, než ji Opera zobrazí, než se pustí Netbeans, než přepne projekt, než refreshne knihovny po update.

Dnes commit do Mercurialu je hned. Apache je rychlý (na mnohonásobně rychlejším počítači aby ne), Safari je rychlé. MacVim se spustí ihned. Refresh projektu je do vteřiny. Mozek nemá kdy odpočívat.

Dostal jsem se do situace, kdy moje produktivita je jako Ferrari, ale mé řidičské zkušenosti mi dovolují jezdit maximálně na úrovni Volva. Na rovinkách to rozjedu, ale v serpentinách jedu buď pomalu, nebo se vybourám. V tuto chvíli už produktivitu můžu zvyšovat vyšší schopností sebeřízení a disciplínou, ne více hračkami a fintami.

Někdy se podíváte do zdrojového kódu a je taky plný výplní, obskurních konstrukcích, větvení, která nikam nevedou, míchání databáze a view dohromady.

Obojí je o tomtéž problému.

Kuchař (programátor) neví, jak to má být správně

Nutelová pizza, kreativní výtvor českých taky-pizzerií budiž ukázkou. Nebo pizza s vysočinou a eidamem. Proč špatné? Pizza je italské jídlo. Musí být tedy uděláno z ingrediencí, které jsou v Itálii dostpné, jinak to není pizza, ale zeleninová placka se salámem. Správná pizza je taková, u které Ital nepozná, že ji nedělal Ital a že nebyly použity italské ingredience.

Představte si, že jste Číňan a chcete si otevřít „Českou restauraci Švejk“ a nikdy jste nebyli v Česku. Chcete uvařit knedlo-vepřo-zelo. Vezměte pekingské zelí (to je totiž u vás „zelí“, tak jako u nás je eidam „sýr“), knedličky dim-sum, jen je uděláte o trošku větší, aby vypadaly jako houskové. K tomu upečete maso. Měl jsem to štěstí ochutnat vepřové v autentické čínské restauraci v čínské čtvrt v LA. Bylo sladké (výrazně, nejspíš marinované v cukru)! Výsledek si umíte domyslet.

Nebo taková omeleta je stálice na poli nepochopených pokrmů (obdobně jako Javascript na poli programovacích jazyků). Takže omeleta má být nadýchaná, hebká, rozhodně nestačí jen rozmíchat vajíčko, hodit ho na pánev a jít vyvenčit psa.

Jen se podívejte:

Je to stejné, jako mít půl tříd v projektu statických (nebo singletony). Je to stejně špatné, jako používat návrhové vzory tam, kde nedávají smysl. Je to stejné, jako tvrdit, že není potřeba zabezpečovat aplikaci, že stačí jen skrýt prvky těm, kteří na akci nemají právo. Kolikrát je za tím jen neznalost. „My ve firmě píšeme objektově“ – mýtus toho, že když člověk umí syntax třídy, umí psát objektově.

Jak z toho ven? Mít kuchařské učňáky, kam se chodí z lásky a ne proto, že kluk je blbec a na lepší se nedostal. Vzdělávat konzumenty, kuchaře i číšníky.

Když chcete vařit italskou kuchyni, pošlete kuchaře vařit pár měsíců do Itálie (bez toho to prostě nejde a myslete si co chcete – já se v Itálii vařit učil a vrátil jsem se jako úplně jiný kuchař a pochopil jsem hodně souvislostí, které by mi v ČR nikdo neřekl). Chcete si otevřít sushibar? V Japonsku jsou na to školy. První rok se učíte vařit rýži. Druhý rok už děláte sushi. 2 roky denního studia. Zrychlený kurz trvá 2 měsíce. Jak dlouho se to asi učili ti kuchaři, kteří ještě týden předtím vařili svíčkovou se sedmi?

Jak z toho ven u vývojářů? Učit se, číst, vzdělávat se. Ale ne od špatných to špatné. Než koukat deset hodin do zdrojových kódů Wordpressu, je lepší koukat půl hodiny do zdrojáků Nette nebo Zend Frameworku. Jít do firmy, kde se věci dělají dobře, kde se píšou testy, kde se testuje použitelnost, kde je management trochu vědecký (a má manažerské vzdělání) – třeba i jen na nějaký internship, stát se učněm.

Musí toho být hodně a musí to být levné

V kuchyni dají třetinu na suroviny, třetinu na provoz a třetina ceny by měla jít do zisku. Když si dáte jídlo za 70 korun, spočítejte si, že na vaši porci vyjde 23 korun – co se za to dá koupit? Jděte do obchodu, nakupte poctivé ingredience a spočítejte si, na kolik vás vyšly. Mám zkušenost, že suroviny na poctivé jídlo mě vyjdou tak na 50 korun na porci (pokud je jídlo vegetariánské). V restauraci, pokud chci stejnou kvalitu, musím zaplatit aspoň 150 korun. Ano, jsou vyjímky, předražené podniky, které do surovin peníze nedávají, nebo levné a kvalitní podniky (těch je ale velmi velmi málo).

Při vývoji je to podobné. Zákazník vždy dostane jen to, co si zaplatí. Žádný čistý a otestovaný kód nepadá z nebe. Dobře, padá, jmenuje se to framework, ale těch můžete taky naráz použít jen omezené množství a zdaleka ne všechny FW mají čistý kód.

Vývoj software je drahý. To je fakt. Vývoj kvalitního software, rychle a ve velkém objemu, to je ještě daleko dražší. Když bude zákazník platit málo, dostane to v lepším případě kvalitní, ale pomalu (vývoj udělají junioři a senioři budou jen kontrolovat práci). Daleko pravděpodobnější ale je, že utrpí kvalita.

Mám trošku pocit, že tady by mělo být možné vychovat si zákazníka.

Nejdražší je ve spoustě firem lidská síla. Software umí automatizovat lidskou práci. Příklad: Systém umí rozeslat 10 000 mailů denně. Jeden člověk jich pošle denně 100. To znamená, že systém zvýší stonásobně produktivitu. Investice do systému za 100 tisíc se vrátí už za 2–3 dny.

Obdobně si od ceny jídla musíte odečíst čas, kdy nakupujete, krájíte, vaříte, servírujete, uklízíte. Nemluvě o tom, že umíme uvařit omezený počet jídel, kdežto specializovaný a kvalitní kuchař jich umí mnohem víc a to navíc se znalostí souvislostí. Nemluvě o tom, že restaurace je všude. Prostředí se mění. Můžete si vybrat, nevaříte jen z toho, co je doma. Zkrátka je to služba a zaplatit ji má smysl.

Neexistuje profesní hrdost

Vývojáři neumí svým šéfům říct ne. Říct ne tomu, když je nadřízený explicitně poprosí, ať to „nějak oprasí“, když to hlavně už bude hotové. Co myslíte, že by řekl hrdý a dobrý lékař („operuj rychleji, vždyť se bypass dělá každou chvíli“), učitel („naučte je sčítat a násobit, dělení a odečítání už si dostudují“), hasič („stačí uhasit jen půlku střechy“), pokrývač („no to ale nevadí, že tam ještě pár tašek není, rychle pojď dělat druhou střechu“)?

Schopní a chytří programátoři často jen skloní hlavu a poslechnou. Stejně jak ti kuchaři. Ve škole se sice v lepším případě učili, že mají psát testy, že stejk vypadá jako jídlo pro chlapa a ne jako tenký pláteček masa dobrý tak na řízek. V reálu se podle toho nezařídí.

Shrnu to tedy. Co je cestou ven?

• musíte se naučit, jak má skutečně dané jídlo vypadat, vonět a chutnat (vydáte se do země původu a několikrát si ho dáte, ideálně se ho přímo tam budete učit i vařit). Naučíte se programovat s nejlepších knih (jako je Čistý kód) a tak, že budete pracovat s kvalitními vývojáři, kteří vás povedou.
• nastavte kvalitativní mez, pod kterou prostě nepůjdete. Kdyby měla půlka zákazníků odejít, ta druhá se ještě mnohokrát vrátí a přivede známé. Můžete nakrmit 100 zákazníků blafem a oni se už nevrátí. Nebo desekrát za sebou 50. Matematika je jasná. Pokud to šéf nepochopí, jste pro něj vy příliš dobří.
• pracujte tak, abyste se za svou práci dovedli postavit. Opravujte příčiny chyb (nekvalitní suroviny), neskrývejte následky (zkažené maso zakryjeme víc kari, pak si vypneme NOTICEs).

Protože u aktuálního projektu, na kterém pracuji, musí mít každý objekt test, chtěl jsem se nějak vyrovnat i s tímto. A tak jsem vymyslel způsob, jak se snadno s problémem vyrovnat.

Vezměme si třídu, kterou chceme testovat:

class UserAdministrator extends Model
{
        function fetchUser($userId)
        {
                return iterator_to_array($this->database->table("users")->where("id", $userId)->fetch());
        }
}

Napsat test není až takový problém. Vytvořil jsem třídu Mockista\MockChain, která vrací pořád sama sebe, dokud není zavolaná určená metoda (zde fetch()). Pak MockChain deleguje další práci na předaný mock. Jak to vypadá v praxi?

use Mockista\MockChain;

class UserAdministratorTest extends KDev_Test
{
        private $databaseMockChain;

        function prepare()
        {
                $this->databaseMockChain = new MockChain;
        }

        function mockFetchUserFetches()
        {
                $mock = Mockista\mock();
                $mock->fetch()->once->andReturn(new ArrayObject(array('a'=>1)));
                return $mock;
        }

        function testFetchUser()
        {
                $object = new UserAdministrator(
                        $this->databaseMockChain->addLastCalledMethod("fetch", $this->mockFetchUserFetches)
                );
                $ret = $object->fetchUser(1);
                $this->assertEquals(array("a"=>1), $ret);
        }
}

Samozřejmě test je zatížen tím, že znám vnitřní implementaci třídy. Ale jediná možnost, jak se tomuto vyhnout, by bylo skutečně vložit data do databáze a dotazovat se skutečně db místo použití mocku.

Kdybych chtěl naprogramovat takový test pomocí doubles v phpUnitu, měl by výkonný kód místo 7 řádek kódu těch řádek 25. Navíc by vnitřní implementaci odhaloval ještě daleko víc. Ani se mi na časy před Mockistou nechce vzpomínat.

Díky tomu, že už učím Mockistu i na svých školeních testování, mám od studentů spoustu podnětů k vylepšení.

Proč právě týdenní a ne větší horizont?

• zmenšil jsem si projekty, takže skutečně dokončím několik cílů
• je to dost na experiment, ale není to příliš moc, abych v něm selhal
• jak jsem již naznačil, ohromně mě motivuje, kde všude můžu už za týden být
• věci se v životě vynořují takovým tempem, že mít podrobně rozepsané plány na půl roku prostě nejde
• protože chci zvalidovat své hypotézy rychle
• a když jsou mé myšlenky pravdivé, chci brzo získat benefit z daného cíle

Není pravdou, že bych nedělal plánování i na větších časových horizontech, ale na vyšších úrovních jsou mé cíle dost abstraktnější. Rozhodně tam nenajdete „mít jachtu a vilu s 20 ložnicemi a bazénem jak Mrtvé moře“. O vyšších časových horizontech tu ostatně ještě napíšu (a hodně podrobně je rozebírám na školení GTD).

Za týden jsem spustil žítIT, za týden bych byl schopen spustit velmi osekanou verzi TopMonks, za týden se dá spustit slevový server. Za týden se zkrátka dá začít business, který už teď ukážete na trhu a budete ho upravovat, dokud nezačne generovat zajímavý zisk.

Kde budete za týden odteď vy?

Typicky když chcete objednat něco z e-shopu. Balíček je o 120 korun dražší. Kolik minut cesty nejdále musí být výdejna e-shopu, abyste pro balíček jeli?

Jak si cenu vašeho času spočítat?

Zaměstnanci to mají nejjednodušší. Vezmu svoji čistou hodinovou sazbu. Stejně tak brigádníci. OSVČ obvykle také mají způsob, jak si spočítat, jaká je jejich cena času. Tam ale pozor, protože je nutné započítat všechen čas, kdy se i jedná se zákazníky, fakturuje, připravuje daňové přiznání, jedná o reklamě et cetera. Pak jsou tu podnikatelé se zaměstnanci, u nich je to nejtěžší. U nich bych osobně volil delegovat vždycky a všechno na nejlevnějšího možného zaměstnance.

No a trochu vyjímkou jsou lidé na mateřské, důchodci a nezaměstnaní. Ti si sice mohou spočítat cenu své hodiny, ale nemají možnost s částkou hýbat tím, že přidají čas. Takže tam se prostor pro delegaci dost snižuje – přesně o tolik, aby jim zbylo dost na normální život.

No a co teď s cenou vlastního času?

Podíváte se na všechno, co chcete tento týden zařídit. Vyberete vše, co vás nebaví a může udělat někdo jiný. A zadáte tu práci levněji, než kolik vyděláte. O stejnou částku pracujete déle.

Je pravdou, že v Česku ještě není tak úplně rozvinutý ekosystém pro to. Třeba to změní TopMonks (v době psaní tohoto článku web neběží). Tam v podstatě jen zadáváte úkoly a lidé si úkoly berou a dělají. Můžou to být v podstatě libovolné úlohy.

Co se dá delegovat i v malém bez najímání lidí nastálo?

Tak třeba:

• nákupy
• překlady textů
• korektury
• programování, grafika, kódování
• plnění informací do CRM
• jednání se zákazníkem (pokud máte vhodný business)
• cesta do knihovny, výdejen e-shopů
• pošta
• vytahování informací z různých zdrojů
• fakturace
• úklid
• hledání dalších brigádníků
• dovézt auto do opravy

Je jasné, že část úkolů můžou dělat jen lidé, které znáte a věříte jim. Nicméně je možné se zbavit spousty úkolů, které člověku brání v tom, aby se mohl zaměřit na to, v čem je nejlepší.

A věřím, že existuje v Česku (nebo kdekoliv jinde) potenciál pro vybudování ekosystému. Člověk, který bude odchytávat jen nákupy, zajede denně do makra a rozveze zboží svým autem, si může vydělat dost na život.

Delegujete svou práci na jiné? Plánujete to udělat v blízké budoucnosti? Kolik měsíčně byste do toho chtěli dát?

• obrovské třídy
• obrovské metody
• nelogicky pojmenované parametry, proměnné, třídy
• hromady memory leaků (tam, kde to dává smysl)
• naopak málo testů
• nejednotná štábní kultura
• spousty zbytečných komentářů
• uživatelské rozhraní, které dělali programátoři, ne grafici nebo odborníci na UX

No a to není zdaleka všechno. Co mají takové projekty společného? Jsou úspěšné. Dlouhodobě používané po celém světě. Vycházejí nové verze a programátoři jsou stále schopni přidávat nové vlastnosti.

Celé mě to přivádí k jedné úvaze. Já a mí přátelé, kdo vyvíjíme software, se obvykle shodneme, že bez testů to nejde. Bez refaktorování to nejde. Že se člověk neobejde bez toho, aby trávil docela dost času dostáváním kódu do takového stavu, kdy se za něj nebude stydět.

A jak je tedy možné, že když jiní doslova bastlí, tak dovedou i takový hnus udržovat?

Soudím, že každý zdrojový kód se dá nějak udržovat. Ale…

Protože jezdím hlavně do firem, ve které mají lidé pocit, že už něco musí udělat, že kód právě udržovatelný není, myslím, že dokážu odpovědět docela přesně.

• produktivita práce vývojářů ve firmě je mizerná, je těžké přidat nové vlastnosti
• vývojáři tráví 50–70 procent času opravami chyb místo toho, aby vyvíjeli nové vlastnosti
• je nesmírně obtížné zaškolit nového člověka, aby byl schopný v rozumném čase přidávat novou funkcionalitu
• časové odhady pro zákazníky se natahují, takže roste riziko, že si najde jiného dodavatele
• vývojáři ve firmě nejsou s prací spokojení. Mají pocit, že kvůli něčemu takovému se programátory nestali.
• management je zavalen neustálým hašením požárů místo toho, aby se staral o obchod.
• nastává syndrom: musíme přepsat kusy aplikace, už nejsou udržovatelné

Je fakt, že všech těch věcí dovedu podniky zbavit. A to právě tím, že lidi vedu k čistému kódu. Vyšší kvalita se zpětně odrazí v produktivitě a spokojenosti všech. Kód s testy se lidé bojí mnohem méně upravovat. Správný proces vývoje (jako je Scrum) vede k tomu, že roste produktivita (obvykle zvýším produktivitu o 100 procent) i kvalita (jen správným nastavením procesů a vhodně psanými testy se dá zachytit nebo předejít 70 procentům stávajících chyb) naráz. Hezké a úhledné zdrojáky se lidé nebojí měnit, naopak, je to radost.

Na otázku, jestli má smysl čistý kód, odpovídám ano, smysl má. Jde to i s hnusnými zdrojáky, ale budete pomalejší a svou práci budete nenávidět. Dobré dílo zajistí, že se projekt po čase nezhroutí sám do sebe.

Nejdřív si zopakujme, proč vydávat první verzi brzo:

• velmi rychle získáme odezvu na produkt, co si lidi přejí, co jim brání v použití
• je to doplnění user testingu: UT je skvělý, ale je to kvalitativní metrika. Pustit na web tisíce lidí je kvantitativní metrika.
• každý produkt je postaven na nějakých očekáváních (lidé jsou ochotní kupovat i věci, které právě nepotřebují, když je sleva velká: Groupon; sociální sítě jsou plné lidí, lidé chtěji i menší síť, kde může být maximálně 150 přátel: Path) – díky rychlému dostání se na trh, je možné zvalidovat představy

Aby ale nebylo vydání první verze jen tak, je potřeba vydat první verzi tak, aby skutečně k něčemu byla.

Ideálně tedy:

• naprogramujeme ty části, které zvalidují naši ideu (slevy u Grouponu byly nejdřív postavené na Wordpressu a rozesílali lidem e-maily ručně – měli tržní produkt jen tím, že udělali design + velmi jednoduchý modul, který poslal e-mail operátorům)
• pokud je první naprogramování složité, ukážeme lidem jen prototyp (autor Dropboxu natočil video)
• musíme vytvořit vstupní kanál pro návštěvníky (uživatelé zaregistrovaní na Comming Soon, skupina fanoušků na facebooku, followeři na twitteru, placená reklama)
• dáme na web všechny možné metriky (Google Analytics, ale třeba i Clicktale a další

Pak zbývá ještě jeden důležitý krok:

Jaké metriky nás zajímají především?

U webu, kde chceme prodávat průběžně (sociální síť), je pro nás důležité, aby se lidé vrátili. 1000 hits od 100 uživatelů (kteří si desetkrát zobrazili stránku) je cennější než od 1000 uživatelů. Návštěvnost se dá vyladit. Začnete brzo řešit, proč se lidé nevrací.

U slevového serveru nás zajímá, jestli mají lidé skutečně zájem o slevněné zboží. Zajímá nás, jak moc zvýší konverzní poměr procento slevy. 49 nebo 51 může hrát roli. Optimalizujete brzo. Hledáte správné produkty.

Víc teď přemýšlím, co u produktu, který teď buduju, vlastně zvaliduje jeho ideu a jak výsledek dostat na trh co nejrychleji.

Co je důležité pro produktivitu? Že je jiná, než lidi obvykle čekají.

Obvyklá představa: Produktivita = objem práce / čas

A ten, kdo udělá více práce v kratším čase, ten je produktivní. To ale není vůbec produktivita. To je dobré jen pro ty, kteří pracují pro někoho. Ten si ten obsah práce u zaměstnance optimalizuje. Pro vás samotné to ale fungovat nebude.

Pro přinesení hodnoty sobě samotnému platí rovnice:

Produktivita = získaná hodnota / čas
Získaná hodnota = objem práce * důležitost práce

A co z toho vyplývá?

Pokud chceme zvýšit svou produktivitu:
Můžeme zvýšit objem práce, který uděláme v daném čase na srovnatelně hodnotných úkolech.
Nebo můžeme zvýšit důležitost práce i při kratším čase.

Dneska chci ukázat, jak zvýšit důležitost práce. Předpokládám, že jste sami sobě pány.

Jak na to? Postup je následující:

1. Napište to

Když vám přijde úkol, napadne vás úkol, napadné vás další startup, nebo místo, kam chcete na dovolenou a podobně, všechno napište. Pište to a nedělejte rovnou (pokud to není maličkost na pár minut).

2. Zhodnoťte to

Jednou za čas si napsané věci zpracujte. Výborně na to funguje GTD, pokud ho nepoužíváte, nevadí. Princip je následující:
seřaďte úkoly podle hodnoty, kterou vám přinese (vždycky je možné říct, jestli vám větší radost udělá vynesený koš nebo to, že si zacvičíte nebo to, že si vyděláte o 500 korun víc), třeba v knize Snězte tu žábu, kterou by měl přečíst každý, se radí rozvrhnout úkoly do kategorií ABCDE podle důležitosti.

3. Pracujte na tom od nejdůležitějšího k méně důležitému

Průběžně si zařazujte další a další úkoly podle priority do seznamu práce. Tím se vám seznam úkolů stane nekonečným (opravdu, nikdy není možné „mít vše hotovo“). Lidský mozek a naše okolí se bude neustále snažit nám na seznam úkolů protlačit své priority. Od rodiny a nejbližších je to v pořádku, jinak ale musíte být nemilosrdní a dávat úkolům reálnou prioritu.

Na úkolech pracujte a vybírejte si ty zvrchu, je-li to možné (umožňuje-li to kontext, dostupný čas a energie).

4. Nastavte si horizont

Podle toho, jak rychle vám úkoly přibývají, tím kratší horizont musíte mít. Jak vám budou přibývat úkoly, které zapadají do různých kategorií, zjistíte, že jste schopni týdně udělat 20 úkolů z kategorie A (což budou třeba všechny) a 8 vrchních úkolů z B.

Co se doby úkolů týká, ono se to statisticky vyrovná. Od doby, co jsem v rámci zavádění Agile v osobním živote změnšil své projekty, platí to obzvlášť.

5. Nemilosrdně úkoly mazejte

Když vám bude dlouhodoběji toto fungovat a budete dělat jen nejhodnotnější úkoly (A, B) a ty ostatní (C, D, E) se budou nonstop posouvat. Smažte je. Nikdy se k nim nedostanete. Máte svou rychlost a své tempo přibývání nových úloh.

Už znáte svůj nejmíň hodnotný možný úkol, jaký uděláte? Odteď při hodnocení úkolů do systému vůbec nezanášejte úkoly, které budou mít důležitost C, D, E, pokud nejste tak rychlí. Některé úkoly prostě sice mají hodnotu, ale malou. Pryč s nimi.

Nebo si je třeba někam napište. Ale jsou to úkoly pro zábavu. Když budete takový úkol dělat, bude to jen proto, že právě musíte nebo proto, že se zrovna hodnotný úkol dělat nedokopete.

V tuto chvíli polovinu práce, kterou si zadávám, mažu. Je to odpad? Ano! Je to cesta ke zlepšení? Ano! A jak to bylo dřív? Dřív nejen, že jsem úkoly nemazal. Přebíral jsem úkoly ze všech stran. Měl jsem 60 projektů na velmi dlouho dopředu. Teď jich mám 20 na asi 3 týdny (ohromně jsem zkrátil své projekty). Vlekl jsem obrovský seznam úkolů, z kterých jsem tak 85 procent nikdy neudělal.

Úkoly zadávejte tempem, jakým je dovedete realizovat.

Ukázalo se, že nemá smysl plánovat na extrémně dlouho jinak, než jen nějakou vizí. Realita okolo se mění tak rychle, že prioritní úkoly se vynořují jako na běžícím pásu a tak za 3 týdny odteď budu mít zase jiné projekty, jakmile si své současné zrealizuju.

Člověk se učí a neustále má nové příležitosti. Proto je určitá hranice, za kterou už jednoduše úkoly nestihneme, pokud je neuděláme rychleji nebo pokud si někoho nenajmeme.

Jak do toho zapadá zaměstnání? Zaměstnání přináší určitou hodnotu. Když nás baví, super. Když ne, je to hrozná škoda, ale aspoň jsou z něj peníze. A peníze přináší hodnotu. A tu hodnotu si můžu dát do toho svého seznamu úkolů a někam ho umístit.

Osobně jsem zjistil, že víc než poloviční úvazek vám ale bude účinně bránit v dosahování osobních cílů. Poslední dva a část roku jsem pracoval na poloviční úvazek. Teď jsem práci zkrátil o dalších 10 hodin na 70 měsíčně. Pracuju teď už jen na tom, na čem dělat opravdu chci a v čem vidím dlouhodobější smys­l.

Prostě se mi osvědčilo rozbít velký blok práce na menší závazek a případně se nechat najmout i někde jinde nebo prodat firmě víc svého času, pokud chce.

Mezitím samozřejmě pracuju, ale na svých úkolech, na kreativitě, na školeních, na cestování, na sportování, na vztazích s nejbližšími.

Výsledkem je, že vytěžíte ty nejdůležitější příležitosti ve svém životě. Výsledkem je, že se naučíte hledat nové příležitosti s vysokou přidanou hodnotou. Výsledkem je, že místo startupů na půl roku fulltime s pravděpodobností úspěchu 1 procento budete dělat krátké projekty, které postupně přidávají do vašeho života víc a víc. Což způsobí, že velmi rychle zjistíte, jestli jste na dobré cestě nebo ne. I hodně riskantní projekt se dá rozbít na menší pro rychlou validaci ideje.

Výsledkem je, že zjistíte, v jak nestabilní době žijeme a jaký horizont plánování si můžete dovolit. Naučíte se říkat ne. Nepovlečete sebou tunu závazků, na které jste řekli „ano“, protože se to někam zařadit dá, takže se to i někdy udělá. Neudělá.

Výsledkem je uvědomění, že to, že jsme si přidali běhání do GTD, neznamená, že někdy běhat budem. Musí se stát prioritou a něco jiného bude muset z kola ven.

Výsledkem je, že ušetříte čas plánováním nepodstatných věcí. Výsledkem je, že nezklamete lidi okolo zavázáním se k něčemu, co neuděláme.

Výsledkem je spokojenější, úspěšnější a méně hektický život.

Obecně si myslím, že certifikát za účast na školení je k ničemu. Jen marketing. Dárek na památku. „Přijmete mě do zaměstnání, když místo potvrzení účasti na školení přinesu i papírový certifikát?“

Soudím, že certifikát by měl být pouze za zkoušku. Osvědčení znalostí. Stejně tak věřím, že při vzdělávání by mělo být co nejvíce zkoušek a ty by měly být pokud možno co nejtěžší.

Když se podíváte na Ebbinghausovu křivku zapomínání, zjistíte, že za 14 dní už si ze školení student moc nepamatuje, pokud si znalosti nezopakuje (ostatně proto jsem spustil Žít IT). Tak k čemu by mu měl být certifikát, když vlastně nepotvrzuje ani znalost nějakého tématu?

Certifikáty by měly cenu tehdy, když by zkouška samotná probíhala třeba dva týdny po školení. Tedy tehdy, když to donutilo člověka si téma párkrát zopakovat (a tím pádem mu zůstane v hlavě podstatně víc).

Zkouška samotná by měla být nastavena tak, aby jí prošlo tak 30 procent studentů.

Třeba vezměte si Certified Scrum Master. Dělá se ihned po školení (pamatujete si většinu informací) a navíc je nastavena tak, že projde 98 procent studentů (takže zkouška je pro forma, ve skutečnosti je to certifikát za účast).

CSM je cesta, jak prodat školení jednotlivcovi za cenu, za kterou já zaškolím celou firmu od lektora, který pravděpodobně má podobné zkušenosti jako já.

Toto neplatí zdaleka jen o CSM. Tímhle trpí velká většina školení s certifikátem. Buď není zkouška žádná (certifikát = dárek), nebo je moc lehká (certifikát = titul z Plzně) nebo je ihned po školení (mám certifikát, v hlavě mi toho za pár týdnů ale už moc nezůstalo).

Já si myslím, že certifikát by navíc neměl být doživotní (srovnej jazykové certifikáty FCE a TOEFL). Jak chcete zajistit, že člověk, který používá certifikát, tomu tématu pořád rozumí, nebo si udělal školení a 5 let už na téma nesáhl. Dnes, v době, kdy je certifikát skoro používán jako doplněk titulu za jménem, je nutné, aby měl nějaký význam.

Ve zkratce se neliší v ničem.

Obecně platí, že co je dobré ve štíhlých firmách, je dobré i ve Scrumu. Ostatně tam, kde nějaká metodika už nesahá, beru při školení příklady ze štíhlých firem (a stejně tak štíhlé firmy by si mohly vzít hodně od Scrumu nebo Agile obecně).

Rozdíly se hledají těžko. Jsou spíše v názvosloví. V případě Kaisenu i v tom, že je dost postaven na kolektivistickou společnost, kdežto agilní přístup vyrostl v individualistické euro-atlantické civilizaci.

Agile má krátké iterace (nebo nemá iterace vůbec).
Štíhlá výroba má jednokusový tok výroby.

Agile má na konci iterace retrospektivu a na začátku plánování podle zjišťení ze sprintu.
Štíhlá výroba má kolo Build – Measure – Learn.

Agile má autonomní týmy, které vyvíjejí proces.
Stejně tak Kaisen vychází z postupného zlepšování procesu na bázi nápadů ze všech pater hierarchie.

Agile má rádo spolupráci se zákazníkem, ten je na pracovišti. Jednou z technik používaných agilními týmy je uživatelské testování a prototypování.
Lean Startup validuje svou ideu s early adopters v extrémně ranné fázi.

Agile nepracuje ve velkých týmech.
Lean Startupy taky nepracují ve velkých týmech.

Mohl bych pokračovat, co je ale zjevné: revoluce lean startupů je zároveň revolucí agilních metodik, jen pod jiným názvem. Lean má určité přesahy (jak u průmyslových podniků tak i startupů) do business sféry. Agilní metodiky se hojně spojují s agilními technikami (jako je párové programování nebo TDD). Proto myslím, že je dobré číst literaturu z obou světů a vytěžit maximum.

Na sobě jsem vypozoroval jednu věc. Čím jsem starší a čím déle dělám GTD, tím lépe jsem schopný přemýšlet i o dlouhodobějších horizontech.

Když jsem začal s GTD, byl jsem šťastný za ty své seznamy úkolů a projektů. Po pár měsících jsem ale pořád nedělal GTD v jeho úplné podobě, ignoroval jsem perspektivu. Zkoušel jsem si rozmyslet, kde chci být za 1 rok. Za 2 roky. A čím déle do budoucnosti jsem koukal, tím víc jsem si uvědomoval, že sám sebe příliš neznám.

Trvalo to několik let zjišťování, cestování, poznávání lidí, experimentování, abych dokázal poznat své vyšší úrovně.

Když začnete s GTD, budete na úrovni rozjezdové dráhy až 10 tisíc stop.
Zhruba po měsíci si uvědomíte 20 tisíc stop.
Po asi 3–4 měsících začnete chápat úrovně 30 a 40 tisíc stop.
Asi po roce až roce a půl se vám skutečně povede dostat se pod kontrolu a perspektivu a vyloučit cizí úkoly. V tu chvíli ty úrovně 30–40 tisíc stop výrazně přehodnotíte a vyvinete se v člověka, který dělá „life-design“.
Na to, abych si napsal úroveň 50 tisíc stop, jsem si musel počkat skoro 3 roky.

Chce to trpělivost a nezahodit GTD pro něco jednoduššího. Všechno v něm má svůj smysl a třeba Zen to Done právě sráží GTDčko jen na tu úroveň kontroly projektů a kroků. Ten, kdo bude dělat GTD poctivě, dojde podle mě dál, než ten, kdo ho oseká o věci, které teď považuje za zbytečné. Je nutné být trpělivý a počkat pár měsíců, než na pravý význam přijdete.

Co je tedy nového?

Do projektu Mockista jsem přidal třídu KDev_Test, která dědí z PHPUnit_Fra­mework_TestCa­se. Umožňuje několik rozšíření:

• místo setUp se volá prepare (setUp je jen historický relikt ???Unit nástrojů, prepare je mnohem hezčí)
• přibyla metoda cleanup, která se volá před i po každé testové metodě
• to hlavní: zavolání $this->mockXYZ je odchyceno, zavolá se $this->mockXYZ(), očekává se vrácení Mockista objektu a třída si ho zaregistruje a po doběhnutí testu i zkontroluje.

Následuje příklad otestování registrace uživatele:

class UserRegisterTestion extends KDev_Test
{
        function mockAuth()
        {
                $mock = Mockista\mock();
                $mock->calculateHash('b')->once->andReturn('c');
                return $mock;
        }

        function mockDatabase()
        {
                $mock = Mockista\mock();
                $mock->table("users")->once->andReturn($this->mockTableUsers);
                return $mock;
        }

        function mockTableUsers()
        {
                $mock = Mockista\mock();
                $mock->insert(array("first_name"=>"a", "password"=>"c"))->once;
                return $mock;
        }

        function testRegister()
        {
                $inputArray = array(
                        'first_name'=>'a',
                        'password'=>'b',
                );
                $register = new User($this->mockDatabase, $this->mockAuth);
                $register->register($inputArray);
        }
}

Cesta je v nezávislosti.

Chci sportovat? Nebudu se vymlouvat na pracovní dobu a půjdu sportovat. Pokud je sport priorita, práce jde přeci stranou. Nevydělávám dost peněz? Do minuty dokážu vymyslet 20 způsobů, jak si zvednout příjem. Nebaví mě zaměstnaní? Můžu jít jinam. Nemám nějaké vzdělání? Podat přihlášku na školu trvá chvilku. Průkazku do knihovny vyřídím na počkání.

Pravda je taková, že lidé ohromně podceňují schopnost změnit své vlastní prostředí jako jednotlivci a předpokládají, že jsou vlečení okolnostmi.

Když se podívám do svého GTD na úkoly, které dělám, vidím jednu věc. Před třemi lety bylo tak 60 procent úkolů od jiných lidí – úkolů, které pro mě neměly v dlouhodobém horizontu žádný smysl. Poslední rok a půl je číslo jiné. 0, zero, nadá, nula! Nedělám nic, co mi jiní zadávají, pokud to nezapadne do mé dlouhodobější perspektivy. Trvalo to dlouho, osekat se o různé závazky a hlavně patologické zvyky dělat všechno, co po mě kdo chce.

Pracuju méně, vydělávám víc, jsem spokojenější a dělám věci, ke kterým se budu chtít za 5 let odteď přihlásit. Přestal jsem dělat kompromisy ve věcech, které jsou prioritou.

Nikdy jsem k tomu nepotřeboval žádného ochránce. Každý ochránce má své zájmy. On by si to dokázal vybrat. Předelegovat své potřeby i na mě.

GTD tím, že vyžaduje dokonalé plánování, mi dává skvělý obrázek práce, která mě čeká. Kolik času mi vezme. Pomůžu tím těm, kterým chci pomoci? Nebo si jen někdo jiný mým prostřednictvím chce realizovat cíle? Kam to směřuje dlouhodobě?

Za 5 let může člověk změnit svůj život takovým způsobem, že tomu okolí neuvěří. Vyžaduje to, aby vzal život do svých rukou a pomohl si sám. Za něj to nikdo neudělá. Jiný sleduje svůj zájem. Za 5 let může člověk, který vzal život do svých rukou, dosáhnout víc, než by jinak dosáhl za celý život.

Malé odbočení k politice. Je to tak – ani politik vám nepomůže. Člověk sám, pokud vezme život do svých rukou, si za 1 rok pomůže víc, než by mu pomohl libovolný politik za 10 let.

Lidé říkají, že za to, jak se mají, můžou politici. Vzpomínají, jak se měli dřív líp a teď je to už špatné.

Líp se měli, protože měli ideály a bojovali za svůj svět. Teď už jsou semletí. Neznají svůj zájem. Pracovat tvrději pro ně znamená trávit víc času prací pro někoho, protože oni sami jsou rozpuštění. Pracovat tvrději znamená víc usilovat o své cíle, svou agendu. Být sám sobě politikem, voličem i ministrem! Nespoléhat na drobné ze státního rozpočtu, budovat si svůj rozpočet. Sám sebe nebude nikdo korumpovat!

Je důležité nebýt vystrašený. Nebát se, že: „mé cíle nezapadají do cílů chlebodárce, tak já ještě rok počkám s tou dovolenou, s tím, že chci už dělat X a ne jen asistenta X“. Ne! Každá spolupráce musí být oboustrannou výhrou, nebo jen zbytečně marníte svůj život. Něco vám vadí? Změňte to! Vždy existuje cesta i za cenu velkých změn.

„Nejlepší cesta ven je skrz.“
Robert Frost

co chci – co mám = co si chci koupit

K úvaze mě inspiroval kamarád. Má seznam věcí, které si chce koupit. Byly tam nějaké levné věci, knížky, ale i kvalitní oblek, hodinky snad za 100 tisíc a nebo automobil v ceně malého domu.

Říkal jsem si, jaká je to zajímavá myšlenka. Přišel jsem domů a zkusil to. A problém je v tom, že jsem skoro na nic nepřišel. Hej! Aston Martin, dům u moře, pár obleků na míru, upgrade počítače a pár menších věcí. A byl jsem u konce.

Až na pár maličkostí (snadno splnitelných), jsou to jen rozmary, které jsem si navymýšlel, abych taky měl finanční cíle.

Zkusil jsem si tedy napsat, co vlastně chci vlastnit. Soupis kompletního majetku, který opravdu chci, těší mě a život bez něj by pro mě byl složitý (ano, včetně zubního kartáčku nebo skleničky na vodu).

Co jsem zjistil, mi potvrdilo můj předpoklad. Na seznam – Chci mít – se dostalo možná 5 procent mého majetku. A všechno to ostatní, byly věci, které jsem nakoupil zbytečně. Někde dostal. Koupil zbytečně velké balení.

Když jsem se vrátil ke kreativitě v životě, nakoupil jsem si spoustu věcí. Akvarely, pastelky, tužky, propisky, paletu, tempery, štětce, papíry (spoustu druhů a velikostí), jednu zrcadlovku, druhou, objektivy…

Dnes používám přesně 3 věci: moleskine, černý popisovač a zrcadlovku. Na všechno ostatní se práší. Zbytek jsem použil nulakrát (většina štětců), jednou (tempery, paleta), dvakrát (akvarely), třikrát (voskovky).

Přestože už nějakou dobu přecházím k minimalismu, mě udivuje, že jsem si nikdy nenapsal, co vlastně chci mít. Teď se mi bude věcí zbavovat daleko snáze. Buďto půjdou na seznam nebo je daruju, prodám, vyhodím.

Co myslíte, je toho víc, co si máte ještě koupit, nebo toho, čeho byste se měli zbavit?

Hlavní důvod, proč je tak těžké změnit sebe samotného je v tom, že to, kde jsme teď, by se dalo psychologicky přirovnat k „rovnovážnému stavu“ a ať už se vychýlíme kamkoliv, každý budeme směřovat do rovnovážného stavu. Vegetarián je v rovnovážném stavu a pokus jíst maso ho může stáhnout zpět k vegetariánství. Naopak ten, kdo maso jí, musí vynaložit velké úsilí, aby se stal vegetariánem. Pro nekuřáka je těžké začít kouřit. Pro kuřáka je těžké přestat. Komu pivo nechutná, tomu se těžko začne pít. Komu chutná možná až moc, se bude těžko přeučovat na zelený čaj.

Existují dvě cesty, jak se změnit.

1. naskočit na jiný rovnovážný stav
2. posunout svou rovnováhu

První postup je náročný v tom, že v jiném životě najednou musíte budovat nové předsudky. Rutiny, které máte, najednou padají a chvíli trvá, než si uděláte nové. Mě se už párkrát povedlo úspěšně přeskočit do jiné rovnovážné polohy. Před 10 lety jsem se během jednoho dne stal vegetariánem. Před čtyřmi lety jsem lusknutím přestal kouřit. Obojí nebylo vůbec snadné a ani jednoho nelituju ani na vteřinu. Ale když tohle zkusíte vy, pravděpodobně se to nepovede. Stejně jako by se to nejspíš nepovedlo mě v jiný den a trošku jiným způsobem. Byla náhoda, že nový přístup mi sednul.

Nevěřím, že fungují návody, jak zcela změnit svůj život ve vteřině. Na výše popsané úspěchy padla spousta neúspěchů. Neúspěchů, ke kterým obvykle došlo ve chvíli, kdy najednou v novém systému „nevíte“, jak se řeší ten či onen problém. A tak ho vyřešíte postaru a už jste znovu na cestě ke staré rovnováze.

Druhý postup je náročný v tom, že trvá dlouho, zezačátku není nic vidět a vyžaduje opakování. Do svého nástroje na sebeorganizaci si napíšete, že máte každý den jít běhat. To je to lehké. Vytrvat, to je složitější. A protože jde o postupný přesun, můžete se nutit třeba tím, že řeknete: tento týden doběhnu jen přes kopec a zpět půjdu pěšky. Příští si přidám. A přidáváte si. Když si po čase vybudujete vztah, nevadí, že občas zaměškáte, zvyk už tam je a to je hlavní.

K posouvání rovnováhy se mi ještě osvědčily ještě dva postupy.

1. experimentem ke změně
2. ptaní se: „Jak to má být správně?“

Experiment je vynikající způsob, jak se změnit. Bylo by to asi na samostatný článek. Princip je následující. Vždy na týden nebo měsíc si dám nějaké předsevzetí, které výrazně posouvá realitu. Přeskočím tedy z rovnovážného stavu do jiného, pro mě nezvyklého nerovnovážného stavu. Finta je v tom „na týden“, „na měsíc“. Naplánuju si selhání. Je to život bez zlozvyku (nebo s užitečným návykem) na zkoušku.

Tento týden jsem si řekl, že půjdu pětkrát běhat.

Mám za sebou měsíce dělání kliků. Sedů lehů. Týdny experimentů s polyfazickým spánkem. Měsíce, kdy „kreslím každý den jednoduchý obrázek“. Týden cvičení jógy.

Experiment je nutné dělat v co nejradikálnější poloze. Na hranici sil. Jíš jako prase? Zkus týden jíst striktně veganskou stravu. Vůbec se nehýbeš? Uděláš jen 10 kliků? Udělej jich denně 50, ikdybys je dělal po pěti.

Takhle radikální posun by v dlouhodobém pohledu musel nutně selhat. Když je ale selhání naplánováno na týden (tedy konec experimentu), dá se vydržet skoro cokoliv. A co je výsledkem? Ikdyž se člověk vrátí „ke starému životu“, už nikdy není stejný. Obvykle se rovnováha posune směrem k experimentu. Ikdyž pokud mám srovnat rovnovážný stav a vyhrocený experiment, tak je člověk pořád mnohem blíž staré rovnováze. Před časem jsem přecházel na slow-carb dietu. Je to dieta od Tima Ferrise a její zaměření je: bezcukrová, beztuková dieta s neomezeným množstvím jídla a porcí s nízkým glykemickým indexem. Následkem diety má být kromě hubnutí i snížení krevního cukru, prevence diabetu, některých druhů rakovin a srdečních chorob. Odjezd do USA, země fast foodů, mi mou dietu dost znesnadnil a když jsem se vrátil zpět, nedostal jsem se zpět do téže diety. Ale mé stravovací návyky už zůstaly jiné. Výrazně jiné! Pevně věřím, že stačilo pár týdnů experimentu a já získal návyk, který mi prodlouží život o celé roky (o vyšší kvalitě života ani nemluvě).

V průběhu experimentu, je důležité ptaní se: „Jak to má být správně?“ Vyhledáváte body, v kterých nevíte, jak byste řešili danou situaci jako vegetariáni, nekuřáci, sportovci apod. Předcházíte selhání tím, že aktivně vyhledáváte témata, kdy byste mohli řešit problém postaru a přemýšlíte (a googlíte, ptáte se přátel, kteří jsou už v nové rovnováze), jak se dané životní situace s problémem srovnávají.

V průběhu experimentu nedokážete zodpovědět všechny otázky. Co ale dokážete, že váš mozek postupně uvyká i nové rovnováze. Po 3 až 4 experimentech (například se syrovou zeleninou) zjistíte, že čas experimentu pro vás přestává být chvílí, kdy se musíte hlídat a jste na dobré cestě „přeskočit“ do nového vlaku.

Vybudovat zlozvyky nám trvalo celý život. Zbavit se jich může trvat opravdu hodně dlouho, bude to stát psychické úsilí, spoustu nepohodlí a než se člověk znovu dostane do stavu, kdy řekne: „tohle je můj nový život bez zlozvyku“, uplyne hodně vody. Smysl to má!

K čemu to je?

• naučil jsem se utřídit si myšlenky, díky deníku se mi i články píšou mnohem snáze. Zvykl jsem si psát denně. Zvykl jsem si na to, že hledat téma je jen o tom vydat se několika směry, experimentovat s textem a když se téma vynoří, napsat ho.
• uklidnil jsem se. Chvíle, kdy si něco píšu a je to jen pro mě, je okamžik asi největšího soustředění. Občas jsem chtěl napsat článek a byl jsem naštvaný nebo jinak rozrušený. Při psaní jsem se vždy během několika minut uklidnil, smazal první odstavec a byl z toho neutrální článek.
• získal jsem v životě perspektivu, když mi GTD week review a analýza 80/20 přestávaly stačit a potřeboval jsem „fine tuning“. Když je deník opravdu jen váš, začnete mu věřit. Tím, že sdílíte dobré i špatné často přijdete na nový východiska, kroky a možnosti.
• rozvinul jsem kreativitu. Protože deník není blog, nikde není komentátor nebo stovky čtenářů, může být formát libovolný. Můžu mít jedno slovo na řádce. Můžu si psát asociace.
• často se k deníku vracím, když něco hledám. Spousta analýz pro osobní management je mi k dispozici.
• výborně mě motivuje najít si každé ráno nějaký citát a vložit si ho jako první příspěvek. Pak se k citátu kdykoliv vrátit. Občas jsem použil i nějaký starší, který mi hodně zabral.

Cvičení

Ukážu vám jedno cvičení na rozvoj kreativity a umění psaní, které ve svém deníku občas dělám.

Nejdřív si napíšu na levou stranu „že X je jako…“ (kde X nahraďte věcí, vlastností, barvou, zvukem a nebo cokoliv vás napadne). Například:

Byl zelený jak…
Měl křivé nohy jak…
Nosil oblek tak starý…
V létě se potil tak moc…
Sestru měl tak škaredou…

A pak na pravou stranu doplňte konec přirovnání. Ideálně tak, aby vznikla vtipná pointa, ale platí jen jedno pravidlo. Vyhnout se klišé.

Takže třeba:

Byl zelený jak… duha po cenzuře Greenpeace.
Měl křivé nohy jak… plně naložený krmelec.
Nosil oblek tak starý… že i důchodkyně přecházely na druhý chodík.
V létě se potil tak moc… že noc co noc dostával v posteli aquaplaning.
Sestru měl tak škaredou… že by ji nechtěli ani v Rumunským bordelu.

Je to samozřejmě obtížné, ale každý, kdo píše nějaký text, by měl svou kreativitu pilovat a ne jen opakovat přirovnání, která za něj vymysleli jiní.

Co jsem použil?

Aplikaci Day One. Věřím tomu, že si píšu deník i díky této aplikaci. Kdybych zkoušel nějaký TextEdit nebo Vim a ukládal poznámky do souborů, asi by mě to nedonutilo.

Co aplikace má?

• naprosto nerušivé rozhraní, jen postranní pruh a text
• vyhledávání
• otevírací okno v horním pruhu, kde můžu rychle přidat poznámku
• zálohování do cloudu
• krásné uživatelské rozhraní, které je navíc opravdu určené na míru psaní deníku
• ochrana heslem
• připomenutí na to, aby člověk nezapomenul napsat příspěvek (což mi už po půl roce problém nedělá)

Závěrem chci říct, že psát deník vyžaduje dost disciplíny a oddanosti. Na druhou stranu se vám začne od prvního dne odvděčovat. V době, kdy lidé „nemají na nic čas“ je možná i to samotné zastavení se, ať už deníkem, vařením, nebo dobrou knihou, dobrou prevencí vyhoření nebo nějaké neurózy.

Anketu vyhodnotím já a Martin Malý a výsledek, který bude agregovat výsledky, bude zveřejněn zde a na Zdrojáku.

Pokud na článek upozorníte Twitterem nebo jinak poprosíte kamarády z dalších firem, aby ho vyplnili, získáme všichni mnohem lepší představu o tom, jak vypadají České a Slovenské firmy.

Jenže!

Velmi často se setkávám s tím, že se naprosto stejný systém, který už v podniku běží, rozhodne firma přepsat. A to proto, že aktuální zdrojový kód je bastl. A nikdo už to nechce udržovat. Všichni se bojí na ten zdroják byť jen kouknout. Je plný chyb a každá úprava buď nějakou chybu odhalí, nebo zanese.

Potkal sem se s projektem tak zpraseným, že se výsledné HTML přepisovalo regulárním výrazem, protože už nebylo možné nové věci systémově přidat.

Jsem bytostně přesvědčen, že přesně tomuto lze zabránit:

• správným procesem vývoje
  • například se dá dostatek času na vývoj a otestování, než aby se to „nějak ohackovalo“ a pak se strávil dvojnásobek času opravami na produkci
  • quickfixy dělané přímo na produkci se nedostanou do hlavní větve verzovacího nástroje, tam se oprava udělá čistě
• hrdostí vývojářů – naprostá většina profíků ve svých oborech dělají svou práci s nejlepším vědomím a svědomím. Neznám pekaře, který by dobrovolně nechal v těstu myš nebo fotografa, který by se spokojil s tím, že má fotky rozmazané a lidem uřízl nohy a půl čela. Ve světě IT je podle mé zkušenosti běžné, že se zákazníkovi dodává systém, který má uřízlé nohy a půl čela.
• nulová analýza – nejen, že se nedělá analýza u práce na několik týdnů. Když už se někde dělá, kolikrát si ji vývojář udělá sám a ani ji nekonzultuje s někým dalším. Typicky jako junior konzultuje s nadřízeným a jakmile je vývojář senior, tak najednou „nemůže udělat chybu“ a tak se neporadí.
• refaktoring – refa…co? V Česku se refaktoruje málo. Přitom já bych řekl, že pro trvalou udržitelnost jakéhokoliv systému je refaktoring naprosto nezbytný. Nejde se bez něj obejít.
• testováním – nejde jen o to psát testy. Jde o to psát účinné testy. Neulehčovat si to. Nepsat testy jen na moduly, které se snadno testují, ale hlavně na ty, v kterých je maximum průserů.

Vím, že to není právě málo věcí. A je potřebná podpora managementu podniku. Ale jsem přesvědčen, že je možné se vyhnout zbytečnému přepisování téhož systému pořád a pořád dokola.

Nehledě na to, že ono to ani není ekonomické.

Poznal jsem podnik, kde v PHP4 naprogramovali systém. Pak ho dali implementátorům a ti ho nasazují. Sami začali vyvíjet novou verzi na zelené louce. Po půl roce měli funkcionalitu staršího systému, ale v PHP5 a pak půl roku přidávali nové vlastnosti. Pak předali novou verzi implementátorům. A začali znovu na zelené louce a půl roku přepisovali systém, ale tak, že už se naučili líp objektově a vybrali pár věcí ze Zend Framewoku. Jestli to nevidíte: ta firma každý rok vyhodí 50 procent pracovní doby všech vývojářů proto, že opakovaně „tuší, co chcou“, ale přitom to neví.

Vlastně to v mnoha projektech není ani možné.

Zmiňovaná firma měla štěstí, že se jí neměnilo zadání. Tam, kde se mění často zadání a vy se rozhodnete ho napsat znovu, jste vystavení těžkému úkolu. Začnete programovat a než uděláte půlku díla, změní se vám zadání. Změníte směr a pořád a pořád se snažíte dostat se k cíli. Zadání se zase změní a tak se vydáte novým směrem. A dokola. Je to jak snažit se dohnat zajíce, který sice kličkuje, ale stejně je rychlejší než vy. A když konečně se dostanete do bodu, kdy je seznam úloh prázdný a systém hotov, je kvůli tolika změnám směru a kompromisům v takovém stavu, že můžete začít znovu přepisovat.

Platí prostě to, že ikdyž budete přepisovat systém „čistě“, špatným procesem vývoje se vždy dostanete ke špatnému zdrojovému kódu. Je naprosto nezbytné refaktorovat, dělat analýzy a nedělat kompromisy ve věcech kvality kódu. Když k tomu přidáte dobré vedení, můžete udržovat jeden zdrojový kód třeba 8 let a bude kvalitnější, než konkurenční rok starý.

Ale! Přijde druhý týden a začnete si odpouštět úkoly, říkat si: „Tohle já nemusím dělat, nic se nestane.“ A přijde třetí týden a vše je zase při starém. A velké cíle jsou zase v nedohlednu. Nebo respektive: v dohlednu, pokud si rychle koupíte další knížku o tom, jak je super dělat si týdenní plány a tak si uděláte týdenní plán a zopakuje se kolečko, abyste za 2 týdny byli na startovací čáře.

Nejhorší ze všeho jsou takové knihy, které slibují, že něco nemusíte a ono se to udělá samo. Nemusíte hubnout, hubnoucí vibrační pás hubne za vás! Klidně dál jezte metr točeňáku denně. Nemusíte pracovat, delegace práce do Indie to za vás vyřeší! Nemusíte studovat, Bill Gates taky místo toho radší budoval firmu. Nedělejte e-shop, dělejte dropshipping (co když se rozhodne totéž dělat i ta dropshippingová firma?).

Já věřím, že tajemství produktivity znám.

Je to hodně nepopulární, ale velká, velká, velká část produktivity je tvrdá práce. Nejspíš nikdy neprorazím s knížkou, ve které budu lidem slibovat za tvrdou práci dobrou odměnu. Zaprvé – je to nuda. Zadruhé – nikdo mi nezaplatí za něco, co je očividné. Lidé chtějí nalézt v knihách něco, co očividné není.

Přitom všechny úspěšné knihy (až na pár perel) se dají shrnout do pár vět.

„Chudý táta, bohatý táta – přestaň utrácet všechno, co vyděláš. Najdi způsob, jak investovat ušetřené peníze tak, aby rostly geometrickou řadou. Staň se podnikatelem a později investorem.“

„Zen To Done – osekej vše na kost. Zjednoduš to. Pak ještě jednou. Pak ještě jednou. Neboj se zastavit a nedělat nic.“

„(spousta dalších knih) – napiš si cíle. Pověš si nad postel obrázek jachty. Plň cíle a co nevidět bude jachta tvoje. Buď ambiciózní. Jack z Arizony měl rád propisky, začal s malým papírnictvím a dnes dodává propisky do celého světa a vydělává 10 milionů dolarů ročně. Ty čteš tuto knihu a proto patříš do stejné promile lidí, jako je Jack!“

Je hloupost předpokládat, že autoři těchto motivačních knih přijdou s něčím novým. Tohle – sakra – nejsou žádní teoretičtí fyzici. Ti autoři umí jen napsat dvouřádkovou myšlenku na dvěstě stran a výborně ji prodat.

Teď už v knihkupectví tyhle knížky ani neotvírám. Našel jsem si věci, které pro mě fungují. Část z nich píšu tady. Část z nich se dozvíte na školení GTD. Jsou to ale poměrně nudné pravdy, které zahrnují tvdou a chytrou práci, kontrolu a perspektivu, cílevědomost a pokrok – po malém úspěchu větší.

Je čas se smířit s jednou věcí: tahle literatura je vnímána jako literatura faktu, přestože to je beletrie. Hezké čtení. Přečtete si dnes kousek osudu nebohé Gervaisy v Zabijákovi od Zoly, nebo radši o tom, jak Donald Trump kupoval svůj první mrakodrap a jak byste si měli taky jeden koupit? Obojí je vaší dnešní realitě vzdálené asi stejně.

Já si každé ráno opakuji: „Začni s nutnou prací aspoň na chvíli. Drž se svého cíle a nepřeskakuj moc mezi úkoly.“ To je víc, než všechny motivační knížky dohromady.

Co jsem zjistil:

Trik pro rychlé usnutí – při short napu máte 5 minut na to usnout. Jinak bude spánek moc krátký. Osvědčilo se mi soustředit se na dech. Když na nic moc nemyslím, lehnu na záda a soustředím se na dech, nemám problém za pár minut zabrat.

Minutka je váš přítel – pořiďte si minutku. Nejlépe takovou, která jen necinkne, ale která opravdu hodně zazvoní. Hodí se na spoustu dalších věcí. Kdybych měl z hořícího domu vynést dvě věci, byl by to laptop a kuchyňská minutka!

Mobilům se nedá věřit – už je umíme ovládat nejspíš ze spánku, nebo občas nebudí, zkrátka jako budík se mi mobil neosvědčil. Mobily jsou zlomyslné a občas díky nim přetáhnete zdřímnutí o 4–5 hodin.

Nebudete vědět, co s časem – to je pravda. Pokud nežijete stylem, že nevíte, kde vám hlava stojí, zvažte, jestli vůbec další hodiny nějak využijete. Už ty dvě ušetřené hodiny denně vám dají zabrat, abyste si vymysleli zábavu (a nepočítejte, že budete schopni nějak zvlášť pracovat, hlavně zezačátku ne).

Po short napu budete osvěžení. Kdykoliv si dáte krátký spánek, budete po probuzení bystřejší, chytřejší a příjemnější na lidi okolo. Někteří lidé by měli i při osmihodinovém spánku zařazovat ještě zdřímnutí.

Velkým nepřítelem polyfazického spánku je hospoda, cestování a alkohol. Tvrdí se to i o kofeinu. Na mě kofein neúčinkuje, takže nemůžu soudit.

Není pravda, že potřebujete 8 hodin spánku. Nejspíš je potřebuje mozek zvyklý na monofazický spánek a vědci nejspíš lidi se změněnými režimy nezkoumali. Jsou lidé, kteří v polyfazickém spánku vytrvali měsíce a roky bez toho, aby byly pomalejší nebo hloupější nebo trvale ospalí. Samozřejmě adaptační fáze vám dá prvních 14 dní zabrat. Use Google Luke!

Jsme ohromně svázání konvencemi. Večer spát. Ráno vstávat. Někdo je ranní ptáče, někdo je sova, nikdo není obojí. Ikdyž tomu třeba nevěříte, ale to, že spíte méně vám lidi nebudou zrovna závidět, budou si myslet, že jste divní. Ale jak jsem psal už dříve, lepší být divný, ale mít o celé roky delší život, než normální a třetinu života trávit v bezvědomí.

Není vůbec problém dát si občas den monofazického spánku. Typicky když přijedete za rodinou a všichni se odeberou v 10 spát a v domě je tma. To jsem skutečně už netlačil na pilu. Když pak navážete na svůj spánkový cyklus, je to v pohodě. Narozdíl od situace, kdy zaspíte při zdřímnutí – to vám pak posune celý spánkový cyklus a může se vám stát, že půjdete spát třeba už v 8 večer.

Pokud nejdete do uberman (jen 4 případně 6 krátkých zdřímutí za den a žádný delší spánek), naplánujte si hlavní spánek tak, aby se vám kryl mezi 2–5 hodinou ráno. Tyto hodiny jsou kritické a garantuju, že nic kloudného v té době nevymyslíte. Ty tři hodiny je zbytečné být vzhůru.

A nakonec výzva. Rozhodl jsem se zkusit následující rozpis: 4,5 hodin spánku v noci. Půl hodiny zdřímnutí jednou přes den. Kdo chcete zkusit taky nějakou formu polyfazického spánku, napište mi e-mail. Někde uděláme diskuzi, v které se budeme navzájem hecovat a sdílet zkušenosti, tipy a triky.

To, že spíme jen jednou denně má ohromný vliv na náš život. To jsem si neuvědomil, dokud jsem nezkusil polyfazický spánek. Poly-co?

Polyfazický spánek spočívá v tom, že nespíme jen jednou denně, ale uděláme si během dne čas na jeden až několik půlhodinových zdřímnutí. Za každou půlhodinu spánku si pak můžeme odečíst dvě hodiny spánku v noci.

Já jsem experimentoval s jedním zdřímnutím. A co jsem zjistil? Obvykle se udává, že pokud vynecháme krátké zdřímnutí (tzv. short nap), budeme rozhození několik dní. U siesty to tak není. Zjistil jsem, že mi stačí 6 hodin spánku a vynechání short napu mi nedělá problém. Prvních 20 minut po probuzení se sice motám jako smyslů zbavený, ale pak už je to v pohodě a necítím žádnou únavu.

Dlouho jsem tedy provozoval denní rytmus: spánek 00:00 – 06:00 a když jsem měl chuť, kolem 18:00 jsem 30 minut spal. To bylo dost na to, abych poznal krásy a zápory toho spát polyfazicky:

• žádný vliv na kreativitu – toho jsem se bál asi nejvíc, méně spánku má způsobit, že lidé jsou nerudní, nekreativní a snáze ovladatelní. Nic z toho se nenaplnilo.
• v dvou hodinách před půlnocí, kdy jsem měl čas sám pro sebe, jsem obvykle nedokázal udělat žádnou užitečnou práci. Snažil jsem se tedy aspoň do této části dne soustředit čtení článků a knížek. Každý máme nějaké produktivní pásmo, u mě je cca 8–12 a pak kolem 14–15 hodin, určitě ale ne 22–24.
• velký klad je, že vám najednou ostatní připadají, že jsou zbytečně „v hibernaci“. Že si zbytečně ubírají roky života. Když se to spočítá na celý život, myslím, že polyfazickým spánkem si člověk prodlouží život a spoustu let, které nestrávil v bezvědomí může použít k čemukoliv.
• má to negativní vliv na rodinný život – najednou s přítelkyní ani nechodíte spát, ani s ní nevstáváte. Četl jsem na více místech, že lidé fungující polyfazicky ostatním připadají jako podivíní. Ale lepší být podivín, než si zbytečně zkrátit život o 5 let, že?
• zezačátku jsem si kladl otázku, k čemu mi to je, když v těch dvou hodinách nedokážu pracovat. Stačilo si připomenout základní fakt: nejsme tu pro práci. Práce je jen zábava a pokud nemůžu dělat tuhle zábavu, můžu zatím dělat nějakou jinou. Třeba to čtení článků, které mi bralo čas ve dne.
• ohromně snadno se mi začalo vstávat. Na školení často vstávám kolem páte ráno, abych dojel přes půl republiky. Domů se často vracím kolem desáté večer. Dřív mi to vadilo, teď už je mi to jedno.

Právě teď polyfazický spánek nepraktikuju. Může za to ten „rodinný život“. Garantuju vám, že vám přítelkyně nepoděkuje, když místo ní budete trávit noci u počítače. Věřím ale, že tento pokus měl velký smysl a v průběhu zimy bych se chtěl pokusit o to přejít jen na 4 hodiny spánku a dvě krátké prospání přes den.

Občas mě to donutí do těch komentářů vlézt a to je vždycky takové osvěžení. Uvědomím si, že průměrné IQ je pořád 100, nic se nezměnilo a já jen do té doby měl to štěstí pobývat ve společnosti chytrých. Ostatně – když na mě v komentářích, milí čtenáři, zaútočíte a já vám poděkuju, máte to štěstí, že právě vy jste mi „normální lidi“ připomněli. Přestože většina komentářů na serverech typu idnes, ihned, novinky jsou obvykle hrozné zvratky, občas zachytím nějaký postřeh, perlu v hnoji.

Jakým způsobem se má člověk probírat běžným bahnem diskuzí? Naučím vás pár tipů, jak rychle filtrovat komentáře, které obvykle nemají žádnou informační hodnotu.

1. Pokud obsahuje komentář slovo „jaksi“, nemá smysl číst dál. Vypozoroval jsem, že za dobu, co čtu diskuze obsahoval pouze 1 příspěvek slovo jaksi a dával smysl. Skóre je odhadem 500:1.
2. Jakmile přečtete „stát by měl“, přestaňte číst dál. Autor obvykle ve větě poté demonstruje svět, který by byl pro něj naprosto ideální. Dovětek za „stát by měl…“ bude obvykle naprosto opačný, pokud ho píše dlužník nebo exekutor.
3. Pokud je text VELKÝMI PÍSMENY, nečtěte dál. Autor příspěvku se snaží přehlušit své okolí, protože je obvykle fanatik a nikdy se od něj nedočtete žádná fakta, pouze smyšlenky:
4. Jakmile narazíte na jakékoliv označení politické orientace (socan, modropták, černoprdelník), přestaňte ihned číst. Nebo si chcete přivést vysoký tlak?
5. Při druhé gramatické chybě (na třířádkovém komentáři) přestaňte číst. Jedna chyba může být překlep, pokud ale dotyčný sází chyby jednu za druhou, pravděpodobně v dětství ani dospělosti pořádně nečetl knížky. Takový člověk je odkázaný jen papouškovat názory – obvykle nenávistné – jiných. Výjimku tvoří dysgrafici. Pár jich znám, i když jsou to chytří a milí lidé, nějakou náhodou taky nejsou moc dobří při veřejném mluvení – o jejich psaném textu nemluvě. S dysgrafikem je lepší jít na pivo a bavit se s ním osobně. Vesele v komentářích proto ignorujte i ty a radši je pozvěte na pivo.
6. Pokud někdo použije více interpunkčních znamének za sebou, nemusíte číst dál. Dokonce jsem zjistil, že málokdy najdete smysluplný komentář, když jeho autor nedělá mezeru za tečkou a čárkou.
7. Termíny „zavřít…“ (někoho, kdo je úspěšný a trochu drzý), „vyfasovat tepláky“, „pověsit na lampu“, „poslat domů“ (v článcích o muslimech nebo romech) jsou okamžitý stop! Člověk, který něco takového vyplodí nemá v hlavě nic kromě nenávisti. Takový vás nic dobrého nenaučí.
8. Každý odstavec má začínat zajímavou větou – ideálně tou nejdůležitější, když ne, aspoň zajímavou. Pokud začíná větou, která vás nezaujala, nečtěte dál. Zbytek odstavce obvykle není lepší.
9. Jakmile někdo píše o „nás chudých lidech“, také se obvykle nic chytrého nedozvíte. Nemusíte číst dál. Není sice hanba být chudý, ale kdo v hlavě něco má, ten se obvykle identifikuje jinak: „my sokolové“, „my zedníci“, „my pěší turisté“. Takový člověk se sice nestydí za svou chudobu, ale nedělá z ní ctnost (protože to žádná ctnost není a chudí nejsou o nic čestnější než bohatí). Jakmile se dočtete něco od komentátora, který se otevřeně identifikuje s chudými, ve statisticky významném množství se dozvíte jen o tom jak: a) stát chudým nic nedá, b) jsou bohatí lumpové a měli by jim všechno znárodnit a pak je poslat do vězení
10. Na běžných serverech, kde se nezdržují ekonomové je i stop slovem kapitalismus. On totiž skutečný význam slova kapitalismus skoro nikdo nezná (zejména ne v Česku, kde žijeme v socialismu a tvrdíme, že je to kapitalismus, ha ha ha).

Můj návod samozřejmě není stoprocentní. Možná někde žije génius, který má svět hodně co naučit a svět o něm neví, protože má zablokovaný caps lock. Pro dobro vás samotných si takového můžete nechat klidně ujít. Na diskuzních serverech je komentátorů, kteří porušují některé z těchto pravidel 90 procent. Těch 10 procent komentářů, které sítem projdou, obsahují zajímavou myšlenku tak ve třetině případů.

Dáme si soutěž? Kdo dokáže napsat komentář, který porušuje všech 10 stop pravidel?

V tuto chvíli se už na bitbucketu dá stáhnout verze, která:

• má vylepšené chybové hlášky
• místo metody collect() se teď používá assertExpecta­tions()
• testování počtu volání u metod never, once, twice, atLeastOnce, noMoreThanOnce lze realizovat pomocí atributu
• zaregistroval jsem doménu mockista.com, kde je v tuto chvíli starší článek vydaný o Mockistovi

Co plánuju do Mockista 2?

Generování mocku z existujícího objektu

Pochopil jsem, že praktické použití pro mnohé brání právě to, že programátoři používají Type Hinting, kterým Mockista neprojde.

Vymyslel jsem rozhraní, kdy 1. parametr nemusí být jen pole, ale i třída nebo objekt:

$mock = Mockista\mock($object);
$mock = Mockista\mock("Trida");

Pokud chcete použít rychlý způsob pro přepsání, bude možné místo 1. parametru, jako je teď, použít druhý:

$mock = Mockista\mock($object || "Trida", array("x"=1, "y"=>function(){return time()};));

Testování pořadí volání

Získání atributu ordered nad atributem způsobí, že bude otestováno i pořadí.

$mock = Mockista\mock();
$mock->f(1)->ordered->once->andReturn(true);
$mock->f(2)->ordered->once->andReturn(false);
$mock->freeze();
$mock->f(1);
$mock->f(2);
$mock->assertExpectations(); // projde OK, opačné pořadí hodí výjimku

Špión

Mockista by mohl do mockovaného objektu předávat volání, takže by byl jen transparentní dekorátor a na konci by vám umožnil testovat, že byly metody volány správně.

$connection = new Nette\Database\Connection("mysql:dbname=test")
$mock = Mockista\mock($connection);
$mock->query()->exactly(6)->spy;
$mock->freeze();
// nejake pouziti db
$mock->assertExpectations()
$mock->unfreeze();
$mock->query()->getCalls(); // vrati pole volani s parametry a navratovymi hodnotami

Dokumentace

Na webu Mockista.com bude úplná dokumentace s příklady a to i v angličtině. Bez toho, pevně věřím, nemá ta knihovna šanci uspět.

Co vám překáží v mockovacím nástroji v PHPUnitu? Jaké nástroje používáte v jiných jazycích? Co byste chtěli vylepšit?

V okamžiku, kdy startup najde svůj trh, svého zákazníka, dodá produkt, který zákazník chce, je skoro vyhráno. Je potřeba umět ještě jednu věc: zopakovat to, zopakovat to, zopakovat to, zopakovat to… A naučit se růst objemem zakázek tak dlouho, dokud se podnik nedostane do černých čísel.

Přesně v tu chvíli, kdy se tam dostanete, přestaňte být startup.

Zaveďte normální pracovní dobu. Mějte firemní procesy. Rozdělte role a pravomoci. Zaveďte management. Staňte se firmou!

Být startup, to není nic k oslavování. Být startup znamená, že tam ještě nejste. Že máte produkt, kteří lidi nechtějí. Že neumíte propagaci. Že nemáte nic jisté. Že jste úspěch ještě nezopakovali dostkrát.

Být firma, to je důvod k oslavě! Jste v zisku. Nepotřebujete dalšího investora (a když už ho chcete, jeho nesehnáním z trhu nezmizíte). Máte produkt, který lidi uspokojuje. Opakujete svůj business a když je nejhůř, uskromníte se, v nejhorším se rozloučíte s nějakým zaměstnancem, ale jedete dál.

Je spousta druhů obchodování, kde si vůbec fází startupu nemusíte projít. Slyšeli jste někdy o zelináři, který by rozdával zelí zadarmo, dokud nepřijde na to, jestli má účtovat po kusech nebo kilech a jakou má mít vývěsní ceduli? Dnes je doba, kdy se za startup označuje skoro cokoliv. Je to pohodlné: jsme ve ztrátě, protože jsme startup. Ne proto, že náš produkt lidi nechtějí, neumíme ho prodat a ani nevíme, kolik si říct. Musíme jen udělat „správný počet pivotů“.

Ještě jednou musím říct: je mnohem, mnohem lepší bojovat a vidět zisk někde v budoucnu, než se smířit s tím, že cíl je daleko. Ale nezapomeňte, že doba, kdy budete s partou kámošů 16 hodin denně sedět u kulatého stolu a hackovat s flaškou vodky, musí jednou přejít v podnik. Podnik, který vás uživí ještě za spoustu let (a nebo aspoň toho, komu ten podnik prodáte).

Z agilních metodik a technik jsem si vzal:

• týdenní sprinty (na jejichž konci dělám klasické review, na začátku planning)
• minimalizace work in progress – dělám menší projekty a snažím se nepracovat na mnoha projektech naráz
• daily standup: především tedy kontrola, co dělám, zda to stíhám v termínu a podobně
• minimalizace time to market – tedy zkracovat čas pro uvolnění projektů do produkce. Například za ŽítIT je ani ne týden vývoje (ostatně důležitý je obsah, aplikace postupně poroste) a už se blížím k prvním změnám (oproti přidávání nových vlastností, které bych jinak dělal)
• definuju si víc Done, tedy kdy je úkol hotový a snažím se nedělat o moc víc, než je nutné
• zákaz přesčasů – mi paradoxně přidal na produktivitě.

Agile mění, co vlastě člověk dělá. Snažíte se dostat rychle nějaký výstup a ověřit, jestli funguje. To je přesně věc, která mi chyběla. Dřív jsem měl dlouhatánské projekty a netušil jsem, jestli z toho nakonci něco bude. Teď se předem snažím vycházet při definici projektů z toho, co mi chybí, o čem vím, je potřeba a nebo to, u čeho můžu ověřit, že to skutečně splnilo svůj cíl.

Obecně ve mě Agile navíc buduje vztah k experimentu. Postup z testování – zjišťovat, jestli to funguje – teď stále častěji používám i v normálním životě. Místo toho, abych něco hloupě předpokládal, protože to někdo řekl, zkouším, zda to tak skutečně je.

V neposlední řadě jsem se stal velkým fandou procesů. Někomu, kdo agile tak dobře nerozumí, by to mohlo připadat zvláštní. V agilním manifestu se přeci jde proti procesům! Není to pravda, ani trošku, ani úplně. V tuto chvíli chystám školení (firemní i veřejná) pomocí procesů. Vylepšuju pomocí procesů. A když si při plánování nejsem jistý, jestli a jak něco dělat, nakreslím si diagram průchodu a zrealizuju ho.

Vždycky jsem v knize GTD četl, že si systém budu postupně vylepšovat. A byla to pravda. I o agile jsem nejdřív četl, pak i zjistil, že se postupně vylepšuje. Jsem šťastný, že benefity obojího, se mi daří do života zavádět a oba systémy si tak vylepšovat.

Chcete o agile v reálném životě slyšet víc?

Role analýzy je říct mi, kde jsem a co potřebuji, abych došel k dalšímu sprintu.

K programování pomocí TDD nemusím mít stovky diagramů, desítky stránek specifikace. Ale taky to neznamená, že k cíli dojdu intuitivně. Ikdyž je TDD skvělé, je každá jeho iterace jen drobný krůček k cíli, který může být daleko. Mnohem jistější je člověk, pokud má k cíli kdesi za horizontem navíc spoustu bodů po cestě, které ho k cíli dovedou. Proto i to TDD by mělo směřovat k milníkům. Situace má i více benefitů. Třeba v two bits jsem zažil, že jsme pomocí testů začali psát aplikaci z dvou stran, jeden od modelu a druhý od view. Ikdyž nebylo dané žádné rozhraní, díky dílčím cílům (rozdrobeným na 1–2 hodinové User Stories) a aktivní komunikaci jsme se potkali a kód do sebe zapadl.

Ponaučení zní: Udělejte si drobné cíle a osvětlete, co znamená „hotovo“ – toto je součást vaší analýzy.

Další mýtus je v tom, že díky MVC nepotřebujeme analýzu. Díky tomu, že se nedělá analýza v PHP, je 90 procent projektů v něm napsaných neudržovatelný odpad. Málokdo ale ví, že vinou „MVC mýtu“ je odpad i 90 procent aplikací v Rails nebo Djangu.

Uvedu některé chyby, které například Railsisté dělají běžně, protože nedělají analýzy:

• Active Record je vhodný pro pár procent situací. Přitom ho používá tak 90 procent projektů – už proto je většina věcí napsaných v Rails neudržovatelný bastl. Kdyby dělali analýzu, zjistili by, že Active Record se nehodí, v dlouhodobém pohledu zpomaluje práci. Kdyby dělali analýzu, zjistili by, že Data Mapper (který získává v Rails komunitě popularitu, ikdyž ta jeho nejznáměnší implementace je taky udělaná špatně) stojí jen jednu vrstvu nad Active Recordem a že můžou mít Model daleko důmyslnější, rozšiřitelnější a do budoucna udržovatelnější. Stačil by class diagram a vůbec nestavět Model nad tím, že existuje něco jako databáze.
• do RESTu exponují Modely a ne Use Cases. Důvod, proč je většina RESTful služeb implementovaných špatně je v tom, že: „exponovat model je jednoduché a nějak to jde vždy použít“. Kdyby dělali analýzy, popíšou ve své aplikaci Use Cases a postaví služby nad nimi. Když budu chtít převést peníze, nezajímá mě API pro výběr, API pro vklad a API pro transakce. Chci jedno API pro převod. A to se Rails prý snaží propagovat „správné programátorské návyky“. Stačil by use case diagram.

A to jsou jen Rails, které jsou ještě pořád nadprůměrný framework.

Ponaučení zní: nekonzumujte hloupě to, co vám nabídne framework a udělejte si class diagram (aspoň pro Model) a use case a stavte aplikaci podle nich.

Další mýtus je, že ve Scrumu nemusí být analýzy. Přískoky po týdnu nebo po dvou jsou sice skvělé, ale i během jednoho týdne se dá hodně zkazit. Není nic horšího, než desetkrát opakované kolečko:

„Posuň to o 2 pixely doprava“
„Tenhle input dej na druhou stranu“
„To logo by mělo být větší“
„Mělo by se dát filtovat podle ceny“
„Jak jste mohl zapomenout na odkaz Odhlášení?“

Tomuto by se dalo snadno bránit. Jak?

Pamatuj, prototyp je tvůj přítel. Řekne ti, na jaké stránce co uvidíš, jak to bude rozložené, co můžu vyplnit, na co kliknout a kam se tím dostanu.

Poslední roky snad všechno, co mělo nějaké GUI, jsem vyvinul s pomocí prototypů. A musel jsem se zeptat na mnohem méně věcí a daleko víc věcí bylo dobře z první.

Shrňme si to tedy:
Rozbijte úkoly na maličké, určete, co znamená „mít je hotové“. Udělejte si use-case a aspoň omezený class diagram. Všechny stránky v aplikaci pokryjte prototypem a jako součást zadání vždy dodávejte i ten.

Jaké je dnešní cvičení?

Naučte se používat funkci assert.

Tato funkce testuje, zda se podmínka vyhodnotí jako false a pokud k tomu dojde, dojde k chybě. Je možné ale chování assertu přepsat svým handlerem, který například jen tiše zaloguje chybu nebo udělá cokoliv podobného.

Její syntaxe je:

assert('vyraz, ktery musi byt vyhodnocen true')

// napr.

class FileStorage
{
        private $securizer;

        function __construct($securizer)
        {
                // type hinting pro chude
                assert('method_exists($securizer, "sanitizeAgainstDirectoryTraversal")');
                $this->securizer = $securizer;
        }

        function save($key, $value)
        {
                assert('is_string($key)'); // staticke typovani pro chude
                file_put_contents(__DIR__ . '/' .
                        $this->security->sanitizeAgainstDirectoryTraversal($key), serialize($value);
        }

        function load($key)
        {
                assert('is_string($key);');
                $path = __DIR__ . '/' . $this->security->
                        sanitizeAgainstDirectoryTraversal($key);
                if (file_exists($path)) {
                        return unserialize(file_get_contents($path));
                }
        }
}

Naučte se používat assert tam, kde většinou používáte var_dump, print_r apod. Jeho použití je zejména při vývoji bez testů na začátku a konci metod, kdy na začátku testujete parametry, které dostáváte a na konci testujete návratovou hodnotu a to, že objekt změnil svůj vnitřní stav - samozřejmě pokud k tomu mělo dojít.

Až svůj kód napíšete, nemusíte asserty v metodách nechávat. Pokud je odstraníte, bude kód čitelnější. To je samozřejmě znatelná nevýhoda testů v kódu (mimo jazyků, kde obdobný přístup: Design By Contract, je přímo součástí jazyka). Jakmile máte upravit kód, přidejte (nebo upravte) asserty tak, aby nejdřív reflektovaly nové chování. Nechte testy nejdřív selhat. Pak teprve naprogramujte řešení. Je to tak lepší z několika důvodů. Za stěžejní považuji ten, že tak ověříte, zda jsou vaše testy skutečně účinné.

Jestli vás cvičení bavila, přihlašte se na školení Power PHP, kde dostanete šanci poznat v komletním rámci tato a další cvičení a pak si je v systému Žít IT sami vyzkoušíte.

Vypisuji nová školení plus je tu nový termín školení testování. Power PHP je zaměřené na kvalitu a produktivitu, ať už programujete v PHP cokoliv, v OOP PHP se naučíte navrhnout libovolně velký systém čistě s pomocí návrhových vzorů.

Power PHP

Co se naučíte ve školení Power PHP? 20 různých cvičení, díky kterým snížíte chybovost svého kódu a uděláte ho čitelnější, další cvičení, jak zrychlit a zlepšit svou analýzu, ukázky toho, jak se programovat nemá a jak špatné kusy kódu poznat a zbavit se jich, zároveň získáte tipy, jak zlepšovat svou produktivitu při vývoji. Dozvíte se o nástrojích, jak předcházet chybám, jak dělat analýzy pro MVC (Zend, Symfony, Code Igniter, CakePHP) i MVP (Nette) frameworky.

Druhý den se naučíte podstatu a řešení všech častých bezpečnostních chyb, které na webu běžně potkáte (XSS, SQLi, CSRF, Session Fixation…)! Navíc se naučíte psát automatizované testy pro odhalení většiny těchto chyb. Zlepšíte svou práci s výjimkami, naučíte se, jak navrhovat třídy výjimek a jejich strukturu, povíme si, jak zlepšovat starý a neudržovaný kód. Na konci školení se naučíte psát škálovatelné aplikace, které můžou běžet přes N serverů.

Školení je dvoudenní a stojí 5500 Kč bez DPH. Je vypsáno na datum 28.-29.11 v Praze. Studenti získávají slevu 20 %.

Absolventi se můžou těšit, že v Žít IT najdou příklady, na kterých si zkusí další cvičení pro snížení chybovosti celkově a to včetně bezpečnostních chyb.

OOP PHP

V tomto školení OOP se naučíte to, jak hledat objekty a třídy v projektu. Doporučované a nedoporučované návrhové vzory a jejich implementace. Architekturu MVC a MVP frameworků aneb jak a proč to funguje, tak jak to funguje. Zároveň se naučíte pokročilé postupy, jako je řešení odložených úloh v PHP, oddělování modulů, snižování závislostí mezi moduly.

Při školení budu kombinovat funkcionální a objektový postup, s tím, že tam, kde by byly postupy ve sporu, bude upřednostněn objektový přístup.

Během školení bude praktické cvičení, kdy zkusíme rozebrat problém a formou agilní analýzy navrhneme první iteraci a uděláme design.

Školení je jednodenní, stojí 3000 Kč bez DPH. Je vypsáno na datum 1.12. v Praze. Studenti získávají slevu 20 %.

Absolventi školení budou mít v systému Žít IT možnost zopakovat si návrhové vzory a zkusí si sami hledat objekty v zaslaném zadání.

Školení testování v PHP

Vypisuji další pokračování svého školení testování v PHP. Své školení neustále vylepšuji. V posledním školení jsem rozšířil podstatně množství praktických cvičení, které se při školení dělají.

Naučíte se chápat, jak chyba vzniká, z jakých důvodů. Naučíte se rozhodnout, jaké testy a kdy máte psát. Naučíte se psát přímo testy. Naučíte se, jak psát testovatelný kód. Naučíte se pokrývat existující kód testy.

Školení je jednodenní (je o něco dělší, než obvyklých 7 hodin), stojí 4400 Kč bez DPH a bude 30.11. v Praze. Studenti získávají slevu 20 %.

Žít IT už nyní má připravené příklady, kde si studenti zopakují psaní testů a ještě si vyzkouší můj nový nástroj na mockování Mockista.

Školení GTD

Konečně vypisuji školení GTD, kde se naučíte celé Getting Things Done, jak ho navázat do svého života, běžné rituály denně i na vyšších úrovních.

Toto školení si klade za cíl urychlit přechod ke GTD, opravit všechny chyby, které by se mohly při přechodu na GTD stát a zabránit jeho zavedení. Během školení studenti získají spoustu mou doporučovaných postupů a naučí se i to, jak GTD spojit do spolupráce v práci, v běžném životě atd.

Školení je jednodenní, stojí 3900 Kč bez DPH a bude 2.12. v Praze. Studenti získávají slevu 20 %.

Žít IT bude i tady pro absolventy připraven a získají možnost zopakovat si všechny důležité rituály a naučí se další postupy, pomocí kterých čelím prokrastinaci a zvyšuju svou produktivitu.

Budu se na vás těšit!

Tak jsem vymyslel systém průběžného rozvoje, který právě spouštím do beta provozu. Běží na adrese ZitIT.cz a je k dispozici všem, kteří kdy byli na mém školení (na spoustu z vás nemám e-mail, komu ještě nepřišlo pozvání, prosím, napište mi e-mail).

Startuju s osvěžením znalostí ze školení testování a Scrum a brzo přibudou i moduly pro GTD a time management, které co nevidět už vypíšu a dál rozvoj pro ty, kteří pracují v HTML5 a Javascriptu.

Moduly jsou výhradně pro absolventy mých školní. Časem přemýšlím, že vypíšu i veřejná témata (jako třeba Mercurial) pro oblasti, kde chci lidi něco naučit a objem nutných znalostí nevyjde na celodenní školení a ani není moc v čem se rozvíjet.

Tento web bude pro absolventy mých školení zezačátku zcela zdarma a po zopakování témat budou platit pár stovek měsíčně za studenta a modul. Časová náročnost bude 1–2 hodiny měsíčně.

V tuto chvíli pracuju na spoustě příkladů a rád bych při přípravě oslovil další možné autory příkladů.

Chci ŽítIT popřát šťastný start!

Takže jaký je váš dnešní úkol:

Zbavte se magických konstant a duplicitního kódu.

Co je magická konstanta? Magická konstanta je kousek dat (například řetězec, číslo), který se vyskytuje ve zdrojovém kódu bez toho, aby měl nějaké pojmenování, které určí význam.

sleep(3 * 86400)

Nic, člověku, který po vás přijde, může přijít divné, proč má výpočet zastavit na 3 * nějaké divné číslo.

const DAY = 86400;

sleep(3 * DAY)

Aha, program má zastavit na 3 dny! Ale pořád máme v kódu magickou konstantu: 3. Proč mám stát 3 dny?

Co je:

sleep($config->import->daysToWaitToNext * DAY);

To je najednou zjevné: kolik dní se má po importu počkat na další import?

Odstranění magických konstant zpřehlednilo kód.

Duplicitní kód není jen kód, který vypadá na první pohled stejně. Duplicitní kód může kolikrát vypadat i dost odlišně a přesto v něm lze najít společného jmenovatele.

// vygenerovat pole
function gen_arr() {
        return array_map(function($row) {
                return (object)array("x"=>$row%2, "y"=>$row);
        }, range(1, 10));
}
$items = gen_arr();

// prvni funkce
$accumulator1 = 0;
$func1 = function($row) use (&$accumulator1) {
        if ($row->x) {
                $accumulator1 += $row->y;
        }
        return $row->y;
};

// druha funkce
$accumulator2 = array();
$func2 = function ($row) use (&$accumulator2) {
        $rowArr = (array)$row;
        $accumulator2 = array_merge($accumulator2, array($rowArr));
        return $rowArr['y'];
};

$items1 = array_map($func1, $items);
$items2 = array_map($func2, $items);

//////////// ------------------

// spolecny jmenovatel
$returnY = function($row) { return $row->y; };

// prvni funkce
$accumulator1b = 0;
$func1b = function($row) use ($returnY, &$accumulator1b) {
        if ($row->x) {
                $accumulator1b += $row->y;
        }
        return $returnY($row);
};

// druha funkce
$accumulator2b = array();
$func2b = function($row) use ($returnY, &$accumulator2b) {
        $accumulator2b = array_merge($accumulator2b, array((array)$row));
        return $returnY($row);
};

$items1b = array_map($func1b, $items);
$items2b = array_map($func2b, $items);


// overim, ze je vse v poradku
var_dump(
        $accumulator1 == $accumulator1b,
        $accumulator2 == $accumulator2b,
        $items1 == $items1b,
        $items2 == $items2b
);

/** ocekavame vystup:
 * bool(true)
 * bool(true)
 * bool(true)
 * bool(true)
 */

Tento příklad není právě z praxe, každopádně ukazuje, že i kusy kódu, které vypadají ne moc podobně, můžou obsahovat společnou funkcionalitu.

Zbavení se magických konstant a duplicitního kódu učiní náš kód čitelnější (většinou) a lépe udržovatelný (vždy). Tak hurá do toho!

V knize vystupují kontrasty mezi Amerikou a Francií. Hrdinové si to náležitě užívají – a celé to působí realisticky, ostatně autorku stihl podobný osud, takže měla odkud čerpat. Mezi tím se prolíná kniha jídlem, o to je to pro mě – foodieho – větší zábava.

Já bych se chtěl podělit o pár útržků a myšlenek, které jsem v knížce načerpal:

Nejdřív z pohledu Francouze:

Byl to Henry Miller, kdo řekl: „V Americe je každý člověk potenciálním prezidentem.“ Tady je člověk potenciální nulou.

Mí rodiče se nikdy nesetkali s nikým, kdo by se věnoval takovým věcem. Nejsme z takového světa. Neměli žádné přátele, kteří by mi mohli poskytnout práci. Měli strach, že neuspěju a oni mi nedokážou pomoct. Báli se, že si nezískám místo ve společnosti. A já sám jsem na to neměl sílu. Nechtěl jsem je zklamat. A tak jsem se stal inženýrem. Tak to tady u nás chodí. Pokud chceš udělat něco trochu jinak, pokud o kousek přečníváš, uříznou ti hlavu. Je to tak od doby revoluce. Znáš to heslo: Liberté, égalité, fraternité. Égalité – rovnost – se nachází přesně uprostřed. Všichni musí být stejní.

Američanka:

Ze všech historek, které mi Gwendal do té doby vyprávěl, mne tahle šokovala ze všech nejvíce. Nikdy v životě, ani jednou, mi nikdo neřekl, že existuje něco, co bych nemohla dokázat, nebo čím bych se nemohla stát.

Byl tak inteligentní a soustředěný na to, co dělal. Mohl dokázat cokoliv. Gwendal stále ležel v trávě a užíval si sluníčka. Nevypadal zatrpkle nebo rozlíceně. Tak to prostě chodilo a nemohlo mu to zkazit chuť na odpolední siestu.

Všechny ty věci, které mi vířily hlavou, se však nedotýkaly jádra problému. Na Gwendalovi bylo ještě něco jiného, co ve mně vyvolávalo neklid. A pořád jsem to nedokázala vyhmátnout. Až se mi to podařilo. „On je pořád tak debilně šťastný. Až je to divné.“ Takhle jednoduché to bylo. Gwendal je šťastný člověk a se na šťastné lidi dívám od přírody s podezřením. V Americe, kde jsem vyrostla, neříkají malé děti: „Až vyrostu, chci být šťastný.“ To prostě není správný konec věty. U nás se říká: „Až vyrostu, chci být lékařem, astronautem, pilotem stíhačky.“ Štěstí pro mne bylo něco značně abstraktního, cosi jako konec velice dlouhé rovnice, která by mohla vypadat třeba takhle: počáteční sebeúcta vynásobeno x úspěchů, vyděleno y dolarů, z dluhů, minus f odpracovaných hodin, plus g získaného respektu. Štěstí bylo podle mého názoru konečným výsledkem celého seznamu věcí, které jsem ještě nezvládla.

Bála jsem se, že Gwendal je až příliš spokojený. Že pokud se stále o něco nesnaží (a tudíž se nepotýká se stálými zklamáními) jako já, je s ním něco v nepořádku. A že mu také něco chybí.

Ze zkušenosti můžu říct, že mi lidé přišli šťastní v Americe i ve Francii. V Americe tím svým způsobem, že i z obsluhy někde ve fast foodu bylo vidět, že si žije Americký sen™, věří, že se bude mít lépe, že právě poctivou prací to někam dotáhne. V Americe pracovali i bezdomovci. Ve Francii lidé byli šťastní jiným způsobem, poznali jste to na těch jejich dlouhých obědech. Dokázali si nekonečně dlouho šťastně vykládat. Jen pauza mezi chody trvala u nich déle, než mě celý oběd. Radost z toho, že rozbíjí krusičku na Crème brûlée, nebo že jsou elegantně oblečení a opačné pohlaví si jich všímá (co jsem zatím zažil, nejvíc elegantně chodí oblečení muži v Paříži).

Samozřejmě najdou se i ve Francii lidé, kteří chtějí hodně dosáhnout. A v Americe lidé, kteří žijí bohémským životem. A asi každý z nás občas žije v tomhle kontrastu: něco dokázat versus pořádně si to užít. Osobně si myslím, že vytěsnit ze života jeden z těchto faktorů člověku nepřidá na štěstí. Všichni by si měli užívat, ale každý hezky za svoje.

Bude se jednat o službu, která má mít globální charakter, má fungovat v prohlížeči a budou ji používat miliony lidí. Funding už je zajištěný.

PHP

• framework (zatím volím mezi Nette, Zendem a Symfony, problém Zendu je v tom, že verze 2 je za dveřmi, ale ne ve stavu, že by se dal používat; na Symfony je obtížné sehnat vývojáře; i Nette má co zlepšovat, ale v tuto chvíli bych volil asi to)
• PHPUnit – kdo netestuje, nemůže o sobě tvrdit, že je profesionál (ne, o tom opravdu odmítám diskutovat).
• Mockista – zjednoduší nám mockování
• Googy – správné řešení práce s řetězci, poli, funkcionální programování pro PHP, implementuje celé Underscore.JS

Práce s databází

Tak tady jsem zatím naprosto bezradný. Žádná databázová vrstva v PHP mi nepřijde dobrá. Doctrine je pomalý, dibi, Nette\Database nebo NotORM moc low-level, Zend_Db_Table low-level a ještě špatně použitelný. Nejspíš budu nucen napsat si tenký Data Mapper nad Nette\Database.

HTML a CSS

• HTML5 Boilerplate 2 – osvědčil se nám na Tripomatiku, oceňuju hlavně detekci podporovaných vlastností z HTML5
• BlueprintCSS – enormně zrychlí prototypování, od té doby, co ho používám, neměl jsem v IE problém s rozpadajícím se layoutem. Díky Blueprintu udělám za 5 minut třináctisloupcový layout.
• Less.JS – Less dělá z CSS kulervoucí jazyk (proměnné, mixiny, výpočty). Navíc umožňuje používat BlueprintCSS sémantickým způsobem (namixuju si nesémantické classy do svých přímo v cssku a do HTML už dávám jen sémantické classy a ID) – tím pádem umožní i responsive design.

Javascript

• CoffeeScript – Cčková syntaxe je v případě JavaScriptu opruz. Ten jazyk je objektový a funkcionální (což jste mohli vidět u Crockforda na Webexpu). Coffee objektovou i funkcionální část z JavaScriptové syntaxe vytahuje velmi viditelně. Zdrojový kód je podstatně čitelnější.
• jQuery – pořád ještě framework číslo 1 pro práci s DOMem. Musí se s ním ale opatrně.
• Angular.JS – v mnoha situacích je jeho použítí vhodné, já na druhou stranu budu psát web, který musí jet i bez Javascriptu, takže Angularu tam moc nebude
• Underscore.JS – funkcionální programování ještě funkcionálnější a podporované napříč prohlížeči, jo!

Management

• Scrum – během let jsem si zkusil všechny role ve Scrumu a systém jako takový mi přijde docela přirozený
• Getting Real – postup z knížky Getting Real není sice obvykle popisován jako agilní metodika, ale když se na to podíváte pořádně, zjistíte, že se o agilní přístup jedná.
• Pivotal Tracker – tento software mi maximálně vyhovuje a stojí za ním solidní firma

Dnešní doba nabízí spoustu nástrojů, které programování posouvají kupředu. Které nástroje používáte vy a nedokážete si už bez nich představit život?

Jak Mockista funguje?

Můžete si snadno nadefinovat nějaké chování

$mock = Mockista\mock();

// můžu přiřazovat atributy
$mock->a = 11;

// můžu definovat chování metod (určím parametry a návratovou hodnotu)
$mock->add(1, 1)->andReturn(2);
$mock->add(2, 2)->andReturn(4);

// můžu určit, že pro dané parametry se vyhodí výjimka
$mock->divide(3, 0)->andThrow(new Exception("Division by zero", 0));

// pokud neuvedu žádné parametry, je dané zavolání defaultní
// a můžu používat callback pro generování výsledku
$mock->multiply()->andCallback(function($a, $b) { return $a * $b; });

// pak zmrazím mock
$mock->freeze();

// a začnu ho používat jako libovolný objekt
echo $mock->a; // 11;
echo $mock->add(1, 1); // 2
echo $mock->add(2, 2); // 4
echo $mock->divide(3, 0); // vyhodi vyjimku
echo $mock->multiply(3, 3); // 9

Co umí Mockista ještě?

Umí kontrolovat, kolikrát byla metoda zavolána:

$mock = Mockista\mock();
$mock->fce()->never(); // nikdy nebude zavolána
$mock->fce()->once(); // jednou
$mock->fce()->twice(); // dvakrát
$mock->fce()->exactly(4); // přesně čtyřikrát
$mock->fce()->atLeastOnce(); // aspoň jednou
$mock->fce()->atLeast(3); // aspoň třikrát
$mock->fce()->noMoreThanOnce(); // ne víc než jednou
$mock->fce()->noMoreThan(3); // ne víc než třikrát
$mock->collect(); // zkontroluje a pokud se očekávání nenaplní, vyhodí výjimku

Přidal jsem zkratku pro přidávání atributů a metod:

$mock = Mockista\mock(array("x"=>1, "y"=>function($x){return $x * 2;}));
$mock->freeze();
$mock->x; // 1
$mock->y(2); // 4

Mockista je k dispozici pod licencí: "Dělejte si s tím, co chcete. Já za nic neručím." (neboli BSD licence)

Verzi 1 si můžete stáhnout z bitbucketu.

Instalace je jednoduchá. Potřebujete pouze require dvou souborů:

require_once "MockistaInterface.php";
require_once "Mockista.php";

A co je v plánu?

1. Mockista by měl možná umět vytvořit mock z třídy i objektu a měnit chování jen tam, kde je to potřeba. Tuto vlastnost ještě zvažuji. Implementace takové funkcionality je v PHP docela špatná, nejde bez evalu, je tedy možné, že bude implementovaná jen omezeně.
2. freeze() a collect() jsou teď zabrané pro potřeby Mockista. V budoucnu by měly vracet MockMethod a tedy umožnit i definici chování stejnojmenných metod v mockované metodě.
3. Taky by měl umět testovat, v jakém pořadí byly metody zavolány.
4. Rád bych mockistu zaintegroval do PHPUnitu (pořáde nebude ale PHPUnit vyžadovat), aby nebylo nutné volat collect()
5. Chtěl bych se zbavit závislosti na freeze(). Nápady?

Slajdy se dělí do čtyř skupin:

1. ty naprosto strašné – to jsou většinou slajdy na vysokých školách. Desítky slajdů s 10 odrážkami. Na každé odrážce věta. Přednášející pak čte slajdy a ve skutečnosti by snad ani nemusel na místě být. Takové slajdy jsou dobré akorát na přípravu na zkoušku.
2. lepší, byť s odrážkami – přednášející už někdy slyšel o určité uměřenosti. Tak začal dělat slajdy se 3–4 velmi obecnými odrážkami. I já jsem dlouho takový byl. Problém je v tom, že takové slajdy jsou publiku naprosto k ničemu a hodí se přednášejícímu k tomu, aby měl osnovu spíš pro sebe. Soudím, že kdyby přednášející svůj notebook vůbec nezapojil do projektoru, takové slajdy by publiku neubraly ani na informacích, ani na zábavnosti přednášky.
3. lepší, s obrázky – takové slajdy se vyrábí následovně. Napíšete si, o čem budete přednášet. A pak ke každému tématu vygooglíte obrázek a ten do slajdů dáte místo textu. A pak tam občas přilepíte 1–2 slova (velikostí ideálně 300 pixelů, ultra ultra ultra bold). Problém těchto slajdů je v tom, že je VELMI těžké najít skutečně trefný a vtipný obrázek. A člověk hledá, hledá a nakonec nároky a soudnost klesnou natolik, že tam vlepí něco, co je aspoň trošku analogické. Takže když je něco „jako v pohodě“, tak tam bude opálený model na pláži. Když je něco „ekonomicky úspěšné“, uvidíte smějícího se tmavovlasého modrookého modela v modré nebo bílé košili u počítače. Když jde o „komunikaci“, tak tam vedle toho frajera bude ještě kočka v kostýmku se zuby bělejšími než antiperle. Když je něco divné, tak tam bude buďto nějaká šílená rasa psa (bulldog, baset…) čumící nakřivo do objektivu. Případně ten frajer z kanceláře, jenže místo smíchu jako křičí.
4. jiné, lepší slajdy, o ty se snažím já.

Pochopil jsem, že když chci slajdy, které budou bavit, budou relevantní, budou prezentaci doplňovat a nevyužijou žádná šílená klišé, musím si je vyrábět sám.

Při přípravě prezentace na Internet Developer Fórum jsem na to přišel. Vzal jsem papíry a udělal jsem něco, co bych nazval vizuálním scénářem. Vycházel jsem z toho, o čem budu mluvit. Už tehdy jsem přišel na základní princip:

Najdi nejlepší způsob, jak prezentovat svou prezentaci graficky a osekej použité nástroje na kost.

Platí následující: zvol témata z vizuálního scénáře a minimalizuj počet prostředků, které potřebuješ k jejich realizaci. Na IDF mi stačily papíry, pastelky a mísa s vodou. A samozřejmě zrcadlovka mající objektiv s velkou světelností, bez toho by to nešlo.

Slajdy z IDF najdete tu

Další konference na holení bylo letošní Webexpo. Stačil mi popisovač a větší formát Moleskine (typ na akvarel). A opět vizuální scénář. Pozvolna jsem skládal svou prezentaci. Zhruba polovina kreseb se do slajdů nedostala. Kvalitu čehokoliv, co děláme, je možné zvýšit tím, že si dáme určitou kvalitativní rovinu a vše pod ní vyhodíme. Skoro polovinu svých článků nikdy nezveřejním. A stejně tak slajdy na Webexpo byly vizuálním pomocníkem, který měl umožnit mým návštěvníkům to, aby se zároveň dozvěděli co nejvíc, ale zároveň nebyli zahlceni a prezentaci si užili.

Slajdy z Webexpa najdete tady

A je tu Barcamp, kde jsem povídal o Cargo Scrumu. Můj vizuální scénář opět nesmí chybět. Obsahuje prvky, které jsem chtěl zobrazit, obsahuje pořadí a taky to, jak dlouho se bude nějaký slajd zobrazovat. Tentokrát jsem svou prezentaci osekal na pouhých 8 slajdů. 75 procent prezentace se navíc na slajdech budou zobrazovat jen číslice 5 a 12. Trošku netradičně jsem použil výkresy, voskovky, nůžky a propisku, jako vždy zrcadlovku, oblečení z Egypta a sama sebe.

Slajdy jsou plné nedokonalostí a to je na nich nejlepší. Kdybych chtěl dokonalé efekty, dokonalé stíny, dokonalé cokoliv, vyrobil bych slajdy celé v počítači.

Všech 8 slajdů má svou logiku (která vyplývá z mé osobní osnovy a vizuálního scénáře).

Prezentaci z Barcampu najdete tady.

Vysvětlení následuje:

1. nápis Scrum – se zobrazovala celou dobu, než prezentace začla, v průběhu toho, než se představím a přijde čas na osnovu. Pomáhá to lidem, kteří vchází do přednáškové místnosti poznat, že jsou na správné prezentaci, případně že mají rovnou odejít, pokud je téma nezajímá.
2. osnova – jediné odrážky v mé prezentaci. Osnovy jsou velmi důležité. Zajedna díky nim dostanou šanci ještě včas odejít ti, kteří by marně čekali na něco pro ně relevantního (50 dobře zacílených návštěvníků je mnohem lepší, než 50 zacílených a 50 nudících se, kteří si u toho vykládají a nudí se a ruší ostatní). Zadruhé je to pravá chvíle lidem říci, že nemusí nic opisovat, že na konci bude odkaz, kde si můžou všechna zmiňovaná fakta stáhnout i se zdroji, z kterých jsem čerpal.

3–5) Jsou to slajdy, kdy jsem si dovolil smysl pro humor a je v nich úvod do tématiky (jediný text, který jsem použil, je odkaz na agilní manifest, další 2 slajdy jsou fotografie, na jedné z nich jsem já jako arab, žádný model na pláži nebo před monitorem). Význam je v tom, že Agile je občas špatně vnímáno jako nějaké nábozřenství. Že do firmy přijde konzultant a ten to tam zavádí jak nějaké rituály a to je špatně. Že je důležité pochopit principy agile obecně.

6. nápis 5 – protože jsem povídal o 5 základních benefitech a zároveň pravidlech, které agile (a Scrum zároveň) nabízí.
7. nápis 12 – protože jsem povídal o 12 velmi častých chybách, které se udělají snadno a podnik díky nim brutálně pohnojí implementaci Agile a Scrumu.
8. odkaz na můj web – každá prezentace musí končit jednou věcí. Co chci, abyste udělali teď. Pokud vás lámu ke sportu, dám odkaz na vyhledavač sportovišť. Pokud chci, abyste si koupili knížku, odkážu vás na stránku té knihy na Amazonu. Na Webexpo jsem připravil speciální stránku ukazka.knesl.com, na které jsem připravil účastníkům prezentace seznam všech zdrojů, z kterých čerpám. Já tam dal odkaz na svůj web a svůj Twitter, protože o agile pravidelně píšu. Na svůj web dávám odkaz, protože je tam možnost přidat si RSS. Na svůj Twitter proto, že všechny mé články linkuju i tam.

Možná vás zajímá téma vizuálního scénáře. Vzniká takto:

• vezmu témata, o kterých budu mluvit.
• vymyslím, co na slajdech bude. Vždy se snažím sloučit více témat do jednoho slajdu.
• napíšu si, jak dlouho budu mluvit a jak dlouho bude slajd svítit

Čím delší dobu mi říká, že někdo bude na slajd koukat, tím musí být jednodušší. Číslici 5 a 12 si nikdo nebude dlouho prohlížet – narozdíl od palem na pláži nebo nějaké modelky, která navíc vypadá mnohem líp než já. A tak budu mít náležitou pozornost, můžu mezi jednotlivými body témata přeskakovat, jak se mi hodí a nemusím vůbec myslet na prohazování slajdů. Je to pro všechny zúčastněné praktické.

Níže následují fotky z přípravy slajdů:





 

Měl jsem problém nastartovat 4. pomodoro ten den. Jednoduše už se mi nechtělo tu minutku natáhnout a tak jsem se nedonutil. Tak jsem se rozhodl, že aspoň ta pomodora natáhnu. A zjistil jsem, že 45 minut práce, 15 minut přestávka mi naprosto vyhovuje.

Původní motiv se po čase rozplynul, teď kolikrát funguju i mimo pomodoro (mám 2 další způsoby, jeden jsem získal jinde, druhý jsem si vynalezl a fungují mi minimálně stejně dobře). Přesto 45 minutová pomodora preferuju před 25 minutovými.

Bylo to povahou mých úkolů, které byly spíš 35–40 minutové a já často po 25 minutách přetahoval do přestávky, abych ten úkol dokončil. Pětiminutové přestávky jsou jednoznačně nedostatečné – zvlášť pokud děláte obtížnou práci. Tam rozhodně 15 minut každou hodinu člověk ocení.

Má to i své zápory. Hlavně člověk třeba stihne během té doby 3–4 úkoly a ztrácí možnost dělat si z pomodor nějakou analytiku. 1 pomodoro, které má 45 minut, to je ohromné kvantum práce (minimálně v IT) a tak je potřeba přidat si další nástroj, kterým člověk poznává svou produktivitu.

Já jsem to vyřešil tím, že jsem několik dní sledoval, jak vlastně pracuju a co dělám. A s tím jsem potom nějakým způsobem operoval a dělal si statistiky.

Takže jaké je dnešní zadání?

V jedné metodě udržujte jednu úroveň abstrakce.

Co to znamená?

Každý kód je jinak abstraktní.

Nejspíš se shodnem, že v této metodě se úrovně abstrakce střídají:

$data = $this->model->fetchData(); // 1.
$encoder = new JsonEncoder; // 2.
file_put_contents(WWW_DIR . '/exports/export.json', $encoder->encode($data)); // 3.

První řádka je velmi obecná. Nějaký model vytahuje nějaká data.

Druhá řádka je konkrétnější, protože říká, jaký konkrétní encoder bude použit. Místo ní by byla řádka

$encoder = $this->getEncoder();
// nebo
$encoder = EncoderFactory::getEncoderFor(EncoderFactory::EXPORT_TO_FILE);

Třetí řádka je nejkonkrétnější, nejspíš bude místo ní volání:

$this->exportData($data)

A metoda exportData si získá path pomocí metody getPath (takže v první metodě už bude jen 1. a 3. řádka - 3. řádka změněná), teprve ona si nechá vytvořit encoder a v metodě writeDataToFile zapíše data na disk.

function exportData($data)
{
        $encoder = EncoderFactory::getEncoderFor(EncoderFactory::EXPORT_TO_FILE);
        $this->writeToFile($this->getPath(), $encoder->encodeData($data);
}

function writeToFile($path, $data)
{
        if (file_exists($path) && ! is_writable($path)) {
                throw new FileSystemException("Unable to write to path: $path");
        }
        file_put_contents($path, $data);
}

Získáme tím kód, ve kterém máme úrovně abstrakce rozdělené natolik, že se samo od sebe vynoří, jak a kam máme přidávat nové funkcionality. Ještě jednou připomínám, že dva lidé uvidí vždy v kódu úrovně abstrakce trošku jinak a je nutné neustále trénovat.

Dnešní cvičení číslo 3 je:

Určete a znejte vždy typ dat v proměnné.

Uvnitř proměnné musí být právě jeden typ a nebo null. Nikdy se nesmí stát, že by v proměnné byl „int“ nebo „string“. Pokud v proměnné držíte nějaký objekt – byť bude instancí různých tříd – musí implementovat rozhraní, podle kterého s ním budete pracovat. Pokud se objekt předává zvnějšku, rozhraní otestujte pomocí type hintingu (existuje-li odpovídající rozhraní pro daný use-case). Typ proměnné se nesmí za běhu metody změnit.

Co získáte tímto cvičením?

Lépe porozumíte svému programu. Můžete vždy zjistit, jak se bude implicitně přetypovávat. Zabráníte některým bezpečnostním chybám.

Cvičení číslo 4 je:

Všechny primitivní lokální proměnné musí být immutable. To znamená, že smí být přiřazení práve jednou. Povolená výjimka je buffer, do kterého skládáte výsledek (ať už pole nebo řetězec).

Pokaždé, když potřebujete udělat nějakou modifikaci, nikam nic nepřiřazujte a rovnou volání funkce vložte jako parametr funkce nebo si založte novou proměnnou.

Jaké chybě tím zabráníte?

Představte si dlouhou metodu (což by se nemělo dít, ale budiž):

$promenna = funkce();
// 50 radek kodu
$promenna = funkce($promenna);
// 50 radek kodu
$promenna = funkce($promenna);
// 50 radek kodu
$promenna = funkce($promenna);

Zde může dojít k té chybě, že u jedné proměnné nebudete vědět, v jakém už je stavu. Místo toho použijete postup, kdy si vždy vytvoříte novou proměnnou.

$promenna = funkce();
// 50 radek kodu
$promennaOtrimovana = funkce($promenna);
// 50 radek kodu
$promennaRozsplitovana = funkce($promennaOtrimovana);
// 50 radek kodu
$promennaZnovuSpojena = funkce($promennaRozsplitovana);

Váš kód bude mnohem čitelnější, donutí vás to zamyslet se nad tím, jak pojmenováváte své proměnné a označíte, co v nich je. I vaši kolegové snáze najdou v kódu významy jednotlivých proměnných.

Tak hurá do toho.

A jak to tedy dneska bude?

Maximální zanoření metody smí být o 2 úrovně (pokud je v metodě if, while, for, foreach, může obsahovat maximálně jednu další úroveň z výčtu). Pokud jste odvážní, snižte si limit na 1 úroveň (tedy je-li v metodě if, while, for, foreach, nesmí obsahovat žádný další if, while, for, foreach).

Použijte 3 způsoby:

Rozdělení do metod

Toto je preferovaná cesta. Jakmile se objeví další úroveň zanoření, udělejte místo ní metodu. Tento postup má plno výhod, ale hlavně vás donutí se zamyslet na významem toho, co se v daném kusu kódu děje. Když to pojmenujete v metodě (a zjednodušíte metodu, z které funkcionalitu trháte), nepotřebujete tolik komentářů.

Občas by se mohlo stát, že by vytržená metoda byla nesmyslná. Pak změňte architekturu metody. V jednom z dalších cvičení se naučíte, jak takovému riziku zabránit v zárodku. Nebo v nějaké smyčce si potřebujete ukládat ještě výsledky pro další výpočet, který proběhne později. I to jde řešit – obvykle atributy objektu.

Vnořené zařaďte za sebe

Není nic horšího, než tři vnořené foreache, které by mohly být za sebou. Srdce objektového puristy trpí při špatně použité dědičnosti, návrhu nebo použití návrhových vzorů. Nic z toho se ale nemusí dlouho projevit. Vložené smyčky jsou nechutní žrouti výkonu a počty prvků nemusí být až tak velké. Pokud existuje způsob, jak udělat M + N + O průchodů místo M * N * O, tak je udělejte.

Jakmile rozdělíte kód do více smyček, stejně zvažte, zda je nedáte do samostatných metod. Tím, že kus kódu dáte do metody, musíte ho pojmenovat. Jakmile něco pojmenujete, osvětlíte, co daný kus kódu dělá, s čím a co je výsledkem.

Zplacaťte kód pomocí převodu na funkcionální

Téměř všude, kde se dá použít foreach, for, while, se dá použít nějaká z array_* funkcí. Tento postup už ovládáte z cvičení 1. Převod na array_* funkce vám vytvoří samostatné closury. I tyto closury musí mít nějaké jméno. Co z toho vyplývá? Obdobné benefity, jako z rozdělení do metod (což byste v tomto případě měli taky rozhodně zvážit).

Good luck a zase dejte vědět, jak se vám zadařilo.

Já vám popíšu nějaký postup. Obvykle se bude jednat o žádoucí praktiku, takže by s tím neměl zaměstnavatel mít problém – navíc se jedná o tipy a triky, které nebudou vyžadovat čas navíc. Vy to zkusíte jeden den praktikovat a podělíte se, jak to šlo. Pokud se rozhodnete používat postup i nadále, tím lépe pro vás!

Takže zadání první.

Nepoužívejte for ani foreach tam, kde se v PHP dá použít array_map, array_filter, array_reduce nebo array_walk.

Co se naučíte?

Zmiňované funkce array_* vedou k některým návykům z funkcionálního programování. Jejich výhodou je sémantičnost. Jejich nevýhodou je, že se to musíte naučit číst (potom se vám už čtou lépe) – s tím mělo už hodně mých kolegů problém. Nicméně naučíte se funkcionálnější postup.

Po chvíli vám bude přístup:

$vysledek = array_map($modifikator, $vstup);

Připadat logičtější, než:

$vysledek = array();
foreach ($vstup as $rada) {
        $vysledek[] = $modifikator($rada);
}

Aby byl váš kód ještě čitelnější a sémantičtější, můžete použít můj nástroj Googy, který funkcionální programování v PHP v mnoha ohledech usnadňuje.

V Googym by takový kus zdrojáku vypadal:

use Googy as _;
$výsledek = _\Arr($vstup)->map($modifikatorMap)->toArray();
$výsledek = _\Arr($vstup)->filter($modifikatorFilter)->toArray();
$výsledek = _\Arr($vstup)->reduceLeft($modifikatorReduce)->toArray();

Array filter se dá redukovat na filter(). Array_walk funguje stejně pomocí map, jen přiřadíte do původní proměnné a array_reduce má obdobu v metodě reduceLeft.

Ale jak si udržet čerstvé nápady i kreativitu ikdyž se člověk v práci ustálí?

Zatím jsem si všiml, že je několik věcí, bez kterých to dlouhodobě nejde:

• dostatečně spát (stačí jen hodina nedostatku spánku a výkon, kreativita a příjemnost na lidi okolo jde rapidně dolů, naopak nadbytek spánku už nic nepřidává)
• odpočívat (když budu jen pracovat, nakonec udělám za dvojnásobek času stejnou práci, jako dřív za stejný čas)
• dobře jíst (tělo potřebuje spoustu energie, i myšlenková práce dokáže člověka vysílit a to rychleji, než by jeden čekal)
• mít dostatek pohybu

Dnes k tomu pohybu. Celý život jsem sportoval a když jsem šel na VŠ, nějak jsem s pohybem na několik let přestal. Mělo to strašné následky, na můj tlak, na mou postavu, ale i na to, jak dobře jsem se uměl soustředit a jestli jsem dokázal fungovat kreativněji. Neudělat se sebou nic, asi bych v 50 dostal cukrovku, v 60 infarkt a v 70 bych byl na vozíku.

Když jsem se vrátil ke sportu, rozhodl jsem se mu dát aspoň 6 hodin týdně a staly se skvělé věci. Zkoušel jsem i míň, ale nefungovalo to. Vyrazit na kolo na 3 hodiny o víkendu nemá ten efekt. Chce to třikrát týdně aspoň 2 hodiny (ikdyž v reálu chodívám na 20–30 kilometrové pochody, které si těch 5 hodin vezmou v jednom dni, stejně se ještě dvakrát týdně aspoň 2 hodiny hýbu).

Jaké skvělé věci?

Mám učebnicově perfektní tlak.
Shodil jsem 7 kil během 2 měsíců.
Přestalo mi vadit spát jen 6 hodin, tělo se naučilo odpočívat rychleji.
Staly se neuvěřitelné věci s mou kreativitou.

A teď k tomu programování.

Když se hýbu, mozek stejně na pozadí pracuje. Kolikrát problém, který se mi nedaří rozlousknout, zlomím po sportu. Když mám úkol, do kterého se mi extrémně nechce, stačí si dát 50 kliků, člověk se napumpuje a start těžkého úkolu je daleko snažší. Když začnu místo programování prokrastinovat a nechce se mi dělat nic užitečného, jdu aspoň ven, vyběhnu si schody, nepracuju pořád, ale aspoň to netrávím shrbený u počítače. Když dělám 45 minutová pomodora, z 15 minutové pauzy se snažím aspoň půlku času dělat strečing. Pak se k programování vrátím s pocitem sprintera na startu (vážně) a dalších 45 minut rychle uteče v závodní atmosféře.

Sport mi ohromně pomáhá a pomáhal by mi, ikdybych dělal jakoukoliv jinou myšlenkovou práci.

Je hloupé mít vizi: „Chceme být předním poskytovatelem vzdělávacích aktivit ve střední Evropě. Své vize dosáhneme dynamickým vývojem, zapojením zákazníka a tvrdou prací. Chceme zůstat mladí, flexibilní a připravení reagovat na turbulentní trh a stále nové technologie.“ To je vize, kterou si můžete vylepit možná tak na záchod a nad tím patosem slintat. Je to vize, kterou se v podniku nikdo nebude řídit, nebude si ji pamatovat a ikdyž bude, ne dobrovolně.

Mou vizí je dělat taková školení, kde se lidé dozví mnoho velmi užitečných věcí a co nejvíce si z toho zapamatují. Má vize mě drží pevně na zemi a je spojena s realitou. Těžko přijde student a řekne: „Rád bych se naučil něco neužitečného“, „rád bych toho uměl méně“ a nebo dokonce: „kéž bych toho víc zapomenul!“.

Z realistické vize se dají dělat realistické cíle a realistické cíle se dají přetavit do realistických projektů. Realistické projekty se dají … zrealizovat!

Vzletné fráze skvěle zní a dobře se vyjímají vedle stejně honosného firemního sloganu. Ale nic neříkají. Neříkají nic zákazníkovi a co je horší, neřeknou nic vlastním lidem. Kdy jednám dynamicky? A kdy pracuju tvrdě? A musím snad školit každou novou technologii?

Ano, vize je obecnější než cíle podniku. Ale nesmí žít ve svém vlastním světě. Být první může být v jednom oboru jeden. Realita, ve které bude sto firem „největší stavební firmou v Česku“ je nemožná. Lepší vize by byla: „troufneme si postavit to, na co ostatní už nemají“. Má kuráž, hodně vypovídá o tom, jak se budou lidé ve firmě chovat a hodně říká o tom, že se atypické projekty oceňují.

Zvláštní situace platí pro začínající podniky. Tam je vize: „stát se největším…“ naprosto mimo mísu. Mladá firma vstupuje na trh, kde je vybudovaný ekosystém věrných dodavatelů, věrných zákazníků, fungující konkurence a rostoucích nároků trhu. Vize se vyvíjí a pokaždé, když se změní podmínky na trhu, může to vyžadovat revizi vize podniku. Od mladého podniku bych čekal vyjádření ve stylu: „Jsme jiní, nebudeme otravovat zákazníky vlastní byrokracií, ať budeme jakkoliv velicí. Děláme XYZ a děláme to lépe než konkurence. Naše XYZ se nerozbíjí, stojí únosnou cenu a skvěle vypadá. Zakládáme si na tom, že naše XYZ se skvěle používá. Zvedli jsme laťku a hodláme v tom pokračovat.“

Naučil jsem se během víkendu najít si 2 hodinové bloky (obvykle kolem 9–10. hod. a kolem 15–16. hod., to bude u každého dost individuální). Během té doby paradoxně odpočívám prací, protože se snažím každý víkend hodně sportovat, nebo jít aspoň na dvacetikilometrový výšlap a možnost pracovat intelektuálně se výborně střídá s fyzickou námahou.

Za ty 2 hodiny udělám ohromné kvantum práce. Kdybych pracoval 5 hodin běžným způsobem, bylo by to srovnatelné. Co tím získávám? Jeden den práce navíc, ale bez toho, abych musel někde být celý den. Když vím, že mě čeká jen hodina práce, pustím se kolikrát i do úkolů, které jsem dlouhodobě odkládal (ten pocit, když zjistím, že stačilo 20 minut práce a projekt se posunul kupředu!).

S jedním dnem práce se dá dělat plno věcí:

• nepracovat jeden den v týdnu
• posunout projekty dopředu o 20 procent rychleji
• rozvolnit generování hodnoty
• překvapit ostatní tím, že v pondělí je už hotová práce na jeden den a všechno se bude lépe stíhat

Osobně si myslím, že model 5/8 je reliktem průmyslové revoluce, kde se pracovalo 6/12 a někdy i hůř. Tehdy si lidi říkali: „Pracovat tak 8 hodin 5 dní v týdnu!“ Ale doba se ohromně změnila, produktivita práce je dnes daleko vyšší a dnes by si mohli říkat: „Pracovat tak 3–4 dny v týdnu 6 hodin!“ A nebo: „Pracovat tak 3 hodinky denně a když budu potřebovat, vzít si volno!“

Zkuste sami experiment a sledujte své činnosti po minutách. Zkuste to alespoň týden a v pracovní době. Zjistěte, kolik času skutečně tvoříte hodnotu pro zákazníka. Třeba budete překvapeni, že můžete půlku pracovní doby odhodit a přidáním 4 hodin o víkendu ve skutečnosti uděláte víc než kdy dřív.

Běžný postup programátora, který používá kvalitní verzovací software, je:

1. převezmu si úkol
2. zajistím si potřebné údaje
3. vytvořím feature branch
4. v branchi vyřeším úkol
5. branch spojím do development větve a pošlu věc na akceptaci
6. pokud projde, pošlu branch do stable větve, která jde na deployment

Tento přístup je skvělý, ale nedokáže se vyrovnat s několika problémy:

• dílo v branchi vyžaduje nekolizní editace (věc, která se předělává, se nesmí editovat v jiné větvi)
• pokud je branch dlouhodobý, tak se tým dozví, jak se povedlo integrovat řešení až opožděně (třeba i jiný den – problém se typicky vynoří, když kolega zmerguje svou práci za celý den a odejde na dovolenou a nechá vzniklé problémy jiným)
• v případě opravdu velmi dlouhodobých změn (předělání architektury na celé týdny), dochází obvykle k tomu, že tým není schopen celé týdny udělat release

Branch by Abstraction problém řeší naprosto odlišným způsobem.

Programátor postupuje takto:

1. převezmu si úkol
2. zajistím si potřebné údaje
3. zjistím, v čem se liší můj úkol od stávajícího stavu a kde budu systém editovat
4. všude tam, kde budu editovat současný kód, postavím abstraktní vrstvu na tím, co se bude měnit a přenesu do ní stávající implementaci
5. naprogramuji novou implementaci splňující shodné rozhraní jako další adaptér
6. přepnu abstrakci všude tam, kde mám práci hotovou a postupně přidávám místa s novou logikou
7. až jsem přepsal všechny části systému, znovu odstraním abstraktní vrstvu a starý kus abstrakce zahodím (chci-li)

Zejména u dlouhodobých změn jsem získal možnost dělat průběžně releasy s kousky nové logiky. Pracuju v hlavním branchi a všichni vidí, jak abstrakce přibývá a když chcou v kusu kódu udělat úpravu, už ji dělají uvnitř abstraktní vrstvy, které se zatím používá.

Tento postup je poměrně složitý na pochopení, často se můžou do abstrakce vytrhávat způsobem, který je dost nezvyklý. Proto jej zatím nepoužívám (a jsem spokojený s feature branche). U dlouhodobých změn na projektu bych každopádně nad Branch by Abstraction docela silně zauvažoval.

Více článků k tématu:

• Paul Hammant – Branch by Abstraction
• Jez Humble – Make Large Scale Changes Incrementally with Branch By Abstraction

Co to je? K čemu? A jak na něj?

Continuous Deployment je proces, při kterém dochází k automatizovanému nahrávání nové verze na server krátce poté, co je vlastnost prohlášena za připravenou k produkci. Podnik tím extrémně zrychlí odezvu zákazníků, ví tedy mnohem přesněji, že to, co vytváří, dělá zákazníky spokojenými.

Aby mohl CD fungovat, vyžaduje od firmy několik specifik:

• automatizované testy
• distribuovaný verzovací software
• extrémně zrychlená akceptace nově naprogramovaných vlastností
• deployment trvá maximálně pár minut

Automatizované testy garantují, že kód dělá, co dělat má. Alespoň v tom, na co jsou napsané testy. Jak produkt roste, není možné otestovat ručně všechny jeho vlastnosti. Pokud se deployment provádí třeba desetkrát denně, není to možné už vůbec. A proto jsou nutné automatizované tes­ty.

Distribuovaný verzovací software (např. Mercurial nebo Git) umožňuje velké množství workflow, které výborně zapadají do CD. Typický je například vývoj nových vlastností v branchi a při akceptaci vlastnosti dojde k automatizovanému spojení větvě nové vlastnosti do stabilní větve a následně automatizovanému deploymentu.

Aby byly vlastnosti co nejrychleji doručeny, musí se kolečko akceptace a úprav maximálně zrychlit a zkrátit, aby se vlastnost dostala bleskově na produkci. O zrychlení akceptace se obvykle bavím i na svém školení testování, tato praktika má mnoho dalších následků (snížení počtu chyb, zvýšení produktivity…).

Deployment nesmí vyžadovat několikahodinový proces (jako je generování AMI v případě deploymentu do Amazonu EC2). Naopak – je nutné mít reakční dobu v řádu maximálně minut. Proč? Umíte si představit to peklo, že nahrajete rozbitou verzi a musíte počkat několik hodin, než nahrajete opravenou verzi?

Obvykle není triviální vytvořit automatizovaný deployment sám o sobě. Přechod na CD je ještě mnohem složitější, musí se dodatečně pokrýt testy celá aplikace, musí se upravit firemní procesy, infrastruktura a často i změnit verzovací systém. Následkem je ale podnik s pružnější reakční dobou, než má konkurence.

Jak děláte deployment vy?

Framework samotný nabízí spoustu pokročilých vlastností (Dependency Injection, podpora pro testování), které tady zamlčím. Chtěl bych vám místo toho ukázat tři jeho vlastnosti, které považuji za důležité v situaci, kdy s Angular.JS začínáte.

Instalace

Instalace je primitivně snadná, do HTML přidáte namespace, vložíte javascript a je to.

<html xmlns:ng="http://angularjs.org">
 <script src="http://code.angularjs.org/0.9.15/angular-0.9.15.min.js"
   ng:autobind></script>

MVC

MVC i v Javascriptu? Ano, dává to smysl, protože aplikace v JS neustále rostou a v určitou chvíli hrozí, že se zodpovědnosti rozdělí zle. V Angularu píšete pomocí MVC. Šablona je blok HTML (obvykle stránka, do které Angular vkládáte, ale stejně tak se dá použít do widgetů v OS X nebo Windows 8). Controller je javascriptový objekt. Model může být další objekt, ale stejně dobře se dá použít jen pole, které je atributem controlleru.

Navázání je jednoduché, zde ho provádím na body, šel by i na jakýkoliv jiný uzel DOMu.

<body ng:controller="MyController">

Jakýkoliv atribut, který se v controlleru objeví v this, je automaticky přístupný v šabloně. Chci-li tedy vložit data do šablony, udělám to v Coffeescriptu následovně:

class MyController
        items: [{name: 'a'}, {name: 'b'}, {name: 'c'}]

V šabloně (která nápadně připomíná Latte v Nette, až se člověk ptá, zda se neinspirovali) se potom položky vypíšou pomocí namespace ng.

<ul ng:for="item in items">
        <li>{{ item }}
</ul>

Obdobně mám-li nějaké tlačítko nebo odkaz v šabloně, můžu snadno nabindovat událost onclick.

<ul ng:for="item in items">
        <li ng:click="clickedLi(item)">{{ item }}
</ul>

V controlleru se potom zavolá daná metoda clickedLi:

class MyController
        items: [{name: 'a'}, {name: 'b'}, {name: 'c'}]

        clickedLi: (item) ->
                alert item.name

Two-way data binding

Další naprosto skvělá vlastnost je, že změny na obou stranách se automaticky promítnou v controlleru i šabloně.

<input name="alb">

class MyController
        alb: "idx"

Input se vykreslí s hodnotou "idx". Ve chvíli, kdy někdo změní hodnotu v daném inputu, změní se i hodnota v controlleru. Pokud si například natáhnu data AJAXem (Angular můžete používat dál s frameworky, na které jste zvyklí, jako jQuery, Dojo atd.) a změním je, změna se promítne i v šabloně.

class MyController
        items: [{name: 'a'}, {name: 'b'}, {name: 'c'}]

        constructor: (@$xhr) ->
                setTimeout @loadData, 10000

        loadData: ->
                @$xhr "GET", "http://example.com" , (code, response) =>
                        @items = response

HomepageController.$inject = ['$xhr']

Zde jsem si do this.modules stáhl pomocí objektu $xhr, který je dodáván do Angularu data. Ikdyž jsem měl nějaká data zobrazená, po 10 vteřinách se zobrazí data získaná AJAXem, jakmile spustí closura v setTimeout.

Poslední řádka je už použití Dependency Injection a mimo záběr tohoto článku.

Díky Angularu jsem začátek vývoje vysloveně nakopnul a už během pár hodin jsem měl svůj prototyp rozpohybovaný daty ze serveru a reagující na kliknutí tak, jak si to představuju.

Ve výsledku firmě produktivita vůbec nevyroste, naopak přibude byrokracie a všichni si ťukají na čelo, co je ten Scrum za blbost. V podniku se nenasadil Scrum, ale Cargo Scrum, napodobování úspěšných postupů neúspěšným způsobem.

Problém je často v tom, že naučit se být agilní neznamená dělat rituály, ale změnit své vnímání. Ale i, že podnik si pro své potřeby ohne agile v tom, v čem se agile ohýbat nemůže a okopíruje to, co by se naopak mělo udělat podniku na míru. Víc se potom praktikuje náboženství, než manažerský postup.

Za dobu, co dělám agile, jsem si zkusil být součástí týmu, být Scrum Masterem (koordinátor agile v týmu), Product Ownerem (manažer, který určuje priority) a agilním koučem. V různých týmech a různě velkých podnicích. A tak jsem byl mnohokrát svědkem „temných údolí“, kde se může implementace agilních metodik úplně zkazit.

Vy, kdo jdete na Barcamp v Brně, přijďte si mě poslechnout na mou přednášku Cargo Scrum. Aby bylo jistější, že se do programu dostane, budu vděčný za váš hlas.

Týká se vás tentýž problém? Scrum nepřinesl slibované výsledky? Napište mi e-mail (jiri.knesl@gmail.com) a já vám pomůžu zařadit vyšší rychlost.

Letos jsem chodil na přednášky víc, než kdykoliv předtím.

Jak se mi líbily?

• HTML5 WorkShop od Štěpána Bechynského byl skvěle připravený. Od začátku, který byl na mě až moc obecný (nevěřím, že v tomto roce ještě nikdo neslyšel o tom, co je vlastně HTML 5) se postupně propracoval k popisu technologií. Úspěšně nás varoval, že máme být opatrní při používání různých API, protože jsou stále nestabilní. Co se mi líbilo nejvíc, že jsmě během workshopu viděli spoustu zdrojáků, které navíc byly opravdu zajímavé (benchmarky, převádění videa do canvasu a převod do černobílé, práce s GPS, hledání lokace podle wifi a plno dalších věcí). Hodnotím skvěle a doufám, že Microsoftu dělá víc takových lidí.
• Jak správně nastavit cenu webových aplikací od Václava Lorence. Zajímavé povídání, které naplnilo přednáškovou místnost. Bylo spojené s povídáním o TopMonks (u této služby pořád moc nechápu, proč není víc propagovaná), o tom, jak se cenové politiky vyvíjely a jak co se bude dít dál. Osobně musím říct, že o pricingu mi tato přednáška neřekla skoro nic – minimálně pokud už člověk čte blog Pricing Idiot.
• Architektura škálovatelných aplikací – tuto přednášku jsem slyšel při přípravě řečníků od Jeanne Trojan a jediné, co dokážu říct je, že v two bits děláme škálovatelnost naprosto odlišně. Dá se říct, že škálovatelnost na vlastních serverech se hodně liší. Hlavní je mít rychlé (ideálně SSD) disky a celý problém se o dlouho odsune!
• Deployment prakticky – Láďa pracuje ve firmě, která má asi 5 různých prostředí. Logicky i jejich deployment je tím pádem hodně komplikovaný. Myslím, že mi mnohem víc pomohlo potom povídání 1:1, protože v LMC mají situaci opravdu mnohem těžší, než v běžné firmě. Jsem rád, že zazněla zmínka o capistranu, které je vhodné i pro projekty měnší o dva řády. Tuto přednášku jsem slyšel taky při přípravě řečníků, takže nevím, jak moc ji Láďa vylepšil.
• Test Driven Development v CoffeeScriptu – toto mé povídání shrnulo syntaxi Coffee, psaní testů na klientské straně a Test Driven Development. Slajdy jsem kreslil ručně a za přednášku jsem dostal pár pochval a jednu kritiku. Zaměřil jsem se hlavně na evangelizaci toho, že má smysl testovat, má smysl dělat TDD a CoffeeScript není něco, čeho by se měl člověk obávat. Vzhledem k tomu, že někteří lidé se nedostali dovnitř a nikdo neodcházel, doufám, že se mi to povedlo. :-)
• Angular.JS od Vojty Jíny. Vojta pracuje v Google a je fanda TDD. Já sám používám Angular na dvou projektech a vím, že ten framework má ohromné benefity. Přesto jsem si všiml, že obsah přednášky hodně vyzdihoval věci, které člověk ocení až později (např. Dependency Injection), nedošlo na podrobný popis toho, co ocení každý hned (MVC, two-way data binding, instalace na 2 řádky kódu).
• Evoluce designera – na tuto přednášku jsem přišel až na samém konci a slyšel jsem jen poselství lidem. Adam Hrubý bude nejspíš skvělý přednášející a jak jsem si všiml na akci večer, je člověk s neotřelým vzhledem.
• Velikost myšlení – Lukáš Plíhal má zvláštní styl přednášení. Určitě se mi líbilo téma. Méně se mi líbilo, že trvalo půl přednášky, než se vůbec dostal k tématu. Na druhou stranu – když se Tomáš Hajzler s lidmi rozjel tak, že kreslili nohou a zpívalí – i tady mi to přišlo hodně interaktivní. Několik lidí Lukáše obejmulo, udělali společné foto. Přednáška řekla informačně asi desetinu toho, co mohla. To mi nevadí, bavilo mě to. Příště bych ale trávil míň času zády k publiku.
• Funkční grafický design – komunikovat nebo dekorovat? Od Lukáše Kostkana. Lukáš dělá bezesporu svou práci dobře a leccos jsem se dozvěděl o tom, jak moc musí vědět designer souvislostí. Bral bych ale živější přednes (třeba jako Michal Juhás ze startupu BookFan).
• MongoDB Lukáše jsem poznal na přípravě řečníků. Nevím, jak moc svou přednášku změnil, ale už na první pokus to bylo plno zajímavých informací, díky kterým vím, že Mongo nepoužiju na nic jiného než zapisování logů.
• Za hranicemi jQuery, Daniel Steigerwald – wow! Dan povídal o tom, co všechno člověk potřbebuje a hodí se mu, když dělá projekt o JavaScriptových 500 třídách. Navíc znovu povídal o Angular.JS. Myslím, že Dan hodně předběhl dobu v tom, co lidi v JS obvykle píšou.
• Servesideness, Douglas Crockford je Javascriptové eso. Ale přemýšlí a píše funkcionálně. A tím pádem si myslím, že přednáška byla pro většinu lidí nesrozumitelná. I já jsem se mnohokrát ocital v situaci, kdy jsem sice rozuměl syntaxi, ale nechápal jsem motiv.
• Prezentace OpenBrand.com přednášel Mirek Burkoň. Já osobně musím říct, že prezentace se utopila v termínech reklamek, který je pro většinu lidí naprosto nesrozumitelný.
• Představení startupu tripomatic.com – Lukáš a Bára z two bits prezentovali Tripomatic. Mě se povídání líbilo, vím ale, že Tripomatic toho umí mnohem víc a na tak krátkém prostoru je potřeba vypíchnout jen část. Lukáš a Bára na sebe v přednášce navazovali, za to jim dávám bod navíc, protože vím, jak je to těžké.
• Zkušenosti vítěze startup show 2010, Zdeněk Cendra povídal o tom, jak rozvíjí Bijk, jak se úplně minuli v tom, že běžný uživatel nebude chtít sledovat 7 serverů, ale 1. Jak je obtížné dělat marketing projektu, který mám konkurenci zdarma jako open source. Taky předvedl svůj nový projekt a další utajený P…..cz naznačil.
• Strategie kešování utopil Michal Špaček v dlouhém úvodu. I přednáška se odchýlila od tématu a místo strategie kešování se popsaly postupy kešování. Michal obvykle prezentuje obratněji, nejen já jsem si všiml, že nedělal vtipy.
• Scala – Wow! Zdeněk Farana na nácviku řečníků měl (troufnu si říct) nejhorší prezentaci ze všech. A od té doby ji ohromně zlepšil. Krásné slajdy, zajímavé povídání, vypustil některé šílené funkcionální konstrukty, pracoval s publikem, když ukazoval pattern matching přímo na lidech.
• Lean Product Development – Dan Martell povídal docela typicky o tom, jak fungují startupy a nejspíš si většinu věcí dočtete i jinde. Co se mi ale líbilo, když Dan začal povídat o svém bratrovi Pierrovi a o tom, že i při stavění domů můžete být „štíhlí“ a dělat pivoty. Pierre si uvědomil, že domy ve skutečnosti nekupují muži, ale ženy a upravil dům a zacílil reklamu na ně. Během roku zšestnáctinásobil poptávku.
• Finále startup show 2011 – 1 moderátor, 3 prezentace, 4 porotci. Povídání o Open Brands zase trpělo použitým slovníkem: „reklamštinou“. Chápu, že je obtížné mluvit o odborných problémech neodborným jazykem, ale tím člověk dost ztratí body. Potom šel Tripomatic. Lukáš a Bára v obměně ukázali svou předchozí přednášku a mnohem lépe zazněly cíle do budoucna. A na konec to nejzábavnější, Michal Juhás je energický řečník, skvělý bavič, který věří svému produktu. Občas to bylo navzdory argumentaci. Vtipem obracel dobře míněný dotaz na frašku. Publikum (i mě) to bavilo, Bookfan (který byl podle mě na 3. místo celou dobu) to ale nahoru nevytáhlo.
• Za kolik prodat svoji firmu – John Vanhara, Ondřej Raška, David Špinar a Tomáš Čupr povídali o tom, jak se prodává podnik. Ale i o tom, jak se buduje podnik pro prodej. Došlo i na investice do firem a v zásadě se dá říct, že ikdyž v publiku nejspíš něco takového zažijí 1–2 lidé, pro všechny ostatní je to minimálně pohled do sfér, které člověk neřeší. Šokující pro mě bylo třeba to, že když člověk prodává firmu, tak 3 měsíce v podstatě nemá čas v té firmě dělat management, rozvíjet ji, on na fulltime prodává podnik. Zdeněk Cendra jako moderátor nemusel lidi téměř pobízet a na dotazy publika se skoro nedostalo, pánové si povídali sami od sebe velmi dobře.

Abych to shrnul, Webexpo je konference číslo jedna v ČR a hranice mezi Webexpem a čímkoliv, co by se pokusilo vstoupit na trh, neustále roste. I přes nešťastnou komunikaci před Webexpem, akce samotná byla tak dobrá, že se už nemůžu dočkat dalšího ročníku.

K tomu úspěchu vedla spousta faktorů.

• dobře dělaný Scrum – velká spousta firem si představuje Scrum jako nějaký kouzelný rituál, který bez práce zdvojnásobí produktivitu. Musím říct, že v two bits tohle neplatí. Scrum se tady opravdu povedl.
• skvělý tým – mám pocit, že ikdyž jsem dělal Scrum Mastera, daleko větší podíl má Michal, Rosťa, Petr, Vladimír a další kolegové, kteří pomohli Tripomatic vyvinout, naplnit daty, odhalit chyby a hlavně, dávat mu směr.
• skvělí majitelé – Lukáš a Bára jsou nejlepší šéfové, jaké jsem v životě poznal. Vzdělaní, demokratiční a ohromně milí lidé. Umožnili celý tento projekt a osobně můžu říct, že když se podívám na to, kolik dat jsme už předtím měli o letištích, městech, letech a uživatelích, všechno k tomu postupně směřovalo a oni to uviděli dobře a včas.
• prototypování – celý Tripomatic je vyvíjený na bázi prototypů. Tedy minimálně to, co je navenek vidět, to je vidět celé dny a týdny předtím v prototypech. Hodně nám to umožnilo koukat na to, přemýšlet nad logikou věci ještě než se naprogramuje a nedá se změnit tažením myši.
• uživatelské testování – postupně jsme díky uživatelskému testování dostali produkt od stavu „WTF? I can NOT use this product“ do fáze, kdy lidi nadšeně v testech vykřikují: „It's amazing, I didn't expect that to be so wonderful!“.

V příštích měsících Tripomatic dozraje a stane se z něj projekt, který bude připravený pro celosvětový úspěch. On se totiž tento „úspěch“ nedá pokládat za něco, co by ještě bylo potvrzením užitečnosti pro trh. Je jen dobrým impulsem, který ukazuje, že vše, co v Česku na webu vzniká, si mezi sebe Tripomatic musí připustit.

Já tento týden odcházím z two bits do Prahy a má pozice se transformuje z pravidelné na občasnou. Chci všem, kteří na Tripomaticu pokračují dál, popřát, ať ten projekt klapne, ať vás to baví tak, jako nás to bavilo doteď, ať překonáte milión problémů, jako ty, s které jsme se doteď setkali a nebáli se jich.

Nejlepším způsobem, jak těmto úlohám bránit, je odložit je bokem, napsat si je někam na seznam, který měsíčně reviduju. Jen očištění o momentální nadšení mě zbaví 80 procent úkolů.

Pokud se nápad dostane z listu na odložení, ještě pořád nemá vůbec jistý osud.

Potom se ptám na spoustu otázek a jsem co nejkritičtější.

Jak dlouho to budu dělat, než budu mít nejmenší možný tržní produkt?
Chci s tím spojit svůj život i za 5 let?
Je to úplná změna toho, jak lidi žijí/pracují/ko­munikují, nebo jemný tuning, který lídr na trhu může vychytat za 2 týdny práce?
Kolika lidem to pomůže?
Jak to k těm lidem dostanu?
Jak z toho dostanu peníze?
Jak se vyrovnám s malým zájmem? Jak se vyrovnám s obrovským zájmem?
Kolik už takových projektů se hlásilo do různých startup soutěží? Je to skutečně postavené nohama na zemi?
Ikdyž chci využít tržní niku, je ta nika etablovaná už delší dobu (rybáři, sběratelé LPíček), nebo může zaniknout tak rychle, jak vznikla (fanoušci 3. řady nějaké hry, která se změnší na jedno procento, až vyjde 4. díl)
Využívá to to, co umím nejlépe? Mám nějakou konkurenční výhodu, kterou nikdo nemůže napodobit?

Když projdu tímto vším, většinou končím tím, že programuju něco pro sebe a své studenty (jako třeba Googy, web s českou dokumentací pro Mercurial).

Pak začnu kreslit prototypy, udělám si třeba i HTML prototyp v Blueprintu. Začnu přemýšlet, v čem to naprogramuju, kde to budu hostovat. To jsou činnosti, které dělám řadu týdnů od chvíle, kdy mě napadlo naprogramovat danou věc. Takže je to (naštěstí) očištěné o technologii, kterou jsem se tou dobou čerstvě naučil (a byl jsem z ní nadšený, že bych do ní přepsal nejradší úplně všechno).

Teprve tehdy začnu programovat.

Přijde vám to pozdě? Ano a je to tak dobře! Jeden dokončený projekt je lepší, než deset rozdělaných a psaných nepoužitelně, naslepo, bez prototypu – což by byl můj osud, nebýt dnes daleko konzervativnější, než dřív.

Princip je v tom, že si nejdřív musím namountovat FTP jako disk. V OS X se na toto hodí například Transmit.

V každém případě můžete použít nějaký FTPFs. Na Windows poslouží například WebDrive.

Předpokládám, že používáte verzovací systém Mercurial. Stejně dobře toto řešení funguje v Gitu, Bazaaru, méně pohodlně i v SVN (musíte ho mimojiné víc zabezpečit).

Potom už si připravim na serveru Mercurialový repozitář:

hg clone ~/Websites/Projekt /Volumes/ftp.pro­jekt.com

Pokaždé, když chci deploynout novou verzi, stačí ve složce projektu napsat:

hg pull -u

Jaké to má výhody?

1. na nic se nezapomene, navíc je strojový deployment skoro vždy rychlejší než ruční
2. vždy přesně vím, jaká revize je na serveru
3. můžu snadno zavést deployment na libovolné platformě
4. můžu se kdykoliv vrátit zpět
5. když hg pull uvedu bez parametru, můžu potom pomocí hg up uvést explicitní revizi, na které chci běžet
6. je to celé automatizovatelné
7. a s automatizací je možné i přidat promazání cache, což se třeba v Nette dělá pomocí rm -rf app/temp/c*
8. spustit migrace je u mě spuštění 1 souboru: php app/migrate.php (tam, kde migrace používám)
9. quickfixy přímo na produkci si můžu snadno stáhnout
10. Mercurial přenáší jen delty, takže ušetří prostor proti tomu, kdyby posílal celé soubory

V budoucnu si kolem toho plánuju obestavět ještě lepší systém.

Dvě věci jsem nepřekládal: 1. názvy typů pivotů, protože si myslím, že tak mají větší šanci fungovat jako oficiální terminologie. 2. slovo „pivot“ jako takové – znamená změnu kursu/obchodní strategie/fungování startupu a docela se ve svém oboru zažil.

Oblíbený pohled na podnikatele je jako na někoho s velkou vizí a silou posouvat se obtížím navzdory směrem k ideálnímu produktu. Vize je skvělá, ale úspěšní podnikatelé zjistili, že cesta k úspěšnému produktu často vyžaduje mnoho změn směru a strategie.

V Silicon Valley se objevil nový populární způsob (Lean pozn. překl.), jak dramaticky zlepšit efektivitu a rychlost změn. Svůj díl nese i autor Eric Ries, autor knihy „Lean Startup“, kde ukazuje, jak dnešní podnikatelé neustále inovují svůj podnik ke zrychlení svého podnikatelského úspěchu.

Eric podporuje navrhování produktů tak, aby byl nejdřív realizován nejmenší počet vlastností pro uspokojení zákazníků a rychlé změny podle reakce trhu. Ve své knize dělá skvělou práci, když vysvětluje, že podnik by měl dělat manažerská rozhodnutí, ne impulsivní rozhodnutí při změnách kurzu. Tím se zvyšuje pravděpodobnost úspěchu.

Změny kurzu se mohou lišit v mnoha způsobech. Každá ze zmiňovaných cest adresuje odlišnou hypotézu o produktu, obchodním modelu, způsobu růstu.

Souhlasím s Erikovým výčtem deseti nejčastějších způsobu změny směru:

1. Zoom-in pivot – v tomto případě podnik z jedné vlastnosti produktu udělá celý produkt. Principem je hodnota „zaměření se“ a minimálního možného produktu (Minimal Viable Product), který uspokojí trh. Výsledkem je rychlejší doručování nových vlastností.
2. Zoom-out pivot – v opačném případě podnikatel zjistil, že celý produkt nestačí pro uspojení zákazníka a rozšiřuje produkt natolik, že co bylo dříve celkem, je nyní jen jedna vlastnost. Výsledkem je mnohem větší produkt.
3. Customer segment pivot – Ikdyž máte produkt, který lidé chtějí, možná jste se zmýlili v tom, kdo jsou vaši zákazníci. Řešíte tedy něčí problém, ale někomu jinému, než jste čekali. Posunete tedy směr a výsledkem je, že vaši skuteční zákazníci budou mít produkt zacílení lépe na sebe.
4. Customer need pivot – Každá odezva od zákazníka ukazuje, že problém, který řešíme, není moc důležitý a lidem nestojí za ty peníze. V tu chvíli podnik buď radikálně mění produkt, nebo ho zahodí a hledá nový problém, který stojí lidem za řešení a začne budovat produkt okolo.
5. Platform pivot – produkt se může posunout k platformě nebo naopak. Mnoho podnikatelů svůj produkt do budoucna vnímají jako platformu pro další aplikace, ikdyž dosud žádnou skvělou aplikací nemají. Více zákazníků kupuje produkty než platformy.
6. Business architecture pivot – před mnoha lety zjistil Geoffrey Moore, že dvě hlavní obchodní architektury jsou: „vysoká marže, nízký počet prodejů“ (model komplexních systémů) nebo „nízká marže, mnoho prodejů“ (model častých prodejů). Nikdy není možné aplikovat obě strategie naráz.
7. Value capture pivot – změna způsobu, jak firma vlastně od lidí získává peníze má obrovské následky pro obchod, produkt a marketingové strategie. „Free“ model nezískává mnoho hodnoty.
8. Engine of growth pivot – v dnešní době většina startupů používá jeden ze tří nejčastějších způsobů růstu: virální, model přilepení se na uživatele a placeného růstu. Vybrat správný model může výrazně změnit rychlost a profitabilitu růs­tu.
9. Channel pivot – v terminologii prodejců, jde o mechanismus, jak firma doručuje produkt zákazníkům je nazvaný „prodejní kanál“ nebo „distribuční kanál“. Součástí takového kanálu je unikátní nacenění, výběr vlastností a tržní nasazení vůči konkurenci.
10. Technology pivot – občas startup objeví způsob, jak dosáhnout stejného řešení kompletně jinou technologií. Nová technologie ale dokáže nabídnout skvělou cenu a/nebo výkon pro dosažení konkureční výhody.

Každý podnikatel čelí při vývoji produktu mnoha výzvám. A to i v tom, jaký „pivot“ ho čeká a jaký model má zvolit a kdy má naopak vydržet, ikdyž se dostavil dočasný neúspěch. Zeptejte se většiny podnikatelů a oni vám řeknou, že litují toho, že nezměnili kurs dřív. Ve skutečnosti není ranvejí startupu objem peněz, ale počet pivotů, kolik si ještě může dovolit. Jaká je vaše cesta, abyste byli schopní rychleji změnit směr?

Zdroj: http://www.forbes.com/…ean-startup/

Ale ono to rčení má i další význam:

Cesta je míněna jako neustálý vývoj. Cílem tedy je neustálý rozvoj.

A i to je ohromná hloupost.

Proč člověk ubíhá cestu? Protože není spokojený v bodě A a potřebuje se dostat do bodu B. Nutnost dostat se z A do B vlastně znamená, že člověk je nespokojený. A cesta z bodu A do B je vždy horší, než být v B (protože jinak bych zůstal na cestě v bodě, kde jsem, nepůjdu do B, kde se budu mít hůř). Cílem tedy není cesta od A do B, ale být v B a zjistit, že je to to pravé, kde budu spokojený. A potom, až zjistím, že chci být v C, lusknutím prsty se tam přesunout, nepodnikat cestu, kdy se paradoxně můžu cítit hůř, než jsem se měl ve výchozím bodě.

Když šli Židé přes poušť do země zaslíbené, taky to měli nejspíš těžší, než v Egyptě. A rozhodně nebylo jejich cílem celý život strávit cestou v poušti. Oni chtěli do cíle, do země zaslíbené.

Cesta je cesta a cíl je cíl. Cesta samotná (proces transformace) nesmí vytlačit to, že máme cíle (stavy, kterých chceme dosáhnout). Cesta je prostředek, jak se dostat z jednoho cíle k dalšímu. To, co mění svět, to je dosahování cílů, ne cesta bez cíle a tvrzení, že cesta samotná je cíl. Ten, kdo nemá vlastní cíle, tomu někdo cíle přidělí.

Když se rohodnu, že chci projet na motorce Austrálii, je to proto, že v bodě A (Česko) budu méně spokojený, než měsíc na motorce v bodě B (v Austrálii). To, jak se budu rozhodovat a putovat, to nemusím mít v Česku rozmyšlené, na místě si můžu klást další cíle a putovat po nich. Na začátku cesty mám rozmyšlený velký cíl (Austrálie), malé cíle přijdou, až dosáhnu toho velkého.

Cesta je cíl zní krásně. Cíl je cíl a cesta je prostředek, to už zní všedně, ale aspoň je to pravda.

Programátor přestává být amatér, když začne být profesionál.

Jak se pozná profesionál?

Profesionál ví, co v jeho oboru znamená kvalitní řešení – amatér nezná své chyby, těch novinek je tolik, že neví, kde začít. Profesionál už se našel a ví, že chce dělat HTML5, nebo databáze, nebo 3D grafiku, nebo embed zařízení. Ve svém oboru profesionál zjišťuje novinky a trendy, ostatní oblasti čte pro zábavu.

Profesionál má potřebnou infrastrukturu – amatér si stáhne „knihovnu“, vygooglí si nějaký hosting a založí si takzvané webové studio. Profesionál buduje infrastrukturu. To znamená systémy, které ho podporují, které pouští testy, které integrují jeho práci, systémy, které provádí deployment, systémy, které provádí databázové migrace. To jsou časové investice, které profesionál nedělá do zákazníka, ale do sama sebe – aby ale ve výsledků udělal víc práce pro zákazníka a nemusel dělat práci, kterou za něj udělá skript.

Profesionál zná svou cenu – amatér nemá reference. Amatér nemá poptávku. Amatér jde s cenou dolu. Amatér nemá konkurenční výhodu jinou, než cenu. Profesionál se diferencuje a nabízí služby, které se dají obtížně napodobit. Čím delší dobu profesionál něco dělá, tím víc oblastí zasahuje, ale zároveň v jedné, dvou proniká do velké hloubky. A dřív nebo později se objeví zákazník, který přesně tyto znalosti potřebuje.

Profesionál umí poradit zákazníkovi – profesionál už jednal se spoustou zákazníků. Ví, co zákazníci chtějí a dokáže jim poradit řešení, které sice nepoužívá nejvíc trendy technologii, kterou by rád vývojář použil, ale které využije to, co je jednoduché, má existující knihovny, klienty, dokumentaci a umožní zákazníkovi případně od profesionála odejít a najít si jiného (ano, myslím si, že vendor lock-in je nemorální).

Profesionál ví, kdy má porušit pravidla – profesionál svou práci dělá nejlépe, jak umí. Ale zároveň ví, že má určité hranice. Když přijde zákazník s tím, že chce web s 15 stránkami a 1 kontaktním formulářem, nepoužije Zend (v kterém bude mít aplikace promili velikosti proti celému ZF), nepoužije Data Mapper, ale přímo SQLka, nebo nějaký Active Record. Říká se, že každá aplikace roste. Já mám pocit, že aplikace rostou, webové stránky ale nejsou aplikace a moc to o nich neplatí. Tam většinou jen roste obsah (mluvím o zákaznících, pro které internet není ani hlavní, ani vedlejší prodejní kanál a pro které je stránka jen vizitka).

Profesionál ví, co nejde – je to zvláštní, ale „vědět, co jde“, není až tak těžké. To je v dokumentaci. To je v API. Co nejde, to si musí člověk zjistit praxí. Na druhou stranu: profesionál nebude lhát, že něco nejde jen proto, že je to obtížné.

Profesionál našel své pracovní nástroje – Nechápu firmy, v kterých se globálně nařídí jeden editor kódu, jeden browser a programátoři ani nemají administrátorská práva na svůj počítač (přestože nejspíš vědí o počítačích stokrát víc, než správce sítě, který ta práva má). Když budu řídit jadernou elektrárnu, pětisethlavou firmu, tam to pochopím. U podniku s třiceti zaměstnanci to nedává smysl. Každý je unikátní a každý pracuje jiným způsobem. Proto je potřeba respektovat jeho odlišnosti, jinak nebude výkon lidí profesionální, podnik se zredukuje na „společný jmenovatel“, místo es budou ve firmě jen vzájemně zaměnitelní průměrní zaměstnanci. Profesionál v takovém prostředí pracovat nebude. Profesionál používá nástroje, které podpoří jeho talent, ne takové, které se dobře používají i kolegům-juniorům.

Být profesionál ale hlavně znamená být odpovědný. Nebát se podepsat pod svou práci a nestydět se za ni.

Vyšlo i na Zdrojáku

Úrovně perspektivy jsou:

Úkoly a projekty (třeba 1 měsíc dopředu)

Toto je výchozí úroveň na které člověk pracuje na běžné denní bázi. V podstatě je to úroveň jednotlivých projektů a kroků, které člověk chce (nebo musí) v nejbližší budoucnosti zpracovat. To je část kontrola, které jsem se věnoval v minulém díle.

Úrovně zodpovědnosti (několik měsíců dopředu)

GTD postupuje při zadávání úloh (nevnucených zvnějšku) shora dolů. Úkoly a projekty, které si člověk dává vychází z oblastí zodpovědnosti. Oblast zodpovědnosti je jakákoliv činnost, osoba, jev, v němž chceme dosáhnout nějakých cílů.

Běžné úrovně odpovědnosti jsou:

• být zdravý
• strávit víc času s rodinou a nejbližšími
• zlepšit svůj příjem
• cestovat
• být kreativní
• zlepšit si vzdělání

Z každé z těchto úrovni odpovědnosti vznikají projekty. Proto je v GTD naprosto jednoduché vyvážit pracovní a osobní život (jednoduše pokud se zaměřujete na 10 oblastí zodpovědnosti a práce se dotýkají jen 3, nemůžete prací trávit 70 procent času – nestíhali byste ostatní projekty).

Cíle (cca 1–2 roky dopředu)

To, jaké si zvolíme úrovně zodpovědnosti, řeší naše cíle. Cíle na 1–2 roky bývají už poměrně ambiciózní představy, jak chceme, aby náš život vypadal.

Za 1–2 roky se dá naučit cizí jazyk, dokončit opuštěná vysoká škola, shodit všechen tuk, uběhnout maraton, připravit svatbu, mít první výstavu svých fotografií, našetřit si a procestovat Indii.

Aby se cíle skutečně splnily, musí člověk stanovit správné oblasti zodpovědnosti. Proto například pro cestu do Indie si řeknu na této úrovni:

Do 18 měsíců pojedu na 1 měsíc do Indie
Vytvořím pro to oblast zodpovědnosti: Cesta do Indie
Z toho budou projekty:

• zjistit, kolik peněz potřebuju na cestu do Indie a jaké si dát očkování (první krok, obepsat mailem ty, o kterých vím, že byli v Indii – což by u mě byl snadné, jsou to jen 2 lidé)
• vytvořit si fond na Indii a plán ukládání
• zjistit, kde se dá očkovat na všechny choroby (neřeknou-li mi to ti lidé)
• zajistit si měsíc času
• vytvořit itinerář
• najít letenky
• nechat se očkovat
• zajistit si víza
• zajistit člověka, který se mi postará o kytky
• odjet na letiště

GTD mě k cílům automaticky dovede. Stačí pouze realizovat jednotlivé kroky.

Vize (cca 5 let dopředu)

Za pět let se dá v životě změnit úplně všechno. Za 5 let může mít člověk perfektní zdraví, žít v zahraničí, mít prestižní práci, vybudovat rodinu a domov, změnit svůj obor na prakticky jakýkoliv.

Z pohledu plánování shora dolů právě tu velkou změnu musí člověk nějak zahájit. Proto vize z pohledu 5 let ovlivní cíle z pohledu 1–2 let.

Chci žít v zahraničí do 5 let?
Za 1–2 roky už musím mít zkušenost s dlouhodobějším pobytem v cizině.
Už bych měl mít i pracovní zkušenost v dané zemi.
Měl bych mít osvojeny základy toho jazyka.

Chci do pěti let mít rodinu?
Do 1–2 let potřebuju mít jistotu bydlení, kam s ženou děti přivedeme.
Do té doby se s tou ženou vezmu.

Chci být do pěti let milionář?
Do 1–2 let musím mít příjem alespoň 100 tisíc měsíčně čistého.
Taky musím do té doby začít odpoutávat svůj podnik od své osoby a začít ho škálovat nahoru.

Chci do pěti let zajistit důstojný důchod pro své rodiče? Do 1–2 let musím vědět, co vlastně důstojný život pro ně obnáší, zjistit aktuální stav spoření rodičů a vymyslet, jak jim pomoci. Do té doby musím vytvořit trvale udržitelný systém přispívání a dalších služeb, které budou potřebovat.

Jak vidíte, vize jsou opravdu velmi ambiciózní změny v životě, které nejdou udělat přes noc – a když, tak špatně s rizikem selhání. Termín, který se pro GTD na pokročilé úrovni vžil, je takzvané: „life designing“ – tedy navrhnout si život tak, abych žil svůj ideální život a zároveň jsem dostatečně pružný se na denní úrovni pružně rozhodovat.

Smysl života

Nejvyšší úroveň perspektivy je životním smyslem člověka. Tato část je jen pár vět, v kterých člověk řeší svůj vztak k sobě, rodině, přátelům a okolnímu světu. David Allen, když nevíme, jak na tuto část, doporučuje napsat si pohřební řeč. Nebo co chceme, abychom o sobě řekli na smrtelné posteli.

Můj smysl života zahrnuje mé nejbližší, cestování, kreativitu, vytváření hodnot a víru v trh.

Smysl života je instancí číslo jedna. Nikdy nesmíme v GTD vytvořit úkol, který by šel proti smyslu života. Neexistuje žádné: „já jsem jen plnil rozkazy“. Pokud věřím trhu, nikdy nebudu pracovat ani minutu pro KSČM, ikdyž to bude skvěle zaplacené. Pokud mi jde o lásku k rodině, nikdy je neodsunu na druhou kolej jen kvůli vydělávání peněz.

Ze smyslu života vyplývá úroveň za 5 let. Úroveň vize představuje ideální realizaci toho, jak si představujeme realizaci myšlenek vyjádřených smyslem života.

Ukázali jsme si úrovně perpektivy. Ty ale jsou neoddělitelné od kontroly (tedy práce s inboxem a seznamy). Výsledkem kontroly a perspektivy je jedinec, který přesně v každou chvíli ví, co dělá (nebo nedělá) a jaký je smysl toho konání a zda ho to někam vede (a hlavně kam). Pak už zbývá jen samotné vykonání úkolů, to už GTD tolik neřeší. Jedna myšlenky z knihy mě ale zaujala a myslím, že o té exekuci úkolů říká hodně:

Být v každou chvíli a dělat právě to, o čem jsem bytostně přesvědčen, že mám dělat.

Takže co je GTD?

GTD je metodika řízení, která definuje workflow na denní, týdenní, měsíční a dlouhodobějších bázích (ještě 1–2 roky, 5 let a celý život).

Na denní a týdenní úrovni existují 2 rituály:

Denní rituály GTD

Ráno se podívám do diáře, co mě čeká a dám je do dnešního seznamu. Pak se podívám na seznamy úkolů, co musím udělat nejpozději dnes a na další dny dopředu. Dám je do seznamu. Projedu si aktuální projekty a podívám se, jestli tam jsou odpovídající další kroky a dám si je do To Do Today pod položky z diáře a úkoly, které musím udělat dnes.

Úkoly, které mám v diáři a které dnes expirují jsou prioritní, když neudělám ostatní úkoly, nevyčítám si to.

Týdenní rituál GTD

Každý týden je Week Review. Projdu úkoly, které jsem udělal a zhodnotím, jak se mi dařilo nebo nedařilo. Pokud jsem měl nějaký experimentální týden (týden, kdy jím jenom syrovou stravu, týden, kdy si každý den zapisuju, co jsem dělal minutu po minutě apod.), zhodnotím výsledky.

Po revizi nastává práce se vstupní schránkou. Beru jednotlivé položky a dělám s nimi proces, který si zaslouží samostatný článek. V podstatě ale u každé položky zjistím, co pro mě znamená. Zda nějak ovlivňuje mé cíle, zda vytváří novou práci pro mě nebo někoho jiného a zda si dané údaje chci uchovat. Podle toho s každou položkou naložím.

Buďto ji smažu (nejčastější)
Nebo z ní udělám projekt (a naplánuju první kroky)
Nebo z ní udělám úkol (pokud je to jednoduchá věc)
Nebo úkol deleguju (protože nikoho nezaměstnávám, mám rozhodně v této oblasti co dohánět)
Nebo položku zařadím do seznamu jednou/někdy a zhruba za měsíc se k ní vrátím a zjistím, jestli je pořád pro mě zajímavá (pak z ní udělám projekt; tady dávám všechny „geniální“ nápady, které mám chuť hned začít programovat)

Posléze následuje samotné plánování projektů. Podívám se na své oblasti zodpovědnosti (oblasti, kde chci dosáhnout cílů) a vytvářím projekty tak, abych se ve všem posouval. Oblasti zodpovědnosti nejsou jen profesní, zahrnují sport, vztahy s rodinou a přítelkyní, cestování apod. Všechny vyplývají z vyšších úrovní o kterých napíšu v dalším díle. Na konci week review mám seznam projektů s termíny na týden dopředu.

Toto je workflow na nízké úrovni. Už to člověku hrozně uleví.

Pak jsou tu vyšší úrovně, které mají ještě větší vliv na život. Těm se věnuji v následujícím článku GTD není jen o seznamech 2.

Nejdřív vás naučím Coffeescript. Potom si ukážeme, jak se píšou testy v Javascriptu na client-side. Na přednášce si nechám dostatek prostoru pro vaše otázky (nebo na ukázku toho, jak se píšou testy v node.js). Pro ty stále nepřesvědčené mám připravenou část, kde jednoduše vysvětlím benefity testování.

Můžete se těšit na prezentaci připravenou po školeni Jeanne Trojan. Takže bude daleko zábavnější, pochopitelnější a zapamatovatelnější. Velkou inspirací pro mě byly i slajdy Evy Lotty Lamm.

Ještě víc se můžete těšít na plno ukázek kódu, který můžete snadno psát i vy sami a které použijete v praxi.

Slajdy nebudou nudné desetiřádkové výčty údajů, slibuju! Místo toho uvidíte ručně kreslené obrázky a grafy.

V průběhu školení vás čeká překvapení: přístup k informacím o testování v JS a Coffee, který připravím speciálně pro Webexpo 2011.

Stránka mé prezentace i s časem na webu Webexpo.

Já jsem začal používat software Sequel Pro. Shrňme si jeho výhody proti webovým řešením:

• vypadá je a chová se nativně
• mám v Docku pro něj ikonu, to je druhý nejrychlejší způsob, jak se dostat k databázi (hned po klávesové zkratce, kterou má taky)
• používá systémovou klíčenku, přežije upgrady (což webový aplikace přežije jen tehdy, když bude login formulář identický)
• napovídá mi při psaní SQL názvy sloupců, jejich typy
• automaticky obaluje názvy tabulek a sloupečků `
• napovídá mi názvy SQL funkcí a pořadí parametrů
• je rychlejší, než jakýkoliv webový nástroj, jaký jsem v životě potkal (vypíše 80 000 řádek do jedné vteřiny, Beat it!)
• nikdy mu nevypadne session, můžu mít uspaný notebook třeba 5 let a pak ho otevřu a on se chytře přihlásí znovu bez toho, aby mi zrušil obrazovku, na které dělám
• nemusím ho hledat v N tabech, aplikace se dá vyvolat 1 klávesovou zkratkou
• má TUNU klávesových zkratek
  • například bundles známé z Textmate. Napíšu SQL a když se rozhodnu ho obalit jiným delimiterem, označím text a stisknu ctrl-alt-cmd-w a ono to automaticky obalí novým delimiterem, který napíšu (a automaticky najde starý delimiter a nahradí jeho výskyty na nové)
  • ať už jsem kdekoliv v aplikaci (koukám na obsah nebo strukturu nějaké tabulky), do okna SQL se dostanu 1 zkratkou (cmd-5)
  • mezi různými pohledy na tabulku se přepínám pomocí cmd-1 (struktura), cmd-2 (obsah), cmd-3 (relace), cmd-4 (informace o tabulce)

Jaké výhody sdílí s webovými aplikacemi?

• umožňuje práci v tabech i ve více oknech
• jeho instalace je snadná (stáhnu a spustím bez instalace 1 soubor)
• funguje gesto pro zpět (na poslední pohled, který jsem dělal)
• funguje klávesová zkratka pro refresh

Jaké má nevýhody proti webovým aplikacím?

• nefunguje na některých hostinzích (ikdyž asi by šlo i to protunelovat)
• nutnost používat jednu platformu (opět: u mě je to jedno, používám pouze OS X)

Pro mě je to jasné. Od té doby, co používám většinu času nativní aplikaci, ze svého rozhodnutí jen těžím. Zjišťuju, že to pohodlí mi ohromně vyhovuje. Pevně věřím, že i Windows a Linux mají skvělé klientské aplikace. Vy, kteří pracujete s MySQL, prozkoumejte aspoň jednu a nebudete litovat.

Sepíšu si úkoly, které chci dělat. Na každou řádku jeden. U každého úkolu si nechám místo zleva (aspoň 2–3 centimetry) i zprava (aspon 2 centimetry).

Každé ráno se rozhodnu, jaké úkoly ten den udělám. Úkoly, které musím udělat ten den, označím zleva hvězdičkou. Protože jsem na dovolené, počítám si dny od 1.

Příklad:
1* sehnat si týdenní jízdenku
1 napsat Monice, poradí mi kam v Říme jít
jet k moři
jít nakoupit dárky rodině
sehnat seznam dobrých restaurací

Toto znamená, že první den dovolené chci udělat 2 věci, jedna z nich je důležitá (týdenní jízdenka), druhou, když neudělám, nevadí to.

Jakmile je úkol hotov, na konec toho úkolu napíšu _, pokud je nehotový, napíšu za něj /

Například koupil jsem část dárků (ikdyž jsem si to nenaplánoval) a sehnal jsem si týdenní jízdenku.

1* sehnat si týdenní jízdenku _
1 napsat Monice, poradí mi kam v Říme jít
jet k moři
jít nakoupit dárky rodině /
sehnat seznam dobrých restaurací

Úkol je hotov, jakmile má za sebou _. Pokud se rozhodnu úkol nedělat vůbec, přeškrtnu ho.

Pokud nestihnu úkol v tom dni, kdy jsem si ho předsevzal, napíšu si před něj druhý den hvězdičku (už ho musím udělat). Nestihl jsem třeba napsat Monice:

1* sehnat si týdenní jízdenku _
1* napsat Monice, poradí mi kam v Říme jít
2 jet k moři
jít nakoupit dárky rodině /
2 sehnat seznam dobrých restaurací

Pokud ani druhý den nestihnu úkol začít dělat, už mi na něm nezáleží a přeškrtnu ho (nejproduktivnější technika je rušit úkoly a nedělat je).

Jak se dovolená blíží ke konci, snažím se ukončovat rozdělané úkoly (ty s / místo _) a řídit si je pomocí hvězdičky. Dokončit 5 úkolů je vždy cennější, než rozdělat a nedokončit 10.

Tento systém občas používám i doma, když dávám šanci papíru (velmi vzácně, nejvíc mi vyhovují softwarová řešení se synchronizací do iPhone). Výhodou je, že tento systém jde používat i s Pomodoro. Místo dní píšu odhad počtu pomodoro.

Pokud dokončím pomodoro, píšu za úkol X, pokud úkol dokončím, píšu _, pokud mě někdo přeruší tak, že musím zrušit pomodoro, píšu /, pokud je vyrušení krátké (kolem 15 vteřin), píšu '. Pokud úkol zvládnu za méně než půl pomodora, píšu /_

Příklad: 1 zero inbox X_ (je to hotovo po 1 pomodoro)
1 100 kliků XX (dělal jsem kliky 2 pomodoro a není to ještě hotovo)
2 napsat článek //_ (začal jsem psát, ale byl jsem přerušen, pak znovu a pak jsem úkol dokončil)

Věc občas kombinuju se systémem Autofocus. Ten umožňuje ohromně zvětšit objem dokončené práce a hlavně tehdy, když se mi nechce dělat pomodoro, funguje stejně dobře. Ten popíšu jindy.

Když děláte UX, musíte zároveň být expertem na:

• zábavu – tohle je oblast, o které se moc nemluví. UX guru z vás udělá to, že jste guru na zábavu. Všechno ostatní jde stranou, pokud uděláte hnusný web ve Flashi pouze pro monitory s aspoň 1440 pixelů na šířku, můžete ukázat puristům prostředník, pokud na vašem webu lidi tráví 5 hodin denně a jsou závislí (ano, opravdu si myslím, že lidi by na Facebook chodili dál, ikdyby byl růžový a na homepage skákal animovaný jednorožec).
• použitelnost – použitelnost je to, z čeho UX vzniklo (kromě zábavy, ta je v UX číslo 1). Odborník na UX čte hodně článků o použitelnosti. Pokud nejste přímo expert na použitelnost, pravděpodobně víte o použitelnosti polovinu toho, co ví odborník na UX. Jen odborník na UX si dokáže odůvodnit červený text na růžovém pozadí: tedy tam, kde uživatelský prožitek stojí za to nepohodlí.
• psychologii prodeje – proč děláte weby? Ikdyž internet vznikl jako vojenský akademický projekt, business si našel k netu velmi rychlou cestu. Kvalitní odborník na UX nejspíš umí upravit váš web tak, že zaplatíte o 10 dolarů měsíčně víc a ještě hezky poděkujete.
• grafiku – aspoň trošku. Odborník na UX bez grafického cítění bude jen teoretik. A tak nějaká představa o tom, jak to má vypadat, musí být. Něco podobného by se dalo říct i o informační architektuře.
• analytický software – „tak ty sis navrhl změnu a ani si ji neumíš vyhodnotit?“ Odborník na UX nejspíš bude mít praktické zkušenosti s A/B i multivariantním testováním.
• vyjednávání – UX zasahuje do mnoha oborů. UX expert pracuje s grafiky, kodéry, zadavateli, manažery, vývojáři, pracovníci marketingu

Proto je těch lidí tak málo? Ano, je to tím, že každá z těch disciplín vyžaduje ohromnou spoustu znalostí. Dokážu si představit experta na zábavu, experta na použitelnost, experta na psychologii prodeje, experta grafika, experta analytika i experta vyjednávače.

Tyto multidisciplinární profese mají i tu výhodu, že objem znalostí je tak velký, že se můžete celý život vzdělávat a nikdy nedojdete na konec.

Něco jiného je to ale s podvržením POSTu. Skoro každý systém, s kterým jsem se setkal, trpěl tím, že přinejmenším v administrační části bylo možné podvržením postu editovat údaje, na které ten uživatel neměl dostatečná práva.

Je to samozřejmě dáno tím, že programovat tuto ochranu není zcela triviální (ve srovnání s ochranou proti např. SQLi).

Jaké jsou nároky na architekturu, aby bylo možné naprogramovat ochranu proti podvržení postu?

1. Model musí být schopen říci už před uložením, které položky smí uživatel vidět/upravit/sma­zat.
2. Controller tyto údaje předá z modelu do view a to podle toho (ne)zobrazí editační prvky, případně údaje samotné.
3. Při ukládání formuláře se pošlou data modelu a ten opět musí provést kontrolu, která se prováděla už při renderování stránky. Tohle je bod, před kterým většina vývojářů skončí.

Pokud budete někdy dělat bezpečnostní audit svého firemního CMS, e-shopu, zkuste se zaměřit i na podvržení POSTu.

Máme podvědomou potřebu kupovat je a plnit údaji, obrázky, seznamy úkolů, vizemi na měsíce a roky dopředu. Někdo více a někdo méně. Jeden si v Moleskinu eviduje své GTD, jiný je kreativní, maluje a kreslí, vlepuje obrázky, experimentuje s textem.

Všechny tyto diáře a bločky můžou hodně pomoci. Třeba já mám několik různých papírových kamarádů a každý z nich má nějaký smysl.

Běžný řádkovaný Moleskine

Do tohoto diáře píšu ze dvou stran.

Odzadu je inboxem, místem pro poznámky, různé jednoúčelové údaje, jednoduché nákresy, bitevním polem. Každá stránka je jiná. Je místem číslo 1, kam zaznamenávám nový podnět, pokud nemám u sebe zařízení s Things, které používám na GTD. Je místem, kde kreslím mind-mapy.

Z druhé strany mám minimalistický systém řízení, když jedu na dovolenou, kde mám ještě co řešit a nechci si sebou brát počítač nebo spoléhat na Things v iPhonu. Tato část je jediné místo ze všech mých diářů, které je racionální a strukturované. Někdy ten systém popíšu, ale je hodně podobný Autofocusu (který popíšu časem taky).

Cestovatelské Moleskine

Když někam jedu na dovolenou (delší než víkend), snažím se obstarat si Moleskine toho místa. Zapisuju a kreslím si do mapy restaurace, kde jsem jedl, jaká byla obsluha (jsem foodie, rád dobře jím, ještě radši vařím, takže si zapisuju i recepty, které mámím z číšníků). Podobný osud mezi řádky malého diáře s mapou mají i zvláštní místa, okamžiky, šifrované připomínky, které třeba pro jiného turistu nemají žádný smysl.

Postupně se plní i postranní kapsa. Vizitkami, účtenkami s adresou a obrázky, které jsme s přítelkyní nakreslili na ubrousky a účtenky. Zjistil jsem, že díky tomuto diáři většinu suvenýrů z dovolených můžu zahodit. Stačí listovat po stránkách a to nejdůležitější – zážitky – se samo připomene.

One Sketch a Day

Tento diář jsem si koupil v Muzeu současného umění v San José. Princip je jednoduchý: na každé stránce je prostor pro datum a obrázek. Každý den nakreslím jednoduchý obrázek. Někdy se to zvrhne a namaluju jich daleko víc. Co mi přinesl? Naučil mě tomu, že co se kreslení týká, pravidelnost se hodně vyplácí.

Větší Moleskine s papírem pro akvarel

Protože jsem postupně přestal kreslit propiskou a začal používat černé popisovače, přestal mi One Sketch a Day vyhovovat. Propisoval se skrz stránky. Domů putoval větší moleskin pro malbu akvarelem. Papír je mnohem tvrdší a příjemnější na kreslení i na dotek. Má sice málo stránek, ale svou úlohu plní dobře.

Dokonce jsem už do něj zkusil nakreslit i něco akvarely, na které se mi doma do té doby jen prášilo (teď už se mi práší jen na tempery, voskovky a plastelínu).

Závěrem

Papír se pro mne stal místem, kde můžu rozvíjet tu kreativní část svého mozku. A neuplyne den, kdy si pro to nenajdu chvilku. I já bych vám to určitě rád doporučil.

Je toho plno.

Kromě organizace svých školení plánuju workshopy, kdy budu procvičovat v menších skupinkách pokročilejší postupy při psaní testů, zavádění Scrumu a agile. Co se školení týká, mám ještě překvapení, to si ale zatím nechám pro sebe.

Taky bych rád udělal setkání lidí, kteří se zajímají o time management, GTD a ukázal lidem, jak moc si člověk může zlepšit život, když začne praktikovat Agile ve svém individuálním životě.

No a protože se i transformuje má spolupráce s two bits, hledám za sebe na Tripomatic nového kolegu, programátora v PHP (Nette). Čímž bych rád vyzval ty, kteří rádi dělají svou práci pořádně a rádi by šli do podniku, kde se věci nedělají polovičatě, ať se ozvou!

Dneska koukneme na infrastrukturu.

Podniková infrastruktura je obvykle zdrojem spousty zbytečných procesů, nedokončených (nebo nedomyšlných) činností a habání časem i po hodinách zúčastněných denně. Proto patří mezi první oblasti, které ve firmě při zavádění Scrumu optimalizuji.

Typické chyby, které ve firmách potkávám jsou:

• nesprávné zadávání úkolů a správa v IS (úkoly jsou zadávány tak, že jsou obtížně pochopitelné, netestovatelné a chybné – moc krátké nebo dlouhé)
• nesprávná kontrola úkolů (neexistuje kontrola jak zdrojových kódů tak i z ekonomického pohled)
• pomalé schvalování úkolů (někdy i v řádu týdnů tam, kde by feedback mohl být v minutách)
• složitý deployment (podporuje vznik chyb, ztěžuje jeho samotné provedení, trvá dlouho)
• správa kódu, která brání radikálním změnám
• testy odhalená chyba je dlouho neřešená

A dalo by se pokračovat.

Firmy se zbytečně připravují o spoustu času, kdy by mohli všichni členové týmu pracovat na něčem novém. Výsledky se dostávají k zákazníkovi pomalu, s chybami a je s tím spojený zbytečný stres.

Učím proto několik postupů, které optimalizují procesy směrem k produktivitě a zároveň kvalitě.

Například psát správně zadání úloh tak, aby byly správně informativní, skvěle testovatelné a neodporovaly realitě. Nebo jak kontrolovat úkoly tak, aby se dařilo nahrát kód z první a zákazník byl spokojen. A jak dělat správně deployment. A jakou zvolit strategii deploymentu a jak ji realizovat.

Co se infrastruktury týká, rohodně platí řčení o kovářově kobyle, tedy že i velmi technologické firmy mají nedotaženou infrastrukturu.

Co se na školení naučíte?

Jak zkvalitnit svou práci s jQuery tak, aby se celý návrh nerozpadl ve chvíli, kdy aplikace trošku vyroste. Zároveň jak psát svůj kód tak, aby byl znovupoužitelný i na jiných projektech.

Nejdůležitější nástroje pro psaní AJAXových aplikací (pro vývoj, ladění, lint, deployment)

Jak psát pomocí MVC v Javascriptu a jak navrhnout architekturu webové aplikace

Programování pomocí událostí a jak ho využít

Zjednodušení aplikace pomocí namespaces a explicitních závislostí

Jak psát testy v Javascriptu

Continuous Integration

Jak zrychlit aplikaci v Javascriptu

Školení bude mít řadu přesahů, například Coffeescript, Google Closure, obfuscace a další.

Pro koho je?

Školení je pro každého, kdo ovládá přinejmenším základy syntaxe Javascriptu až po ty, kteří píšou v JS rozsáhlejší aplikace. Pevně věřím, že v ČR si s Danova školení má co odnést naprosto každý webový vývojář.

Zde je stránka školení javascriptu.

Objednávejte na otevřený termín, já vás budu včas kontaktovat a vybereme termín, který bude vyhovovat všem účastníkům.

Jenže čas od času si asi každý člověk dá předsevzetí. Taková ta novoroční předsevzetí: přestanu kouřit, naučím se anglicky, zhubnu, nebudu koukat na televizi, začnu běhat…

A pak opravdu začne. Od začátku to tlačí silou vůle a je odkázán selhat. Proč? Vůle, ať už máte jakoukoliv, je poměrně omezený zdroj síly a co je nejhorší – vůli dělat X si nejlépe doplníte děláním negace X (hubnutí vás třeba dovede k tomu, že sníte půl dortu, pak si to vyčtete a nastoupíte ještě drsnější dietu, ve které selžete).

Pokud člověk chce změnit své návyky, potřebuje k tomu systém, který není postavený na vůli.

Jedním z postupů je: prostě začít a neřešit to. Říct: odteď nejím víc než 1500 kalorií denně.

Ale ikdyž se problém dokáže transformovat z roviny vůle do roviny „toto je můj nový životní styl“, hrozí selhání. Konkrétně hroí selhání proto, že člověk je najednou vystaven novým procesům, okolnostem a je nucen trávit čas mimo svou komfortní zónu, což ho vysiluje.

Pokud má člověk uspět v nějakém předsevzetí nastálo, musí si vybudovat návyk vystoupit ze své komfortní zóny a pohybovat se mimo ni vždy, když je to výhodnější.

Což je ale opravdu vysilující. A tak je potřeba trénovat. Zezačátku třeba 5 dní.

• Je vám nepříjemné telefonovat potenciálním zákazníkům? Zavolejte denně pěti.
• Neumíte se seznamovat? Oslovte na ulici každý den cizího člověka.
• Bojíte se přijít o práci? Zkuste žít pět dní s naprostým minimem nákladů.
• Vstáváte v 11? Zkuste vstávat v 6.

Člověk se musí naučit fungovat mimo svou komfortní zónu a tím získá několik nových schopností:

• tam, kde už není vůle, pořád ještě figuruje zvyk toho, že člověk se musí vyrovnávat s neznámými situacemi
• rozšíří se okruh komfortí zóny a do čeho se dřív člověk nechtěl pustit proto, aby tu svou zónu neopustil, už teď nedělá problém.
• nové zážitky, poznaní lidé apod.
• často i zjištění, že jste se něčeho báli zbytečně

Nespoléhejte na vůli, ta je krátkodobá a živí se opakem toho, co chcete vůlí dosáhnout. Spoléhejte na dlouhodobé zvyky. Ty zvyky pilujte praxí a neustálým vystupování ze zóny, ve které je nám dobře.

I pro firmu, která vytváří web je to pohodlné. Udělá napojení a všechny ty eventuality, jako změnu hesla, zaslání nového hesla, bezpečnostní otázka, registrace atd. programuje někdo jiný. Ušetří se tím docela dost práce (ano, naprogramovat to jednoduše netrvá dlouho, vychytat GUI a procesy okolo až tak snadné není).

Jenže vše není tak růžové.

Zaprvé: automaticky svou službu omezujete na uživatele jiné služby. Ano, Facebook nebo Google Account má dnes téměř každý, to za několik let nemusí být pravda.

Za druhé: jak souvisí můj web např. s Facebookem? Tím, že si dám na stránky login přes Facebook, uživatel nejspíš bude očekávat nějaký další důvod za tím. Tedy když budu např. programovat aplikaci na analytiku na Facebooku, dám tam přihlašování přes FB ihned. Pokud budu psát internetové bankovnictví, eshop se zahradníma hadicema nebo software pro GTD, uživatel bude poprávu zvědavý, proč se má přihlašovat právě Facebookem.

Za třetí: to nejdůležitější nakonec. V user testech jsme v two bits zjistili, že uživatelé jsou extrémně neochotní se přihlašovat přes Facebook. Zjevně je to tím, že už se několikrát spálili s různými aplikacemi, za druhé na FB má každý své osobní údaje, lidé jsou kolikrát neochotní povolit přístup, ikdyž aplikace chce přečíst jen e-mail. Tím, že Facebook neustále mění pravidla soukromí, nedává svým uživatelům taky moc velkou důvěru, že povolení k základním údajům nebude o rok později něco naprosto odlišného.

Takže ve výsledku dopadnete tak, že k tomu FB, Google Accountu nebo Twitter loginu musíte přidat i svoji vlastní registraci, zapomenuté heslo, login, logout a protože se jedná o kombinaci, problém se nezjednodušší. Ve skutečnosti je pak vše složitější. Musíte řešit spojování účtů. Změny údajů na FB, dvojitou databázovou strukturu a další.

Pokud na svém webu máte nějakou funkcionalitu, která by se dala považovat za social networing (tlačítko Like opravdu nepočítám), dejte si tam klidně nějaký způsob přihlašování přes sociální síť. Ale vždy musíte mít i starý klasický způsob, jinak o spoustu lidí přijdete při konverzi z anonyma na uživatele.

Stalo se to, co jsem čekal a přesto mě to šokovalo. Skenoval jsem si čas pořádně týden (nakonec úplně jinak, než jsem si původně myslel) a výsledky ukazují na něco pro mě velmi zajímavého. Dnes se budu věnovat výkonnost při práci.

Takže jaké jsou výstupy:

Běžně jsem se vydal pracovat na asi 7 hodin denně.

Skutečnost je taková, že den, kdy jsem toho udělal spoustu, normálně a nebo málo je dané jen a pouze jedním ukazatelem. Kolik času jsem byl schopen pracovat bez vyrušení delší dobu (alespoň 45 minut). Pracovat znamená fungovat ve stavu, kdy nemám nikde na pozadí žádné další okno, jsem jen já, problém a řešení.

Skvělý výkon jsem měl, když jsem vydržel pracovat 3 hodiny denně. Průměrný výkon jsem měl, když jsem vydržel pracovat 2 hodiny denně. Špatný výkon jsem měl, když jsem vydržel pracovat 1 hodinu denně.

Rada teda zní, hned ráno se pustit do práce aspoň na 1 hodinu. Do oběda stihnout další hodinu. Ještě než se člověk naobědvá, už má minimálně průměrný výkon v kapse.

Zbývající „taky-práce“ má cenu maximálně půlhodiny soustředěné práce.

Výsledek? Ano, stačilo by poloviční množství času, kdyby člověk byl schopný pracovat nonstop. Naučil jsem se proto nastavit si pomodoro na jednu hodinu a pokud vím, že nemám možnost pracovat celou hodinu, dělat pomocné úkoly (jednoduché úlohy, administrativu, udělat daily standup). Jakmile se vynoří časový rámec, kdy můžu dělat hodinu jen tak sám, je nachystáno na to udělat třetinu denní práce (pokud jako já chcete podat skvělý výkon).

Pracuju každý den, tedy i o víkendech. Když si za den najdete 2 hodinky, uděláte práci jako za běžný pracovní den (opravdu). A ještě můžete být na cestách, sportovat, jít do kina apod.

A jakým způsobem se u toho organizuju? Mám svůj systém, který hodně velkou měrou zatočil s potřebou chodit na sociální sítě/číst blogy apod. ve vymezeném čase pro práci. Ten systém tady někdy popíšu (a nebo si ho možná nechám pro školení gtd). Ve výsledku má člověk před sebou hromadu úkolů a je během dne schopen třeba půlku zredukovat. Spousta z nich nemusí být právě příjemná práce.

Tajemství je v tom najít si chvíle, kdy je člověk jen se svým problémem a nesoustředí se na nic jiného, než jak ho překonat.

Pár dalších dobrých triků:

• pořádně se nasnídejte, když má člověk hlad, nemůže se soustředit
• nedávejte porady doprostřed dopoledne/odpo­ledne, máte stoprocentní šanci, že se tím někomu trefíte do produktivní zóny (místo toho to nalepte na jednu stranu oběda)
• naučte se věnovat práci 60 minut, jen pracovat, jakmile dokončíte úkol, nabrat si další
• máte-li před sebou problém, který vypadá jako půlhodina extrémně nechutné práce, nastavte si 10 minut a pracujte na tom těch 10 minut. Kolikrát zjišťuju, že problém dělám dlouho, protože se na něj nechci soustředit. Za 10 minut se obvykle ta nejnechutnější část dá udělat a pak už to jde samo.
• první úkoly jdou hrozně rychle, ty poslední naopak moc ne, člověk má totiž tendenci spotřebovat všechen čas, který je mu dán

V blízkém čase chci víc experimentovat s krátkou pracovní dobou prováděnou naplno a s různými délkami. Zajímalo by mě, zda bych byl schopen dvouhodinového pomodora.

V čem to spočívá?

Udělá se vám geniální nápad a chcete ho zrealizovat. Čím rychleji, tím lépe. Ale počkat! V tuhle chvíli byste se měli zastavit, zamyslet a popřemýšlet nad tím, jak bude na webu probíhat interakce.

Chyba by byla sednout, vyrobit tabulky v databázi a hned si vygenerovat CRUD. V prototype-driven developmentu si naopak nejdřív ze všeho vyrobíme prototypy.

Co takový prototyp obsahuje?

Seznam všech stránek

Seznam všech ovládacích prvků na stránkách

Definici průchodů mezi stránkami

Co získám tím, že se budu dělat s prototypy?

Hned od první hodiny mám určitý základ pro testování použitelnosti. Můžu to jít ukázat kamarádům (aby mi řekli, že je to blbost, hned zezačátku). Můžu s tím utíkat třeba na za potenciálním investorem (a pokud se mi něco povedlo už v minulosti, mám šanci, že na to nějaké fondy získám). Taky má člověk testování interakcí. Vidí přibližně ohyb stránky a tuší, že tady na to tlačítko už mu lidi klikat nebudou. Je možné začít myslet na konverzní trychtýř ještě předtím, než se naprogramuje byť řádka nebo utratí halíř za grafika.

Důležitým prvkem, jak šetřit peníze při vývoji jakéhokoliv software, je možnost selhat rychle, odhalit chyby, poučit se v rané fázi a pokračovat bez velkých následků dál. Chyba objevená už v prototypu stojí zdaleka nejméně peněz.

A když mám tedy prototyp, co s ním udělám?

Zhotovím HTML podle prototypu a prototyp pošlu i grafikovi. Teprve potom se doplňuje funkcionalita na backendu.

O backendu platí, že tak jak se v TDD programuje minimální kód, který projde testy, zde se vyvíjí minimální funkcionalita (třeba s testy), která projde prototypem.

Člověk nepoužije generovaný CRUD tam, kde je výsledek až příliš odlišný, ušetří si tím čas. Taky už má člověk hned šablonu, hned při vývoji vidí, že občas bude nevalidní formulář a prototyp s tím nepočítá atd. a tak si vyžádá aktualizaci.

Jakmile se zrealizuje logika a grafika, projekt se deployne. Mezitím je možné na šablonách dělat testy použitelnosti. Tripomatic, který jsem tu už dříve popisoval, máme pokrytý celý prototypy. Jakmile je součástí zadání wireframe, mám daleko větší jistotu, že to i jako programátor udělám dobře (ve spojení s tím, že mám nějaké classy, které v různých situacích automaticky dávám k nějakým prvkům, je výsledek téměř hned nastylovaný a kolega s grafickým citem udělá jen doladění a to ne vždy).

A jak na průběžný vývoj?

Prototyp je živý stejně jako šablona projektu. Může se měnit a taky se mění. Vždy při změně (ne doplnění) zadání se vytvoří kopie a zařadí se do následujícího sprintu. Pokud se tedy bude GUI nějaké stránky měnít, na příští iteraci už mám jistotu, že vím, jak to bude vypadat a chovat se.

Prototypy na další sprint vznikají v průběhu současného sprintu, je možné je kritizovat. Zároveň se vytváří dva prototypy pro situaci, kdy buď je nějaký výpis prázdný (vidím ho poprvé), nebo už jsou v něm data. Vyhnem se tak hloupé situaci, kdy prázdný výpis rovná se prázdná tabulka jen s názvy sloupečků.

Závěrem jaké nástroje se dají dobře používat?

Osobně používám Omnigraffle Professional a papír s tužkou. Dál můžu doporučit MockFlow (je ale bohužel v Airu), Axure (nejdražší, ale asi nejlepší prototypovadlo na světě) a Balsamiq Mockups (prototypy vypadají docela hezky).

Seiton říká, že každá věc má mít své místo a má být na svém místě.

Zní to strašně jednoduše, ale v reálu to není příliš dodržováno. Tak jako doma bychom měli pro každou věc mít své místo (mýdlo patří do koupelny a vrtačka do dílny) a mělo by to na svém místě skutečně být, totéž platí i o kódu.

Správa dat do modelu. Šablony k šablonám. Přesměrování do controlleru. Testy ve složce s testy a jejich seed data přiložená poblíž.

A doma všechny faktury u faktur, věci kolem nájmu ve své složce, záručáky u záručáků.

O co přijdeme, když přestaneme Seiton dodržovat?

Když tu věc potřebujeme a nenajdeme ji na svém místě, je to jako bychom ji neměli. A musíme jít, věc si koupit, kód doprogramovat a otestovat – a nebo hledat, dokud neobjevím v nějakém nelogickém místě. Ve skutečnosti je to ještě horší. Najednou se nám věci/kód duplikují a musíme je udržovat.

Předpeklí porušení zásady Seiton jsou v kódu třídy/jmenné prostory Util. Kdekoliv jsem je viděl, našel jsem tam pár kusů kódu pro práci s datumem, měnou, stringy a vše z toho se dalo velmi dobře pojmenovat a přemístit do jmenného prostoru, kde by je člověk hledal.

Obdoba v domácnosti? Krabice na „cokoliv, co nevím kam dát“. Dvě taky mám (už brzo půjdou z domu), jsou plné kabelů, papírů a malých dárků, které jsem kdysi dostal. Nic z těch věcí už nepotřebuju – cokoliv jsem mezitím potřeboval, jsem hledal jinde a vše jsem ponahrazoval.

Máte i vy ve svém kódu Util nebo doma krabice na věci, které nemají místo? Zbavte se obojího. Věci se vám budou hledat lépe a snáze zjistíte, kolikrát máte všechno zduplikované a čeho všeho se můžete zbavit.

Tak například: Už jste někde na světě potkali stát, kde by by bylo více hostingů pro Ruby než pro PHP? Už jste někde na světě potkali stát, kde by bylo více webových programátorů pro Python než pro PHP? Už jste někdy potkali stát, kde by vývojář v .NETu dělal weby rychleji než PHPčkař?

PHP je nesmírně vyspělá platforma. Pamatuju si své eskapády s Ruby. 2 dny jsem kompiloval MySQL driver. Pak jsem zjistil, že neumí multithreading (resp.umí ale stejně to padne do jednoho vlákna). Multithreadovaná verze taky pořádně nefungovala. Data Mapper jako první věc po instalaci hodil Segmentation Fault. Nic z toho v PHP nezažijete (pokud nechcete psát něco pro např. Sybase).

PHP nahrajete kdekoliv. Nepotřebujete SSH, nepotřebujete dedikovaný server, nepotřebujete virtualizovanou mašinu, nemusíte být v žádném sandboxu, nic! Ten jazyk je navržený pro web a na webu běží.

PHP jako jazyk je ohromně produktivní. Má sice C-čkoidní syntax, což implikuje spoustu zbytečného kódu navíc, ale je snadno pochopitelné, rychle naučitelné a poměrně předvidatelné. Syntax se navíc (pro někoho bohudík, pro jiného bohužel) moc nemění.

Zároveň má PHP 3 velké nevýhody:

Knihovna funkcí – je bastl bez logiky pojmenování. Kéž by existoval někdo, kdo veškerou funkcionalitu zabalí do objektů a udělá to součástí PHP. Funkce by fungovaly dál, nový kód by se ale mohl začít psát objektově.

Nesolidní vývoj – na vývojáře PHP se nedá moc spolehnout. Vyjde verze a hned se doporučí ji nestahovat ani neinstalovat. Ikdyž PHP neprojde vlastními testy, stejně je vydáno. Není předem řečeno, jak se změní chování embed funkcí a tříd. Slíbí se podpora UTF a pak se stopne.

PHP je jazyk umožňující objektové programování, není ale objektově orientovaný – nejvíc mi vadí existence primitivních typů. Nemůžu udělat method chaining u primitivních typů, nemůžu si string nebo pole rozšířit o vlastní metody.

Závěrem tedy chci říct, že má smysl PHP se naučit. Člověk získá vyspělou platformu, extrémní rozptyl hostingů, které jsou vhodné od webovky s 5 stránkami a 1 formulářem až po masivně škálované aplikace. Než člověk z PHP vyroste, to trvá spoustu let. Celou tu spoustu let může člověk dělat skvělou práci a mít výsledky a neřešit hlouposti typu: „kde to budu hostovat, když zkrachují ty (snad) 2 existující české Python nebo Ruby hostingy“ nebo „kde vezmu peníze na Visual Studio, až mi Express přestane stačit“.

Veřejné školení testování

Toto školení by se mělo jmenovat spíš „školení předcházení chyb a práce s chybami při vývoji software“. Na školení se studenti dozví, jak je testování obecně nalepené na principy objektového programování, jak chyby vznikají a proč a jak nastavit procesy, aby se chybám předcházelo a aby psaní testů bylo pro jejich business ekonomicky výhodnější, než testy nepsat. Navíc se na školení studenti naučí ovládat PHPUnit, psát testy databáze a plno dalších tipů.

Školení je vypsáno na 14. září. Přihlásit se na školení můžete tady

Veřejné školení GTD

Getting Things Done dává člověku určitý rámec, jak má podstatně zvýšit svou produktivitu. Problém je v tom, že systém je docela komplexní a je potřeba ho implementovat celý a nějakou dobu ho praktikovat, než dovede uživatele k tomu, co slibuje: tedy ohromné zlepšení kontroly nad svým životem, úspěch, větší produktivitu a pořádek a klid v životě.

Já jsem se rozhodl svým studentům tu cestu zkrátit tím, že je naučím důležité návyky, a přivedu je na proces, který vede k bezproblémovému zavedení GTD tak, jak má fungovat – tedy celý pohromadě.

Byl vypsán otevřený termín. Přihlásit se na školení můžete tady

Mimo tato školení nabízím i firemní školení, zaměřená na Scrum, testování a Zend Framework.

Jenže jakmile zastánce NoSQL slyší růst, začne se ohánět škálovatelností. A celá diskuze potom dopadne v bahně toho, že když něco používá Google, Facebook, Youtube, nebo Amazon, „musí na tom něco být“. Logika, podle které je kamion nejlepší dopravní prostředek. Výsledkem je, že (naštestí malá) část vývojářů se potom snaží nasazovat Mongo, Couch, nebo Postgres, Firebird na malé aplikace.

Já jsem přesvědčen, že 80 % toho, co je dnes online, by si poměrně pohodlně vystačilo s ukládáním dat do souborů v nějaké serializované formě (JSON? XML? YAML? serializované PHP?). Na jednom z projektů, na kterém teď v node.js dělám, jsem měl taky ona cukání dát tam Mongo. Jenže na takovou maličkost, která poběží 2 měsíce, přijde na ní všehovšudy 1000 lidí, tam je omezení platforem, které budu muset spravovat, velká výhoda. A tak ukládám data v JSONu do souboru.

Implicitní očekávání, že na každém projektu v PHP musí být MySQL (nebo jeho obdoba) je hloupé. Obdobné implicitní očekávání, že na každém projektu v Rails nebo node.js, bude nasazeno NoSQL je stejně špatné.

Špatné jsou i časté argumenty pro a proti SQL a NoSQL. Ano, MySQL je všude. Právo zápisu na disk ale taky. Ano, SQL umí každý. Zapisovat do souboru umí taky každý. Ano, alter table může na databázi v gigabajtech trvat věky – argument pro NoSQL. Realita: málokdo má databázi s gigabajty dat (které nutně potřebuje a dělá přes ně denně selecty). A když, tak má takovou jednu, dvě tabulky, ne 80 % tabulek v databázi.

Pokud vůbec nevíte, jestli bude váš projekt úspěšný, udělejte rychle prototyp. Data nahrňte klidně do souborů, hlavně něco vydejte a dostaňte odezvu. Ve výsledku téměř vždycky potřebujete naprogramovat něco úplně jiného, než jste si na začátku mysleli (třeba Tripomatic jsme ještě před prvním veřejným releasem předělali podle user testingů úplně čtyřikrát a rewrite 5 bude následovat). Teprve když víte, co máte programovat, sníží se frekvence změn struktury databáze (pokud přejdete na SQL), případně materializovaných pohledů (pokud přejdete na NoSQL) – tehdy vyberte, kam budete ta data ukládat podle skutečných priorit, které řešíte.

A tak jsem se rozhodl, co musím udělat. Zkusit si den, dva, týden sledovat, co dělám a kolik času mi to bere, v druhém kroku i to:

• kolik z celkového času jsem vytvářel pro lidi hodnotu
• kolik z celkového času jsem dělal úkoly, které podpořily tvoření hodnoty
• kolik z celkového času „jsem zcela žil“
• kolik z celkového času jsem byl naopak smutný

A co se s tím dá potom dělat?

Jsou tři cíle a každý z nich vyžaduje svoje.

1. Zdvojnásobení produktivity
2. Trávit minimum času „čekáním na život“
3. Netrávit čas tím, co mě činí nešťastným

Zdvojnásobení produktivity

Každý člověk vytváří skutečnou hodnotu (a úkoly, které to podporují) jinou dobu ve svém dni. Někdo 2 hodiny, někdo půl hodiny a někdo třeba 8. Pokud jsou to dvě hodiny, mohl bych vypuštěním zbytečností udělat čtyřikát tolik práce. Pokud šest hodin, pořád si můžu polepšit o třetinu. Nebo bych mohl pracovat kratší dobu, nebo od obojího.

Cílem tedy je objevit procesy, které přinesly hodnotu a ty dělat tak dlouho, dokud mě to bude ten den bavit.

Nečekat, až život začne

Žiju podle svých představ, cestuju, poznávám lidi (na školeních bývají obvykle velmi chytří lidé), hodně čtu, kreslím a mohl bych pokračovat. Nevím, jestli na život někdy čekám, já si to nemyslím. Ale proč to nezměřit, nezjistit, třeba jsem na tom tak, jak říkal Sokrates v citátu na začátku tohoto článku.

Odbourat zlo

V životě toho všichni zažíváme hodně špatného. Něco z toho je nezbytné a s tím se nedá nic než jen smířit. Ale pak je tu plno věcí, které si způsobujeme sami. Myslím, že člověk je sám sobě největší nepřítel a za většinu toho špatného, co se nám stane, si můžeme sami. Hodně zlozvyků, okolí, které mě ohrožovalo nebo činilo nešťastným, jsem se zbavil. Ale tohle je něco, co nemá žádný konec, proto i s tím budu pracovat.

Nástroje skenování

Abych si ten svůj čas dobře naskenoval, potřeboval jsem nějakou aplikaci, která může běžet nonstop, bude dostupná kdekoliv (i na mobilu), bude možné tam přidávat záznamy, které si napíšu na papír a bude se skvěle používat (otevření 1 klik, přepnutí kontextu na 1 klik, určení štěstí/neutrál/neš­těstí 1 klik).

Jak jsem to vyřešil?

Zatím jsem si napsal jednoduchý prográmek do mobilu (pojmenoval jsem ho LifeScanner). Po pár dnech si výsledky pošlu na web a ručně je dám dohromady s textovými popisky. Aplikace je extrémně jednoduchá. V podstatě se jedná o dva formuláře, v prvním nastavuju, co dělám a v druhém, jak se mám.

Aplikace je pouze JavaScriptová (tedy CoffeeScriptová) a ukládá všechny změny do lokálního uložiště přímo na mobilu. Až budu chtít údaje vytáhnout, doplním do stránky odeslání POSTem a výsledky si vyparsuju.

Zdrojový kód nástroje LifeScanner jsem dal k dispozici na bitbucket, licence je GNU/GPL. Celý prográmek je extrémně jednoduchý a k jeho provozování nyní nepotřebujete ani PHP, pouze browser schopný HTML5 localStorage. Až budu získávat údaje, přidám na bitbucket i kód pro stažení dat.

Zatím mám za sebou jeden a půl dne sledování a opravdu hodně zapomínám měnit kontexty. Budu muset nejdřív vypilovat stav vědomí toho, že právě měním činnost a měl bych to nějak zaznamenat.

Brzo popíšu své výsledky. Stay tuned.

Stát se minimalistou. Co to obnáší?

Vzít do ruky každou svou věc a zeptat se sama sebe

• potřebuju to nutně?
• nemám to víckrát? nemám něco, co mi problém už vyřeší?
• když odhlédnu od vztahu k dané věci, skutečně mi k něčemu je? pamatuje si ten člověk vůbec, že mi tu věc dal?
• kdybych si pořídil 1 věc, mohl bych vyhodit 4 objemnější a méně univerzální?

Tím, že se vše vyprázdní, tím to nekončí, ale začíná. Věci člověku berou čas, berou mu koncentraci, staré věci, které jsem považoval za užitečné a teď se na ně práší. Když člověk zredukuje vše na kost, najednou má více prostoru, více peněz, více světla, více času a více koncentrace. Co s tím?

Dal jsem si za cíl naplnit svůj svět tím, co považuje za skutečně cenné: lidmi, zážitky, cestováním bez dvacetikilových zavazadel (do USA jsem jel s docela obyčejným baťůžkem). Místo hromadění věcí nových věcí běžné kvality budu radši zvyšovat kvalitu těch, o kterých vím, že je skutečně hodně chci.

Počítejte se mnou:
90 dní, to je tak 90 hodin bez získávání zpravodajských informací

Získáte 5 dní v bdělém stavu (pokud jako já spíte 6 hodin, 5 a půl dne, pokud spíte déle)
Za tu dobu se poměrně naučíte node.js a psát testy v CoffeeScriptu (jako jsem to udělal já)
Naučíte se 900 slovíček cizího jazyka
Naučíte se řídit ultralight a složíte pilotní zkoušku
Znatelně zlepšíte svou postavu v posilovně
Přečtete 6 knih

A co jsem ztratil? Nemám pocit, že bych o cokoliv přišel. Noviny tady nejsou od toho, aby nám daly informace nutné k přežití – tyto informace nám dá nejbližší okolí. Noviny jsou tady od toho, aby bavily člověka (a když se podíváte na běžné zpravodajství na Nově, tak je to zábava docela morbidního charakteru).

Smysl má získávat informace trvalého charakteru, ty totiž můžeme využít celý život.

Několik technologií okolo node.js (a CommonJS obecně) opravdu stojí za to, vezměme si třeba:

• CoffeeScript – minimalistický jazyk, který šetří práci, zdroják a výsledkem je čitelnější kód
• Sockets.IO – využití WebSockets tak, jak to v PHP asi nikdy nepůjde
• Now.JS – sdílení proměnných mezi klientem a serverem pomocí sockets.io
• CoffeeKup – šablonovací jazyk napsaný přímo jako CoffeeScript
• Kyuri – port nástroje pro BDD Cucumber ze světa Ruby (který generuje stories pro další zajímavý nástroj vows)
• Express – port frameworku Sinatra z Ruby, jen daleko rychleji (a obdobný, kulervoucí framework Zappa)
• Sinon – mockovací knihovna, která je opravdu jednoduchá na použití

Všechny zmiňované technologie můžete snadno nainstalovat pomocí NPM (weby a githuby projektů vyhledáte snadno v NPM Searchi ).

Myslím, že než bude node.js webovým jazykem číslo jedna, uplyne ještě spousta času (třeba 8–10 let). Na druhou stranu ještě tak rok a vynoří se solidní hostingy (třeba za hranicemi, ale budou) a nebude velký problém začít psát v JavaScriptu server-side poměrně běžně.

Co tím získáme?

• Sjednocení na jeden jazyk (a tím si dovolím skromně tipovat CoffeeScript)
• Extrémní výkon (už brzo srovnatelný s C)
• Hned od začátku budovaná komunita, ve které je zvykem testovat
• Deployment pomocí gitu (PHPFog budiž čestnou výjimkou).
• Proti PHP lépe udělané objektové programování.
• Metody jsou lépe utříděné a dokumentované.

Já se na budoucnost webových technologií ohromně těším, když srovnám svou práci před 5 lety, vzpomínám, co všechno nebylo a teď je, mám z toho radost.

Princip 5S se skládá (velmi velmi zjednodušeně) z následujích bodů:

• Seiri – mám jen to nezbytné pro svou práci
• Seiton – je to, co nezbytně potřebuju na svém místě?
• Seiso – je to, co používám v pořádku, čisté, připravené k použití?
• Seiketsu – existuje systém, podle kterého se mají věci zařazovat?
• Shitsuke – je tento systém dodržován a průběžně zlepšován?

A jak se to dá aplikovat na programátorský editor?

Seiri dodržujeme tehdy, když nám editor nabízí jen to, co skutečně potřebujeme. Znamená to, že v menu je jen to, na co klikáme. Pro co existuje klávesová zkratka (pokud je využíváme což bych rozhodně doporučil), tam není nabídka v menu. Formuláře IDE nemají žádné zbytečné položky (zbytečné pro nás, byť pro jiného by mohly být užitečné.

Seiton platí, když je pořádek v menu i v dialozích, vše je ucelené a když nějaké klávesové zkratky v systému fungují určitým způsobem, budou podobné zkratky fungovat obdobným způsobem.

Seiso je v pořádku tehdy, když editor zbytečně nepadá, všechny funkcionality fungují tak, jak očekáváme a nestává se nám, že by se nám zničila data.

Seiketsu nám říká, že když si ten editor rozšíříme, zda je zařazení pluginů logické, dodržuje systém, která je pro nás použitelný a zapadá do logiky editoru.

Shitsuke do toho jen přidává, zda sami svému editoru prospíváme, zjišťujeme, jak průběžně vylepšovat ostatní S a zda umíme kriticky zjistit, zda mi prostředí vyhovuje, nebo (v lepším případě) vidím, co zlepšit a mám sílu to provést (a skutečně to průběžně dělám).

Podívejte se níže na reálnou obrazovku mého MacVimu, na kterém pracuji (fullscreen bez čehokoliv jiného na celém monitoru, zatímco se přepínám mezi fullscreen shellem, na kterém mi běží testy a make).

O tom, že dodržuji seiri není pochyb, vidím jen název souboru, otevřené soubory, pozici v souboru a zdrojový kód. Víc toho nepotřebuji. Všechno, co potřebuji je i na svém místě. Ve chvíli, kdy se přepnu do insert módu, v místě, kam bych psal command, je napsáno insert, perfektní pro rozlišení, kde se zrovna pohybuji. Seiso mi říká, že mám mít vše funkční – a světě div se, ono všechno funguje, jak má. Občas se ve vimu stane, že spolu některé pluginy nefungují, pak se je snažím upravit nebo nepoužívat a najít fungující náhradu. To se mi zatím daří. Seiketsu mi říká, že má existovat nějaký systém v chování pluginů. Nahoře mám výčet otevřených souborů. To je logické. Po stisknutí Ctrl-C se mi otevře Project View nalevo s výpisem souborů – to je taky naprosto logické.

Co se Shitsuke týká, samozřejmě je plno věcí, které je potřeba pořád zlepšovat:

• NERDTree (Project View) se musí vypnout a zapnout, když promažu buffery
• FuzzyFinder (rychlé hledání souborů podle psaní kousku cesty a názvu souboru) mi nefunguje
• ConqueTerm (příkazová řádka jako okno ve vimu) funguje opožděně
• debugger PHP funguje extrémně špatně

A plno věcí, které jsem zlepšil v poslední době:

• přemapoval jsem v insert módu kk (dvojitý stisk k) pod uložit a opustit insert mód
• přemapoval jsem v insert módu jj (dvojitý stisk j) pod uložit a vrátit do insert módu
• mám taky rychlé zkratky pro make, přeložení CoffeeScriptu do JS přímo pod výběrem a další

Jak tak zhodnocuji systémem 5S všechny nástroje a postupy, zjišťuji, že v mnoha dalších oblastech ohromně habám svou produktivitou a pozorností a že používám nástroje, které sice jsou ve svém oboru asi nejlepší, ale pořád ne dost dobré. Je každopádně fakt, že aby člověk mohl aplikovat 5S v plném rozsahu, musí mít moc změnit své nástroje (a to i tak, že zbytečnosti vyloučí).

The Beauty of Emptiness

Krása prázdnoty

V prázdnotě nejsou komplikace, jen jednoduchost.

V prázdnotě není žádné zmatení, jen jistota.

V prázdnotě nejsou ceny, jen svoboda.

V prázdnotě není sobectví, jen jednota sebe sama.

V prázdnotě není odpad, jen efektivita.

V prázdnotě není znečištění, jen čistota.

V prázdnotě nejsou žádná vyrušení, jen soustředění.

V prázdnotě je krása.

…Vyprázdni prostor a udělej ho už dnes krásný.

Zavedení agile spočívá v aplikaci agilních principů. Nejsložitější a nejdůležitější je vybudovat agilní podnikovou kulturu, která bude otevřená ke změnám, která bude pouštět zákazníka na pracoviště, která zbourá komunikační bariéry a dá členům týmu jasně vymezená práva a povinnosti.

Být agilní znamená být rychlý, komunikativní, otevřený změnám a ne „dělat techniku XYZ, jak to psali v těch knížkách“. Žádné dvě firmy nebudou mít stejně nastavené procesy, nebudou stejným způsobem používat stejné nástroje.

Agilní metodiky a agilní techniky jsou jen určitou specializací, realizací agilního přemýšlení. Scrum, extrémní programování a další, to jsou velmi efektivní a kvalitní metodiky, které vedou k vyšší produktivitě práce. Na druhou stranu, agile je 90 procent Scrumu a jiných metodik a pokud nějaká firma nemůže Scrum použít, nic jí nebrání být alespoň agilní.

Na svém školení Scrumu a agilních metodik se zabývám především předáním hodnotových měřítek, zavedením principů, hledání kroků, které umožní realizovat i agilní manifest (který je bohužel napsaný nešťastným způsobem a je potřeba ho dobře chápat, aby se dal i dobře vyložit) a teprve potom jak zavést jednu z konkrétních implementací, tedy Scrum.

Je tedy jasné, že zavést agile není záležitost na týden. Předělat myšlení lidí a manažerské postupy může zabrat i měsíce nebo roky, než se podnik stane tak flexibilní a produktivní, jak to jen agilní metodiky umožňují. Ty rituály Scrumu (nebo XP) jsou v tom skutečně to nejmenší a jejich význam lidé v plném rozsahu ocení až tehdy, kdy fungují agilně nějakou dobu.

Přesto všechno věřím, že zavádět agile se vyplatí. Nejen, že se zvedne produktivita, radikálně se omezí chyby, zvýší se kvalita vývojářů, uspokojí se zákazník, ale všichni lidé v týmu mají rázem svou práci daleko radši.

Prokrastinace je:

• činnost, kterou dělám sám
• činnost, při které nedělám to, co jsem si předsevzal
• činnost, která je zajímavá, ale nevede mě k mým cílům
• u mě vždy spojená s čtením blogů, sociálních sítí nebo jiných „zajímavých byť neužitečných“ ob­sahů

A co jsem zjistil? Že v den, kdy nepracuju, neprokrastinuju. O víkendu jdu radši na procházku, hrát squash nebo si čtu knížku. Zvláštní, prokrastinace je u mě spojená s tím, že „si dám za úkol pracovat“ – zjistil jsem například, že když se nesnažím pracovat a jen tak ze zábavy si beru úkoly z GTD, prokrastinace se mi neděje. Neumím si to vysvětlit.

Zjistil jsem, že když mám zajímavé úkoly, prokrastinuji podstatně méně. To je ale logické, že? Zajímavé je, že když si zařadím mezi zajímavé úkoly i nějaké nutné, pořád nezačnu až do určité chvíle, kdy překročím nějakou hranici a pak se to rázem hodně zhorší.

Být v pondělí odpočatý vůbec nepomáhá. To mi taky zatím nejde na rozum. Rizikovým faktorem je i pocit zahlcení (nevím přesně, jak ho přeložit, v angličtině je pro tento pocit slovo exhaustion). A když mě to chytne opravdu hodně, nedonutím se ani nastartovat pomodoro. Dokonce mi nepomůže ani vzít si nějaký zajímavý úkol. Pomůže jen to, že se na hodinu odpojím od práce, od internetu, od prohlížeče a dělám něco úplně jiného – jenže kdo to může v průběhu práce jen tak udělat?

Prokrastinace je v podstatě práce/studium, která je neužitečná. A je tak zajímavá, že nemám potřebu „prokrastinovat uvnitř prokrastinace“ – tedy například v průběhu čtení článků o PHP nemám potřebu prokrastinovat čtením článků o lidském mozku.

Velmi zajímavý úkol mi zabrání prokrastinovat.

Při přípravě školení nebo při školení mě to nikdy k prokrastinaci netáhne. Dobrým způsobem, jak zabránit prokrastinaci, je u mě práce s více lidmi, nebo když jsem offline.

Největším rizikovým faktorem je, když buď dělám něco triválního, nebo když se naopak na nějakém problému zaseknu delší dobu. Také jsem zjistil, že když začnu ráno prokrastinovat, je větší šance, že se to potáhne až do odpoledne. Přechod na polyfazický spánek u mě vytvořil zónu mezi 22. a 24. hod., kdy jsem náchylný k prokrastinaci, když už nemám chuť dělat další úkoly, jdu spát, lepší spánek, než neužitečné zevlení na internetu.

Jak to řešit?

• nepracovat (dělat užitečnou práci nerovná se pracovat, nastavit se psychicky tak, že nepracuju, jen když mám chuť, dělám úkoly – ve výsledku jich udělám dost)
• nepracovat sám
• pracovat jen na středně složitých programátorských úkoláh, školení, konzultacích a code review
• dávat si hlavně úkoly, které jsou příjemné podobně, jako prokrastinace, byť nepřinesou maximální efekt
• pracovat hodně offline
• nastartovat pomodoro timer co nejdřív, nastavit pomodoro na 45 minut a udělat alespoň 3, pak už to jde celkem samo

Já si každé ráno připravím seznam úkolů na den. Některé z nich musí být příjemné (alespoň 50 procent činnosti). Snažím se nastartovat co nejdřív pomodoro timer.

Musím říct, že po aplikaci tohoto postupu, se mi podařilo prokrastinaci už skoro eliminovat, ještě mi zbývá ráno rovnou vstát a nedat žádnou šanci čtení blogů, RSS ani sociáních sítí.

Co vy? Jak na to jdete? Má vaše prokrastinace stejnou podobu? Jak se jí bráníte?

Pokrývač si nejdřív nanosí tašky a pak pokrývá. Vědec se snaží omezit vyrušování, protože by mohl udělat chybu. Prodavačka si počítá osmnáct, dvacet, čtyřicet, padesát a sto, aby to nespletla. Všichni používají určité „pracovní vzory“. Návrhové vzory jsou také „postupy při práci analytika a programátora“ – jen jsou zapsané přímo v kódu.

A teď se podívejme na známé typy návrhových vzorů:

Vzory týkající se tvorby objektů

Tyto vzory řeší problematiku, kdy v systému vznikají nové objekty a my nechceme (nebo nemůžeme) jen tak zavolat new bez následků. Návrhový vzor umožňuje snáze vytvářet podobné objekty, oddělit vytváření objektu od implementace, je-li to složité, umožňuje oddálit skutečné vytvoření až na okamžik, kdy je objekt skutečně použit, řeší situaci, kdy má být v systému práve jedna instance, nebo řeší správu paměti nad objektem.

Vzory týkající se struktury programu

Tyto návrhové vzory se obvykle týkají flexibility systému. Buď umožňuje snadno rozšiřovat kód o další varianty, nebo usnadňuje použití stávajícího zdrojáku. Výsledkem použití takového návrhového vzoru je například to, že nejsme závislí na jedné databázi, nebo že jsme schopni použít cizí knihovnu s extrémně zpraseným API lidsky.

Vzory týkající se chování

Tyto vzory jsou velmi variabilní. Často se ale týkají toho, že v OOP obekt zasílá zprávu a nám se může stát, že není předem jasné, komu tu zprávu chceme poslat, nebo kam přiložit další nutná data, které onen objekt použije. Zároveň takové vzory umožňují sledovat změny v objektech, dávat o nich informace dalším objektům v našem systému (nebo v testovacím prostředí).

Vzory řešící problémy vzniklé spouštěním programů ve vláknech a tudíž při souběžném řešení úlohy

Tyto návrhové vzory se zaměřují pravděpodobně tu nejtěžší činnost, kterou můžete při programování řešit. Na souběžně běžící kód, správu procesů, správu sdílených dat, případně slučování práce více vláken.

Proč by měl někdo návrhový vzor používat?

Nejen proto, že se jedná o prověřenou cestu. Něco takového je sice argument, ale nezabrání v tom, prošlapávat si svou cestičku a zkoušet objevovat nové vlastní vzory. S čím jsem se ale setkal a co mi přijde na návrhových vzorech skvělé, že dovedu popsat (a pochopit) systém mnohem rychleji.

Nejhorší (z toho, co jsem zažil, pominu-li experimenty s assemblerem) je strukturované programování, musím si pamatovat, co dělá která funkce v systému. Nad tím stojí objektové programování – stačí si pamatovat, jaké objekty mají jaké zodpovědnosti. Ještě výš stojí systém naprogramovaný s použitím návrhových vzorů – tam stačí pamatovat si, jak na sebe jednotlivé vzory v systému navazují. Úplně nejvýš stojí systém napsaný ve frameworku s použitím návrhových vzorů – tam je velká část aplikace jasná ze zvyklostí toho daného frameworku.

Co se jednoduše chápe, to se i snáze učí. A systém, který správně používá návrhové vzory a vhodný framework, se každý vývojář naučí mnohem rychleji. Zejména tehdy, kdy daný framework a vzory dobře ovládá. Předávání práce novému kolegovi je tak stane mnohem snažší, než by tomu bylo v neobjektovém kó­du.

Samozřejmě existují situace, kdy je nějaký návrhový vzor použit špatně (často je vypichován Singleton, já bych k němu přidal i Factory, který se často používá místo Dependency Injection). V tom je nejlepší odpovědí:

1. používat framework
2. mít dobrého analytika
3. refaktorovat a redesignovat průběžně a vzory, které se neosvědčily zahodit, nebo vyměnit

Nicméně s návrhovými vzory může začít každý. Doporučím, nezačínejte se Singletonem ani Factory, zaměřte se a naučte spíš tyto vzory: Adapter, Chain of responsibility, Observer, Inversion of Control, Strategy, Data Mapper a samozřejmě MVC. Ostatní už přijde samo, pokud máte čas při práci refaktorovat (což byste rozhodně měli), brzy se naučíte vzory používat správně.

80/20

Podobný motiv se prolíná i knihou Čtyřhodinový pracovní týden. Tahle kniha je ale jiná! Autor ukázal spoustu skvělých příkladů (20 procent kriminálníků páchá 80 procent zločinů, 1 procento lidí vlastní 50 procent majetku světa, 50 procent lidí vlastní 1 procento majetku světa). Princip knihy je zjednodušeně řečeno následovný:

„Vezmi to, co ti přibližně vydělá 80 procent peněz za přibližně 20 procent času a dvojnásob množství času, který věnuješ tomuto, zbytek eliminuj“ (těchto analýz je v knize více, včetně analýzy zákazníků, oborů)
„Vezmi to, co ti dělá největší radost, své nejlepší přátele, nejbližší rodinu a zdvojnásob čas s nimi“
„Zjisti, co tě nejvíc štve, deprimuje, bere ti čas a chuť do života a to maximálně omez nebo úplně vynechej“

Jsou to v podstatě jednoduché rady, které člověk slyšel už mnohokrát, ale nevím proč, stejně jsem celý život nevzal účetnictví a nešel po konkrétních poměrech typu 80/20, 70/30. Byl jsem plně zaujatý tím, co autor nazývá 50/50 thinking, tedy představa, že objem práce a peníze spolu úzce souvisí, že víc práce znamená lineárně více peněz. Neuvědomoval jsem si, že kolik dělám je velmi nepodstatný ukazatel ve srovnání s tím co dělám (já je měl hodnotově skoro na rovině).

Koch se ostře vymezuje proti time managementu (což dělá i Tim Ferriss v 4HWW). Autor tvrdí, že time management zlepší produktivitu třebas o 20 procent, zatímco 80/20 dosáhne výsledků se zlepšením třeba o sto procent. Nikdy neřeší kombinaci obojího. Škoda.

V knize autor dále zabývá tím, jak investovat na burze. Jeho strategie je dost Buffetovská: specifikuje nějaké ukazatele, na kterých hledá, kdy trh v panice jde dolu a dovede cenu až na podkoupenou a tam říká nakoupit. Na vystoupení z pozice používá trailing stop na 85 %.

Většina knih o sebepomoci, time managementu apod. je bullshit (o tom zas jindy) a i tato kniha obsahuje některé zbytečné pasáže. V pozdějších částech se začala dost opakovat a ta investiční strategie je na tu knihu dost divně napasovaná. Ať je to jakkoliv, soudím, že tu knihu stojí za to přečíst.

Jak prodat vycpaného žraloka za 12 milionů dolarů

Tahle kniha mě přesvědčila ještě víc, že kapitalismus je ten nejlepší systém. Bohužel iluze, které jsem dříve ztratil o investičních bankách (díky geniální knížce Cityboy), padly po této knize i o nejbohatších umělcích (především o Andreji Warholovi), galeriích, aukčních síních, dealerech umění a sběratelích. Autor se vydal do Londýna a New Yorku, největších metropolí umění na světě, do LA, mluvil se všemi skupinami, sbíral údaje a dává je do kontextu.

85 % umění se nikdy neprodá dráž, než se poprvé kopilo v galerii. Žádné (0.001 procenta) umění koupené v malých lokálních galeriích se nikdy nedostane do Christie's, Sotheby's a nikdy nebude mít větší cenu, než za jakou ji člověk koupí. Jakmile je umění vystaveno v dobré galerii, projde kvalitní aukcí, nebo ho sbírá známý sběratel, jeho cena se navždy zvýší. Ani existence v Christie's nebo Sotheby's není zárukou kvality. Polovina obrazů, která se před 30 lety prodávala v těchto aukcích (které jsou nejprestižnější na světě), dnes tyto síně odmítnou přijmout, protože se změnil trend, vkus a obrazy už nejsou dost umělecké (zní to divně, že?).

Značka umělce je důležitá. Milion korun stojí kožená bunda ležící v rohu přidělaná stříbrným řetízkem ke stěně. Vycpaný žralok vyrobený za 50 000 USD má cenu 12 milionů. Andy Warhola (a další) často nemalovali své obrazy, jen je podepisovali – a toto navíc dělá mnoho dalších umělců: sází jen na svou kreativitu a samotné řemeslné zpracování outsourcují. Wow!

Umění je komodita, ropa, kukuřice, Warhola, Hirsch, zlato, americké dluhopisy. Milionáři kupují obrazy, aniž by je viděli, nebo ikdyž se jim nelíbí – jen na radu agentů. Neplatí to tak o všech, někteří mají sbírky některého umělce, jiní ale jen „kupují značku“. Věděli jste, že v NY je mezi milionáři trendy mít v obývacím pokoji obraz, který stál stejně jako celý byt?

Jestli jste někdy přemýšleli, KDO a CO dělá úspěšného umělce a jestli je dnes vysoké umění nekomerční, přečtěte si tuto knížku.

Brain Rules

Tahle kniha mi hlavně pomohla trochu pochopit, jak funguje paměť a jak ji zlepšit. No a taky jak vykládat tak, aby si lidi víc věcí zapamatovali. Autor knihy John Medina je molekulární biolog a zkoumá mozek. Ve své knize nevyužívá téměř ničeho jiného, než odkazů na vědecké studie a proto ji považuju za opravdu lépe podloženou, než většinu ostatních knih.

Co ve své knize píše? Mimojiné, že:

• Fyzické cvičení je dobré pro mozek
• Lidské tělo strádá, pokud neujdeme denně 15–30 kilometrů (netušil jsem!)
• Mnoho příznaků stárnutí lze zvrátit – velká část osmdesátiletých lidí může mít pořád velmi dobrý intelekt a úsudek (a když člověk s mnoha příznaky stařecké demence napodobí životní styl vitálního důchodce, jeho mozkové funkce se obnoví)
• Telefonování za volantem i s hands-free prodlužuje reakční dobu jako alkohol
• Zapamatování se dá zlepšit opakováním ve správných odstupech (zvětšujících se)
• Zapamatování se dá zlepšit intervaly, kdy mozek vystavujem maximálnímu nebo neopak minimálnímu množství ruchů
• Jazyky bychom se měli učit v odděleném kontextu, třeba si udělat doma „anglickou“ místnost a v ní mluvit jen anglicky
• Ztráty pozornosti po 10 minutých lze zabránit pomocí tzv.„háků“, koncept je složitější, ale jde o to najít k tématu vtipnou historku, která propojí téma s tím, co řeší posluchač ve svém životě nebo praxi. Každých 10 minut je potřeba něco takového aplikovat a lidé si udrží pozornost i mnohem delší dobu.

Knížku pořád ještě čtu, nemůžu si na ni zatím udělat celkový názor. Pokud si chcete přečíst knihu, která se odkazuje na mnoho výzkumů o lidské mozku a vytahuje z nich zajímavá fakta, přečíst si o tom, kde v mozku je co uloženo a co udělá poškození té dané části mozku, nebo o tom, jak si lépe něco zapamatovat, toto je kniha pro vás.

Outsourcingem firma může sledovat několik zájmů, např.:

• zmiňované zjednodušení všech procesů ve firmě
• zbavení se nutnosti vlastnit a udržovat vybavení, které je složité na údržbu a drahé, nebo je v nejhorším případě téměř nevyužité
• snížení nákladů na pracovníka (je-li možné opakující se úkony přehodit na pracovníky z levnějších zemí/chudších měst)
• přesunutí zodpovědnosti (v případě chyby za ztrátu zodpovídá dodavatel)
• v situaci, kdy je potřeba pro určitou činnost zvláštní povolení (nebo existuje jiná bariéra vstupu) a podnik nechce do tohoto investovat úsilí

Někdy ale může dojít k tomu, že se outsourcing nevyplatí, často se dá vysledovat, že se jednoduše porušilo pravidlo na začátku:

Outsourcing jádra samotného podnikání

Jádro podnikání je to, co vytváří 80 procent příjmů. Je to to, co naplňuje misi a vizi podniku. Předat tuto činnost na jiné firmy (ikdyby měli lepší lidi, podmínky a prostředí) je ortel smrti. Taková firma má svou misi a vizi, má své potřeby a nic jí nebrání buď převzít celé podnikání svého klienta, nebo změnit své zaměření a jemu znemožnit pokračovat v podnikání.

Outsourcing toho, na co jsem si najal ty nejlepší lidi z oboru

Je jasné, že např. H1 si nenajme na SEO někoho nezkušeného. Použije vlastní lidi. Předmětem mých školení jsou agilní metodiky, agilní techniky, Zend (a od podzima pár dalších témat). A školím tyto věci s láskou, baví mě to, snažím se pořád zlepšovat (hodně mi pomohla kniha Nápady na ubrousku a možnost podívat se na školení jiných lektorů). Byl bych hloupý, kdybych se najednou rozhodl třeba školit ASP.NET (který spíš neumím, než umím) a najal si někoho, ať dělá za mě něco, co už umím.

Přesto věřím, že se většině podniků vyplatí outsourcovat část činností, které dělá (a to ikdyž by to zvádli vlastní zaměstnanci – ti mají ale za úkol řešit jádro podnikání). Místo spousty Núčelových všeschopných firem můžeme mít větší spoustu jednoúčelových firem, které dělají jednu věc pořádně (a zaměřují se na to, kde je jejich největší zdroj zisku).

Proč tohle tady vlastně píšu? Neplatí stejný argument i v jinde? Co třeba při návrhu objektů, zodpovědností a delegace?

Tady je hamburger uměleckým dílem, něčím, co se stává plnohodnotný oběd a ne jen „rychlé občerstvení“. V kvalitní hamburgrárně se vás zeptají, jak moc máte rádi burger propečený, nechávají si péct housky na míru, vyrábí si vlastní dressingy a kečupy. Maso je obvykle opravdu velmi jemné, často pilují směsi zkušení šéfkuchaři. Třeba v Go Burger používají výhradně směs různých mas z plemene Black Angus, výjimečně na některá jídla (ne burgery) maso z plemene Kobe. V méně kvalitní (třeba v Burger Kingu) dostanete opravdový obouručák, který těžko mačkáte a ještě hůř strkáte do pusy – v lepším podniku na tohle můžete rovnou zapomenout, burger vám třeba donesou už rozdělaný s příborem a obsypaný hranolkama (tady se jí hamburger buď s hranolkami, cibulovými kroužky nebo salátem). Hambáč je opravdu velký, když říkám velký, myslím VELKÝ (v ČR jste rádi za čtvrtlibrák, tady dostanete od 1/3 libry přes půllibráky až po 24 uncák (skoro třičtvrtě kila) ve Fatburgeru.

Opravdu vyhlášené podniky v L.A. jsou:

• Go Burger
• Umami Burger
• Tommy's Hambur­gers
• Fatburger
• Comme Ca

A našlo by se jich více (třeba Hawkins House of Burgers, kde dělají třípatrový burger asi dvaapůlkrát vyšší než širší). Specializovaných hamburgeráren, které se v L.A. snaží o vyšší kuchyni je přes 90 a neustále se předhánějí.

Já jsem byl v Go Burger, čtyřikrát v Umami Burger, Fatburger a v pár neznámých podnicích (co se soutěžení o top burger v LA týká). Co jsme měli popíšu:

Go Burger

Ochutnali jsme C Cubed a UltiMELT. Ke každému burgeru jsme dostali nakládanou okurku (v jiném láku než v Česku, míň kyselý a jinak kořeněný) a salát coleslaw (opravdu dobře udělaný). Burgery v jednotlivých provozovnách se liší, protože každá má svého šéfa. Hned po usazení nalijou zdarma vodu, což je v USA poměrně časté, nicméně není to pravidlem.

Vrstvy budu uvádět vždy zvrchu.

C Cubed

salátová okurka
červená cibule
dressing z chipotle
salát
slanina
avokádo
kuřecí obalované v těstíčku

UltiMELT

toto je dost zvláštní burger, podává se v něčem, co připomíná trojúhelníčky toustáku, ale musí to být na zakázku, protože je to pečivo velmi tvrdé (vhodné pro tento typ jídla)
grilované cibulky
slanina
tlustá vrstva sýra gruyere
burger z Black Anguse

Dovedou dobře poradit co na pití, zaměřují se na mléčné šejky, ale měli i slušný výběr piv (o amerických pivech jsem napsal před časem ). Bohužel obsluha se v pivu nevyznala a číšník po prosbě o radu na dobré US pale ale mi nejdřív poradil Guiness (což je irský stout) a pak Paulaner (což je mnichovský pšeničný weissbier). Nakonec jsem zkusil jejich značkový Go blond, což byl honey ale, který byl jen velmi jemně nachmelený, což mi přijde na USA dost nezvyk, chuťově dost průměrné pivo.

Celkově musím Go Burger zhodnotit nadprůměrně, tým se výborně doplňoval a podnik vypadal moderně. I přes velmi rušnou pozici (křižovatka Vine a Sunset bulváru přímo na chodníku slávy) byl uvnitř klid. Navíc nejedou pořád jedno menu, vyvíjejí ho a mají týdenní burgery a šejky.

Umami Burger

Umami burger je hodně specifický. Šéf se snaží o opravdové použití páté chuti umami, takže v jídle používá suroviny, které danou chuť obsahují. Maso berou u Rocker Bros v kvalitě USDA Prime (toto označení dostává v USA přibližně jen 1 % hovězího masa) a opět se jedná o plemena Angus a Kobe (na burgery používají Angus). Byli jsme v provozovně na Hollywood bulváru nedaleko spoje se Sunset bulvárem, což je docela klidná část města. Podnik je vyzdoben japonskými znaky, japonskými panenkami a zbytek je jen dřevo, jednoduché barvy, místo stropu přímo trámy střechy a docela stylové vybavení. Jídlo dostanete na hranatých mělkých talířích, které možná znáte ze sushi-barů. Všechny provozovny mají společného šéfa Adama Fleischmana.

Umami Burger

domácí umami kečup (sladší a lehčí než Heinz, který je tady všude – ze zralých rajčat, která jsou plná umami)
portobello – zdroj umami
pečené rajče – zdroj umami
tenký plátek zpečeného sýra (vytváří mřížku, takže byl nejspíš nastrouhán a upražen na grilu, některé sýry jsou zdrojem chuti umami)
grilovaná cibule
 burger

Earth Burger

aioli z bílé sóji (sója je plná chuti umami)
salát
pečené rajče (zralá rajčata jsou plná umami)
grilované cibulky
lanýžová ricotta (lanýže jsou zdrojem umami)
burger z hub a rozvařené sóji, neuvěříte, že to není mleté maso s houbami – nicméně je to umami bomba

Tady mají k burgerům přímo na stolech doporučená pití a přílohy já se nechtěl smířit a nechal jsem si poradit, což byl rozhodně šťastný krok Drifter Pale Ale je pro mě zatím to nejlepší pivo z USA. Velmi podobné mému Pale Ale, který sám vařím, ale daleko lépe zpracovaný, sytý a dokonce i pěnivý. Ochutnal jsem další dva pale ales, které mi ale neutkvěly v paměti.

Umami mi rozhodně vyhovovalo, jedná se o podnik s velmi moderním pojetím a postavený na fůzi Japonska a typicky amerického jídla.

Poznámka: tento článek jsem napsal asi před 10 dny, od té doby jsme byli v Umami ještě třikrát a zkusili jsme několik dalších burgerů (SoCal, Stinky…). Nejvýrazněji jsem chuť umami cítil asi v Stinky burgeru (s česnekovým aioli, grilovanou ančovičkou, domácím kečupem a grilovanýma cibulkama). Zajímavá mi přišla fúze hranolek s lanýžovým sýrem, který je podnikovou přílohou vedle ručně krájených hranolek s domácím kečupem.

Co dál?

Ještě mám v úmyslu se podívat do výše linkovaného Tommy's a srovnat si ho s Fatburgerem. To jsou hamburgnárny zajeté už řadu let (ale pořád vyhlášené), takže místo dost revolučních Go Burgerů, Umami nebo teď docela populárního Juicy Burgeru se dá čekat velmi klasický nerevoluční americký hambáč (mysleno v dobrém).

Rozhodně si myslím, že Česku takovýhle druh podniků opravdu chybí. Ač to může znít zvláštně, napodobit americký fastfood je docela obtížné a bojím se, že ani Pohlreichův dvouručák to nevytrhne.

Zájemcům doporučuju pár zdrojů:

• 10 nejlepších burgerů v roce 2011 podle laist.com
• Web zaměřený na recenze burgerů, hot dogů a pizzy, rozuměj tedy fast foodů
• L.A. Eater – občas píšou i o burgerech
• A Hamburger Today – internetový blog

Podařilo se nám poznat manžele Martinu a Michala Glenn z Česka, on pracuje (a je podílníkem) v dnes už Dellem koupeném startupu Kace – oba se ve světě startupů vyznají. Ptal jsem se, v čem vlastně je důvod toho, že právě Silicon Valley je světovým střediskem IT (a biotechnologických firem, což mnoho lidí neví). Odpověď byla pro mě dost velké překvapení: „Je to tím, že se tady všichni znají. Každý ví, kdo pro koho pracoval, kdo co založil.“

Výhodou Silicon Valley není Stanfordská univerzita (ikdyž ta v tom má také svůj podíl), ale to, že se lidé mají šanci poznat. Že na sebe naráží ve stejných hospodách, že nakupují ve stejných obchodech, myjí auta ve stejných myčkách, chodí ke stejnému zubaři. A lidi z IT firem často poznáte (postavy v tričkách a mikinách Google, LinkedIN, Amazon a další jsou na ulicích docela běžné).

A proč tedy mám zapomenout na Silicon Valley? Fintou je ta paralela s ČR: každý, kdo nějak bloguje, povídá na konferencích, nebo na ty konference chodí, kdo sleduje tweety lidí z Česka, diskutuje na builder.cz, Zdrojáku a blozích, zná ostatní lidi, kteří dělají totéž. Česko-Slovensko má podle mě perfektní podhoubí pro to, stát se křemíkovým údolím Evropy.

Věřím, že je v naší zemi dostatek lidí, kteří chtějí něco dělat. Tak už lidi konečně nekopírujte nápady z údolí! Ty nápady vznikají a jsou relevantní tady, v Kalifornii, vyrůstají v podhoubí a prostředí, které reaguje na místní potřeby a zájmy. Potřeby a zájmy západní a střední Evropy (což je také gigantický trh) jsou odlišné. A opravdu dobrý nápad se může stát globálním.

Chápu, že venture kapitalisti, business angels, startup akcelerátory jsou v ČR o deset řádů méně zkušení (křemíkové údolí „založili“ Hewlett a Packard roku 1938, takže máme nějaké třičtvrtě století zpoždění za dnes už zavedeným ekosystémem). Je ale velkou výhodou to, že v Česku není těžké sehnat „garáž“ (rozuměj levnou kancelář) a začít opravdu s nízkým rozpočtem. V Silicon Valley je dnes už těžké se prosadit, ceny jsou jak ve velkoměstě, ceny nemovitostí jsou až nechutné a máte obrovskou konkurenci.

A další výhoda ČR proti jiným místům všude po světě? Že je Česko malé! Ano, myslím to vážně. Není problém, aby se parta nadšenců třeba ze Vsetína sebrala a jela přes půl republiky za investory. Tohle nemůže Německo, Velká Británie ani Francie napodobit.

Navíc jak jezdím po firmách a školím, nemůžu si nevšimnout, jak chytří lidé v Česku žijí. Teď už je to snad jen otázka času, kdy se projeví globální ambice, kdy české projekty překročí český jazyk a dostanou ty dobré nápady do celého světa. Jednotkám už se to povedlo, věřím, že stovky budou následovat.

Jaké nejčastější situace tady máme:

Protože se mi to bude hodit v obou třídách

Je správné řešení vícenásobná dědičnost? Nevzniká tím tzv.božský objekt? Neporušuje se tím single-responsibility princip? Nebude potom taková větší třída špatně udržovatelná? Bojím se, že většinou vícenásobná dědičnost povede k horšímu kódu, než při použítí delegace.

Rodič ví o potomkovi

abstract class AbstractTask
{
        protected $x;

        public function setX(XInterface $x)
        {
                $this->x = $x;
        }

        public static function initWithType($type)
        {
                switch ($type) {
                        // toto je chyba -> nova trida bude vyzadovat upravu abstraktni tridy
                        case "a":
                                $out = new ATask;
                                break;
                        case "b":
                                $out = new BTask;
                                break;
                        default:
                                $out = new DefaultTask;
                                break;
                }

                $out->setX(new X);
                return $out;
        }
}

class ATask /* BTask DefaultTask */ extends AbstractTask
{
}

Type-hinting třídou

Pokud mám vytvořit mock/stub objekt z finální třídy, nelze použít dědičnost. Jazyk by mě nepustil, zatímco interface ano. Pokud chci dekorovat objekt, který nebudu dědit ale držet jako instanci (které budu její metody posílat), dodržuji rozhraní. Type hinting postavený na dědičnosti třídy mě nepustí, interface ano. Oba dva zmíněné příklady jsou naprosto čisté a v pořádku a type-hinting založených na třídách je v takové situaci chyba.

Vícenásobná dědičnost zde není řešením. Nemůžu přeci do mock/stub objektu mixovat reálnou funkcionalitu, chci svou, nastavenou napevno, bez rizika chyby. A už jsem u potřeby existence interfaces v jazyce.

Dědičnost pro získání atributů

Pokud dva objekty mají stejné (podobné) atributy, může vás napadnout: použiju dědičnost, vždyť tím bráním duplikaci kódu (settery/gettery, defaultní hodnoty atributů). Ve skutečnosti tím vytvořím rodiče, který nemá žádnou dědičnost, žádnou určující schopnost, nic, je jen skladištěm na atributy, settery a gettery. Jedná se o chudý objekt a na to, aby stál za začlenění do objektového modelu, musel by umět o něco víc.

Přikladem by mohl být controller, který by neměl žádnou metodu dispatch(), run(), jen by si získal request a response.

AbstractSingleton

Jestli je třída singleton, to je implementační detail, který může řešit Dependency Injection kontejner. Může to řešit v horším případě i samotný objekt. Vytvářet třídu, která nic neumí, jen sama sebe vytvořit jednou, to je jasné zneužití dědičnosti.

Jak teda na to?

Celý postup je velmi praktický, dobře použitelný a umožňuje snadno rozdělit celky v třídě. Ale…

S velkou mocí přichází i velká zodpovědnost. Traits se dají svou silou přirovnat k anonymním funkcím v PHP 5.3 (které se pořád ještě nepoužívají tak, jak by měly). A já se upřímně bojím, že budou teď traits používány špatně. Dnes už mnozí vědí, že neopodstatněná dědičnost (což je valná většina případů) je špatná. Ale použít trait tam, kde bych použil špatně dědičnost, je úplně stejná chyba.

K čemu tedy traits v PHP jsou užitečné:

• nový behaviour – třída svou zodpovědnost řeší lépe, šíře
• rozdělení logických celků (například oddělím v HTTP routeru části skládání url a parsování url, protože tyto metody mohou být znovupoužity
• obecné algoritmy, které neřeší žádnou zodpovědnost a proto nejsou dostatečné pro třídu
• v určitých situacích (string, array, LINQ query) je výhodné vytvořit objekt, který toho umí opravdu hodně a tak se do třídy namixuje řada funkcionalit

K čemu nejsou:

• přidávání zodpovědností – vznikají megatřídy, byť jsou ve více souborech.
• obrana proti duplicitnímu kódu – od toho je delegace.

I nadále by měla zůstat volbou číslo jedna delegace, pak další návrhové vzory, následované traits a v poslední řadě (a skutečně opodstatněných případech) dědičnost. Když Jakub Vrána napsal, který framework použije traits jako první, napadlo mě: který framework použije poprvé traits správně? Nette už první trait na githubu má. A i v tom Nette bych si uměl představit v ideálním případě (tedy v případě implementace v PHP, jak by to bylo správné) jiné první použití traits:

Všechny třídy by musely mít v PHP společného předka. Trait by musel jít přidat dynamicky (i do nativních tříd). A Nette by svůj event-model přidalo traitem všem objektům (framework se v daném prostoru používá obvykle jeden, může si to tedy dovolit).

Když se snažím vyjít ze svých současných zvyklostí při návrhu objektového modelu (a to zdaleka nejen v PHP), myslím, že traits nebudou patřit k široce používaným funkcionalitám a to proto, že je jejich implementace málo dynamická – jak jsem uvedl už dříve, není možné traits mixovat za běhu a není možné pomocí traits měnit systémové třídy (napsané klidně v C).

V čem to spočívá?

1. mám seznam úkolů
2. splním úspěšně úkoly a dostanu plno nápadů na další projekty
3. najednou mám obrovský backlog úkolů s termíny, které předpokládají, že budu každý den produktivní
4. přiblíží se den, kdy úkoly nestíhám, posouvám termíny a vísí mi tam úkoly 14 dní po termínu
5. všechno smažu a zbavím se zodpovědností
6. funguju bez nebo s minimem seznamů
7. dostanu nápad na projekt, rozepíšu ho do projektů
8. jdi na 1

Tohle kolečko posílení sama sebe z úspěšně završených úkolů, navalení si práce, frustrace, odhození úkolů a znovunastoupení do kolečka se děje prakticky pořád s periodou cca dvou měsíců. Nicméně daří se mi amplitudu množství vytvářených i mazaných výrazně mírnit tak, že:

• se velmi bráním vytváření projektů (pracuju víc se someday/maybe v GTD)
• každý měsíc si dělám analýzu 80/20 (80 % štěstí, příjmu, zábavy posiluju, 80 % stresu odhazuju, čímž jsem se zbavil velké spousty projektů, které jsem ani nemusel začít řešit)
• u každého projektu se snažím zadávat takové úkoly, abych musel vynaložit minimální úsilí k dosažení cíle – stejně tak u úkolů přemýšlím, jak vynaložit minimální úsilí k dosažení cíle
• uzavřený backlog úkolů (ohodnocených pomodory) s měřenou velocity mi brání nabrat si příliš mnoho práce
• dovedu něco málo delegovat, byť to pořád není zdaleka ono

V současné době mám jen 10 projektů, naráz pracuju jen na polovině z nich (teď tedy na dovolené nepracuju na žádném mimo vylepšování webu a psaní). Ve skutečnosti bych jich asi zvládl víc, nebýt supertrialu, který dělám i během dovolené.

Firma, která prodává termíny, zkratky a výrazy, tak činí z pro ni výhodného pohledu. Odřízne se od „studentů“, „webtržníků“ a podobných low-cost služeb. Zákazníci mají pocit, že firma je cool, sami že jsou blbci a proto akceptují zbytečně vyšší cenu (za sice vyšší, ale neodůvodněnou kvalitu tam, kde není nutná).

Bohužel, svět IT nás nutí přemýšlet ve zkratkách. Headhunteři, personálky, často i manažeři a zaměstnanci personálních oddělení zvou lidi na pohovor podle hledání klíčových slov v životopise. Někdy vznikají téměř bezobsažné zkratky (REST = používejte HTTP tak, jak bylo zamýšleno, přijde to jako WTF jen mně?), nebo se dává zkratka technologii/pos­tupu, který už existuje řadu let (Web 2.0) nebo dokonce desetiletí (NoSQL uložiště).

Přitom zákazníka zajímají významy: „že to spojí s účetnictvím“, ne: „to umí konzumovat API“; že: „lidé si můžou prohlédnout produkty“, ne: „produkty se vypíšou beztabulkově AJAXem z CouchDB“. Dělejte věci nejlépe, jak to umíte (a použítejte technologie, které se hodí a vyváží mix čistota/produk­tivita), ale nezahlcujte zákazníka použitými technologiemi, i on nejspíš ve svém oboru dělá to nejlepší, co umí a taky vám necpe Polyesterový dvousložkový stěrkový tmel L100034.

Sám jsem ze svého CV začal technologie a klíčová slova spíš vyhazovat, místo věcí, které umím, tam nechávám věci, které nejen umím, ale hlavně chci dělat. Byť jsem papírově horší, než bych mohl, v reálu člověk dělá zajímavější práci. Nehledě na to, že mé CV není důvod, proč dostávám práci, jakou dostávám.

Nemluvte na lidi slovníkem ajťáka a nevnucujte technologie, které dílo zákazníkovi celé jen zdraží. Mluvte lidsky, jako byste neměli s IT nic společného. Druhá strana, ať už to bude účetní, truhlář, majitel demoliční firmy nebo zubařka, se k vám budou vracet radši, doporučí vás a budete se cítit jako lepší člověk.

Každý úkol lze vyhodnotit a pokud neprojde, tak i vylepšit, nebo v ideálním případě smazat podle 5 kritérií:

Specific
Measurable
Aligned
Realistic
Timed

Ve skutečnosti jsem se setkal s mnoha jinými záměnami (Specific, Significant… Measurable, Motivational… Aligned, Acceptable… Realistic, Relevant… Timed, Trackable…) Já předávám, jak jsem získal a jak jsem sám na SMART úkoly zvyklý.

Specific – je zadání jednoznačné. Dokážu přesně říct, kdy je úkol „hotov“? Znám maximální povolené prostředky? Znám smysl onoho úkolu a jak zapadá do celku? Pokud budu úkol delegovat, je jeho popis tak specifický, že už budu řešit s kolegou jen provozní maličkosti (které se dají vyřešit za pár minut ústně nebo prototypem)? Úkol je specifický tehdy, když je člověk, který úkol bude vypracovávat, schopný ho vlastními slovy vysvětlit znovu a je to správně. Pokud to tak není, je nutné specifikaci zlepšit.

Measurable – je v definici „hotovo“ použita jednotka, případně stav ano/ne? Úkol (a jeho splnění) je měřitelné tehdy, když je zadané exaktně: „Počet skrytých závad automobilů snížíme v záruční době na 0.01 procenta“, „Obrat se zvýší o 33 procent“, „Ve výzkumu veřejného mínění dosáhneme názoru veřejnosti, že jsme nejlepší fitcentrum v Praze“. Pokud místo toho obsahuje zadání vágní tvrzení typu: „zlepšíme ziskovost“ (bez čísla), „staneme se známějšími“ (bez měřitelného kritéria – tedy např. výzkumu veřejného mínění), úkol neprošel a je nutné ho přeformulovat.

Aligned – je cíl pro podnik relevantní? Pokud firma má velký problém s fluktuací, neměl by podnik vynaložit radši úsilí na práci s lidmi, než na obnovu vozového parku? Shodne se každý zúčastněný, že úkol je pro podnik skutečně důležitý? Pokud ne, je nutné úkol přeformulovat nebo smazat.

Realistic – je vůbec možné úkol splnit. Stát se největší ocelárnou v USA zabere 15 let. Stát se nejpoužívanějším vyhledávačem v současných podmínkách může být pro začínající firmu i zcela nemožné (ale třeba se mýlím a Nový hledač opravdu prorazí). Dávat si vysoké cíle je potřeba. Být první může být ale jen jeden. A s nejvyšší pravděpodobností bude v nejbližší době jedničkou někdo v TOP10 oboru, ne začínající podnik. Všichni zúčastnění se musí shodnout na tom, že cíl – byť má ambice – je splnitelný.

Timed – úkol musí mít termín. Obrat se zvýší o 33 % za rok do 1. července 2012. Každý měsíc snížíme skryté vady výrobků o 10 %. Pokud nemá úkol termín, není to úkol, ale jen přání. Samozřejmě existují způsoby, jak fungovat bez termínů u většiny úkolů: ale to jen tehdy, když velké množství malých (netermínovaných) úkolů směřuje k většímu (termínovanému) cíli. Pokud není jasné, do kdy má cíl být splněn a vyhodnocen za úspěšný nebo neúspěšný, úkol neprošel.

SMART má výhodu v tom, že se jedná o primitivně jednoduchou techniku, kterou stačí slepě sledovat a ona má výsledky. U většiny technik člověk přemýšlet musí, SMART funguje úplně automaticky. Z této techniky můžou těžit jak firmy, tak jednotlivci. Schválně si zkuste své úkoly projít a zjistit, jak na tom jste.

• komáří moč uvařit umí – říká se jí light (např. Bud Light), je to nízkoalkoholické pivo vařené na chuť podobnou euroležáku
• komáří moč netvoří ani třetinu toho, co uvidíte v regálech
• v hospodě vám určitě tu komáří moč vnucovat nebudou, právě naopak
• americká piva jsou především Ale (hlavně Pale Ale, Amber Ale a Honey Ale), což jsou svrchně kvašená a často výrazně chmelená piva (používá se často chmel Cascade, nicméně podobného efektu dosáhnete i s jinými, třeba s Premiantem, který se používá i v Česku)
• mimo ejly (Ale) jsou velmi populární populární pšeničná piva (a to jak do stylu českého Velena, tak i piva s příchutí, stylu Hoegaarden)

Regály s pivem jsou tu opravdu plné výběru, za jakými musíte v Česku do specializovaných pivoték. Nabízí se lambiky, kriek, pomerančové a čokoládové ejly, další speciální piva a vedle toho importy z celého světa (velmi populární je Corona) včetně Plzeňského prazdroje. Místní pivovary se inspirují hlavně v Belgii, což lze jen a jen pochválit, Belgičani společně s Němci vaří pravděpodobně nejlepší piva na světě.

Bohužel je téměř nemožné koupit si půllitr piva, buď si musíte koupit velkou láhev (cca 0.7 litru), nebo balení piv po šesti kusech (přibližně třetina litru). Pokud ale chcete napít piva jednoho pivovaru, dají se koupit balení 12 piv se čtyřmi druhy po 3 lahvích.

Já jsem takhle vyzkoušel 3 pivovary:

Pyramide

• Hefeweizen – jemně hořké, ale celkem bez chuti. Kdybych pšeničné pivo sám nevařil, asi bych ji z chuti nepoznal
• Apricot Wheat Ale – nejhorší pivo, které jsem v USA ochutnal, přítelkyně ho komentovala „vůně do záchoda“. Nechutná ani jako pivo, ani jako sirup. Chutná jak obojí a naředěné vodou 1:1.
• Curve Ball – jemňoučký pale ale, téměř nechmelený, nic zvláštního
• Thunderhead – jediné slušné pivo od Pyramide. Dalo by se pít dostatečně. Nachmelení je tak uprostřed rozmězí, co jsem v USA ochutnal. Výrazně chmelovější, než cokoliv ostatního od Pyramide

Zhodnocení: od Pyramide ruce pryč, budete-li mít možnost koupit pivo z jiného pivovaru. Pokud ne, doporučuju Thunderhead.

New Belgium

• Sommersault – velmi silná chuť, výrazně sladové, chmelem se na tomto pivě šetřilo
• Fat Tire – pivo až karamelové, chlebové a syté, přitom se nejedná o černé ani polotmavé pivo. Je to docela zvláštní pivo, myslím, že podobný efekt by se dal dosáhnout 25 % karamelového sladu.
• Mothership – pšenice napodobující poměrně úspěšně Hoegaarden. Dobré pivo, viditelné kvasnice na dně sklenic, originální název i logo.
• Ranger IPA – výrazně nachmelené, skvěle chutnající srovnatelné s Drifterem a Rotatorem od Widmer Brothers

Zhodnocení: New Belgium rozhodně doporučuju napít. Hlavně vyzkoušet Ranger IPA a Sommersault, obě piva jsou fakt dobrá a vybočují (což platí i o Fat Tire). Mothership je solidní pokus o Hoegaarden, nicméně původce nepřekonává.

Widmer Brothers

• Drifter Pale Ale – společně s rotatorem nejnachmelenější pivo. Sytá barva až do odstínu mědi.
• Rotator IPA – platí vše jako u Drifteru, je ale víc hořké a nemá tak výrazný slad.
• Hefeweizen – dobrá pšenice asi jako náš Velen. Z pšeničných piv mi víc chutnal Mothership od New Belgium.
• Citra Blonde Summer Brew – pivo celkem bez chuti, na úrovni Curve Ball nebo Go Blonde z Go Burgeru, nenadchnulo

Zhodnocení: První dva zmiňované ejly byly asi to nejlepší, co jsem zatím na novém kontinentu pil. Rozhodně doporučuju koupit a pít v množství větším než malém.

Musím říct, že ač jsem velkým příznivcem pšeničných piv (sám vařím pšeničná piva a pale ale), tady jsem své preference dost posunul k ejlům. V Americe se opravdu snaží o hodně velké rozmezí chutí a to mi vyhovuje.

Poznámka na závěr: neochutnal jsem zcela záměrně jediný ležák plzeňského typu, byť tu výběr existuje, asi ani žádný neochutnám, nelákají mě, Češi tato piva umí asi stejně líp. Nicméně zkusil jsem Bud Light s limetkou a byla to solidní limonáda připomínající Frisco.

Poznámka sám pro sebe: musím vymyslet, jak ta piva dostávat do ČR za cenu běžnou v USA. Za 20 korun na láhev se to dá pít, 80–100 Kč v pivotékách je naprostá drzost.

Já jsem se rozhodl jeden přeložit a mírně ho upravit (podle svých zkušeností). Původní originál je: 10 principles of Agile Project Time Management

Následují samotné principy:

1. definujte „hotovo“

Jak? Definujte, co znamená, že je úkol hotov a počítejte za hotové jen ty úkoly, které splňují akceptační kritéria Proč? Vyvarujete se skrytých úloh typu, teď to odkliknut ale musím si pamatovat, že…

2. Používejte uzavřené backlogy

Jak? Nastavte si časové termíny od-do pro práci na svých projektech a v daném časovém intervalu si neměňte obsah práce Proč? Uzavřený backlog vám nechá zaměření na to, co je skutečně důležité

3. K časovým odhadům nepřidávejte žádné „polštáře“ (časy pro případ zdržení)

Jak? Poznejte svou rychlost, přizpůsobte se jí. Pracujte s tím, že si zjistíte, kolik budete mít další týden čas. Proč? Všechny časové zálohy se vždy použijí (viz Parkinsonův zákon)

4. Odkládejte rozhodnutí

Jak? Dělejte rozhodnutí v poslední možný okamžik. Nerozhodnutí je také varianta. Proč? Čím později rozhodujete, tím více máte v danou chvíli informací.

5. Zkracujte trvání cyklu

Jak? Neplánujte na dlouho dopředu, mějte krátké iterace (já mám týdenní) Proč? Zrychlí se zároveň doba učení, zkrátí se TTM (time-to-market)

6. Nedělejte na příliš věcech naráz

Jak? Omezte množství nedokončené práce a veškerou administrativu spojenou. Proč? Zrychlíte svůj reakční čas, uděláte více práce

7. Buďte disciplinovaní

Jak? Předejděte problémům tím, že si nastavíte pravidla a dodržíte je (neuděláte kompromis typu: já ty testy napíšu pak). Proč? Řešení problémů v průběhu projektu je dražší, než od začátku pracovat bez kompromisů.

8. Omezte přepínání úkolů

Jak? Přecházejte mezi projekty co nejméně (nejsou-li hotové) a braňte se vyrušením Proč? Uděláte více práce.

9. Zabraňte přesčasům

Jak? Zapomeňte na používání svého volného času jako cesty k akceleraci projektů Proč? Sníží se vám produktivita, kvalita i motivace. Budete unavení a přestanou vás úkoly bavit.

10. Oddělte urgentní a důležité

Jak? Nedělejte projekty od nejvíc urgentních k méně. Jděte podle priorit úkolů. Proč? Skutečně důležité úkoly budete odkládat a z dlouhodobého pohledu si uškodíte, nebo alespoň zpomalíte cestu ke svým cílům.

Musím osobně říct, že mě těší vědomí, že nejsem jediný, kdo se propojením agile a time managementu zabývá. Závěry, ke kterým autor přišel, jsou podobné tomu, co se v knihách o time managementu běžně píše. Začínám si pomalu myslet, že možná bude existovat nějaký svatý grál time managementu.

• Kreditní karty místo běžných – platba kartou trvá asi tak 1 vteřinu
• Milí lidé všude – všichni se snaží, na hotelu nám našli spoj do San Francisca, hotel, místo, kde si půjčit auto a to bez nějakých affiliate kódů. Dali nám members-card do blízkého obchodáků, hotelu jsem vydělal asi 30 centů a nám to ušetřilo několik set kč hned za první 2 nákupy. Když se usmějete na člověka na ulici, hned se taky usměje a pozdraví.
• Obrovský výběr – blízkost Mexika je jasná, je tu tolik zeleniny, část jsem v životě nikdy neviděl. Papričky habaneros, které 4 stojí v ČR asi 30 kč tady prodávají za zlomek tak, že si člověk prostě nabere do pytlíku. Jsem blázen do chilli, tady to je můj ráj, hned jsem si nakoupil.
• Oblohy – v ČR nemám rád zeleninové oblohy. Obvykle dostanu v ČR sterilovanou zeleninu z piksle a soused u vedlejšího stolu (s jiným jídlem) dostane naprosto stejnou oblohu. Divím se, že kuchaři v Česku nedávají tu unifikovanou oblohu i k buchtičkám se šodó. Tady oblohy nejsou buď vůbec (bravo!) nebo když už dostanu třeba salát, je správně ochucený (nekoupe se v dressingu a přitom má chuť).
• Ceny – když s člověk podívá na jejich příjmy, ceny jsou směšné. Třebas jsme si koupili výborná hefeweizen piva za 25 kč každé. Něco podobného platí i o vodách, potravinách, drogérii…
• Multikulturnost – mám pocit, že v USA to fakt funguje. Lidi se tu míchají, vídám smíšené páry, nevidím, že by si běloši dělali od kohokoliv odstup.

A pak plno věcí, které přenést do ČR asi nejdou, jako velká auta, super klima, levný benzín.

Co se mi naopak nelíbí:

• Bez auta je všechno mnohem těžší – byť je MHD poměrně solidní, je poznat, že prim tady hraje ježdění autem. Zastávky nejsou značené, některé silnice nemají chodník, některé ho mají jen na jedné straně.
• Koupit alkohol je mnohem složitější – je to tak, později večer/brzo ráno je velmi obtížné najít „liqstore“ (a např. benzínky alkohol často vůbec nemají). Chci v USA ochutnat místní piva, hlavně jejich Pale Ales, protože podobné pivo i sám vařím. Pivotéku aby jeden hledal týden.
• K lékárnám – tak místo lékáren jsou tady normální obchoďáky s oddělením, kde se prodávají léky. Volný prodej je taky třeba opravdu „volný“: mezi zubníma pastama a sirupama najdete léky na nachlazení, benefibru a jiné věci na hubnutí, doplňky pro sportovce, multivitamíny, náplasti… Asi je to tím, že přítelkyně je lékárnice, ale trošku mě to děsí.
• Na všem varovné cedule – myslím, že je to důsledek toho, že každý může žalovat kohokoliv za cokoliv. Tak jsou na všem velká varování jak na použití dané věci a jak vůbec ne a vychází to tak, že v USA by nikdo nic neměl dělat sám, neměl by být důchodce, ale ani příliš mladý, neměl by před čímkoliv pít alkohol a všechno činí na vlastní nebezpečí.
• Mříže v oknech – já si tu připadám v bezpečí, ale viděli jsme čtvrtě, kde měli na plotech ostnatý drát, v lepších čtvrtích většinou vystačí s bodcema, velkým varováním (skoro na každém domě), že kdo sem vleze, toho předají policii.
• Sladké snídaně – je to věc individuální chuti, já osobně ale říkám: Fuj!

Jsem tu zatím chvilku, takže dojmů není až tak moc. Každopádně očekávaný kulturní šok se nedostavil, rozdíly jsou (vlastně jiné je úplně všechno – ikdyž jen trošku), ale nejsou nijak šokující (pořád chodí po nohou, jedí pusou, hlava nahoru-dolu je ano, doleva-doprava ne, ani těch tlustých tu není tolik, jak jsem si myslel). Musím říct, že si dovedu život v SoCal představit, nicméně nebyla by to – až na ty usměvavější lidi a lepší klima – žádná extrémní změna k lepšímu.

1. upload souboru se provádí vždy do sdíleného uložiště Věc je složitější – se souborem se musí pracovat, až když doběhne transakce nahrávání.

   Instance vykonávající kód samotná nikdy nesmí záviset na tom, že má u sebe nějaká data – když je potřebuje, ať si je stáhne.

2. cache žurnál musí být sdílený, totéž platí i o sessions Připravte se na výpadky všech technologií, které použijete – většina software je v distribuovaném prostředí daleko hůř otestovaná, na stažená open-source CMSka, e-shopy apod. můžete klidně zapomenout. Otestujte pád memcache, výpadky instancí, to, zda v případě velké zátěže dovede systém v předstihu škálovat nahoru.
3. databázi převeďte na jednoduché uložiště Vyhněte se složitým JOINům, v budoucnu může být polovina tabulek na zcela jiném serveru.

   Osekáním zátěže na serveru a JOINy v aplikaci oddálíte okamžik, kdy musíte použít master-slave replikaci. Na hodně dlouhou dobu vystačíte pro každou databázi s jednou instancí.

4. připravte rychlý deployment Kód se musí na server dostat rychle. V ideálním případě byste měli být schopni udělat deployment během pár minut (třeba) pushnutím do repozitáře.
5. nespoléhejte na IP adresy: mohou se změnit – a taky se změní
6. beta server musí mít více souběžně spuštěných instancí, jinak neotestujete řadu funkcionalit, které na jednom serveru běží a na více serverech se chyba teprve projeví
7. vyvíjejte systém bez centrálního bodu – například se vyhněte situaci, kdy si výkonné servery stahují přihlašovací údaje pro připojení k SQL, memcache apod. z jedné instance. Dřív nebo později i tato instance spadne. Naprogramujte systém tak, že informace se cloudem distribuuje a všechny servery mají aktuální informace. Až do desítek běžících serverů si s tímto vystačíte.
8. s cache pracujte chytře – mějte více různých cache, některé lokální pro instanci, některé globální (jako je memcache, databáze) – promýšlejte, jak kešovat výsledky. Žurnál může být i na jiném storage.
9. sledujte zdraví všech instancí. Dělejte si statistiky pádů a jejich důvody.
10. vytvářejte snapshoty Je sice perfektní mít možnost kdykoliv udělat deployment pomocí pushnutí do Mercurialu. Stejně ale vytvářejte průběžně obrazy celé instance. Budete mít vždy k dispozici kombinaci nastavení serveru a aplikace, která na něm běží.

Přes to všechno se dá naučit rychle psát škálovatelný software. Jde o velmi pochopitelné principy a nebudete potřebovat pro přesun svého kódu do cloudu vyhodit polovinu řešení.

Jak jsem psal už dříve, zavedl jsem si Agilní metodiky v reálném životě. Znamená to pro mě především týdenní sprinty, daily standupy, menší projekty, které se dají do týdne zvládnout. A ono to na GTD lze opravdu dobře napasovat.

• Daily standup → Denní procházení listů, Zero Inbox
• Backlog → Označení projektů termínem
• Bodování úloh → Kolik pomodoro mi to zabere?
• Sprint review & Sprint planning → Week review
• Burndown chart → Kolik zbývá pomodoro?

Všechno to do sebe dobře zapadá a agile by se asi s GTD dalo dobře kombinovat, mám ale časem problém s nástroji. Vyzkoušel jsem jich strašnou spoustu, Omnifocus, RTM, papíry, Everynote a nakonec jsem zakotvil u Things. Myslím, že Things jsou asi nejlepší nástroj na GTD, mají ale jeden strašlivý neduh (stejně jako ostatní nástroje). Když máte desítky projektů na půl roku dopředu, máte před sebou docela dlouhý list. Jenže tyto projekty člověk používá (různě doplňuje, předělává obsah, nastartuje je) jen výjimečně. Zjistil jsem totiž, že nejvíc toho udělám, když si na 1 týden na 4 projektech dám 4 velké cíle. Ale oči pořád poletují v Things i mimo tyto projekty, mimo tyto úkoly. Jenže člověk, chce-li být produktivnější, by neměl jednu věc číst víckrát, než je nezbytně nutné.

Znásilnil jsem tedy Things a udělal si týdenní backlog v Today. A pomalu si zvykám nekoukat na seznam projektů. Ono těch 4×4 úkolů není až tak moc, takže vždy mám tak na 3 týdny tyto úkoly jasné. Nicméně tím jdu dost proti GTD; David Allen, byť si sám seznamy úkolů na den dělá, nedoporučuje tyto listy (denní, týdenní) ze dvou důvodů:

1. do Today se má dát jen to, co má ten den pevně daný termín a po dnešku už to bude neaktuální úkol – jakmile do tohoto seznamu nahrnu řadu jiných úkolů, tento mezi nimi snadno zapadne a člověk pak tyto úkoly opomene.
2. pokud nestihnu vše z today/this week listu, budu mít pocit viny.

K prvnímu argumentu: to je pravda a skutečně se to už stalo. Prošvihl jsem termín, protože jsem dělal na něčem – ten den – důležitějším. Přitom tomu úkolu stačilo věnovat hodinku a půl, dvě a projekt mohl být hotov, takhle jsem odpískal řadu hodin práce. Jenže jak z toho ven? Zkoušel jsem mít vypsaných těch 4×4 na papíře mimo Things. Jenže GTD (naprosto správně) se zaměřuje i na minimalizaci počtu listů a tohle by byl další papír navíc, který bych kontroloval.

Co se druhého problému týká, tohle u mě naštěstí nehrozí, v tomhle mě agile naučil. Odhaduju úkoly v pomodorech a upravuju si velocity tak, aby odpovídala mému reálnému výkonu (což je tak polovina toho, co si myslím, že skutečně stihnu).

Co bych tedy doopravdy potřeboval? Skrývat projekty (vše mimo 4 hlavních), ale aby se pořád termínované úkoly dostávaly do backlogu.

Možností je několik:

1. vytvořit si kešující metodu, která původní dekoruje (umí například Zend_Cache)
2. vytvořit si metodu, které předám closuru generující data, která chci kešovat
3. celé kolečko kontroly a vytahování shrnout do jedné metody, která si vezme data z objektu stdClass (nebo podobného objektu/pole), do kterého jsou hodnoty generované jako atributy.

Jak naprogramuju druhou možnost?

$args = array(1, 2);
$promenna = $this->cached(function($a, $b) {  /*  nejaky slozity vypocet treba */ return $a + $b;  }, $args);

protected function cached($block, $args = array())
{
        $key = md5(serialize($args) . serialize(\Reflection::export(new \ReflectionFunction($block), true)));

        if (! isset($this->cache[$key])) {
                $this->cache[$key] = call_user_func_array($block, $args);
        }
        return $this->cache[$key];
}

Celá finta je jen v tom, že si vytvoříme ReflectionFunction, která je pro danou closuru unikátní, výsledkem je tedy unikátní identifikátor, pod kterým si hodnotu uložím.

Osobně bych doporučil využít prvního řešení, ostatní rešení totiž:

V případě 2:

• vyžaduje použít dědičnost – dalo by se použít dekorace, ale pak jsme u řešení 1 s obalením closurou
• veškerá práce s reflexí nepatří v PHP k nejrychlejším

V případě 3:

• nám vzniká zbytečný objekt, do kterého se skládají data
• kód není hezký, celá logika toho řešení je cca na 10 řádek, vyžaduje dvě nové samostatné metody (generování proměnných do objektu a uložení do cache, vytažení z cache a zapsání do proměnných)

Znáte ještě jiný způsob, jak jednoduše kešovat výsledek volání metody? Podělte se v diskuzi.

Jako to má asi kažý, počet věcí, které mám, se s časem zvětšuje. Triček kupuju víc, než vyhazuju, kupuju různé potraviny a koření, které se spotřebovávají opravdu dlouho a v lednici tráví měsíce. V polici „dílně“ mám spoustu věcí pro stýčka příhodu a den ode dne víc a víc věřím, že kromě lepidla, kladiva a izolepy nepoužiju snad nic.

Ono to opravdu člověku nepřekáží, když se přesťěhuje z menšího do většího – zvlášť do bytu s takovýma úložnýma prostorama. Ale to je právě ono. Nevyhodil jsem starou vodní dýmku, když jsem dovezl z Egypta novou. Nevyhodil jsem spacák, když jsem dostal nový. Nezbavil jsem se knih, které jsem přečetl a už se k nim nechci vracet (ufff, dokonce jsem se ještě ani nezbavil špatného pocitu, když vyhodím knížku).

A každý byt, sebevětší, se jednou zaplní. Pozná se to jednoduše, úklid se musí dělat častěji, trvá déle a vydrží kratší dobu. Věci zůstávají ležet na baru, nad postelí, vedle konferenčního stolku… a přitom mám pocit, že používám pořád stejný počet věcí.

A v tuhle chvíli jsem se zastavil. Řekl jsem si: „Musím to vyhodit!“ a začal jsem přemýšlet, co všechno jsou „věci“, které mě otravují.

Zjistil jsem, že vyhodit, rozdat, prodat nebo jakkoliv eliminovat z mého prostoru potřebuju následující věci:

• boty (staré, prošlapané)
• oblečení (tuna oblečení, mám plno oblečení ještě z dob gymnázia)
• papír (nevyhodil jsem jedinou smlouvu, co jsem podepsal, od 18 let a přitom už půlka z nich není aktuální.)
• sklo (když kamarádíte s pankáči, vždycky máte doma desítky prázdných lahváčů, to je prostě fakt)
• plast (co dnes není z plastu?)
• software (s tímhle už nějakou dobu bojuju, 160 giga prostě nebude navždy stačit všem, ani mě ne)
• staré rostliny a květináče (i kytky občas umírají. nebo přestávají být zábavné… už 3 roky mám v kelímku od jogurtu fíkus, čekám, že z něj bude bonsai někdy do roku 2030)
• potraviny (opravdu budu tu řasu nori používat na suši, když jsem si mezitím už třikrát koupil novější?)

Je to hrubý odhad, ale rád bych se dostal do stavu, kdy budu mít přesně 3 cestovky věcí.

Když budu chtít pořídit novou věc, starou prodám, daruju, vyhodím. Aspoň budu místo hromadění náklaďáků věcí zlepšovat kvalitu toho, co mám a používám.

Moc nevěřím, nepočítám-li věci běžné denní spotřeby (lžíce, hrnec, toaletní papír, šampón), že používám víc než 100 věcí.

Princip fungování je takový, že se člověk zcela záměrně nekouká na žádné informační weby (od zpravodajství přes RSS až po Facebook nebo Twitter), nekouká na zprávy v televizi, neposlouchá rádio (hudbu ano, ale ne zpravodajství). Během včerejška jsem udělal spoustu práce, mám dokonce pocit, že najednou i to Pomodoro je skoro zbytečné (to má ale jiné výhody, kvůli kterému jsem se na něj nevykašlal). Informace člověk hledá jen když je potřebuje nutně ke své práci.

Celá idea informační diety je z knihy Čtyřhodinový pracovní týden od Tima Ferrisse. Účelem je dosáhnout toho, že má člověk více volného času. Volného času o moc víc nemám, protože mám v GTD úkolů dost na měsíce dopředu – navíc vím, že když chci, tak si prostě čas vždycky udělám. Na mě má informační dieta jiný vliv: naprosté odbourání prokrastinace, vyšší produktivita, právo večer říct: „Jo, dneska jsem opravdu hodně pracoval!“

Informační dieta má podle knížky trvat týden, přestože autor jemně odlehčenou formu praktikuje neustále. Já sám jsem záměrné odříznutí se od všech informací podceňoval. Zablokoval jsem si Facebook a Twitter a pár zpravodajských serverů, jenže když chce mozek „zevlovat“, najde si vždycky další způsob, třeba Google Reader, Weblogy apod. Úplný informační půst je ultimativní řešení, které nedává prostor tomu nebýt kreativní. Na druhou stranu není ani zárukou toho, že člověk využije svůj čas efektivně (produktivní nerovná se efektivní).

Nejspíš začnu číst noviny jednou týdně. E-maily budu kontrolovat dál jen jednou denně a využiju ušetřený čas efektivněji, třeba se začnu učit hrát na nějaký hudební nástroj. A co když opomenu nějakou důležitou zprávu? No kdyby měl být konec světa… někdo by mi o tom řekl.

Zde je kód:

/**
 * key value storage under 1kb including tests
 * save data to kvs.dat
 *
 * Usage:
 * kvs($key) - read key (allowed scalar values)
 * kvs($key, $value) - write value by key
 * kvs(function) - find values by callback (return true on match)
 * kvs(function, function) - find values by first callback
 * (return true on match) and map by second (return value)
 *
 */
function kvs()
{
        $map = null;
        $dataFile = __DIR__ . '/kvs.dat';
        touch($dataFile);
        $data = unserialize(file_get_contents($dataFile));
        $args = func_get_args();
        if (array_key_exists(1, $args)) {
                if (is_scalar($args[0])) {
                        $data[$args[0]] = $args[1];
                        file_put_contents($dataFile, serialize($data));
                } else
                        $map = $args[1];
        }
        if (isset($args[0])) {
                if (is_scalar($args[0]))
                        return $data[$args[0]];
                else {
                        $out = array_filter($data, $args[0]);
                        if ($map)
                                $out = array_map($args[1], $out);
                        return $out;
                }
        }
}

/** tests */

kvs();
kvs("a", "b");
kvs("b", "c");
foreach (range(1,100) as $i) {
        kvs($i, $i);
}
assert('kvs("a") == "b"');
assert('kvs("b") == "c"');
assert('91+92+93+94+95+96+97+98+99+100 == array_sum(kvs(function($i){return $i>90;}))');
assert('-9-8-7-6-5-4-3-2-1 == array_sum(kvs(function($i){return $i>90;}, function($i){return $i - 100;}))');

Líbí se Vám tento kód? Prosím, dejte mi hlas v soutěži.

Michaeli, vlastníš a provozuješ Nozbe.com. Můžeš sebe a svůj server představit?

Ano, jsem zakladatel Nozbe, time-and-project managementové webové aplikace pro zaneprázdněné profesionály a produktivní týmy :-) Všechno začalo poté, co jsem si přečetl Getting Things Done (GTD), knihu Davida Allena. Metodiku jsem si zamiloval a chtěl jsem Davidovo GTD hned nasadit. Nedařilo se mi najít žádnou dobrou webovou aplikaci která by mi s tím pomohla, takže… jsem se rozhodl vybudovat si svou. Nejdřív pro sebe a později, když jsem zjistil, že není tak špatná, ukázal jsem ji světu. Za dva měsíce oslavím čtyři roky provozu Nozbe a pomoci lidem a firmám okolo světa mít vše hotovo (doslova get things done).

Proč bych si měl vybrat Nozbe a ne Things nebo Omnifocus?

Když pracuješ sám, jen na jednom počítači… Macu – Things i Omnifocus můžou být skvělé aplikace. Ve chvílii, kdy potřebuješ synchronizovat více zařízení, počítačů, nebo chceš sdílet projekty s ostatními lidmi, Nozbe ti s tím pomůže daleko víc.

Nozbe je webová aplikace, takže funguje na všech počítačích (PC, Mac, Linux) v tvém browseru. Navíc máme skvělé aplikace pro iPad a iPhone a příští měsíc vyjdou i verze pro Android a Blackberry.

Díky vlastnostem pro týmovou práci, může Nozbe pomoci tobě a tvému týmu pracovat dohromady na projektech, posílat „Next Actions“ mezi sebou navzájem a plno dalších věcí. Idea je udělat GTD jednoduché a týmové.

Nozbe se snaží o čistou implementaci GTD. Sám používáš Getting Things Done v čisté formě, nebo sis něco změnil nebo přidal?

Místo přidávání vlastností GTD jsme se snažili odstranit vlastnosti. Jak určitě víč, GTD je docela složitý systém – je skvělý a všechno, ale je docela komplexní. Viděl jsem lidi, kteří se snažili implentovat systém celý. Mnohokrát selhali a další pokusy vzdali.

Když jsem začal navrhovat Nozbe, zaměřil jsem se na tři stěžejní koncepty GTD: Projekty, Kontexty, Seznam dalších kroků a všechno vybudoval kolem nich. Po čtyřech letech jsou tyto koncepty stále základem systému a všechna funkcionalita v nich je vybudována okolo.

Kolik lidí z Česka používá Nozbe?

Moc ne, míň než tisíc lidí. Určitě by jich mohlo být víc a doufám, že současní uživatelé pomůžou jeho rozšíření i v ČR. Už jsme pro Nozbe i připravili vícejazyčnost a někteří z tvých krajanů pomohlo a získali jsme překlady mnoha částí systému.

Segment on-line project-managementových softwarů je velice konkurenční. Jakým způsobem propaguješ Nozbe?

Je nesmírně a konkurenti se objevují úplně všude. Naštestí jsme už hodně zaběhlí – především u tržní niky uživatelů orientovaných na GTD. Pomáhá nám osobní doporučování (word of mouth) a navíc dobré zboží se chválí samo. Plno firem se odněkud vynoří se zajímavým projektem, chvíli ho vyvíjí a pak ho buď přestanou udržovat, nebo to vzdají úplně. Lidé potřebují věřit svému projektovému softwaru a my jsme na trhu čtyři roky a každý měsíc přidáváme nové vlastnosti. Lidé věří, že nám svá data můžou svěřit.

Neděláme Nozbe proto, abychom vydělali „snadno a rychle“, chceme opravdu pomáhat. Lidé dostávají dva měsíce na to, aby službu zkusili a když jim nebude vyhovovat, vrátíme jim peníze. Tak dlouhá garance se u takové služby nevidí.

Používají Nozbe jen jednotliví uživatelé, nebo i celé firmy?

Především jednotlivci, ale pružný rodinný plán (Family plan), mnozí přitáhli své přátele a příbuzné. I plno malých týmů dosahuje s tímto plánem cílů. Je zábavnější mít více známých na jedné lodi, sdílet mezi sebou jednu aplikace, projekty, kroky. Jsmě fakt skvělí v usnadnění spolupráce více lidí ve srovnání s nástroji typu Things nebo Omnifocus, hlavně proto, že týmové úkoly můžeš sdílet a delegovat i z iPhonu a iPadu. Na týmovou práci se teď hlavně zaměřujeme a chceme se posunout tam, kde bude getting things done daleko snadnější.

Zjistil jsem, že chystáte offline mód. Plánujete využít i jiných novinek v prohlížečích (například CSS3, Javascriptové WebWorkers a podobně)?

Skvělé je, že při vývoji Nozbe se používáme co nejmodernější technologie a učíme se je za pochodu tím, že je rovnou nasadíme. Mí vývojáři milují výzvy a tak mají tu radost přinášet nové technologie a standardy na web. Nasazujeme CSS3 v nové iNozbe mobilní aplikaci (brzo bude spuštěna pro Android a Blackberry) a další technologie budou následovat. Současný technický vývoj nás drží nadšené a pomáhá nám spouštět Nozbe na dalších platformách a systémech a dělat s webovou aplikací věci, které ještě před pár lety nebyly vůbec možné.

Nozbe je napsané v PHP, je to tak? Použili jste pro vývoj nějaký framework?

Vytvořil jsem si svůj framework, který z velkou měrou připomínal zjednodušené Smarty. To bylo před čtyřmi lety, dnes jsou frameworky jsou mnohem robustnější a lepší. Ten současný nám vyhovuje, navíc jsme se s časem víc a víc zaměřili na Javascript, takže zůstáváme u toho, co nám funguje.

Je více vývojářů Nozbe? Používají taky GTD?

Ano a ano. Každého, kdo začně pracovat pro Nozbe, se snažíme naučit GTD. Když ještě Getting Things Done neumí, pomalu ho do něj zapracováváme. GTD používám pro řízení celé firmy (všichni jsou řízení přes Team account). Po roce jsem najal prvního programátora (Tomasz) a tak to nějakou dobu zůstávalo. Nedávno jsem najal dalšího programátora (Pawel) a grafika, aby nám pomohl udělat Nozbe hezčí. :-)

No a abych nezapomněl, samozřejmě máme člověka na podporu, Delfínu. (super jméno. pozn. J.K.)

Nozbe je tvůj hlavní zdroj příjmů? Můžeme se těšit i na jiné projekty?

Ano, určitě. Nozbe začalo vydělávat po roce provozu a příjmy mi pomohly vybudovat větší tým a dosáhnout více lidí okolo celého světa. Hlavním cílem je teď šíření lepší produktivity do více zemí (teď jsme úspěšní hlavně v USA). Je toho ještě hodně, co můžeme udělat a moc se na to těšíme.

Navíc pracujeme na další aplikaci pojmenované Emailine, kterou chceme počátkem roku 2011 ukázat světu. I tento projekt nás hodně nadchnul.

Děkuju za tvé odpovědi Michaeli.

Poznámka na závěr. Z Michaela je i po čtyřech letech na jednom projektu vidět nadšení. Určitě mu fandím v tom, ať mu to vydrží a ať dojde Nozbe co nejdál. Myslím, že velká spousta startupů se na projekt vykašle třeba jen chvíli předtím, než začně doopravdy vynášet. A ikdyž už ta služba roste a přináší nějaké peníze, mnohdy je opustí nadšení implementovat stále složitější vlastnosti.

Které konkrétní činnosti jsem do svého života přenesl (mnohdy jsem je začal dělat dřív, než jsem začal používat agile):

Backlog

Jakmile jsem začal používat GTD, vynořily se projekty, seznamy úkolů, kontexty. Zkrátka vím, co budu dělat, kdy to budu dělat. To ale ještě není správný backlog, ne každý seznam úkolů je backlog. Z agile jsem se poučil v tom, že:

• místo souběžné práce na 20 projektech (jakkoliv jich eviduju ještě daleko víc) pracuju na tolika úkolech, aby se daly stihnout do týdne
• projekty jsou menší s ohledem na cíl, který má zvýšit hodnotu mého života (obdoba business values u User Stories)
• zadávám si teď už spíš projekty, které mě budou nejen bavit, ale mají i nějaký dlouhodobější smysl (uzdvihnout 60 kilo mě nezajímá tolik, jako vydržet běhat hodinu na squashi – proč? Daleko častěji něco dobíhám než zvedám).

Iterativní „život“ a sprinty

V životě jsem si zavedl týdenní iterace. Každou sobotu vytvořím backlog toho, co chci za týden stihnout na další týden. Nepřepínám se, úkolů si dávám zhruba polovinu toho, co si myslím, že bych mohl stihnout. Ono to pak vychází, protože obvykle se objeví spousta jiných neočekávaných událostí (třeba se povede sportovat místo 2 dnů v týdnu rovnou 6 dní, což si vezme čas).

Sprint review a planning

Mám-li backlog seřazený podle priorit, většinou je plánování nového sprintu jen nabrání nejdůležitějších projektů a doplnění o nezbytné záležitosti (nákup dárků např.). Sprint review každou sobotu je okamžikem, kdy přemýšlím, zda se můj život posunul kupředu a co můžu udělat do příští soboty, aby se zlepšil co nejvíc. Nicméně je faktem, že malé projekty teprve začínám dělat a mám tu zatím spoustu opravdu dlouhodobých projektů, takže často je review smutné. Spousta malých kroků za cílem v budoucnu. Nicméně každá velká věc se skládá z mnoha malých.

Minimální analýza

Spoustu projektů nerozepisuju na kroky, protože skutečná realizace bývá odlišná. Typicky psaní esejí: navrhnu to pro psaní shora dolů, pak to píšu nahodile tak, jak se mi daří získávat útržky. Nechávám si jen v projektu krok, ať to zanalyzuju víc, až to bude aktuální. Je to takové just-in-time GTD. Co se finančních cílů týká, ikdyž dělávám plány a sleduju náklady, finanční situace se může neustále měnit, proto i následná realizace bývá až podle možností.

Daily standup

Každé ráno a večer mám několik rituálů. Ráno si dávám výživu na klouby a hlavně si rozepíšu úkoly na den z nichž obvykle tři označím za DAYTASK. Potom si rozepíšu cvičení na den (snažím se každý den buď sportovat, nebo alespoň udělat 100–200 sedů-lehů a nějaké kliky). Večer pak si zapíšu všechny náklady za den a vyčistím e-mailovou schránku na nulu (odpovím, převedu do úkolů, nejčastěji ale vymažu).

Jaké je ponaučení z agile a jak bych mohl tento proces zlepšit?

Mohl bych každý den udělat opravdu scrumový standup, podívat se, co jsem udělal včera, co chci udělat dnes a zjistit, zda mi v tom něco brání. Asi to zkusím už tento týden zavést.

Hodnocení úkolů v bodech

Všechny úkoly, které mě čekají, hodnotím v pomodorech (půlhodinách práce). Každé ráno při vytváření seznamu úkolů se podívám, kolik pomodor mě ten den čeká udělat. Podle toho si pak navrhnu, jak dlouho budu v kanceláři, v kolik půjdu spát, atd. Vím (tuším, nicméně odhady se stále zpřesňují s tím, jak sám sebe stále lépe poznávám), kolik toho za den zvládnu udělat.

Hodnocení v bodech mi dává horizont, podle kterého poznám, jaký budu mít den. Zda hodně pracovní nebo vůbec. Taky existují dny, kdy vím, že nestihnu vůbec nic (takže si naberu maximálně řešit telefonické hovory).

Zákaz přesčasů

Dřív sem se snažil za den udělat více práce, teď se snažím udělat za den dostatek práce, která bude ale maximálně hodnotná. Navíc ani už pro mě není možné dělat příliš mnoho jednotvárné práce, protože mám ten systém nastavený úplně jinak. Někdy jindy vysvětlím, jak zaručit, že mám v životě rovnováhu i v době, která je hektická a člověk by se nechal snadno strhnout a dělal jen na jedné věci a nevnímal přítelkyni, vlastní zdraví atd.

Ochrana proti „změnám zadání“

Naprosto luxusní záležitosti jsou inbox v GTD a pauzy mezi pomodory.

Najde-li se nějaký velký úkol – třeba nápad udělat svůj nový dynamičtější flexibilnější bio modřejší facebook – dám ten nápad do inboxu, tedy schránky, kterou vybírám během týdenního review. Většinou do té doby vychladnu, pochopím, jak záležitost zapadá do mého životního stylu a cílů a podle toho ji buďto zařadím do backlogu, nebo ne.

Druhou záležitostí jsou různé články, čtení twitteru, odpovídání na maily a tak podobně. Tyto úkoly se dají řešit v pauze mezi pomodory.

To důležité je, že práce, na které záleží, není zasažena.

Závěrem

Adopce agile do osobního života je u mne teprve na začátku a určitě se z mnoha věcí ještě hodně poučím, ale už teď vím, že povede k častějšímu doručování hodnoty do života, což me u agile ani trošku neudivuje. A co si budeme povídat: úspěch je návyk, který vede k dalším úspěchům.

Zní to strašně jednoduše, jak může tedy Pomodoro pomoci?

1. soustředím se jen na práci
2. každou půlhodinu odpočívám
3. sleduji, jak dlouho mi který úkol trvá a podle toho se rozhoduji, zda na něm mám pokračovat
4. daří se mi snižovat počet vyrušení
5. časové odhady v GTD si dělám v pomodorech – vím už, kolik práce jsem schopen denně udělat

Co k pomodoru potřebuju?

1. kuchyňskou minutku (pravou nebo elektronickou, na doma jsem si koupil suprovou v IKEA – jen má nevýhodu, že na malé časy, typicky na 5min pauzu, nezazvoní, ale jen cinkne)
2. papír a tužku
3. dostatek úkolů :)

Proces je velice jednoduchý, přesto doporučuju přečíst si knížku, která je na webu Pomodoro volně k dispozici v PDF.

Autor Pomodoro technique Francesco Cirillo tuto techniku vymyslel během svých studií informatiky. Pomohlo mu to lépe se soustředit na studium. Dnes už programuje a pomodoro používá v týmu.

Jak to funguje?

Ráno přijdu do kanceláře a prohlédnu si Activity Inventory (v původním smyslu je to papír, kam si píšete všechny úkoly, u mě tuto roli zajišťuje Pivotal Tracker, případně Things). Sestavím si Daily ToDo a ohodnotím úkoly pomodory. Vím, že ikdyž pomodoro zabere jen půl hodiny, když se odečte oběd, zmařená pomodora (vysvětlím níže), komunikace s dalšími lidmi v týmu, jsem schopen udělat denně jen tolik pomodor, kolik hodin chci být v kanceláři.

Poté nastartuji první pomodoro. Během pomodora na mě nesmí nikdo mluvit, jakmile na mě někdo něco chce, buď odpovím do 15 vteřin (v pomodoro ale není dovoleno lidi odbýt nedostatkem informací nebo jim dokonce lhát) a pak zvýším úsilí pro dokončení práce podle odhadu.

Poté, co mi pomodoro zazvoní, udělám si u úkolu v ToDo X. Pokud mě ale někdo vyrušil, píšu si buď ', když jsem to vyřešil do 15 vteřin, nebo /, když to trvalo déle. Pokud to trvá déle, pomodoro nastavím znovu na 25 minut a pracuju znovu. Jakmile je úkol hotov, poznačím k němu _. Pokud se rozhodnu úkol ten den vůbec nedělat, přeškrtnu ho.

Během přestávek mezi pomodory není dovoleno pracovat na témže úkolu, projektu, ideálně by měl člověk dělat něco úplně odlišného (třeba odepsat na maily, které zatím přišly).

Má to nějaké nevýhody?

Výhody už znáte, pomodoro má i nevýhody.

První nevýhodou je zmaření pomodora, pokud někdo potřebuje akutně pomoci. Pak pracujete znovu a časové odhady, kolik jste na práci vlastně strávili, jsou daleko méně přesné (a dělá se hůř review).

Druhou nevýhodou je tlak, který může až paralizovat. Několikrát se mi stalo, že jsem u úkolu na 2 pomodora přemýšlel dobu 1 pomodora, jak to udělat za 1 pomodoro jen abych minimalizoval čas, přitom se mi to nepovedlo a práce trvala potom i s analýzou 3 pomodora (jednoduše proto, že jsem na zkratku nepřišel).

Třetí nevýhodou je, že vás nikdo nenutí tu minutku spustit, takže po prvních 4–6 pomodorech je pro mě psychicky těžké pusti další pomodoro. Řeším to �