To ale není jediný možný přístup k tvorbě programů. Teorie (a koneckonců i praxe) říkají, že stejné výpočetní síly jde dosáhnout také pomocí vhodně složené sady logických formulí (“Logické programování”). Nabízí se otázka, jestli – a jak – způsob programování ovlivní, jaké chyby se v programu mohou vyskytnout. Logické programování ale je spíš koncept výpočtu než určitý programovací jazyk, proto se ve zbytku textu omezím na vyprávění o jazyku Prolog, který z tohoto konceptu vychází.

Pravda ale také je, že největší inspirace k sepsání tohoto textu je cvičení z Neprocedurálního programování, které vedu, a kde se začíná právě Prologem. Seznam typů chyb tak je z větší částí soupis chyb, na které jsem narazil během opravování domácích úkolů. Některé z nich jsem čekal, jiné (hlavně ty z první kategorie) mě dost překvapily.

Překlepy, syntaktické chyby a chyby při překladu

K této kategorii chyb není moc co říkat, tady se Prolog v ničem neliší od imperativních programovacích jazyků. Prolog má, stejně jako jiné programovací jazyky, určitou syntaxi, kterou není složité porušit. Asi největší problém je zvyknout si na to, že velké/malé první písmeno identifikátoru rozhoduje o jeho typu (proměnná/konstanta). Na druhou stranu, překladač na takové chyby upozorní, takže jejich oprava je triviální.

To samé platí pro překlepy v názvech predikátů. Prolog sice není staticky kompilovaný jazyk a za běhu jde přidávat nebo odebírat pravidla a fakty (program se tak může sám modifikovat), ale pokud váš program obsahuje dotazy na neexistující predikáty, tak překladač vypisuje varování. Všechna varování sice jde vypnout, ale pokud si pod sebou někdo cíleně řeže větev…

Překlep v názvu proměnné je o trochu horší. Proměnné v Prologu jsou deklarované prostě tím, že jsou někde v programu zapsané. Situaci trochu zachraňují varování překladače v případě, že je některá z proměnných použitá jen jednou, ale ani to nemusí stačit. Nepříjemné je i to, že styl programování v Prologu vede k velkému množství pomocných proměnných a kde je hodně proměnných, tam rychle vzniká chaos.

Logické chyby

V případě logických chyb opět nejde o nic, co by v jiných jazycích nebylo. Špatný – nebo špatně zapsaný algoritmus, konstanta sem, konstanta tam, špatně zapsaná podmínka… prostě nic, co by v jiných jazycích nebylo. A stejně jako v jiných jazycích, ani v Prologu překladač s hledáním logických chyb moc nepomůže. Koneckonců, jak říká teorie, překladač může odhalit zjevné chyby, ale jinak toho moc nezmůže. A stejně jako typy chyb, i způsob boje proti nim je zcela tradiční.

Kapitola sama pro sebe jsou nekonečné cykly. I v programu, který je jinak úplně správně, není problém vyrobit nekonečný cyklus vhodným přehozením podmínek. V logickém programování jako výpočetním modelu se při vždy (nedeterministicky) vybere správný postup výpočtu. V praxi to je trochu problém, protože orákulum pro správný nedeterministický výběr stále ještě nepatří k mezi běžně dostupný hardware. Pořadí, v jakém Prolog provádí vyhodnocování proto je pevně dané a tak stačí nešťastné pořadí predikátů…

Chyby způsobené nejednoznačností

Třetí typ chyb by sice správně měl patřit pod “Logické chyby”, ale protože jde o záležitos specifickou pro Prolog a jeho způsob výpočtu, nechám je samostatně. Koneckonců, jde o článek o Prologu, ne?

Z nedeterministické povahy výpočtu v logickém programování vyplývá také další typ chyby. Volbu “správného” směru výpočtu nejde (na současných počítačích) z principu implementovat přímo, proto je v Prologu nahrazena backtrackingem. Pokud v některém kroce výpočet nemůže pokračovat dál, není to žádný problém, Prolog se vrátí o krok zpět a (opět podle deterministických pravidel) zkusí jinou větev výpočtu. Nejlépe je toto chování vidět přímo v příkazovém řádku interpretu Prologu – po nalezení odpovědi na dotaz Prolog čeká na vaši reakci a pokud odpověď zamítnete (tj. řeknete mu, že výpočet selhal), zkusí backtrackovat, aby našel další možné odpovědi.

