Čas je neúprosný

V dnešní době se neustále za něčím honíme. Máme neomezené možnosti a snažíme se tak dosáhnout maxima. Jediné, co nás svazuje, je čas. A moc dobře si to uvědomujeme. Mnohem více než kdykoliv předtím cítíme, jak nic není překážka, dokud nepřijde na čas.

Bylo jen otázkou času :-) kdy si položíme otázku a začneme přemýšlet o tom, zda jde čas překonat. Podmanit si ho. Žijící generace s takovými sny a nápady vyrůstaly, ale není tomu tak dávno, kdy se poprvé objevily první teorie. Pojem časoprostor, kde je čas jako čtvrtá dimenze, na světlo přinesl Einsteinův učitel v roce 1908. Jen chvíli před tím v roce 1895 vznikl první román s tématikou cestování časem, The Time Machine.

Od té doby jsme čím dál více masírováni různými příběhy o podmanění si času. Možnost měnit minulost, opravit chyby, a několik způsobů jak se vypořádat s paradoxy s tím spojené. Zrychlovat nudné pasáže života. Zpomalovat ty dobré. Opakovat je. Skákat mezi časovými obdobími. Vidět budoucnost a moct ji změnit. Nebo využít znalosti, které ještě nemám, ale budu mít.

Je toho tolik a všude, že je těžké přijít s něčím novým. A o tom je nový (rozepsáno po premiéře, publikace se lehce zpozdila) film Arrival. Svěžím neokoukaným klidným stylem servíruje zamyšlení směrem k našemu úhlavnímu nepříteli. Skvěle s tématem pracuje a proto tak dobře funguje. Rád se na něj podívám znovu. Raději než jen na hrdinské sny v případě Marvelu, DC a dalších.

Je možné, že se brzy dočkáme průlomu a přestaneme jen snít, kdo ví. Až sám čas ukáže. Teď však věnujme raději energii nemít potřebu naše skutky měnit.

Rule of Three

I like the number three probably a lot. I'm not sure why. Probably because when someone asked me for the first time, it was my first answer. Like a lot of people uses date of birth. But I not just like it, I also use it a lot.

  1. For example as programmer when I do something for the third time I go write script to do that job for me.
  2. Or when I read or watch something I take at least three most important notes which will remind me that book or lecture later.
  3. Also every year I have three major goals to be sure I'm always moving forward.

It's really magic number to me. It helped me a lot. It saves my time, helps me to not forget and pushes me forward. Feel free to use it or be inspired by it and have magical 2017!

Vše stárne, včetně vědomostí

Chci si napsat malou aplikaci pro Android a jsem na rozcestí – Java nebo React Native? Volba byla na začátku jasná. Java, jak je u Androidí komunity zvykem od začátku. Přes všechna utrpení jsem si připravil prostředí a začal pracovat. Ale rychle jsem narazil. Neznám Javu a neznám Androidí API. Začal jsem tedy patlat dohromady všechno možné dle různých návodů na internetu, abych měl co potřebuji co nejdříve. Na konci dne jsem neměl vůbec nic a naopak spoustu otázek, jak udělám elementární věci jednodušeji, než jak jsem našel.

A pak přišla otázka: chci se to vůbec učit? Rád se učím nové věci. Rád zjišťuji, jak fungují jiné věci, jak fungují jinak. Jenže v tomto případě to není o tom jinak. Je to spíš další spousta znalostí, které za pár let budou k ničemu, a moc mne neposunou.

Vlastně jeden z důvodů, proč jsem na začátku vyřadil z možností React Native. React je tu chvíli, ze světa JavaScriptu, kde se celý ekosystém lehce promění během chvilky. Kdo si ještě vzpomene na Closure Library například? React však umím a docílím toho, co potřebuji, dnes, nikoliv za několik měsíců. Bez nutnosti muset se učit něco, co mi sebere spoustu času a za rok bude stejně k ničemu.

