Selenium + Python + Debian server

Už mi nestačí hrabat se pouze v jednotkových či integračních testech a tak si nějak dobu hraju se Selenium. S nástrojem, který dokáže z velké části nahradit i „testera klikače“. Před pár dny jsem měl potřebu si Selenium rozběhat na serveru s tím, že absolutně netuším, jestli to lze a jestli to lze udělat nějak snadno. (Mimochodem serverem mám na mysli mašinu někde bůh ví kde bez jakéhokoliv vstupně/výstupního zařízení.)

Pokud nebudu počítat občas trochu zmatené lidi v diskuzích kolem tohoto problému (na otázku jak nainstalovat Firefox na Debian serveru bez Xek jsem našel nespočet odpovědí „ty blázne, to nejde. Proč to vůbec potřebuješ, vždyť to je blbost!“), tak to udělat lze a velmi jednoduše. 

Jako první si musíme uvědomit, cože to vlastně požadujeme. Chceme použít Selenium 2.0 (Webdriver) v Pythonu na otestování webové aplikace, která nám běží na Debian serveru bez X serveru. Začněme tedy postupně řešit.

Nejprve je potřeba Python, nainstalujeme.

# apt-get install python

Super, máme. Dále potřebujeme Selenium pro Python. Selenium lze nejjednodušejí nainstalovat přes PyPI (Python Package Index), na to potřebujeme nainstalovat balík python-pip.

# apt-get install python-pip
# pip install selenium

Máme nutný základ pro jakékoliv testování pomocí Pythonu a Selenia. Dál je potřeba nějak vyřešit problém „žádný X server“. Řešeních je víc, já si však vybral XVFB. Celým jménem virtual framebuffer X server. Česky se jedná o virtuální X server. Tedy možnost spouštět grafické programy bez nutnosti fyzické podpory pro grafický výstup. Jen nic není vidět. :)

Budeme potřebovat nejen balík xvfb, ale také knihovnu pyvirtualdisplay pro Python, abychom mohli ovládat xvfb přímo z našeho testovacího kódu.

# apt-get install xvfb
# pip install pyvirtualdisplay

Nyní nám zbývá předposlední část a to nainstalovat Firefox. Ve standardních Debian repozitářích k nalezení není a tak se musí nejprve přidat další zdroj na linuxmint.

# vim /etc/apt/sources.list
// pridat radek "deb http://packages.linuxmint.com debian import"
# apt-get update
# apt-get install firefox

Tím je připraveno prostředí a můžeme konečně spustit první test funkčnosti.

from selenium import webdriver
from pyvirtualdisplay import Display

display = Display(visible=0, size=(800, 600))
display.start()

browser = webdriver.Firefox()
browser.get('http://www.google.com')
print browser.title
browser.quit()

display.stop()

Pokud vše proběhlo hladce, zbývá si už jen ukázku přepsat do Pythoních unittestů a s radostí začít testovat. :)

class SomeTest(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        cls.display = Display(visible=0, size=(800, 600))
        cls.display.start()
    
    def setUp(self):
        self.browser = webdriver.Firefox()
        self.browser.get('http://www.google.com')
    
    def testGoogleTitle(self):
        self.assertEqual(self.browser.title, 'Google')
    
    def tearDown(self):
        self.browser.quit()
    
    @classmethod
    def tearDownClass(cls):
        cls.display.stop()

if __name__ == '__main__':
    unittest.main(verbosity=2)

Výstup pak už je klasický, který známe:

testGoogleTitle (__main__.SomeTest) ... ok

----------------------------------------------------------------------
Ran 1 test in 4.226s

OK

Dále je dobré si udělat nějaký vlastní wrapper pro TestCase, který se postará o rutiny. (Stále pamatujeme na DRY.) Případně ještě nevytvářet instanci Firefoxu pro každý jednotlivý test, ale pro celou třídu nebo pro všechny testy. Záleží na potřebách a preferencích.

Tento způsob se mi velmi líbí i pro desktop, protože (díky použití Webdriveru) nemusím pouštět žádný Selenium server a ani mi na monitoru nevyskakuje Firefox. Vše hezky v pozadí. A když se něco nedaří a potřebuju vidět, co se děje, stačí pouze dočasně odstranit vytváření virtuálního X serveru.

Proč jsem zvolil Webdriver?

Protože to je součást Selenia 2.0 (největší novinkou druhé verze je právě integrace Webdriveru). Tedy je to směr, kterým se tento nástroj ubírá.

Protože má objektovější API. Sice to v mých velmi jednoduchých ukázkách není dobře vidět, ale náznak tam je. Pak lze kusy kódu lépe zapouzdřit. Například vytvořit celou třídu reprezentující nějaký základní stavební kámen na webu a není třeba jeho funkčnost mít všude možně (změna v HTML se poté nerovná změně ve všech testech, ale jen někde na jednom místě).

Protože Selenium ovládá prohlížeč skrze JavaScript, kdežto Webdriver ovládá přímo prohlížeč. Na Webdriveru se podílejí všichni hlavní tvůrci prohlížečů. Díky tomu také není potřeba spouštět Selenium server.

Devel.cz konference se povedla

Neměl jsem jít, ale na téměř poslední chvíli jsem se rozhodl navštívit konferenci pořádanou Devel.cz. Obával jsem se, že to nebude za to stát, protože už tu bylo IDF, které zrovna nejlepší nebylo a důkazem nechť žádné informace o pokračování. Konference Devel.cz se však podařila. Pravděpodobně úspěch je díky dobrým výběrem řečníků – vybrat především známé, zábavné a dobré řečníky je perfektní volba. Tedy výjimky zde byli

Nejvíce se mi zřejmě líbila přednáška od @steida, který nás zasvětil do vývoje mobilních JS aplikací. A zasvětil nás velice zábavně a kriticky. Nebál se opřít do jQuery (jak jinak), do serverů (protože jsou mrtvé) a tím se tedy pustil i v česky mluvících zemích do Nette, že se „jednoho dne probudíš a Nette bude jen XML konfigurátor“, nebo do Androidu („Android je nový IE6“), Vodafonu, Facebooku („Facebook je špatná ukázka, protože v telefonu je na hovno“) a spoustu dalšího, co jsem už spolehlivě zapomněl. Přitom vtípky na informační kvalitu neměly vliv.

Jako informačně zajímavá mi přišla přednáška od @jakubvrana, který se s námi podělil o zkušenosti z vývoje ve Facebooku. Je velmi zajímavé se dozvědět něco, jak taková firma jako Facebook čelí výkonostním problémům. PHP zrovna dvakrát nefandím, ale technické řešení v podání Facebooku se mi velice líbí. Po přednášce jsem měl chuť se přidat a podílet se na takovém vývoji.

Nesmím samozřejmě opomenout také přednášku od kolegy @janovsky, který přiblížil problém fulltextového hledání a jak ho Seznam.cz řeší. Fulltext jsem ještě nikdy nezkoumal a tudíž pro mne byla přednáška velice přínosná. Bohužel kompletní kuchařka na vlastní fulltext nebyla podána, protože kdyby ano, „tak zítra by vyšly články ŠÍLENEC POSTŘÍLEL 300 LIDÍ V KNIHOVNĚ, protože bych vás tu všechny musel…“ Mimochodem Seznam.cz neustále hledá vývojáře a „bere i lidi vyhořelé, kteří sekají kód jako baťa cvičky“.

Devel.cz by měl mít do dvou týdnů nahrávky na webu, takže až se tak stane, určitě tyto tři přednášky doporučuju zhlédnout. Pokud máte spoustu času, zhlédnutím i těch ostatních nic nezkazíte. Přednášky jsou poučné, zábavné, inspirující.

Rád přijdu příští rok znovu!

Twitter hashtag: #develcz.

PS: Potěšilo mne, že všichni řeší stejné problémy jako my a že jsme se bez nějakých bolestí dostali ke stejnému řešení, jako mají ostatní a které prezentují jako dobré. Tedy někdy máme dokonce o něco lepší (samožřejmě 8)), ale také někdy o něco horší – musí být prostor se někam posouvat, že? :)