To samo o sobě ještě není žádný problém. Naopak jde o základní vlastnost, která dělá Prolog Prologem. Problém je, že programátorům, kteří s Prologem začínají (ale nejen jim), se často stane, že na tuto vlastnost při psaní kódu a při jeho testování zapomenou. Často tak vznikne predikát, který sice dá správnou první odpověď, ale pokud ho přinutíte backtrackovat, budete se divit. Situace, které mohou nastat jsou různé. Začínají neškodným zopakování vrácené hodnoty. To sice zdrží výpočet, ale jinak žádné škody nenapáchá. Horší je, pokud takový predikát vrací správnou hodnotu nekonečně krát, nebo při backtrackování vrací nesprávné hodnoty – to už efektivně znamená buď zacyklený program, nebo celkově chybný výpočet.

V zásadě jsou dvě možnosti, jak se těmto chybám bránit. První z nich je dopsat vstupní podmínky ke každé variantě predikátu, aby pro každý vstup bylo jednoznačně určeno, ke kterém predikátu patří. Druhá možnost je vhodně umístěný operátor řezu. Jaká varianta je lepší záleží na konkrétní situaci – operátor řezu může vést k efektivnějšímu programu, na druhou stranu se tím ztrácí přehlednost a ještě víc se zvedá význam správného uspořádání pravidel. Může se stát, že nejednoznačnost v určité úloze nevadí, protože na backtracking nikdy nedojde. Ale i v takovém případě je dobré na možné problémy s nejednoznačností myslet, protože tyhle okamžiky “nikdy” nastávají až nečekaně často.

Na závěr jen krátký (učebnicový) příklad, jak nevinně může taková chyba vypada.

removeAll(_, [], []).
removeAll(X, [X|Xs], Ys) :- removeAll(X, Xs, Ys).
removeAll(X, [Y|Xs], [Y|Ys]) :- removeAll(X, Xs, Ys).

Oprava by mohla vypadat například takto:

removeAll(_, [], []).
removeAll(X, [X|Ys], Ys) :- removeAll(X, Xs, Ys).
removeAll(X, [Y|Xs], [Y|Ys]) :- X \= Y, removeAll(X, Xs, Ys).

nebo s použitím operátoru řezu takto:

removeAll(_, [], []).
removeAll(X, [X|Xs], Ys) :- !, removeAll(X, Xs, Ys).
removeAll(X, [Y|Xs], [Y|Ys]) :- removeAll(X, Xs, Ys).

Jak jsem vybíral