Takže si nakonec píšu aplikaci v React Native. Nikoliv protože chci zkoušet nejposlednější výstřelky. Ale protože nemá smysl se učit něco, co tu s námi dlouho nebude. V mém případě to bohužel prohrála „Androidí Java“.

O tomto tématu se píše i v blogpostu „Reflections of an "Old" Programmer“, který proletěl sociální sítěmi pár měsíců zpět. I vám doporučuji se vždy zamyslet, čemu věnujete čas. Existuje mnohem víc technologií, než stojí za to se naučit. Což jsem demonstroval na jednom mém paradoxním příběhu. :-)

Zápisky z cest: Rusko

Každého druhého srpna v Moskvě slaví tzv. VDV den. Je to svátek výsadkové armády a slaví ho od samého rána. To je poznat především večer, kdy už raději nikdo kromě opilých oslavenců není venku. Přeci jen plavání či souboje ve fontánce nebo rozbíjení vypitých lahví o hlavu (a taky vše dohromady) není pro každého.

Aneb jaký lepší den si zvolit pro přílet do Moskvy!

Zhenya, naše kamarádka a tak trochu průvodkyně na domácí půdě, nás vzala do Gorky Central Parku právě za těmi modrobílými pruhovanými kluky. Pro jistotu jeden z nás si dal tričko naruby a obráceně, aby náhodou fakáč moc neprovokoval, a tak nás žádná adrenalinová akce nepotkala. Vlastně jediná akce byla pěkně nudná – cesta k tomu parku.

V Rusku mají úplně jiná měřítka. V Praze si děláme srandu, že Brno je zahraniční politika. Tam taková vzdálenost je úplně normální. Nedivil bych se, kdyby používali běžně oznámení typu „vyrážím k tobě na návštěvu, připrav za tři dny večeři“. A nejen to. I baráky mají děsně obrovské. Do dveří bych se často vešel na výšku dvakrát. Jsou od sebe hodně daleko, mezi ně nemají problém mít ve městě čtyřproudou ulici. V jednom směru. Vlaky a metra jsou taky obrovské. Tak obrovské, že chodby jsou ucpané, ale vagóny poloprázdné.

Asi to bude tím, že jakmile jedno metro odjede, přijede hned další. Tím se odbaví spoustu lidí, víc, než stihne projít turnikety. Aspoň budete mít čas se pokochat výzdobou. Každá stanice je jiná a něčím úchvatná! Na Stockholm to (asi) nemá, ale pořád je to nejlepší, které jsem zažil.

Všichni jsou na ta měřítka zvyklí. Všude mají internet a jednoduše vyřizují vše možné během cesty. Po pár dnech jsme si na to taky zvykli a stejná cesta nám přišla poloviční. Možná pomohlo, že jsme začali vzdálenosti počítat na počet potřebných lahví vodky na cestu. 8-)

Zároveň je Moskva plná kontrastů. Na jedné straně parádní výzdoba, krásné parky, budovy atd. na straně druhé temné neudržované uličky, kde jsem si až vyčítal, proč jsem musel jít tou nejkratší cestou. Lehký strach ze mne opadl, když jsem mezi tím bordelem potkal procházet pár. Muž v luxusním obleku a žena ve slavnostních šatech.

Pokud chcete vidět nějaký další kontrast, který s Ruskem nemá nic společného, může posloužit třeba Moscow City.

Aby toho nebylo málo, mají v Moskvě takovou úchylku – vše se dá najít fungující 24/7. Například jsme potřebovali dojít na poštu a vyřídit dokumenty ohledně turistické návštěvy. Na poště jsme byli od jedenácti do dvou. Ráno. Ve dvě jsme ještě došli do copy centra udělat pár kopií. Po únavném vyřizování si došli ve tři ráno na Červené náměstí dát tříchodové menu do luxusní restaurace. To je velký rozdíl oproti návštěvy Španělska, kde mi ve tři odpoledne(!) nedají najíst.

