Tak nám zrušili Posterous

Co se dá dělat, musím o dům dál. Na jednu stranu mě to štve, protože se nechci starat o nějaké převody dat. Na stranu druhou naopak převedu svoje texty konečně (snad) na něco použitelnějšího. Totiž, nevím zda to bylo pouze u mne, ale Posterous se mi načítal neúnosně dlouho a ve webovém rozhraní se mi nepracovalo zrovna nejlépe.

Hledal jsem tedy službu, kam se přesunu. Podíval jsem se na ty profláklé – Blogger a Wordpress. Říkal jsem si, že Blogger by to mohl vyhrát. Přeci jen to je Google, od kterého používám spokojeně spoustu služeb. Ale nevyhrál. A ani Wordpress. Služby se mi nelíbí, nemluvě o složitosti převodu.

Není tedy asi divu, že jsem si založil účet na Posthaven. Líbí se mi to mnohem více, než Posterous. Vychází to z něj. Slibuje věčnost. Import Posterousu je na jedno kliknutí úplně se vším. Paráda. Doporučuju zkusit, pokud jste na Posterous a ještě nemáte převod zařízen. Ale rychle, zbývají už jen dva dny.

A jelikož jsem tvorem líným a nemám nakonfigurovanou vlastní URL, musíte si sami upravit adresu ve své záložce a RSS čtečce na http://horejsek.posthaven.com. :)

Windows 8 ani omylem

Vědět dřív to co vím teď, všechny známé bych varoval před upgradem na Windows 8. Přínáší to totiž poměrně závažný problém – kompatibilita.

Celé to vzniklo tak, že děda dostal k licenci sedmiček slevu na Windows 8. A ne zrovna malou, aneb nekupte nový operační systém od Microsoftu za čtyři stovky. Tak se taky stalo a krásně fungující sedmičky nahrazovaly kostičky.

Ještě než budu pokračovat, menší problém jsou i samotné kostičky. Nad tímto krokem jsem se pozastavoval už u prvních informací o Windows 8. Proč je sakra metro na desktopu? Vždyť to je nepoužitelné… To jsem však ještě nezkoušel a tak jsem si říkal, že třeba to je jen o zvyku. Gnome 3 je také jiné a musím říct, že to je lepší než klasické prostředí.

Ne, není to o zvyku. Je to postavené na hlavu. Kdo si v Microsoftu sakra myslí, že je dobré vypínat počítač najetím do jednoho rohu, poté se držet u strany (protože jakmile se vzdálíte, meníčko zmízí), najet až na nastavení (protože to je přece logické, že v nastavení je vypnutí počítače) a tam kliknout na vypnout? A pak ještě jednou. A pak čekat až se nainstaluje bambilion aktualizací; to už je však známý příběh.

Celé metro není na desktopu vhodné. Posouvat se do strany, plýtvat místem, přepínat se mezi dvěma rozhraními, atd. To není to pravé ořechové. Takže v tom legu se využívá pouze jedna věc – proklik na klasický desktop. Nejeden člověk se mě ptal, jak tuhle otravnou obrazovku odebrat. Netuším. Hrál jsem si s tím přes hodinu bez výsledku. [Pokud to lze, dejte mi prosím vědět a já to hned pošlu všem, kteří to po mně chtěli.]

No ale zpět k tomu hlavnímu problému. Fungující sedmičky teda nahradilo metro, které oznámilo, že trasa kompatibilita končí ve stanici běžný hardware a dál nejede. A nejede tam ani další spoj. Ani ten další. Žádný.

Popravdě moc typů hardwaru jsem nezkoušel; co vím, tak klasické klávesnice, myši, reproduktory, mikrofon, externí a flash disky pracují v pohodě. Prostě ta klasika, do které nepatří tiskárny. Zřejmě tisk je luxus pro firmy, které se do upgradu nepohrnou, a tak nevadí, že z Windows 8 lze tisknout jen na dobré slovo. Jen když se tomu zrovna chce.

