Čistý Programátorský Experiment

Dovolte mi malý experiment. Týká se všech programátorů, které baví návrh aplikací a OOP. Zadám vám velmi jednoduchý úkol, který má mnoho možných řešení. A spíš než konkrétní kód mě zajímá způsob uvažování. Budu rád, když se zapojí programátoři používající různé jazyky. Proto také zadání zapíši v pseudokódu.

Mějme třídu WebPage, které zadáme URL a ona načte stránku a vrátí jeji obsah, hlavičky a dokonce i náhled v podobě obrázku. Příklad použití:

page = new WebPage
page.url = 'http://phpfashion.com'
echo page.url
echo page.body
echo page.headers
echo page.thumbnail

Chápejme url, body, headers a thumbnail jako vlastnosti (properties, accessors) třídy WebPage. Je asi zřejmé z logiky věci a principu zapouzdření, že zatímco url umožňuje zápis i čtení, ostatní vlastnosti lze pouze číst.

Protože funkčnost třídy WebPage je výkonnostně i časově náročná, je vhodné jednou získaná data ukládat do databáze. Jak to ale implementovat? Sice nejsnadnější by bylo rovnou upravit kód třídy WebPage, jenže takový postup je špinavý. Proč by třída s jednou srozumitelnou funkcionalitou měla navíc ještě komunikovat s databází? Pověříme tím tedy třídu WebPageStorage. Ta nám bude, mimo jiné, schopna dodat objekt WebPage rovnou z databáze:

page = WebPageStorage.load('http://phpfashion.com')
echo page.url
echo page.body
echo page.headers
echo page.thumbnail

Otázka zní: jak to naprogramovat?

Zopakuji, že se pídíme po nejčistším řešení. Jak docílit toho, aby metoda load mohla vytvořit objekt a nastavit mu read-only vlastnosti body, headers a thumbnail na hodnoty načtené z databáze? Vytvořením setterů nebo zpřístupněním vnitřních proměnných by se porušil princip zapouzdření. Navrhli byste redesign třídy WebPage? Jaký? Navrhli byste redesign WebPageStorage? A co když úkol zkomplikujeme tím, že thumbnail se z databáze načte až při vyžádání?

Věřím tomu, že pro řadu čtenářů je zadání naprosto triviální. Přesto se zkuste zamyslet nad nejčistším řešením a vysvětlete jej v komentářích. Klidně obšírně. Díky!

28. 10. 2009 PHP Komentáře: 84

Jak zazálohovat všechny své twíty

Pokud máte dojem, že ty 140 znakové kravinky, co píšete na Twitter, je nutné zálohovat pro příští generace, ať už z důvodu, že Twitter má občas výpadky doprovázené ztrátou dat, nebo vám někdo může účet ukrást a smazat, nebo se blížíte k limitu 3200 štěbetnutí, po kterém se (prý) nejstarší kusy odmazávají, nebo prostě chcete mít vše na disku kvůli lepšímu vyhledávání, je tento článek pro vás.

Protože jsme na blogu o PHP, nebudu zde popisovat online služby určené k zálohování, ale rovnou vypustím z klávesnice kus kvalitního objektového kódu ;)

Nejprve si stáhněte knihovničku Twitter for PHP (verzi 1.2) od stejnojmenného autora s autorem blogu. A pak si vytvořte zálohovač twitter-backup.php:

<?php
set_time_limit(0);

require 'twitter.class.php';

$twitter = new Twitter('davidgrudl', '......'); // zde dejte své přihlašovací údaje

// naráz lze načíst maximálně 200 twittů, tož budeme stránkovat
$page = 1;
do {
        try {
                $channel = $twitter->load(Twitter::ME, 200, $page);
                if (empty($channel->status)) { // prázdný výstup? narazili jsme na konec
                        break;
                }
                file_put_contents("twitter-backup.$page.xml", $channel->asXml());
                echo "Uložena stránka č.$page<br>";
                $page++;

        } catch (TwitterException $e) {
                echo 'Error: ', $e->getMessage();
                exit;
        }
} while (TRUE);

Po spuštění se vytvoří soubory twitter-backup.1.xml, twitter-backup.2.xml atd., podle toho, jak jste aktivní štěbetal. XML obsahuje skutečně vše, včetně informací, na koho zpráva reaguje, z jakého zařízení byla poslána nebo jaké máte barvičky v profilu.

12. 9. 2009 PHP Komentáře: 9

Vyplatí se jít na školení Jakuba Vrány?