U jídla ještě chvíli zůstanu. Zhenya nás vzala do takového bufetu. Budka na parkovišti, do které bych nikdy sám nevlezl. Vlastně bych ani nepoznal, že se tam dá najíst. A přitom to bylo skvělé! Prý to je bufet Kavkazského typu. Měli jsme spoustu různého jídla a najedli jsme se k prasknutí. V přepočtu asi za dvě stovky na naše koruny za jednoho.

Jelikož je pro nás Rusko levné, jedli jsme trochu víc. Před a po bufetu jsme navštívili tržiště. Pak prozkoumávali kouty Moskvy a stavili se v nějaké kavárně. Zhenya nám chtěla ukázat, že ať zajdeme do jakékoliv kavárny, dostaneme skvělé kafe a dezerty. A měla pravdu. Později jsme procházeli kolem další, ale za jeden den jsme toho už měli dost. Jen jsme si přáli, abychom ještě měli hlad.

Takové malé upozornění: Rusko je levné co se týče lokální výroby. Není problém mít za stejnou cenu luxusní jídlo a jeden drink aneb za jeden drink jsem jednou dal v přepočtu téměř tisíc korun.

I přes všechno to dobré jídlo je hra „najdi ošklivou holku“ děsně náročná. Všechny jsou jednoduše neskutečně krásné. Nechápu, jak si dokážou udržet své postavy. Každopádně je radost kochat se a kór, když se tam jede tancovat. Všechny umí taky bezvadně tancovat. Když se v Rusku do něčeho pustí, udělají to pořádně. Stylem výuky se máme od nich co učit.

Nejvíc ale na těch ženách oceňuji jejich ženskost. Neskutečně mne irituje, jak v Americe podržet ženě dveře je skoro brané jako sexuální harašení. U nás je to lepší, ale stále by se mi líbilo tu mít víc dam a gentlemanů. Asi jako v tom Rusku. Nebo co znám i lidi z Ukrajiny či Rumunska, tak i jako tam.

Lidi obecně jsou v Rusku milí. Před návštěvou jsem měl na Rusko obecně negativní názor. Po návštěvě ho mám pozitivní. Jsou to lidi jako všude jinde. Holt politika není nejlepší, ale zrovna my asi nemáme moc co vyčítat. Navíc interně jim to tam funguje, co jsem se tak ptal, dobře a jsou spíš spokojeni než nespokojeni. Tedy jsou více spokojeni než my, jak mi to pocitově přijde.

Možná by všichni měli více cestovat a zjistit, že všude jsme jen lidi. Především politici by měli víc cestovat. Já už se těším, až tam pojedu na návštěvu příští rok znovu!

How to merge git repositories into one keeping history

We had a lot of git repositories and sometimes we had to implement some new feature across more of them and keep in sync. Which is hard and means we actually need only one repository for our project. Well, Google has everything, like everything, in one huge repository, so why would you need separate git for every microservice, right?

Decision was made—merge it but with history. No merge without history. You know, it's pretty easy to split one big repository into more repositories. Other way around is much harder with challenges on the way. That's why I want to give you this help if you are facing same step.

Let's go! First of all you need to know some theory. Best way how to merge repositories is to prepare them in state that there will be no conflict. Let's say you have repositories A, B and C and want them to merge into X. Think about how you want them merge into X. Probably best option is to have in final solution repository X with directories A, B and C containing original repositories in new merged one. By now you probably get that idea—first step is to move all files into directories and then merge them.

You can do it simply with git mv but you will lose history. Actually you will not lose it, still you can blame files and see history with git log --follow. And that's why I don't like this solution. There is better one which will move all files into new directory and rewrite whole history as it would be for the whole time like that:

git filter-branch --index-filter \
    'git ls-files -s | sed "s-\t\"*-&FOLDER/-" |
    GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
    git update-index --index-info &&
    mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
    ' --tag-name-filter cat -f -- --all

Important: watch end of second line, you have to change FOLDER for your name of directory.

When you do it with all your current repositories we can move on to merge it. It's kind of easy part. Add remote and pull it. Just repeat following for all your repositories:

