Nexus 5x vs. Pixel

My old Nexus 5 was broken and I needed new one. It was just few weeks after Pixel was released so I had tough question: go for Nexus 5x with discount or go for Pixel?

There was really big pro for Nexus: the price. 8 vs. 22 thousand (CZK) is a big difference. On the other hand, I like to have latest Android. Mostly because Google, kind of, cares about security and privacy and all good new features are available only in latest versions. To buy older Nexus 5x means to deal with end of support sooner. Additionally, Google released few features only for Pixel. Of course I wanted that!

But I stayed reasonable and bought Nexus 5x. It was almost a year ago. One month ago I went on vacation to New York City and there I discovered that a lot of Nexus phones have some bug which means: you will not be able to turn it on again. All not synced data lost. Of course it had to happen abroad. No one there could fix that soon so I had to buy new one again.

I was surprised that it's hard to find something else than the iPhone. In NYC is everywhere only iPhone. Actually, I had only one option to stay with Google phones: to buy Pixel finally. It was like some kind of sign! :-)

I love this phone! It's smaller. Prettier. It has better glass. It feels more precise. The camera is much faster and also results looks better (which is weird because both have almost the same). It has more memory and a better processor. That new assistant is very cool, at least in NYC. Amazing!

But! But because of using metal and glass it's heavier and slippery. The difference is very small, anyway very notable. I could hold my Nexus and also Nexus 5x lightly on fingers even in vertical directions without problem. Now it's not possible. I cannot have it in my pocket because when I sit down, there is big chance it will slip off and I will lose it.

It's not good for such expensive phone. In the end, I'm kind of sad that my Nexus 5x didn't make it. Because Pixel is not so much better. It's just a little bit better with assistant I will not use in Prague and nice design which is not practical. Not worth that money. Hope next one will be again more like Nexus.

I want a next Google phone more practical and more affordable. I know, it is impossible, so at least I wish that. :-)

Oblíbené restaurace (v Praze)

Moje úchylka na skvělé jídlo začala poměrně nevinně. S přáteli jsme čas od času zašli do lepší restaurace, kde jsme nechali pro nás v té době velké peníze, a užili si něco, co si běžně nemůžeme těsně po škole dovolit. Jednou jsem měl dobrou náladu a chtěl jsem za své milé přátelé zaplatit. V kamarádovi se probudilo chlapské soupeření a nakonec zaplatil on. Tím se odstartovaly naše pravidelné návštěvy a střídání u placení.

Soupeření však neustalo. Předháněli jsme se kdo pozve do lepší restaurace. Po čase jsme se tak dostali na úroveň, kdy pro nás dřívější skvělé restaurace byly najednou na úrovni obyčejné hospody. Na úroveň, kdy už člověk za ty peníze chce opravdu něco skvělého. Problém byl – jak poznat, že to v té restauraci bude dobré a nebudu litovat?

Naštěstí jsem se dozvěděl o skvělém Grand Restaurant Festivalu, který probíhá každý únor. Možnosti si za „pouhých“ šest stovek ověřit celkovou spokojenost z restaurace. O festivalu jsem se dozvěděl teprve dva roky zpět a v ten rok si ho nestihl řádně užít. Což jsem napravil loni a letos. V dalších ročnících se mnou určitě mohou počítat!

Navštívil jsem spoustu různých restaurací a letos jsem hodně přemýšlel, co mi vlastně říká, že jsem si nějakou restauraci zamiloval. Proč mne například jedna z nejlépe hodnocených nepřijde tak skvělá jako jiná z konce TOP 100 žebříčku. Vlastně to nebylo vůbec složité přemýšlení…

Neumím hodnotit pouze jídlo. U těch TOP restaurací už ty velice jemné nuance v jídle, si myslím, ani nepoznám. Vždy zbožňuji, když kuchař přijde se zajímavým nápadem, například ke kachně dát pomerančovou omáčku, ke kotletě jablka v šafránu, crème brûlée s ananasem a spoustu dalších hrátek s jídlem. Ale to umí od určité úrovně všude.

Pro mne je důležitý celkový zážitek. Nemyslím tím pouze obsluhu, ale taky prostory a další drobnosti jako například přítomnost živé hudby. Určitě je taky hodně důležitá společnost. Naštěstí na kamarádky jsem obecně hodně náročný, takže problém se společností jsem nikdy neměl. :-)

Pozastavím se u těch prostor. Spoustu restaurací má neskutečně krásné prostory. Ale já si to tam neužiji tolik jako jinde. V poslední době mám hodně rád procházky starou Prahou až si říkám, jak by se mi líbilo ve Starém Městě bydlet. Kdyby tam nebylo tolik turistů. Minimálně se svým šatníkem bych tam zapadl, jak trefně několik kamarádek podotklo. Možná i proto mne tolik začala bavit historie, teď naposledy První republika. Což hodně ovlivňuje, které restaurace jsou mé nejoblíbenější.

Takže které restaurace to jsou?

Všechny mohou nabídnout famózní jídlo, skvělou obsluhu a perfektní romantické prostředí. Pořadí mám podle mých pocitů z návštěvy či návštěv. Je velice možné, že po čase pořadí upravím. I když Art Nouveau v prostorách Obecního domu, s živou hudbou a stolem u okna, kde je naprosté soukromí, se bude těžce překonávat.

Teď už jen i v Praze vyzkoušet restauraci s Michelinskou hvězdou. Máme tu tři: Alcron, La Degustation a nově Field. Z mého textu a popisu restaurací je jasné, že nejvíce bych si měl užít Alcron.

I když La Degustation patří k Ambiente a jakoukoliv restauraci od nich mohu doporučit. Jejich sněz co sníš degustace, ať už italské či masové, jsou boží. Další z dostupnějších mám rád La Gare, Mariott nebo La Casa Argentina.

A jaký typ restaurací máte rádi vy? Které konkrétně? :-)

První republika

Dostaly se ke mne dobré ohlasy na knihu První republika 1918–1938 a zaujala mne natolik, že jsem si ji koupil. A dobře jsem udělal!

Ve škole jsem si vybudoval averzi k předmětům, kde po mne chtěli znát zpaměti jména a data. Což znamená, že v literatuře a dějepise mám spoustu mezer. Pamatování takových věcí mi stále nejde. Naštěstí nyní, několik let po škole, nikdo po mne nechce takové věci pamatovat a tak si rád z těchto dvou oblastí přečtu zajímavé knihy. A dokonce mne to baví! Jako třeba právě kniha První republika.

Díky této knize jsem pochopil strašně důležitou věc. Narodil jsem se chvíli po tom, co se začalo internetu říkat internet, i když v našich končinách se o něm ještě moc nevědělo. A jako vášnivý programátor jsem viděl svět úplně jinak. Sice jsem ještě na chvíli zažil časy bez spojení a chytrých zařízení, ale moc si z toho nepamatuji. Mám tudíž obtíže si představit dobu před technologiemi a internetem. Když to hodně přeženu, abych vysvětlil, co myslím, moje představa byla, že před sto lety jsme byli ještě na stromech, v lepším případě v jeskyních.