Prapůvodně měl být na tomto místě ohlas na školení Jakuba Vrány Konfigurace a výkonnost MySQL. Chtěl jsem psát o tom, že ačkoliv mě Jakub dopředu varoval, že téma konfigurace MySQL není gór moc kůl, obavy se ukázaly jako liché, neboť prakticky každou vlastnost demonstroval na živých příkladech a tím držel posluchače ve střehu. Jako skvělý prezentační nástroj se přitom ukázal Adminer. Až jsem měl pocit, že si ho vyrobil speciálně k tomu účelu, protože s phpMyAdminem by tak ladně demonstrovat některé rysy MySQL nešlo. No a pak tu mám několik drobností, které bych školení vytkl, nicméně…

…Nicméně hlubší rozbor tohoto konkrétního školení vynechám. Jednak proto, že ho Jakub aktuálně nenabízí. (Přesněji řečeno nabízí řadu jiných školení a máte poslední šanci se na ně přihlásit, první z nich je totiž už zítra). A také proto, že více čtenářů bude zajímat odpověď na úvodní otázku.

Začnu obecně: aby pro vás školení mělo přínos, musí dojít k určité konjunkci hvězd:

přednášející musí tématu výborně rozumět
přednášející musí umět školit
přednášející musí mít školení dobře připravené
a vy si musíte vybrat správný kurz (a ptát se)

Že neříkám nic objevného? Kéž by. Divili byste se, kolik firem posílá lidi na školení k pánům nikdy-jste-o-mně-neslyšeli, jsem-o-kapitolu-před-vámi nebo říkají-mi-uspavač-hadů. Není lepší jít na doopravdické školení? Obzvlášť pikantní je, když se na takovém doopravdickém školení objeví osoba ze známé-školící-firmy, aby se to naučila, bo za týden to sama školí

Jak je na tom Jakub Vrána, jsou jeho školení doopravická? Nepopiratelně je významná osobnost PHP scény, jeho jméno najdete dokonce v dokumentaci. Navíc disponuje schopností přednášet, jeho výklad je srozumitelný a působí přirozeně. A když jsem z něj ve svých školitelských začátcích mámil know-how, shodli jsme se na tom, že jednomu kurzu věnujeme téměř rok příprav. Splňuje tedy všechny tři body. Čtvrtý už je na vás. Když ho splníte, tak vězte, že se školení rozhodně vyplatí.

Při psaní tohoto článku zemřelo jen zanedbatelné množství zvířat a žádný Davídek nebyl podplacen.

10. 9. 2009 PHP Komentáře: 12

Jak funguje zálohování disků „za chodu“

Na zálohování jsem si pořídil úžasný prográmek Drive SnapShot. Umí zálohovat celé disky, má pouhých 160kB a funguje nejen pod Windows , ale i pod DOS. Což se náramně hodí, pokud potřebujeme obnovit zhroucené Windows. A hlavně: umí provádět rozdílové zálohování, archívy šifrovat (AES, 128bit) a poté je mountovat jako další disk! Vřele doporučuji vyzkoušet.

Tento prográmek (stejně jako jemu podobné: Norton Ghost, Acronis True Image) dokáže uložit přesný obraz disku, jaký existoval v okamžiku spuštění. Vždycky mě ale zajímalo, jak zálohování on-fly vlastně funguje. Vždyť celá operace nějakou chvíli trvá. Od minut až po hodiny. Přesto program vytvoří přesný obraz disku, ať už s ním během zálohování dělám cokoliv. Jak je to možné?

Vše se točí kolem vyspělých operačních systémů na bázi NT. Tedy třeba Windows Vista, nikoliv však zastaralých 95/98. Při spuštění zálohování přikáže aplikace operačnímu systému, aby uložil všechna data, která si drží v paměti, na disk. Poté se napojí na diskový ovladač, aby mohla monitorovat každý přístup na disk. A zahájí kopírování pěkně sektor za sektorem.

Jakmile se objeví požadavek na zápis na disk, a to v místě, které ještě nebylo zálohované, tak tento sektor přednostně zazálohuje a pak teprve zápis povolí.

V tom je celý trik. Jakmile odstartujeme zálohování, můžeme na disku jakkoliv řádit, instalovat či mazat programy, chytit virus. Záloha bude vždy obsahovat konzistentní podobu disku v okamžiku spuštění. Chytré, co?

16. 8. 2009 PHP Komentáře: 9

Proč opustit Subversion (SVN)

Řada projektů opouští populární verzovací systém Subversion a přechází na jiný. Jaké jsou důvody?

K používání Subversion (SVN) mě přiměl kdosi v počátcích vývoje Texy. Veřejnému repositáři jsem odolával, protože mi připadalo, jako by mi někdo koukal při programování pod prsty. Během práce jsem ale stejně „verzoval“; archivoval RARem složku s kódem před každým větším zásahem. A něco sofistikovanějšího by bodlo. Zkusil jsem proto lokální SVN server s už tehdy skvělým GUI TortoiseSVN a rychle si na nový styl práce zvykl.