git remote add src_repo_name src_repo_filepath
git pull src_repo_name
git remote rm src_repo_name

Important: src_repo_filepath is meant as just local path. I don't recommend to push those changes to origin. For historical purposes or if something goes wrong, it's good to have old repositories untached.

And now you have your new shiny merged repository, nice!

Yes, but… but what about other branches? You can do similar move for all branches as for master branches. There could be just two use cases when it's not enough or too complicated. For example two branches from two repositories I actually wanted as one branch in final one. I didn't want to do mistake with some cross-git merging (which can be done very easily) so I used different technique: make patches of affected commits and apply them in order as I need.

git format-patch -X HASH

Call this in original repository and branch. HASH is hash of latest commit and X means for how many commits you want to do patches. Then you will see patch files which you can apply. You can also modify and merge more commits into one.

git apply xxx.patch
git commit -m "..." --author ""

Second use case for this solution is when someone has local branch. You can “easily” merge public branches because you changed hashes and it matches but some colleague can have local branch and he will need to merge it as well. He can use this technique for that, just before making patches he needs to move all into same directory (all commits). For those purposes he doesn't have to run first slow command keeping history but faster one:

git subtree add --prefix=FOLDER

And that's it! Hope you will successfully merge it without problems.


Note: this is my first post in English. Sorry for those who prefer Czech. Don't worry I will still publish also some Czech posts. It will depend on how many people I will want to share it with. :-)

Workshopy na festivalech: jít či nejít?

Letos jsem chtěl vycestovat na jeden taneční salsa festival. Vybral jsem si Beach Splash v Šibeniku. Festival po celý týden s tancováním přes celé dny i noci u pláže a bazénků se spoustou šikovných tanečnic (a tanečníků). Lehce mi změnil život a tak pro mne zůstane speciální. Tam jsem totiž konečně začal tancovat salsu on2 aka mambo, procvičil spoustu variací a především se rozhodl jet na další festival.

Do Rostova. V Šibeniku jsem poznal několik šikovných holek z Ruska a když mi Marián říkal, jak tam jsou všechny takové a nemají s kým tancovat, rozhodnutí bylo jasné. Přidal jsem se k mužské posile z Česka. Nepopsatelně skvěle jsem si tam zatancoval a bylo mi smutno, že nebude dlouho možnost si zase takhle zatancovat. K tomu jsem si udělal několik dalších kamarádek.

A všechny měly v plánu cestu na El Sol ve Varšavě. Samozřejmě jsem nemohl chybět. Ale abych nemusel čekat celé tři měsíce, skočil jsem si do Varšavy ještě jednou na jiný festival. A také jsem nemohl chybět na našem domácím kongresu!

Jinými slovy jsem salse úplně propadl a už mám na příští rok v plánu navštívit osm festivalů! Potřeboval jsem však vymyslet, co se spánkem. Ono totiž není úplně zvladatelné jít přes den na workshopy a pak večer být do nějakých pěti až sedmi rána na parketě.

Vyzkoušel jsem si obě varianty a mluvil o tom s více lidmi a došel k závěru, že workshopy nejsou potřeba. Chybí jim totiž jedna důležitá věc: feedback. Možná to okoukám a udělám tak nějak dobře, ale těžko si sám opravím nějaký detail. Kdy často právě detaily udělají celý trik!

Lepší model je navštěvovat oblíbené učitele na běžné hodiny a festivaly naopak brát jako možnost naučené věci vytancovat se všemi těmi úžasnými tanečnicemi (či tanečníky) ze všech koutů světa. Na našich hodinách mamba nás Marián učí samé krásné věci, jenže na běžných tanečních akcích není tolik možností se vytancovat. Je rozdíl a hodně znát, jestli se něco zkouší jednou či dvakrát týdně chvilku večer vs. týden celé dny i noci. Navíc je potřeba zkoušet s více partnery – každá partnerka reaguje jinak a co funguje u jedné, nemusí fungovat u druhé.

