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.

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

O projektu

Guido byl na poměry softwarových projektů na MFF poměrně neobvyklý tím, že se jednalo o projekt náročnější hlavně z teoretického hlediska. Konkrétně šlo o implementaci relativně nové teorie z oboru umělé inteligence založené na práci s pravděpodobností. To s sebou přináší několik vlastností, se kterými je dobré počítat předem (my jsme si je ze začátku neuvědomovali úplně do důsledků)

• Množství kódu v takovém projektu je ve srovnání s jinými malé. Pro nezůčastněného člověka to může znamenat, že jste na takovém projektu odvedli málo práce. Vy víte, že to není pravda, bohužel čas strávený studiem a optimalizacemi se na výsledku projeví jen nepřímo.
• Je možné, že komise a oponent projekt nepochopí a nebude ho chtít nechat obhájit. To se nám (alespoń z té druhé části) nestalo.
• Vývoj takového projektu se těžko odhaduje dopředu. Nevíte, kdy narazíte na zádrhel, který vás zdrží nebo donutí část projektu přepracovat.

Na druhou stranu je nutné dodat, že takový projekt pravděpodobně nebude jenom o datlování kódu v co největším množství, ale půjde hlavně o experimentování, hledání nových postupů a optimalizace těch starých. Tím se projekt stává zajímavější a můžou se tím vyvážit i výše uvedené nepříjemnosti. Možná Vás i bude bavit

O týmu

Tým jsme sestavili ještě před začátkem projektu, náš cíl byl co nejmenší tým (a z toho plynoucí menší projekt a jednodušší organizace práce), dohromady tedy čtyři řešitelé (přesněji tři řešitelé, jedna řešitelka a vedoucí). Všichni jsme se znali předem alespoń od vidění z přednášek o umělé inteligenci a díky tomu jsme minimálně vzájemně tušili, co je kdo zač.

V mnoha soupisech zkušeností z obhájených projektů se píše "neberte do týmu své přátele, protože po dokončení projektu už to přátelé nebudou." Myslím, že takové doporučení není úplně správné, v kažédm případě byste měli předem vědět, s kým budete pracovat, protože se svými kolegy s projektu budete muset vydržet rok nebo dva a šance na změnu jsou (zvlášť ve chvíli, kdy je větší část projektu hotová) mizivé.

Je dobré si předem zjistit, kdo z týmu se chystá odjet studovat do zahraničí, kdy a na jak dlouho. Půlka našeho týmu po roce vycestovala na rok do Amsterdamu, naštěstí ale oba ve stejný čas do stejného města, proto jsme mohli pokračovat v práci jenom s drobnou změnou v dělení práce.

O vývoji

Stejně jako zadání nepatřilo mezi úplně typická, tak ani vývoj neprobíhal tak, jak je u softwarových projektů obvyklé. Alespoń podle zkušeností z obhájených projektů jsem pochopil, že práce na projektu se obvykle v úvodní fázi rozdělí do několika částí podle počtu účastníků a ti pak samostatně pracují na svých částech a jen čas od času se sejdou, aby probrali noviky a určili směr dalšího vývoje.

To v případě Guida nebylo úplně možné, protože ani po začátku vývoje nebylo úplně jasné jaká bude náročnost jednotlivých částí projektu. Navíc se nám před zahájením projektu dostala do ruky kniha Extrémní programování od Kenta Becka. Popisované výhody některých postupů byly natolik inspirativní, že jsme se rozhodli je adaptovat.

Základem bylo párové programování, které se nám dařilo udržet téměř po celou dobu vývoje (a to i ve chvíli, kdy polovina týmu odjela za Erasmem do Amsterdamu). Díky tomu odpadla nutnost pravidelných týmových schůzek, protože při vývoji byl obvykle celý tým pohromadě v labu a díky tomu jsme mohli sdílet informace a klást dotazy hned na místě, stačilo jen otočit hlavu. Alespoń z části jsme dodrželi pravidlo o sřídání vývojářů na kódu tak, aby pravidelně procházel (implicitně) revizemi i od dalších vývojářů.

Vývoj tímto způsobem sice probíhá na pohled o něco pomaleji, ale na druhou stranu si myslím, že výskyt chyb v kódu a rychlost jejich odstrańování byly proti individuálnímu vývoji nesrovnatelné.