Teprve mnohem později jsem začal používat veřejné SVN. Pokud si odmyslíme nezpochybnitelné komunitní výhody, jako je spolupráce více vývojářů a přidaný rozměr pro chápání kódu (čas), nepřineslo to z hlediska jednotlivce nic pozitivního. Nešlo pracovat offline, dříve okamžité operace trvaly dlouhé sekundy. Jakákoliv chyba byla navždy zvěčněna v historii repositáře. Zjistil jsem, že během vývoje dílčích částí zase verzuji RARem a subversion mi přestal pomáhat.

Oči mi otevřel až Karmi, když mi ukázal, že kromě centralizovaných repositářů, jako je SVN, existují i distribuované (DVCS), které všechny zmíněné problémy řeší. Jsou umístěny lokálně s celou historií, takže nepotřebují internet a reagují bleskově. Lze v nich zkušebně rozvíjet několik vývojových cest. Ty slepé smažete, správnou pustíte na „centrální“ repositář. Úžasné! A tím výčet výhod nekončí.

Přejít na distribuovaný verzovací systém mi vyplynulo jako nutnost.

Jaký distribuovaný systém zvolit?

Karmi propaguje Git, který současné úložiště mých projektů Google Code nepodporuje. Nabízí však alternativu v podobě systému Mercurial (HG). Kromě těchto dvou je ještě slyšet o Bazaar. Který z nich zvolit? Jak se liší?

Pustil jsem se do důkladné rešerše a zjistil, že dobrat se odpovědi není vůbec snadné. Protože Subversion ve prospěch distribuovaných systémů opouští čím dál více projektů (jen PHP nyní slavně přešlo na SVN, hehehe), narazil jsem na tyto analýzy:

Z obou je cítit bezradnost, a ačkoliv volba padla na Mercurial, důvody nesouvisí s objektivní kvalitou systémů. Navíc za poslední půl rok se hodně změnilo a zmíněná absence GUI pro Windows v případě Gitu je dnes naopak jeho předností (tj. už má skvělé GUI).

Z dalších úvah jsem vyřadil nejmladší a nejméně populární Bazaar a podíval se zblízka na Git s Mercurialem.

Git

obrovský a komplexní projekt (možná až zmatený a nesrozumitelný)
umožňuje zasahovat do historie, mazat slepé větve
domovem je mu Linux, na Windows to není úplně ono
napsaný v C a shell skriptech
import i export SVN včetně historie
hosting: Github.com (mnohem lepší než Google Code)
GUI nástroj: TortoiseGit (vypadá přesně jako TortoiseSVN)
dokumentace (český překlad, začátečníkům nesrozumitelná)
cheat sheet

Mercurial

malý a chytrý (ovládáním podobný SVN)
nelze zasahovat do historie
výborně funguje na všech platformách
napsaný především v Pythonu
import SVN včetně historie
hosting: Bitbucket.org (mnohem lepší než Google Code)
GUI nástroj: TortoiseHg (jen se blíží TortoiseSVN)
dokumentace (anglická, ale čtivá a srozumitelná)
cheat sheet

Na rozpacích

Od začátku mi byl sympatičtější Mercurial, protože mám raději malé šikovné a promyšlené věci, než molochy (nejen ve frameworcích). Lépe funguje na Windows (import SVN repositáře je 70× rychlejší než na Git). Podporuje jej Google Code.

Jenže svět je složitější. Příklad: Mercurial má srozumitelnější příkazovou řádku, podobnou té v SVN. Jenže stejně ho budu ovládat pomocí GUI. Tam naopak (dnes) vede TortoiseGit, který jako by z oka vypadl TortoiseSVN, zatímco TortoiseHg je hodně jiný a slabší. Ale tím, že je jiný, umožňuje commitovat tzv. hunks. Což se mi skutečně často hodí. Nicméně s distribuovaným repositářem přichází jiný styl práce – budu i poté potřeboval hunks?

Mercurial čísluje revize, Git používá 40 místný hash. Preferuju samozřejmě číslo, ale není to jen pozůstatek SVN uvažování?

A tak by se dalo pokračovat dále. Nejsem zatím schopen říct, který ze systémů více vyhovuje mým potřebám. Jediná možnost je oběma věnovat několik dní času a zkusit s nimi pracovat. Co však můžu říct s naprostou jistotou je, že SVN chci opustit.

14. 8. 2009 PHP Komentáře: 53