Modul pro stahování dat s autentizací

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

BAKALÁŘSKÁ PRÁCE

Modul pro stahování dat s autentizací

Petr Škoda

Prosinec 2007

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

2

Shrnutí Tato práce se zabývá systémy pro kontrolu stahování souborů z webových stránek, obvykle realizovaných jako formuláře pro vyplnění uživatelských údajů. Do větší hloubky je rozebírána problematika způsobu získání informací od uživatele a rozlišení člověka od stroje v prostředí internetu. Dále je čtenář seznámen se systémem pro podporu řízení softwarových projektů Trac a s možnostmi jeho rozšiřování zásuvnými moduly. Nakonec, po přiblížení již existujících zásuvných modulů pro podporu stahování souborů v tomto systému, se práce zabývá novým modulem pro podporu stahování s kontrolou a statistikami, který se jmenuje TracDownloader. V praktické části byl podle požadavků zadavatele vytvořen nový zásuvný modul pro systém Trac, který umožňuje kontrolu stahování nabízených souborů, pohodlnou administraci a správu posbíraných dat společně se zobrazováním statistik o stahování. Tento modul se snaží dosáhnout co nejvyšších kvalit v závislosti na teoretických poznatcích popsaných v této práci.

Klíčová slova stahování souborů, kontrola stahování souborů, získávání informací od uživatele, statistiky, CAPTCHA, zásuvný modul, plug-in, Trac, TracDownloader

3

Obsah Kapitola 1

Úvod

5

Kapitola 2 Stahovače s formulářem 6 2.1 Přístupy ...................................................................................................................... 6 2.2 Zamezení stahování roboty ........................................................................................ 8 2.3 Zhodnocení............................................................................................................... 10 Kapitola 3 Systém Trac 12 3.2 Trac wiki ................................................................................................................... 13 3.3 Databázové pozadí.................................................................................................... 14 3.4 Python....................................................................................................................... 14 3.5 Trac API.....................................................................................................................15 3.6 Zásuvné moduly ....................................................................................................... 16 Kapitola 4 Existující stahovače 19 4.1 Přílohy wiki stránek (attachments) .......................................................................... 19 4.2 TracDownPlugin....................................................................................................... 19 4.3 DownloadsPlugin .....................................................................................................20 Kapitola 5 Zásuvný modul Downloader 21 5.1 Hlavní body specifikace............................................................................................ 21 5.2 Pro a proti začátku na zelené louce .......................................................................... 22 5.3 Organizace souborů.................................................................................................. 23 5.4 Formulář před stažením souboru............................................................................. 26 5.5 Zamezení stahování roboty ...................................................................................... 29 5.6 Způsob poskytnutí souboru...................................................................................... 31 5.7 Zpřístupnění souborů pomocí wiki .......................................................................... 32 5.8 Konfigurace .............................................................................................................. 32 5.9 Statistiky ................................................................................................................... 34 5.10 Další vývoj Downloaderu..........................................................................................38 Kapitola 6

Závěr

39

Literatura

40

Přílohy 42 Příloha A – datový model systému Trac............................................................................... 42 Příloha B – úplná specifikace zásuvného modulu Downloader .......................................... 43 Příloha C – form_data.py – definice formuláře před stažením souboru............................. 45 Příloha D – všechna nastavení zásuvného modulu Donwloader ........................................48

4

Kapitola 1

Úvod Stahování dat z internetu je pro většinu z nás každodenní samozřejmostí. Nezáleží na tom, jestli se jedná o video, hudbu, obrázky, programy či pouhé „surfování“ po internetu, které je ve své podstatě také jen stahování dat. Existuje mnoho a mnoho dalších způsobů, jak získávat obsah z internetu, je to služba elektronické pošty stejně jako desítky výměnných sítí. Stahujeme prostě neustále. Aby bylo co stahovat, musí data na internetu někdo také vystavovat a tím je nabízet. Nejběžnějším způsobem je pravděpodobně poskytování obsahu pomocí webového serveru jako je Apache či IIS (Internet Information Service – webový server od společnosti Microsoft). Jedná se o metodu, kdy jsou informace vlastně veřejnými, tedy může je stáhnout potenciálně kdokoliv, kdo zná jejich adresu. Jakmile je adresa dat, obvykle souboru, někde k dostání, mohou být tato stažena a obsluha celé události je plně v režii webového serveru. Ten samozřejmě většinou dokáže řídit přístup k jednotlivým adresářům či souborům pomocí rozličných metod autentizace, stejně tak dokáže sbírat spoustu zajímavých informací o klientovi, který daný obsah stahuje, to ovšem vždy nemusí stačit. Obzvláště na poli vývoje aplikací si často přejeme získat o stahujícím zcela jiné informace než ty, které umí automaticky zaznamenat webový server. Případně je pro nás nežádoucí, aby byl nějaký soubor stažen roboty, přitom však chceme aby obsah zůstal co nejvíce dostupný lidskému uživateli. To vylučuje těžkopádné metody autentizace a autorizace pomocí webového serveru. Tato práce se zabývá systémy pro kontrolu stahování souborů z webových stránek. Do větší hloubky potom postihuje tuto problematiku v souvislosti se systémem správy a řízení softwarových projektů Trac [1]. Nejprve je rozebrána problematika „stahovačů s formulářem“ (tímto výrazem bude v dalším textu označován systém pro poskytování souborů, který nutí uživatele vyplnit před stažením nějaký dotazník), jejich využití a techniky které je možné použít k získání dodatečných informací od uživatele. V další části je čtenář seznámen se systémem pro správu a řízení projektů Trac. Především s jeho vnitřní filosofií, API (application programming interface – rozhraní pro programování aplikací) a v neposlední řadě také s možnostmi rozšiřování tohoto systému zásuvnými moduly. Kapitola 4 potom stručně seznamuje s již existujícími zásuvnými moduly pro podporu stahování v systému Trac. Poslední a nejvýznamnější částí práce je kapitola o zásuvném modulu TracDownloader [2], který byl vytvořen na základě poznatků vyvozených z předcházejících kapitol.

5

Kapitola 2

Stahovače s formulářem Když se blíže podíváme na možnosti sběru informací webovým serverem, velice rychle zjistíme, že takto získané údaje v celku nic neříkají o tom, kdo je zájemcem o námi poskytované soubory. Webové servery totiž mohou o příchozím uložit pouze ty údaje, které jim předá jeho webový prohlížeč (dále jen prohlížeč) – jedná se především o internetovou adresu (IP), operační systém, podrobnosti o prohlížeči a HTTP referer [3] (adresa URL odkud klient přišel). Všechny informace předávané prohlížečem viz [4]). Pokud provozujeme internetový portál, nebo jen běžnou internetovou prezentaci jsou pro nás informace získané automaticky od klientova prohlížeče dostačující, případně ve chvíli kdy se chceme dozvědět více, použijeme dobrovolnou anketu. Tu sice nevyplní každý příchozí, ale z velkého počtu návštěvníků získáme reprezentativní vzorek informací. Situace není tak jednoduchá se soubory nabízenými ke stažení. Stáhnout soubor si klient často přijde z nějakého externího odkazu (odkaz, který není na našem webu), v mnoha případech dokonce vede odkaz přímo na požadovaný soubor, potom je dobrovolná interakce s uživatelem (třeba anketou) v podstatě nemožná. Musíme tedy zavést nějaké řízení poskytování souborů ke stažení.

2.1

Přístupy

Dvojité přesměrování Běžným způsobem, jak zajistit, aby člověk, který stahuje soubor navštívil i stránku k němu patřící je dvojité přesměrování. Tato strategie však není stahovač s formulářem, zařadil jsem ji sem, protože se snaží dosáhnout podobných cílů. Realizuje se tak, že na stránce souboru je odkaz, který vytvoří nové okno prohlížeče. V něm se provede přesměrování přímo na soubor (toto okno většina prohlížečů zase zavře, jakmile zjistí, že se jedná o soubor ke stažení). Původní okno je mezitím přesměrováno na jinou stránku, kde se obyčejně nachází odkaz zpět na stránku daného souboru a reklamy. V případě absence JavaScriptu je původní odkaz přesměrován přímo na soubor. Díky tomuto postupu je každý uživatel nucen navštívit nejprve stránku souboru a až poté jej může stáhnout. Přímá adresa na soubor se totiž nikdy nezobrazí na žádné stránce jako odkaz, ani není použita v žádném okně prohlížeče jako adresa (jediné okno s touto adresou prohlížeč sám zavře), takže kdokoliv chce odkazovat na takový soubor může použít buď adresu s reklamou a odkazem na původní stránku souboru, nebo přímo stránku souboru. 6

Tento postup je využíván hlavně na webech nabízejících velké množství cizích souborů ke stažení. Tyto portály jako www.downloads.com nebo český www.stahuj.cz se živí především reklamou, kterou tímto způsobem dostávají k uživatelům. Nepovinný formulář Velké firmy, které poskytují své programy nebo ovladače ke stažení a to ať se jedná o plné verze nebo ukázkové, obvykle před stažením souboru nabízejí k vyplnění krátký někdy i delší dotazník, jehož vyplnění však není podmínkou k umožnění stažení souboru. Technicky je tato varianta řešena skriptem na straně serveru, který posílá jako odpověď na požadavek klienta o soubor stránku s formulářem, do chvíle kdy je formulář uživatelem odeslán. Takže všechny požadavky na soubor mají stejnou URL, ovšem soubor je poskytnut pouze za předpokladu, že byl před tím odeslán formulář (nemusí přitom být vůbec vyplněný). V dotazníku tohoto typu bývají otázky jako za jakým účelem klient soubor stahuje, případně v jaké firmě je zaměstnán, jaká je jeho pozice ve firmě a podobně. Nakonec může být přidán ještě dotaz na e-mailovou adresu uživatele a výběr informací, které si přeje od poskytovatele souboru získávat elektronickou poštou. Povinný formulář Poslední variantou je umožnit stažení souboru, jen uživateli, který vyplní formulář požadovaným způsobem. Po této možnosti nejčastěji sahají tvůrci aplikací zaměřených na úzké spektrum uživatelů, případně poskytovatelé všemožných datových balíků. Tyto soubory sice nabízejí veřejně, ale chtějí mít přehled o tom, kdo a jakým způsobem je používá, protože díky takové interakci mohou zvažovat například další vývoj daného produktu nebo jeho komerční nasazení. Nejčastěji poskytovatel souboru žádá po uživateli jeho skutečnou (validní) e-mailovou adresu. Může to být z různých důvodů. Jedním z nich je možnost informovat uživatele o novinkách, případně rozesílání jiných sdělení. Můžeme rozlišit několik způsobů ověření pravosti adresy elektronické pošty [5]: • regulárním výrazem – Jedná se o nejjednodušší způsob a jako takový je také nejméně účinný. V praxi se užívají různé složitosti tohoto výrazu, nicméně ne všechny poštovní servery jsou implementovány přesně podle normy a tak s konkrétností regulárního výrazu roste riziko zamítnutí funkční adresy [6]. Výhodou této metody je, že nepotřebuje provádět k ověření adresy žádné síťové (vzdálené) operace, díky čemuž je spolehlivá ve smyslu výpadků a především rychlá, takže uživatel nemusí dlouho čekat na odpověď. • kontrola existence domény pomocí DNS (Domain Name System – hierarchický systém doménových jmen [7]) – Touto metodou zjistíme, jestli vůbec existuje doména, na které by měla daná poštovní schránka být umístěna. Kontrola se prove7