Díky způsobu vývoje odpadla i nutnost explicitně stanovit vedoucího týmu, protože tým byl v době vývoje celý na jednom místě, bylo možné důležitá rozhodnutí dělat okamžitě a velice efektivně.

Pro vývoj libovolného projektu je vhodné používat systém pro správu verzí, u týmových projektů se jedná o věc naprosto nutnou. My jsme díky nezkušenosti použili CVS, které zvlášť pro projekty v Javě vřele nedoporučujeme, jeho věk je na něm dost znát. Ale libovolný systém je lepší než žádný a nakonec jsme se rozhodli, že si nebudeme přidělávat starosti s přenášením repository na jinam a doklepali jsme to s ním až do konce.

Užitečnou pomůckou při vývoji byly automatické (unit) testy, které díky povaze projektu bylo možné aplikovat ve skutečně velké míře. Testované byly prakticky všechny třídy s výjimkou GUI, kde automatické testování není tak jednoduché a účinné. Možnost kdykoliv kompletně otestovat kód je k nezaplacení – a navíc nám díky testům množství kódu dost narostlo

Spolu s automatickými testy jsme zavedli pravidlo, že projekt v CVS musí být vždy kompilovatelný a všechny testy musí na kódu z CVS uspět (a které jsme dokonce až na pár výjimek dodrželi). To opět velkou měrou přispělo k soudržnosti a nízké chybovosti našeho kódu, protože každý člen týmu měl možnost po celou dobu vývoje testovat projekt jako kompletní aplikaci a každý se radší zamyslel, než něco commitoval do CVS.

Další absolutní nutností je buď e-mailová konference s vyhledáváním, nebo vlastní diskusní fórum. Obojí je poměrně jednoduché zařídit a vždy se vyplatí mít někde archiv všekeré důležité komunikace ohledně produktu. Osobně dávám přednost diskusnímu fóru, které umožńuje lepší organizaci diskusních threadů, jejich další třídění do kategorií a případně i další finesy (například aktuální TODO list vyvěšený na titulní straně).

O závěrečném týdnu

Asi u všech softwarových projektů začne pracovní tempo měsíc až dva před odevzdáním rapidně stoupat, s vyvrcholením v posledním týdnu. Je dobré počítat s tím, že v tomto týdnu už nestihnete nic nového naprogramovat, protože budete číst a přepisovat dokumentaci, zajišťovat její tisk, vyrábět instalační CD a do toho opravovat poslední bugy, které se najednou začnou projevovat v nečekané míře.

Pro poslední týden nebo dva je vhodné si udělat TODO list včetně priorit a věnovat se jenom položkám s nejvyšší prioritou (a těm, které můžete dokončit hodně rychle). Nemá smysl se pouštět do úkolů, které zaberou více jak den, pokud nejsou pro odevzdání naproso nepostradatelné. Byl by problém je dokončit a otestovat v rámci celé aplikace, a nestabilní nebo neotestovaná odevzdaná verze určitě není něco co byste chtěli.

Hned po odevzdání je dobré si zjistit, kdo bude projekt oponovat a nabídnout mu předvedení projektu. Oponent bude mít lepší pocit a vy budete poměrně rychle vědět, jak si s projektem stojíte a co můžete čekat na obhajobě. Navíc to je šance, jak si vyslechnout nepříjemné připomínky k projektu ještě před obhajobou a případně je do té doby vyřešit.

O dokumentaci

Dokumentace se odevzdává jednak uživatelská a jednak programátorská. K uživatelské není asi co dodat, snad jen že by měla popisovat skutečně všechny funkce, protože co není v dokumentaci, o tom se nikdo nedozví. Nevím, jaká je situace u jiných projektů, ale v tom našem se uživatelské rozhraní stabilizovalo až ke konci a předtím jaksi nebylo uživatelskou dokumentaci o čem psát.

Programátorskou dokumentaci je možné rozložit do dvou částí – na jedné straně komentáře v kódu (JavaDoc, resp. Doxygen) a na druhé dokumentace psaná jako souvislý text, která popisuje kód z nadhledu a usnadńuje orientaci. Obě části mají svoje místo a ani jedna nemůže úplně nahradit tu druhou. A obě je dobré psát hned od začátku. Opět se vyplatí pravidlo, že nekomentovaný kód do CVS nesmí, které jsme bohužel zas tolik nedoržovali.