Jenže ono to tak vůbec nebylo. Všechno bylo úplně stejné! Jen jsme neměli všichni v kapse instantní chat, který se snažím ignorovat a ne vždy se mi daří. A i přesto už tehdá byli Češi všude možně po světě a nebyl problém se domluvit. Doma jsme věděli dobře, co se děje v celém světě. Nebyl ani problém cestovat.

Pochopil jsem, jak funguje politika. Jak se vlastně tvoří takový národ. Že vlastně žádný systém není dokonalý a i opěvovaná První republika měla své problémy. A stejně tak, když mi pár lidí říkalo, že by byli rádi, kdyby se monarchie nerozpadla, ta měla ještě větší neudržitelné problémy. Pomohlo mi tak lépe pochopit dnešní politiku a Evropskou unii.

Kniha nabízí mnohem víc. Sečteno podtrženo, skvělá investice. Vše je moc pěkně zpracované, popsané a ukázky jako tehdejší noviny, první zákon a další jsou k nezaplacení se do té doby úplně ponořit a pochopit. Doporučuji!

Co mi dalo pět let na jednom projektu

Podobnost s předchozím článkem není ponechána náhodě. Je to takové volné pokračování myšlenek. Na interní službě SOS (Seznam Obchodní Systém) v rámci Seznamu jsem byl přesně pět let a jeden měsíc. Měsíc leden jsem tam zůstal navíc ještě jako podpora, kdy jsem hodně pároval a předával vědomosti nejen o projektu. To mi dalo i zajímavou příležitost vidět před odchodem celý projekt z trochu jiné perspektivy a čas na zamyšlení.

Díky tomu jsem si všiml jedné velmi zajímavé věci, které si lze všimnout právě po delší době na „jednom“ místě. Lidi se totiž točí přibližně co dva/tři roky a tak jsem poznal různé programátory a viděl jejich pohled na stejný kód a práci jejich předchůdců. A jelikož jsem znal i některé předchůdce, udělal jsem si obrázek.

Obrázek mi vyšel takový, že programátoři mají tendenci neustále něco zlepšovat. Aspoň to je to, co si myslí. Ve skutečnosti chtějí spíše měnit k obrazu svému. Jak si myslí, že je to správně. Realitou ale je, že nikdo neví, jak je to správně. I když víme, co vše systém má umět, nebudeme schopni si jít sednout a na zelené louce postavit krásnou vilku. Kód, který tam nyní je, by nebylo možné použít a nejlepší by bylo sáhnout po něčem novém. Novém Pyhtonu, jiné komunikační vrstvě, využít jiné patterny, napsat web jako SPA nebo naopak nepsat už jako SPA atd.

Tedy dnes sice víme, co jsme neměli dělat tak, jak jsme udělali. Jenže s dnešními technologiemi zase nevíme, čemu se vyhnout tentokrát. Protože to je prostě něco nového a musí se zase prozkoumat. Jinými slovy opět udělat chyby. Což je důležité si uvědomit, než se začne křičet jak někdo mohl něco napsat jak napsal.

Neříkám, že by se mělo smířit, jak kód vypadá, a přidat další bez žádného vylepšení. Právě přesný opak: zlepšovat! Ale ne neustále to samé. Protože mi přijde, že se často řeší ty samé věci dokola. A jakmile se dostane do jednoho bodu, začne se mluvit o tom, že to vlastně není dobře, a předělává se znovu. Třeba i do více méně verze, jak bylo dřív.

Byl jsem v tomhle ohledu mírný a dnes už vím, že bych měl přitvrdit. Například struktura kódu, validace vstupních dat, úroveň zobecňování, … jsou věci, které se řeší téměř všude a neustále, každý na to má svůj názor a jiné zkušenosti a nikdy řešení nebude perfektní. Protože perfektní neexistuje. Takže nemá smysl se snažit o dokonalost a neustále měnit ty samé věci.

Málokdo (čti opravdu málokdo, nejsem to ani já a velice pravděpodobně ani vy) dokáže napsat nadčasový kód. Podobně jako málokterý spisovatel dokáže napsat nadčasovou knihu či scénárista film.

Je potřeba se smířit s tím, že před námi napsal kód „prostě jen člověk“ a nezabývat se zbytečným přepisem. Na každém projektu je spoustu zajímavých a mnohem důležitějších oblastí, které je potřeba řešit. Stačí se rozhlédnout, udělat si seznam a priority. A řešit to, nikoliv jestli v pár let starém kódu je [doplň si jakoukoliv nekritickou věc, která tě irituje].

Co mi dalo pět let v Seznamu

Už na pohovoru mi Petr, (v té době) budoucí nadřízený, říkal, že se nejedná o veřejný projekt. Abych nebyl zklamán. Zřejmě byl překvapen, když mne to naopak potěšilo a bral jsem všemi deseti. :-) Utíkal jsem totiž od klientů/uživatelů, s kterými jsem si užil svoje. Chtěl jsem přestat řešit věci, které mne nebaví, a zaměřit na věci, které mne naopak baví. A to vývoj.

Když jsem nastoupil, moc jsem toho neuměl. Nevěděl jsem ani, že je rozdíl, zda definuji proměnou v initu nebo na třídě. Ani verze Pythonu mi moc neříkaly, resp. bylo mi úplně jedno, jaká kde je. Verzování pro mne bylo pouze commit. Testy jsem věděl, že jsou dobré a chtěl je psát, ale zkušenost žádná.

Přišel jsem jako jeden z pomocníků k projektu, který už nějaký rok běžel se spoustou úkolů a žádný čas na řešení technického dluhu. Seznam má naštěstí výhodu v podporování teambuildingů a tak jednou v hospodě jsme se s kolegou dohodli, že zavedeme code review. A bylo. Když to ulehčím. Samozřejmě jsme si to dlouho ladili a ladíme neustále.

To vyvolalo diskuze o tom, co vlastně používáme. Framework uplácaný na koleni z dob, kdy frameworky ještě pořádně nebyly. Což o to, na dobu vzniku dobré, ale nijak dál se nevyvíjelo. Takže čas migrovat. Měl jsem v té době hodně rád Django, takže jsem přispěl s refaktoringem modelů na něco jako modely v Djangu. Aby se to mohlo jednou na Django převést. Kéž bych v té době viděl do budoucnosti…

…a věděl, že bez testů je refaktoring blbost. Potřebovali jsme testy. Měl jsem o testování velký zájem, takže jsem byl pověřen nastudováním, vyslán na školení, zavedení na projektu a zaškolení kolegů. Zpětně se těm úplně původním testům doslova řechtám. Ale bylo potřeba nějak začít a úkol to splnilo.