ASUS Transformer Pad TF300T

Měl jsem potřebu vyměnit můj starý notebook, který mi přestal vyhovovat, za něco novějšího. Potřeboval jsem něco velmi lehkého, malého a rychlého. Něco takového nejlépe zvládá Apple a tak jsem čekal, s čím se vytáhne na WWDC. Bohužel mě zklamal, protože MacBook Air zdražil a nový MacBook Retina je příliš drahý (nejsem blázen dávat 60 tisíc za notebook). Jelikož jsem ale opravdu potřeboval něco nového a čekal jsem příliš dlouho, ještě ten večer jsem hledal, co koupím jiného.

Nejprve mi na myšlenku přišly netbooky s ChromeOS. Jsou to hezká malá zařízení a zvládnout téměř vše, co potřebuju, protože většina věcí, které na takovém zařízení potřebuju, jsou na internetu. Je ale stále problém s offline režimem (moc se toho dělat nedá) a zřejmě na browser-only ještě nejsem zcela připraven.

Takže jsem hledal dál. Při návštěvě stránek Alzy na mě hned vyskočila reklama na nový Transformer (ASUS EEE Pad Transformer TF300T). Zaujal. Malé lehké zařízení vždy v pohotovosti s výdrží 15 hodin. To je přesně to, co jsem potřeboval!

Jenže Android. Když se mě někdo zeptal na názor k tabletu s Androidem – nedoporučoval jsem, místo toho jsem doporučil omrknout iPad. Ale na druhou stranu se jedná o Transformer, o kterém se mluví dobře, a hlavně o nový Android 4.0, který je určitě lepší, než to bývalo. Zkusil jsem mrknout na videa (hodně videí) a zjistil jsem, že nejenže Android 4.0 vypadá na tabletu dobře, on je konkrétně na tomhle zařízení i svižný! (Tedy použitelný.)

Položil jsem si tedy ještě jednu otázku: zvládne Android mé potřeby? Zamyslel jsem a odpověděl si, že ano. Lze s ním udělat vše, co lze udělat na kdejakém netbooku, až na programování, ale to jsem ani neměl v plánu (nemluvě o tom, že nějaké vyvojářské prostředí (ehm, editor) už existuje).

Takže druhý den k poledni jsem ho držel v ruce…

Zatím jsem tedy řekl, že to je malé, lehké, vždy v pohotovosti, výdrž 15 hodin, svižný a zvládne vše, co kdejaký netbook. Co je z toho pravda v praxi? Vše. Jsem nadmíru spokojen.

Občas se mi zdá trochu těžký, ale to jen když jsem unaven a je zapojen do dokovací stanici s klávesnicí. Jinak to je váhově v pohodě. Mnohem lepší, než jsem měl v plánu.

Díky procesoru od NVIDIA Tegra 3 si nemohu na rychlost absolutně stěžovat. Vše je krásně plynulé a když jsem zkusil nějaké hry na otestování výkonu… no paráda. Co před lety sotva zvládl můj počítač nyní zvládne taková malá destička aniž by se zahřívala.

Poměrně mě překvapil zvuk. Na mobilní zařízení perfekní. Minimálně sledovat filmy na tom lze bez problému. S hudbou se už musí počítat s externími reprobednami, pro které tu je připravený klasický Jack. A kdyby náhodou nestačila malá obrazovečka, je tu i micro HDMI.

Připojit externí monitor jsem zkoušel, bohužel to ještě není ideální. Vše probíhá zrcadlově, ale jakmile jde o nějaké video, na tabletu je vidět černo nebo nevideová část aplikace (například YouTube – komentáře atp.) a video pouze na externím obrazovce. Neříkám, že to je špatně, mohlo by to být však dotažené tak, aby šlo display na tabletu vypnout; stejně jako když přehrávám hudbu.

