Programování bez komentářů

Hodně vídám v kódu komentáře. To by nebylo to nejhorší, jsou situace, kdy jsou komentáře opravdu důležité, ale většinou narážím na situace, kdy je tomu opačně. Takové komentáře mám čím dál více nerad.

Přitom by stačilo málo – než se napíše komentář, stačilo by se zamyslet, zda je opravdu důležitý. Jako nejběžnější zbytečné komentáře jsou totiž takové komentáře, které popisují to, co už popisuje sám kód.

Pokud však kód nemluví sám za sebe (a zdá se, že je komentář nutný), pak je pravděpodobně samotný kód napsán špatně. Stačí se podívat zda nepomůže lepší pojmenování nebo rozdělení funkcionality na menší dílky atp. Prostě refaktorovat.

Ve výsledku by měl být komentář nutný opravdu jen ve výjimečných situacích.

Je mi jasné, že psát bez komentářů není jednoduché, chce to praxi. Jenže bez zkoušení se praxe nezíská. Hezky to popisuje Steve Yegge:

In the old days, seeing too much code at once quite frankly exceeded my complexity threshold, and when I had to work with it I'd typically try to rewrite it or at least comment it heavily. Today, however, I just slog through it without complaining (much). When I have a specific goal in mind and a complicated piece of code to write, I spend my time making it happen rather than telling myself stories about it.

S tím se vlastně pojí čistý kód. Doporučuju si přečíst knížku Clean Code nebo jsem o tom také psal na Zdrojáku v krátkém seriálu, kde se dozvíte jak psát kód, který mluví sám za sebe.

Naivně jsem měl za to, že komentáře budou ubývat a ubývat, ale opak je pravdou. Proto tento blogpost. Zahrajme si hru programujeme bez komentářů!

Mor zvaný jQuery

V poslední době píšu více a více JavaScriptu a čím dál více zjišťuju, že jQuery je zlo, které akorát moří internet. Dříve jsem ho občas použil, když bylo potřeba, abych web trochu rozhýbal (pamatuju si i různé kung-fu s DOMem; jó, to byly časy). Později, to když jsem si začal psát složitější věci, jsem se mu začal vyhýbat. A nyní bych byl raději, kdyby jQuery neexistovalo.

Ano, jQuery je super, když je potřeba na malé prezentační stránce umístit například uživatelsky příjemný formulářík (výběrak datumů atp.). Tím to však začíná a zároveň i končí.

Je nutné si uvědomit, že jQuery je hnusný spaghetti code, poskládaný v jednom namespace, snažící se to napravit bambiliony pluginů řešící jednu a tu samou věc, zabírající nezanedbatelnou velikost pro mobilní připojení a tak dále. Nechci vás od jQuery tímto však odrazovat, praste si klidně dál (někde může být opravdu dobrá volba jQuery použít).

Jen chci, aby se jQuery nepoužívalo jako správná odpověď na internetu na JavaScriptové otázky. Opravdu mě nemálo štve, když si nejsem jist či opravdu nevím, jak něco v JavaScriptu správně řešit, jdu guglit a naleznu odpovědi „use jQuery“ s ukázkou na pár znaků nevysvětlující absolutně nic.

Jeden příklad za všechny:

Sakra, já nechci kvůli prkotině tahat celých dalších 100 kB dat zbytečného kódu, který nepotřebuju! Natož uživatel mé aplikace.

Takže si řekneme hezky nahlas: nikdy nebudu odpovídat na otázku jak něco udělat v JavaScriptu „use jQuery“, pokud o to nebudu požádán!

Mimochodem osobně používám na všechno Closure Library a neměnil bych.

Chyby jsou povinnost

Zjistil jsem, že každý správný programátor by měl dělat chyby. Možná to může vyznít bláznivě, ale mám pro to své důvody, kterých je hned několik:

Asi jako nejdůležitější důvod je ten, abychom si udrželi práci. Představte si situaci, kde po vás zákazník chce nějakou aplikaci, kterou mu dodáte před termínem ve vynikajícím stavu (tzn. kde nejsou žádné chyby a odpovídá představám zákazníka). Myslíte, že vás bude zákazník po předání ještě potřebovat nebo že dostanete speciální odměnu? Ale kdepak… jen když v aplikaci budou chyby a nebude dle očekávání, máte možnost ze zákazníka dostat další prácí za feature, které nebyly v zadání.