Jedna z vtipných věcí byl pětiřádkový SVN hook, který testy pustil a poslal mail. Ještě že Petr viděl za včas kam to směřuje a poukázal na sluhu Jenkinse. Slouží nám dobře dodnes. Jen jsme ho postupně zahltili více a více úkoly. O tom za chvíli.

…a taky, že když na měsíc odjedu, nakonec se rozhodne pro Flask a SQL Alchemy. Při prototypování vyšel jako vítěz co se týče možností poskládat a postupně rozšířit do celé aplikace bez nutnosti zastavit vývoj nových featur. Takže rozhodně nelitujeme.

Což jsem už v době, která byla pro mne i tým zlomová. Dostal jsem celý tým na starost. Kluk, který rád programuje a nemá rád lidi, se má najednou postarat o celý tým. Mám však rád výzvy, tak jsem do toho šel. Spoiler alert: dnes už vím, že mne to děsně baví!

A proč to bylo zlomové pro tým? Protože mám asi tak trochu úchylku na automatizaci. Ne že bych si automatizoval úplně vše, ale mezi slepými jednookým králem, že. Začalo to už chvíli po nástupu do Seznamu, kdy jsem si udělal několik utilitek. Jmenovitě například pro balení deb balíků a jejich instalaci na testovací servery či pro práci s logy.

Což bylo fajn, ale chtěl jsem je dotáhnout mnohem dál. Takže jsem postupně projekt vedl k bodu, kdy nasadit na test neznamená sedět u počítače půl hodiny a bouchat něco do konzole. Nemluvě o nasazení do provozu. Ale nedělat nic, naopak si vychovat sluhu. Jenkinse. Což teda znamenalo spoustu práce na pozadí, která není ani vidět (a produkťáci se pro jistotu ani nesmí dozvědět :-)), ale přijít do práce a vidět v e-mailu, které tickety byly samy přes noc nasazeny, je slast.

A ještě větší radost je, když už od vývoje do provozu nejsou průměrně dva měsíce, ale týden. Pro to jsme museli změnit styl verzování a zlepšit testy a code review. Se vším jsme se poprali. Dnes už větvíme o sto šest a všichni vyjmenují základy Gitu i ve dvě ráno. S integračními testy nám pomohl pytest a Selenium (o čemž jsem už párkrát vyprávěl na různých akcích a konferencích; například v Bilbau a českém PyCONu). Jen code review nám dlouho haprovalo. Dnes se už můžeme chlubit párováním, což je nejlepším code review. Odhadem tak třetina, možná i polovina, kódu se páruje a zvyšujeme.

Druhý tool jsem měl pro stahování a parsování logů. Jenže, i když jsem téměř nemusel nic dělat, stále trvalo půl hodiny dostat se k požadovaným informacím. Navíc se hledalo jen to, co se nahlásilo. Takže jsem opět pomaličku nepozorovaně dostal na televizi téměř real-time chyby z provozu se všemi potřebnými informacemi k rychlému vyřešení. (Všichni sborově: áááh.)

Když jsem si říkal, že už jsem udělal dost a zasloužím si po pěti letech změnu, pustil jsem se ještě do jedné věci na rozloučenou. Dokumentace. Abych mohl vše, co o aplikací vím, sepsat. A nejen já, ale všichni v týmu mohli mezi sebou sdílet informace, proč se kde co jak vlastně udělalo. A jak to vlastně používají samotní uživatelé.

Ano. Po pěti letech projekt opouštím a bude mi hodně chybět. Přeci jen to byla parádní jízda a těch pět let mi dalo opravdu hodně. A nebude mi chybět pouze, co jsme na projektu dokázali a jak nám funguje, ale i kluci. Přeci jen celý tým jsem si sám poskládal dle svých představ. Cítím však potřebu změny a věřím, že díky schopnosti kluků moje absence nebude vlastně ani znát. Těším se, až si za dalších několik let sedneme s Viktorem (mým nástupcem) a budeme se smát dnešní situaci jako se nyní smějeme té před pěti lety. Protože je stále co zlepšovat a hlavně je v backlogu spoustu zajímavých projektů. Pro které mimochodem Viktor určitě uvítá dalšího pomocníka.

Každopádně nejdu moc daleko. Seznam mám rád, takže se jen přesunu o pár stolů dál, kde se budu dál zlepšovat na projektu doporučování a cílení.

Coders at Work: rozhovory s velikány v oboru

Pořídil jsem si knihu Coders at Work: Reflection on the Craft of Programming. Což jsou rozhovory s velikány z oboru. Chtěl jsem se tedy dozvědět nějaké jejich názory. Takový výtažek, který jsem si z toho vzal, někde i sám přidal, tu sdílím.

Začneme školou: není potřeba. Pro to, abych mohl programovat. Programátorský svět se tak rychle vyvíjí, že se musí učit neustále. Kdyby na škole záleželo, pak by se škola nikdy nemohla opustit.

V rozhovorech se řešilo i jaké má programování postavení mezi obyčejnými lidmi. Zda by se mělo zařadit mezi základní předměty jako jazyk a matematiku. Nemělo. Základní věci lze naklikat a pokročilé věci stejně nepochopí, jako programátoři si nezvládnou ušít oblek.

Taky si pamatujete, jak pracovat ve skupině bylo bráno jako podvod? Tak přesně taková je nejlepší praxe: párovat. Pomůže udržet focus na úkol. Aneb kolikrát začnete lelkovat, když se dostanete do slepé uličky a potřebujete odstup? Ten druhý má ten potřebný odstup. Jiný pohled. A tak.

Párování je dobré taky pro zaučování. Stejně jako jinde se nováček učí pozorováním mistra, aby se jím jednou taky stal, je dobré toto aplikovat i v programátorském světě. Nemusí to být nutně nováček. Spoustu lidí se naučí algoritmy atp., ale nikde se neučí jak debugovat. Což je skill, který trvá dlouho osvojit si. Párováním ho lze získat mnohem rychleji.

Pokud není dostupný nikdo do dvojice, stačí mluvit s něčím. Třeba na PyCON UK 2014 rozdávali debug kachničky. Často jen říct si, jaký mám problém, co je jeho vstupem a výstupem, stačí k jeho vyřešení.

Aby ale nebylo potřeba debugovat, Tony Hoare má skvělou frázi, že lepší mít kód, kde samozřejmě není žádný bug, než kde není žádný zřejmý bug. Nebo lépe v originále: „your code should obiosly have no bugs rather than having no obvious bugs“. Pro to je potřeba držet čitelný kód. Základem je formátovat kód, stejně jako formátujeme běžný text. Což Dijkstra podtrhává větou: „if you can't write in your native language, give it up“. Hned druhým důležitým bodem je správné pojmenování. Jsou i programátoři, kteří mají vždy po ruce slovník.