Při psaní JavaDoc komentářů je dobré už od začátku dbát na kvalitu a výmluvnost, pokud je u funkce setScale popisek Sets scale, tak to asi nikomu nepomůže. Je vhodné se při psaní inspirovat strukturou a způsobem vyjadřování v dokumentaci k JDK (resp. inspirovat se MSDN).

K tisku jsme měli připravených cca 50 stran povídací programátorské dokumentace, do které jsme chtěli doplnit JavaDoc dokumentaci důležitých tříd (převedenou pomocí Doxygenu do latex formátu). Nechali jsme to na poslední večer před tiskem s tím, že vygenerované soubory jednoduše upravíme a přiložime. Co k tomu říct… po shlédnutí vygenerovaných souborů bylo jasné, že neupravíme a přiložíme jen v html podobě na odevzdaném CD. Proto bych rád upozornil všechny, kteří počítají s tím, že poslední den vygenerují programátorskou dokumentaci z komentářů v kódu, aby si to raději napřed vyzkoušeli a pak počítali ještě jednou.

O prezentaci

K prezentaci je nejdůležitejší vědět, že 30 minut včetně proslovu oponenta, vedoucí a diskuse je strašně krátká doba. Je dobré počítat s tím, že na proslovy a diskusi minimálně 10 minut padne, proto je lepší prezentaci plánovat na 15 minut (s tím, že před komisí se vaše prezentace možná mírně protáhne).

Cílem prezentace není předvést všechna okna v projektu a kompletně popsat jeho API, ale ukázat, co jste vlastně udělali a čím to je zajímavé, na technické detaily je programátorská dokumentace. Cílem je porotu zaujmout a přesvědčit ji, že váš projekt je super, ne ji ze začátku uspat a doufat, že se jí bude zdát něco pěkného a nechá projekt obhájit.

Před odevzdáním projektu si zajděte alespoń na jedny obhajoby a sledujte, co týmy při prezentaci dělají a jak na to komise reaguje, snažte se pochytit, co se komisi nelíbilo, proč a takového jednání se při vlastní prezentaci vyvarovat.

Také se zkuste předem zamyslet nad tím, na jaké dotazy by se vás komise a ostatní účastníci obhajob mohli ptát a připravte si na tyhle dotazy odpovědi. Schopnost pohotově odpovědět určitě udělá na všechny dobrý dojem.

O projektech obecně

Softwarový projekt pro mě byl zajímavá zkušenost,ale myslím si, že svůj hlavní cíl – totiž naučit studenty týmové práci na větším softwarovém díle neplní. O tom, jak (ne)má probíhat vývoj projektu ve více lidech jsem se během několika měsíců zaměstnání v nejmenované softwarové firmě dozvěděl mnohem víc. Na druhou stranu práce na projektu dobře posloužila pro vyzkoušení si některých extrémních programovacích praktik a praktické ověření jejich oprávněnosti.

Souvisejícím problémem projektů je, že zajímavé a bohaté na zkušenosti jsou maximální první dva měsíce a potom až poslední měsíc (první dva jsou pro ty, kteří ještě nic podobného nedělali a v posledním se naučí se pracovat ve stresu a organizovat si práci podle priorit a zbývajícího času). Zbylý čas se jen datluje kód s vyjímečně nízkou bodovou dotací, aby se splnily požadavky na velikost díla, ale nic nového tím nezískává. Čas, který to zabere by šel strávit mnohem lepším způsobem na jiných přednáškách, nebo praxí v nějaké firmě, která je jednak poučnější a jednak mnohem lépe ohodnocená.

Dost často u projektů totiž chybí vedení, který by tým směrovalo ke správným postupům a díky kterému by týmy nemusely hledat vhodná řešení organizace práce metodou pokus-omyl. A z obhajob různých minulých projektů jsem míval pocit, že některé týmu zůstaly u omylu až do úplného konce.

Pokud by projekt měl skutečně sloužit k výuce týmové práce, myslím, že by bohatě stačilo, kdyby se na něm pracovalo jen jeden semestr, ale o něco intenzivněji a pod větším dohledem ze strany lektorů (vedoucích projektů), kteří by byli schopni do projektů zasahovat a včas upozorńovali na chyby. To se v současném systému neděje a stává se, že první skutečnou zpětnou vazbu tým dostane až při obhajobě – a to není to nejlepší místo na zjištění, že něco je špatně. Pak je jasné, že není něco špatně jen v projektu, ale v celém systému, který nechá takový projekt rok nebo dva bez zásahu probíhat.