S tím úzce souvisí další důvod – musíme si naši práci udržet, poněvadž přeci nic jiného dělat neumíme. Nebo dokážete si představit (pokud jste pravý noční tvor nazývající se developer) jak někde něco děláte rukama? Třeba zametáte chodníky? Přece takový člověk by si o koště přerail obě ruce.

Další neméně důležitý důvod je vzdělání. Přeci chybami se člověk učí. Nikdy se nenaučíte nic tak dobře jako tím, že něco zkusíte a ono vám to dá ránu, která vás naučí, že tohle se dělat nesmí. Třeba strkat vidličku do zásuvky. A čím víc chyb uděláme, tím víc špatných možností vyloučíme. Pak jednoho dne, až toho hodně vyzkoušíme, budeme vědět, která řešení jsou ta správná.

No a takový poslední důvod je abychom si připadali jako lidé a nikoliv jako stroje. Protože chybovat je lidské.

Tak, a teď vážně…

Zdůrazňuji, že potuď to byl žert!

Tento článek je o testování, konkrétně o tom, co vlastně testovat. Postupů pro to je několik a záleží, v jaké situaci právě aplikace je. Začnu od ideálního případu, kdy se teprve aplikace začíná vyvíjet.

SLIME

Zatím jsem neprozkoumal mnoho postupů, jak pokrývat aplikaci testy, ale osobně se mi prozatím nejvíce zamlouvá SLIME (by Adam Goucher), což je zkratka ze security, languages, requirements, measurement a existing. 

Tedy nejprve otestovat bezpečnostní prvky. Například otestovat, že aplikace se ubrání proti různým útokům jako je napříkald XSS, CSRF, SQL injection, Clickjacking, zda se posílají hlavičky zvyšující bezpečnost a spoustu dalšího. Protože pokud aplikace bude mít problém s bezpečností, je většinou už jedno, že jinými chybami netrpí.

Další v pořadí je nutné otestovat, zda si aplikace poradí na všech místech s kódováním. Bylo by velmi nepříjemné narazit na skvělou aplikaci, kterou nemohu používat, protože místo písmenek vidím čtverečky kvůli špatnému kódování.

Dobrou technikou může být otestovat některé vlastnosti knihoven, na které je aplikace velmi závislá a není jisté, že autoři té knihovny nedostanou amok, kdy celé API změní bez předchozího upozornění. Poté může být velmi těžké zjišťovat, co se vlastně změnilo a co se musí upravit. Právě takovéhle testy by s tím měly pomoci.

Dále se hodí měřit výkon aplikace. Je to velmi podobné jako s jazyky – může se jednat o skvělou aplikaci, ale když budu čekat na odezvu příliš dlouho, velmi rychle mě to přestane bavit. Proto je dobré si napsat testy a nechat se upozornit, jakmile se výkon aplikace zhoršuje.

A nakonec testovat samotný kód, který vzniká. Jednotkové testy, integrační testy a tak dále.

80 % ve 20 %

Většinou se však snažíme testovat již existující aplikaci a tam už testovat předchozí body není úplně nutné, protože aplikace si prošla nějakým vývojem, kde se všechny popisované neduhy už (doufejme) opravily a testy by nepřinesly mnoho ovoce. Což ale neznamená, že to není užitečné – pokud se plánuje měnit jádro aplikace, určitě je užitečné si nejprve výše zmíněné testy napsat.

Popojďme ale dál k samotnému kódu aplikace. Určitě nejlepší strategie je začít těmi nejdůležitějšími a nejvíce používanými částmi aplikace. Existuje takové pravidlo 80/20, což znamená že 80 % všech chyb je 20 % kódu. Většinou toho nejvíce užívaného. Takže relativně během chvilky jsme schopni pokrýt spoustu věcí.

Mindmaps