Čitelnost se pojí i s optimalizováním. Pravidlo je, zůstat u čitelnosti a neoptimalizovat. Protože často, ne-li vždy, programátoři řeší optimalizaci toho, co je cool, zajímavé, náročné. Ale tyhle části nemají žádný zásadní vliv na optimalizaci a co je skutečně potřeba, na to se nesáhne. Proto lepší zůstat u čitelnosti a až když je opravdu potřeba, teprve pak jít optimalizovat. Což má druhou výhodu – čitelnou verzi už mám a tu nesmažu. Nechám ji vedle té optimalizované. Tak bude kód čitelný a pokud se najde chyba, můžeme přepnout na pomalejší správnou. Mimochodem jednodušší je optimalizovat správný kód, než opravovat optimalizovaný kód.

Postupným vývojem ale kód tak jako tak degraduje. Když se problém zapisuje do kódu, musí se najít způsob, jak to zapsat. Jenže postupem času se problém může trochu změnit. Nebo naopak problému začneme lépe rozumět. Tím nám původní kód přestává vyhovovat a musí se upravit. Protože když se ponechá ve starém znění, kód začne být nečitelný.

Otázka je, kdy refaktorovat? Někdo říká neustále, někdo po Xtém sprintu, … Udělejte to tak, jak je potřeba. Často stačí držet se skautského „ponechám kód v lepším stavu, než jsem k němu přišel“. Někdy ale je potřeba změnit celou architekturu. To se dá poznat podle pomalosti vývoje, aplikace, bugovosti atp. Vývojáři nejsou ze dne na den horší. To jen kód degraduje a je horší ho udržovat.

Jak ale tohle vysvětlit produkťákům/klientovi? Nijak. Refaktor je potřeba si plánovat mezi běžné věci. Něco odhadnu na tři dny, tak tam šoupnu čtyři na potřebný refaktor. Pokud potřebuji velkou změnu, třeba frameworku, o čem se nerado slyší, zabalím to do jiného názvu. Třeba údržba pro zrychlení vývoje, aplikace a menší chybovost.

Není nic horšího, než když se někdo bojí sáhnout na něčí, či dokonce svůj, kód. Na to je lék testování. Testy dodávají jistotu. Čím lépe otestovaná aplikace, tím větší jistota a klid na duši.

Aby testy měly smysl, je potřeba testovat inkrementálně, stejně jako se píše kód. Nejlépe formou TDD. Často se naráží na problém, že nelze napsat test, pokud nevím, jak kód bude vypadat. To je chyba. Je dobré nejprve vědět, jak chci kód využívat, a poté napsat implementaci. Když udělám opak a zjistím, že chci nakonec používat jinak, musím celé předělat. Pokud z nějakého důvodu takto nelze, aspoň napsat kód nejvíc jednoduše, poté testy, a nakonec udělat refaktor a případné optimalizace.

Testy poslouží i jako taková dokumentace, pokud jinou nemáte. Což teda je potřeba nějakou dokumentaci mít a hlavně ji nepsat až po napsání kódu, ale už s ním. Protože jen tak zdokumentujete, co je potřeba. Za dva dny si těžko vzpomenete na všechny konstrukce, které jste napsali a hlavně proč přesně.

Někdy programátoři dokumentují pouze pokud se jedná o znovupoužitelný kód. Na něco takového zapomeňte, znovupoužitelnost neexistuje. Resp. pouze u stejných problému a často ty stejné problémy jsou již vyřešeny. Vaše aplikace bude jednodušší, pokud ji napíšete jednodušeji bez zbytečných vrstev. Líbila se mi hláška, proč OOP a použitelnost moc nejdou k sobě: „you want banana and they carry around implicit environment with gorilla holding banana within jungle“.

Je to trochu tím, že vývojáři píší kód. A když píšou knihovnu (nebo klidně i celý jazyk, podívejme se třeba na Ruby), chtějí přidat něco svého. Jenže je více věcí, které lze přidat, než věcí, které by se pouze měli přidat. Na to je potřeba cit, který má málokdo. Softwarový vývoj je hodně jiný oproti cokoliv porovnatelnému a stále se učíme jak ho nejlépe vést. I hardware se vytváří jako například stavba domu – cihlu položit na cihlu, sem dám dveře, okno.

Například na otázku „jak bude dlouho trvat tahle změna?“ máme několik možných odpovědí. Pokud je to změna na jeden řádek, víme, že máme rychle hotovo. Jenže pokud je taková změna nesystémová, víc takových hacků by znepřehlednilo kód a pozdější maintenance. Takže druhá možnost je zahrnout nějaké lepší pojmenování a refaktor okolního kódu. Tím ale pouze oddálíme čas, kdy se dostaneme do situace, jako v prvním případě. Pak je třetí možnost, že to uděláme pořádně. Což znamená úpravu zanést řádně do celé aplikace. A to musí programátoři vidět a dát odhad přibližující se poslední možnosti. Pak by nemělo dojít k nutnosti začít na zelené louce.

Nejchytřejší programátoři by neměli automaticky o všem rozhodovat. K dobrému rozhodnutí je právě potřeba ten cit. Bez empatie či emoční inteligence půjde těžko navrhnou dobrý jazyk, API, GUI apod.

Na závěr zmíním, že produkty se netočí kolem technologie, ale kolem výsledku produktu samotného. Technologie je jen prostředek. Takže je jedno, který framework nebo jazyk se použije a není třeba se kolem toho hádat. Já mám rád třeba čokoládový Häagen Dazs, vy zase jinou zmrzlinu. A taky se u toho nehádáme. :-)

EuroPython 2015 – poznámky

Logování

Stejně tak jsem začínal i minulé poznámky. Tentokrát jsem se však dozvěděl víc. A to to, že stále neexistuje žádný pořádný tool. Resp. existuje jich spoustu a každý umí stejnou věc trochu jinak. V základu jde o to, že není potřeba otevírat logy. Automaticky jsou shromažďovány na jednom místě a analyzují se. Vyhledávají se chyby a jiné užitečné „události“. Například pomalé odpovědi, warningy atp. Tyto události se groupují a zobrazují v hezké podobě s grafem četností výskytu. Také s možností se podívat kterým lidem událost nastála a kdy se objevila poprvé, případně naposledy.

Jenže stále neexistuje nic, co by si člověk mohl nainstalovat u sebe. Dostupné tooly fungují jako služby, což v mnoha případech není možno použít z důvodu citlivých dat. Takže tu zůstává ELK (Elastic + Logstash + Kibana), což ale „jen“ graficky zobrazí logy v prohlížeči s možností filtrovat. Tedy nutno si udělat v takovém případě vlastní řešení.

Každopádně je důležité si uvědomit, že aktuální situace na zpracování logů je stále nedostačující. Pokud nemáte problém posílat data cizí službě, běžte do toho (seznam různých možností). Pokud máte, investujte čas minimálně do ELK. Věřte mi. :-)