Druhou možností jsou softwarové projekty zadávané firmami, za které by byli studenti placeni a měli tak alespoń nějakou motivaci k tomu, aby se věnovali i těm méně zajímavým aspektům projektu. O zpětné vazbě zadavatele, kterému skutečně záleží na výsledku ani nemluvě.

Závěrem

Nemyslím si, že by softwarové projekty byly zbytečné a nebo že by se měly rušit, na druhou stranu jejich současná koncepce vede k velkému plýtvání časem řešitelů, a že by lépe motivovaný (finančně/bodově/…), nebo kratší – ale o to intenzivnější – zážitek pro budoucí praxi posloužil mnohem lépe.

Po poněkud chudším lonském ročníku se letos naštěstí podařilo sehnat dostatek peněz od sponzorů a to se znatelně odrazilo na materiálním zajištění akce (čti zdarma byly nejen kola a bagety, ale i chipsy a nealko na baru:)). Drobnost, ale potěší.

Organizátoři začátkem roku operovali i s finančními odměnami přednášejícím, což by mělo na akci přivést odborníky a zkušené přednášející a ve výsledku vést ke zvýšení kvality přednášek, jestli k odměńování skutečně došlo ale nevím. Osobně jsem měl dojem, že se proti lońskému roku kvalita přednášek spíš snížila. V žádném případě nechci zpochybńovat odbornost přednášejících, přednes některých z nich ale kritiku zaslouží v každém případě. To, že přednášející svůj příspěvek předčítá v sedě monotonním hlasem z papíru je pro mě až neuvěřitelné. Dalším a častějším nešvarem bylo nadužívání cizích slov, zvlášť v přednášce o dvou pohledech na level design to působilo dost komicky (aspoń se tím vyvážil nestravitelný přednes přednášejícího, který svůj příspěvek pravděpodobně na pódiu viděl poprvé); díky zvláštnímu a těžko zaměnitelnému způsobu vyjadřování si dokonce jeden z přednášejících hned v prvních pár minutách vysloužil přezdívku Aštar Šeran.

To, že většina přednášejících neměla zkušenosti s vystupováním před publikem a jejich hlasový projev tomu odpovídal je na akci tohoto typu pochopitelné, hůř pochopitelné a odpustitelné ale byly místy velké mezery v přípravě přednášejících. Že by prezentované aplikace měly být na promítací počítač nainstalovány předem považuji za samozřejmost, vhodné by bylo předem připravit i všechny příklady a při prezentaci je jen spouštět – pokud není hlavním tématem práce ve vývojovém prostředí, tak psaní kódu během prezentace zdržuje a odvádí pozornost od řešeného problému. Navíc tak můžou vzniknout nečekané problémy, které dost kazí celkový dojem z prezentace (zdravím Rezńu a jeho jinak zajímavou přednášku o SOAPu). Mělo by platit i to, že všechno, co chce přednášející předvést by mělo být připravené na slajdech, a na nich jen upozorńovat na důležitá místa. Pokud budou po skončení akce předváděné příklady ke stažení, posluchači o nic nepřijdou a z přednášky vypadnou hluchá místa.

Na znalosti přednášejících si ale v žádném případě stěžovat nešlo (jen mi nesedí to, že zvířata si hrají jen tak bez nějakého dalšího účelu, to podle mě fakt je nesmysl), jen mě mrzí, že na některých z těch lépe hodnocených přednášek jsem nebyl a ta nejočekávanější se vůbec nekonala, tak za rok snad.. Ale což, cesta Brnem pro Memova pravopisná pravidla za to stála.

Nejdůležitější na GDS stejně je sociální interakce vývojářů v Brněnských restauračních zařízení, tomu byly věnované oba večery, noci a rána, ale i celý nedělní program. Díky tomu se mi podařilo aspoń částečně nahlédnout do tajů univerza Mathery od Aštara (jmenuje se sice Jirka, ale tak mu už české hry asi říkat nikdy nebudou) a po dlouhé době si zahrát Jungle speed ve víc lidech.