de dotazem podobným jako provádí nslookup (program umožňující jednoduše zadávat DNS dotazy serverům poskytujícím tuto službu), případně je provedena přímo tímto programem. Tato kontrola by měla být provedena až po úspěšném ověření pomocí regulárního výrazu a k jejímu provedení je nutné oddělit doménovou část emailové adresy (vše vpravo od znaku zavináče). Tato metoda je spolehlivější, než předchozí, nicméně stále je možné zadat adresu na doméně, která je sice registrovaná, ale neexistuje pro ni žádný poštovní server. • kontrola MX (mail exchange) záznamu domény – Mail exchange je jeden ze záznamů, které mohou být uvedeny v zónovém souboru domény (jakýsi balík záznamů, které DNS systém zná o dané doméně [7]) . Tento záznam obsahuje adresu serveru, který se stará o příjem elektronické pošty domény. Kontrola MX záznamu může být realizována podobně jako předchozí kontrola pomocí programu nslookup. Výhodou je, že po této kontrole skutečně víme, že e-mail bude přinejmenším zpracován serverem příchozí pošty na doméně z které adresa pochází. Ani tato kontrola však nezaručí, že zadaná poštovní schránka skutečně existuje. • ověření odesláním e-mailu a následným potvrzením – Především kvůli spamu většina domén neumožňuje ověřit existenci konkrétní poštovní schránky. Jedinou naprosto spolehlivou metodou proto zůstává poslat na ověřovanou adresu zprávu s tajemstvím, které bude muset uživatel zadat před stažením souboru, případně může zpráva obsahovat odkaz, který zajistí zaznamenání validity poskytnuté adresy. Tento postup umožňuje získat skutečně funkční e-mailovou adresu a ještě k tomu je to adresa právě toho uživatele, který požaduje náš soubor. Stinnou stránkou je, že tímto způsobem uživatele nemálo zdržíme, navíc mu zpráva může dorazit až po delším čase, což ho může zcela odradit od stahování. Dále v mnoha případech poskytovatel souborů požaduje vyplnění různých částí dotazníku, jako označení některých výběrů, nebo vyplnění textových polí určitým způsobem. Pro ověření textových polí se nejčastěji nasazují regulární výrazy, ověření „zaškrtávátek“ a výběrů je programátorsky triviální.

2.2

Zamezení stahování roboty

Asi každý uživatel internetu se již setkal se spamem. Tento fenomén dnešní doby se po internetu neustále šíří a obtěžuje jeho uživatele. Navíc opatření proti němu jsou náročná, drahá a někdy skoro stejně obtěžující jako samotný spam. Jedním z často používaných postupů proti spamu je dobře známý obrázek se zdeformovaným, nebo jinak porušeným textem, který musí uživatel opsat do pole formuláře. Tyto „obrázky“ se poprvé objevily kolem roku 2001 pravděpodobně na portálu AltaVista k zamezení automatického zadávání URL do seznamu stránek k indexování a zhruba ve stejnou dobu je použil i portál Yahoo ve své chatovací službě proti automaticky zadávaným 8

inzerátům a reklamám. [8] [11] Pro postup odlišení člověka od stroje pomocí obrázku s textem vymyslela čtveřice autorů zabývající se touto problematikou název CAPTCHA, což je akronym pro sousloví Completely Automated Public Turing test to tell Computers and Humans Apart – „plně automatický veřejný Turingův test k odlišení počítačů a lidí“. Jako CAPTCHA jsou klasifikovány i jiné testy, které mají za cíl odlišit roboty od lidí. Hlavním kritériem je skutečnost, že test musí být automaticky generovaný strojem, ale rozluštitelný výhradně pro člověka [9]. Druhy testů CAPTCHA • klasický obrázek s textem – Nejčastěji používaným je dle mého soudu test s poškozeným textem na obrázku. Tento test je velice oblíbený, ačkoliv obtížnost jeho realizace i nároky na hardware nejsou zrovna minimalistické. Jeho rozšířenost také nutí výrobce spamu k vylepšování technologií OCR (Optical Character Recognition – optické rozpoznávání znaků), kvůli čemuž je nutné vytvářet čím dál víc znečitelněné obrázky, které někdy potrápí i lidského čtenáře. Například původní zvlněné nebo zakroucené texty (první nápis vlevo na obr. 1) jsou dnes již ve většině případů čitelné roboty a proto je nahrazují jiná poškození. Efektivní je zatím metoda přeškrtávání čárami (obr. 2), ovšem zdá se mi, že i ta bude mít brzy odzvoněno. Jako další ztížení pro stroje se objevily různě přerušené znaky v textu, čímž stroj často ztratí možnost rozeznat hranice jednotlivých znaků a přesto je zachována poměrně příjemná čitelnost člověkem (obr. 3).

Obr. 1: Vlevo ukázka jednoduché deformace z nástroje Gimpy [10], vpravo tři obrázky s pospojovanými znaky k zabránění jejich rozlišení počítačem.

Obr. 2: Přeškrtnutý text.

Obr. 3: Text s přerušenými znaky.

• vylepšený klasický obrázek s textem – reCAPTCHA – Tato metoda je ve své podstatě shodná s metodou předchozí. Vylepšení je založeno na úvaze: „Proč nevyužít výpočetní sílu lidí k řešení úloh příliš obtížných pro počítač?“ Knihovny po celém světě se snaží digitalizovat co nejvíce starých knih, přičemž jejich snímání do formy 9

počítačového obrazu je jen prvním krokem. Velké úsilí je věnováno přeložení knih do počítačového textu, k tomu slouží již míněné OCR programy. Tyto programy samozřejmě nedokáží přečíst každé slovo, protože texty v knihách bývají různě poškozené. Zde se objevilo možné využití obrázků pro rozlišení člověka od stroje. Princip je prostý: Vezme se část textu, která byla úspěšně rozpoznána pomocí OCR a přidá se jiná část, která rozpoznána nebyla. Obrázek se předá člověku jako test a pokud člověk správně opsal známou část, předpokládáme, že správně opsal i neznámou (neznámé slovo se nechá přečíst vícekrát, tím se zabrání lidské chybě). Obě části textu musejí být znečitelněny a nesmí být rozlišitelné, kterou část počítač již zná a kterou ne. [12]

Obr. 4: Tři ukázky reCAPTCHA.

• obrázek – Jedná se o obrázek s geometrickými tvary, případně jednoduchými kresbami. Uživatel je následně tázán na nějakou otázku týkající se obrázku (jakou barvu má trojúhelník). Na první pohled je tento postup výborný, žádná hrozba jako je OCR pro předchozí postupy. Problém je však v automatickém generování otázek, počítač totiž sám moc jasně neví, co na daném obrázku je a už vůbec neumí snadno sestavit smysluplnou otázku. Otázek proto obvykle bývá jen pár typů a tím vzniká riziko naučení automatu většiny možných otázek a jejich odpovědí. Takový automat by pak s určitou úspěšností ochranu prolamoval. Právě kvůli problematickému generování testů není tato metoda vždy označována jako CAPTCHA. • dětská matematika – Ověřit přítomnost člověka na druhé straně linky můžeme také zadáním prostého matematického příkladu, jako je sčítání, odčítání, násobení a dělení malých čísel. Ideje rozpoznání spočívá v neschopnosti stroje správně pochopit zadání úlohy. Tento test je výpočetně i implementačně poměrně jednoduchý, lze realizovat i bez generování obrázku. Nedostatkem však je, že rozsah možností automatického generování těchto testů je slabý podobně jako v předchozím případě, tedy nejsme schopni dosáhnout miliard možných otázek, ale pouze stovek až tisíců.

2.3

Zhodnocení

Stahovače s formulářem jsou obvykle jedinou možností, jak se dozvědět více informací o zájemcích o poskytované soubory. Každá z popsaných variant vyhovuje jinému důvodu na10

sazení. Poskytovatel souborů musí vždy důkladně zvážit jak únosné je „obtěžování“ zájemce o soubor tak, aby nebyl odrazen ještě dříve, než soubor získá. V případě sběru většího množství citlivých informací by nemělo být zapomenuto přidat k formuláři také zdůvodnění sběru těchto údajů a poznámka o jejich využití.

11

Kapitola 3

Systém Trac Trac je minimalistický webový systém pro řízení a sledování událostí při vývoji softwarových aplikací. Je velice dobrým pomocníkem při tvorbě OpenSource, ale i jiných projektů. I Trac sám je OpenSource, díky tomu je velice adaptabilní a existuje k němu obrovské množství zásuvných modulů. Hlavními součástmi Tracu jsou systém wiki stránek, systém ohlášení (tickets) a velice precizní propojení se systémem pro řízení verzí Subversion. Wiki umožňuje jednoduše odkazovat na většinu interních entit, jako jsou jednotlivá ohlášení, nebo revize (ucelená funkční úprava zdrojového kódu v Subversion). [13] V porovnání s jinými podobnými systémy pro řízení projektů, je Trac nejvíce odlišný filozofií známou z wiki, která je v něm aplikována téměř všude. V podstatě jde o to, že kdokoli kdo má přidělena správná oprávnění může v každém okamžiku změnit skoro cokoli. Výhodou tohoto přístupu je, že není třeba složitě řešit role jednotlivých vývojářů, či vstupovat pro úpravy některých věcí do administračního režimu, prostě má-li člověk co dodat či vylepšit, může to udělat hned. [13] Dále se v této kapitole zaměřím hlavně na vnitřní části systému, protože především ty souvisejí s mojí prací s Tracem. Pohled pod kůži Trac sám o sobě je naprogramován v jazyce Python a ke svému chodu využívá několika dalších nástrojů. Nejhlubší pozadí tvoří databáze a to buď SQLite, Postgre SQL nebo MySQL. Část nejbližší k uživateli zatím tvoří ClearSilver, velice rychlý a silný systém šablon, v dalších verzích pak systém šablon Genshi. Současnou verzí je Trac 0.10, jeho API se od předchůdce Trac 0.9 liší vesměs v několika maličkostech, nicméně API verze 0.10 je zase o něco lepší a pro programátory příjemnější k používání. [14] Budoucností je verze 0.11, která se blíží prvnímu plnému vydání. Tato verze je v celku přelomová, k jejímu vytvoření bylo vynaloženo obrovské úsilí a množství změn v API (za zmínku stojí předělání práce s časem tak, aby byl reprezentován podle zvyklostí na straně uživatele) společně s nahrazením nadále nevyhovujícího systému šablon ClearSilver za systém Genshi v podstatě zaručuje naprostou nekompatibilitu s jakýmikoli zásuvnými moduly z minulých verzí (ClearSilver je ještě ve verzi 0.11 podporován pro snazší přechod zásuvných modulů na tuto verzi) . Světlou stránkou věci je, že změny v API byly provedeny skutečně cit-

12

livě a přinášejí spoustu nových možností a tak je námaha tvůrců zásuvných modulů vynakládaná k portování jejich děl pro Trac 0.11 snad i trochu příjemnou prací. [15]