Type Hinty

S novým Pythonem 3.5 přijde PEP 484 – type hinty. Není divu, že o nich bylo hned několik přednášek. Ale nic velkolepého. Mohlo se slyšet o obhajobě, proč něco takového se do Pythonu vůbec zavádí. Jak to vlastně vypadá. Proč to je takové… ošklivé. A tak.

Osobně mi takové diskuze přišli zbytečné. Jasně, že type hinty jsou fajn. Však to známe z jiných jazyků. A jelikož Python je nezavádí povinně a ani na ně nebude defaultně reagovat, není ani potřeba nic řešit. Naopak spoustu starostí odpadne. Třeba nebude potřeba psát asserty. Pylint nebude mít problémy. A hlavně, což je ze všeho nejdůležitější, editory budou schopné lépe napovídat. Například PyCharm přijde s plnou podporou někdy na podzim. Pylint zase příští rok v totálně přepracované verzi 2.

OK, type hinty jsou fajn, jenže my jedeme stále na Pythonu 2.7… Za prvé, není potřeba se stydět. Za druhé, je možné psát tzv. stub files už dnes. :-)

AsyncIO

Dalším velkým tématem bylo asyncio. Přeci jen se stále jedná o novinku.

Pokud vám jde opravdu o výkon, nejvýkonnější asynchronní aplikaci napíšete ve Scale. Ale zdroják není tak pěkný. Hned v závěsu se drží Pythoní Tornádo s asyncio. A nejhůře dopadla Node.js aplikace. Podrobnosti v přednášce Better asynchronous with Tornado and Python 3.

Už kdysi jsem si hrál s asyncio v Pythonu 3.3, což je backportnutý balík z 3.4. Tak nějak mne vůbec nenapadlo, že by mohl existovat port i na nižší verzi Pythonu. U trojky mi to přišlo zbytečné a na dvojku nemožné. Ale existuje – balík trollius. Sice nemá příliš podpory ze strany knihoven, ale za zmínku stojí opět podpora Tornáda.

Sice s asyncio vypadá asynchronní kód jako synchronní, i tak potřebuje trochu změn v testech. Na což pro můj oblíbený pytest existuje plugin pytest-asyncio. Není to jediná knihovna využívající asyncio, od vydání Python 3.4 vzniklo spoustu užitečných knihoven na napojení všemožných databází atp.

Testování

Narazil jsem na velmi zajímavý tool na vylepšení pytestu – po změne kódu či testu automaticky spustit jen ty testy, kterých se změna týká. Zní to opravdu skvěle a vypadá ještě lépe. Ale jedná se o beta verzi a u nás v práci jsme to zatím nerozchodili kvůli závislostem. Počin to je i tak obdivuhodný. Balík se jmenuje pytest-testmon.

V programu jsem zahlédl ještě jednu zajímavou předášku o testování pro machine learning. Bohužel zajímavá byla pouze na papíře. Než jsme se prokousali přes úvodní slajdy, co je vlastně machine learning, nezbyl pořádně žádný čas na to, jak je možné takové programy testovat. Jen že numpy má pár vychytaných assertů. Tak i to se hodí vědět, i když žádný velký zázrak.

Balíčkování

Neustálý boj, jak vlastně distribuovat aplikaci. Buď jednoduše jako Git repozitář. Nebo přes Python balíček. Či jako skutečnou aplikaci jako debianí (či jiný OS) balíček. Jenže při debianím balíčku těžko dáme závislost na pypi. Ale opět, jako vždy, vítězí poslední možnost. Do Pythoního balíčku prostě celá aplikace nepatří. Tečka. Nesnažte se to dělat.

Naopak Pythoní balíček pro knihovny a další tooly je jako dělané. A umí spoustu věcí, o kterých pravděpodobně ani netušíte.

Na balíčkování jsem navštívil ještě jednu přednášku o pluggy. To je totiž způsob, jak funguje pytest a pluginy pro něj. Většinou nic takového nikdo nepotřebuje, ale když na to přijde… je už funkční hezké řešení. Teda, pokud nepočítám, že se jedná zatím o alpha verzi a ještě nemá ani dokumentaci. Ale to přijde! Zatím aspoň slidy.

Terminal Whispering

Jedna z mála přednášek, které se mi opravdu, ale opravdu líbily, byla Terminal Whispering. Bylo v ní totiž několik užitečných věcí:

  • Znáte pdb? Používáte? Taky znám a moc nepoužívám. Existuje vylepšenější, visuální, pudb.
  • Terminál podporuje spoustu escape sequences. Pro mne bylo novinkou možnost vstoupit do full-screen módu. Je to vidět u spoustu programů, ale stejně mne nenapadlo, že to je vlastně děsně jednoduché. A s knihovnou blessed o to víc!
  • Mimochodem zajímavá myšlenka je optimalizovat weby pro konzole. Tedy pokud přijdu na web přes telnet, mohu posílat i escape sekvence a ono to bude fungovat. Nic překvapivého ani nového, ba naopak. Ale kdo si to dnes uvědomuje? :-) Schválně zkuste telnet termcast.org.
  • Zadávání hesel se dá vyřešit pomocí shelového příkazu stty -echo. Aby to bylo v Pythonu hezčí, existuje ve standardní knihovně getpass.

Více v celé přednášce.

Transducers

Styl funkcionálního programování se mi líbí a velmi zajímá. Takže jsem se zašel podívat na workshop s transducery.

V jedné věte s big data dnes často uslyšíte napříkad Hadoop. Což jsou map-reduce joby přes několik serverů. Transducer je technika (představená teprve nedávno v Clojure), jak naopak map a reduce spojit do jednoho průchodu. Není to ale hlavní myšlenka. Důležitější je, jak jsou data zpracovávány. Zpracování dat je úplně odděleno od toho, jak se data dostávají dovnitř a ven. Pak kód na zpracování zůstává nezměnný i když data přicházejí třeba asynchronně.

Workshop začal cvičením, že funkce map a filter v Pythonu vlastně nejsou potřeba. Oboje lze zapsat pomocí funkce reduce. Na tom to celé stojí. Zbytek už jsou postupné hrátky až k finálnímu řešení, což je knihovna transducer. I přesto, že výsledek není těžké pochopit, napsat si vlastní řešení není zrovna jednoduché cvičení. Tedy za tři hodiny jsme se dostali sotva do poloviny. Naštěstí mi to stačilo na pochopení konceptu. Vám doporučuju spíš přečíst sérii článků o tomto tématu od stejného člověka.

O funkcionálním programování bylo více témat. Například blázinec zvaný Mochi, představená knihovna pyrsistent a další.


Poznámek mám víc, ale už to jsou jen takové drobnosti. A na spoustě přednášek jsem nebyl. Takže pokud chcete, podívejte se na přednášky sami. Všechny se nahrávaly. :-) A rozhodně stojí za to se podívat i na některé z Montréalu.