Jednou za čas používám flash paměť a trochu jsem se obával, jak to budu řešit s tímto tabletem. Nebudu muset zatím své zvyky měnit, poněvadž dokovací stanice je vybavena jedním klasickým USB portem. Popere se to s flash pamětí a třeba i s externí myší. Ale fotoaparát se mi připojit už bohužel nepodařilo; jednalo se však o velmi starý kousek, tak až bude příležitost, musím zkusit něco novějšího, třeba to půjde.

Dále bych se měl zmínit o klávesnici. Ze začátku jsem s ní tak trochu bojoval – jinak rozložená, upravená pro Android a příliš titěrná (jsem zvyklý na velké klávesnice). Po pár dnech jsem se s ní ale sžil a je to v pohodě. Chtělo to hlavně zvyk na tu titernost. (Ústupek za rozměry a váhu.) Dokonce tento článek píšu na ní.

Jinak asi nemám co víc říct. Skvělá náhrada netbooku. Mám buď netbook nebo, po odpojení klávesnice, tablet (ideální pročítání webu v posteli). Bezvadně se na tom kouká na Google Earth či Google Maps, některé hry dostávají nový rozměr, … Já osobně jsem nadmíru spokojen.

Na závěr: samotný tablet bez klávesnice bych doma nechtěl. Se samotným tabletem bych tak spokojen nebyl, protože se na tom nedá napsat více, než pár znaků. Samotný tablet je jen opravdu pro čtení webu nebo hraní her. Až s dokovací stanicí s klávesnicí lze úspěšně konkurovat klasickým netbookům.

Elegantní řešení potřebuje nejprve znalosti

Nedávno jsem zhlédl mini seriál Frozen Planet z dílen BBC a hodně se mi tam líbila jedna scéna. Samozřejmě se mi nelíbila jen tato jedna scéna, ale všechny jako u ostatních mini seriálů zaměřených na přírodu od BBC. Tahle jedna scéna mi ale připomněla jak je dobré mít znalosti.

Jedná se o scénu hned z první epizody, kde se zabijácké velryby snaží ulovit tuleně. Tuleň relaxuje na ledové kře a velryby jsou pod ním ve vodě s myšlenkami si na něm pochutnat. Pro někoho (v pozici velryby) by to mohl být tvrdý oříšek, případně by si dobrovolně ničil své tělo nárazy na kru. Velryby to ale vyřešili poněkud jednoduše a elegantně…

Z toho je vidět, že se vyplatí znát nejen rybníček, ve kterém se pohybujeme, ale také to, co je na břehu, nad ním nebo ještě dál. Třeba matematika, fyzika, bilogie, chemie, historie nebo cokoliv jiného. Číst a učit se ze všech možných oborů však není vůbec snadné. Hlavně časově, ale třeba také finančně (dobrou knihu internet nenahradí).

Z těchto důvodů doporučuju navštívit stránky Khan Academy, kde se vše, co jsem jmenoval, a ještě mnohem víc můžete naučit z krátkých dobře zpracovaných videí. Nemohu říct, zda jsou tak všechna videa, ale ta, která jsem sledoval, jsou vysvětlena velmi dobře nebo minimálně dobře. (Za poslední dva měsíce jsem sledoval jen něco z oboru matematiky, fyziky a historie.)

Úspěšnost této výuky je pravděpodobně tím, že na videu je vidět pouze černé plátno na kterém se postupně barevně objasňuje popisovaná tématika (anglicky) mluveným slovem. „Když někdo počítá příklad a přitom myslí nahlas, myslím, že je to pro lidi cennější a ne tak odstrašující,“ komentuje Salman Khan svůj výukový přístup.

Neznalost neomlouvá a vědět se vyplácí. Takže pokud nemáte problém s angličtinou, pokračujte tímto odkazem: http://www.khanacademy.org (a nezapomeňte si ho přidat do záložek).

Datový typ boolean v MySQL

Už je to dlouho, co jsem se s vámi chtěl podělit o tip, jak vytvořit datový typ boolean v databázi MySQL trochu jinak. Nějak jsem na to úplně zapomněl, takže se s ním dělím dnes.

V MySQL datový typ boolean je, ale není to samostatný datový typ, nýbrž alias pro TINYINT(1). V normálních situacích by to mělo stačit, ale občas nastane prostě specifická situace, kdy to nepostačuje…

Dělám totiž na business aplikaci, kde je velmi často co nějaký formulářový prvek, to atribut v databázi. Každý takový formulářový prvek je nějak omezen a uživatele musíme případně upozornit, pokud takové hranice překročí. Programátor je od přírody tvorem lenivým a proto nic nepíše dvakrát (tzv. DRY) a tudíž ani my jsme nechtěli validace psát vícekrát.

„Vícekrát?“ ptáte se? Ano, vícekrát. Nejenom, že musím někde v kódu specifikovat validační pravidla, ale i databázi musím nějak nastavit. Už jenom tohle je dvakrát a to nepočítám nějaké menší kontroly na straně klienta – v JavaScriptu. Například věk. V databázi musím určit TINYINT a v kódu ošetřit vstup, aby mi minimálně databáze neodpověděla out of range.

Abychom to nemuseli dělat, napsali jsme si takovou fičuru – při nastartování aplikace se přečte celá databáze a pro každý atribut v každé tabulce se sestaví validační pravidlo. Jaký to je datový typ a jaká jsou omezení (maximum/minimum, maximální/minimální délka, možnost nastavit NULL, …). A tyto pravidla se využijí při validaci (která si samozřejmě můžeme v aplikaci ještě zpřísnit).

Tedy když pomocí SQL syntaxe řeknu, že e-mail může být maximálně 256 znaků dlouhý, nemusím toto stejné číslo použít znovu někde v kódu. A kdyby se náhodou toto omezení změnilo, stačí provést úpravu na jednom místě.

Řešení to je hezké a funguje nám to bez problémů dlouho (něco přes rok), ale měli jsme s tím při programování menší problém. Jednalo se o datový typ boolean. V databázi jsme ho měli jako každý jiný vytvořen pomocí TINYINT(1), jenže takto tam máme i atributy, které jsou skutečně celočíselné – nabývající od nuly do devíti.