3.2

Trac wiki

Již zmíněná součást, systém wiki, je hned po systému ohlášení (ticket) nejdůležitější a nejužitečnější pomůckou v Tracu. Hlavním cílem používání wiki při správě projektů je poskytnout co nejsnazší cestu a dodat odvahu k přispívání do projektu jak členům týmu, tak širokému okolí, jako jsou betatesteři ale i běžní uživatelé. Způsob tvorby a úpravy stránek proto musí být co nejsnazší a nejpřímočařejší. Díky tomu, že lze přes wiki snadno odkazovat na ohlášení, revize a sady změn (change sets), je pro každého uživatele také snadné vytvářet reporty či informační stránky přesně podle aktuálních potřeb. [16] Trac používá svoji vlastní sadu wiki značek, je to běžný jev s ohledem na to, že celý wiki systém je v Tracu implementován na zelené louce. Vlastní sada značek má tu výhodu, že jsou poskytovány právě ty značky, které jsou třeba a používají se, tím je celý systém přehlednější. Nepříjemné je, že projekty mohou přecházet na Trac z jiného systému wiki, tím přibývá zbytečná práce s přeformátováváním. Naštěstí existují převodní filtry do Trac wiki z fromátů MediaWiki (formát užívaný wikipedií) a MarkDown (formátování zaměřené na co nejpříjemnější čitelnost v prostém textu). [16] Nesmíme také zapomenout, že aby wiki fungovala správně a informace v ní uložené nepodléhaly neodborným úpravám, je nezbytné evidovat všechny změny provedené na jednotlivých stránkách. Trac tuto funkcionalitu samozřejmě podporuje a to velice příjemným způsobem. Seznam změn na stránce je zobrazován ve stejné formě jako seznamy změn provedených ve zdrojových kódech programů z repozitáře Subversion daného projektu. To má hned dva příjemné efekty: za prvé shodný způsob výpisu podporuje snadnou orientaci uživatele, za druhé způsob výpisu rozdílů v Tracu považuji za přehlednější a obecně lepší, než jaký používá třeba Wikipedie. Další užitečnou pomůckou je možnost rozšíření wiki syntaxe přímo v jednotlivých zásuvných modulech. Tím se dá docílit maximální uživatelské přívětivosti i v externích součástech Tracu. Představme si, že máme zásuvný modul kalendáře, který umí zaznamenávat úkoly. Každý úkol má vlastní ID. Potom se jeví jako ideální vytvořit wiki syntaxi, která bude umožňovat jednoduchou tvorbu odkazů na jednotlivé úkoly jen prostým zadáním ID, v praxi může zápis ve zdrojovém kódu wiki vypadat například takto: „cal:65“. Podle implementace wiki syntaxe našeho imaginárního kalendáře může být tento výraz při vykreslování nahrazen třeba názvem události s časem jejího začátku nebo jiným o ní známým údajem. Všechny zmíněné možnosti wiki napomáhají k neuvěřitelně jednoduchému vytváření jakýchkoli informačních stránek, reportů, nebo návodů v prostředí Tracu s využitím všech jeho součástí – interních i externích.

13

3.3

Databázové pozadí

Jak již bylo zmíněno, Trac podporuje tři databázové systémy jako své pozadí pro ukládání dat. Každý z těchto systémů však má jiné schopnosti, protože implementace dotazovacího jazyka SQL (Structured Query Language – strukturovaný dotazovací jazyk používaný pro komunikaci s databází) se skutečně liší systém od systému. První komplikací plynoucí z různorodosti databázového pozadí je již samotné vytváření nových tabulek. Různé databázové systémy mají totiž obvykle různě pojmenované datové typy z čehož nejzáludnější je užití takzvaných sekvencí (v MySQL a SQLite auto increment). Použití sekvencí je praktickou pomůckou při přidávání nových řádků do tabulek, jelikož automaticky zaručuje unikátnost primárního klíče v tomto novém řádku, v podstatě se jedná o jedinou rozumnou možnost jak se vyhnout kolizím klíčů v tabulkách, do kterých může v jednom okamžiku zapisovat více uživatelů. Právě způsob používání sekvencí je výrazně odlišný u jednotlivých databázových systémů. Nejvíce vybočuje PostgreSQL, který sekvence ukládá zcela odděleně od tabulek, ke kterým patří, ovšem i MySQL a SQLite mají svá specifika. Z tohoto důvodu musí mít Trac svojí vlastní vrstvu pro vytváření nových tabulek naprosto nezávislou na SQL. Tento způsob přináší svá omezení, na druhou stranu vše co lze vytvořit pomocí této vrstvy v jednom databázovém systému, lze vytvořit a bude správně pracovat i v ostatních podporovaných databázích. Na další problémy narazíme při složitějších databázových operacích. Je proto vhodné mít alespoň částečné povědomí o specifických schopnostech (u SQLite neschopnostech) každého ze systémů. Že je SQLite téměř extrémně jednoduchý databázový systém jsem již naznačil, zdá se mi proto výhodné jej používat při vývoji zásuvných modulů do Tracu jako referenční. Je totiž pravděpodobné, že vše co umí SQLite budou druhé dva databázové systémy, které hodnotím jako výrazně dospělejší, umět také. Doporučuji nahlédnout do seznamu neimplementovaných vlastností SQLite [17]. Možnost použití jednoho z velmi rozšířených databázových systémů (Postgre SQL a MySQL) je rozhodně výhodou, protože na mnoha serverech jsou již před nasazením Tracu používány, tím je zjednodušena instalace Tracu, ale především také usnadněné zálohování (pokud je již nasazený databázový systém zálohován). Naopak podpora SQLite přináší výhody tam, kde jiné databáze nejsou a dokonce ani není možné je nasadit. Navíc SQLite umožňuje rychlé spuštění celého systému jako snadno instalovatelného balíku s minimem konfigurace. A do třetice je také SQLite úsporné a výkonné řešení právě pro skladování ne příliš rozsáhlých tabulek s malým zatížením jako jsou tabulky Tracu.

3.4

Python

„Python je interpretovaný, interaktivní, objektově orientovaný programovací jazyk. 14

Je často přirovnáván k Tcl, Perlu, Scheme nebo Javě.“ [18] Tak je Python uveden na jeho oficiálním webu. Tento jazyk je poměrně oblíbený především mezi uživateli operačního systému Linux, nicméně interprety jsou k dispozici skoro pro všechny platformy. Já osobně vnímám Python podobný hlavně s Javou, především pro to, že používá stejně jako Java bytecode, což je binární reprezentace programu určená ke zpracování virtuálním strojem – interpretem. Bytecode je automaticky vytvořen a uložen do souboru před spuštěním programu v případě, že ještě neexistuje, nebo byl změněn zdrojový kód. Další podobností je práce s moduly, Java sice původně moduly neměla, nicméně analogií modulů jsou v podstatě JAR soubory (archívy obsahující třídy, případně datové soubory), dnes je však i v Javě k dispozici implementace modulů [19]. A poslední významnou podobností, kterou zmíním, je blízký způsob práce s objekty v obou jazycích. Syntaxe Pythonu je pro programátora zvyklého na jazyky typu C mírně neobvyklá, není mnoho jazyků, které k vymezení bloků programu používají různé odsazení. Přesto je tento způsob zápisu, při použití inteligentního textového editoru, velice pohodlný a účinný. Dá se říci, že svojí podstatou nutí programátory k větší kultivovanosti zdrojového kódu a tím větší přehlednosti celého programu. Objektové schopnosti Pythonu jsou rozsáhlé, chybějí však například rozhraní, která by se hodila při definování rozšiřujících míst pro zásuvné moduly. Toto omezení však není zásadní a lze řešit jinými cestami. Python je rozhodně výborný jazyk, který se hodí k velké škále využití. Webové aplikace jsou při tom jen jakousi nepatrnou částí s ohledem na to, že Python podporuje také práci s mnoha systémy grafických uživatelských rozhraní (GUI).

3.5

Trac API

Aby bylo možné systém rozšiřovat podle nejrůznějších potřeb, disponuje Trac vlastním API a na něj úzce navazujícím systémem pro rozšiřování zásuvnými moduly. Nejprve si shrňme proč API a k čemu vlastně slouží. API je rozhraní, které umožňuje programátorovi využívat funkcionalit naprogramovaných jinými programátory, které jsou obvykle součástí nějaké knihovny, nebo v tomto případě přímo aplikace, kterou rozšiřujeme. Základní důvody k používání API jsou dva. Prvním je nutnost vytvoření rozhraní (funkcí a metod) pro práci se součástmi daného systému nebo k využívání funkcionalit poskytovaných nějakou knihovnou. Druhým důvodem je jakési zjednodušení a unifikace práce s vestavěnými funkcemi programovacího jazyka. Příkladem k druhému důvodu může být práce s časem a datem v Tracu. U systému, který je koncipován k použití na různých místech světa je běžným problémem jednak samotná reprezentace času a datumu, stejně tak způsob zadávání těchto údajů a v neposlední řadě práce s časovými pásmy. Pro ulehčení zacházení s časovými údaji poskytuje většina jazyků včetně Pythonu základní (někdy i poměrně pokročilé) funkce. To však nebývá dostačující, pokud je systém používám naráz lidmi z různých částí světa. Právě zde je ideální vystavět vlastní

15

API, které bude jakousi nadvrstvou nad časovými funkcemi jazyka a bude prostě sjednocovat práci s datem a časem v závislosti na uživateli, kterému tyto informace poskytuje, přičemž programátor nemusí ani pomyslet na to, že pro různé uživatele je třeba zacházet s časem jinak. API Tracu poskytuje tyto možnosti (pouze orientační výčet) • Práce s databází. Umožňuje snadno získat připojení k databázi, poslání dotazu do databáze a pohodlnou manipulaci s výsledky dotazů. • Manipulace s konfigurací. Čtení, zápis a implicitní nastavení hodnot v souboru s konfigurací. • Zaznamenávání událostí do logu. • Manipulace s požadavkem na webový server (request) od uživatele. Získávání údajů předaných uživatelem webovému serveru, odeslání odpovědi uživateli, přesměrování a další. • Ovládání komponent grafického výstupu Tracu. Přidání kaskádových stylů (CSS), přidání nových umístění statických dat pro zpřístupnění uživatelům a ovládání šablon pro vykreslení grafického výstupu. • Vytváření fragmentů html kódu pohodlným způsobem. • Nástroje pro manipulaci s datem a časem. • Nástroje pro manipulaci s řetězci v kódování unicode.

3.6

Zásuvné moduly

Zásuvné moduly umožňují rozšiřování systému Trac tak, aby vyhovoval specifickým potřebám různých projektů. Praktické je, že způsob integrace zásuvných modulů z nich v podstatě dělá další součásti zcela rovné nativním komponentám Tracu, ten je sám o sobě také složen ze zásuvných modulů a tato filozofie je s dalšími verzemi čím dál zřetelnější. Základem Tracu je komponentní architektura. Její princip spočívá v tom, že systém tvoří jednotlivé komponenty (jsou to objekty rozšiřující třídu Component). Každá komponenta může využívat (připojovat se k) rozhraní jiných komponent (takzvaná místa rozšíření – extension points) a stejně tak může poskytovat nová místa rozšíření. Místa rozšíření jsou jakési součásti API, takže každý zásuvný modul může touto cestou nabízet své vlastní API. Připojení k místu rozšíření vzniká na základě implementace rozhraní pro něj definovaného. Rozhraní říká, jaké metody musí připojující se třída implementovat, takže komponenta poskytující místo připojení nemusí mít vůbec žádné další informace o připojené komponentě. Poskytující komponenta pak jen pomocí seznamu komponent připojených na dané místo připojení, používá podle potřeby jí známé metody připojených komponent. Seznam připojených 16