Thinking, Fast and Slow

Už si ani nepamatuji, jak jsem se dostal ke knize Thinking, Fast and Slow. Každopádně jsem za přečtení rád a knihu doporučuji. Proč? Přečtěte si mé poznámky… (Psáno převážně pro vlastní potřebu, pro lepší pochopení sáhněte po knize. :-))


Máme dva typy myšlení: rychlé a pomalé (System 1 a System 2). Přičemž to pomalé je velmi drahé na energii. Jelikož mozek dostává „jen“ 20 procent veškeré energie, často tedy pomalé, neboli důkladné, myšlení vynecháváme. Není to lenost, prostě nedokážeme například běžet a násobit dvouciferná čísla zároveň. Pomalé přemýšlení potřebuje koncentraci.

Další zajímavý příklad z knihy, který se mi stává: plně se soustředím na úkol, přičemž mi někdo zadá další úkol. Možná zabrblám odpověď, ale jak se koncentruji na jiný úkol, jakoby okolí neslyším. Tohle většinou lidi nechápou a dopadá to naštvaně či se slovy, že „slyším jen to, co se mi líbí.“

Abychom mohli rychle reagovat, náš mozek funguje jako programátor – těžký úkol změní či rozpadne na lehčí, aby se nemusel aktivovat System 2. Občas to není dobrý způsob. V knize je příklad, kde míček a pálka stojí $1.10. Pálka stojí o dolar více, než míček. Kolik stojí míček? Jako první odpověď bude (velmi často) chybná, obsloužena systémem 1. Naše lenost se může taky vykašlat na věci, které se těžce zpracovávají. Například můžeme odmítnout smlouvu na základě špatně čitelného fontu.

Velmi mě překvapilo, jak si můžeme snadno nalhávat. Kdy System 1 něco vytvoří a System 2 tomu uvěří. Má to pozitivní stránku: stačí se pro sebe usmát a skutečně se cítíme lépe! Mozek jde obelhat ještě jinak a dokonce mohu ovlivnit odpovědi ostatních. Například je těžké odpovědět na otázku „jak se cítíš poslední dny?“, ale je jednoduché odpovědět na „kolikrát jsi byl na rande tento týden?“. A teď se zeptejme v opačném pořadí…

Máme touhu z malých čísel dělat závěry. Je to vidět všude kolem nás. Spousta lidí věří různým statistkám, ale při pohledu na velikost vzorku (a prohnáním této informace systémem 2) jasně vidíme, že z toho nelze dělat žádné závěry. Naopak zapomínáme na důležité statistiky při různých událostech – pokud za poslední měsíc spadnou dvě letadla, spousta lidí se bude bát letět, i když se stále jedná o zdaleka nejbezpečnější dopravní prostředek.

Máme také touhu statistiky narušovat. Například děláme stále ty samé chyby předvídáním řídkých události za předpokladu chatrných důkazů. Start-up může vypadat velice dobře, ale jak si můžeme být jisti, když úspěch je velice vzácný? Pokud nemáme dobré podklady, měli bychom zůstat u obecných statistik.

Představte si drahý produkt. Teď si představte, že za stejnou cenu dostanete stejný produkt s levným dárkem. V jaké situaci je nabídka více atraktivní? Další příklad: Linda je velice inteligentní a asertivní žena. Jaká je šance, že je hlavní obchodnice? A jaká je šance, že je feministická hlavní obchodnice? Většina lidí si myslí, že druhá možnost má větší šanci. Méně je více.

Statistika nezabírá, pokud se nespustí System 2. Například těžko někoho poučíte statistikou; více dosáhnete popsáním jedné konkrétní situace, která je k daným lidem blízká.

Výsledek testu jasně neurčí vzdělanost člověka. Test může dopadnout dobře náhodou; zrovna vyšlo štěstí. Nedávno jsem akorát vyplňoval test gramatiky angličtiny, kde jsem získal 100 % bodů. Několik otázek jsem však otipoval a kdybych dostal test znovu s jinými otázkami, byl bych na tom mnohem hůř. Stejně tak úspěch firmy nezaručí, že použité postupy budou fungovat i jinde. Mohlo jít také pouze o aktuální štěstí.

Do jaké míry lze důvěřovat expertovi? Budu raději věřit hasičovi, než psychiatrovi, protože lze najít podobnost v požárech a poučit se z chyb. Psychiatr nemusí mít jistotu správnosti postupu ani za několik let.

Pokud se díváme na naši práci pouze v rámci firmy, projektu či úkolu, neuvidíme věci, které by mohl vidět někdo nalézající se mimo tyto hranice. Programátorům se běžně stává, že potřebují nakopnout hloupou otázkou. Od toho tu je párové programování. Pro udržení vnějšího pohledu je dobré si nemyslet, že vím víc, než ve skutečnosti vím.

Milionář nebude s bonusem 20 tisíc spokojen tolik, jako člověk vydělávající mnohem méně. Stejně tak nadšení bude menší, pokud stejný bonus dostanu znovu, ale podruhé budu mít větší plat. I když se pokaždé jedná o stejnou částku. Zajímavá je také situace, kdy u dvou stejných kanceláří je jedno, kterou dostanete, ale po přiřazení ji už nikdo nechce měnit.

Člověk přirozeně vybírá volby, které nejsou matematicky optimální. Příkladem budiž kupování lístků do loterie či připlácení za jistotu (raději si připlatíme než spoléhat na last-minute nabídky). Obchodník nás může navíc ovlivňovat tzv. počítáním skóre. Jakmile u nejdražšího automobilu řekne, že má nejbezpečnější sedačky, těžko se budete rozhodovat pro jiné. Skóre je zlo i například u hotovostních vs. bezhotovostních plateb – peníze jsou peníze.

Riskování je studie sama o sobě. Aby lidé riskovali, musí získat víc. Sázka vyhrát jeden tisíc vs. prohrát jeden tisíc není zajímavá, jako výhra sto tisíc vs. prohra jeden tisíc (je vidět podobnost s loterií?). Prohra je sice stále stejná, přesto v druhém případě lidi budou častěji riskovat. Mimochodem při možnosti opakovat sázku se logicky sázka vyplatí, ale člověk vidí spíše každou sázku samostatně a odmítne (možno lépe vidět v tomto videu).

Ti, kteří stojí na straně pravděpodobné prohry, budou bojovat silněji, než ti, kteří stojí na straně pravděpodobné výhry.

Lépe se cítíme při zdůraznění kolik získáme, než kolik ztratíme. Šance 90 % na přežití je lepší, než 10 % pro chybu při operaci. Podobně raději uslyšíme, kolik nám po dovolené zbylo, než kolik jsme utratili.