Tiskáren jsme zkoušeli víc. Ani jedna se nechytala. Windows sám žádné základní ovladače nenabídl (no tak kde to žijeme?) a výrobce na nějakou podporu z vysoka kašle. Jelikož byla stejně potřeba nová tiskárna, začalo se pátrat po tiskárně s podporou nových Windows. Tohle by však nedal ani Holmes! Takovou tiskárnu jsem ještě neviděl.

Zkusili jsme si prostě vybrat nějakou tiskárnu a podívat se na stránky výrobce, zda náhodou už ovladače nejsou dostupné a jen se zapomnělo na úpravu specifikace. Naštěstí jsme takovou našli a koupili. S radostí jsme ji zapojili a šli instalovat ovladač. Ale ejhle, pokaždé to spadlo s chybou.

Sice to pak psalo, že tiskárna je nainstalovaná, ale tisk stejně nešel. Opravdu už netuším, co jsem s tím dělal, každopádně po třetím restartu se rozjela. Možná pomohla nějaká aktualizace, která mě otravovala při jednom restartu. A která se nepovedla nainstalovat.

Nyní tiskárna tak nějak tiskne, ale nemám vůbec jistotu, že to není na dobré slovo, jako ta předtím. Uvidíme.

Celý Windows 8 na mne působí jako Windows Vista. Nedodělek, které raději nepoužívat. Windows 7 je vlastně doladěná Vista. S Windows 9 to vidím podobně a proto doporučuju počkat a vykašlat se na jakékoliv slevy. Nervy jsou cennější.


Moc se mi líbí, když v Linuxu (to je ten hrozný operační systém zadarmo) připojím tiskárnu a po chvilce se mi ukáže, že mohu tisknout. A pokud potřebuju lepší ovladač, zajdu na stránky výrobce a tam je jen jedna položka s Linuxem, takže se nespletu, který mám stáhnout (aneb bambilion verzí Windows a Mac OS).

Stále mi nejde na rozum, jak něco zadarmo může fungovat mnohem lépe než něco placeného.

Konzolové Easter Eggs

Po těch letech, kdy jsem vyhledával v konzolovém manuálu man, jsem našel několik easter eggů. Při posledním nálezu v nápovědě utility ack-grep jsem na chvíli zapomněl, cože jsem to vlastně hledal a s kolegou dali dohromady seznam, co vlastně všechno už za shellové easter eggs známe.

apt-get help vypisuje větičku „This APT has Super Cow Powers“. A má pravdu:

$ apt-get moo
         (__) 
         (oo) 
   /------\/ 
  / |    ||   
 *  /\---/\ 
    ~~   ~~   
...."Have you mooed today?"...

Samo to nabádá vyzkoušet i ten druhý oblíbený balíčkovací manažer, aptitude. V nápovědě (aptitude help) sice říká přesný opak, „This aptitude does not have Super Cow Powers.“, ale ve skutečnosti easter egg má. A propracovanější:

$ aptitude moo
There are no Easter Eggs in this program.
$ aptitude moo -v
There really are no Easter Eggs in this program.
$ aptitude moo -vv
Didn't I already tell you that there are no Easter Eggs in this program?
$ aptitude moo -vvv
Stop it!
$ aptitude moo -vvvv
Okay, okay, if I give you an Easter Egg, will you go away?
$ aptitude moo -vvvvv
All right, you win.

                               /----\
                       -------/      \
                      /               \
                     /                |
   -----------------/                  --------\
   ----------------------------------------------
$ aptitude moo -vvvvvv
What is it?  It's an elephant being eaten by a snake, of course.

Pokud by náhodou někdo zapomněl otázku nebo odpověď, tu, no, však víte, tamtu. Stačí otevřít editor vim a zadat :help 42:

What is the meaning of life, the universe and everything?  *42*
Douglas Adams, the only person who knew what this question really was about is
now dead, unfortunately.  So now you might wonder what the meaning of death
is..

Milovníci kočiček mohou v manu ack-grepu jednu takovouo nalézt. Spouští se příkazem ack-grep --thpppt:

_   /|
\'o.O'
=(___)=
   U    ack-grep --thpppt!

Pokud máte nainstalován prográmek cowsay, můžete napsat, aby vám něco kravička pověděla:

$ cowsay hello
 _______