komponent je poskytován manažerem komponent (Component manager), což je součást jádra Tracu, která se stará o životní cyklus komponent. [20]

Obr. 5: Komponentní architektura – ukázka propojení komponent a míst rozšíření. [18]

Zajímavá místa rozšíření Tracu • IRequestHandler – umožňuje spustit metodu komponenty v závislosti na dotazu uživatele (adresy URL). • INavigationContributor – místo rozšíření pro komponenty poskytující odkaz do hlavního řádku navigace v Tracu. • IPermissionRequestor – umožňuje komponentě poskytovat akce, které jsou subjektem přidělování oprávnění jednotlivým uživatelům. • ITemplateProvider – umožňuje komponentě poskytovat šablony a statická data. • IWikiSyntaxProvider – umožňuje vytvářet vlastní syntaxe wiki odkazů. • ISearchSource – zprostředkovává další vyhledávání v Tracu, například v datech zásuvných modulů. • IEnvironmentSetupParticipant – implementující komponenta může bezpečně měnit strukturu databáze, změny jsou provedeny aktualizací prostředí. Míst rozšíření existuje mnohem víc, některá další jsou popsána v [21]. Bohužel důkladnější dokumentace Tracu stále chybí a tak programátor často musí vyhledávat jeho možnosti procházením zdrojových kódů. Vydání zásuvného modulu – balíčkování Trac využívá pro zpřístupnění zásuvných modulů ty nejsnazší cesty. V podstatě by stačilo celý Python modul (adresář) zásuvného modulu pro Trac nahrát kamkoliv na takzvanou module path (cesta na které Python vyhledává moduly podle jména). Obvykle je však praktičtější zásuvný modul zabalit do formátu Python egg, což je způsob preferovaný pro všechny zásuvné moduly Tracu. Python egg umožňuje kontrolu závislostí a verzí, automatickou insta-

17

laci závislostí za chodu a přenášení celých aplikací i s jejich daty. Takto lze například zásuvný modul jen nahrát do určeného adresáře v některém prostředí (environment) Tracu a bez jakékoli instalace jej začít používat. V jiném případě je možné balíček jednoduše někam rozbalit (egg je přejmenovaný zip) a přidat jeho cestu do seznamu balíčků zpřístupněných pomocí Setuptools (sada nástrojů zprostředkovávající mimo jiné podporu Python egg). Pak stačí jen povolit spouštění zásuvného modulu v konfiguraci Tracu. [22] Jak sestavit vlastní zásuvný modul, včetně postupu jeho vydání je výborně popsáno v návodu „Jak vařit vejce pro Trac“ (How to cook eggs for Trac) [23]. Asi největším zdrojem již hotových praktických rozšíření všeho druhu pro Trac je web http://trac-hacks.org.

18

Kapitola 4

Existující stahovače Problém poskytování souborů z Tracu byl samozřejmě řešen již jinými autory zásuvných modulů. Nemohu sice říci s konečnou platností, že existují jen dva, ovšem podařilo se mi najít pouze TracDownPlugin [24] a DownloadsPlugin [25]. Nejzákladnějším způsobem poskytování souborů je však vestavěná funkce příloh k wiki stránkám.

4.1

Přílohy wiki stránek (attachments)

Trac disponuje určitým způsobem poskytování souborů sám o sobě. Součást wiki totiž umí do kterékoli stránky vložit přílohu (attachment), ta je potom zobrazena v přehledu všech příloh na konci stránky. Přílohy lze také odkazovat ze stejné stránky syntaxí ve formě attachment:celý_název_přiloženého_souboru. Takže vytváření stránek se soubory ke stažení není velký problémem. Přílohy se ukáží nepraktické až ve chvíli, kdy chceme se soubory nějak složitěji zacházet, nebo chceme-li je lépe organizovat. Shromažďování jakýchkoli informací byť jen o počtu stažení není nijak podporováno, takže jediným zdrojem informací jsou záznamy webového serveru. Toto řešení poskytování souborů je jakási „nouzovka“, je v Tracu k dispozici okamžitě a vždy, avšak tomu také odpovídají možnosti, které tato metoda poskytuje. Nedá se ani říci, že se jedná o skutečný stahovač.

4.2

TracDownPlugin

Tento stahovač je to nejjednodušší, co lze k danému účelu vytvořit. K poskytování souborů využívá přímo webový server tím způsobem, že na stránce se seznamem souborů ke stažení pouze každé položce vygeneruje odpovídající URL, soubory samotné musejí být umístěny v prostoru přímo dostupném přes webový server. Seznam souborů se vytváří automaticky podle obsahu adresáře, ve kterém jsou umístěny. Soubory nabízené ke stažení musejí být v podadresářích, každý adresář je pak zobrazen v seznamu jako samostatná kategorie. Soubory umístěné v kořeni stahování, nebo hlouběji, než v prvním podadresáři nejsou zobrazeny. TracDownPlugin disponuje i jednoduchou webovou konfigurací, její zprovoznění je však obtížné, často spíše nefunguje, proto je třeba jej nastavit editací konfiguračního souboru Tracu. Poměrně strohý je i popis instalace a provozu na domovské stránce tohoto zásuvného

19

modulu, proto nemusí být pro každého snadné jej uvést do chodu. Tento přístup k řešení stahování souborů projektu je výhodný díky tomu, že soubory jsou poskytovány přímo z adresáře v souborovém systému, takže je velice snadné automaticky nahrávat nové soubory po sestavení nové verze nebo takzvané „nightly builds“. Nevýhodou je, že není umožněno jakkoliv lépe popsat daný soubor, ani neexistuje wiki syntaxe, pomocí které by se lépe přidávaly soubory do wiki stránek. Celkově však hodnotím TracDownPlugin kladně, za výborný nápad s jednoduchou realizací, která dobře poslouží mnoha projektům.

4.3

DownloadsPlugin

Zásuvný modul Downloads nabízí oproti předchozímu výrazně širší možnosti, soubory jsou plně spravovány tímto modulem, takže je nejprve musíme pomocí administračního rozhraní nahrát a vytvořit k nim popis a teprve potom je možné je poskytovat. Záznamy o souborech jsou vedeny v databázi, díky tomu lze například evidovat počet stažení jednotlivých souborů. Soubory mohou být uloženy kdekoliv na disku, není třeba je zpřístupňovat pomocí webového serveru přímo, protože modul sám zařídí pomocí skriptu předání uživateli. Údajů o souboru lze nadefinovat poměrně velké množství, příjemná je také možnost výběru informačních polí zobrazovaných u jednotlivých položek v seznamu souborů ke stažení. Jako trochu nepraktické se mi zdá zadávání jednotlivých parametrů o souboru, je totiž nutné nejprve definovat seznam možných hodnot polí (architektura, platforma, typ) teprve po přednastavení je můžeme přiřadit jako atributy. Popis je možné zadat jen poměrně krátký, jelikož je ve výpisu zobrazován přímo v buňce tabulky. Bohužel také není možné měnit jméno souboru po jeho nahrání a ještě k tomu v aktuální verzi na platformě Windows (jiné platformy jsem netestoval) zůstává jméno souboru spojené s jeho původní cestou před nahráním. Výpis souborů ke stažení je pouze v jedné úrovni, tedy neexistují žádné kategorie, všechny soubory jsou prostě „na jedné hromadě“, nicméně seznam lze alespoň řadit podle kteréhokoli sloupce vzestupně i sestupně. Samotné stažení souboru probíhá hladce, jméno souboru není součástí adresy URL, je předáno v hlavičkách protokolu HTTP (hypertext transfer protocol – jeden z protokolů užívaný k přenosu dat na internetu). Vykreslování není správně odladěno do všech tří hlavních internetových prohlížečů (Internet Explorer, Firefox, Opera), někdy by se hodilo lépe rozvrhnout prvky na obrazovce tak, aby výsledek byl dobře čitelný i v menším okně. Konfigurace chování modulu se provádí výhradně editací konfiguračního souboru Tracu, toto nastavení však většinou stačí provést pouze jednou po instalaci. DownloadsPlugin je dle mého názoru povedený stahovač, který poskytuje všechno to, co neumí TracDownPlugin, samozřejmě mimo formuláře a statistik. Modul obsahuje i wiki syntaxi, díky které lze snadno odkazovat na nabízené soubory z wiki stránek a samozřejmě různá uživatelská oprávnění pro řízení přístupu do jednotlivých částí modulu.

20

Kapitola 5

Zásuvný modul Downloader Downloader je stahovač s formulářem do systému Trac. Jeho vytvoření bylo jedním z cílů této bakalářské práce. Modul umožňuje poskytování souborů ke stažení se sledováním počtu stažení, získávání dalších informací o stahujícím uživateli pomocí formuláře a poskytuje přehledné grafové statistiky o počtech stažení. Downloader svým způsobem doplňuje mezeru mezi již existujícími stahovači do systému Trac. Základní cíle byly definovány v zadání této práce, konkrétní specifikaci, podle které byl modul naprogramován, jsem sestavil na základě pohovoru s vedoucím práce.

5.1

Hlavní body specifikace

Zde jsou obsaženy skutečně jen hlavní body. Kompletní specifikace v příloze B je o něco podrobnější. Tato specifikace samozřejmě dokonale neodpovídá vytvořenému modulu, protože během vývoje se objevily i lepší možnosti, jak dosáhnout podobných cílů. Obecné • Downloader bude připraven jako zásuvný modul systému Trac. • Seznam souborů ke stažení bude v záložce modulu Downloader a bude dělen na tzv. vydání, k souborům bude možné vytvořit textové poznámky. • Soubory bude možné přidávat pomocí administračního rozhraní. • Každá část modulu bude mít vlastní práva nastavitelná v administraci Tracu. Formulář před stažením souboru • • • • •

Bude obsahovat zadávací pole pro jméno, příjmení, e-mail a účel stažení. Formulář bude možné rozšířit o další vstupní pole. Uživatel bude muset formulář vyplnit před každým stažením souboru. Validita e-mailové adresy bude před přijetím vhodným způsobem ověřena. Formulář bude obsahovat ověření opsáním textu z obrázku.

Administrace • Bude umožňovat výpis všech vyplnění stahovacího formuláře s filtrováním. • Mazání záznamů bude možné provádět jednotlivě nebo jako skupinu ohraničenou časem. 21

• Nahrávání a správa souborů bude umožňovat měnit všechny parametry o nich uchovávané. Statistiky • Hlavní statistikou bude seznam souborů s informacemi o počtech stažení. • Další statistiky budou počty stažení v závislosti na času v různých detailech.

5.2

Pro a proti začátku na zelené louce