Notebook používám hlavně na cestách, na balkóně, na zahradě a když zrovna desktop vytěžuju výpočtama. Notebook používám jen na práci a na komunikaci. Aby nedošlo k nedorozumění, práce pro mě znamená jednak programování (v kdečem, hlavně Java, Perl, Haskell, C# a C++) a psaní (LaTeX). Při práci zhusta využívám standardní unixové nástroje (bash, sed, grep, …) pro skriptování a pro transformaci dat. Hry na notebooku nehraju, na filmy se na něm dívám jen zřídka. Naopak si cením lehkých notebooků s pevnější konstrukci (k NTB se chovám slušně, ale často ho přenáším) a delší výdrž na baterie, abych s sebou nemusel nosit adaptér úplně všude.

Když to shrnu, tak od notebooku chci, aby

• na něm šlo bez problémů provozovat Linux nebo jiný Unix-like systém.
• byl snadno přenosný – tedy aby se mi vešel do batohu (v pouzdře) a nepřipadal jsem si s ním na zádech jako šnek s ulitou.
• vydržel běžet z baterie ostře víc než tři hodiny.
• měl rozumný výpočetní výkon (stačí libovolně Core2 Duo + dostatek paměti)
• nevětral, pokud zrovna nedělá něco fakt náročného.
• byl od "rozumného výrobce" a byla na něj dostupná záruka typu Next Business Day.
• nepoužíval dotykové senzory a nevypadal jako vánoční stromeček.

Naopak nepotřebuju

• výkonnou grafickou kartu.
• velké LCD nebo nadstandardní rozlišení.
• "bezpečnostní" mechanismy jako je čtečka otisků prstů nebo systémové heslo.
• závratně velký disk, nedejbože dva v RAIDu.
• moc USB portů nebo dokovací stanici.

Nakonec jsem na vybíral mezi ThinkPadem X200 a 13,3" unibody MacBookem. X200 je sice menší a o dost lehčí, po dlouhém rozhodování ale vyhrál MacBook (větší, ale stále přijatelné rozměry a váha, o něco nižší cena, Unix bez shánění ovladačů a jako bonus možnost vyvíjet pro iPhone).

Co mi vyhovuje

Začnu tím, co se mi na MacBooku proti mým předchozím notebookům líbí. Jako první věc – ano, OS X skutečně má pod grafickým rozhraním Unixový systém. Všechny standardní nástroje včetně pěkné terminálové aplikace jsou hned v základní instalaci. Překvapilo mě, že byl k dispozici i Perl, Subversion klient a X-Window server. Navíc díky MacPorts lze instalovat další (Unixové) aplikace stejným způsobem jako na FreeBSD. Obecně – pokud nějaká aplikace existuje pro Linux, pravděpodobně půjde přeložit i pro OS X a pravděpodobně už to někdo udělal. Na druhou stranu jde o systém určený pro daný hardware, takže není potřeba nic kompilovat, konfigurovat nebo instalovat. A pokud potřebuju nějaké aplikace z Windows, jde je virtualizovat (a s VMWare Fusion i "integrovat" mezi Macovské). Visual Studio 2008 není žádný problém.

Uživatelské prostředí v OS X je vcelku příjemné a nemám pocit, že by mě nějak brzdilo při práci (až na pár drobností popsaných níže). Když si člověk zvykne na nové klávesové zkratky, dá se s ním pracovat celkem efektivně. Navíc dvojhmaty přes Command (který je vedle mezerníku) mi přijdou o dost jednodušší než přes Control, není na ně potřeba tolik kroutit ruce.

Dál se mi hodně líbí tělo "z jednoho kusu hliníku" (jak udělali, že notebook jde otevřít, když to je z jednoho kusu?!), notebook je díky němu pěkně pevný, nikde se nic neprohýbá a nevrže. Tělo navíc slouží pro odvod tepla jako velký (a tichý) chladič. Ale už vím, že uvnitř je i větráček – viděl jsem ho, když jsem přidával paměť. Trochu jsem se bál, aby při větším zatížení nebyl rozpálený celý notebook, ale zatím jsem nenarazil na problém a i po delším zatížení není horký a jde bez problémů nechat na kolenou. Ještě uvidím, jak se bude chovat za horkých letních dní. Pěkný je taky adaptér – je celkem malý a navíc jde, podobně jako u Dellu, jednoduše sbalit do úhledného balíčku (ale to si možná zaslouží vlastní zápis).

Příjemná věc je obrovský touchpad bez tlačítek. Chce to chvíli si zvyknout, ale už bych neměnil. Touchpad navíc (ve výchozím nastavení) nekliká po klepnutí, ale až po domáčknutí, takže nechtěná kliknutí prakticky neexistují, přestože není nijak zapuštěný.

A jako poslední drobnost (ale příjemnou) bych uvedl design, který je prostě povedený. Opravdu si cením celkové "jednoduchosti" – co není potřeba, to tam není. Prakticky žádné rušivé modré a zelené diody. A i ty, co tam jsou, svítí jen když je potřeba (dioda co bliká, když je notebook uspaný, ale zhasne, když je zapnutý), nebo když si o to uživatel řekne (indikátor stavu baterie, který je na tlačítko). Prakticky jediný úlet je svítící ohryzek na zadní straně displeje, ale ten stejně při práci s notebookem není vidět Navíc je fajn, že na hliníku nezůstávají viditelné otisky prstů. MacBook White bych používat nemohl.

Co se mi (zas tolik) nelíbí

Tak a teď ty méně příjemné záležitosti. Z hlediska hardware mi chybí hlavně čtečka paměťových karet. Ano, dá se za pár korun sehnat externí, ale je to další věc, kterou je potřeba nosit s sebou. Podobné to je s výstupem na externí monitor. Ten je realizovaný přes Minidisplay Port a je k němu potřeba dokoupit redukci. Že je ji potřeba dokoupit se dá přežít, že to je další věc, co jde někde zapomenout, už je horší. Někomu by mohlo vadit, že MacBook má jen dva USB porty, ale já to nejsem.

Další trochu nepříjemná záležitost je CD/DVD mechanika, která je štěrbinová, takže má problémy s menšími formáty CD. Na druhou stranu, ani si nevzpomínám, kdy jsem naposledy cpal do notebooku vůbec nějaké CD nebo DVD. Vlastně vzpomínám… když jsem po pořízení toho předchozího instaloval Ubuntu.

Na klávesnici mi chybí klávesy PgUp/PgDown, Home a End (které jsou dostupné přes Fn). Dá se na to zvyknout a při práci dvěma rukama je přístup přes Fn a šipky možná rychlejší, než hledat samostatný Page Down někde na okraji klávesnice. Jinak je klávesnice na psaní hodně příjemná, nikde se neprohýbá a klávesy jsou pěkně oddělené mezerami. Moc se mi nelíbí rozložení klávesnice – US je víceméně standardní, ale u české jsou některé znaky jinde než jsem zvyklý a na středník přes Alt si budu zvykat hodně těžko.

Věc, která mi ale u ovládání vadí asi nejvíc je chybějící tlačítko pro kontextové menu. Ve většině aplikací jde nazkratkovat celé menu, ale z nějakého důvodu ve Finderu v menu chybí položka "Otevřít s…". To je jen v kontextovém menu souboru a jediný způsob jak se k tomu dostat, je myší. Podobně myšové mi přijde přepínání v rámci oken jedné aplikace (ano, to z klávesnice jde, ale…).

Displej má výborný obraz a podsvícení, jenom nechápu, proč se musí tak lesknout. Asi to je součást firemní image. Nebo výsledek lobby očních lékařů. Jak jsem zjistil, existují přímo pro MacBook matné fólie, ještě kdyby je někdo (za rozumnou cenu) dovážel do ČR… Díky dobrému podsvícení se dá pracovat i v autobuse/ve vlaku, ale na matno by to bylo ještě lepší. Navíc mi přijde, že 1440×900 by na 13,3" notebooku bylo výborné rozlišení, ale co, pracovat se dá i v 1280×800. Co ale nechápu už vůbec, je, že celkem nízké rozlišení je i u 15,4" MacBooků Pro.

Daly by se najít ještě další drobnosti, jako poněkud nestabilní ukazatel baterie (i když za to možná mohla automatická regulace jasu displeje), ale už nejde o žádné zásadní bugy, které by mě nějak trápily.

Závěrem

I když se na něm dají najít věci k pomlouvání, myslím si, že MacBook výborný stroj, který bez problémů plní moje požadavky. OS X vidím jako výhodu, není v něm problém přepínat mezi klikáním a konzolí jak se mi to zrovna hodí – a pokud zrovna potřebuju Visual Studio, tak s Fusion to jde i bez přepínání do virtuálního počítače. Desktop od Apple bych si nekoupil, ale MacBook je výborná volba (nejen) jako Unixový notebook, v žádném případě nelituju, že jsem si ho pořídil a doporučuju i ostatním. Doporučuju

Určení, jestli formulář vyplnil člověk nebo spamovací automat je pak jednoduché – pokud je úkol splněný správně, pak formulář zřejmě vyplnil člověk. Pokud ne, byl to počítač. Nepříjemné je, že splnění úkolu se musí testovat na serveru – pokud by k němu docházelo pouze na klientovi, bylo by pro spammery jednoduché tuto kontrolu obejít vyřazením testu (například vypnutím JavaScriptu) a pak odesílat obsah formuláře automaticky.

Na druhou stranu ale je nepříjemné, že pokud formulář obsahuje validaci hodnot v JavaScriptu, pak se tato validace nedá moc dobře vztáhnout i na captchu. Lze sice najít jednoduché řešení pomocí AJAXu, ale to naráží na asynchronní komunikaci a na bezpečnostní omezení XMLHttpRequestu (zakázané cross-domain requesty, které nemusí, ale mohou vadit).

Druhá možnost, jak dosáhnout validace už na straně klienta, je inspirovat se kryptografickými postupy. Víme například, že faktorizace na prvočísla je těžký problém, pro který neznáme efektivní algoritmus. A teď jak toho využít pro tvorbu captchy:

1. Příprava na serveru: server vygeneruje dvě dostatečně velká prvočísla p a q a vypočítá jejich součin n. Prvočíslo p zakóduje do captchy (například jako obvyklá čísla v obrázku) a spolu s obrázkem pošle číslo n.
2. Klient dostane obrázek s kódem a číslo n. Uživatel opíše číslo z obrázku. Pokud ho opíše správně, jde o prvočíslo p a číslo n je jím dělitelné bez zbytku. JavaScript během validace formuláře ověří dělitelnost a v případě neúspěchu upozorní uživatele.
3. Protože faktorizace je obtížný problém, klient pouze na základě čísla n nemůže v rozumném čase zjistit, jaké jsou hodnoty p a q. Navíc, pokud by jí provedl, uspěje pouze v 50 % případů, protože správná odpověď je pouze jedno prvočíslo, klient ale bez použití obrázku neví, které z prvočísel to je.

Pro dosažení rozumné bezpečnosti je potřeba použít delší prvočísla. Dostatečná hodnota by mohlo být například 256 bitů na jedno prvočíslo. Drobnou nevýhodou této metody je, že taková prvočísla mají cca 77 číslic (znaků), což by odradilo nejen spammery, ale i běžné uživatele. Pokud pro kódování použijeme i velká a malá písmena, sníží se počet znaků na 44, což moc velké zlepšení není.

Lepší tedy je použít alternativní řešení (díky Jirkovi za nápad), zvolit dostatečně dlouhý náhodný kód, tak 6-10 znaků, zakódovat je do captchy klasickým způsobem a spolu s captchou poslat hash kódu. Pokud bude hashovací funkce zvolená rozumně, nebude možné pomocí ní získat původní kód a navíc inverze hashovací funkce opět povede k více možnostem, z nichž jen jedna bude správná.

Nejlepší (nejjednodušší) nakonec ale stejně bude přestat teoretizovat, zůstat u současných (osvědčených) řešení a captchu ověřit jen na straně serveru…

Co mají obě hry společného? Obě jsou velmi dobře chráněné proti pirátům. Dokonce tak dobře, že je (legálně) jde nainstalovat jen třikrát. V praxi to znamená, že si člověk nesmí přeinstalovat Windows. Nesmí měnit hardware, nesmí svoji kopii půjčit sourozencům když zrovna není čas na hraní. Jinak si vyčerpá svůj čas na hru bez toho, že by aspoń trochu zahrál. Za ceny přes 1000 Kč to je trochu moc starostí. V případě Stalkera jde ochranná perverze tak daleko, že omezení na tři instalace mí i verze pro Steam, který sám o sobě zajišťuje aktivaci po Internetu. Tady mě vážně nenapadá jiné vysvětlení, než záměrné omezování uživatelů.

Teoreticky jde hru upiratit. Pokud pomineme, že pirátství nelegální, je pro autory hry docela užitečné. Takový pirát jednak rozšiřuje komunitu hráčů (a slouží jako motivace pro další zájemce o hru) a jednak slouží jako docela dobrá reklama. Reklama, která nemá problémy s počtem aktivací a proto o nich nikomu neřekne. Jasně, že pár lidem tu hru nahraje sám pirát, ale pár dalších si ji třeba koupí. A nebo si ji koupí známí pirátova kamaráda. A tak dále.

Pojďte si taky nekoupit Spore a další hry s DRM a dát tak jasný signál, že tohle nechceme. Pojďte takové hry nestahovat, ať nemají vydavatelé pocit, že to je skoro ono, jenom to chce lepší ochranu. Pojďte podporovat tvůrce, kteří aktivaci nevyžadují. Že situace není ještě úplně ztracená, ukazuje třeba i český a polský CD Projekt, jejichž Zaklínač nejen nevyžaduje aktivaci, ale pro kterého dokonce nabídli obsah nedávno vydané rozšířené edice zdarma ke stažení majitelům původní hry. Takhle má vypadat služba zákazníkům, ne je omezovat a obvińovat z krádeže (u videjí navíc obvinění vidí jenom majitelé originálu, kdo by si něco takového kopíroval s filmem?). Tak co, kdo další se přidá?

Tento zápis je hlavně seznam problémů a nedodělků, na druhou stranu nechci, aby z něj nekdo získal dojem, že mobilní Opera je nepoužitelný krám, protože to prostě není pravda. Jde o funkční a poměrně rychlý prohlížeč, ve kterém jde, více či méně pohodlně, udělat témeř vše, co v plnohodnotné verzi na PC. A to nemluvím pouze o prohlíženi statických stránek a hledání na Google. Nakonec úspěšně proběhly i složitější operace jako rezervace hotelu a letenek.

Tolik k pozitivním stránkam, teď ty slibované nepříjemnosti. K mému překvapení se ukázalo, že Opera Mini a Opera Mobile jsou hodně odlišné aplikace, a co je v jedné dobře zvládnuté, může v druhé představovat velký problém. Další text proto rozdělím do sekcí podle toho, o kterou verzi jde.

Společné neduhy

Načítaní obrázků

Příjemnou vlastností obou mobilních Oper je, že lze vypnout nahrávání obrázků, aby se stránky načítaly rozumně rychle i s pomalejším připojením. I když jde o standardní vlastnost, přítomnou ve všech prohlížečích, na mobilech ji považuji za obzvlášť důležitou, protože rychlé mobilní připojení stále není standardem ani ve vyspělejších zemích. O cenách za kilobyte nemluvě.
Většinu času jsem pracoval bez načítání obrázků, nicméně ve výjimečných případech to bez nich prostě nejde (captcha, fotky při rezervaci ubytování, mapy, …). Proto mě dost překvapilo, že načítáni jde zapnout/vypnout jen globálně pro celou aplikaci (a ne například pouze pro jedno okno ve verzi Mobile). Zároveń chybí funkce “načíst obrázky na aktuální stránce”, kterou je nutné emulovat zapnutím načítání v Settings, reloadem stránky, a následným vypnutím načítání. Implementace takove funkce je triviální a výrazně by zvýšila uživatelský komfort.

Rozložení stránky vzhledem k velikosti displeje

Hodně stránek není vytvořených korektně podle webových standardů. A i ty co jsou, často nepočítají se zobrazením na miniaturních displejích mobilů a PDA. Obvykle to nepředstavuje vážný problém, ale například použití frame pevné šířky může znamenat problém, protože celou plochu obrazovky zabere navigační menu, zatímco na užitečná data zbývá jeden řádek textu.
Ideální řešení by asi bylo použít virtuálni obrazovku určité “běžné” velikosti (např. 800×600) pro výpočet velikosti prvků stránky, a nepočítat podle velikosti obrazovky telefonu nebo PDA.

Opera Mini

Jde o J2ME aplikaci optimalizovanou pro mobilní telefony. Překvapivě je hodně svižná a ani na stránkách využívajících JavaScript s ní nebyly zásadní problémy.

Pohyb kurzoru

Opera dobře zvládá reagovat na pohyb kurzoru (hover, JavaScriptové handlery), tady problém není. Problém je, že kurzor je vždy cca ve středu zorného pole. To ale znamená, že pokud se nějaka informace zobrazí při zastavení kurzoru nad určitým prvkem na stránce (tooltipy, vysvětlivky, …) a není viditelná celá, tak si ji neprečtete. Při posunu výhledu se totiž posune i kurzor. V tu chvíli ale přestane být na tom jediném správném místě a informace opět zmizí, nebo ji nahradí jiná.
Částečné řešení je ve vhodnou chvíli vypnout podporu JavaScriptu (globální volba, stejně jako u načítání obrázků), přečíst si kýžený text, a pak JS opět zapnout. Komfort opět veškerý žádný.

Podpora více oken

Prestože Opera dokáže otevřít pop-up okna nezávisle na zdrojovém, človek nic takového udělat nemůže. Přitom právě možnost mít více oken současně je klíčová třeba při hledání dopravy, hotelu a dalších činnostech, kde se porovnávají různé nabídky a možnosti. Nutná funkčnost v Opeře očividně implementovaná je (viz pop-up okna), proto nechápu, proč není možné používat více než jedno okno v jeden okamžik.
Částečne je možné tuto funkci “simulovat” pomocí záložek nebo ukládáni stránek do paměti, ale ani jedna možnost není zcela funkční a přináší s sebou řadu problémů, především u aplikaci s formuláři.

Opera Mobile

Jak název napovídá, jde o verzi pro Windows Mobile (resp. Pocket PC). Původně jsem očekával, že půjde o výrazně vyspělejší aplikaci, než je Javová verze, ale skutečnost mě mnohdy dost překvapila.

Ukládání stránek

Z neznámého důvodu není možné uložit stránku “na disk”. Nevím proč a neumím si to nijak vysvětlit, protože to zvládá i verze Mini.

Zavírání oken

Tlačítko pro zavření okna je hned nad horním tlačítkem vertikálního scrollbaru. A neptá se na potvrzení. No a zkuste se do toho scrollbaru strefit stylusem… Za jízdy autobusem… Po křivých anglických silničkách… Máte? Dodávám, že jsem se občas ukliknul, i když jsem seděl v klidu na posteli. Což dost naštve, zvlášť když človek scrolluje, aby zkontroloval pracně vyplněný formulář.
Co by pomohlo – buď nechat zavíráni oken jen v kontextovém menu okna (kde prozměnu tato funkce chybí), nebo před zavřením okna požadovat potvrzení. A nejlépe obojí.

Závěrem

Protože v příspěvku píšu hlavně o nedostatcích, musím ještě jednou zdůraznit, že se jedná o funkční a ve většině případů dobře použitelný software, který je stále výrazně lepší, než konkurence (různé OEM prohlížeče v telefonech a Pocket Internet Explorer). A to jak v komfortu, tak v množství funkcí. Navíc se pro PDA chystá výrazně inovovaná verze 9.5, u které už snad většina uvedených výtek nebude platit. Uvidíme – zatím budu vše z povzdáli sledovat a v pravou chvili se do věci vložím.

$tal->process(a => $a, b => $b, a_or_b => $a || $b);

To je ale nepříjemné řešení, protože zesložiťuje komunikaci mezi šablonou a “užitečným kódem” a může vyžadovat úpravy perlového kódu při změně designu stránky.

Jak tedy zapsat základní logické spojky? V dokumentace to přímo napsané není, ale nakonec to není tak složité:
Pozn.: v příkladech používám pro Petalovské atributy namespace tal, jako to je v příkladech v dokumentaci na CPANu.

Negace

Nejjednodušší varianta, před podmínku stačí dopsat false:

if (not $hashref->{"a"}) {
  #...
}

lze zapsat jako

<span tal:condition="false:a">...</span>

Konjunkce (logické and)

Logický and jde vytvořit jednoduše, jako vyhodnocení posloupnosti podmínek (tj. vnořením tagů s podmínkou do sebe). Problém je, že tak ve výsledném HTML kódu vzniknou nechtěné elementy. Tomu jde v Petalu zabránit přidáním atributu omit-tag s pravdivou hodnotou (například omit-tag="string:1") u pomocných tagů, přidaných jen kvůli podmínkám.

if ($hashref->{"a"} && $hashref->{"b"}) {
  #...
}

lze tedy zapsat jako

<span tal:omit-tag="string:1" tal:condition="a">
  <span tal:condition="b">
    ...
  </span>
</span>

Disjunkce (logické or)

S disjunkcí to je o něco složitější, trik s vnořování tagů tu zopakovat nejde. Na druhou stranu lze využít schopnost Petalu vkládat hodnoty proměnných přímo do textu pomocí dolarové notace – ${x} se při zpracování šablony nahradí hodnotou proměnné x. To lze využít ke skládání hodnot pro podmínky. Přidáním string: na začátek podmínkového atributu Petal přinutíme, aby výraz v podmínce zpracovával jako řetězec (a ne jako název proměnné). Pak do něj lze zadat více proměnných najednou (viz příklad). Pokud alespoń jedna z nich bude mít pravdivou hodnotu, pak bude mít pravdivou hodnotu celý řetězec a podmínak bude splněna.

if ($hashref->{"a"} || $hashref->{"b"}) {
  #...
}

lze zapsat jako

<span tal:condition="string:${a}${b}">
  ...
</span>

Složitější výrazy

Už budou trochu problém… každou logickou formuli sice lze přepsat na konjunkci disjunkcí (konjunktivní normální tvar) a na ten pak aplikovat výše uvedené postupy, ale o přehlednosti takové šablony bych si dovolil předem pochybovat. O skutečné potřebě používat takové podmínky také.

V tomhle dojmu mě utvrzuje i drobná poznámka na konci Vrecova zápisku na stejné téma, že před časem se to -ml- pokoušel vytáhnout z konkurence. Na jednu stranu obdivuju jeho výdrž a odhodlání, ale pokud má Excalibur dotáhnout do úspěšného konce, je potřeba především silná vlastní vize, ne sbírat moudrosti z komentářů na Internetu…

To ale neznamená, že bych jeho snaze nefandil. Už jenom proto, že -ml- v Excalibur očividně opravdu hodně věří. A taky proto, že situace na trhu českých herních časopisů je, mírně řečeno, strnulá. A proto, že před časem jsem s nostalgií pomalu na Aukru dával dohromady první ročníky Excaliburu a Score a vzpomínal na ty krásné časy

První problém: soubory s Masonovskými komponentami obsahují HTML kód (z pochopitelných důvodů psaný jako UTF-8) a je potřeba Perl přesvědčit, že je tak také má interpretovat. V “normálním” skriptu to lze udělat například přidáním řádku

use utf8;

na začátek souboru. Masonovská šablona sice normální skript není, ale Mason šablony při zpracování překládá na skripty (takže text+html v šabloně padne do řetězcových konstant) a ty pak spouští. Takže zbývá jen odhalit, jakým způsobem do nich propašovat výše uvedený řádek. Přímočerá možnost je uvést ho do sekce <%init> u každé komponenty. Nepraktické, že? Naštěstí jde Masonu v konfiguraci Apache předat kus kódu, který bude přidán na začátek kódu každé komponentu. Při použití přes mod_perl stačí do konfigurace Apache přidat řádek:

PerlSetVar MasonPreamble "use utf8;"

Podobně pro (Fast)CGI.

Druhý problém: Apache2::Request nenastavuje interní Unicode flag automaticky, přestože z HTTP hlaviček ví, že data v Unicode jsou (kvůli možným útokům přes neplatné UTF-8 znaky). Při normální práci přes mod_perl není problém parametry správně překódovat nebo zpracovat ručně, ne přes Apache2::Request. s Masonem to je trochu horší – parametry si zpracovává sám pomocí Apache2::Request a nepodařilo se mi najít jednoduché řešení, jak zasáhnout přímo do zpracování parametrů, ale bez změn ve zdrojových kódech Masonu. Naštěstí se k parametrům dá dostat v Masonovských autohandlerech ještě předtím, než se k nim dostane libovolná komponenta. Vložení následujícího kódu do autohandleru v kořenovém adresáři aplikace

<%init>
%ARGS = map { 	$_ = Encode::decode('utf8', $_); }%ARGS;
$m->call_next(%ARGS);
<%init>

způsobí překódování parametrů do UTF tak, že všechny ostatní komponenty je dostanou ve správném tvaru.

Třetí, čtvrtý, … problém: řetězce z databáze, souborů a dalších zdrojů. Ale to až někdy jindy. A nebo na to přijdete sami

Nebylo. Při kontrole korektnosti pozice se testovalo, zda v některé skupině (tj. řádku, sloupci nebo podčtverci) nejsou dvě stejné hodnoty a že pro každé pole zbývá alespoń jedna možná hodnota. Přidáním dalšího testu, který kontroluje, jestli do každé skupiny stále lze vložit (nebo už je vloženo) všech devět číslic. Na úloze z předchozího příspěvku klesl počet návratů při backtrackingu díky rychlejší detekci nekorektní pozice z 174844 na 35039.

Bez dalších technických optimalizací se čas nutný přo nalezení řešení výše zmíněné úlohy (na stejném stroji) snižil z průměrných 2940,3 ms na 392.16 (± 16) ms. Nová verze solveru včetně zdrojových kódů je ke stažení na stránce projektu. Několik nápadů na zrychlení ještě zbývá, ale to zas někdy příště…

Na začátek pár slov o reprezentaci dat a uložení hrací plochy. Ke každému políčku (Field) si algoritmus udržuje tři základní údaje: hodnotu políčka (0-9; 0 znamená nevyplněné políčko) a množinu hodnot, které políčku ještě jde přiřadit (jeden bit pro každou hodnotu). Stav hrací plochy je pak uložen jako dvourozměrné pole políček.

Základní myšlenka řešícího algoritmu spočívá v propagaci možných hodnot a backtrackingu, podobně jako v programování s omezujícími podmínkami. Po přiřazení hodnoty jednomu políčku je tato hodnota zakázána všem ostatním políčkům ve stejné skupině (řádku, sloupci, čtverci). Když v některém políčku zbyde jediná hodnota, pak ji tomuto políčku přiřadí (a provede další propagaci). Pokud jsou v některém poli zakázány všechny možné hodnoty, prohledávání v této větvi končí neúspěchem.
Pokud po skončení propagace hodot jsou některá políčka stále nepřiřazená, algoritmus zkusí do takového pole dosadit jednu z povolených hodnot (to, že políčko zůstalo po propagaci volné znamená, že na základě dostupných informací je do něj možné dosadit více než jednu hodnotu) a provádí backtracking.

Naivní řešení

Naivní řešení používá pro uložení zásobníku java.util.Stack<T>. Při každém sestupu při backtrackování se alokuje nová reprezentace hrací plochy a zařadí na zásobník. O staré stavy ze zásobníku, pro které prohledávání selhalo se stará garbage collector. Jednoduché, ale funkční.

private Stack gameStateStack;

private void pushGameState() {
  Field[][] new_state = cloneGameState(currentGameState);
  gameStateStack.push(currentGameState);
  currentGameState = new_state;
}


Zlepšení s předalokováním

Teď se nad problémem zamyslíme trochu víc. Je snadné si uvědomit, že při řešení Sudoku 9×9 nikdy nebude hloubka zanoření backtrackingu vyšší než 81 – podle počtu polí na hrací ploše. Ve skutečnosti bude ještě nižší, protože některá pole jsou obsazená již v zadání. 81 je poměrně málo. Dost málo na to, aby šlo všech 81 stavů hrací plochy na zásobníku předalokovat a při backtrackingu do nich jen zkopírovat aktuální stav hry.

// alokováno při inicializaci
private Field[][][] gameStateStack = null;
private int stackPosition = 0;

private void pushGameState() {
  stackPosition++;
  cloneGameState();
  currentGameState = gameStateStack[stackPosition];
}

Výsledky

Efektivitu obou verzí kódu jsem testoval na následujícím zadání (těžké sudoku se sedmnácti podporami):

- - -|- - -|- 1 3
- - -|- 3 -|- 8 -
- 7 -|- - -|- - -
-----+-----+-----
- - -|2 - 6|- - -
- 3 -|- - -|9 - -
- - -|- 1 -|- - -
-----+-----+-----
6 - -|5 - -|2 - 4
- - -|4 - -|7 - -
1 - -|- - -|- - -

Naměřené časy shrnuje tabulka níže. Jde o průměrné časy ze 100 pokusů, aby měl JVM dost času se zahřát. Při řešení jednoho zadání solver provedl vždy 174844 rekurzivních sestupů a tedy i “alokací” nového pole.

Časy jsem měřil na počítači s procesorem Intel Core2Duo 1800MHz, spoustou paměti, Gentoo Linuxem a Javou 1.6 (nicméně výsledky na Javě 1.5 jsou obdobné). Rozdíl je sice viditelný (cca 7%), přesto je o dost menší, než jsem čekal. Je vidět, že se v Sunu opravdu snaží o co nejefektivnější JVM a na jejich tvrzení, že nemá smysl optimalizovat na počet alokací opravdu něco bude