Proto u mne od teď uvidíte především party passy a výlety za skvělými učiteli. Ale jako vždy, ani tady není vše černobílé. Zažil jsem i workshopy s ideálním počtem lidí, který mi dal hodně, a zároveň je možné učit i jinak, jako například má v popisu Mamboland, kam se moc těším. :-)

Viva la salsa!

O čem je párové programování?

Když se řekne párování, někteří vidí dva lidi ztrácet čas u jednoho počítače, když by mohl každý dělat něco jiného. Jiní zase vidí dva lidi, kteří daný úkol zvládnou za polovinu času. Pravda může být v obou případech, ale oba případy jsou velmi vzácné. Častokrát je to někde mezi a pravá podstata párování leží jinde, než ve snaze mít úkol hotov rychleji.

Párování je především o investici do budoucna. O investici do kódu, lidí a týmu celkově.

Většinou všichni začnou řešit především, jak párování pomůže kódu, aniž si jsou plně vědomi dalších výhod. I já tak kdysi začal. A jak tedy pomůže kódu? Především tak, že ho vidí dva lidi po celou dobu vývoje. Tím se odstraní problém code review, kdy se při revizi už programátor kouká na výsledek a ne na průběžný tok myšlenek. Programátor může opomenout některý edge case, který bude při review o sto řádcích ještě více zahrabán, ale při programování to druhého hned trkne do očí.

Během párování jsou totiž dva. Jeden, který píše, a druhý, který diktuje aka driver. Běžný muž nezvládne dvě činnosti naráz :-) a tak se může plně věnovat psaní anebo přemýšlení nad všemi dopady okolo. Jinými slovy během psaní algoritmu těžko budete přemýšlet jaké to bude mít následky pro současný či dokonce budoucí kód. Častokrát dostanu nápad, zamyslím se, napíšu kód, pak se na výsledek podívám a zjistím, že jsem si neuvědomil jeden podstatný detail a musím lehce poupravit. V tom lepším případě, v horším až o pár dnů později po review, kde musím upravit mnohem víc věcí, které jsem na tom postavil. A na takové momenty tu je driver – mám instantní feedback na to, co dělám.

Dalo by se říct, že párování je velmi poctivé review. Ano, ale tím to zdaleka nekončí. Mnohem zajímavější je investice do lidí. Jeden z nejčastějších modelů párování je jeden zkušený a jeden méně zkušený programátor. Nemusí to znamenat nutně pouze junior a senior, i junior může mít roli toho zkušenějšího. Jde vždy o konkrétní dovednosti pro dokončení konkrétního úkolu, například programovací jazyk, framework, databáze, část aplikace, … A v této dvojici ten zkušenější v dané oblasti předává znalosti tomu druhému.

V takovém spojení samozřejmě úkol nebude hotov rychleji. Zkušenější programátor by to zvládl sám rychleji. Jenže ten druhý by sbíral zkušenosti sám mnohem déle. Tím je snad očividné, že z pohledu týmu se jedná o jasnou výhodu, investici. Navíc investice není ani tak velká – stejně by se dělalo code review. Při sečtení času psaní kódu, review a případné úpravy vs. párování nebude nijak velký rozdíl. Dokonce párování pomáhá i tomu zkušenějšímu. Programátoři nutně potřebují trénovat (sebe)prezentaci, protože spoustu skvělých lidí selhává při sdílení super nápadů či technologií. Plus nikdo ještě nesežral Šalamounovo hovno, nikdo neví vše a správně. Každý může mít malý nápad, který úplně změní pohled na věc.

Sám nespočítám všechny případy, kdy jsem po dlouhé době zjistil, jak se věci vlastně skutečně mají. Například dlouhou dobu jsem měl o některých technologiích mylné představy a přistupoval k nim za špatný konec. Všechno nakonec sice fungovalo a review prošlo. Kdybych však pároval a řekl moje myšlenky někomu nahlas, opravil by mne mnohem dřív a mohl jsem si ušetřit v některých případech spoustu času.