Člověk je rozliší poměrně jednoduše podle názvu, ale robot generující validační pravidla to má o něco horší. Mohli jsme mu to usnadnit například nějakým speciálním zápisem do poznámky, ale to není úplně to pravé ořechové. Poznámka / komentář je jen poznámka / komentář. Něco takového by nemělo být rozhodujícím pro běh programu. To jsme tedy neudělali.

Udělali jsme to, že TINYINT(1) jsme převedli (kde se jednalo o logickou hodnotu) na BIT(1). Dřív byl BIT také alias pro TINYINT, ale od MySQL 5.0.3 je to samostatný datový typ, takže ho lze rozlišit a dokonce může správně nabývat pouze dvou hodnot.

Výhody to nemá – datově si nijak nepolepšíme (BIT(1) zabírá totéž jako BIT(2) nebo i BIT(8)) a nepolepšíme si ani nijak jinak. Vlastně si ještě ztížíme práci, protože BIT se přenáší jako BINARY, což je v MySQL řetězec. Na to je jednoduchá náprava: stačí hodnotu převádět například pomocí funkce CONVERT.

MySQL dokumentace radí i převádění pomocí přičtení nuly, ale to mi nepřijde zrovna přehledné. Ale je to kratší když pracujete v konzoli. ;)

Jinak žádné další problémy s použitím BITu jsme neměli. Dokonce je teď jasnější, že se jedná o logickou hodnotu, protože TINYINT(1) prostě neříká „hej, čau, já jsem nějaký flag!“ Což potvrzuje to, že máme skutečně atributy TINYINT(1), které nejsou logické.

Pokud tedy někdy přestane vyhovovat TINYINT(1) jako logická hodnota i vám a v MySQL stále nebude (stále není v poslední MySQL 5.6) pravý BOOLEAN, zkuste náhradní řešení s BIT(1).

Pro vysoký výkon se hodí naopak něco jiného: CHAR(0) DEFAULT NULL (v případe InnoDB). Tohle řešení se mi mi zdá velmi ugly, ale co bychom neudělali pro vysoký výkon, že? :) O tom už ale jinde, například v knize High Performance MySQL nebo v článku Efficient Boolean value storage for Innodb Tables.

Seriál Python profesionálně

Měl jsem chuť napsat sem něco o Pythonu. Později jsem zatoužil po víc a chtěl jsem napsat o zajímavostech v Pythonu – jak se v něm věci dělají jinak, jednodušeji, na co si dát pozor, a tak. Postupně jsem si sepisoval, co bych chtěl zmínit, když v tom jsem to celé přeskládal a přidal podstatně více věcí. Nakonec vznikl seriál.

Zkusil jsem to napsat zajímavě. Použil jsem popis nějakého problému s jeho postupným řešením od špatných řešení až po ta dobrá, kde jsem i na tom špatném ukazoval různé věci. Někomu se to líbí hodně, někomu vůbec (to hlavně puristům). Osobně jsem s výsledkem spokojen, i když to není úplně takové, jak jsem si představoval, že bude.

Ať tak či onak, pokud máte za sebou nějakou prvotní příručku Pythonu za sebou (například Dive Into Python 3, která je k nalezení i v češtině) a zatím jste můj krátký seriál o Pythonu nečetli, nezapomeňte to napravit. :)

A kdeže je? Na Zdrojáku pěkně prosím:

  • V prvním díle vás uvedu do seriálu a začnu s jednoduchými věcmi jako ternární operátor, iterace, cyklus a podobně. Ale nepřeskakujte tento díl – téměř s jistotou vše neznáte.
  • Ve druhém díle se posunu dál ke generátorům, lambda funkcím nebo například konext manageru.
  • Ve třetím díle se dozvíte pár vybraných tipů na nějaké moduly či proč si dávat pozor při definování defaultních parametrů ve funkci.
  • Ve čtvrtém díle předvedu několik návrhových vzorů, které jsou v Pythonu napsat jinak a lépe, než znáte z jiných jazyků.
  • A v posledním, pátém, díle se dozvíte, cože to je vlastně metatřída, jak ji napsat a příklady kde se dá šikovně použít.

Prosím, nepište komentáře k seriálu sem, ale k jednotlivým článkům na Zdroják, ať to je na jednom místě. Díky.

PEP8 a můj názor na něj

Dovolil jsem si napsat krátký seriál o Pythonu, kde jsem v prvním díle nedodržel kompletně PEP8. A to byl přesně důvod pro to, aby se rozjela smršť hádek. Některé komentáře byly trochu až drsné. Nesnažil jsem se s nikým hádat a další díly ještě přepsal, aby ukázky vyhovovaly PEP8. Nechci to však nechat být bez vyjádření.

Pokud PEP8 neznáte, možná bude dobré si ho v rychlosti proletět, aby bylo jasné, o čem je řeč. Je k nalezení na adrese http://www.python.org/dev/peps/pep-0008/.

PEP8 dobrý, ale…

Je velmi dobré se držet nějakého stylu, aby byl kód čitelný. A to není pouze jen tak. Na toto téma je velmi zajímavá přednáška Programming Style & Your Brain by Douglas Crockford, na kterou doporučuju se podívat (odpusťte mi, že odkazuju na přednášku, kde se používá JavaScript, když mluvím o Pythonu). Což je také důvod, proč si myslím, že je dobré, že Python něco takového má.

Jenže. Jenže podle mne to je až příliš konkrétní. Opravdu si myslím, že to je až příliš, protože spousta lidí to teď vidí jako něco, co se musí přesně do pontíku dodržovat. A když se to náhodou nedodrží v nějakém bodě, hned rozhořčeně píší do diskuze, jak je to špatné, když se to nedodržuje. Nebojí se pak ani říct, jak je to nečitelné či bijící do očí.

Aby mě náhodou někdo nepochopil špatně – konvece na názvy private či protected metod, pojmenování args a kwds, nemixování mezer a tabů, nepsat mezery navíc uvnitř příkazů, … vítám a vyžaduju. O tom žádná, to se musí. Bez těchto konvecí by v tom byl pěkný bordel.