Když už si myslíme, že jsme pokryli to nejdůležitější, chceme pokračovat dál a aplikace je tak rozsáhlá, že není lehké zjistit, co už pokryto je a co není, mohou pomoci mindmap grafy. Jedná se o diagram, ve kterém si postupně vyznačíme všechny funkčnosti aplikace.

Řekněme, že naše aplikace je e-shop. Začneme prvotní tečkou někde uprostřed a z té uděláme větve „uživatel“, „produkty“, „košík“, … Z košíku udvětvíme dál na „přidat do košíku“ a to můžeme zase odvětvit na „dynamické přidání pomocí JS“ a „klasické přidání“ atd. Pak zbývá jen fajfkovat, co už otestováno je a co nikoliv.

Nutno podotknout, že existují i utility, které prozkoumají pokrytí testů. Nemám s nimi ale dobrou zkušenost – čísla nejsou přesná a lze to využít jen pro jednotkové testy.

Dělat chyby

No a když už aplikace obsahuje spoustu testů a jejich psaní nás stále neomrzelo, zbývá poslední trik o kterém je tento článek – dělat chyby.

A dělat je záměrně. Nikoliv však kvůli důvodům ze začátku, ale kvůli otestování testů. Při úspěšném rozbití (jinak skvěle fungující, samozřejmě) aplikace lze jednoduše zjistit, kde mají testy mezery a je potřeba některé upravit či další připsat.

Tato poslední metoda neplatí jen pro případ, kdy už se neví, jaké testy napsat. Dobré je při psaní testu ověřit, že test funguje. Pokud se praktikuje TDD, tak se to vlastně dělá; ale pokud se testy dopisují k existujícímu kódu, je potřeba funkčnost testu ověřit dodatečně. Test, který je neustále zelený, je k ničemu…

Tak dělejme chyby!

WebExpo 2012

Opět jsem šel navštívit WebExpo a opět z něj mám smíšené pocity, které spolu tvoří neutrální stav. Celkově to není ani na kladné, ani na záporné hodnocení. Ale vezmu to trochu podrobněji, začnu obecnými věcmi.

Jídlo: To byl podle mne tak nějak fail. Minulý rok v podobě menzy to bylo mnohem lepší ze dvou hlavních důvodů: množství a „čerstvost“. Jako promiňte, ale když normálně spořádám k obědu celou pizzu, tak se se třemi kousky opravdu nespokojím, natož ještě se studenými. V pátek jsem šel na oběd až po jedné obědě a jakmile jsem zjistil, jak to s obědem je, druhý den jsem šel už po jedenácté. Bohužel to nebylo o nic lepší; vždy pizza studená. Nemluvě u nemožnosti si k obědu sednout…

Rychlost: Přednášky navazovaly ihned na sebe a byl tak problém mezi nimi cestovat, kór když některé přetahovaly. Nedaly se tak stíhat všechny začátky a nebo všechny konce včetně otázek. Tedy téměř ve všech přednáškách na začátku a na konci byl ruch, kdy se návštěvníci postupně odebírali už do jiného sálu. Myslím, že začátek se může klidně posunout o hodinu až dvě dopředu a tento čas rozdělit mezi přednášky jako rezervu.

Internet: Pokud jsem se dostal na Wi-Fi, internet byl v pohodě. Jenže jsem měl pokaždé se na tu Wi-Fi dostat… Přišlo mi to skoro jako kdyby tam bylo málo IP adres a tudíž když bylo plno, měl jsem smůlu. Nebo prostě jen přetížený APčko. Nevím. Snad se zjistí, kde byl problém a do příště se vyřeší.

Pozitivní věci: Ani nevím. Však to lidé z IT znají: když všechny systémy běží v pohodě, nikdo si na ně nevzpomene. :) Jednoduše zbytek konference byl fain. Byla mapka, dobré značení, vše srozumitelné aniž bych musel číst instruktážní mail, prý se překládalo z/do angličtiny, dobíjet šlo a tak. Každým rokem to je lepší a lepší, ale vždy se najde něco, co je potřeba do příště zlepšit.

Tak a teď samotné přednášky…