I z toho důvodu je někdy velmi výhodná kombinace senior a senior. Například jsme v práci měli úkol a byli jsme dva s lehce různými názory, jak to udělat. Vyžádal jsem si párování a tím se vše vyřešilo. Než se dlouze dohadovat, rovnou sednout a diskutovat při každém kroku. Doiterovali jsme do nějakého řešení uprostřed a i když tam budeme po odstupu času ještě ladit nějaké detaily, výsledek je mnohem lepší než kdyby dělal kdokoliv z nás sám.

Abych to shrnul, párování je investice. Díky párování se mnohem rychleji zaučí nováčci v týmu. Rychleji celý tým nasbírá spoustu potřebného know-how v týmu. Corové věci budou mnohem vyšší kvality. Nebude potřeba review, párování je totiž nejkvalitnější review. Rychleji lze vyřešit problém – kolikrát jste se už zasekli u řešení (nejen) bugu a potřebovali pomoc? Naučíte se různé postupy, tooly a zkratky, na které byste jinak nenarazili. Naučíte se prezentovat a učit. Samé pozitivní věci!

P.S.: Pokud nejste po půl dne párování naprosto vyřízení, děláte to blbě. Párovat nelze celý den, párujte klidně složité úkoly půl dne a pak sami odpočívejte u jednoduchých až primitivních úkolů.

Monolit nebo microservices? Ani jedno, services!

Velké kusy jsou zlo, ať žijí co nejmenší kousky!

To je s čím se často setkávám. Mám však jiný názor: praktičnost je mnohem důležitější než cokoliv jiného. Pokud budu mít úplně vše v jednom a bude problém takovou obří věc nasadit – je to špatně. Pokud budu mít spoustu malých krabiček, které budou různě mezi sebou komunikovat, sahat si na stejnou databázi bez plné automatizace včetně monitoringu – je to taky špatně.

Jakoby by existoval buď jen obrovský neohrabaný monolit nebo spoustu malých microservices. To ale není pravda. Existuje taky celá škála mezi těmito pojmy.

Spousta lidí utíká před monolitem, protože je tak nějak obecně známé, že mít aplikaci jako monolit je špatné. A sexy slovo je microservices a vrhají se po něm, aniž by vlastně věděli proč a přinášelo to nějaký dobrý užitek. Nepochopte mne špatně, nejsem proti microservices. Jen mají velmi málo opravdových využití a pokud mají, je potřeba jim velmi dobře rozumět a být na ně připraven. To samé platí pro monolit.

Drtivá většina naopak potřebuje něco uprostřed, říkejme tomu services. Něco, co logicky patří k sobě. Do takového logického celku může patřit databáze, cron joby, API, webovka a cokoliv dalšího, co utváří službu. A všechny tyto části mít v jednom repozitáři.

Z toho plyne spoustu výhod:

  • Jednu změnu lze provést v jednom commitu.
  • Snadněji se bude testovat, že je celek funkční.
  • Vždy vím, co je s čím kompatibilní – to co bylo dohromady v jednom commitu.
  • Nejsou tak problémy se závislostmi.
  • Deployment je pak mnohem přímočarejší a v případě nouze i rollback.

Pokud se služba rozbije na microservices, výše zmíněné výhody budou tu tam. Jakmile začnou dvě microservices komunikovat se stejnou databází, musí být někde specifikován model a pomocné funkce k němu. Jenže kde? Velice pravděpodobně v nějaké extra knihovně a bude se muset řešit závislost. Tím začne boj o to, co s čím je vlastně jak kompatibilní, z čehož vyplývá i pořadí nasazování. Testování napříč celou službou začne být náročné až téměř nemožné a bude vznikat spoustu falst-positiv či false-negativ, záleží na stylu testů. O jedné logické změně přes víc repositářů ani nemluvě.