Mě jde o něco jiného – o drobnosti. Například jak psát názvy nebo maximální šířka řádku.

Jak dodržuju PEP8

PEP8 se mi líbí a vyhovuje mi, takže PEP8 dodržuju až na pár drobností:

  • U názvů metod a proměnných používám camelCase (první písmeno malé), 
  • nebojím se použít (pokud to zlepší čitelnost) i 80. znak na řádce (klidně i pár dalších),
  • a pokračující řádky dělím trochu jinak; místo:
    def long_function_name(
            var_one, var_two, var_three,
            var_four, var_five):
        # ...
    používám (pokud zahrnu i změnu v názvech):
    def longFunctionName(
        varOne, varTwo, varThree,
        varFour, varFive,
    ):
        # ...

A podle mého názoru to není prohřešek. Něco jiného by bylo, kdybych například mixoval tabulátory a mezery nebo před public metodu psal podtřžítko.

Co jsem se dozvěděl z komentářů

Na mé mírné úpravy jsem se dozvěděl velmi zajímavé názory!

Když jsem u názvů metod použil camelCase, dozvěděl jsem se, že z toho „docela bolí oči, že to není JavaScript“. Jestli používá hodně tříd, tak ho docela lituju.

Nebo jiná perlička: „Za camel case normálně sekám ruce. To proto, že rozlišovat identifikátory pouze na základě velikosti písmen je zaručená cesta do záhuby a zdroj zcela zbytečných chyb.“ Při psaní tříd v Pythonu dle PEP8 pozor na ruce!

Dokonce jsem se dozvěděl, že nedodržovat PEP8 je „základní chyba“. No nevím, za použití camelCase mi ještě interpret ruce neutrhl. Dokonce ani nezobrazil žádné varování. (Ani žádný jiný jazyk.) Asi to nebude tak horké, jak se tvrdí…

Myslím, že tohle málo stačí pro to, abych ukázal, jak směšné takové diskuze jsou.

Týmové konvence jsou důležitější

Mnohem důležitější, než dodržování PEP8, je dodržování domluvených konvencí v týmu. Jelikož pracuju v Seznamu, tak někdo nezapomněl do diskuze přispět s odkazem na Python klienta pro API Skliku (prostě nějaký Python kód ze Seznamu), aby ukázal, jak (ne)dodržujeme PEP8 (pro zasmání ostatním diskutujícím) a že vlastně já to nemám tak strašné. Jiný diskutující se toho chytl a smál se. Samozřejmě, jak jinak. Docela bych rád viděl jak oni dodržují PEP8 v jejich zaměstnáních.

U malých a hlavně neprofesionálních firem se to nedělá, u těch ostatních je však bežné, že se na začátku (ať už projektu nebo firmy) stanoví nějaký coding style a ten se dodržuje, aby byl kód jednotný. A je úplně jaký bude; důležité je, aby s ním souhlasili všichni zúčastnění.

Například (což je i důvod zmíněného posměchu) v Seznamu na konci tříd, metod, cyklů, … používáme komentáře #endclass, #enddef, #endfor, … Já osobně tyto komentáře (u svých věcí) nepoužívám a k čitelnosti mi to nepomáhá (ale ani neubírá). Tento coding style se tu však zavedl a používá se. Jsou tu i vývojáři, kterým to přijde přínosem. Takže v práci tyto komentáře píšu a nemám s tím žádný velký problém.

V komentářích jsem našel také toto: „(…) respektuji konvence jazyka/prostředí, ve kterém dělám. Opačný přístup znamená, že jsem tam vetřelcem.“ Já na to říkám: Dodržováním konvencí jazyka mohu být vetřelcem pro tým, který má zavedený jiný coding style.

Sečteno podtrženo

Jděte se bodnout s tím z čeho vás bolí oči a za co sekáte ruce.

Jelikož to ale stejně neuděláte, budu příště na servrech, jako je Zdroják, dodržovat PEP8, ať máme všichni klid. Ve svých projektech budu ale nadále dodržovat svůj coding style a v práci budu nadále psát #endarticle.

Tipy jak se zlepšit v angličtině

Minulý měsíc jsem byl v zahraničí naučit se mluvit dobře anglicky. Sice stále neumím anglicky plynule, jak by se mi líbilo, ale stejně jsem za krátkou dobu udělal výborný kus práce. A stačilo mi pár jednoduchých triků o které se chci s vámi podělit. (Pokud se chcete naučit jiný jazyk, místo angličtiny dosaďte jakýkoliv jiný jazyk. Téměř vždy to bude platit.)

Dříve jsem byl v angličtině špatný, protože jsem si myslel, že jsem špatný. Jeden měsíc v zahraničí toho moc nového nenaučí. Opravdu ne. Mě to ale dalo hodně. Zjistil jsem totiž, že jsem se předtím pouze bál angličtinu použít, protože jsem se bál, že udělám nějakou blbou chybu a někdo se mi bude za to smát.

Když jste však v zahraničí a kolem sebe máte pouze anglicky mluvicí lidé a potřebujete se nějak domluvit, prostě něco řeknete. A buď už vám budou rozumět a pomůžou a nebo se jednoduše na vás udiveně podívají a tím máte příležitost svůj problém říct znovu nebo trochu jinak. A tím udiveným pohledem se vám neposmívají ani vám nechtějí utrhnout hlavu.

Takže tip číslo jedna, jak se učit angličtinu: nebát se angličtinu použít.

Kdyby se náhodou ale někdo smál, tak se s ním jednoduše nebavte. Je to blbec.

Ve škole moc čechů nebylo, takže češtinu jsem zaslechl málokdy. Zato francouzky mluvících tam byli tři pr...desítky. Podobně na tom byli japonci. Bylo hezky vidět, jak se většinou tito studenti spolu nejvíce kamarádí a po škole si povídají svým jazykem. Tohle je velmi častá a velká chyba.