V pátek jsem hodně přecházel (tím se omlouvám všem, které jsem rušil) a začal jsem v business hall, kde měl přednášku John Vanhara s jeho Shipito. Popravdě mě velmi zklamal. Zajímavé informace řekl v podstatě minulý rok a letos jen řekl, že na Vánoce jim přetékal sklad a museli tak shánět plachty, protože v tomto obodbí nesvítí sluníčko.

První páteční přednáška zaujala až „Social analytika: co nezměříš, nezměníš!“. Zajímavé zjistit jaké jsou problémy s měřením, jak se s tím poprat a potvrdit si, že na Facebooku lze nejlépe vydělávat odhlášením se (aneb nefunguje ani sdílení ani reklama).

Samozřejme David Grudl nezklamal a měl opět jednu z nejvtipnějších přednášek. Ale s vtipem se nejlépe poukáže na problémy; konkrétně dependency injection a „Jean, podejte mi klavír. Mám na něm doutník!“ (= předávejte objektu jen to, co opravdu potřebuje). Sice mi tato přednáška nic nového nepřinesla, ale určitě spoustu jiným lidem přinese.

Zbytek pátečního dne už byl takový nijaký. Nic o čem bych měl potřebu se zmínit. Zato sobota, ta byla nabitá. Poprvé jsem celý jeden den proseděl v jedné místnosti a to development hall.

Sobota začala s přednáškou „Nepoužívejte Git jako SVN!“. Z této přednášky jsem si nic moc nového nepřinesl; nejpřínosnější pro mne bylo potvrzení, že Git umožňuje opravdu hodně a nejlepší je si udělat workflow podle způsobu práce. Jinak jsme se dozvěděli jaké jsou Git-flow, GitHub-flow a Medio-flow a že s pomocí rebase lze historii větvení upravovat, aby byla historie přehledná.

Pak jsem se těšil na Jiřího Knesla s jeho soubojem frameworků. Dozvěděli jsme se, že pokud je to možné, nejlepší najmout Jakuba Vránu (pure PHP) a nebo naberat Nettaře. Ostatní frameworky (Symfony, Rails nebo Tii) dopadly nastejno. Je však potřeba si ale uvědomit, že v čistém PHP je to velmi nepřehledné a nový vývojář s tím bude mít spoustu práce pochopit kód. Taky je potřeba si uvědomit, že se jednalo o práci jednoho dne na čisté louce; po čase by čisté PHP nestíhalo a podle mne teprve pak by se zjistilo, jaký framework je dobrý – nejde jen o rychlý vývoj, ale také o udržovatelnost.

K této přednášce bych se chtěl ještě všem omluvit, protože jsem se měl souboje účastnit také s frameworkem Django. Bohužel mi to nevyšlo a na poslední chvíli jsem souboj musel odříct. Abych to alespoň trochu odčinil, dal jsem si předsevzetí, že se na zadání nepodívám dokud nebudu mít volný den, kdy zadání vypracuju a výsledek odešlu Jirkovi.

Dále následovala změna programu – místo Jana Tichého přišel Hooman Beheshti s přednáškou „Web Performance“. Přednášku jsem neviděl celou, ale byla velmi zajímává. Hooman poukázal na různé výkonostní problémy webovek, jak je zjistit a jak je řešit. Pár klíčových slov za všechna: CDN, komprese (HTTP, HTML, CSS, JS), cache (verzovat statický obsah), viewport (to co je na stránce dole nás zajímá až později) a další.

Development hall pokračoval s přednáškou „Dart nudný a inovativní“. Co jsem si z této přednášky odnesl? Asi to, že je opravdu nudný. A také to, že ještě není vhodné ho nasadit, protože není finální verze; i když aktuální podoba se už moc měnit nebude, minimálně ne ty základní kameny. Kdysi jsem ho zkusil použít a nějak se mi nelíbil (hlavně kvůli nepodpoře v prohlížečích). Tato přednáška mě taky nepřesvědčila k jeho využití…

Pokračovalo se s „Node.js: zápisky z fronty“. Nejvíce mě překvapilo, že výjimka, která probublá úplně nahoru, zabije server! Jinak to byla celkem normální přednáška pro někoho, kdo v Node.js ještě nic nezkoušel.