V minulé kapitole jsem popsal existující možnosti poskytování souborů v systému Trac. Podívejme se tedy, jestli a za jakých podmínek je možné využít zmíněné zásuvné moduly jako základ nového stahovače s rozšířenými schopnostmi podle specifikace z přílohy B. TracDownPlugin Filozofie tohoto zásuvného modulu je naprosto odlišná od požadavků na nový stahovač. Neeviduje v databázi žádné informace o poskytovaných souborech, seznam souborů je generován přímo v okamžiku požadavku podle aktuálního obsahu adresáře a soubory nejsou poskytovány uživateli systémem Trac, ale přímo webovým serverem, takže ani není možné sledovat Tracem jednotlivá stažení souborů. Jediné co má modul společného s požadavky na nový stahovač je poskytování souborů ke stažení z prostředí systému Trac. TracDownPlugin proto není vhodným základem. DownloadsPlugin Když porovnáme popsané vlastnosti DownloadsPluginu se specifikací nového stahovače, najdeme mnoho podobností: • Soubory jsou poskytovány skriptem, takže není možné stáhnout soubor bez vědomí modulu. • Soubory jsou nahrávané pomocí administračního rozhraní. • Uživatelská práva jsou nastavitelná pro jednotlivé části modulu. • Modul ukládá informace o souborech do databáze a počítá stažení souborů. Dalo by se říci, že je možné vybudovat nový modul jako rozšíření tohoto. Bohužel při hlubším přezkoumání požadavků je tento fakt minimálně sporný (DownloadsPlugin vs. nový modul) : • Organizace souborů je „plochá“ oproti požadovanému systému „kategorie – vydání – soubor“ (nebo při nejmenším „vydání – soubor“). • Schéma tabulek v databázi je příliš jednoduché, muselo by být v podstatě celé nahrazeno. • Popisy souborů jsou příliš krátké, to znamená nutnost změnit způsob jejich výpisu i uchování. 22

• Záznam o stažení souboru je proveden jen inkrementací záznamu v databázi s počtem stažení, z čehož plyne, že není možné na těchto informacích vystavět statistiky. • Skladba obrazovek je nevhodná pro přidání dotazníku (příliš široké tabulky). Ve světle těchto poznatků jsem dospěl k závěru, že pokud bych chtěl nový modul založit na DownloadsPluginu, muselo by být vynaloženo minimálně stejné úsilí, jako při začátku na zelené louce. Navíc nový modul by ani nemohl být považován za rozšíření stávajícího modulu, protože by jej měnil od základu a tak by se muselo stejně jednat o nový nezávislý projekt. Posledním argumentem je, že vnitřní struktura programu není taková, aby se daly změny tohoto formátu snadno implementovat, tudíž nový začátek je i čistší řešení.

5.3

Organizace souborů

Systém: kategorie – vydání – soubor Jako základní princip organizace souborů v Downloaderu byl zvolen systém kategorie – vydání – soubor (category – release – file). Vychází z předpokladu, že u softwarového projektu obvykle chceme poskytovat více kategorií souborů ke stažení a že do kategorií budeme přidávat jednotlivá vydání („verze“). Každé vydání pak obsahuje jeden či více souborů, které k němu patří (obr. 6). Tento systém je podle mne osvědčený a dobře se hodí k poskytování software ke stažení, používá jej například portál Sourceforge (www.sourceforge.net).

Obr. 6: Downloader – obrazovka seznamu souborů ke stažení

23

Jaké informace o souboru uchovávat Množství údajů poskytovaných o souborech ke stažení se u různých stahovačů liší. Například DownloadsPlugin umožňuje zobrazit poměrně velké množství informací: jméno souboru, krátký popis, velikost, časový údaj přidání, počet stažení, kdo soubor nahrál, komponenta, verze, HW architektura, platforma, typ. Oproti tomu Sourceforge [27] i Google Code [26] zobrazují informací výrazně méně. Z důvodu co největší přehlednosti jsem se rozhodl zobrazovat pouze minimální množství údajů, které jsou nezbytné pro snadnou identifikaci souboru a jeho způsobu užití (obr. 6): • Jméno • Velikost • HW architektura Každý soubor, vydání i kategorie má ještě pole „Poznámky k vydání“, které je dostupné kliknutím na odpovídající ikonku. Toto pole může obsahovat i rozsáhlejší popis ve formě prostého textu. Jako rozšíření popisu plánuji do budoucna přidání vlastní wiki stránky ke každé ze zmíněných entit. Životní cyklus souboru Základními fázemi životního cyklu jsou: • Nahrání souboru a přidání informací o něm. • Existence souboru (případně úpravy informací o něm). • Odstranění souboru. První dvě fáze jsou poměrně přímočaré a nevznikají během nich problémy. Třetí fáze, odstranění souboru, s sebou však nese některé komplikace, s kterými je nutné se vypořádat. Během existence souboru ve stahovači totiž pro uchování statistik vznikají záznamy, které se odkazují na informace uložené o souboru, ty jsou později potřeba pro správné vykreslení statistik z minulosti. Proto je ve fázi odstranění souboru pouze fyzicky smazán nahraný soubor, ovšem údaje o něm vedené, především jméno a čas smazání, jsou stále uchovávány a nadále zobrazovány ve statistikách z dob, kdy soubor ještě ve stahovači existoval. Udržování informací o smazaných souborech je využíváno i při zobrazování odkazů na soubory ve wiki stránkách, což přispívá k orientaci uživatele ve změnách, které nemusejí být vždy ihned konzistentní v celém systému. Způsob zadávání údajů Při nahrávání nového souboru nebo při editaci existujícího stejně jako při stejných úkonech s kategoriemi a vydáními, zadáváme různé údaje o těchto entitách do formuláře. Otázkou je, jaké způsoby zadávání zvolit, aby byla práce uživatele co nejpohodlnější a nejefektivnější.

24

Obr. 7: Vlevo zadávání údajů v DownloadsPluginu, vpravo v novém Downloaderu.

Obr. 8: Nastavení možností atributu.

V kapitole o DownloadsPluginu jsem se již zmínil, že tento modul využívá k zadávání téměř všech údajů rozbalovací pole se seznamem možností (obr. 7 vlevo). Toto řešení mi připadá nevhodné, jelikož ve chvíli kdy je třeba přidat novou možnost se musí uživatel „proklikat“ do správy předdefinovaných atributů (obr. 8) a tam, v jiném formuláři, atribut přidat. Další nepříjemností je potřeba odstranění některé z možností, kdy je nutné nejprve zajistit, aby tato možnost atributu nebyla nikde použita a teprve potom je možné ji smazat. Naopak výhodou systému předdefinovaných možností je unifikace, díky níž se nestane, že je například architektura u jednoho souboru zapsána jako „i386“ a u následujícího

25

„I386“. Systém lze pro uživatele vylepšit přidáním textového zadávacího pole pro novou možnost atributu přímo pod rozbalovací seznam. V něm se potom zobrazují všechny možnosti tohoto atributu, které jsou přiřazeny nějaké entitě, díky tomu je uživateli dopřán maximální komfort a odpadá nutnost přednastavování jednotlivých možností pro každý atribut. Pro svůj stahovač jsem zvolil zadávání všech atributů textovými poli (obr. 7 vpravo). Komfort uživatele je srovnatelný s posledním popsaným způsobem a výrazně vyšší, než se způsobem pevného předdefinování možností atributů. Uživatel však musí dodržovat kulturu zápisu možností sám. Datový model Pro uložení informací o souborech, vydáních a kategoriích slouží v databázi tři tabulky: downloader_file, downloader_release a downloader_category (horní tři tabulky na obr. 9). Pro uložení všech informací by za stávajícího stavu postačovala místo těchto třech pouze jedna tabulka s atributy z tabulky downloader_file, kde by další atribut specifikoval typ elementu (kategorie, vydání, soubor), o který se jedná. Řešení se třemi tabulkami je praktičtější z hlediska možné potřeby přidání nových atributů pro jednotlivé elementy v dalších verzích.

Obr. 9: Datový model zásuvného modulu Downloader.

5.4

Formulář před stažením souboru

Prvek, který je odlišný od všech ostatních existujících stahovačů do systému Trac, je formulář, jež je nutné vyplnit před stažením souboru. Teoretickou rovinu stahovačů s formulářem jsem rozebral v kapitole 2, nyní se podíváme blíže na řešení aplikované 26

v zásuvném modulu Downloader. Uživatelsky volitelný formulář Aby byl formulář užitečný co nejširšímu spektru uživatelů, je nutné jim nějakým způsobem umožnit tento formulář definovat podle vlastních potřeb. Navíc je třeba definici co nejvíce zjednodušit pro snadné pochopení uživatelem, přitom však musí být dobře srozumitelná i pro počítač tak, aby formulář dokázal správně vykreslit na různých místech, uložit informace pomocí něho získané a ověřit validitu zadaných dat. S ohledem na tyto požadavky a rychlost zpracování jsem zvolil, jako vhodný formát pro uživatelské sestavení formuláře, datové struktury jazyka Python (struktury seznam a slovník). Srozumitelnost zápisu je zajištěna dobrým strukturováním, odsazeními a závorkami. Příklad jednoduchého formuláře s jedním zadávacím polem typu textfield (typ vstupního pole ve formuláři zapsaném jazykem HTML) je na obr. 10, zápis celého přednastaveného formuláře i s popisem jak formulář sestavit (anglicky) viz příloha C.

Obr. 10: Jednoduchý formulář s jedním zadávacím polem zapsaný ve formátu, který používá k definici formuláře zásuvný modul Downloader.

Z ukázky (obr. 10) a přílohy C je patrné, že zápis je přehledný a srozumitelný. Tento formát definuje několik typů vstupních polí (atribut type v příkladu): • text – Zadávací pole pro jednořádkový text. • radio – Vybírací políčko pro výběr jedné z více možností. • checkb – Zaškrtávací políčko. • label – pouze popisek pro oddělení částí formuláře, nebo nadepsání výběru z více následujících možností. S pomocí těchto prvků může každý uživatel jednoduše sestavit vlastní formulář podle svých požadavků a získávat tak od zájemců o soubory data, která potřebuje. Ověřování údajů získaných formulářem Downloader umožňuje v uživatelsky definovaném formuláři ověření dat zadaných do 27

textových polí regulárním výrazem. Tuto metodu nelze označit za zcela uživatelsky přívětivou, protože tvorba regulárních výrazů a jejich testování je ve své podstatě programátorská činnost. Popis použití však instruuje jednoduchý regulární výraz pro ověření délky zadaného řetězce, což je podle mého názoru základní ověření, které uživateli bez hlubších znalostí regulárních výrazů postačí. Regulární výraz je ve struktuře formuláře zadán atributem regexp.

Obr. 11: Obrazovka Downloaderu s formulářem z přílohy C po nesprávném vyplnění údajů.

Validita výběru „jeden z více“ je nejasný pojem, Downloader umožňuje nastavit povinnost vybrat jedno (jakékoli) vybírací políčko ze skupiny se stejným jménem. Toto nastavení se provede přidáním atributu mustchoose s hodnotou True k prvnímu vybíracímu políčku ze skupiny se stejným jménem. Ošetření validity zaškrtávacích políček je problematické a vyžadovalo by velice komplikované rozhraní, proto jsem žádný způsob ověření pro tento element neimplementoval. Většina běžných užití typu: „Souhlasím s podmínkami…“ lze provést pomocí políčka výběru „jeden z více“. I když přidání možnosti povinného vybrání zaškrtávacího políčka zvažuji k pozdější implementaci. 28