Při neúspěšném zakončení bereme celek jako neúspěšný. Rozvod ale neznamená, že předchozí roky manželství byly špatné. Člověk obecně často mění nálady – pokud se rozbilo po cestě do práce auto, nebude zrovna ideální čas na zeptání se o spokojenosti v zaměstnání.

Nejjednodušší cesta ke štěstí je kontrolovat čas. Můžete najít více času pro věci, které děláte rádi?

PyCON UK 2014 – poznámky

Měl jsem možnost se podívat na PyCON UK a nelituji. Odnesl jsem si spoustu nových znalostí, tipů, na co se podívat či co aplikovat v praxi. Něco málo předám dál.

Logování

Můžete se snažit jak chcete, ale uživatelé vždycky najdou chyby ve vašich aplikacích. Kvůli tomu je potřeba si zajistit dobré logování a o tom byla jedna z prvních přednášek. Tipy jsou poměrně jasné, ale je dobré si je připomenout, stejně jako tak prozkoumat, zda neexistují nějaké nové pomůcky, které se mohou hodit.

Základ je logovat tak, aby šlo chybu jednoduše znovu vyvolat. Ještě lepší by byl formát, abych to mohl jednoduše hodit do unit testů. Což je sice hezká idea, ale přednášející ji dál nerozváděl a nedovedu si představit jak něco takového zautomatizovat. Ale rozhodně stojí na zamyšlenou. U webovek by šlo třeba generovat aspoň základ Seleniového testu…

Během přednášky zaznělo několik toolů na správu reportovaných chyb. Z nich mě zaujal například Sentry, který zvládne víc, než jen sbírat chyby, ale také umí vyhledávat duplicity. Mám chuť už dlouho udělat u naší aplikace automatické nahrávání bugů do systému, z čehož mě stále odrazují duplicity. Přednáška mi sice nedala odkaz na tool, který by se mi přesně hodil, ale minimálně mne nakopla se k tomuto problému vrátit a konečně vyřešit.

Refaktorování

Další obsahově zajímavá přednáška byla o Rope. Pythoní balík umožňující refaktoring. Občas se hodí udělat přejmenování některé proměnné, která je prolezlá všude možně. To se pak do práce moc nechce. Proto mne seznámení s Rope potěšilo. Škoda jen, že zatím není tolik propojení s editory (pro vim či emacs plugin samozřejmě existuje). Proto vznikl projekt Traad, který je nadstavba nad Rope komunikující v JSON, s čímž dnes komunikuje snad každý. Jsem zvědav, zda to podpoří vytvoření pluginů pro další editory.

Jak jsem však zmínil, jedná se o Pythoní balík s API v Pythonu. Takže to lze pouštět hacker stylem. V následujícím příkladu přejmenovávám třídu nazvanou ClassName v modulu module.py na NewClassName. Hezké na Rope je, že, co jsem zkoušel, zvládne projít codebase a nahradit opravdu všude, kde se používá. Což například mé oblíbené Komodo IDE nezvládne.

project = rope.base.project.Project('.')
module = project.get_file('module.py')
offset = module.read().index('ClassName')
changes = rope.refactor.rename.Rename(project, module, offset).get_changes('NewClassName')
project.do(changes)

Hezké také na Rope je, že při volání project.history.undo() vrátí všechny změny z několika souborů najednou. Více informací na GitHubu projektu.

Prezentace z přednášky.

Testování

Většinou, když se jde v Pythonu testovat, sáhne se po knihovně unittest. Nejsem si jist, zda jsem opravdu neslyšel o knihovně pytest, nebo zda jsem zaslechl, ale vůbec jsem se nepodíval a pustil to z hlavy. Každopádně mne její představení mile překvapilo.

Klasický unittest řeší testování a nějaký ten setUp pro přípravu testovacího prostředí. U větších projektů to nemusí stačit a je potřeba si fixtures pořešit nějak jinak. V práci jsme si udělali docela dobrý jednoduchý systém. Píšu docela, protože stále to není ono. Na pytestu se mi líbí, že právě tyto problémy má vyřešené, resp. obsahuje hezkou práci s fixtures, a to hezky.

Napíšete jednoduše test, do parametru přidáte fixture(s), napíšete tyto fixtury, které označíte dekorátorem, a pustíte. Hotovo. Může to vypadat nějak takto:

@pytest.fixture(scope='module', params=['mysql', 'postgresql'])
def db_conn(request):
    return create_db_conn(request.params)

@pytest.yield_fixture
def db_table(db_conn):
    db_table = db_conn.make_db_table()
    yield db_table
    db_table.drop

def test_one(db_table):
    ...

Na této ukázce je hned několik věcí, které se mi líbí:

  • Každý test má jen takové fixtury, které potřebuje. U unittestu je jeden setUp pro třídu. Pokud tam budete mít jeden test, který patří do této sady, ale nepotřebuje všechny fixtury, vytváří se některé zbytečně (drahocené milisekundy).
  • Fixtury mohou na sebe záviset, stejně jako závisí test na fixturu. Není potřeba si dělat vlastní systém, kdy při použití tabulky musím také vytvářet konexi do databáze.
  • U fixtury mohu říct její platnost. To je v ukázce u db_conn určeno pomocí parametru scope, čímž říkáme, že chceme konexi sdílet pro module nazvaný module. Konkrétní ukázka je obdoba setUpModule, ale nemusím v každém modulu tuto funkci definovat – napíšu jednou bokem a použiji, kde potřebuji, jako závislost.
  • Pro více parametrů se volá test vícekrát. Například v ukázce výše máme jeden test. Zavolá se však dvakrát. Jednou pro databázi MySQL a jednou pro PostgreSQL. Samozřejmě, pokud použiji u jednoho testu více fixtur a každá bude mít různé parametry, vyzkouší se daný test se všemi možnostmi.
  • Vytváření a rušení fixtur je hezky v jedné metodě vedle sebe.

Na jednoduché aplikace to nemusí mít moc velký wow efekt, ale co mi řeklo, že to rozhodně musím vyzkoušet na jakémkoliv dalším projektu, je zobrazení selhání:

    def test_add():
        a = 1
        b = 2
        expected = 4
>       assert add(a, b) + add(b, b) == expected
E       assert (3 + 4) == 4
E        +  where 3 = add(1, 2)
E        +  and   4 = add(2, 2)

test_pytest_examples.py:12: AssertionError

Normálně byste jen viděli, že 7 != 4. pytest však udělá menší analýzu kódu a rozpadne jednotlivé volání v příkazu. Tak můžete rychle najít, kde je problém. Šikovné. Mimochodem nad testem je také vidět, jaké fixtures byly do testu posílány.

Jinak vidíte správně – využívá se klasický assert. Žádné volání různých metod. Zde vidím jednu nevýhodu a to, že tímto způsobem není možné nahradit metodu assertAlmostEqual, musí se ručně psát něco jako assert abs(foo) < 0.0001. Když si ale vzpomenu, kolikrát jsem tuto metodu využil, chybět mi nebude.