Zato po „Úvodě do grafové databáze Neo4j“ jsem měl velkou chuť jít sednout si k počítači a vytvořit nějaký projekt, kde bych takovou databázi použil. Zajímavé, jak lze k datům přistupovat podle teorie grafů. Téměř všechny NOSQL databáze nesplňují ACID (atomic, consistency, isolated, durable) a tím dosahují té vynikající rychlosti. Neo4j však ACID splňuje. Další rozdíl od tradičních NOSQL databází je, že schéme od klasické relační databáze nezjednodušuje, ale naopak zesložiťuje. Z toho je vidět, jaké problémy je vhodné s Neo4j řešit – sociální sítě, doporučovací systémy, geoprostorové problémy a další.

Nakonec jsem se těšil na Dana Steigerwalda a jeho „Este.js, evoluční JavaScriptový framework“. Dan o tom hodně psal, ale nějak jsem nechápal, co to vlastně přesně je. Teď už vím: je to rodina několika nástrojů – Google Closure, CoffeeScript, Mocha tests, Stylus, Node.js, Este.js library, MVC mobile ready a další. Ke všemu řekl proč použil zrovna to, co použil, a u všeho měl přesvědčující argumenty. Až na textový editor – podlě mě by mohl někde napsat doporučení, ale nijak ho neprosazovat, protože každý by si měl najít svou oblíbenou interakci se zdrojáky. Jinak skvělá přednáška.

Toť vše. Z Twitteru jsem se dozvěděl, že byly ještě dobré dvě páteční přednášky: „Jak jsme upravovali Sport.cz“ a „Jak bojovat s prokrastinací?“, na které se chystám podívat ze záznamu. A na co bych doporučil se podívat ze záznamu? Tu je seznam:

  • Závislosti, injekce a vůbec (David Grudl)
  • Souboj frameworků (Jiří Knesl)
  • Web Performance (Hooman Beheshti)
  • Úvod do grafové databáze Neo4j (Michal Bachman)
  • Este.js, evoluční JavaScriptový framework (Dan Steigerwald)

Herní tip: Anomaly Warzone Earth HD

V únoru byl Humble Bundle for Android. Jelikož mám styl nakupování ála Humble Bundle rád, i tento bundle jsem si za několik doláčů pořídil. Koupil jsem to však jen abych to podpořil, protože v té době mě už dávno hry na mém Android telefonu omrzely…

V létě jsem si však koupil tablet s Androidem a Tegrou 3 a jako správný milovník IT hračiček jsem samozřejmě musel tablet podrobit různýjm testům včetně zkoušky různých her. Po pár týdnech jsem si vzpoměl, že vlastně mám někde v mailu klíč od her z Humble Bundle for Android a šel jsem instalovat.

Jelikož World of Goo jsem již měl, nadchla mě pouze jedna hra a to Anomaly Warzone Earth HD od 11 bit studio. Jedná se o opačnou verzi hry typu tower defense, což mám rád.

Hra nemá žádný velký příběh – jednoduše naši planetu obsadili emzáci a hráč musí takticky projet a zničit různé objekty na herní ploše, kde číhá spoustu nepřátelských věží, které se snaží hráčův konvoj zlikvidovat.

Na hře se mi líbí, že si mohu naplánovat úplně vše a kdykoliv v průběhu hry měnit. Mohu si naplánovat cestu, jaké jednotky mi budou pomáhat k vítězství, jaké vylepšení jim dám a také v jakém pořadí pojedou. Přičemž pro výhru na všem zálěží a hráč se musí opravdu snažit.

Z videa pravděpodobně není poznat, že hra je zpracovaná do detailů – při bližším pohledu je možnost vidět jak si autoři vyhráli s grafikou nebo se zvukem. Tedy hra je velmi líbivá. Na hratelnost při tom nezapomněli – dali si záležet i na každém levelu.

Hru jsem dohrál sice během několika hodin, ale bylo to velmi zábavné a proto doporučuju vyzkoušet.

Nutno poznameta, že hra lze hrát téměř na čemkoliv; lze ji sehnat v Google Play, v Ubuntu Software Centeru, v App Store, a snad i na PS3 či PC.

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.