Sociální interakce v hospodě letos nově nahradila nedělní workshopové dopoledne. Na jednu stranu bylo dobré, že všichni seděli v jednom sále u svojich sklenek a mohli se volně pohybovat a bavit, na druhou stranu je mi klasického (organizovaného) pojetí workshopů trochu líto: workshopy umožńovaly řešit konkrétní problémy, výhodou bylo i to, že na ně obvykle přišlo menší množství lidí, takže problém bylo možné řešit odbornou diskusí všech účastníků. Při klasickém pojetí měl (aspoń podle mého názoru) vedoucí workshopu i jeho potenciální účastníci předem čas na přípravu, čímž se kvalita dostala do jiné roviny, než při neplánované diskusi. A kromě toho přiznávám, že restaurace, kde se nedělní část konala, a její obsluha mi nesedly a doufám, že příště snad půjdeme jinam.

Co říci závěrem? Že se akce vydařila a splnila všechna očekávání, některá dokonce předčila. Staré známé jsem potkal, poznal několik nových a konečně osobně poznal další lidi, které jinak znám jen jako nick z IRC, pivo i kofola tekly proudem a atmosféra jiskřila nápady a dobrou náladou. Už se těším na rok 2007.

Velká výzva – proto, když mě pcmaster pozval, abych se zničením hlavního počítače matrixu pomohl jeho elektrotechnickému týmu, jsem neváhal a rychle souhlasil. Moje šance na sestavení vlastní skupiny a úspěšný útok na registrační formulář byly v té době už nulové, tak proč ne.

Akce začala nečekaně promítáním sestříhu scén z filmů – některé se jim dokonce podařilo vylepšit citlivou změnou dabingu, nebo hudby na pozadí. Zřejmě se ale organizátorům podařilo dostat do filmu nějakou podprahovou informaci, protože už během promítání většina lidí kino opustila a vydala se směrem do Stromovky. Právě tam začínala první část hry, která nás později zavedla přes Letnou, Malou Stranu a Staré Město a k ránu až do lesů na jihu města. Hra, díky které jsme získali zajímavé nové zážitky a poznali nové pocity.

Pocit překvapení, když jsme z hecu nadiktovali pcmasterovu otci do telefonu text šifry a on nám přeříkal nazpět překlad z maďarštiny: “Milí řešitelé, pro moudré lidi jako jste vy jistě překlad nebyl žádný problém….”

Pocit beznaděje, když jsme už půl hodiny hledali ukrytý server Matrixu a nemohli ho najít. Věřte, že jsme pečlivě prohlédli opravdu každý kanál v okolí i všechna sklepní okna budovy.

Pocit uspokojení, když jsme ho potom našli v okně v prvním patře, pod kterým jsme předtím nejméně desetkrát prošli, a když se nám podařilo úspěšně po písmenkách opsat sekvenci tohoto serveru.

Pocit strachu a nejistoty, když se k nám po zapsání sekvence vydaly ze stínů dvě tajemné postavy. Jsou to G-agenti matrixu kteří nás chtějí obrat o šerpy reprezentující ve světě Matrixu životy? Nebude lepší pokusit se o útěk?

Pocit úlevy, když jsme zjistili, že se jedná jen o tajné policisty, kterým (pravda, celkem oprávněně) přišlo naše chování podezřelé a přišli nás zadržet. Sláva, šerpy nám zůstaly.

Pocit stresu, když nám operátorka Matrixu řekla, že máme dvě minuty na to, abychom zvedli telefon v budce na Újezdě a my jsme nevěděli kde a která to je.

Pocit zimy a ospalosti o páté ráno.

Pocit radosti, když jsme si přečetli, že jsme se dostali do druhé části.

Pocit znechucení z toho, že jakási hyena v lidském těle krade po cestě šifry, aby zablokovala postup dalším týmům.

Vítězný pocit po hladkém dokončení trasy ve druhé části a nalezení šifrovacího kroužku.

Zoufalý pocit bolesti nohou otalčených v botech po dvaceti hodinách pochodování.

Pocit zadostiučinění potom, co jsme po ukončení hry polohu klíčníka vyluštili jen se dvěma šifrovacími válečky, přestože organizátoři mluvili o třech jako o minimu.

Hlavní ale byl krásný pocit z skvěle vymyšlené a dobře provedené akce. Sláva organizátorům a jen doufám, že se Matrix přeci jen zničit nepovedlo a tato akce bude mít pokračování.