Někteří si mohou všimnout, že co popisuji nejsou ve skutečnosti microservices. A budu jenom souhlasit. Microservices mají v definici nezávislost nasazování. Mezi lidi se však nějak dostalo „monolit je zlo a jediné správné jsou microservices, což je jeden proces napsaný v jednom jazyku“.

Aby se microservices v tom podání, které popisuji, obhájili, často slýchám či čtu podobné reakce:

Mohu nasazovat různé části různě často. Jenže to právě vede k častým problémům. Co s čím je vlastně kompatibilní, jak něco takového testovat, v jakém pořadí se musí instalovat, … Pokud tým něco takového opravdu nutně potřebuje, pak může mít smysl vynaložit energii do řešení těchto problémů. Jinak rozhodně ne.

Délka buildu je s microservices mnohem kratší. Koho to vlastně trápí? Nikdo to stejně ručně dělat nebude. V případě microservices je potřeba tak jako tak mít automatizaci na všechno, takže nikdo těch pár vteřin ani nepocítí.

Lehčí udržet čistotu a může pracovat na aplikaci více lidí. To lze i u monolitu. Množšství kódu bude úplně stejně, jen lehce jinak rozházen. Velikost repozitáře není důležitá, například Google má jeden obrovský úplně se vším!

Lze lépe škálovat. Jsou situace, kdy bude lehce snadnější situace u microservices, každopádně jak poběží aplikace na serveru by mi nemělo diktovat, jak si strukturovat aplikaci. Navíc s dnešními kontejnery rozhodně nechci, aby aplikace řešila kde a kolikrát běží. Chci jen aby uměla běhat kolikrát bude potřeba.

Je to jednodušší. To snad nyní už ani nepotřebuje komentář. :-)

Abych to shrnul, běžte do microservices, ale do těch správných. Pokud vás to svádí ke špatným, říkejte tomu prostě jen services.

Párové programování…

…není pro každého.

Aspoň co mi zkušenosti s párováním říkají, nejde využít párování s kýmkoliv. Kdysi jsem narazil na vtipný tweet, který má v sobě hodně pravdy: pokud se mají programátoři rádi, párují, pokud ne, dělají review. Ale není to jen o tom. Je tam ještě jedna důležitější věc. Většina programátorů jsou spíš takoví introverti a u párování se musí programátor otevřít. Musí ukázat své silné stránky, ale také ty slabé.

Při párování je pak hodně vidět, že vlastně někdo používá vim (či jiný editor, klidně i celé IDE) neefektivně. Že vlastně nevyužívá všech jeho možností a pluginů. Je hodně vidět, že vlastně debuguje stále „líně líně“, tzn. ne programátorsky líně, ale prostě líně – raději pomalu hází printy, než aby využil testů, nedej bože TDD, případně jiných zvyklostí konkrétního jazyka. A co je asi nejdůležitější – jsou vidět jeho myšlenkové pochody. Jak se ke všemu vlastně dobírá oklikou, až hloupě, dá se říci.

A to je to, co spoustu programátorů odrazuje od párování. Protože nechtějí, aby takové nedostatky byly vidět. Jednou jsem byl na večeři se začínající herečkou a barvitě mi vyprávěla, jak to mají herci těžké. Že se na place musí plně otevřít. Jsou vidět všechny chyby. Celá osobnost. Nic nezůstane u kolegů skryté. Jak je těžké něco takového přijmout a žít s tím. Hodně mi to připomínalo právě párování.

Každopádně když se přes tohle člověk dostane, stane se mnohem lepším programátorem. Párování má totiž spoustu výhod a vůbec se není potřeba bát svých chyb. Díky párování má člověk právě možnost se chyb zbavit. Je hodně literatury na spoustu témat, ale praktické věci se z knih nevykouká. Praktické věci je potřeba natrénovat a okoukat od ostatních.