Na jazykový kurz do zahraničí jedu přece proto, abych byl donucen daný jazyk používat a naučil se ho co nejvíce. Přijet, vyhledat kdo umí jazyk, který taky umím, jsou podle mne vyhozené peníze. To si mohu rovnou najít levnější jazykovku doma, nemusím nikam jezdit a po škole můžu normálně mluvit mým rodným jazykem.

Tím tedy máme tip číslo dvě: vyhýbat se lidem, kteří umí můj jazyk. Nebo se donutit používat pouze angličtinu, což nemusí být jednoduché.

Řekl bych, že normálně nemluvíme nějak moc často. Alespoň já. Resp. mám na mysli nějaké složité rozhovy. Ne takové ty srandičky typu „Hi, how are you?“ - „I'm good, thanks. What are you doing tonight?“ - „Probably I'll drink in my favourite bar.“, ... Jinými slovy běžně není moc možností, jak se naučit angličtinu na dobré úrovni. Pokud neumíte angličtinu vůbec, jednoduché věty vás naučí díky četnosti základy velmi rychle. Ale když už angličtinu umíte, nijak výrazně vás to neposune kupředu.

Zkusil jsem takový trik, který mi v tomhle pomohl. Každý má myšlenky a každý má své myšlenky v jeho rodném jazyce. Já zkusil po celou dobu jazykového kurzu angličtiny mít i myšlenky v angličtině. Je to namáhavé a limitující, protože samozřejmě chceme přemýšlet komplexně. Ale zkuste to a nevzdávejte to.

Navíc si představte situaci, že jste například v nějakém obchodě, něco si prohlížíte a přemýšlíte nad důvody, proč si to koupit a nekoupit a zda tady někde nemají tohle, ale s jinými parametry (například tahle košile je super, ale mohla by mít jinou barvu, velikost a střih). Najednou za vámi přijde obchodník a zeptá se, zda potřebujete pomoct. Pokud přemýšlíte v češtině, musíte své myšlenky přeložit. Pokud v angličtině, jednoduše zopakujete, co jste si před chvíli řekli pro sebe.

Další třetí tip tedy je: snažit se přemýšlet v angličtině.

Když už umíte angličtinu trochu lépe, dalším krokem jsou média. Nejprve můžete zkusit se zaposlouchat do textů vaší oblíbené písničky a zkusti dekódovat o čem to vlastně zpívají. Pokud tedy obsah už neznáte. Dále pokračovat s filmy. Nejprve s titulky a potom i bez nich. Z toho co jsem viděl naposledy můžu doporučit Hunger Games – je to nový, dobrý a rozuměl jsem všemu (= není to složitá angličtina; zkuste bez titulků).

Nakonec nějaké třešničky. Jako první třešnička je četba v angličtině a druhá je nastavit si technicku do angličtiny (počítač, mobil, tablet, televizi, webové účty, cokoliv). Popravdě tu druhou třešničku bych doporučil jako první krok při výuce jakéhokoliv nového jazyka, ale to je pro silnější osoby.

A to je celé. Tohle málo mi pomohlo se během krátké doby posunout v angličtině z úrovně B1 na úroveň B2 (osobně mám pocit, že to bylo z úrovně A2 na skoro úroveň B2). Abyste byli taky úspěšní, stačí se snažit a nevzdávat se (což platí všude, nejen při studiu angličtiny). Shrňme si to: nebát se angličtinu používat, při kurzu se vyhýbat čechům, snažit se přemýšlet v angličtině a konzumovat obsah v angličtině.

Hodně štěstí!

Sublime Text: Téměř ideální IDE

Už je to nějaký pátek, co jsem narazil na IDE Sublime Text. Moc mě ale nenadchnul a tak jsem si dál používal Komodo IDE, protože jsem byl štastný držitel licence. A taky protože přeučovat se něčemu novému stojí čas a tím i peníze.

Firma ActiveState naštěstí nespí a díky tomu už (bohužel) nemohu svou licenci použít pro nejnovější editor Komodo IDE 7, které přináší spoustu vychytávek. Takže nadešel čas se na Sublime Text podívat blíže a rozhodnout se, komu přispěju svou troškou na další vývoj špičkového editoru.

Hned zprvu musím říct, že jsem ho testoval jen doma na menší práci, protože se nemohu v práci zdržovat kvůli nesžití mých prstů s editorem. Tím jsem nemusel narazit na všechny vychytávky a mouchy. Ale teď už se pustím do popisu, co mě nadchlo a co nikoliv.

V tolika souborech, aby se pra…

Určitě to znáte. Je potřeba něco vyvíjet a jelikož jste „Clean Coder“, tak máte vše rozdělené do menších souborů. Bohužel se občas stane, že se některé soubory (v různých adresářích) jmenují úplně stejně. Ve svém oblíbeném editoru si otevřete několik souborů, z toho budou tři stejného názvu. Ze začátku víte, který je který (vždyť jste je teď otevřeli a seřadili), ale za chvíli už nevíte. A hledáte a hledáte.

Hodně srandovní je pozorovat kolegu, který má jEdit. Tam se taby rozmísťují do řádků a všelijak to samo přeskakuje.

Přesně tohle se vám se Sublime Text nestane. Po otevření souboru sice zůstane v záložce pouze jméno souboru, ale po otevření jiného souboru se stejným názvem, se u obou záložek zobrazí navíc cesta k souborům, aby se daly od sebe rozeznat.

Horší to je při otevření velmi velkého množství souborů. Sublime Text taby zmenšuje a tím se tam vejde méně a méně textu. Naštěstí nemívám otevřené velké množství souborů, aby by mi to vadilo, ale někomu to vyhovovat nemusí.

Jak se ta metoda jenom jmenuje

Jednou za čas se mi stane, že otevřu soubor a teď si nemohu vybavit, co to vlastně hledám. Tak prostě scrolluju. Až narazím na to, co hledám.

Něco takového se se Sublime Text dělá velmi hezky. A efektně. Po pravé straně je (defaultně, lze vypnout) zobrazen panel s náhledem celého zmenšeného souboru. To jsem ještě nikde jinde neviděl! Výborná věc. Sice to nepoužiju tak často, ale pro fotografickou paměť to je eňo ňuňo.