< hello >
 -------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

A nebo taky můžete…

$ cowsay -f head-in ouch
 ______
< ouch >
 ------
    \
     \
    ^__^         /
    (oo)\_______/  _________
    (__)\       )=(  ____|_ \_____
        ||----w |  \ \     \_____ |
        ||     ||   ||           ||

V případě častého pletení příkazu ls doporučuju nainstalovat sl. Sice to nepomůže odstranit překlepy, zato ale můžete sledovat mašinku.

====        ________                ___________
  _D _|  |_______/        \__I_I_____===__|_________|
   |(_)---  |   H\________/ |   |        =|___ ___|      _________________ 
   /     |  |   H  |  |     |   |         ||_| |_||     _|                \_____A
  |      |  |   H  |__--------------------| [___] |   =|                        |
  | ________|___H__/__|_____/[][]~\_______|       |   -|                        |
  |/ |   |-----------I_____I [][] []  D   |=======|____|________________________|_
__/ =| o |=-~~\  /~~\  /~~\  /~~\ ____Y___________|__|__________________________|_
 |/-=|___||    ||    ||    ||    |_____/~\___/          |_D__D__D_|  |_D__D__D_|
  \_/      \__/  \__/  \__/  \__/      \_/               \_/   \_/    \_/   \_/

Zkuste ji předat nějaké parametry. Bude se měnit.

A to je vše, co jsme dali dohromady. Není toho moc, proto udělám výjimku a přidám ještě jeden grafický easter egg z prostředí Gnome – Alt+F2 a zadat „free the fish“. Tento easter egg vypustí rybičku a půjde se ji zbavit jen killnutím celého gnome panelu.

Bohužel rybička už v novém Gnome Shell není a tak jsem ji převedl do HTML světa. Třeba se bude někomu hodit nebo bude chtít jen zavzpomínat. Je k nalezení třeba taky na intru BOObook.cz (po zadání magického „free the fish“).

Devel.cz 2013

Je tomu týden, kdy proběhla druhá konference Devel.cz. Chtěl jsem se k ní vyjádřit co nejdříve, ale bohužel mi to psaní dříve nevyšlo. Pozdě, ale přeci jen... Možná jen proto, že první se mi opravdu líbila a těšil jsem se na pokračování, které mě však zklamalo. I když jsem si vstup neplatil sám, lituji těch peněz, které jsem mohl použít na něco lepšího. Ještě více lituji drahoceného času.

První co na celé konferenci nechápu je čas oznámení. Tím nemyslím, že by mě newsletter v poledne vzbudil, ale že oznámení přišlo jen pár dní před konferencí. Skoro si říkám, že nejenom pozvánka nepřišla na poslední chvíli, ale že celá konference byla připravena na poslední chvíli.

Díky tomu, že jsem na termín konference nic jiného naplánovaného neměl, mohl jsem na Dejvice dorazit, abych zjistil, že web s konferencí je otřesný. Optimalizace pro telefon žádná a informace kde se přesně koná taky nikde. Přitom tam je místa klidně i na podrobnou mapu. Informace, že se jedná o budovu FIT ČVUT je fain, ale ne každý ví, kde je. Případně vyvěšené cedule by byly taky nebyly k zahození.

Organizátoři nezklamali a uvnitř se na cedule taky vykašlali. Aneb myslel jsem, že pití tentokrát nebude. Dokud na úvodu nebylo řečeno, v jakém skrytém koutku ho lze nalézt. Naštěstí aspoň u vchodu někdo stál a říkal, kde je šatna.

Teď k samotnému obsahu. Zkráceně bych řekl „stálo to za prd“. Přínosná a zábavná přednáška byla snad jen ta, která se nezabývala žádným programovacím jazykem atp., od Patricka Zandla. Ostatní mi přišlo, no, vezmu to postupně.

Dan Steigerwald mluví stále o tom samém. Este.js. Hodnotím ji jako lepší přednášku, protože dokázal uznat a říct, jaké chyby se dopustil na začátku, opravil ji a podělil se o nástroje, které mu s tím pomohly. Škoda jen, že za celou přednášku jsem se dozvěděl jen o existenci pár libek.

Vojtěch Semecký… Ufff. Na jeho místě bych se moc nechlubil jak web, který lze udělat za pár večerů, dělal celých čtrnáct dní. A už vůbec ne řešením – XML převádět na JSON, aby ho Nette celé převedlo do HTML a jQuery skrylo prvky, které na dané URL nemají být vidět. Databáze nebyla použita, protože by do ní byla data pouze zapisována a zase čtena (wtf?) a nebylo generováno z XML rovnou HTML, protože co kdyby se později hodilo data nějak filtrovat (proto asi ten JSON; wtf?). Tohle nepatří na takovouhle konferenci.

Předchozí přednášku jsem musel rozdýchat a tak jsem na přednášku od Davida Majdy a Josefa Reidingera dorazil se zpožděním. Nevypadala špatně, ale byla taková... nebylo řečeno nic neznámého.

U další přednášky jsem přemýšlel zda už jít na oběd nebo počkat, zda se od Michala Illicha dozvím něco zajímavého. Měl jsem jít na oběd. Co to je strojové učení ví snad každý, případně kdo a kde ho používá by šlo říct během chvilky, nemusí to trvat půl hodiny. Druhá půlhodina (okecávka pár odkazů na knihovny) šla taky zkrátit na dvě minuty.

Jelikož organizátoři nezařídili oběd a ani nedali vědět restauracím kolem, aby se připravili na nával, stihl jsem pouze konec přednášky Davida Grudla. Konec byl však dobrý, škoda že jsem ji nestihl.

Michal Špaček měl dobrou přednášku. Škoda ale, že se o tomto tématu neustále mluví, a tím nepřinese na takové konferenci nic nového. Aspoň mě se to tak zdá.

Během půl hodiny vysvětlit efektivní vývoj na iOS od Michala Vašíčka, který začal povídání o tom, jak první rok vyvíjel jen ve virtuálu a neměl vůbec tušení jak to má vlastně dělat… Rovnou jsem vypnul. Za půl hodiny se víc než základní Hello World nestihne a ten je k vidění snad na každé konferenci.

Martin Malý mě velice zklamal. Od něj jsem čekal něco víc, ale pokračoval v duchu předchozí přednášky – tedy od něj jsem se dozvěděl to, co se dočtu na hlavní stránce CoffeeScriptu. Obohacené jen o to, na co si dát pozor.

Potom jsem už odešel raději domů a netrápil se.

Problém vidím hlavně v tom, že přednášky byly teoretické a chudé. Teorie se dá načíst z tutoriálů a dokumentace během pár minut. Nemusím kvůli tomu sedět celý den na nějaké konferenci. Mě hlavně zajímá praxe. Zkušenost s nasazením. Jaké jsou problémy. Co je dobré. Kdy je dobré danou technologii použít. A podobné věci.

Příště si rozmyslím, zda se přijdu zase podívat.

Tipy na testování webových aplikací

Testováním webových aplikací se zabývám už poměrně dlouho a přijde mi, že integrační testy v podobě Selenia jsou mnohem důležitější, než jednotkové testy JavaScriptu nebo backendu. V různých knihách a článcích se píše o tom, že pokud není praxe, ať se testuje dle toho, co danému programátorovi přijde vhodné. Tím se získá praxe a najde se ten cit pro rozhodování jaké napsat testy přednostně a čím se nemá smysl zabývat.

Také jsem tak začínal a cit si vybudoval. I když, stále se mám co učit. Dnes už ale vím, že to není zrovna nejlepší poučka. Minimálně co se týče webových aplikací. Tam už vím, že nejlepší je sáhnout prvně po Seleniu. Důved je velmi prostý – jednotkové testy, jak JavaScriptu, tak backendu (ať už je to jakýkoliv jazyk), otestují jen nějakou tu jednotku. Řekne to programátorovi „hele, tenhle kus kódu je správný. Jestli ale náhodou šablona očekává něco jiného a nezobrazí tlačítko, na kterém to je závislé… to už nevím. Ověř si sám.“ nebo tak nějak.

Tohle však testy bohužel neřeknou. Odpoví jen stručné „OK“. Jakmile tuto odpověď uvidí programátor, jde radostně nasadit na betu, oznámí uživatelům že mohou testovat a ejhle. Ona tam je chyba v šabloně (nebo v čemkoliv jiném, co už jednotkové testy nepodchytí) a programátor musí po víkendu zjišťovat, cože to v pátek dělal a cože to musí opravit.

Neříkám však, že ostatní testy nejsou dobré. Taky mi odhalili spoustu chyb, Selenium však jednoznačně vede.

To je tedy tip číslo jedna – u webovek se zaměřit více na Selenium.

V naší aplikaci v práci mi hodně vadilo, že tam máme spoustu chyb v JavaScriptu. Webmasteři se u nás ještě do nedávna střídali jeden za druhým, každý si to dělal po svém a nikoho nezajímalo, co tam je a co tam bude. Dnešní situace je už dobrá a neustále se zlepšuje, bylo mi to ale málo a napadlo mě do našich Selenium testů přidat kontrolu JavaScriptových chyb. Do stránky jsem přidal kus JS:

<script type="text/javascript">
window.jsErrors = [];
window. function(errorMessage) {
  window.jsErrors[window.jsErrors.length] = errorMessage;
}
</script>

a v Selenium (po každém testu, v tearDown) přečetl obsah proměnné jsErrors. Spustil to a… nalézalo to jednu chybu za druhou. Tady className neexistuje, tajhle null nemá atribut getElementsByTagName apod. Vlastně ještě dnes to nalézá takové chyby díky tipu číslo tři, o tom ale až za chvíli.

Úprava mě stála asi hodinku se vším všudy a dostal jsem mocnou zbraň proti bugům v JavaScriptu. Stačí aby se na něco opomnělo a testy zařvou. Druhý tip je myslím jasný – přidat do Selenia podporu na hledání JavaScriptových chyb.

Je tedy pravda, že takhle selžou testy, které ve skutečnosti prošly. „Jen“ nastala nějaká drobnost v JavaScriptu. Já na to odpovím: nezájem. Je tam chyba? Je. Opravit.

Říkal jsem, že nám tu testy stále oznamují různé chyby v JavaScriptu díky třetímu tipu. Tento tip zní: fuzzy testování.

Zmíněná aplikace je velmi obrovská a testy se začaly psát teprve někdy před rokem a půl. Stále máme spoustu nepokrytého místa, které se zpětně těžce vyplňuje (nelze se vybodnout na všechny známé bugy a feature requesty, na měsíc se zavřít ve sklepě a dopsat všechny testy). To mě pochopitelně trápilo a vyřešil jsem tento problém alespoň fuzzy testováním. Během chvilky jsem napsal primitivní algoritmus na náhodné proklíkání webové aplikace.

Neočekával jsem, že to něco pořádně najde, ale světe div se… ono to našlo hned chybu na dvacátý náhodný klik. Klik, který by neudělal žádný programátor (protože ví, kam klikat nemá), ale ani tester či uživatel. Tedy, věřím, že to někdo už udělal, jen se nenamáhal s reportem. Fuzzy testování jsem zatím nechal v primitivní podobě jak jsem to poprvé napsal a stále to nachází různé fatální chyby, které měly skončit jen chybovou hláškou. Někdo by mohl konstatovat, že to je drobnost, nic kritického. Uživatel má však opačný názor.

Minimálně v našem případě to hodně pomáhá s najitím chyb v JavaScriptu různě v aplikaci, kam se Selenium testy sami od sebe jen tak nepodívají.

Zbývá poslední tip. Selenium je takové neohrabané. Hodně mi vadil styl použití. Sice používám webdriver (Selenium 2), což je lepší, než předchozí verze, ale stále to není ono. Takže jsem napsal wrapper, který práci se Seleniem ulehčí. Kód jsem vystavil volně na GitHubu a ještě mám nějaké plány na zlepšení než to převedu do stable verze. Každopádně už nyní to používají dvě aplikace. Více zde: https://github.com/horejsek/python-webdriverwrapper. (Jedná se o Python.)

Pokud bych dnes začínal nový projekt, s těmito testy bych začal.

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.