Prezentace srovnání unittestu a pytestu. Dokumentace k pytestu.

Práce s daty

V poslední době mne zajímá téma machine learning a tak bylo jasné, že na workshop Practical introduction to machine learning via Kaggle problems musím zajít. Moc ohledně samotného machine learningu jsme se nedozvěděli. Celé nás to spíš provázelo problémem „máme nějaká neúplná data a potřebujeme je nějak transformovat do podoby, abychom mohli předvídat“. I to však přineslo své ovoce – seznámení s knihovnou pandas.

V práci děláme na obchodní aplikaci se spoustou statistik a vždy s těmi daty operujeme docela neohrabaně. Resp. nikdy mi nepřišlo, že ten styl je až tak neohrabaný, dokud jsem se neseznámil s pandou. Tato knihovna umí doslova psí kusy. Přesvědčte se sami:

In [55]: df['one']
Out[55]: 
a     1
b     2
c     3
d   NaN
Name: one, dtype: float64

In [56]: df['three'] = df['one'] * df['two']

In [57]: df['flag'] = df['one'] > 2

In [58]: df
Out[58]: 
   one  two  three   flag
a    1    1      1  False
b    2    2      4  False
c    3    3      9   True
d  NaN    4    NaN  False

Viz dokumentace.

Může se to zdát tak trochu jako ne-Pythonovský přístup, ale líbí se mi. Je dost praktický. Složitá transformace dat lze provést jednoduše, čitelně. Je to další dokumentace, kterou si budu muset projít, abych měl přehled, kdy si budu moct jak zjednodušit práci. Hlavně odstranit zbytečné chyby. Brzy nás čekají velké úpravy statistik, tak se těším na použití. :-)

Dokumentace k pandě.

Requests

Určitě jste už někdy v Pythonu dělali nějaké requesty a určitě jste se trápili s modulem urllib. Případně jste už sáhli po lepším balíku requests, ale použili jste pouze requests.get('url').content. Víte však, co všechno tento balík zvládne a jak je sexy? Pro příště mám jasno, co použiji. Před chvílí jsem si akorát upravil jedno použití a hned to vypadá lépe.

Mrkněte na prezentaci.



Na konferenci zaznělo samozřejmě více zajímavých přednášek. Pokud prahnete po dalších informacích, mrkněte na program a dohledejte si prezentace k tomu, co vás zajímá. Všechny přednášky v místnosti HP room byly nahrávány, takže se časem na internet dostanou i záznamy. Případně můžete mrknout na videa z jiných PyCON konferencí, která jsem postoval nedávno.

Chromecast

Minulý víkend Google u nás zpřístupnil Movies a jelikož jsem si tak nějak už zvykl na Google Music (ideální to není, ale lepší než drátem do oka; minimálně mám dobrý pocit z legálního poslechu), řekl jsem si, že vyzkouším i filmy. Nechtěl jsem však přehrávat filmy ani na telefonu, ani na notebooku. Sice mohu připojit televizi jako externí monitor, ale to není ono. Pořídil jsem si tedy Chromecast.

První zapojení, konfigurace, a… narážím na problém číslo jedna – neumí 5 GHz Wi-Fi. Občas tu je na 2.4 GHz tak rušno, že spojení padá. Po prvním týdnu se však Chromecast drží, to se musí nechat. Každopádně se mi už rozhodně nelíbí, že z notebooku musím být také na 2.4 GHz Wi-Fi, protože rozšíření v Chrome se s tím nepopere. Telefon zvládá v pohodě.

Jdu tedy vyzkoušet nějaké aplikace. Líbí se mi, jak mohu na telefonu či notebooku vyhledávat obsah mnohem pohodlněji a nerušit aktuální promítání. Problém je, že se mi nesmí telefon či notebook odpojit. Google aplikace mají tohle vyřešené – při odpojení Chromecast přehrává dál. „Pouze“ už nemohu obsah například pozastavit či se podívat, kolik ještě zbývá do konce. Horší varianta je (například u Red Bull TV), kdy se po odpojení přehrávání zastaví úplně.

Tedy na přehrávání filmů to není rozhodně vhodné. Aspoň ne dokud nebude Chromecast podporovat taky CEC – posílání příkazů z ovladače přes HDMI. Nevidím důvod, proč by to nemohlo podporovat. Bylo by skvělé, kdybych poté mohl obsah pozastavit, posunout atp. nejen z notebooku či telefonu, ale také přímo z televize. Přeci jen nechci u filmu sedět s otevřeným notebookem…

Jelikož Chromecast na filmy používat nebudu, zkusil jsem najít nějaké využití. Našel jsem jen jedno a to když si chci pustit nějaké delší video na YouTube, například nějakou přednášku. Nebo další lekci z Khan Academy či Coursera. Na to je Chromecast skvělý, protože nemusím koukat na malém displeji a ani za sebou tahat HDMI kabel. Podobně Google Music – mohu si pouštět hudbu na reproduktorech bezdrátově. Problém ale je, že musí být aktivní televize, což je v tomhle případě zbytečné.

Takže celkově, jelikož jsem našel jen jedno vhodné použití, je Chromecast zbytečná další drahá hračka.


Chromecast jsem si pořídil kvůli Google Movies, řeknu něco málo stručně i k této službě:

  • Vadí mi nemožnost si film stáhnout. To znamená být svázán se službami Google. Chápu to u All Access, zde však chci mít možnost si zakoupené tituly stáhnout. Už jen proto, že si budu chtít film třeba přehrát někde na cestách, kde nebudu mít internet (to sice nedělám, ale jde o princip; mohu mít problém s připojením i doma).
  • Chtěl jsem si tedy pustit nějaký film. Zahlédl jsem Fast & Furious a hned jsem dostal chuť na poslední šestý díl z této slavné řady. Dostal jsem však informaci „tento titul není dostupný v mé zemi“. Začal jsem tedy zkoumat, co vše je dostupné a jsem zklamán.
  • Našel jsem si tedy jiný film, už si ho chci koupit, když najednou zjistím, že uvedených 89 Kč je pouze pronajmutí na dva dny v té horší kvalitě. Při zjištění skutečných cen jsem byl docela v šoku. Často mi vyjde levněji návštěva kina i s předraženým popcornem a colou.
  • Jeden film jsem si tedy opravdu pronajmul a podíval se na něj. Nebudu zde už řešit odpojení notebooku a nemožnosti pozastavení filmu. Co mě ale dostalo je, že ani titulky nejsou kvalitní a často byly mimo…

Přijde mi, jak se Google snaží proniknout všude možně, nestíhá vše dotáhnout kvalitně do konce. Někdo by měl Googlu zakázat všechny ty akvizice. Protože jestli to odflákne, opravdu tu jednou budeme mít rozzlobený Skynet. ;-)