Jen dva prstíčky tam strčíme…

Poměrně častá situace (u mne) je, že potřebuju jen do některého souboru nahlédnout na nějakou informaci a pak ho zavřít. Případně ještě něco zkopírovat, třeba název objektu, metody, …

V jiných editorech musím soubor opravdu otevřít a pak opravdu zavřít. Se Sublime Text nikoliv. A nevymýšlím si! Po (jednom) kliknutí na soubor (v editoru) se ihned zobrazí. Ale není otevřen v tabu. Pokud překliknu jinam, tak není v žádném seznamu otevřených souborů a musím ho případně znovu najít ve stromové struktuře. V tomto stavu mohu v souboru klidně cokoliv označit a zkopírovat a stále nebude otevřen. Funkčnost je dotažena tak daleko, že jakmile začnu editovat, tak se mi soubor už opravdu otevře. Úžasné.

I don't care

Když jsem poprvé viděl funkci, která skrývá kusy kódu, které mě zrovna nezajímají, byl jsem nadšen. Dnes už to tolik nevyužám, protože Komodo IDE nabízí dělat si záložky a v rámci jednoho souboru jednou klávesou přes ně skákat. Navíc editory s tím docela otravují – je to designově ošklivé a někdy kód skrývají blbě, že to spíš obtěžuje (například skryjí i následující mezery po metodě). Takže to vypínám.

Sublime Text na to jde dobře a hezky. Šipky pro code folding zobrazuje jen tehdy, když najedu myší nad sloupec s čísly řádků. A kód skrývá tak, jak se má. I když teď bych raději ty záložky. :)

Když jsem u toho zobrazení jen když potřebuju – podobně funguje zobrazování bílých znaků. Většina editorů umožňuje zobrazovat mezery a tabulátory jako nějaké puntíky a šipky. Je to super věc, ale nikdy jsem to neměl zapnuté natrvalo, protože to je s tím velmi nepřehledné.

Sublime Text zobrazí mezery a tabulátory normálně (jako prázné místo). Ale po označení textu se tyto bílé znaky zamění na zmíněné puntíky a čáry. Inteligentní.

Příjemné na pohled

Každý správný editor musí mít podporu schémat. A každý takový editor musí mít minimálně jedno tmavé schéma. Jinak to nikdy nemůže být můj editor. Koukat několik hodin denně do monitoru nelze se světlým pozadím. Prostě bez tmavé ani ránu.

Původně jsem si oblíbil schéma Oblivion v Geditu. Toto jsem se snažil dostat i do Geany. A povedlo se. Potom jsem si oblíbil v Komodu schema Dark, které se mi líbí nejvíce do dnes. Ale až Sublime Text je editor, který má tmavé schema nasteveno defaultně; potěšilo. Dokonce i poměrně hezké. Ale žádný strach – Sublime jich má spoustu na výběr, i netmavých!

Z nuly na sto km/h pod sekundu

Sublime Text je rychlý. A to hodně!

Ještě jsem nikde jinde neviděl takovou rychlost. Možná tak u obyčejného Geditu či Notepadu. Jenže ty neumějí to, co Sublime Text. Ostatní editory se s ním v rychlosti nemohou vůbec srovnávat. Například raději jeden řádek upravím ve vim-u, než abych zapínal Komodo (které startuje třeba 20 sekund). Sublime Text naběhne téměř okamžitě.

Rychlost není pouze při zapínání editoru, ale všude. Například rychlé otevírání souborů, vyhledávání, nahrazování, … A nejlépe s klávesovými zkratkami CTRL+P/R/G. Vyzkoušejte si. ;)

Správný programátor zvládne multitasking

Taková třešnička: pomocí CTRL + klik lze vkládat více kurzorů. Tím lze editovat několik řádků najednou. Taková blbina, ale hezká. Někdy se to může hodit více, než hromadné nahrazování. A hlavně, kdo může v jiném editoru psát více kódu najednou?! :)

Ale…

i tak to nebude můj hlavní editor. Ani doma, ani v práci. Proč? Inu, protože má i své nevýhody. První, taková drobnost, je správa projektů. Vygeneruje to víc, než jen jeden soubor (dva), a to je moc. Nemám rád, když to zaplní pracovní adresář „kravinama“, které nezačínají tečkou. Akorát se to motá pod nohama. Ani pak nevím, který soubor mám otevřít. A každý projekt se mi otevírá v novém okně.

Dál mi vadí, že si do postranního panelu se seznamem souborů musím adresář ručně přidat. Nemohu listovat z home či z root adresáře, jako v Komodu či Geditu a kdekoliv jinde. To mě docela zklamalo.

Při vyhledávání metod (pomocí zkratky CTRL+G) se sice rychle filtrují výsledky, ale pokud mám v souboru dvě třídy a oba mají metodu se stejným názvem, tak nerozeznám která je která. Komodo IDE to má vyřešené lépe – vypís zobrazí jako stromovou strukturu a nadřazený objekt neskryje.

(Ne)verzujeme

Zatím to byly drobnosti, které by šly překousnout, ale co mi opravdu vadí a přes co nejede vlak, je podpora verzovacích systémů. V Komodo IDE jsem si zvykl na rychlé zjištění stavu souboru, na rychlý náhled diff-u, na rychlý pohled do historie souboru.

Zde nic takového není. Našel jsem pouze nějaké rozšíření, které umí zjistit stav souboru a zobrazí nějakou konzoli, kterou mohu zavřít tak, že kliknu v menu na otevřít konzoli (páč klávesová zkratka nefunguje) a poté kliknu na zavřít konzoli. Jinak se toho nezbavím. A neumí to commitovat, neumí to zobrazit historii, diff. Nezobrazí stav souboru ikonkou v tabu ani v postranním panelu se seznamem souborů. A to je velká škoda!

Možná, pokud to někdo nestihne udělat přede mnou, bych si zkusil napsat vlastní extension pro Sublime Text pro podporu verzovacích systému. Se stejnou funkčností jako je má Komodo. Pak to bude super.