Žádná kniha vám neřekne, jak máte ovládat editor. Žádná kniha vám neřekne, jak debugovat. Žádná kniha vám neřekne, jakým stylem tvořit kód. Záměrně píšu tvořit, protože na první dobrou se nikdy nic nenapíše. Vždy se nějak musí začít a postupně se dobrat k co nejlepšímu výsledku. Cesty jsou různé a každý si našel nějakou svou a té se drží. Jenže cest je spoustu a je velmi poučné sledovat někoho jiného s jinou cestu, kterou mne může obohatit.

Proto mám osobně párování rád. A proto také začnu nový nepravidelný seriál s články jakým stylem programuji. Takové párování přes blog posty. :-) Snad se bude líbit a někdo obohatí i obráceně mne, když uvidí, že něco dělám prapodivně (nebo i jen jinak). Pokud máte nějaký požadavek na konkrétní téma, nebojte se říct v komentářích! Stay tuned!

Jak bychom se měli chovat k dětem?

Jako malý jsem poměrně často slýchával „to pochopíš až budeš starší“. Nevybavuji si, jaké jsem z toho měl přesné pocity tenkrát, ale retrospektivně jsem si jist, že mne to dost štve. Na spoustu věcí jsem si musel přijít sám a i když některé překvapím, kam jsem se zatím dostal, nepřijde mi to nijak výjimečné.

Mám pocit, jako by mi lehce pomohlo štěstí, jaké lidi jsem si k sobě našel. Přeci jen nás hodně formuje naše okolí. Dovedu si snadno představit, že by vše mohlo být úplně jinak a stačilo by málo. (Díky Próšo, Marcelko a Terko! Později spolubydlícím, kolegům, Evče, Mariánovi a všem z tanečního světa!)

Proč máme takový problém chovat se k dětem jako sobě rovným? Představte si, že byste nevěděli co to je skleróza a jako odpověď by se vám dostala, že na to nejste dostatečně staří. Až vám bude šedesát, tak to pochopíte.

Na toto téma jsem narazil dřív už v knize, s lehce delším názvem, How to Talk So Kids Will Listen & Listen So Kids Will Talk. V knize se píše o zapojování děti do rozhodování rodiny. A ne jen co bude k večeři, zahrnovat je i do financí. Vysvětlovat vše možné už od raného dětství a nebát se, že by něco nepochopili nebo pochopili špatně.

Je to takové škatulkování, které máme rádi. Tobě je deset, musíš umět tohle a tamto, a tamhleto bude v testu příště. V testu, který mají všichni stejný. Kdo se nezajímá, jednoduše je odpadlík. Kdo se zajímá, je zbytečně utlumován. Až jednoho dne…

Moc hezky o tom mluví Sir Kenneth Robinson v jeho bezvadných dvou přednáškách o vzdělávání, Changing Education Paradigms a How to escape education's death valley:

Nikdy jsem nad tím tolik nepřemýšlel. Až film Tohle je náš svět, resp. hezčí originální název Captain Fantastic, mne o tom donutil přemýšlet. Určitě doporučuji film shlédnout, každopádně stručně: rodiče se domluvili o žití mimo civilizaci a o výchovu dětí se postarají sami. Tak, že se nebudou nic bichlovat, ba naopak se bude po nich chtít pochopení a vysvětlení vlastními slovy. K tomu dostanou vysvětlení na jakoukoliv otázku. Třeba i co to je znásilnění a soulož. Desetileté holčičce.

Největší kontrast je vidět při příjezdu na návštěvu ke známým, kde jsou děti vychovávány „normálně“, řekněme spíš jak je běžné. Na jedné straně ví, co to jsou adidasky a překvapuje je, že někdo to neví, na druhé straně neví nic o světě a jeho fungování.

Což je proč mne retrospektivně vadí absence odpovědí na moje otázky. Věděl jsem spoustu běžných věcí, ale nic o fungování světa. Sice nemám s výchovou žádnou zkušenost, ale až nadejde situace, přijde mi zatím nejlepší dětem vše vysvětlovat bez servítek, stejně jako Ben ve filmu. Přeci jen děti jsou taky lidi, proč se k nim tedy tak nechovat?