Aby uživatel věděl co a jakým způsobem má v chybně vyplněném formuláři opravit, může být v definici zadán do atributu errinfo text vysvětlující požadavky správného vyplnění (červený text ve formuláři na obr. 11). Ten je zobrazen v případě detekce chybných dat z daného pole na začátku formuláře. Pokud tento atribut není zadán, je chybné pole pouze označeno červenou hvězdičkou (toto označení je provedeno i v případě zobrazení vysvětlujícího textu). Sémantika formuláře Jak jsem již zmínil, formulář musí být srozumitelný i pro počítač (tedy skript, který s ním pracuje). Pro zajištění správného zobrazování na různých místech slouží atribut cat a s ním související label_for. Tyto atributy umožňují u skupiny políček výběru „jeden z více“ definovat popisek výsledné hodnoty, který je použit při výpisu všech dat jednotlivého stažení souboru a v hlavičce tabulky přehledu vyplněných dat. Tyto atributy slouží také ke zvýšení přehlednosti formuláře, protože prvky jedné skupiny jsou od ostatních prvků odděleny mezerami před a za skupinou (podrobný popis viz příloha C). K sémantickému propojení skupiny políček výběru „jeden z více“ potom slouží atribut name stejně jako v HTML. Díky tomu lze všechny zadané hodnoty ukládat do tabulky ve formě: jméno atributu, hodnota. Posledním zajímavým atributem je show_in_main_list. Při jeho nastavení na True je pole ke kterému náleží zobrazováno v tabulce s hlavním přehledem vyplněných údajů, tím je umožněno pohodlné prohlížení tohoto atributu. Datový model Údaje vyplněné v jakkoli sestaveném formuláři společně s daty o stažení jsou ukládány do dvojice tabulek downloader_downloaded a downloader_downloaded_attributes (spodní dvě tabulky na obr. 9). První z nich uchovává informace o stažení – ID stažení, ID staženého souboru a časovou známku. Druhá tabulka slouží k uchování dat z formuláře. Každý záznam je spojen s některým záznamem z první tabulky. Všechny řádky spojené s jedním (stejným) záznamem z první tabulky pak reprezentují data uložená při jednom vyplnění formuláře. Díky tomu, že všechna pole formuláře jsou převeditelná na dvojici „jméno atributu, hodnota“ není problém skladovat data z jakéhokoli formuláře v tabulce downloader_downloaded_attributes.

5.5

Zamezení stahování roboty

Aby nedocházelo jednak k vyplňování formuláře roboty a tím ke kažení statistik a za druhé k „ukradení“ souborů robotem a jejich automatickému nabízení na jiném serveru, je nutné použít nějaký způsob odlišení člověka od stroje. Pro modul Downloader byla zvolena metoda, kterou jsem v části 2.2 nazval „Klasický obrázek s textem“. Na internetu jsem objevil 29

několik různých systémů odpovídajících této metodě. Bohužel se všechny mimo jediného vyznačují přílišnou jednoduchostí až primitivitou a proto by neposkytovaly dostatečnou ochranu nabízených souborů. Vybral jsem tedy systém PyCAPTCHA. Z nevyhovujících systémů zmíním systém reCAPTCHA [27], který je ideální volbou pro všechny projekty, kde je třeba ověření přidat snadno a rychle. Jeho užití jsem bohužel musel zamítnout s ohledem na to, že se jedná o on-line službu, která nemusí být vždy plně spolehlivá, dostupná a dostatečně rychlá. PyCAPTCHA Jak název napovídá, jedná se o systém implementovaný v jazyce Python, což je nezbytné kvůli co nejsnazší implementaci do zásuvného modulu pro Trac. PyCAPTCHA vytváří velice kvalitní ověřovací obrázky, které skládá z několika definovatelných grafických vrstev. Můžeme použít vlastní obrázky pro pozadí, vlastní fonty ve formátu TrueType, přidat poloprůhledné obrázky do popředí i naprogramovat vlastní deformační filtry. Díky tomu je možné nakonfigurovat si CAPTCHu přesně podle potřeb plánovaného použití například i s ohledem na design celé stránky, kde má být vygenerovaný ověřovací obrázek použit. Pochopit a zprovoznit tento systém není zcela triviální úkol, což je jakási daň za robustnost. Pro jednodušší použití systému PyCAPTCHA obsahuje její základní balíček několik obrázků na pozadí i popředí, fonty a sadu ukázkových, přitom však plně funkčních, přednastavení. Celkově je PyCAPTCHA výborný systém, u kterého programátor rozhodně nemá svázané ruce. Použití PyCAPTCHA v zásuvném modulu Downloader Balíček PyCAPTCHA byl použit s daty (obrázky, fonty a deformace), které jsou součástí základní instalace. Při vhodném nastavení a výběru jen některých kvalitních obrázků jsou tato data naprosto dostačující a zaručují přiměřený stupeň bezpečnosti při zachování dobré čitelnosti textu. Byla vytvořena speciální konfigurace, která umožňuje uživateli zásuvného modulu Downloader měnit některá nastavení, jako je velikost písma, tloušťka obrysu nebo počet znaků v obrázku. Navíc je možné vybrat prozatím jen ze dvou složitostí generovaného obrázku. Samozřejmě hůře čitelný obrázek pro počítač znamená také horší čitelnost pro člověka, proto je na uživateli, aby zvolil pro něho vhodný kompromis. Generování slov je zajištěno pseudonáhodným výběrem ze seznamu znaků (vestavěná funkce random jazyka Python), takže nevznikají žádné slovníkové výrazy ani není brán zřetel na zapamatovatelnost jako tomu bývá v systémech pro generování hesel. Sada znaků obsahuje všechna velká i malá písmena anglické abecedy a všechny číslice. Ověření správnosti opsaného řetězce je prováděno bez ohledu na velká a malá písmena, navíc není rozlišováno mezi nulou a písmenem „o“, tím je zvýšen komfort uživatele při opisování kódu z obrázku.

30

5.6

Způsob poskytnutí souboru

MIME typy Pro správné zobrazení staženého souboru v uživatelově prohlížeči je nezbytné vybavit hlavičky protokolu HTTP před odesláním správným MIME typem (Multipurpose Internet Mail Extensions – standard původně určený pro definování parametrů částí obsahu zpráv elektronické pošty). K tomuto účelu disponuje modul Downloader vlastním seznamem MIME typů a jim náležících přípon souborů. Seznam je realizován jako prostý textový soubor, na každém řádku jeden záznam ve tvaru: přípona souboru, oddělovací mezera, MIME typ. Aby nemusel být tento soubor před každým použitím znovu parsován, je po rozpoznání změny automaticky transformován do zdrojového kódu jazyka Python a tento následně interpret Pythonu přeloží do bytecode, jak již bylo popsáno v části zabývající se Pythonem. Tím je dosaženo maximální možné rychlosti při práci se seznamem MIME typů. Trac sám disponuje funkcemi pro rozeznání MIME typů, nepoužil jsem je, protože ve verzi 0.9 vykazovaly zvláštní chování. Nicméně v dalších verzích byly tyto funkce vylepšeny a zkvalitněny, tudíž v příštích verzích modulu Downloader pravděpodobně samostatný seznam MIME typů zmizí. Přímé přesměrování vs. Poskytnutí odkazu Ve chvíli, kdy uživatel správně vyplní dotazník a odešle jej, stojíme před otázkou, jakým způsobem mu soubor poskytneme. V zásadě existují dvě možnosti: buď uživatele na soubor přesměrujeme ihned po odeslání správně vyplněného formuláře nebo místo přesměrování vrátíme stránku, kde bude zřetelně připraven odkaz na požadovaný soubor. Okamžité přesměrování je pro uživatele přínosné v tom smyslu, že nemusí znovu klikat a soubor se mu ihned buď zobrazí, nebo ukáže ke stažení. Bohužel si v tomto případě nemůže sám zvolit, jestli chce soubor přímo otevřít v internetovém prohlížeči, nebo jestli si jej přeje uložit. Můžeme buď nastavit, že u všech souborů bude nabídnuto uložení, nebo nechat volbu způsobu zobrazení na prohlížeči. Uživatel tento fakt již nemůže ovlivnit. Vypsání odkazu je nepříjemné právě proto, že návštěvník je nucen znovu hledat na stránce co se to vlastně stalo a potom ještě jednou kliknout na poskytnutý odkaz, nicméně díky tomu si sám může zvolit, co se souborem provede – jestli jej chce přímo uložit (klikne na odkaz pravým tlačítkem a vybere odpovídající volbu), nebo zobrazit přímo v prohlížeči (klikne na odkaz), či dokonce zobrazit v novém okně prohlížeče (klikne na odkaz, přičemž drží klávesu ctrl nebo jinou v závislosti na typu prohlížeče). Downloader poskytuje obě popsané možnosti, je tedy na uvážení poskytovatele souborů, který způsob se mu zdá, s ohledem na typ nabízených souborů, vhodnější.

31

5.7

Zpřístupnění souborů pomocí wiki

Protože wiki je jedním z hlavních nástrojů napomáhajícím při řízení softwarového projektu systémem Trac, je velice vhodné mít k dispozici co nejjednodušší nástroje ke zpřístupnění nabízených souborů touto cestou. Trac umožňuje zásuvným modulům vytvářet takzvané wiki syntaxe, které slouží právě ke snadnému odkazování na data spravovaná zásuvnými moduly. Modul Downloader zpřístupňuje pomocí vlastních wiki syntaxí jednak samotné soubory, jednak jednotlivá vydání a nakonec také celé kategorie. Stačí pouze napsat klíčové slovo downloader pro soubor, downloaderrel pro vydání a downloadercat pro kategorii a za toto slovo pak id daného elementu oddělené dvojtečkou. Názorný příklad viz obr. 12.

Obr. 12: Horní obrázek ukazuje zdrojový text wiki stránky s odkazy do modulu Downloader, na dolním obrázku je výsledná podoba stejné stránky při zobrazení v HTML.

Číslo id elementu bohužel v aktuální verzi není na žádném místě implicitně zobrazované, je možné jej najít pouze v odkazu na element – číslo na konci adresy URL. Tato vada bude v některé z příštích verzí opravena.

5.8

Konfigurace

Konfigurace v systému Trac Do verze 0.10 je preferovaným způsobem nastavení editace konfiguračního souboru, který obsahuje každé prostředí (environment) systému Trac. Konfigurace je prováděna kla32