Takže

Suma sumárum to je velmi povedené vývojové prostředí. Vidím velkou šanci, že opustím mé oblíbené Komodo IDE a přejdu na Sublime Text. Vychytávek je opravdu spousta a určitě ho všem doporučuju minimálně zkusit. Ale já s jeho nasazením ještě posečkám.

Pokud podpora verzování je důležitá i pro vás, pak upozorním, že do 15. března je Komodo IDE 7 ve slevě. Jak nová licence, tak upgrade ze šestky.

Komunikace je důležitá

Nedávno jsme měli v práci opravdu kritickou situaci. Nasazovali jsme nový release aplikace a při tom se vloudila chybička. Ta nic ošklivého sice neprovedla, ale naneštěstí za ní následovala další, která kvůli té první už ano. Zničehonic jsme se dostali do pěkné ošklivé situace, ze které se nešlo dostat zpět. Aspoň ne jednoduše a bez újmy. I přesto, že jsme se pečlivě připravovali a promýšleli různé scénáře…

Co se dalo dělat. Muselo se to prostě dokončit a dostat do co nejlepšího stavu. Zůstali jsme tedy v práci o „něco“ déle a snažili se to dát do pořádku. Byla to rušná noc a po pár hodinách spánku i krušné ráno. Vlastně ještě několik dalších dní. Nic příjemného.

Proč to ale píšu – po každé takové situaci se snažím ohlédnout zpět a najít chyby, kterých jsem se dopustil. Po takové situaci jsou totiž vidět nejlépe mezery, které je potřeba eliminovat. A těmto chybám se příště, pokud možno, vyhnout velkým obloukem.

Ohlédl jsem se i nyní a našel u sebe nedostatek v komunikaci. Ne, že bych měl problém mluvit nebo tak podobně, ale spíš problém se přesně vyjádřit. Aby když popíšu hrníček na kávu, tak aby si spolukonzultant představil přesně ten samý hrníček jako já.

Hodně dobře problém dvojznačnosti popisuje ukázka z knížky The Cleaner Coder: A Code of Conduct for Professional Programmers od Robet C. Martin:

Sam (stakeholder): “OK, now these log files need to be backed up.”
Paula: “OK, how often?”
Sam: “Daily.”
Paula: “Right. And where do you want it saved?”
Sam: “What do you mean?”
Paula: “Do you want me to save it a particular sub-directory?”
Sam: “Yes, that'd be good.”
Paula: “What shall we call it?”
Sam: “How about 'backup'?”
Paula: “Sure, that'd be fine. So we'll write the log file into the backup directory every day. What time?”
Sam: “Every day.”
Paula: “No, I mean what time of day do you want it written?”
Sam: “Any time.”
Paula: “Noon?”
Sam: “No, not during trading hours. Midnight would be better.”
Paula: “OK, midnight then.”
Sam: “Great, thanks!”
Paula: “Always a pleasure.”

Later, Paula is telling her teammate Peter about the task.

Paula: “OK, we need to copy the log file into a sub-directory named backup every night at midnight.”
Peter: “OK, what file name should we use?”
Paula: “log.bakckup ought to do it.”
Peter: “You got it.”

In a different office, Sam is on the phone with his customer.

Sam: “Yes, yes, the log files will be saved.”
Carl: “OK, it's vital that we never lose any logs. We need to go back through all those log files, even months or years later, whenever there's an outage, event, or dispute.”
Sam: “Don't worry, I just spoke to Paula. She'll be saving the logs into a directory named backup every night at midnight.”
Carl: “OK, that sounds good.”

Ukázku zvěřejňuju s laskavým svolením autora 

Jak je z ukázky dobře vidět, oba se domluvili, oba byli spokojení, ale každý si to představil jinak. Sam, stejně jako zákazník Carl, měl na mysli zálohu každého dne, ale Paula to pochopila jako zálohu jen za poslední den. Bylo by velmi nešťastné, kdyby na to přišli až v produkčním nasazení.

Proto je potřeba se takových situací vyvarovat. Asi nejlépe to jde s akceptačními testy, jak posléze popisuje ve zmíněné knize Robert C. Martin. O těch se ale nebudu rozepisovat – přečtěte si knížku, anebo si akceptační testy vyguglete. Chci ukázat, jak může jednotlivec pomoct v obraně proti nejednoznačnosti (bez nutné aktivní účasti dalších lidí).

Poměrně jednoduše to lze pomocí odlehčených akceptačních testů. Například zrovna dnes jsem něco takového udělal: potřeboval jsem si ověřit, že vývoj nové funkcionality souhlasí se zadáním. Jednoduše jsem si proto přivolal zadavatele a poprosil, zda se může podívat na polotovar. Zda je to takhle OK. Ještě, že jsem to udělal! Nebyla tam nějaká drobná nejasnost, ale poměrně zásadní. Upravovat to později by mě stálo zbytečně dost času navíc. A hlavně firmu zbytečně více peněz.

Stále se ale může stát, že k nejednoznačnosti dojde a dělá se zbytečná práce. Proto je dobré být neustále na pozoru – hledat možné nesrovnalosti a případně si je ihned vyjasnit. Jako dobrá pomůcka si mi osvědčilo si po přečtení nebo vyslechnutí požadavku celý problém znovu projít, popsat ho svými(!) slovy, sdělit je zpět zadavateli a nechat si potvrdit, že vše souhlasí. Případně si o tom ještě promluvit.

Podle zkušeností mohu říct, že tyhle dvě pravidla pomohou snížit „ambiguity“ na minimum. Bohužel to je jen pro přijímání zpráv. Opačně se musí (pro jistotu) předpokládat, že si druhá strana nejednoznačnosti nevšimne, a podle toho se vhodně vyjadřovat. A to je přesně to, co mi zatím moc nejde a na čem musím zapracovat. Snad nebude dlouho trvat a budu psát pokračování k tomuto článku s ověřenými tipy, jak na to. :)