sickým způsobem doplňování názvů parametrů a jejich hodnot. Nepraktické je, že uživatel musí znát všechny nastavitelné parametry, jejich hodnoty a význam. Z toho vyplývá, že musí nejprve někde najít popis nastavení a teprve potom může nastavovat. Další konfigurace týkající se databáze (nastavení práv, přidání nových milníků a podobně) pak musí být provedena v příkazové řádce pomocí nástroje trac-admin. Od verze Trac 0.9 však existuje zásuvný modul TracWebAdmin, který umožňuje většinu nastavení dělat i pohodlněji přes webové rozhraní. S ohledem na oblíbenost tohoto modulu je pak ve verzi 0.11 přibalen přímo do distribuce Tracu. Výhodou konfigurace přes GUI je, že uživatel se může dozvědět vše potřebné ke správnému nastavení přímo na místě, kde jej provádí. Staré způsoby nastavování jsou stále možné, protože TracWebAdmin je jen jakousi nadstavbou, která částečně dělá to samé co nástroj trac-admin a částečně edituje soubor s konfigurací. Konfigurace a uživatelé Obrovské možnosti nastavení jakéhokoli produktu jsou k ničemu, pokud je uživatelé neumějí použít nebo nepotřebují. Aby nedocházelo k prvnímu zmíněnému případu, je vhodné používat grafická rozhraní nejlépe pro všechna existující nastavení. V Tracu k tomu výborně slouží TracWebAdmin, který poskytuje místa rozšíření pro vytváření nových konfiguračních rozhraní. Druhý případ, nepotřebná nastavení, jsou nebezpečná pro to, že uživatel v záplavě možností není schopen najít nastavení, které potřebuje, nebo jej nedokáže správně provést. Proto i v nastavitelnosti musíme dobře zvážit, jestli je daná možnost skutečně užitečná. Konfigurace zásuvného modulu Downloader Ke správnému fungování Downloaderu je nezbytné, aby byl v systému nainstalován TracWebAdmin pomocí kterého je mimo konfigurace řešena i správa souborů nabízených ke stažení. Samotnou konfiguraci je možné provádět editací konfiguračního souboru prostředí Tracu i jednoduchým a přehledným „naklikáním“ v modulu TracWebAdmin (obr. 13). Na obrázku je vidět, že u každého nastavovacího prvku je krátký název, který stačí zkušenému uživateli k pochopení jeho významu a teprve níže je umístěn rozsáhlý popis daného nastavení a jeho důsledků. Konfigurace je vytvořena tak, aby byl uživatel hned po instalaci Downloaderu nucen provést kritická nastavení potřebná k funkčnosti modulu, bez správného provedení těchto úkonů je uživatel při pokusu použít modul okamžitě přesměrován do konfigurace, kde jsou požadovaná nastavení zvýrazněna a popsána. Stručný přehled nastavení (kompletní možnosti konfigurace v angličtině viz příloha D): • vypnout dotazník, • zobrazit dotazník pouze při prvním stažení v uživatelově sezení, • místo přesměrování poskytnout odkaz na soubor, • vypnout ověřování obrázkem, 33

• • • • •

počet znaků v obrázku, velikost písma, obrys písma, obtížnost obrázku, adresář pro uložení poskytovaných souborů.

Obr. 13: Konfigurace modulu Downloader – nastavení ověřovacího obrázku CAPTCHA.

5.9

Statistiky

Schopnost vytvářet přehledné statistiky je jedním z hlavních přínosů zásuvného modulu Downloader. Statistiky jsou nenahraditelným vodítkem při sledování zájmu o nabízené soubory. Mohou také pomoci zjistit, které informační kampaně byly účinné a které ne. Se statistikami se na internetu obvykle setkáváme v souvislosti s návštěvností webových stránek, nejzajímavější bývá zobrazení počtů návštěv v závislosti na čase. Právě taková statistika je základem statistik i v Downloaderu. Dále jsou k dispozici přehledy počtů stažení o jednotlivých entitách (souborech, vydáních a kategoriích) a i pro ně je možné zobrazit samostatné časové statistiky. Zatím neimplementované zůstávají statistiky údajů vyplněných ve formuláři. Vytvořit smysluplné, přehledné a funkční statistiky tak různorodých dat je poměrně náročný úkol, nicméně výsledek má rozhodně velký přínos a nabízí slušné zhodnocení nasbíraných dat. Prozatím je možné vytvářet podrobné statistiky těchto informací pouze externě v aplikacích typu Excel a to díky tomu, že Downloader umožňuje vyexportovat přehled všech uložených dat ve formátu csv, který je dobře zpracovatelný právě těmito aplikacemi (výběr možností exportu je vidět na obr. 14 dole). 34

Sběr dat a uživatelský komfort V podstatě každá překážka na cestě za požadovaným obsahem může odradit nemalé procento zájemců a další velké skupině výrazně znepříjemnit jeho získání. Hlavním mottem při návrhu způsobu získávání dodatečných informací od uživatele by tedy mělo být: „Udělej vše pro uživatele.“ Přesto se často setkáváme s nedokonalými formuláři, které nedokáží správně informovat o tom, proč jejich vyplnění nebylo přijato, ztrácejí vyplněné údaje po odeslání nebo obtěžují několikanásobným vyplňováním stejného dotazníku. Downloader se snaží být co nejpřívětivější, proto kdykoli je k dispozici ukládání dat mezi jednotlivými požadavky uživatele, ukládá a následně předvyplňuje data do dotazníku. Modul také umožňuje uživatele co nejpřesněji navést na chyby, kterých se při vyplňování dopustil, to samozřejmě velkou měrou záleží na tom, jak kvalitně je dotazník sestaven, detaily byly zmíněny v části 5.4. Správa vyplněných údajů K prohlížení vyplněných údajů je určena část statistiky v sekci administrace. Zde najdeme přehlednou tabulku všech vyplnění formuláře. Data můžeme řadit sestupně a vzestupně podle kteréhokoli sloupce (mimo id), je také možné zvolit počet řádků tabulky na stránku a zobrazit všechny údaje vyplněné v jednom odeslání formuláře. Tabulka obsahuje mimo prvních třech pouze sloupce, u kterých je v definici formuláře povoleno zobrazení v hlavním přehledu (bylo popsáno v části 5.4). Toto řešení se neukázalo být ideální, lepších výsledků by bylo dosaženo přidáním výběru zobrazovaných sloupců přímo k přehledové tabulce, aby si prohlížející mohl snadno různě měnit zobrazované sloupce.

Obr. 14: Tabulka správy vyplněných údajů, ve spodní části obrázku jsou uvedeny možnosti exportu.

35

Jelikož se mezi vyplněné údaje mohou i přes všechnu snahu dostat vadná data, je třeba umožnit jejich mazání. Zatím existují jen dva způsoby. Prvním je mazání jednotlivých záznamů prostým zvolením akce „smazat“ v posledním sloupci, tuto volbu je třeba ještě potvrdit a po té je celý záznam odstraněn a není nadále započítáván ani do celkového počtu stažení odpovídajícího souboru ani do žádných jiných statistik. Druhým způsobem je mazání bloku záznamů ohraničeného časem. Stačí jednoduše zapsat nebo nakopírovat časové známky prvního a posledního smazaného souboru požadovaného rozmezí a stisknout tlačítko „Smazat“. Žádné další potvrzení této akce není nutné, dostatečnou ochranou proti nechtěnému smazání je složitost vyplnění časových známek, které musejí být přesně v předepsaném formátu. Nabízejí se i další možné způsoby mazání souborů, ovšem uvedené dva jsou zatím dostačující. Reprezentace dat Aby statistiky měly smysl, je třeba je nějak zobrazovat. K tomuto účelu obvykle slouží grafy různých typů. Pro přehledy typu „počet stažení v časovém intervalu“ jsou nejvhodnější klasické sloupcové grafy, kdy nejvyšší hodnota dosahuje horního okraje grafu a ostatní sloupce mají k němu poměrnou velikost (obr. 16). Podobným způsobem lze tento typ grafu vykreslit i horizontálně (obr. 15), to je často jediná možnost jak přehledně zobrazit hodnoty velkého množství atributů.

Obr. 15: Samostatná statistika pro jednotlivé soubory.

Downloader poskytuje dvě úrovně časových statistik, první je přehled měsíců v jednom roce, druhá pak přehled dnů v měsíci (obr. 16). Tyto statistiky jsou jednak souhrnné pro všechna stažení najednou a jednak samostatné pro jednotlivé soubory, vydání a kategorie 36

(obr. 15). Užitečným rozšířením nabízených grafů by mohly být například souhrnné statistiky dnů v týdnu ze všech období najednou, případně ještě dobře známý graf pro jednotlivé denní hodiny opět ze všech období společně.

Obr. 16: Časová statistika – graf dnů v měsíci.

Vykreslování grafů K tomuto účelu je k dispozici mnoho různých nástrojů. Nejžhavější novinkou je API pro grafy od Google [28]. Všechny tyto snadno dostupné nástroje mají však jedno společné – vytvářejí grafy jako obrázek, který je potom načten ve stránce. Toto řešení má hned několik nevýhod: • graf jako obrázek není možné přizpůsobit velikosti okna prohlížeče, • vykreslení grafu do obrázku nás stojí výpočetní čas serveru, • případná interaktivita (odkazy v grafu, informace po najetí na část grafu) je velice komplikovaná, • obrázek velkého grafu je velký a bude se déle stahovat. Ovšem řešení s obrázkem má také jednu obrovskou výhodu – graf je vždy stejný a vždy správně zobrazen. To je bohužel sen, o kterém si s jinými způsoby vykreslování můžeme jen nechat zdát. Ve svém modulu jsem se však rozhodl jít méně prošlapanou cestou a to hlavně kvůli více bodům proti, než pro u předchozího řešení. Jedná se o vykreslení grafu jen s pomocí prvků HTML. Jak napovídají obrázky, nakonec se vše podařilo, nicméně skutečně krásně se tyto grafy (především ty vertikální – obr. 16) vykreslují jen ve třech hlavních prohlížečích (Internet Explorer, FireFox, Opera) a to v jejich posledních verzích. V dalších prohlížečích již ne37

musejí být všechny popisy přesně zarovnané a podobně. Kuriózní vadou tohoto řešení je, že vertikální grafy se snad ani v jednom z prohlížečů nevykreslí ideálně při tisku (výsledek je však většinou rozumný), takže pokud si uživatel přeje vytisknout graf tak jak jej vidí, nezbývá mu než udělat snímek obrazovky a tisknout jako obrázek. S vykreslováním horizontálních grafů, podobných grafu na obrázku 15, je minimum problémů, ty by se vyhnuly i vertikálním grafům, jenže HTML ani CSS bohužel nepodporují otáčení textů. Na konec je nutné dodat, že tyto stránky s grafy jsou podle validátoru konsorcia W3 plně validní HTML.

5.10 Další vývoj Downloaderu Zásuvný modul Downloader jsem navrhl podle požadavků zadavatele této práce, avšak při jeho tvorbě jsem se snažil myslet i na jeho využití v jiných projektech. Proto pokud bude o tento modul zájem, budu pokračovat v jeho vývoji. Prvním cílem po jakési testovací lhůtě (u větších projektů se stavu, ve kterém momentálně Downloader je, říká beta verze), která v době psaní této práce probíhá, a odladění chyb je zmrazení vývoje pro Trac verze 0.9 a 0.10 a vytvoření nové verze pro Trac 0.11, který je aktuálně ve stádiu beta testování. Později bych rád postupně zapracoval některé, nebo nejlépe všechny, změny zmíněné v předchozím textu a tím dále zvyšoval užitnou hodnotu tohoto díla.

38

Kapitola 6

Závěr V předchozím textu jsme se postupně seznamovali se základy problematiky stahovačů s formulářem, systémem Trac, již existujícími stahovači pro tento systém a nakonec s nejnovějším přírůstkem zásuvným modulem Downloader. Tento modul byl vytvořen jako součást této práce a odpovídá požadavkům stanoveným zadavatelem. Tím bylo naplněno zadání této práce. Avšak osobně doufám v to, že vytvořený modul zůstane, například prostřednictvím jeho webové prezentace http://trac-hacks.org/wiki/TracDownloaderPlugin na portálu Trackhacks.org, i nadále živým projektem, který si najde své uživatele a tím naplní i můj cíl, jímž bylo vytvořit užitečnou pomůcku, která není jen další prací „do šuplíku“, stejně tak věřím, že se najdou čtenáři, kteří toto dílo objeví a bude jim přínosem.

39

Literatura [1]

The Trac Project [online]. 2007-08-17– . [cit. 2007-12-27]. .

[2]

TracDownloader homepage [online]. 2007-12-14– . [cit. 2007-12-27]. .

[3]

Wikipedia – http referer [online]. 2007-12-27– . [cit. 2007-12-27]. .

[4]

Wikipedia –List of HTTP headers [online]. 2007-10-21– . [cit. 2007-12-27]. .

[5]

FINER, Joshua. The Forgotten Art of Email Address Validation [online]. 2007-9-30– . [cit. 2007-12-27]. .

[6]

GOYVAERTS, Jan. The Forgotten Art of Email Address Validation [online]. 2007-10-20– . [cit. 2007-12-27]. .

[7]

Wikipedia – Domain Name System [online]. 2007-12-28– . [cit. 2007-12-27]. .

[8]

PARC’s CAPTCHA’s -- History [online]. Palo Alto Research Center. 2003-2-28– . [cit. 2007-12-27]. .

[9]

Wikipedia –CAPTCHA [online]. 2007-12-29– . [cit. 2007-12-27]. .

[10] MORI, Greg. – MALIK, Jitendra. Breaking a Visual CAPTCHA [online]. UC Berkeley Computer Vision Group and Simon Fraser University. [cit. 2007-12-4]. . [11] ROBINSON, Sara. Human or Computer? Take This Test [online]. The New York Times Company. 2002-12-10–. [cit. 2007-12-01]. . [12] Digitizing Books One Word at a Time [online]. Carnegie Mellon University Center. 2007– . [cit. 2007-12-27]. . [13] SMART, John. What issue tracking system is best for you? [online]. JavaWorld.com. 2007-3-14– . [cit. 2007-12-27]. 40

. [14] TracDev/ApiChanges/0.10 [online]. 2007-12-14– . [cit. 2007-12-27]. . [15] TracDev/ApiChanges/0.11 [online]. 2007-12-23– . [cit. 2007-12-27]. . [16] The Trac Wiki Engine [online]. 2006-10-10– . [cit. 2007-12-27]. . [17] SQL Features That SQLite Does Not Implement [online]. 2007-11-13– . [cit. 2007-12-27]. . [18] What is Python? [online]. 2006– . [cit. 2007-12-27]. . [19] MARINESCU, Floyd. Replace JARS with Java modules and a repository [online]. TheServerSide.com community. 2005-5-15– . [cit. 2007-12-27]. . [20] Trac Component Architecture [online]. 2007-4-7– . [cit. 2007-12-27]. . [21] Writing Plugins for Trac [online]. 2007-12-12– . [cit. 2007-12-27]. . [22] The Quick Guide to Python Eggs [online]. The PEAK Developers’ Center. 2007-5-21–. [cit. 2007-12-27]. . [23] How to cook eggs for Trac [online]. 2007-7-11–. [cit. 2007-12-27]. . [24] Trac Downloads [online]. 2007-12-5–. [cit. 2007-12-27]. . [25] Downloads Plugin [online]. 2007-7-30–. [cit. 2007-12-27]. . [26] Google code – Developer Home [online]. Google. 2007–. [cit. 2007-12-27]. . [27] CAPTCHA: Telling Humans and Computers Apart Automatically [online]. Carnegie Mellon University Center. 2007–. [cit. 2007-12-27]. . [28] Google code – Google Chart API [online]. Google. 2007–. [cit. 2007-12-27]. .

41

Přílohy Příloha A – datový model systému Trac

42

Příloha B – úplná specifikace zásuvného modulu Downloader Download Module with Authentication for TRAC system =================================================== OBECNÉ: ------- Downloader bude připraven jako plug-in systému Trac - Skrytí souborů bude provedeno pomocí "zahrabání" v adresářové struktuře Tracu, stažení bude obstarávat skript, takže uživatel nikdy neuvidí skutečné umístění souboru, přístup k adresáři také pravděpodobně odstíní mod_rewrite, který je používán Tracem - Seznam souborů ke stažení bude v záložce modulu Downloaderu a bude dělen na tzv. Releases * U jednotlivých releases a souborů bude možnost přidat nějaký komentář (popis) - Soubory bude možné uploadovat pomocí administračního rozhraní - Každá část Download modulu bude mít vlastní práva nastavitelná v administraci Tracu * Prohlížení seznamu souborů a stahování souborů * Zobrazování statistik * Správa souborů REGISTRAČNÍ FORMULÁŘ: --------------------- Bude obsahovat zadávací pole pro: * Jméno * Příjmení * E-mail * S možností rozšíření o další (jako výběr k jakému účelu uživatel soubor stahuje) - Uživatel bude muset formulář vyplnit před každým stažením souboru * Nebude udržováno žádné propojení mezi staženími - E-mail bude ověřován: * Kontrolou regulárním výrazem * (případně) kontaktováním domovského SMTP serveru * (a V případě neúspěchu) odesláním e-mailu s tokenem pro ověření platnosti e-mailu - ověření opsáním textu z obrázku - bude použit nějaký Open Source generátor ověřovacích kódů ADMINISTRACE: ------------- Výpis všech vyplnění stahovacího formuláře: * Filtrování podle měsíce/týdne - Mazání záznamů bude možné provádět: * jako jednotlivé záznamy (výběrem ze seznamu) * jako skupinu ohraničenou časem - Nahrávání a správa souborů: * Vytvoření nového Release * Smazání/editace existujícího release * Nahrání souboru do release * Smazaání souboru z Release

43

* Přidání popisu k Release * Přidání popisu k souboru STATISTIKY: ----------- Hlavní statistikou budou měsíční souhrny všech stahování * Nakliknutím bude možné zobrazit jednotlivé týdny daného měsíce - Další statistika bude seznam souborů v tabulce s: * počtem stažení jednotlivého souboru celkem * počtem stažení v posledním měsíci - Po rozkliknutí bude u každého souboru vlastní statistika * pro jednotlivé měsíce * případně pro jednotlivé týdny * nebo ještě dny v měsíci - Seznam souborů bude možné řadit podle: * počtu stažení celkem * počtu stažení v některém měsíci

44

Příloha C – form_data.py – definice formuláře před stažením souboru # # # # # # # #

-*- coding: utf-8 -*Author: Petr Škoda All rights reserved. This software is licensed under GNU GPL. You can read http://www.gnu.org/licenses/gpl-3.0.html

it at

""" This file contains structures used to create question form which must user fill up before he can download any file. Each part like the one bottom represnts one item in questionnaire. { 'type': 'text', 'name': 'name', 'label': 'Name:', 'show_in_main_list': True, 'regexp': r'.*\w{2}.*', 'errinfo': 'Name must be at least 2 characters long.' }, ATTRIBUTES: type: text

radio

checkb

label

gives MEANINGFUL CO-ATTRIBUTES: name label show_in_main_list regexp errinfo cat gives MEANINGFUL CO-ATTRIBUTES: name label value show_in_main_list mustchoose (only first of same name) errinfo (only first of same name) cat gives MEANINGFUL CO-ATTRIBUTES: name label value show_in_main_list gives just text label into questionnaire (good for radios) MEANINGFUL CO-ATTRIBUTES: text label_for

45

name

Should be unique for each element in questionnaire, it's used to reference it. label Is text displayed to user about that item input questionnaire for example text above text input, or text on right side of radio and checkbox. value Is value of radio or checkbox which will be saved if that item is checked. regexp It's standard regular expression, this string should be signed with r before it like r'regular expression'. Documentation about Python regex is at http://docs.python.org/lib/re-syntax.html. For example if you want check only lenght of given string you can use regex like this: r'.*\w{2}.*' It says that correct is non whitespace value longer than 2 letters. errinfo This is the text given to user if he filled particular field incorrectly. It depends on regex for type text and on mustchoose for type radio. mustchoose You can set this to True in the first item of radio choose to foce user choose one of radios with that name. cat This is only for organisation, if you give the same cat for few elements one after another, they will be separated by space before and after whole category - good for radio and checkb. label_for Set this in type of label to name of some category (it's recomanded to cathegrorize radios and checkboxes) and this label will be shown at admin stats as name of this item when showing questionnaire fill up. If you don't use this, the name of radio will be taken from label of first radio input set. show_in_main_list If this is set to True, this item will be displayed input table on Stats admin page, so you can easily browse and sort it's values. FORBIDDEN NAMES: nr, id, timestamp, file_id, file_name """ quest_form = [ { 'type': 'text', 'name': 'name', 'label': 'Name:', 'show_in_main_list': True, 'regexp': r'.*\w{2}.*', 'errinfo': 'Name must be at least 2 characters long.' }, { 'type': 'text', 'name': 'surname', 'label': 'Surname:', 'show_in_main_list': True, 'regexp': r'.*\w{2}.*', 'errinfo': 'Surname must be at least 2 characters long.' }, { 'type': 'text', 'name': 'email', 'label': 'E-mail:', 'description': 'Valid e-mail address.', 'show_in_main_list': True, #'regexp': r'\S*@\S*\.\S*', # You can use regexp above if the one below doesn't work for you

46

# Or look here - http://www.regular-expressions.info/email.html 'regexp': r"[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z09!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+(?:[a-zAZ]{2}|com|COM|org|ORG|net|NET|gov|GOV|mil|MIL|biz|BIZ|info|INFO|mobi|MOBIL|name|NAM E|aero|AERO|biz|BIZ|info|INFO|jobs|JOBS|museum|MUSEUM)\b", 'errinfo': 'You must enter valid e-mail address.' }, { 'type': 'label', 'text': 'Purpose:', 'label_for': 'purpose' }, { 'type': 'radio', 'name': 'purpose', 'cat': 'purpose', 'value': 'private', 'label': 'Private', 'errinfo': 'You must specify purpose of your download.', 'mustchoose': True, 'show_in_main_list': True, }, { 'type': 'radio', 'name': 'purpose', 'cat': 'purpose', 'value': 'school', 'label': 'School', }, { 'type': 'text', 'name': 'purpose_shool_which', 'cat': 'purpose', 'label': 'Which school:', }, { 'type': 'radio', 'name': 'purpose', 'cat': 'purpose', 'value': 'commercial', 'label': 'Commercial', 'last': True, }, { 'type': 'text', 'name': 'purpose_commercial_which', 'cat': 'purpose', 'label': 'Which company:', }, ]

47

Příloha D – všechna nastavení zásuvného modulu Donwloader

48